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

Многие даже опытные тимлиды и руководители не любят оценивать разработку проектов. Это бывает сложно сделать, да и допустить ошибки велика вероятность. Однако без оценки далеко не уедешь — это объективная необходимость. На её основе бизнес планирует бюджеты и маркетинговые кампании, решает, инвестировать в проект или нет.

В реальной жизни мало кто может позволить себе подход Джона Кармака, который, разрабатывая Doom 3, заявил: «Будет сделано, когда будет сделано».

Но есть и хорошая новость! Оценка проектов — это навык, и его можно прокачать. Об этом и поговорим!

Если кратко: во всём виноват наш любимый мозг. Мозг — это мощный аналитический орган, но и энергии он потребляет много. Поэтому старается максимально экономить энергию и для этого прибегает ко всяким трюкам.

Типичный трюк — это подмена сложного вопроса на более простой. При этом обычно человек сам не замечает эту подмену. Посмотрим на примере оценки проекта:

Разработчик поопытнее не забудет включить все процессы в оценку. Но что, если мы сделаем его главным ответственным этот проект? Получится примерно следующее:

Противоположная история возникает, когда с нами проводят всякие психологические манипуляции. Или если мы сами склонны к излишнему оптимизму:

Теперь давайте разбираться, как избежать этих и подобных ошибок.

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

Например:

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

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

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

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

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

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

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

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

Чтобы люди не влияли друг на друга, используйте слепые независимые оценки или planning poker.

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

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

Для начала задайте себе вопрос: «Что конкретно подразумевается под интеграцией с 1С?» или «Как мы реализуем каталог товаров?». Если вы не можете ответить сами, задавайте вопросы другим — заказчику, продукт-менеджеру, дизайнеру и т.д.

Все ваши предположения («мы будем использовать СУБД X», «товары будут нам приходить в виде XML-файла на FTP»), все ответы от заказчика и все риски («мы не знаем, какая будет нагрузка на сайт») должны быть записаны и открыты для всей команды проекта. Это обязательно пригодится позже — когда вы будете показывать оценку кому-то ещё или если в будущем изменятся требования к продукту или проекту.

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

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

☝ Важно: не тратьте на это много времени и не старайтесь максимально всё детализировать. Это может завести вас в ловушку уверенности — когда вы думаете, что всё будет именно так, как вы прописали.

Для каждой подзадачи полезно иметь чек-лист того, что вы включаете в оценку, а также что считаете завершённой задачей — так называемый Definition of Done. Например:

✓ функциональность реализована в соответствии с техзаданием;

✓ код прошел код-ревью;

✓ юнит-тесты написаны и выполняются;

✓ окружения Staging и Production настроены;

✓ код залит на Staging и Production с помощью CI/CD;

✓ регрессионные тесты написаны;

✓ регрессионное тестирование на Staging и Production пройдено;

✓ документация по продукту обновлена;

✓ продукт продемонстрирован заказчику.

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

Если вам нужно оценить то, что вы никогда не делали, например, хитрую интеграцию с незнакомым продуктом, проведите небольшое исследование. Например:

На одном из проектов мы разрабатывали интернет-магазин и должны были интегрироваться с системой управления складом. Прежде, чем оценить эту задачу, мы собрали прототип — программу, которая скачивала каталог товаров и меняла товарные остатки через API склада. Оказалось, что в системе много дубликатов товаров, и API не выдерживает необходимой нагрузки. В итоге подход к интеграции пришлось существенно пересмотреть. И, соответственно, оценить совершенно другой объём работ.

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

Скорректируйте оценку относительно предыдущих проектов. Мы обычно смотрим на следующие факторы:

В зависимости от масштаба проекта, выражайте его оценку в часах, днях, неделях или месяцах, чтобы показать правильный уровень точности. В ситуации, когда нужно дать оценку какому-то крупному блоку работ (разработка/дизайн) не стоит давать её в формате 256 часов. Удобнее для восприятия, честнее и правильнее будет сказать «разработка займет примерно 7 недель».

В реальности не существует идеально точных оценок. Да это и не нужно. Просто помните, что если задача занимает у вас больше 40 часов, скорее всего, её нужно уточнить и/или разбить на подзадачи.

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

И помните: оценка проектов — это навык, которому можно научиться. Главное только, чтобы был цикл обратной связи.