Folyamat-státusz színek: hogyan definiálunk piros, sárga és zöld állapotot
Egy vezetői felületen három szín jelzi a folyamatok állapotát: piros a lejárt határidő, sárga a mai, zöld a későbbi. Ilyen szabályt bárki elfogad ránézésre — és pontosan ez a veszélyes benne. Egy valós példában a piros oszlop hónapokon át alacsony számot mutatott, és mindenki megnyugodott tőle; amikor a szín mögötti feltételt visszavezették a forrásrendszer saját szabályáig, kiderült, hogy a piros nem azt jelentette, amit mindenki hitt: egy mintanapon három kollégánál 3, 0 és 0 helyett 14, 9 és 15 tétel volt valójában lejárt határidős.
Egy hibás definíció ugyanis pontosan úgy viselkedik, mint egy jó: számot ad, változik, hihető. Ez a cikk arról szól, mi tartozik egy állapot-definícióhoz, honnan kell kiolvasni, ki a gazdája, és milyen négy olcsó próbával ellenőrizhető — mielőtt döntések sora épülne rá.
A tipikus eset: a szín, ami mást számol, mint amit ígér
A felület egy értékesítési folyamat állapotát mutatja kollégánként. A szabály papíron egyszerű: piros, ha a kezelési határidő lejárt, sárga, ha ma jár le, zöld, ha később. Ilyen szabályt bárki el tud fogadni ránézésre, és pontosan ez a veszélyes benne: a mondat érthető, a mögötte lévő feltétel viszont nem látszik sehol.
A csapda ott nyílik, ahol az illesztés készül. Ha a fejlesztő a forrásrendszer képernyőjén látott listát próbálja utánozni — keres néhány szűrőt, amivel a saját lekérdezése ugyanazt adja ki, mint a képernyő —, akkor nem a szabályt vette át, hanem egy nézetet. A szűrők közé így olyan megkötések is bekerülhetnek, amiknek a folyamat-határidőhöz semmi közük: egy hívás-típusra vagy egy eszköz-fajtára vonatkozó feltétel, ami az adott képernyőn éppen ott volt.
A forrásrendszer tárolt eljárása közben gyakran csak annyit ad ki, amennyit tényleg tud: a kezelési határidőt és a sárga küszöböt. A pirosra nincs szabálya. Ha egy állapotra a forrásrendszer nem ad szabályt, akkor azt az állapotot az illesztés definiálja — és ilyenkor ezt le kell írni, különben senki nem tudja, mit néz. Enélkül a következmény kiszámítható: a piros nem a lejárt tételeket számolja, hanem azoknak egy szűk, véletlenszerű részhalmazát. A bevezetőben említett mintanapon a felület 3, 0 és 0 tételt mutatott; a valóságban 14, 9 és 15 tétel volt lejárt határidős.
A javítás önmagában ritkán nagy munka: a lekérdezést és a felületre küldött adatot a forrásrendszer saját határidő-szabálya szerint kell újraírni, majd az állapot-csempék mellé kiírt jelmagyarázat kerül. A drága rész nem ez, hanem az az idő, amíg egy ilyen eltérés észrevétlen marad — és az a döntéssor, ami közben ráépül.
Miért nem tűnik fel sokáig egy hibás definíció?
Mert a kis szám megnyugtat. Ha a piros oszlopban tizennégy tétel áll, valaki rákérdez. Ha három, akkor nem történik semmi: három elintézhető, három nem vészhelyzet. A hibás definíciók tipikusan lefelé tévednek, és pont ezért maradnak életben — a felfelé tévedő hibát egy nap alatt bejelentik.
Mert az egyforrású szám mindig hihető. Ha a felület az egyetlen hely, ahol az adott szám látszik, nincs mellette másik kimutatás, aminek ugyanazt kellene mondania, és nincs kézi lista sem, amivel össze lehetne vetni. Nincs, ami ellentmondjon neki — ezért kell minden fontos státusz mellé egy független ellenpróba, akár csak egy havi, tízsoros kézi minta.
Mert a felhasználó a címkét ismeri, nem a feltételt. Aki naponta nézi a felületet, azt fogja mondani, hogy „a piros a lejárt”. Papíron így is van. Hogy a gép ezt milyen feltétellel számolja ki, azt jellemzően egyetlen felhasználó sem tudja, és nincs is hol elolvasnia.
Mert az illesztés „egyezett” az eredeti felülettel. Ez a legalattomosabb rész. Az illesztés készítője elvégez egy ellenőrzést: összehasonlítja a saját eredményét a forrásrendszer képernyőjével, és egyezést talál. Csakhogy a képernyő maga is szűrt: egy adott nézetet mutat, nem a teljes halmazt. Az egyezés tehát igaz, és mégis rossz definícióhoz vezet.
Mi tartozik egy állapot-definícióhoz?
Egy állapot (piros, lejárt, kockázatos, kezelendő) akkor használható, ha hat kérdésre van írásos válasz. A hat válasz elfér fél oldalon egy belső leírásban, és a kitöltése fél óra — nagyjából annyi, amennyit egyetlen félreértett nap elvisz.
| Elem | A kérdés | Rossz válasz |
|---|---|---|
| Jelentés | Mit állít az állapot az üzletről? | „Ez a piros oszlop” |
| Viszonyítás | Mihez képest lejárt: melyik dátumhoz, melyik naptárhoz? | „A határidőhöz” — melyikhez? |
| Forrás | Melyik mezőből, melyik szabályból számoljuk? | „Amit a képernyő is mutat” |
| Frissülés | Mikor számolódik újra, és mennyire friss a képernyőn látott érték? | „Folyamatosan” |
| Gazda | Ki dönthet a definíció megváltoztatásáról? | „A fejlesztő” |
| Hiányzó adat | Mi történik, ha nincs határidő vagy nincs felelős? | Hallgatás — ilyenkor tűnnek el tételek |
A leggyakrabban kihagyott sor az utolsó. Egy állapot-logika általában három ágra készül, és a negyedik — a „nincs adat” — csendben kiesik. Ezek a tételek nem kapnak színt, ezért nem is kerülnek egyik oszlopba sem, és a felületen úgy tűnik, mintha nem léteznének. Ha a színek darabszáma nem adja ki az összes tételt, a különbség nem kerekítés, hanem hiány.
A gazda kérdése pedig nem formalitás. A definíciót az üzlet mondja ki, nem a fejlesztő: nem fejlesztői döntés, mi számít lejártnak. A fejlesztő dolga az, hogy amit kimondtak, azt pontosan és ellenőrizhetően valósítsa meg — és jelezze, ha a kimondott szabály az adatból nem számolható ki. A gyakorlatban egy állapot rendszerint akkor válik egyértelművé, amikor egy vezető kimondja, mit jelentsen a három szín, és ezt valaki le is írja.
Érdemes a definíció mellé odaírni a határeseteket is, mert a vita mindig ott lesz. Mi történik, ha a határidő munkaszüneti napra esik? Lejárt-e az a tétel, amit ma zártak le, de a határideje tegnap volt? Külön állapot-e a felfüggesztett, vagy a lejártba esik? Ezekre a kérdésekre az első hónapban senki nem gondol, a harmadikban viszont már mindenki mást feltételez — és ettől kezdve két kolléga ugyanarra a képernyőre nézve két különböző számot mond.
A másik gyakori hiányosság a változás-napló. Ha egy definíció módosul — kibővül egy szűrő, változik egy küszöb —, annak dátummal és indoklással kell bekerülnie a leírásba. E nélkül az idősor összehasonlíthatatlan lesz: a tavaszi és az őszi piros-szám két különböző dolgot mér, és senki nem fogja tudni, melyik hónapban változott meg a szabály. Egy két oszlopos táblázat — mikor, mi változott — elég hozzá.
Négy olcsó próba, amivel ellenőrizhető egy állapot-szín
1. Tízsoros kézi mintavétel. Vegyen tíz tételt a pirosból és tíz olyat, aminek pirosnak kellene lennie, és nézze meg egyesével a forrásrendszerben. Ha a második csoportból bármelyik nincs a felületen, megvan a hiba. Ez húsz perc, és nem kell hozzá fejlesztő.
2. Összegpróba. Adja össze a színek darabszámát, és vesse össze az összes érintett tétel számával. Ha nem jön ki, a különbség azokat a tételeket takarja, amelyek egyik feltételbe sem estek bele. Ez a leggyorsabb módja annak, hogy a „nincs adat” ágat leleplezze.
3. A nulla gyanús. Ha egy állapot hosszú ideje pontosan nullát mutat, az két dolgot jelenthet: tényleg nincs ilyen eset, vagy nem működik a számolás. A kettő között egyetlen módon lehet dönteni: csináljon szándékosan egy olyan tételt, aminek meg kell jelennie, és nézze meg, megjelenik-e. Ugyanez a szabály érvényes a riasztásokra is.
4. Jelmagyarázat a képernyőn. Írja ki a felületre, mit jelent a szín — egy mondatot, ott, ahol a szám van. Ennek két haszna van: a felhasználó tudja, mit néz, és ha a mondat nem stimmel a látottakkal, valaki azonnal szól. A fenti példában pont ez történt: az állapot-csempék mellé kiírt jelmagyarázat tette a definíciót nyilvánossá.
Ezt a négy próbát érdemes minden új kimutatás bevezetésekor lefuttatni, és minden olyan változtatás után, ami a szűrőket érinti. Éles automatáknál ehhez jön egy ötödik szabály: a definíciót állandó ellenőrző teszt őrizze, ami elbukik, ha valaki később csendben módosítja a feltételt.
A négy próba akkor ér a legtöbbet, ha írásban marad a nyoma: mikor futott le, mit talált, ki nézte át. Enélkül fél év múlva ugyanaz a kétely ugyanúgy megindul, és megint valaki kézzel fog tíz tételt kikeresni. Egy három soros feljegyzés a kimutatás mellé — dátum, próba, eredmény — elég ahhoz, hogy az ellenőrzés ne nulláról induljon, és hogy egy vezetőváltás után is legyen mire hivatkozni.
Gyakori kérdések
Mit jelent a piros státusz egy vezetői kimutatásban?
Csak annyit, amennyit előre definiáltak hozzá. A szín önmagában nem információ: meg kell adni, mit állít az üzletről, melyik dátumhoz viszonyít, melyik mezőből és milyen szabályból számolódik, és mi történik akkor, ha hiányzik az adat.
Honnan tudom, hogy jó-e a státusz definíciója?
Két olcsó próbával. Vegyen tíz tételt, amelynek az adott státuszban kellene lennie, és nézze meg egyesével a forrásrendszerben; majd adja össze a státuszok darabszámát, és vesse össze az összes tétel számával. Ha a kettő nem egyezik, vannak tételek, amelyek egyik feltételbe sem esnek bele.
Miért baj, ha egy szűrőt a képernyő alapján állítunk be?
Mert a képernyő maga is szűrt nézet, nem definíció. Az egyezés így igaz lehet, miközben a mögöttes szabály rossz. A definíciót a forrásrendszer saját szabályából kell kiolvasni, és ha az adott állapotra nem ad szabályt, akkor azt az állapotot maga az illesztés definiálja — ezt pedig le kell írni.
Ki legyen egy státusz gazdája?
Az a vezető, akinek a döntése épül rá, nem a fejlesztő. Az üzleti tartalmat (mi számít lejártnak, mi sürgősnek) az üzlet mondja ki; a fejlesztő feladata az, hogy pontosan és ellenőrizhetően valósítsa meg, és jelezze, ha a kimondott szabály az adatból nem számolható ki.
Mennyi ideig tart egy ilyen ellenőrzés?
A négy próba (mintavétel, összegpróba, a nulla vizsgálata, jelmagyarázat) együtt jellemzően egy délelőtt alatt elvégezhető, és fejlesztő nélkül is megcsinálható. A javítás ennél hosszabb lehet, de a lekérdezés és a felület átírása általában egy körben elfér. A drága rész nem a javítás, hanem az az idő, amíg egy hibás definícióra döntések épülnek.
A következő lépés: öt kérdés a saját vezetői felületéhez
Vegye elő azt a kimutatást vagy felületet, amire a legtöbb napi döntés épül, és válaszoljon öt kérdésre. Mind az öt megválaszolható egy délelőtt alatt.
- Mit jelent pontosan a legfontosabb státusz? Ha három ember három választ ad, a definíció nincs meg.
- Hol van leírva? Ha sehol, akkor az a definíció, ami a kódban van — és azt senki nem olvassa.
- Kiadja-e a színek összege az összes tételt? Ha nem, keresse meg a különbséget.
- Mikor egyeztették utoljára a forrásrendszerrel? Egy tízsoros mintavétel elég.
- Ki a gazdája? Név szerint, nem szerepkör szerint.
Ha a válaszok nyugtalanítóak, az nem a fejlesztő hibája és nem is a rendszeré. A definíció hiánya szervezeti hiány: mindenki azt hiszi, hogy valaki más tudja. Egy folyamat-audit első napja pont ezért nem a technológiáról szól, hanem arról, hogy a legfontosabb mutatók mit állítanak, és miből számolódnak — a folyamat és az ár az AI-audit árak oldalon van leírva. Ha a kimutatásai forrásából is kérdései vannak, olvassa el az Adatminőség a riportban; ha pedig azt keresi, hogyan épül egy megbízható, ütemezett kimutatás-réteg a meglévő rendszer fölé, arról a heti riport automatikusan cikkünk szól.