Михаил Вязанкин ( mihey911 )

Я расскажу вам историю про одну перегруженную команду.

У нас была команда, не очень большая, 20 человек высококвалифицированных специалистов — разработчиков, тестировщиков, DevOps. У этой перегруженной команды была дюжина заказчиков, в основном, внутренних. Эта дюжина заказчиков постоянно дралась за приоритеты. Для команды это большой стресс, напряженность, команде не понятно, что будет дальше — каждый день может какая-то новая бизнес-задача прилететь. В таких условиях Scrum, который два года у них работал и к которому они привыкли, начал ломаться, commitment (то, что они обещали сделать на спринт) они сделать уже не могли, потому что прибегал кто-то очень важный и хотел что-то очень ценное. А ценное — это деньги, их делать надо.

И команда от этого устала, и готова была меняться. Это важное условие.

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

О себе. Программировать я начал в 11 лет. В профессиональном IT работаю уже больше шести лет, из которых три года я — менеджер. Работал в нескольких компаниях, управлял проектами от маленьких до больших, самые большие — порядка 40 человек в команде. Последние годы увлекаюсь Agile-методологиями, активно интересуюсь тем, как это все можно оживить, что можно из этого сделать, различными исследованиями, экспериментами.

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

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

Первое — нам нужно было не потерять мотивацию, потому что тяжело, напряженно, люди начинали уставать. Нужно было им сделать просто, легко, чтобы им было работать в кайф. Естественно, отсюда вытекает, что нам нужны были понятные приоритеты.

Понятные приоритеты — это самая болезненная часть. Как оказалось, мало, кто знает, как сделать приоритеты понятными.

Из этого следующая цель — нам нужна предсказуемость.

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

После того, как мы определили цели, для того чтобы понять горизонт, куда мы хотим прийти, нам необходимо было более детально понять, как оно будет, и что именно мы будем делать, чтобы этих целей добиться? Т.е. у нас были какие-то условные показатели, которых мы хотели достичь, и варианты конкретных действий.

Так, мы могли пофиксить тот Scrum, который был. К примеру, commitment ребята не соблюдали — из-за приоритетов не делали то, что обещали. Мы могли взять и начать учить их этот commitment соблюдать — потратить кучу сил и нервов, внешние условия не изменились бы, а ребята бы пыхтели и страдали… Мы все делали бы по Scrum, но неизвестно, что из этого получилось бы.

Мы могли собрать из кирпичиков что-то новое, т.е. выкинуть Scrum и сказать: «Ребята, давайте свой процесс из головы придумаем». Тогда увлекались такой интересной штукой, как Essence от института SEMAT. Мы его использовали не так, как этот институт хотел его использовать, а больше обращались к нему как к справочнику, который собрал в себя все элементы IT-процессов и описывал их плюсы, минусы, и сочетаемость. Посмотрели, не понравилось.

Был у нас вариант объявить kanban. Декларативно. Менеджер пришел и сказал: «Завтра у нас kanban». Мы взвесили плюсы и минусы такого варианта, показалось, что в таком случае команда не достигнет самостоятельности практически никогда.

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

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

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

У нас была установка, что команда хочет как лучше. Большинство команд хочет как лучше, и хочет сделать так, чтобы у них работа была классная, чтобы она приносила результат. Не очень много профессионалов просто приходит, зарплату получает и уходит. И мы решили помочь команде сделать как лучше. Это тоже помогало нам не бояться, потому что мы знали, что мы не одни такие, не одни понимаем проблему и не одни будем ее решать, т.е. команда нам будет помогать.

Также мы пришли к пониманию, что нам нужно идти маленькими шажками. Есть такое замечательное понятие — кайдзен (kaizen), оно несколько перекликается с kanban’ом — когда вы очень-очень медленно, точечными мазками весь свой процесс двигаете куда-то в «хорошо». Кайдзен позволяет получить классный бонус, когда можно откатить примененные изменения, т.е. что-то поменяли — мазочек сделали, поняли, что поплохело, быстренько убрали, как, вроде бы, ничего и не было.

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

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

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

Мы составили такую Roadmap:

У нас был сломанный Scrum, мы из него взяли и выкинули спринты, сказали: «Все, мы, типа, сейчас по kanban работаем».

Основная цель kanban’а, если кто не знает, это выстроить поток таким образом, чтобы задачи через него просачивались оптимально быстро — от постановки бизнесом задачи до уже готового решения, которое у вас в продакшне.

И пошли мы дальше, точнее, собирались пойти дальше, но поняли, что оценки у нас в такой системе не работают. Не надо цепляться за оценки, их можно чем-то заменить, важно получить предсказуемость. Давайте предсказуемость получим тем, что мы просто задачу сделаем очень прозрачной. Т.е. мы решили сделать задачи очень понятными, когда мы с высокой степенью вероятности можем сказать, какие проблемы и боли могут возникнуть. Потратили большое количество времени, инвестировали его в коммуникации, но научились задачи разбивать на более простые, более понятные как команде, так и заказчику, бизнесу.

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

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

Собственно, как это все происходило, как команда через все это шла?

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

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

Я постараюсь не зацикливаться на какой-то kanban атрибутике, на каких-то вещах, которые свойственны для Agile. Это было не важно. Мы, например, попробовали такую штуку, как физическая доска — вывешивать стикеры на доске по колоночкам. Но у нас была очень IT’шная команда, которая не любила физические доски, и закончилось тем, что team lead каждый день в гордом одиночестве перевешивал эти стикеры, а потом где-то там в таск-трекере повторял. Мы дважды попробовали это, на второй раз у нас просто вся доска осыпалась под конец, потому что все забили. Не надо, так не надо. Мы это все заменили классной автоматизированной доской, выводили ее на большой экран — эффект тот же, но физическая доска оказалась нам, вообще, не нужна.

