Приховані резерви команд або 1+1=3

Що таке приховані резерви команд? Це коли при загальних рівних умовах ми чекаємо від команди трохи більше… ніж вона може дати. Буває ситуації, коли тобі щастить з підбором гравців в команду, везе з замовником і поставлений ідеальний процес. Що ще потрібно? А команда не показує результат. У свою чергу, команда зібрана з посередніх хлопців з новачком тім лидом перевиконує план у два рази! Давайте розглянемо в чому секрет на прикладі реальної команди в Scrum процесі.

image

Трохи про себе: мене звати Михайло Попчук, я працюю в Ciklum Consulting Office і займаюся стартом команд. Мої знання та навички базуються на 6-річному досвіді управління проектами в IT. Останні кілька років я працюю з розподіленими командами, використовуючи методології з звучним ім'ям Agile. Це слово звучить досить часто останнім часом: «Agile mindset», «Agile команда», «Agile компанія», "… працюємо по Agile.." і т.д. З цього слова роблять якийсь культ і, виникає таке відчуття, що сподіваються на нього, як на запорука успіху.

Чому? Тому що компанії, що давно з цим шляхом, на своєму досвіді можуть сказати, що гнучкі методології приносять свої плоди:

  • Подвоюється продуктивність
  • 250% зростання якості
  • Зменшується час випуску продукту вдвічі
  • Оптимізується навантаження команди


Ці дані не плід моєї фантазії, а дослідження компанії Rally Software, яка представила їх у звіті Impact Agile Quantified за 2013 рік на підставі аналізу більш ніж 9 тисяч компаній, що використовують її інструменти для управління проектами.
Проте будь-якій людині, якій доводилося впроваджувати гнучкі методології очевидно, що такі результати швидше щось екстраординарне.

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

image

У цій статті я хочу розповісти саме про такому аспекті впровадження Agile, де найчастіше роблять помилки.
Цей реальний випадок стався в моїй роботі. Сам кейс цікавий тим, що дві команди мали умови, максимально наближені один до одного: менеджмент команд був єдиний, робили команди один і той же продукт, впроваджували їм один і той же Scrum framework. А ось отримали вони абсолютно різні результати.

Отже, у нас був Клієнт, який розробляв складний інноваційний продукт. Сам продукт являє собою якусь віртуальну сцену магазину з полицями і товарами, в якому можна проводити навігацію, гуляти між полицями і розглядати товари. Програма збирає статистику про те, куди Ви дивитеся, як Ви рухаєтеся в магазині, на які товари звертаєте увагу та ін. Тобто сам додаток технічно досить складна і включає багато нефункціональних вимог, пов'язаних з архітектурою (платформна клієнтська частина, розподілене додаток). Команда Клієнта перебувала, скажімо, в Норвегії, і займалася backend додатком.

В планах у Клієнта було найняти двох архітекторів, скажімо, в Харкові на три місяці і запустити до них в команду чотирьох розробників. Потім архітектори виходять, і команда «летить» сама. Перший пілот очікували через 4 місяці. Звучить непогано.

Посолити-поперчити?

  • Специфічний запит на фахівців і нетипова завдання для Unity3D.
  • Відсутність досвіду роботи з Unity3D у першої команди і досвіду роботи з побудовою архітектури у нової команди (горезвісних архітекторів знайти так і не вдалося). Відсутність знань про технології і досвіду роботи з віддаленими командами в Норвегії.
  • У харківській команді не було управлінського досвіду у тимлида, команда отримала 1 senior + 2 junior +1 middle Untiy3d/C# інженера.


Трохи лірики.

В Ciklum для кожного проекту існує т.зв. Account team = Client service manager + HR consultant + PM consultant, які дбають про щасливе майбутнє проекту. Природно, після усвідомлення ситуації, оптимізму в нас поменшало. Вугілля і піддавав жару пілот через 4 місяці. Рішення було прийнято — робити фокус наконсолідацію команди (для деяких хлопців це був перший досвід роботи в комерційних проектах, в інших, як розумієте, досвід був невеликий), розкачку мотивації (передбачалося, що з такими малоймовірними термінами випуску проекту, хлопці будуть відчувати постійний тиск) і встановлення ефективного циклу розробки (необхідно було проконтролювати, що буде поставлений ефективний процес, тільки підсилює два попередні досягнення). Особливу увагу слід було приділити управлінню очікуваннями клієнта. Трохи докладніше про це…

Ciklum надає Клієнтам таку послугу, як Own Development Center (ODC) модель, в якій Ciklum наймає людей і забезпечує їх всім необхідним для роботи, а Клієнт керує командою згідно своїм цілям і розсуд. До загальної «радості» це був якраз такий випадок. Клієнт був зацікавлений у допомозі CIklum Consulting Office, а саме в managed services. Це сервіс, де такі хлопці, як я, допомагають Клієнту інтегрувати нову команду в організацію, налагодити там процес, уникнути популярних помилок. В той же час таке залучення тимчасове, відповідно, ми не стають проксирующим елементом між командою і Клієнтом, а тільки консультуємо його з метою ефективно інтегрувати команду в його організацію. Такий підхід дозволяє Клієнту користуватися всіма перевагами ODC, а менеджерам з managed services безболісно виходити.

Клієнт був достатньо відкритим до пропозицій, і наші рекомендації були в тому, щоб іти шляхом встановлення процесу, заснованого на гнучких методологіях, «а-ля» Scrum. Аргументами у нашій пропозиції були складності технічних рішень та невизначеність вимог.

image

