Derrick és Harry Projektmenedzsment Blogja

Terjedelem Mentesítés: fix ár, fix határidő, fix szkóp, 2. rész

2014. június 05. - TanacsLajos

Az elvileg fix feltételek mentén végzett projektharcok kemény diójának feltöréséről indított cikksorozatunk előző részében odáig eljutottunk már, hogy ha fix áron, határidőre és terjedelemben kell szoftvert szállítanod, akkor arra érdemes törekednünk, hogy az adott határidőre és pénzből hozzunk össze valami értelmeset, és a végére valahogy győzzük meg a megrendelőt, hogy jó lesz neki az, amit kapott. Lássunk most néhány tippet arra vonatkozóan, hogy hogyan oldjuk meg ezt a feladatot minél fájdalommentesebben!

Hidd el, nem tudod, mit akarsz!

Alapvetően kétféle megrendelő létezik a világon:

1-es típus: nem tudja hogy mit akar, de ezt legalább tudja magáról

2-es típus: nem tudja hogy mit akar, és ezt sem tudja magáról

Ha véletlenül az aktuális megrendelőd az 1-es típusba tartozik, átugorhatod ezt a fejezetet. Sajnos a sors különös játékának eredményeként valamiért én mindig a 2-es típusú megrendelőkkel találkozom. Megkérdezed, tudod-e mit akarnak, és az egyértelmű "Persze!" felkiáltás után ilyen folytatásokat hall az ember:

"Hát olyan rendszert akarok, hogy legyen benne egy ilyen vájerlessz digitális toll, ami ír a képernyőre, és az ügyfél ott helyben a képernyőn aláírhassa vele a szerződését. Ez a jövő!"

"Olyan legyen, mint az XYZ rendszer, csak jobb. És fusson iPad-en."

"Figyelj, az egész rendszer tök egyszerű, idebent már megbeszéltük, két ember 6-8 hét alatt simán meg tudja csinálni, csak nincs szabad erőforrásunk, üssétek már össze."

Aha, persze. Funkciók, felhasználók, folyamatok, hibaágak, kapcsolódó rendszerek, ellenőrzések, algoritmusok, képernyőfeliratok, dizájn, ergonómia, mind mellékesek.

Na az itt a feladat, hogy ráeszméljen a kedves megrendelő: az ő víziója még ahhoz sem elég egzakt, hogy egy három oldalas póverpointot csináljunk belőle, nem hogy működő szoftvert. Hiába várja el, hogy ez alapján máris kopogjanak a programozók ujjai a billentyűzeten beszpídezett harkályt megszégyenítő sebességgel.

A megoldás: pontosító workshop, minden mennyiségben! Itt aztán eláraszthatod a megrendelőt a részletekre vonatkozó kérdések százaival, amire nyilván nem tud válaszolni, összezavarodik, és belátja, mennyire ködösek az elképzelései. Segítségre van hát szüksége, közösen meg kell terveznetek a rendszert.

Hidd el, nem az kell neked, amit akarsz!

Az első nehéz lépés után jön a következő: a workshopok, tervezési megbeszélések során lassan összeáll egy rendszer képe. Egy akkora rendszeré, amihez képest a houstoni űrközpont homokozóvödörnek tűnik egy lapáttal. A felvázolt komplexitás első körben hatalmas büszkeséggel tölti majd el a megálmodóit, és így még fájdalmasabb lesz szembesülni a ténnyel, miszerint ezt a szoftvert így nem lehet megcsinálni a tervezett erőforrások hatszorosából sem.

Az üzenet, amit közvetítened kell a következő:

Vágni kell a szkópból, annyit, amennyit most még el sem tudtok képzelni, de ez az egyetlen út a sikerhez.

Ne mutass irgalmat, vágjatok ki mindent, amíg azt nem mondják, hogy már képtelenség ennél többet elvenni belőle: ami így megmaradt, annak a felét érdemes megcsinálni. Persze lesz sírás, tiltakozás, ellenkezés, de a kezdeti célok drasztikus megvágása az egyetlen esélyetek. Sokkal jobb egy egyszerű és működő rendszer, mint egy soha el nem készülő monstrum: egy használható lapát ezerszer többet ér egy nem felborult exkavátornál. Ezzel próbálj meg gödröt ásni:

images_1.jpeg

Ugye, hogy jó lesz a lapát is annak a néhány tujának?

Mindig van egy következő verzió

