МенеджментПідрозділ
Ведення проєкту
Чотири речі, яких проєктного менеджера ніхто не вчить, але всі очікують, що він їх уміє: що робити з тим, що ще не пішло не так, як сказати, скільки щось займе, у якій формі організації доведеться жити проєкту і що робити в перші тижні на проєкті, який почав хтось інший. Усі чотири — це ремесло ведення проєкту, а не метод його ведення, тому вони стоять поряд із методологіями, а не всередині якоїсь із них. Кожна сторінка написана так, щоб нею користувалися в понеділок, а не вчили до іспиту.
Що всередині
Усі сторінки цієї групи — і про що кожна з них.
- Ризик-менеджментШість місць, звідки приходить ризик, чотири відповіді й шість публічних провалів із контролем, якого в кожному бракувало.РеєстрPre-mortemКейси
- Чекліст нового проєктуДні 1–30, 31–60 і 61–90 на успадкованому проєкті — і базова лінія, яку можна зібрати лише на першому тижні.90 днівSTARSБаза
- Методики оцінюванняStory points, людино-дні, години й розміри T-shirt поруч — що вимірює кожна одиниця і до якого рішення вона пасує.Story pointsЛюдино-дніДіапазони
- Структури управлінняЛінійна, функціональна, дивізіональна, матрична й проєктна структури в порівнянні — і скільки може вирішувати PM у кожній.МатрицяPMBOKКонвей
З чого почати
- Ви щойно прийшли на проєктЧекліст, і спершу розділ про базову лінію: ці п’ять чисел — єдині, по які не можна повернутися пізніше.
- У вашому плані немає запасуРизик-менеджмент, розділ про оцінювання: він про те, що робити, коли чесна відповідь — «я не знаю».
- Просять реєстр ризиківСпершу прочитайте кейси: саме вони показують різницю між реєстром-контролем і реєстром-документом.
- Просять оцінкуМетодики оцінювання, і спершу розділ про діапазони: число, яке кажуть уголос, справджується приблизно тричі з десяти.
- Не певні, що можете вирішуватиОрганізаційні структури: п’ять питань у першому розділі покажуть, у якій структурі ви насправді працюєте.
Інше в цьому розділі
- МенеджментУправління IT-проєктом — це набір рішень, які перетворюють намір на випущений продукт: що будувати, як розрізати це на роботу, яку справді можна завершити, як команда організовує себе тиждень за тижнем і як результат доходить до користувачів. У розділі 25 тем у шести групах — продуктовий менеджмент, декомпозиція, методології, реліз-процес, формальні фреймворки й саме ремесло ведення проєкту, а не метод його ведення, — і кожна сторінка дає компроміс за вибором, а не переказ для сертифікаційного іспиту.
- ФреймворкиДва зводи практик проєктного менеджменту, які ви зустрінете в тендерній документації, вимогах до сертифікації чи процесному посібнику клієнта. Вони не конкуренти: один є зводом знань про те, про що думати, другий — методом, що приписує, хто що вирішує. Обидві сторінки описують, що справді каже чинне видання, а порівняння між ними — це та суперечка, яку зазвичай ведуть без нього.
- Процес релізуЩо відбувається між «код змерджено» і «користувач це має», — а у здоровій команді це рішення, а не подія. Три теми: як планувати реліз, коли не можеш пообіцяти дату; яку модель гілкування витримає ваша швидкість рев’ю; і як записати, що змінилося, для тих, для кого воно змінилося.
Було корисно?
Поділіться з тим, хто працює над тією ж задачею.