HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

A priorizálást sokan utálják – de mégis nagy szükség van rá, ha nem akarjuk megütni a bokánkat.

A priorizálást sokan utálják – de mégis nagy szükség van rá, ha nem akarjuk megütni a bokánkat.

A priorizálást már többször említettem, például itt, most következzék egy konkrét állatorvosi ló!

Az eset rögtön kiabálással kezdődik: az egyik menedzsertől kaptam egy dühödt levelet, hogy XY kérését miért csináltuk meg, amikor vannak annál fontosabb dolgok? És persze elkezdett azon spekulálni, hogy mennyire vagyunk vagy nem vagyunk képesek megszervezni az életünket és azt csinálni, amire szükség van.

Természetesen ott volt csatolva a levele, amiben kérte a fejlesztőket, hogy a kérését rakják fel a listára, és majd megbeszéljük a prioritását. Ugyanis a listán vannak fontosabb igények is, amiket sokkal hamarabb meg kellene csinálni, mint XY. A fejlesztők pedig azonmód ki is fejlesztették a kért funkciót.

A fejlesztőket megértem – ha egy felhasználónak ügyes-bajos dolga van, és gyorsan meg tudjuk oldani, akkor „az úttörő ahol tud segít” alapon megcsináljuk, akkor is ha esetleg éppen máson kellene dolgozni.

Viszont ha a felhasználó direkt kéri, hogy a prioritásnak megfelelően dolgozzunk, akkor más a helyzet. Ugyanis az egyes új funkciók között függőség lehet, illetve az egyes funkciók bevezetése lehet, hogy oktatást, dokumentálást, stb feltételez. Tehát nem lehet csak úgy új funkciókat kifejleszteni.

A másik gond ezzel az esettel az volt, hogy a felhasználó nem jelezte a levélben, hogy ez változáskérelem. A levél valami olyasmit mondott, hogy ha megnézem az X adatokat, akkor ott Y hiányzik, és jó lenne ha ott lenne. Na de ez nem bug volt, hanem feature! Az Y adatok ott sosem jelentek meg, a felhasználó ezt tudta, és abban a hiszemben küldte el a mailt, hogy változást kér. A fejlesztő meg azt hitte, hogy valami adathiba van, és rögtön megcsinálta.

Mi a különbség hiba és változáskérelem között? Óriási!
Ha bejön egy hibajegy, akkor azzal azonnal foglalkozni kell. A hibajegy azt jelenti, hogy valami nem működik, hogy az alkalmazással baj van, a felhasználók nem tudnak dolgozni, és nekünk minél hamarabb szállítani kell a megoldást.
Amikor meg éppen nem hibát javítunk, akkor dolgozgatunk a változáskérelmeken, azok fontossága szerint.

Vagyis ha egy beérkező alacsony prioritású kérelmet hibának nézünk, akkor az hirtelen a sor elejére ugrik.

Milyen sorról is beszélünk? Az élet már csak olyan, hogy igényből mindig több van, mint erőforrásból. Feladatból sok van, időből kevés, tehát meg kell határozni, hogy mi a legfontosabb feladat, illetve mi a 2. legfontosabb feladat ha az elsővel végeznék, stb. Ha nem lenne ilyen lista, akkor a fejlesztők azzal foglalkoznának, amihez éppen kedvük van, vagy aki éppen a leghangosabban kiabál (egyik sem jó).

Szóval kell egy lista, ami a prioritásokat tükrözi. Mi alapján kerülnek a prioritások meghatározásra? Nyilvánvalóan a felhasználók, az üzleti vezetők véleménye alapján. Az üzleti oldalon van 1 ember, aki az igényeket koordinálja és egyezteti ezek fontosságát, illetve a listát heti rendszerességgel közösen átnézi az IT-val. Tehát az IT hetente kap egy friss listát, és 1 hétig tud ez alapján dolgozni.

A lista közös átnézése még azért is fontos, mert a munka és a kommunikáció nem csak egyirányú. Igaz hogy elvileg az IT végzi a munkát, de időnként a felhasználóknak is részt kell venniük (pl. ha kérdés van, vagy ha a megoldást le kell ellenőrizni). Meglehet, hogy erről a felhasználók nem is tudnak, azaz várnak az IT-ra, miközben az IT vár rájuk. Éppen ezért a lista áttekintése közben meg lehet beszélni, hogy az adott feladaton éppen ki dolgozik, várunk-e valakire, ha igen kire és mire. Az üzleti koordinátor pedig meg tudja keresni a felhasználót és egyeztetni a feladatot.

Mi történik, ha egy feladat jelenik meg? Egész egyszerűen az üzleti koordinátor felrakja a listára, a megfelelő helyre (prioritás), és amikor az IT odaér, akkor dolgozik rajta.
Ezzel nagyon szépen el lehet kerülni azt az esetet, amikor 5 különböző menedzser jön 5 különböző feladattal, hogy most izibe azonnal csináljuk meg mert az övé a legfontosabb a világon. Tessék szépen felrakatni a feladatokat a listára, aztán majd amikor odaérünk akkor megcsináljuk.

Azt hiszem látható, hogy ha nem létezne a lista és nem létezne a priorizálás, akkor mennyire szétesne a munka. Ez a lista és a priorizálás tiszta, világos helyzetet teremt, nincsenek viták, és mindig tudjuk mi a dolgunk.

Viták legfeljebb abból vannak, amikor valaki nem követi a folyamatot, vagy amikor a lista nem tükrözi a valóságot.

Címkék: priorizálás

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr835211492

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.

Nincsenek hozzászólások.
süti beállítások módosítása