Какие вопросы с заказчиком обсудить еще до начала работы над проектом? Устраняем потенциальные проблемы

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

Вина за такое недопонимание, конечно, общая, но менеджер со стороны IT-компании виноват больше. Он опытнее, это он должен знать, какие задать вопросы, и что ему нужно для работы. Да и какая разница, кто виноват, если работу нужно переделывать и клиент недоволен.

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

Это первый и самый главный вопрос, который нужно выяснить. Нет смысла в разработке ради разработки. К сожалению, заказчики это не всегда понимают. Очень часто возникают ситуации, когда клиент приходит с просьбой разработать сайт, даже не понимая зачем: «Потому что у всех остальных есть».

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

• Создание посадочной страницы для привлечения трафика.
• Организация онлайн-продаж.
• Ресурс для коммуникации с клиентами и их поддержки и т.д.

Если проект не имеет цели, и не решает конкретную боль клиента, то он просто не может быть успешным. Он не приносит пользы клиенту. Иногда роль менеджера и в том, чтобы вместе с заказчиком подумать, какие «узкие горлышки» в его бизнесе можно расширить при помощи разработки программных продуктов.

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

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

Будьте осторожны, давая письменные обещания. Не стоит гарантировать того, что может быть не достигнуто по результатам работы. Впечатление заказчика от сотрудничества будет сильно испорчено.

Есть ли у компании-заказчика сайт, приложения, CRM, учетные системы 1С, возможно какое-то дополнительное ПО? Эта информация очень важна.

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

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

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

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

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

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

Далеко не всегда заказчики согласны на любые дедлайны, которые им назовут исполнители. По объективным причинам сроки разработки могут быть очень сжаты. Этот момент менеджер проекта должен уточнить при первой же консультации с клиентом. В противном случае он просто потратит время на расчет сроков, которые не устроят заказчика.

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

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

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

• Технологическая готовность. Насколько IT инфраструктура компании развита и безопасна. Достаточно ли ресурсов для реализации будущего проекта.

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

• Функциональная и нормативная готовность. Насколько в реальности бизнес-процессы компании работают так, как руководитель хочет их автоматизировать. Особенно это касается автоматизации учета на предприятии. Строить конфигурации 1С только со слов руководителя неправильно. В реальности каждый учетный процесс может проводиться совсем по-другому. В итоге, продукт не то что сделает процесс эффективнее, но и замедлит его из-за неудобства использования.

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

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

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

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

Не менее важно обсудить, что программа НЕ должна делать. Обычно диалог менеджера проекта с заказчиком строится вокруг того, что должно быть в продукте. Тема ограничений поднимается далеко не всегда.

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

Это неприятный, но необходимый для обсуждения вопрос. Заказчику может показаться, что работа еще не началась, а мы уже обсуждаем проблемы. Но лучше это обговорить «на берегу», а не в момент сдачи проекта.

Клиенту нужно объяснить, что при работе по Waterfall модели сразу все предусмотреть невозможно. После того как проект будет реализован, а заказчик его «пощупает» совершенно точно у него появятся пожелания по доработке функционала, а вы вряд ли захотите делать их за свой счет. Вот и возникла проблема на ровном месте. Из-за того, что о внесении доработок, и их платности никто заранее не предупреждал.

Это далеко не все вопросы, которые должны быть обсуждены на предварительных встречах между заказчиком и клиентом. Также важно обговорить конфиденциальность сотрудничества (NDA), ожидания по бюджету и многие другие детали работы. Более того, список вопросов и необходимой информации меняется в зависимости от типа проекта, его масштаба, особенностей бизнеса заказчика и многих других мелочей. Все рассмотреть в одном тексте невозможно. Способность менеджера проектов «вытягивать» из заказчика нужную информацию приходит с опытом.

Источник — Курс «Как стать классным менеджером проектов и не ох..еть»

Ссылка на курс для жителей России