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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

КМ = 10 % (по умолчанию) + 5 %(нет пользовательских историй) + 10 % (нет схемы процесса) = 25 %.

Получилась такая вот смета:

Теперь, когда прямые трудозатраты более-менее понятны, попробуем дополнить их обязательными работами для обеспечения качества и поддерживаемости функциональности (тестирование, документирование, обучение):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Послесловие

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

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