Adott egy képzelt cég ami IT idegen tevékenységet (gyártásnak képzelt fejlesztést) folytat és rajtad kívül senki nem ért az IT-hez/SW fejlesztéshez, vannak heti meetingek, reportok, jelentések. Ezt követően egy szép napon odajönnek hozzád, hogy pár hete emailben nem kapják meg a jelentéseket (ezt gyorsan rövidrezárod némi személyes támogatással hamar kitaláljátok a fiókjának a jelszavát: 123456 (mondjuk tényleg) és ezután egyúttal közlik veled, hogy egyébként is annyit azért tudnak az IT és SW fejlesztés egy olyan terület ahol úgy baszod át őket ahogy akarod, jelentés ide, report oda, meeting amoda, demó akárhova. Ezért azt kérik tőled, hogy tedd mérhetővé, hogy amit csinálsz az reális-e. Természetesen értékelni nem tudják amit csinálsz és számukra csak 2 állapot létezik: kész/nincskész. A 99% az nincskész, ergó (szerintük) meglopod a őket (tételezzük fel mellé, hogy órabérben vagy).
Pont ezt a képzelt példát nem kell most megoldani. De egyébként most ettől elvonatkoztatva, egy ilyen esetben hogyan lehetne mérhetővé tenni hozzá nem értők számára, hogy mennyire reális az ami számukra érthetetlen? Egyébként érthetetlen? Létezik valamilyen megoldás erre? Ez egyébként probléma máshol is, mondjuk egy nővér megbíz egy kőművest órabérben...
- 2491 megtekintés
Hozzászólások
Ticket vezetése részletesen, részfeladatokra lebontva, esetleg még a ráfordított idő mérésével is.
Kb. ezt tudom elképzelni "mérés" címszó alatt.
- A hozzászóláshoz be kell jelentkezni
Írsz egy új SW-t egy számodra új hardverre (jellemzően nem PC-ről van szó) és szívsz egy DMA/egyéb hasonló problémával mondjuk 2 hetet. "Lemértük" az időt is. Hogyan döntjük el, hogy ez most reális volt-e vagy Te vagy alkalmatlan. Persze minden egyes adott feladatra lehetne találni valakit, aki pont azt az egy feladatot 1 hét alatt megoldaná mert egész életében csak azt csinálta ismeri a buktatókat, míg ugyanez az ember egy másik feladatot oldana meg 2 hét alatt mert neki meg az lesz új. Vagy mikét példában szereplő ember egyformán rossz teljesítmény hoz? Vagy valójában másik 1000 közül egy sem végezne ugyanezzel 3 hétnél gyorsabban tehát valójában pont kifogtuk a 2 legjobb embert a példához? Még nem értem, hogyan lehetne mérni mi a reális. Vagy, hogy mi mást kéne mérni helyette, ami ezt helyettesíteni tudná.
- A hozzászóláshoz be kell jelentkezni
Így már értem a problémádat. Akkor viszont marad Oregon hozzászólása, hagyd ott apékbe őket.
- A hozzászóláshoz be kell jelentkezni
Az ügyfél szempontjából mindegy, hogy azért tart sokáig, mert te nem értesz hozzá, vagy azért mert lusta vagy, vagy pengén értesz hozzá és éjt nappallá téve dolgozol de lassan.
Neked kell annyira ügyesnek lenned, hogy a rizikót beleveszed, amikor megbecsülöd, mennyi idő lesz, mennyiért érné meg neked.
Persze ez nem csak ebben az esetben igaz, bármilyen ügyfél és bármilyen szolgáltató cég (pl. egyedi szoftvert készítő programozóhadak munkáját bérbeadó) ugyanezzel szembesül.
Több megközelítés van, egyik sem tökéletes, de mind működik valamennyire. Választani kell egyet, ami mindkét fél számára elfogadható. Ha egy idő után nem tetszik valakinek, akkor esetleg megbeszélni a problémákat és egy másikat lehet választani és onnantól aszerint tolni.
- A hozzászóláshoz be kell jelentkezni
Hagyd őket ott. Sajnos nincs jobb választásod, úgyis ez lesz a vége.
- A hozzászóláshoz be kell jelentkezni
Szerintem az állásidőket kell rögzíteni. Minél kevesebb, annál jobb. Mérhető.
- A hozzászóláshoz be kell jelentkezni
Ügyfél részről egy számukra megbízható, de tapasztalt szakember felvétele Product Owner-i szerepkörbe, és valami agilis módszertan (scrum, kanban) bevezetése.
- A hozzászóláshoz be kell jelentkezni
ez melyik orszag?
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
- A hozzászóláshoz be kell jelentkezni
HU
- A hozzászóláshoz be kell jelentkezni
Ha abszolút nem tudják azt, hogy mennyi idő reális valamire, akkor teljesítménybérben kell dolgozni.
Egy rendszer, x összeg, van rá n hónap. Bemutatod, tesztelik, működik, fizetnek, leszállítod, mindenki örül.
Ha jól sejtem azért van órabér, mert nem tudják előre pontosan, mi kellene.
Vagyis legyen agile.
Adott funkció mennyit ér meg nekik. Ha neked megéri kifejleszteni annyiért, akkor megcsinálod.
Ha valami nekik kevesebbet ér, mint amennyit neked megér a kifejlesztése, akkor azt nem csinálod.
Funkciónkért demózol, ami a következő release-ben van elfogadott cucc, azt fizetik ki mindig.
- A hozzászóláshoz be kell jelentkezni