Команда работает на полную, задачи в трекере есть, но релизы выходят нерегулярно. Стейкхолдеры спрашивают «когда будет готово?» — а вы не знаете, что ответить. Знакомо?
Меня зовут Артём Герасимов, я владелец продукта SimpleOne SDLC. В этой статье расскажу, как превратить хаос в управляемый процесс разработки — без внедрения тяжёлых фреймворков, бюрократии и микроменеджмента. Начнём с трёх простых вопросов, которые помогут навести порядок уже сейчас.
Хаос в разработке: когда все заняты, но ценность не появляется
Хаос в разработке — это когда вы не можете прогнозируемо провести задачу от идеи до релиза. Появляется много блокирующих факторов, которые невозможно предсказать заранее. Часть задач не выпускается или уходит «в стол». И главное непонятно, как спланировать путь задачи от начала до конца. Вот как это может выглядеть.
Задачи приходят со всех сторон, и всё срочно
В компании много стейкхолдеров на одном уровне. Каждый приходит напрямую в команду со своим горящим запросом. Например, два менеджера по продажам обещают фичу разным клиентам — и обе задачи прилетают в разработку с пометкой «срочно». При этом менеджеры друг с другом не общаются, не знают о задачах коллег. Команда получает два одинаково важных запроса и не понимает, что делать первым.
Это происходит, потому что у команды нет единой точки входа и человека, который отвечает за приоритизацию. Нормально, когда стейкхолдеры приходят напрямую в команду, но всегда лучше, когда есть человек, который отвечает за то, что команда возьмет в работу.
В Scrum это владелец продукта — он понимает, что делает разработка, собирает запросы со всех сторон, но последнее слово за ним. В Kanban нет роли владельца продукта, но подразумевается, что есть встреча или ритуал, где все стейкхолдеры договариваются друг с другом до входа в команду.
При этом важно, чтобы хаоса не было именно на этапе Delivery, так как это один из самых дорогих участков процесса. Здесь работают аналитики, разработчики, тестировщики, релиз-менеджеры — множество ролей и процессов нужны для того, чтобы задача прошла от идеи до релиза. Не страшно, когда мы можем не договориться на уровне Discovery. Но как только команда приняла обязательства по выполнению задачи, процесс должен быть максимально прозрачным и упорядоченным. Иначе мы просто выбрасываем деньги.
Проблема в том, что многие компании пропускают этап Discovery. Все задачи сразу попадают в команду — без предварительной обработки, без понимания, нужно ли это делать вообще, когда и зачем.
Приоритеты меняются каждый день
Команда не успевает закончить начатое и постоянно переключается на новые «срочные» задачи.
Представьте реку: если она течёт по одному руслу, вы можете предсказать, когда бумажный кораблик доплывёт из точки А в точку Б. Но если вы начнёте строить у реки новые русла, кораблик может сначала потечь в одно русло, потом в другое. Где-то скорость реки станет медленнее, потому что часть потока ушла в другое русло. Где-то появятся камни. В какой-то момент вы потеряете возможность предсказать, когда кораблик придёт из точки А в точку Б.
В разработке то же самое. Как только наша «река» становится менее предсказуемой, начинаются проблемы со сроками. У команды больше нет понятного ответа на вопрос «когда будет готово?», это прямое следствие постоянных переключений. Когда команда не завершает задачи, а перескакивает с одной на другую, предсказать что-либо невозможно.
Непредсказуемость приводит к тому, что часть работы просто не доходит до пользователей. Команда что-то делает, но результат теряется по дороге.
Наша задача — сделать разработку максимально предсказуемой. Это сложно, но возможно, если начать с базовых договорённостей.
Как начать наводить порядок
Перед тем как внедрять любые изменения, нужно ответить на главный вопрос: зачем? Какие проблемы вы хотите решить? Пока вы не решите, что хотите изменить, вы не сможете понять, что нужно менять, какие инструменты и методологии использовать.
При этом не обязательно выбирать конкретную методологию и пытаться перестроиться на новый процесс за один день.
Методология как книга рецептов — хорошие повара редко готовят строго по книге, они помнят базовый рецепт, но пропорции и детали подбирают под себя. То же самое с разработкой. Важно понимать, как и для чего работают процессы в Scrum, Kanban или SAFe. Но не факт, что всё, что там описано, нужно именно вам.
Любая методология — это способ задать себе правильные вопросы. Почему умные люди хотят делать так, а мы так не делаем? Может быть, нам тоже стоит попробовать, и это принесёт пользу. А может быть, для нашей компании это не подходит.
Например, вы делаете B2B-продукт с огромным циклом разработки и не можете работать спринтами по две недели, так как вы просто не будете видеть результата. В этот момент вы признаёте, что Scrum не подходит, и проще работать исп��льзуя Kanban метод, отслеживая путь задач.
Важный момент: в контексте внедрения новых процессов нужно помнить о «кривой изменений», или J-curve.
Сначала команда будет терять эффективность: люди учатся новому, совмещают старый и новый процессы, делают больше ошибок. Затем, по мере освоения, производительность возвращается к прежнему уровню и может превысить его, когда новый способ работы стабилизируется. Если компания сможет пережить этот момент ухудшения, то со временем все процессы станут лучше.
Статистика от Kanban University, к сожалению, неутешительная: около 30% масштабных инициатив по изменению процессов проваливаются и отменяются. Компании паникуют в момент падения показателей, отменяют инициативу, проводят реорганизацию, увольняют людей — и начинают всё заново.
Только около 10% таких проектов действительно достигают ожидаемых результатов. Остальные 60% восстанавливаются, часто выше исходного уровня, но так и не оправдывают вложенных инвестиций.
Если компания сможет пережить этот момент временного ухудшения, процессы со временем улучшаются. Но многие не выдерживают.
Готовы ли вы пережить такое падение? Если нет — лучше менять процесс за процессом. Это не принесёт быстрого результата, но не так сильно ударит по жизни компании.
Три вопроса, с которых начинаются изменения
1. Откуда берутся задачи?
Есть ли у вас единая точка входа? Не прилетают ли задачи сразу напрямую в команду? Если прилетают, узнаёт ли об этом ответственный менеджер?
Ответственным менеджером может быть владелец продукта, продакт-менеджер, проджект-менеджер. Названия разные, но суть одна: обычно есть кто-то, кто отвечает за задачи и бэклог.
Единая точка входа помогает собирать все запросы в одном месте. Любой клиент или стейкхолдер может оформить заявку с описанием проблемы и видением решения. А дальше владелец продукта разбирает эти запросы и работает с бэклогом.
2. Как мы понимаем, что задача готова?
Это важная часть Scrum — Definition of Done (критерий готовности). На самом деле, это есть и в других методологиях, но чаще всего этого нет в компаниях. Как бы это ни было смешно, но очень сложно ответить на вопрос: «Как понять, что задача готова?»
Если есть чек-лист, который позволяет определить готовность, это помогает в том числе ответить стейкхолдерам на вопрос «когда будет выпущена задача».
Эти практики должны быть по возможности едиными для компании. У вас могут быть разные команды разработки, но желательно, чтобы Definition of Done были синхронизированы. Это не всегда получается, например, для мобильной и веб-разработки релизный цикл разный, финальные этапы могут отличаться. Но будет полезно, если DoD хотя бы примерно будут консистентны.
3. Кто и за что отвечает?
Тот же Scrum очень хорошо подсвечивает, что должна быть матрица ответственности. Зоны не должны пересекаться:
Владелец продукта отвечает за задачи. Больше никто за задачи не отвечает.
Scrum-мастер отвечает за процессы и обучение команды. Команда не думает, как обучаться — они приходят к Scrum-мастеру и говорят: «У нас что-то плохо работает, исправь». Scrum-мастер исправляет.
Команда разработки не думает о том, как задачу нужно реализовать с точки зрения бизнеса. Это зона владельца продукта. Разработка отвечает за техническую реализацию.
Таким образом, три роли не конкурируют за определённую зону, не пытаются договариваться. Они просто отвечают каждый за своё и тянут продукт в свою сторону, масштабируя его.
Как это работает на практике: инструменты SimpleOne SDLC
Договорённости нужно зафиксировать в едином инструменте, иначе они забудутся. SDLC-система помогает новым процессам работать автоматически — вам не придётся каждый раз напоминать команде о правилах.
Что должна уметь система:
Собирать все задачи в одном месте
В SimpleOne SDLC есть функциональность Feature Requests — запросы на улучшение продукта. Любой клиент или стейкхолдер может оформить такой запрос прямо с портала продукта.
Человек описывает, что не нравится и как он это видит. Дальше владелец продукта или проджект-менеджер разбирает эти запросы и работает с бэклогом. В запросе есть вопрос срочности. Но за счёт того, что это единая точка входа, очень удобно собирать всю информацию централизованно и управлять приоритетами.
Можно настроить сбор информации из разных источников — почта, портал, интеграции с другими системами. Feature Requests будут приходить из разных каналов, но собираться в одну точку в виде единого списка.
Фиксировать критерии готовности задач
Работу с Definition of Done можно начать с базы знаний — составить чек-лист критериев готовности. Дальше — настроить поля в системе, которые отвечают за эти критерии.
Например:
Поле «Релиз» — в каком релизе задача была выпущена
Поле «Билд» — номер сборки
Чекбоксы для проверки отдельных этапов
Можно создать отдельную вкладку в задаче, где с помощью чекбоксов указано, что нужно сделать, и связать эти чекбоксы с соответствующими полями.
SimpleOne за счёт Low-code инструментов позволяет создавать такие поля динамически — не нужно ждать, пока нужная функциональность появится в «коробке» продукта. Вы адаптируете систему под свои процессы, а не подстраиваете процессы под систему.
Делать прозрачными зоны ответственности
В каждой задаче можно указать не только исполнителя, но и роли, которые отвечают за разные этапы работы. Например:
Роль аналитика — кто пишет спецификацию
Роль дизайнера — кто делает макеты
Роль разработчика — кто реализует функциональность
Роль тестировщика — кто проверяет качество
Так в задаче сразу видно, кто отвечает за какой этап разработки. Более того, можно настроить автоматизацию: исполнитель будет подтягиваться в зависимости от статуса задачи.
Это создаёт основу для осознанного анализа процессов и их постоянного улучшения. SDLC-система в этом случае становится инструментом, который поддерживает и усиливает такие изменения.
***
Расскажите в комментариях, с какими признаками хаоса в разработке вы сталкивались чаще всего? Как справлялись?
