A hat hét korlát, nem dicsekvés
Amikor azt mondjuk, hogy egy termék hat hét alatt élesbe megy, a hat hét végzi az igazi munkát. A nyitott végű határidő nyitott végű scope-ot szül; a rögzített viszont kikényszeríti a kérdést, amelyre minden fiatal terméknek válaszolnia kell: mi az az egyetlen kör, amit a felhasználónak az első naptól végig kell tudnia csinálni?
Ezért a határidőt és a scope-ot együtt, írásban rögzítjük, még az első kódsor előtt. A határidő nem egy ködös tervre rácsavarozott ígéret. Ez az az eszköz, amelytől a terv konkréttá válik.
Nulladik hét: vágni, amíg fáj
Mielőtt a build elindul, vágunk. Admin dashboardok, beállítás-képernyők, jogosultsági rendszerek, ötféle bejelentkezés: ezekből szinte semmi nem való az első kiadásba, és mindegyik azzal az egy folyamattal versenyez, amely ténylegesen bizonyítja a terméket.
A scoping kimenete két lista: a mag-kör, amit az MVP-nek hoznia kell, és a parkolópálya mindazzal, amire tudatosan mondtunk nemet, egyelőre. Mindkét lista bekerül az írásos ajánlatba, így a "ez benne van a scope-ban?" kérdésre mindig van válasz papíron.
A stack, amitől ez lehetséges
Egy szenior mérnök, egy cross-platform kódbázis és menedzselt infrastruktúra. Amikor a ChildLinket, a saját társszülő appunkat építettük, egy Flutter kódbázis ment mindkét app store-ba, a Firebase pedig kiváltott egy backendet, amely különben heteket evett volna meg: a Firestore valós időben tartotta szinkronban a két háztartást, megírandó szerver nélkül.
A CI az első héten be van kötve, még a feature-teljesség előtt. Minden build, amely később elérte a store-t, ugyanazon a pipeline-on ment át, így a launch hete rutin volt, nem kapkodás.
A heti demó mindenkit őszintén tart
Minden hét élő demóval és rövid írásos összefoglalóval zárul, a staging build pedig az első héttől a kezedben van. A haladás valami, amire kattintasz, nem státuszriport. Ha valami félremegy, a második héten derül ki, nem a hatodikon.
Mire nem való a hat hét
Nem fér bele minden. Az okos hardver, a nehéz integrációk és a tanúsítási követelményekkel járó termékek saját ütemtervet igényelnek, ezért ezek a buildek egy egyhetes scoping sprinttel indulnak, nem egy ígérettel.
De ha a terméked egy app vagy webes termék egyetlen bizonyításra érdemes mag-körrel, hat hét általában elég ahhoz, hogy valódi felhasználók elé kerüljön. Ez az MVP lényege: hogy hat hét múlva kezdj tanulni, ne egy év múlva.