37
1
0
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
Назад

Как выстроить работу с заинтересованными лицами ИТ-проекта

Время чтения 1 минута
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
37
1
0
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники

Привет. Меня зовут Дмитрий Кочергов, я кандидат экономических наук и бизнес-аналитик. Сегодня предлагаю поговорить о том, как организовать эффективное взаимодействие с заинтересованными сторонами разработки и внедрения ИТ-решения, потому что здесь кроется много подводных камней.

Как выстроить работу с заинтересованными лицами ИТ-проекта

Для начала определимся с понятиями

Обычно заинтересованные стороны (ЗС), или стейкхолдеры, в проекте автоматизации — это любые люди, организации или институты, которые пользуются его результатами и могут на них влиять. Прежде всего это заказчики/покупатели АИС как продукта. Основная работа аналитика с ними заключается в сборе и анализе бизнес-требований.

Первая встреча: как подготовиться

Перед первой встречей постарайтесь собрать максимум достоверных сведений о бизнесе заказчика. Сюда входят:

  • отраслевая специфика; 
  • история организации;
  • какие средства автоматизации внедрены;
  • есть ли стратегия цифровой трансформации и каков ее план;
  • кто ваши конкуренты на рынке исполнителей и что они продают.

Эти сведения помогут составить предварительные варианты вашего предложения: не стоит ждать, что заказчик сядет и расскажет, какая ему нужна функциональность, даже если есть готовое ТЗ. Парадокс в том, что в 9 из 10 случаев напротив вас за столом окажутся менеджеры, которые не просто малокомпетентны в ИТ, — они плохо понимают, чего на самом деле хотят, и не могут это объяснить в четких критериях и показателях эффективности. Вы должны сделать первый шаг ради собственного успеха. Шаблоны таких технико-коммерческих предложений следует составить заранее, исходя из ваших возможностей и продуктово-сервисной линейки.

Главное правило общения и другие советы

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

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

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

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

Фиксируйте изменения требований, лучше под запись: ЗС часто капризны и беспамятны, плохо разбираются в ИТ, не могут сразу ответить, чего хотят, а что не нужно. Критически важно соотносить вновь поступившие запросы ЗС с их старыми версиями, анализировать причины перемен, открыто обсуждать их с учетом ресурсных ограничений с вашей стороны (вендора) и актуализировать артефакты. 

Три вопроса, которые помогут определить концепцию ИТ-решения

В результате работы со стейкхолдерами от аналитиков ждут вербализацию и визуализацию идей — того, о чем думает топ-менеджмент, чего хотят или захотят заказчики и покупатели, чего не хватает в работе пользователям и что поэтому должно появиться на рынке. Я советую вначале сосредоточиться на трех вопросах: ЧТО, КОМУ и ЗАЧЕМ вы собираетесь предложить как концепцию ИТ-решения. 

ЧТО — сформулируйте техническое название продукта, которое отразит его целевое назначение. Например, если речь о решении для автоматизации склада, вполне годится «система управления складскими операциями с товарно-материальными запасами». Это четко определяет отраслевую принадлежность и предметную область проекта. Имя бренда коллеги придумают потом (и, скорее всего, вас не спросят).

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

ЗАЧЕМ — отталкиваясь от представленных интересов и ожиданий целевой аудитории, укажите основные функциональные возможности продукта на верхнем уровне без деталей. Это поможет очертить границы автоматизации и покажет полезность проектируемого решения.

Что, если по итогу интервью ЗС нужно подготовить описание процесса с учетом оптимизации, но в нем много участников, шагов и промежуточных результатов? 

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

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

Комментарии0
Тоже интересно
Комментировать
Поделиться
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники