И вот прошло плюс+минус три года, как я работаю в «выделенной» роли системного аналитика. «Выделенной» – в кавычках, потому что я всегда был убежден, что разделение труда – наше все.

Но все мы взрослеем, и картина мира меняется. Появляется насмотренность, становишься более гибким, кругозор расширяется, и, как следствие, парадигма сдвигается или вовсе трансформируется.

Желание поразмышлять на тему необходимости системного аналитика, возникло когда критический вес «убежденности происходящего из собственного опыта» пополнился звеном работы в продуктовой команде, а соблазн отрефлексировать все это дело с точки зрения проектного управления (за плечами три года заказной разработки в роли ПМ-а) не дает покоя и требует выхода на бумагу.

Делая отсылку к своему менеджерскому опыту, я могу сравнивать роль системного аналитика в разных методологиях управления проектом/продуктом, а это ой как важно при ответе на вопрос: «Нужен ли системный аналитик?».

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

Размышления я разложил на три плоскости. Очередность – формальная. По факту порядок может быть любой.

Плоскость №1. Плюсы и минусы

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

Плоскость №2. А как вообще бывает?

Мне удалось побыть аналитиком в разных компаниях и разных командах. Где-то это была каскадная модель – «ждем», когда коллеги сделают. Где-то был гибрид – я называю это «аджайл внутри водопада». Где-то стремительный аджайл – правки «наживую» за два часа до релиза.

В таком разнообразии можно ощутить все горести и радости бытия аналитика. Это подтвердило существование такого тезиса-опции: «Умный аналитик – глупый разработчик или глупый аналитик – умный разработчик».

Формулировку и некоторые поинты я взял из статьи коллеги (разрешение согласовал) – уж очень емко сказано. Но немного переформулировал. Если упоминается «умный» или «глупый», речь не про когнитивные способности, а про глубину контекста и погружение в реализацию решения.

Глупый аналитик, умный разработчик

Аналитик не участвует в синтезе решения, а отвечает только за функциональные требования.

Проблемы

• Низкая проработка требований. Если аналитик пишет только функциональные требования, это не всегда плохо. Для команды с высокой погруженностью в предметную область, часто функциональных требований будет достаточно, чтобы понять, что система должна делать. Но это в том случае, если речь идет про внутреннюю архитектуру. Если же требуется синтезировать решение для межсистемных интеграций, например «система А, передает данные в систему Б, через прослойку X», то функциональных требований будет недостаточно. Возникают справедливые вопросы: «А какие данные передавать, как часто, в каком формате и где, собственно, сформированный интеграционный контракт?». В этом случае разработчик идет самостоятельно выяснять, «Что? Где? Когда?», и что самое неприятное – распространять это знание на команду. То есть «удержание контекста» и «управляемость смыслами» уходит на сторону разработчика, а не аналитика;

• Аналитик не растет. Без участия в синтезе решений, аналитик просто не понимает, как система работает. То есть осуществить приемку функциональности может в двух режимах: требования выполняются, требования не выполняются.
  К чему это приводит. Аналитик не знает, насколько сложно или просто выполняется требование. Не обрастает архитектурно-технической насмотренностью. И на будущих сессиях с экспертами и заинтересованными лицами не сможет предложить менее безумное и более элегантное решение, которые будет быстрее и дешевле для бизнеса;

• Низкое качество тестирования, образование «горлышек» на этапе отладки. Для тестировщика важно получить спецификацию такого уровня детализации, чтобы можно было понять, как работает функциональность и как эту функциональность правильно протестировать. То есть спецификация должна отвечать на вопросы: «что система делает и как система выполняет это «деланье»», то есть как она работает. Если ответ только на первый вопрос, то тестировщик должен самостоятельно пойти к разработчикам и разобраться. А как мы помним, «разбор» – это зона ответственности аналитика.

Умный аналитик, глупый разработчик

Аналитик закрывает роль всевозможных архитекторов. То, что аналитику никогда не стать компетентным архитектором, будет отдельная статья. Скажу лишь, что вся эта «движуха» с системным дизайном – только на бумаге. По факту решение разрабатывается коллегиально, и никто в здравом уме не допустит аналитика к «придумыванию» архитектуры в одиночку.

Все что будет ниже, это крайности. Но их познал я на себе. Более того, разговаривая с коллегами, оказалось, что я не один такой. На мой прямой вопрос, «а как ты понимаешь, что это правильно?», я получил ответ: «а я каждый раз не знаю, как правильно».

Проблемы

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

