Як менеджеру справлятися зі страхом і невпевненістю

Стаття написана у співавторстві з Мері Ротарь , Co-Founder IAMPM

Всім привіт!

Я свитчер («Здрастуй, світчер», як кажуть в клубах анонімних алкоголіків/дармоїдів/наркоманів — потрібне підкреслити). Перейшов в IT ще коли це не було мейнстрімом. У 2003 році закінчив географічний факультет Київського національного університету, там же в 2008-му — аспірантуру. Прийшов в IT 2004 року на посаду редактора сайту, маючи за плечима три роки журналістики в різних друкованих і електронних виданнях. Вибирав шлях або в ІТ, або в журналістику, але рекрутер в IT-компанії була дуже красивою жінкою :) За минулі з тих пір 15 років пройшов шлях до директора департаменту і керівника проектного офісу. Сертифікований менеджер проектів PMP і IPMA.

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

Для початку кілька постулатів від Капітана Очевидність, в деякому роді це словник термінів для цієї статті.

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

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

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

Самоорганізована команда — команда, здатна пропонувати і, при необхідності, приймати рішення з персональною відповідальністю за їх результати. У разі помилкового рішення в такій команді ніхто пафосно не надуває щоки: «У нас agile, тому ми відповідаємо за обране рішення всією командою». Це з серії позерства школярів на великій перерві, коли м'ячем розбили вікно.

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

Проект. Визначень проекту досить багато, ми не будемо відбирати роботу у Гугла ;) Зазначимо тільки, що в нашій історії це не просто створення замовленого ПЗ, а сукупність робіт з комплексного розв'язання задачі клієнта.

А тепер давайте заглянемо в голову менеджеру, самі її потаємні і темні кути.

Більше спілкуйтеся з командою і клієнтами

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

В роботі прожект-менеджера важливо регулярно розмовляти. З командою, з замовником, з неприємними людьми з відділу забезпечення і приємними дівчатами з HR. Один з найважливіших навичок спілкування — запитання. І не тільки стандартний «коли ми нарешті зарелизим?».

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

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

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

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

Плануйте роботу на випадок авралу

З-за проблем з комунікацією можуть зриватися дедлайни. Про яких ви могли навіть не знати, так як не запитали, ага. Подібна ситуація одного разу сталася у мене на B2G-проекті (business-to-government).

О пів на дев'яту вечора шеф департаменту, з якими ми співпрацювали, раптом згадав, що завтра в їх системі повинен з'явитися замовлений міністерством функціонал. Вони-то знали про це, але забули сказати. Розробка зайняла б півтора-два місяці. Ми вийшли із ситуації своєрідно: підготували презентацію Power Point і показали, як система запрацює після тестування. Не заробила, до речі. Але це вже інша історія.

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

Одного разу Я проявив чудеса перепланування і підписав додаткову угоду з фінальною датою 24 серпня. А так як це День Незалежності, тобто вихідний, я отримав ще один день для овертаймів, якщо ми знову все важливе пропустимо.

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

Вчіться новим у колег

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

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

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

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

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

Аргументуйте жорсткі рішення

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

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

Сніговий ком корпоративного обурення обрушив на тест-менеджера всю свою силу. Наш же герой з незворушністю Шерлока Холмса пояснив в доступній для менеджменту формі можливі наслідки для компанії та замовника. Він знайшов у собі сили прийняти жорстке рішення, аргументував його і відстояв свою позицію. Керівництво пояснило клієнту всі нюанси, і проект успішно запустили через два тижні. Осад, звичайно, залишився, але це вже інша історія.

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

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

Будьте щирим з командою

Проектна команда частіше обговорює сторонні теми, перекури та обіди затягуються, і колеги все рідше звуть вас з собою? Ймовірно, колектив більше не довіряє керівнику і назріває бунт. «Вони заряджають гармату. Навіщо? А, вони будуть стріляти!»

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

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

Потрібен звіт? Просто дайте його

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

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

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

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

І що ж я зробив? Звичайно, впевнено відклав дзвінок: «Проведу-ка з хлопцями планірку і подзвоню...», Після чого раптово настав час обіду. «Ну що ж, пообедаю, замовник пообедает, всі будуть добрі — тоді і поспілкуємось». Вечоріло...

Коли шеф в черговий раз запитав, чи говорив я з клієнтом, я промимрив: «Ні». І він дав мені пораду: «Завжди спершу „з'їсти жабу“ — зроби те, що неприємно, але необхідно, звільни голову». Наступного ранку я все-таки повідомив замовника про проблеми та можливі способи її вирішення. Звичайно, почув, що «я ваша компанія труба шатал», але в кінці замовник все ж подякував, що про погане його попередили заздалегідь.

Не збирайте страхи — розвантажите голову

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

Але є в цьому і позитивний момент. Як у оптимістів, які навіть на кладовищі бачить не хрести, а плюсики. Емоційне вигорання — це экономрежим організму. Фізичні прояви (головний біль, сонливість, простудні захворювання) сигналізують, що пора відпочити. Зробіть перерву та оцініть роботу з боку. Можливо, якийсь із страхів ви давно подолали. Наприклад, страх читання лонгридов ;)

Замість висновку

Страхів і тривог у прожект-менеджера багато. Є обґрунтовані і немає, суб'єктивні та об'єктивні. З деякими можна впоратися самостійно, інші потребують допомоги. Разом з тим страх є і стимулом: люди боялися літати, але брати Райт подолали цей страх, і тепер ми боїмося не літаків, а того, що попадеться середнє місце з храпящими сусідами по обидві сторони. Подолання страху — це можливість отримати нові навички та знання. Далі звичайно треба мотивуюча фраза в стилі Тоні Роббінса. Ось вона: виберіть хоча б один страх і почніть отримувати задоволення від його подолання:

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

Keep calm and wash your hands ;)

Опубліковано: 30/03/20 @ 10:00
Розділ Різне

SEO Блог