Обычное дело — на этапе обсуждения будущего проекта студия выясняет, что на стороне заказчика нет лица, принимающего решение. Точнее он есть, но до него не добраться. Вместо него дела ведет доверенный менеджер. Брать ответственность за принятие окончательного решения он не может, но и выхода на ЛПР не дает.  Проблема в том, что это не выгодно никому — ни ЛПРу, ни менеджеру, ни подрядчику.  В статье расскажем, каких ошибок избежит бизнес, если в разработке продукта будет участвовать лицо, принимающее решение.  ЛПР — лицо, принимающее решение. То есть человек, чье решение является окончательным в заключении сделки. Это может быть исполнительный или генеральный директор. В некоторых случаях владелец бизнеса. Сходу важное уточнение — ему НЕ нужно присутствовать на проекте 24/7, речь про участие в ключевых моментах:  брифинг, когда выясняются потребности бизнеса; демонстрация результата после каждого этапа, чтобы согласовать последующие действия.  Этого достаточно. Итак, теперь по пунктам: Еще на начальных этапах руководитель может скорректировать планы и работу, сэкономив тем самым время и бюджет.  Представьте: ЛПР доносит до своего доверенного менеджера, что будущий сайт должен быть как у Apple. Студия берет его за референс и делает в лучших традициях яблока. Но потом оказывается, что как у Apple должен быть только шрифт, а все остальное — футуристичное. Пример грубый, но подобные недопонимания — явление частое. Менеджер среднего звена может не подозревать о стратегических целях компании, а это в дальнейшем повлияет и на выбранный технологический стек, и на стоимость проекта. ЛПР может скорректировать этот момент, информируя студию из первых уст. Важные нюансы, которые влияют на стоимость и сроки, не станут для него сюрпризом.  Ситуация: студия информирует менеджера заказчика, что оплачивать услуги нужно до 10 числа каждого месяца. Оплачиваются только потраченные в этом месяце часы. Менеджер передает руководству, мол, платить нужно до 10 числа. Но не доносит важную информацию, что оплата идет за затраченные часы. И заказчик требует сначала сдать задачи, и только потом будут деньги. Эффект глухого телефона в деле.  Например, мы в Пиробайт еще на этапе пресейла готовим аналитику и/или концепцию дизайна.  Если коротко — ничего хорошего.  Может внезапно оказаться, что новые «хотелки» влияют на предварительно озвученный бюджет.  Ситуация: ЛПР представлял, что в работу по умолчанию включены неоговоренные этапы (наполнение и публикация в сторах, например). Менеджер на стороне клиента знал, что дополнительная работа оплачивается отдельно. Но забыл сказать или не хотел расстраивать. Представьте: дизайнер создал концепцию, менеджер все утвердил, запустилась верстка. ЛПР пропустил письма и увидел результат сильно позже. Получилось не то, чего он ожидал. Каждому из участников придется набраться терпения и морально настроиться на переделку. Ситуация может дойти до крайности, когда поверх правок будут новые, а поверх них — еще одни. В результате релиз затянется, а бюджет сольется. С позиции менеджера среднего звена этот момент может быть неочевидным, но с точки зрения руководителя — это почти всегда весомые потери.  Или не то, что просил.  Ситуация: студия вложилась в пресейл. Сделала концепт, провела аналитику, потратив 16 часов своего времени, а ЛПР вернулся из отпуска и сказал, что его и старый сайт устраивал  ¯\_( ͡° ͜ʖ ͡°)_/¯  Или обратная ситуация — перетягивание одеяла, когда за проект отвечают все и никто. Актуально, когда на стороне заказчика работают 2 или 3 менеджера. Команда предлагает идеи и накидывает правки, которые противоречат друг-другу.  В итоге руководство будет недовольно ни результатом, ни исполнителем, ни работой менеджера. А все потому, что у ЛПРа нет контекста — он не участвует в разработке и не знает всех нюансов. Когда человек, не погруженный в курс дела, видит картинку, он не видит всего того, что было проделано до. Поэтому у него нет понимания, почему блоки на странице именно такие, почему цвет синий, а не розовый, почему на главной страницы нет анимации. *** И одно дело, когда до ЛПРа действительно не допрыгнуть, потому что в компании сложная организационная структура. Но чаще бывает другое — когда доверенное лицо говорит, что ЛПРа нельзя подключить к разработке, а на деле за этим прячутся страх или личные мотивы. Или нежелание лишний раз попадаться на глаза начальству, чтобы не «получить» за какие-то другие задачи, поэтому и с этой он не пойдет к руководителю. Менеджеру кажется, что он прекрасно знает, что нравится его руководителя. Но как только ожидание сталкивается с реальностью, выясняется, что у босса совсем другое видение, которое не сходится с видением своего помощника. Руководитель слишком занятой человек (это бесспорно), а потому его лучше не отвлекать от дел. Либо он мало что понимает в разработке, по его мнению. В этих ситуациях высок риск того, что как только руководство подключится к этапам, которые он пропустил, все повернется на 180°. Обычно так и происходит. Совет простой — не строить иллюзий по поводу сроков и успешности проекта (потому что иногда успешность зависит от сроков напрямую). На практике переговоры без ЛПР затягиваются, сроки срываются, а бюджет сливается на оплату очередных итераций правок студии. Все потому, что видение менеджера клиента и ЛПРа, вопреки ожиданиям, часто расходятся. Вывод простой — доносите до ЛПР важность его участия на ключевых этапах разработки. И пишите в комментариях, что думаете по этому поводу. ***  Чтобы не пропустить интересное, следите за нами: В телеграм-канале Во ВКонтакте На нашем сайте  Разработка веб-сервисов и приложений