Еще один интересный момент. Как я уже говорил, мы шли мелкими шажками, и в процессе они выглядели, например, как «создать в Jira кнопочку». Просто создаешь кнопочку. Казалось бы, с точки зрения большого процесса, с точки зрения бизнеса, создать кнопочку — какая-то фигня. Но она нам сэкономила кучу нервов тестировщиков. Разработчики перестали недоверчиво относиться к kanban’у. Благодаря этой штуке все поняли, что такое поток, и от этой «несчастной» кнопочки мы получили столько бонусов, что усилия по созданию кнопочки несоизмеримы с полученными бонусами. Поэтому, когда вам предлагают маленькое изменение, не стоит отказываться, стоит попробовать. Ее потом легко можно откатить, если это не понравится.

Спустя два месяца после начала всей этой эволюции мы рассказали ребятам про CycleTyme. CycleTyme — это среднее время, от того, когда у вас задача попала в «молотилку задач», до времени, как она вышла. Обычно на входе это пришли заказчики, product-менеджеры или еще кто-то и заявили «хотелку», а заканчивается где-то в продакшне, т.е. на серверах боевых. Итак, через два месяца, когда ребята уже привыкли к потоку, мы меряли этот CycleTyme для себя, и они уже легко его восприняли. Т.е. они привыкли, что есть поток, они поняли, как он работает.

Следующее изменение у нас было примерно через три-четыре месяца — мы начали вводить лимиты. Лимиты — это физическое фактическое ограничение на какой-то выполняемый тип работ. Например, у вас разработчиков двое, они вряд ли физически смогут одновременно делать12 задач. А мы, как люди разумные, говорим: «Пусть они по две задачи делают». И вот у нас какой-то лимит сам собой вырисовывается — четыре задачи. Оптимально, когда разработчик время не тратит, не переключается между задачами, когда над одной работает. И kanban говорит нам о том, что желательно эти лимиты приближать к единице. Оптимально — по количеству людей, которые работой занимаются.

Второй важный лимит, который мы ввели, — это количество задач, выполняемых сейчас командой в целом. Мы сильно урезали входящий поток. У нас было огромное количество заказчиков, и мы с этими заказчиками договорились следующим образом: мы всем заказчикам рассказали, какие задачи нам ставят другие заказчики, т.е. все заказчики знали, что у нас сейчас очень много задач. И если им нужно было что-то приоритетное, они могли пойти и договориться с «соседями», попутно выяснив, какая из задач сейчас для бизнеса важнее. Это принесло много боли и страданий, как заказчикам, так и PM, но зато это позволило нам сосредоточиться на важных задачах и не перегружать команду. Задачи мы стали выполнять намного быстрее.

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

В итоге, что у этой команды получилось, какого успеха они достигли?

Мы получили тот самый пул задач, когда все заказчики знают обо всем — он открыт и понятен. Драка за приоритеты прекратилась сама собой за несколько месяцев, приоритеты стали понятны, предсказуемы, и мы смогли очень быстро бизнес-задачи решать. Насколько быстро? Например, задача — рекламной компании нужно очень быстро сделать промостраницу. Мы ее выполнение с двух недель до двух рабочих дней сократили.

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

Например, у них сейчас есть прикольная должность, называется «почтмейстер». Это человек, который несколько дней отвечает за всю входящую на команду почту и раскидывает задачки. Должность выборная и переходящая. Обычно разработчики на почту, вообще, не любят отвечать, она их раздражает, но когда они понимают, что через несколько дней они это отдадут кому-то, так жить становится легче. Почту они стали регулярно разбирать, быстренько на нее отвечать, всем стало нормально. И, как бонус, мы в этой команде получили такую классную штуку как continuous delivery. Это когда мы утром сделали задачу, а вечером она уже «в бою». Через автоматику прогнали, и в зависимости от тяжести задачи, за несколько часов, а, может быть, даже минут, она может попасть на все сервера. Такой у нас опыт получился.

Как этот опыт можно на себя спроецировать, если вы с командами работаете, не важно, с какими, и вы хотите что-то применять, научить чему-то команду?

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

Надо посмотреть, какие у вас есть варианты, какие болезненные, какие безболезненные. После того, как выбрали более или менее приемлемый вариант, нужно продумать по шагам, как вы его будете внедрять. Даже если внедрять его будете с оглядкой на команду, вы должны какие-то точки опоры иметь, знать, достигли ли вы сейчас, на текущий момент, успеха или нет.

Самое главное: не бояться делать изменения. Самое тяжелое — начать. Первый шажочек сделали, дальше легче пойдет. И обязательно оставляйте себе право на ошибку, научитесь быстро откатывать свои принятые решения, признавать ошибки, делать какие-то маленькие шажочки. Маленькие шажочки назад гораздо легче сделать, чем большой прыжок.

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

Контакты

» mihey911
» twitter
» Блог компании 2ГИС

Этот доклад — расшифровка одного из лучших выступлений на конференции по управлению и предпринимательству WhaleRider.

На сайте конференции вы можете подписаться на список рассылки, где опубликованы расшифровки лучших докладов с нескольких последний Whale Rider. Через этот же список можно следить за подготовкой к новой конференции.

Ну и главная новость — мы начали подготовку весеннего фестиваля "Российские интернет-технологии", в который входит восемь конференций, включая WhaleRider.

Автор:

Источник