Работа системного аналитика | Рассказы PRO
Системный аналитик – связующее звено между командой разработчиков и заказчиком. О нюансах работы системного анализа мы пообщались с системным аналитиком Centicore Group Елчином Меликовым.
-Что входит в обязанности системного аналитика в Centicore Group?
– Все зависит от проекта, команды и разделения ответственности внутри команды. Необязательно работа системного аналитика только системный анализ – он вполне может совмещать его с бизнес-анализом.
Если обобщить, системный аналитик в Centicore Group выполняет сбор требований, их анализ и систематизацию, далее уже технический ресерч, проектирование, написание спецификаций разработчикам.
В некоторых проектах аналитик может выступать как feature owner и ответственен за сопровождение фичи от момента выявления потребности до вывода в прод, не уходя при этом в проектный менеджмент.
-Какими техниками выявления требований к продукту ты пользуешься? Почему?
– Обычно я интервьюирую пользователей и иных заинтересованных лиц, изучаю существующую документацию, занимаюсь прототипированием, моделированием.
Но тут опять же все зависит от заказчика – какие бы техники и инструменты не использовались, самое основное – достичь того уровня, чтобы ты с заказчиком могли говорить “на одном языке”. Каким-то заказчикам проще понять вашу мысль, изучая прототип интерфейса, кому-то проще разобраться, изучив схему бизнес-процесса – все очень индивидуально и необходимо находить свой подход к каждому заказчику.
-Какие методики ты используешь для системного анализа? Почему выбираешь определенные методики для разных проектов?
– Скорее, методика больше зависит даже не от проекта, а от типа задачи.
Если это какая-то сложная архитектурная задача, то вполне может быть применен и brainstorm с командой разработки. Если разбираешь дефект, то в зависимости от влияния дефекта на систему тоже могут быть вариации исследования – замеры метрик, дебаггинг и т.д.
Но если взять классическую задачу на создание какой-то фичи, то, при условии, что с требованиями разобрались, то мои действия следующие: ресерч (системы или части системы; API смежной системы, например, в т.ч. “потыкать его”); фиксация того, что наресерчил; прототипирование; проектирование (иногда с мозговым штурмом); валидация с разработчиками; декомпозиция фичи на таски и написание подробных спецификаций для разработки.
-Может и должен ли системный аналитик заниматься проектированием графического интерфейса пользователя? В каких проектах, для чего и в каком объеме это необходимо?
– Считаю, что может, но не могу сказать, что должен.
Основная задача при создании прототипов интерфейса, вне зависимости от проекта – показать пользователю функциональность системы, возможно, какой-то атрибутивный состав, а не расположение кнопок и прочих элементов. После создания прототипа интерфейса необходимо, по моему личному мнению, обратиться к UI/UX специалистам для более тщательной проработки юзабилити. Порой они могут придумать (или уже знают) крутые решения, о которых ты даже подумать не мог.
-Какой подход к управлению проектами тебе ближе: классический или Agile? Почему? Зависит ли выбор подхода от проекта и каким образом?
– Ближе Agile, как ни странно, в силу своей гибкости.
Я бы применял Agile для проектов, для которых возможна итеративная разработка и такая же демонстрация value заказчику, а также для проектов, в которых не исключается право на ошибку.
Например, я бы использовал Agile в продуктовой разработке, но не использовал бы в ракетостроении и прочих околонаучных дорогостоящих областях.
-Как оценить эффективность работы системного аналитика?
– Эффективный системный аналитик – аналитик, который удовлетворил и заказчика, и разработчиков. То есть проработал задачу и спроектировал все так, что и принес ожидаемый value заказчику. При этом не растратил много ресурсов команды разработчиков и не создал техдолг.
