Comments on: Kaheksa põhjust miks IT-juhid arendajaid saamatuteks peavad

By: Süsteemiarendaja 7 käsku

Süsteemiarendaja 7 käsku — Thu, 27 May 2010 19:10:51 +0000

[...] eksitakse pidevalt lihtsate reeglite vastu. Seekord inspireeris mind mõtted paberile panema blogipostitus, mis kirjeldab klientide pettumusi arendajate suhtes. Uurides aga efektiivseid arendajaid, selgub, et nende mõtteviisis on teatud sarnasused, mis [...]

By: asd

asd — Thu, 25 Sep 2008 07:47:20 +0000

> On siililegi selge, et “staarid” tuleb panna laehndama keerukaid
> probleeme ja nyri igavat käsitsitööd kasutajaliidese kallal tuleb
> treima panna nooremprogrameerija esimese aset2itja abid.

offf, mida sa nüüd öelda tahtsid? punkt 2 (et siis lõppkasutajakeskselt mõtlemise) juures räägid naakadest kasutajaliidese kallal?

By: Gunnar

Gunnar — Mon, 22 Sep 2008 21:51:16 +0000

Siim, elu on näidanud, et kõik need head plaanid suudab ühe lauluga nulli lasta näiteks olukord, kus tellija ise suurt ninapidi kõige juures ei istu ning laseb kõiksugustel vähem tehnilistel pudividinatel otsustada ja juhtida. Edasi pole muud vaja, kui seda, et taolised tegelased koostavad arendajatele taskid valmis ja ongi järjekordne hullumaja käes

By: Lembit

Lembit — Mon, 22 Sep 2008 19:32:22 +0000

Olen erinevatel ametitel olnud erineval poolel - nii arendaja kui ka arendust telliv klient.
Oma kogemustest võin öelda et paljudki IT juhid (väga vabandan kui mõni tunnneb end puudutatuna) ei oma pädevust seda ametit pidada.
Näitena võin tuua olukorra kus kliendi (tarkvara tellija) IT juht arendustarkvara firmaga läbirääkimisel küsib: “Mind vaevab üks küsimus, kord räägite te PHP-st ja kord räägite te MySQL-ist, minu küsimus on et millest te siis ikkagi selle süsteemi lõpuks teete, kas PHP-s või MySQL-is? Tean siis oma it mehi informeerida.”
Olgu siin mainitud et eelnimetatud kliendi ettevõtte suurus oli 150-200 inimest - ei ole just väikeettevõte.

Moraal: eelkirjeldatud näite puhul kui juba IT juhi või proj. juhi tasemel tekib selline infokadu, siis kujuta ette mis info jõuab arendajani. Ei ole ime et lõpptulemus on see et klient tellis aia aga arendajad tegid valmis aia augu.

Lisaks tänap. IT / Proj. juhtidel on kombeks suusõnaliselt või lühikirjelduslikult edastada kliendi tellimus.
Juht edastab arendajale et klient tahtis “autot”, arendaja teeb “auto” valmis. Auto edastatakse kliendile ning klient esitab pahameelt et ta tahtis “automaat käigukastiga” ja “universaal kerega” “autot”. Arendajad teevad “auto” ümber ja kliendil leidub jälle 100 põhjust millega mitte rahul olla.

Tihtipeale juhid “rebivad” kõvasti nalja kliendiga läbirääkimistel selleasemel et kõik korralikult kirja panna.
Samas kui klient küsib “autot” siis ei kiputa täpsustama et missugust autot, mis värvi, kui suurt jne jne.
Moraal: kliendiga suhtlemisel tuleb kõik kirja panna ning hiljem mõlemapoolselt kokkuleppida et kas on ikka üheselt arusaadud, vältides sellega hilisemaid probleeme.

Olles arendaja poolel siis viimane näide tegelikult on äripoliitiliselt arendusettevõttele kasumlik. Kui klient tellis auto siis teeme talle auto. See et klient tahab automaat käigukastiga, selles pole kokku lepitud seega ” hilisem lisaarendus” ja kliendi rahakotti pigistatakse mõnuga.

…
ma ei viitsi rohkem kirjutada, võtan lühidalt kokku:
…
kogu selle crapi point on see et arendajad teevad täpselt nii head tööd kui head tööd on teinud IT / proj. juht.
Leidub ka erandeid.

By: Siim

Siim — Mon, 22 Sep 2008 16:14:39 +0000

