Працюючи проджект менеджером вже більш як 5 років я часто згадую свої перші кроки в цій професії. Всі свої помилки і знання які здобувались болючими шишками. Інколи я думаю, було б добре, аби деякі поради мені дали на початку мого шляху, це б не призвело до певних неприємних подій. Але, знав би де впадеш - соломки підстелив би.
Та все ж, можливо комусь мій погляд, думки і висновки будуть корисними, тож почнемо з теми управління командою. Не рідко кожен ПМ нервує, бо девелопер знов не виконав якусь обіцянку, зірвав строки, став “вузьким місцем” розробки. ПМ починає всіляко бігати туди-сюди, забуваючи про інших, більш відповідальних членів команди. І, на початку, це здавалось нормою. Але, в команді майже ніколи не буде всіх “супер-пупер-відповідальних-сеньйорів”, треба вміти працювати і управляти (як би не приємно це не звучало) усіма типами працівників.
Типи працівників.
З мого досвіду в айті я виділила б 3 типи працівників (нижки кажуть, що різновидів більше і назви у них більш обґрунтовані, та моя практика каже саме про три основні категорії):
1. Task doer - тобто люди, які повноцінно виконують роботу по завданню, але самостійно щось запропонувати/продумати/закреативити або не здатні або принципово не бажають
2. Sabotager - люди, котрі по максимуму намагаються відтермінувати чи "скинути з себе" задачу, щоб нічого не робити. Наприклад, "саботують" задачу виконавши лише частину, аргументуючи "я не зрозумів, що робити". При цьому, звісно, не задаються додаткові питання.
3. Hard workers - ті, хто переймаються проектом/продуктом/іншими людьми, які намагаються щось додати, вдосконалити і віддають максимум себе завданню.
Як працювати з Task doer?
Мій план робіт з першим типом виглядає так:
1. Працюємо з чітко детермінованими задачами. Є люди, котрим важко/не хочеться/не можеться креативити, додумувати і т.д., але при цьому вони якісно виконують інструкції. Це ок і у проектах часто є велика потреба у таких членах команди. Навіть складну задачу можна довірити спокійно, якщо вона достатньо чітко розписана.
2. Налаштувати співпрацю QA/Developer до тестування. Якщо в задачі бракує чіткості, чи є нетривіальні моменти – можна попросити тестувальника надати тест-кейси по задачі чи хочаб чек-ліст, щоб розробник перевірив чи нічого не забуто і доробив те, чого не вистачатиме. Це допоможе зекономити час на тестування/зменшити кількість багів.
Як працювати з Sabotager?
Дехто скаже: "та нащо такі люди у команді, зразу здихатись та і по всьому", але інколи ситуації і причини бувають різні. Наприклад, проекти, де кожен ресурс на вагу золота і будь-яка поміч буде в нагоді. Тому з такими також треба вміти працювати. Що ж робити?
1. Вивести на діалог. Треба визначити причини такої поведінки. Можливо, у людини щось сталось і це тимчасове явище, чи демотивація як наслідок незадоволеності роботою. Наприклад: «Мені платять дуже мало, щоб я якісно робив роботу, буду виконувати стільки, скільки вважаю справедливим». Це пряма наводка до спілкування з керівництвом. Адже незадоволена людина, яка саботує проект не допоможе принести те, для чого компанії і створюються – очікуваний прибуток. Або ж інша ситуація: людина просто не розуміє процесів роботи на проекті чи "навіщо робити задачу". Колись у мене був випадок, коли розробник саботував задачу аргументуючи тим, що "це нікому не потрібно, це такая дурня і мізер, чому нам не дають толкових задач". Виявилось що простий діалог який підкреслює бізнес-ціль або бізнес-проблему вирішило питання за пів дня. Треба обо'вязково спробувати визначити причини у діалозі, і краще тет-а-тет. Далі індивідуально працюємо від отриманої інформації.
2. Встановити правила роботи (не відміняє першого пункту, а скоріше є підсилюючим чи планом б, якщо відвертий діалог не відбувся):
2.1 Закладати часові ризики. Скоріш за все правильне виконання, тобто отримання очікуваного результату, буде займати декілька ітерацій. Це також з досвіду співпрації з таким типом людей. Навіть якщо в запланований час задача виконувалась - кількість багів та пропущених кейсів майже завжди подвоювала час на отримання кінцевого результату. Час на ризики не універсальний параметр, ви маєте його визначити самостійно.
2.2. Встановлювати майлстоуни на задачу (де це можна застосувати). Тобто домовитись, що Задача А буде розділена на (умовно) 3 частини, і кожного дня девелопер має демонструвати по 1-й частині (чи то на дейлі мітингу чи то окремою активністю. Це обговорюється). На таких міні-демо прогресу зразу виявляються прогалини, які фіксуються і відправляються на допрацювання. Не завжди це можна застосувати, але часто можна. Ніколи не соромтесь просити девелопера продемонструвати прогрес. Це звучить "запарно", та повірте, насправді на такий детермінований контроль витрачається набагато меньше часу, ніж на перебранки і сподівання що хтось "схаменеться" чи "врятує". В логічному розділенні задачі на частинки (щоб не зламати логіку чи високі незримі матерії девелопменту) вам може допомогти архітектор, чи лід, чи просто більш досвідчений колега.
2.3. Якщо закрадаються сумніви з оцінки задачі, рекомендую використовувати second opinion або просити надати план роботи з обгрунтуванням оцінки (не працює з джунами). Second Opinion треба використовувати також з розумом, адже підходити до людини, яка оцінила задачу в 100 годин з фразою "а от Коля її оцінив на 50" це дуже погано. По-перше Коля виглядатиме погано. Особливо якщо Коля це член тої ж девелопмент команди. По-друге, яким би Коля молодцем не був, він має не просто сказати оцінку а дати якесь обгрунтування. Можливо Коля вже аналогічних 500 задач зробив і у нього просто вищі навички. Все це треба зважувати. Тому краще спочатку попросити надати обгрунтування початковій оцінці у вашого девелопера, а далі з цією розшифровкою кудись йти. В майбутньому, чим більше проектів у ПМ-а в скарбничці, тим вище шанс що сам ПМ зможе на основі свого досвіду розуміти де його дурять з естімейтами, а де ні. Але, інколи, якщо проект дозволяє, можна і дати себе надурити. Батіг-пряник. Але не в даному випадку.
Ось така схема працює для мене. Може здатись, що це займає купу часу і біганини, але встановлені правила дуже скорочують ці затрати. Дані правила і підходи дозволять девелопера «дотягти» в наш останній вагон дедлайну. Якщо, звісно, людина зовсім не виявляє бажання працювати і не йде до діалогу, то коли «гарячка» спаде,рекомендую переглянути ваші трудові відносини, "кобила здохла - злізь з неї".
Як працювати з Hard workers?
3 група. Це найперші люди, що вигорають. І зазвичай, це трапляється "в самий подходящій мамєнт". Вигорають з декількох причит. Це може бути через стресовий проект, чи через те, що взяли на себе забагато обов'язків, чи через невизнання. Ну зізйнайтесь, у кожного менеджера було таке: так, задача складна, віддам її Васі і цю і цю, на нього можна покластися і я буду спокійний(а) за проект, Вася машина робить по 10 задач, поки інші одну мусолять, він у мене молодець.
І Вася бере, і робить, і часто не признається, як ночами пихтить над тим компом. А менеджер нічого з цим не робить, бо сро(а)ки горять. От в один прекрасний день приходить на роботу Вася 2.0, який не те що "не прикриє могучим плечем обіцянки по проекту", а і просту задачу більше зробити не взмозі. І тут друга помилка менеджера: Вася, ну ти що, чого ти мене підводиш? І тут Вася 2.0 ризикує стати ще і токсиком.
Звичайно, це гіпотетичний варіант розвитку подій. Але тут я вбачаю обов'язкові дії, які треба зробити, щоб Вася міг продовжувати працювати і не втрачав іскру в очах. А саме:
1. Слідкувати, щоб працівник користувався щорічною відпусткою або отримував інші блага, які допоможуть компенсувати стрес і перенапруження (де це можна застосувати, не у всіх менеджерів є можливість і ресурс для видачі благ)
2. Розподіл навантаження. Навіть якщо проект складний, замовник в двадцятий раз прислав правки, а дедлайн стає лише ближче - це не привід все звалювати на одну людину. Хоча часто менеджер просто стає комуністом і пропагує "Від кожного — за здібностями, кожному — за потребами". Але це не буде працювати вічно. Увага в такій ситуації потрібна загалом команді, проекту. Якщо вже не вистачило важілю для врегулювання ситуації на рівні менеджер-замовник, то треба закономірно розподілити задачі. Коли так трапляється не треба панікувати. Беремо паузу, знаходимо чи вибираємо з наявних технічного консультанта/ліда/архітектора і переглядаємо пул задач. Розділяємо їх, плануємо, презентуємо команді, закріплюємо домовленості, назначаємо логічну кількість чек-пойнтів, не більше 1 в день і спокійно запускаємо наш девелопмент процес знову. Паніка принесе хаос в життя проекту і часто лише погіршить стан "надіїї всього проекту - ака Васі".
3. Ненав'язливий моніторинг і особистий діалог. Це працюватиме, якщо ви вибудували довірливі відносини з членом команди. І по певним показникам ви зможете помітити перші прояви вигорання і допомогти запобігти сумним наслідкам.
4. Де виникає та сама "м'ясорубка" з дедлайном і кількістю задач, а ви з якої б то не були причини не можете розподілити задачі на інших людей - можна "Васю" розвантажити. Наприклад, даємо можливість ігнорувати якісь мітинги, чи робимо послаблення у таймирекінгу чи інший бюрократії. Це тимчасова пілюля, але інколи може спрацювати.
5. Прийняти, що універсальних ліків не існує. Для кожного "Васі" потрібен буде свій підхід і свій "рецепт".
Висновки
Правильно вибудована стратегія і план дій з кожним членом вашої команди - це прямий шлях до легкого в управлінні й успішного проекту. Хоч кожна ситуація і унікальна, та хоч одна порада, та думаю вам підійде.
Мабуть, аби я була джуном-джуном я би пропустила ці поради і статтю повз себе, але зараз, керуючись цією схемою я економлю собі дуже багато нервів і часу, які можу присвячувати іншим справам та обов’язкам.
Буду рада, якщо комусь це стане корисним.
