Как стать автором
Обновить
133.77
Домклик
Место силы

Когда сделаете доработку?

Время на прочтение 8 мин
Количество просмотров 16K

Довольно часто я попадаю в ситуацию, когда мне нужно в моменте оценить длительность реализации бизнес-фичи. Обычно это какая-нибудь рядовая встреча, на которой инициатор бизнес-идеи, резво размахивая руками в воздухе, рассказывает о своем предложении. В конце своего выступления, в котором часто много слов (но не цифр) сказано о том, зачем это фича нужна и какой эффект она даст, всегда звучит сакральный вопрос: «Когда сделаете эту великолепную доработку?»

Я хотел бы поделиться с читателем ходом своих рассуждений, которые позволяют мне довольно точно оценивать сроки реализации даже в самых запущенных случаях.

Разумеется, я не смогу предусмотреть и учесть все нюансы и специфики, принятые в различных компаниях в процессе разработки и вывода новой функциональности в эксплуатацию. Однако я верю, что описанные ниже практики будут полезны и вы сможете их адаптировать под свою ситуацию.

Сразу упомяну, что речь идет в первую очередь о продуктовых компаниях, где нет жесткого учета рабочего времени и можно подумать о качестве и поддерживаемости новой функциональности. В случае заказной разработки всё обычно гораздо сложнее и требует более детальной проработки.

Процесс оценки

Когда сделаете эту доработку?

Итак, вопрос прозвучал и наступил самый опасный момент встречи. Всё, что вы сейчас ответите, будет записано на диктофон, зафиксировано в анналах истории и начнет бесконтрольно распространяться из презентации в презентацию среди менеджмента.

Первое страшное преступление, которое вы можете совершить, это попытаться самостоятельно оценить доработку «в уме» и назвать итоговую дату.

Почему это плохо:

  • Никакие ограничительные факторы типа «при условии…», «если смежные команды…», «при наличии того-то и того-то…» услышаны не будут.

  • Вы наверняка дадите оценку с большей погрешностью, чем в случае более детального разбора фичи.

  • Вы не учтете кучу факторов и подводных камней.

  • Для вопрошающего ваша оценка будет звучать как магическая непонятная заповедь. И если он сам не понимает, откуда взялась оценка, то может возникнуть желание «почеленджить» её (будь проклят человек, придумавший этот термин).

  • У вас не будет фактуры, на основе которой вы делали оценку, а значит и способа доказать ее справедливость. Если к вам вернутся с желанием «почеленджить» через неделю, то вы можете и не вспомнить всех факторов, заставивших вас посчитать именно так, а не иначе.

Можно взять паузу и пообещать вернуться с проработанной оценкой через какое-то время. Это уже лучше, но тоже не очень хорошо, потому что:

  • При отложенной оценке вы что-то забудете из того, что вам говорили на встрече.

  • У вас не будет возможности уточнить подробности функциональности (или эти уточнения потребуют дополнительного общения).

  • Если вы привлечете к оценке кого-то третьего, то потратите и его, и свое время.

На мой взгляд, идеальный вариант — это открыть Макбук, запустить Excel и оценить длительность доработки вместе с инициатором. Прямо на встрече. Этот вариант самый лучший, потому что:

  • Инициатор вместе с вами участвует в процессе оценки. Это уже не только «ваша» оценка, но и его! И он ее будет гораздо ревностнее защищать перед другими коллегами.

  • У вас будет возможность уточнить детали.

  • У вас останется понятная фактура с верхнеуровневой структурой работ.

  • Инициатор будет понимать логику оценки и не станет подвергать ее сомнению.

Выбор джедаев — оценка на месте. Здесь и сейчас.

Оценка трудозатрат

Для начала не спешите оценивать календарные сроки, начните с оценки трудозатрат.

Второе страшное преступление, которое вы можете совершить, это приступить к оценке, не уточнив следующий перечень вопросов:

#

Вопрос

Если ответ «да» или могут показать

Если ответ «нет/не знаю» или не могут показать

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 %

КМ = Коэффициент мути. По сути это величина погрешности «оптимистичной» оценки трудозатрат, которую вы традиционно даете в надежде, что «всё будет хорошо». КМ по умолчанию равен 10 %, и в зависимости от ответов на поставленные вами вопросы может так и остаться 10 %, либо вырасти до 85 %.

Далее расписываем структуру необходимых работ (тут предполагается, что вы обладаете достаточным IT-бекграундом и сумели бы сделать эту задачу в одиночку, при достаточном запасе времени). При этом старайтесь формулировать работы таким образом, чтобы инициатору (бизнес-менеджеру) они были максимально понятны.

Для примера я приведу структуру работ, которая у меня получилась при оценке следующей задачи:

