Gawain ang pagmamapa ng proyekto para gawing malinaw ang mahahalagang ugnayan sa isang proyekto: paano nag-uugnay ang trabaho sa resulta, aling mga deliverable ang umaasa sa iba, sino ang nag-aambag, at saan kailangan pa ng mga pasiya. Hindi iisang unibersal na diagram ang tinutukoy ng termino. Piliin ang mapa ayon sa tanong na kailangan ninyong sagutin.
Kapaki-pakinabang ang project map kapag nakapaglilista ng mga gawain ang mga tao pero hindi maipaliwanag kung paano magkakaugnay ang mga iyon. Maaari rin nitong ilantad na magkaibang resulta ang inaasahan ng dalawang team kahit pareho ang pangalan nila sa proyekto. Naipakikita ng mapa ang hindi pagkakasundong iyon bago bigyan ng maling katiyakan ng detalyadong iskedyul.
Piliin ang mapa ayon sa pasiya
| Tanong | Kapaki-pakinabang na mapa | Hindi nito pinapalitan |
|---|---|---|
| Bakit natin ginagawa ang trabahong ito? | Mapa mula resulta tungo sa deliverable | Ebidensiyang mahalaga ang resulta |
| Ano ang dapat mangyari bago ang iba? | Mapa ng mga dependency | Pinananatiling iskedyul at plano ng mapagkukunan |
| Sino ang kailangang mag-ambag? | Mapa ng stakeholder o tungkulin | Aktuwal na pakikibahagi at tinanggap na pagmamay-ari |
| Paano dumadaloy ang trabaho sa proseso? | Mapa ng proseso o workflow | Pagmamasid sa mga eksepsiyon at aktuwal na gawain |
| Ano ang saklaw ng proyekto? | Mapa ng saklaw | Proseso ng pagpapasiya sa mga pagbabago |
Huwag pagsamahin ang bawat tanawin sa iisang canvas. Maaaring mas mahirap gamitin ang diagram na may napakaraming uri ng palaso kaysa maliit na hanay ng magkakaugnay na tala. Magsimula sa tanong na nagdudulot ng di-katiyakan.
Tukuyin ang resulta bago imapa ang mga deliverable
Isulat sa isang pangungusap ang nilalayong pagbabago. Pagkatapos, ihiwalay ang mga resulta sa mga output. Output ang naihatid na form, serbisyo, o ulat. Resulta ang kapaki-pakinabang na pagbabago sa kayang gawin ng isang tao at kailangan nito ng ebidensiya.
Inirerekomenda ng gabay ng GOV.UK sa discovery na unawain ang mas malawak na user journey at ang mga team o serbisyong nakapaligid sa problema. Mahalaga itong konteksto para imapa ang hangganan ng proyekto; hindi nito iniuutos ang partikular na mapping workshop sa ibaba.
Itanong kung aling mga output ang makatwirang susuporta sa resulta. Kung walang malinaw na ugnayan ang workstream, maaaring mahalagang pantulong na gawain ito, hindi pa nasusubok na palagay, o hindi kailangang saklaw. Lagyan ng label ang ugnayan bago magpasiyang panatilihin o alisin ito.
Buuin ang unang project map sa limang pagdaan
- Ilagay sa itaas ang resulta. Isama ang grupong apektado at senyas na susuriin.
- Idagdag ang mga pangunahing deliverable. Gumamit ng makikitang resulta sa halip na pangalan ng aktibidad gaya ng “gumawa sa integration.”
- Pag-ugnayin ang mga dependency. Lagyan ng label kung ano ang kailangan ng isang item mula sa iba.
- Idagdag ang mga may-ari at pasiya. Ipakita kung sino ang nag-uugnay sa bawat resulta at aling pagpili ang bukas pa.
- Markahan ang kawalang-katiyakan. Ihiwalay ang kumpirmadong ugnayan sa mga palagay na nangangailangan ng ebidensiya.
Iwasan ang mga petsa sa unang pagdaan maliban kung tunay na limitasyon ang mga iyon. Maaaring pumihit sa usapan ang maagang petsa bago maunawaan ang saklaw at dependency. Idagdag ang tiyempo kapag sapat na ang linaw ng mga ugnayan para suportahan ito.
Kumpletong halimbawa: pagpapabago ng account nang mag-isa
Hipotetikal na halimbawa: gusto ng team na makumpleto ng mga customer ang karaniwang pagbabago sa account nang walang handoff sa support. May interface design, API work, help content, analytics, at anunsiyo ng paglulunsad sa unang listahan nito ng gawain.
Inilalantad ng mapa ng resulta ang nawawalang gawain. Nakasalalay ang API sa pasiya kung sino ang awtorisadong humiling ng pagbabago. Nakasalalay ang help content sa pag-unawa sa mga eksepsiyon. Nakasalalay ang kahandaan ng support sa kaalaman kung aling kaso ang hindi saklaw ng self-service.
Tahasan na iginuguhit ng team ang tatlong ugnayan:
| Resulta | Nakasalalay sa | Kailangang pasiya o ebidensiya |
|---|---|---|
| Magagamit na daloy ng pagbabago sa account | Tuntunin sa awtorisasyon | Kumpirmahin kung sino ang maaaring magbago |
| Malinaw na ruta para sa eksepsiyon | Mga alam na kasong hindi sinusuportahan | Suriin ang mga kinatawang edge case |
| Pagsukat sa resulta | Tinukoy na kaganapan ng pagkumpleto | Pagkasunduan kung ano ang bibilangin na tapos na gawain |
Binabago nito ang agarang plano. Sa halip na sabay-sabay simulan ang lahat ng workstream, nilulutas muna ng team ang usapin sa awtorisasyon at sinusuri ang mga eksepsiyon. Maaari pa ring magpatuloy ang paggalugad sa interface, pero lalagyan ito ng label na pansamantala.
Hindi pinatutunayan ng mapa kung aling implementasyon ang pinakamahusay. Ipinakikita nito kung aling mga pasiya ang nakaaapekto sa ilang bahagi ng trabaho at samakatuwid ay nangangailangan ng maagang atensiyon.
Gawing makabuluhan ang mga palaso ng dependency
Lagyan ng label ang bawat palaso ayon sa ambag: pasiya, data, kapaligiran, pagsusuri, interface, o kakayahan sa operasyon. Hindi paglalarawan ng dependency ang “Team B.” Ang “Kinukumpirma ng Team B ang tuntunin sa may-ari ng account” ay paglalarawan.
Para sa mga panlabas na dependency, itala kung hiniling o tinanggap na ang ambag. Hindi makalilikha ng commitment para sa ibang team ang inyong mapa. Tukuyin ang contact, huling kapaki-pakinabang na petsa, at mangyayari kapag nagbago ang ambag.
Ihiwalay ang lohikal na dependency sa gustong pagkakasunod-sunod. Maaaring magkasunod sa iskedyul ang dalawang item dahil iisang tao ang gumagawa sa mga ito kahit hindi naman teknikal na nakasalalay ang isa sa iba. Mahalaga ang pagkakaibang iyon kapag naghahanap ng alternatibo ang team.
Magdaos ng 45-minutong workshop sa pagmamapa ng proyekto
Magsimula sa limang minutong tahimik na pagbasa sa project brief. Gumugol ng sampung minuto sa pagpapasulat nang magkakahiwalay sa mga kalahok ng pangunahing output. Paghambingin ang mga listahan bago pag-ugnayin ang mga ito; maaaring ilantad ng mga pagkakaiba ang palagay sa saklaw na hindi pa nalulutas.
Gamitin ang labinlimang minuto sa pagguhit at paglalagay ng label sa mga ugnayan. Maglaan ng sampung minuto para kuwestiyunin ang mga palagay na may pinakamalaking bunga at limang minuto para magtalaga ng susunod na hakbang sa ebidensiya o pasiya.
Magtabi ng lugar para sa detalyeng hindi nagbabago sa layunin ng mapa. Maaari pang gawin sa sistema ng delivery ng team ang kumpletong breakdown ng implementasyon. Dapat matapos ang workshop nang mas malinaw ang susunod na pasiya, hindi lang mas malaki ang canvas.
Hilingin sa taong magpapatakbo sa resulta na suriin ang mapa. Itanong kung ano ang maaaring pumalya sa unang araw pagkatapos ng paglulunsad. Maaaring lumitaw sa tanong na iyon ang gawaing suporta, monitoring, handoff, at maintenance na wala sa larawang nakatuon sa delivery.
Gawing pinananatiling plano ang mapa
Pumili ng opisyal na lugar para sa mapa at itala ang petsa at may-ari nito. I-link ang mga deliverable sa work tracker sa halip na kopyahin ang bawat gawain sa diagram. Itago sa decision log ang mahahalagang pasiya kasama ang katuwiran at may-ari.
I-update ang mapa kapag nagbago ang hangganan, dependency, o palagay. Nagiging lumang larawan ang mapang gamit lang sa kickoff. Naipapaliwanag ng pinananatiling mapa kung bakit naiiba sa orihinal ang kasalukuyang plano.
Gumamit ng agile retrospective para suriin kung paano nakikipag-ugnayan ang team batay sa mapa. Itanong kung aling dependency ang nahuling nakita o aling output ang walang maikabit sa resulta. Mangolekta ng obserbasyon sa simpleng format ng retrospective, saka subukan ang isang pagpapahusay sa pamamagitan ng proseso ng follow-up mula sa retrospective.
Mga pagkakamaling nakalilinlang sa project map
Mga departamento lang ang imapa. Maaaring itago ng label ng departamento ang aktuwal na pasiya, impormasyon, o serbisyong kailangan. Tukuyin ang ambag.
Ituring na iskedyul ang mapa. Nakakatulong sa pagpaplano ang mga ugnayan pero hindi nila itinatakda ang tagal, availability, o kumpiyansa sa petsa.
Ipakita bilang matibay na katotohanan ang bawat palagay. Gumamit ng tahasang label at listahan ng hakbang sa ebidensiya. Huwag hayaang burahin ng magandang itsura ang kawalang-katiyakan.
Isama ang bawat posibleng detalye. Iayon ang mapa sa tanong nito. Kung hindi makita ng mambabasa ang susunod na pasiya, hatiin ang tanawin o alisin ang detalyeng dapat nasa ibang lugar.
Mga madalas itanong
Kapareho ba ng mind mapping ang pagmamapa ng proyekto?
Makakatulong ang mind map sa pagbuo ng mga ideya tungkol sa paksa. Karaniwang nangangailangan ang project map ng tahasang ugnayan gaya ng ambag, dependency, pagmamay-ari, o saklaw para suportahan ang mga pasiya sa delivery.
Maaari bang ipalit ang project map sa project plan?
Maaari nitong suportahan at pasimplehin ang pagpaplano, pero hindi nito pinapalitan ang kinakailangang iskedyul, pasiya sa mapagkukunan, pamamahala sa panganib, o mga tala ng pamamahala. Gamitin ito para ipaliwanag ang mga ugnayang pinagbabatayan ng mga tala na iyon.
Ano ang dapat naming imapa muna kapag hindi malinaw ang proyekto?
Magsimula sa problema, grupong apektado, at nilalayong resulta. Kung pinagtatalunan ang mga iyon, siyasatin muna bago gumawa ng detalyadong mapa ng mga ipinapalagay na deliverable.