Тинькофф

Как прошла Tinkoff Agile Conference 2021

22 октября прошла Tinkoff Agile Conference 2021 — ежегодная конференция про развитие команд и инженерные подходы к управлению. Онлайн ее посмотрели 6000 зрителей, офлайн участвовали еще 250. Главное условие очного присутствия — пожертвование в фонд борьбы с лейкемией. Благодаря участникам мы собрали и отправили на благотворительность 500 тысяч рублей.

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

А в этой статье расскажем о двух докладах. Из них вы узнаете, как спикеру удалось ускорить движение задач по доске в 2,5 раза без лишних усилий. А также почему метрики могут обмануть и что значимо в анализе эффективности работы.

«Как ускорить движение задач в 2,5 раза», Александр Сулейманов, delivery-менеджер в Тинькофф

Исходные данные. 4 команды, 54 человека. Это четыре разные бизнес-линии, объединенные только мобильным приложением — каналом, через который они поставляют свои решения.

В процессах все по классике:

— доска с задачами в Jira со статусами;

— статусы Staged и Hold — «помойка», куда скидываются заблокированные или забытые задачи;

— отсутствие визуализации блокеров;

— движение задач вправо-влево по доске;

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

Какие были проблемы в командах

  1. Перегрузка на некоторых этапах. Например, тестирование зашивается, а разработка ничего не делает, и наоборот, разработка загружена, а тестирование отдыхает.
  2. Длительный Lead Time (LT).
  3. Как следствие, недовольство бизнеса всей этой ситуацией.
  4. Фокус на локальной функции. Например, тестировщики занимались только тестированием, и их не волновали проблемы разработки, системного и бизнес-анализа — и наоборот.

Если смотреть на метрики, то в начале пути они выглядели так:

Что изменили

1. Начали визуализировать блокеры на доске не за счет статусов Staged/Hold, а с помощью флажка. Также добавили отображение количества дней, которое задача провела в статусе.

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

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

Я предложил командам относиться к доске как к прогрессу и визуализации по накоплению знаний. Пока задача в левой части доски, мы знаем о ней немного. Но чем дальше вправо она движется, тем больше знаний о ней накапливается. Это легко объясняет, почему не нужно двигать задачу назад: нельзя внезапно забыть все, что мы о ней знаем.

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

4. Избавились от статусов Staged/Hold, убрав возможность для команды следовать старым привычкам.

5. Ввели циклы обратной связи. У команд появились две обязательные встречи в рамках обратной связи: обзор поставки и стандартная ретроспектива. На обзоре поставки мы обсуждаем не вообще все проблемы команды, а только конкретные задачи и возникшие аномалии. Например, почему задача была в работе 150 дней или почему она имела 25 багов при приемочном тестировании.

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

Также мы ввели WIP-лимиты. Они помогли сделать поставку более предсказуемой, а поток работы — равномерным. В результате 95-й перцентиль стал ближе к среднему значению, как в примере ниже:

Это говорит о том, что команда стала работать предсказуемее: с вероятностью 95% мы можем сказать заказчику, что его задачу мы сделаем за 48 дней. Кажется, что много, но раньше было 105.

Итоги и планы на будущее

  1. Нагрузка стала равномерной.
  2. Lead Time сократился.
  3. Недовольство бизнеса уменьшилось.
  4. Команда стала фокусироваться на ценности продукта, а не на своей отдельной функции.
  5. Система стала самоподдерживающейся — команды проводят встречи самостоятельно, а я только иногда о них напоминаю и поддерживаю активность.

В будущем планируем визуализировать весь E2E-процесс, используя такие же практики, те же правила и в других бизнес-направлениях.Посмотреть выступление полностью можно в записи на «Ютубе».

«Почему ваши метрики вам не нужны», Анастасия Медведева, руководитель оптимизации процессов разработки в Тинькофф

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

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

Пример 1. Lead Time — время поставки. Оно рассчитывается от момента взятия запроса в работу до поставки готового решения. Менеджеры ставят цель: время поставки — не более 30 дней.На этом скриншоте видно, что оно сократилось почти в два раза. Значит, цель выполнена:

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

Из этого нельзя сделать вывод, хорошо или плохо работала команда: метрика некорректная. И таких данных в выборке на предыдущем графике — 50%.

Вывод: любая метрика строится на данных. База данных — это система ведения задач. Для корректного расчета нужны правила и культура ведения задач в системе.

Пример 2. Реперные точки. Для Lead Time реперные точки — это момент взятия запроса в работу и поставка готового решения.

Со второй точкой обычно проблем не бывает, а с первой возникают сложности: либо ее нет, либо она не явная. Разберемся, в какой момент появляется точка принятия обязательств.После того как формируется запрос, аналитики изучают его и описывают требования. Затем требования верифицируются: собирается команда разработки с продактами и решают, что требований достаточно. Когда команда разработки выбирает задачу в бэклог и формирует ожидания по поставке, появляется точка принятия обязательств, или Commitment Point от ИТ.

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

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

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

Посмотрим на график динамики пропускной способности одной из команд:

Цель от менеджера: пропускная способность — более 45 задач в месяц. Смотрим на июль и август: команда стала производить больше.

