company_banner

Как делать в два раза больше и получать от этого удовольствие

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



Наша команда развивает кредитные и гарантийные продукты для юридических лиц. Направление молодое, первые выдачи начались в 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 — придумывать крутые решения. Нельзя лезть в вотчину другого подразделения, это убивает креатив и вызывает взаимную неприязнь.
TINKOFF
IT’s Tinkoff — просто о сложном

Comments 14

    +8
    Я вчитался в статью и вот что я вижу.
    1. У вас была старая команда, которая сделала проект как можно быстрее, но из-за этого накопила тех. долга, на который бизнес не хотел выделять времени.
    2. Из-за тех.долга в команде большая токсичность плюс бизнес влезает в ИТ процессы, видимо чтобы ускорить работу.
    3. Из-за тех.долга ваш проект напоминает ведро с гайками, поэтому релиз каждый раз долго готовится

    Что вы сделали
    1. Решили перейти на другой стэк, вместо выполнения бэклога. Бизнес вложил деньги в методику соседнего проекта
    2. Ретро решили проводить только в карайних случаях. Хотя пишете что ретро проводите раз в месяц, что нормально, если спринт 2 недели
    3. Разогнали старую команду и наняли новую
    4. Централизовали роль архитектора
    5. Отказались от спринтов и заменили их на некие due-даты (кстати что это?)

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

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

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

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

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

      Пару слов о том, как мы набираем задачи — планируем верхнеуровневыми мазками фичи на квартал, дальше по мере освобождения бэклога договариваемся, что пойдет в разработку следующим.
      +8
      Чтобы без проблем начать делать в 2 раза больше сегодня, нужно было позавчера начать делать по крайней мере в 2 раза меньше.
      Из названия статьи почему-то ожидал, что речь пойдет о хитром методе к зашкаливающей продуктивности, а не о том, как она сначала упала сильно, а потом восстанавливалась.
        0
        Это история о том, как мы выправляли наше деливери. Приемы, благодаря которым у нас получилось — универсальны, и наверняка могут быть полезны и сработают не только у нас

        Идея о закупке разработчикам пива для достижения пика Балмера тоже была (:
        0
        Непонятно, какой бизнес анализировал бизнес-аналитик в этом кейсе
          0
          Привет, Денис!

          В Тинькофф Бизнес мы строим экосистему для юридических лиц.
          Конкретно наша команда занимается кредитными и гарантийными продуктами.

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

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

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

            0

            Как вы работаете с due-датами? Можно подробнее? Вижу в этом подходе много подводных камней.

              0
              Нам было страшно на них переходить — дата не сторь, накладывает обязательства.

              Если есть due от заказчика, то работаем с ним. Такое бывает, когда есть внешние ограничения, не зависящие от команды. Например когда мы блокируем другую систему, или есть срок от аудиторов. В таком случае все понятно — ставим эту дату.

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

              Отпуска — закладываем в due, около 10% накидываем на непредвиденные ситуации. По мере разработки большой задачи (от нескольких недель которая) встречаемся и синхронизируемся успеваем ли к due.
                0
                С этим-то как раз все понятно. Непонятно другое.
                Для того, чтобы поставить due-дату, нужно задачу декомпозировать, оценить время исполнения всех подзадач, вычислить общее время выполнения, заложить всякие митинги и походы в туалет, а после этого нужно еще распланировать другие конкурентные задачи. Просто потому, что они могут конфликтовать по срокам. А могут быть незапланированные задачи поддержки и т.д.

                Сдается мне, что это вы, как менеджер, просто сняли с себя некую головную боль и переложили ее на разрабов.
                И куча подводных камней тут выглядят следующим образом.
                1. На разрабов увеличилась нагрузка на планирование. Т.е., если раньше эту работу выполняли вы, то сейчас — разрабы. Скорее всего дорогой лид с зарплатой около 200, на котором и так висит контроль за полчищем джунов. Т.е. лид просто перестал заниматься разработкой и стал менеджером.
                2. Если раньше они не вписывались в сроки одной задачи, то просто переносили ее на следующий спринт, а за срыв сроков отдувались менеджеры, то сейчас разрабы просто тупо сидят на переработках. Т.е. упала внеплановая задача или из-за ошибки оценки сроков, и они просто сидят на работе несколько дополнительных часов. И хорошо, если это время покрывается финансово. Чаще всего бесплатно сидят.

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

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

                  Некорректно называть мою роль менеджер команды — я один из заказчиков, который за всю жизнь написал пару сотен строк кода на питоне. Планировать сроки за команду и провести правильную декомпозицию по трем нашим приложениям, самостоятельно я не смогу. По-науке правильно назвать мою роль «владелец продукта».

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

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

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

                    Спасибо. Действительно было бы интересно посмотреть на это новшество с другой стороны.
                      0
                      Новшества никакого нет на самом деле :)
                      Важно заметить, что у нас есть команды которые замечательно живут со сторипоинтами (чтобы не думали, что мы повсеместно мигрируем с них на due date).
                      1. На разрабов увеличилась нагрузка на планирование. Т.е., если раньше эту работу выполняли вы, то сейчас — разрабы.

                      На самом деле нет, нагрузка не увеличилась. У разработчиков и до этого были мнения и оценки по трудозатратности задач, но их просто не учитывали. Теперь флоу идет централизованно в следующем виде:
                      1. Заказчик приходит с задачей к лиду
                      2. Лид просит кого-нибудь из разработчиков провести архитектуру задачи. Если нужно, то собирает брейншторминг с командой.
                      3. На основе оценок от разработчиков лид прикидывает сроки, учитывая при этом рабочие дни, отпуска, техдолг и т.д.
                      Ну и самое важное, что нужно было сказать в начале: due date — это не не твердое обещание, это дедлайн в который мы стремимся уложиться. За исключением дедлайнов по задачам где сроки обусловлены законами и т.д.

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


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

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


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

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

            Only users with full accounts can post comments. Log in, please.