Как за 1,5 месяца наладить стабильный поток задач, снизить время поставки и научить команду работать с удовольствием

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

«Зачем нам Jira?»

На старте одним из главных запросов от руководителя была задача — научить команду работать с Jira: сделать ее использование понятным и единообразным для всех участников процессом. В реальности картина выглядела следующим образом: в Jira было заведено 4 столбца: Backlog, To do, In progress и Done, где рандомно появлялись задачи. Автор мог составить описание на свое усмотрение, отсутствовали конкретные критерии готовности (Definition of Done, DoD), ну и вишенка на торте: была неизвестна судьба задачи в столбце Done (возможно, ее уже залили на прод, или она требует проверки со стороны тимлида, или в ней есть ошибки, которые надо устранить, на самом деле или всё прозаичнее — про нее просто благополучно забыли). Отдельная неразбериха творилась с эпиками: их могли создавать все участники команды, без учета объема и понимания, что относится к этой категории работ. 

Как вы уже поняли, в таком виде Jira вызывала единственный вопрос: «А зачем нам это надо?». В свою очередь никто не знал ответов на мои вопросы: «Сколько времени занимает выполнение разных типов задач? С чем связаны задержки? Как распределяется загрузка в команде?».

По сути, Jira была введена директивно, никто не объяснял команде, как пользоваться, по каким правилам, чем это может помочь, соответственно у ребят не было мотивации разбираться и погружаться в детали.

Исследование процессов на старте

В течение месяца я разбиралась с внутренними процессами в компании, провела 1-1 с каждым участником команды и серию встреч с руководителями и даже сформировала специальный опросник, где просила оценить важность Jira, эффективность коммуникации, прозрачность процессов, сроки и приоритизацию задач. Всё это было необходимо, чтобы максимально точно и объективно определить текущее положение дел и ожидания компании относительно моей работы.

Полученные выводы подтвердили мои собственные наблюдения: 

— сильный разрыв между созданными и решенными задачами: количество запросов в 3 раза превышает пропускную способность команды;

— низкая прозрачность процессов:

• нечеткие сроки и статусы,
• не все задачи попадали в Jira, некоторые «жили» на досках других департаментов,
• отсутствует описание задач и критерии приемки,
• высокий средний возраст задачи — 22 дня 4 часа,
• неровная загрузка команды (нет понимания, сколько задач выполняет каждый специалист в текущий момент, плюс ребята не забирали имеющиеся задачи из бэклога, а просто ждали входящих запросов);

— низкая мотивация по использованию Jira, отсутствие вовлеченности и инициативы в рамках встреч команд.

Работа в Jira: как, зачем и по каким правилам

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

Затем я предложила ввести дополнительные столбцы и сформировать понятные и четкие правила работы в Jira: 

— добавили столбец Ready/Готово к работе, сюда относятся задачи, готовые для принятия в работу. Эти задачи должны быть актуальны, декомпозированы и иметь критерии приемки. По сути, это своеобразный бэклог спринта, некая точка принятия обязательств для команды.

— добавили столбец «На рассмотрении» (перед Done). Здесь находятся задачи, которые выполнены командой, но еще не проверены. Напомню, что раньше после перемещения из In progress в Done судьба задачи была очень туманной, никто не знал, что конкретно с ней происходит дальше. 

— добавили горизонтальный swimlane для срочных задач. В компании были кейсы, когда срочные задачи попадали в Backlog, там умирали, а нерешенные ошибки приносили большой урон системе и репутации компании.

— сформировали и утвердили правила по ведению Jira:

• Все задачи, кроме 2-ой линии поддержки (масштабирование на Service Desk было решено провести позднее), фиксируем в Jira.

• Завершенную задачу не восстанавливаем, создаем новую. Это очень важный момент! В каждую задачу вложена определенная бизнес-ценность, финансовые и временные ресурсы, возвращая задачу обратно, команда фактически обнуляет собственные усилия и уже потраченные бюджеты. 

