Довольно часто я попадаю в ситуацию, когда мне нужно в моменте оценить длительность реализации бизнес-фичи. Обычно это какая-нибудь рядовая встреча, на которой инициатор бизнес-идеи, резво размахивая руками в воздухе, рассказывает о своем предложении. В конце своего выступления, в котором часто много слов (но не цифр) сказано о том, зачем это фича нужна и какой эффект она даст, всегда звучит сакральный вопрос: «Когда сделаете эту великолепную доработку?»
Я хотел бы поделиться с читателем ходом своих рассуждений, которые позволяют мне довольно точно оценивать сроки реализации даже в самых запущенных случаях.
Разумеется, я не смогу предусмотреть и учесть все нюансы и специфики, принятые в различных компаниях в процессе разработки и вывода новой функциональности в эксплуатацию. Однако я верю, что описанные ниже практики будут полезны и вы сможете их адаптировать под свою ситуацию.
Сразу упомяну, что речь идет в первую очередь о продуктовых компаниях, где нет жесткого учета рабочего времени и можно подумать о качестве и поддерживаемости новой функциональности. В случае заказной разработки всё обычно гораздо сложнее и требует более детальной проработки.
Итак, вопрос прозвучал и наступил самый опасный момент встречи. Всё, что вы сейчас ответите, будет записано на диктофон, зафиксировано в анналах истории и начнет бесконтрольно распространяться из презентации в презентацию среди менеджмента.
Первое страшное преступление, которое вы можете совершить, это попытаться самостоятельно оценить доработку «в уме» и назвать итоговую дату.
Почему это плохо:
Второе страшное преступление, которое вы можете совершить, это приступить к оценке, не уточнив следующий перечень вопросов:
КМ = Коэффициент мути. По сути это величина погрешности «оптимистичной» оценки трудозатрат, которую вы традиционно даете в надежде, что «всё будет хорошо». КМ по умолчанию равен 10 %, и в зависимости от ответов на поставленные вами вопросы может так и остаться 10 %, либо вырасти до 70 %.
Далее расписываем структуру необходимых работ (тут предполагается, что вы обладаете достаточным IT-бекграундом и сумели бы сделать эту задачу в одиночку, при достаточном запасе времени). При этом старайтесь формулировать работы таким образом, чтобы инициатору (бизнес-менеджеру) они были максимально понятны.
Для примера я приведу структуру работ, которая у меня получилась при оценке следующей задачи:
Был понятен состав и ролевая модель разметчиков. Можно было рассчитать (что и сделал инициатор в моменте) максимальное и среднее количество одновременно работающих пользователей. Тираж — сразу на всех. Описания пользовательской истории нет. Схемы процесса нет. Какой-то сложной логики или алгоритмов не предполагалось (вычеркиваем).
КМ = 10 % (по умолчанию) + 5 %(нет пользовательских историй) + 10 % (нет схемы процесса) = 25 %.
Получилась такая вот смета:
Теперь, когда прямые трудозатраты более-менее понятны, попробуем дополнить их обязательными работами для обеспечения качества и поддерживаемости функциональности (тестирование, документирование, обучение):
Получается чуть больше 19 человеко-дней.
Ниже я приведу макет, который был нарисован в рамках этой задачи:
Самое главное — эту оценку мы делали вместе с инициатором. И он понимал каждую строчку в смете (для чего она нужна и почему она требует именно столько трудозатрат). Это уже была «наша», а не «моя» оценка. И он даже полностью согласился с величиной КМ.
Итоговая календарная оценка получилась 10 дней, хотя мы и привлекли аж трех разработчиков. Часть ускорения была съедена штрафами на взаимодействие.
Главное, помнить: лучше перезаложиться и сделать раньше, чем недозаложиться и сорвать дедлайн.
habr.com
Я хотел бы поделиться с читателем ходом своих рассуждений, которые позволяют мне довольно точно оценивать сроки реализации даже в самых запущенных случаях.
Разумеется, я не смогу предусмотреть и учесть все нюансы и специфики, принятые в различных компаниях в процессе разработки и вывода новой функциональности в эксплуатацию. Однако я верю, что описанные ниже практики будут полезны и вы сможете их адаптировать под свою ситуацию.
Сразу упомяну, что речь идет в первую очередь о продуктовых компаниях, где нет жесткого учета рабочего времени и можно подумать о качестве и поддерживаемости новой функциональности. В случае заказной разработки всё обычно гораздо сложнее и требует более детальной проработки.
Процесс оценки
— Когда сделаете эту доработку?Итак, вопрос прозвучал и наступил самый опасный момент встречи. Всё, что вы сейчас ответите, будет записано на диктофон, зафиксировано в анналах истории и начнет бесконтрольно распространяться из презентации в презентацию среди менеджмента.
Первое страшное преступление, которое вы можете совершить, это попытаться самостоятельно оценить доработку «в уме» и назвать итоговую дату.
Почему это плохо:
- Никакие ограничительные факторы типа «при условии…», «если смежные команды…», «при наличии того-то и того-то…» услышаны не будут.
- Вы наверняка дадите оценку с большей погрешностью, чем в случае более детального разбора фичи.
- Вы не учтете кучу факторов и подводных камней.
- Для вопрошающего ваша оценка будет звучать как магическая непонятная заповедь. И если он сам не понимает, откуда взялась оценка, то может возникнуть желание «почеленджить» её (будь проклят человек, придумавший этот термин).
- У вас не будет фактуры, на основе которой вы делали оценку, а значит и способа доказать ее справедливость. Если к вам вернутся с желанием «почеленджить» через неделю, то вы можете и не вспомнить всех факторов, заставивших вас посчитать именно так, а не иначе.
- При отложенной оценке вы что-то забудете из того, что вам говорили на встрече.
- У вас не будет возможности уточнить подробности функциональности (или эти уточнения потребуют дополнительного общения).
- Если вы привлечете к оценке кого-то третьего, то потратите и его, и свое время.
- Инициатор вместе с вами участвует в процессе оценки. Это уже не только «ваша» оценка, но и его! И он ее будет гораздо ревностнее защищать перед другими коллегами.
- У вас будет возможность уточнить детали.
- У вас останется понятная фактура с верхнеуровневой структурой работ.
- Инициатор будет понимать логику оценки и не станет подвергать ее сомнению.
Оценка трудозатрат
Для начала не спешите оценивать календарные сроки, начните с оценки трудозатрат.Второе страшное преступление, которое вы можете совершить, это приступить к оценке, не уточнив следующий перечень вопросов:
# | Вопрос | Если ответ «да» или могут показать | Если ответ «нет/не знаю» или не могут показать |
| 1 | Есть ли описание пользовательской истории (как должна работать фича с точки зрения пользователя)? | КМ =+0 % | КМ =+5 % |
| 2 | Есть ли описание процесса в виде блок-схемы? | КМ =+0 % | КМ =+10 % |
| 3 | Есть ли макеты/скетчи пользовательского интерфейса (для фичи с пользовательским интерфейсом)? | КМ =+0 % | КМ =+10 % |
| 4 | Есть ли понимание ролевой модели (каким пользователям эта фича будет доступна и при каких условиях)? | КМ =+0 % | КМ =+10 % |
| 5 | Можно ли назвать среднее и максимальное количество одновременно работающих пользователей? | КМ =+0 % | КМ =+10 % |
| 6 | Готовы ли API смежных систем (если требуется интеграция с другими системами)? | КМ =+0 % | КМ =+10 % |
| 7 | Есть ли модель тиража новой функциональности (сразу всем, либо какой-то план раскатки)? | КМ =+0 % | КМ =+10 % |
| 8 | Есть ли описание (блок-схема) какой-то сложной логики или алгоритмов (если такие есть)? | КМ =+0 % | КМ =+10 % |
Далее расписываем структуру необходимых работ (тут предполагается, что вы обладаете достаточным IT-бекграундом и сумели бы сделать эту задачу в одиночку, при достаточном запасе времени). При этом старайтесь формулировать работы таким образом, чтобы инициатору (бизнес-менеджеру) они были максимально понятны.
Для примера я приведу структуру работ, которая у меня получилась при оценке следующей задачи:
Речь идешь всего лишь о разработке интерфейса для разметки. Был подготовлен набросок желаемого интерфейса. Вот такой
Был понятен состав и ролевая модель разметчиков. Можно было рассчитать (что и сделал инициатор в моменте) максимальное и среднее количество одновременно работающих пользователей. Тираж — сразу на всех. Описания пользовательской истории нет. Схемы процесса нет. Какой-то сложной логики или алгоритмов не предполагалось (вычеркиваем).
КМ = 10 % (по умолчанию) + 5 %(нет пользовательских историй) + 10 % (нет схемы процесса) = 25 %.
Получилась такая вот смета:
Тип затрат | Задача | Backend, чел./д. | FrontEnd, чел./д. | Прочие работы, чел./д. | Итого, чел./д. |
| Проектирование | Проектирование архитектуры. | 0 | 0 | 1 | 1,0 |
| Разработка дизайн-макетов. | 0 | 0 | 1 | 1,0 | |
| Разработка | Создание модели данных в БД для хранения результатов разметки. | 0,5 | 0 | 0 | 0,5 |
| Создание новой задачи в CRM-системе для разметки звонка. | 1 | 0 | 0 | 1,0 | |
| Создание новой роли для обеспечения доступа к задаче на разметку звонка. | 1 | 0 | 0 | 1,0 | |
| Экранная форма разметки звонка (верстка). | 0 | 2 | 0 | 2,0 | |
| API получения файла с записью разговора. | 0,5 | 0 | 0 | 0,5 | |
| API получения списка услуг для проверки в рамках прослушки звонка. | 0,5 | 0 | 0 | 0,5 | |
| API фиксации времени начала и окончания продажи услуги в рамках звонка. | 0,5 | 0 | 0 | 0,5 | |
| Механизм создания задач в CRM-системе на основе Excel-файла установленного формата. | 1,5 | 0 | 0 | 1,5 | |
| Code Review (10 % от разработки). | 0 | 0 | 1 | 1,0 | |
| КМ (25 % от разработки). | 2,4 |
Тип затрат | Задача | Backend, чел./д. | FrontEnd, чел./д. | Прочие работы, чел./д. | Итого, чел./д. |
| Проектирование | Проектирование архитектуры. | 0 | 0 | 1 | 1,0 |
| Разработка дизайн макетов. | 0 | 0 | 1 | 1,0 | |
| Разработка | Создание модели данных в БД для хранения результатов разметки. | 0,5 | 0 | 0 | 0,5 |
| Создание новой задачи в CRM-системе для разметки звонка. | 1 | 0 | 0 | 1,0 | |
| Создание новой роли для обеспечения доступа к задаче на разметку звонка. | 1 | 0 | 0 | 1,0 | |
| Экранная форма разметки звонка (верстка). | 0 | 2 | 0 | 2,0 | |
| API получения файла с записью разговора. | 0,5 | 0 | 0 | 0,5 | |
| API получения списка услуг для проверки в рамках прослушки звонка. | 0,5 | 0 | 0 | 0,5 | |
| API фиксации времени начала и окончания продажи услуги в рамках звонка. | 0,5 | 0 | 0 | 0,5 | |
| Механизм создания задач в CRM-системе на основе Excel-файла установленного формата. | 1,5 | 0 | 0 | 1,5 | |
| Code Review (10 % от разработки). | 1 | 0 | 0 | 1,0 | |
| КМ (25 % от разработки). | 2,4 | 2,4 | |||
| QA | Интеграционное тестирование (15% от разработки). | 1,92375 | 1,92375 | ||
| Написание автотестов для новой функциональности (15 % от разработки). | 1,92375 | 1,92375 | |||
| Подготовка к сопровождению | Документирование функциональности (Swagger+ Confluence). | 0,5 | 0,5 | ||
| Нагрузочное тестирование. | 1 | 1 | |||
| Penetration test. | 0,5 | 0,5 | |||
| Инструкции/обучение HelpDesk. | 0,5 | 0,5 | |||
| ИТОГО: | 6,5 | 2 | 10,7 | 19,2 |
Ниже я приведу макет, который был нарисован в рамках этой задачи:
Самое главное — эту оценку мы делали вместе с инициатором. И он понимал каждую строчку в смете (для чего она нужна и почему она требует именно столько трудозатрат). Это уже была «наша», а не «моя» оценка. И он даже полностью согласился с величиной КМ.
Оценка календарных сроков
Третье страшное преступление, которое вы можете совершить, это остановиться на оценке трудозатрат. Казалось бы, вы всё предусмотрели, учли и прямые, и косвенные затраты на разработку, но не тут-то было. Необходимо очень внимательно подойти к последнему этапу и обратить внимание на следующие моменты:- Не факт, что вы сразу сможете приступить к реализации фичи. Возможно, ее приоритет не определен, или вам сначала потребуется завершить текущий спринт.
- Берите в расчет, кто будет делать задачу — один человек (Fullstack) или несколько (например, Backend-разработчик и Frontend-разработчик). Для фуллстека никаких изменений в сроках не предвидится, участие же Frontend- и Backend-разработчика увеличивает срок разработки примерно на 10 % из-за дополнительного взаимодействия.
- Если к работам будет привлекаться джун, то увеличивайте срок его работ на 50 %. Если неизвестно, будет ли работать джун, не делайте этой корректировки. Если джун будет не один (в паре с мидлом или сеньором), то увеличивайте срок работ на 25 %.
- За каждого дополнительного разработчика (больше одного) увеличивайте календарный срок на 5 % для издержек на то же взаимодействие.
- Если к работам будут привлекаться Backend- и Frontend-разработчики, то работы обычно можно выполнять параллельно: считайте календарный срок по большей ветке. Иногда, конечно, у задач есть зависимости, но скорее всего, в моменте вы не сможете все их выявить и быстро посчитать.
- Работы по обеспечению качества лучше не распараллеливать.
- Примите во внимание процедуры вывода функциональности в эксплуатацию, принятые в вашей компании. У нас сама команда разработки может вылить функциональности в прод, но не во всех компаниях это так.
- Попытайтесь учесть (если сможете) отпуска разработчиков. У меня в моменте это не получается.
- Если в ходе работ требуется интеграция со смежным сервисом, то накидывайте 30 % календарного срока на длительность интеграционных работ.
Тип работ | Задача | Итого трудозатраты, чел./д. | Коэффициент различных разрабов на фронт и бек (10 %) | Коэффициент джуна (50 %) | Коэффициент на многочисленность разрабов (5 %) | Коэффициент интеграции со смежными сервсами (30%) | # исполнителей | ИТОГО, календарных дней |
| Проектирование | Проектирование архитектуры. | 1,0 | 0 % | 0 % | 0 % | 0% | 1 | 1 |
| Разработка дизайн макетов. | 1,0 | 0 % | 0 % | 0 % | 0% | 1 | 1 | |
| Разработка | Создание модели данных в БД для хранения результатов разметки. | 0,5 | 10 % | 0 % | 5 % | 0% | 2 | 0,2875 |
| Создание новой задачи в CRM-системе для разметки звонка. | 1,0 | 10 % | 0 % | 5 % | 0% | 2 | 0,575 | |
| Создание новой роли для обеспечения доступа к задаче на разметку звонка. | 1,0 | 10 % | 0 % | 5 % | 0% | 2 | 0,575 | |
| Экранная форма разметки звонка (верстка). | 2,0 | 0 % | 0 % | 0 % | 0% | 1 | 0 | |
| API получения файла с сзаписью разговора. | 0,5 | 0 % | 0 % | 0 % | 0% | 2 | 0,25 | |
| API получения списка услуг для проверки в рамках прослушки звонка. | 0,5 | 10 % | 0 % | 5 % | 0% | 2 | 0,2875 | |
| API фиксации времени начала и окончания продажи услуги в рамках звонка. | 0,5 | 10 % | 0 % | 5 % | 0% | 2 | 0,2875 | |
| Механизм создания задач в CRM-системе на основе Excel-файла установленного формата/ | 1,5 | 10 % | 0 % | 5 % | 0% | 2 | 0,8625 | |
| Code Review (10 % от разработки). | 1,0 | 10 % | 0 % | 5 % | 0% | 2 | 0,54625 | |
| КМ (25 % от разработки). | 2,4 | 10 % | 0 % | 5 % | 0% | 2 | 1,365625 | |
| QA | Интеграционное тестирование (15 % от разработки). | 1,92375 | 10 % | 0 % | 5 % | 0% | 2 | 1,106156 |
| Написание автотестов для новой функциональности (15 % от разработки). | 1,92375 | 10 % | 0 % | 5 % | 0% | 2 | 1,106156 | |
| Подготовка к сопровождению | Документирование функциональности (Swagger+ Confluence). | 0,5 | 10 % | 0 % | 5 % | 0% | 2 | 0,2875 |
| Нагрузочное тестирование. | 1 | 10 % | 0 % | 5 % | 0% | 2 | 0,575 | |
| Penetration test. | 0,5 | 10 % | 0 % | 5 % | 0% | 2 | 0,2875 | |
| Инструкции/jбучение HelpDesk. | 0,5 | 10 % | 0 % | 5 % | 0% | 2 | 0,2875 | |
| ИТОГО | 19,2 | 10,7 |
Послесловие
Задача будет готова через X + 2 недели и 1 день, где X — дата начала работ. Вот итоговое число, которое получилось у нас с инициатором. И он его понял, принял и отстаивал перед менеджментом яростнее меня. Вероятно, в ходе этого упражнения мы немного перезаложились… но и что-то не учли. Могу сказать, что на практике такая методика позволяет более-менее комфортно попадать в сроки.Главное, помнить: лучше перезаложиться и сделать раньше, чем недозаложиться и сорвать дедлайн.
Когда сделаете доработку?
Довольно часто я попадаю в ситуацию, когда мне нужно в моменте оценить длительность реализации бизнес-фичи. Обычно это какая-нибудь рядовая встреча, на которой инициатор бизнес-идеи, резво размахивая...
habr.com