Як успішно сформувати команду і перейти до продуктивної роботи

У цій статті поговоримо про команду і командоутворенні: як з розрізнених людей зробити згуртовану команду і досягти цілей, поставлених перед цією командою; що робити тимлиду, а також будь-якому члену команди на кожному етапі формування команди, щоб заощадити сили в русі до мети.

У мене є досвід роботи в командах (від 2 до 20 осіб) більше 10 років, я виступала в ролі менеджера, так і в ролі члена команди, і багато разів чула і спостерігала, як новоспечена команда зустрічалася з нерозумінням один одного в роботі, як хотілося продуктивно співпрацювати, але не виходило.

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

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

Але раз вже ми розуміємо, що робота в команді неминуча/необхідна/бажана/підставте своє, то варто детально розібратися, як працює цей інструмент, як він влаштований зсередини, які вигоди є для керівника і кожного учасника і як користуватися ними собі і іншим на благо. Ну гаразд, хоча б собі :)

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

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

Розберемо механізм командоутворення на прикладі моделі Брюса Такмана , який стверджує, що будь-яка команда проходить 5 стадій розвитку:

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

Виходить, що модель командоутворення — це інструмент для того, щоб чітко побачити модель формування і розвитку команди, щоб з розрізнених людей зробити згуртовану команду і досягти поставлених цілей. І зробити це найменш витратним для всіх способом, витративши менше нервів і отримавши побільше класних результатів.

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

Отже, детальніше про кожну стадію розвитку команди.

Формування (forming)

На стадії формування (forming) відбуваються такі основні процеси: команда збирається, знайомиться, обговорює завдання, терміни; обумовлюються правила взаємодії, методи і частоту контролю.

Щоб успішно пройти фазу формування і рухатися далі, виконайте такі завдання:

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

Щоб ці проблеми запобігти, ліду варто зробити такі дії:

Останньому пункту приділю особливу увагу. В команді так чи інакше з'являється лідер — або формально призначений лід, або неформальний лідер, якого всі слухають і за яким йдуть. Будь-яка команда розпадеться, якщо лідер пропаде і на його місці не з'явиться новий. Команда живе за рахунок енергії лідера. Енергія лідера — це паливо в бензобаку команди. Він задає напрям, прибирає перешкоди, приймає рішення у складних ситуаціях.

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

Ну не можна ж постійно бути на піку енергії, скажете ви! І будете праві, це складно.

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

Команда за інерцією йшла вперед, не в такому швидкому темпі, як раніше, але все ж. Василь відновлював сили, потім повернувся в лад як раз, коли колеги вже втомилися. І всі разом стали знову потихеньку розганятися на енергії Василя, яка знову пожвавилося.

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

Якщо ви не лід, а один з учасників команди, все одно можете вплинути в командоутворенні на:

Притирання (storming)

Йдемо далі. На стадії притирання (storming) зібрана команда проходить «бойове хрещення». Відбувається розбіжність поглядів і тертя в спілкуванні, тролінг, конфлікти. Команда хотіла б робити свою роботу, веде всіх до спільної мети, але на шляху до результату виникає безліч перепон. Кожен член команди реагує по-своєму: хтось стійко рухається далі, інший впадає в смуток від того, що немає «миру в усьому світі», і гальмує із завданнями, хто активно бореться за свої права і обов'язки, тільки це не завжди допомагає рухатися до результату.

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

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

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

Що може зробити лід в таку активну і насичену пору життя команди:

Тимлид Віталій бачив, що його новоспечена команда з 5 чоловік стала часто сваритися: мітинги перетворилися в балаган, частина питань залишалася невирішеною за результатами зустрічей, відчувалося напруження при спілкуванні в чаті.

«Лебідь, рак і щука», — думав Віталій. А мета начебто у всіх одна. На найближчих зборах команди Віталій ще раз прояснив очікуваний результат проекту, у кого яка роль і обов'язки. Також попросив команду підготувати перелік того, чим кожен незадоволений і що пропонує, і запланував 1-1 зустрічі з кожним для обговорення. Через два тижні Віталій зібрав інформацію від всіх членів команди, виніс її на обговорення з усіма, досяг прийняття рішень по кожному пункту.

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

Якщо ви не лід, а рядовий працівник, ви теж можете допомогти своїй команді на цьому етапі:

Тестувальник Сергій завжди емоційно сприймав затримки поставок з боку команди розробників. «Знову провтикали! Знову напартачили! Знову мені сидіти допізна в п'ятницю!» — роїлося в голові у Сергія, але назовні показувалася лише злісна гримаса і ні слова про те, що його не влаштовувало. Сергій злісно лупив боксерську грушу в спортзалі, випускаючи злість після важкого робочого дня. Це допомагало, але ненадовго. На наступний день Сергій усвідомлював, що нічого не змінилося і в п'ятницю, як і раніше, доведеться затриматися з-за цих нехороших людей, і злість виникала знову.

