A héten résztvettem egy szoftverfejlesztői álláshirdetés megfogalmazásában. A kiírás rendhagyóra sikeredett: az első oldalon leírtuk, milyen – szerintünk – egy jó szoftverfejlesztő, a másik oldal pedig arról szólt, milyen egy szoftverfejlesztő napja a cégnél.
Ketten dolgoztunk ennek a provokatív, figyelemfelkeltő álláshirdetésnek az elkészítésében. Pont ez a provokáció volt az, ami nekem tetszett az egészben. A cég vezetőségében viszont úgy döntöttek, hogy finomítanak az eredeti megfogalmazásunkon, és a szövegben fellelhető “vadhajtásokat” lenyesegetik. Az egyik mondat, amelyikre a legbüszkébb voltam (és akár egy buddhista tanításnak is beillene), végül kikerült a végleges szövegből:
A jó szoftverfejlesztő nem lepődik meg azon, ha állandóan “változnak a követelmények”, mert tudja, hogy valójában azok nincsenek is, mert egyetlen cél létezik csupán: a végén jó szoftvert előállítani.
Egy új szoftverfejlesztési projekt a követelményfelméréssel szokott kezdődni. Csutorás Zoltán írt arról egy igen elgondolkodtató cikket, hogy a követelményeket célszerű inkább elvárásokként tekinteni. Ugyanis:
“[…] a követelmények részben a környezeti kényszerek, részben a megrendelők adott pillanatban, adott információk alapján kialakított elvárásainak rögzített leképezése. A gond az, hogy ezek mind változnak. […] A megrendelőt […] nem érdeklik a követelmények. A megrendelőnek elvárásai vannak, amiknek megfelelő rendszert akar látni. Az üzleti megrendelő szemében a követelmény csak egy szükséges rossz, amibe az előzetes követelményspecifikáción alapuló fejlesztési kultúra belekényszeríti a tervezhetőség látszatának fenntartása érdekében.”
Mi köze van ennek az egésznek egy szoftverfejlesztőhöz?
Nagyon is sok. Sok helyen a szoftverfejlesztőket (vagy szofverfejlesztő cégeket) droidként kezelik. Átadják nekik a követelményeket: “Tessék, ezt kell megcsinálni!”. A szoftverfejlesztők pedig engedelmeskednek. Eszükbe sem jut, hogy valójában a követelménylistában megfogalmazott egyes tételek hátterében mi húzódhat. Mennyi mindent nem érdemes megcsinálni belőle, mennyi mindent lehetne másképpen, jobban csinálni. A határidő szorításában szolgaian lefejlesztik valahogyan a benne felsorolt funkciókat, eredményezzen az bármilyen szoftvert.
A nagyobbik baj, hogy a szoftverfejlesztők el is hiszik magukról, hogy nekik ez a feladatuk. Pedig ennél lehetne jobban is csinálni. Ha hagynánk, hogy a szoftverfejlesztők megértsék a követelmények mögött rejtőző elvárásokat, megérthetnék, hogy a megrendelőnek mi a valódi célja rendszerrel, és így sokkal jobb szoftvert tudnának szállítani. A szoftverfejlesztőktől érkező visszajelzéseket vissza lehetne csatolni a megrendelő felé, akivel egyeztetve revidiálni lehetne a korábbi elképzeléseket.
A szoftverfejlesztők (szoftverfejlesztő cégek) sok projektet csináltak már végig, sok esetben projektről projektre egy-egy újabb és újabb szakmát elsajátítva. Nem csak kódot írnak, hanem ők azok, akik tudják, mik egy fejlesztés buktatói, hogyan érdemes és nem érdemes dolgozni. Kár lenne ezt a lehetőséget kihagyni…
Amikor úgy fogalmaztam, egy jó szoftverfejlesztő tudja azt, hogy változó követelmények valójában nincsenek is, a valódi cél pedig a jó szoftver előállítása, akkor arra gondoltam, hogy a jó szoftverfejlesztő nem foglalkozik azzal, amit éppen követelményként rázúdítanak. Tudja, hogy ezen követelmények egy hibás fejlesztési folyamatnak, módszertannak az eredménye, és azon sem lepődik meg, ha ezen követelmények változnak.
A követelmények buta követése helyett a jó szoftverfejlesztő mindig megkérdőjelezi, amit mondanak neki. Folyamatosan ezen kérdések pörögnek a fejében: “De miért?”, “És mi lenne, ha…?”. Meg akarja érteni, hogy hogyan alakult ki egy képtelen szituáció, és abból megpróbál segíteni kitörni. A korábbi tapasztalatai alapján tudja, hogy nem szabad elfogadnia semmilyen helyzetet. Ha érzi, hogy tud egy jobb megoldást, akkor azt nem szabad magában tartania.
Félreértés ne essék, nem arról van szó, hogy a jó szoftverfejlesztő egy rendszeren kívüli elem, aki önkényesen felülbírál és kritizál minden korábbi döntést. Csupán arról van szó, hogy képes arra, hogy korábban megszerzett tapasztalatából adódóan hangot adjon véleményének, és ezzel segít cégénék, ill. a megrendelőnek abban, hogy végül egy jó (jobb) szoftver készülhessen.
zsepi
Oct 10th, 2010Anno beszélgettük egy ügyfelünkkel, hogy az adott projekt legnagyobb haszna nem is maga a működő szoftver volt, hanem az, hogy mi minden derült ki a régi folyamatukról. Egy csomó mindent csináltak, amit nem kérdőjeleztek meg (s voltak olyan lépések is, amikről nem is tudtak, hogy vannak!). Az összefoglalóink s kérdéseink (pl.: Ezt a három lépést egymás után így végzitek, de úgy tűnik, mintha semmi kihatása nem lenne a végeredményre. Mi értettünk félre valamit vagy tényleg így van?) lehetőséget teremtettek, hogy egyszerűsítsék ezeket. Figyelni kell arra persze, hogy mi csak kérdezzünk-javasoljunk, nem megmondjuk, hogy legyen, hiszen a területet ők ismerik jobban.
Hesz Roland
Oct 11th, 2010Most akkor leírtad a BA feladatainak egy részét. Akik természetesen feleslegesek. Legalábbis nálunk.
Nyugatra van azért belőlük sok (és nem csak szoftveriparban, mert a BA nem fejlesztő), de hát mi mindig jobban tudtuk mint a nyugat.
akocsis
Oct 11th, 2010Némi aggályam van az ominózus mondattal kapcsolatban…
A szoftverfejlesztés alapja az ügyfél igénye. Az a fejlesztő, aki eleve abból indul ki, hogy a megkapott követelmények rosszak, hibásak, az egyrészt túl nagy ego-ra utal (okosabb vagyok, mint a felhasznál), másrészt pedig szükségszerűen rossz lesz a szoftver (ha nem felel meg a követelményeknek, akkor mire lesz jó?)
Másrészt a profi fejlesztő profi rendszerszervezőkkel és profi menedzserekkel szokott dolgozni. Ha a potenciális munkahelyénél azt látja, hogy nem képesek specifikációt írni, akkor “ezek amatőrök” felkiálltással máshova megy dolgozni.
Harmadrészt pedig, ha nem a szakmai tudás hanem a rugalmasság alapján keresel fejlesztőt, akkor csúnya meglepetésben lehet részed.
A cég vezetői jól látták a dolgot…
Marhefka István
Oct 11th, 2010zsepi: Egyetértek, és ezért is gondolom azt, hogy hasznos, ha a szoftverfejlesztő cég proaktívan áll hozzá a szoftver kifejlesztéséhez.
Természetesen a kommunikáción nagyon sok múlik, nem mindegy, hogyan adjuk el a saját ötleteinket a megrendelőnek.
Marhefka István
Oct 11th, 2010Roland: Nem mondanám, hogy felesleges a BA szerepkör, de egy jó fejlesztőben is kell ilyen attitűdnek lennie.
Marhefka István
Oct 11th, 2010akocsis: Én egyszerűen egy teljesen más munkamódszert képviselek, mint amit Te (a blogbejegyzéseid és hozzászólásaid alapján merek erre következteni).
Ennek a két módszernek az ütköztetését nem tudjuk elintézni ilyen kommentelős, blogolós módon, ezért javaslom, hogy más fórumokon – ahol talán személyesen is találkozunk – próbáljuk meggyőzni egymást. (Úgy érzem, nem lesz könnyű :))
“A cég vezetői jól látták a dolgot…”
Azt nem írtam le, hogy miért nem került bele a leírásba az én eredeti mondatom… A vezetőség egyetértett vele. Ugyanúgy gondolkoznak, ahogy én, pedig ők nem voltak soha fejlesztők. Viszont sok szoftverfejlesztési projektet csináltak már sok ügyféllel. Olyan vezetőségről van szó, akik nagy cégekkel is tudtak már agilis szerződést kötni.
A vezetőség félelme az volt a mondattal szemben, hogy akik olvassák, nem értik meg azt.
akocsis
Oct 11th, 2010Állok elébe a megbeszélésnek
Janó
Oct 12th, 2010Hívjatok meg engem is! Érdekel a téma.
Ha a rendelkezésre álló pénzt és időt, mint erőforrásokat végtelennek tekintjük, akkor még jól is működhet az a modell, hogy
* Addig specifikáljuk a feladatot, amíg a specifikáció minősége eléri a megfelelő kis epszilonnyi finomságot.
* Ezt követően elegendő fejlesztőt teszünk a projektre, akik addig reszelik a programot, hogy elérje ugyancsak megfelelő kis epszilonnyi hibaszázalékot és megfeleljen a specifikációnak.
* Ehhez elegendő tesztelőt is rendelkezésre bocsájtunk, akik a fejlesztők munkáját állandóan tesztelik és ellenőrzik a specifikációban leírtakhoz képest.
* A Fejlesztők természetesen hibákat is javítanak…
Látszódik, hogy sok emberanyagra van szükség, viszont a specifikálókon kívül nem sokan mondanak véleményt a projektben. Gyakorlatilag aki megvalósítja az elkészülő szoftvert vagy segíti a megvalósulást, egyáltalán nem érdekelt abban, hogy az valóban jó legyen az ügyfél számára. Ő egy kisebb világban él, ahol van egy főnöke, ha a főnöknek tetszik a végrehajtó által elvégzett munka, akkor rendben is vagyunk, mindenki boldog… LESZ szoftver. Valamilyen.
A szoftverfejlesztés fenti módszertanát lefordítva a matematika nyelvére, ha a szoftverfejlesztés folyamatában felmerülő minden egyes tényezőt konvergens folyamatnak/függvénynek tekintünk, akkor a folyamatok együttes összege is konvergens lesz. Szóval boldogok is lehetünk.
Vagy mégsem? Két dolog aggasztó ebben a modellben:
* Hány függvény/folyamat/szakember szükséges? Milyen a költségvetése a projektnek? Van-e elegendő számú csak a saját szakterületéhez értő szakember a cégnél?
* Mi az együttes határidő? Elbírja-e teljes specifikáció megvalósítását a projekt határideje? Résztvevők számának növekedésével növekszik a teljesítés határideje is.
Én attól tartok, hogy fenti módszert matematikusok találták ki annak idején, amikor még nem sok tapasztalata volt a szakmának arról, hogyan is kell hatékonyan szoftvert fejleszteni. Ezzel nincs is baj, a baj azzal van, hogy nagyon sok helyen átvették ezt a modellt és mai napig nem tudnak szabadulni tőle.
Ha egy fejlesztő érdekelt az üzleti folyamatokban is, akkor miért ne szólhatna bele, azok alakulásába? Miért kell az embereket megmondókra és megvalósítókra kettéosztani egy projekten belül? Miért kell a projekt scope-ját kőbe vésni már az elején, amikor még az ügyfél azt se tudja, hogy mit akar? És még sok hasonló kérdés van…
akocsis
Oct 12th, 2010@Janó:
Nem írok hosszan, mert a cikk nem erről akart szólni. Csak annyit mondok, hogy a dolog nagyon jól működik a gyakorlatban, és a nagyok ezt használják.
Személyesen szívesen elmondom, hogy miért.
Marhefka István
Oct 12th, 2010akocsis: Ha jól működik, akkor nem kell változtatni rajta. Azonban érdemes elgondolkozni, hogy mi lehet a gond, ha a következő problémák ütik fel a fejüket:
- sokáig tart a projekt és sokba kerül,
- a végén az üzleti felhasználók nem azt kapják, amit szerettek volna,
- ha később a szoftvert tovább kell fejleszteni, nem lehet.
Tudok olyan nagyokat mondani, akik nem a hagyományos megközelítéssel dolgoznak. Pl. Google, Lockheed Martin (vadászrepülőgépek), Toyota.
Marhefka István
Oct 12th, 2010Janó: Annak, hogy a hagyományos megközelítés az elterjedtebb, az az oka, hogy évtizedekkel ezelőtt tényleg nagyon alaposan kellett megtervezni a szoftvert, mert minden – a tervnek nem megfelelő – változásnak/változtatásnak óriási volt a költsége.
Ez mostanra teljesen megváltozott. A rendszerek, amiket pedig fejleszteni kell, sokkal összetettebbek lettek.
Janó
Oct 12th, 2010Igen. Jobb eszközökkel a változtatásnak sokkal kisebb a költsége.A tisztán megírt kód pedig megengedi a változtatást, mert saját magát dokumentálja.
akocsis
Oct 13th, 2010Szerencsétek van, szombaton ráérek
11. kerületben lakok, de agilisan fel tudok máshol is bukkanni.
Email címem akocsis75 kukac yahoo pont com
Marhefka István
Oct 23rd, 2010Zsepitől: http://blogs.headspring.com/2010/10/18/FocusOnYourCoreCompetencyOutsourceEverythingElse.aspx
“It’s just about trying to be in lockstep and in good alignment with the client and the client’s goals rather than being accountable for building a set of functionality that performs certain tasks.”