Projekt késések
Kérdezném a kedves kollegákat, hogy igaz-e, hogy van olyan mondás, hogy ha a fejlesztőt megkérdik, mennyi időre van szüksége egy projekthez, akkor a válaszát meg kell szorozni 2-vel?
A késéssel en bloc mint problematikával kapcsolatban kérdeznélek titeket. Napra pontosak vagytok? Állandóak a kisebb késlekedések? Ügyfelek hogy viselik? Vannak elhúzódó késések? Kötbért vállaltok? Késés esetén vannak belső viták a cégben, ki a felelős?
Nem hinném, hogy igazságos dolog a fejlesztőre hárítani az egészet, és ezzel elintézni, mert én úgy tapasztalom, hogy létezik egyfajta maximalizmus az ügyfél, és a menedzser részéről is, akinek piszkálja a csőrét, hogy az adminban nem így kéne, hanem úgy kéne rendezni a menüpontokat, és eszerint és aszerint szűrni, és ez nem tetszik, az nem tetszik. Aztán nem teljesen érthető a specifikáció, ami ráadásul ötletszerűen változik néha. Az utóbbinak része, hogy a menedzser/projektvezető nem képes elsajátítani a szájtlogikát, csak az ügyfél logikáján beszél, holott szerintem ennek a kettőnek nála (is) kéne találkozni, nem csak a fejlesztőben. A fejlesztő annyit tud csinálni, hogy az ügyféllogikához szájtlogikát rendel (adatbázisséma, admin struktúra stb.), és ezt a logikát kínálja (még implementáció előtt), ezt a menedzsernek meg kell tudnia érteni, és akceptálnia kell.
Sajnos nálunk, úgy érzem, ehhez a menedzsernek nem nagyon van affinitása, és ahhoz sem, hogy vmiféle szakmai stratégia dolgában irányt mutasson, vagy konzultációt kezdeményezzen. Gondolok például arra, hogy a fejlesztőgárdája mégis milyen frameworkben vagy CMS-ben gondolkozzon, vagy kell-e ilyen egyáltalán. Szerintem ilyen szinten neki kéne egyfajta rálátással rendelkeznie, mert pont itt dől el, milyen kompromisszumokra kell számítania, ha a határidők pontos betartására vágyik.
Általános tapasztalatokra volnék kíváncsi ilyen téren.
Üdv,
fraki
■ A késéssel en bloc mint problematikával kapcsolatban kérdeznélek titeket. Napra pontosak vagytok? Állandóak a kisebb késlekedések? Ügyfelek hogy viselik? Vannak elhúzódó késések? Kötbért vállaltok? Késés esetén vannak belső viták a cégben, ki a felelős?
Nem hinném, hogy igazságos dolog a fejlesztőre hárítani az egészet, és ezzel elintézni, mert én úgy tapasztalom, hogy létezik egyfajta maximalizmus az ügyfél, és a menedzser részéről is, akinek piszkálja a csőrét, hogy az adminban nem így kéne, hanem úgy kéne rendezni a menüpontokat, és eszerint és aszerint szűrni, és ez nem tetszik, az nem tetszik. Aztán nem teljesen érthető a specifikáció, ami ráadásul ötletszerűen változik néha. Az utóbbinak része, hogy a menedzser/projektvezető nem képes elsajátítani a szájtlogikát, csak az ügyfél logikáján beszél, holott szerintem ennek a kettőnek nála (is) kéne találkozni, nem csak a fejlesztőben. A fejlesztő annyit tud csinálni, hogy az ügyféllogikához szájtlogikát rendel (adatbázisséma, admin struktúra stb.), és ezt a logikát kínálja (még implementáció előtt), ezt a menedzsernek meg kell tudnia érteni, és akceptálnia kell.
Sajnos nálunk, úgy érzem, ehhez a menedzsernek nem nagyon van affinitása, és ahhoz sem, hogy vmiféle szakmai stratégia dolgában irányt mutasson, vagy konzultációt kezdeményezzen. Gondolok például arra, hogy a fejlesztőgárdája mégis milyen frameworkben vagy CMS-ben gondolkozzon, vagy kell-e ilyen egyáltalán. Szerintem ilyen szinten neki kéne egyfajta rálátással rendelkeznie, mert pont itt dől el, milyen kompromisszumokra kell számítania, ha a határidők pontos betartására vágyik.
Általános tapasztalatokra volnék kíváncsi ilyen téren.
Üdv,
fraki
késés, projekt, terv, pénz, hungarikum
a megszorzást kettővel szerintem el kell felejteni...volt részem már ebből adódó nagyon kellemetlen konfliktusokban. Például: a fejlesztők hittek ebben a dologban, ezért már eleve több időt mondtak. A projektvezetők is hittek ebben, ezért a fejlesztők által adott időt újra megszorozták kettővel. (ebben a projektben a fejlesztők bérbe lettek adva, tehát az ügyfélnél dolgoztak) Az ügyfél persze nem hülye!!! Ezt jó észben tartani... (és a felhasználók sem azok!) A fejlesztők kimentek dolgozni és a fél éves (becsült idő) helyett 1 hónap után szinte mindennel elkészültek. Eléggé gáz volt és nagy tanulság lehett volna, de persze a vezetők szart sem tanultak belőle, mert Magyarországon nem nagyon divat korrektnek lenni.
Szerintem a legfontosabb dolog a nagyon jó tervezés. Ha tehetném ezt 5x aláhúznám. PHP-s projekteknél sajnos nem divat az UML és társai, nem nagyon használják az objektumorientáltság legfontosabb előnyét, ami miatt végülis kifejlesztették, mégpedig azt, hogy ipari környezetben hatékonyan, újrafelhasználhatóan és átláthatóan lehessen dolgozni. Persze minden cég veri a nyálát, hogy dejó lenne így tervezni a valóságban azonban éppen úgy, ahogyan a fele legális fizetés, fele borítékban dologról nem képesek leszokni (tud valaki fejlesztő céget, ahol legális a fizetés??? mert ugye minden fejlesztő ebben az országban 250-300e ft nettót kér...aha, kap is, de persze papíron csak 120-at keres...), azt sem értik meg, hogy a fejlesztésre időt és pénzt kell áldozni, ezért általában megy a ganézás és a kapkodás...toldoznak, foltoznak és kipréselik a fejlesztőkből a leggyorsabb megoldást, hogy minél hamarabb új projektet tudjanak rájuk sózni. Gyakran az egyiknek még vége sincs, már odavetik a másikat az arcuk elé: itten van egyed meg szépen! :)
Igazságosság. Ezen röhögnöm kell. A magyar cégvezetési kultúra körülbelül az óvoda kiscsoportos szintjén leledzik, körülbelül oda jutott el, hogy az ügyfelek akkor jók ha sokat, rendszeresen és előre fizetnek, különben meg buták és kapják be, majd jól lehúzzuk őket. Az alkalmazottak meg legjobb esetben kapnak illúziókat, de valójában kuss a nevük. !Láttam már kivételt képező céget is, de eddig csak 1-et...! A fejlesztő akkor jó, ha egyben tervező, projektvezető, tud 5 programozási nyelvet, tud kávét főzni és túl lehet hajtani, mint egy tinót az iga előtt. Ha pályakezdő akkor pedig jól ki kell használni.
Persze ha elmész egy cégbe, akkor csak nagyritkán látszik meg ez legelsőre, mert hazudnak és a legtöbb esetben nem is tudasoítják, hogy hazudnak, mert nekik ez a természetes.
:))
Bocs ha negatívnak tűntem, de az én 12 éves tapasztalatom eddig ezt mutatja a belső bio-adattáraim statisztikái alapján. :)
Persze ennek nem így kellene lennie és rossz duma az, hogy a cégek rá vannak szorulva, meg hogy szegénykéknek nincs pénzük. Kamuzás... Van. Csak elsunyizzák.
Kivételek vannak. Szerencsére! Csak nem nagyon sok és meg kell őket találni.
valtaska
Azert ellenkezojere is van am pelda. Egyik kollega idobecsleset mindig meg kell novelni egy nagysagrendel (perc -> ora -> nap), igy mar kb helyes eredmenyt kapunk.
van példa
Nem beszélve arról, hogy az időbecslés a projektvezetésnek csak egyetlen részfeladata, aminek szinkronban kell lennie a többivel... (projekt költség menedzsment, projekt célkitűzés menedzsment, projekt irányítás, projekt integráció, projekt humán erőforrás menedzsment, projekt kommunikációs menedzsment, projekt kockázat kezelés stb.)
És mivel a költség és az idő általában a két legkritikusabb pont, ezért ezeket kell optimalizálni...csak nem mindegy milyen módon, ezért pontosan ehhez kell a tudás, tapasztalat és a vállalti kultúra.
ezért kell elfelejteni a megszorzást...persze tudom, hogy ez részemről naivitás, mert: lásd legfent a véleményemet. :) de nem akarok ebbe belemélyedni és nincsenek illúzióim.
van pelda
- Csinalj egy oldalt, mennyi ido mulva lesz kesz?
- 2 nap.
- Rendben.
Ezek utan a kollega ket hetig nyomja a gepet.
Ha esetleg szuletik egy olyan kis iromany, ami a feladatok (a fuggosegeket nem!) es a feladathoz tartozo becsult idot tartlamazza, 2 nap mulva meg sutba, senki nem foglalkozik vele. Ja, a fonok szereti a teljes idot elosztani annyival, ahanyan dolgozunk rajta, mintha semmi nem fuggne semmitol. Ennek koszonhetoen egy projekt mar eluszott. Hetfon lett volna a vegleges atadas, ahhoz kepest, jo ha 15%-ban kesz van.
Saját cég
Csak annyit szeretnék sugallni, hogy valóban utópikus elképzeléseid vannak, de ezeket lerombolni csak akkor fogod tudni, ha magad is kipróbálod.
A fizetéstémáról csak annyit, hogy olyan módon lehúzza az állam a kiscégeket, hogy azt el sem tudod képzelni. Ha van kivétel ez alól, akkor annak a kiscégnek napi probléma a versenyképesség elvesztése, mivel mindenki lop,csal,hazudik és így jóval olcsóbban tud szállítani. A kliensek meg egytől-egyik költségérzékenyek Magyarországon, bármit is hőbörögnek össze. Ha van olcsóbb, lesz*rják hogy mi már szállítottunk kiváló minőségű megoldást és sokéves tapasztalat van mögöttünk számos területen, akkor is az olcsóbbat választják. Tehát a tisztességes cég éhenhal. A multiknál pedig ez a viselkedés alapvetően radikális érdekkülönbségeket és nagyfokú szűklátókörűséget takar.
Nyilván a klienseken kellene elsősorban változtatni, de rajtuk lehetetlen. Magyarországon a legtöbb kliens még addig sem ér fel ésszel, hogy otthagyja a rossz minőségű, olcsó megoldásokat, amikor konkrétan az ő zsebébe fáj a fixálgatás, csúszkálás, értékesítési arány csökkenése. Mert olcsóbban megkapta a terméket - szerinte.
A másik okosság amit hallottam, hogy IT kamara kell nekünk és majd kartell lesz itt kéremszépen. Ez talán még nagyobb szamárság, mint a kliensek evangenizálása. A kamara akadályozza a szabad versenyt, ráadásul mivel emberek alkotják, akik egymás versenytársai is, 10 percbe nem fog telni a bürokrácia és a személyeskedés szövevényes hálójának kialakítása.
Szóval szerinted hogy lehetne ezen változtatni?
Két dolog...
1. Mindig minden fontosabb mint az aktuális projekt-szindróma.
2. Akkor kezdjük el a projektet, amikor vége kéne legyen-szindróma.
Többet nem mondok.
Késés
A lényeg hogy minden fejlesztő, minden ember egyedi. Ha beskatujázod őket, nem fogják szeretni azt amit és ahol csinálnak. Just my two cents.
"Szoftverütemezés egyszerűen"
Na, azért! :)
kis adalék
http://particletree.com/notebook/the-importance-of-deadlines/
Fejlesztői oldal