[Из песочницы] Как делать в два раза больше и получать от этого удовольствие
Привет, Хабр! Я Максим, бизнес-аналитик в Тинькофф. В этой статье я поделюсь опытом нашей команды: как выполнять в два раза больше задач, переписать с нуля легаси-проект и при этом не умереть.
Наша команда развивает кредитные и гарантийные продукты для юридических лиц. Направление молодое, первые выдачи начались в 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 — придумывать крутые решения. Нельзя лезть в вотчину другого подразделения, это убивает креатив и вызывает взаимную неприязнь.