Siinkohal näen peamiste võlurohtudena:
1) Ole vastutusvõimeline ja proaktiivne - kummuta oma kahtlused ja maanda riskid suheldes
2) Enne töö alustamist tee selgeks ülesande tegelik eesmärk ning selle mõistlik eeldatav ajakulu/investeering
3) Enne lahenduse väljapakkumist veendu, et mõistad ülesande olemust ja vajalikkust maksimaalselt
4) Otsi sünergiaid, loo ja kasuta taaskasutatavaid komponente
5) Lahenda esmalt ärikriitiline funktsionaalsus - prototüüp minimaalse funktsionaalsusega. Alati saab asju keerukamaks teha, mis omakorda ohustab keskendumist olulisimale.
6) Hoia suurt pilti silme ees kogu arenduse vältel. Ole pidevalt kursis, kui kaugel reaalselt asud - palju tehtud, palju veel teha. See ei ole ainult projektijuhi ülesanne.
7) Ole pidevalt empaatiavõimeline ja müü uut funktsionaalsust kliendi ärivajadustest lähtuvalt.

By: Offf

Offf — Tue, 16 Sep 2008 13:56:35 +0000

No vott. Aga “code monkeysid” on meil massiivselt palju ja Tõelisi Programeerijaid kole vähe. Võiks lausa öelda, et code monkeyd moodistavad massiivse enamuse sellest neegrikarjast kes tasapisi määratuid ärirakenduse-monstrume ehitab. (ja muid jõledusi, mida tuleb hallata).
Ja ikka ja j2lle kerkib kysimus: “Kui kaua peab jooma, et sellist asja produstseerida”

By: Gunnar

Gunnar — Tue, 16 Sep 2008 09:36:15 +0000

Ma kardan, et küsimus pole mitte niivõrd aastates kuivõrd inimeste suhtumises. On neid, kes ka peale kümmet aastat kirjutavad sama läbimõtlemat aja algajalikku koodi kui esimese kursa junsud. Samuti on esimese kursa jõnglaste hulgas neid, kes suudavad kirjutada täiesti adekvaatset koodi. See kõik on pigem kinni inimeses endas.

By: Offf

Offf — Mon, 15 Sep 2008 12:54:47 +0000

Gunnar: minu blogis on olnud piisavalt karjatusi stiilis: “Mida peab suitsetama, et selliste “lahenduste” peale tulla!”
Kunnar: 10 aastase kogemusega arendajatega enamasti polegi seda probleemi, et mida nad suitsetavad. Nemad on oma keelatud ainete kogused juba 2ra suitsetanud.
Probleem eksisteerib noorte, II kursuselt otse koolipingist kuubikusse v2rvatud jaava-arendjatega, kes produtseerivad t6eliselt Halba Jaavat. Produtseerides jubeda kvaliteediga mooduleid mitmesugusele 2ritarkvarale.
Mul on n2iteks tihedad kokkupuuted umbes 4 kontoriga. Neist 4jast kontorist 1 sisaldab Arendajaid, kes toodavad Koodi. Yelj22nud kolm kasutavad allhankijatena laste orjat88d ja tulemuseks saadud kood on suhteliselt jube. Isegi minu, mitte-arendaja vaatevinkilst vaadatuna.
Enamasti mitte lihtsalt halb vaid Halb sellises thedailywtf stiilis - TRUE/FALSE/FILENOTFOUND.

By: Gunnar

Gunnar — Mon, 15 Sep 2008 10:53:55 +0000

Enamasti tekib igasugust jama siis, kui keegi tehnikakauge tegelane paneb paika selle, kuidas süsteem peab toimima kuskil sellisel tasemel, kuhu tal asja pole. Tulemuseks see, et hulluks lähevad kõik, kes seda asja peavad elus hoidma. Ei pääse ei arendajad ega adminid…

By: Priidik

Priidik — Mon, 15 Sep 2008 09:12:27 +0000

Mina olen aru saanud, et arendajate ja adminnide vahelise vastuolu peamine põhjus on selles vaidluses, kes peaks tööd tegema. Õigemini kes peaks vähem tegema. Kas asjad peaks lahendama serveri tasemel või peab koodi kirjutama võimalikult nii, et see sobiks olemasoleva serveriga.

Eks arendaja oskus ole siin panna adminnile mõte pähe, et tegelt on see muudatus adminni mõte. Praktikas aga on see keeruline ja ajab närvi