Van azért egy általános gyógyír, ami segít enyhíteni a megálmodott, vágyott, de elveszni látszó funkcionalitás által okozott kínt: a következő verzió. Csak kevés funkciót érdemes végleg eltünteti az egyszerűsítési, fókuszálási folyamat során: már a projekt előkészítése során kezdjük el hangsúlyozni, hogy több fázisban fogunk dolgozni. Lesz majd egy következő, meg egy azutáni, meg azutáni verzió, és mindazt ami nem valósult most meg, megvalósul majd akkor!

Ez a megoldás egyrészt nem engedi, hogy eseltegesen indokolt fejlesztési igények elvesszenek az erőteljes terjedelemvágás során. Másrészt lelkileg könnyebb elviselni a vágyak meg nem valósulását, ha életben hagyjuk a reményt. Úgy valahogy, ahogy Kovács Gézuka 5 éves óvodásnak is azt mondták a szülei Mukiról, a kis húsvéti nyusziról, hogy "neeeem Gézuka, a kis Muki jól van, csak elköltözött egy gyönyörű farmra, ami nagyon messze van, úgyhogy nem tudunk oda elmenni." Pedig valójában a Gézuka apukája bizony átment szegény Mukin a Zsigulival tolatás közben, amikor az a kocsibejárónál téblábolt.

Ahogy minden kis nyuszi számára létezik valahol egy távoli, gyönyörű farm, legyen úgy a te projektedben is mindig ott a következő verzió!

A bejegyzés trackback címe:

https://derrickesharry.blog.hu/api/trackback/id/tr256262464

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

BigTom 2014.06.05. 22:17:43

Pontosító workshop helyett csináljatok inception deck-et. Ez garantáltan kihozza, hogy mi kell igazán a megrendelőnek.
Az elképzelt terjedelmet bontsátok funkciókra és csináljatok komplexitás becslést és üzleti érték becslést minden funkcióhoz (például relatív súlyozással). Ez alapján meg tudjátok határozni, hogy melyik funkció képviseli a legnagyobb hasznot a bonyolultságához képest, és könnyedén tudjátok eszerint sorba rendezni a funkciókat.
Ekkor már csak az van hátra, hogy az első fázis ne legyen nagyobb 1-2, de maximum 3 hónap alatt elkészíthetőnél (minimum életképes termék), és minden egyebet a további fázisokban tegyetek hozzá.

takacsot · http://www.qualityontime.eu 2014.06.10. 07:36:56

@BigTom: A funkciókra bontás csak akkor működik, ha megvan a minim termék (minimal viable product) És ez az egyik legnehezebb lépés, mivel egy ügyfélnek sokszor a csillogó és forgó email ikon is minimális funkcionalitás.

Ehelyett a szükséges igényből kell kiindulni. Mi az az üzleti terület, amit fejleszteni kell (nagyon rég óta/elképesztő ritkán nincs igazán új termék/funkció a világon, csak a meglévő feljavítása), mérhető módon. Arra jöhetnek a megoldási terek, amik impaktját is becsülni kell. És csakis ez után jöhet szóba implementációs terv vagy architektúra.

BigTom 2014.06.10. 21:19:12

MVP-t csinálni azért nem olyan nehéz. Én a forgó ikon árát mindig valami megfoghatóra vetítem le, például kaphat egy új macbook-ot, vagy egy forgó ikont, ilyenkor általában nem kérik a forgó ikont. Ugyancsak segít az üzleti érték pontozás, ami plasztikusan megmutatja, hogy mi mennyire fontos.

A megoldási terek impaktját nem értem.

Vén Márton 2014.06.15. 23:26:32

Jó a poszt, bár a következő nem tiszta nekem belőle:

Ha részleteiben akarunk specifikációt csinálni egy összetett rendszerről, akkor nyilván hetekig-hónapokig tartó pontosító workshopokról beszélünk.

Ez viszont általában ajánlat és szerződés után történik meg. Emiatt az alábbi nekem nem értelmezhető:

"így még fájdalmasabb lesz szembesülni a ténnyel, miszerint ezt a szoftvert így nem lehet megcsinálni a tervezett erőforrások hatszorosából sem"

Ebben a stádiumban az ügyfél pozíciója a tapasztalataim szerint jóval erősebb. Eszébe sincs vágni a scope-ból, hiszen van egy szerződése, hogy mi ezt eddig és ennyiért megcsináljuk. Így sokszor beleáll ebbe a pozícióba, hogy ez a funkcionalitás (vagy a nagy része) neki minimálisan kell.

