Мудрий PM

2019-03-26 14:00:33 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 Відкрити / Коментувати

2019-03-15 16:30:36 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 символів. Я пишу сюди всі оновлення і новини які я отримую по ризику з датами. Відкрити / Коментувати

2019-03-08 13:36:55 Risk Management Tools

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

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

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

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

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

2019-03-01 14:00:19 3 ознаки що ви готові до менеджерської позиції

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

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

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

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

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

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

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

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

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

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

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

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

2019-02-28 14:00:16 Тим часом в мене в професійному житті також відбувається багато змін, спроб нових ролей. Зявляються нові завдання, ролі, виклики. А також нові особисті та спільні проекти. Хочеться ними також поділитись - то проголосуйте (можна кілька кнопочок вниху одночасно), якщо цікаві:
- анонси подій на яких я виступатиму
- дізнатись про мої особисті чи спільні робочі проекти
- вакансії (ПМ і суміжні), куди мене просять когось порекомендувати
- інструменти якими я користуюсь

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

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

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

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

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

2019-01-12 16:00:10 Коли відхиляєш кандидата

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

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

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

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

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

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

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

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