Истинно так. Это все названия одной сущности "8человекочасов", "1 человекодень" или сторипоинт - по сути это просто мера. В классике берется эталонная понятная задача, ее нормируют на среднего сотрудника и назначают мерой в 1 сторипоинт. Все остальные задачи с ней сравниваются, и получается эта таска из 7 таких эталонных - ее оценка 7 сторипоинтов. Или человекодней. Или 56 человекочасов.
на практике же у тебя выпуск задачи - это и работа аналитика, часто ux, так же разработчика и тестера. И кто-то из них в отпуске, кто-то заболел, кто-то будет медленнее делать, так как заменяет Серегу, который на таких тасках задачу съел, и так далее. В итоге любые оценки задач и попытки их уместить в единицу релизовремени (спринт) - это все равно планирование конкретных исполнителей на конкретные задачи в конкретные временные отрезки. И как следствие - их оценивать и делать должны или равные по скиллу или те же люди, кто их будет делать. И только с 1 целью - понять и сделать оптимальным инкремент, который выйдет в прод, и запланировать занятость людей и приоритеты.
Так что все эти методологии по сути просто попытка оценки на глаз опытным менеджером переложить на команду, разделить якобы ответственность, и вместо решения проблемы заказчика (либо мы хотим точно знать, что и когда мы получим, либо мы хотим получать больше просто потому что) попытки сделать красивое лицо при плохой игре.
А реальных выхода всегда 2:
сделать процесс планирование с вовлечением заказчика, чтобы заказчик жил с командой и понимал процессы, тогда его ожидания будут совпадать, он не сможет сказать условному Сереге, что он проканал сроки, потому что будет видеть, что Серега сделал все, что мог, и проблема вне команды, и принимать это нормально и с пониманием, и сам отстаивать сроки и снижать ожидания
либо нанимать блин больше людей, если не хватает, и выделять больше бюджета, а не делать мозги, что у Петьки в стартапе в приложении на 15000 строк кода ребята делают 20 задач, а вы в платформе с 3млн пользователей ежедневно и 25 миллионами строк кода и ограничениями в ИБ и кучей интеграций только аналитите 2 месяца.
Вот и вся петрушка. Делать быстро несложно. И оценивать несложно. В маленьких продуктах без зависимостей, выделенной и достаточной командой и разделением на growth и саппорт в рамках итерации, чтобы никто не прибегал с важной таской на зашел и вышел, отвлекая от запланированного времени. В остальных случаях хорошее планирование - лишь цепь случайно сошедшихся обстоятельств, а неудачное - вина команды, все не так, давай менять процессы, но времени и денег на это мы не выделим)))
В таком случае я согласен с предыдущим оратором, вы снова про инструмент вместо процесса.
Процесс - это про то, как вы выявляете требования. На старте, в середине, на завершении проекта и в процессе эксплуатации продукта. Процесс - это как вы работаете с требованиями. Стратегически, тактически, календарно и так далее, не в каком инструменте, а как и почему
Ключевой посыл любого требования - это нахера. Нахера оно надо заказчику? а продукту? А команде? Инструмент, который не отражает ответа на этот вопрос - это скорее карта, визуализация, и чек-лист, но это соблюдение опять же, а не выявление и работа с требованием. И как следствие, у вас спутана роль - эта штука про QA и тестирование требований, а не про анализ. От анализа здесь ничего нет, это другой контекст, к сожалению.
Это не плохо, статья была полезна для меня, например, я ее для qa как раз и покажу. Но тяжело будет получить релевантную аудиторию аналитиков, я бы переименовал тогда, и картинка сложится
А давай зададим вместо твоего вопроса "правильный вопрос" - а зачем/нахрена вообще измерять метрикой качество кода? Ты измеряешь метрикой количество кислорода в воздухе, которым тебе надо дышать? Нет. Ты берешь и дышишь или просто не дышишь. Так и с кодом - нет смысла измерять метрикой то, что должно быть стандартом, который соблюдается. Для этого должны быть прописаны эти стандарты и внедрены механизмы контроля - код-ревью, перформансы, а так же принята за аксиому идея писать код, соответствующий этим требованиям. И тогда качество кода прямо влияет на скорость выполнения задачи командой или отдельным человеком.
Если условный Васян делает среднюю задачу, доходящую до тестирования (то есть уже прошедшую код-ревью), за 18чч, а Пашан за 8ч, то вот и показатель эффективности сотрудника. А качество кода - это не показатель, а критерий, который в принципе нельзя нарушить.
Если вернуться к первоначальному вопросу, то проблема *у нас выходит некачественный код" решается не метрикой, а стандартом "выпускать весь код качественно". Так зачем нужна метрика, отражающая 100 процентов по умолчанию? Нужна лишь метрика, за какой срок это выполняется.
В свое время в работе в студии был Б24 раздел "проекты". А там тебе и канбан, и автоматизации, и чат внутри, и статистика, и ваще че хочешь как из коробки, так и настраивай, дешево и сердито оказалось (хочешь, бизнес-процессы делай, хочешь, воронки строй как хошь, вот тебе и гант есть, и иерархия + переписка, и звонилка даже внутри). Максимально удобная система, которая просто забывает себя позиционировать на управление проектами, хотя у нее все для этого есть. При этом это было облако, даже не коробка, в которой можно было бы кодить все, и даже облака с головой хватало
Да, не JIRA+confluence и все такое, но куда шире по возможностям. Сейчас в компании azure.devops, более приближенная к жире система, тоже приятная, хотя несколько непривычно по началу, но и ей хватает гибкости. А обзор классических канбанов скучноват показался.
а что ты хочешь узнать? Как последних безопасников за пару месяцев до этого отпустили, а инфре зарезали бюджеты? Компанию продавали подороже, резали расходы как могли. В итоге шифровальщика поймали на всю инфру, пришли с утра, а нет ничего. Вот и вся любовь. как так вышло? А изян, когда некому следить за безопасностью, никто и не следит.
я как муж своей жены, которая тогда руководила третью разработки СДЭКа, могу сказать, что тот подвиг, который они совершили, это просто невероятно, столько не спать всей командой и вытащить это все.
А их вины примерно 0. Не они командами денег на инфру и инфобез пожалели, но восстанавливали он .
Тут ответ простой. Разработке можно работать просто. А те ребята, которые этой разработке платят, планируют сроки и деньги, чтобы оценить возврат инвестиций. А для этого надо знать, что тот или иной продукт или фича выйдут в таких-то пределах, потребуют столько-то людей (которых надо донанаять и обучить к такому-то сроку), когда нужно докредитоваться и получить определенный объем денег на счете для того, чтобы платить зарплаты и дивиденды, да и прочие подобные скучные вещи. При этом никто не требует точного до дня планирования, так как планы идут кварталами и годами, но хочется, чтобы эти планы выполнялись в целом, и для этого и нужны взвешенные и не пущенные на самотек процессы, а какое-то внятное по процедуре планирование в спринт, в силы команды и в людей. Так как эти сущности не прогнозируемы точно, то идет вероятностная оценка, выстраивается доверительный интервал в +-20 процентов, и балансируется переработками/уделением времени в обучение и техдолг, чтобы все заработали свое бабло. Кодить в вакууме хорошо, когда ты несешь отвестственность за самого себя. А когда у тебя таких кодеров 15000, бюджеты в миллиарды и триллионы - без планирования и слоя бюрократии никуда. Главное без перегибов и энтузиастов бюрократии - чтобы эта процедура была быстрой и БОЛЕЕ-МЕНЕЕ реальной, в среднем сходилась, риски учитывала и ехала
основная типовая проблема - это баланс времени, потраченного на оценку и реализацию. Глубокая оценка с проработкой зачастую - это 80 процентов времени и успеха задачи. Так тратить их заранее только для того, чтобы решить, ехать ли в спринт или нет - кощунство, ведь задач в хорошем продукте куда больше, чем людей, они имеют тенденцию устаревать, меняться, отпадать - и жалко как-то потратить время и не сделать
Отсюда и вырастает процедура экспресс-оценки в попугаях, которая дается для того, чтобы просто взвесить задачу на предмет профит/трудозатраты относительно других задач и выстроить приоритеты.
Совершенно очевидно, что любая задача может оказаться быстрее или медленнее, чем планировалось. Но это нивелируется в обе стороны другими задачами спринта, так как в одну задачу ты по факту недозаложил 3чд, в другой сделал на эти же 3чд быстрее. Если исполняется 90 процентов запланированого - значит планирование эффективно. Главное себе не врать и не оценивать овермного или овервпритык. Именно честная оценка, + чуть перезакладываться ведет к успеху (так как тогда ты можешь не сделать 1 задачу, ставшую из Mки XLкой, но сделав вместо этого 7XSок). Бизнес-заказчик это вполне поймет и одобрит, ну и рассматривать лишь 1 задачу, вышедшую по срокам с конкретными объяснениями просто и понятно.
Если же ситуация, что задачи сделаны, а время осталось... ну техдолг, задачи по приоритетам из след.спринта и все такое - легко найти занятость, короч. Как итог - команда не выгорает на переработках, планы исполняются, прогнозируемы, релизы ожидаемы, сроки и бюджеты бьются, премии лутаются и командой и бизнесом, все в срок, все путем.
Для этого нужен адекватный рук.команды/лид, который отстаивает объем спринта (что-то добрать=что-то выкинуть), не планирует оверсайз, и умеет объяснить и договориться с бизнесом, почему так и столько без торгов на рынке "делайте быстрее" или "ну позязя, еще вот это", и при этом система гроу разделена от системы поддержки и эксплуатации (дежурные в команде/дежурная команда на инциденты, а не овертаймить, чтобы что-то починить и переключать контексты). Ну и продакт/бизнес, который учится быстро/уже умеет в адекватные приоритеты и на связи с командой тесно.
Вот, собственно, и вся разработка 2000-2025. Проводи своевременно оценки/грумминги, планирования, мутите ретры, чтобы высказывать друг другу и решать проблемы, как делать лучше, тусуйтесь и относитесь к продукту, как к своему, отстаивайте свои интересы, но иногда в обе стороны прогибайтесб под потребности, делитесь между бизнесом и разработкой планами, цклями и проблемами и вместе ищите способы их преодолеть - и успешный успех IT-разработки достигнут.
Давай попробую сформулировать идею, которая первая пришла мне в голову.
На Большом Адронном Коллайдере в точке А выпускается пучок заряженных частиц, который может обладать разной энергией, и от нее зависит скорость каждой отдельной частицы. К сожалению, чтобы найти субатомную частицу и измерить ее показатели, надо быть точно уверенным, что в точке замера частица одна. А они еще и по кругу бегают. А испускать ровно 1 частицу не получается, их всегда несколько.
Можно ли во-первых, посчитать точное количество частиц (и за какое время) и как, а так же измерить показатели каждой, достоверно предполагая, что в моменты измерения в точке частицы однозначно были одиноки?
я боюсь, ято автор выше совершенно перевернул ваше представление о мире. Вы реализовали функционал на ядре решения...нарушающего законодательство) Речь о том самом cades, о котором вам намекает пользователь выше: ваша задача не просто поставить ЭЦП вида УНЭП/УКЭП, а еще и обеспечить соответствие хранения этой эцп 50 лет, а это не сервис тайм-стампов, а сам вид ЭЦП. Таймстампы обеспечивают смежную задачу - умеют подтверждать достоверность подписи в моменте времени, а так же подписи, ее подписавшей и так далее по "матрешке вложенности подписей".
Но все не так плохо: вам нужно не саму систему переделать, а лишь модуль подписи, то есть составную часть, а так же обеспечить корректное наложение и проверку стампов при вызове документов на подпись и из архива. Ну и собственно, этот же коммент открывает вам еще 1 задачу: что делать с документами, где ЭЦП в момент времени просрочилась? До какого момента должен на самом деле действовать документ? До минимального значения подписи в цепочке? Еще как-то?
А если придет проверка, как УЦ бцдет доказывать достоверность? А есть crl-ы? В общем, вот и смежный продукт и его свойства)))
А в остальном классно, когда дешево удается сварить MVP, да еще и с приличной функциональностью. Главное, не упустить момент, когда он перестанет быть масштабирован, и пора вернуться к разработке
Егор, привет. Внезапно наткнулся на твою статью, и она как откликнулась моей болью, может что-то посоветуешь. Привет от бывшего длинноволосого Артура)
Есть продукт, довольно большая CRM, в которой много разных направлений живут со своими воронками, отчетами и прочими радостями, частично или полностью пересекаясь. Изначальная документация кривая и больше техническая, не хватает как раз понимания, что на что влияет, как следствие версии при выходе часто ломают что-то старое. Собрать тест-кейсы для регресса так же тяжело, так как тестеры в продукте всегда свежие, и посадить их за описание - это по сути на месяц садить их учить, что мы делаем, и черкз 2 месяца все по новой (оргдизайн управления проектный, люди бегают, никто не в продукте). С чего и через кого лучше начать описание всего, что есть с взаимосвязями между фичами и структурными блоками?
Похожую схему делали с кластером редиса, в принципе не могу сказать, что в чем-то концептуальные отличия, так же сваренный синхронизатор, структура БД для хранения, и индексы. Коллеги просто не стали описывать типовые процедуры прогрева редиса в первый раз, перезапись в случае сбоев из БД и так далее. Персистентность нужна для того, чтобы не приходилось кэш обнулять и перезаписывать, это довольно затратная по ресурсам операция, типа "а давай-ка 100500 записей удалим, а то есть подозр, что какие-то из них битые, и запишем заново" - и хренак, на 4-6 часов у тебя инстанс вылетает из пула, перезаписывается, и так все по очереди (мы же не дурачки, да, в одном кеше все хранить, нужен кластерок). И тут тоже свои песни возникают, типа "а если за время синхронизации еще записей появилось? А если изменилось что-то в бд? - то есть еще возникает некая промежуточная шина, в которую на время обновления пишутся события обновления, чтобы потом после полной перезаписи их раздать, и так по каждому инстансу кеша. Короч, решение скажем так сложнее, чем тцт описано, но у ребят явно не было цели описать все, скорее "а как заманить к ним в команду клиента, которому это надо".
jtbd в вашем случае - это набор функциональностей и пользы, которых еще нет в дадата, маркетинга, чтобы хоть кому-то продать сервис. А не чтобы одна фича в прод уехала. Вы на уровне проджекта смотрите "что нужно сделать, чтобы фича была полезной", а на уровне продакта это "что нужно сделать, чтобы продукт был коммерчески успешным", если прям грубо и приблизительно выразиться.
Ключевая проблема такого подхода (у него есть даже термин - фичерить) - это что в продукт вносится куча разных улучшений, отдельных, небольших, которые кушают бюджеты по частям, в итоге съедая очень много в сумме, но не общая стратегия, которая приводит проект к коммерции.
А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.
Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они - платформа, на которой ваши клиенты обитают.
jtbd в вашем случае - это набор функциональностей и пользы, которых еще нет в дадата, маркетинга, чтобы хоть кому-то продать сервис. А не чтобы одна фича в прод уехала. Вы на уровне проджекта смотрите "что нужно сделать, чтобы фича была полезной", а на уровне продакта это "что нужно сделать, чтобы продукт был коммерчески успешным", если прям грубо и приблизительно выразиться.
Ключевая проблема такого подхода (у него есть даже термин - фичерить) - это что в продукт вносится куча разных улучшений, отдельных, небольших, которые кушают бюджеты по частям, в итоге съедая очень много в сумме, но не общая стратегия, которая приводит проект к коммерции.
А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.
Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они -платформа
Но ты же при этом понимаешь, что ВЕРОЯТНОСТЬ, что человек окажется завтра на войне/взломан/убит/закрыт великим файрволом в подворотне ниже в условной Голландии, чем в РФ? А жизнь - это череда вероятностей, и работа по митигации рисков бизнеса - это ключевая задача СБ/ИБ. Рынок вне РФ чуть более конкурентен со стороны работодателя, и поэтому они могут выбирать. Это у себя на стуле ты хороший. А он видит 70 стульев, где все хорошие, и ему проще выбрать тот стул, который хорош со всех сторон)
слушай, мы с моей прошлой командой прям друзья. Вместе тусим, ходим по барам, ходим в гости друг к другу, играем на гиатрке, снова пьем, говорим о чем угодно и так далее. Вы почему-то ограничиваетесь работой как работой - делать таски и получать зп. Это тоже важно и нужно, но чьерт побьери, я могу делать таски и получать зп и все, а могу делать таски, получать зп и круто проводить время в компании друзей. Это никак не мешает мне делать свою работу. Никто не мешает мне шутить и смеяться, даже если полный треш вокруг. Потому что с грустным хлебалом я уже работал, больше не хочу. И поверь, если ты сам открыт к людям, то и люди к тебе открыты. Если ты понимаешь, что у условного Сани вечером др, ты никогда в жизни не запланируешь на него какой-то левый кранч. Если ты знаешь, что Юльке в 6 надо быть в садике, ты будешь планировать спринты и ее загрузку с учетом этого знания, а не "я чет там напланировал, а команда опять меня подвела".
И если у пацанов и чик проблемы на работе или вне ее - мы их реально перетрем, что на ретро, что в баре, так как мы бро, а бро слушает своего бро, ферштейн? И проблема решится, потому что если бро в соло не может, мы ему поможем на том или ином уровне. Я вот продакт, и мог прийти и попросить к линейным рукам бабок тому или иному сотруднику, потому что его уже заманало, а морально не умеет просить. А мне черт возьми не жалко, мне жалко, если я хорошего человека и сотрудника из команды потеряю. Если он будет ходить унылым и не хотеть делать свою работу (а че мы потом в баре обсудим?!) Если есть тела, которые не влились, то можно ж вместе их подкалывать?
Так что я тут с ТСом согласен от и до - нормально общаешься - быстрее летит. А когда сидишь в своей конуре в одного 24/7, то и пропускаешь как весь движ, так и всю помощь.
У меня было в управлении 2 команды - веб и мобилки, с частью общих сервисов, где как раз оценки фронтов были близки к правде, а оценки на сервисы сильно расходились с действительностью именно в мобильной команде.
Что сделали: мобилки согласовали некий шаблон оценки задач и рисков при ее решении, и мы договорлись, что задачи со средней степенью неопределенности и сложнее мы идем и оцениваем дольше, выделяя время в спринте только на оценку (с неким исследованием). Если задача в принципе неоцениваема, мы выделяли отдельной задачей поиск решения, согласовывали на это выделение времени, и после поиска задача сводилась из высокой неопределенности к средней или набору простых, и оценки бились. Оценки нужны для 2х вещей: чтобы спринт был наполнен, а не перегружен (то есть чтобы разработчик честно сказал, я не сделаю - и не сделал), а так же чтобы бизнесовому заказчику делать ограничения с 2х сторон на периоде (сделаем не раньше такого-то и не позже такого-то).
Итог довольно простой: в командах вопрос на ретро "почему ты не сделал, хотя мы же планировали" перестал подниматься в принципе, отношения стали гораздо лучше, а для бизнеса стало понятнее, что если они хотят что-то впихнуть, то придется чем-то жертвовать. Я продакт, то есть я представлял тот самый бизнес, но так как я же и проджект (ну не было отдельного, епрст), я же и понимал необходимость ограничений, прекрасно понимал своих парняг и девчин в команде, и как следствие, у нас доверие, чилл, отсутствие авралов по вине перепланирования, не было кранчей - мне спокойно, людям спокойно.
а если приходить сверху и как заказчик "а к среде сделаете? а почему?", не разбираться в процессах, не иметь понимания технологий и ограничений, не видеть ситуацию изнутри - то да, проблема оценок стоит остро, тогда "эти они виноватые, а я все сделал" и прочие радости эффективного менеджмента вылезают. Вы одно целое с командой, один продукт делаете, один хлеб едите, так и двигайтесь к общим интересам
Мы когда приходили с проблемой оценок в команду, мы тоже с вторым коллегой-продактом приходили не с ноги "вы все косяки", а с проблемой "у нас есть запрос озвучивать границы, мы уже и перезакладываемся, и че тока не делаем, но все равно случается попадос, и влетаем - ребяты, как можно сделать лучше".
и ретры не ради ретр, а ретры от лица любого члена команды с подобными вопросами имеют место быть, с совместным же решением, благодарностями, участием. Вот тогда щасье
боюсь, это неправда. Тендер - это тендер по условиям. То, что в результате тендера компания должна сделать согласно ТЗ/требований - это как отче наш. Но есть еще требования с коэффициентами, типа компания имеет аналогичные проекты такой же компетенции, сколько у компании сотрудников по профилю, что есть из сертификатов и так далее - в общем, это так же параметры честного тендера, не только цена. И итог - это кэф*цену, то есть приведенная цена контракта
Истинно так. Это все названия одной сущности "8человекочасов", "1 человекодень" или сторипоинт - по сути это просто мера. В классике берется эталонная понятная задача, ее нормируют на среднего сотрудника и назначают мерой в 1 сторипоинт. Все остальные задачи с ней сравниваются, и получается эта таска из 7 таких эталонных - ее оценка 7 сторипоинтов. Или человекодней. Или 56 человекочасов.
на практике же у тебя выпуск задачи - это и работа аналитика, часто ux, так же разработчика и тестера. И кто-то из них в отпуске, кто-то заболел, кто-то будет медленнее делать, так как заменяет Серегу, который на таких тасках задачу съел, и так далее. В итоге любые оценки задач и попытки их уместить в единицу релизовремени (спринт) - это все равно планирование конкретных исполнителей на конкретные задачи в конкретные временные отрезки. И как следствие - их оценивать и делать должны или равные по скиллу или те же люди, кто их будет делать. И только с 1 целью - понять и сделать оптимальным инкремент, который выйдет в прод, и запланировать занятость людей и приоритеты.
Так что все эти методологии по сути просто попытка оценки на глаз опытным менеджером переложить на команду, разделить якобы ответственность, и вместо решения проблемы заказчика (либо мы хотим точно знать, что и когда мы получим, либо мы хотим получать больше просто потому что) попытки сделать красивое лицо при плохой игре.
А реальных выхода всегда 2:
сделать процесс планирование с вовлечением заказчика, чтобы заказчик жил с командой и понимал процессы, тогда его ожидания будут совпадать, он не сможет сказать условному Сереге, что он проканал сроки, потому что будет видеть, что Серега сделал все, что мог, и проблема вне команды, и принимать это нормально и с пониманием, и сам отстаивать сроки и снижать ожидания
либо нанимать блин больше людей, если не хватает, и выделять больше бюджета, а не делать мозги, что у Петьки в стартапе в приложении на 15000 строк кода ребята делают 20 задач, а вы в платформе с 3млн пользователей ежедневно и 25 миллионами строк кода и ограничениями в ИБ и кучей интеграций только аналитите 2 месяца.
Вот и вся петрушка. Делать быстро несложно. И оценивать несложно. В маленьких продуктах без зависимостей, выделенной и достаточной командой и разделением на growth и саппорт в рамках итерации, чтобы никто не прибегал с важной таской на зашел и вышел, отвлекая от запланированного времени. В остальных случаях хорошее планирование - лишь цепь случайно сошедшихся обстоятельств, а неудачное - вина команды, все не так, давай менять процессы, но времени и денег на это мы не выделим)))
и тут придумывается вместо бита...кубит!)))
В таком случае я согласен с предыдущим оратором, вы снова про инструмент вместо процесса.
Процесс - это про то, как вы выявляете требования. На старте, в середине, на завершении проекта и в процессе эксплуатации продукта. Процесс - это как вы работаете с требованиями. Стратегически, тактически, календарно и так далее, не в каком инструменте, а как и почему
Ключевой посыл любого требования - это нахера. Нахера оно надо заказчику? а продукту? А команде? Инструмент, который не отражает ответа на этот вопрос - это скорее карта, визуализация, и чек-лист, но это соблюдение опять же, а не выявление и работа с требованием. И как следствие, у вас спутана роль - эта штука про QA и тестирование требований, а не про анализ. От анализа здесь ничего нет, это другой контекст, к сожалению.
Это не плохо, статья была полезна для меня, например, я ее для qa как раз и покажу. Но тяжело будет получить релевантную аудиторию аналитиков, я бы переименовал тогда, и картинка сложится
А давай зададим вместо твоего вопроса "правильный вопрос" - а зачем/нахрена вообще измерять метрикой качество кода? Ты измеряешь метрикой количество кислорода в воздухе, которым тебе надо дышать? Нет. Ты берешь и дышишь или просто не дышишь. Так и с кодом - нет смысла измерять метрикой то, что должно быть стандартом, который соблюдается. Для этого должны быть прописаны эти стандарты и внедрены механизмы контроля - код-ревью, перформансы, а так же принята за аксиому идея писать код, соответствующий этим требованиям. И тогда качество кода прямо влияет на скорость выполнения задачи командой или отдельным человеком.
Если условный Васян делает среднюю задачу, доходящую до тестирования (то есть уже прошедшую код-ревью), за 18чч, а Пашан за 8ч, то вот и показатель эффективности сотрудника. А качество кода - это не показатель, а критерий, который в принципе нельзя нарушить.
Если вернуться к первоначальному вопросу, то проблема *у нас выходит некачественный код" решается не метрикой, а стандартом "выпускать весь код качественно". Так зачем нужна метрика, отражающая 100 процентов по умолчанию? Нужна лишь метрика, за какой срок это выполняется.
В свое время в работе в студии был Б24 раздел "проекты". А там тебе и канбан, и автоматизации, и чат внутри, и статистика, и ваще че хочешь как из коробки, так и настраивай, дешево и сердито оказалось (хочешь, бизнес-процессы делай, хочешь, воронки строй как хошь, вот тебе и гант есть, и иерархия + переписка, и звонилка даже внутри). Максимально удобная система, которая просто забывает себя позиционировать на управление проектами, хотя у нее все для этого есть. При этом это было облако, даже не коробка, в которой можно было бы кодить все, и даже облака с головой хватало
Да, не JIRA+confluence и все такое, но куда шире по возможностям. Сейчас в компании azure.devops, более приближенная к жире система, тоже приятная, хотя несколько непривычно по началу, но и ей хватает гибкости. А обзор классических канбанов скучноват показался.
а что ты хочешь узнать? Как последних безопасников за пару месяцев до этого отпустили, а инфре зарезали бюджеты? Компанию продавали подороже, резали расходы как могли. В итоге шифровальщика поймали на всю инфру, пришли с утра, а нет ничего. Вот и вся любовь. как так вышло? А изян, когда некому следить за безопасностью, никто и не следит.
я как муж своей жены, которая тогда руководила третью разработки СДЭКа, могу сказать, что тот подвиг, который они совершили, это просто невероятно, столько не спать всей командой и вытащить это все.
А их вины примерно 0. Не они командами денег на инфру и инфобез пожалели, но восстанавливали он .
Тут ответ простой. Разработке можно работать просто. А те ребята, которые этой разработке платят, планируют сроки и деньги, чтобы оценить возврат инвестиций. А для этого надо знать, что тот или иной продукт или фича выйдут в таких-то пределах, потребуют столько-то людей (которых надо донанаять и обучить к такому-то сроку), когда нужно докредитоваться и получить определенный объем денег на счете для того, чтобы платить зарплаты и дивиденды, да и прочие подобные скучные вещи. При этом никто не требует точного до дня планирования, так как планы идут кварталами и годами, но хочется, чтобы эти планы выполнялись в целом, и для этого и нужны взвешенные и не пущенные на самотек процессы, а какое-то внятное по процедуре планирование в спринт, в силы команды и в людей. Так как эти сущности не прогнозируемы точно, то идет вероятностная оценка, выстраивается доверительный интервал в +-20 процентов, и балансируется переработками/уделением времени в обучение и техдолг, чтобы все заработали свое бабло. Кодить в вакууме хорошо, когда ты несешь отвестственность за самого себя. А когда у тебя таких кодеров 15000, бюджеты в миллиарды и триллионы - без планирования и слоя бюрократии никуда. Главное без перегибов и энтузиастов бюрократии - чтобы эта процедура была быстрой и БОЛЕЕ-МЕНЕЕ реальной, в среднем сходилась, риски учитывала и ехала
основная типовая проблема - это баланс времени, потраченного на оценку и реализацию. Глубокая оценка с проработкой зачастую - это 80 процентов времени и успеха задачи. Так тратить их заранее только для того, чтобы решить, ехать ли в спринт или нет - кощунство, ведь задач в хорошем продукте куда больше, чем людей, они имеют тенденцию устаревать, меняться, отпадать - и жалко как-то потратить время и не сделать
Отсюда и вырастает процедура экспресс-оценки в попугаях, которая дается для того, чтобы просто взвесить задачу на предмет профит/трудозатраты относительно других задач и выстроить приоритеты.
Совершенно очевидно, что любая задача может оказаться быстрее или медленнее, чем планировалось. Но это нивелируется в обе стороны другими задачами спринта, так как в одну задачу ты по факту недозаложил 3чд, в другой сделал на эти же 3чд быстрее. Если исполняется 90 процентов запланированого - значит планирование эффективно. Главное себе не врать и не оценивать овермного или овервпритык. Именно честная оценка, + чуть перезакладываться ведет к успеху (так как тогда ты можешь не сделать 1 задачу, ставшую из Mки XLкой, но сделав вместо этого 7XSок). Бизнес-заказчик это вполне поймет и одобрит, ну и рассматривать лишь 1 задачу, вышедшую по срокам с конкретными объяснениями просто и понятно.
Если же ситуация, что задачи сделаны, а время осталось... ну техдолг, задачи по приоритетам из след.спринта и все такое - легко найти занятость, короч. Как итог - команда не выгорает на переработках, планы исполняются, прогнозируемы, релизы ожидаемы, сроки и бюджеты бьются, премии лутаются и командой и бизнесом, все в срок, все путем.
Для этого нужен адекватный рук.команды/лид, который отстаивает объем спринта (что-то добрать=что-то выкинуть), не планирует оверсайз, и умеет объяснить и договориться с бизнесом, почему так и столько без торгов на рынке "делайте быстрее" или "ну позязя, еще вот это", и при этом система гроу разделена от системы поддержки и эксплуатации (дежурные в команде/дежурная команда на инциденты, а не овертаймить, чтобы что-то починить и переключать контексты). Ну и продакт/бизнес, который учится быстро/уже умеет в адекватные приоритеты и на связи с командой тесно.
Вот, собственно, и вся разработка 2000-2025. Проводи своевременно оценки/грумминги, планирования, мутите ретры, чтобы высказывать друг другу и решать проблемы, как делать лучше, тусуйтесь и относитесь к продукту, как к своему, отстаивайте свои интересы, но иногда в обе стороны прогибайтесб под потребности, делитесь между бизнесом и разработкой планами, цклями и проблемами и вместе ищите способы их преодолеть - и успешный успех IT-разработки достигнут.
спасибо большое. Пошел применять
Давай попробую сформулировать идею, которая первая пришла мне в голову.
На Большом Адронном Коллайдере в точке А выпускается пучок заряженных частиц, который может обладать разной энергией, и от нее зависит скорость каждой отдельной частицы. К сожалению, чтобы найти субатомную частицу и измерить ее показатели, надо быть точно уверенным, что в точке замера частица одна. А они еще и по кругу бегают. А испускать ровно 1 частицу не получается, их всегда несколько.
Можно ли во-первых, посчитать точное количество частиц (и за какое время) и как, а так же измерить показатели каждой, достоверно предполагая, что в моменты измерения в точке частицы однозначно были одиноки?
я боюсь, ято автор выше совершенно перевернул ваше представление о мире. Вы реализовали функционал на ядре решения...нарушающего законодательство) Речь о том самом cades, о котором вам намекает пользователь выше: ваша задача не просто поставить ЭЦП вида УНЭП/УКЭП, а еще и обеспечить соответствие хранения этой эцп 50 лет, а это не сервис тайм-стампов, а сам вид ЭЦП. Таймстампы обеспечивают смежную задачу - умеют подтверждать достоверность подписи в моменте времени, а так же подписи, ее подписавшей и так далее по "матрешке вложенности подписей".
Но все не так плохо: вам нужно не саму систему переделать, а лишь модуль подписи, то есть составную часть, а так же обеспечить корректное наложение и проверку стампов при вызове документов на подпись и из архива. Ну и собственно, этот же коммент открывает вам еще 1 задачу: что делать с документами, где ЭЦП в момент времени просрочилась? До какого момента должен на самом деле действовать документ? До минимального значения подписи в цепочке? Еще как-то?
А если придет проверка, как УЦ бцдет доказывать достоверность? А есть crl-ы? В общем, вот и смежный продукт и его свойства)))
А в остальном классно, когда дешево удается сварить MVP, да еще и с приличной функциональностью. Главное, не упустить момент, когда он перестанет быть масштабирован, и пора вернуться к разработке
Егор, привет. Внезапно наткнулся на твою статью, и она как откликнулась моей болью, может что-то посоветуешь. Привет от бывшего длинноволосого Артура)
Есть продукт, довольно большая CRM, в которой много разных направлений живут со своими воронками, отчетами и прочими радостями, частично или полностью пересекаясь. Изначальная документация кривая и больше техническая, не хватает как раз понимания, что на что влияет, как следствие версии при выходе часто ломают что-то старое. Собрать тест-кейсы для регресса так же тяжело, так как тестеры в продукте всегда свежие, и посадить их за описание - это по сути на месяц садить их учить, что мы делаем, и черкз 2 месяца все по новой (оргдизайн управления проектный, люди бегают, никто не в продукте). С чего и через кого лучше начать описание всего, что есть с взаимосвязями между фичами и структурными блоками?
Похожую схему делали с кластером редиса, в принципе не могу сказать, что в чем-то концептуальные отличия, так же сваренный синхронизатор, структура БД для хранения, и индексы. Коллеги просто не стали описывать типовые процедуры прогрева редиса в первый раз, перезапись в случае сбоев из БД и так далее. Персистентность нужна для того, чтобы не приходилось кэш обнулять и перезаписывать, это довольно затратная по ресурсам операция, типа "а давай-ка 100500 записей удалим, а то есть подозр, что какие-то из них битые, и запишем заново" - и хренак, на 4-6 часов у тебя инстанс вылетает из пула, перезаписывается, и так все по очереди (мы же не дурачки, да, в одном кеше все хранить, нужен кластерок). И тут тоже свои песни возникают, типа "а если за время синхронизации еще записей появилось? А если изменилось что-то в бд? - то есть еще возникает некая промежуточная шина, в которую на время обновления пишутся события обновления, чтобы потом после полной перезаписи их раздать, и так по каждому инстансу кеша. Короч, решение скажем так сложнее, чем тцт описано, но у ребят явно не было цели описать все, скорее "а как заманить к ним в команду клиента, которому это надо".
jtbd в вашем случае - это набор функциональностей и пользы, которых еще нет в дадата, маркетинга, чтобы хоть кому-то продать сервис. А не чтобы одна фича в прод уехала. Вы на уровне проджекта смотрите "что нужно сделать, чтобы фича была полезной", а на уровне продакта это "что нужно сделать, чтобы продукт был коммерчески успешным", если прям грубо и приблизительно выразиться.
Ключевая проблема такого подхода (у него есть даже термин - фичерить) - это что в продукт вносится куча разных улучшений, отдельных, небольших, которые кушают бюджеты по частям, в итоге съедая очень много в сумме, но не общая стратегия, которая приводит проект к коммерции.
А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.
Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они - платформа, на которой ваши клиенты обитают.
jtbd в вашем случае - это набор функциональностей и пользы, которых еще нет в дадата, маркетинга, чтобы хоть кому-то продать сервис. А не чтобы одна фича в прод уехала. Вы на уровне проджекта смотрите "что нужно сделать, чтобы фича была полезной", а на уровне продакта это "что нужно сделать, чтобы продукт был коммерчески успешным", если прям грубо и приблизительно выразиться.
Ключевая проблема такого подхода (у него есть даже термин - фичерить) - это что в продукт вносится куча разных улучшений, отдельных, небольших, которые кушают бюджеты по частям, в итоге съедая очень много в сумме, но не общая стратегия, которая приводит проект к коммерции.
А начать стоит с вопроса - у вас хорошее предложение, чем по сравнению с конкурентами и для каких категорий клиента? (бесплатно? А в каком случае это плюс? Меньше функционала да проще? а в каком случае это плюс? и т.д. и т.п.). Рисуете категоризацию для клиентов, ставите as is to be в каждой категории, чтобы стать лучше, считаете ожидаемый профит и ожидаемые инвестиции выбираете, в каком случае вам будет выгодно и во что доработаться/вложиться в сегменты аудитории и как - получаете тот самый jtbd, чтобы дойти из текущей точки в точку безубыточности хотя бы - считаете, готовы ли и едете. А вы начали с конца - сперва сделали, теперь пытаетесь натянуть на коммерческую составляющую.
Что касается АМО и БИТРЫ - они уже интегрированы с чем угодно, дело говорят. Хотите упростить жизнь ВАШИМ пользователям - упрощайте, делайте бесплатный модуль простой интеграции, точки вызова и настройки, и вуаля, они-то тут причем. АМО и Битрикс - не ваш клиент, они -платформа
Но ты же при этом понимаешь, что ВЕРОЯТНОСТЬ, что человек окажется завтра на войне/взломан/убит/закрыт великим файрволом в подворотне ниже в условной Голландии, чем в РФ? А жизнь - это череда вероятностей, и работа по митигации рисков бизнеса - это ключевая задача СБ/ИБ. Рынок вне РФ чуть более конкурентен со стороны работодателя, и поэтому они могут выбирать. Это у себя на стуле ты хороший. А он видит 70 стульев, где все хорошие, и ему проще выбрать тот стул, который хорош со всех сторон)
слушай, мы с моей прошлой командой прям друзья. Вместе тусим, ходим по барам, ходим в гости друг к другу, играем на гиатрке, снова пьем, говорим о чем угодно и так далее. Вы почему-то ограничиваетесь работой как работой - делать таски и получать зп. Это тоже важно и нужно, но чьерт побьери, я могу делать таски и получать зп и все, а могу делать таски, получать зп и круто проводить время в компании друзей. Это никак не мешает мне делать свою работу. Никто не мешает мне шутить и смеяться, даже если полный треш вокруг. Потому что с грустным хлебалом я уже работал, больше не хочу. И поверь, если ты сам открыт к людям, то и люди к тебе открыты. Если ты понимаешь, что у условного Сани вечером др, ты никогда в жизни не запланируешь на него какой-то левый кранч. Если ты знаешь, что Юльке в 6 надо быть в садике, ты будешь планировать спринты и ее загрузку с учетом этого знания, а не "я чет там напланировал, а команда опять меня подвела".
И если у пацанов и чик проблемы на работе или вне ее - мы их реально перетрем, что на ретро, что в баре, так как мы бро, а бро слушает своего бро, ферштейн? И проблема решится, потому что если бро в соло не может, мы ему поможем на том или ином уровне. Я вот продакт, и мог прийти и попросить к линейным рукам бабок тому или иному сотруднику, потому что его уже заманало, а морально не умеет просить. А мне черт возьми не жалко, мне жалко, если я хорошего человека и сотрудника из команды потеряю. Если он будет ходить унылым и не хотеть делать свою работу (а че мы потом в баре обсудим?!) Если есть тела, которые не влились, то можно ж вместе их подкалывать?
Так что я тут с ТСом согласен от и до - нормально общаешься - быстрее летит. А когда сидишь в своей конуре в одного 24/7, то и пропускаешь как весь движ, так и всю помощь.
У меня было в управлении 2 команды - веб и мобилки, с частью общих сервисов, где как раз оценки фронтов были близки к правде, а оценки на сервисы сильно расходились с действительностью именно в мобильной команде.
Что сделали: мобилки согласовали некий шаблон оценки задач и рисков при ее решении, и мы договорлись, что задачи со средней степенью неопределенности и сложнее мы идем и оцениваем дольше, выделяя время в спринте только на оценку (с неким исследованием). Если задача в принципе неоцениваема, мы выделяли отдельной задачей поиск решения, согласовывали на это выделение времени, и после поиска задача сводилась из высокой неопределенности к средней или набору простых, и оценки бились. Оценки нужны для 2х вещей: чтобы спринт был наполнен, а не перегружен (то есть чтобы разработчик честно сказал, я не сделаю - и не сделал), а так же чтобы бизнесовому заказчику делать ограничения с 2х сторон на периоде (сделаем не раньше такого-то и не позже такого-то).
Итог довольно простой: в командах вопрос на ретро "почему ты не сделал, хотя мы же планировали" перестал подниматься в принципе, отношения стали гораздо лучше, а для бизнеса стало понятнее, что если они хотят что-то впихнуть, то придется чем-то жертвовать. Я продакт, то есть я представлял тот самый бизнес, но так как я же и проджект (ну не было отдельного, епрст), я же и понимал необходимость ограничений, прекрасно понимал своих парняг и девчин в команде, и как следствие, у нас доверие, чилл, отсутствие авралов по вине перепланирования, не было кранчей - мне спокойно, людям спокойно.
а если приходить сверху и как заказчик "а к среде сделаете? а почему?", не разбираться в процессах, не иметь понимания технологий и ограничений, не видеть ситуацию изнутри - то да, проблема оценок стоит остро, тогда "эти они виноватые, а я все сделал" и прочие радости эффективного менеджмента вылезают. Вы одно целое с командой, один продукт делаете, один хлеб едите, так и двигайтесь к общим интересам
Мы когда приходили с проблемой оценок в команду, мы тоже с вторым коллегой-продактом приходили не с ноги "вы все косяки", а с проблемой "у нас есть запрос озвучивать границы, мы уже и перезакладываемся, и че тока не делаем, но все равно случается попадос, и влетаем - ребяты, как можно сделать лучше".
и ретры не ради ретр, а ретры от лица любого члена команды с подобными вопросами имеют место быть, с совместным же решением, благодарностями, участием. Вот тогда щасье
боюсь, это неправда. Тендер - это тендер по условиям. То, что в результате тендера компания должна сделать согласно ТЗ/требований - это как отче наш. Но есть еще требования с коэффициентами, типа компания имеет аналогичные проекты такой же компетенции, сколько у компании сотрудников по профилю, что есть из сертификатов и так далее - в общем, это так же параметры честного тендера, не только цена. И итог - это кэф*цену, то есть приведенная цена контракта