Довольно часто я попадаю в ситуацию, когда мне нужно в моменте оценить длительность реализации бизнес-фичи. Обычно это какая-нибудь рядовая встреча, на которой инициатор бизнес-идеи, резво размахивая руками в воздухе, рассказывает о своем предложении. В конце своего выступления, в котором часто много слов (но не цифр) сказано о том, зачем это фича нужна и какой эффект она даст, всегда звучит сакральный вопрос: «Когда сделаете эту великолепную доработку?»
Я хотел бы поделиться с читателем ходом своих рассуждений, которые позволяют мне довольно точно оценивать сроки реализации даже в самых запущенных случаях.
Разумеется, я не смогу предусмотреть и учесть все нюансы и специфики, принятые в различных компаниях в процессе разработки и вывода новой функциональности в эксплуатацию. Однако я верю, что описанные ниже практики будут полезны и вы сможете их адаптировать под свою ситуацию.
Сразу упомяну, что речь идет в первую очередь о продуктовых компаниях, где нет жесткого учета рабочего времени и можно подумать о качестве и поддерживаемости новой функциональности. В случае заказной разработки всё обычно гораздо сложнее и требует более детальной проработки.
Процесс оценки
— Когда сделаете эту доработку?
Итак, вопрос прозвучал и наступил самый опасный момент встречи. Всё, что вы сейчас ответите, будет записано на диктофон, зафиксировано в анналах истории и начнет бесконтрольно распространяться из презентации в презентацию среди менеджмента.
Первое страшное преступление, которое вы можете совершить, это попытаться самостоятельно оценить доработку «в уме» и назвать итоговую дату.
Почему это плохо:
Никакие ограничительные факторы типа «при условии…», «если смежные команды…», «при наличии того-то и того-то…» услышаны не будут.
Вы наверняка дадите оценку с большей погрешностью, чем в случае более детального разбора фичи.
Вы не учтете кучу факторов и подводных камней.
Для вопрошающего ваша оценка будет звучать как магическая непонятная заповедь. И если он сам не понимает, откуда взялась оценка, то может возникнуть желание «почеленджить» её (будь проклят человек, придумавший этот термин).
У вас не будет фактуры, на основе которой вы делали оценку, а значит и способа доказать ее справедливость. Если к вам вернутся с желанием «почеленджить» через неделю, то вы можете и не вспомнить всех факторов, заставивших вас посчитать именно так, а не иначе.
Можно взять паузу и пообещать вернуться с проработанной оценкой через какое-то время. Это уже лучше, но тоже не очень хорошо, потому что:
При отложенной оценке вы что-то забудете из того, что вам говорили на встрече.
У вас не будет возможности уточнить подробности функциональности (или эти уточнения потребуют дополнительного общения).
Если вы привлечете к оценке кого-то третьего, то потратите и его, и свое время.
На мой взгляд, идеальный вариант — это открыть Макбук, запустить 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 — дата начала работ. Вот итоговое число, которое получилось у нас с инициатором. И он его понял, принял и отстаивал перед менеджментом яростнее меня. Вероятно, в ходе этого упражнения мы немного перезаложились… но и что-то не учли. Могу сказать, что на практике такая методика позволяет более-менее комфортно попадать в сроки.
Главное, помнить: лучше перезаложиться и сделать раньше, чем недозаложиться и сорвать дедлайн.
Комментарии (24)
ImLoaD
28.09.2021 12:11+2Отличная статья.
Помнится в книге Р. Мартина "Идеальный программист" автор открыл глаза на вероятностное распределение в оценке. Если считаешь что выполнишь за 3 дня, то это значит что наиболее вероятно 3 дня, чуть меньше вероятности что 4, и так далее. Наименьшая вероятность была на цифре 11.
Он предлагает вдохновится программой PERT от ВМС для проектирования подводных лодок в части вычисления оценок. При оценки задачи предоставляются три числа:
оптимистичная оценка
номинальная оценка
пессимистичная оценка
Так же приводятся формулы для суммирования этих оценок по группе задач и вычисления среднеквадратичного отклонения
Можно ли это как то применить при подходе, описанном Вами?
Turundur Автор
28.09.2021 12:26+5Я пытался так делать, но через некоторое время поймал себя на мысли, что я даю оценку и "придумываю" оптимистичную и пессимистичную вариацию этой оценки, минусуя и прибавляя определенный процент. То есть это не 3 оценки - а одна, с определенным люфтом.
Ну и такой подход сложнее объяснить инициатору
iiwabor
28.09.2021 16:57+5Мы рассчитанную цифру еще умножаем на коэфф. 3,14 - и, по итогам разработки, очень часто как раз столько и получается. Потому что еще есть очень много неучтенных факторов, которые невозможно учесть в начале пути. А если сделали быстрее - то молодцы!)
Turundur Автор
28.09.2021 22:10+3Такой подход может оставить бизнес инициатора с неоправданными ожиданиями — «Почему именно 3,14? Откуда такая цифра? Опыт? Так в этот раз будет все по другому!»
iiwabor
29.09.2021 09:47+1Довольно часто так бывает, что инициатор фичи, услышав озвученные сроки реализации и понимая, что за пять минут она не сделается (как он думал ранее), отказывается от нее, т.к. на самом деле она была не очень-то и нужна)
Turundur Автор
29.09.2021 13:52Мне кстати такой исход не очень нравится (хотя чисто по-пацански - норм, отстали и ладно). Это же по-сути означает, что "проблема" бизнеса не решена и от предложенного системного решения отказались в пользу каких-то других костылей. А костыли ломаются везде - и в IT и в бизнесе.
SergeyMax
28.09.2021 20:55+7Основная ошибка автора состоит в том, что он забыл все сроки умножить на два и прибавить две недели!
HellWalk
29.09.2021 09:08+1Вы недооцениваете хитрость ситуации. Ключевой момент здесь:
Инициатор вместе с вами участвует в процессе оценки. Это уже не только «ваша» оценка, но и его! И он ее будет гораздо ревностнее защищать перед другими коллегами.
Соответственно, даже хорошо, если сроки будут сорваны - инициатор тоже окажется виноватым, а следовательно, в следующий раз у него будет меньше желания просить оценить сроки на ходу, без ТЗ.
NeverIn
28.09.2021 22:03На 80% этих вопросов ответ есть у аналитика или овнера сразу, если они знают свой продукт. Ещё и заказчику помогут сформулировать задачу
ErnestMiller
28.09.2021 23:10+1Еще в универе мне препод говорил, что если хочешь оценить сроки разработки, то спроси у программиста за сколько он сделает описанный в ТЗ продукт. Затем названные сроки надо умножить на три, прибавить три дня и одну ночь. Тогда сроки будут максимально близки к реальности.
S-trace
29.09.2021 05:41У вас в пункте про козффициент мути что-то не сходится (по таблице КМ присваивается либо +0%, либо +5%, либо +10% (зачем указывать знак плюс при присвоении, если он плюс и так по умолчанию?), однако ниже пишете, что "КМ по умолчанию равен 10 %, и в зависимости от ответов на поставленные вами вопросы может так и остаться 10 %, либо вырасти до 70 %.").
Поправьте либо таблицу (чтобы был инкремент, типа КМ += 10%), либо вывод))
Turundur Автор
29.09.2021 07:14+1Кажется понял, что Вы имели в виду. Спасибо за обратную связь, поправил - надеюсь будет понятнее.
mkll
02.10.2021 09:41Там, где у вас в табличке КМ +10%, это на самом деле не проценты, а процентные пункты.
Было бы проще для понимания, как мне кажется, использовать для КМ не проценты, а просто число от 0 до 1 (или больше, если табличка разрастется). Даже само слово "коэффициент" на это намекает, ведь коэффициенты в процентах обычно не исчисляются.
HellWalk
29.09.2021 09:06+2Я хотел бы поделиться с читателем ходом своих рассуждений, которые позволяют мне довольно точно оценивать сроки реализации даже в самых запущенных случаях.
Это же невозможно, подумал я. Без ТЗ оценивать сроки не только невозможно, но и глупо!
Инициатор вместе с вами участвует в процессе оценки. Это уже не только «ваша» оценка, но и его! И он ее будет гораздо ревностнее защищать перед другими коллегами.
А, ну все понятно. На одну разводку (когда программиста просят оценить сроки без ТЗ - это именно разводка) вы делаете встречную. С точки зрения «бей врага его же оружием» неплохо :)
zhulan0v
29.09.2021 09:24+1У меня довольно часто работает правило - первая оценка которая всплывает в подсознании X 2.
weiser
29.09.2021 12:37+1Если в ходе работ требуется интеграция со смежным сервисом, то накидывайте 30 % календарного срока на длительность интеграционных работ
Это работает в случае готового сервиса, разработанного в той же организации и который будет использоваться "как есть".
Иногда бывает что надо интегрироваться с внешним сервисом, который ещё и допиливается под нужды твоего проекта - вот тут я бы говорил об условной оценке собственных трудозатрат (учитывая каналы связи с внешней командой, возможные рычаги управления и т.п.)
Да, формально мы можем просто взять оценку доработки от внешней команды и приплюсовать к нашей оценке для нашего проекта + добавить какой-то процент сверху "на издержки коммуникации". Однако любой внешний исполнитель привносит нехилый элемент рандома. Если есть цель предоставить более-менее объективную, а не формальную оценку - то на подобные вещи лучше указывать отдельно, подразумевая, что точную оценку именно данного аспекта (интеграции) в такой ситуации предоставить нереально.
Turundur Автор
29.09.2021 13:55В целом - да, Вы правы.
Беда в том, что все "отдельно выделенные" проблемные места тут же сотрутся в памяти инициатора. Там умещается только одна цифра.
Я бы предпочел накинуть в "гору" побольше времени на внешний сервис. А если это госорган (ПФР, ФНС, Минсельхоз и т.д.) - то гора должна быть размером с Эверест.
ReaderReader
29.09.2021 13:20Для вопрошающего ваша оценка будет звучать как магическая непонятная заповедь. И если он сам не понимает, откуда взялась оценка, то может возникнуть желание «почеленджить» её
Вот это — самое страшное. Причем аргументы для обоснования уменьшения сроков обычно берутся из серии «Товарищ Иванов! Вы же — коммунист! И пулемет застрочил снова.»Turundur Автор
29.09.2021 13:49Часто сталкиваюсь с такой ситуацией. Всегда есть важный внешний фактор, ограничивающий сроки на задачу - "KPI руководства", "изменения в законах", "конкуренты уже вышли на рынок с таким же продуктом" и прочее.
По сути - это способы о стороны инициатора повлиять на срок (хотя их особо то и нет), перекладывая последствия в виде поддержки говнокода на разработку. Это естественная реакция каждого человека - "надо же что-то делать, чтобы ситуацию улучшить". Я пытаюсь показать, как с помощью прозрачности направить вектор этого "надо же что-то делать" с прессинга разработки на управление ожиданиями топ менеджмента.
kirillk0
29.09.2021 13:40Меня беспокоит идея оценки на коленке. Аналитика, которая позволит как-то более-менее оценить время разработки -- это сама по себе работа, на которую должно быть выделено время.
Turundur Автор
29.09.2021 13:44+1Каждая оценка имеет некую точность (ну или "погрешность"). ПОдробный разбор задачи аналитиком позволяет снизить такую погрешность (но кстати не убрать ее, а именно снизить).
В тепличных условиях - конечно нужно отрисовать схемы процессов, макеты интерфейсов, отрисовать алгоритмы работы, спроектировать модель данных и т.д.
Беда в том, что периодически ситуация такова, что на оценку времени особо нет. По разным причинам (об этом можно отдельную статью написать), но нет.
В этом случае оценку можно сделать самому в условиях дефицита информации, взяв "в гору" и объяснив, почему так (как собственно я и предлагаю) - либо можно подставить аналитика, и попросить его сделать такую оценку, выделив минимум времени - тогда он по сути сделает то же самое, но ответственность вроде как будет на нем. Я за первый варик.
fedor7
Описано подробно и понятно. Впечатление такое, что такая оценка "на месте" займет не меньше часа. И это при условии, что основные детали реализации сразу ясны, что странно для идеи, которую только презентовали.
"Сумели бы сделать в одиночку", это не всегда подразумевает, что не требуется исследование. Адекватный план работ -- видится наиболее сложной частью оценки. А продуманные (или рожденные опытным путем) коэффициенты -- это здорово! Если это первая оценка, и после уточнения требований и деталей реализации, перед тем как задача попадет в спринт, -- будет вторая оценка, тогда совсем хорошо.
Это замечательно!