nmk

Лекція №8 (4 години). Командоутворення, лідерство та психологія в IT-проєктах

План лекції

Ролі та відповідальність у проєктній команді. Soft skills vs Hard skills.
Етапи розвитку команди за моделлю Брюса Такмана.
Мотивація IT-фахівців (Маслоу, Герцберг, Пінк). Чому гроші не завжди мотивують розробників.
Управління конфліктами та матриця Томаса-Кілманна (Стратегії вирішення).
Специфіка роботи з віддаленими (розподіленими) командами.
Емоційний інтелект (EQ) PM-а та стилі лідерства. Техніка ефективного делегування.
Професійне вигорання (Burnout): симптоми, причини та профілактика.

Перелік умовних скорочень

EQ (Emotional Quotient / Intelligence) — емоційний інтелект;
Soft Skills — “м’які” (соціальні) навички;
Hard Skills — “жорсткі” (технічні) навички;
Burnout — синдром професійного вигорання;
Micromanagement — мікроменеджмент (надмірний контроль).

Вступ

Згідно з опитуваннями менеджерів в IT, понад 70% їхніх проблем у проєкті — це проблеми не з кодом, не з технологіями, а з людьми. Програмісти вигорають, сваряться через вибір фреймворку, саботують роботу “поганого” менеджера або просто звільняються, отримавши кращий офер (пропозицію роботи).

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

1. Ролі у команді. Soft skills vs Hard skills

В IT-команді кожен має свою експертизу. Ідеальна команда є крос-функціональною.

Базові ролі:

Product Owner / Business Analyst: “ЩО ми маємо зробити?” (Вимоги).
Tech Lead / Architect: “ЯК ми це реалізуємо технічно?” (Архітектура).
Software Engineers (Розробники): Пишуть код.
QA Engineers: Гарантують якість.
UI/UX Designers: Відповідають за інтерфейс та досвід користувача.
DevOps: Налаштовують інфраструктуру (сервери, бази даних).
Project Manager / Scrum Master: Знімає перешкоди, організовує процес, забезпечує комунікацію.

Soft Skills (Навички спілкування) та Hard Skills (Технічні навички): Історично вважалося, що ідеальним PM-ом має бути найкращий (найбільш технічний) програміст. Сьогодні цей підхід переглянуто. Занадто технічний менеджер схильний до мікроменеджменту (вказувати як писати код, замість того щоб делегувати це команді). Найкращі менеджери володіють глибокими Soft Skills: вмінням слухати, вирішувати конфлікти, емпатією та навичками ведення переговорів. Сучасний PM має розуміти технічні концепції (щоб не здаватись клієнту безграмотним), але йому не обов’язково вміти писати код 10 мовами.

2. Етапи розвитку команди (Модель Брюса Такмана)

Якщо ви зберете 5 найкращих у світі Senior-розробників в одну кімнату, вони не стануть “Командою” в той же день. Вони будуть просто групою зірок-одинаків. Брюс Такман (1965 р.) описав п’ять обов’язкових стадій, через які проходить БУДЬ-ЯКА команда:

Forming (Формування):
- Знайомство. Усі ввічливі, розгублені. Рівень продуктивності низький.
- Дії PM: Встановити чіткі правила (Ground Rules), познайомити людей, поставити цілі (“Ми зібралися тут, щоб…”).
Storming (Шторм / Конфлікт):
- Медовий місяць закінчується. Починається боротьба за авторитет (хто тут головний архітектор?). Виникають конфлікти (один програміст вказує іншому на поганий код). Продуктивність падає до мінімуму.
- Дії PM: Не уникати конфліктів! Це нормальна стадія. Треба допомогти команді конструктивно виробити свої внутрішні домовленості.
Norming (Нормування):
- Конфлікти вирішено. Люди звикли один до одного. Розподілилися неформальні ролі. Кожен знає, що до тестувальника Олега краще не підходити до кави, а дизайнерка Олена найкраще робить графіку. Продуктивність стабільно зростає.
Performing (Продуктивна робота):
- Високоефективна фаза. Команда сама розв’язує проблеми, легко домовляється і генерує геніальні рішення.
- Дії PM: Відійти в сторону. Застосовувати делегування. Займатися стратегією, а не мікроменеджментом.
Adjourning (Розставання):
- Проєкт закінчено. Команду розформовують на нові проєкти. Важливо провести прощальну вечірку та ретроспективу, щоб закрити гештальт.

Важливо: Якщо на стадії Performing з команди йде ключовий учасник і приходить новачок — команда миттєво падає назад на стадію Forming/Storming.

3. Мотивація IT-фахівців

Як змусити Senior-програміста, який заробляє $5000 і може знайти іншу роботу за день, залишитися працювати понаднормово, коли проєкт “горить”?

Класичні теорії мотивації (і чому вони дають збої в IT):

