×Закрыть

В поисках эффективности: как мы внедряли 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, я собрал тестовую группу ребят (5-7 человек) и презентовал им систему, показал, как работать с задачами в Trello, объяснил, что это нам даст. Не могу сказать, что все были в восторге от идеи работать с новым инструментом, но явных противников не было. Все понимали, что пришло место заменить таблицы Google, OneNote, Bitrix единым инструментом управления задачами.

После ознакомления с целями изменений и инструментами я создал каждому проекту свою доску, где обязательными вначале стали 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 практически все участники позитивно оценили влияние новых инструментов на командную работу.

Еще один вопрос, который касался работы в самих командах, тоже показал позитивное влияние изменений:

Конечно, не опросами едиными. Для оценки внедрения любой системы необходимо использовать более объективные, количественные показатели: время, объем завершённой работы, финансы. По моей предварительной оценке, каждый из показателей, особенно объем завершенной работы, вырос в полтора раза с момента внедрения новой системы, но это нам еще предстоит измерить. А пока впереди еще много работы.

LinkedIn

10 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Ось ще один інструмент схожий на Trello — KanbanFlow kanbanflow.com, дозволяє трекати час на виконання завдань.

Эта затея сработает только на малых проектах и с людьми которые требуют большой доли контроля над ними. В случае когда система плоская, когда нанятый персонал не требует надзирателя с дубиной, а задача может спокойно иметь цикл и месяц, и полгода — вся эта «визуализация» неизменно УБИВАЕТ контроль.

Результат — ужесточение контроля, автоматические (даже если выполняемые человеком) менеджерские функции, и канбан становится катализатором бюрократической смерти. Задачи режутся так, чтобы давать наилучшую картину, а ставятся так чтобы впихнуть невпихуемое и просто нарезать план, иначе говоря раскидать ответственность и самоустранить ответственность руководства.

Канбан — опасная вещь. Прежде всего потому, что он устраняет человеческий фактор. Иначе говоря, руководить канбанами нужно УЧИТЬСЯ, и нельзя доверять тем кто не является неформальным лидером. Иначе говоря, канбан требует институции лидерства, а если таковой нет — становится убийцей такового, и вырождает основу предпринимательства: риск.

Всегда было ощущение что Scrum для тех, кого не нужно мотивировать (гнать дубиной) делать ту работу, за которую ему платят. Канабан не убивает контроль, а помогает не тратить усилия в неизвестных направлениях и строить метрики, без которых контроль не возможен по определению.

Как раз наоборот. Скрам — для тех, кто нуждается в стрессовой ситуации, и соответственно для руководителей которые считают своей ролью таковую создать. Канбан наоборот — начисто снимает стрес с системообразующих элементов, и этим склоняет систему в глупость.

Канбан опасен своей простотой. Он не говорит, когда нужно иметь резервы, а потому момент их истечения становится переломным: в расход идёт обратная связь и прочие атрибуты человеческого фактора, и вместе с их утратой — разрушается равновесие власти и полномочий.

То есть канбан не имеет системы иммунитета. Её нужно создавать отдельно, и контролировать показатели канбана нужно отдельно, не становясь частью системы, не используя её нативных методов. Дргуими словами, роль обратной связи переводится вверх, обратная связь становится дорогим удовольствием, и по большому счёту нужен ИССЛЕДОВАТЕЛЬ, который будет анализировать что происходит. Фактически, это человек с полномочием стратегического руководства, но положением в иерархии на уровне руководства младшего звена. Правильнее всего назвать его агентом. Если на это руководство способно — система обретает потрясающую стабильность и приспосабливаемость к любым условиям. Но стоит лишь раз недооценить роль агентов, взять на эту работу не тех людей, или не так мотивировать, не тем людям отдать в подчинение — и бюрократия уже неискоренима.

Такова «прелесть» всех систем, строящихся по принципу инверсии управления. Но выгода их в существенной экономии ресурса: процес становится управляемым на самом нижнем уровне, оставаясь простым для наблюдения на верхнем. Верхний же уровень имеет защиту от ошибок: система, построенная на равновесии, немедленно даст понять об ошибке, потребует усилий на коррекцию, и так руководство получит понимание о цене риска, прочувствует цену ошибки.

Ключевая проблема в том, что нужно хоть раз выйти на эту точку равновесия. Если она не достигнута, то повышенные затраты на руководство будут считаться нормой, как и подделка ключевых показателей, и в итоге — ложь, наглая ложь и статистика.

Скрам — для тех, кто нуждается в стрессовой ситуации, и соответственно для руководителей которые считают своей ролью таковую создать.
Вообще не похоже на тот скрам по которому доводилось работать, а потому по которому доводилось: команда определяла объем работ нужный для историй, команда могла рсширять время на выполнение для включения нефукциональных требований и упрощения будущих разработок, команда могла создавать отдельные истории, дробить, обединять, создавать задачи, менеджер, же, только определял приоритеты, мерял продуктивность, улаживал конфликты в команде. Проект был удачным, истории сдаваль вовремя, заказчики остались довольны.

Я не спорю, что в умелых руках скрам работает. Лишь ставлю фактом, что эта система соблазняет злоупотребить властью, и в случае стресса руководителя (а заказчик это умеет, и его руководство это умеет) — просто таки шепчет на ухо «надави на этих зажравшихся лентяев», «давай заставим этих скотов почувствовать кнут».

Проблема резерва в Канбане решается полосочкой Критических задач. Да просто, но это всегда было оправдано.

Я не говорил, что проблема нерешаема. Или что эти решения сколь-либо сложны. Канбан завоевал мир, наверно же он работает и работает хорошо?

Я говорю лишь о том, что Канбан настолько упрощает, что позволяет менеджерам поверить что всё на самом деле просто, и упустить те моменты которые система не покрывает. А это прежде всего человеческий фактор.

Почитайте Дао Тойота на досуге, будет много открытий

Подписаться на комментарии