DT blogi

Leidsin CIO.com sirvides päris põneva lugemise teemadel, mis kirjeldab lahkhelisid IT-juhtide ja arendajate vahel. CIO.com uuris IT-juhtidelt, mida peaksid arendajad teadma või tegema, et tulemused oleksid paremad ettevõtetele ja inimestele, kes loodud tarkvara kasutavad. Artikkel kannab pealkirja 8 Reasons Why CIOs Think Their Application Developers Are Clueless.

Peamised probleemid IT-juhtide jaoks (võiks võtta tõsiselt, sest nemad sõlmivad ja lõpetavad töölepinguid arendajatega) olid suures plaanis järgmised. Esitan iga punkti juurde oma seisukoha ka.

Et pea eest tulle sööstmist harrastavad arendajad minu peale pahaseks ei saa ja ennast kommentaariumis kogemata teistele rumalatena ei näitaks, siis mainin ära, et CIO. com koostas kunagi analoogse küsitluse arendajatele, saamaks teada, miks IT-juhte saamatuteks peetakse.

1. Arendajad ei mõtle praktiliselt

IT-juhid ootavad, et arendajad käituksid praktilisemalt ning ei leiutaks jalgratast. Kui on võimalik osta valmis komponente, mida programmides kasutada, siis on mõttekas seda teha. Tihti aga nii ei tehta. Selle asemel, et leida vajalikud komponendid, püüavad arendajad ise luua käepäraseid lahendusi.

Nõustun osaliselt selle probleemiga. Valmis komponentide kasutamisega on samas see häda, et neid tuleb enne testida - muidu ei saa kindlalt väita, et see ja too komponent vastab kõikidele esitatud nõuetele, kuigi mõne jooksva probleemi lahendab see sujuvalt ära.

On igasugu muudki jalgratta leiutamist ja peamine häda, mida ma olen näinud ja millega ma olen ise kokku puutunud pea igal pool, kus ma olen töötanud, on järgmine -

2. Arendajad ei suuda mõelda lõppkasutaja keskselt

IT-juhid ootavad, et arendajad oskaksid oma töötulemustele vaadata ka lõppkasutaja seisukohalt, kellel on paraku hoopis teised prioriteedid kui arendajatel. Süsteem võib lahendada igasuguseid probleeme ja olla väga efektiivne oma funktsionaalsuselt, kuid kui lõppkasutajal on seda raske kasutada või kui kasutamine on tema jaoks ebamugav, siis ootab seda süsteemi kuulsusetu surm.

Jah, nii see on. Paljud arendajad panevad peamise rõhu sellele, et kuskil sügaval süsteemi kõhus toimiks kõik nii nagu peab. Lõppkasutajatega seonduv on neile tihti teisejärguline ja tehnilises mõttes liiga lihtne problemaatika.

Sellise suhtumise taha on surnud nii mõnedki head lahendused, samuti on sellise suhtumise tõttu päris paljud süsteemid ebamugavad ja keerukad kasutada.

Minu meelest tuleb teha lõppkasutajatega tihedat koostööd, et jõuda just sellisele tulemusele, nagu neil on vaja. Just see grupp inimesi teab seda, mis on nende tööd peamised liigutused, mis on vähemtähtsad liigutused, millised on praeguste süsteemide ebamugavused ja millised asjad on praegustes süsteemides lahendatud hästi. Ilma selle infota on ka süsteemi ehitamine nagu seotud silmadega märki laskmine.

3. Arendajad ehitavad ebavajalikke lahedaid asju

See probleem on isegi laiem, kui võiks arvata. See pole ainult IT-juhtide mure, vaid ka projektijuhtide ja tellijate mure. Arendajad püüavad olla innovatiivsed ning ehitada valmis rohkem kui on vaja. See läheb enamasti vastuollu käsiloleva projekti peamiste nõuetega, mida esitatakse töökindlusele, tööprotsessidele ja süsteemide hallatavusele.

Igasuguste lahedate asjade asemel soovivad nii IT-juhid kui ka lõppkasutajad midagi muud - neil on vaja töökindlaid süsteeme, mis täidavad neile ettenähtud ülesandeid.

Mõneti haakub see punkt esimesega. Kuigi on igati tore anda oma panus süsteemi täiuslikkusesse igasugu algselt vahvatena tunduvate lisavõimaluste abil, võib see osutuda karuteeneks.

Iga osa süsteemist võib olla see koht, kus tekivad probleemid. Mida suurem on süsteem ja mida keerukam ta on, seda keerukam ja aeganõudvam on ka selle haldamine, monitoorimine ja vigade korral lappimine.

4. Arendajad ei pea silmas oma tegevuse ärilisi prioriteete

