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

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

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

Не менее важным инструментом становится моделирование бизнес-процессов с использованием нотаций BPMN или EPC. Визуализируя процессы в состояниях "как есть" и "как будет", системный аналитик может выявить истинные узкие места процесса. Это позволяет в идеальных случаях оптимизировать его еще до начала проектирования системы, либо, чаще, опять же уточнить требования найдя в процессе "черные ящики", недоописанные функциональности. В результате это ведет к созданию более детализированных и полезных технических требований. Мы ведь не хотим попасть в ловушку автоматизации хаоса, верно?)

Использование подобных техник не из явного инструментария системного аналитика также играет вот какую роль. Как мы помним, после сбора требований задача аналитика - их верификация. А кто является источником требований? Владелец продукта? Бизнес-оунер процесса? Конечный исполнитель? К чему веду - залетевшие в нас требования всегда имеют искажение угла зрения. И как нам верифицировать хотелки продуктовика? Он то видел под фичей инструмент корректировки определенных значений продуктовых метрик. В итоге нам надо и его логику проверить и критически к ней подойти, взглянув на его видение со стороны, к примеру, конечного исполнителя, чья часть исполнения процесса, к примеру, может пострадать. Ибо симплификация, к примеру, фронтовых форм для клиента может потребовать лишних действий оператора "по ту сторону" процесса. Продолжим, как раз зацепили угол зрения продуктовика.

Подходы к формулированию требований можно также расширить - да, мы расписываем классические пользовательские истории, но Customer journey map, пришедшая из продуктового управления вновь расширяет наше видение. Такая техника помогают сместить фокус с формального списка действий на потребности пользователя. Польза для системного аналитика здесь заключается в способности создавать ценные фичи, отсекая маловажные "хотелки" и концентрируясь на решении конкретных задач.

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

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