Derrick és Harry Projektmenedzsment Blogja

A három napos egy órás feladat

2014. március 23. - TanacsLajos

daystohours.png

Van egy kérdés, ami folyton kísért. Egy kérdés, ami újra és újra megtalál a projektek során. Ezerszer megválaszoltam már, és már nem akarom soha többször, ezért most megírom a választ mindenkinek, akit érdekel. Aztán ha megkérdezik, nem mondok majd semmit, csak átadok egy kis kártyát majd, amin ennek a cikknek az URLje szerepel.

Hogy mi a kérdés? Hát az, hogy "Mi tart ezen a feladaton három napig??"

A három helyére persze lehet 147-et, vagy hat órát, vagy akármit írni. A lényeg az, hogy a kedves megrendelőnek mindig nagyon határozott elképzelése van arról, meddig is tart egy adott szoftverrészt elkészíteni vagy módosítani, még akkor is, ha informatikai ismeretei véget érnek az iPad háttérképének beállításánál, legkomolyabb számítástechnikai teljesítménye pedig még '92-ben volt, amikor megnyerte az osztályban rendezett Tetris versenyt gimnáziumi számtek órán.

Ez a határozott elképzelés kivétel nélkül mindig lényegesen kevesebb, mint amit a szakember (fejlesztő) mond, és kivétel nélkül mindig lényegesen kevesebb, mint amennyi idő alatt az adott feladat megvalósítható. Miből adódik ez a markáns véleménykülönbség? Hát abból, hogy általában a megrendelőknek a programozók munkájáról alkotott idealista képük igencsak messze van a rideg valóságtól.

Vegyünk most egy egyszerű példát, amin keresztül ezt a különbséget meg szeretném világítani. Tegyük fel, hogy felmerül egy nagyvállalati rendszerben két menüpont módosításának igénye: az egyiket arrébb kell rakni, a másikat át kell nevezni.

Lássuk, hogyan képzeli el a feladat megoldását és erőforrás igényét egy átlag megrendelő:

  1. Számítógép bekapcsolása (5 perc)
  2. Fejlesztői környezet indítása (3 perc)
  3. Egyik menüpont áthelyezése drag-and-drop technikával (1 perc)
  4. Másik menüpont átírása: eredeti szöveg backspace billentyű nyomkodással történő törlése, majd új beírása (2 perc)
  5. Egy csésze kávé elfogyasztása (7 perc)
  6. Módosítások megtekintése a fejlesztői környezetben (3 perc)
  7. Mentés, fejlesztői környezetből kilépés, számítógép kikapcsolása (4 perc)

Ez összesen 25 perc, legyünk nagyvonalúak, szorozzuk meg kettővel és kerekítsünk fölfelé, még így is megvan a dolog egy órán belül.

