Pigilan ang paglawak ng saklaw sa pamamagitan ng paglilinaw sa mga hangganan ng proyekto at mga pasya sa pagbabago. Tukuyin ang resulta, mga kasamang deliverable, mga hindi kasama, at mga kondisyon ng pagtanggap. Kapag may bagong kahilingan, itala ang halaga nito at ang epekto sa pagsisikap, dependency, gastos, at oras bago ito tanggapin. Normal ang pagbabago; problema ang paglawak nang hindi sinusuri.
Maaaring maging flexible ang team habang kinokontrol ang saklaw. Pinoprotektahan ng pagtanggi sa bawat bagong ideya ang lumang plano. Itinatago naman ng pagtanggap sa bawat kahilingan ang ibang pagkabigo: unti-unting nagbabago ang proyekto ngunit hindi nagagalaw ang orihinal nitong palagay sa deadline at kapasidad.
Ibinubukod ng papel ng PMI tungkol sa paglawak ng saklaw ang awtorisadong pagbabago sa proyekto at ang dagdag na trabahong ipinapasok nang walang wastong pahintulot o pagsasaalang-alang sa mga bunga. Iniaangkop ng mga praktikal na gawain sa ibaba ang pagkakaibang iyon sa maliliit na kolaboratibong team.
Tukuyin ang hangganang madaling makilala ng mga tao
Sinasagot ng kapaki-pakinabang na pahayag ng saklaw ang apat na tanong: Anong resulta ang sinusubukan nating makamit? Ano ang gagawin natin? Ano ang sadyang hindi natin isasama? Anong ebidensiya ang magpapakitang katanggap-tanggap ang napagkasunduang gawain?
Nag-iiwan ng puwang para sa magkakasalungat na inaasahan ang “Gumawa ng reporting dashboard.” Mas malinaw ang: “Bigyan ang mga pinuno ng suporta ng lingguhang tanaw sa mga hindi pa nalulutas na escalation gamit ang kasalukuyang datos ng ticket. Isama ang tagal sa pila at may-ari. Huwag isama ang pagtataya, datos sa pagsingil, at real-time na alerto. Para sa pagtanggap, kailangang itugma ng pinangalanang pinuno ang sample at mga pinagmulang tala.”
Hindi inaalis ng dagdag na detalye ang kawalang-katiyakan. Nagbibigay ito sa team ng pinagsasaluhang batayan sa pagpapasya kung pasok ang kahilingan. Itago ang hangganan kung saan karaniwang sinusuri ng mga tao ang mga pasya sa proyekto. Hindi mabisang kontrol ang dokumento ng saklaw na hindi makita.
Pag-ibahin ang mga inaasahan sa kalidad at mga opsiyonal na dagdag. Hindi awtomatikong bagong feature ang depektong pumipigil sa napagkasunduang pagtanggap. Sa kabilang banda, hindi nagiging bahagi ng orihinal na kasunduan ang kakayahang walang kaugnayan dahil lamang tinawag itong “maliit na pag-aayos.”
Gumamit ng magaang kahilingan para sa pagbabago
Hindi kailangan ng maliit na team ng komite para sa bawat paglilinaw. Kailangan nito ng nakikitang pasya kapag binabago ng kahilingan ang mga pangako. Gumamit ng maikling talaan:
| Field | Itatala |
|---|---|
| Kahilingan | Ang pinakamaliit na kongkretong pagbabagong iminumungkahi |
| Dahilan | Suliranin ng user, obligasyon, o bagong ebidensiya |
| Kaugnayan sa saklaw | Paglilinaw, pagwawasto, pagpapalit, o dagdag |
| Mga bunga | Gawain, dependency, gastos, panganib, at oras |
| Trade-off | Ano ang ihihinto, liliitan, ililipat, o bibigyan ng dagdag na kapasidad |
| Pasya | Tanggapin, siyasatin, ipagpaliban, o tanggihan |
| Awtoridad | Sino ang maaaring gumawa ng pasyang ito |
| Na-update na batayan | Saan itatala ang binagong pangako |
Humingi ng pagtatayang proporsiyonal sa pasya. Hindi dapat mangailangan ng detalyadong business case ang kalahating araw na pagbabago ng pananalita. Kailangan ng mas malalim na pagsusuri ang kahilingang magsama ng bagong data source kahit maliit lamang ang nakikitang interface.
Makakatulong ang shared workshop board upang linawin ng grupo ang mga kahilingan at trade-off. Panatilihin ang opisyal na saklaw, iskedyul, at mga pangakong pinansiyal sa mga sistemang ginagamit ng organisasyon para sa mga iyon.
Halimbawang may paliwanag: nagiging integration ang isang dagdag na chart
Isaalang-alang ang isang kathang-isip na team na gumagawa ng support dashboard na inilarawan sa itaas. Humihiling ang isang stakeholder ng “isa pang chart” na nagpapakita ng halaga ng mga apektadong account ng customer. Mukhang simple mismo ang chart. Nasa hiwalay na sistema ng pagsingil ang datos nito, may ibang identifier at limitasyon sa access.
Inuuri ng team ang kahilingan bilang dagdag, hindi kosmetikong pagpapahusay. Natutukoy nito ang gawaing integration, pag-apruba sa access ng datos, pagtutugma, at tuloy-tuloy na responsibilidad sa pagpapanatili. Sinusuri rin nito kung kailangan ba talaga ng orihinal na resulta para sa suporta ang chart.
May tatlong opsiyon ang tagapagpasya: panatilihin ang orihinal na saklaw at ipagpaliban ang chart; palitan ng integration ang deliverable na mas mababa ang halaga; o dagdagan ang yaman at oras. Pinipili ng team ang pagpapaliban at nagtatala ng muling pagsusuri matapos magamit ng mga pinuno ng suporta ang unang ulat.
Halimbawa lamang ito. Hindi nito sinasabing laging pinakamainam ang pagpapaliban. Mahalaga na makita ng grupo ang tunay na pagpili sa halip na hilingin sa team na tahimik na akuin ang trabahong hindi nakikita.
Linawin kung sino ang maaaring tumanggap ng pagbabago
Karaniwang pagkabigo ang watak-watak na awtoridad. Nangangako ang sales ng kakayahan, humihiling ng pagbabago ang stakeholder, at ipinapatupad ito ng developer upang tumulong. Walang nakakakita sa pinagsamang epekto. Tukuyin kung sino ang maaaring mag-apruba ng pagbabago sa resulta, badyet, petsa ng paghahatid, at teknikal na paraan.
Sa Scrum, pinapahintulutan ng Scrum Guide ang paglilinaw at muling pakikipagkasundo sa saklaw kasama ng Product Owner habang may bagong natututuhan, kasabay ng pagpapanatili sa layunin ng Sprint. Iba ito sa pagtrato sa Sprint Backlog na para bang walang kondisyong kontrata ng feature o pagpapahintulot sa sinumang stakeholder na direktang magsingit ng gawain.
Para sa ibang paraan ng paghahatid, gamitin ang angkop na tungkuling may pananagutan. Pareho ang prinsipyo: kailangan ng malinaw na paraan ng pagkuha ng pasya ang mga gumagawa ng trabaho, at kailangang malaman ng tagapagpasya ang totoong mga bunga. Dapat magbunsod ng pag-uusap tungkol sa trade-off ang “gawin na lang,” hindi tahimik na pangako.
Bantayan ang mga maagang palatandaan sa halip na manisi sa dulo
Tingnan kung dumarami ang kondisyon ng pagtanggap, nauulit ang gawain sa labas ng nakikitang backlog, nadidiskubre ang mga bagong tagasuri, o nananatiling nakapirmi ang petsa ng paghahatid habang dumarami ang dependency. Walang isang palatandaang nagpapatunay agad ng paglawak ng saklaw. Bawat isa ay hudyat upang siyasatin kung ano ang nagbago at kung ipinakikita iyon ng plano.
Maikling suriin ang mga tinanggap na pagbabago sa karaniwang pagpaplano. Ihambing ang kasalukuyang saklaw sa naunang bersiyon. Kung hindi maipaliwanag ng team kung bakit naisama ang gawain, ayusin muna ang tala ng mga pasya bago gumawa ng dagdag na pag-uulat.
Gumamit ng agile retrospective upang suriin kung paano hinarap ang mga pagbabago: Aling kahilingan ang lumampas sa mga pasya? Aling pagtataya ang hindi nagsama ng koordinasyon? Aling hindi kasama ang namali ng pagkaunawa? Ituon sa sistemang nagpadali sa nakatagong paglawak, saka pumili ng isang pagpapahusay.
Huwag sukatin ang tagumpay sa dami ng tinanggihang kahilingan. Maaaring maghatid nang eksakto sa plano ang team na tumanggi sa mahahalagang pagbabago ngunit maling bagay naman ang maihatid. Mas mahusay na ebidensiya kung may malinaw na dahilan, makatotohanang trade-off, at na-update na pangako ang mga tinanggap na pagbabago.
Mga madalas itanong
Kapareho ba ng pagbabago ng mga requirement ang paglawak ng saklaw?
Hindi. Maaaring magbago ang mga requirement dahil sa lehitimong pagkatuto at tahasang mga pasya. Tumutukoy ang paglawak ng saklaw sa pagdagdag na lumalampas sa wastong kasunduan o hindi tinutugunan ang mga bunga. Ang pagkakaiba ay kung paano sinusuri at isinasama ang pagbabago.
Paano kami tatanggi sa maliit na kahilingan ng stakeholder?
Unawain muna ang halaga at totoong mga bunga nito. Ipaliwanag ang mga posibleng trade-off: tanggapin kapalit ng ibang gawain, ipagpaliban, siyasatin, o baguhin ang oras at kapasidad. Huwag sabihing maliit ang kahilingan bago suriin ang mga dependency.
Maaari bang gumamit ng change control ang agile team?
Oo, kung sinusuportahan nito ang pag-aangkop sa halip na hadlangan ito. Panatilihing malinaw ang mga pasya sa produkto, pagpaplano ng team, at mga pangako. Kadalasang sapat ang magaang na naitalang pag-uusap para sa maliit na pagbabago; kailangan ng wastong awtoridad ang malalaking pangako.