Системный аналитик – один из важнейших специалистов на проекте, он участвует в общении с заказчиком с самого начала проекта.
Вместе с заказчиком и менеджером аналитик определяет вид и логику будущего сайта или приложения. Его задача – переводить запросы и пожелания со стороны бизнеса в документацию для разработчиков.
На старте проекта аналитик формирует первичные требования, в ходе разработки – консультирует разработчиков, а на этапе поддержки – вписывает новые функции в готовый продукт так, чтобы не нарушить его логику.
Работа системного аналитика подобна составлению плана для строительства дома. Невозможно начать со спальни, а потом достраивать все остальное. Документация руководит работой различных специалистов, чтобы каждый этап соответствовал общей концепции. При приёмке работ сравнивается их выполнение с планом.
Предпроектное обследование (ППО) – это серия интервью, на основе которых формируется видение результата. На этом этапе системный аналитик — главное действующее лицо.
Он не просто задаёт клиенту вопросы о его задачах и пожеланиях к разработке, а проверяет полученные ответы на непротиворечивость, приоритизирует их и дополняет своими экспертными предложениями. Результатом этапа становится согласованный с заказчиком документ под названием Vision. Он содержит верхнеуровневое описание разделов и функций будущего продукта, их связей и контента, описание пользовательских ролей. Если на проекте задействовано несколько команд или систем, то ещё одна важная задача — очертить их границы ответственности.
Аналитик формирует Vision и задаёт вопросы заказчику:
Написание технических заданий (ТЗ): если на первом этапе главная задача – отделить существенное от несущественного и составить общий список разделов и функций, то дальше нужно детально описать каждый будущий экран, страницу и элемент.
В ТЗ может входить описание модели данных, ролевая модель, описание логики функционала. Аналитики могут писать обычным языком, но часто используют нотации – таблицы и схемы для наглядного отображения связей технически сложных объектов. Иногда они рисуют прототипы экранов, чтобы показать логику будущего продукта.
Идей бывает много, но в конечном ТЗ аналитик должен зафиксировать только утверждённое решение с заказчиком в таком виде, чтобы разработчику всё было ясно.
В процессе разработки всегда возникают вопросы и разночтения – это нормально. Именно аналитик валидирует получающиеся технические решения, проверяет их на соответствие исходному видению, а также помогает справиться с ситуациями, когда реальный мир оказался сложнее замысла: некоторый функционал приходится пересматривать и проектировать заново, искать альтернативы или уточнять детали.
Вернёмся к примеру с приложением для кофеен с программой лояльности. В процессе реализации некоторые методы отсутствовали, а другие работали иначе, чем ожидалось. Аналитик выявляет реальные возможности программы лояльности и предлагает альтернативные решения для достижения цели.
Иногда бывает нужно подготовить документацию по ГОСТу или, наоборот, написать инструкции на легко читаемом языке.
Еще одна задача – написать техническую документацию для разработчиков смежной команды, которые будут делать другую часть проекта.
Раздел с акциями в приложении для кофеен будет заполнять сотрудник через административную панель. Аналитик пишет инструкцию в текстовом или видео формате, а также можно организовать обучение. В случае госпроекта, где требуется соответствие ГОСТу, аналитик обеспечивает правильное оформление документации.
После первого запуска обычно идут следующие релизы: крупные раз в несколько месяцев или частые по 2-3 задачки.
Любые изменения на сайте требуют новой документации, ее надо аккуратно добавлять в ТЗ. Документы, написанные на предыдущих этапах, нужно систематически актуализировать.
Честно: нет, он нужен не всегда. Чем сложнее система, чем больше специалистов участвуют в разработке, чем более долгий срок работы ожидается от системы, тем важнее качественно проводить аналитику и обновлять документацию.
Можно обойтись без аналитика:
Если вам нужен несложный сайт – визитка, графика, красивый визуал без сложной логики, в том числе сайты на конструкторах;
Если нужен сайт посложнее, но буквально на пару месяцев, например, на период промоакции: тимлид и менеджер смогут быстрее сами сформулировать все требования. И можно не анализировать эффективность этих решений в долгосрочной перспективе, ведь поддержка не потребуется;
Если мы делаем только какую-то часть работ, например, только дизайн, по требованиям, которые у заказчика уже готовы.
В остальных случаях наши аналитики помогут сформировать четкие и непротиворечивые документы, с которыми разработчики будут сверяться, реализовывая функционал.
Вернёмся к сравнению системной аналитики с постройкой дома. Без детального плана можно смастерить декоративную беседку, но для объектов с инженерными сетями необходим чёткий план. Иначе строительство будет мучительным, а результатом невозможно пользоваться.
