Часть разработчиков пропускает этап проектирования, считая его потерей времени. На несложных задачах это оправдано. Но на сложном проекте планирование экономит куда больше, чем отнимает: внести правку в диаграмму проще, чем переписывать код, а нужное решение видно ещё до первой строчки.
Вопрос в том, чем описывать задачу. Привычный инструмент - текстовое техническое задание. Оно отлично работает, пока задача линейная. Когда процессов много и они переплетены, текст начинает мешать.
Что такое UML
UML (Unified Modeling Language) - система обозначений для анализа и проектирования программных систем. Проще говоря, это язык схем: процессы, объекты и связи между ними рисуют диаграммами, а не описывают абзацами. Для сложной логистики или многоступенчатой автоматизации такая форма структурирует информацию лучше, чем текст.
Где текстовое ТЗ перестаёт работать
Мы столкнулись с этим на автоматизации логистического подразделения крупной компании. Процессов, структур данных и взаимосвязей было столько, что текстовое описание перегружало: систему невозможно было удержать в голове целиком. Не спасал и гибкий подход - блоки так зависели друг от друга, что вынуть и переписать один отдельно не выходило.
Решением стали UML-диаграммы с перекрёстными ссылками и текстовыми пояснениями. Графика и текст работали вместе: общая архитектура - на схеме, детали - под иконками и в дочерних диаграммах.
Что это дало на практике
- →Навигация по проекту. Элемент на схеме ссылается на другие диаграммы, где он встречается - переход по связям вместо поиска по тексту.
- →Масштаб по требованию. Нужный блок раскрывают в деталях, лишнее сворачивают - видно и лес, и отдельное дерево.
- →Видимые зависимости. Сразу понятно, в каких блоках задействован конкретный компонент - меньше сюрпризов при изменениях.
- →Удобство обсуждения с заказчиком. Проблемные места подсвечивают цветом, вопросы оставляют комментариями прямо на схеме.
Плюсы и минусы подхода
Текстовое ТЗ: быстро для простых задач, не требует специального ПО и навыков, привычно заказчику. Но на сложном проекте текст перегружается, связи теряются, а целостную картину собрать трудно.
UML-диаграммы: наглядность, видимые зависимости, простой сбор информации и передача знаний между этапами. Минус - нужны знание нотаций (UML, BPMN) и специальное ПО, а сам этап проектирования дольше; подход ближе к водопаду, чем к гибкой разработке.
Это не выбор раз и навсегда: на простой доработке хватит текста, на сложной автоматизации процессов выручают схемы, часто - в связке. Если у вас многоступенчатый процесс и непонятно, как его описать без потерь, - разберём задачу на диагностике. Как мы наводим порядок в запутанных процессах, видно на примере автоматизации продаж спецтехники в Битрикс24.
