Привет! Меня зовут Виталий, я New Business Director в AGIMA. В этой статье расскажу про наше небольшое, но классное изобретение — Agimaban. Это система управления разработкой, которая спасла нас от головной боли.
- Мы 16 лет делаем сайты, приложения, ERP-системы для крупных бизнесов. Нас часто подключают к проектам не с нуля. Иногда мы делаем только часть работ, иногда работаем в кооперации с другими командами, а иногда своими силами разрабатываем целые продукты для заказчика. И тогда уже мы подключаем подрядчиков.
- Работать в таком режиме сложно: процессы на каждом новом проекте построены по-своему, иногда нет никакой системы. Поэтому мы несколько лет тщательно документировали все наши процессы, меняли их, тестировали и внедряли на новых проектах. И в какой-то момент мы поняли: кажется, стало удобно. Так и появился Agimaban.
Говоря, что мы его изобрели, я, конечно, преувеличиваю. В его основе привычный Kanban-метод, который мы адаптировали под условия заказной разработки. Поэтому разговор про Agimaban не получится, если мы не вспомним основные положения Kanban-подхода.
А когда вспомним, расскажу, что мы добавили и какую пользу это принесло нам и нашим заказчикам.
- Спойлер: скорость доставки фич в прод ощутимо увеличилась, а процессы стали более прозрачными. Так что если вы руководите агентством, можно украсть у нас пару идей.
Вспомним практики Kanban-метода
Если вы спец по Kanban-методу, просто пропустите этот параграф. Тут я дам общие вводные, чтобы объяснить, как мы пришли к Agimaban.
Все особенности Kanban-метода неоднократно перечислены в интернете, но здесь нам важно освежить его основные практики. Их 6:
На последнем пункте остановлюсь чуть подробнее. В нём ключ к пониманию Agimaban. Посмотрим на пример:
- Визуализировать процесс работы. Каждый участник процесса должен видеть, как задачи двигаются по Kanban-доске.
- Делать договоренности явными. Каждый должен понимать, кто и за что отвечает, не должно оставаться «ничейных» задач.
- Ограничивать количество выполняемой одновременно работы. Аврал тормозит процесс.
- Управлять потоком задач. Не людьми, а именно задачами на доске: каждый раз решать, как улучшить или упростить процесс.
- Проводить встречи (каденции). Одни и те же встречи задают ритм работе, позволяют своевременно собирать обратную связь и решать проблемы.
- Эволюционировать. Всё сложное — это эволюционировавшее простое, поэтому процесс нужно постоянно улучшать.
На последнем пункте остановлюсь чуть подробнее. В нём ключ к пониманию Agimaban. Посмотрим на пример:
- У компании X много заказчиков. Каждым проектом руководит свой менеджер. И в каждом случае это отдельный процесс: свои регламенты, правила и ритуалы. Этот процесс эволюционирует, становится удобным для всех. А потом — бац. Проект завершился, начался новый. Все процессы приходится выстраивать с нуля. Эволюция обнулилась. Мы решили, что нам такое не подходит.
Мы внедрили систему, при которой эволюция процессов на каждом новом проекте не обнуляется. И назвали ее Agimaban, где ban — это Kanban, а Agima — это мы, потому что такие процессы удобны именно нам.
Фактически мы «канбанизировали» всё наше производство. Причем Agimaban лучше всего подходит для работы над продуктами, которые нужно развивать в течение длительного времени. Например, приложение приложение для ухода за домашними животными. Это сервис, работу которого можно улучшать постоянно.
Из чего состоит Agimaban
Пойду с козырей. Главная особенность — наличие трех отдельных Kanban-сервисов с досками. Мы проанализировали все наши задачи и поняли, что их можно смело делить на 3 группы: Management, Requirements и Features.
✔️ Management
На этой доске зачастую работают руководители проекта и стейкхолдеры. Этот сервис обеспечивает работу двух других. Он делает процесс разработки эффективнее и отвечает за ту самую эволюцию, про которую я писал выше.
На эту доску задачи попадают из регламента старта новых проектов, из ежеквартальных Client-service-встреч и после ретроспектив команды. Здесь мы найдем задачи типа «подписать допсоглашение», «согласовать PR», «найти еще одного дизайнера» и т. п.
Сервис Management фокусирует руководителей проекта на решении инфраструктурных проблем, чтобы они не становились блокером для остальной команды.
✔️ Requirements
Это доска с требованиями, в ней работают аналитики: бизнес-, системные и продуктовые, — тимлиды, архитекторы, проектировщики, дизайнеры, копирайтеры, редакторы и менеджеры.
Это доска с требованиями, в ней работают аналитики: бизнес-, системные и продуктовые, — тимлиды, архитекторы, проектировщики, дизайнеры, копирайтеры, редакторы и менеджеры.
Само наличие этой доски важно: карточки, связанные с формализацией задач проходят собственный цикл, а на доску разработки приходят уже полностью готовыми. Разработка не останавливается из-за того, что нужно уточнить какие-то требования.
Когда требование готово, оно попадает в колонку Ready for Coding, и специалист ставит дату его реализации в продакшене. На этом этапе очень важно провести авторский надзор и подкрутить качество уже выпущенной функции, сверить её с требованием, дизайн-макетом и ТЗ.
✔️ Features
На этой доске работают разработчики, тестировщики, тимлиды и все, кто отвечает за конкретные фичи. Тут только технические, полностью формализованные и описанные задачи.
Они делятся на 3 группы по приоритетности:
- Срочные: ошибки на бою, задачи, прилетевшие от условного генерального директора, и др.
- Задачи к сроку: например, из-за выпуска нового закона Центробанка нужно решить какую-то задачу к определенной дате, и сдвинуть эту дату нельзя.
- Стандартный сервис: задачи, которые делаются в порядке очереди в соответствии с WIP-лимитами и пропускной способностью команд.
- Время от времени мы слышим мнение, будто чем раньше разработчик приступил к задаче, тем быстрее он ее закончит. Опыт доказал обратное: если разработчик берет сырую задачу, у него то и дело возникают вопросы. Ответить на них бывает сложно. Все уже забыли, откуда взялась задача, в чем ее важность и почему срок именно такой. Суть трех досок в том, что каждая задача была провалидирована, подробно описана, обдумана и только потом пришла в производство.
Когда задача переходит в статус To Do на доске разработки, происходит так называемый Commitment Point. Это значит, что компания берёт на себя обязательство как можно быстрее выполнить и сдать задачу. Срок исполнения задачи отсчитывается с этого момента, а не с момента, когда менеджер ее обсудил с заказчиком.
Еще один важный момент. Все задачи разных команд стекаются на доски руководителей цехов в соответствии с их типами. Например, все задачи по аналитике руководитель отдела аналитики видит на своей доске. Это позволяет ему оптимизировать процесс производства.
Исчерпывающие чек-листы
Второй важный компонент Agimaban — регламентация и документация процесса от и до. У нас почти не осталось процессов, которые мы не продумали и не описали. И все регламенты разбиты на чек-листы, которые на дают нам ни про что забыть.
Чек-листы бывают 2 типов:
В нашем таск-трекере к каждой задаче можно крепить вот такие списки:
- DoR (Definition of Ready) — те условия, при которых задачу можно быть взята в работу;
- DoD (Definition of Done) — условия, при которых стадия считается выполненной.
В нашем таск-трекере к каждой задаче можно крепить вот такие списки:
Это чек-лист на доске с требованиями, он прикреплен к некоторым задачам дизайнеров. Задача не будет считаться готовой, пока все галочки в этом списке не будут проставлены.
- Например, если раньше мы часто забывали отрисовать страницы ошибок, то теперь это невозможно. Задача не будет считаться сделанной, ее нельзя будет передать дальше по циклу. Другой пример: задача после формализации должна быть провалидирована заказчиком и тимлидом. Если тимлид считает, что подробностей в задаче недостаточно, галочку мы не поставим. А значит, задача не пойдет в разработку. Такими чек-листами охвачены почти все задачи.
Все чек-листы мы бережно храним в нашей базе знаний. Менеджер проекта или руководитель направления может быстро провалидировать любую задачу, просто пройдя по списку в Wiki или таск-трекера. Если чего-то не хватает, мы это сразу заметим благодаря чек-листу.
Вот пример чек-листа по созданию дизайн-концепции.
Чек-листы мы постоянно меняем или дополняем, если чего-то не хватает и что-то не работает. В этом помогают ретроспективы, другие регулярные встречи и метрики. Мы всё время анализируем процесс, чтобы понять, как его улучшить. Это одна из практик Kanban-метода.
Как мы работаем с досками
Каждая колонка на доске в любом из сервисов — это отдельный этап накопления знаний о задаче. Чем тикет правее, тем больше по нему знаний накоплено. Двигаться задачи могут только слева направо.
Даже когда тестировщик возвращает задачу на доработку, она не может улететь назад. Вместо этого она остается в той же колонке, для нее мы создаем подзадачу типа Fix. Это важное требование Kanban-метода: задача прошла по доске, накопила информацию и обнулить этот процесс мы не можем. Исключения из этого правила случаются редко и только если в процессе была допущена ошибка.
На схеме основные маркеры и пометки, которыми мы пользуемся:
На схеме основные маркеры и пометки, которыми мы пользуемся:
Задачи на доске мы именуем определенным способом:
[практика/функция: компонент] + имя фичи
Практика/функция — это чаще всего тот артефакт, над которым мы работаем: API, ТЗ, верстка и т. п.
Компонент — это элемент архитектуры: iOS, Mobile, Web и т. п.
Наши задачи на любой доске выглядят примерно так:
- [Back-end: Mobile] Пополнение баланса.
- [Front-end: Web] Главная страница.
- [Дизайн: Mobile] Экран «Счет карты».
Как мы контролируем качество
- Мы собираем статистику по всем задачам, которые связаны с нашим внутренним тестированием. Все баги, которые нашел техлид или QA-команда, заводятся в конкретный таск. Так мы можем отслеживать динамику багов по каждой задаче и исполнителю.
- То же самое делаем с клиентской приемкой. Это баги, которые просочились несмотря на проверку техлида и QA, их мы тоже отслеживаем. На каждой встрече с заказчиком (обычно раз в квартал) смотрим на динамику регрессии внутренних тестирований и на динамику багов, которые нашел заказчик.
- Мы отслеживаем Lead Time — время от появления задачи до ее полного выполнения. Нам нужно выполнять задачи не только качественно, но и быстро в рамках тех же ресурсов. Так мы повышаем эффективность часа и возврат инвестиций в команду.
- Например, мы развиваем большой сервис по уходу за домашними питомцами, интегрированный с разными системами. На стороне клиента нет никого из технической команды, на их стороне только продакт-менеджеры. Они взаимодействуют с нами, как с черным ящиком, — не влезают в сам код. А мы на цифрах обосновываем качество нашей работы. Так мы уменьшили Lead Time.
- На графике видно, что в абсолютном большинстве кейсов в течение 14 дней мы решали все задачи, которые попадали в «to do» клиента. Большая часть задач решается быстрее, но в 85% случаев все задачи попадают в это окно. Это говорит о том, что мы можем подписываться под такой SLA по поставке. Он обусловлен не нашими фантазиями, а реальной производительностью системы.
Почему мы полюбили Agimaban
Самый очевидный ответ — потому что мы его придумали. Но на самом деле всё гораздо интереснее.
Что нам дает Agimaban:
- Мы сокращаем Time to Market. Чем лучше формализована задача, тем быстрее разработчик напишет код. Чем подробнее чек-боксы, тем менее вероятно, что мы забудем про какие-то артефакты. Логика такая, и она работает. Средний показатель Lead Time сократился с 120–130 дней до 80. Мы хотим сократить его до 50.
- Мы делаем процесс предсказуемым. А предсказуемость — это хорошо. Теперь мы предсказываем сроки исходя из статистики, а не на пустом месте, точнее называем цену заказчикам и реже выходим за бюджет.
- Мы быстрее подключаемся к проектам. Раньше на старт нового проекта могло уходить 2 месяца: это рабочие моменты, подписание бумаг, внедрение регламентов и правил работы. Теперь это проходит вдвое быстрее.
А еще подписывайтесь на наши телеграм-каналы: один посвящен управлению проектами, другой — проблемам (и их решению) агентского рынка. Там мы рассказываем, какие подходы и инструменты вообще существуют.
Комментарии и обсуждения статьи на habr.
Комментарии и обсуждения статьи на habr.