Многие даже опытные тимлиды и руководители не любят оценивать разработку проектов. Часто это довольно сложная задача, в которой легко допустить ошибку. Но вместе с тем, оценка проектов — это объективная необходимость. На её основе бизнес планирует бюджеты и маркетинговые кампании, решает, инвестировать в проект или нет. В реальной жизни мало кто может позволить себе подход Джона Кармака, который, разрабатывая Doom 3, заявил: «Будет сделано, когда будет сделано».

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

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

Почему мы часто ошибаемся в оценке

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

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

❓ Вопрос: «Сколько займёт этот проект?»

🧠 Мозг начинающего разработчика: «Сколько мне надо времени, чтобы это закодить?»

☝ Ошибка: кроме программирования, вероятно, ещё надо разбираться с требованиями, тестировать, вести коммуникацию и прочее.

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

❓ Вопрос: «Ты будешь разрабатывать этот проект. Сколько займёт по времени?»

🧠 Мозг разработчика: «Ой, во сколько времени я ТОЧНО уложусь и не облажаюсь? Заложу-ка побольше…»

☝ Ошибка: желание перестраховаться и полностью исключить риски заставляет давать сильно завышенные оценки.

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

❓ Вопрос: «Наш проект опаздывает, а ты наш самый лучший разработчик. Можешь нас выручить? Скажи, сколько тебе надо времени, чтобы закончить проект?»

🧠 Мозг разработчика: «Да, я красавчик. Интересно, как максимально быстро я могу это запилить? Ща покажем этим джунам, как надо работать…»

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

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

Правило 1: поймите, для чего нужна оценка

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

Например:

• Оценка превратится в смету для внешнего заказчика. Если мы её превысим, наша компания потеряет деньги.
• На основе оценки будет строиться план проекта либо вычисляться какой-то ключевой дедлайн.
• Это примерная оценка. Её затем будут  использовать, чтобы разбить проект на крупные фазы.
• На основе оценки будут примерно приоритизироваться фичи или просчитываться ROI (return on investment) для фич.

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

Правило 2: возьмите время «на подумать»

Правильный ответ на вопрос «Сколько это займёт времени?» всегда будет «Я подумаю и отвечу тебе тогда-то». Даже небольшую оценку не стоит давать сразу, когда вам вдруг позвонил менеджер проекта с такой просьбой. Вы будете более точными, если не будете торопиться.

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

Правило 3: задавайте правильный вопрос

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

Сколько времени обычно требуется нашей команде, чтобы сделать подобный проект?

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

Правило 4: соберите команду оценки

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

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

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

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

Правило 5: сделайте блиц-оценку

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

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

Правило 6: задавайте вопросы и документируйте предположения

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

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

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

Правило 7: разбейте проект на понятные части

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

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

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

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

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

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

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

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

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

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

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

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

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

Правило 8: используйте диапазон для оценки

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

• Low (50% вероятность). Бытовой смысл: «Я обычно доезжаю до работы за 15 минут».
• High (90% вероятность). Бытовой смысл: «Мне нужно на важную встречу к 9, поэтому я выйду за 40 минут, чтобы точно не опоздать».

Правило 9: исследуйте сложные части до оценки

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

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

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

Правило 10: сравните свои оценки с историческими данными

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

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

• Объём работ: то же самое, что на проекте Х, только есть ещё сложный раздел с возвратами товаров. Добавим +20%.
• Возможность переиспользования кода: здесь есть готовая библиотека UI компонентов, не придётся её создавать с нуля. Сэкономим процентов 15%.
• Сложность предметной области: здесь нужна локализация и различные правила документооборота для пяти стран, а прошлый проект был только для одной страны. Добавим +30% к оценке. 
• Команда: на прошлом проекте были одни сеньоры, а здесь половина мидлов-новичков. Добавим +15% на адаптацию команды.
• Технологический стек: возьмём проверенный простой фреймворк React вместо замороченного новомодного Remix. Будет быстрее на 20%.

Правило 11: используйте удобные единицы времени

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

Оценивая фичи, ограничьте себя фиксированных набором значений — 1, 2, 4, 8, 16, 32 часа. Это поможет избежать planning paralysis (паралича планировщика), когда вы будете долго думать, сколько же займёт задача — 14 или 18 часов? 6 или 6.5 часов?

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

Правило 12: анализируйте, что получилось в итоге

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

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

Фото в заголовке:  Jakub Dziubak on Unsplash

Фото и иллюстрации в статье: Brilevsky, Hkniberg at English Wikipedia,  

Автор статьи: Андрей Степанов

Редактура: Марина Медведева