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