Кажется, что цель выполнена, но на деле команда изменила подход к декомпозиции задач. Где раньше была одна задача, их стало от 2 до 4. А с точки зрения ценности и перформинга команды ничего не поменялось.

Вывод: одна метрика в вакууме не показательна. Нужно анализировать соотношение метрик.

Что делать, чтобы не быть обманутым

  1. Настроить систему ведения задач и отметить там реперные точки.
  2. Договориться о правилах работы и соблюдать их.
  3. Анализировать каждое изменение метрики на дашборде, в том числе относительно друг друга.
  4. Смотреть метрики в динамике.
  5. Не гнаться за зеленым сигналом. Это индикатор здоровья команды, но не нужно ставить цели по снижению и росту тех или иных метрик.

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

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

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

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

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

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

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

Сначала мы смотрим на поставляемое решение и думаем: востребовано ли оно, будут ли его покупать? Это про поиск и поддержку Product Market Fit — продукта, обладающего ценностью для ЦА. Задача любого продукта — привлечь аудиторию, которая согласится купить предлагаемое решение ее проблемы. Если оно не будет соответствовать потребности клиента, то не будет продаж, а значит, и прибыли.

Общие выводы

  1. Не гонитесь за зеленым сигналом.
  2. Процессные метрики без контекста не имеют ценности.
  3. Эффективность — это довольный клиент.

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

Посмотреть выступление полностью можно в записи на «Ютубе».

0
2 комментария
Популярные
По порядку

"Благодаря участникам мы собрали и отправили на благотворительность 500 тысяч рублей."
Так это вообще ни о чем в борьбе с лекимией, на пол процедуры не хватит для одного человека. Сомнительная помощь.

1

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

0
Читать все 2 комментария
Продавец eBay из Кургана стала победителем в финале Всероссийского конкурса «Молодой предприниматель России 2021»

27 ноября в Москве состоялся финал ежегодного конкурса «Молодой предприниматель России 2021». В нём приняли участие предприниматели и самозанятые в возрасте до 35 лет. Всего было подано более 300 заявок из 43 регионов страны.

Откуда берут взрослые деревья для парков и улиц

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

SkillFactory раздает подарки: повышенная ставка и новогодний марафон для вебмастеров

В преддверии Нового года мы решили порадовать своих настоящих и будущих партнеров — участников партнерской программы школ Skillfactory, Contented и Product LIVE. Это возможность получить денежный бонус и заодно увеличить прибыль от продажи наших курсов.

Доказал, что миллиардеры не видят разницы между вином за $500 и $10 тысяч: история Руди Курниавана Статьи редакции

Курниаван продавал подделки под видом редких вин предпринимателям, генеральным директорам и голливудским продюсерам и обманул их более чем на $35 млн.

Руди Курниаван LA Times
Яндекс плюс снимают деньги и не оформляют возврат.Сотрудники компании не отвечают

Произошла неприятная ситуация с Яндекс плюс,причём во второй раз.С банковского счёта было списано 299₽,в самом профиле никакой подписки нет,тогда вопрос,за что снимали?Обратилась в поддержку ,заполнила форму-отказ ,хотя я приложила все доказательства и чек.Написала в чат ,попросили выслать номер карты,со второго числа никто не отвечает,писала уже…

И сотрудников тоже касается: кибербуллинг на рабочем месте
Design vector created by pikisuperstar - www.freepik.com
«Неслучайная случайность», или как рождаются крипто стартапы на примере Freya

Статья носит сугубо ознакомительный характер и не призывает к инвестированию в какие либо активы.

Агрегатор "Яндекс.Еда" не возвращают оплату за заказ, которого не было

Здравствуйте! Ситуация следующая, 22.10.2021 г. я сделала заказ у агрегатора доставки "Яндекс.Еда". Доставка из Магазина "Магнит". В момент списания оплаты с банковской карты за заказ заметила, что адрес доставки товара указан с ошибкой. В заказ проставился рабочий адрес, а не домашний, ехать на автомобиле от дома до работы мне 10 минут, пешком…

re:Store продал Macbook Pro с раскладкой azerty и серийный номер ноутбка не совпадает с серийным номером на коробке
Хоум кредит про меня забыли. Долг с 2009года

Решил я значит проверить свою кредитную историю на одном из известных ресурсах. И что я обнаружил? Действующий долг в #хоум_кредит с 2009 года и как следствие краснющую историю! Я конечно же позвонил в эту контору, говорю каким образом банк забыл про меня? - а вы знаете? Мы вам звонили звонили... но не дозвонились ... Так же как и вашим…

Глава американской компании Better.com уволил 900 сотрудников одним видеозвонком Статьи редакции

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

Я пришёл к вам с плохой новостью. Рынок изменился, как вы знаете, и мы должны двигаться за ним вперёд, чтобы выжить, процветать и исполнять нашу миссию. [...] Я делаю это второй раз в своей карьере и не хочу повторять. В последний раз, я плакал, но на этот раз надеюсь быть сильнее. [...] Если вы сейчас смотрите это, значит вы в той невезучей группе, которую увольняют.

Вишал Гарг
null