Что будет, если в разработке не участвует ЛПР?

Разработка мобильного приложения — это не просто написание кода, а создание инструмента, который решает конкретные бизнес-задачи. Чтобы продукт действительно приносил пользу, подрядчик должен понимать контекст бизнеса: цели предприятия, процессы, ограничения, сезонность, финансирование и аудиторию. Единственный человек, который располагает полной картиной, — ЛПР (лицо, принимающее решения). И если он не участвует в процессе, то проект рискует превратиться в хаос.

Однажды, когда студия только начала работать, к нам пришёл клиент с проектом, который разрабатывался без участия ЛПР. Когда тот подключился, оказалось, что бюджет не учитывает необходимые интеграции, не соответствует стратегическим целям бизнеса. Всё это пришлось переделывать с нуля. Итог: сдвиг сроков, пересогласования, дополнительные расходы. Разработчик не экстрасен — ему нужен доступ к полному контексту!

Важно понимать потребности бизнеса, его аудитории и стратегические приоритеты, а ключевую роль в этом играет ЛПР.

• Только он понимает, какие цели ставит перед бизнесом руководство.
• Только он знает особенности аудитории, для которой создаётся продукт.
• Только он может согласовать бюджет и определить стратегические приоритеты.

Если этот человек не включён в процесс, подрядчик вынужден работать вслепую, ориентируясь на посредников, у которых может не быть всей информации.

Когда подрядчик не может оперативно взаимодействовать с ЛПР, процесс превращается в игру в испорченный телефон:

• Разбивка проекта на этапы становится сложной: без понимания конечных целей невозможно предложить корректные альтернативы.
• На этапе обсуждения технических решений возникает недопонимание и разночтения, а значит, растёт риск получить продукт, который не соответствует ожиданиям.
• Вместо чётких решений — долгие согласования через посредников.
• Каждая корректировка бюджета превращается в бесконечные обсуждения.

Если ЛПР не участвует в обсуждении с исполнителем, велика вероятность, что он не получает всей полноты информации, и итоговая версия приложения окажется слишком дорогой, слишком сложной или просто бесполезной.

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

Контекст определяет границы разработки, а также создаёт точки опоры. ЛПР должен участвовать в постановке задач, потому что:

• Без него сложно спроектировать механику приложения так, чтобы она решала именно те проблемы, ради которых создаётся продукт.
• Только он может скорректировать подрядчика и предупредить ошибки ещё на этапе проектирования.
• Без его участия приёмка проекта может превратиться в пытку: «Я это не запрашивал!», «Почему здесь нет того, о чём я думал?!», «Теперь переделывайте!»

Если ЛПР не участвовал, то, скорее всего, на этапе приёмки начнётся выяснение, почему всё не так, как он представлял. Но исправлять ошибки в конце — всегда дороже и дольше.

В каком-то смысле ЛПР должен быть не просто участником, а автором проекта. Ведь именно он понимает, какие задачи приложение должно решать для бизнеса, а подрядчик — лишь инструмент, который помогает воплотить эти идеи в жизнь.

Если убрать ЛПР из процесса, то:

• Подрядчик не сможет принимать стратегические решения.
• Проект может уйти не в ту сторону.
• Итоговый продукт не принесёт бизнесу ожидаемой пользы.

Разработчик — не волшебник, он реализует идеи бизнеса. А если ЛПР в стороне, приложение может оказаться «ни вашим, ни нашим».

Разработка без участия ЛПР — это риск получить продукт, который не решает бизнес-задачи, стоит дороже, чем хотелось бы, и требует бесконечных доработок. Если же ЛПР включён в процесс с самого начала, разработка идёт быстрее, а итоговое приложение действительно приносит пользу.

Так что, если хотите, чтобы ваш проект был успешным, не прячьтесь за менеджеров. Участвуйте, направляйте и становитесь соавторами вашего будущего цифрового продукта!