
2024-08-01 12:00:01
Повний гайд з ризик менеджменту у Software Development проєктах.
В мене є погана звичка, щойно я дивлюсь на будь-яку річ — я думаю, що може піти не так. І хоча вона багато в чому мені шкодить, в роботі, вона безумовно допомагає.
Менеджер — це часто не про ideal path.
Це про — аналіз того, що може піти не так, й якась робота з цими подіями.
Тому, якщо на вашому проєкті ще немає Risk Mitigation Plan'у, дуже раджу зайнятися цим прямо зараз. Це може зекономити вам велику кількість грошей та нервів у майбутньому.
Особливо це стосується R&D проєктів. Коли ви ще не розумієте, як саме ви будете досягати поставленої цілі, й у вас є рісерч.
Як зрозуміти, які ризики існують у вашому проєкті?
→ Історичні данні.
Подивіться на ваші попередні цикли. Проєкти. Особливу увагу приділяйте не успішним. Проаналізуйте, та зрозумійте, що саме пішло не так. Та подумайте, що ви могли б зробити інакше.
З мого досвіду, багато проєктних ризиків — зав'язані на організаційному менеджменті. А це означає, що ці ризики можуть бути не тільки у вас, але й в сусідніх проєктах або командах.
→ Комунікація з командою.
Ви експерти в своїх доменах. Скоріш за все, ви вже після онбордінгу, маєте відчуття, що може піти не так. Головне, поговорити з усіма, від розробників, до DevOps'ів і QA. Бо кожна зі сторін має свій вплив на ваш проєкт.
→ Майндкарта
Пройдіться по майндкарті яку я зашерив, та подумайте, чи є в кожному з цих доменів якісь ризики для вас та вашого проєкту.
До речі, ви можете попросити ChatGPT допомогти вам, але важливо надати йому максимальну кількість контексту про ваш проєкт, для цього можете надиктувати слова через SuperWhisper.
Це одна з найпопулярніших категорій питань під час співбесід.
Тому вам обов'язково потрібно розбиратися в домені ризиків.
В мене є погана звичка, щойно я дивлюсь на будь-яку річ — я думаю, що може піти не так. І хоча вона багато в чому мені шкодить, в роботі, вона безумовно допомагає.
Менеджер — це часто не про ideal path.
Це про — аналіз того, що може піти не так, й якась робота з цими подіями.
Тому, якщо на вашому проєкті ще немає Risk Mitigation Plan'у, дуже раджу зайнятися цим прямо зараз. Це може зекономити вам велику кількість грошей та нервів у майбутньому.
Особливо це стосується R&D проєктів. Коли ви ще не розумієте, як саме ви будете досягати поставленої цілі, й у вас є рісерч.
Як зрозуміти, які ризики існують у вашому проєкті?
→ Історичні данні.
Подивіться на ваші попередні цикли. Проєкти. Особливу увагу приділяйте не успішним. Проаналізуйте, та зрозумійте, що саме пішло не так. Та подумайте, що ви могли б зробити інакше.
З мого досвіду, багато проєктних ризиків — зав'язані на організаційному менеджменті. А це означає, що ці ризики можуть бути не тільки у вас, але й в сусідніх проєктах або командах.
→ Комунікація з командою.
Ви експерти в своїх доменах. Скоріш за все, ви вже після онбордінгу, маєте відчуття, що може піти не так. Головне, поговорити з усіма, від розробників, до DevOps'ів і QA. Бо кожна зі сторін має свій вплив на ваш проєкт.
→ Майндкарта
Пройдіться по майндкарті яку я зашерив, та подумайте, чи є в кожному з цих доменів якісь ризики для вас та вашого проєкту.
До речі, ви можете попросити ChatGPT допомогти вам, але важливо надати йому максимальну кількість контексту про ваш проєкт, для цього можете надиктувати слова через SuperWhisper.
Це одна з найпопулярніших категорій питань під час співбесід.
Тому вам обов'язково потрібно розбиратися в домені ризиків.