В поисках эффективности: как мы внедряли Kanban и Trello
Любая компания на стадии роста сталкивается с рядом типовых проблем. Как правило, они связаны с тем, что методы управления, которые применялись ранее, перестают быть эффективными для организаций большего размера. Это в первую очередь влияет на взаимодействие между людьми и командами. Если ваша компания растет, а вы все чаще слышите от сотрудников «делаем», «в процессе», «у меня другая задача», «не знаю, успеем ли» — поздравляем, у вас болезнь роста, и вам пора что-то менять.
Когда я столкнулся с такой ситуации на своем опыте, решение проблемы, как это часто бывает, пришло спонтанно. В разговоре со своим другом-программистом я узнал об интересном инструменте для организации работы команды — Trello. Визуализация задач, простая работа в команде, стикеры, метки, тэги и кучи всяких «вкусняшек» — звучало как что-то, что стоит попробовать.
В тот же вечер я решил просмотреть нескольких видео-обзоров о Trello и сделал свой первый шаг в мир Agile. Для дальнейшего чтения статьи рекомендую просмотреть, как минимум, официальный видео-обзор Trello.
Открытие Kanban
О гибких методологиях управления проектами, Scrum в частности, я слышал и ранее, но особо не углублялся в их суть, полагая, что они больше касаются команд разработки и не совсем подходят для маркетинга и продаж. Я ошибался.
Первый же материал, найденный в Интернете, а именно «10 Kanban досок и контекст» наглядно показал, что методологию можно смело использовать, как в работе программистов, так и продавцов, маркетологов, ребят из службы технической поддержки. Вопрос только в том, сможете ли вы настроить систему под свои потребности.
Еще один материал окончательно и бесповоротно поставил меня на путь «гибкости»: «Scrum и Kanban: выжимаем максимум».
Что же такое Kanban? Я не претендую на звание agile-мастера и «теоретика» систем управления. Мои формулировки и понимание принципов данного подхода — это гремучая смесь прочитанного и уже испробованного на практике.
Kanban — методология управлению производством, проектами, наиболее гибкий из подходов Agile, в основе которого лежат несколько принципов, которым необходимо следовать.
Во-первых, Kanban — это вытягивающая система. Спрос на задачи, производственный заказ, формируется исходя из возможностей производственной единицы (специалиста, отдела). Из этого положения вытекает принцип, о котором все много слышали, — «just in time», или точно в срок. Не имеет смысла ставить больше задач, поставлять/выталкивать больше деталей на следующий этап производства, чем их могут обработать команды, люди в заданный период времени.
Например, вы, конечно же, можете выдать пул задач/ТЗ для вашего дизайнера и подбрасывать еще по одной задаче в день, но имеет ли это смысл, если вы знаете, что на выполнение одной задачи дизайнером в среднем уходит 2 дня? Таким образом, вы будете «складировать» задачи в то время, как вместо создания запаса могли бы выполнить другую работу.
Во-вторых, цель Kanban, как и всех гибких методов — обеспечить скорейшее завершение, то есть получение результатов работы команд, компании в целом. Для этого Kanban предлагать ввести единственное ограничение — объём незавершенной работы для команды, человека. Если концентрировать внимание на ограниченном количестве задач в заданный момент, которые необходимо довести до конца, вы регулярно будете получать результат работы в виде готового продукта.
Это ограничение логично исходит из того, что специалист в данный момент времени может выполнять только одну задачу. Конечно, задач в процессе может быть и больше: это задачи, которые «зависли» и ждут вмешательства другого специалиста, либо по процессу требуют «зависания». Пример: компиляция кода может занять несколько часов, в это время программист выполняет другую задачу — две задачи находятся в процессе выполнения.
В Scrum это ограничение находит свое выражение в Product Backlog, когда команда должна закрыть пул задач, и без закрытия пула двигаться дальше запрещено. В Kanban не обязательно создавать Product Backlog и ограничивать команду определенным списком задач. Kanban ограничивает количество задач в процессе для команды, человека, подталкивая команду к непрерывному процессу поставки достигнутого результата.
Несколько слов о Trello
Как я уже сказал, мое познание Kanban началось с Trello. Trello — это инструмент для управления задачами, который позволяет организовать работу команд вокруг проектов и задач, а также визуализировать данную работу.
В интернете вы найдете множество видео-обзоров и статей о Trello. Практически во всех материалах авторы акцентируют внимание на таких возможностях продукта, как:
— Быстрое создание задач, где задача — это карточка с описанием, возможностью приложить файл, назначить исполнителей, поставить дедлайн, тэгировать задачу;
— Удобное управление командами проекта путем приглашения людей в команды;
— Визуальная привлекательность карточек задач, списков задач, проектов — с системой приятно работать;
— Простота и легкость, с которой можно «перетягивать» задачи по процессу «вперед-назад»;
— Минимальный барьер входа — начать работать может кто угодно, вне зависимости от уровня компьютерной грамотности и опыта управления ПК.
Список можно продолжать. Я бы подчеркнул то, что Trello — это супер-гибкий инструмент. Вы можете настроить и организовать свою работу и работу своей команды, как вам будет угодно.
Внедрение Kanban/Trello
Учитывая гибкость методологии и инструментов, шансы на провал я оценил как минимальные, поэтому, фактически на пятый день знакомства с данными инструментами я обрадовал свою команду, что теперь мы будем делать все по-другому :).
Чего я хотел достичь? Цель, которую я определил для себя и команды на первом этапе — это «улучшить взаимодействие проектов и команд компании с отделами дизайна и веб-разработки».
Ранее в компании все проекты взаимодействовали с двумя независимыми подразделениями: дизайна и веб-разработки. Маркетинг и продажи каждого проекта напрямую зависели от оперативности работы данных подразделений. С учетом того, что количество людей и задач с ростом компании фактически удвоилось, между руководителями проектов часто начали возникать «бои за ресурсы», когда каждый менеджер пытался «протолкнуть» свою задачу вперед, часто не имея понятия о загруженности отделов, их приоритетах и возможностях поставки результатов в срок. В отделах дизайна и веб-разработки это приводило к напряженности и частому возмущению в стиле «вам всем необходимо срочно, так что же более срочно?».
Перед тем как начать работу с Trello по технологии Kanban, я собрал тестовую группу ребят
После ознакомления с целями изменений и инструментами я создал каждому проекту свою доску, где обязательными вначале стали 3 листа/списка задач: To do, In progress, Done. Для команд дизайна и веб еще одним обязательным списком стал лист Testing, как часть задачи в процессе, которая требует обратной связи перед тем, как попасть в Done или опять вернуться в In progress.
При этом я не вводил никаких ограничений сразу по количеству задач для команд. Добавляйте столько задач, сколько вы хотите. Сделал я это, чтобы спустя определенное время увидеть текущую картину по задачам.
Для удобства, учитывая, что состав команд был небольшим, я также предложил разнести задачи «In progress» по конкретным людям, где будут созданы списки «Ник: in progress». Конечно, если речь идет о командах 4 человека и больше, это уже не совсем удобно, доска получается очень широкой. Но в варианте с отдельными списками In progress для каждого человека понимание загруженности людей еще больше увеличивается.
Правила создания и управления задачами, которые мы выработали для тех, кто начал работать с Trello, выглядели так:
1) Новая задача попадает в список «to do» для дизайнеров или веб-разработчиков только если она имеет ТЗ;
2) Задача попадает в «in progress» только благодаря исполнителю, который ее вытягивает из списка «to do»;
3) Задача может быть переведена в список «done» только тем, кто создавал задачу;
4) Все задачи должны иметь обязательные атрибуты: метка (к какому проекту относится), описание результата, назначенного к выполнению специалиста, срок;
5) Оценочная длительность задачи не должна быть больше 3 дней. Если задача занимает больше 3 дней, ее необходимо разбить на подзадачи;
6) Все коммуникации по задаче должны вестись в виде комментариев к задаче в конкретной карточке, исключается Skype, почта, другие мессенджеры.
Чтобы мотивировать людей работать с новой системой, я ввел систему мотивации — тот, кто идеально закрывает задачу в Trello и хорошо справляется со своей работой, получает «звездочку», 5 звездочек = премия в конце месяца.
Итак, мы начали работать с Trello. Вы спросите меня, а где же здесь командное взаимодействие, если для каждой команды была создана отдельная доска команды? Кто ставил задачи на доску дизайнеров и веб-разработчиков? Вокруг чего строится взаимодействие команд?
Эти вопросы мы решили очень просто. Все задачи для дизайнеров или веб-разработчиков ставятся и выполняются только на досках соответствующих команд. Например, если контент-менеджеру украинского направления необходимо создать иконку для e-mail рассылки, контент-менеджер идет на доску дизайна и создает там отдельную задачу.
Самый показательный пример того, как организована работа вокруг комплексных задач — это создание страницы сайта. Процесс создание страницы сайта можно разбить на несколько этапов или подзадач:
1) Создать ТЗ;
2) Дизайн;
3) Верстка.
Мы не дробили этапы и задачи на более мелкие и приняли следующую схему:
1) Менеджер проекта/задачи создает на доске своего проекта задачу с подзадачами — Trello для этого случая позволяет создавать внутри задачи дополнительные перечни.
2) Когда менеджер поместил задачу в прогресс и создал ТЗ, он видит, что следующий этап работ — это дизайн, соответственно он берет и создает отдельную задачу на доске дизайнеров — Создать страницу, прикрепляя к ней ТЗ.
3) Когда задача будет выполнена дизайнерами, он получит уведомление и сможет поставить галочку возле «Дизайн» на своей доске и создать отдельную задачу на доске веб-разработчиков — «Сверстать страницу».
Таким образом, менеджер контролирует выполнение задачи или проекта, ставя подзадачи специализированным командам и отмечая на своей доске ход выполнения общей задачи. Это может звучать сложно, но на практике, все довольно просто, особенно, если учесть, что в Trello можно при постановке задачи поставить ссылку на другую задачу.
Постепенно к Trello в течение 2 недель были подключены все команды и проекты. На совместном собрании было принято решение об оптимальном ограничении количества работ в «In progress» для каждой команды. Первый этап внедрения был завершен. Через 4 недели мне предстояло сделать срез результатов внедрения.
Результаты и выводы
Если вы захотите внедрить у себя Trello, хотя это касается и любого другого инструмента, будьте готовы, что 50% вашего рабочего времени должно уйти на контроль и корректировку того, как работают с новой системой люди. Не полагайтесь, что все заработает без вас. Хорошо, если у вас появятся ярые приверженцы системы, которые подхватят инициативу и понесут ее «в народ».
Фактически с первого дня работы Trello очень наглядно показал:
— Реальную загрузку каждого человека в команде;
— «Узкие» места компании — на каком этапе происходит торможение проекта, у кого контейнер задач переполнен, а кто еще может «пить кофе»;
— Умение или неумение людей корректно ставить задачи в письменном виде.
Сведя все коммуникации вокруг задач в единое поле — карточку задачи, мы фактически сразу же перестали общаться в других каналах, задачи и подзадачи перестали теряться в потоках сообщений, все стало более заточенным под рабочий процесс. Я, менеджеры, все мы вместе начали понимать, стоить или не стоит создавать новые задачи и забрасывать их в другие отделы. При этом абсолютно очевидным стал тот факт, что прозрачность работы всех команд, четкость и ясность в коммуникациях, ограничение работы в прогрессе привели к повышению продуктивности.
Через месяц после внедрения Trello и Kanban я провел опрос участников новой системы, задав несколько вопросов, ключевым из которых был:
Цель первого этапа была достигнута — спустя месяц работы с Trello по системе Kanban практически все участники позитивно оценили влияние новых инструментов на командную работу.
Еще один вопрос, который касался работы в самих командах, тоже показал позитивное влияние изменений:
Конечно, не опросами едиными. Для оценки внедрения любой системы необходимо использовать более объективные, количественные показатели: время, объем завершённой работы, финансы. По моей предварительной оценке, каждый из показателей, особенно объем завершенной работы, вырос в полтора раза с момента внедрения новой системы, но это нам еще предстоит измерить. А пока впереди еще много работы.
