Egy saját belső üzleti rendszer igényeit úgy tudod érthetően elmondani a fejlesztőnek, ha végigvezetsz egy rendelést, munkalapot vagy más ügyet a jelenlegi működésen. Mondd el, ki kapja meg, milyen adatokkal dolgozik, miről dönt, és mit ad tovább. Az egyedi rendszer igényfelméréséhez nem kell kész műszaki dokumentációval érkezned: néhány jól kiválasztott példa és a hozzájuk tartozó szabályok már használható alapot adnak.
A „mindent egy helyen szeretnénk látni” vagy a „legyen automatikus az adminisztráció” érthető szándék, de többféle rendszert jelenthet. Más problémát old meg egy munkalap követése, a kapacitásbeosztás és a vezetői kimutatás. Mi akkor tudunk érdemben kérdezni, ha látjuk, melyik konkrét munka akad el, és mit jelentene helyette a jó működés.
Egyetlen ügy történetével kezdd az egyedi rendszer igényfelmérését
Válassz egy gyakori, de több embert érintő ügyet. Lehetőleg olyat, amelynek ismered a kezdőpontját, a köztes lépéseit és a lezárását. A beszélgetéshez nem az ideális céges szabályzat kell, hanem az, ahogyan a munkát most ténylegesen végzitek. A kerülőutakat és az ismételt adatrögzítést is mutasd meg.
Az alábbi történet kitalált szemléltető példa egy karbantartó vállalkozásról, nem KovaBuild-ügyfélprojekt. Az ügyfél e-mailben hibát jelent egy berendezéshez. Az ügyintéző megkeresi a szerződését, felveszi a helyszínt és a berendezés azonosítóját, majd munkalapot ad a koordinátornak. A koordinátor kijelöl egy szerelőt és időpontot egyeztet.
A szerelő a helyszínen rögzíti az elvégzett feladatot és a felhasznált anyagot. Ha a munka meghaladja az előzetesen engedélyezett keretet, a folytatáshoz jóváhagyás kell. A lezárt munkalapot a pénzügy ellenőrzi, a számlázásra átadott ügy pedig visszakapja a kapcsolódó bizonylat azonosítóját. A vezető azt szeretné látni, mely ügyek várnak még egyeztetésre vagy jóváhagyásra.
Ebből már több tisztázandó kérdés következik. Minden bejelentésből létrejöhet munkalap, vagy előbb ellenőrizni kell a szerződést? Mi történik, ha nem ismert a berendezés? Ki dönt a többletmunkáról? Ezek a válaszok határozzák meg a rendszer működését, nem az, hány menüpontot szeretnél látni benne.
A jelenlegi és az elvárt folyamatot külön írd le. Ha ma a koordinátor telefonon kér jóváhagyást, de az új rendszerben ezt követhető döntésként szeretnéd rögzíteni, jelöld változtatásként. Így nem keveredik össze a megőrzendő működés és a javítandó szokás. Ha még azt keresed, melyik folyamat legyen az első, az első üzleti automatizálás kiválasztásáról szóló cikkünk segít ezt külön eldönteni.
Mutasd meg a szereplőket és a használt dokumentumokat
Ne csak felhasználószámot mondj. Sorold fel a munkaköröket, és mindegyikhez írd oda, mit hozhat létre, mit láthat, mit módosíthat és mit hagyhat jóvá. A példában a szerelőnek szüksége lehet a saját munkalapjára és a helyszíni információkra, a teljes pénzügyi kimutatásra viszont nem feltétlenül. A vezetői cím önmagában sem írja le pontosan a szükséges hozzáférést.
A helyettesítést is beszéljétek át. Ki veheti át a nyitott feladatokat szabadság alatt, és mi történik, ha egy munkatárs távozik? Ha külső partner is részt vesz a folyamatban, külön kezeld, mit kap meg és mit küldhet vissza. Az, hogy valaki láthat egy ügyet, még nem jelenti, hogy át is teheti lezárt állapotba.
Az első egyeztetéshez gyűjts össze egy jellemző e-mailt, táblázatot, kitöltött munkalapot és a folyamat végén készülő dokumentum mintáját. Az érzékeny részeket cseréld mintákra vagy takard ki. A mezők, kapcsolatok és kivételes helyzetek így is megmutathatók; valódi jelszóra vagy teljes ügyféladatbázisra nincs szükség egy induló igénybeszélgetéshez.
Minden fontos adat mellé kerüljön oda, honnan származik és ki javíthatja. Például a berendezés azonosítóját a központi nyilvántartás adja, a helyszíni megjegyzést a szerelő rögzíti, a szerződéses besorolást az ügyintéző ellenőrzi. A „megjegyzés” nevű szabad szöveges mezőbe gyűjtött sok különböző adatot érdemes külön kibontani, ha később ezek alapján szeretnél keresni vagy kimutatást készíteni.
A szabályokat konkrét feltételként, a kivételeket külön útként mondd el
A „jóváhagyás után lehessen folytatni” mondatból még nem tudható, ki hagy jóvá és pontosan mit. Használhatóbb így: a koordinátor kezdeményezi a többletmunkát, a kijelölt felelős elfogadja vagy indoklással elutasítja, és a szerelő csak elfogadás után rögzítheti azt elvégzettként. Ez még nem műszaki terv, de már közösen ellenőrizhető üzleti szabály.
Az állapotokat is a munkából vezesd le. A „nyitott” jelenthet új bejelentést, alkatrészre várást vagy hiányzó aláírást. Ha ezek eltérő teendővel és felelőssel járnak, érdemes megkülönböztetni őket. Minden állapothoz legyen érthető belépési feltétel, következő teendő és lezárási lehetőség.
Külön gyűjtsd össze azokat az eseteket, amikor a szokásos út nem működik. A példában ilyen lehet az ismeretlen berendezés, a téves helyszín, a megismételt bejelentés vagy a már lezárt munka utólagos javítása. Mindegyikhez mondd el, megálljon-e az ügy, visszakerüljön-e valakihez, vagy külön engedéllyel folytatódhat.
Az ellentmondó belső válaszokat is érdemes feljegyezni. Ha a koordinátor és a pénzügy másképp értelmezi a lezárást, ezt a fejlesztő nem tudja üzleti felhatalmazás nélkül eldönteni. Jelöljetek ki valakit, aki a nyitott szabálykérdésekben dönthet. A bizonytalanság feltárása az igényfelmérés hasznos eredménye, nem a felkészületlenség jele.
A rendszerkapcsolatnál az átadott adatot és a visszajelzést is nevezd meg
Az „össze kell kötni a számlázóval” helyett mondd el, melyik esemény indítsa az átadást. Mely adatokat küldjük, melyik alkalmazásban számít véglegesnek az ügyfél címe, és mit várunk válaszként? A külső rendszer pontos neve, az előfizetés vagy telepítés típusa és a rendelkezésre álló dokumentáció segít a későbbi műszaki ellenőrzésben.
Ne ígérj automatikus összekötést pusztán abból, hogy mindkét programban szerepel az ügyfél neve. Előbb tisztázni kell a kapcsolódási lehetőségeket, a hozzáférést és az azonosítást. Az első beszélgetésen elfogadható válasz az is, hogy a kapcsolat technikai feltételei még ismeretlenek. Ezekből külön felmérési feladat lesz.
Mondd el, mit lásson a munkatárs sikertelen átadásnál. A munkalap maradjon például ellenőrzésre váró állapotban, jelenjen meg a hiba, és legyen kijelölt felelőse a rendezésnek. Az ismételt próbálkozásnál azt is tisztázni kell, hogyan derül ki, létrejött-e már a külső bizonylat. A bizonytalan kimenetet ne tekintsétek automatikusan sikernek vagy sikertelenségnek.
Írd le, miből ismeritek fel a kész működést
A „könnyen kezelhető” vagy a „gyorsabb legyen” fontos elvárás, de önmagában nehezen átadható. Adj helyette kipróbálható helyzeteket. A koordinátor lássa az összes kiosztatlan munkalapot, a szerelő találja meg a hozzá rendelt ügy előzményeit, a pénzügy pedig meg tudja különböztetni a hiányos és az átadásra kész munkalapokat.
A GOV.UK felhasználói történetekről szóló útmutatója is a szereplő, az elvégzendő feladat és a cél megnevezését javasolja, az elfogadás feltételeit pedig ellenőrzőlistaként kezeli. Ezt egyszerű magyar mondatokkal is használhatod. Nem a forma betartása a cél, hanem hogy a fejlesztő és a munkatárs ugyanazt értse a kívánt eredményen.
A szemléltető munkalapnál például ilyen elfogadási feltétel lehet: hiányzó berendezésazonosítóval az ügy rögzíthető, de nem osztható ki szerelőnek; a hiányt az ügyintéző listáján látni kell. Másik feltétel: egy szerelő ne tudja módosítani más munkatárs lezárt munkalapját. Ezeket a példákat majd a saját működésetekhez kell igazítani, nem kész követelményként átvenni.
A kimutatásoknál a mezők mellett a döntést is nevezd meg. Mire fogod használni a heti listát? Ha a késés okát keresed, a puszta összesített darabszám kevés lehet. Ha csak a kiosztatlan ügyekre szeretnél rálátni, nem feltétlenül kell már az első változatban összetett vezetői elemzés.
Kitölthető kérdéssor az első fejlesztői egyeztetéshez
Másold át az alábbi kérdéseket egy közös dokumentumba, és rövid mondatokkal válaszolj. Amit nem tudsz, jelöld nyitott kérdésként. Érdemes a folyamatot végző munkatárssal is átbeszélni: ő olyan köztes lépéseket is megmutathat, amelyek a vezetői összefoglalóból kimaradnak.
- A megoldandó helyzet: Most az okoz gondot, hogy … Ez akkor fordul elő, amikor … A következménye …
- A folyamat határa: Az ügy akkor indul, amikor … Akkor tekintjük késznek, ha … Az első változatnak nem feladata …
- A jelenlegi út: Először … végzi el … alapján. Ezután … kapja meg … formában. Végül … ellenőrzi és lezárja.
- A szerepkörök: … rögzíthet, … módosíthat, … hagyhat jóvá. … csak a saját ügyeit láthatja. Helyettesítéskor …
- A bemenetek: Az ügyhöz szükséges adat vagy dokumentum … Ennek forrása … Kötelező adat … Hiány esetén …
- A döntési szabály: Ha … teljesül, akkor … történhet. Ezt … hagyja jóvá. Elutasítás esetén … következik.
- A kivételek: Gyakori rendhagyó eset … Ezt jelenleg … kezeli. Az új rendszerben ilyenkor … történjen.
- A kapcsolódó rendszerek: … alkalmazásból … adat érkezik. … alkalmazásba … eseménykor … adat menjen. Sikertelen átadásról … kapjon jelzést.
- Az elvárt kimenet: A folyamat végén … dokumentum, lista vagy rögzített állapot kell. Ezt … használja … döntéshez vagy következő feladathoz.
- A kipróbálás: Akkor fogadjuk el a működést, ha … normál eset, … hiányos eset és … jogosultsági helyzet megfelelően végigvihető.
- A bevezetés: A régi adatokat … helyről kell átvenni. A próbában … vesz részt. A napi működésért és a nyitott kérdésekért … felel.
Az első egyeztetés eredménye egy közös feladatértelmezés legyen
A kérdéssor mellé vigyél egy normál és egy problémás mintát ugyanabból a folyamatból. Jelöld, mely elvárások nélkülözhetetlenek a munkához, és melyek későbbi kényelmi bővítések. A határidő mellett azt is írd le, mihez kötődik: szerződéshez, belső átálláshoz vagy egy még rugalmas tervhez.
Ezek alapján még változhat a megoldás iránya. Előfordulhat, hogy teljes új rendszer helyett egy meglévő alkalmazás kiegészítése vagy két eszköz összekapcsolása elegendő. Az egyedi szoftver és kész rendszer közötti választásról külön cikkben írunk; a most összeállított folyamatleírás mindkét lehetőség vizsgálatához felhasználható.
A KovaBuild egyedi szoftverfejlesztési szolgáltatásánál ebből a működésből tudunk kiindulni. Ha megírod nekünk egy fontos ügy jelenlegi útját és a kívánt változást, a nyitott kérdések mentén már célzottan át tudjuk beszélni a következő felmérési lépést. Nem kell előre kitalálnod a technikai megoldást; a céges döntéseket és a napi munka részleteit viszont közösen tisztáznunk kell.