Оценка IT-проектов: всё, что вы хотели знать, но боялись спросить

Принято считать, что оценивать проект целиком (например, с нуля до этапа запуска в продакшн) имеет смысл только при работе в рамках методологии waterfall, при работе же с гибкими методологиями чаще всего каким-то образом оценивается только та часть работ, которая берется в спринт.

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

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

Часто в головах у руководителей ФОТ на автомате учитывается в регулярные траты и не переносится в стоимость развития IT-систем. Но если внутренняя команда реализует большой проект, то она за это время получает ЗП и не реализует что-то другое, поэтому важно до старта работ понимать будет ли польза от проекта больше, чем расходы на ФОТ команды и откладывание каких-то других проектов.  

Помимо финансового планирования оценка больших объемов работ на старте полезна следующим образом:

1. Появляется возможность понять сроки внедрения проекта и корректировать их, добавляя больше инженеров на проект, или снижать единовременные расходы, уменьшая команду, если сроки это позволяют.
2. В процессе оценки выявляются наиболее сложные и ресурсоемкие задачи проекта, что помогает сосредоточить усилия на ключевых моментах и уменьшить риск возникновения проблем (например, откладывание релиза из-за того, что какую-то из критичных задач оставили на потом, думая, что она реализуется быстро).
3. Обнаруживаются риски, связанные с коммуникациями с третьими сторонами (например, представители сервисов, с которыми необходимо интегрироваться, другие команды, которые работают над смежными проектами) — позволяет своевременно начинать работы по их снижению.
4. Оценки трудозатрат повышают уровень прозрачности между бизнесом и IT-командой — заказчики проекта понимают, что когда ждать, и не начинают подозревать команду в безделии, когда она делает “подкапотные” задачи, результаты которых нельзя просмотреть с помощью интерфейса (например, подготовка окружения, реализация сложных интеграций и т.д.).
5. Сравнение фактических трудозатрат с плановыми помогает оценить эффективность работы команды разработчиков и выявить возможные узкие места для последующего улучшения процесса планирования и разработки.
6. Сравнение оценок одного проекта от разных команд в случае, если они сильно расходятся, позволит выстроить предметный диалог и выяснить, какая из команд подошла к оценке более ответственно, и принять решение с кем работать.

Выше мы говорили про массовый переход к гибким методологиям в IT. Такие методологии не подразумевают предварительной долгой аналитики и проработки полноценных технических заданий, на основании которых делать точную оценку большого объема работ очень удобно: всё прописано до мелочей, делаешь оценку, добавляешь 30% на риски и подписываешь договор по Fix Price (модель оплаты услуг, когда все требования, объем работ и стоимость проекта зафиксированы в самом договоре) без рисков сработать в минус. Но оценки по такому детальному заданию обычно делаются довольно долго, как минимум, нужно время, чтобы прочитать весь текст задания, а решение о старте работ на основании стоимости и сроков часто важно принять как можно быстрее.

Получить оценку быстрее позволяет договоренность работать по Time & Material (модель оплаты услуг, когда заказчик оплачивает исполнителю фактически затраченное время, исходя из стоимости часа специалистов), так как при таком формате работы исполнитель не рискует остаться без частичной оплаты работ, подготовив на старте быструю оценку с меньшей проработкой деталей.

Для заказчика тоже есть преимущества в работе по такой модели:

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

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

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

При сочетании этих факторов становится реально достаточно быстро подготовить качественную оценку, которая будет:

• Содержать функциональные блоки (блоки работ, которые представляют ценность, даже если весь проект не будет завершен, благодаря такому разделению заказчик не из IT сможет сориентироваться, что делать раньше, что позже, или не делать вообще, раз оно столько стоит);
• Техническую декомпозицию работ внутри функциональных блоков (чтобы было понятно, как именно будет реализовываться функционал — это отдельно важно, если у заказчика есть свое IT-подразделение, так можно согласовать общий подход к разработков);
• Диапазон часов, которые потребуется для реализации каждой из задач (чем больше неизвестных по конкретной задаче, тем шире будет диапазон);
• Специализация и уровень специалиста, который будет работать над каждой из задач (тестированием не должен заниматься разработчик, простыми задачами не должны заниматься синьоры, и то и другое в конечном итоге приведет к бессмысленному удорожанию проекта);
• Рейт каждого специалиста, которых планируется подключать к реализации (из этого и предыдущего пункта складывается оценка стоимости, точнее вилка min-max);
• Различные комментарии к функциональным блокам, задачам или в общем к оценке, которые подсвечивают допущения, предположения, на основании которых сделана оценка, риски, которые могут возникнуть в процессе реализации;
• Сроки всего проекта в двух вариантах: если над проектом работает оптимальное количество сотрудников в параллель и если минимально необходимое.

Качественно сделанные оценки на старте полезны и заказчикам, и самим ИТ-специалистам. При высоком уровне специалистов и хорошо выстроенных коммуникациях даже на большие объемы работ достаточно быстро можно получить оценку с понятной погрешностью для принятия решения о старте проекта.

Мы всё это знаем, потому что за 5 лет работы компании мы сделали несколько сотен оценок различных задач и проектов — от коротких задач до больших проектов на команды разных специалистов на несколько лет работы, и это не считая опыта наших специалистов с предыдущих мест работы.

Если у вас есть идея, которую можно реализовать силами java-разработчиков, QA-инженеров и инженеров DevOps, и вам для принятия решения не хватает только понимания стоимости и сроков, то мы всегда готовы это обсудить и подготовить оценку.

Вы всегда можете с нами связаться
через почту: client@softwarecats.dev
телеграм @alex_zarubin

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