Приховані витрати конкуренції всередині команди

Блогер та розробник Джозеф Круз розповів кілька історій про внутрішню конкуренцію в ІТ-командах й поділився тим, як отримати вигоду з такого «змагання».

Пропонуємо вам переклад його його авторського блогу від нашої редакції. Далі — слово автору.

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

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

Приклади з життя

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

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

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

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

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

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

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

До речі, деякі вважають такий підхід однією з головних причин провалу компанії.

Нав’язування такої конкуренції всередині команди змушує співробітників працювати в стилі «перемога-поразка» — моделі, в якій виграш однієї сторони обов’язково означає програш іншої (і навпаки). Якщо я виграю, то ти програєш. Якщо ти виграєш, то я програю. Що в цьому поганого?

Перемога-поразка

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

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

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

Думаю, кожен з нас хоча б раз чув щось подібне:

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

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

Проблеми вирішуються дуже довго або не вирішуються взагалі

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

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

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

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

Проблеми з’являються з нізвідки

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

Наприклад, програміст може внести зміни в код великої кількості файлів без консультацій, знаючи, що над ними зараз працюють кілька людей. У цьому випадку цілком можливо почути від автора коміту щось на кшталт: «Вони цього потребують — нехай зливають. Я роблю свою роботу».

Інший приклад: «Хоча Джеймс може виконувати такі завдання, я не піду до нього, а розберуся сам. Інакше керівництво вирішить, що я гірший за Джеймса». Це також яскравий прояв суперництва між членами команди, яке може раптово створити проблему.

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

Прихований саботаж

Прихований саботаж — найруйнівніший прояв внутрішньої конкуренції. Це навмисне ускладнення роботи інших членів команди. Яскравим прикладом такого саботажу є відомий рядок коду C++: «#define TRUE FALSE //щасливого дебагування, с*чки».

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

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

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

Байдужість і відсутність спільних цілей

«Що ви від мене хочете? Я пишу код, все інше мене не стосується». Це твердження зрозуміле. Заробітна плата, кар’єра та визнання співробітника не залежать від успішності проекту або від результату його роботи, від чогось значущого і потрібного людям, а тільки від того, як швидко він пише свій код.

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

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

Як можна мотивувати людей до спільної справи?

Win-win

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

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

Для цього достатньо, щоб успіх кожного члена команди приносив користь усім іншим. Працюйте за моделлю «Win-Win». Ця модель дуже добре описана у чудовій книзі Стівена Кові (якщо ви її ще не читали, біжіть до книгарні!).

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

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

І, найголовніше, необхідно чітко і ясно донести до всіх ідею: «у нас у всіх одна мета, ми всі робимо одне й те саме», і не порушувати цей підхід ні словами, ні діями.

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

Тільки в цьому випадку команда матиме шанс зробити щось значуще, а не просто витирати клавіатури комп’ютерів і випускати клони марних ремесел знову і знову.

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