Як проходить день проєктного менеджера в IT аутсорсі

Привіт, мене звуть Марина Руденко. В IT я вже 4 роки, а останній рік співпрацюю з EPAM як Project Manager. У статті розповім, як проходить типовий день проєктного менеджера: розклад, документація, інструменти, проведення зустрічей, взаємодія з командою та клієнтами.

Розклад

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

Що важливо зробити перед стартом основного процесу:

• Розвантажити оперативну пам’ять: витягнути «з голови» та зафіксувати всі завдання на сьогодні. Ми часто пам’ятаємо багато дрібних і великих завдань: зробити таймлайн, завести тікет, перевірити продакшн, призначити демо з клієнтом. Якщо не вести цьому облік, можна щось проґавити. Тому важливо складати список справ у блокноті чи будь-якому зручному інструменті для менеджерів.
• Перевірити пошту та месенджери, виписати нові завдання. Це особливо важливий момент, якщо ви працюєте на закордонний ринок — не завжди графік клієнтів збігається із вашим. У таких випадках PM-и часто можуть побачити нові правки, change requests, запити та решту зворотного зв’язку від замовника саме вранці.
• Визначити список «важливого на сьогодні» та «важливого на інші дні». Не всі завдання, які виникають сьогодні, потрібно вбудовувати у пріоритетний список. Цілком нормально частину з них запланувати на інший день. Тайм-менеджмент — один із найважливіших навичок на позиції РМ.
• Переглянути в календарі графік зустрічей і визначити, в які часові блоки можна поставити інші робочі завдання. Наприклад, коли можна виділити повноцінні 2 години на підготовку таймлайну для нового проєкту, а в який день будуть постійні мітинги, а значить, великі завдання краще відсунути на інший час.

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

Перша половина дня – час для активностей

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

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

• як справи щодо проєкту;
• які є блокери;
• де потрібна допомога;
• що у кожного за планом сьогодні.

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

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

Обід — час для перезавантаження

Запорука продуктивної роботи протягом 8 годин — це обов’язкова тривала перерва на відпочинок. Якщо ви ще на початку вашої кар’єри PM, вам це може здаватися не дуже суттєвим. Тим не менш, дуже важливо з самого початку побудувати собі графік, в якому є місце для відпочинку та перезавантаження організму — так ви зможете довше залишатися в ресурсі, зосередженим та ефективним.

Рекомендую виділяти на обідню перерву близько години. На цей час залиште в спокої: робочі чати, пошту та дзвінки, навчальні сесії. Відпочиньте!

Друга половина робочого дня — час для закриття решти завдань

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

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

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

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

Робота з документами

Документація — невід’ємна частина роботи PM-а. Вона відрізняється залежно від проекту, ІТ-компанії, підходів самого менеджера. У роботі можна використовувати як власні шаблони, так і застосовувати стандартизовані — все залежить від цілей, домовленостей з клієнтом, керівництвом і командою.

Один із обов’язків PM-а — фіксувати всі основні етапи роботи над проектом та вчасно давати зворотний зв’язок команді, керівництву та клієнту і в цьому йому допомагає правильна документація.

Три обов’язкові документи:

• Статус-документ для клієнта/керівництва. У ньому фіксують поточний статус проекту.
• Таймінг проєкту. За ним контролюють темп просування проекту: чи йдете за графіком, скільки вже пройшли, які наступні контрольні точки.
• Risk Log. Тут враховують ризики вашого продукту.

По суті, цих трьох документів на практиці достатньо для контролю основного процесу, але є й інша документація, щоб спростити роботу РМ-а.

Документи на розсуд проєктного менеджера та компанії, в якій він працює:

