Alisin ang dobleng gawain sa proyekto sa pamamagitan ng paghahambing sa layuning makamit ng mga inisyatiba, hindi lamang sa mga pamagat ng mga ito. Gawing nakikita ang aktibong gawain, tukuyin ang magkakaparehong user at resulta, at pagpasiyahan kung pagsasamahin, gagamitin muli, pag-uugnayin, o sadyang paghihiwalayin ang mga pagsisikap. Pagkatapos, magtalaga ng isang may pananagutan para sa anumang pinagsasaluhang deliverable.
Hindi sagot ang listahan ng bawat gawain sa kompanya. Kailangan ng mga team ng sapat na tanaw upang matukoy ang makahulugang pag-uulit bago magsimula ang malaking gawain, kasama ng magaang paraan upang lutasin ito. Maaaring ipalit ng sentral na pila ng pag-apruba para sa bawat maliit na gawain ang paghihintay sa halip na pag-uulit.
Nag-aalok ang gabay na ito ng praktikal na paraan ng koordinasyon, hindi ng ipinapalagay na pamantayan sa industriya. Tinutukoy ng gabay ng ASQ sa pagmamapa ng proseso ang dobleng gawain at mga paglilipat bilang kapaki-pakinabang na susuriin sa workflow. Dito, inisyatiba o deliverable ang sinusuri kapag lumilitaw ito sa gawain ng mahigit sa isang team.
Ihiwalay ang pag-uulit sa kapaki-pakinabang na sabayang gawain
Hindi nangangahulugang nagsasayang ng pagsisikap ang dalawang team na gumagawa ng magkakatulad na output. Maaaring magkaiba ang mga user, kondisyon ng pagtanggap, o palagay na sinusubukan nang hiwalay dahil mapanganib ito. Ang tanong ay kung mapananatili ng pagsasama ng gawain ang nilalayong halaga.
Gayundin, hindi palaging mas mura ang iisang pinagsasaluhang bahagi. Maaaring mangailangan ito ng koordinasyon, kompromiso, pagpapanatili, o pahintulot na hindi kinailangan ng alinman sa orihinal na team. Paghambingin ang kabuuang gastos at mga bunga ng pagbabahagi sa gastos ng magkakahiwalay na solusyon.
Hanapin muna ang maiiwasang pag-uulit: parehong pagsasaliksik sa customer na isinagawa nang dalawang beses; dalawang dashboard na sumasagot sa iisang tanong sa operasyon; paulit-ulit na paglilinis ng datos dahil hindi naibahagi ang pinagkakatiwalaang resulta; dalawang integration na binuo para sa iisang serbisyo nang walang koordinasyon. May kongkretong output na maihahambing ang mga halimbawang ito.
Huwag ituring na duplicate na proyekto ang bawat paulit-ulit na pulong o lokal na checklist. Maaaring kailangan ng team ang sarili nitong pagninilay at proseso ng pasya kahit tinatalakay ng ibang team ang katulad na paksa. Gumamit ng agile retrospective upang suriin ang mga problema sa koordinasyon nang hindi isinasentralisa ang lahat ng usapan.
Bumuo ng maliit na talaan ng pag-uulit
Humingi sa bawat team ng maikling paglalarawan ng mga aktibong inisyatiba at malapit nang mapagpipilian. Gamitin ang kasalukuyang talaan ng pagpaplano kung maaari. Dapat tumuro ang talaan sa opisyal na gawain, hindi lumikha ng panibagong backlog na kailangang panatilihin.
| Field | Bakit nakatutulong |
|---|---|
| Nilalayong resulta | Nagpapakita ng magkakatulad na gawain sa magkakaibang pangalan |
| Mga user o tatanggap | Nagpapakita kung talagang nagtatagpo ang mga pangangailangan |
| Deliverable | Tinutukoy ang output na magagamit muli |
| Kondisyon ng pagtanggap | Naglalantad ng mahahalagang pagkakaiba |
| May-ari ng gawain | Nagbibigay ng taong makokontak ng ibang team |
| Kasalukuyang yugto | Nagpapakita kung posible pang pagsamahin ang gawain |
| Dependency | Naglalantad ng pinagsasaluhang serbisyo o espesyalista |
| Pinagmulang tala | Pumipigil sa pagkakaroon ng magkatunggaling kopya ng katayuan ng proyekto |
Limitahan ang paunang audit sa tinukoy na lugar, gaya ng isang departamento o kaugnay na hanay ng mga workstream. Maaaring maluma ang katalogo ng buong kompanya bago ito maging kapaki-pakinabang. Magsimula kung saan nagpapahiwatig ng totoong pag-uulit ang paulit-ulit na kahilingan, pinagsasaluhang dependency, o agawan sa yaman.
Iwasang kopyahin sa talaan ang sensitibong detalye ng customer. Layunin nitong madaling matuklasan ang gawain, hindi bigyan ang lahat ng malawak na access sa bawat pinagbabatayang rekord. Kung kailangan, maglagay ng link sa ebidensiyang may wastong kontrol sa access.
Mag-usap tungkol sa pag-uulit at pumili sa apat na kinalabasan
Kapag magkahawig ang dalawang inisyatiba, tipunin ang mga may-ari nito kasama ng taong nakauunawa sa pagtanggap. Paghambingin ang problema, populasyon, output, at mga limitasyon. Itanong kung ano ang mawawala kung iisang pagsisikap na lamang ang magpapatuloy.
Pumili ng isa sa apat na kinalabasan:
- Pagsamahin: Matutugunan ng iisang deliverable ang dalawang pangangailangan, na may malinaw na may-ari at pinagsasaluhang pagtanggap.
- Gamitin muli: Magagamit ng isang team ang kasalukuyang output nang kaunti lamang ang pag-aangkop.
- I-coordinate: Kailangan pa rin ang magkakahiwalay na output ngunit maaaring paghati-hatian ang pananaliksik, dependency, o oras.
- Sadyang panatilihing magkahiwalay: Binibigyang-katwiran ng mga pagkakaiba ang magkahiwalay na gawain; itala kung bakit at kailan ito muling susuriin.
Mga pagpipilian sa pasya ang mga ito, hindi ranggo ng kahusayan. Hindi awtomatikong pinakamainam ang pagsasama. Kapaki-pakinabang ang paglipat mula sa aksidenteng pagkadiskubre ng pag-uulit pagkatapos ng paghahatid tungo sa sinasadyang pagtimbang sa trade-off.
Itala kung sino ang magpapanatili sa resulta. Maaaring magdulot ng mas maraming dobleng gawain sa hinaharap ang pinagsasaluhang asset na walang team na nagpapanatili rito, dahil gagawa ng kapalit ang bawat gumagamit kapag hindi na natutugunan ng orihinal ang mga pangangailangan.
Halimbawang may paliwanag: dalawang dashboard ng escalation
Isipin ang isang kathang-isip na team ng suporta na gumagawa ng dashboard ng mga hindi pa nalulutas na escalation. Gumagawa naman ang team ng operations engineering ng ulat na kapareho ang pangalan. Una, hinihiling ng pamunuan na kanselahin nila ang isa sa mga gawain.
Paghahambingin ng mga may-ari ang mga kondisyon ng pagtanggap. Kailangang matukoy ng suporta ang mga kaso ng customer na walang may pananagutan. Kailangang siyasatin naman ng engineering ang paulit-ulit na palya ng serbisyo sa iba’t ibang insidente. Magkahawig ang mga label ngunit magkaiba ang operasyonal na tanong.
Nakakita ang mga team ng bahaging magagamit muli: pareho silang nangangailangan ng maaasahang pagtutugma sa pagitan ng mga identifier ng kaso at pangalan ng serbisyo. Magkakasundo silang pananatilihin ng operations engineering ang pagtutugmang iyon habang pananatilihin ng bawat team ang sariling ulat. Iko-coordinate nila ang mga depinisyon ng datos at iiwasang ulitin ang pagkuha nito.
Pag-gamit-muli na may koordinasyon ang resulta, hindi sapilitang pagsasanib. Inimbento ang halimbawa upang ilarawan ang pasya. Hindi nito pinatutunayang dapat paghiwa-hiwalayin ang bawat pares ng dashboard o laging nalulutas ng pinagsasaluhang datos ang pag-uulit.
Pigilan ang pag-uulit sa pagpasok pa lamang ng gawain
Magdagdag ng maikling pagsusuri sa pagtanggap ng inisyatiba: “May umiiral na bang kaugnay na gawain, at sino ang nakonsulta?” Mabilis na paghahanap at pag-uusap lamang ang kailangan nito sa karaniwang gawain. Maaaring mangailangan ng pormal na pagsusuri ang malalaking pangako sa iba’t ibang team.
Gumamit ng magkakatugmang paglalarawan ng resulta at malinaw na may-ari. Maaaring hindi makita sa paghahanap ng malawak na pamagat ng proyekto ang gawaing nakatago sa panloob na codename. Isama sa tala ang problema ng user upang mahanap ito ng mga tao nang hindi alam ang bokabularyo ng organisasyon.
Suriin ang mga paulit-ulit na kahilingan sa shared workshop board. Itala ang pag-uulit at mga pasya, saka mag-link pabalik sa karaniwang tracker ng team. Huwag sabihing awtomatikong nakakakita ng duplicate o nagsi-synchronize ng mga sistema ng proyekto ang board.
Pagkaraan ng ilang siklo ng koordinasyon, siyasatin kung nakatutulong ang talaan. Mas maaga bang nahanap ng mga team ang kasalukuyang gawain? May nagpapanatili ba sa mga pinagsasaluhang asset? Nagdulot ba ang koordinasyon ng pagkaantala na hindi proporsiyonal sa pakinabang? Pumili ng format mula sa mga ideya para sa retrospective upang suriin ang totoong kaso.
Suriin ang pasya, hindi inimbentong kabuuan ng matitipid
Huwag mag-ulat ng “mga oras na natipid” sa pagbabawas ng magagaspang na pagtataya na para bang sinukat na resulta ang mga iyon. Itala ang itinigil, ginamit muli, o binagong gawain at lagyan ng label bilang pagtataya ang mga tantiya. Kung may ebidensiya, paghambingin sa paglipas ng panahon ang pasanin sa pagpapanatili at mga resulta ng paghahatid.
Suriin din kung nakapinsala ang pagsasama-sama. Kung nagiging sobrang bigat na bottleneck ang iisang pinagsasaluhang team, maaaring magmukhang matagumpay ito sa katalogo habang pinatatagal ang gawain ng lahat. Suliraning dapat unawain ang parehong duplicate na gawain at labis na dependency.
Mga madalas itanong
Paano namin mahahanap ang dobleng gawain kung magkakaibang tool ang gamit ng mga team?
Gumamit ng maliit na pinagsasaluhang talaan ng mga resulta, deliverable, may-ari, at link sa pinagmulan. Panatilihin ang detalyadong katayuan sa opisyal na sistema ng bawat team. Dapat nitong gawing madaling matuklasan ang pag-uulit, hindi kopyahin ang bawat gawain.
Dapat bang palaging pagsamahin ang magkahawig na proyekto?
Hindi. Paghambingin ang mga user, pagtanggap, limitasyon, at pagpapanatili. Maaaring burahin ng pagsasama ang mahahalagang pagkakaiba o magdagdag ng gastos sa koordinasyon. Katanggap-tanggap din ang muling paggamit at koordinadong magkahiwalay na paghahatid.
Sino ang dapat magmay-ari ng pinagsasaluhang deliverable?
Pumili ng team o taong may awtoridad at kapasidad na magpanatili nito, at linawin ang mga responsibilidad ng mga gagamit. Hindi plano sa pagpapanatili ang pinagsasaluhang interes na walang malinaw na may-ari.