Вам приходилось испытывать сильные эмоции на работе? Как насчёт страха, внезапно захлестнувшего ваш ? Легко потом работать эффективно? Если ваша организация уже внедрила 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 и потребности мозга». А пока рекомендую обратиться к следующим источникам:
- Канеман. Thinking Fast Thinking Slow
- Мозг. Инструкция по применению. Дэвид Рок
- Дубынин. Лекции о физиологии мозга, «мозг и потребности»
- Описание ретроспективы в SAFE
Автор: Artem Zarafyants
