Всем привет! Меня зовут Роман, я руковожу разработкой. Когда‑то начинал разработчиком, потом тимлид, сейчас управляю лидами.

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

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

Казалось бы, инструментов хватает: Jira, YouTrack, Trello, GitLab, Confluence и ещё десятки. Но если копнуть глубже, становится понятно: каждый из них решает только кусочек головоломки. Целостной картины всё равно нет. Она появляется только в голове после погружения, но и тут засада — голов в проекте много, и у каждой своя картинка.

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

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

1. Неоднозначные формулировки задач

Это проблема кажется не истребима. Но снизить болезненный эффект до управляемого уровня можно попытаться. Если грубо, то один из частых вариантов проблемы в том, что в задачах пишут «Сделать модуль загрузки файлов в формате CSV». Структуры в CSV не описаны, как их интегрировать в текущую системы не понятно. Какие ограничения на размер и время обработки, что делать при возникновении ошибок — все это осталось за кадром.

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

Чего тут не хватает:

• Трассировки требований через все слои архитектуры к задачам

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

2. Разрыв между проектом и реализацией

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

Итак, проблема выражается в том, что в условных Enterprise Architect, Confluence и Jira развиваются свои параллельные реальности. В какой‑то точке происходит частичная синхронизация. Например — что‑то спроектировали в EA (ну как в EA — в draw.io, Archi, Visio, Miro т.д.), далее отправили аналитиков прорабатывать постановки в Confluence, далее разработка вошла в активную фазу отработки замечаний и все постановки и изменения уехали в Jira. В итоге смотреть схемы и стройные постановки становится бесполезно потому, что их уже не актуализируют. А, согласитесь, по Jira собрать актуальную документацию считай что невозможно. Как следствие, исполнитель не может увидеть контекста задачи.

Чего тут не хватает:

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

3. Отслеживание состояния системы

По трекеру задач можно понять состояние задачки или спринта. Если поднатужится, то можно по сторям собрать статистику. И кажется все. Все остальное это какая‑то, обычно ручная интеграция с условным MS Project. А как получить информацию о результатах тестирования. А что со сборкой и стендами? А все ли требования к системе закрыты?

Чего тут не хватает:

• картины состояния реализации системы: что реализовано и в каком объеме, что протестировано, где накопились проблемы

• интеграции с метриками: тестирования, CI\CD, состояния стендов и соблюдения сроков, ресурсов и.т.д.

4. Сложность коммуникации

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

На небольших проектах Jira и Confluence еще справляются с задачей накопления контекста. Но на длинной дистанции надо тратить усилия по актуализации устаревших описаний, а занимаются этим крайне редко.

Чего тут не хватает:

• все также нужен единый источник правды

• кажется в этом месте должен появится AI‑ассистент

5. Накопление технического долга

Что такое технический долг — вопрос дискуссионный. Но, кажется, многие согласятся что долг со временем растет и им нужно управлять. Как проявляется проблема:

• архитектурные или технические решения становятся не актуальными

• задачи в бэклоге конфликтует с реализованной функциональностью или затрагивают проблемные места в системе.

Чего тут не хватает:

• анализатор тех. долга

• кажется опять AI‑ассистент мог бы сформулировать подсказки

Я пока не встретил инструмента, который закрывал бы все эти проблемы целиком. Возможно они есть — расскажите в комментариях.

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

На мой взгляд связка единый источник правды + AI ассистент может сильно помочь в решении указанных проблем.

Теоретически, инструменты типа EA или Business Studio могли бы развиваться в этом направлении. Но вот вопрос: способны ли они масштабироваться до уровня детализации задач, которые ведуться в Jira. И второй, не менее важный вопрос: цены этих инструментов не сопоставима с Jira.

Таким образом приходится констатировать печальную ситуацию — есть экономические ограничения для технической реализации такой задачи привычными методами работы. А покуда так — Лиды на проекте а) незаменимы б) перегружены. Ну в общем работа есть.

А вы что думаете?