Ang alitan sa pagitan ng mga tagapamahala ng produkto at mga inhinyero ay isa sa mga pinakanahuhulaang problema sa mga software team, at isa sa mga madalas na maling paghawak.
Pakiramdam ng mga PM na itinutulak ng mga inhinyero ang lahat nang hindi nag-aalok ng mga alternatibo. Pakiramdam ng mga inhinyero na ang mga PM ay nangangako sa mga deadline at saklaw nang hindi nauunawaan ang teknikal na kumplikado. Karaniwang tama ang magkabilang panig tungkol sa mga blind spot ng kabilang panig, at kadalasang pareho ang mali tungkol sa mga intensyon ng kabilang panig.
Bihirang ayusin ito ng karaniwang sprint ⟦RETROS⟧ dahil malamang na manatili sila sa loob ng mga hangganan ng koponan. Mga inhinyero na retro kasama ang mga inhinyero. Nag-debrief si PM sa mga PM. Naiipon lang ang cross-functional na tensyon hanggang sa pumutok ito sa isang planning meeting o isang napalampas na deadline.
Ang isang nakatuong product-engineering ⟦RETRO⟧ ay naglalagay ng parehong mga pananaw sa parehong silid na may istraktura na ginagawang produktibo ang pag-uusap sa halip na panlaban.
Ang Apat na Umuulit na Friction Point
Bago idisenyo ang ⟦RETRO⟧, nakakatulong itong pangalanan nang tapat ang mga tensyon. Sa karamihan ng mga team, nagku-cluster sila sa apat na kategorya.
1. Mga Kinakailangang Mukhang Malinaw ngunit Hindi
Nagsusulat ang isang PM ng spec na itinuturing nilang masinsinan. Binasa ito ng isang engineer at may labinlimang tanong. Pakiramdam ni PM ay nitpicking ang engineer. Pakiramdam ng engineer ay hindi pinag-isipan ni PM ang mga edge cases.
Ang ugat na isyu ay bihirang katamaran sa magkabilang panig. Iba ang iniisip ng mga PM at engineer tungkol sa mga produkto. Ang mga PM ay nag-iisip sa mga paglalakbay ng gumagamit at mga resulta ng negosyo. Ang mga inhinyero ay nag-iisip sa mga daloy ng data, pamamahala ng estado, at mga mode ng pagkabigo. Ang isang spec na kumpleto mula sa isang perspective ay puno ng gaps mula sa isa.
2. Bilis kumpara sa Kalidad
Panagot ang mga PM para sa pagpapadala sa oras. May pananagutan ang mga inhinyero kapag nasira ang mga bagay sa produksyon. Ang mga insentibong ito ay humihila sa magkasalungat na direksyon, at hindi mali ang alinman.
Lumalabas ang salungatan bilang mga debate tungkol sa pagputol ng saklaw, saklaw ng pagsubok, pagiging ganap ng pagsusuri ng code, at kung kukuha ng mga teknikal na shortcut. Kung walang tahasang pag-uusap tungkol sa mga tradeoff na ito, ipinapalagay ng bawat panig na ang isa ay walang pakialam sa kung ano ang mahalaga.
3. Teknikal na Utang
Nakikita ng mga inhinyero ang pag-iipon ng utang at gusto nila ng oras upang matugunan ito. Nakikita ng mga PM ang backlog ng mga feature na nakaharap sa user at nahihirapan silang bigyang-katwiran ang trabahong hindi nakikita ng mga customer. Ang resulta: ang utang ay ipinagpaliban hanggang sa magsimula itong magdulot ng mga insidente, kung saan ang lahat ay sumang-ayon na dapat itong nahawakan nang mas maaga.
4. Mga pagtatantya at Paghuhula
Kailangang ipaalam ng mga PM ang mga timeline sa mga stakeholder. Pinipigilan ng mga inhinyero ang pagbibigay ng mga pagtatantya dahil alam nila kung gaano kalaki ang kawalan ng katiyakan. Narinig ng PM ang "I don't want to commit" at narinig ng engineer na "just tell me what I want to hear." Wala alinman sa interpretasyon ay tumpak.
Pagse-set Up ng ⟦RETROC⟧
Patakbuhin itong quarterly o pagkatapos ng mga pangunahing release. Ang buwanan ay masyadong madalas -- ang mga pattern ay nangangailangan ng oras upang bumuo.
Sino ang dumadalo: Mga product manager, tech lead, at senior engineer. Panatilihin ang grupo sa 6-10 tao. Kung mas malaki ang grupo, magiging performative ang pag-uusap.
Tagal: 90 minuto. Ang cross-functional na ⟦RETROS⟧ ay mas matagal kaysa sa parehong-team dahil kailangan mo ng oras upang bumuo ng magkabahaging pag-unawa, hindi lamang lumalabas na mga isyu.
Pagpapadali: Gumamit ng isang neutral na facilitator, mas mabuti na isang taong hindi PM o isang engineer sa team. Ang isang engineering manager, isang scrum master, o isang tao mula sa ibang team ay gumagana nang maayos. Ang trabaho ng facilitator ay pigilan ang pag-uusap na maging debate at tiyaking maririnig ang magkabilang panig.
Isang Istraktura na Gumagana
Bahagi 1: Dual-Perspective Collection (20 minuto)
Hayaan ang mga PM at engineer na malayang sumulat ng mga card na sumasagot sa parehong tatlong senyas:
- Ano ang naging mahusay sa aming pakikipagtulungan ngayong quarter?
- Saan tayo pinabagal ng alitan?
- Ano ang gusto mong mas maunawaan ng kabilang panig?
Ang ikatlong prompt ay ang mahalaga. Nagpapakita ito ng mga pagpapalagay at pagkabigo na karaniwang nananatiling hindi nasasabi.
Kolektahin ang lahat ng card nang hindi nagpapakilala. Mahalaga ito -- sumusulat ang mga tao nang mas tapat kapag hindi nakalakip ang kanilang pangalan, lalo na tungkol sa mga cross-functional na tensyon.
Bahagi 2: Pagtalakay sa Tema (40 minuto)
Pangkatin ang mga card sa mga tema. Kasama sa mga karaniwan ang: kalinawan ng mga kinakailangan, proseso ng pagtatantya, mga pagpapasya sa priyoridad, mga puwang sa komunikasyon, at teknikal na pangangasiwa sa utang.
Para sa bawat tema, iwasan ang tuksong makipagdebate kung sino ang tama. Sa halip, itanong:
- Para saan ang pag-optimize ng bawat panig? (Kadalasan ang magkabilang panig ay may mga lehitimong layunin na nasa tensyon.)
- Saan nahuhulog ang handoff? (Karamihan sa alitan ay nangyayari sa mga hangganan sa pagitan ng mga tungkulin, hindi sa loob ng mga ito.)
- Anong impormasyon ang kulang sa bawat panig? (Maraming mga salungatan ay aktwal na mga impormasyong asymmetries in disguise.)
Bahagi 3: Mga Tukoy na Kasunduan (30 minuto)
Huwag umalis nang may malabong intensyon. Umalis nang may mga partikular na kasunduan sa pagtatrabaho na pinangako ng magkabilang panig.
Ang magagandang kasunduan sa pagtatrabaho ay:
- Mapapansin -- Masasabi mo kung nangyayari ang mga ito o hindi.
- Bilateral -- Ang magkabilang panig ay nagbabago ng isang bagay, hindi lamang ang isang panig na humihiling sa isa pa.
- Time-boxed -- Subukan ang mga ito para sa isang quarter at suriin.
Narito ang mga halimbawa ng mga kasunduan na malamang na gumana:
Para sa kalinawan ng mga kinakailangan: "Ang mga PM at tech na lead ay gugugol ng 30 minutong magkasama bago maibahagi ang anumang spec ng feature sa mas malawak na team, partikular na upang matukoy ang mga edge case at teknikal na mga hadlang."
Para sa pagtatantya: "Magbibigay ang mga inhinyero ng mga pagtatantya sa hanay (pinakamahusay na kaso / malamang / pinakamasamang kaso) sa halip na mga pagtatantya sa isang punto, at ipapaalam ng mga PM ang saklaw sa mga stakeholder sa halip na ang pinakamahusay na kaso lamang."
Para sa teknikal na utang: "Ang 20% ng bawat kapasidad ng sprint ay nakalaan para sa gawaing prioridad sa engineering. Hindi inilalaan ng mga PM ang kapasidad na ito at hindi kailangang bigyang-katwiran ng mga inhinyero ang mga indibidwal na item, ngunit ang mga inhinyero ay nagbabahagi ng quarterly na buod ng kung ano ang ginugol sa oras."
Para sa mga talakayan sa saklaw: "Kapag kailangang putulin ang saklaw, iminumungkahi ng PM kung ano ang puputulin at iminumungkahi ng engineer kung paano pasimplehin. Tinatalakay ang parehong mga opsyon bago magpasya."
Paghawak sa Mahirap na Pag-uusap
Patuloy na nakakadiskaril ang ilang paksa sa cross-functional ⟦RETROS⟧. Narito kung paano pangasiwaan ang mga ito.
"Wala kaming oras para sa teknikal na utang." Huwag makipagtalo kung mahalaga ang teknikal na utang. Sa halip, itanong: ano ang halaga ng kasalukuyang utang? Kung maaaring ituro ng mga inhinyero ang mga partikular na insidente, pagbagal, o karanasan ng developer na dulot ng utang, ang pag-uusap ay lumilipat mula sa abstract patungo sa kongkreto. Tumutugon ang mga PM sa data ng epekto, hindi sa mga abstract na apela para sa kalidad ng code.
"Patuloy na nagbabago ang mga kinakailangan." Nagbabago ang mga kinakailangan dahil nagbabago ang market, dumarating ang feedback ng user, at nagbabago ng mga priyoridad ang mga stakeholder. Ang tanong ay hindi kung magbabago ang mga kinakailangan, ngunit kung paano ipinapahayag ang mga pagbabago at kung gaano kahuli sa proseso ang pagdating ng mga ito. Tumutok sa proseso: sa anong punto ng pag-unlad dapat ituring na nagyelo ang saklaw? Ano ang escalation path para sa mga pagbabago pagkatapos ng puntong iyon?
"Palaging minamaliit ang pagtatantya ng engineering." I-flip ito: sinusubaybayan ba ng team ang katumpakan ng pagtatantya sa paglipas ng panahon? Kung hindi, magsimula. Pagkatapos ng ilang sprint ng data, lumilipat ang pag-uusap mula sa mga akusasyon patungo sa mga pattern. Marahil ay patuloy na minamaliit ng team ang isang partikular na uri ng trabaho (mga pagsasama, paglilipat) at tumpak sa iba. Naaaksyunan iyon.
"Hindi naiintindihan ng mga PM kung gaano ito kakomplikado." Madalas itong totoo, at trabaho rin ng engineer na gawing nakikita ang pagiging kumplikado. Kung sinabi ng isang engineer na "mahirap ito" at marinig ng PM na "mahirap ito," walang magbabago. Kung sinabi ng engineer na "nangangailangan ito ng mga pagbabago sa tatlong serbisyo, isang database migration, at may panganib ng downtime kung mabigo ang paglipat," maaaring mangatuwiran ang PM tungkol sa tradeoff.
Ano ang Mukhang Magandang Sa Paglipas ng Panahon
Pagkatapos ng tatlo o apat sa retrospective na ito, dapat mong makita ang mga kongkretong pagbabago:
- Mas kaunting mga sorpresa sa pagpaplano ng sprint dahil mas maagang nag-align ang mga PM at tech lead
- Mas matapat na pag-uusap tungkol sa mga tradeoff sa halip na mga passive-aggressive standoffs
- Binawasan ang muling paggawa dahil ang mga kinakailangan ay ginalugad mula sa parehong mga pananaw bago magsimula ang pag-unlad
- Patuloy na tinutugunan ang teknikal na utang sa halip na ipagpaliban hanggang sa magdulot ito ng krisis
- Ang mga pagtatantya ay nagiging mas tumpak dahil ang koponan ay nag-calibrate laban sa nakaraang pagganap
Ang layunin ay hindi alisin ang tensyon sa pagitan ng produkto at engineering. Ang ilang pag-igting ay malusog -- nangangahulugan ito na ang magkabilang panig ay nagtataguyod para sa kung ano ang mahalaga. Ang layunin ay gawing produktibo ang pag-igting na iyon sa halip na nakakasira.
Subukan ang NextRetro nang libre -- I-facilitate ang cross-functional na retrospective gamit ang anonymous na koleksyon ng card at structured discussion workflows.
Huling Na-update: Pebrero 2026
Oras ng Pagbasa: 7 minuto
