Цель статьи — помочь понять, нужен ли вам на проекте системный аналитик или нет.
А также предостеречь тех, кто только собирается стать системным аналитиком.

Последние восемь лет я работаю системным аналитиком и до сих пор не перестаю удивляться тому, насколько противоположные мнения об этой роли встречаются даже среди опытных специалистов. Ещё в далёком 2008 году был доклад на близкую тему — «Аналитик в Agile: архаизм или необходимость?». С тех пор прошло семнадцать лет, а ситуация принципиально не изменилась — тема по-прежнему вызывает ожесточённые споры.

Точки зрения кардинально различаются:

Многие вопросы о необходимости СА упираются в извечное «это зависит». Однако есть то, что, на мой взгляд, действительно критично — это ключевая компетенция.

Нередко звучит обоснованная претензия, что роль остаётся слишком размытой и специалисты на данной позиции часто оказываются не готовы к тем задачам, которые на них возлагаются, — у многих нет достаточных навыков ни в предметной области, ни в проектировании, ни в глубоком техническом взаимодействии. А тот небольшой процентов «универсалов», которые «могут» очень редко встречаются на рынке. Чтобы стать таким специалистом, нужно накапливать опыт в нескольких направлениях одновременно и постоянно учиться, — а это под силу далеко не каждому.

За последние годы фокус профессии сместился из области анализа в область проектирования. Достаточно открыть несколько вакансий, или поискать в интернете матрицу компетенций одной из крупных компаний. Данную проблему уже не раз затрагивали в статьях Хабр. Однако я хотел бы взглянуть на неё под другим углом и ответить на вопрос: почему так происходит?

Agile процессы и сроки

В таких подходах как Waterfall или RUP, работы по «проектированию» были выделены в отдельный этап (требования — проектирование — разработка) и было очевидно, в какой момент и кто занимается проектированием. Вот например как пишет об этом Крэг Ларман в своей книге Шаблоны проектирования и UML 2.0 в контексте применения подхода RUP.

В течении первых двух дней разработчики и другие специалисты должны попарно заниматься моделированием и проектированием, строить диаграммы UML на доске или с использованием других средств. Как правило вся эта деятельность выполняется в общей комнате под руководством главного архитектора.

В Agile далеко не всегда очевидно в какой момент происходит проектирование. Работы могут быть распределены так:

С учётом того, что нам нужно дать точную оценку в рамках короткой двух-недельной итерации, то мы стремимся все фактические работы по проектированию, которые связаны с неопределённостью сдвинуть как можно дальше влево. Намного легче оценить время реализации функции (отображение проектного решения в код), чем оценить время на проектирование новой функции. Под этапом «Разработка» в последнее время часто понимается буквальное написание кода. И фактическое распределение работ по проектированию во времени, всё чаще выглядит так:

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

Детальное проектирование — трудоёмкий этап

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

Детальное проектирование это про генерацию микро-идей и про их синхронизацию между всеми участниками процесса

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

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

Детали оказывают непропорциональное влияние на успех продукта

В цифровой среде цена одной непродуманной детали может оказаться непропорционально высокой: потерянные заказы из-за сбоя в веб-форме; потерянные деньги при расчётах в транзакции; массовая паника, вызванная ошибочным push-уведомлением. То, что кажется мелочью, может разрушить всю систему — и продукт в целом. Таких примеров немало. Один из самых известных — инцидент с межпланетной станцией Mars Climate Orbiter, которая сгорела в атмосфере из-за простой несогласованности: одна команда инженеров использовала британские единицы измерения (фунты силы), а другая — метрические (ньютоны). И этого никто не учёл.

Место системного аналитика среди других ролей

Распространённые ошибки при встраивании СА в процесс разработки:

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

• Из за наличия СА на проекте, команда не участвует в детальном проектировании, не погружается в предметную область и ждёт готовой постановки. Обратная крайность, когда СА не продумывает детали реализации: не видит узких мест, пограничных кейсов, альтернатив, полагаясь на то, что команда сама со всем разберётся. Процесс проектирования должен быть итеративным с рассмотрением альтернатив всей командой.

Выводы

Прежде чем включать СА в процесс разработки, необходимо:

• Определить необходимую степень предсказуемости на вашем проекте. Возможно, более разумный подход — выпускать релизы как можно чаще, опираясь на текущее, пусть и «сырое» понимание будущей системы. Иногда это лучше чем застревание в попытках предусмотреть всё заранее, впадая в аналитический паралич, бесконечные обсуждения и продумывание идеального варианта реализации.

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

• Определить степень вовлечённости участников команды и их готовность тратить значительное количество времени не на код.

• Посмотреть на команду комплексно, — как на систему. Определить, кто из участников команды:

  • Выявляет, анализирует и согласует требования.

  • Декомпозирует требования в задачи для разработки и формализует их в виде схем, сценариев, спецификаций. На основании каких данных проводится тестирование?

  • Описывает модель предметной области. Удерживает контекст и все ключевые связи системы. Продумывает логику пользовательских процессов в вашей системе.

  • Проектирует API, структуру хранения данных, интерфейсы.   

  • Занимается сопровождением системы и обучением пользователей.

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