Projekto pradžios (kickoff) susitikimo darbotvarkė inžinerijos komandoms

Klausimas, kurį kickoff susitikimai praleidžia

Sėkmingai vykęs projekto kickoff palieka komandą suderintą dėl to, ką kurti, kas ką daro ir kada tai turi būti atlikta. Toks suderinimas paprastai išsilaiko apie tris savaites. Tada apimtis išsiplečia, suinteresuotas asmuo persigalvoja dėl esminės prielaidos, priklausomybė vėluoja, ir komanda pastebi, kad niekada nesusitarė, kas priima sprendimą, kai du protingi žmonės nesutaria.

Klausimas, kurį dauguma kickoff darbotvarkių praleidžia, yra: kaip ši komanda priims sprendimus, kai kas nors nueis ne taip? Ne projekto planas — sprendimų priėmimo sistema. Kas atsakingas už apimtį, kai funkciją reikia iškirpti? Ką komanda daro, kai techninis apribojimas paneigia produkto reikalavimą? Kuris suinteresuotas asmuo turi galutinį žodį, kai du padaliniai nori skirtingų dalykų?

Į šiuos klausimus lengva atsakyti kickoff metu, nes dar niekas nepastatyta ant kortos. Į juos kur kas sunkiau atsakyti projekto viduryje, kai kiekvienas turi savo poziciją. Žemiau pateiktas šablonas rezervuoja tam laiko dar prieš prasidedant sunkiajai daliai.

Darbotvarkė (nukopijuokite ir įklijuokite)

Trukmė: 60–90 minučių, priklausomai nuo projekto sudėtingumo
Formatas: vedamas; visi pagrindiniai suinteresuoti asmenys ir prisidedantieji dalyvauja arba asinchroniškai peržiūri prieš pradedant


1 skiltis — Projekto tikslas ir apimtis (20 min.)

  • Nurodykite tikslą vienu sakiniu: kaip atrodo sėkmės rezultatas, jei įmanoma, išmatuojamas
  • Apimtyje: ką projektas pristatys, įvardyta konkrečiai
  • Už apimties: ko šis projektas aiškiai nedarys — išvardykite bent tris dalykus
  • Sėkmės kriterijai: kaip komanda žinos, kad projektas baigtas?
  • Už šią skiltį atsakingas vadovas (EM) arba produkto vadovas (PM); inžinieriai prieštarauja, jei nurodyta apimtis neatitinka įgyvendinamumo

2 skiltis — Vaidmenys ir atsakomybė (15 min.)

  • Kiekvienai darbo srautui įvardykite vieną atsakingą asmenį — ne komandą, o žmogų
  • Kas priima galutinį sprendimą dėl: produkto apimties, techninės architektūros, išorinės komunikacijos?
  • Kas yra informuojamas, kas konsultuojamas, o kas sprendimų priėmėjas kiekvienam pagrindiniam sprendimų tipui?
  • Įvardykite projekto vadovą, kuris yra atsakingas, jei niekas kita neaišku

3 skiltis — Apribojimai ir rizikos (15 min.)

  • Griežti apribojimai: terminas, biudžetas, atitiktis, priklausomybės nuo kitų komandų
  • Žinomos rizikos: kokie yra trys svarbiausi dalykai, galintys išmušti šį projektą iš vėžių?
  • Kiekvienai rizikai: tikimybė, poveikis ir mažinimo atsakingas asmuo
  • Kas priverstų projektą atšaukti ar reikšmingai sumažinti apimtį? Įvardykite tai dabar

4 skiltis — Komunikacijos planas (10 min.)

  • Kaip dažnai komanda derinsis? Kokiu formatu?
  • Kas gauna būklės atnaujinimą ir kaip? Nemanykite, kad suinteresuoti asmenys nori to paties kanalo
  • Kur laikoma projekto dokumentacija?
  • Koks eskalacijos kelias, jei kas nors blokuoja projektą?

5 skiltis — Neatsakyti klausimai (15 min.)

  • Išvardykite kiekvieną klausimą, į kurį komanda šiandien negali atsakyti
  • Kiekvienam: priskirkite atsakingą asmenį ir datą, iki kurios reikia atsakymo
  • Klausimai be datos ir atsakingo asmens vis dar bus neatsakyti pusiaukelėje

