Как оценить часы на разработку

Вероятнее всего, кто-то уже набил на этом руку, ну а для кого-то вопрос оценки продолжает оставаться pain in the ass. Процесс оценки — коллективный. Помимо того, что оценка включает не только разработку, еще и сама первичная оценка, полученная от разработчика, часто претерпевает изменения перед отправкой клиенту. Один мой знакомый товарищ даже искренне верил, что менеджмент набрасывает часы «чтобы сбить бабла с клиента». (Спойлер: он был неправ)

Как и специалисты в других областях, мы даём клиенту или собственному менеджменту ориентир в часах, сумме или поинтах на выполнение задачи.

— How much would it take to create a WP website?
— 400-500 hours

— I need to fix this bug immediately!!!
— That would be 500USD

— Can we include this story?
— Yes, it’s 5 pts.

— When will you push update to the staging server?
— By the end of the week!

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

Осмелюсь предположить, что процентов 90 хотя бы один раз не попадали в собственную оценку, причем в сторону превышения. У кого-то сама задача эстимейта вызывает неприятные ощущения вплоть до гнева: «Да там же ничего не понятно, как я могу это оценить? Пусть точнее скажут, что хотят». Очень много хронических оптимистов: «Да что там делать? Неделя и готово». Пессимизм приходит с опытом и далеко не ко всем, самые страшные оптимисты как раз сеньоры, притом самые талантливые.

Кроме того, учитывая абстрактный характер работы и перфекционизм, присущий многим, программирование стремится занять всё отведенное на него время: всегда можно бесконечно что-то улучшать, рефакторить, переделывать. Вы оценили работу в «две недели», базово сделали за три дня, оставшееся время ушло на улучшения, в итоге заняло две недели.

Также любая оценка — субъективна. Она зависит от опыта, от уровня владения технологией, от того, в каких проектах девелопер участвовал.

Из последствий непопадания в оценку:

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

Давайте рассмотрим, какими методами можно бороться с проблемой некорректной оценки.

I Классические приёмы

1) Poker estimate
Собирается группа девелоперов, озвучивается задача, все эстимейтят втихаря, потом сравнивают. Авторы самого большого и самого маленького значений обосновывают свою оценку. В конце нужно прийти к общему мнению.

2) Сравниваем с похожими уже сделанными задачами
Причем не с тем, что оценивали, а тем, сколько получилось фактически.:) Есть еще complexity factor, если делали что-то похожее, но легче/проще. На фактор умножаем.

3) Bottom up & top down
Первое — берем (или делаем) декомпозицию задачи и оцениваем каждую подзадачу, потом суммируем. Второе — пытаемся оценить задачу целиком. Если между двумя значениями большая разница, пытаемся понять, откуда эта разница.

4) Сторонняя экспертиза
Приглашаем Василия из соседнего отдела, просим прикинуть и сравниваем со своей оценкой.

II Лепта менеджмента

5) Риски
15-20% накидываются сверху на риски. Обычно, самые сложные или самые непонятные части системы и будут самыми рискованными, поэтому, если уже есть декомпозиция, можно накинуть только на эти части. Обычно риск постфактум звучит как «в процессе разработки выяснилось, что придется переделать структуру БД».

6) Не весь ресурс
Считаем, что есть только 80% ресурса. Т.е. у Василия в рабочей неделе 32 часа, а не 40. Но эти 80% применяем не к самому эстимейту, а к планированию дат. Т.е. оценку вы даёте в 40 часов, но готово будет через 6 рабочих дней. Подстраховка от больничных и прочих неожиданных моментов.

7) Out of scope
Требования имеют свойство обновляться и добавляться, это нормально. Ненормально считать, что первоначальный эстимейт их покроет. Проапдейтились требования? Ок, that’s great, here’s the updated estimation which includes this new feature.

8) Статистика
Авторы в Managing the Unmanageable ссылаются на то, что девелоперы, в среднем, кодят 55% от своего времени. Остальное уходит на коммуникацию с менеджментом, коллегами, тестировщиками, дизайнерами, клиентом; на code review и менторинг и на переключение между задачами. А в проекте, в целом, 1/6 времени уходит на первичное написание кода, а 1/2 на тестирование и багфиксинг.

III Выведено из практики

9) Честно вовремя признаться
Это нормально, что в процессе работы первоначальная оценка будет уточняться. Чем больше вам подробностей известно, тем точнее вы знаете, сколько времени понадобится. И чем раньше выясняется, что поменялся предполагаемый объем работ, тем лучше. Можно обсудить с клиентом, как урезать скоуп, поменять ожидаемую дату или добавить еще разработчика. В идеале, неуспевание на ранней стадии должен заметить PM, но на практике нужен еще и инпут от программиста. Особенно актуально, если процесс в компании прихрамывает или у лида/проджекта нет времени каждый день узнавать, как дела. На моей практике, самое безобидное «сейчас заканчиваю» длилось с восьми вечера до трех ночи. Может на неделю растягиваться, каждый день в стадии «сейчас, разворачиваю». Если станет известно на ранней стадии, очень много шансов выйти сухим из воды.

10) Индивидуальная скорость работы
Довольно редко проектом занимается только тот человек, который его оценивал. Были случаи, когда оценку давал один девелопер, а проект делал другой. Поэтому обычная практика — оценивать по средней мидловой скорости.

11) Погружение
Не стоит забывать, что для ознакомления с задачей требуется время. До того, как вы начнете непосредственно кодить архитектуру, может уйти день-два на «подумать».

12) Коммуникация
Включайте в эстимейт время на общение с коллегами. Вспоминайте, сколько раз приходится что-то спрашивать и уточнять и сколько раз самому отвечать на вопросы. Запросто, что час в день.

13) Разрыв между значениями
Во-первых, дается два или даже три варианта оценки. Два — это от N и до M, три — оптимистический, реалистический и пессимистический. Во-вторых, не стоит делать разницу между нижней и верхней границами больше, чем 20%. Эстимейт 200-1000 часов испугает всех. Такой большой разрыв допустим, если всё очень плохо с требованиями или поведение какой-то сторонней библиотеки или сервиса непредсказуемо.

14) Ничего не забыли? Для клиента может быть очевидно, что включено:

• аналитика,
• тестирование,
• менеджмент,
• дизайн,
• code review,
• юнит тесты,
• документация,
• мануалы,
• автоматизация,
• саппорт IE6,

поэтому явно пишите, что эстимейт включает, а что — нет.

IV Пример

Оцениваем сайт на WP, где будет лежать несложный контент, а у юзеров будут свои аккаунты. Платежей нет, особых фич для залогиненных товарищей тоже нет. Нужно подготовить rough quote для клиента.

• Обращаемся к профильному лиду, экспертное мнение 200-300 часов.
• Добавляем 15% на риски: 230-345 часов.
• Понимаем, что один лид проектом заниматься не будет, а у других ребят скорость отличается. Пусть на 1/4, получаем 288-431.
• Плюс коммуникация, 20-30 часов: 308-461.
• Делим на 6.4 часа в день и получаем 2-3 месяца разработки.

Итого, всегда делайте эстимейт хотя бы двумя способами, всегда сообщайте, если что-то непонятно или есть опасность изменения сроков, не забывайте про риски и помните, что учитываются не только те полчаса, за которые вы решили проблему, а и те полтора часа, которые вы ходили раздумывали, гуглили или советовались с коллегой.