Brief projekti softuerik: 10 seksione që duhet t’i shkruani para se të kontaktoni një zhvillues

Shumica e projekteve softuerike që dështojnë nuk prishen te kodi. Prishen shumë më herët, në një bisedë të paqartë ku të gjithë kanë miratuar me kokë dhe askush nuk ka shkruar asgjë. Studimi i PMI-së për menaxhimin e kërkesave tregon se 47% e projekteve të pasuksesshme nuk i arritën objektivat për shkak të menaxhimit të pasaktë të kërkesave (PMI, Pulse of the Profession: Requirements Management). Një brief projekti softuerik i shkruar mirë është mënyra më e lirë për të mos u bërë pjesë e kësaj shifre.

Ky udhëzues ju tregon si ta shkruani një të tillë brenda një pasditeje, edhe nëse nuk jeni teknik: çfarë duhet të përmbajë, çfarë ta lini jashtë dhe si ta përdorni për të marrë oferta që mund t’i krahasoni vërtet.

Çfarë është një brief projekti softuerik (dhe çfarë nuk është)

Briefi është një dokument i shkurtër, zakonisht dy deri në pesë faqe, që shpjegon çfarë doni të ndërtoni, për kë dhe si do ta kuptoni që funksionoi. Ai qëndron mes një ideje me një rresht (“na duhet një aplikacion”) dhe specifikimit të plotë teknik.

Nuk është specifikim teknik. Nuk pritet që ju të zgjidhni bazën e të dhënave, teknologjinë apo pamjen e çdo ekrani. Kjo është puna e zhvilluesit, dhe një ekip i mirë do t’ju kundërshtojë nëse vendosni shumë herët zgjedhje teknike. Detyra juaj është ta përshkruani qartë problemin e biznesit dhe kufizimet, që ekipi të propozojë një zgjidhje të arsyeshme dhe ta çmojë me ndershmëri.

Pse ka rëndësi para se të flisni me ndonjë zhvillues

• Ofertat bëhen të krahasueshme. Nëse ia dërgoni të njëjtin brief tri kompanive, merrni tri përgjigje për të njëjtën pyetje, jo tri hamendje të ndryshme për atë që keni dashur të thoni.
• Zgjerimi i pakontrolluar i projektit bëhet i dukshëm. Kur gjatë punës shfaqet një ide e re, e krahasoni me briefin dhe vendosni me vetëdije nëse është ndryshim i fushëveprimit, pra me kosto ose afat të ndryshuar.
• Zbuloni boshllëqet tuaja. Kur shkruani “kush e miraton një porosi?”, shpesh del një vendim që askush nuk e ka marrë ende. Më mirë ta zbuloni para se të paguani orë zhvillimi.
• Mbron marrëdhënien. Shumica e mosmarrëveshjeve mes klientëve dhe ekipeve të softuerit vijnë nga pritshmëri të ndryshme për të njëjtën fjali.

10 seksionet e një briefi të mirë

1. Problemi, në terma biznesi

Filloni me atë që dhemb sot, jo me zgjidhjen. “Ekipi ynë i shitjeve rishkruan çdo kërkesë nga email-i dhe WhatsApp-i në një fletë Excel dhe afërsisht një ndjekje nga pesë harrohet” vlen shumë më tepër se “na duhet një CRM”. Nëse mund të jepni një numër (orë në javë, porosi të humbura, kërkesa mbështetjeje), jepeni. Nëse jo, thuajeni hapur.

2. Objektivat dhe si matet suksesi

Listoni dy-tre rezultate që do ta bënin projektin të suksesshëm: “Ta ulim futjen e porosisë nga 15 minuta në 3”, “Klientët të rezervojnë pa na telefonuar”, “Të zëvendësohet raporti mujor me dorë”. Këto bëhen kriteret e pranimit më vonë, prandaj duhet të jenë të vëzhgueshme.

3. Përdoruesit dhe rolet

Kush do ta përdorë sistemin dhe çfarë lejohet të bëjë secili? Një listë tipike: klient, punonjës, menaxher, administrator. Për secilin rol, një rresht për atë që duhet të arrijë. Ky seksion i vetëm ndikon shumë në vlerësimin e punës, sepse çdo rol shtesë sjell ekrane, leje dhe teste shtesë.

4. Rrjedhat kryesore të punës

Përshkruani tri deri pesë udhëtimet më të rëndësishme, hap pas hapi, me gjuhë të thjeshtë. Për shembull: “Klienti dërgon kërkesë për ofertë, shitjet marrin njoftim, shitjet dërgojnë ofertën, klienti e pranon, krijohet fatura.” Përfshini edhe rastet e këqija: çfarë ndodh kur pagesa dështon ose klienti anulon.

5. Detyrimisht, mirë-të-kesh, jo tani

Ndajini funksionet në tri grupe. Detyrimisht do të thotë që pa to produkti nuk vlen. Mirë-të-kesh shton vlerë, por mund të dalë më vonë. Jo tani është vendi ku ruhen ide të mira që do ta vononin versionin e parë. Është e njëjta disiplinë që përshkruajmë te udhëzuesi ynë për zhvillimin e MVP-së, dhe është mënyra më efektive për ta mbajtur buxhetin nën kontroll.

6. Sistemet ekzistuese dhe integrimet

Listoni çdo mjet me të cilin duhet të komunikojë softueri i ri: programi i kontabilitetit ose faturimit, faqja ose dyqani online, ofruesit e pagesave, WhatsApp, email-i, një bazë e vjetër të dhënash. Shënoni kush e zotëron secilin dhe nëse ka API. Integrimet janë një nga burimet më të shpeshta të punës së nënvlerësuar. Në Shqipëri, mos harroni lidhjen me fiskalizimin dhe faturat elektronike nëse sistemi do të lëshojë fatura.

7. Të dhënat, siguria dhe përputhshmëria

Çfarë të dhënash do të ruajë sistemi dhe sa të ndjeshme janë? Përmendni gjithçka të rregulluar me ligj: të dhëna personale, të dhëna pagese, dosje shëndetësore ose financiare. Nëse keni klientë në BE, thuajeni, sepse ndikon te hostimi, pëlqimi dhe afatet e ruajtjes. Nuk ju duhen përgjigjet, vetëm pyetjet.

8. Kufizimet: buxheti, afati, teknologjia

Jepni një interval realist buxheti dhe një datë të synuar, dhe shpjegoni çfarë e përcakton datën (një fushatë, një kontratë, një pikë sezonale). Intervali vlen më shumë se një shifër e vetme, sepse i lejon ekipit të propozojë opsione, si një fazë e parë më e vogël. Për një pikë reference, shihni sa kushton një faqe interneti në Shqipëri dhe faqen tonë të çmimeve. Përmendni edhe kërkesat e detyrueshme teknologjike, si “duhet të punojë me llogaritë tona ekzistuese të Microsoft 365”.

9. Referenca dhe shembuj

Pamje ekrani të mjeteve që ju pëlqejnë, konkurrentë, madje edhe foto të formularit në letër që përdorni sot. Një imazh shpesh zëvendëson një faqe përshkrimi. Shpjegoni çfarë ju pëlqen te secili shembull, jo vetëm emrin.

10. Kush vendos dhe si

Emërtoni një person me autoritet për të miratuar fushëveprimin, komentet dhe faturat. Projektet ngadalësohen kur pesë vetë kanë të drejtë vetoje. Shënoni edhe si doni të komunikoni (telefonatë javore, chat i përbashkët, demo çdo dy javë).

Një shembull i shkurtër

Ja si mund të lexohet një brief për një distributor të vogël:

Problemi: Stoku mbahet në tri skedarë Excel për dy depo. Shitësit telefonojnë depon për të parë disponueshmërinë dhe shesim më shumë se kemi afërsisht një herë në javë.
Objektivi: Një pamje e përbashkët stoku, e përditësuar sa futet një porosi, me njoftim kur një artikull bie nën minimum.
Përdoruesit: Shitjet (shohin stokun, krijojnë porosi), depoja (pranojnë dhe dërgojnë), pronari (raporte).
Detyrimisht: stok i drejtpërdrejtë për depo, futje porosish, njoftime për stok të ulët. Mirë-të-kesh: skanim barkodi. Jo tani: portal për klientët.
Integrime: eksport i faturave në programin e kontabilitetit; më vonë, sinkronizim me dyqanin online.
Buxheti dhe afati: interval i rënë dakord brenda kompanisë; versioni i parë duhet para pikës së janarit.

Janë më pak se 150 fjalë, dhe një ekip kompetent mund të bëjë tashmë pyetje të sakta dhe të japë një vlerësim të parë kuptimplotë. Për këtë skenar në thellësi, lexoni udhëzuesin për programin e menaxhimit të stokut.

Gabimet më të shpeshta që duhen shmangur

• Të përshkruani zgjidhjen në vend të problemit. “Ndërtoje një aplikacion me panel dhe chatbot” fikson zgjedhje para se dikush të kontrollojë nëse duhen.
• Çdo funksion të jetë “detyrimisht”. Nëse gjithçka është prioritet, asgjë nuk është, dhe buxheti shkon te 30% më pak e rëndësishme.
• Të injoroni njerëzit që do ta përdorin çdo ditë. Kërkojini atij që e bën punën sot t’i shqyrtojë rrjedhat tuaja. Ai i di përjashtimet që keni harruar.
• Të anashkaloni pyetjet e pronësisë. Bini dakord me shkrim që ju zotëroni kodin, të dhënat dhe llogaritë ku punon softueri.
• Ta trajtoni briefin si të ngurtë. Është dokument i gjallë. Përditësojeni kur ndryshojnë vendimet dhe ruani historikun e versioneve.

Çfarë bëhet me briefin pasi të shkruhet

1. Ndajeni me dy-tri ekipe, jo dhjetë. Cilësia e bisedës vlen më shumë se sasia e ofertave.
2. Vini re pyetjet që ju kthejnë. Ekipet e mira sfidojnë supozimet dhe tregojnë rreziqet; ato të dobëtat dërgojnë vetëm një çmim.
3. Krahasoni ofertat sipas fushëveprimit, supozimeve dhe asaj që përjashtohet, jo vetëm sipas totalit. Pyetjet te 12 pyetjet para se të firmosësh vlejnë për çdo ofrues.
4. Filloni me një fazë të parë të vogël dhe të përcaktuar mirë. Kështu të dy palët e provojnë bashkëpunimin para angazhimit më të madh.

Pyetje të shpeshta

Sa i gjatë duhet të jetë një brief projekti softuerik?

Zakonisht mjaftojnë dy deri në pesë faqe. Nëse shkon mbi dhjetë, ndoshta po shkruani specifikim teknik, që bëhet më mirë së bashku me ekipin e zhvillimit gjatë një faze zbulimi të paguar.

A më duhet një person teknik për ta shkruar?

Jo. Briefi shkruhet me gjuhë biznesi. Nëse mund t’i përshkruani procesin dhe problemin një kolegu të ri, mund ta shkruani briefin. Një partner i mirë zhvillimi do ta kthejë në kërkesa teknike.

Çfarë bëj nëse nuk e di buxhetin?

Jepni një interval që do të ishit rehat ta paguanit dhe thoni që është fleksibël. Ekipet mund të tregojnë çfarë blen çdo nivel. Nëse nuk e tregoni fare buxhetin, ofertat dalin ose të fryra, ose jorealisht të lira.

A duhet ta ndaj briefin nën një NDA?

Nëse përmban informacion vërtet konfidencial, po. Ekipet serioze janë mësuar ta nënshkruajnë. Mos vendosni në brief të dhëna të ndjeshme si lista klientësh; nuk ju duhen në këtë fazë.

A mund të më ndihmoni ta shkruaj?

Po. Shumë klientë vijnë vetëm me një problem dhe disa shënime. Një bisedë e shkurtër zbulimi zakonisht mjafton për t’i kthyer në një brief të strukturuar dhe një vlerësim të parë realist.

Shndërroni shënimet tuaja në brief dhe vlerësim të parë

Nëse keni një ide për aplikacion web, CRM, sistem të brendshëm ose automatizim me AI, por nuk dini si ta përshkruani, mund t’ju ndihmojmë ta formësoni. Na tregoni problemin, kush do ta përdorë softuerin dhe afërsisht kur ju duhet. Do t’ju kthejmë pyetjet që ia vlen t’u përgjigjeni, një fazë të parë të sugjeruar dhe një pamje transparente të kostos dhe afatit.

Filloni një bisedë me ekipin e Shkulaku ose shihni shërbimet tona të zhvillimit të softuerit.