Мудрий PM


Гео и язык канала: Украина, Украинский


Канал про Project & Product Management і про особисту продуктивність.
Веду його я - Андрій Мудрий @amudryy

Связанные каналы

Гео и язык канала
Украина, Украинский
Статистика
Фильтр публикаций




Online Risk Management workshop

Ще сьогодні зранку думав як цікаво можна була би розповісти про ризики?
Ситуація сьогоднішня, буквально свіженька - кілька годин тому. Рейс Братислава - Львів не може вилетіти з Словаччини. Хлопці повертаються з Product Increment Planning сесії, де щойно запланували наступні 12 тижнів роботи. Паніка: в турбіну при зльоті потрапила птаха, і літак не закінчує процедуру вильоту.

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

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

Про це вже за 2 тижні я розповідатиму на онлайн воркшопі спільно з @iampmclub Ще одним цікавим моментом майстер класу буде те, що він поводитиметься англійською, бо це доволі нечасте явище на українському ринку.

Ось тут лінк на реєстрацію з 15% знижкою від організаторів: для цього треба бути у 5-ці перших, хто ним скористався. Від себе цій пятірці я додам безкоштовну 30-хвилинну ментор сесію. Лінк діє до 23 січня.
https://secure.wayforpay.com/payment/sebe30c47f761

Що? Де? Коли?
Де? Онлайн.
Коли? 30 січня.
Тривалість 3 години.


Через форс мажор вебінар переноситься на 26 листопада.
Ще є майже 2 тижні зареєструватися!

Чекаю вас!


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

На щастя, тема моя улюблена - Risk management - і тут я люблю і маю що багато розповісти.

Ми з IAMPM дуже старались, щоб було цікаво!
До речі, вебінар відкритий - тож: Щиро Запрошую!

http://bit.ly/2K4xwTL


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

Інструменти управління ризиками тепер доступні як стаття на Medium

Дякую за коментарі і натхнення.


І ще раз про делегування

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

⭐️ При делегуванні - передавайте не план, а критерії результату.

Задати acceptance criteria і все - видається просто. Насправді ні. Делегування - це не тільки можливість встигати більше - це і ріст команди. Як люди зможуть розвязувати складні завдання, якщо їм не давати скласти шлях вирішення?

⭐️Тому делегуйте результати, а не дїі.

Про всяк випадок нагадаю, що для менгеджерів,
⭐️ Делегуються завдання а не відповідальність!


З нагоди 1 квітня Atlassian опублікували відео про JIRA для дітей. Мовляв прививайте любов до самоорганізації змалку. Але найкращий той жарт, в якому тільки доля жарту.

Можна скільки завгодно говорити про те, що Scrum зокрема чи Agile застарів, але ми таки не навчились використовувати підходи, як ми застосовуємо в роботі в реальному житті.
🔹Як часто ми плануємо великі проекти ітеративно в реальному житті?
🔸Скільки нервів і зусиль ми витрачаємо просто тому ще не можемо синхронізуватись?
🔹Чи часто ми проводимо ретроспективу того, що вийде добре в стосунках і чи можна щось покращити?
🔸Чи всі проекти та ініціативи для нас справді пріоритетні? Чи приносять найбільше повернення інвестицій грошей та часу? При цьому повернення не завжди повинне бути у грошах, а й в самореалізації, досягненні дитячих чи дорослих мрій, щасті.
🔹Наскільки швидко ми адаптуємось до змін, що весь час відбуваються?

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

https://www.youtube.com/watch?v=9shZslfbaS0


Risk Management Tools 3/3

Самописні інструменти

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

Свого часу, я брав участь в ініціативній групі розробки рішення на основі розширеного фреймворку роботи з ризиками ADRIANO (сам фреймворк заслуговує окремої серії дописів) на основі JIRA. Здається (але це не точно) нам навіть вдалось вийти на Atlassian Marketplace і навіть продати кілька прикладів цього рішення.

Зараз я працюю з Sigma Software - і у нас також є Project Management Tool, який має вбудовану систему управління ризиками. Список властивостей ризиків приблизно відповідає тому, який описувався у розділі про реєстр ризиків в таблиці. Але перевагою такого інструменту є наприклад те, що активні ризики потрапляють у щотижневі звіти про проект автоматично. Відповідно до критичності ризиків можна сказати ступінь здоров’я проекту по кожній зі складових частин: часу, обсягаи робіт, задоволеності команди і клієнта і навіть кошторисом проекту. А після закінчення проекту ризики аналізуються під час Post Mortem, і висновки (Lessons Learned) потрапляють до спеціального репозиторію. І їх можна використовувати і при старті інших проектів. Таким чином виконується остання стадія управління ризиками, про яку часто забувають, якщо користуються простими інструментами на кшталт Spreadsheets.

