Articles

Ce ar trebui să conțină un deviz detaliat de la o firmă de dezvoltare de aplicații web și mobile

Care client vrea să știe cât mai repede prețul proiectului. Chiar dacă există o modalitate rapidă de a determina prețul cu o estimare aproximativă, aceasta nu potolește setea. Aici intră în joc o estimare detaliată.

De fiecare dată când începem colaborarea cu un nou client, compania noastră de dezvoltare de aplicații web și mobile pregătește două documente cuprinzătoare care dezvăluie toate cele mai fine detalii legate de costurile proiectului clientului nostru.

Poate ați citit deja despre de ce și cum facem estimări aproximative (dacă nu, ar trebui neapărat să faceți acest lucru). Iar acum este timpul să descoperim tot ce ați vrut vreodată să știți despre estimările detaliate din MindK.

Ce este o estimare detaliată?

O estimare detaliată este un document cărnos care vă oferă o defalcare cuprinzătoare a costurilor pentru proiectul dumneavoastră.

Divizează întregul domeniu de activitate în părți elementare – caracteristici.

Care caracteristică este estimată separat de către echipele noastre interfuncționale.

Timpurile necesare pentru a termina fiecare caracteristică se adună pentru a forma un buget detaliat pentru aplicația dvs.

Stimare detaliată vs. estimare aproximativă

Dacă doriți să punem o etichetă de preț pe o idee de bază pe care tocmai ne-ați împărtășit-o, vă vom trimite cu plăcere o estimare aproximativă. Acesta vă poate oferi doar o idee generală despre costurile proiectului dumneavoastră.

O estimare detaliată este un document mult mai nuanțat și mai amplu.

În estimările aproximative, împărțim aplicația dumneavoastră în blocuri uriașe de funcționalitate numite epice.

În estimările detaliate, facem un pas mai departe și împărțim fiecare epică în funcționalități.

Înainte de a putea scrie estimarea detaliată, trebuie să adunăm și să documentăm toate cerințele, să clarificăm toate întrebările deschise și să scriem caietul de sarcini (în cazul unui model de angajament cu preț fix utilizat pentru proiect).

În acest fel suntem capabili să aflăm în prealabil toate detaliile necesare și să oferim ca rezultat cea mai precisă estimare.

Nu pot exista presupuneri în această etapă, ci doar afirmații.

Stimare detaliată vs. estimare precisă

Când avem de-a face cu estimări, Detaliat nu înseamnă neapărat Precis.

Iată de ce.

Stimațiile cu adevărat exacte sunt posibile numai după finalizarea fazei de Descoperire, prototiparea soluției, redactarea caietului de sarcini și aprobarea domeniului de aplicare detaliat al lucrărilor.

Pentru proiectele cu preț fix, întocmim o estimare detaliată numai după finalizarea fazei de Descoperire. De obicei, facturăm această fază ca pe un proiect separat.

Pentru proiectele Agile/Scrum, folosim o abordare diferită.

Conform acestei metodologii, dezvoltarea produsului este un proces dinamic și foarte flexibil. Scopul său principal este de a produce o soluție gata de utilizare la fiecare 2 până la 4 săptămâni și de a se adapta la feedback-ul utilizatorilor.

Facerea unei estimări definitive pentru întregul proiect nu se potrivește cu adevărat acestei abordări.

În cele mai multe cazuri, nu puteți prezice cu adevărat forma pe care o va lua aplicația dvs. peste luni și ani. De aceea, pentru proiectele Agile preferăm să folosim ceea ce numim Guesstimate.

Ne permite să pregătim estimări aproximative, dar extrem de detaliate, fără să pierdem o tonă de timp în faza de Descoperire.

Ce constituie o estimare detaliată?

O estimare detaliată în MindK are de obicei trei secțiuni: estimarea propriu-zisă, costurile legate de software și analiza riscurilor.

Stimatul propriu-zis

Secțiunea vă oferă o defalcare caracteristică cu caracteristică a costurilor pentru proiectul dumneavoastră.

Pentru proiectele cu preț fix, scriem doar costul exact al fiecărei caracteristici, dar pentru proiectele Agile, putem oferi doar o estimare aproximativă.

În această secțiune, nu includem nimic altceva decât caracteristicile care sunt 100% confirmate de către clienții noștri. Dacă aceștia decid la un moment dat să adauge o caracteristică, o estimăm separat și actualizăm documentul.

Dacă un proiect este unul complex (de exemplu, aveți nevoie atât de o aplicație web, cât și de o aplicație iOS /Android, un chatbot și așa mai departe), fiecare dintre aceste componente este estimată separat.

Care caracteristică este scrisă sub forma unui user story. Acesta este un mod simplist de a reda o bucată de funcționalitate din punctul de vedere al utilizatorului.

De obicei, aceasta sună astfel:

Se citește: În calitate de <rol>, vreau <funcționalitate> astfel încât <avantaj> (de exemplu, în calitate de proprietar de blog, vreau un formular de abonare, astfel încât să am abonați care să primească actualizări cu privire la noul articol de pe blog.).

Poveștile utilizatorului sunt scurte, concise și flexibile. Dar, cel mai important, ele sunt extrem de ușor de înțeles, chiar dacă sunteți un începător în lumea dezvoltării de software.

