Привет, Хабр! Я Максим, бизнес-аналитик в Тинькофф. В этой статье я поделюсь опытом нашей команды: как выполнять в два раза больше задач, переписать с нуля легаси-проект и при этом не умереть.



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

Симптомы

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

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

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

Проблемы

Углубившись в процессы команды, мы нашли клубок проблем, которые нельзя было решить по отдельности, они требовали комплексного подхода:

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

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

Старый технологический стек. Наш процесс был написан на IBM ODM системе с рядом особенностей, которые мешали команде. Детально их описал наш архитектор Денис Kotskin в кейсе соседнего проекта (правда, там был IBM BPM, но в целом все справедливо). Отдельно отмечу, что на рынке нет специалистов с опытом работы в этой системе.

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

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

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

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

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

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

Что мы сделали

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

• Перестроение канбан-процесса. Спасибо деливери-центру Тинькофф Бизнеса, который оперативно вник в нашу проблематику и помог адаптировать Jira.
• Синхронизация бизнеса и IT. Тут нас двигала вера в то, что команда должна хорошо понимать продукт, а не просто выполнять задачи, которые ей принесут.

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

Часть 1. Переписывание процесса

Итак, мы начали переписывать процесс с IBM ODM на Camunda. Причины выбора Camunda описаны в статье Николая nshipyakov.

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

Возникает естественный вопрос: как мы договаривались с бизнесом? Понятно, что переписывать уже работающий функционал это дольше, чем доработать его на старом движке. Все получилось достаточно просто: коллеги были готовы инвестировать в новый процесс, потому что видели, как круто это сработало на соседнем проекте (и снова привет, Денис Kotskin). При этом сроки разработки на новом движке были не намного больше, так как мы начали ротацию: выгоревшие ребята перешли в другие проекты, на замену наняли сотрудников с опытом разработки и проектирования бизнес-процессов.

Часть 2. Изменение порядка ведения задач

При изменении процесса разработки опирались на следующие установки:

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

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

Данные о ценности продукта команда получает в формате user story и оценки влияния задачи на продукт. Бывает трудно отличить блеф ушлых бизнес-заказчиков. Например, оценка Это правило важное, будет проверяться на всех заявках намного менее информативна, чем Мы провели аналитику, правило будет отказывать по 10 дополнительным заявкам в неделю. Поэтому перед тем, как отдать задачу в разработку, качество написанной ценности валидирую я, как представитель бизнес-команды, который разделяет ценности разработчиков.

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

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

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

Часть 3. Синхронизация IT- и бизнес-команды

Для синхронизации бизнеса и разработчиков используем несколько форматов.

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

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

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

Проводим лекции о продуктах в формате ликбеза и последующего обсуждения. Их цель погрузить ребят из IT в бизнес-контекст. По собираемой обратной связи в виде опроса с максимально общей формулировкой Оцените сегодняшнюю лекцию средняя оценка 8,5 из 10.

Итоги

Через полгода мы переписали больше 80% процессов, запустили кредит под контракт полностью на новом движке. Атмосфера в команде улучшилась, и мы стали эффективнее. Чтобы убедиться в этом, провели опрос команды и сняли статистику с Jira.

В опросе спрашивали про атмосферу в команде, качество спецификаций, разработки и архитектуры, качество общения с бизнесом. По итогам опроса средняя оценка у ребят, которые больше полугода в проекте, поднялась с 6 до 8 баллов из 10. К сожалению, опрос не до конца честный, так как его провели уже после изменений. Приведенные показатели относятся к началу года и началу июля. Так что справедливо говорить о том, что положение дел в команде улучшилось, но нельзя сказать насколько.

Производительность (количество задач в день) за это время выросла в два раза. Естественно, не за счет декомпозиции: мы заранее договорились о неких стандартах, которых придерживаемся.

Количество возвратов из теста в разработку незначительно уменьшилось. То есть при кратном увеличении числа выводимых на прод задач количество возвратов не возросло. Это свидетельствует об улучшении качества проработки задачи на этапах discovery и архитектуры. Количество багов, находимых на проде, не изменилось.

Чему мы научились

Теперь сформулирую несколько идей, которые мы с командой извлекли из нашего опыта. Если у вас в командах похожие проблемы надеюсь, они помогут и вам.

• Отказывайтесь от практик, которые мешают. Выявить их легко они приносят дискомфорт команде. Сторипоинты, планирования и ретро не панацея, а инструмент. Если инструмент неудобен используйте другой.
• Обязательно делитесь опытом, даже самым, на ваш взгляд, незначительным, и впитывайте все знания, которые до вас доходят. Помогают внутренние митапы, ликбезы по конкретным темам и все в таком духе.
• Возвраты зло, которое надо побороть, чтобы работать эффективно. Это касается возвратов из теста в разработку, возвратов с прода в виде багов, из разработки в discovery в виде вопросов к заказчику.
• Один человек с позитивным опытом тимлида кратно повышает эффективность за счет инвестиций в развитие команды. Организация one-one-встреч, нахождение точек роста сотрудников, поддержание общей нетоксичной атмосферы. Этим человеком у нас был Саша Shoom3301, спасибо ему огромное.
• У каждого своя задача: у бизнеса делать бизнес, у IT придумывать крутые решения. Нельзя лезть в вотчину другого подразделения, это убивает креатив и вызывает взаимную неприязнь.

Иногда при обсуждении продукта метрики только мешают

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

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

Итак, меня спросили: Если бы для agile-команды можно было бы отслеживать только две метрики, что бы вы выбрали?

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

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

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

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

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

Опасность использования метрик

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

Рассмотрим три ловушки, в которые можно попасть, используя метрики.

1. Избыток метрик

А давайте отслеживать всё подряд! Зачем ограничиваться одним показателем эффективности, если можно использовать больше? Чем больше, тем лучше, верно? Конечно же нет если речь идет о командах, разрабатывающих продукт.

Допустим, отслеживаются такие метрики:

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

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

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

Уильям Эдвардс Деминг

Чем больше метрик, тем больше усилий и людей требуется для сбора соответствующих данных. При этом мы даже не пробуем оценить, стоит ли отслеживать каждый конкретный показатель. Но несмотря на всё это, мы пытаемся выжать из отслеживания данных максимум.

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

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

2. Сравнение между командами

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

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

Скажи мне, как ты меня будешь оценивать, и я скажу, как я буду себя вести.

Эли Голдратт

Если нам кажется, что за нами наблюдают, мы начинаем вести себя иначе это называется хоторнским эффектом.

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

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

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

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

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

И такое может произойти и с любой метрикой, если она становится внешней целью.

3. Чрезмерный акцент на объективных данных

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

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

Если есть страх, цифры будут врать.

Уильям Эдвардс Деминг

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

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

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

Единственная нужная метрика

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

Без данных ваши слова просто очередное мнение.

Уильям Эдвардс Деминг

Но перечисленные три проблемы избыточное количество метрик, сравнение между командами и увлечение объективностью не дают использовать данные эффективно. Так что же делать?

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

Метрика вовлеченность команды

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

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

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

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

Общайтесь с коллективом.

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

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

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

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

Итак, мой окончательный ответ

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

Теперь, тщательно всё обдумав, я бы дал более взвешенный ответ:

Пусть решают сами команды. Нужно почаще заходить к ним и общаться чтобы они ощущали участие и поддержку.

Методология Agile ориентирована на то, чтобы команда работала сообща и совершенствовалась. Главное здесь не цифры, диаграммы или графики.

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

Особая благодарность Мацею Ярошу и Маартену Далмийну за их вклад в эту статью.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее