Что превращает набор задач в эффективный план развития продукта и как не сбиться с пути? Делимся готовой системой: от User Story Maps до детальной декомпозиции на задачи и действия. Сквозное планирование вплоть до учета отпусков разработчиков.
Меня зовут Игорь Кузнецов, я IT-директор в компании «Технологии успеха». Она существует с 2011 года и создает инструменты для автоматизации. Сейчас мы разрабатываем сервис Hantico. Это сервис платформенной занятости, который предоставляет удобные инструменты для работы курьеров и таксистов в различных агрегаторах. Продукт состоит из веб-версии, мобильного и Телеграм-приложений.
В 2024 году у нас полностью обновилась команда, состав расширился новыми ролями, появилось больше IT-специализаций. Передо мной поставили задачу создать непрерывный производственный процесс и выбрать таск-трекер, который позволит эффективно и прозрачно отслеживать работу IT-департамента.
Я предложил Kaiten, потому что давно был знаком с ним. На мой взгляд, здесь есть все функции, которые позволяют организовать работу IT-команд. Вот что особенно привлекает:
- Гибкая настройка пространств и досок — их можно адаптировать под запросы компании и конкретных отделов.
- Встроенные отчеты — позволяют отслеживать показатели и оценивать эффективность команд.
- Блокировка — если работа над задачей на паузе, карточку можно заблокировать. Так мы понимаем, почему она не двигается дальше.
- User Story Map — в Kaiten есть модуль, который позволяет создавать карты пользовательских историй и связывать их с задачами на досках.
Отражаем в Kaiten план разработки — таск-трекер помогает следовать ему
В основе процессов лежит верхнеуровневый план разработки. В нем описаны функции, которые необходимо реализовать в продукте в ближайший год. У каждой из них — две составляющие: для нашего клиента и для сотрудника компании. Например, разрабатываем функцию по управлению профилем. Чтобы ее выпустить, нужно понять, какие элементы должны появиться в пользовательском приложении и в панели управления системой.
Затем описываем пользовательские истории. Последний шаг в плане — выставляем общие технические требования, не углубляясь в детали, например, «Позволяет обрабатывать данные 4000 пользователей в минуту».
Когда план готов и согласован, мы визуализируем его в Kaiten.
Шаг 1. Заносим функции в план разработки
У нас есть пространство «План разработки», на котором размещена доска «Поток функционала». На ней есть колонки, которые отражают поэтапную работу над задачей: «В работу», «В работе», «Разработка завершена», «Добавлено на Preprod» и другие.
Мы создаем под каждую запланированную функцию карточку и добавляем ее в столбец «В работу». Благодаря канбан-системе мы сразу видим, сколько фич нужно реализовать в текущем периоде — квартале. А после его завершения оцениваем, какие функции не успели выпустить.
Шаг 2. Составляем User Story Map
На этапе сбора требований переходим в модуль User Story Mapping и создаем карту. Под каждую функцию прописываем пользовательские истории. Например, User Story может звучать так: «Как клиент сервиса, я хочу регистрироваться без создания аккаунта в агрегаторе».
В сервисе Kaiten можно соединить User Story с карточками на пространствах. Мы привязываем пользовательские истории к задачам в «Плане разработки». Удобно, что из функции на доске можно сразу перейти к User Story, которые ей соответствуют.
Шаг 3. Собираем бизнес-требования и выставляем приоритеты по задачам по методу ADR
После подготовки пользовательских историй и определения функционала к следующему релизу начинается сбор бизнес-требований, на котором мы готовим черновика дизайна для согласования с представителями бизнеса. Как только результаты исследования бизнес-требований прошли согласование, начинаем работать над подготовкой ADR (Architecture decision record).
В Kaiten есть модуль «Документы», в котором мы создаем папку под каждую функцию. В текстовых файлах прописываем, как и в какую очередь будем реализовывать фичи. Документация хранится в том же сервисе, где находятся задачи — не нужно использовать отдельный сервис и вручную прикреплять текстовые файлы в Kaiten.
Шаг 4. Декомпозируем задачи
На последнем этапе мы делим каждый эпик из «Портфеля проекта» на задачи для команды. Для этого создаем дочерние карточки, которые связаны с основной. Так видно, к какому эпику относится задача.
Дочерние карточки попадают в пространство «Разработка продукта». Здесь под каждый отдел выделена горизонтальная дорожка: например Аналитика, UX/UI, CRM, DevOps. Так мы разделяем задачи разных команд, чтобы они не путались.
Для каждого этапа созданы автоматические чек листы, которые позволяют отслеживать прогресс по задаче. При перемещении карточки на следующий этап на связанной доске создается подзадача на ответственного исполнителя. В задачу наследуются цели и описания из базовой карточки Плана производства.
Упорядочили заявки на обучение и отпуск
Помимо разработки продуктов, в Kaiten мы ведем график обучения сотрудников и отпусков. Для этого есть отдельное пространство, на котором размещены две доски.
Обучение. Здесь сотрудники оставляют заявки на курсы, которые хотят пройти. Руководители рассматривают их и согласовывают. Заявки находятся в одном месте и не теряются, а по каждой из них всегда видно статус.
Отпуск. На этой доске мы создали карточку с именем каждого сотрудника и перемещаем ее в зависимости от того, отдыхает сейчас работник или нет.
График отпусков можно посмотреть в виде диаграммы Ганта. А затем в отдельной вкладке открыть план разработки и посмотреть, не выпадает ли отпуск ключевых сотрудников на ее главные этапы. Например, чтобы не отправить отдыхать ведущего программиста во время работы над важной функцией.
Через отчеты подводим итоги недели и анализируем самостоятельность сотрудников
Чтобы оценить эффективность команды, в Kaiten мы просматриваем три основных графика.
Суммарный отчет. Каждую неделю анализируем, над какими задачами работали, сколько из них закрыли, с какими сложностями столкнулись. Так мы понимаем, в каком темпе продвигается разработка и успеваем ли сделать все, что планировали.
Распределение карточек. График распределения помогает оценить, насколько работники становятся самостоятельными при постановке задач в Kaiten. Изначально в компании этим занимался я: сам заводил и оформлял карточки, а сотрудники только двигали их по колонкам. Сейчас многие работники сами создают карточки.
Накопительная диаграмма потока. Она показывает, сколько задач находится на каждом этапе. Если на определенной стадии карточек слишком много, определяем причины, почему задачи «зависают» и как это исправить.
Отчеты не только наглядно показывают текущие результаты, но и мотивируют команду.
Например, недавно мы поняли, что за три месяца закрыли целых 450 задач — это в среднем по 1,5 задачи в день. Когда сотрудники видят конкретные результаты своей работы, их продуктивность повышается.
Путь разработки стал понятным
Благодаря Kaiten процессы в компании стали прозрачными: мы видим статус каждой задачи, этап, на котором она находится, ожидаемый результат. В таск-трекере отображается полный roadmap продукта, которому легко следовать.
Сотрудники теперь более самостоятельные. Они сами ставят задачи на досках, заполняют карточки, общаются в комментариях — руководителям не приходится подробно погружаться в операционку.
