Programozók körében terjedő városi legendák és azok cáfolata.

Programozók körében terjedő városi legendák és azok cáfolata.

Néhány népszerű városi legendát veszek ma nagyító alá, amolyan Mythbusters jelleggel.

Az ügyfél nem tudja, mit akar
Mire a programozók az ügyféllel kapcsolatba kerül, addigra az ügyfél már valamilyen formában elköteleződött sok-sok pénz kifizetésére. Erre bizonyára nyomós oka lehetett. Lehet hogy nem tudja rendesen elmondani/leírni, de a fejében biztosan van valamilyen elképzelt megoldás. Ha nem lenne, akkor nem kereste volna meg a fejlesztőket.
Felhívnám a figyelmet, hogy a fejlesztők és az ügyfél más hozzáállással, más tudással rendelkeznek, ezért törvényszerű közöttük a félreértés.

Az ügyfél menet közben meggondolja magát
Tessék tudomásul venni, hogy az emberi kommunikáció nem tökéletes. Amit leír, az nem biztos hogy az, amit gondol. Ezért vannak rendszerszervezők, hogy kinyerjék az információt az ügyfélből.
A másik oldala pedig, hogy az embertársaink egy része vizuális típus: azaz csak akkor fog értékelhető válaszokat adni, ha látható módon megjelenítünk neki valamit (pl. egy adatbázis tervet vagy egy képernyő tervet). Ilyenkor el tudja mondani, hogy pl. igen ilyesmire gondoltam, de ez a gomb legyen nagyobb, az a mező ne itt legyen, stb.

Az ügyfél menet közben meggondolja magát 2
Az élet velejárója a változás. Az üzlet folyamatosan változik, tehát az üzleti igények is változnak. Egy fél éves vagy ennél hosszabb projektben már biztos, hogy az éles induláskor másak az elvárások, mint a kick-off idején. A menet közbeni változtatás része a projektnek – még a legkonzervatívabb vízesés modell esetén is.

Az ügyfél buta
Lehet hogy buta, de fizet. Tesco-ba se csak azt engedik be, akinek sikerül az IQ tesztje. Meg egyébként sem feltétlenül buta, legfeljebb a fejlesztők önbizalma túl magas.
Tessék inkább az „ügyfélnek mindig igaza van” szellemében eljárni.

Majd meggyőzzük az ügyfelet, hogy a mi módszertanunkat, szerződésünket, stb használja
Nézzük meg pontosan a szembenálló feleket:
Az egyik oldalon van a multi mint megrendelő:
- egy komplett, jól fizetett jogi osztállyal
- és kőkemény beszerzőkkel
A másik oldalon a kkv szoftverfejlesztő cég:
- egy olyan ügyvéddel, akinek az IT cég csak egy ügyfél a sok közül
- olyan pre-sales kollégával, aki esetleg nem rendelkezik erős értékesítői vénával

A meccs erősen egyesélyes.

Majd mi megtanítjuk a multit, hogyan kell szoftvert fejleszteni
Számtalan olyen produkciót láttam, ahol a fejlesztők zseniálisnak gondolták magukat, és megmutatták, hogyan kell szoftvert fejleszteni. Aztán amikor élesbe került a rendszer és elkezdtek jönni a problémák, akkor kénytelenek voltak visszavenni a mellényből. Nyusziba pedig igazán akkor mentek át, amikor közösen átnéztük az architektúrát, és fény derült a tipikus „don’t do” megoldásokra.

Csak annyit vagyok hajlandó dolgozni, amennyi a szerződésben le van írva
Rossz hírem van: többet kell. Nem elég azt leszállítani, amit az ügyfél kér, hanem azt úgy kell leszállítani, hogy meggyőző, megnyerő legyen. Sokszor azok a kis apróságok sokat számítanak, és azokat a kis apróságokat elrendezni idő, pénz, energia. Put a lipstick on the pig!

Ha az ügyfél hülyeséget csinál, az nem az én problémám
Jah, csak éppen akkor nem lesz teljesítés, és nem fognak fizetni.

Minőség = szoftvermérnöki tökéletesség
Tévedés. Minőség = elégedett ügyfél.
A szoftver nem akkor jó, ha az összes unit test tökéletesen lefut, hanem akkor, amikor az ügyfél problémáját megoldja.

Mi mindent jól csináltunk, ha valami hiba van, az nem nálunk van
Persze, de amíg a rendszer nem áll össze, addig nem lesz kifizetés.

Olyan specifikációt még nem láttam, ami ne változott volna
Valóban, az élet magával hozza a változást. De az igényeket dokumentálni kell (egy bizonyos szintig) hogy ne legyen belőle később vita. Mert ha vita van, akkor abból a beszállító nehezen jöhet ki jól.

A multinál csupa léhűtő, inkompetens ember dolgozik
Biztos akadnak léhűtők is, de akadnak nagyon jó szakemberek is. A csapdahelyzet az, hogy elindul a szoftverfejlesztés, és nem biztos, hogy a jó szakemberekkel találkozunk elsőre. A minőségi standardok lejjebb kúsznak, a fejlesztők lazítanak. Aztán egy nap felbukkan egy szakértő, és megkérdezi hogy mi ez a szemétdomb…