Готові рішення

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

"Risk Gap”

В мене був досвід користуватись одним з готових інстументів Risk Gap. Ми використовували його під час навчального проекту Expedition PM (про нього я теж колись напишу окрему статтю). Перевагами інструменту було те, що він легко налаштовувався, містив оцінки від 1..10 для імовірностей і впливів ризиків (зі зручними підказками), дозволяв оцінювати ризики кількісно якщо задати скільки коштуватиме в часі, грошах чи обсягу той чи інший ризик. Користувачі могли оцінювати ідентифіковані ризики незалежно одне від одного - а отже оцінка ставала більш об’єктивною. А також можна було створювати завдання для уникнення чи зменшення ризику. Якщо треба “підняти систему з нуля”, то я б радив цей інструмент.

Інші інструменти
Ось ще кілька інструментів по роботі з ризиками про які мені розповідали колеги ПМи:
🔹 https://parapet.com/
🔸 www.project-risk-manager.com/
🔹 RiskView
🔸 Citius One
🔹 Prims Risk Management


Risk Management Tools 2/3

Risk Register

Якщо досвід в управлінні ризиками (а також час - що насправді не маловажливо) - то можна створити цілий реєстр ризиків. Я зазвичай робив їх у Google Spreadsheets чи Excel. Тут можна просто задати всі необхідні атрибути ризиків.
Я використовав вбудовані фільтри та Conditional Formatting для наочності та зручності роботи. Таким чином можна відсікти напиклад watchlist - ті ризики які треба переглядати значно рідше через їх менше значущість.

Ось колонки які я використовую в таких реєстрах ризиків:
🔹 Назва ризику (до 60 символів)
🔸 Опис ризик - його для простоти роботи з реєстром можна ховати, коли знає про що йдеться і відкривати коли демонструєш реєстр тим, хто з ним стикається значно рідше (твітер статус - 140 символів, чи для любителів - 280 символів)
🔹 Сфера впливу - випадний елемент (time, scope, budget, quality, team satisfaction, customer satisfaction)
🔸Опис впливу - аналогічно до опису самого ризику
🔹 Ймовірність - оцінкова ймовірність за шкалою 1..3, 1..5, 1..10
🔸Вплив - йдеться про вплив ризику на проект як і ймовірність вище
🔹Значущість ризику - добуток і ймовірності на вплив
🔸Статус ризику - можна легко відфільтрувати закриті ризики щонайменше
🔹Стратегія - стратегія реакції на ризик (mitigate, omit, transfer, accept)
- ці реакції заслуговують на окремий пост чи навіть статтю
🔸Тип - позитивний чи негативний - ризик чи можливість
🔹Дата створення
🔸Дата закриття
🔹Власник ризику - особа яка відповідальна по роботі з ризиком (і так це не завжи скрам мастер чи менеджер)
🔸Коментарі - тут можна дати волю письму, не обмежуватись в 140 символів. Я пишу сюди всі оновлення і новини які я отримую по ризику з датами.


Risk Management Tools

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

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

Impediment backlog
Той хто ближче знайомий зі Scrum напевно знає, що єдиний інструмент яким володіє лише Scrum Master - Impediment Backlog. Impediment - це перепона, яка не дає команді бути повністю ефективною і scum master має їх усувати.
Можна усувати проблеми (читай: імпедіменти) в міру їх появи - реактивний підхід. Якщо скрам мастер це робить - це непогано. Добре: працювати проактивно - реєструвати потенційні проблеми команди - ризики.
Відповідно Impediment backlog - дуже спрощена форма роботи з поточними ризиками в скрамі.

Impediment backlog можна організувати різними способами:
🔹 Стікерами на окремій дошці (працює для доволі рідкісного випадку коли вся команда таки знаходиться в одній кімнаті)
🔸 Віртуальними стікерами на віртуальній дошці - на зразок RealtimeBoard (для повністю розподілених команд)
🔹 Окремим проектом в таск трекері. Так наприклад TFS Online, JIRA теж дозволяють побудувати окрему канбан дошку для скрам мастера. Можна навіть додати окремий лінк для будь якого члена команди, щоб він міг створити імпедімент на розгляд
🔸 Будь-який інший інструмент що підтримує списки і дозволяє спільну роботу


Дякую за фідбек щодо тем каналу і зацікавлення по темах. А ще дякую всім хто писав із пропозиціями тем в приват. Виглядає, що анонси подій будуть (але в міру появи запрошень), пропоновані вакансії можна постити але не частіше ніж що 2-3 тижні, а проекти також не чітко з’являються.
Виходить десь співвідношення 1-1-1-3
А от рубриці постів про інструменти таки бути.
Про що вже наступний допис.