«В рамках подготовки ипотечной сделки, в ходе телефонных переговоров менеджера Банка с клиентом, последнему предлагают приобрести несколько дополнительных услуг. При этом, иногда услуги навязывают, а иногда вообще не предлагают. Чтобы контролировать этот аспект, была разработана и уже готова нейросеть для транскрибации голосового трафика в текст и анализа текстовой стенограммы разговора. Но ее нужно обучить, и для этого необходимо разработать WEB интерфейс для разметки телефонных звонков с клиентом. Список звонков будет предоставлен в Excel файле и периодически будет обновляться.»

Речь идешь всего лишь о разработке интерфейса для разметки. Был подготовлен набросок желаемого интерфейса. Вот такой :)

Был понятен состав и ролевая модель разметчиков. Можно было рассчитать (что и сделал инициатор в моменте) максимальное и среднее количество одновременно работающих пользователей. Тираж — сразу на всех. Описания пользовательской истории нет. Схемы процесса нет. Какой-то сложной логики или алгоритмов не предполагалось (вычеркиваем).

КМ = 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

Получается чуть больше 19 человеко-дней.

Ниже я приведу макет, который был нарисован в рамках этой задачи:

Самое главное — эту оценку мы делали вместе с инициатором. И он понимал каждую строчку в смете (для чего она нужна и почему она требует именно столько трудозатрат). Это уже была «наша», а не «моя» оценка. И он даже полностью согласился с величиной КМ.

Оценка календарных сроков

Третье страшное преступление, которое вы можете совершить, это остановиться на оценке трудозатрат. Казалось бы, вы всё предусмотрели, учли и прямые, и косвенные затраты на разработку, но не тут-то было. Необходимо очень внимательно подойти к последнему этапу и обратить внимание на следующие моменты:

  • Не факт, что вы сразу сможете приступить к реализации фичи. Возможно, ее приоритет не определен, или вам сначала потребуется завершить текущий спринт.

  • Берите в расчет, кто будет делать задачу — один человек (Fullstack) или несколько (например, Backend-разработчик и Frontend-разработчик). Для фуллстека никаких изменений в сроках не предвидится, участие же Frontend- и Backend-разработчика увеличивает срок разработки примерно на 10 % из-за дополнительного взаимодействия.

  • Если к работам будет привлекаться джун, то увеличивайте срок его работ на 50 %. Если неизвестно, будет ли работать джун, не делайте этой корректировки. Если джун будет не один (в паре с мидлом или сеньором), то увеличивайте срок работ на 25 %.

  • За каждого дополнительного разработчика (больше одного) увеличивайте календарный срок на 5 % для издержек на то же взаимодействие.

  • Если к работам будут привлекаться Backend- и Frontend-разработчики, то работы обычно можно выполнять параллельно: считайте календарный срок по большей ветке. Иногда, конечно, у задач есть зависимости, но скорее всего, в моменте вы не сможете все их выявить и быстро посчитать.

  • Работы по обеспечению качества лучше не распараллеливать.

  • Примите во внимание процедуры вывода функциональности в эксплуатацию, принятые в вашей компании. У нас сама команда разработки может вылить функциональности в прод, но не во всех компаниях это так.

  • Попытайтесь учесть (если сможете) отпуска разработчиков. У меня в моменте это не получается.

  • Если в ходе работ требуется интеграция со смежным сервисом, то накидывайте 30 % календарного срока на длительность интеграционных работ.

В нашем случае работы будут выполняться тремя разработчиками: мидлами (один Front и два Back). Работы можно выполнять параллельно, поэтому для определения календарных сроков будем считать только Backend-ветку (без фронта). Имеем следующую картину:

Тип работ

Задача

Итого трудозатраты,

чел./д.

Коэффициент различных разрабов на фронт и бек (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

Итоговая календарная оценка получилась 10 дней, хотя мы и привлекли аж трех разработчиков. Часть ускорения была съедена штрафами на взаимодействие.

Послесловие

Задача будет готова через X + 2 недели и 1 день, где X — дата начала работ. Вот итоговое число, которое получилось у нас с инициатором. И он его понял, принял и отстаивал перед менеджментом яростнее меня. Вероятно, в ходе этого упражнения мы немного перезаложились… но и что-то не учли. Могу сказать, что на практике такая методика позволяет более-менее комфортно попадать в сроки.

Главное, помнить: лучше перезаложиться и сделать раньше, чем недозаложиться и сорвать дедлайн.

Теги:
Хабы:
+64
Комментарии 24
Комментарии Комментарии 24

Публикации

Информация

Сайт
domclick.ru
Дата регистрации
Дата основания
Численность
501–1 000 человек
Местоположение
Россия
Представитель
Евгения Макарова