A brief célja nem az, hogy helyetted megtervezze a fejlesztést

Sok érdeklődő azért nem ír projektbriefet, mert úgy érzi, nem ismeri a megfelelő technikai kifejezéseket. Pedig egy jó briefhez nem kell tudni, hogy milyen adatbázist, keretrendszert vagy cloud szolgáltatást használjon a fejlesztő.

A brief elsődleges feladata az, hogy közérthetően bemutassa:

  • milyen üzleti helyzetből indul a projekt;
  • milyen eredményt szeretnél elérni;
  • kik fogják használni;
  • milyen folyamatot kell támogatni;
  • mi a legfontosabb az első verzióban;
  • milyen korlátok és meglévő rendszerek vannak.

A technikai tervezés ezek után következik.

1. Rövid üzleti háttér

Mutasd be néhány mondatban a vállalkozást és a projekt környezetét.

Példa:

Ipari alkatrészeket értékesítő KKV vagyunk. Az ajánlatkéréseket jelenleg e-mailben és Excelben kezeljük. Három értékesítő dolgozik ugyanazokkal az ügyfelekkel, ezért nehéz követni, ki hol tart.

Ez többet segít, mint az, hogy „CRM-et szeretnénk”.

2. A probléma

Írd le a jelenlegi működés fájdalompontjait. Konkrét helyzetekben gondolkodj:

  • elvesznek az érdeklődők;
  • lassú az ajánlatadás;
  • sokszor kell ugyanazt az adatot rögzíteni;
  • nincs közös ügyféltörténet;
  • az ügyfél nem látja a rendelés státuszát;
  • nehezen készül riport;
  • a meglévő weboldalt nem lehet szerkeszteni;
  • a rendszer mobilon nem használható.

A jó probléma-megfogalmazás nem megoldást ír elő, hanem láthatóvá teszi, miért szükséges a változás.

3. Üzleti cél és siker

A „legyen modern” nem mérhető cél. Jobb példák:

  • csökkenjen az ajánlat elkészítéséhez szükséges manuális munka;
  • minden érdeklődőnek legyen felelőse és következő feladata;
  • az ügyfél online tudjon időpontot kérni;
  • a termékadatok egy helyről legyenek szerkeszthetők;
  • vezetői dashboard mutassa a nyitott lehetőségeket;
  • az adminisztrátor kódmódosítás nélkül tudjon tartalmat frissíteni.

Nem szükséges az első napon pontos százalékot megadni, de legyen világos, mi alapján mondjuk majd, hogy a projekt értéket teremtett.

4. Felhasználók és szerepkörök

Sorold fel, kik használják a rendszert, és milyen jogosultsággal.

Példa:

  • látogató: szolgáltatásokat néz és ajánlatot kér;
  • ügyfél: belép, dokumentumot tölt fel és státuszt követ;
  • értékesítő: leadet kezel és ajánlatot készít;
  • vezető: riportokat lát és jóváhagy;
  • adminisztrátor: felhasználókat és beállításokat kezel.

A szerepkörök korai tisztázása segít elkerülni a későbbi adatvédelmi és jogosultsági problémákat.

5. A fő felhasználói folyamat

Írd le lépésenként, mi történjen egy tipikus esetben.

Példa időpontfoglalásra:

  1. az ügyfél kiválasztja a szolgáltatást;
  2. megadja a helyszínt és időpontot;
  3. a rendszer ellenőrzi a kötelező adatokat;
  4. visszaigazolás érkezik;
  5. az admin látja az új igényt;
  6. státuszt vált és értesíti az ügyfelet.

Nem kell minden kivételt az első briefben megoldani. A főútvonal már elegendő ahhoz, hogy jó kérdések szülessenek.

6. Kötelező, fontos és későbbi funkciók

Használj prioritási kategóriákat:

Kötelező az MVP-hez

Nélküle a rendszer nem tudja teljesíteni az alapcélt.

Fontos, de későbbi verzióba tehető

Értéket ad, de az első piaci vagy belső teszt nélküle is elindítható.

Ötlet vagy jövőbeli irány

Még nincs validálva, ezért ne növelje az első verzió kockázatát.

Ez a felosztás sokkal hasznosabb, mint egy 60 pontos, azonos prioritású kívánságlista.

7. Mi ne legyen része a projektnek?

A „non-goals” lista védi mindkét felet.

Példa:

  • az első verzióban nincs online fizetés;
  • nincs natív mobilapp, csak reszponzív webalkalmazás;
  • nincs automatikus jogi döntés;
  • a régi adatokból csak az aktív ügyfelek kerülnek át;
  • marketingkampány nem része a fejlesztési projektnek.

A scope-határ nem negatívum. Segít időben és költségben tartható projektet kialakítani.

8. Meglévő rendszerek és integrációk

Sorold fel:

  • weboldal és domain;
  • tárhely vagy cloud;
  • CRM vagy ERP;
  • számlázó;
  • webshop;
  • naptár;
  • levelezés;
  • fizetési szolgáltató;
  • külső adatforrás;
  • rendelkezésre álló API-dokumentáció.

A „kapcsolódjon a számlázóhoz” önmagában kevés. Fontos, milyen adat mikor és melyik irányba mozogjon.

9. Adatok és adatvédelem

Jelezd, ha a rendszer kezel:

  • személyes adatot;
  • egészségügyi vagy más különleges adatot;
  • pénzügyi adatot;
  • üzleti titkot;
  • dokumentumot vagy képet;
  • gyermekek adatait;
  • helyadatot.

A pontos jogi megfelelőséget szakértővel kell véglegesíteni, de a fejlesztőnek már a tervezéskor tudnia kell az adat kockázati szintjét.

10. Tartalom és design

Ki biztosítja a szöveget, képeket, logót, termékadatokat és fordítást? Van-e arculati kézikönyv? Milyen oldalakat vagy termékeket kedveltek, és miért?

A „legyen olyan, mint X” helyett írd le a tulajdonságot:

  • egyszerű navigáció;
  • kevés, egyértelmű döntési pont;
  • szakmai, de nem túl merev;
  • gyors mobilos használat;
  • erős termékkereső.

11. Határidő és döntési folyamat

A projekt időtartamát nem csak a fejlesztő sebessége határozza meg. Fontos:

  • van-e fix esemény vagy jogszabályi határidő;
  • ki ad visszajelzést;
  • ki hagyja jóvá a designt és funkciókat;
  • mennyi idő alatt születik ügyféloldali döntés;
  • mikor érkeznek a tartalmak és hozzáférések.

12. Költségkeret

A költségkeret megadása nem arra szolgál, hogy a szolgáltató automatikusan a teljes összeget elkérje. Segít olyan scope-ot javasolni, amely reális az adott keretben.

Ha nincs pontos keret, adj nagyságrendet vagy prioritást:

  • minimális validálható verzió;
  • kiegyensúlyozott üzleti verzió;
  • teljesebb, hosszú távú megoldás.

13. Üzemeltetési elvárás

Tisztázd:

  • mennyire üzletkritikus a rendszer;
  • mikor használják;
  • milyen első válaszidő szükséges;
  • kell-e monitoring és backup;
  • ki kezeli a felhasználókat;
  • szükséges-e havi fejlesztési keret.

14. Elfogadási feltételek

A projekt akkor adható át, ha a meghatározott folyamatok tesztelhetően működnek. Példák:

  • az ügyfél sikeresen beküldhet egy ajánlatkérést;
  • az admin megkapja és státuszt válthat;
  • a rendszer elküldi a jóváhagyott értesítést;
  • jogosulatlan felhasználó nem lát más ügyféladatot;
  • a főoldal mobilon és asztali gépen is használható.

Bemásolható rövid briefminta

Projekt neve:
Vállalkozás és üzleti háttér:
Jelenlegi probléma:
Elérni kívánt eredmény:
Célfelhasználók és szerepkörök:
Fő felhasználói folyamat:
MVP kötelező funkciói:
Későbbi funkciók:
Ami nem része az első verziónak:
Meglévő rendszerek és integrációk:
Kezelt adatok típusa:
Tartalom és arculat állapota:
Kívánt indulás vagy határidő:
Döntéshozó és kapcsolattartó:
Költségkeret vagy prioritás:
Üzemeltetési/SLA igény:
Egyéb fontos megjegyzés:

A BT Digital megközelítése

Nem várjuk el, hogy az ügyfél technikai specifikációt írjon. Az a mi közös feladatunk. A jó brief viszont segít abban, hogy ne egy előre kiválasztott technológiáról, hanem a valódi üzleti célról induljon a beszélgetés.

Minél tisztább a probléma és az első verzió határa, annál pontosabb lehet az ajánlat, az ütemezés és a megvalósítás.