Парадокс оценки проекта

Зачастую клиент приходит со своим проектом и говорит:
“Хочу сделать сайт. Сколько будет стоить, когда сделаете и как гарантируете сроки/стоимость?”

Здесь уместна аналогия с приемом у доктора.
Пришел пациент, сказал: “У меня болит”.
Навряд ли он надеется на то, что доктор без общения с пациентом, без изучения истории его болезни, без анализов и обследования выпишет лекарства и даст гарантию на сроки выздоровления.

Но почему-то с IT-проектами не так.
Клиенты хотят четкости и гарантий уже на старте.
Забывая или даже не догадываясь о том, сколько факторов влияют на итоговую оценку.

Давайте разберем три главных причины, почему оценка и гарантии в IT разработке на старте — просто маркетинговый трюк.

Причина №1.
Недостаток данных

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

Если данных на старте недостаточно, то оценка — это не четкий расчет, а гипотеза.

Причина №2.
Все течет, все изменяется.

Даже если клиент идеален и учел, как ему кажется, все нюансы на старте, то дальнейшие изменения  все равно неизбежны.
Рынок, конкурентная среда, технологии — все меняется с невообразимой скоростью.
Проект в такой ситуации приходиться эволюционировать. 
Клиент видит работу, соотносит ее с изменившимися условиями и осознает, что нужно что-то добавить или переделать. 
И это нормально!
Но как можно гарантировать точную оценку, если мы понимаем, что сам фронт работ гарантированно будет меняться?

Причина №3
Взаимодействие клиента и команды.

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

Команда разработки – эксперты в технологиях, но не в специфике бизнеса клиента.
Важные бизнес-детали, конкурентные преимущества, ключевые потребности ЦА – всё это знает только клиент.

Если заказчик долго не участвует в работе, а потом резко подключается с новыми требованиями, это приводит к дорогостоящим переделкам.

Зачастую клиент, как идеолог проекта, начинает общение с командой разработки, а затем переключает все на свой менеджмент.  А менеджмент, как оказывается, не “тянет” проекта на уровне идеолога.

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

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

• Насколько понятны этапы работы?
• Насколько удобна и прозрачна коммуникация?
• Насколько быстро принимаются решения и вносятся изменения?

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

Если процесс вас устраивает — едем дальше.  Если нет — лучше расстаться на раннем этапе, чем столкнуться с проблемами позже.

А как организован этот процесс на практике и почему именно он определяет успех проекта – читайте в следующей статье:  "Как старт проекта не сделать его финишем".