18+ вопросов заказчику, которые нужно задать перед началом работы

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

Дополнительные вопросы заказчику: отвечают эксперты

Сергей Комаров

руководитель департамента информационных решений РДТЕХ

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

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

В числе основных проблем, которые я упомянул в самом начале, было две: выход из бюджета и срыв сроков. Поэтому при обсуждении будущего проекта всегда надо уточнять сроки получения результата (как окончательного, так и промежуточных результатов – они для заказчика могут быть не менее важны) и планируемый бюджет. Ответы на эти вопросы задают граничные условия проекта и позволяют задать вектор дальнейших обсуждений. Например, если сроки чрезвычайно сжатые, то можно обсуждать подход MVP (Minimum Viable Product — минимально жизнеспособный продукт).

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

Михаил Сарычев

директор по развитию DBI

Перечень конкретных вопросов очень зависит от специфики проекта. Обычно мы задаём много вопросов заказчику о его внутренней инфраструктуре, о том, как реализована интеграция: в этом направлении чаще всего упускаются какие-то, казалось бы, мелкие нюансы, которые потом могут кардинально повлиять на оценку и на ход проекта. Особенно это касается интеграционных компонентов и систем, созданных заказчиками самостоятельно, «с нуля». Я рекомендую получать максимальную информацию о таких программных продуктах: очень часто их описание не задокументировано, а ответы на вопросы хранятся только в головах их разработчиков. Часто, работая с собственными разработками заказчиков, мы недооценивали сложность интеграции или в самый последний момент узнавали о том, что программный продукт реализован на старой или редкой технологии, которую в нашей компании мало кто знает.

Несколько важных вопросов, которые мы спрашиваем у клиента всегда, вне зависимости от специфики проекта:

1. Кто внутренний заказчик (так как с запросом может прийти ИТ, а использовать продукт будет, например, маркетинг)?
2. Второй важный вопрос: есть ли верхнеуровневое ТЗ и видение конечного результата у заказчика, а также чётко сформулированные критерии успеха проекта.
3. Если ТЗ уже готово, и проект достаточно проработан, то присутствует ли на проекте ещё кто-то из подрядчиков по смежным направлениям, связанным с данным проектом? Это важно понимать для построения правильной коммуникации, координации и планирования.
4. Есть ли специфические требования у отдела службы информационной безопасности заказчика? Сроки предоставления доступов, возможность работать удаленно, какие технологии и подходы одобрены в компании и т. д. В подавляющем большинстве случаев проходить согласование со службой безопасности перед приёмкой проекта придётся, поэтому лучше уточнить все требования «на берегу», чтобы потом не было неприятных неожиданностей.

По нашему опыту, отсутствие ответов на эти вопросы приводит к целому набору проблем: затягивание сроков старта проекта из-за несвоевременного предоставления доступов; расхождения в понимании конечного результата и ожиданий клиента; сложности в дополнительной координации и коммуникации и затягивание сроков из-за задержек на стороне других участников проекта; неверная постановка задач от ИТ-службы заказчика в связи с расхождением в понимании требований между айтишниками и конечными пользователями проекта.

Руслан Сумцов

руководитель отдела аналитики и проектирования решений Bercut

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

Говорим с бизнес-заказчиком

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

ТОП-4 вопроса для бизнес-заказчика:

1. Какую бизнес-задачу должен решать продукт? Или какие ограничения для бизнеса должен устранять?

Пример бизнес-задачи. Наше решение MNP (Mobile Number Portability) решает задачу автоматизации переноса данных при сохранении номера абонента, когда он меняет оператора.

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

2. Какова стоимость проекта?

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

3. Срок. Когда решение должно достигнуть результата?

Так же, как и стоимость, длительность может стать как ограничителем всего проекта и поставляемого решения, так и дать дополнительные возможности.

4. Готов ли заказчик что-то менять в компании в связи с поставкой решения?

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

Говорим с техническими специалистами

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

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

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

Вот мои ТОП-5 вопросов для технических специалистов заказчика:

1. Какие должны быть использованы технологии?
2. На каком уровне необходимо решать вопросы безопасности?
3. Планы по нагрузке (число пользователей)?
4. Как пользователи видят свою работу с решением, какие задачи важно решить?
5. Что важно получить от решения для эффективной повседневной работы с ним?

Аналитику важно помнить, что любое решение делается для людей и ради людей.