Ілюстрація Марії Рибак
Рекомендації тімліда, проджект-менеджера, Scrum-майстра.
Стаття написана у співавторстві з у JMind, та у JMind.
Те, як ми поводимося зі співробітниками, наші слова і навіть інтонації — все це впливає на ефективність людей і їхнє бажання з нами працювати. Згідно з , стрес на робочому місці призводить до збільшення добровільного плину кадрів майже на 50%. Часто його причиною стають не умови праці чи складні завдання, а взаємодія з керівництвом.
В університеті, на курсах і тренінгах нам часто кажуть, що і як ми повинні робити на конкретній посаді, як діяти в тій чи іншій ситуації. Але рідко говорять, чого робити не варто з погляду людських взаємин.
Про це ми з колегами з jMind, компанії холдингу TECHIIA, говоримо в цій статті: чого не варто робити чи говорити своїй команді, якщо ви створюєте здорову атмосферу на робочому місці.
Ми працюємо на різних позиціях: CPO, Scrum-майстер, тімлід. Наші поради та історії доповнюють одна одну і будуть корисними для всіх керівників — від лідів до CTO і тих, хто планує вийти на ці позиції. Будемо раді вашому досвіду в коментарях.
Поради для Project Manager
Не кажіть людині, як виконувати її роботу
Будь-якого фахівця, включаючи розробника, наймають за його знання і навички. Ваша ключова задача — налагодити взаємодію між людьми з різними навичками і триматися на іншому рівні абстракції. Не вчіть кожного з них хард скілів, які в них, найімовірніше, прокачані краще, ніж у вас — інакше ви б працювали на їхньому місці. Передусім вам важливий робочий результат в обумовлені терміни.
Якщо ж ви знаєте якісь тонкі прийоми в написанні шматка коду чи більш вдалу бібліотеку і це може допомогти колезі, поділіться знаннями як рекомендаціями, але не вказівками. А ще краще — у форматі «що думаєш з приводу використання ось цього?»
Не поспішайте оцінювати трудомісткість завдання до того, як почуєте думку розробника
Навіть сам колега може недооцінити або переоцінити складність і потрібний час для завдання — а він точно глибше розуміє свої можливості. Жоден керівник не може знати всіх компетенцій своєї команди, особливо якщо вона крос-функціональна.
Тому навіть якщо здається, що ви краще знаєте, вислухайте думку тих, хто безпосередньо буде займатися завданням, і тільки потім виставляйте естимейти.
Не присвоюйте всі заслуги та не звинувачуйте в усіх бідах підлеглих
Позиція керівника вимагає якраз зворотного підходу. У разі успіху важливо підкреслювати, що це заслуга команди і всі доклали зусиль, щоб отримати гарний результат. Якщо щось пішло не так, беріть максимум відповідальності за це — так ви зрозумієте, як більш ефективно організувати процес у майбутньому.
Не карайте за помилки, особливо допущені вперше
У нас у JMind і в інших командах TECHIIA навіть склалося негласне правило: на перший промах у завданні не звертати уваги. Без помилок не буває експериментів, а без експериментів — великих досягнень. Ми радше похвалимо за сміливість і зробимо продуктивні висновки, ніж тикнемо пальцем в інструкцію.
Інша річ, коли співробітник помиляється систематично і не тому, що пробує нове. Але навіть у цьому випадку не поспішайте звинувачувати. Помилка співробітника тісно пов’язана з помилками менеджера. З’ясуйте, чи під силу конкретно цій людині саме це завдання, чи вдосталь необхідних ресурсів. Чи однаково ви з колегою розумієте тонкі моменти техзавдання, чи чітко воно сформульоване? Пам’ятайте: якщо ви щось не вказали в ТЗ — за будь-якого виконання завдання зроблене правильно.
У цьому ж пункті рекомендую не замовчувати більшу картину (helicopter view) і причини ухвалення тих чи інших рішень — навіть таких, які здаються незначними для виконання завдання. Подавайте приклад — аргументуйте свої рішення. Це допоможе мінімізувати помилки й налагодити відкритість у команді.
І ще не нагнітайте обстановку, не примножуйте негатив. Потрібно показати команді, що навіть із проблемної ситуації є вихід.
Поради для Scrum-майстра
На будь-якій посаді під час роботи з командою актуальні одні й ті самі теми: організація процесів, атмосфера на робочому місці, фідбек і те, як його варто подавати. Я керуюся принципами Scrum, але написане нижче — універсальне для будь-якої методології.
Не сваріть колегу при всіх
Сюди ж додам: якщо трапився інцидент, не шукайте винних. Спочатку вирішіть проблему. Розбори польотів з відповідальними краще робити, коли пожежу ліквідовано.
Залишайте негативний фідбек для розмови тет-а-тет. Навіть якщо емоції зашкалюють. Публічна прочуханка вбиває професійну творчість і поляризує команду: з’являються «жертви», «рятівники», «переслідувачі». Ви даєте іншим право на цькування, закладаєте фундамент для токсичності.
Зло особливого ґатунку — емоційний негативний фідбек хоч особисто, хоч у присутності команди. Якщо співробітник і сам усвідомлює свій промах, ваш підвищений тон тільки зажене його у більший стрес і завадить зробити здоровий фаховий висновок. А дискусій з вами колега уникатиме, адже знатиме, що ви можете легко перейти на особистості.
При цьому хвалити корисно на загальних зборах. Особливо тих, хто об’єктивно вклався у досягнення команди. Не лестіть, просто перерахуйте факти і щиро подякуйте за внесок. Так створюється здорова конкуренція — за умови, що у вас як у керівника достатній авторитет.
Не забувайте про людське
Розробник — не тільки робочі руки, а й особистість зі своїми інтересами, проблемами та обставинами. Вони можуть по-різному впливати на його продуктивність в конкретний момент. Іноді може бути корисно поцікавитися справами поза роботою, щоб перерозподілити навантаження, під’єднати HR компанії та вчасно підтримати людину.
Не варто мікроменеджити і «капати на голову» співробітнику
Гіперконтроль і гіпервтручання тягнуть за собою дві біди. Перша — ваш колега, найімовірніше, буде лише дратуватися від ваших постійних уточнень. Через це він віддасть сире рішення, аби ви швидше відчепилися. Ваші взаємини це теж навряд чи поліпшить.
А друга біда — постійно влізаючи в дрібниці, ви ризикуєте «з’їсти» у розробників відповідальність за якість роботи та потонете в рутині й операційці. Команда перестане сама пропонувати рішення, всі будуть діяти за вашими вказівками.
Не думайте, що мотиви вашої поведінки всім зрозумілі. Завжди аргументуйте свою позицію і рішення
Одного разу після чергового Backlog Refinement команда дружно сказала, що завдання зрозуміле і на розробку потрібно N сторіпоінтів. Тільки згодом з’ясувалося, що розуміння деяких термінів у Product Owner і команди відрізнялися. Завдання реалізували так, як зрозуміли, і це виявилося зовсім не те, що малося на увазі в умовах.
Бажано проговорювати кожну дрібницю. Ми можемо витратити кілька хвилин (на перший погляд, зайвих), але в результаті зекономимо дні чи навіть тижні.
Цю рекомендацію можу написати тільки без «не»: завжди пам’ятайте свої обіцянки!
Поради для тімліда
Не вішайте на співробітників ярлик супергероїв
Будьте готові прийти на допомогу будь-кому із них. Іноді навіть люди з досвідом стикаються зі складнощами, які здаються їм нерозв’язними або такими, що вимагають багато часу. У деяких ситуаціях синергія і взаємопідтримка позитивно впливають на результат роботи і окремих колег, і всієї команди.
Був такий випадок. Один із колег набагато довше, ніж зазвичай, працював над завданням, при цьому на питання «Чи все гаразд?» продовжував відповідати ствердно. Так тривало певний час, аж поки від нього не надійшло повідомлення в стилі «все пропало».
Довелося занурюватися в ситуацію. Трохи вивчивши проблему, я дійшов висновку, що не знаю рішення. Але здавалося, що воно дуже близько. Зідзвонилися, я намагався бути конструктивним, дізнався, які спроби й підходи вже застосовувалися. Ми запустили сесію парного програмування — і за короткий час знайшли рішення. Похвалив колегу і нас двох. А найголовніше — позбавив його тривоги за те, що він не встигає вчасно виконати завдання.
Не будьте занадто критичні. Але й не варто перехвалювати
Постійний конструктивний діалог дає чітке розуміння основних потреб і настрою співробітників.
Нещодавно один із колег запропонував у проєкт інновацію. На жаль, він не порадився і замість пропозиції прийшов до нас з конкретною реалізацією. Більшості членів команди вона здалася надмірною і несвоєчасною. Вони запропонували відкласти її застосування або спробувати знайти більш елегантне рішення.
Замість того щоб взяти за основу рішення команди й закріпити його, я вирішив підтримати колегу і спробувати мотивувати його на пошук кращого рішення. Але зробив неправильний вибір. Дискусія перетворилася на бурхливу суперечку, ми витратили набагато більше часу, ніж вимагала ситуація. Результат — трохи розчарований ініціатор і роздратовані колеги.
У спірних ситуаціях краще вдаватися до аргументованої думки команди. А пропозиції та поліпшення спочатку виносити на обговорення, обов’язково відзначивши ініціативу. І тільки після цього переходити до реалізації з урахуванням коментарів.
Не допускайте розвитку особистих та робочих конфліктів. Але й ігнорувати їх теж не варто
У суперечках народжуються гарні рішення, а в суперечках з переходом на особистості — бомби уповільненої дії, які можуть розірвати команду. Звертайте увагу на випадки, коли дискусія виходить за професійні кордони та втрачає конструктив. Проводьте ретроспективу суперечок і виробляйте чіткий механізм вирішення подібних проблем.
Як превентивний захід своєчасно збирайте, аналізуйте і передавайте фідбек від команди. При цьому важливо враховувати, що не всі готові особисто висловлювати думку про колег. Особливо в умовах роботи онлайн, коли людям складно вибудовувати відносини і прямо висловлювати думку про інших співробітників. Тут ваше завдання бути фасилітатором і створювати мости довіри.
А чим би ви доповнили наш список? Завдяки яким історіям у вас з’явилися власні «не»?
Статті та література за темою
- Jurgen Appelo —
- Patrick Lencioni —
- Ігор Манн —
- Деніел Пінк —
Оригінал статті на .