Mi történik ezzel szemben a valóságban?

  1. A fejlesztő és a projektvezető végigzsibbadnak egy 2 órás meetinget, ahol a résztvevők 20 percig vitatkoznak arról, mi legyen pontosan az őket érintő menüváltoztatási kérelem. (2 x 2 óra)
  2. Három nappal később megérkezik levélben leírva a változtatási kérelem, ami azonban nem egyezik a megbeszélésen elhangzottakkal. Négy telefon és három email születik a témában. (2 óra)
  3. A véglegesnek látszó írásos követelmény alapján a fejlesztő kibogarássza a szoftverben, hogy hol is van a menük szövege és szerkezete tárolva, nem tudja fejből, hiszen már 8 hónapja senki se nyúlt ahhoz a részhez. (1 óra)
  4. A fejlesztő lassan megérti a menüt leíró kódrészt, és rádöbben, hogy a korábbi quick & dirty megoldások miatt át kell szerkesztenie a teljes menüleíró XML fájlt, és még négy helyen bele kell nyúlnia a controller osztályokba. (3 óra)
  5. A fejlesztő kipróbálná a saját környezetében a módosítást, de a gépén levő WebSphere összeomlik, és nem indul el többet hosszas próbálkozás után sem. (2 óra)
  6. Más választása nem lévén, a fejlesztő a változtatását berakja a repository-ba, és telepíti a módosítást a fejlesztői integrációs tesztrendszerre. (1 óra)
  7. A módosítás tesztelésekor kiderül, hogy egy helyen még át kell írni az alkalmazást ahhoz, hogy a NullPointerException-ön túl egyéb funkciók is elérhetők legyenek. A javítás megtörténik. (1 óra)
  8. A javítás után újabb telepítés, újabb teszt, ami ezúttal sikeres. (1 óra)
  9. A változtatás kikerül az UAT környezetre (2 óra), ahonnan azonnal 6 darab kritikus hibajelentés érkezik, mert a menü nem felel meg a tesztesetben leírtaknak. (2 óra)
  10. Heves vita után a tesztelők meghátrálnak, és duzzogva elvonulnak tesztesetet módosítani, a hibásan felvett hibajegyeket lezárják. (2 óra)
  11. A módosításra élesítés előtt egy nappal ránéz a megrendelő terület, majd szirénaszerű reakciókat hallatva juttatja mindenki tudtára, hogy ezzel így nem lehet dolgozni, a módosítás elfogadhatatlan. (1 óra)
  12. A fejesztőnél csörög a telefon, aki reszkető gyomorral kutatja fel az emailt, amiben a fejlesztés leírását kapta napokkal azelőtt. Fellélegezve látja, hogy ő azt csinálta meg, ami le volt írva, a levelet boldogan küldi szét mindenkinek. (1 óra)
  13. Újabb megbeszélés a témában, ahol a felelősség áttolásának és az egymásra mutogatásnak a magasiskolája zajlik. A beszélgetés üvöltözésbe és ajtócsapkodásba torkollik, majd a fejlesztő megadja magát, és bevállalja a módosítás módosítását. (2 x 1 óra)
  14. Programozás, tesztelés, nem jó, újra programozás, újra tesztelés, már jó, becsekkolás, telepítés UAT-ra, újra tesztelés, most már tényleg jó mindenkinek. (4 óra)
  15. Élesítés során a fejlesztőt berendelik, hogy asszisztálja végig az üzemeltetőket, aki rezignáltan végigüli a telepítést este 8-tól 11-ig, majd hazamegy. (3 óra)

Ez összesen kb. 4 napnyi munka, de legyünk optimisták és higgyük azt, hogy nem fogunk minden fent felsorolt problémával szembesülni, úgyhogy legyen 3 nap.

Hát ezért tart három napig, és nem egy óráig. Van még kérdés? Ugye nincs? Na, akkor hajrá, lehet indítani a megrendelőt :)

A bejegyzés trackback címe:

https://derrickesharry.blog.hu/api/trackback/id/tr265875189

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Jace Brennan 2014.03.24. 13:19:08

Szerintem a fenti valóságot leíró eseménysor egy kissé optimista, de ezt leszámítva remek post.

Szakyster 2014.03.24. 22:50:18

@sajnos_kacat: Hát, kicsit irigykedek, hogy adtak neked annyi időt, hogy egy ilyen rendszert összerakj, és nem az volt, hogy "egy diák fél éve elkezdte, 3 hónap után elment, van rá két napod, hogy minden működjön".

mennyémá 2014.03.25. 07:10:07

@sajnos_kacat: majd szólj, ha sikerült összehozni bármilyen, a "hello world"-nél összetettebb programot, amihez a sötét szobád magányánál több kell. Látszik, hogy legjobb esetben is a sarki fűszeresnek írtál bármit,nagyvállalati környezetben előforduló managerről meg még olvasmány élményeid sincsenek. nem baj, egyszer majd felnősz és akkor csúnya meglepetések fognak érni.

retikanya 2014.03.25. 08:22:02

@sajnos_kacat: A leírás alapján még nagyobb összetettebb enterprise környezetben nem volt szerencséd (?) dolgozni. Én számos esetben javítottam már ilyen MVC alakalmazásokat is, és nyugodtan mondthatom nem nagy élmény egy tök ismeretlen kódban rájönni ki mit miképp szokott elkészíteni. Igen van a pattern, de aztán e mellett is számos út létezik, s persze aki írta a kódot meg az én általam követett nem szokott megegyezni. Kivétel meg még egy trükkösebb karakternél is összejön és utána derül ki mi is az code page és hogy a szervered mást kér mint amit te adni tudsz...

