Кросс-функциональные команды и самоорганизация в основе 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”, тремя ключевыми элементами мотивации для большинства людей служат:

Source: https://www.tutor2u.net/business/reference/motivation-pink-three-elements-of-intrinsic-motivation
  1. “Автономность” или, говоря другими словами, Свобода самореализации
  2. “Мастерство” или Возможность самосовершенствоваться
  3. “Причина” или Возможность служения высшей цели

Основываясь на своем личном опыте, хотел бы добавить что всё это действительно работает, при условии стабильности и удовлетворения базовых финансовых потребностей.

Предоставляя возможность прямо влиять на архитектурные решения, выбор используемых технологий, способ решения задач и даже непосредственно на судьбу продукта/проекта (предлагая на рассмотрение какие-то собственные идеи и решения) мы создаем условия, в которых сотрудникам интересно работать, решать задачи и вносить реальный вклад в жизнь продукта. Если при этом Ваш продукт еще и решает какую-либо значимую социальную или иную проблему — уровень мотивации взлетает до небес. В качестве актуального и яркого примера в пользу этого довода можно привести инженеров SpaceX.

Самоорганизация != Анархия

Любой адепт административно-командной системы управления с ходу назовет вам ключевую проблему самоорганизации и отсутствия микроменеджмента: “Рано или поздно все это скатывается в анархию!”. Но так ли это на самом деле? И что именно вкладывают в термин “самоорганизация” авторы Agile Manifesto?

Чтобы разобраться в этом, давайте взглянем на приведенную ниже схему:

Source: https://www.mountaingoatsoftware.com/blog/preview/1680

Слева по вертикали у нас расположены зоны ответственности:

  • Определение общего направления движения;
  • Дизайн команд и определение их контекста;
  • Контроль и управление рабочим процессом;
  • Выполнение задач.

По горизонтали под таблицей расположены стадии самостоятельности команд. Синий цвет “квадратов” обозначает, что данная зона ответственности лежит на менеджере, бирюзовый — на команде. Как видим, самоорганизующаяся (Self-Organizing) команда отвечает лишь за выполнение задач (в том числе, за выбор способа решения этих задач) и за контроль за процессом их выполнения. При этом, определение контекста существования всей компании/продукта и отдельной команды, а также её дизайн, лежат на менеджменте. Безусловно, даже такая система “сдержек и противовесов” не позволяет избежать анархии в 100 случаях из 100, но существенно снижает такую вероятность.

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

Эпилог

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

P.S. Спасибо всем тем, кто дочитал до этого момента! Именно Вы мотивируете меня продолжать публиковать мои мысли онлайн и я буду очень благодарен за комментарии с критикой и/или похвалой (но лучше с критикой;) ).

P.P.S. Уже после написания этой статьи я снова вернулся к “ошибке” в русскоязычном переводе Agile Manifesto и задумался над тем, как существенно она меняет весь контекст принципа. Несмотря на то, что я все-таки склонен полагать что это именно ошибка, а не намеренное искажение первоначального смысла, в ближайшее время я обязательно опубликую свои мысли на этот счёт.

--

--

Org Design consultant, Trainer & LeSS Coach @ Agile Expat | Head of Agile Practices @ PandaDoc | Professional Scrum Master | CMI Team Coach | Kanban Coach

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Agile Expat by Denis Salnikov

Agile Expat by Denis Salnikov

Org Design consultant, Trainer & LeSS Coach @ Agile Expat | Head of Agile Practices @ PandaDoc | Professional Scrum Master | CMI Team Coach | Kanban Coach