(function(m,e,t,r,i,k,a){m[i]=m[i]||function(){(m[i].a=m[i].a||[]).push(arguments)}; m[i].l=1*new Date(); for (var j = 0; j < document.scripts.length; j++) {if (document.scripts[j].src === r) { return; }} k=e.createElement(t),a=e.getElementsByTagName(t)[0],k.async=1,k.src=r,a.parentNode.insertBefore(k,a)}) (window, document, "script", "https://mc.yandex.ru/metrika/tag.js", "ym"); ym(93790508, "init", { defer: true, clickmap:true, trackLinks:true, accurateTrackBounce:true }); ym(93790508, 'hit', window.location.href);

Трекинг времени в разработке? Вы просто не умеете его внедрять

Типичная история тимлида. Съездил на конференцию, узнал новые вдохновляющие идеи и загорелся. Начал сходу внедрять то, что (по его мнению) точно сработает, и получил ожидаемый отпор команды: «Зачем нам вообще что-то менять?»

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

Андрей Болгов
тимлид, ведущий разработчик в облачной платформе Selectel

История про метрики

Этот кейс был еще на заре моей карьеры тимлида. Я был молод и не опытен. На одной конференции услышал доклад про метрики эффективной команды и понял, что нам не хватает трекинга времени в задачах. Без этих данных было сложно делать выводы об эффективности. Мы делали много задач, но тонкий fine-tuning в условиях нашей Jira был невозможен.

Несмотря на боевой запал после конференции, я задумался, все ли я понимаю в том, что буду менять? И осознал, что я как молодой лид хотел внедрить эти метрики, привнести что-то новое, но в реальности не знал, как это сделать.

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

Есть множество книг по теории управления изменениями. Придумано много разных методов, метрик и способов их отобразить. Рабочей для меня стала формула успешности изменений Бекхарда, которая выражается простым неравенством:

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

D — Неудовлетворенность ситуацией

Здесь нужно рефлексировать: а в чем мое недовольство текущей ситуацией?

Это не про то, что «горит» прямо сейчас, а про потенциальные риски — что-то где-то идет не так и может привести к проблеме. Главное — не натягивайте сову на глобус, не придумывайте проблему. Даже если вам очень хочется внедрить крутой инструмент.

Важно ответить для себя на простые вопросы:

  • Какую проблему решает инструмент, о котором вы узнали?
  • Есть ли вообще такая проблема у вас?
  • Что лично вы приобретаете от того, что в команде появляется новый инструмент или методика?
  • Зачем это команде? Что она от этого получит?

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

Поделись печалью своей

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

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

Как это было в моей ситуации.

Я хотел быть увереннее в долгосрочном планировании, но мне не хватало контекста: сколько мы реально что-то делаем. Плюс хотел удачнее закрывать спринты — на тот момент 40-50% от взятых задач не закрывались.

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

В результате мы пришли к одной боли: мы хотели уменьшить страх от неизвестности объемов задач.

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

Я тогда выскочил на белом коне: «У нас есть непонимание, так давайте трекать время! Это классная идея!» На что получил реакцию: «А зачем?»

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

Я вернулся к формуле: наступил момент, когда мы предлагаем решение, выдвигая гипотезу.

V — Видение будущего

Мы не говорим, что точно знаем секрет успеха. Мы делаем предположение: «Вот это, скорее всего, даст нужный результат и решит нашу проблему. Наверное». Ключевое слово — наверное. Это очень важный момент — честно сказать об отсутствии 100% уверенности, что идея сработает.

Так звучала моя гипотеза: «Может, попробуем отмечать затраченное время в задачах? Это даст нам статистику, необходимую для будущего планирования».

Сбор урожая

После выдвижения гипотезы собираем первичный фидбэк и опасения. Это может быть как «Точно не сработает!», так и техническая мантра, которую мы часто себе повторяем: «Работает – не трогай!»

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

Будет и страх изменений. Нашему мозгу энергозатратно выстраивать новые нейронные связи, создавать другие паттерны для действий, поэтому мы интуитивно избегаем изменений.

Страхи — это то, с чем нужно работать. Поэтому важно выслушивать и фиксировать все опасения. Делайте это максимально прозрачно, четко проговаривайте: «Так, я услышал это опасение и записал его».

Это уменьшает сопротивление изменения (R) просто за счет того, что человек понимает, что к нему прислушиваются.

