Аналитика на госпроектах – это не страшно
Как часто вам приходилось слышать на собеседованиях, что аналитики-кандидаты отказывают вашему проекту из-за нежелания работать в государственном секторе, так как считают, что бюрократия будет сильно мешать работе, их развитию, выпуску качественного продукта?
Сегодня я хотел бы поделиться с вами нашим опытом, подчеркнув, что работа аналитиком на государственных проектах не так страшна, как может показаться. Меня зовут Георгий Доделия, и я руковожу международными ИТ-проектами в компании АО «ГНИВЦ», работаю в отрасли ИТ уже более 12 лет. Начинал как бизнес-аналитик, потом проникся системным анализом, а уже после ушел в проектный менеджмент.
Небольшая справка о компании АО «ГНИВЦ»: существуем на рынке более 46 лет, штат сотрудников превышает 1700 человек, мы представлены в 8 городах Российской Федерации. Наши продукты вам хорошо известны: это и мобильные приложения для разных типов налогоплательщиков (например, личный кабинет индивидуальных предпринимателей, физических лиц) самозанятых», платформа для проверки чеков, проект реестра ЗАГС и т.п. Также в нашем ведении набор систем для внутренних нужд Федеральной налоговой службы России.
Представление нашего опыта хочется начать с введения в контекст — подробно расскажем об условиях, в которых мы начинали.
Первое условие — это закрытие всех офисов на карантин из-за пандемии, которая заставила работать удаленно, что создало ряд проблем, например: взаимодействие с непроверенными инструментами, работу по старым процессам, сложности с формированием и оснащением команды.
Второе — международный проект, который подразумевает взаимодействие с иностранным государством. Необходимо было налаживать коммуникации с коллегами из налоговых органов другой страны, а это было непросто по одной простой причине: вас не знают, с вами не знакомы — отсюда проблемы с доступом, с вами не поделятся информацией и так далее, так как вы для них — «варяги».
Третье — нужен быстрый старт разработки в связи с тем, что до пандемии был заключен Госконтракт.
Четвертое — у заказчика выстроена жесткая иерархия. Вам не то чтобы требования не предоставят, с вами курить не пойдут, если не получено разрешение сверху.
Пятое — достаточно устаревшие ИТ-процессы у заказчика. Например, отсутствуют роли: аналитик, тестировщик, руководители проектов. Я уж не говорю про DevOps. Разработчик поднимается «наверх» к своему руководителю (представитель «бизнеса»), получает от него задачу и идет ее реализовывать. Через неделю у него уже новая задача и так далее. Добавим, что присутствует только dev-стенд и промышленный. А разрабатывают коллеги только OLTP-системы. В рамках своего же проекта мы столкнулись с проблемой, что аналитическую систему по нахождению (обнаружению?) нарушителей налоговой дисциплины сложно построить по одной простой причине — достаточно низкое качество данных (из-за плохой проработки бизнес-требований к системе, коллеги постоянно ее дорабатывают и генерят уйму «костылей»).
Шестое условие касается внутренней проблемы для России, с которой мы столкнулись при найме — это большой бум на IT в среде «неайтишников». Представим себе коллегу из бизнеса, который сделал две небольшие постановки для разработчиков, посетил пару тренингов, написал красивое резюме и претендует на роль аналитика с высокими зарплатными ожиданиями. Нам пришлось потратить огромное количество времени на фильтрацию таких кандидатов.
С чего же мы начали? С проведения череды встреч между лидами аналитики, разработки, тестирования и руководителем проекта. Мы обсудили ожидания каждой из ролей от результатов работ другой роли, в каком виде этот результат требуется предоставить.
По окончании серии встреч мы сформировали требования к команде аналитики. Делимся.
Во-первых, наш аналитик должен обладать знаниями в бизнес-анализе. Мы всегда в контракт добавляем этап изучения процессов той автоматизации, которую мы внедряем, чтобы не заниматься автоматизацией хаоса.
Во-вторых, у аналитика должны быть архитектурные навыки. Для понимания, что находится «под капотом» программно-аппаратного комплекса заказчика, мы проводим технический аудит. Аналитики чаще занимаются формализацией процессов, которые выстроены в IT-подразделениях нашего заказчика, и помогают в коммуникации и организации проведения аудита по всем остальным направлениям инфраструктуры и безопасности.
Также аналитик должен обладать знаниями в системном анализе. Бонусом являются знания гибких методологий, знания нотации BPMN, умение моделирования моделей данных, знания use-case и user-story (далее — UC и US соответственно) и интеграционного взаимодействия. Но как вы понимаете, список может быть бесконечным, а специалиста нам следует найти в сжатые сроки, поэтому любая комбинация дополнительных навыков нас устраивала, остальному мы готовы были обучать.
Следующие договоренности лидов были в отношении рабочих объектов. Мы их назвали «рабочие элементы Jira». Всю разработку разбили по бизнес-смыслу на эпики, которые декомпозировали на «стори». А для четкого понимания прогресса по реализации той или иной «стори» приняли решение заводить sub-task для каждой из ролей. Во время работ могут появляться задачи, которые напрямую с бизнес-фичей не связаны, под них следует заводить просто task. Например, подготовка к презентации, написание ПМИ, работа с новой библиотекой. Также у команды тестирования готовятся тест-кейсы и тест-планы. Дополнительно мы заводим дефекты.
После всего этого у нас выстроился следующий производственный процесс.
Но сначала про состав ролей продуктовой команды:
· группа методологии, это бывшие сотрудники Центрального аппарата Федеральной налоговой службы России, которые перешли в АО «ГНИВЦ» и обучались на курсах продуктологов;
· аналитики: как бизнес-ориентированные, так и системно-ориентированные.
· группа разработки, состоящая из frontend, сервисного слоя и уровня данных (в своей работе мы используем подход с «озером данных»);
· команды тестировщиков (мануальных, автоматизаторов и нагрузчиков).
За базу в процессе взяты Kanban-принципы, визуализация осуществляется через Kanban-доску.
Шаг 1 — наполнение Backlog-а. Backlog формируется командой методологии. Коллеги пишут «стори» (я как… хочу… чтобы…), дополненные критериями приемки. С определенной периодичностью проводится Backlog-grooming, в котором участвуют все члены команды или представители от каждой роли, уточняются ожидания, критерии приемки, тем самым «сторя» дописывается.
Шаг 2 — планирование задач. «Сторе» присваивается тот или иной приоритет, и она попадает в колонку «Запланировано».
Шаг 3. Из колонки запланированных задачи берутся в работу аналитиками. Аналитик начинает сбор требований, проектирование. После полной готовности сбора и проектирования, он передает свою постановку на внутреннее ревью команде аналитиков и команде методологии. Так мы поддерживаем принцип V&V — Validation and Verification.
Шаг 4. Если задача прошла ревью, она уходит в колонку «Анализ готово». При этом она должна удовлетворять требованиям Definition of Ready. Это набор критериев, которым должна удовлетворять любая постановка, чтобы считаться готовой. Например, среди постановок должен быть сценарий демонстрации, а также скорректированный с учетом работы аналитика набор критериев приемки.
Шаг 5 — разработка кода. Когда команда разработки заявляет о свободных ресурсах, назначается «стори-ревью», на котором аналитик защищает свою постановку перед командой разработки и тестирования. Задача уходит в разработку, декомпозируется, и происходит колдовство написания кода. Чтобы перевести задачу из «Разработки» в «Разработка готово», она должна удовлетворять требованиям готовности команды разработки — Definition of Done.
На этапе «Разработка» к работам подключается команда тестирования, которая формирует тестовые данные и тестовый дизайн.
Шаг 6. Задача переводится в «Разработка готово», после чего по ней проводят демо в лице аналитика и продуктолога. Если все устраивает, мы достигли цели «стори»: решили задачу на старте. Дальше она переходит в статус «Тестирование». Причем «сторя» может перейти в «Тестирование» после демо даже с минимальным набором дефектов.
Шаг 7. Теперь очередь команды тестирования. Перед тем как приступить к тестированию, аналитиком и продуктологом проводится тест-кейс-ревью. Это ревью тест-кейсов, чтобы понять, все ли вариации покрыты и нет ничего лишнего, чтобы не тратить время впустую. По результатам тестирования задача будет переведена в статус «Тестирование готово» при удовлетворении требованиям test-computation criteria, так называемым критериям готовности по результатам тестирования. Например, определенное количество дефектов допустимо при некотором уровне значимости и так далее.
Шаг 8 — подготовка релиза. Как накопилось определенное количество «сторей» в «Тестировании готово», по решению команды происходит их объединение в релиз.
Шаг 9 — релиз устанавливается на промышленный стенд. Как только установка выполнена, задачи переводятся в статус «Deployed».
Какие же артефакты готовят аналитики у нас на проекте?
Одним из таких артефактов, которыми они пользуются, является система для совместной работы с информацией для написания документации и инструмент для управления проектами для отслеживания задач.
В системе для совместной работы заводится страничка, которая называется «История», у нее есть номер, присвоенный по определенной маске. На страницу переносится «я хочу, чтобы» и критерии приемки из инструмента по отслеживанию задач. Хочу сразу объяснить, что «История» — это одноразовая страничка. Если нам нужно будет поменять этот же функционал, то мы не будем корректировать эту «Историю», мы заведем новую, потому что это уже будет новая бизнес-фича (с новыми «хочу» или новой целью). Дальше эта US расписывается через UC (основной и альтернативные), в конце постановки находится сценарий для демо. Если в рамках «Истории» необходимо разработать новые экранные формы, то аналитик прорабатывает для них «мокапы», размещая в разделе GUI на странице «Истории». «Мокапы» готовятся в макросе draw.io, после чего уходят в работу дизайнеру, который дальше их реализует в Pixso, приложив ссылку в «Историю». Все комментарии и правила работы экранных форм формализуются аналитиком в виде текста под каждым из «мокапов», на которые есть ссылки из шагов UC.
У UC, конечно, есть предусловия и расширения. Одним из примеров расширений являются алгоритмы. Алгоритм прописывается на отдельной страничке в блоке алгоритмов, он версионируется. На страничках алгоритмов обычно содержится краткое описание алгоритма, его назначение, входящие и результирующие параметры, блок-схема расчета и пошаговое текстовое описание этой блок-схемы (возможно в виде таблицы).
Чтобы все на проекте разговаривали на одном языке, помимо глоссария мы используем модель данных логического уровня, потому что на этапе проектирования аналитики до конца не знают, из какой БД (реляционной или нет, откуда конкретно) далее будут браться данные для алгоритма. Это будет спроектировано архитектором, например, совместно с командой Hadoop.
Если нам необходимо выдать какие-то права или наоборот урезать какие-то доступы, то у нас есть ролевая модель, она тоже отдельно описана с версионированием и описанием каждой роли.
Есть справочник всех оповещений и ошибок, который содержит в себе табличку с текстом оповещения или ошибки и указанием US.
Присутствует у нас и нормативно-справочная информация, где каждый справочник находится на отдельной страничке и также версионируется.
Если же необходимо расширить список нефункциональных требований в отношении GUI, например, вид и размеры шрифтов, цветовую гамму и тд, то для этого используется отдельная страница изменений. На этой странице каждое требование к GUI ведется атомарно. Для остальных подвидов нефункциональных требований есть отдельная страница с разделами по подвидам и описанием атомарных требований (например, версия браузера, разрешение экрана и тд).
Если необходимо описать отчетную или печатную форму, то следует публиковать ее на отдельной страничке с кратким описанием: что это за форма, алгоритмы и правила заполнения каждой из ячеек, начиная от требований к шрифтам, заливке, и заканчивая описанием правил заполнения полей. Плюс, если это форма динамическая (может менять число строк или столбцов), то обязательно описываеть алгоритм расчета. Неотъемлемым артефактом является приложенный пример формы.
Еще одним важным артефактом является описание интеграционных контрактов. Аналитики описывают в табличной форме структуру файлов (запросов/ответов), прикладывают их схемы и примеры.
Теперь хочется кратко рассказать о наших планах.
Во-первых, сейчас есть небольшая проблема с шаблонами документации для системных кейсов. О чем идет речь? Чтобы получить расчет или выборку, зачастую необходимо настроить ETL-процесс. Все это запихнуть в одну пользовательскую историю будет некорректно, она будет и по времени разрабатываться долго, и потянет за собой большое количество накладных расходов (начиная от контроля реализации, заканчивая долгим согласованием с заказчиком). Сейчас это заводится в виде dev-task, что не очень красиво. Мы хотим шаблонизировать артефакты для таких типов задач и по ним работать.
Во-вторых, мы хотим настроить макрос, позволяющий собирать документацию по ГОСТ из пространства в системе совместной работы, требующую в дальнейшем минимальных доработок от аналитика и технического писателя.
В-третьих, смотрим в сторону еще одного макроса. Он позволит четко определить, что такое требование на нашем проекте, присвоит ему идентификатор, набор реквизитов и самое главное — связи. Мы получим трассировку требований, которая повысит качество требований при их изменении в будущем.