CIB poszt toló 2014.03.25. 13:12:55

Előző munkahelyemen szállóigévé vált az egyik ügyfélnél egy új funkcióról történő egyeztetés során elhagzott "Három nap? De hát ez csak egy új gomb a UI-on!..." mondata.

Hokunda 2014.03.25. 21:34:40

Egy olyan szoftveren amit sok ember írt sok éve, akik közül már senki sem dolgozik a cégnél bizony egy gomb funkciójának aprócska megváltoztatása is sokáig tarthat, feltéve, hogy egyáltalán megvan a forráskód és szerencsés esetben ha lefordítom még ugyan azt a végeredményt is produkálja, amit épp használnak.
A post jól szemlélteti azt, hogy a project alapú szemlélet fenékvédésre kiváló, valamint, hogy a funkció pontos definiálása tovább tarthat, mint az egész fejlesztés teszteléssel együtt.
A poszt arra sem tér ki, hogy ha valaki mégiscsak ki akarja spórolni a tesztelést, merthogy annak úgysincs értelme és ezzel lehet spórolni 5%-ot, akkor a szétment adatbázis javítása az egész project idejének sokszorosára nyúlhat.

xxylon 2014.03.25. 22:38:32

En nem ertek a szoftvertervezeshez de akkor most egy ekkora rendszerben ez az egyetlen megoldas? Ez igy most jol van? Mert se hatekonynak se atgondoltnak nem tunik.

piszter 2014.03.26. 13:24:43

@xxylon: Ha nem így működne, nem lehetne lekaszálni érte egy valag pénzt, és sok apuka meg anyuka nem lenne foglalkoztatva, ami azért komoly gondokat okozna nemzetgazdasági oldalról is! Persze nem "csak" ettől bonyolult ez...

TrefaRepa 2014.03.26. 14:54:12

A hatékony munkavégzés magasiskolája..

"Higyjük" vagy inkább higgyük?

ramirez7788 2014.03.27. 00:08:07

Pfff, eléggé elszégyellném magam, ha az általam fejlesztett szoftverben egy felirat módosítása nem csak egy resource fájl szerkesztése lenne :)

Persze bár a példa rossz, a mögöttes tartalom azért rendben van, és a mítinges sztori még így is megállja a helyét. :)

b0c1k4 2014.03.27. 10:25:18

@ramirez7788: Azert nem egy hello worldrol beszelunk. 1 mivan ha a lokalizalt felirat nem resource fileban van hanem db-bol jon, vagy ne adj isten egy zippelt filebol? (mert anno ez volt a megrendelo igenye mert draga a tarhely). Szep hogy kezzel megmodositod de az eles rendszeren ki fogja? Db eseten mindjart db insert, amit tesztelned kell. Es akkor meg az sorrendrol nem is beszeltunk.(pl ha inkrementalis a sorrend az adatbazisban akkor az osszes felette levo mezot megkell modositanod).

"általam fejlesztett szoftverben". Az esetek nagy tobbsegeben az adott fejleszto mar reg elment a cegtol mire te odakerulsz. Kurvara nemtudod hogy rendereli a feliratokat, az se biztos hogy hagyott hatra dokumentaciot.

Az a baj hogy itt mindenki felreerti a peldat. Itt egy enterprise (nalam mondjuk ez szitokszo) rendszerrol van szo. Amit nem te irtal, lehet hogy neked csak bele kell nyulnod. Az se biztos hogy tudod hogy a menupontok felirata honnan jon, mert nem volt 3 honapod hogy a meglevo kodot "atvedd" es atnezd, plusz megkerdezd a feladatok kiosztoit hogy ez es az miert pont ugy lett megcsinalva.

Lehetne-e hatekonyabban/jobban csinalni? Persze. Ha minden fejleszto irna teszteseteket. Ha a necces vagy nem egyertelmu kodokat dokumentalna. Ha lenne idod megerteni egy rendszert amit nem te irtal.

Lehet a label atiras rossz pelda volt mert tul egyszeru. hozhatott volna az SAP integracios reteg modositasara egy peldat, csak lehet hogy arra a kedves olvasok tobbsege csak pislogott volna.

Vajon_minek 2014.04.18. 08:11:29