Дуайт Мак-Грегор (Теорія X та Y): Теорія X каже, що ліниві люди працюють тільки під “батогом” (штрафи, жорсткий контроль). Це вбиває ініціативу в IT. Теорія Y (на якій базується Agile) вважає, що розробники творчі і мотивовані зсередини, потрібні лише гарні умови.
Гігієнічні фактори Ф. Герцберга: Він стверджував, що існують фактори-мотиватори (визнання, кар’єра) та “гігієнічні” фактори (комфортний стілець, безкоштовні обіди, зарплата). Суть: Збільшення зарплати НЕ мотивує працювати краще в довгостроковій перспективі. Якщо не платити гарну зарплату, розробник буде ображений і піде, але підвищення зарплати на 10% зробить його щасливим лише на 2 тижні.

Теорія мотивації Деніела Пінка (Мотивація 3.0): Для інтелектуальних (когнітивних) професій, де немає конвеєра, найкраще працюють три фактори:

Autonomy (Автономність): Програмісти ненавидять мікроменеджмент. Скажіть їм що треба зробити (ціль), але дозвольте їм самим вирішувати як (який стек, який дизайн) це робити.
Mastery (Майстерність): Можливість розвиватися. Якщо розробник з року в рік робить однотипні нудні сайти на старих технологіях, він піде туди, де складніші задачі і новий модний фреймворк.
Purpose (Цілеспрямованість/Сенс): Програмісти хочуть знати, що їхній код допомагає людям або змінює світ. Задачі формату “Просто перефарбуй кнопку, мені так керівник сказав” вбивають мотивацію. Пояснюйте бізнес-цінність!

4. Управління конфліктами (Матриця Томаса-Кілманна)

Конфлікт в IT — це не завжди скандали. Це зіткнення інтересів. Наприклад, програміст хоче написати ідеальний, естетичний код за 5 днів. Менеджер хоче здати фічу клієнту вже завтра, хай і “костилями”. Цей конфлікт — корисний, він не дає проєкту зайняти крайнощі.

Стратегії розв’язання конфліктів за Кілманном (базується на співвідношенні Співпраця vs Наполегливість):

Ухиляння (Avoiding): (Низька співпраця / Низька наполегливість). Ігнорування проблеми. Менеджер просто відтягує час і уникає важкої розмови. (Зазвичай погана стратегія, але корисна, якщо емоції на межі, і треба дати людям охолонути).
Конкуренція / Примус (Forcing/Directing): (Низька співпраця / Висока наполегливість). PM стукає кулаком по столу і каже: “Я тут керівник, робимо по-моєму”. Можна використовувати лише в кризових умовах (пожежа, сервер лежить), інакше команда вас зненавидить.
Пристосування (Accommodating): (Висока співпраця / Низька наполегливість). Ви поступаєтеся іншій стороні заради збереження хороших стосунків. “Добре, бери для нашого сервера цей фреймворк, хай буде”.
Компроміс (Compromising): Обидві сторони чимось жертвують. (Ситуація Lose-Lose - обидва не задоволені до кінця, але рішення прийняте швидко).
Співробітництво (Collaborating): (Висока співпраця / Висока наполегливість). Ситуація Win-Win. Сторони довго і аргументовано сперечаються (наприклад, малюють архітектуру на дошці), поки не винайдуть третій шлях, який повністю задовольнить обох. Це ідеальна, але найбільш часовитратна стратегія.

5. Специфіка роботи з віддаленими (Remote) командами

В IT робота з дому стала галузевим стандартом. Але віддалена команда приносить нові виклики для PM:

Зниження довіри: Людей, які не п’ють разом каву на кухні, важче згуртувати (складніше пройти стадію Storming).
Асинхронна комунікація (Різні часові пояси): Зазвичай перетинається лише кілька ефективних годин на добу (наприклад, між Києвом і Сан-Франциско).
“Незрима” робота: Менеджер не бачить, коли люди працюють, тому фокус зміщується з оцінки часу (хто сидить до 18:00) на оцінку РЕЗУЛЬТАТУ (чи була виконана фіча з Jira).

Правила гігієни Remote-проєктів:

Увімкнені камери на дзвінках (щоб бачити міміку, це +50% до EQ).
Daily Standups (щоденні 15-хвилинні дзвінки) — єдиний “пульс” команди.
Усе має бути задокументовано (Confluence). Те, що сказано усно без запису, не існує.

6. Емоційний інтелект (EQ) та Лідери

Справжній керівник проєкту (на відміну від “погонича рабів”) спирається не на посадову інструкцію, а на вплив. Це забезпечується Емоційним інтелектом (EQ).

Складові EQ менеджера:

Самосвідомість: Розуміти свої емоції (Я зараз злюсь, мені краще помовчати 5 хвилин).
Самоконтроль: Здатність не кричати і не панікувати, коли клієнт погрожує розірвати контракт. Команда завжди дивиться на обличчя PM-а. Якщо панікує він - панікує вся розробка.
Емпатія: Вміння “прочитати” колегу. Розуміти, що програміст мовчить на мітингу не тому, що він лінивий, а тому, що в нього проблеми в сім’ї і йому потрібен day-off.

