Scope creep valódi ára: miért nem "csak még egy feature"
Minden "csak gyorsan még ez" kérés 3 másik dolgot tol el. Elmagyarázzuk a dominó-hatást, és azt, hogy hogyan dokumentáljuk a változást pénzben, nem érzelemben.
Nem a feature a drága, hanem az, hogy miatta 3 másik feature-t kell újratervezni.
A scope creep ritkán drámai. Senki nem kér 20 új funkciót egyszerre. Egy "csak még egy mező a formon", egy "legyen Excel export is", egy "ja, és a user tudja szerkeszteni is" — a maguk nemében apró dolgok. Összeadva viszont felborítják az architekturális döntéseket, és hetekkel tolják a határidőt. A baj nem a változtatás, hanem az, hogy nem érvényesítjük az árát.
A dominó, amit senki sem lát
Egy új szerkeszthető mező nem egy mező. Validáció, audit log, jogosultság, UI state, API mutation, optimistic update, error handling, teszt, migráció. Ha a mező összefügg egy másik modullal (pl. számlázás), akkor ott is touch pontok jönnek. A 30 perces módosításból 2 napos munka lesz. Ha ez 3x megtörténik egy sprintben, elveszítettél 6 napot — az a sprint fele.
Change request protokoll — papíron, mindig
- 1. Minden új kérést írásban dokumentálunk (email vagy a Nortinia Consulting App engagement-megjegyzés), szóbeli nem létezik
- 2. Becslés: órák, érintett modulok, tesztigény — az ügyfélnek látnia kell a teljes képet
- 3. Trade-off explicit: ha ez bejön, mi csúszik? — nem lehet csak hozzáadni, valaminek mennie kell
- 4. Ár és határidő: új sprint-módosítási megállapodás, aláírva (digitálisan elég)
- 5. Csak ezután dolgozunk — "majd utólag egyeztetjük" = garantált veszteség
A change request protokoll nem bürokrácia, hanem az egyetlen tanulási lehetőség. Ha az ügyfél minden héten 3 új kérést nyújt be, a kezdeti becslés hibás volt — a következő szerződésnél 1,5x puffert építünk be. Ha viszont ritkán kérnek változást, jó scope-olás volt, büszkélkedünk vele. A protokoll a mérőeszköz.
A "nem" szó nem ellenségeskedés. A "nem most" szó profi kommunikáció. Sokszor a "de akkor valami más csúszik" egyetlen mondat elég.