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