Avagy a terv semmi, a tervezés minden
Építettél már házat?
Leülsz egy kivitelező tervezővel, mondod neki, kellene egy ház. Ő hümmög egyet, megkérdezi, mégis milyet? Erre elmondod, olyan kéne, amibe nem esik be az eső, a széltől sem dőlnek össze a falak. Legyenek benne szobák, különböző funkcióval, még nem pontosan tudod, majd később eldöntöd. Nagyon jól nézzen ki és biztonságos legyen. Meg modern, mindenképpen a legújabb technológiákkal készüljön. Kérsz rá egy árat gyorsan, meg egy határidőt. A kivitelező ráncolja a homlokát, majd határozott, magabiztos hangon azt mondja 100 millió birodalmi krajcár lesz ez. Neked pont ennyid van rá, megörülsz, bele is csapsz a kezébe, akkor menjen a dolog, írjunk szerződést.
Vennél így házat? Mi sem. Informatikai projektet akkor miért vennél így?
Sokszor látni-hallani a következő menetrendet: Kiadunk egy ajánlatkérést. Jó esetben leülünk egyszer-kétszer egy-egy órát beszélgetni az ajánlatadó cégekkel. A fejlesztők ez alapján adnak egy becslést és árajánlatot, részletes bontással. A bejött ajánlatokból, ha több van, kiválasztjuk a szimpatikust, ami megfelel árban és a terv szakmaiságában is.
Persze ez egy fiktív terv lesz:
- a becslésbe bekerül egy csomó biztonsági tartalék is, mert a szállító is tisztában van vele, hogy nem tudja az összes információt, amire szüksége lenne egy „biztos” terv elkészítéséhez.
- különböző értéktelennek gondolt események (pl sprint tervezés, retrospektív) elkenésével és hozzáadásával végül már a legelső terv is fiktív. Nem azt tartalmazza, ami történni fog.
- előfordul, hogy a megrendelő sem tudja még pontosan elképzelni, milyen szoftvert szeretne, „de valamit mondani kell”(tehát eleve fiktív alapokra épül a fiktív becslés).
Az ajánlatkérés-adás már csak így működik. Ezzel elsősorban nem az a probléma, hogy a szállítók nem elég jók a becslésben és a nem várt körülmények előrejelzésében, a megrendelő pedig a szükséges szállítandók pontos definiálásában.
A veszteségünk ott fog keletkezni, amikor ezeket a fiktív terveket és becsléseket szerződésbe foglaljuk, majd pedig a végsőkig ragaszkodunk hozzájuk.
Nem lehetséges hatékonyan összeszedni előzetesen az összes szükséges információt és bombabiztos tervet készíteni rá. Ugyanakkor az is teljesen nyilvánvaló, hogy valamire építenünk kell. Megrendelőként terveznünk kell a költségekkel, a határidőkkel, hiszen, amit szeretnénk megvalósítani, az szükséges a saját stratégiánkhoz.
De ha a terveink nem biztosak, mivel tudunk kalkulálni? Mi az, ami mindig, minden projektnél biztos?
- Soha, senki nem tudja előre megmondani mi várható. Mindig történik olyan esemény, amire senki sem számított a projekt indulásánál.
Mi történhet menet közben?
- új információ, ami megváltoztatja a termékfejlesztésünk prioritásait (pl.: új jogszabály jött ki, ami miatt nagyon fontos valamilyen változtatást sürgősen végrehajtani)
- Másként értelmezte a specifikációban lévő egyik követelményt a szállító és a megrendelő
- Menet közben derül ki, hogy egy nagyon fontos funkciót elfelejtettünk
- A papíron leírt, és általunk tudott folyamat nem úgy történik a valóságban
- Az első Usability teszteken kiderül, hogy a felhasználók nem úgy viselkednek, ahogy vártuk
- Valamilyen információ, ami szükséges lenne a haladáshoz mégsem áll rendelkezésre időben
- Kiderül, hogy valamit sokkal bonyolultabb megcsinálni, mint azt előzetesen feltételeztük.
Rengeteg példát lehetne még felsorolni, gyakorlatilag végtelen számú új körülmény fordulhat elő, mialatt egy új szoftver elkészül (ez tulajdonképpen az élet bármely területén ugyanígy működik).
- Ha nem várt esemény biztosan lesz, akkor az is biztos, hogy ez borítja (vagy legalábbis eredeti formájában már nem végrehajthatóvá teszi) a tervünket.
Egész egyszerűen azért, mert nem tudtunk számolni rengeteg új tényezővel, amikre fentebb már felsoroltunk néhány példát.
Miért ragaszkodunk mégis a tervekhez?
Azért, mert látszólag biztonságot nyújt. Azt érezzük rajtuk keresztül, hogy kézben tartjuk, kontrolláljuk, ami történik. Reális az, hogy irányítsuk a dolgok menetét olyan terv alapján, ami akkor készült, amikor sok nagy hatású körülmény még nem is volt ismert?
Akkor a tervek rosszak? Korántsem. A tervek, és főleg a tervezés egyáltalán nem rosszak. A probléma az, ha ezeket mindenáron végre akarjuk hajtani eredeti formájukban. A lenti, elválasztó utáni részben olvasható egy példa arról, hogyan fut le egy ilyen projekt.
Rendben, de mit tegyünk akkor?
Mindig tervezz, de soha ne ragaszkodj a tervekhez minden áron.
- A tervezés ne legyen egyszeri tevékenység, folyamatosan időt kell rá szánni, hogy be lehessen építeni és alkalmazkodni lehessen az új körülményekhez.
- A terveid legyenek több szintűek, mindig a nagy célból vezesd le a kisebbeket, és csak akkor, amikor arra szükséged van.
- Az vezet sikerre, ha mindig beépítjük az új információkat és adaptálódunk az új körülményekhez – életszerűtlen, hogy a kezdeti infók birtokában semmilyen irányváltásra ne legyen szükség. Képzeljük el, hogy elindulunk autóval a Balatonra: ehhez megnézzük a térképet, esetleg felhívjuk ismerőseinket, akik előzőleg arra jártak, hogy mondják el hol kell esetleg valamit kikerülni, majd beállítjuk a kormányt és elhatározzuk, bármi lesz is, nem mozdítunk rajta amíg el nem érjük a Balatont, hiszen így terveztük.
És persze legyen gyanús, ha valaki egy órás beszélgetés és egy néhány oldalas leírás alapján pontosan megmondja egy egész éven át tartó projekt menetrendjét, tartalmát és határidejét.
Maradjatok velünk, a következő blogcikkeinkben arról írunk, hogyan érdemes fejlesztési projekteket végezni szerintünk (persze nem csak szerintünk, inkább az iparági best practice-ek alapján).
Ha szeretnél arról beszélgetni, hogyan lehetne elkerülni a csapdákat és hasznosan elkölteni a fejlesztésre szánt pénzt, keress
linkedinen!
Másokkal történik csak ilyen projekt: A klasszikus ajánlatot kérünk – rövid megbeszélések után szerződünk egy évre, majd elkezdjük megnézni részletesen mi is a feladat projektek jellemző forgatókönyve látható a következőkben.
20** január
- Projekt kick-off pogácsával
- Kőbe vésett határidő: 20**. év vége
- A biztonság kedvéért van egy kis ráhagyás a becsléshez képest
- Az igények részletes összegyűjtése még csak most kezdődik (mi alapján született a becslés?)
20** Május
- Igényspecifikációk még nincsenek lezárva
- A konkrét szoftverfejlesztés még nem indult el
- Projekt státusza: zöld
- A feladat már most többnek látszik, mint azt előzetesen bárki gondolta
20** Július
- Még mindig hatalmas hiányosságok a specifikációban
- Fejlesztési munka elindult elindult. Kockázat: az elejét lehet, hogy ki kell majd dobni, mert még mindig sok a nyitott kérdés
- Kommunikált projekt státusz: A projekt befejezhető időben
20** Szeptember:
- Specifikációk lezárva (változtatási kérelmek még várhatóak)
- Fejlesztés felét az új infók fényében újra kell tervezni és fejleszteni (emiatt látható az ábrán, hogy csökkent az elvégzett feladatok mennyisége, azok a részek mentek a kukába)
20** November
- A fejlesztők sokszor túlóráznak, de azt mondják készen lesznek
- Projekt státusza: zöld (a végén mindig bele kell húzni, ez természetes)
20** December
- Nem lettek készen
- Rengeteg a hiba, a folyamat még nem tudott végigmenni egyszer sem (csak az egyik fejlesztő gépén)
- A határidőt ki kell tolni egy hónappal
20**+1 Február
- Egy hónapja lejárt a kitolt határidő is
- Az Ügyfél most látja először a szoftvert
- Azért nem tud végigmenni a folyamat, mert fontos részek nem kerültek be a specifikációba, pedig így is 200 oldal volt
20**+1 Március
- A fejlesztők az utólagosan megrendelt változtatásokon dolgoznak
- Már mindenki, mindig túlórázik
- Napi két státusz megbeszélés
20**+1 Május
- A projekt átadásra került
- A költségeken túlhaladt, az emberek fele felmondott
Befejeződött a projekt, de örülünk neki?
- Amíg elkészült, világossá vált, hogy a scope legalább felére már nincs szükség, de a szerződésben benne volt, meg kellett csinálni.
- Menet közben látható lett mi lenne fontosabb, de nem az szerepelt az eredeti szerződés mellékletekben.
- Jelenleg a szponzorok meggyőzése a feladat, hogy még egyszer ennyi pénzért finanszírozzanak egy új projektet az előző hibáinak kijavítására
