Mar 25, 2018
Кросс-функциональные команды и самоорганизация в основе Agile, часть 3
Прежде всего я хотел бы извиниться за столь длительную паузу, взятую мной с момента публикации предыдущей статьи из цикла “Кросс-функциональные команды и самоорганизация в основе Agile”. Если честно, я уже и не планировал продолжать писать на эту тему, так как не считаю что я способен сказать что-то новое на столь избитую тему, но Вы заставили меня передумать.
Именно благодаря письмам от Medium, содержащим статистику просмотров, прочтений и реакций на предыдущие статьи я решил снова “взять в руки перо”.
Несмотря на то, что скоро в моей жизни произойдут существенные изменения, я постараюсь больше не “пропадать с экранов” и регулярно делиться с Вами своими мыслями об Agile и всем, что с ним связано. А поводов и материалов для этих размышлений скоро станет еще больше!
Самоорганизация
В предыдущей статье из цикла мы разобрались с понятием кросс-функциональных команд, “официально” привнесённым в мир Agile фреймворком Scrum, и постарались донести их преимущество относительно традиционного деления по “зонам ответственности”. Но теперь перед нами обязательно встает вопрос — как организовать работу этой команды? Вот что говорит нам об этом Scrum Guide:
Самоорганизующиеся команды самостоятельно решают, как выполнять свою работу, а не следуют внешним указаниям. Кросс-функциональные команды обладают всеми необходимыми компетенциями для выполнения работы и не зависят от людей, которые не входят в команду.
Так как мы рассматриваем понятие самоорганизации в отрыве от конкретного фреймворка, нам стоит пойти “от основ” и обратиться к 12 принципам, описанным в Agile Manifesto. Ключевыми в данном контексте для нас являются следующие из них (здесь и далее приводятся формулировки принципов из официальной русскоязычной версии Agile Manifesto):
Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
Ключевыми словами здесь являются понятия “мотивированные профессионалы” (что, к слову, не совсем верно, ведь в оригинальной версии Agile Manifesto речь идет о “motivated individuals”) и “доверие”. Мотивация отдельных специалистов и людей в целом — тема очень глубокая и сложная. Я постараюсь предельно кратко затронуть её в рамках данной статьи и раскрыть в своих дальнейших публикациях, но для начала предлагаю сосредоточиться на второй части этого словосочетания — “профессионалы”.
В основе любого процесса поиска и найма сотрудников лежит последовательность мероприятий, направленная на определение уровня знаний и опытности сотрудника. Помимо “welcome”, “behavioural” и других разновидностей общих интервью, почти каждый технический специалист проходит стадии технического интервью и выполнения технического задания. Подобные проверки обычно проходят даже “нетехнические” специалисты, в том числе и Agile Coach или Scrum Master. В большинстве компаний именно по итогам этих 2 этапов принимается решение о его приеме на работу, будущем grade специалиста, а зачастую и о размере предлагаемой заработной платы. Успешное прохождение данного процесса подразумевает, что компания считает выявленный уровень экспертизы специалиста соответствующим требованиям компании или конкретного проекта.
Следующим этапом обычно становится процесс постепенного введения сотрудника в курс дел: его знакомят с существующими правилами работы (как гласными, так и негласными); дают посмотреть существующий код (в идеале, знакомят с принятыми в компании или на конкретном проекте code style требованиями)/тест кейсы/style guide (нужное подчеркнуть) и инструментарий; дают поработать над простыми задачами из бэклога или “посидеть на тех.поддержке” и постепенно подключают в имеющийся workflow команды, где он работает под присмотром более опытных сотрудников, регулярно передает написанный код на code review (Вы же практикуете code review, правда?) или даже принимает участие в регулярных pair programming сессиях.
Таким образом, к моменту наступления часа Х мы имеем в распоряжении специалиста, обладающего достаточным уровнем экспертизы, (1) прошедшего строгий процесс отбора (2) и последующее обучение стандартам работы компании/команды (3), имеющего достаточный уровень представления о проекте (4) и опытного куратора, который регулярно проводит code review (5). Позволяет ли существование этих 5 факторов считать нам человека “профессионалом”?
Если Ваш ответ “нет”, и кто-то из вас двоих все еще работает в Вашей организации, то у Вашей компании очень большие проблемы.
Для тех, чей ответ “да”, я продолжу.
Секрет мотивации
Итак, мы работаем в окружении людей, которых без зазрения совести можно назвать “профессионалами своего дела”. Все они, так или иначе, принимают активное участие в жизни компании и продукта/проекта, внося свой вклад выраженный в знаниях, опыте и идеях. Почему бы не дать этим профессионалам свободу действий и принятия решений хотя бы в тех вопросах, где уровень их компетенции явно выше менеджера? К сожалению, большинство руководителей и даже самих менеджеров не решаются на такой шаг, упуская серьезную выгоду как для проекта, так и для всей компании в целом.
Согласно результатами многочисленных исследований, проводившихся по обеим сторонам Атлантического океана, финансовая составляющая уже давно не является ключом к мотивации сотрудников. Да, уровень финансового благополучия россиян значительно отстает от жителей многих европейских и североамериканских стран, но специалистов из IT отрасли это затрагивает не столь сильно.
Согласно ставшей настоящим культурным феноменом книге Дэниел Пинка “Drive: The Surprising Truth About What Motivates Us”, тремя ключевыми элементами мотивации для большинства людей служат:
- “Автономность” или, говоря другими словами, Свобода самореализации
- “Мастерство” или Возможность самосовершенствоваться
- “Причина” или Возможность служения высшей цели
Основываясь на своем личном опыте, хотел бы добавить что всё это действительно работает, при условии стабильности и удовлетворения базовых финансовых потребностей.
Предоставляя возможность прямо влиять на архитектурные решения, выбор используемых технологий, способ решения задач и даже непосредственно на судьбу продукта/проекта (предлагая на рассмотрение какие-то собственные идеи и решения) мы создаем условия, в которых сотрудникам интересно работать, решать задачи и вносить реальный вклад в жизнь продукта. Если при этом Ваш продукт еще и решает какую-либо значимую социальную или иную проблему — уровень мотивации взлетает до небес. В качестве актуального и яркого примера в пользу этого довода можно привести инженеров SpaceX.
Самоорганизация != Анархия
Любой адепт административно-командной системы управления с ходу назовет вам ключевую проблему самоорганизации и отсутствия микроменеджмента: “Рано или поздно все это скатывается в анархию!”. Но так ли это на самом деле? И что именно вкладывают в термин “самоорганизация” авторы Agile Manifesto?
Чтобы разобраться в этом, давайте взглянем на приведенную ниже схему:
Слева по вертикали у нас расположены зоны ответственности:
- Определение общего направления движения;
- Дизайн команд и определение их контекста;
- Контроль и управление рабочим процессом;
- Выполнение задач.
По горизонтали под таблицей расположены стадии самостоятельности команд. Синий цвет “квадратов” обозначает, что данная зона ответственности лежит на менеджере, бирюзовый — на команде. Как видим, самоорганизующаяся (Self-Organizing) команда отвечает лишь за выполнение задач (в том числе, за выбор способа решения этих задач) и за контроль за процессом их выполнения. При этом, определение контекста существования всей компании/продукта и отдельной команды, а также её дизайн, лежат на менеджменте. Безусловно, даже такая система “сдержек и противовесов” не позволяет избежать анархии в 100 случаях из 100, но существенно снижает такую вероятность.
При этом, очень важно существование в коллективе не просто “менеджера”, но лидера — человека, способного вдохновлять других людей учиться чему-то новому, создавать что-то новое и следовать за ним не из-за официального регламента или иерархии, а в силу его личностных и профессиональных качеств. Именно такой человек должен формировать видение продукта и направлять всех людей, вовлеченных в работу над ним.
Эпилог
Подводя итоги данного цикла статей, хотелось бы еще раз быстро пройтись по всему сказанному в обратном направлении и понять, в чем же действительно преимущества Agile подхода.
P.S. Спасибо всем тем, кто дочитал до этого момента! Именно Вы мотивируете меня продолжать публиковать мои мысли онлайн и я буду очень благодарен за комментарии с критикой и/или похвалой (но лучше с критикой;) ).
P.P.S. Уже после написания этой статьи я снова вернулся к “ошибке” в русскоязычном переводе Agile Manifesto и задумался над тем, как существенно она меняет весь контекст принципа. Несмотря на то, что я все-таки склонен полагать что это именно ошибка, а не намеренное искажение первоначального смысла, в ближайшее время я обязательно опубликую свои мысли на этот счёт.
