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

Понимание сути и объема задачи должно появиться до первой строки кода. Писать сколь угодно емкое введение о важности этого этапа можно долго, но кажется, что все мы понимаем, что самые дорогие ошибки — на этапе проектирования.

Разработчику с проектированием и документированием решения задачи помогает аналитик.

Аналитики бывают двух видов:

• Бизнес-аналитик — понимает заказчика, его бизнес, пользователей, творчески мыслит. Он приносит задачу в команду на уровне «Наш бизнес (или пользователи) хочет такое вот волшебство: в двух словах рассказываю, все понятно, делаем!». Бизнес-аналитик отвечает за ожидания и потребности пользователей, за вид ПО снаружи.

• Системный аналитик — как правило, встречает бизнес-аналитика (если сам им не является) / заказчика / владельца продукта, получает «несколько строк на человекочитаемом» описания задачи, BPMN-диаграммы дедлайн. Он принимает задачу: оценивает изменения, анализирует влияние на подсистемы, модель данных, расписывает алгоритмы и вот это вот все.
  Системный аналитик отвечает за внутренности, о которых пользователям лучше вообще не знать и не думать.

Задача системного аналитика — спроектировать решение «от и до»:

• Проработать пользовательские и системные сценарии, алгоритмы, реакцию на действия пользователя, обработать все возможные «а что может пойти не так»,

• Определить связи между подсистемами, влияние на них,

• Декомпозировать задачу, если она большая,

• Описать изменения в модели данных.

• Продумать требования к UI/UX.

В процессе проектирования с командой разработки обсуждаются варианты технической реализации. Системным аналитиком создаются UML-диаграммы, ER-диаграммы, схемы обмена данными, последовательности передачи управления. В общем всё, что происходит внутри — зона ответственности системного аналитика.

Об очевидном

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

У нас в компании есть команды, которые отвечают за развитие отдельных частей МоегоСклада.

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

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

Причины появления системного аналитика

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

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

• Разработчики не готовы описывать результат анализа на человеческом языке. Они готовы только запрограммировать и показать готовое решение. Такой подход не всегда оптимален, потому что решение может оказаться неудовлетворительным для поставщика требований. А с ним оно должно быть согласовано.

• По итогам разработки остается только код. Разработчики не любят документировать, это не их задача.

Что делает системный аналитик?

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

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

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

Шаблон для проектирования поможет получить результат

От системного аналитика требуется описание модели ровно в том объеме, в котором его хочет получить заказчик.

Проект дома — понятие широкое, в него может быть вложено абсолютно разное наполнение: от дизайна комнат до высоты фундамента и толщины стен. Бизнес-заказчику обычно важно только то, что видит пользователь, а вот госзаказчику описание подавай по ГОСТу. Все разные.

В МоемСкладе — свой продукт. Нам важно понимать, какие возможности он реализует, какое поведение можно ожидать от системы, как обеспечена реализация в коде, как представлены объекты в модели данных.

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

Наш шаблон состоит из перечисленных далее блоков. Он помогает описывать, как встраивать новые кирпичики в «большое здание МоегоСклада».

Общее описание. Фото здания снаружи

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

Если необходимо, то обозначаются особенности работы, которые точно вызовут вопросы в процессе реализации и тестирования — все «потому что так задумано».

Влияние и связи. Не заденем ли мы при строительстве ель и баню, которые тут уже стояли?

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

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

Так, например, изменения в пользовательском UI основного приложения могут повлиять на наш публичный API и мобильные клиенты. Другим командам нужно будет своевременно сообщить о необходимости доработок.

Описание функциональности и основные сценарии. Список помещений и способы их использования

Системный аналитик прорабатывает:

• Пользовательские сценарии, алгоритмы обработки данных и поведение системы.

• Требования к передаче управления между подсистемами.

• Влияние исходного состояния системы на результаты выполнения задач.

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

Описание может включать UML- и BPMN-диаграммы, блок-схемы, диаграммы состояний, текстовое описание поведения, макеты экранов. Всё, что может помочь разобраться в том, как система должна работать: все решения по алгоритмам, основным сценариям и способам обработки ошибок.

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

Доступы и ограничения или просто ролевая модель. Кто может войти в здание

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

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

Описание UI/UX. Дизайн-проект здания

Здесь важно не просто рассказать про то, что «пользователь видит на экране форму документа» и прикрепить макет, а подробно описать:

• Поля ввода, селекторы, тексты подсказок, кнопки и вообще все элементы, которые должны быть отображены на экране для каких состояний.

• Описать требования к валидации данных со стороны клиентского приложения (то, что проверяется без отправки запроса в сеть): ограничения на ввод, допустимые символы, значения для селекторов, какие проверки инициируются нажатием на кнопки, можно ли выделить текст на экране и т.п.

• Для кнопок и других элементов описываются требования к отправке запросов на сервер и реакция на их нажатие.

• В идеале здесь стоит описать, как данные на экране связаны с БД.

Если к моменту начала разработки есть макет от дизайнера — прекрасно! Если нет, то системный аналитик должен уметь сделать макеты, поставить задачку дизайнеру, который сделает всё удобно и красиво.

Для наглядности показываю нашу заглушку.

P.S. Хранить скрины и макеты в будущей документации не всегда хорошо. Они частенько теряют актуальность

Техническая реализация. Описание фундамента и инженерки

Самое интересное происходит здесь!

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

Нужно проанализировать и описать:

• Список подсистем, которые будут реализовывать функциональность и процесс обмена данными между ними.

• Изменения в модели данных.

• Требования к алгоритмам обработки данных, работе с CRUD-моделью. Другие особенности реализации.

Техническая реализация — это последняя стадия проектирования перед написанием кода. Она может быть описана  поверхностно, и доделывать ее нужно только после написания кода.

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

Логирование и метрики. Как монтировать камеры видеонаблюдения и систему охраны

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

Другие блоки

В зависимости от того, какая часть МоегоСклада описывается, могут быть блоки:

• REST API - контракты.

• Работа ПО в оффлайн-режиме — особенности поведения в отсутствии сети для касс и мобильных приложений.

• Программно-аппаратные интеграции для касс.

Подытожим

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

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

Моделируя систему, определитесь с тем, кто будет потреблять документированную  информацию как на этапе разработки, так и в будущем, какие знания важно сохранить по итогам реализации на «электронной бумаге».

Строить дом без плана — странно. Может получиться избушка на курьих ножках, куча дров в результате дуновения ветра или недостроенное нечто.

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

Нет модели — нет ожидаемого поведения системы.

Проектируйте, и в процесс вашей разработки придет порядок!