A Steve McConnel által leírt bizonytalanság kúpja azt mutatja, amit minden tapasztalt szoftveres szakember tud. Ami azt jelenti, hogy minden projekt kezdetén nem tudjuk pontosan, hogy mennyi ideig fog tartani egy projekt.
Ezeknek számos oka van. Nincs két olyan projekt, amelynek:
- azon követelmények.
- azon emberek.
- azon üzleti környezet.
- azon technológia.
- azon prioritások & korlátok.
Minden projekt egyedi. Minden egyes kódsor kézzel készített. És az okos, kreatív emberek bevonásával végzett tudásmunka nem alkalmas a pontosságra, mint az árokásás.
Mégis a pontosság az, amit kérnek. A szponzorok pontosan tudni akarják, hogy mikor lesz kész a projekt, és mennyibe fog kerülni.
Az ezzel a problémával való foglalkozás majdnem olyan régi, mint maga az idő. Íme néhány módszer, ahogyan a csapatok és a vállalatok kezelik ezt a bizonytalanságot.
A kúp kezelése
Többszörözze meg a becslést
Az alulbecslés szúrását megérezve az egyik gyakori reakció az, hogy a következő alkalommal megduplázzák vagy megháromszorozzák a becslést. Ez határozottan csökkenti az előzetes kockázatot, de a számok kitömése nehezebb, mint amilyennek hangzik.
Túl nagy számot ad, és a szponzorok meginognak, és nem hagyják jóvá a projektet. Ha túl alacsony számot adsz, azt kockáztatod, hogy kifutsz a pénzből. Ez kétszeresen is kockázatos, ha fix árajánlatú szerződésekre pályázik, ahol még nagyobb a nyomás, hogy a számokat alacsonyan tartsa.
A legtöbb projekt valamilyen módon kiegészíti a végső számokat, hogy elegendő mozgásteret biztosítson magának. Egy másik dolog, amit a csapatok tehetnek, hogy összehasonlítják ezt a projektet másokkal.
A projektet viszonylagosan méretezik
Az emberek nagyon jók a dolgok relatív méretezésében. Nem tudjuk pontosan megmondani, mekkora egy szikla. De azt meg tudjuk mondani, hogy mekkora valami máshoz képest. Ezt használhatjuk a projektek méretezésénél is.
Legyünk nyíltak és őszinték
Az agilisok alapértelmezett működési módja az átláthatóság és a láthatóság. Így nem lehet meglepő, hogy az agilis módszer a kúpokkal való bánásmódban az, hogy legyünk nyíltak és őszinték.
Nézd! Nem tudjuk, hogy ez mennyi ideig fog tartani. Ez a legjobb tippünk. De ha adsz nekünk néhány iterációt, akkor meg tudunk építeni valamit, meg tudjuk mérni, hogy ez mennyi ideig tart, és akkor sokkal jobban meg tudjuk mondani, hogy mekkora ez a dolog.”
Egy másik megközelítés, amit néhány agilis csapat alkalmaz a bizonytalanság kommunikálásának elősegítésére, hogy a becsléseket tartományként mutatják be.
Ez azzal az előnnyel jár, hogy láthatóan megmutatja a szponzoroknak a projekttel járó bizonytalanságot, és így a szponzorok eldönthetik, mekkora kockázatot engedhetnek meg maguknak.
Finanszírozás fokozatosan
Egy másik megközelítés, amelynek sok értelme van, de sajnos nem látom elég gyakran alkalmazni, a fokozatos finanszírozás.
A fokozatos finanszírozásnál nem kérünk előre az egész zsák pénzt. Csak annyit, amennyi elég ahhoz, hogy a munkálatok egy részét végigcsináljuk, és egy pontosabb számot tudjunk mondani arról, hogy mennyi ideig fog tartani.
Ez nem bolondbiztos. Később még mindig bajba kerülhetsz. De ha a csapatoknak 30-50 ezer dollárt adunk, hagyjuk, hogy építsenek valamit, és megnézzük, mennyi időbe telik, az nagyban csökkentheti az előzetes számok eltérését.
A tervezésnek erről a módjáról és előnyeiről többet olvashat Jeremy Hope Beyond Budgeting
A kiváltó ok
Az éves költségvetések világában élünk. És sajnos ez okozza a munkahelyi feszültségek és drámák nagy részét. Bizonyos szempontból az éves költségvetések természetesek (éves ciklusokban élünk és követjük az időt), más szempontból azonban borzalmasak a tervezés szempontjából, mivel egy év hosszú idő a piacon.
Ha azon kapod magad, hogy a bizonytalanság kúpjába botlasz, ne feledd, hogy a szoftverbecslés lényege annak meghatározása, hogy a projekt egyáltalán lehetséges-e.
Vagy ahogy Steve McConnell mondja:
A szoftverbecslés elsődleges célja nem az, hogy megjósolja a projekt kimenetelét; az, hogy meghatározza, hogy a projekt céljai elég reálisak-e ahhoz, hogy a projektet úgy lehessen irányítani, hogy elérje azokat.
-Steve McConnell, Software Estimation: Demystifying the Black Art