Как снизить неопределенность: советы для всех, кто запускает ИТ-проекты

Разрабатываете приложение, внедряете новую систему или модернизируете существующую? К сожалению, ни в одном из этих случаев вы не застрахованы от неопределенности или, проще говоря, от неполноты информации о требованиях и/или условиях реализации решения. 

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

Это самые распространенные примеры, с которыми может столкнуться каждый руководитель проекта. Как же избежать неопределенности на старте и какие вопросы задать клиенту, как помочь бизнесу дать нужные команде ответы и успешно согласовать предложенные решения? Все эти вопросы разберем в этой статье. Материал будет полезен владельцам продуктов, руководителям ИТ-проектов, а также всем, кто запускает и развивает ИТ-решения. Здесь вы найдете практические советы, которые помогут снизить неопределенность.

Снижаем неопределенность — задаем уточняющие вопросы владельцу продукта

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

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

Рисуем квадрат и распределяем уточняющие вопросы по четырем блокам

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

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

На мой взгляд, первую встречу можно считать успешной, если:

• Заданы заранее заготовленные и возникшие в ходе беседы вопросы по всем 4 пунктам;
• Получены ответы на половину и более заданных вопросов;
• Заказчик задавал встречные и даже «щекотливые» вопросы.

Как помочь заказчику дать все необходимые ответы

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

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

Есть ряд методик, чтобы помочь заказчику дать необходимые ответы по тем вопросам, где нужно видение клиента. Например, схема уточняющих вопросов «глагол-объект-условие». Рассмотрим на примере.

Глагол: «Уточните, что необходимо получить на момент закрытия проекта?».

Объект: «Характеристики, свойства и особенности продукта, услуги или результата. Какие задачи должна решать система?».

Условия/Последствия: «Как вы поймете, что получили наилучший результат? Какие из требований наиболее приоритетны?».

Разговорить клиента и помочь ему найти ответы на представленные вопросы можно с помощью теории трансактного анализа Э.Берна. Хорошим подспорьем в этом может стать книга Томаса Харриса «Я —  О’кей, Ты — О’кей». 

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

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

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

Во-вторых, не забываем про психологические особенности восприятия конкретного человека, с которым вы ведете переговоры. Для этого определите, кто перед вами: аудиал, визуал, кинестетик или дигитал. Если верить статистике, то в России 35% — кинестетики, 35% — визуалы, 25% — дигиталы и всего 5% — аудиалы. Далее приведу список некоторых «слов-мотиваторов», которые помогут донести смысл и подобрать презентацию для соответствующего типа личности. Безусловно, способ подачи не влияет на содержание, но при этом помогает передать информацию быстрее и наиболее удобным для клиента образом.

• Визуал: здесь все понятно, как вы можете увидеть, давайте посмотрим, стоит обратить внимание, представьте, что это выглядело бы вот так, я вижу о чем, вы говорите.
• Аудиал: послушайте, это звучит привлекательно, это о много говорит; как вы могли слышать, было интересно услышать его мнение.
• Кинестетик: данные вызывают оптимизм, в итоге получается, с радостью могу сообщить, весомый, крепкий, прочный, надежный.
• Дигитал: логично, как вам известно, я полагаю, при внимательном изучении, знаю, понимаю, рассмотрим эту деталь, очевидно, что.

Вместо выводов

Как известно, есть четыре вида неопределенности: 

• Изменчивость — незначительные изменения, которые клиент, возможно, попросит вас внести в ходе проекта. Как избежать этих изменений, мы и рассказывали в этой статье.
• Ожидаемая неопределенность — неопределенность, которую можно выявить в ходе заполнения реестра рисков и плана событий. 
• Неожиданная неопределенность — событие, которое нельзя предсказать или оно очень маловероятно. Неожиданную неопределенность следует воспринимать как проблему, с которой необходимо разобраться по мере ее возникновения.
• Хаос — тут и так понятно. Чаще всего такой вид неопределенности связан с какими-то внешними факторами, например, изменения на рынке, которые не зависят ни от клиента, ни от команды. Здесь только один совет — быть гибкими, быстро подстраиваться под меняющиеся условия и новые требования. 

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