IT-juhtide hinnangul puudub arendajatel arusaam süsteemide ärilisest tasuvusest. ROI (Return Of Investment), TCO (Total Cost Ownership) ja muud vahvad kolmetähelised, mida magalarajooni hoonete seintele kritseldatuna ei leia, on olulise tähtsusega näitajad ärilises mõttes. Nõusolek ühe või teise süsteemi ehitamiseks sünnib enamasti mõne taolise näitaja hindamisel.

See on koht, kus IT-juht võib jääda kahe tule vahele. Ühel pool on arendajad, kes ei saa aru sellest, et valmiv süsteem peab saama just selleks ajaks just sellisel kujul valmis ja mitte üks kriips lahedamalt. Teisel pool aga on ettevõtte juhatus, kes ootab, et projekt püsiks antud ajalistes ja rahalistes raamides. Seda kõikide etappide lõikes - kuni juurutamise ja järeltoeni välja.

See on probleem, mida annab kergesti vältida. Arendajatele tuleb lihtsalt ära rääkida, milleks seda süsteemi ehitatakse, milline peab olema lõpptulemus ja millisel kohal ettevõtte strateegias antud süsteem paikneb.

Tihti on see just IT-juhtide enda süü, et leiutatakse lihtsa tõukeratta asemel uus väike Ferrari ning minnakse nii ajalistest kui ka rahalistest raamidest välja. Arendaja jaoks on see suur erinevus tema enda töös, kui ta peab ehitama valmis killer application-i, mille vastast turul pole või kui ta peab arvestama sellega, et süsteem olgu pigem lihtne ja töökindel, kui koormatud kõiksugu meeldivate lisavõimalustega.

IT-juht, kellel on vaja just viimast, ajab aga tihti arendajad nõukarisse kokku ning esitab loo, mis kirjeldab just esimest. Siit tekib ka lahkheli, sest vajadus on lihtsa ja võimalikult töökindla asja järgi, kuid arendajatele anti tööülesandeks ehitada valmis süsteem, mis on tõsine relv igas oma aspektis.

5. Arendajad ei saa aru süsteemi otstarbest

IT-juht on ühelt poolt nagu tellija, kes tellib arendajate käest töid ning teiselt poolt nagu ärimees, kelle klientuuriks on juhatus. Juhatus tellib süsteemi mingi kindla tegevuse hõlbustamiseks. Sellel tegevusel on olemas mingisugune äriline väärtus. Juhatuse jaoks on tihti IT nagu elekter - nad kasutavad seda, kuid nad ei tea, mis see on. Nad tahavad lihtsalt seda, et nad saaks vastuse oma küsimusele ja nad tahavad seda lihtsasti.

Kõige hukutavamaks on siinjuures arendajad, kes ei saa aru, et see, mida neilt oodatakse võib olla lihtne mängimine andmetega, sisendiks väärtused paarilt tekstiväljalt ja rippnimistust ning tulemuseks peab olema lihtsalt tabel mingite tulemustega.

Tihti on vaja lihtsakoelist asja, mis toimib. Selle põhjal otsustatakse edasi, kas on vaja midagi juurde või kas on vaja midagi muuta. Otsuse tegemiseks pole aga vaja ehitada ei uut raketti ega transatlantilist vaakumtoru.

IT-juht ja temale alluvad arendajad satuvad aga kõik väga halba valgusesse, kui arendajad hakkavad ehitama raketti ning väljuvad ajalistest graafikutest. Juhatus ei saa aru, miks sellise väikse asja tegemine on nii mahukas, sest IT-juht sai arendajatega töid hinnates algselt hoopis teise tulemuse.

6. Arendajatel puudub arusaam IT-juhi rollist

Arendajad ja IT-juhid on oma taustalt küllaltki erinevad. IT-juhid tulevad peamiselt operatsioonide poolelt ja arendajatele on omane lähtekoodi ja süsteemide taga peituva tehnika maailm. IT-juht peab nägema kogu ettevõtte infotehnoloogiat ka suures plaanis ning langetama oma otsused palju ulatuslikumal tasandil, kui üks või teine ekraanivorm.

Artiklis on toodud tabav võrdlus - IT juht peab tegelema paljuski ebakindlusega, mitte selgete ja kindlate hard code-itud reeglitega. Siit tulevad ka erinevused arusaamades.

Selleks, et süsteemid edukalt valmiksid, peavad kõik osapooled teineteisest aru saama. Arendajad kapselduvad tihti üheks lapsikuks jonnipunnide pundiks ning ajavad oma rida, kui nad ei tea, millist vastutust kannavad ja millised otsuseid teevad inimesed, kes neile ülesandeid annavad.

Jällegi, ma leian, et see on koht, kus IT-juht peab ise selgitustööd tegema. Arendajad peavad aru saama sellest, mis maani ja millistel tingimustel saab IT-juht hoida asju sujumas.

