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

Такая градация помогает мне определить подход взаимодействия со специалистом. А также позволяет спрогнозировать, каких результатов от этого сотрудника можно ожидать.

Эта статья будет интересна системным аналитикам и участникам команд разработки. А если среди ваших коллег есть люди, подходящие под моё описание, то, возможно, вы будете понимать их чуточку лучше.

Но до того, как перейти к классификации, давайте обозначим, кто такой системный аналитик, за что он отвечает и какие навыки для него самые важные.

Безусловно, системный аналитик – специалист широкого профиля. Он отвечает за сбор требований к Системе, занимается проектированием технического решения, ставит задачи команде разработки, поддерживает задачи на всем жизненном цикле. Часто выполняет менеджерские функции: организовывает коммуникации в команде, фасилитирует встречи, поднимает острые вопросы и принимает важные решения.

Основа моей классификации – 5 ключевых навыков, по развитию которых и можно определить тип системного аналитика:

1. ПРЕДМЕТНАЯ ОБЛАСТЬ.
   Умение оперативно погрузиться в предметную область.

2. ПОТРЕБНОСТЬ.
   Умение проводить эффективное интервью по сбору требований, правильно формулировать вопросы и выявлять ключевую потребность Заказчика.

3. СИСТЕМНЫЙ АНАЛИЗ.
   Умение понимать принципы построения систем, уметь трансформировать бизнес-требования в функциональные и нефункциональные требования, быть способным генерировать новые решения, использовать различные инструменты для систематизации требований.

4. ТЕХНИЧЕСКОЕ ЗАДАНИЕ.
   Умение описывать требования в виде конечных, логически правильно выстроенных предусловий, понятных и однозначно трактуемых всеми, кто однажды откроет ваше ТЗ; использовать общепринятые методологии/регламенты описания требований.

5. КОММУНИКАЦИИ.
   Умение работать в команде, коммуницировать с различными заинтересованными сторонами, с бизнес-пользователями, умение проводить встречи и подводить их итоги.

Теперь переходим к самой классификации.

Итак, первый тип ???? Аналитик-техпис ????

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

1. ПРЕДМЕТНАЯ ОБЛАСТЬ.
   Не будет глубоко погружаться в предметную область, максимум поищет в общем пространстве какую-то сопутствующую информацию.

2. ПОТРЕБНОСТЬ.
   Не будет пытаться выяснять какие-то тонкие моменты у Заказчика, разбираться в чём истинная цель данной доработки.

3. СИСТЕМНЫЙ АНАЛИЗ.
   Не станет анализировать возможность иной реализации, предлагать новые решения. Не будет проверять все возможные зависимости с другими объектами Системы.

4. ТЕХНИЧЕСКОЕ ЗАДАНИЕ.
   Техническое задание напишет правильно. Опишет требования, оформит по установленному регламенту, внесет своевременно правки.

5. КОММУНИКАЦИИ.
   Коммуницировать будет по острой необходимости. На встречах не будет проявлять инициативу, в основном предпочтет письменный способ общения.

Результат работы такого аналитика всплывает, как правило, после выхода задачи на прод.

Возможные причины недовольства Заказчика:
???? Ожидаемый результат не соответствует реализации.
???? Допустили серьезные ошибки, не реализовали необходимые контроли.
???? Процесс работы стал затруднен и требует дополнительных действий.

Потенциальные вопросы от ИТ подразделения и команд разработки:
???? Почему использовали именно такой подход к реализации, когда есть более простой путь?
???? Зачем создавали новые атрибуты/поля/объекты, ведь можно было использовать уже имеющиеся?
???? Почему не учли конфликты с другими объектами Системы?
???? Почему реализовали через «местный костыль», не проработали фундаментально-универсальное решение?

Второй тип ???? Аналитик-пофигист ????

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

1. ПРЕДМЕТНАЯ ОБЛАСТЬ.
   Погрузится настолько, насколько посчитает достаточным. Изучит внутренние процессы Заказчика.

2. ПОТРЕБНОСТЬ.
   Выявит ключевую потребность Заказчика. Проведёт не одно интервью по сбору требований. Подключит дополнительные экспертизы.

3. СИСТЕМНЫЙ АНАЛИЗ.
   Понимает принципы построения Систем. Проведет анализ взаимосвязи с другими объектами Системы. Предложит новые решения и подходы, оптимизирующие работу сотрудников Заказчика. Проанализирует необходимость в дополнительных контролях.

