Как работать со стейкхолдерами ИТ-проекта
Заинтересованные стороны (ЗС), или стейкхолдеры, в проекте автоматизации — это любые люди, организации или институты, кто пользуется его результатами и может на них влиять. Прежде всего, это заказчики / покупатели АИС как продукта. Основная работа аналитика с ними заключается в сборе и анализе бизнес-требований.
Перед первой встречей постарайтесь собрать максимум достоверных сведений о бизнесе заказчика — отраслевая специфика, история организации, какие средства автоматизации внедрены, есть ли стратегия цифровой трансформации и каков ее план, кто ваши конкуренты на рынке исполнителей и что они продают. Эти сведения помогут составить предварительные варианты вашего предложения — не стоит ждать, что заказчик сядет и расскажет, какой ему нужен функционал. Даже если есть готовое ТЗ. Прикол в том, что в 9 из 10 случаев напротив вас за столом окажутся менеджеры, которые не просто мало компетентны в ИТ — они плохо понимают, чего на самом деле хотят, и не могут это объяснить в четких критериях и показателях эффективности. Вы должны сделать первый шаг — ради собственного успеха. Шаблоны таких технико-коммерческих предложений следует составить заранее, исходя из ваших возможностей и продуктово-сервисной линейки.
Главное правило общения с ЗС — слушать и слышать. Важно получить и корректно интерпретировать их видение — танцевать в итоге тому, кто заказал музыку. Вы же не хотите испортить танец? Управляйте неизбежным конфликтом интересов — рано или поздно, в ходе переговоров вы обнаружите, что разные ЗС начинают противоречить друг другу, а порой и самим себе, в своих требованиях. Более того, недопонимание, инфошумы и откровенный саботаж станут навязчивыми спутниками проекта. Постарайтесь обозначить точки роста — зоны совпадения целей и задач, векторы конструктивного направления мысли, от которых вы сможете оттолкнуться, наметив шаги для дальнейшего согласования.
Оперируйте четкими ясными критериями для оценки результатов — предложите ЗС назвать или выбрать из вашего перечня конкретные параметры, например, эффективности внедрения, с помощью которых можно сформулировать образ желаемого будущего объекта автоматизации. Говорите с ними на одном языке — языке бизнеса.
Оставайтесь в курсе рыночной, геополитической, нормативно-правовой конъюнктуры отрасли проекта — вас не должны застать врасплох технологические инновации, длинные волны кризисов, законотворчество в сфере деятельности ЗС. Изучите специфику работы вашего заказчика (заказная разработка) или покупателя (коробка).
Фиксируйте изменения требований, лучше под запись — ЗС часто капризны и беспамятны, плохо разбираются в ИТ, не могут сразу ответить, чего хотят, а что не нужно. Критически важно соотносить вновь поступившие запросы ЗС с их старыми версиями, анализировать причины перемен, открыто обсуждать их с учетом ресурсных ограничений с вашей стороны (вендора) и актуализировать артефакты.
В результате работы со стейкхолдерами от аналитиков ждут вербализацию и визуализацию идей — того, о чем думает топ-менеджмент, чего хотят или захотят заказчики и покупатели, чего не хватает в работе пользователям и что поэтому должно появиться на рынке. Я советую вначале сосредоточиться на трех вопросах — ЧТО, КОМУ и ЗАЧЕМ вы собираетесь предложить как концепцию ИТ-решения.
ЧТО — сформулируйте техническое название продукта, которое отразит его целевое назначение. Например, если речь о решении для автоматизации склада, вполне годится «система управления складскими операциями с товарно-материальными запасами». Это четко определяет отраслевую принадлежность и предметную область проекта. Имя бренда коллеги придумают потом (и, скорее всего, вас не спросят).
КОМУ — опишите группу целевых пользователей, тех, кто будет непосредственно взаимодействовать с вашим продуктом. Перечислите их ключевые интересы, в улучшении каких показателей ежедневных процессов они нуждаются, каков их образ идеального рабочего места, пространства, дня. Не фантазируйте без меры — можно опереться на опыт предыдущих проектов, аналоги и конкурентов, открытые данные о предметной области.
ЗАЧЕМ — отталкиваясь от представленных интересов и ожиданий целевой аудитории, укажите основные функциональные возможности продукта, на верхнем уровне без деталей. Это поможет очертить границы автоматизации и покажет полезность проектируемого решения.
Что если по итогу интервью ЗС нужно подготовить описание процесса с учетом оптимизации, но в нем много участников, шагов и промежуточных результатов? Не всегда графические модели — предел наглядности необходимого и достаточного. Часто лучшим ответом на вопрос выше будет текстовый регламент — спецификация бизнес-процесса, в которой показана суть происходящего, как оно должно стать. В такой спецификации следует описать алгоритм основного позитивного сценария — по шагам от лица всех акторов в прямой последовательности, кто, что и когда исполняет и кому передает результаты работы. При необходимости добавьте ветвления альтернатив — негативные сценарии, параллели, эскалации в случае просрочек и других нарушений.
Затем уже можно идти общаться с коммерсантами и техническими специалистами — коллеги помогут дополнить и скорректировать материалы, набросать эскизы концептуальной модели продукта, системной архитектуры, диаграммы прецедентов и прочих артефактов для наглядности, предоставят фактуру по рынку и стратегическим планам компании, расскажут про ваши ресурсные потенциалы и ограничения. По ходу дела не позволяйте заинтересованным сторонам игнорировать интересы своей организации — в конце концов, вы создаете благо не только для конкретных бенефициаров и топ-менеджеров, вы проектируете фундамент цифрового общества и его устойчивого развития.
