Негибкий “Энтерпрайз” и гибкие методологии


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

Однако мы (в Альфа-Банке в целом и в Альфа-Лаборатории в частности) придерживаемся иного подхода. Подхода, когда усилия всех участников процесса направлены на создание ценности для клиента, при этом путь, которым они этого достигают, может содержать очень много степеней свободы.



Я расскажу, как у нас в Лаборатории выстраиваются процессы работы. Мы опираемся на концепцию Agile. В качестве основного фреймворка мы выбрали Scrum, модель производства — командно-центричная.

Составы команд варьируются в зависимости от потребностей создаваемого продукта, но практически всегда это “полный стек”, необходимый для доработки или разработки продукта. Чаще всего это Product Owner (PO), скрам-мастер, дизайнер, системный аналитик, несколько разработчиков и тестировщик. Набирается 7 — 10 человек. Всего в Лабе таких команд порядка 30.

Наши принципы


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

Кросс-функциональность и взаимовыручка


Одна из самых важных вещей в командной работе — это внутрикомандное взаимодействие.

Мы в командах не ставим задачи вроде “разработчик — пишет код”, “аналитик — готовит документацию” и т.д.

Общая цель команды — чтобы клиент получал ценность. И если, например, у нас накопилась очередь в тестировании, то остальные ребята помогают своему тестировщику, чтобы команда выполнила цели спринта и по его итогам привнесла инкремент продукта.

В Scrum-гайде это называется “кросс-функциональная команда”.

Никаких заказчиков и исполнителей


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

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

Соответственно, и в проработке бэклога задействована вся команда. У нас нет такого, что PO в качестве заказчика “загружает” в команду требования, а затем просто ожидает результата.

Продуктологи приходят к команде с клиентской проблемой (иногда бывает, что и сразу с решением). Далее все члены команды участвуют в проработке проблемы, формировании гипотез, поиске решений — они вместе делают “story map”, формируют пользовательские истории, обсуждают сценарии, решают, как будет выглядеть продукт.

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

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

Итеративность


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

Прозрачность


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

В качестве “градусника” мы используем burndown-диаграмму спринтов команды. Burndown достаточно оперативно отражает возникающие в процессе работы проблемы (если график “плоский”), и мы можем своевременно реагировать на эти проблемы.

Кроме того, по совокупности графиков нескольких спринтов можно оценить общее положение дел в команде.

Очень удобно то, что все наши команды используют Jira в качестве таск-менеджера — воспользовавшись этим, мы настроили общий дашборд, на котором видны все 30 burndown-диаграмм. Можно сказать, что это наш Центр Управления Полётами :)

Не надо стесняться


В продолжение темы прозрачности поговорим о важном для нас мероприятии — демонстрации итогов.

В конце итерации (раз в одну или две недели) в каждой команде проводится Sprint Review — ребята показывают и рассказывают, что они сделали за спринт.

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

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

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

Система поощрений


Помимо комфортного офиса, интересных задач, крутой команды и стандартных “белая зарплата + ДМС”, у нас существует система мотивации сотрудников.



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

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

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

Кто на новенького


Немало внимания мы уделяем поиску и подбору людей.

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

Человеческие качества кандидата, подходит ли он нам по духу — это те вещи, на которые мы обращаем внимание на собеседованиях.

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

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



Также на плечи наставника ложится задача ввести человека в предметную область.

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

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

В начале испытательного срока “новобранец” и его наставник формируют “План на 100 дней”, в котором они совместно определяют цели на ближайшие три месяца и договариваются о метриках успешности испытательного срока.

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

Думаю, наше особое внимание к именно этим критериям помогло нам собрать такую крутую команду, работать в которой — всегда в радость и с удовольствием!

Если вы разделяете подобный подход к работе и хотели бы стать частью команды — обратите внимание на наши текущие вакансии — дизайнер интерфейсов, Scrum master, iOS-разработчик и многие другие.
Поделиться с друзьями
-->

