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

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

Максим Мул

финансовый директор Work Solutions

1. Какая проблема решается?

Когда-то давно я начинал с фриланса, а сейчас собираю проектные команды, и могу сказать — неважно, берётесь вы за масштабную разработку или выполняете небольшую задачу — алгоритм всегда один.Первым делом поймите, какую проблему заказчика вы решаете. Здесь хитрость в том, чтобы не путать задачу и решение. Часто бывает так, что вам не называют проблему, но говорят, как её решить: просят сделать сайт или приложение. А задача на самом деле — сократить издержки, увеличить продажи. Эти вещи нужно связать, чтобы проверить работоспособность предложенного решения. Будет ли всё работать так, как это представляет себе заказчик? Задавайте открытые вопросы, но без фанатизма, никто не любит на них отвечать.

2. Каков ожидаемый результат?

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

3. Сколько времени даётся на выполнение проекта?

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

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

4. Это разработка с нуля или развитие существующего продукта?

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

Если это работа над существующим проектом, есть ли готовая документация?”]Это важно, так как отсутствие документации и, тем более, разработчика, который занимался проектом до вас, значительно усложнит задачу, что повлияет на сроки и итоговую стоимость.

5. Каков планируемый бюджет?

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

Насколько хорошо подготовлен к проекту сам заказчик?

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

Елена Шишкова

начальник отдела развития и внедрения ERP-решений CorpSoft24

На старте любого проекта важно оценить не только свои силы, как исполнителя, но и понять готовность заказчика к проекту.

Вот то, что нужно уточнить у заказчика в первую очередь:

1. Техническая готовность. Насколько ИТ-инфраструктура заказчика надёжна, обладает ли она достаточной мощностью для реализации будущего проекта.
2. Функциональная готовность. Насколько выстроены функциональные и бизнес-процессы в компании, которые будут задействованы при реализации проекта.
3. Нормативная готовность. Приведены ли в порядок внутренние регламенты и нормативная документация предприятия, необходимые для проведения работ.
4. Информационная готовность. К ней относится уровень качества предоставляемой информации. Насколько подготовлены исторические данные, задействованные в работах и влияющие на процесс и результат проекта. Какова информированность всех участников проекта о предстоящих целях, действиях, процессах, изменениях, результатах.
5. Ресурсная готовность. Достаточная вовлечённость выделенных со стороны заказчика специалистов (компетентность и высокая мотивация как в участии в проектных работах, так и в конечном результате). Заинтересованность в проекте топ-менеджеров заказчика.

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

1. Уточняющие вопросы заказчику по техническому заданию

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

2. Как должна сдаваться работа: по частям или целиком?

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

3. Кто ещё будет задействован в проекте?

Этот вопрос заказчику нацелен на правильное построение коммуникации. Всевозможные созвоны, доступы к документам или сервисам, отчётность — всё это зависит от команды, которая задействована в реализации проекта.

Евгений Лопатин

директор департамента разработки «Инфосистемы Джет»

1. Предполагаются ли какие-нибудь ограничения в работе системы?

Важно в самом начале также ответить на вопрос: «А чего система НЕ будет делать?» Кто-то скажет: ответ очевиден — система не делает ничего, кроме того, что в ТЗ. Но нет, для многих заказчиков это не вполне очевидно, и между строк они зачастую видят много чего сверх.

2. Есть ли какие-либо требования к стеку разработки?

Такой вопрос стоит задать заказчику, если он понимает процесс разработки, это проект не с нуля, или его команда работает с какими-то конкретными инструментами. Допустим, вы привыкли всё хранить в репозиториях на GitHub, а команда заказчика работает с Bitbucket, или он вообще не хочет, чтобы во время разработки проект выходил за пределы локали.

Валерия Суворова

эксперт Центра информационной безопасности компании «Инфосистемы Джет», сертифицированный менеджер проектов (PMP)

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

Приведу простой пример: представьте, что для технического проектирования внедряемой системы вы всегда используете требования ГОСТа, и в очередной раз оформляете документ по стандарту. В момент его согласования вы узнаёте, что у заказчика для него есть свой утверждённый корпоративный шаблон, который содержит специфичные разделы и особое оформление. Вы не задали вопрос заранее, и теперь придётся потратить дополнительное время на исправление результатов.

1. Будет ли команда заказчика участвовать в разработке?

Часто случается так, что заказчик стремится минимизировать расходы и начинает подключать своих людей в середине работы. Это неправильно. Уточните сразу, примет ли ещё кто-то участие в самой разработке, и если да, как это будет спланировано.

Евгений Лопатин

директор департамента разработки «Инфосистемы Джет»

Планируется ли дальнейшее развитие разрабатываемого продукта? Каким оно будет?

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

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

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

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

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

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

В числе основных проблем, которые я упомянул в самом начале, было две: выход из бюджета и срыв сроков. Поэтому при обсуждении будущего проекта всегда надо уточнять сроки получения результата (как окончательного, так и промежуточных результатов – они для заказчика могут быть не менее важны) и планируемый бюджет. Ответы на эти вопросы задают граничные условия проекта и позволяют задать вектор дальнейших обсуждений. Например, если сроки чрезвычайно сжатые, то можно обсуждать подход 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. Что важно получить от решения для эффективной повседневной работы с ним?

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