Системная аналитика

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

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

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

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

(Какие виды работ выполняет системный аналитик?)

Предпроектное обследование

Написание технических заданий

Сопровождение разработки

Написание документации и инструкций

Актуализация ТЗ

(Предпроектное обследование)

Предпроектное обследование (ППО) – это серия интервью, на основе которых формируется видение результата. На этом этапе системный аналитик – главное действующее лицо.

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

Аналитик формирует Vision и задаёт вопросы заказчику:

регистрация по СМС, эл. почте или логин-пароль?
будет ли авторизация через социальные сети?
как у вас работает программа лояльности?
будем ли делать управление акциями и новинками через админ панель?

(Что будет, если пропустить этот этап?)

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

(Написание технических заданий)

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

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

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

(Что будет, если пропустить этот этап?)

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

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

(Сопровождение разработки)

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

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

(Что будет, если пропустить этот этап?)

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

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

(Написание документации и инструкций)

Иногда бывает нужно подготовить документацию по ГОСТу или, наоборот, написать инструкции на легко читаемом языке.

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

Раздел с акциями в приложении для кофеен будет заполнять сотрудник через административную панель. Аналитик пишет инструкцию в текстовом или видео формате, а также можно организовать обучение. В случае госпроекта, где требуется соответствие ГОСТу, аналитик обеспечивает правильное оформление документации.

(Что будет, если пропустить этот этап?)

Ничего :) Инструкции пишутся только по запросу заказчика.

(Актуализация ТЗ)

После первого запуска обычно идут следующие релизы: крупные раз в несколько месяцев или частые по 2-3 задачки.

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

(Что будет, если пропустить этот этап?)

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

Вместо того, чтобы открывать ТЗ и сразу делать выводы, им придется тратить время, чтобы разобраться в том, как работает система изнутри.

(Всегда ли нужен аналитик?)

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

Можно обойтись без аналитика:

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

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

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

Хотите связаться с владельцами компании напрямую?

Константин Франгуриди

Account director

НАПИСАТЬ

Дмитрий Тарасов

СЕО

НАПИСАТЬ