3 ознаки що ви готові до менеджерської позиції

Часто трапляється так, що найкращого технічного працівника промоутять до ПМа, мовляв, це нормальний ріст для технічної людини, і якщо ти справлявся з технологіями то ти - найкращий кандидат щоб справитись із командою. Так ліди мають авторитет в команді - і це мало б грати на руку, але в дійсності часто виходить що чудового техліда зробили таким собі ПМ-ом.
Мені траплялися навіть керівники великих департаиментів, котрі замість того, щоб займатись ними по тихому брали маленькі проекти на Upwork. А значить: нова роль не приносила реалізації в професійному плані. Раніше, років 10 тому стати ПМом означало ще і більшу зарплату, але зараз це зовсім не так

З іншої сторони найталановитиіші ПМи теж виходять з розробників і тестувальників, і справа тільки в готовності і у внутрішньому поклику щзоб стати класним ПМом
Тому ось зібрані 3 ознаки, до яких варто прислухатись:

1️⃣ Бачення того, що ти більше зможеш зробити як керівник.

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

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

2️⃣ Бажання працювати більше для отриманням НОВИХ вмінь.

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

Правда, хороші новини в тому що це не зробить вас менш продуктивними. Навчаючись новому у менеджменті - ви ставатимете кращими в чомусь новому, чого бракує. Треба тільки застановитись чи хочете ви саме цього. Нормально і одне і інше: чи ставати вузькопрофільним спеціалістом в галузі, чи “прокачуватись” в управлінні.

3️⃣ Ви не можете більше реалізувати все самотужки.

З десяток років тому як стати скрам-мастером та ПМ, я багато саморефлексував про свій подальший рух. Я розумів, що хочу радше будувати нову структуру та культуру. І найефективнішим способом було - лідерство в команді (і “служіння” команді). І, мабуть, тільки разом з моїми командами це було можливим.

Менеджмент має сенс, тільки коли твої цілі більші, ніж те, що ти зможеш зробити сам.

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


Тим часом в мене в професійному житті також відбувається багато змін, спроб нових ролей. Зявляються нові завдання, ролі, виклики. А також нові особисті та спільні проекти. Хочеться ними також поділитись - то проголосуйте (можна кілька кнопочок вниху одночасно), якщо цікаві:
📈 - анонси подій на яких я виступатиму
🗞 - дізнатись про мої особисті чи спільні робочі проекти
🙋🏼‍♀️ - вакансії (ПМ і суміжні), куди мене просять когось порекомендувати
🔨 - інструменти якими я користуюсь

А ще цікаво почути про відгуки та запитання в коментарях і в приват @amudryy


Нас 500! Рубікон перейдено! (Насправді коли вийде цей пост буде вже майже 600).
Коли я неповний рік тому я таки зважився створити цей канал я собі важко міг уявити, що канал досягне цієї позначки. А тепер наче відкриваються нові горизонти. Я навмисне жодного разу не купував реклами каналу, а розрховував на органічний ріст - коли читачі радитимуть канал знайомим. Ну і я з виступів на конференціях і мітапах його популяризував. Так я перевірив (ніби як починаючий Product Manager), що він таки цікавий і корисний і це мотивація продовжувати далі і докладати ще трохи більше зусиль.

Дякую за ваші:
💬 коментарі - так я знаю, що хтось відчитує мої не надто короткі тести
🔥реакції - так я знаю що заходить більше
❓запитання - з них виходять деколи навіть цілі статті і доповіді на конференція (хоч відверто запитань хотілось би більше)
💡ідеї і пропозиції
І натхнення яке я отримую щоб рухатись вперед!


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

Але тут дружній канал "ПМ без проблем" знайшов рішення - ПМ Чат. Де відбувається трохи більше спілкування. Тому люто раджу ПМ чат, якби вам як і мені деколи бракувало більше спілкування. Не на правах реклдами а на правах сенсу.


Коли відхиляєш кандидата

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

Коли ти відхиляєш кандидата:
1️⃣ Розкажи рекрутеру які сильні сторони ти в кандидата помітив. Не варто знижувати шанси кандидата пройти іншу співбесіду, вдаривши по його/її самооцінці.
2️⃣ Якщо - це доречно, порекомендуй кандидату як підправити резюме. Для того щоб бути нормальним не потрібно багато зусиль.
3️⃣ Якщо кандидат справді не підійшов - повідом (сам чи через рекрутера) йому це як тільки ти це зрозумів. Краще коли знаєш, що ти не підійшов ніж тобі морочать голову. (Зізнатись: сам потім відчув це кілька разів на власному досвіді).
4️⃣ Перед тим як починати співбесіду - згадай що таке емпатія. Не давай приводу вважати, що щось піде не так, ще до того як увійшов до кімнати.
5️⃣ Якщо знаєш ПМа чи компанію якій би кандидат міг підійти - порекомендуй. В компаніях і на проектах різні культури чи потреби, і якщо хтось не підійшов тобі, то це не значить що не пасуватиме деінде. Якщо твоя рекомендація буде успішною - вигорають всі три сторони.


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