• Избыточность проработки ради «красивой» документации. Еще одна мысль, которую я позаимствовал у коллеги. Хорошо, когда техническое задание и спецификация в одинаковом объеме и глубине описывают функциональные блоки. Тот, кто будет читать такие документы, быстрее погрузится в контекст. Но такой подход часто затягивает аналитика в описание всего, что только можно:

  • SQL-запросы к БД, хотя в проекте есть ORM. И давайте будем честны, аналитик должен знать, как найти нужные данные в табличках. Это нужно при отладки багов или, если просят загрузить какую-нибудь статистику. Но как экстрактить эти данные, чтобы написать фичу – обязанность разработчика. Аналитик никогда не сможет это сделать в нужном качестве;

  • описание алгоритмов для базовых функций. Например, расписывать, как работает пагинация или дата-пикер на UI. Чаще всего для этого уже есть написанный метод или компонент во фреймворке;

  • порядок парсинга какой-нибудь эксель таблицы для загрузки данных куда-нибудь.

• Дороговизна поддержания документации. В случае, если требования меняется, а причин этому может быть множество, то поддержка документации в актуальном состоянии – задача не самая дешевая. Я уже молчу про вовлеченность исполнения такой задачи. В случае глобальных изменений ландшафта бизнеса может возникнуть потребность изменить архитектуру приложения, язык или фреймверк. Документация, близкая к «кодовой базе», просто потеряет свою актуальность;

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

Я не планировал подводить итоги для каждой из плоскостей. Но ценные замечания коллеги с соседного продукта перевесили. Буду цитировать небольшими изменениями:

«Cистемный аналитик это сервисная роль. Некий переводчик или курьер или журналист. Формат и результат его работы – формируется общекомандно и сильно зависит от требований непосредственных исполнителей. Полностью согласен, что аналитик сам код не пишет и не имеет компетенции. Так что исполнители вправе требовать формат той документации которая им нужна для реализации. Аналитик не должен решать, какой формат будет на проекте, чтобы не биться в стену со своей реализацией, мешая всем. Либо поставляя недостаточную документацию, чтобы разрабы сами сидели и думали что надо сделать бизнесу. Сама суть сервисной роли противоречит этому. Общей консенсус, с командой исполнителей их участие в согласовании формата работы аналитика это обязательный фактор».

Если упроситить. То нужно пойти к команде и спросить: «Уважаемые господа и сэры, а как вам будет удобнее?».

Плоскость №3. Зрелость бизнеса

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

Когда я говорю «мы», то речь идет про продукт/проект и всех тех людей, которые непосредственно будут участвовать в разработке.

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

Если очень утрировать, то:

• ландшафт быстро меняется – гибкая методология;

• ландшафт условно-статичный, стагнирующий – линейная.

Оптимизационные и гибридные методологии – опционально-ситуационные.

Что мы имеем: рынок диктует скорость, бизнес диктует методологию, методология диктует конфигурацию команды.

И вот мы добрались до вопроса: «А в нашей конфигурации есть место для системного аналитика? Или его роль может взять кто-то другой?».

Если бизнес задается такими вопросами, то «шансы есть». В этом случае бизнес способен:

• понять какова степень неопределенности на проекте/продукте и какая нужна степень предсказуемости;

• чувствовать насколько команда вовлечена. Назовите это «степенью продуктовости». То есть насколько специалисты готовы тратить время не на профильную деятельность;

• смотреть на команду, как на комплексный механизм. Выявить тех, кто сможет или уже:

  • выявляет требования, описывает сценарии, готовит спецификации;

  • модерирует циркуляцию знаний и удерживает контекст предметной области;

  • проектирует контракты и формирует логику хранения данных;

  • придумывает интерфейсы;

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

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

По итогу, системный аналитик нужен?

В моем представлении, чтобы ответить на этот вопрос, требуется пройтись по всем трем плоскостям в любом порядке, перескакивая, и собрать чек-лист за и против.

Плоскость №1

Если вы готовы мириться с минусами, а профит от плюсов потенциально высокий, смело ставьте – «за». В противном случае попробуйте распылить обязанности на другие роли.

Плоскость №2

Если вы способны удерживать баланс между «умом» и «глупостью» либо же способны нанять такого специалиста, то смело ставьте – «за». Иначе аналитик превращается в имитацию и впитывает в себя: владельца продукта, менеджера проекта, скрам-мастера, архитектора, техписа.

Плоскость №3

Если вы зрелы, то должно хватить опыта, чтобы трезво оценить текущую ситуацию и выбрать нужную методологию, а значит – собрать нужную конфигурацию. Если в этой конфигурации находится место для аналитика – «за». Если же команда эффективно поставляет продукт/закрывает задачи без аналитика, то его роль уже распределена и стоит подумать над тем, ломать ли текущую конструкцию или нет.