• Вводим критерии приемки для задачи. До этого задача могла беспорядочно мигрировать от Backlog к Done и обратно, обрастая на этом пути новыми требованиями и превращаясь в необъятного монстра, к которому непонятно, с какой стороны подступиться, потому что на старте не были описаны конкретные требования, а заказчик как будто всё больше входил во вкус — ему хотелось еще больше и лучше. 

• Отмечаем блокеры на задачах флажками. Задача могла висеть неделями без опознавательных знаков, и только во время статусных встреч можно было понять, что причина не зависит от команды, а связана с внешними обстоятельствами (работа других департаментов, поставщиков и т.д.).  

• Обозначаем цель для задачи. Общаясь с ребятами в рамках 1-1, я очень часто слышала, что им непонятно, зачем они это делают, какие проблемы это решает и какая впереди конечная цель. Отсутствие понимания и прозрачности в коммуникации резко снижали мотивацию и вовлеченность команды. 

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

• Отмечаем ответственного к задаче. Плюс одно очко Гриффиндору к прозрачности: указываем автора, исполнителя и ревьюера.

— определили, что такое эпик (Epic). Напомню, что на старте с ними была отдельная проблема: их создавали все и на свое усмотрение. Вместе с руководителем и лидами мы утвердили общее понимание, что это большой скоуп работ, который затем можно разбить на задачи, например, перенос базы данных из одной системы в другую. Утвердили описание и критерии, а после поделились этим с командой и договорились, что эпики могут создавать только лиды или руководитель.

Если вы дочитали до этого абзаца, то точно любите полезный контент про современные практики управления. Еще больше материалов, видео и экспертных советов от Agile-коучей, анонсы бесплатных вебинаров и митапов в Телеграм-канале ScrumTrek

Внедряем регулярные встречи

До моего прихода в компанию встречи носили нерегулярный характер, назначались в рандомные дни и время. Но самое главное — команда была очень слабо вовлечена в сам процесс обсуждения. Обычно это выглядело так: выключенные камеры, тимлид общается с участниками в режиме вопрос-ответ, говорят только двое, остальные просто ждут, когда прозвучит их имя в эфире. Казалось, что кроме тимлида, никто не понимает, что происходит в целом, есть ли какие-то пересекающиеся задачи и зоны ответственности, трудности, которые нужно обсудить командой. Т.е. о полноценной коммуникации речи не шло.

Статусные встречи

Поэтому на первом этапе я предложила проводить общие статусные встречи дважды в неделю (позднее на ретро вместе с командой мы подобрали другой формат — об этом расскажу ниже) и внедрить обязательные для всех участников правила встреч: 

• На статусных встречах идем по Канбан-доске справа налево, фокусируясь на вопросе: что нужно сделать, чтобы закончить задачу?
• Вносить изменения в доску Jira во время встреч. Мне было очень важно приучить команду фиксировать все договоренности: мы не просто встречаемся, чтобы поболтать, мы обсуждаем и принимаем решения, которым будем следовать дальше. И когда мы уходим со встречи, эти договоренности никуда не исчезают. 
• Встречаться регулярно, в одно и тоже время.
• Включенные камеры. Для этого пункта руководитель даже закупил камеры всей команде — и сразу все почувствовали изменения: ребята стали более открытыми, активнее включаться в процесс, появились свои фишки, шутки. Наконец, коммуникация стала живой, непосредственной.
• Тайминг. Изначально было сложно соблюдать этот пункт, потому что ребятам нужно было научиться проводить встречи правильно, сделать их действительно полезными. Сейчас этой проблемы нет, мы всегда укладываемся в заявленный тайминг — команды хорошо чувствуют темп, содержание, после каждой встречи мы фиксируем результаты и договоренности, команды понимают, в чем смысл и ценность такого мероприятия, что им важно обсудить. 
• Парковка (чат, куда можно присылать вопросы). В реальности пользуемся редко, команды приходят с вопросами на статусные встречи.  
• Уважительный тон встреч (проявляем уважение к коллегам). Кажется, очевидным, но как и в любой команде были исключения, из-за чего некоторые ребята ощущали дискомфорт, были более закрытыми и отстраненными. Именно поэтому я решила отдельно подсветить эту проблему, зафиксировать в качестве самостоятельного пункта и призвала всех максимально придерживаться этого правила на встречах.
• Здесь и сейчас (отвлекаться только, если срочно).

