Привет, Хабр! 

Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC.

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

Симптом первый: релиз как чёрный ящик

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

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

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

Пока команда маленькая, такой режим ещё можно терпеть.

Но с ростом продукта он начинает обходиться всё дороже: всё труднее объяснить задержку, сбой требует лишних проверок, а подготовка changelog или ответа для бизнеса становится ручной работой, которая поглощает время. И проблема здесь уже не в отдельных задачах, а в том, что сам релиз нельзя рассмотреть как нечто единое целое.

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

Как говорилось выше, при разработке используется множество разных систем, и с одной стороны это устоявшаяся практика — команда привыкает совершать десятки мелких действий в процессе разработки. Сборки смотрят в одной системе, code review (мы писали о нём в другом нашем материале) в другой, требования и их обсуждения остаются в трекере или базе знаний, и так далее. 

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

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

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

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

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

Симптом третий: поддержка и разработка живут в параллельных мирах

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

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

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

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

Симптом четвертый: команда выросла, а инструмент остался на уровне доски с карточками

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

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

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

И тогда вопрос уже не в том, как ещё настроить трекер, а в том, способен ли он вообще поддерживать разработку на текущем масштабе.

Симптом пятый: процесс обсуждают по ощущениям, а не по данным

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

Другими словами, без аналитики команда теряется, и не может ни просчитать реальную эффективность работы, ни нащупать черные дыры и проблемные места, пожирающие время. И здесь стоит проверить проект небольшим чекбоксом вроде этого:

• Сколько времени уходит на исправления?

• Сколько на релиз новой функциональности?

• Как много съедают срочные переключения? 

• Где копится узкое место? 

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

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

В зрелой системе метрики показывают, как работа течёт на самом деле: где застревают задачи, как движется спринт, что происходит с cycle time, где команда стабильно теряет темп. Не на словах в духе «нам кажется, что стало хуже», а на понимании, что «вот здесь поток замедлился, вот здесь перегрузка, вот здесь пора менять сам способ работы, потому что так говорят графики».

И для разработчиков существует инструмент, который решает корень перечисленных симптомов. Можно сказать, что это следующая ступень эволюции таск-трекера для разработчиков. Название ему SDLC-система.

Где заканчивается таск-трекер и начинается SDLC-система

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

Для трекера задача – это в первую очередь карточка.
В ней есть описание, исполнитель, срок, комментарии. Этого хватает, пока команда работает в небольшом контуре и ей не нужно видеть весь путь изменения. Но в зрелой разработке одна задача почти никогда не живёт сама по себе. Она связана с веткой, коммитами, тестированием, релизом, конкретной версией продукта, а иногда ещё и с инцидентом или запросом из поддержки. Если система не держит эти связи внутри процесса, команде приходится достраивать их вручную.

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

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

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

Как выбрать SDLC-систему

Ошибка здесь обычно начинается с неверно поставленного вопроса.

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

Соответственно идти по принципу «похожа на Jira или нет» — не самая надёжная стратегия. Внешнее сходство почти ничего не говорит о том, сможет ли инструмент поддерживать реальный процесс разработки. Гораздо важнее другое: насколько глубоко он встраивается в ваш стек, и видит ли связь задачи с кодом, релизом, тестированием, версиями, сборками. Умеет ли удерживать весь путь изменения внутри одной логики, а не заставляет команду снова собирать картину по кускам из разных сервисов.

Не меньшее значение имеет Low-code кастомизация. У каждой команды своя структура работы, свои роли, свои типы сущностей и маршруты согласования. Если систему трудно адаптировать под процесс без тяжёлой доработки, она довольно быстро начнёт диктовать команде чужую логику. В результате бизнес снова подстраивается под инструмент, а не инструмент под бизнес. Поэтому гибкость здесь  не приятное дополнение, а один из признаков продвинутого решения.

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

Резюме

Таск-трекер хорошо работает до тех пор, пока разработка остаётся относительно простой. Но когда в процессе появляются релизы, зависимости между командами, техдолг (мы писали о нём в другом нашем материале), инциденты и постоянная обратная связь от пользователей, одной доски с карточками уже недостаточно. В этот момент становится важно не просто учитывать задачи, а видеть весь жизненный цикл изменений целиком – от запроса до релиза и дальше до поддержки. Здесь и начинается разница между таск-трекером и SDLC-системой, которая действительно помогает управлять разработкой.

А сколько систем вашей команде нужно открыть, чтобы ответить на простой вопрос о релизе, баге или доработке?