Очень часто заказчики дают нам пример сайта и просят получить оценку проекта. При это говорят, что, конечно примерную с разбросом в 15-20%. Этот момент уже сам по себе является абсурдным. И вот почему:

Первое и самое простое – мы не знаем, что у него под капотом – вы видим либо front end часть. Мы не видим админку, и не знаем какая есть интеграция с внешними системами.

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

Третий момент – вам не все нужно с сайта-примера. Необходимо учитывать, что выбранный проект уже находится не в начальной стадии (вы же не выбрали в качестве образца новоиспеченный проект, верно?). Для начальной стадии нужен далеко не весь функционал, который есть на зрелом проекте.

Четвертый момент – даже имея очень подробное техническое задание, оценка проекта все равно будет иметь довольно большую погрешность (точно не менее 10-20%). Это суровая реальность оценки проектов (а не то, что мы кривые оценщики). Многие требования более детально выявляются уже на этапе разработки. Некоторые требования вообще коренным образом меняются. При оценке разработчик уже должен прикинуть как будет решаться задача, но в реальности решение может быть совершенно другим.

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

Что будет, если вы все-таки заставите разработчиков железно зафиксировать сроки, объем и бюджет?
Скорее всего рано или поздно начнутся проблемы и трения. Приготовьтесь к следующему:
1. Разработчик будет требовать от вас очень очень подробного ТЗ (учим писать ТЗ на курсе по созданию технического задания).
2. Если разработчик опытный, то оценивать ТЗ он скорее всего будет с очень большим запасом, чтобы не встрять.
3. Любое отступление от ТЗ, любой дополнительный чих разработчиков придется согласовывать и оплачивать.
4. В итоге все равно один из параметров все равно будет сорван и начнется охота на ведьм. Кто виноват, что делать и т.д.
5. В итоге неудовлетворенными окажутся и заказчик (получил не совсем то, что хотел), и исполнитель (пришлось решать неучтенные проблемы на проекте за свой счет).

Через все эти моменты мы проходили, т.к. не всегда возможно убедить заказчика в бесперспективности такого подхода.

Есть ли альтернатива?
Со стороны заказчика важно не потратить рационально бюджет, а важно получить бизнес-результат причем как можно быстрее и дешевле.

Как этого добиться?
С помощью следующих принципов:
– сделайте сначала прототип приложения и попробуйте его на реальном клиенте. Это будет дешевле, чем делать весь громадный проект и потом надеяться, что аудитория его примет.
– должно быть понимание, что по ходу проекта будет очень много изменений и метаморфоз проекта. Ориентируйтесь на свою бизнес-цель (удовлетворение потребности конечного клиента), а не на конечный бюджет. В данный момент вы просто не можете знать наверняка, что нужно вашему клиенту. Поэтому делайте малые шажки и проверяйте, что вы двигаетесь правильно.
– постройте правильный процесс взаимодействия с командой разработки. Важны не выходные параметры по договору (цена, сроки и объем) и именно способ взаимодействия. Как вы будете ставить задачи? Как и когда будете контролировать результат? Как вы будете проверять результат на реальных пользователях?
– правильный фокус в проекте. Кого-то несет в дизайн, кто-то начинает добавлять редко используемые возможности. Ваш фокус – это создать самый простой инструмент по решению проблемы пользователя. Все остальное – боком.
– не старайтесь охватить весь проект целиком. Оценивайте только ближайший шаг. У вас должно быть примерное понимание того, что будет надо сделать в будущем, но это не четкий план, а скорее направления, в которых вы будете двигаться в дальнейшем, если ситуация коренным образом не изменится.

Если идти по шагам, то можно выстроить процесс следующим образом:
– определяем минимальный рабочий продукт (MVP)
– выбираем команду для реализации (в первую очередь не по цене и технологиям, а по необходимому вам способу взаимодействия)
– макеты MVP, начальная оценка
– делаем этот минимальный продукт
– проверяем на реальных клиентах
– итеративно улучшаем продукт

Если вы являетесь приверженцем подхода “Все сразу в жестких рамках” и вас совершенно не убедили мои доводы, пожалуйста, дайте свой комментарий по ним.