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

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

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

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

Коли фактичний результат гірший ніж очікуваний, але конкретної причини не видно – згадують про командну відповідальність

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

Припустимо, ваша тепер-безвідповідальна-але-раніше-відповідальна-команда налічує 10 людей. Половина з них йде у відпустку. Тоді що, відповідальність в команді падає ще нижче, чи навпаки – росте на 50%, чи без змін залишається? Якщо в команду приходить новенький, він відразу починає бути носієм безвідповідальності? А можна звільнити когось найменш відповідального в команді, щоб підняти загальний рівень?
Дурацькі, але цікаві питання, еге ж? 

Відповідальність то є спроможність

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

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

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

Носій спроможності завжди окрема особистість

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

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

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

Що ще впливає на спроможність?

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

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

Відповідальність (спроможність) з соромом (осудження провиною) не дружать. Сором – огидне болюче відчуття від якого тікають у злість (“сам дурак”, “менеджери знову наменеджерили”) або у відсторонення (емоційне та когнітивне). Якщо вам потрібна купка однозадачних големів – продовжуйте нарікати команді їх винуватістю.

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

Буває, що команда була спроможна, але дійсно завалила терміни/проект/поставку. Цей текст не про корупцію у міноборони, а про ІТ-розробку, з ККУ ми щодня не звіряємось. Якщо фахівець накоїв дурні та підвів інших – він сам собі стане суворим суддею та дасть собі ради. Але якщо йому і за вухом не свербить, чи дурнем прикидається або на інших наговорює… то взагалі пофіг, що ви будете з цим робити. Люди не міняються, його не виправити. 

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

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

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

Декомпозиція складних питань

Комплексні проблеми можна розділити на менші та простіші. Ось як епіки декомпозують на юзер сторіки та невеликі use case, так і ваші проблеми можна пріоритезувати та розкласти на нормального розміру задачі, тримаючі у фокусі щоб що ви це робите. 

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

Розкладіть “проблему знову зірваного реліза” на діскавері та делівері фази, на етапи моделювання архітектури та рефайнментів, на визначення на формування MVP, на планування спринтів та комунікацію під час дейліків, на підготовку тестових даних та автоматизацію CI’я. Заплутана проблема розсиплеться на звичайні задачки.  

Прозорість та безпека в комунікаціях

Прозорість в діях, мотивації та ставленні усуває добру половину проблем в команді. Чи знають бекендери з якими проблемах живуть тестувальники, чи розуміють куа, як виглядає день продуктового дизайнера, чи в курсі фронти щоденної рутини продакта, чи може маркетолог пояснити специфіку вашого SDLC, чи може юікс райтер викласти спринтові DoRʼи та DoDʼи?

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

Прозорість є наслідком безпеки. Якщо в команді можна казати “ні”, без догани обговорювати помилки, щиро дякувати та просити допомогу, сваритися і миритися, обговорювати чутливі теми – значить в команді безпечно. У вас може бути не сама безпечна атмосфера загалом в компанії, але ви можете підтримувати безпечну середу всередині команди. Важко пояснити, як небезпечне зробити безпечним, але можна плекати такі умови, коли колегам буде кортіти ділитися на роботі ще й особистим або бути формально приналежним до цієї групи людей (і про це окремо статтю напишу). Та й взагалі, в мережі багато прикладів тім-білдінгових та безпекових активностей. 

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

Висновки та патетичні тези

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

До біса ту відповідальність! Створюйте умови🤘

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

Невеличка команда особистостей, які відчувають себе спроможними фахівцями, вкладаються в спільну справу як RHCP на Venice Beach.