Az első 30 nap egy új ügyféllel: onboarding playbook
Az első hónap eldönti a következő 12-t. Lépésről lépésre megmutatjuk, mit csinálunk az új ügyfél 1. napján, 1. hetén, 30. napján.
Nem a szerződés aláírása a kezdés. Az onboarding első 30 napja az.
Sok projekt azért szenved a 3. hónapban, mert az 1. hét felületes volt. Nincs dokumentált hozzáférési lista, nincs egyeztetett kommunikációs csatorna, nincs tisztázott döntési hierarchia. A csapat elkezd dolgozni, az ügyfél elkezdi visszajelzéseket írni a rossz csatornán — és a zavaros indulásból 9 hónapon keresztül nem lehet kilábalni.
1. nap: hozzáférések és emberek
- Ki az egyetlen döntéshozó? (nem több, egy — a többi véleményező)
- Ki a napi kontakt? (lehet más, mint a döntéshozó)
- Ki a technikai kontakt az ügyfél oldalán? (kérdést neki teszünk fel)
- Milyen rendszerekhez kell hozzáférés? (repo, staging, prod, monitoring, CI)
- Ki ad jogosultságot és milyen határidővel?
1. hét: technical read + discovery
Az 1. héten nincs feature fejlesztés. Olvassuk a kódot, jegyzetelünk, rajzoljuk az architektúrát, listázzuk a veszélyes pontokat, beszélünk mindenkivel (nemcsak a döntéshozóval). A hét végén egy 5 oldalas dokumentumot adunk át: "amit láttunk, amit javasolunk, amit nem tudunk megoldani rövid távon". Ez adja meg az alaphangot — nem rohanunk, hanem megértünk.
30. nap: első retrospektív
- 30 perces beszélgetés, csak az ügyféllel (nem technikai)
- 3 kérdés: mi működik, mi nem működik, min változtatunk a következő 30 napban
- Írásban összefoglaljuk, és 48 órán belül visszaküldjük
- Ez az egyetlen időpont, amikor kérhetjük, hogy módosítsák a scope-ot ingyen (mert még tanulunk egymásról)
- A 31. naptól a scope-on szigorúak vagyunk
A 30 napos retró nélkül mindkét fél elkezd bosszankodni, de senki nem mondja ki. Kimondhatóvá tesszük, elegánsan, rituálé formájában. Eddig minden projekten csökkentette a súrlódást — és már kétszer előfordult, hogy a retrón kiderült: rosszul értettük az egyik modul célját. 10 napba telt átszabni, de 2 hónap vitát spóroltunk meg.