6 skiltis — Tolesni žingsniai (10 min.)

  • Trys dalykai, kurie turi įvykti per artimiausias penkias darbo dienas, kad prasidėtų tikras darbas
  • Kiekvienas tolesnis žingsnis turi vieną atsakingą asmenį
  • Patvirtinkite, kaip kickoff santrauka bus išplatinta ir kam

Ką populiarūs kickoff šablonai daro klaidingai

Dauguma kickoff šablonų kruopštūs dėl projekto plano ir menki dėl to, kas nutinka, kai planas nesilaiko. Jie sukuria tvarkingą apimties dokumentą ir RACI matricą, o tai naudinga. Jie nesukuria bendro atsakymo į klausimą „ką darome, kai duomenų bazės tiekėjas projekto viduryje patrigubina kainas?“ arba „kas iškertama, jei pasieksime griežtą terminą su 80 % baigtų funkcijų?“.

Apimties už ribų nebuvimas yra kita nuosekli spraga. Nurodyti, kas įeina į apimtį, paprasta. Nurodyti, kas aiškiai lieka už jos — išvardijant tris ar keturis konkrečius dalykus, kurių projektas nedarys — priverčia tą patį pokalbį apie suinteresuotų asmenų lūkesčius, tik iš kitos pusės. Suinteresuoti asmenys, kurie būtų manę, kad mobilus klientas įtrauktas, sužino tai kickoff metu, o ne šeštą savaitę.

Trečia spraga — neatsakytų klausimų skiltis. Komandos nenori kickoff metu iškelti to, ko nežino, nes atrodo, kad tai reiškia nepasirengimo pripažinimą. Bet nežinomi atsakymai virsta projekto vidurio blokatoriais, o projekto vidurio blokatoriai brangūs. Kuo anksčiau žinote, kad klausimas egzistuoja, tuo anksčiau kas nors gali prisiimti atsakymą.

Apie tai, kaip šios spragos kaupiasi į pridėtines sąnaudas per kelis mėnesius trunkantį projektą: Susitikimų mokestis.

Kodėl verta gerai užfiksuoti kickoff užrašus

Kickoff dokumentas yra dažniausiai bet kuriame projekte remiamasis artefaktas. Būtent jį žmonės tikrina, kai apimtis ginčijama, kai prisijungia naujas komandos narys, kai suinteresuotas asmuo klausia „ar mes nenusprendėme X kickoff metu?“. Gerai dokumentuotas kickoff yra projektas, kurį lengviau valdyti.

Pavleur automatiškai užfiksuoja pilną kickoff'ą: apimtį, kaip išsakyta, vaidmenis, kaip priskirti, rizikas, kaip įvardytos, neatsakytus klausimus su atsakingais asmenimis, tolesnius žingsnius su atsakingais asmenimis ir datomis. Jei kas nors bendrino ekraną su projekto aprašu, diagrama ar reikalavimų dokumentu susitikimo viduryje, vizualas įtraukiamas į ataskaitą šalia diskusijos. Vien garso įrankiai suteikia, kas ką pasakė; jie neužfiksuoja architektūros diagramos ekrane, kai techninis vadovas aprašė priklausomybę. Gauta ataskaita tarnauja kaip projekto tiesos šaltinio dokumentas nuo pat pirmos dienos. Apie tai, kaip tai lyginasi su tradiciniais susitikimų fiksavimo įrankiais: Pavleur ir alternatyvos.

Pastaba apie dalyvavimą

Visi, iš kurių tikimasi, kad priims sprendimą šiame projekte, turėtų dalyvauti kickoff'e arba peržiūrėti pilną įrašą ir rašytinę santrauką prieš pradedant darbą. Suinteresuotas asmuo, praleidęs kickoff'ą ir po dviejų savaičių neformaliai sužinojęs apimtį, yra laukiantis projekto vidurio apimties ginčas. Kickoff'o užduotis — sukurti bendrą kontekstą, o bendras kontekstas egzistuoja tik tada, kai reikiami žmonės yra kambaryje.

Projekto pradžios (kickoff) susitikimo darbotvarkė inžinerijos komandoms | Pavleur