Всем привет! Меня зовут Роман, я руковожу разработкой. Когда‑то начинал разработчиком, потом тимлид, сейчас управляю лидами.
В моём багаже опыта — работа в интеграторе, потом в небольшой компании из сферы 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.
Таким образом приходится констатировать печальную ситуацию — есть экономические ограничения для технической реализации такой задачи привычными методами работы. А покуда так — Лиды на проекте а) незаменимы б) перегружены. Ну в общем работа есть.
А вы что думаете?
Комментарии (0)
Snownoch
15.09.2025 04:04да, тоже задумывался о передаче в могучие руки ИИ сегодняшней работы с задачами. оценили-прослезились, размер БД одной из систем - 7Гб. причем чтобы реализовать функционал, необходимо прогонять через ИИ процентов 20 от БД, ~1.4Гб только данных. пока такие контексты ИИ не под силу. Но, несомненно, в ближайшем будущем, это ограничение будет преодолено
steb
15.09.2025 04:04Вы верно подметили: системы нет. И это одна общая проблема, которая порождает перечисленные вами 5-ть (а так-же и многие другие). Однако в статье, вы описали разные проявления (относительно этапов создания продукта) однако не описали ключевую проблему… т.е. более развёрнуто мысль "системы нет".
Текст моей попытки описать ключевую проблему вышел за пределы комментария и опубликован в виде статьи.
angry_stitch Автор
15.09.2025 04:04Основательно. Ключнвой момент видимо "корень проблемы об отсутствии общеупотребительной системы стереотипов разпознавания и преобразования информации в ходе управления сложными системами". Т.е речь об едином языке, как в математика?
cless75
15.09.2025 04:04Вы так и до методологии управления доберетесь . Например model driven engineering))
Или requirements engineering так в разработке принято называть целостное управление задачами ))
encruzado
15.09.2025 04:04"Каждая несчастливая семья несчастлива по-своему..."
Тем не менее, всегда можно шевелится и какие-то инструментики придумывать по месту. Например:
1. Научить коллег говорить слово "нет". "Я не понимаю". "Я не хочу это делать". Наделать соотвествующих статусов в трекерах. Потом строить аналитику по таким статусам и что-то думать. Легализовать это "нет" и "не хочу", поощрять даже. Пробовать продуктовые механики в проектных командах, когда у людей появляется возможность поиграть в разные роли, сегодня on duty, а завтра галстук нацепил и пошел в presale на несколько часов, в промежутках инфру своими руками поболтил в части касающейся, white paper пописал, короче, разные способы расширения сознания и ответственности. Изничтожать все плохо работающие артефакты. Аналитик принес сторю на 100 листов, которую никто не будет читать? Нарисовал ER, которая не будет иметь никакого отношения к конечному результату в коде? Значит, надо тормозить процессы, всех отправить делать ничего или играть на плойке. Даже на самом горящем проекте намертво остановить неправильную активность дешевле, чем ее продолжать.
Вообще, сложно ставить диагноз по фоторгафии, но "каждый думает о своем" - типично для проектного подхода. И тут надо думать в первую очередь не об инструментах, первичны люди;
2. Уменьшить поверхность всего. Меньше артефактов. Меньше диаграмм. Меньше страниц. Меньше всего. Если можно вместо кучи макулатуры быстро соорудить "живой" PoC, который всем позволит синхронизировать понимание - отлично же. Вводить культуру быстрого прототипирования. Увеличение ответственности для участника процесса, не "я закрыл за 3 месяца 33 тикета", а "я прекрасно провел лето, сделал А, это устранило наши боли B и C, а еще коллеги-смежники порадовались и внедрили и импакт просто офигительный, я доволен, все довольны";
3. Тут даже непонятно, а боль-то конкретно в чем? Звучит как "линейный менеджмент творит дичь, потому что [нужное подстваить]". Успокоить линейных. Подровнять топов, воткнуть нужные срочные метрики, чтобы у них ожидания начали сходиться с реальностью. Тут, опять же, есть куча разных треков в разных контекстах, например, разработчик свои тесты пишет для себя, тестировщик проверяет соотвествие продукта некоторым формальным требованиям и это все ортогональные штуки и т.д.
4. См. п. 2. Если коммуникации сложны - упростить. Уменьшить объем и количество ненужных артефактов, приоритезировать. Запретить людям делать ненужное. Научить задавать всех вопросы "Зачем это надо делать?", "Почему это надо делать именно так?" etc. Легализовать и поощрять подобные вопросы. Выстроить правильные вертикали, чтобы не только разработка могла с бизнесом разговаривать, да хоть поддержка, если у нее есть вопрос "какого хрена?" и нет внятного ответа. Опять же, выглядит как конфликт проект/продукт, смотреть надо для начала сюда. И, опять же, решают не инструменты и методологии, а люди, фокус всегда должен быть в первую очередь не на роботов, а на людей, иначе будет только хуже;
5. Тех. долг - штука неприятная. Но техническая и управляемая. Если он растет - проблемы в управленческой плоскости. Бизнес не получает правильную обратную связь, менеджмент не справляется с ресурсными задачами, неправильные процессы эскалации, неправильная инженерная культура, нет привычки выкидывать плохо написанный код, миллион других причин. Они все решааемы, если понять в чем конкретно проблема. Можно хоть каждый второй-третий спринт посвящать устранению, если уж так наболело.
В целом, любой инструмент или методология - сильно вторичен. Первична команда, контекст команды, взаимоотношения между людьми внутри и снаружи. Серебряной пули все равно не будет, а просто аккуратное изменение процессов и микроклимата может дать прирост к продуктивности на порядок. Казалось бы на ровном месте. Как-то так.
Но главный мой пойнт: перед тем как пробовать очередной способ выковать людям счастье на их головах, надо научится для начала хотя бы просто тормозить проблемные процессы. Под корень. Это уже дает кучу счастья практически бесплатно.
stas_dubich
Знакомые боли) А как решать ? Я думаю только организационно, т.к. единый источник истины это лишь инструмент, а ИИ еще недостаточно могет. И да, это будет дорого.
Мне кажется ИТ это про поиск компромиссов между качеством и ценой
angry_stitch Автор
Да, про компромиссы - это бесспорно, этим любая инженерная специализация занимается. Но вот условно есть чертеж и вроде из него много чего можно понять при строительстве или в машиностроении (я там был, я видел :) ). И составление чертежей - это основа конструирования и взаимодействия с производством. А в ИТ - все больше на словах получается. Т.е. ИТ пока в состоянии, как строители до изобретения бумаги - палкой на песке чертят и тут же забывают:) И это не организационная проблема. И ее надо решать до включения в схему ИИ. Дальше да неросеточка ,RAG и т.д.