Якщо б мені треба було назвати одну проблему, через яку виникали проблеми в 2018, то я б однозначно назвала “miscommunication”. Історії про те, “що ми сказали замовникам, і що вони зрештою прочули” часто виглядають як анекдоти, та щось не завжди смішно.
Спілкування між людьми доволі процес: слова та дії інших людей сприймаються нами через призму нашого досвіду, виховання, настрою. А якщо додати в рівняння ще й різницю в менталітеті, складність сприйняття мови при віддаленій комунікації, то врешті ми отримуємо повний конфуз.
Мій улюблений приклад: слово “Okay”. Ми його завжди сприймаємо позитивно, хоч часто мали б як щось на зразок “мгм” чи навіть “еее….”.

Я про це вперше замислилась, коли клієнт поскаржився, що вся команда бере відпустку перед релізом, не погодивши з ним. “Та ну, не може бути” – радісно заявила я замовнику, – “ми у відпустку лише по апруву ходимо“. І пішла до ПМа. Він мене підтримав, кажучи що звісно по погодженню. І показав повідомлення, де він прислав список відпусток клієнту, на яке той відповів “Okay….”
Оце той випадок, коли “Okay” = “Ееее…” І не варто це було розцінювати як погодження.

Другий приклад: замовник на кожному демо казав “OK". І команда радісно вважала, що замовник апруває всі демо. Насправді, детальне прояснення ситуації з замовником показало, що для нього “ОК” значить десь так: ви мені щось показали, я це щось побачив, нічого не зрозумів, але, сподіваюсь, що наступного разу ви щось внятне покажете. І єдиний мій спосіб дати собі з тим ради – проактивно переконуватись, що нас правильно розуміють.

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

А які історії недокомунікації були у вас?


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

1️⃣ Почати делегувати доволі складно. Найчастіше менеджер починає про це задумуватися лише тоді коли обов'язків і рутинної роботи стає забагато - і просто треба щось зробити, щоб "розгребтись”. Але якщо подумати про це трохи раніше, то час вивільнений, можна використати для пропрацювання речей ширших, про котрі крім менеджера не буле кому думати.

2️⃣ Куди використати вільний час? Уявіть скільки ще часу можна зекономити, якщо звільнений час виділити на роботу з ризиками, замість того щоб витрачати ще більше на “гасіння пожеж” на проекті.

3️⃣ Перші кілька разів, коли делегувати по описаній вище схемі вийде не все просто і кілька кроків можливо треба буде повторити. Так само почувається людина котрій ви делегуєте обов'язки і це нагода почути себе на її місці. Але practice makes perfect - і наступні рази йтимуть легше; і для вас і для делегата.

4️⃣ Найцікавіше на кінець!
Менеджери котрі вже якийсь час попрацювали тяжіють до поведінки, коли вони просто розгрібаючи свій список справ хочуть викинути задачі й до них не повертатись. Просто написати чи сказати комусь що потрібно зробити. І все - чекають що це вже зроблено. Але це підміна понять і відповідальність за проект лежить на менеджерові - бо менеджер відповідає за те щоб цілі проекту були виконані.
Отже,

Ти можеш делегувати обов'язки, але не делегувати відповідальність!


Як делегувати в 4 кроки?

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

Отже мій фреймворк з делегування:
В мене є метод по делегуванню:
0. Для делегування найкраще пасує робота, яка повторюється
1. Зроби все сам/сама і в процесі записуй що саме ти робиш (в процесі подумай чаму так)
2. Наступного разу "програй" записаний сценарій разом з делегатом. Обговоріть питання.
3. Ще раз дай сценарій делегату і перевір роботу.
4. Делегуй завдання і потім просто спитай як справи.
5. Крок 4 повтори.
6. (цього кроку вже нема - завдання делеговано)

Деколи якийсь крок треба повторити, якщо на ньому виникли якісь труднощі, але загалом же принцип простий, правда?


Зробити правильний вибір - це:
- прийняти оптимальне рішення на даний час і при всіх відомих даних обставинах
- ризикувати в прийнятних (відповідно обставин) рамках
- принести найбільшу користь при найменших затрах.

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

Рекомендую подивитись відео за лінком. Висновки вище не синопсис відео, а просто рефлексія на висновки котрі я давно зробив самі ще раз в цьому переконуюсь.

Показано 20 последних публикаций.

757

подписчиков
Статистика канала