Первая ретроспектива

Первая ретроспектива в этой компании оказалась очень непростой. И после этого мероприятия мне очень помогли встречи, которые регулярно проводит ScrumTrek. В рамках таких интервизий мы встречаемся и обсуждаем разные вопросы, которые «болят», их нужно разобрать и извлечь уроки.

На мой взгляд, основные причины, почему ретроспектива оказалась серьезным испытанием, были в следующем: 

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

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

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

Перед началом мероприятия я вынесла на доску все трудные моменты, которые мне удалось выявить в рамках исследования и в ходе 1-1 с каждым в команде. Дальше на этапе обсуждения я разбивала участников по двое, чтобы у всех была возможность высказаться и обозначить свою точку зрения. Каждую проблему мы разбирали в 3 этапа: подсвечивание, обсуждение (почему эта проблема возникла) и варианты ее решения.     

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

— мы сформировали 2 важных материала: 1) документ, регламентирующий виды и структуру мероприятий и правила встреч, и 2) документ, содержащий критерии ведения и создания задач в Jira. Здесь мы максимально подробно определили, как задача должна быть описана, чтобы она была понятна и автору, и исполнителю, чтобы избежать возможного недопонимания (точная формулировка, чек-лист, критерии готовности, срочность, возможные риски и т.д.) Документ живой, он постоянно пополняется и изменяется. 

— команды выбрали более подходящий для них вариант статусных встреч. Проблема была в следующем: в компании существует 2 подразделения (Windows и Linux), и общие статусные встречи, на которых команды не слишком разбираются в процессах друг друга, выглядели неэффективными. Было решено проводить регулярные статусные встречи по Windows- и Linux-направлениям отдельно, но при этом лиды присутствуют на обоих звонках — это позволит выявить смежные задачи и не слишком сепарировать 2 подразделения.

— было решено проводить планирование и ретро 1 раз в месяц, от отдельного ревью команда отказалась в пользу прямой обратной связи от тимлида.

Итого за 1,5 месяца мы провели 18 статусных встреч, 1 ретро и 1 планирование.

Подводим итоги

Спустя полтора месяца вместе с руководителем мы решили измерить, как меняется ситуация и есть ли уже первые результаты. Очевидно, чтобы получить более стабильные данные, требуется больше времени, и тем не менее мы увидели хорошую положительную динамику и более понятные и предсказуемые рабочие процессы:     

— сократился разрыв между созданными и решенными задачами. Напомню, что в начале это был настоящий хаос: было непонятно, что происходит с задачей, на каком она этапе, что тормозит ее движение по доске. Сейчас разрыв составляет не более 10% в пользу созданных задач. 

— средний жизненный цикл задачи составил 9 дней 5 часов против 22 дней 4 часов в начале, только 24 задачи из 211 выбились из стандарта в силу других причин, независящих от команды, например, задержки поставок, отсутствие DoD и т.д.

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

— снизилось время поставки от бэклога до внедрения: 50% задач было решено за 3 дня и 3 часа.

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

Что дальше

Наладив основные процессы, вместе с командой мы решили идти дальше. Ниже список из нескольких направлений, которые были обозначены в качестве приоритетных. Я разделила их на несколько блоков:

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

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

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

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

Мне очень хотелось поделиться этим кейсом, чтобы вдохновить тех, кто только начинает менять процессы внутри компании и, возможно, испытывает недостаток опыта, как было со мной в начале. Я знаю, о чем вы думаете: «Всё сложно, запутанно, кажется, никто не верит в успех, кроме меня». Изначально моя команда не понимала, зачем нужны все эти инструменты и, что уж кривить душой, зачем нужна я. Результаты, которых удалось добиться всего за 1,5 месяца активных изменений, действительно впечатляют. Конечно, нам предстоит еще закрепить успех и впереди много работы, но меня очень мотивирует настрой ребят. После подведения первых итогов они захотели идти дальше вместе со мной, а это значит, что мы на правильном пути.