Un brief de proiect software bun descrie problema, utilizatorii, sistemele implicate și cum arată succesul și lasă soluția deschisă, ca partenerii să o propună. Trimiteți tuturor partenerilor același brief, cu un interval de buget și o listă clară a ceea ce este fix, iar propunerile primite vor fi suficient de precise pentru a putea fi comparate.
Un brief există pentru a face răspunsurile comparabile
Un brief de proiect are un singur rol: să le permită mai multor parteneri să vă înțeleagă problema suficient de bine încât să propună o cale de rezolvare, cu o estimare în care puteți avea încredere. Dacă fiecare partener umple golurile cu propriile ipoteze, propunerile diferă ca perimetru, nu ca calitate, iar cea mai ieftină este adesea cea care a presupus cel mai puțin.
Așadar, brieful trebuie să fie precis în privința problemei și modest în privința soluției. Descrieți ce trebuie să fie adevărat când proiectul este gata și lăsați partenerii să explice cum ar ajunge acolo. Răspunsurile lor la această parte deschisă sunt cel mai util lucru pe care îl veți citi.
Începeți cu problema de business și cu felul în care veți judeca succesul
Începeți cu motivul pentru care există proiectul: ce nu funcționează astăzi, pe cine afectează și cât vă costă să lăsați lucrurile așa cum sunt. Să spuneți că echipa de operațiuni reintroduce manual în ERP fiecare comandă primită pe e-mail îi spune unui partener mult mai mult decât să cereți un portal de gestionare a comenzilor.
Apoi spuneți cum veți judeca succesul. Alegeți câteva rezultate pe care le puteți observa, precum timpul economisit pe comandă, erorile care nu mai ajung la clienți sau o dată până la care un sistem vechi poate fi oprit. Aceste criterii devin mai târziu criteriile de recepție ale etapelor, așa că formulați-le în termeni pe care cineva i-ar putea verifica.
Descrieți utilizatorii, sistemele și datele înaintea funcționalităților
Munca de integrare și cea legată de date sunt ușor de subestimat când un partener nu le poate vedea. Înainte de a enumera funcționalitățile, descrieți cine va folosi software-ul, cu ce sisteme trebuie să funcționeze și ce date gestionează. Golurile din această parte revin mai târziu sub formă de cereri de modificare.
- Utilizatorii: cine sunt, cam câți sunt, unde lucrează și pe ce dispozitive.
- Sistemele existente: care sunt, cui aparțin și dacă oferă un API documentat sau doar o bază de date și exporturi de fișiere.
- Datele: ce este personal, confidențial sau reglementat, unde se află astăzi și cât din ele trebuie migrat.
- Operarea: cine va administra software-ul după lansare și ce reguli de găzduire sau de cloud are deja compania dumneavoastră.
- Constrângerile: limbile, nevoile de accesibilitate, standardele de securitate și orice termen care nu se poate muta, cu motivul lui.
Comunicați un interval de buget și termenul care contează cu adevărat
Mulți cumpărători ascund bugetul ca să vadă ce propun partenerii. Rezultatul sunt propuneri pentru proiecte diferite: un partener proiectează minimul, altul tot ce ați menționat. Un interval, chiar și larg, îi permite fiecărui partener să propună cel mai bun proiect care se încadrează în el și să vă spună deschis dacă nu se încadrează.
Procedați la fel cu timpul. Spuneți ce dată este fixă și de ce, de exemplu un contract care expiră sau un termen legal, și ce date sunt doar preferințe. Un partener poate planifica în jurul unui termen ferm doar dacă știe care este acela.
Marcați ce este fix și lăsați restul deschis
Etichetați fiecare cerință ca fixă, preferată sau deschisă. Fixă înseamnă că o propunere nu este validă fără ea, de exemplu găzduirea în UE sau autentificarea prin furnizorul de identitate existent. Preferată înseamnă că aveți un motiv, dar ați lua în calcul o alternativă. Deschisă înseamnă că vreți recomandarea partenerului.
Lăsați tehnologia deschisă, dacă nu aveți un motiv real să o fixați, precum o echipă internă care va întreține codul sau o platformă pe care compania a standardizat-o. Când fixați totuși o alegere, spuneți de ce, ca partenerii să nu-și petreacă propunerea argumentând împotriva ei.
În fine, cereți fiecărui partener să răspundă în aceeași structură: înțelegerea problemei, abordarea, fazele și etapele, ipotezele, riscurile, echipa și modelul comercial. O structură comună este ceea ce face propunerile comparabile în practică.
Greșeli care fac propunerile imposibil de comparat
Multe propuneri inutilizabile sunt răspunsuri la un brief care le-a provocat. Eliminați aceste tipare înainte de a-l trimite pe al dumneavoastră.
- O listă de funcționalități fără descrierea problemei, așa că fiecare partener vă ghicește prioritățile.
- O specificație lungă care fixează soluția înainte ca cineva să fi examinat problema.
- Nicio mențiune despre sistemele existente sau despre migrarea datelor, care revin apoi sub formă de cereri de modificare.
- Detalii suplimentare date doar unor parteneri, la telefon, așa că propunerile lor răspund la întrebări diferite.
- Cuvinte precum „simplu”, „standard” sau „ca o aplicație cunoscută”, care înseamnă altceva pentru fiecare cititor.
- Niciun termen-limită pentru întrebări sau răspunsuri comunicate doar partenerului care a întrebat.
Invitați întrebările și citiți-le ca parte a evaluării
Dați partenerilor o perioadă stabilită pentru întrebări, răspundeți în scris și trimiteți fiecare răspuns tuturor. Întrebările spun ele însele ceva: un partener care întreabă despre datele, utilizatorii și criteriile dumneavoastră de recepție se gândește deja la livrare.
Dacă problema este încă prea incertă pentru a fi descrisă bine, spuneți-o și cereți o scurtă fază de descoperire plătită în locul unei propuneri complete. O ofertă fermă construită pe presupuneri ascunde necunoscutele în marja de risc; o fază de descoperire înlocuiește presupunerile cu fapte. Dacă vreți ca niște ingineri să vă citească brieful sau să răspundă la el, îl puteți trimite prin formularul nostru „Începeți un proiect”.
De reținut
- Descrieți problema, utilizatorii și cum arată succesul și lăsați soluția deschisă.
- Munca de integrare și de date este ușor de subestimat, așa că enumerați fiecare sistem și fiecare set de date implicat.
- Comunicați un interval de buget și spuneți ce termen este fix și de ce.
- Marcați fiecare cerință ca fixă, preferată sau deschisă și cereți propuneri într-o structură comună.
- Răspundeți la întrebări în scris și comunicați fiecare răspuns tuturor partenerilor.
Întrebări frecvente
Cât de lung ar trebui să fie un brief de proiect software?
Suficient de lung cât să acopere problema, utilizatorii, sistemele, datele, constrângerile, intervalul de buget și calendarul, ceea ce, pentru majoritatea proiectelor, încape în câteva pagini. Dacă se lungește mult peste atât, probabil descrie soluția, nu problema.
Să comunicați bugetul partenerilor software?
Da, sub formă de interval. Fără el, partenerii propun proiecte de dimensiuni foarte diferite și nu le puteți compara. Un interval îi permite fiecărui partener să arate ce ar face în limita lui și să vă spună onest dacă nu este suficient.
Să cereți un preț fix ca răspuns la un brief?
Doar dacă brieful descrie munca suficient de detaliat pentru a putea fi estimată. Dacă întrebări-cheie sunt încă deschise, cereți o fază de descoperire la preț fix sau o estimare pe interval, cu ipotezele precizate, și fixați prețul construcției odată ce necunoscutele sunt lămurite.