«Якомога більше контролюйте та відволікайте»: 5 шкідливих порад для проджект-менеджера

Мене звуть Олександра Стеценко і я обіймаю посаду операційного директора Wezom Академії. За родом діяльності мені доводиться постійно взаємодіяти з розробниками практично на всіх рівнях. Зокрема саме зараз я маю тісну співпрацю з девелоперами, що працюють над модернізацією «Особистого кабінета» наших студентів.

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

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

Власний досвід: про менеджерів і їхню взаємодію зі всією командою

Для початку дуже коротко розповім власну історію.

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

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

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

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

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

Важливий нюанс у розумінні роботи проджект-менеджера

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

Ні, ні і ще раз ні!

Хороший проджект робить все можливе, щоб його команда працювала якнайкраще.

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

Тому такий спеціаліст — це в першу чергу надійна та відповідальна ланка робочого процесу, але аж ніяк не «злий контролер». 

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

Робота з девелоперами: поширені помилки та як їх не припуститися

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

В чому причина?

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

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

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

Результат — непорозуміння в команді, конфліктні ситуації, розчарування і у більшості випадків… втрачений потенціал розробника.

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

Головний секрет успішно побудованого процесу роботи між менеджером і розробником — це грамотно налаштована комунікація і щире бажання проджекта зрозуміти девелопера. Як цього досягти? Як мінімум — не допускати поширених помилок, про які я розповім далі.

Шкідливі поради

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

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

1Якомога частіше відволікайте розробника по справі і без, контролюйте його

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

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

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

2Не переймайтесь щодо підготовки якісного ТЗ. Досвідчений розробник самостійно зорієнтується

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

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

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

3Не вносьте всі правки одразу. Розбийте їх на частини і опрацьовуйте кожну окремо

Коли проджект-менеджер навіть не може зібрати всі правки та коментарі в єдиний список, то він апріорі сумнівний спеціаліст.

Якщо у вас будуть правки по проєкту (а вони дійсно можуть бути):

• зберіть їх всі;
• дайте пояснення;
• перевірте список і структуруйте його.

І тільки після цього передавайте розробнику.

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

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

4Не враховуйте побажання девелопера з дедлайну та його ідеї поза межами задачі

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

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

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

5Не потрібно хвалити підлеглих — це їхня робота. І не забувайте «підсипати» термінові задачі

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

Такий мотиватор часто працює набагато краще, ніж грошова премія в кінці місяця.

Стосовно термінових задач важливо розуміти наступне. Коли у вас постійно зʼявляються задачі «на вчора» — це вже питання до вас як проджект-менеджера. Ваше завдання — планувати робочий процес таким чином, щоб подібного взагалі не було, або ж було якомога менше. Форс-мажорні обставини трапляються, але вони не повинні стати для вас та ваших підлеглих нормою.

Замість підсумків

Важлива характерна риса ефективної взаємодії проджект-менеджера з розробником — це стабільність. Якщо ця стабільність зникає, значить ви щось робите не так.

Наприклад:

• Спеціаліст довго відповідає на ваші повідомлення, хоча раніше відповідав одразу.
• Девелопер просить звернутися до когось іншого з цією задачею, бо не може (або не хоче) її робити.
• Розробник просто змінив своє відношення до вас, став непривітним та, грубо кажучи, «холодним».

Якщо спостерігаєте щось подібне, є вірогідність, що робочі стосунки вже зіпсовано. Але навіть це ще аж ніяк не критична ситуація. Її можна виправити. І я обовʼязково розповім про це у наступній публікації на Highload.

Зараз же хочу підсумувати все вищесказане і підкреслити, що головні задачі будь-якого сучасного проджект-менеджера — це:

1. Слухати і чути. Не сперечатися, а знаходити компроміс у складних ситуаціях.
2. Не перенавантажувати розробника, а допомагати знайти баланс між роботою та вільним часом.
3. Чітко пояснювати кожне завдання, та в той же час залишати простір для нових ідей та шляхів вирішення задач.
4. Навчитись розуміти особисті проблеми співробітника і за необхідності давати паузу для перезавантаження та відпочинку.

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

Але ви, звісно ж, можете не погодитися з деякими моїми думками та ствердженнями. Тому запрошую своїх колег проджект-менеджерів до обговорення теми в коментарях. Як ви взаємодієте з девелоперами і розкриваєте їх істинний потенціал? Давайте поговоримо!