І виявилося, що Клієнт вже намагався впровадити Scrum у своїй норвезькій команді і зазнав «фіаско» в тому, що:

  • Команда регулярно не показувала ті результати, які обіцяла і зовсім не переймався з цього приводу.
  • Команда рухалася дуже повільно. У керівництва не було розуміння про продуктивності команди інформації про те, чому ця сама продуктивність настільки низька.
  • Менеджмент хотів внести передбачуваність і отримати спосіб вимірювання продуктивності команди. Команда негативно ставилася до встановлення певного процесу розробки, сприймаючи його як додатковий фактор контролю.
Все це виразно звучало непривабливо для повторення в Харкові☺. У процесі подальшого аналізу виявилося, що у компанії немає встановленого процесу розробки і немає чіткого розуміння, як його встановити для харківської команди. І ось це був момент, коли допомога з боку CIklum Consulting Office була необхідна! І ми засукали рукави й почали працювати. Нагадаю, що команда працювала безпосередньо з представниками Клієнта, так що діяти ми могли тільки на рівні рекомендацій обом сторонам.

Інтро

Клієнт дав мені як менеджеру проекту карт-бланш і не вимагав роботи 8х5. Перші пару днів я водив команду по офісу, розповідаючи про те, що вони будуть робити Продукт і працювати в такому процесі розробки, де навіть сама постановка завдання буде заохочувати її креативне виконання. Замовники будуть на відстані простягнутої руки розповідати, що вони думають про Продукт, а керівництво буде очікувати конструктивної критики і пропозицій від кожного учасника команди. Технічний Директор з боку Клієнта приїхав в харківський офіс для особистого знайомства і роботи з командою протягом тижня. У процесі роботи, він розповідав, як бачить Продукт, хто ним користуватиметься і навіщо Продукт буде потрібен користувачам. Продукт повинен бути доступний в кінці кожної ітерації. Зміст ітерації в тому, щоб не просто зафіксувати проміжок часу, а мати регулярний та частий інкремент продукту.

Планування

Нагадаю, що у домашньої команди виникали складності з ефективним плануванням роботи над таким Продуктом. Завдання було просто титанічна, і технічні рішення були складні. Норвежці виділяли завдання за архітектурним принципом, відповідно, час виконання кожної було до тижня, і при цьому завдання не мали чіткого критерію «готовності». Члени команди були дуже відповідальними і могли «вилизувати» такі завдання тижнями до моменту, коли можна було сказати, що вони готові. При цьому, номінально, вони працювали 2х тижневими ітераціями. Таким чином, для того щоб показати робочий продукт, їм необхідно було планувати спеціальну активність а-ля «підготовка Продукту до демонстрації».
В якості виходу було рішення щодо зменшення розміру завдань і зміщення фокусу на власну функціональність. Ми домовилися про те, що декомпозируем завдання до розміру в 1 день, оцінюємо в ідеальних днями, вводимо критерії готовності (acceptance criteria). Ідея User story на той момент хлопцям не сподобалася, тому ми вирішили залишити опис у форматі завдань. Для того щоб зафіксувати ітеративності у хлопців, які не звикли до такого типу роботи, є хороша практика — придумувати незвичайні назви спринтів. Команда була весела, і тому вирішили називати спринти ім'ям дівчинки, з якою команда фотографується на початку спринту. Так процес планування проходив досить креативно і неформально, ідея добре вписалася, і хлопці сприймали сам процес як щось веселе, загальне і значне.

Демо

Тут мені довелося використовувати кредит довіри менеджменту й раз на два тижні відривати всю організацію від роботи, щоб усі могли подивитися на результати програмування нової команди. На демо команда готувалася окремо: це був і сценарій, і жарти, і звичайно ж, сам продукт доводився до ідеальності. Як результат, хлопці об'єднувалися навколо єдиної мети — показати робочий продукт. Це додало сенсу в ітеративності для завершення циклу і дозволило зафіксувати ідею з частим випуском продукту. Хлопці бачили, що вони роблять те, що потрібно, щонайменше, 40 людей, присутніх на демо, і це, природно, впливало на загальний процес роботи. Очевидно було, що ми всі в одному човні.

Зусилля не пройшли дарма, і команда потрапила у обіцянка першого спринту! Далі більше:

  • Час виходу пілота: 1,5 місяці замість 4 місяців. Час розраховувалося на підставі подання про продуктивності «домашньої команди».
  • Відносна продуктивність щодо норвезької команди: 500% замість 75%. В Ciklum є такий показник — «відносна продуктивність», коли ми запитуємо, наскільки команда тут продуктивна, щодо домашньої. Очевидно, що він суб'єктивний, але дозволяє нам судити про задоволеності очікувань.
  • Команда Клієнта постійно зростає.
  • Успішно впровадження гнучких методологій.
  • Цілі компанії досягнуті.
  • Попадання в ціль спринту 7/8.
Далі апетит Клієнта йти в «нірвану» гнучких методологій почав рости. Прийшов час для використання інструментів управління завданнями (Jira, Confluence), впровадження більш «класичного» підходу до планування, перехождения на user stories і так далі.

Висновок

Важливо те, що, на відміну від домашньої команди, в команді в Харкові, впровадження процесу почали з культури, а не з практик.

image

Давайте приймемо як даність — якщо команда не захоче слідувати якимось правилами, вона не прийме їх.

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

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

Підсумки:

  • Не просто дотримуйтесь правил і методологій!
  • Будьте дійсно Agile — йдіть від цілей і переваг людей в команді, їх рівня усвідомлення технології. Враховуйте рівень Клієнта і команди.
  • Дозвольте команді хоча б почати «бути правилом», працювати так, як їм зручно і цікаво, обговорювати кожну практику і налаштувати її під себе.
  • Адаптуйте!


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.