Az első 30 nap egy új ügyféllel: onboarding playbook

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.