Правило "двох піц" від Amazon: командний воркшоп як вправа

Amazon була однією з перших компаній, яка застосувала гнучкі методи роботи у великому масштабі - зовсім не покладаючись на Scrum або інші гнучкі фреймворки. Ключовим елементом для гнучких команд в Amazon було правило “Two Pizza Teams”.

Дві команди піци Amazon: Не так просто, як здається

Правило “Дві піци в команді” говорить, що команда може бути достатньо великою, щоб прогодуватись 2 піцами. До речі, це правило належить самому засновнику Amazon Джеффу Безосу.

Незважаючи на те, що з моменту виникнення цього правила піци минули десятиліття, Amazon все ще дотримується “правила команди з двох піц”. Дивіться: Вступ до DevOps на AWS. Ідея малих самоорганізованих команд, таким чином, здається, має позачасову універсальну цінність. 

Навіть якщо ідея малих команд звучить просто, є ще кілька передумов, які необхідно взяти до уваги, щоб максимізувати вплив малих команд на гнучкість компанії. 

Тож давайте розглянемо, як ви можете виміряти та покращити цю філософію управління та її передумови у ваших командах:

Health Check: Команда Amazon Two Pizza

Основна ідея правила “Дві команди піци” полягає в тому, що менші команди можуть діяти і реагувати швидше. Ця спритність часто є важливим диференціюючим фактором при розробці програмного забезпечення, щоб залишатися конкурентоспроможними.

Однак для того, щоб ці невеликі команди могли діяти швидше, необхідно виконати кілька передумов:

• Команда має чітку мету і відчуває повну відповідальність за її досягнення.
  Строго кажучи, команда без спільної мети - це не команда, а група людей. Якщо команда не бере на себе відповідальність за чітко визначену мету, розмір команди не зможе суттєво вплинути на гнучкість.
• Члени команди володіють усіма необхідними навичками для досягнення власних цілей.
  Ваша команда складається лише з людей з однієї спеціалізації? Це не гнучка команда: команди Agile є крос-функціональними і мають всі ролі та навички, необхідні для досягнення поставлених цілей: бізнес-аналітики, дизайнери продуктів, розробники тощо. Склад завжди повинен відповідати меті команди.
• Команда має всі повноваження та ресурси для прийняття рішень, а тому не залежить від третіх осіб у досягненні наших цілей.
  Якщо команда сильно залежить від інших команд або осіб, які приймають рішення, це вбиває будь-яку гнучкість у зародку. Команда повинна мати можливість самостійно випробовувати технології, генерувати дані для прийняття рішень та отримувати прямий зворотній зв’язок від клієнтів.
• Команда має прямий доступ до клієнтів для отримання зворотного зв’язку.
  Якщо команда з двох піцерій просто виконує замовлення, не маючи жодного контакту з клієнтами, це лише обмежена перспектива. Щоб ваша організація дійсно стала більш гнучкою в цілому, кожна команда повинна мати прямий доступ до своїх клієнтів, щоб отримувати відгуки клієнтів і реагувати на них без обхідних шляхів.
  Дивіться також: Принцип клієнтоорієнтованості Amazon

Тож перш ніж бігти скорочувати свої команди, вам неодмінно слід подбати про ці передумови. Хорошим форматом воркшопу, щоб перевірити цю “Дві піци Health Check”, є наступна ретроспектива:

Ретроспектива команди Amazon Two Pizza

Завдяки цій ретроспективі Two Pizza Team ви можете проаналізувати передумови разом зі своєю командою та ініціювати подальший розвиток:

Як це зробити

Amazon Two Pizza Team Health Check: Як проходить ретроспектива

1. Випадковий Icebreaker (2-5 хвилин)

   Echometer надає вам генератор випадкових питань для реєстрації.

2. Огляд відкритих заходів (2-5 хвилин)

   Перш ніж почати з новими темами, слід поговорити про контроль ефективності того, що сталося з заходами з минулих ретроспектив. Echometer автоматично перераховує всі відкриті пункти дій з минулих ретроспектив.

3. Health Check

   Усі члени команди можуть анонімно відповідати на перевірки працездатності за шкалою. Потім перегляньте результати перевірок працездатності разом і, якщо необхідно, запишіть додаткові коментарі. Якщо ви використовуєте ті самі перевірки працездатності в кількох ретроспективах, ви також можете відстежувати тенденції з часом в Echometer.

   • У нас є чітка командна мета, за яку ми несемо повну відповідальність.
   • У нас в команді є всі навички для досягнення поставлених цілей.
   • Як команда, ми маємо все необхідне для досягнення наших цілей незалежно від третіх осіб.
   • Як команді, нам легко збирати відгуки клієнтів і реагувати на них.

