Agile и потребности мозга: управление стрессом

    Вам приходилось испытывать сильные эмоции на работе? Как насчёт страха, внезапно захлестнувшего ваш мозг? Легко потом работать эффективно? Если ваша организация уже внедрила agile, но с вами такое всё еще случается – что-то идёт не так.

    Меня зовут Артем Зарафьянц, и я руковожу одним из отделов разработки СХД Dell Technologies в Санкт-Петербурге. Работаю 12 лет, с открытия нашего офиса. В 2007 году, начиная работу над VNXe, мы стали использовать agile на уровне команды – тогда не сложилось. Наш процесс столкнулся с ватерфоллом на глобальном уровне и постепенно угас. VNXe мы выпускали без agile: конечно же, успешно (как и всё масштабное в нашей корпорации), однако медленно, дорого и на стрессе. Примерно 6 лет назад наша инженерная организация (несколько тысяч сотрудников) начала систематическое внедрение agile at scale сверху. В то время я уже был менеджером и получил второе (из трёх) высшее образование – по психологии. Это помогло мне осознанно пройти через опыт внедрения agile, и я готов им поделиться.



    Представьте, что вы – тимлид или менеджер команды программистов. Ваш заграничный начальник (или заказчик) звонит и в гневе устраивает вам разнос. Якобы разработанная вашей командой фича полна багов и никуда не годится. Вы слышите упреки: «Как такое могло произойти?! Почему такое ужасное качество?! Одни баги вообще, доложите мне какой у вас план исправлений?!». Ваше сознание распознаёт угрозу, вам обидно. Эмоции захлёстывают, накатывают волнами – это несправедливо, и вообще какой-то бред! Не лучший настрой для разработки плана исправлений. Не лучший настрой для продолжения работы по плану итерации.

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

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

    Как?

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

    Начальник и команда. Даша. 10 лет.

    Ретроспектива


    Хорошая ретроспектива помогает осознать неприятности и создать план в виде нейронных связей в вашем мозгу.

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

    Например, как-то раз на заре внедрения agile наша команда провалила итерацию – не достигла целей. Это было лет 6 назад, когда мы начали работать над СХД EMC Unity по новому agile процессу. Ретроспектива начиналась с удручающих эмоций. Пришли нехотя, расселись, ссутулились. Если бы не предварительная подготовка, то могли бы скатиться к нытью. Стали разбираться, что мы можем сделать в следующий раз.

    Система, над которой работает наша распределённая организация, включает большое число областей. Цикл тестирования принёс поток багов, на анализ которых мы потратили много незапланированного времени. При этом большинство багов осело в областях у других команд. Мы вроде как «лили воду на чужую мельницу» – помогали нашей организации, но провалили свой коммитмент.

    У вас такое когда-либо было? Пишите в комментариях, что вы предприняли. Мы повели себя так:

    • Для снижения времени на анализ багов мы вместе с другими командами стали создавать автоматизированные средства предварительного анализа ошибок.
    • Чтобы точнее понимать, что ошибки чужие, и отправлять их на анализ нужно другим командам, мы стали внимательнее к прогонам наших компонентных тестов. Прошедшие тесты подтверждают, что функциональность работает, и снимают подозрения с нашей предметной области, экономя нам время.
    • Для повышения эффективности мы стали планомерно тратить время на развитие навыков анализа дефектов. Со временем начала формироваться новая роль в команде – специалист по анализу дефектов.
    • Чтобы иметь возможность отвлекаться на багфикс без остановки критических работ для итерации, мы стали более жёстко контролировать WIP (work in progress). Над каждой user story стали работать два-три человека – появилась возможность кому-то переключиться на баг.
    • Для улучшения коммуникации с тестировщиками мы начали давать обратную связь в QA. Стали общаться не только через email’ы и комментарии к багам, но и через личные беседы по коммуникатору и телефону.
    • Ну и чтобы проще было управлять багфиксом – перевели его со скрама на канбан.

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

    Хорошая ретроспектива приводит к тому, что в следующий раз при встрече с проблемами тревожность членов команды снижается. Команда привыкает к успеху в каждой итерации – мораль повышается. Повышается желание мыслить и решать задачи вместе. Таким образом, ретроспектива помогает удовлетворению потребности в безопасности, вшитой в мозг Homo Sapiens эволюцией. Я несколько раз наблюдал как хорошая ретроспектива приводила к тому, что тревожность членов нашей команды снижалась, и ощущал как в следующих итерациях мы работали спокойнее и эффективнее.

    Потребности нашего мозга – это ключ к самомотивации, к выстраиванию отношений внутри команды и залог не только производительности труда, но и счастья на работе!

    Если вам интересна эта область, то обязательно дайте об этом знать в комментариях. Я планирую написать цикл постов на тему «agile и потребности мозга». А пока рекомендую обратиться к следующим источникам:

    1. Канеман. Thinking Fast Thinking Slow
    2. Мозг. Инструкция по применению. Дэвид Рок
    3. Дубынин. Лекции о физиологии мозга, «мозг и потребности»
    4. Описание ретроспективы в SAFE
    Dell Technologies
    Компания

    Комментарии 12

      0
      Ретроспективные митинги вообще один из важнейших моментов в agile, но почему-то на них очень часто забивают.
      А именно они и призваны для того, чтобы ваш agile процесс оставался agile — благодаря именно ретроспективе, процесс глобально должен меняться под проект, под местные условия, под местные проблемы. Ибо Agile это не просто спринты и бэклог, а именно возможность подстроить процесс разработки под мелкие нюансы любого проекта. Без ретроспективы, изменения будут мелочными. Но да, именно менеджер должен сделать ретро-митинги полезными.
        0

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

        –1

        Спасибо за статью.
        Пишите, пожалуйста, еще.

          0

          Спасибо

          0
          Ретроспектива хороша если команда новая и не сработанная. Также если есть проблемы в проекте и спринтах. Но когда все хорошо в проекте то про ретроспективу забывают…
            +1
            Верно, когда все хорошо — хорошо, нарабатывается автоматизм успеха! Но на мой взгляд, без ретроспектив такой автоматизм недостаточно осознан.
              0
              Но когда все хорошо в проекте то про ретроспективу забывают…

              Если все хорошо, то ретроспектива переходит на 4-й уровень — неосознанная компетентность.
              +2

              В идеальном случае вести ретроспективу должен внешний фасилитатор. Его основная задача помимо непосредственно модераторства самой встречи — взглянуть на участников и их обсуждение со стороны и обратить внимание на моменты, на которые у команды глаз замылилился за время совместной работы.
              Очень часто именно сработанные команды забивают на "настоящую" ретроспективу из-за отсутствия фасилитатора, способного выдернуть их из привычного состояния, чтобы взглянуть на друг на друга с другого ракурса.
              Для того, чтобы ретроспективу мог проводить кто-то из членов команды, нужно иметь хороший опыт и навыки в этом, и постоянно переключаться между ролями, что совсем не простая задача.
              Ну и отдельная тема — подготовка к ретроспективе, потому как просто собраться и поболтать на тему "Ну что, как оно?" — это не ретроспектива. Мне в этом плане очень понравился Retromat.

                0
                Наверное, даже базовая ретроспектива полезна — выбрать 1-2 действия из зоны влияния своей команды, и развивать их. Какие наши действия помогали добиваться целей итерации? Что будет полезно делать еще больше?
                0
                У вас такое когда-либо было? Пишите в комментариях, что вы предприняли.
                Было, можно почитать тут как мы внедряли Agile и повысили экономические показатели разработки более чем в 5 раз в течении года. Стресс навсегда ушел из рабочей атмосферы.

                Автору спасибо за то, что он затронул важную и интересную тему. Психология и в самом деле существенно повлияла на становление Agile, и все потому что Kent Beck испытал в детстве приступ панической атаки, когда он заблудился вместе с мальчишками в лесу, об этом он рассказывает в "Planning Extreme Programming". А если открыть список использованной Кент Беком литературы в «Extreme Programming Explained» 1st edition, то можно обнаружить весьма внушительный список книг по психологии и философии.
                  0
                  Спасибо. Взял на заметку «Extreme Programming Explained» 2 edition (November 17, 2004).
                    0
                    Лучше начинать с первого издания. Второе издание подходит лучше для формализации процессов, и оно лучше адаптировано под сложившуюся на рынке обстановку. Но для понимания лучше все-таки первое издание. Это почти что две разные книги. Прочесть стоит обе. На русский было переведено только первое издание, если я не ошибаюсь. Ценность второго издания еще и в том, что его легче сочетать со Scrum-процессом (подробней эту тему раскрывает Henrik Kniberg в «Scrum and XP from the Trenches: How We Do Scrum» 2nd edition).

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

                  Самое читаемое