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

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

Я, когда пытаюсь поговорить с ЛПРом о проекте...

1. Контекст — это основа всего

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

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

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

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

2. Цена, сроки, этапы: кто будет принимать решения?

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

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

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

3. "Я думал, что мне сделают всё сразу"

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

4. Постановка целей и задач: без ЛПР будет больно

Контекст определяет границы разработки, а также создаёт точки опоры.

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 12609 тендеров
проведено за восемь лет работы нашего сайта.

ЛПР должен участвовать в постановке задач, потому что:

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

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

5. ЛПР — соавтор проекта

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

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

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

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

Вывод

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