Projektijuhtimine on mitmetahuline ja see, kuidas me kõik oma projektide eri aspekte lahutame, sõltub tõenäoliselt sellest, kuidas meie töökoht seda teeb, kuidas klient seda teha soovib või kuidas me otsustame seda ise teha.
Selle postituse puhul, mis puudutab konkreetse projekti kallal töötamist, räägin konkreetselt sellest, kuidas me võtame projekti nõudeid ja jagame need paremini hallatavateks osadeks ja tulemusteks inimeste jaoks, kelle heaks me töötame. Ja seda tehes on minu arvates oluline, et nad oleksid kursis ja näeksid tagasiside kogumiseks õigetes kontrollpunktides edusamme.
Hoolimata sellest, et olen oma ettevõtte erinevaid aspekte muutnud, kuna olen rohkem õppinud selle kohta, mis töötab ja mis mitte, on üks asi, mis on jäänud järjepidevaks selles, kuidas ma projekti funktsioonide arendusega seotud aspekte käsitlen.
Omadused: verstapostid, ülesanded ja tagasisideahelad
Alati, kui hakkame sellistest asjadest rääkima, on lihtne libiseda meie tööstuse kõnepruuki. Ja kuigi ma arvan, et verstapostides ja ülesannetes ei ole tingimata midagi ülemäära tehnilist, on "tagasiside tsükkel" midagi muud.
Võttes arvesse nõuete kogumit, olenemata sellest, kuidas me selle vastu võtame, hakkan ma viivitamatult dokumenti läbi vaatama, olenemata sellest, kui suur see on, ja mõtlen kõikidele osadele, mida konkreetse funktsiooni saavutamiseks vaja läheb. Olenemata keeltest, tööriistadest, raamistikest või rakendustest, millega töötate, usun, et just siin on oluline oma tööga seotud sügav tundmine.
Funktsioonide jagamine verstapostideks ja verstapostid ülesanneteks.
Sealt edasi võtan antud funktsiooni, jagan selle erinevateks ülesanneteks ja kordan seda iga funktsiooni puhul. Tavaliselt püüan iga funktsiooni muuta verstapostiks, kuid mõned funktsioonid on teistest suuremad ja need tuleb jagada mitmeks osaks. Selleks jagatakse projekt tavaliselt nii, et:
- Funktsioonist saab verstapost (või verstapostid),
- Verstapost on ülesannete rühm,
- Ja ülesanne vastab funktsionaalsele üksusele (mitte tingimata funktsioon üldises koodibaasis).
Seejärel saate sellest tagasi liikuda, et näha, kuidas see väljalasele vastab:
- Ülesanne vastab tavaliselt kohustusele,
- Sisustuste komplekt vastab sildile,
- Silt vastab funktsiooni ühendamisele,
- Funktsioon vastab verstapostile.
Siinkohal peaks verstapost olema valmis lavastuskeskkonda juurutamiseks, et klient saaks seda hinnata vastavalt sellele, mis tal on (ja nõuetes) ja veenduda, et see on täidetud.
Siin tuleb mängu tagasisideahel. Kuid kõigepealt defineerin tagasisideahela lihtsalt järgmiselt:
Vestlus antud funktsiooni ümber, mis määrab, kas see on lõpetatud või nõuab rohkem tööd.
Kuigi teised räägivad palju üksikasjalikumalt. Ma kaldun siiski kõrvale.
Seega, oodates, kuni klient võtab viimase verstaposti osas uuesti ühendust, liigun mina või meie tavaliselt järgmise verstapostiga edasi. Seetõttu on oluline järjepidev viis vahe-eesmärkide, ülesannete ja tagasisidega töötamiseks (koos harudega allika juhtimise ja lavastuskeskkondades).
Alustage uue funktsiooni kallal töötamist pärast seda, kui olete viimase funktsiooni allika juhtimisele ja lavastamisele sidunud.
Kui kliendilt tagasiside tuleb, võtame tavaliselt tagasisidet, otsustame, mida saab teha ja mida mitte, ja seejärel koondame selle uude verstaposti. Mõnikord lisatakse verstapost lõppu; muul ajal lisatakse see järgmise prioriteetse üksusena. Kõik oleneb töö iseloomust, tagasisidest ja sellest, kuidas see projekti ulatusse sobib.
Rohkem kui funktsioone
Üldiselt on see vaid kõrgetasemeline vaade sellest, kuidas ma püüan funktsioonide arendusaspekte hallata. Kuid verstapostide, ülesannete ja tagasisideahelate vaatamine on oluline, sest kui see süsteem on paigas, loob see prognoositava viisi, kuidas teie ja meeskond saate lahendusi rakendada.
Lisaks loob see prognoositavuse tulemuste ja teie kliendiga suhtlemise osas ning see toimib eriti hästi ka korduvklientide puhul, kuna nad teavad, mida oodata.
Nagu paljude asjade puhul, millest kirjutan, ei püüa ma seda esitleda evangeeliumina, kuid usun, et mingi süsteemi olemasolu on oluline. Ma arvan, et keegi ei peaks kunagi projekti juhtima, kui see pole lihtsalt isiklik kõrvalprojekt.
Nii et olenemata valitud lähenemisviisist, kasutage vähemalt lähenemist.