Десять порад проєктному менеджеру-початківцю
Усім привіт! Мене звати Орест і останні дев’ять років я займаюсь управлінням та менеджментом в різних ролях: я був скрам-мастером і допомагав робити еджайл-трансформації, керував маленькими та великим проєктами і програмами (від трьох до 85 людей), будував проєктні офіси і розвивав компетенції ПМ в Eleks та Abto Software.
Також я люблю ділитись своїм досвідом, тому я вже досить давно веду свій блог про менеджмент та лідерство, запустив YouTube канал Kaizen Hub та подкаст «Майже Вчасно», багато викладаю, виступаю на конференціях та сприяю розвитку професійності ПМ в Україні.
Не буду брехати, що всі мої проєкти були успішними — було і багато фейлів та набитих шишок. Саме тому я і вирішив написати цю статтю 🙂
Не сприймайте написане як детальний гайд, який вирішить усі ваші проблеми (якби такий був, то ПМ були б не потрібні 🙂) - тут я просто хочу поділитись своїм досвідом і рефлексіями, які мені було б корисно почути на початку свого шляху в менеджменті.
Комунікація — це все
Як би це банально не звучало, але 99,99% всіх проблем можна вирішити словами через рот. Project Management Institute заявляє, що 90% часу керівник проєкту витрачає на комунікацію, і я думаю, що це не перебільшення.
У мене були випадки, коли за допомогою ефективної комунікації нам вдавалось витягнути проєкт з дна в моменти, коли замовник погрожував судами, або ж коли ми фейлили легкі проєкти через комунікацію.
Колись давно я прийшов на проєкт, де замовник ставився до нашої команди як до рабів людей нижчого сорту і не втомлювався про це нагадувати щодня. Фрази типу «ви тут працюєте тільки тому, що в мене є гроші і я добра людина» звучали на кожному дейліку і... вау, сюрприз — команда була максимально демотивованою!
Я лише прийшов у команду і перший час просто спостерігав і був в шоці від ситуації, але вона дуже скоро досягла апогею — на одній з командних зустрічей замовник безпідставно наїхав на одного з розробників і почав його принижувати в своєму стилі.
Я відразу ж зупинив цей потік нецензурних слів і сказав, що ми завершуємо мітинг і потім повернемось до обговорення.
Замовник миттєво подзвонив мені особисто в скайп і почав кричати — я дав йому виговоритись, а потім аргументовано пояснив, чому така поведінка не ок і як вона демотивує команду. Аргументи, що ми теж люди і до нас треба ставитись по-людськи не спрацювали б, тому я намагався говорити цифрами і пояснити, як він може заробити більше грошей, якщо ми будемо сфокусовані на роботі і ще й до того вмотивовані.
Я банально порахував, скільки в місяць йому коштує щоденний мітинг зі всією командою на одну годину замість 15 хвилин, і це спрацювало — замовник попросив передати свої вибачення розробнику і сказав, що більше так не буде.
Я сказав, що це ситуацію не вирішить, і якщо він його публічно образив, то повинен і публічно вибачитись — замовник взяв паузу, але наступного дня це зробив. Це дуже добре вплинуло на настрій команди, і вони побачили, що не все так безнадійно.
Розберіться, яка мета та цілі проєкту
Перед початком роботи над проєктом розберіться, яка саме мета має бути досягнута. Насправді не завжди все лінійно і в кожного проєкту будуть різні критерії успіху — десь це фінансові показники, десь це довготривалі стосунки із замовником, а десь це набуття експертизи.
Розуміння цілей та їхня пріоритезація допоможе вам визначити ключові результати, які необхідно досягти, і визначити критерії успіху для проєкту. Розгляньте, як цей проєкт вписується в стратегію організації та визначає його важливість.
Зробіть планування пріоритетом
Вміння розробляти чіткий та реалістичний план — ключ до успішного управління проєктами, тому часом на планування не варто нехтувати. І не забувайте, що потім цей план ще потрібно виконати 🙂
Якщо коротко, основна задача ПМ на етапі планування — організувати все таким чином, щоб команда змогла максимально продуктивно працювати відразу після старту проєкту. Короткий чекліст з планування виглядає так:
- Розробка плану управління проєктом — це основний документ, який міститиме всю необхідну інформацію з того, як ви будете працювати.
- Визначити SDLC та обрати методологію ведення проєкту (пам’ятаємо, що вона буде залежати від вашого контексту, а не тому, що ви хочете спробувати скрам чи вам так сказали!).
- Збираємо вимоги, описуємо їх, структуруємо та робимо декомпозицію й узгоджуємо із замовником.
- Формуємо графік проєкту на основі зібраної інформації.
- Тоді ж працюємо з формуванням команди та підбираємо максимально оптимальний склад.
- На основі попередніх пунктів формуємо бюджет проєкту, який залежить від типу контракту, який ми обрали.
- Фіналізуємо процес зі взаємодії та комунікації розробленим комунікаційним планом.
Методології не зроблять вашу роботу
Так, вам треба знати, які є концепції проєктного управління, але життя — це не книжка, і тут ви повинні розуміти, як саме їх адаптувати під вашу ситуацію.
Завжди знайдуться люди, які вам скажуть, що Scrum, Kanban, Waterfall (підставте ваш варіант) не працює. Як і ті, хто з піною навколо рота доводитимуть протилежне 😐
Запам’ятайте — жодна методологія не є панацеєю. Це лише набір практик та інструментів, які потрібно використовувати з розумом.
Для прикладу, що менше ви знаєте про проєкт, то зрозуміліше, що Waterfall сюди не підійде. Waterfall методологію варто використовувати в проєктах з максимально чіткими і пропрацьованими вимогами, в зрозумілому для вас середовищі і якщо у вас немає великої кількості ризиків.
Загалом, ось декілька змінних, на які варто зважати під час вибору методології:
- Вимоги. Зберіть максимум інформації про цілі проєкту, що і як вам потрібно зробити і які обмеження у вас будуть.
- Ризики. Що більше у вас невідомості, то зрозуміліше, що варто рухатись короткими ітераціями, а не намагатись спланувати весь проєкт наперед.
- Тип проєкту та контракту. Якщо це проєкт з фіксованим бюджетом, то тут з Agile дуже не розгуляєтесь. Тому вам потрібно максимально детально пропрацювати перші два пункти і визначити скоуп робіт на цей бюджет.
- Складність проєкту, зрозумілість технологій. Навіть якщо у вас детально пропрацьований скоуп і ви знаєте, що робити, то цього може бути недостатньо для успіху. На своєму досвіді маю провалений проєкт, бо замовник хотів його робити на новій на той час технології, яка ще була нестабільною і постійно мінялась — хоч ми і знали скоуп і розуміли, що робити, але постійні зміни в самій технології від її розробників призвели до частих переробок і зсуву графіку проєкту на доволі значний термін.
Не бійтесь конфліктів!
Середній час, який працівники витрачають щотижня на вирішення конфліктів на робочому місці, становить дві години. У США цей час зростає до 2 год 50 хв на тиждень. Тобто це 5% робочого часу. Менеджери ж витрачають близько шести годин на тиждень (приблизно 15% свого часу) на вирішення робочих конфліктів.
Конфліктів не треба боятись, треба боятись відсутності конфліктів! Я вважаю, що набагато гірше, коли ваша команда мовчить, не спілкується, і є багато мовчазних незгод замість відкритих конфліктів. А от вже навичка хорошого керівника — виявляти та вирішувати конфлікти вчасно та конструктивно, сприяючи побудові співпраці та забезпечуючи позитивне співвідношення між сторонами.
Більше про різні види конфліктів та як з ними працювати ми обговорювали в нашому подкасті, рекомендую, якщо хочете заглибитись в тему.
Працюйте з ризиками
Робота з ризиками — те, чого вам не уникнути в будь-якому проєкті. Ризики бувають різних форм та складності, але вирішення питань пов’язаних з ними є ключовою навичкою хорошого керівника будь-якій організації.
Зробіть процес ідентифікації ризиків пріоритетом для вашої команди, і ви точно будете на декілька кроків попереду. Що більше людей будуть залучені до ідентифікації потенційних загроз, то менше неочікуваностей буде для вас.
Далі ж потрібно розробити план управління ризиками та створити стратегії запобігання їм. Також будьте готові впоратися з непередбаченими ситуаціями та вмійте вбачати можливості там, де інші бачать лише загрози. Про свої фейли в роботі з ризиками я вже також розповідав на DOU, посилання тут.
Помилки — це не страшно
Багато керівників бояться визнавати свої помилки, бо вони переконані, що це буде відображенням їхньої неефективності. Проте, насправді, помилки — це не тільки природна частина розвитку, але і важливе джерело навчання.
Чудовим прикладом навчання на своїх помилках є Вінстон Черчилль і його Дарданельська операція: під час Першої Світової Війни він ініціював воєнно-морську операцію для деблокування Дарданелл і відкриття проходу у Чорне море, яка завершилась жахливою поразкою не лише британської армії, а й союзників.
Історики досі сперечаються, чи ця операція була проваленою ще на етапі планування чи через погане виконання, але фактом є те, що Британія, Франція, Австралія та Нова Зеландія убитими, пораненими і зниклими безвісти втратили 140 тисяч чоловік, а всю провину за провал поклали на керівника операції — Черчилля, і його звільнили з посади першого лорда Адміралтейства, тобто голови британського флоту.
Але Черчилля це не зламало і від цієї поразки він дістав важливий урок — стратегія без адекватної тактики це те саме, що ідея без адекватного вираження. Деякий час після цієї поразки він порефлексував, зайнявся живописом, а потім відкинув свою гордість і погодився на набагато нижчу посаду в британській армії, з якої вже й досягнув тих успіхів, про які ми всі знаємо.
Для мене ця історія дуже повчальна, бо жодна моя робоча проблема не мала таких великих наслідків, як в Черчилля, і це ще один доказ того, що важливо вчитись на помилках. Головне не повторювати однакові помилки двічі 🙂
Тому аналізуйте як позитивні, так і негативні аспекти своїх проєктів. Відмічайте, що спричинило успіх, і чому певні рішення не принесли бажаного результату. Використовуйте ці вивчені уроки для вдосконалення своїх проєктних підходів.
Підтримуйте мотивацію команди
Тут все просто: без команди ви самостійно нічого не досягнете. Створіть зручні умови для роботи вашої команди. Визнавайте досягнення, надайте можливість для розвитку та професійного зростання. Підтримуйте позитивний дух у колективі, створюючи дружню та продуктивну атмосферу.
Це особливо важливий пункт в теперішніх умовах в Україні, під час повномасштабної війни мотивація людей дуже вразлива і буде коливатись часто. Зважаючи на ситуацію, такі фактори, як кар’єрний ріст, уроки англійської мови чи PlayStation в офісі, часто відходять на другий план, оскільки люди шукають стабільності.
Зараз такі базові потреби, як безпека, фізичний і психологічний комфорт важливіші, ніж будь-коли. Тому ви, як керівники, повинні бути поруч з вашими людьми, вислуховуючи їх, забезпечуючи їхню безпеку, зміцнюючи довіру на робочому місці та пам’ятати, що люди є найважливішим надбанням вашої компанії.
Запроваджуйте нові технології
Стеєте за розвитком технологій, які можуть полегшити вашу роботу. Автоматизуйте рутинні процеси, впроваджуйте програми для управління проєктами, використовуйте інструменти для аналізу даних. Це допоможе збільшити продуктивність та знизити ризики помилок.
Також не бійтесь експериментувати — на одному з моїх проєктів ми з командою ввели практику внутрішніх хакатонів з метою презентувати якісь нові ідеї замовнику.
Це почалось як наша внутрішня ініціатива і перші декілька разів команда збиралась на вихідних і генерувала ідеї, ми презентували якісь демки та МВП замовнику і з цих ідей нових продуктів ми змогли стартувати декілька нових проєктів і виростити акаунт.
А далі замовнику настільки сподобалась ця ідея, що він виділяв нам п’ятницю раз в квартал на такі хакатони (насправді одного дня не завжди вистачало і це зазвичай продовжувалось на суботу, але це були наші інвестиції в розвиток бізнесу).
Не забувайте про саморозвиток
Проєктне управління — це постійний процес навчання. Здобуття нових знань та навичок допоможе вам розвиватися як професіонал та досягати кращих результатів у своїй роботі.
Сучасні ПМ — це вже не люди, які обмежені лише скоупом, графіком і бюджетом, тепер вони повинні зосереджуватись на впливі на результати, побудові відносин і досягненні стратегічних цілей своїх організацій.
Тому зараз для хорошого керівника на перший план виходять такі навики, як комунікація, емпатія та інші soft skills. Це те, в чому вас точно не замінить штучний інтелект 🙂
19 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів