A lecke végére a féléves projektet egyetlen, kezelhető feladatra tudod szűkíteni. Meg tudod különböztetni a brief bizonyított elemeit a feltételezésektől, és fel tudod térképezni, kiket érint egy döntés a végfelhasználón túl.
Miért kell brief?
A kutatás után sok ötlet, irány és lehetőség van előtted. Ilyenkor a legnagyobb veszély nem az, hogy kevés a lehetőség, hanem hogy mindent egyszerre szeretnél megoldani. A brief ezt védi ki: rögzíti, mit vállalsz és mit nem. Egy jól megírt brief az a pont, ahová a projekt során visszatérhetsz, amikor egy új ötlet kiterjesztené a hatókört, vagy egy vita elvinné a figyelmet a fő feladatról.
Mire való a brief?
A projektbrief a projekt problémáját, célját, kereteit és nyitott kérdéseit rögzítő dokumentum. Nézzünk egy gyenge és egy jó változatot:
Gyenge: „Tervezek egy appot az egyetemi ügyintézéshez.” Ez túl sok emberre, folyamatra és következményre utal; nem lehet belőle tesztelhető feladatot kijelölni.
Jobb: „Megvizsgálom, hogyan tud egy elsőéves hallgató egyetlen hiánypótlási kérvényhez szükséges dokumentumokat azonosítani és beadni, anélkül hogy több helyen ellentmondó információt keresne.” Itt már látszik a felhasználó, a feladat, a feltételezett akadály és a tervezhető határ.
A brief alapvető elemei
Egy féléves projekthez általában elegendő, ha a brief a következőket tartalmazza.
Elem
Kérdés
Példa (Mai program)
Problémakör
Milyen helyzetet vizsgálsz?
Hallgatók esti programválasztása
Célfelhasználó
Kinek tervezel?
Spontán programot kereső hallgató
Elsődleges feladat
Mit akar elérni?
Ma estére megfelelő programot választani
Jelenlegi helyzet
Hogyan oldja ma meg?
Több oldalon, ismerősök üzenetei alapján
Szervezeti cél
Mit szeretne a fenntartó?
Minél több esemény és használó
Korlátok
Mi szab határt?
Külső adatforrások, nincs fizetési integráció
Kutatási kérdések
Mit nem tudsz még?
Mely adatok döntőek?
Sikerkritérium
Honnan tudod, hogy jobb?
Két percen belül talál megfelelő eseményt
Kizárások
Mit nem vállalsz?
Fizetés, szervezői felület, értékelések
A kizárás különösen fontos: például a projekt nem foglalkozik a háttérrendszer fejlesztésével, fizetéssel vagy minden lehetséges felhasználói szereppel. A kizárás nem gyengeség, hanem tudatos döntés.
Minden mondatnál kérdezd meg, honnan származik. A briefet indíthatja megbízói információ, saját megfigyelés vagy előzetes kutatás, de ezeket ne mosd össze. A „hallgatók nem értik a folyamatot” lehet kutatandó feltételezés, míg „a rendszerben három különböző űrlap létezik” ellenőrizhető tény. Használd az 1. fejezetben tanult bizonyítékcímkéket.
Hatókör és döntési fegyelem
A hatókör (scope) a projektben vállalt és tudatosan kizárt feladatok határa. A hatókör szűkítése nem a probléma kicsinyítése, hanem a tanulás feltétele. Ha egy prototípusban mindent meg akarsz tervezni (keresést, fiókkezelést, értesítést, fizetést, adminfelületet), akkor egyik döntést sem fogod érdemben kutatni vagy tesztelni. Válassz egy magas értékű, nagy bizonytalanságú feladatot, és rajzolj köré világos kezdetet és véget.
Hasznos kérdés: melyik ponton lenne a felhasználó számára a legnagyobb veszteség, ha hibázna vagy feladná? Ez lehet a megfelelő szolgáltatás kiválasztása, az adatok ellenőrzése vagy a visszaigazolás értelmezése. A briefnek nem az a célja, hogy mindenre választ adjon, hanem hogy kijelölje, mely kérdések érdemelnek kutatást.
Egy féléves projektben sokkal erősebb eredmény egyetlen, nagy kockázatú feladat jól kutatott és tesztelt megoldása, mint tíz csak megrajzolt képernyő.
Kik az érintettek?
Az érintett (stakeholder) olyan személy vagy szervezet, akire a szolgáltatás vagy egy tervezési döntés hatással van, vagy aki hatással van arra. A célfelhasználón kívül is vannak érintettek. Egy ügyintézési felületen érintett lehet az ügyintéző, aki hiányos kérelmeket kap; a tanszék, amely szabályt ad; az IT-üzemeltetés, amely a rendszert fenntartja; és a hallgató segítője, akihez elakadáskor fordul.
Az érintetti térkép nem azt jelenti, hogy mindenkinek külön terméket építesz. Azt jelenti, hogy látod, ki ad adatot, ki hoz szabályt, ki viseli a hiba következményét, és ki lehet később döntéshozó.
Készíts táblázatot:
Érintett
Cél / érdek
Hatás a projektre
Nyitott kérdés
Hallgató (célfelhasználó)
Gyorsan megfelelő programot találni
A fő feladat
Mely adatok a legfontosabbak?
Eseményszervező
Minél több résztvevő
Ő adja az adatokat
Mennyi adatot hajlandó megadni?
Fenntartó (egyetemi szervezet)
Aktív, megbízható szolgáltatás
Dönt a keretekről
Milyen mérőszámot figyel?
Üzemeltető
Karbantartható rendszer
Technikai korlát
Milyen formátumban kap adatot?
Ez korán felfedi a konfliktusokat. A felhasználó gyors beküldést szeretne, az ügyintéző viszont teljes dokumentációt. A jó terv nem feltétlenül választ egyikük helyett: például előzetes ellenőrzéssel és világos követelményekkel mindkét oldal terhe csökkenthető.
Hasznos kiegészítés a hatás–érdek rács: két tengelyen (mennyire érintett, mennyire tud hatni a projektre) helyezed el az érintetteket. A nagy hatású és nagy érdekeltségű szereplőkkel érdemes korán egyeztetni, a kis hatásúakat elég tájékoztatni.
Végigvezetett példa: a Mai program briefje
Első ötlet: „események keresése és a jelentkezés kezelése egy helyen”. Kutatás előtt azonban nem ismert, hogy a felhasználók inkább ár, helyszín, társaság mérete vagy időpont alapján döntenek-e. A kutatás (2. fejezet) azt mutatta, hogy az ár, a nyelv és a jelentkezési feltétel a döntő. A brief ezért a következőre szűkít:
Spontán programot kereső hallgató számára ma esti események összehasonlítása és a jelentkezési feltétel megértése.
A fizetési integrációt és a szervezői felületet kizárja, de jelzi, hogy ezek külső korlátok. Az érintetti táblázat megmutatja, hogy a szervezők adatminősége a siker feltétele, ezért a briefben külön nyitott kérdés: „Mennyi adatot hajlandók megadni a szervezők?”.
Gyakori tévhitek
Állítás
Pontosítás
„A brief az ügyfél dolga, nem a tervezőé.”
A tervezőnek is meg kell értenie és szükség esetén vissza kell kérdeznie a keretekre.
„Minél több funkciót tartalmaz, annál jobb.”
A brief fókuszt ad; a kizárások ugyanolyan fontosak, mint a vállalások.
„Az érintettek térképe felesleges egy hallgatói projektben.”
Már egy egyszerű táblázat megmutatja a rejtett konfliktusokat és korlátokat.
Röviden
A brief rögzíti, mit vállalsz és mit nem, és megnevezi az állítások forrását.
A hatókör szűkítése a tanulás feltétele; egy feladat mélyen vizsgálva többet ér, mint sok felületesen.
Az érintetti táblázat feltárja, kinek mi a célja, ki ad adatot, ki viseli a következményt.
Ellenőrző kérdések
Mi az az egyetlen feladat, amelyet a projektedben végig tudsz kutatni és tesztelni?
Melyik briefállításod tény, és melyik csak feltételezés?
Ki viselné a legnagyobb következményt, ha a fő feladat hibázna?
Projektbrief és érintettek
Célok
A lecke végére a féléves projektet egyetlen, kezelhető feladatra tudod szűkíteni. Meg tudod különböztetni a brief bizonyított elemeit a feltételezésektől, és fel tudod térképezni, kiket érint egy döntés a végfelhasználón túl.
Miért kell brief?
A kutatás után sok ötlet, irány és lehetőség van előtted. Ilyenkor a legnagyobb veszély nem az, hogy kevés a lehetőség, hanem hogy mindent egyszerre szeretnél megoldani. A brief ezt védi ki: rögzíti, mit vállalsz és mit nem. Egy jól megírt brief az a pont, ahová a projekt során visszatérhetsz, amikor egy új ötlet kiterjesztené a hatókört, vagy egy vita elvinné a figyelmet a fő feladatról.
Mire való a brief?
A projektbrief a projekt problémáját, célját, kereteit és nyitott kérdéseit rögzítő dokumentum. Nézzünk egy gyenge és egy jó változatot:
A brief alapvető elemei
Egy féléves projekthez általában elegendő, ha a brief a következőket tartalmazza.
A kizárás különösen fontos: például a projekt nem foglalkozik a háttérrendszer fejlesztésével, fizetéssel vagy minden lehetséges felhasználói szereppel. A kizárás nem gyengeség, hanem tudatos döntés.
Minden mondatnál kérdezd meg, honnan származik. A briefet indíthatja megbízói információ, saját megfigyelés vagy előzetes kutatás, de ezeket ne mosd össze. A „hallgatók nem értik a folyamatot” lehet kutatandó feltételezés, míg „a rendszerben három különböző űrlap létezik” ellenőrizhető tény. Használd az 1. fejezetben tanult bizonyítékcímkéket.
Hatókör és döntési fegyelem
A hatókör (scope) a projektben vállalt és tudatosan kizárt feladatok határa. A hatókör szűkítése nem a probléma kicsinyítése, hanem a tanulás feltétele. Ha egy prototípusban mindent meg akarsz tervezni (keresést, fiókkezelést, értesítést, fizetést, adminfelületet), akkor egyik döntést sem fogod érdemben kutatni vagy tesztelni. Válassz egy magas értékű, nagy bizonytalanságú feladatot, és rajzolj köré világos kezdetet és véget.
Hasznos kérdés: melyik ponton lenne a felhasználó számára a legnagyobb veszteség, ha hibázna vagy feladná? Ez lehet a megfelelő szolgáltatás kiválasztása, az adatok ellenőrzése vagy a visszaigazolás értelmezése. A briefnek nem az a célja, hogy mindenre választ adjon, hanem hogy kijelölje, mely kérdések érdemelnek kutatást.
Egy féléves projektben sokkal erősebb eredmény egyetlen, nagy kockázatú feladat jól kutatott és tesztelt megoldása, mint tíz csak megrajzolt képernyő.
Kik az érintettek?
Az érintett (stakeholder) olyan személy vagy szervezet, akire a szolgáltatás vagy egy tervezési döntés hatással van, vagy aki hatással van arra. A célfelhasználón kívül is vannak érintettek. Egy ügyintézési felületen érintett lehet az ügyintéző, aki hiányos kérelmeket kap; a tanszék, amely szabályt ad; az IT-üzemeltetés, amely a rendszert fenntartja; és a hallgató segítője, akihez elakadáskor fordul.
Az érintetti térkép nem azt jelenti, hogy mindenkinek külön terméket építesz. Azt jelenti, hogy látod, ki ad adatot, ki hoz szabályt, ki viseli a hiba következményét, és ki lehet később döntéshozó.
Készíts táblázatot:
Ez korán felfedi a konfliktusokat. A felhasználó gyors beküldést szeretne, az ügyintéző viszont teljes dokumentációt. A jó terv nem feltétlenül választ egyikük helyett: például előzetes ellenőrzéssel és világos követelményekkel mindkét oldal terhe csökkenthető.
Hasznos kiegészítés a hatás–érdek rács: két tengelyen (mennyire érintett, mennyire tud hatni a projektre) helyezed el az érintetteket. A nagy hatású és nagy érdekeltségű szereplőkkel érdemes korán egyeztetni, a kis hatásúakat elég tájékoztatni.
Végigvezetett példa: a Mai program briefje
Első ötlet: „események keresése és a jelentkezés kezelése egy helyen”. Kutatás előtt azonban nem ismert, hogy a felhasználók inkább ár, helyszín, társaság mérete vagy időpont alapján döntenek-e. A kutatás (2. fejezet) azt mutatta, hogy az ár, a nyelv és a jelentkezési feltétel a döntő. A brief ezért a következőre szűkít:
A fizetési integrációt és a szervezői felületet kizárja, de jelzi, hogy ezek külső korlátok. Az érintetti táblázat megmutatja, hogy a szervezők adatminősége a siker feltétele, ezért a briefben külön nyitott kérdés: „Mennyi adatot hajlandók megadni a szervezők?”.
Gyakori tévhitek
Röviden
Ellenőrző kérdések