A legjobban az emberek idealizmusa tetszik a "komoly" rendszerekkel szemben.

A helyzet az, hogy egy "komoly" rendszer (értsd: na'ccég terméke, több száz fejlesztő munkája) kevés kivételtől eltekintve mindig egy óriási töcskölés, tele "időre optimalizált" megoldásokkal, kerülőutakkal, stb.

Ideális megoldások valójában csak kis projectekben, és az opensource világban léteznek. Ez van.

resystance 2014.09.23. 17:34:02

Teljesen átérzem a dolgot, kicsit jobban is érzem magam.

@xxylon: Az a tapasztalatom, hogy a megrendelők azt hiszik, hogy a programozók programozásra szánt segéd-szerkesztő-programokban ügyködnek vígan, amik a kezük alá dolgoznak, és nem is feltétlenül ők tévednek. A kezdetek kezdetén nekem is kb. eddig terjedt a szoftveres fantáziám, hogy meg fogok ismerkedni idővel egy olyan programozói programmal, ami elég fejlett ahhoz, hogy szándékom véghezvitele közben ne kelljen vért izzadnom.

A valóságban minden ennek az inverze, nekem kell megteremtenem a szoftvert a nulláról több tízezer vagy százezer soron át. Kicsit olyan, mintha nekem kéne vezérelnem egy tükör működését, de a tükör előtt álló embernek (megrendelőnek) arról fogalma sincs, hogy a tükröt (programot) nem a természet szülte ilyenre, hanem teljesen kontrollált a tükörben látott látvány.

A programozásban pont az a szép, hogy "bármit" "bárhogy" meg lehet csinálni és ugyanaz lesz az eredmény, de nincs két olyan programozó, akik egyetértenének egymás kódjával. Ha mégis, azok nemtől és kortól függetlenül összeházasodnak.

És ez csak a kezdet, hogy mindent nekem kell legyártanom, amiről a normális ember azt hiszi, hogy az már adott volt. Ott vannak még a hibák. Pl. webfejlesztőknél JavaScriptben hiába felel meg minden a tankönyvben leírtaknak, vannak olyan esetek, amikor a böngésző rejtett működését nekem kell kitalálni és a nem látható problémára megoldást csinálni, mindezt persze tegnapra. :) A szoftvercégeknél nemhogy a normális melóra nincs idő, a böngésző rejtett titkaival való barchobára pláne nincs, és ilyen egy átlagos munkahely. Volt olyan feladatom is, amivel délutánra kész kellett lennem, de én már akkor tudtam, hogy ez egy 3 hónapos meló. Előbb utóbb a mentálisan egészséges programozó is székletürítési problémákkal fog küzdeni, ha nem adja fel és komolyan gondolja, hogy ő programozó egy cégnél.

Szóval kicsit durván fogalmazva, nem csak a megrendelőkkel kell megküzdenünk, hanem ott vannak még a kollégák, akik néha igen korlátoltak tudnak lenni, meg a főnökök, akiknek van némi rálátásuk a szoftveres világra, de nem ők ülnek a gépem előtt és küzdenek a szoftverrel néha napi 20 órán át, hanem én, de az akaratuk a tudásukkal ellentétben igen erős. És ez csak a felszín, tudnék mondani még 1000 példát, hogy a szoftverfejlesztők élete miért nem csak játék és mese, és ezen felül még tanulni is kell az új szakmai fogásokat folyamatosan. Ja és a fizetés... azért a munkáért, amit egy komolyabb tudású programozó hónapról hónapra letesz az asztalra, 300 fölöttit kéne keresnie egy normális világban (szerintem), ezzel szemben én egész életemben minimálbér és 100 ezer huf közötti pénzekért izzadtam Nagyokat. Persze vannak ellenpéldák, akik valamiért jó helyen kötnek ki, de én nem sokkal találkoztam.

Mindezektől függetlenül én abban a világban rekedtem, ahol az az elképzelés volt uralkodó, hogy programozni szép és üdítő foglalatosság, és 10 év vért izzadás alatt el is jutottam addig, hogy olyan fejlesztőrendszert írjak magamnak, amiben hasonlóképp lehet dolgozni, mint ahogy azt az egyszeri laikus megrendelő elképzeli.
süti beállítások módosítása