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

В любом проекте мы имеем дело с двумя видениями проекта: ожиданием заказчика и представлением исполнителя.

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

Кроме того, что ожиданиям нужно соответствовать (если исполнитель не хочет чтобы это был его последний проект с этим клиентом), их желательно превышать (о чем написано много книг о клиентоориентированности, например Карл Сьюэлл “Клиенты на всю жизнь”).

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

vРасхождение между двумя этими видениями в любом случае сохранятся, задача обеих сторон - максимально сократить эту разницу.

1. Если исполнитель не собрал информацию об ожиданиях клиента, то картина будет выглядеть примерно так.
2. Или так, если исполнитель не погрузился достаточно в “тему” клиента и мыслит своими шаблонами или стандартными средствами системы, в которой он будет реализовывать продукт.
3. Практически невероятный сценарий, при котором заказчик не знает почти ничего, а исполнитель сверхответсвенен.
4. Наиболее распространенная картина. В которой с обеих сторон присутствует зона, о которой не знает другая сторона.

Давайте немного детализируем схему. Если техническое задание пишет исполнитель, то его представление будет практически в точности совпадать с границами этого ТЗ (схема справа). Но не редки случаи, при которых тех. задание разрабатывает сторонняя компания, тогда возможно отклонение от обеих существующих точек зрения. Такок видение проекта так же важно (схема слева) - она всегда ближе к тому кто будет пользоваться продуктом.

“Пояс астероидов”

Исполнитель всегда закладывает определенные риски, как при ценообразовании, так и при составлении документа. Таким образом за рамками ТЗ возникает небольшая область работ, заложенная исполнителем в проект, но не описанная им в документах.

Важно зафиксировать, что исполнитель уже готов пойти на работы, которые попадут в эту область ("пояс астероидов"). Но до завершения проекта вы не знаете, какие именно работы могут в нем “разместиться”, поэтом рекомендуем не настаивать на реализации того или иного пожелания, а копить их до приема основных пунктов тех. задания.

Давайте разберем, что же это за задачи, которые могут попасть в этот “пояс”.

1. Пограничный вопрос, косвенно подразумевающийся в ТЗ, но не описанный явно.
2. Вопрос, относящийся к проекту, но крайне опосредованно, шансы включить его реализацию в рамках проекта 50/50 - все зависит от ваших способностей переговорщика.
3. Как правило, так выглядят вопросы, не описанные явно, но являющиеся определенным стандартом на рынке.
4. Крупная задача, выходящая за рамки ТЗ, тут вас, скорее всего, ждет отказ со стороны исполнителя.
5. Функционал никак не связанный с проектом и не упоминавшийся ранее - шансы включить в проект равны нулю.
6. Функционал не затронутый в тз, выглядящий как небольшое пожелание, но требующий существенных усилий для реализации. Например, немного другой алгоритм поиска. Исполнитель будет всеми силами отказываться от реализации этого пункта в рамках проекта.
7. “Серый пункт” - пункт или раздел, сформулированный очень неявно или кратко. Наличие таких пунктов показывает непрофессионализм исполнителя, рано или поздно он уступит и реализует функционал, но это может негативно сказаться на ваших дальнейших взаимоотношениях. В данном случаем мы рекомендуем обеим сторонам пойти на компромисс.

Кто такой профессиональный заказчик

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

Профессионализм заказчика проявляется в нескольких признаках:

• Умение делегировать - принятие решения не завязывается на 1 сотруднике (директоре), который может давать обратную связь в течение 3 дней, а делегируется, иногда в зависимости от типа вопросов.
• Прозрачная схема принятия решения - вытекает из первого, но иногда даже ген. директор берет тайм-аут на согласование проекта с владельцем бизнеса или инвесторами. Это нормальная ситуация, но о ней нужно знать и учитывать при согласовании.
• Клиент умеет прислушиваться к мнению профессионалов - речь идет не только об исполнителе. Тот случай когда клиент способен ориентироваться не только на свое видение, но и прислушиваться к специалистам, своим или сторонним.
• У проекта есть KPI. Кроме KPI проекта после запуска есть KPI реализации самого проекта. В нормальном случае это всего 3 показателя: сроки, стоимость, функции (или ценность функций). Если клиент исходит лишь из формальных признаков проекта, а не достижения цели, для которой реализуется проект, то риски для исполнителя в таком проекте возрастают.

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