Комментарии (26)


  1. triton
    28.07.2017 13:19
    +2

    Можете поделиться как в рамках Agile и Scrum у вас решаются проблемы разнородности команды:
    1. В команде несколько разработчиков разного уровня и скорости выполнения задач — каким образом будет производиться предварительная оценка времени выполнения задачи?
    2. В команде присутствуют разработчики разных специализаций (к примеру, бэкэнд и фронтэнд) как организуется работа, если в текущем спринте недостаток задач для одной из специализаций и как оценивается производительность такой разнородной группы?


    1. molchanov_a_m
      28.07.2017 15:06

      Привет!
      1. Мы не оцениваем время выполнения задачи, а оцениваем сложность. В случае когда на одну и ту же задачу члены команды дают кардинально разные оценки ребята садятся обсуждать и приходят к единому мнению. Чаще всего разница в оценках выражается не в опыте разработчиков, а в том, что кто-то из них чего-то не знал о конкретной задаче.
      2. Задачи (US) внутри спринта нарезаются командой так чтоб выровнять нагрузку между ребятами.


      1. triton
        28.07.2017 16:00

        1. А в Jira заносите планируемое время, только когда задачу взял конкретный разработчик или только по факту списываете?


        1. molchanov_a_m
          28.07.2017 19:15
          +1

          У нас нет самоцели подсчитывать время потраченное на задачу, но некоторые команды так делают по факту выполнения задачи.


  1. Dzen1
    28.07.2017 13:33
    +1

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


  1. aBozhiev
    28.07.2017 19:06
    +1

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


    Уточните, пожалуйста, что понимается под понятием «продукт» — это ИТ-приложение (система) или бизнес-продукт (депозит, карта и т.д.)?


    1. molchanov_a_m
      28.07.2017 19:33
      +1

      Это бизнес-продукт приносящий пользу клиентам.


      1. aBozhiev
        28.07.2017 22:03

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


        1. staticlab
          28.07.2017 23:41
          +1

          А кто вам сказал, что это обязательно должны быть разные приложения? :)


          1. aBozhiev
            31.07.2017 12:26
            +1

            Интересует ответ на вопрос «бывает ли такое, что это разные приложения?»
            Ну и интернет-банк и бек-офис — неужели это и правда одно приложение?


  1. saartr
    28.07.2017 19:18
    +1

    Те вся команда(примерно 10 человек) включая разработчиков и qa занимаются проектированием(story map, поль. сценарии, макеты, прототипы)? Я понимаю, что они могут быть на общем обсуждении, когда что-то готово, но чем они занимаются в остальное время?


    1. molchanov_a_m
      28.07.2017 19:27
      +1

      У команды нет «остального» времени. Все вовлечены в процесс создания продукта на всех его этапах.


  1. Hixon10
    28.07.2017 23:33
    +2

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

    Насколько я знаю, среди прочих команд у вас есть одна — платформа/инфраструктурная команда. Это те парни, кто очень крут, пилит на Спринг Буте базувую функциональность, которую потом используют 30 команд. Скажите, пожалуйста, эти ребята тоже живут по всем тем же принципам: Продакт, Спринты, Джира, или им позволино просто разарабатывать систему без игры в менеджмент?


    1. tolkkv
      31.07.2017 00:20

      Добрый добрый

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

      Если вас интересует продакт, спринты, джира — они имеются в наличии
      Если интересна «игра в менеджмент» — тут вопрос понятий уже. Продакт, Спринты и Джира либо нужны команде, либо это обсуждается на ретроспективе и что то (или кто то) исключается.


      1. Hixon10
        31.07.2017 01:50

        Кирилл, спасибо за ответ, а также за то, что вы делаете публично (конференции, подкасты)! :)


  1. V_Maksim
    28.07.2017 23:40
    +1

    Спасибо, интересно… и завидно, белой завистью :)
    А у нас никакой командной работы. Мой отдел — команда, а всё, что вне отдела, — только эгоизм. Мол все друг другу что то должны…
    Да и какая командная работа, когда и руководство грызеться...


    1. staticlab
      28.07.2017 23:47
      +1

      Нет желания присоединиться?


      1. V_Maksim
        29.07.2017 15:43

        Спасибо.
        Желание есть всегда, но… но проект надо завершить…
        Не смотря на все проблемы, «не благодаря, а вопреки», он завершается!!!


    1. Dmitry_5
      29.07.2017 20:00

      Все что вы описали — точно про альфабанк. Не рекомендую


      1. molchanov_a_m
        30.07.2017 08:09

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


  1. Dmitry_5
    29.07.2017 19:47

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


    1. molchanov_a_m
      30.07.2017 08:13

      Вы правы! Все в одной команде, без заказчиков и исполнителей. Есть PO, SM, DevTeam обладающие разными компетенциями, но работающие вместе.


  1. KvayGon
    31.07.2017 13:44

    Вы не написали в тексте или не используете парное программирование? По методологии скрама оно обязательно, вы от него отказались, если да то почему? По мне так в Jire писать ставить задачи и т.д. возможно должен только PO для отчета перед начальством которое хочет видеть красивые отчетики, живая канбан доска на стене явно лучше мотивирует команду. Насколько я понимаю вы в нашей стране чуть ли не единственные кто разрабатывает ПО по методологии scrum.
    Что используете для определения веса исполнения юзер стори? покер? фибо?
    SM кофе носит всем? молотое? ))))
    Представителя заказчика таскаете на недельные скрам митинги? они реально ходят?
    Каким способом затаскиваете к себе такого представителя (расписанием, приказом и т.д.) или вам удалось назначить крайнего от заказчика и он адекватен?


    1. staticlab
      31.07.2017 14:00
      +1

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

      Интересно, почему вы так решили?


      https://www.quora.com/Can-I-use-pair-programming-with-the-scrum-methodology


      The scrum framework has nothing to say about the actual techniques of doing the work (unlike say eXtreme Programming, which has plenty to say, including that you should do pair programming).

      Ещё:


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

      Тоже весьма спорное заявление


      1. KvayGon
        31.07.2017 14:46

        Видел на обучении в ролике от Джефа Сазерленда. Обратил на это внимание и запомнил.

        Есть примеры предприятий где еще работают по scrum? не по Agile в целом. а именно по scrum. было бы интересно узнать как у них получается.


  1. molchanov_a_m
    31.07.2017 14:02
    +1

    Привет.
    — Используем. Согласен с вами что без XP практик реальное использование фреймворка Scrum практически невозможно.
    — Для оценки сложности используется и покер и фибо. Главное чтоб это не сводили в часы на выполнение US.
    — Видели как один из SMов помог команде обзавестись реальной кофемашиной
    — PO присутствует почти на всех активностях команды и работает совместно с ней. он реально ходит )
    Не заставляем, это скорее вопрос зрелости PO, чем работа каких то приказов и распоряжений.