Він вирішив розповісти все як є свого тимлиду. Той вислухав невдоволення тестувальника і підсумував: «Я правильно зрозумів, що ти вболіваєш за наш проект і тобі в цілому подобається працювати в команді, але тебе злять затримки з боку розробки і недостатнє час на тестування?». Сергій підтвердив. «Тоді ми могли б винести цю проблему на обговорення з усією командою, а також озвучити пропоновані тобою рішення: скоротити кількість завдань на розробку в спринті, щоб залишалося достатньо часу на тестування». Так вони і зробили.

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

Хочу ще додати про стадію штормингу.

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

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

Так, люди різні, буває складно прийняти і подружити всіх-всіх загальнокомандних «тарганів».

Фокусуйтеся на командному цілі та очікувані результати, а також на одержанні задоволення від процесу. І штормінг пройде легше.

Нормалізація (norming)

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

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

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

Якщо на попередній стадії лід багато часу присвячував виконання завдань (зокрема soft-related, наприклад, ведення мітингів) самостійно, то на стадії норминга можна частково делегувати їх. Зазвичай до цього моменту вже видно, кому і що варто довірити.

Будь-який співробітник теж може посприяти командного нормалізації: продовжувати конструктивно спілкуватися в команді, озвучувати свої ідеї, зворотний зв'язок, пропозиції, залишатися залученими до життя і пріоритети команди, продовжувати виконувати свої завдання найкращим чином.

Perform-perform-perform!

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

Співробітники можуть трохи розслабитися (але не сильно!) та насолодитися реальної командною роботою.

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

Не думаю, що про цю стадію варто багато розповідати. Нічого обговорювати, коли все добре. До того ж завдань зазвичай багато, тому команда просто працює. Тобто ні, не просто працює, а працює супершвидко, суперрезультативно, в кайф, з посмішкою нарешті!

Розформування (adjourning)

І наостанок кілька слів про заключну стадію спільної роботи команди — розформування (adjourning) . У деяких команд вона не настає в тому разі, якщо проект довготривалий. Також ця стадія може статися після штормингу, а не перформинга: якщо проект закінчився раніше, ніж бурління і конфлікти в команді.

Отже, розформування — це прощання команди. Проект підходить до кінця, команда фіксує результати, яких досягла, озвучує подяки, виносить уроки спільної роботи, ділиться зворотним зв'язком. І сподівається зустрітися ще на одному проекті в майбутньому (або не сподівається зустрітися :))

Ось ми і розглянули всі стадії командоутворення та копнули трохи глибше в найбільш проблемні місця.

Вважаю важливим сказати, що не буває певних строків, за які потрібно обов'язково пройти кожну стадію розвитку команди.

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

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

На закуску

В теорії воно все бачиться легко, а на практиці, як правило, все заплутано і незрозуміло. У кожного своя ситуація, контекст, цінності і мотивація, унікальні люди і команда відповідно. Але все ж ми всі схожі тим, що унікальні :)

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

Якщо зробити все по моделі Такмана і впровадити рекомендації щодо дій на кожній стадії, це буде гарантією якогось позитивного сценарію?

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

Якщо працівники працюють віддалено, є відмінності в командоутворенні саме віддаленої команди порівняно з командою, яка сидить в одній кімнаті?

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

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

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

Як ще лідеру можна зрозуміти настрій віддаленої команди:

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

Якщо я лід і не знаю, що там за специфічні мотиватори у кожного члена команди? Вишукувати їх колись і нецікаво, що робити?

Більшість людей зазвичай мотивує як мінімум дві речі: похвала і щирий (!) інтерес. Важлива форма подачі похвали і форма вираження інтересу. Але якщо застосувати хоча б ці два інструменти, плюс давати обіцянки в зоні свого впливу і їх виконувати, то лідер вже запрацює хороший авторитет у команді і йому буде простіше подружити колег.

Бажаю всім вдалих команд і перформинга! «Вдалість» в наших руках!

Опубліковано: 22/07/20 @ 10:00
Розділ Різне

Рекомендуємо:

Із добровольців «Азова» в iOS-розробникі: історія ветерана АТО
Про стажування в NASA за напрямком Data Science та культуру ділитися знаннями — розповідь української програмістки
Як перейти на новий фреймворк і не вбити якість продукту
Зустріч 1:1 на ремоуті: як налагодити процес
Як перестати сидіти в чаті та почати працювати. 10 практик асинхронної комунікації