AndrewKozlov
New member
Привет, форумчане! Хочу поделиться своим опытом оценки сроков разработки — темой, которая однажды стоила мне трёх месяцев ночных дедлайнов и изрядной части нервных клеток. Лет пять назад я оценивал задачи по принципу «ну, дня три, наверное», и это работало ровно до того момента, пока проект не стал большим. Тогда я понял простую вещь: интуиция без метода — это лотерея, а лотерея в разработке заканчивается выгоранием команды и разговором с заказчиком, который больше не верит ни одному моему слову. С тех пор я собрал для себя набор из шести методов и хочу рассказать, как они меня вытащили.
Первый метод — декомпозиция плюс экспертные оценки. Я больше не оцениваю фичу целиком: сначала разбиваю её на задачи размером до одного дня работы, а потом собираю оценку от нескольких человек, а не от одного. Хорошо работает приём из метода Дельфи: каждый пишет свою оценку молча, дальше мы озвучиваем крайние значения, обсуждаем расхождения и голосуем заново. Как правило, после второго круга разброс сокращается почти вдвое, а самые фантастические цифры отпадают сами собой.
Второй метод — оценка по трём точкам. Для каждой задачи я определяю оптимистичный, реалистичный и пессимистичный срок, а итог беру как ожидаемое значение. Это спасает от главной ловушки, когда оптимистичный сценарий выдаётся за план. Третий метод — оценка по аналогам: я веду таблицу прошлых задач с фактическим временем и беру похожие случаи за основу. Звучит скучно, но исторические данные — самый честный источник правды о реальной скорости команды, а не о той, что нам хочется показывать.
Четвёртый метод — планирование покером и относительные единицы. Когда команда оценивает задачи не в часах, а в условных баллах, спорят не о цифрах, а о сравнении: эта задача больше вот той или меньше. Это снимает давление и выравнивает оценки между новичками и опытными разработчиками, у которых разные представления о «небольшой доработке». Пятый метод — вероятностный подход: когда есть список задач с оценками, я прогоняю простую симуляцию и смотрю не на одну дату, а на диапазон. Формулировка «с вероятностью восемьдесят процентов закончим к такому-то числу» заказчику нравится гораздо больше, чем уверенное «успеем к пятнице», потому что в ней есть место реальности.
Шестой метод — буферы и защита от выгорания. Раньше я считал буфер признаком слабости, теперь понимаю: он честнее любой героической даты. Я держу запас на непредвиденное примерно в двадцать процентов и отдельный список известных рисков, которые мы ещё не решили. И самое важное правило: если оценка забирает больше восьмидесяти процентов рабочей недели человека, это повод не «оптимизировать», а сокращать объём. Переработки не ускоряют проект, они лишь откладывают провал и приближают выгорание — я проверял это на себе дважды и оба раза зря.
Из практики: раз в две недели я сверяю план с фактом и честно записываю, где ошибся. Поначалу было неприятно смотреть на собственные промахи, но именно этот ритуал дал самый большой прирост точности. Ещё помогают две привычки — не оценивать задачи, когда я устал, и никогда не выдавать срок в день, когда заказчик давит. Спокойный разговор с данными на руках почти всегда работает лучше, чем обещание из вежливости, за которое потом приходится расплачиваться всей команде.
Что рекомендую читателям? Начните хотя бы с одного метода: мелко разбейте задачи и заведите таблицу фактического времени. Через месяц у вас появятся собственные коэффициенты, и оценки перестанут быть самообманом. Добавьте буфер, скажите о нём вслух заранее и не стесняйтесь пересматривать сроки, когда появляется новая информация — это признак зрелости, а не слабости. И держите в голове главную мысль: качественная оценка — это не попытка предсказать будущее, а способ сохранить ясную голову, здоровый сон и уважение к себе и коллегам.
А как оцениваете сроки вы? Расскажите, какой метод прижился в вашей команде и что помогло лично вам не сорвать дедлайн и не выгореть, — будет здорово собрать живую копилку рабочих приёмов вместе!
Первый метод — декомпозиция плюс экспертные оценки. Я больше не оцениваю фичу целиком: сначала разбиваю её на задачи размером до одного дня работы, а потом собираю оценку от нескольких человек, а не от одного. Хорошо работает приём из метода Дельфи: каждый пишет свою оценку молча, дальше мы озвучиваем крайние значения, обсуждаем расхождения и голосуем заново. Как правило, после второго круга разброс сокращается почти вдвое, а самые фантастические цифры отпадают сами собой.
Второй метод — оценка по трём точкам. Для каждой задачи я определяю оптимистичный, реалистичный и пессимистичный срок, а итог беру как ожидаемое значение. Это спасает от главной ловушки, когда оптимистичный сценарий выдаётся за план. Третий метод — оценка по аналогам: я веду таблицу прошлых задач с фактическим временем и беру похожие случаи за основу. Звучит скучно, но исторические данные — самый честный источник правды о реальной скорости команды, а не о той, что нам хочется показывать.
Четвёртый метод — планирование покером и относительные единицы. Когда команда оценивает задачи не в часах, а в условных баллах, спорят не о цифрах, а о сравнении: эта задача больше вот той или меньше. Это снимает давление и выравнивает оценки между новичками и опытными разработчиками, у которых разные представления о «небольшой доработке». Пятый метод — вероятностный подход: когда есть список задач с оценками, я прогоняю простую симуляцию и смотрю не на одну дату, а на диапазон. Формулировка «с вероятностью восемьдесят процентов закончим к такому-то числу» заказчику нравится гораздо больше, чем уверенное «успеем к пятнице», потому что в ней есть место реальности.
Шестой метод — буферы и защита от выгорания. Раньше я считал буфер признаком слабости, теперь понимаю: он честнее любой героической даты. Я держу запас на непредвиденное примерно в двадцать процентов и отдельный список известных рисков, которые мы ещё не решили. И самое важное правило: если оценка забирает больше восьмидесяти процентов рабочей недели человека, это повод не «оптимизировать», а сокращать объём. Переработки не ускоряют проект, они лишь откладывают провал и приближают выгорание — я проверял это на себе дважды и оба раза зря.
Из практики: раз в две недели я сверяю план с фактом и честно записываю, где ошибся. Поначалу было неприятно смотреть на собственные промахи, но именно этот ритуал дал самый большой прирост точности. Ещё помогают две привычки — не оценивать задачи, когда я устал, и никогда не выдавать срок в день, когда заказчик давит. Спокойный разговор с данными на руках почти всегда работает лучше, чем обещание из вежливости, за которое потом приходится расплачиваться всей команде.
Что рекомендую читателям? Начните хотя бы с одного метода: мелко разбейте задачи и заведите таблицу фактического времени. Через месяц у вас появятся собственные коэффициенты, и оценки перестанут быть самообманом. Добавьте буфер, скажите о нём вслух заранее и не стесняйтесь пересматривать сроки, когда появляется новая информация — это признак зрелости, а не слабости. И держите в голове главную мысль: качественная оценка — это не попытка предсказать будущее, а способ сохранить ясную голову, здоровый сон и уважение к себе и коллегам.
А как оцениваете сроки вы? Расскажите, какой метод прижился в вашей команде и что помогло лично вам не сорвать дедлайн и не выгореть, — будет здорово собрать живую копилку рабочих приёмов вместе!