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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#selectel #тимлид #управление_изменениями