Делегування

Найчастіша проблема молодих PM-ів (особливо з колишніх програмістів) — Мікроменеджмент (“Ніхто не зробить краще за мене, тому я сам перепишу його код”). Ефективне делегування передбачає передачу відповідальності ЗА РЕЗУЛЬТАТ, а не за кожну ДІЮ. У розробників це розвиває навички, а PM-у вивільняє час на стратегію та роботу з клієнтом.

7. Професійне вигорання (Burnout) розробників

Синдром емоційного та розумового виснаження — “хвороба 21 століття” в IT-секторі.

Симптоми вигорання програміста:

Цинізм і сарказм (різка критика будь-яких ідей, “все одно ми всі звільнимось”).
Прокрастинація та порушення дедлайнів (людина, яка раніше робила все за день, тепер дивиться в стіну).
Кількість помилок (багів) у коді кардинально зростає.
Соціальна ізоляція (перестає спілкуватися на мітингах).

Причини вигорання:

Постійні перепрацювання (Кранчі / Overtime) на вихідних.
Дефіцит сну та відсутність хобі.
Робота над “Legacy” (страшним, старим кодом, який ніхто не хоче чіпати), або робота без видимого фінального результату.
Токсично-директивний стиль управління або мікроменеджмент зі сторони техліда.

Профілактика (Відповідальність PM):

1-на-1 зустрічі (One-on-Ones): PM повинен щомісяця говорити з кожним розробником тет-а-тет ПРО ЖИТТЯ, а не про код. Запитувати “Як ти почуваєшся?”, “Куди хочеш рости?”, “Чи не думав взяти відпустку?”.
Жорсткий поділ work/life balance: Не писати в робочі чати о 22:00 в суботу (навіть якщо ви самі трудоголік).
Ротація задач: Якщо Senior пів року робить тільки сумний рефакторинг бази даних, дайте йому спробувати зробити щось креативне, новий Proof-of-Concept, навіть якщо це економічно не дуже вигідно компанії на цей момент.

Висновки

Сучасний Project Manager — це не наглядач з палицею, а фасилітатор, який розблоковує потенціал команди (Servant Leadership). Soft-skills домінують над Hard-skills.
Кожна команда (від групи студентів до топ-менеджменту) проходить обов’язкові стадії за Такманом. Менеджер не повинен боятися стадії Storming (шторму), а допомагати команді виробити норми.
Програмісти належать до когнітивних професій. Окрім базової гідної зарплати (Гігієнічний фактор), їхніми основними мотиваторами є Автономія (довіра), Майстерність та Розуміння бізнес-сенсу їхньої задачі.
Конфлікти невідворотні та корисні, якщо ними керувати. Ідеальна стратегія “Співробітництва” (Колаборації) даєWin-Win результат.
Для управління віддаленими командами необхідно більше зусиль інвестувати в прозорість, документацію (Confluence) та відео-комунікацію через втрату неформального спілкування.
Професійне вигорання (Burnout) розробників призводить до падіння якості коду і масових звільнень. Першочергове завдання PM — підтримувати work/life баланс команди через регулярні One-to-One зустрічі.

Джерела

Такман, Б. В. Модель стадій групового розвитку.
Пінк Деніел. Драйв. Що насправді нас мотивує (Drive: The Surprising Truth About What Motivates Us).
Том Демарко, Тімоті Лістер. Peopleware. Людський фактор у програмуванні (Класична книга про психологію розробників та роботу в IT).
Гоулман Д. Емоційний інтелект лідера.

Запитання для самоперевірки

Чому на стадіях “Forming” (Формування) та “Storming” (Конфлікту) за моделлю Такмана продуктивність команди зазвичай найнижча?
Наведіть приклад “гігієнічних факторів” (за Герцбергом) у сучасному IT-офісі і поясніть, чому їх наявність не змушує працювати інтенсивніше.
У чому небезпека мікроменеджменту (діагноз “я зроблю все сам”) для мотивації команди розробників (скористайтеся концепцією Деніела Пінка про “Автономність”)?
Спробуйте застосувати 5 стратегій Кілманна на вирішення такої ситуації: Дизайнер намалював красиві анімації (які займають пам’ять), а Backend-розробник вимагає їх прибрати, бо сайт буде завантажуватись 10 секунд. Опишіть “Win-Win” вихід.
Як неформальне спілкування на офісній кухні впливає на швидкість вирішення робочих завдань, і як PM може компенсувати відсутність такої кухні під час дистанційної (Remote) роботи?
Ви — PM у команді. Під час ранкового мітингу (Daily Standup) один із наймоторніших Senior-програмістів відповідає цинічно: “Я вчора закрив ваш тікет. Сьогодні продовжу тупо правити чужий старий код. Взагалі немає різниці, ми цю програму ніколи не здамо”. Які симптоми ви тут бачите і який ваш наступний крок як керівника?