Небольшое интро

Привет! Меня зовут Аня, я работаю системным аналитиком в InfoWatch на продукте Device Monitor. Это система контроля утечек информации на рабочих станциях, позволяющая организации контролировать и блокировать вынос конфиденциальных данных за пределы ее безопасного контура.

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

Так появилась идея собрать список вредных советов, с помощью которого вы точно сможете помочь вашему системному аналитику выгореть побыстрее и потерять веру в людей. Закончим мы, понятное дело, подборкой хороших практик, ну а пока…

Disclaimer — ещё разок отмечу, что речь именно о вредных советах, а не о руководстве к действию. Более того, в описании хороших практик в конце статьи тоже есть нюансы, и не всё так однозначно, так что приглашаю всех заинтересованных в комменты, подискутировать.

Вредные советы

#1 Аналитик — он и в Африке аналитик

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

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

#2 — «Да тут дел на пять минут»

Пользовательская документация сама себя не напишет. Нет технического писателя? Технический писатель не знает, что писать, а плоды труда в виде описания задач, требований, стендов и тест-кейсов слишком трудно и долго читать или смотреть? Так пусть напишет системный аналитик! Ему точно не сложно, он уже в теме.

#3 — Проектируем и анализируем

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

Но если вы мыслите нестандартно и у вас в команде есть системный аналитик…
В общем, вы поняли.

#4 — Продакт сам не вывезет

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

Может ли это делать системный аналитик? Конечно же.

Лучшие практики

Ладно, а теперь серьёзно. Вот что помогает не скатиться в ситуацию, когда ваш системный аналитик медленно, но верно превращается в человека-оркестра и начинает активно мониторить hh.

Чёткие границы рабочих обязанностей

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

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

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

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

Отдельно остановлюсь на истории с техническими писателями. Если технический писатель время от времени уточняет моменты, которые можно двояко трактовать в требованиях (или если они вообще не описаны) — это вполне себе нормально. А вот если технического писателя нет вообще и эту роль берёт на себя аналитик — это совсем другая история. Отчасти будет похоже на отсутствие бизнес-аналитика — чем шире круг обязанностей, тем ниже скорость выполняемых работ и их качество.

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

Это если говорить о нездоровой ситуации.

Как надо

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

Довольно продуктивный и, на мой взгляд, достойный называться каноничным, подход используется у нас сейчас. Тут взаимодействие аналитика с коллегами организовали вот так:

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

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

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

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

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

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

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

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

Что в итоге

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

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

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

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