4. Обговорення ретро-тем

   Використовуйте наступні відкриті питання, щоб зібрати ваші найважливіші висновки. Спочатку кожен окремо. Echometer дозволяє відкривати кожен стовпець ретро-дошки окремо, щоб потім представити та згрупувати відгуки.

   • Яких навичок чи знань нам найбільше бракує в команді?
   • У яких ситуаціях ми як команда залежимо від третіх осіб у досягненні наших цілей?
   • Що допоможе нам швидше реагувати на потреби та відгуки клієнтів?

5. Універсальне питання (рекомендовано)

   Щоб інші теми також мали місце:

   • Про що ще ви хочете поговорити на ретроспективі?

6. Пріоритезація / Голосування (5 хвилин)

   На ретро-дошці в Echometer ви можете легко розставити пріоритети для відгуків за допомогою голосування. Голосування, звичайно, є анонімним.

7. Визначення заходів (10-20 хвилин)

   За допомогою символу "плюс" на відгуку можна створити пов'язаний захід. Ще не впевнені, який захід буде правильним? Тоді відкрийте дошку для обговорення з цієї теми за допомогою символу "плюс", щоб провести мозковий штурм щодо основних причин і можливих заходів.

8. Виїзд / Закриття (5 хвилин)

   Echometer дозволяє збирати анонімні відгуки від команди про те, наскільки корисною була ретроспектива. Це створює оцінку ROTI ("Retrun On Time Invested"), яку ви можете відстежувати з часом.

Amazon Two Pizza Team Health Check

Питання перевірки працездатності (шкала)

У нас є чітка командна мета, за яку ми несемо повну відповідальність.

Зовсім не згоденПовністю згоден.

У нас в команді є всі навички для досягнення поставлених цілей.

Зовсім не згоденПовністю згоден.

Як команда, ми маємо все необхідне для досягнення наших цілей незалежно від третіх осіб.

Зовсім не згоденПовністю згоден.

Як команді, нам легко збирати відгуки клієнтів і реагувати на них.

Зовсім не згоденПовністю згоден.

Відкриті питання

Яких навичок чи знань нам найбільше бракує в команді?

У яких ситуаціях ми як команда залежимо від третіх осіб у досягненні наших цілей?

Що допоможе нам швидше реагувати на потреби та відгуки клієнтів?

Відкрийте це ретро заразПристосуватися...

Висновок: правило двох піцерій від Amazon

Правило “Дві команди для піци” справедливо зберігає свою актуальність протягом багатьох років. Однак важливо зазначити, що розмір команди сам по собі не є гарантією гнучкості організації.

Тільки в поєднанні з чіткими цілями команди та ефективними командами, які можуть розробляти рішення в прямому контакті з клієнтами без внутрішніх залежностей, організація може отримати вигоду від більшої задоволеності клієнтів та швидшої швидкості розвитку на ринку. 

Залежно від контексту компанії, часто недостатньо просто подивитися на окремі команди. Як правило, організаційна структура також має бути переглянута, щоб створити умови для високоефективної гнучкої компанії:

Щоб по-справжньому стати високоефективною гнучкою організацією, ви маєте по-іншому подивитися на структуру своєї організації та бути готовими змінити своє мислення й поведінку.

Том Годден, AWS Enterprise Strategist, джерело: Amazon Executive Insights

Дивіться також у цьому контексті: “Менталітет першого дня” Amazon

Я сподіваюся, що ретроспектива команди “Дві піци” стане поштовхом до створення таких умов для вашої команди. І, можливо, вона також дасть хорошу поживу для роздумів на організаційному рівні!

Бонус: Чи хотіли б ви вчитися у інших піонерів гнучкості, таких як Netflix?

Ми також розглянули інноваційну культуру Netflix і підготували для вас кілька форматів воркшопів!

• Чому Netflix всі результати (включаючи збої)
• Netflix не має процесів прийняття рішень, але має поінформованих капітанів
• Ідеї повинні бути соціалізовані на ранній стадії в Netflix
• Мислити ставками та тестувати ідеї