Gyakran hiába mondom én szolgáltatói oldalról, hogy ez vagy az a funkció felesleges, mert a "scope csökkentés" általában az ügyfelek leggyűlöltebb kifejezése (a "change request" mellett).

Szóval, mivel szerződés és határidő van fix áron, masszív mennyiségű funkciót levágni a tapasztalataim szerint nem nagyon lehet. Arra még hajlandóak az ügyfelek, hogy fázisokra bontsuk a fejlesztést, de akkor még csak a fix idő problémáját oldottuk meg, mert előfordulhat, hogy fizetni csak a teljes rendszer esetén fog, és akkor is csak az eredetileg szerződött összeget.

Az a tapasztalatom, hogy a fő harcok nem abban vannak egy projektben, hogy mennyit vágjunk a scope-on, hanem hogy mennyi új igényt ne engedjünk hibaként értelmezni. Mert amikor az ügyfél elkezdni tesztelni, vagy akár használni a rendszert az integrációs teszteken, akkor hirtelen jönnek az új igények. Van ami jogos, és van ami nem, de mindegyik újdonság, amivel nem terveztünk.

Ráadásul ebben a stádiumban a szolgáltatónak már nagyon kell a pénz, mert a fejlesztés nagyján túl vagyunk, és ilyenkor leállni minden apró cseprő új igény miatt, eszkalálni azokat a szponzorok felé, az heteket tol a projekten.

Nyilván a legjobb lenne az ajánlat és szerződés előtt alaposan lespecifikálni a rendszert, de egyrészt nyilvánvalóan ez óriási rizikó a szolgáltatónak, mert sok erőforrás, és lehet hogy össze sem jön a projekt, másrészt sok esetben egy tendernél nem is ad rá lehetőséget az ügyfél.

Szóval kíváncsi lennék, hogy mivel tudtok meggyőzni egy ügyfelet változatlan ár és határidő mellett masszív scope szűkítésről, ha őket védi a szerződés?
(és az nem ér, hogy megfenyegetjük az ügyfelet, hogy így visszalépünk a szerződéstől, mert ez a legtöbb esetben nem projektvezetői hatáskör).

TanacsLajos 2014.06.17. 21:56:21

@Vén Márton: Köszi az értékes kommentet! Két részre bontanám a dolgot: az egyik a változtatási kérelmek hibaként értelmezése, a másik a scope csökkentés elérése (a kérdés a végén).
A CR hibaként történő elsütését biztosan el fogja játszani a megrendelő. Egyrészt azért, mert ő természeténél fogva velejéig gonosz :) másrészt meg azért, mert az ő szemszögéből tényleg hibásan működik a rendszer, mert nem tud vele úgy dolgozni, ahogy ő szeretne. Az kevéssé izgatja, hogy benne volt a szerződésben vagy specifikációban a dolog, vagy nem. Ilyenkor nem az a jó megoldás szerintem, hogy a szerződés minden betűjéhez foggal körömmel ragaszkodunk, mert az eredmény egy nehezen, vagy egyáltalán nem használható rendszer lesz, amit utálni fognak. Akármi is van a szerződésben. Inkább minél korábban be kell vonni a megrendelőt a tesztelésbe, már a fejlesztés során, hogy minél előbb kiderüljön, ha valami nem jól lett kitalálva.
Ennek felderítése a szállító felelőssége nagyobb részt. Abból kell kiindulni, hogy a megrendelő nem olvassa el a specifikációt, nem figyel a workshopon, kikapcsol az agya, amikor magyarázzák neki, mit fog kapni: ezért kell neki minél előbb megmutatni, ami már elkészült a szoftverből.
A scope csökkentés lenyeletése igazából valóban akkor tud jól működni, ha az a szerződés aláírása ELŐTT teszi meg az ember (engem egy ilyen élmény inspirált a cikk megírására). Ha már vérszerződést kötöttél az űrközpont leprogramozására, akkor persze nagyon nehéz lesz elfogadtatni, hogy nem kapja meg a megrendelő. A fix áras feladatoknál sokszor nem a szakmai megrendelőn kívülálló személyek, mondjuk a beszerzés szabja meg az anyagi kereteket, és így a szakmai csapat is sarokba van szorítva, abból kell valamit főzniük, amijük van: ekkor lehet nekik segíteni ezze a scope vágós (vagy legalábbis szigorúan priorizálós) hozzáállással. Végülis vágni vagy második fázisra rakni majdnem ugyanaz az éles indulás szempontjából: a végső érv mindig az tud lenni, hogy ha fontos az éles indulás időben, akkor vágni kell, mert képtelenség időre mindent megcsinálni.
Ha mindenhez ragaszkodik a megrendelő és nyúlni kezd időben a projekt, akkor már nem fix határidőről beszélünk, mert nyilvánvalóan tolható a dátum, még ha nem is ezt kommunikálják.
Hú, messzire vezet ez a téma (közben elgondolkoztam azon, meddig is terjed a szállító mint szakértő felelőssége), 28-án este egy sör mellett még szívesen boncolgatnám! Gyere el te is!