• Project Charter. У ньому фіксують головну інформацію щодо проєкту: склад команди, що розробляєте та які цілі, бюджет, часові рамки, принципи комунікації та інші деталі.
• KPI Tracking. Документ, у який записують встановлені керівництвом чи клієнтом ключові показники ефективності.
• Change Management Log. Місце, де фіксують зміни у проекті, які вніс клієнт. Наприклад, замовник спочатку хотів зробити соціальну мережу, а на середині етапу розробки вирішив зупинитися на месенджері — ця інформація вноситься до цього документу.
• Communication Plan. Список людей, з якими спілкується менеджер, з обов’язковою вказаною специфікою спілкування: як часто, в якому форматі.
• RACI Matrix. Список стейкхолдерів із зазначенням ролей та дій, за які вони відповідають. RACI Matrix часто перетинається з Communication Plan. Наприклад, у матриці ви вказуєте, що клієнт підтверджує дизайн. У плані ж фіксуєте, що раз на тиждень даєте замовнику макет на розгляд, який він підтверджує письмово.
• QA Plan. По суті це план відстеження якості продукту, який складають тестувальники. У ньому QA вказують: що, коли і як перевірятимуть, і за якими показниками оцінюватимуть результати.
• Sprint, Day Commitments. Документ, де ви вказуєте заплановані завдання на певний період часу: день, тиждень, місяць.
• Requirements. Вказівка ​​вимог до проєкту: що він має робити, навіщо та як саме. Зазвичай документ складають бізнес-аналітики, перекладаючи побажання та бізнес-потреби клієнта «технічною мовою».
• Meetings Follow Ups. Це невеликий статус після мітингу. Наприклад, ви зустрілися з клієнтом, обговорили поточні завдання та дійшли якихось рішень. Далі все це пишіть у листі і відправляєте замовнику — так ви знижуєте можливість забути щось і фіксуєте домовленості, що у разі спірних питань допомагає врегулювати ситуацію на вашу користь.
• Retro та Sprint Results. Документ, у якому оформлюють результати зустрічі після завершення певного періоду часу, де проводять оцінювання роботи команди.

Список можна продовжувати майже до нескінченності, але з перерахованого рекомендую завжди використовувати Meetings Follow Ups, QA Plan, RACI Matrix, Communication Plan.

Основні інструменти для роботи PM

Правильно підібрані інструменти значно спрощують управління проєктом. Пропоную список найпопулярніших у нашій сфері:

• таск-менеджери: Jira, Basecamp, Trello, ClickUp.
• сховища документації: Confluence, Google Doc, Adobe XD, роздруківки.
• поштові служби: Gmail, Outlook.
• чати: Slack, MS Teams, Skype, WhatsApp.
• засоби для особистих записів: Notion, паперовий блокнот.
• для творчості: Jam Board, Figma White Board, Miro.
• інструменти для дизайну: Figma, Sketch, Axure.

Таск-менеджер — це must have для кожного проєктного менеджера, тому що допомагає планувати, розподіляти завдання і контролювати роботу команди. Більшість компаній використовують Jira, у якій функціональність гармонійно поєднується з дизайном. Для зберігання документації рекомендую застосовувати онлайн-сервіси, які надають гнучкі налаштування рівня доступу для різних груп користувачів. Якщо як таск-менеджер обрали Jira, то у зв’язці найкраще використовувати Confluence.

Для комунікації поштою однаково популярні Gmail та Outlook. Вибір залежить від індивідуальних переваг чи стандартів підприємства. Більшість робочого спілкування відбувається в чаті, тому підходьте до вибору цього інструменту виважено. Мені подобається Slack за широку функціональність та легку кастомізацію. Особисті записи можна вести за допомогою будь-якого інструменту, але для тих, хто все воліє робити онлайн, оптимальним рішенням буде Notion.

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

Лайфхаки для комфортної роботи

• Ставте склянку води або горнятко теплого чаю, щоб швидко змочити горло під час важливого демо. Так ви не посадите свій голос і зможете довше говорити.
• Фіксуйте зустріч у календарі для роботи над комплексним завданням та окремо для обіду. Це допоможе заблокувати ваш час від нетермінових завдань та незапланованих зустрічей. Особливо актуально при великій кількості учасників на проєкті та роботі у різних часових поясах.
• Майте звичку тримати під рукою наклейки для нотаток. Так ви завжди зможете швидко зафіксувати завдання, яке вам мимохідь поставили, спонтанну ідею чи чиєсь прохання.

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

Зустрічі — значна частина роботи менеджера

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

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

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

Обов’язкові зустрічі для PM

Найчастіше я працюю з гнучким управлінням проєктів (вона ж методологія Agile), мій основний фреймворк це Scrum, що має на увазі поділ завдань на частини з розбиттям робочого процесу на невеликі часові відрізки — спринти, які багато команд встановлюють у 2 тижні.

За період спринту я обов’язково проводжу низку зустрічей:

