Привет, меня зовут Сережа, последние несколько нет я работаю на позиции Системного аналитика в крупных финтех-продуктах. А еще менторю и начал вести блог @analytics_career для популяризации направления Системный анализ и помощи новичкам при входе в профессию.
Сегодня хочу поделиться с вами своим опытом по использованию тех или иных инструментов в своей работе.
1. UML
UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.
Уверен, что все, кто каким-либо образом замешаны в разработке ПО - видели UML-диаграммы. Это незаменимый инструмент, особенно в работе системного аналитика, когда необходимо понятно для всей команды описать интеграцию систем, например, с помощью диаграммы последовательностей.
Например, вот часть диаграммы, на которой описан процесс регистрации.
Даже тот, кто не знаком со спецификой обозначений UML вполне сможет понять, что происходит на этой схеме. И это лишь часть того, что позволяет сделать UML.
2. BPMN
Business Process Model and Notation (нотация моделирования бизнес-процессов) — это система условных обозначений, которая отображает бизнес-процессы с помощью блок-схем. BPMN диаграмма показывает в какой последовательности совершаются рабочие действия и перемещаются потоки информации.
BPMN удобно использовать не для описания технической части проекта, а для описания, например, workflow какого-либо процесса. Наглядная схема показывает, где в процессах есть узкие места или вовсе тупики, из-за которых клиенты уходят или не заканчивают целевое действие (заявка, покупка, звонок). BPMN подсвечивает места, которые можно улучшить и моделирует способы адаптации под новые условия.
Правда, иногда, описывая процесс, который постоянно разрастается, обрастая новыми фичами - диаграмма становится невероятно объемной. Но даже в таком случае наличие диаграммы сильно облегчает понимание и последующую аналитику, иначе как на основании одних лишь ТЗ и остальной эксплуатационной документации разобраться, что происходит вот тут:
3. Confluence
Confluence - wiki-подобная система для внутреннего использования организациями с целью создания единой базы знаний.
Опять же, мало кто из людей, участвующий в разработке ПО не слышал и не пользовался таким инструментом.
Очень удобная вещь, в которой можно описывать всю необходимую документацию проекта - архитектуру, дизайн, ТЗ - всё что угодно. Большое количество плагинов также благоприятно сказывается на удобстве использования этой системой и позволят настроить её под вашу команду.
Однако, лично для меня он имеет ряд недостатков и неудобств в использовании. Особенно в части непосредственного написания текста, ибо регулярно встречаются проблемы с форматированием, съезжающими списками, кривыми вставками изображений и пр.
Когда на проекте большая команда, и над документом одновременно работают несколько аналитиков (например, правка документации микросервиса, который меняется в одном релизе в рамках разных задач), становится неудобно отслеживать изменения, формировать диффы для постановки задач на разработку, да и просто одновременно работать.
Поэтому переходим к следующему пункту.
4. Asciidoc + git
Столкнувшись с проблемами, описанными выше при работе в Confluence, мы с командой начали искать пути решения. Была предложена связка asciidoc + git. И это стало потрясающим открытием для меня.
Во-первых, с asciidoc очень приятно работать, нет никаких проблем с рендером текста в визуал. Да, необходимо потратить некоторое время, чтобы разобраться с языком, но это всё окупается сторицей (особенно удобной оказалась фича, когда часто повторяющийся в документации текст, можно оформить в шаблон с помощью плагина и потом просто вставлять в нужные места с помощью одной кнопки).
Во-вторых, избавились от проблем с одновременной работой нескольких аналитиков над одним сервисом. Опять же, пришлось потратить некоторое время на создание репозиториев в git под каждый сервис и перенос туда существующей документации. Однако после этого можно было спокойно отводить ветки от мастер-ветки, вносить изменения, создавать MR (merge request). Опять же - удобно согласовывать MR между аналитиками и удобно отдавать их в разработку, т.к. git отлично отображает все изменений между ветками, в отличие от Confluence. В итоге вся документация из git, с помощью плагина git4c, вставлялась в Confluence, который также рендерил asciidoc в нормальный текст.
С Asciidoc я работал через IDEA. С помощью плагина AsciiDoc преобразует asciidoc в обычный текст. Выглядит это примерно так:
На этом мой базовый набор заканчивается. Если вы до сих пор пишите требования в Word/Excel, рекомендую попробовать, очень экономит время и силы.
Поделитесь в комментариях, если есть еще какие-то важные инструменты для работы аналитика.