Мы с командой выявили три опасения:

  1. Но ведь к нам потом придут и скажут, что мы не дорабатываем. Мы же не работаем 8 (16-20-40) часов в день.
  2. Мы будем забывать отмечать время, а потом мучительно вспоминать, сколько было затрачено. И вообще, это новая история, непонятно, как и зачем трекать.
  3. Слишком много контекстов и переключений. В мире разработки это частая история: мы постоянно переключаемся между этапами задачи и уже не можем понять, где мы делали одну задачу, а где перешли ко второй.

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

F — Первые конкретные шаги

Удивительно, но команда согласилась. Я всего-то заменил «нужно трекать время» на «давайте попробуем трекать время». В чем же тут разница?

Волшебство «Давайте попробуем»

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

Здесь мы начинаем делать первые шаги (F). Волшебство работает, потому что мы проработали проблематику, Vision, и у нас еще остался большой запас инерции.

Но, конечно, без конкретного плана действий ничего не выйдет.

Нам нужен план!

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

Для синхронизации хорошо подходят ретроспективы. Если у вас SCRUM-like мир или просто SCRUM, который работает на 100%, такие периодические встречи очень удобны. Вам не придется проводить дополнительные мероприятия для обсуждения внедренного изменения.

Здесь вы работаете на Vision (V), потому что есть конкретный план внедрения изменения. Также мы уделяем время первым шагам (F): мы услышали существующие опасения и рассмотрели их на первом этапе синхронизации. Все это также уменьшает сопротивление (R). Люди видят, что все ими сказанное было учтено, что их мнение важно.

В результате у нас с командой получился следующий план:

Цель: проверяем гипотезу, что трекинг времени даст нам статистику для планирования, то есть мы сможем собирать аналитику и делать выводы.

Срок: 3 спринта.

Контрольные точки: ретроспективы каждого спринта.

Метрики: Количественная — более 80% задач, взятые в спринт, выполняются. Качественная — ощущение страха перед неизвестным уменьшилось. Страх практически невозможно измерить объективно, но можно оценить по ощущениям.

Мне бы хотелось написать, что после старта все было весело и прекрасно, но это не так. Все трудности вскрылись на первом же этапе.

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

R — Сопротивление изменениям

Проблемы точно будут. Это единственное, в чем можно быть уверенным на 100%. Важно не останавливаться.

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

Это «Давайте попробуем» будет с вами на протяжении всего пути внедрения изменений. Результаты можно получить, только реально пытаясь что-то сделать.

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

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

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

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

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

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

После эксперимента

В конце мы проверяем, сработало или нет. Для этого замеряем целевые метрики, которые можно собирать как в процессе, так и в конце эксперимента. Если сработало, забираем в работу.

Если не сработало, то рефлексируем почему. Здесь может возникнуть соблазн продавить изменение (мы же уже начали), но боритесь с ним. Запишите результат и отложите изменение. Дайте команде понять, что держите слово.

Так мы работаем и с сопротивлением (D), и с недовольством текущей ситуацией (R): проблема осталась, но конкретно это решение для нас не сработало.

Заключение

Конкретно эта история завершилась успешно, но опыт был разный.

Что у нас получилось:

  • Не рассыпались по пути. Опасения, которые мы поймали на первой ретроспективе, удалось достаточно быстро решить. Команда делилась инструментами, совместно мы научились трекать время удобным всем способом.
  • Мы подошли к метрике в 70% закрытых задач за спринт. Но это не главное.
  • Главное — уменьшился страх перед неизвестным объемом работы. Ребята на планировании стали четко говорить: «Так, я понимаю, что, делая такие же задачи, я затратил гораздо больше времени. Наверное, в следующий спринт я не буду брать столько задач. Лучше сделаю то, что поможет успешней закрыть спринт, и буду меньше волноваться из-за сроков».
  • Появился запрос от команды: научиться декомпозировать задачи. Стали разбивать абстрактные таски на шаги.
  • Появилась необходимая аналитика для последующих внедрений. Наработки по трекингу времени мы потом смогли использовать (и использовали) для понимания, где именно мы застревали. Без этих цифр мы бы не понимали, что происходит.

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

Видео моего выступления по этой теме на конференции TeamLead Conf 2021 можно посмотреть здесь.

Хотите поучаствовать в разработке облачной платформы Selectel?

Пишите. У нас классные тимлиды и задачи.

Посмотреть вакансии

0
Комментарии
-3 комментариев
Раскрывать всегда