Kuinka hallitset projektin piiriin kuulumattomia lisäyksiä?

Question

Accepted Answer

**Piirin kutistuminen**, "vain yksi asia lisää" -ilmiön jatkuva kasaantuminen, on se, miten oikealla raidalla olevat projektit hiljaisesti kaatuvat. Ratkaisu ei ole sanoa ei kaikkeen; se on tehdä **jokaisesta lisäyksestä näkyvä, eksplisiittinen vaihtoehto** aikaa vastaan, hiljaisesti absorboinnin sijaan.

## Piirin hallinta

```text
✓ Define DONE up front — written, agreed scope
✓ Make the cost of every addition VISIBLE ("yes, and that pushes us a week")
✓ Track changes — a changelog of what got added/cut
✓ Protect a core MVP — defend the must-haves fiercely
✓ Use a PARKING LOT — capture good ideas for "later," don't reject them
✓ Escalate trade-offs to whoever owns priority — let them choose
```

## Keskeinen siirto

Älä hylkää uusia pyyntöjä suoraan, se tekee sinusta esteen. Tuo sen sijaan esiin vaihtoehto: "Voimme lisätä sen. Se tarkoittaa, että määräaika siirtyy viikkoa eteenpäin tai pudotamme ominaisuuden X. Mitä haluat?" Nyt se on *liiketoiminta*-päätös, jonka tekee oikea henkilö, silmät avoinna.

## Konkreettinen esimerkki

Projektin puolivälissä PM jatkaa pienien säätöjen lisäämistä. Aloitat jaetun piirin muutoslokin. Yhtäkkiä kaikki näkevät, että alkuperäinen kahden viikon projekti imeytti kolmen viikon lisäyksiä, ja keskustelu määräajasta tulee ilmeiseksi ja helpoksi.

## Miksi se on tärkeää

Hallitsematon piirin kutistuminen on määräaikojen hiljainen tappaja; mikään yksittäinen muutos ei tunnu suurelta, mutta ne yhdessä summautuvat epäonnistumiseksi.

Vaihtoehdoista tekeminen eksplisiitiksi pitää tiimin suojattuna, sidosryhmät informoituina ja syyllisyyden pois tekniikasta, kun piiri, ei ponnistus, oli syy.