Stimatul detaliat include defalcarea costurilor pentru fiecare tip de lucrare:

  • Analiză de afaceri;
  • Design;
  • Markup (HTML);
  • Dezvoltare;
  • Asigurarea calității;
  • Managementul proiectului (PM).

Costul PM reprezintă, de obicei, aproximativ 25% din rezultatul final. Procentul exact depinde de mai mulți factori:

  • Cu cât un proiect devine mai complex, cu atât mai multă comunicare și gestionare este necesară.
  • Cu cât echipa devine mai mare, cu atât mai dificilă devine gestionarea ei, ceea ce duce la ore suplimentare de PM.
  • Numărul de integrări cu terți poate, de asemenea, să influențeze costurile de gestionare. Pe lângă faptul că reprezintă încă o caracteristică de implementat (și de gestionat), API-urile terților necesită adesea ca PM-urile noastre să contacteze furnizorii de servicii.

De exemplu, comunicarea cu marile companii (bănci mari, corporații mari etc.) ca furnizori de API-uri poate fi o adevărată pacoste. Nivelul ridicat de birocrație și structurile ierarhice rigide pot transforma o sarcină atât de simplă într-o corvoadă chinuitoare.

Într-o subsecțiune separată, enumerăm toate caracteristicile standard.

Experiența noastră cu dezvoltarea mobilă și web ne spune că anumite caracteristici și sarcini sunt prezente în toate aplicațiile. Acestea pot include, de exemplu, configurarea serverelor și a mediului de dezvoltare, gestionarea proiectului, lansarea în Google Play (pentru aplicațiile Android) și așa mai departe.

Costul soluțiilor de la terți

Când vine vorba de dezvoltarea de software, reinventarea roții este un efort costisitor și adesea inutil. Din fericire, fiecare sarcină standard sau problemă frecventă din lumea IT are cel puțin o soluție gata făcută. Uneori acestea sunt gratuite, dar în cele mai multe cazuri trebuie să plătiți pentru ele.

Dacă pentru a finaliza un proiect trebuie să achiziționăm un software, un serviciu sau o bibliotecă de la terți, estimăm costul acestora și includem cifra în document.

Dacă proiectul dumneavoastră, de exemplu, suportă mesagerie SMS, atunci va trebui să plătim pentru un gateway SMS.

Dacă designul site-ului dvs. se bazează pe un anumit șablon gata făcut pe care doriți să îl folosiți, atunci vom adăuga costul acestuia la estimare.

Sau dacă clienții noștri doresc să îi ajutăm cu găzduirea, le sugerăm cele mai bune opțiuni (cum ar fi Amazon Web Services, DigitalOcean, sau alte servicii dovedite). Astfel, costurile asociate cu găzduirea și întreținerea serverului vor apărea în această secțiune.

Analiză de risc

Care proiect comportă anumite riscuri inerente. Sarcina managerului de proiect este de a le identifica și de a dezvolta strategii pentru a le face față.

În ciuda celor mai bune practici de gestionare a riscurilor, unele dintre riscuri se materializează și au un impact asupra costurilor unui proiect. Evaluăm fiecare risc potențial și le includem în estimarea detaliată.

Trebuie să plătiți suma specificată numai dacă un anumit risc se transformă într-o problemă reală. În caz contrar, păstrați banii.

Aceste estimări ne vor servi apoi ca o asigurare împotriva unei mari varietăți de pericole care amenință dezvoltarea proiectului dumneavoastră.

Iată câteva exemple de categorii de riscuri care apar în dezvoltarea produsului:

  • Calitate/Tehnică/Performanță (i.ex. utilizarea unei tehnologii noi sau excepțional de complexe, modificarea tehnologiei, obiective de producție imposibile);
  • Managementul proiectului (ex. alocarea defectuoasă a fondurilor și a timpului, planificarea insuficientă a proiectului);
  • Organizațional (ex. lipsa de coerență între obiectivele de cost, timp și domeniu de aplicare, prioritizare necorespunzătoare, susținere neregulată);
  • Extern (de exemplu, modificări ale legislației, probleme cu vânzătorii și părțile subcontractante, climatul).

După ce riscurile sunt identificate, PM le prioritizează și efectuează o analiză a riscurilor.

Scopul acesteia este de a afla probabilitatea (adică șansele de materializare) și impactul (consecințele materializării) fiecărui risc în parte.

Un exemplu?

După cum am menționat deja, furnizorii de API pot fi lenți în a răspunde. Aceștia pot întârzia să trimită documentația necesară sau pot oferi un suport sub așteptări. Acesta este un risc real despre care ar trebui să vă avertizăm din timp. Așa că îl punem în secțiunea de riscuri și, în același timp, dezvoltăm o strategie eficientă de gestionare a riscurilor pentru a minimiza probabilitatea amenințării și impactul acesteia.

Încheiere

Acum știți la ce să vă așteptați de la estimarea detaliată din MindK. Documentul vă va oferi un răspuns exhaustiv la întrebarea privind prețul proiectului dumneavoastră și vă va ajuta, de asemenea, la întocmirea bugetului. În cele din urmă, vă va oferi o imagine clară a ceea ce veți plăti.

Există altceva ce v-aș putea spune despre estimările detaliate din MindK? Doar scrieți-ne un rând și vă voi da un răspuns detaliat!

e-book agile development

  • 19
    Share
  • 19

.