Vén Márton 2014.06.18. 11:30:21

Köszi a választ, és a meghívást, szívesen mennék, de pont aznap délelőtt viszem a családot nyaralni. Majd legközelebb.

Nagyon tetszik a blogotok. Jó a stílus és a témák is. Ahogy olvastam, eszembe jutott pár téma amikről jó lenne olvasni, leírom ötletadónak, hátha megtetszik valamelyik:

A projetvezető és az érzelmek, azaz hogyan dolgozzuk fel, hogy a projekt nagyrészében terroristának, aljas gonosztevőnek tekintenek minket.

Projektvezetés vs Sales, azaz hogy jön össze, ha a cégnek valós rendszereket kellene bevezetnie, míg a sales-esek csak álmokban létező rendszereket tudnak eladni.

Kedvenc PM életérzéseim újabb részek, ezek a kedvenceim, egy csomó van ami velem is hasonlóan megtörtént.

Meghökkentő ügyféligények, ügyfél ötletek, ebből minden PM-nek millió érdekes sztorija van, kíváncsi lennék a tiétekre. Csak egy példa rá, mert nem bírom ki:

Még a 2000-es évek elején egy B2B rendelési rendszert fejlesztettünk egy gyógyszer nagykereskedőnek. Javában specifikáltuk a rendszert, egyeztettük a partneri árazást, a készletkezelést, az illesztést a nemtudommilyen háttérrendszerükhöz, mikor a megbeszélésre megérkezett a marketing igazgatójuk.

Leült, és váratlanul papírokat tett az asztal közepére, amin egy közepes, Dargay Attila utánzat rajzolt medve volt különféle pózokban. Azt mondta, azt találták ki a marketingen, hogy a "rendszer kabalaállata egy maci legyen", ami megjelenik itt-ott az oldalakon. Síri csönd lett. A döbbent tekintetünket látva elkezdte magyarázni: a gyógyszertár angolul pharmacy, értjük, far-maci.

Napok kellettek, mire összeszedtük magunkat, és hetek, mire lebeszéltük erről.

HighTroller 2014.06.26. 14:29:36

a legjobb amikor te találhatod ki, hogy mi az amit ők igazából akarnak, és végül azt fogják akarni amit te akartál hogy akarjanak:) (ha jól értem, akkor ez az 1-es típus, ők az ártalmatlan, jószándékú fajta).

a rossz amikor tudod hogy amit akar az szar, és igazából meg is tudod csinálni, de tudod, hogy szar lesz, és hiába akarod meggyőzni arról, hogy ő tulajdonképpen nem is azt akarja amiről azt gondolja hogy akarja, hanem valami egészen mást, ő azt fogja gondolni, hogy biztos szakmai inkompetencia miatt kérdőjelezed meg az ő elképzeléseit.

volt dolgom mindkét fajtával, a 2-es típusnál a projekt után nehéz volt meggyőzni a kedves megrendelőt, hogy nem a szoftver lett bonyolult (pontosabban de, nyilván az is, de miért!), hanem nem engedték az üzleti folyamatokat úgy leegyszerűsíteni, hogy ne egy űrközpontba oltott 86 csatornás keverőpultra hasonlítson a szoftver.

de hát ettől szép ez a szakma vagy mi

venmarton 2014.06.27. 16:48:12

@Kriminalhauptmeister Harry: Még egy (aktuális) poszt ötlet eszembe jutott:

Nyaralhat-e egy projektvezető? Helyettesíthető-e a projektvezetői munka? Nyilván projektméret-függő, de én még sose tudtam úgy elmenni szabadságra, hogy ne kellett volna napi 2x1-2 órát ügyintézni, tüzet oltani.
süti beállítások módosítása