4. ТЕХНИЧЕСКОЕ ЗАДАНИЕ.
   К оформлению технического задания отнесётся недобросовестно. ТЗ напишет верхнеуровнево с выделением основных требований. Все подробности проговорит и зафиксирует устно на встречах или в корпоративной переписке. Не будет утруждать себя в детальном описании кейсов и условий, не будет своевременно вносить изменения и уведомлять об этих изменениях коллег по команде.

5. КОММУНИКАЦИИ.
   Очень активен. Коммуницировать будет часто и со всеми заинтересованными лицами. На встречи приходит с готовыми предложениями и решениями, зачастую чрезмерно настаивает на своей идее.

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

Примерные вопросы Заказчика на этапе согласования технического задания (если у вас есть этот этап, и Заказчик умеет читать требования):
???? Мы проговаривали определенное поведение Системы, не нашёл ничего об этом в ТЗ.
???? Часть требований, которые я заявлял, не описаны.
???? Не готов согласовать в таком виде, так как некоторые условия не описаны и/или нет понимания процесса в целом.

Вероятные причины недовольства Заказчика после реализации (когда нет этапа согласования или Заказчик не умеет читать требования):
???? Поле/раздел/процесс работают не так, как мы ожидали.

Вероятные причины недовольства от своей команды (тестировщик):
???? Реализация не соответствует требованиям ТЗ.
???? Требования прописаны верхнеуровнево, трактуются неоднозначно.
???? Не могу писать тест-кейсы, так как не пониманию поведение Системы на каждом шаге.

Вероятные причины недовольства ИТ подразделения, команд разработки, сотрудников техподдержки:
???? На проде блокирующая ошибка, в ТЗ нет описания по этому пункту. Как пропустили при тестировании?
⛔ Сотрудники техподдержки при поступлении обращения не могут понять по ТЗ ошибка у пользователя или нет.
⛔ Коллеги аналитики из других команд, работая над анализом новых требований, не могут найти актуальное подробное описание работы данного функционала.

Если в вашем окружении есть такие специалисты как «техпис» и «пофигист», задайте им при встрече эти вопросы:
???? Что мешало провести более глубокий анализ?
???? Что мешало написать ТЗ согласно регламенту?
???? Какие трудности возникли в процессе?

А вот и ТОП-7 самых распространённых ответов, которые вы получите:

1. Ничего не мешало (нет явных причин и аргументов);

2. Не знал, как писать ТЗ, никто не подсказал как правильно;

3. Не знал к кому обратиться, где найти информацию;

4. Не подумал, что задача окажется такой многосложной;

5. Не хватило времени на оформление, были установлены сжатые сроки;

6. Отвлекся, так как перекинули на другую задачу, которая была приоритетней;

7. Не вижу необходимости в этом, ведь все проговорили и решили на встречах/созвонах.

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

Третий тип ???? Аналитик-профи ????

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

1. ПРЕДМЕТНАЯ ОБЛАСТЬ.
   Погрузится настолько, насколько это будет возможно. Изучит внутренние процессы Заказчика.

2. ПОТРЕБНОСТЬ.
   Выявит ключевую потребность Заказчика. Проведет не одно интервью по сбору требований. Задаст правильные вопросы. Подключит дополнительные экспертизы.

3. СИСТЕМНЫЙ АНАЛИЗ.
   Понимает принципы построения Систем. Умеет трансформировать бизнес-требования в функциональные и нефункциональные требования. Проведёт анализ взаимосвязи с другими объектами Системы. Предложит новые решения и подходы, оптимизирующие работу сотрудников Заказчика. Проанализирует необходимость в дополнительных контролях.

4. ТЕХНИЧЕСКОЕ ЗАДАНИЕ.
   Техническое задание напишет правильно, оформит по установленному регламенту, внесёт своевременно правки. Требования опишет в виде конечных, логически правильно выстроенных предусловий.

5. КОММУНИКАЦИИ.
   Очень активен. Умеет работать в команде. Коммуницировать будет часто и со всеми заинтересованными пользователями. На встречи приходит с готовыми предложениями и решениями. Умеет подводить итоги и оформлять протоколы встреч.

Бывают ли вопросы к такому специалисту? Конечно бывают. Нельзя сказать, что аналитик-профи совсем не допускает ошибок. Увы, допускает. Результат его работы также может быть раскритикован. Но в большинстве случаев, к работе данного специалиста всё же нареканий не возникает.

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