• Sprint Planning. Мітинг, на якому збирається вся команда з метою оцінити та спланувати навантаження на майбутній спринт. Sprint Planning найчастіше проводить Product Owner або тімлід, а РМ стежить, щоб команду не перевантажили, але дали достатній обсяг завдань.
• Daily Stand Up. Це щоденна зустріч із командою, де кожен відповідає на три запитання: що робив учора для досягнення мети спринту, що робитиме сьогодні і що заважає досягненню цілей спринту. В ідеалі Daily Stand Up має займати не більше ніж 15 хвилин. Якщо команда велика, краще поділити її на групи.
• Refinement. Мітинг, який проводиться під час поточного спринту. На цій зустрічі РМ обговорює завдання, які можна буде виконати на наступному етапі, готуючи подальше планування з урахуванням поточної ситуації на проєкті.
• Sprint Demo. Зустріч, на якій команда демонструє результати двох тижнів команді, клієнту, керівництву. Якщо показувати нічого, можна розповісти про завдання: що виконано, що у процесі чи заплановано.
• Retrospective. Зазвичай проводиться наприкінці спринту. На зустрічі РМ разом із командою обговорює успіхи та невдачі за цей період: що зробили добре, де стався збій та чому, що потрібно покращити. Часто ретроспектива — емоційна зустріч, оскільки на ній можливі оцінки дій як команди загалом, так і кожного окремо. Тому дуже важлива коректна модерація та підвищена увага менеджера до поведінки та слів учасників.
• Internal Status. Напівформальна зустріч, на якій РМ ділиться статусом проєкту з керівництвом та/або клієнтом.

Команда сама вирішує, хто проводить мітинги, але зазвичай це той, кому найбільше потрібно. Наприклад, Daily організовує Scrum Master, Planning — Tech Lead або Business Analyst.

Корисні, але необов’язкові зустрічі

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

• One2One. Зазвичай під цим мають на увазі зустріч менеджера з кимось із команди для обговорення особистих та робочих моментів у форматі тет-а-тет. Я її проводжу раз на місяць із кожним співробітником, щоб отримати та дати людині зворотний зв’язок, зрозуміти поточну ситуацію в колективі. Іноді можу організувати One2One ситуативно, коли я розумію, що без особистої розмови ніяк.
• 3 Amigos. Як правило, це зустріч трьох технічних фахівців — бізнес-аналітика, розробника та тестувальника — для уточнення завдання щодо проекту. BA розповідає, що потрібно зробити. Developer каже, як це можна реалізувати. QA — що і як тестуватиме для оцінки кінцевого результату.
• Tech Discussions. Дискусія розробників між собою з технічних аспектів проекту з подальшою передачею необхідної інформації менеджеру.

Ведучий зустрічі визначається також усередині команди.

Побудова роботи з командою та клієнтом

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

Кожна з цих ролей може бути закріплена як з боку IT-компанії, так і клієнтської. Наприклад, Product Owner зазвичай — це спеціаліст замовника, так як він безпосередньо пов’язаний з бізнесом. Загалом розподіл людей багато в чому залежить від типу проекту: Fixed Price, Time and Material, Dedicated Team.

• У варіанті з Fixed Price встановлюється конкретна сума за певний обсяг роботи, тому зазвичай вся команда на стороні IT-компанії.
• У випадку з Time and Material, коли оплата провадиться за витрачений час на кожну фічу, можливе підключення до процесу окремого фахівця.
• Якщо обрано формат Dedicated Team, замовник сам керує виділеною командою: призначає завдання, встановлює терміни, контролює.

Взаємодія з командою та клієнтом разом

Ідеальна ситуація, коли ви із замовником повністю довіряєте одне одному і не ділите свою команду та його. Тоді відбувається об’єднання в одне ціле фахівців з обох боків та максимальна синергія, а всі чати, листування та зустрічі – спільні.

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

Взаємодія з командою та клієнтом окремо

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

Особливості зарубіжних замовників

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

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

Робота проєктного менеджера чимось нагадує складання конструктора. PM повинен об’єднати в одну робочу систему клієнта, керівництво та IT-фахівців, грамотно вибудувати взаємодію між усіма учасниками проєкту та синхронізувати усі процеси. Деколи це складно, але завжди цікаво!