Să privești din exterior cum crește o afacere este o adevarată plăcere. Puțini însă se gândesc la detalii și puțini sunt cei care analizează cu atenție pașii mărunți care au dus spre succes.
Astăzi, știm clar că, înainte de a demara un proiect nou indiferent de industrie, este nevoie de un plan de acțiune. În majoritatea domeniilor planul de afaceri este cel mai cunoscut și mai des întâlnit. Recent însă în industria software, a apărut un nou concept de analiza POC.
Conform Wikipedia, un POC (proof of concept - concept de business) se definește ca fiind realizarea unei metode sau idei în scopul de a-i demonstra fezabilitatea. În unele cazuri acest POC ia forma unui prototip care oferă multe informații despre viitorul proiect, identifică nevoile, trasează caracteristicile principale și prezintă riscurile.
Conceputul POC s-a impus rapid în inginerie și industria software și este agreat de executant și de client pentru că permite evaluarea corectă și poate estima cât mai bine ce și cum trebuie făcut. Într-un POC se ia în considerare strategia de caracteristici, de preț, de piață, branding și modelul de business.
După cum relatează și Marius Ghenea într-un interviu dat cu ocazia Business Days, business-urile în care investește trebuie să fie validate în piață : "Este esențial să existe un proof-of-concept, ceea ce înseamnă o anumită validare, ce se poate face, în faza inițială, înainte de comercializare, pe focus-grupuri, beta-testeri, proiecte pilot, teste comerciale limitate sau alte tipuri de testare în piață. Dacă piața nu validează un concept de business, nu avem premise de succes, chiar dacă ideea de business pare spectaculoasă și unică."
În cazul unui proiect software demonstrarea funcționalității înainte de a începe dezvoltarea propriu-zisă, este mai mult decât benefică. Drept urmare nu este de mirare că tot mai mulți investitori și business angels agreează ideea unui POC în locul unui plan de business clasic.
Wayne Sutton, blogger la Wall Street Journal susține acest lucru în articolul "Don"t Need No Stinking" Business Plan". Argumentul ar fi că pornirea unui nou business este mult mai ușoară decât acum 15 ani și compară business plan-ul cu metoda waterfall de dezvoltare care e "outdated".
Totul trebuie să fie rapid și să înveți tot timpul odată cu clienții pe care-i servești și îi implici în proces din prima zi. Orice antreprenor trebuie să fie conectat și să își folosească experiențele din viața reală cât mai mult posibil. Autorul articolului se referă exclusiv la startup-urile în industria IT și lasă deoparte businessurile clasice.
Deoarece mediul antreprenorial din România e încă în curs de dezvoltare și pașii se fac mai timid de către tinerii creativi care își caută finanțare, business plan-ul mai rămâne o vreme un punct important de referință.
Menționăm câteva documente importante pentru un tech start-up:
Am observat de-a lungul timpului că tinerilor antreprenori le e greu să facă de la început distincția clară între core-business (activitatea principală) și celelalte activități suplimentare.
Într-un startup e greu de stabilit funcțiile principale pe care trebuie să le îndeplinească un sistem și funcțiile suplimentare. Cu toate acestea, e vitală existența unei liste cu toate posibilele funcții ale viitorului sistem, după care se prioritizează și se împart în funcții principale și secundare.
Voi detalia în continuare partea de use case-uri ca fiind relevantă pentru tech start-up-uri și care ajută mult antreprenorul să nu se abată de la planul stabilit inițial.
Use case-urile sunt modalitatea de a folosi un sistem pentru a atinge cu anumit țel pentru un anumit utilizator. Spre exemplu, un utilizator autentificat pe Amazon dorește să poată plăti cu cardul de credit un produs de pe site. Acesta se poate defini ca un obiectiv de atins.
Toate obiectivele setate împreună compun un set de use case-uri care arată modalitatea în care poate fi folosit un sistem și arată valoarea pe care acesta o aduce utilizatorilor.
Cartea Use-Case 2.0 The Guide to Succeeding with Use Cases scrisă de Ivar Jacobson, Ian Spence, Kurt Bittner prezintă dezvoltarea bazată pe use case-uri într-o variantă foarte accesibilă și practică.
Use case-urile pot fi folosite în dezvoltarea businessurilor noi, caz în care se asociază toată afacerea cu un sistem. Sistemul este cel care implementează cerințele și este subiectul unui model de use case. Calitatea si nivelul de finalizare al sistemului este verificată de un set de teste. Testele au rolul de a verifica dacă implementarea pe felii a use case-urilor a fost un succes sau nu.
Mergâng mai departe cu folosirea use case-urilor, cred că toată lumea e deja familiarizată cu user stor-urile. Aceste "povești" fac legătura între stakeholder-i, use case-uri și părți din use case-uri. Acest mod de a transmite cerințele pentru noul sistem este foarte răspândit pentru că ajută mult la identificarea părților de bază ce trebuie implementate pentru a putea crea un sistem functional de bază. Când se descrie o idee de afacere, modul cel mai bun de a transmite celorlalți începe natural cu "Vreau să fac o aplicație care să permită utilizatorilor de smartphone-uri să facă comandă la taxi prin intermediul unei aplicații care să poată fi instalată pe Android și iOS".
Închei scurta incursiune în analiza de dezvoltare a noilor businessuri cu mențiunea că fără o idee clară și un plan pus la punct de la început, șansele de reușită ale unui proiect sunt extrem de reduse. Fie că se pornește de la un business plan clasic, se merge pe ideea unui proof of concept sau se ajunge chiar la o listă prioritizată de use case-uri pentru noul sistem, planificarea fiecăriu pas înainte trebuie să se facă cu grijă și responsabilitate astfel încât să se poată evita toate riscurile cunoscute.
2. Use-Case 2.0 The Guide to Succeeding with Use Cases, Ivar Jacobson, Ian Spence, Kurt Bittner
de Ovidiu Mățan
de Roland Szabo