Samuti peavad arendajad aru saama sellest, et lapsik jonnimine lõpeb sellega, et IT-juht ei saa neid enam kuidagi aidata ega kaitsta, vaid peab leidma juhatusega koostöös võimaluse projekt jälle rööbastele tagasi saada. See võib tähendada seda, et ennast nõrgimaks lüliks taandanud arendajad on antud projekti mõttes ballast, mis tuleb asendada efektiivsemate inimestega.

7. Arendajatel puudub grupile omane mõtlemine

Huvitav probleem, mida mõned IT-juhid on täheldanud, seisneb järgnevas. Kui kutsuda kokku arendajad ning pidada nendega nõu erinevatel süsteemi puudutavatel teemadel, siis on tulemuseks konsensusel põhinevad lahendused. Kui samade arendajatega aga eraviisiliselt suhelda, siis pole neist pea keegi nõus tolle konsensusega, milleni eelnevalt jõuti. See probleem jõuab omakorda välja selleni, et mõned arendajad, kes ennast aja jooksul on Universumi direktoriteks hakanud pidama, teevad asju kõigest hoolimata hoopis teisiti kui kokku lepiti.

Poolt ja vastu korraga. Primadonna suhtumisega arendajad on igas ettevõttes põhimõtteliselt ülejääk, kuna soov mõne elundi mõõtmete muutmise järgi tuhmistab selge ja kaalutleva mõtlemise. Sellist asja nagu IT-juhtide poolt oodatav grupile omane lähenemine on aga lahenduste surm.

On väga hea, kui arendajate tiim suudab omavahel leppida kokku, kuidas ja mida oleks antud hetkel parim teha. See ongi see ühine otsus - see oodatav tiimi otsus - mis välja öeldakse. Ja sellest tulebki lähtuda.

Igal arendajal on loomulikult erinev arvamus. Ja nii peabki olema. Kui kõik ühtemoodi arvaksid, siis oleks süsteemid olematu kvaliteediga, kuna keegi ei märkaks teiste vigu või ebapädevaid lähenemisi erinevatele probleemidele. Ja loomulikult, kui minna ja vestelda eraviisiliselt mõne arendajaga, siis tema arvamus on erinev. Põhjus on lihtne.

Koosolekul pandi lihtsalt paika see, milleks kõik on võimelised ja millest kõik aru saavad. Eraisiku tasandil aga lahendaks igaüks probleeme pisut erinevalt kui teised, sest kogemused on arendajatel väga erinevad.

8. Arendajad ei mõista personalipoliitikat

Viimase probleemina toovad IT-juhid välja arendajate umbuskliku suhtumise sellisesse populaarsesse teemasse nagu outsourcing. Arendajad kardavad, et nad asendatakse kordi odavama tööjõuga, mis paikneb küll kaugel, kuid mida on piisavalt odavalt piisaval hulgal saada, et see kaaluks üles distantsist tulenevad probleemid.

IT-juhtide mure on aga hoopis vastupidine - kohalikud turud on suuresti tühjaks imetud headest arendajatest, nende järgi on väga terav puudus ning ülikoolid ei suuda inimesi piisaval arvul IT-turule tuua. See tähendab seda, et on tööjõu kriis, mida vähemasti ajutiselt tuleb leevendada tööde väljast hankimisega.

Lõpetuseks - kuidas teha nii, et keegi poleks saamatu?

Minu isiklik tagasihoidlik arvamus on see, et kommunikatsioon ja üksteise mõistmine aitavad ära hoida paljud probleemid. Inimestega tuleb suhelda, teiste inimeste seisukohti ja arusaamu tuleb osata hinnata ning vajadusel osutada nende eksimustele - seejuures tuleb alati selgitada, et mis põhjusel on selline või teistsugune lähenemine kas väär või ebaefektiivne.

Samuti tuleb mõista seda, millist vastutust sisaldavad endas rollid, mida üks või teine projektis osalev inimene kannab. Millised on nende oskused ja milline on nende teadmistepagas. Need on olulised teemad, sest ilma teiste olukorda mõistmata on neile lihtne oma ainuisikuliste otsustega liiga teha või nad lihtsalt võimatusse olukorda asetada.

Lõpetuseks - hoolimata positsioonist ja rollist oleme me kõik inimesed ja meie edukus sõltub sellest, millised me oleme. Lipsu pikkus, töötooli mugavus, laua suurus - need ei tee meist kedagi teistest paremaks või halvemaks.

Kirjutas Gunnar, 13.09.2008 kell 12:50, teemal Tarkvaraarendus, Äri. Jälgi selle postituse kommentaare läbi RSS-uudistevoo (feed). Lisa kommentaar või tagasisideviide (trackback) oma veebilehelt või blogist.