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