Echipa este una dintre cele mai riscante componente ale unui start-up IT. Ce ar trebui să fie?
În primul rând, complet. Aceasta înseamnă că echipa ar trebui să includă dezvoltatori de tehnologie, backend și frontend, designer, tester, administrator de sistem, manager. Pe de altă parte, cea mai mică echipa, mai multe caracteristici combină o singură persoană - este, în general, nu-i rău, dar numai în primele etape ale proiectului, atunci este important să se facă rapid prima versiune, nu pierde timp pe birocrație, afaceri externe și planificarea meticuloasă.
În al doilea rând, au lucrat împreună. Interpretări necorespunzătoare - cum ar fi nisipul în ceasornicărie. Desigur, în timp, orice echipă este capabilă să se "obișnuiască", însă consecințele procesului în sine pot fi imprevizibile.
În al treilea rând, și este de dorit, colectate într-o singură cameră. Dar acesta este deja un element separat.
Există mai multe tipuri de echipe și fiecare are propriile caracteristici.
Comanda distribuită
Când designerul de la Kiev, programatori în Mumbai, și tu în Moscova. Sau invers, nu este important.
- Puteți găsi raportul optim preț-calitate pentru proiectul dvs.
- Nu trebuie să plătiți pentru birou
- Nu vă limitați la personalul din oraș / regiune atunci când formați o echipă (real, deoarece există foarte puțini oameni de calitate pe piață)
- Este dificil să controlezi oamenii
- Există inconveniente asociate cu fusurile orare
- Imaginea stereotipică a unui freelancer iresponsabil este adesea confirmată
- Dificultăți cu atragerea de fonduri: investitorul va fi mai interesat de proiect cu o echipă stabilă "aici și acum"
Echipa nedistribuită la birou
Cea mai bună opțiune pentru o pornire: toată lumea stă sub un singur acoperiș și face un lucru obișnuit.
- Convenabil pentru a controla și a gestiona
- Echipa este imbibata de spiritul proiectului
- Aveți posibilitatea să conduceți rapid rachete colective
- Puteți introduce rapid idei noi în proiect
- Echipa sa este mai atractivă pentru investitori
- costurile pentru birouri, echipamente, întreținere etc. (adesea opțiunea cea mai scumpă)
- Factorul uman: oamenii pot renunța sau se pot îmbolnăvi de câteva săptămâni
- Este necesar să se organizeze procesul de învățare
- Este necesar să se ocupe de resursele umane (inclusiv - să se recupereze rapid pierderile din unitate)
"Închirierea" unei echipe nedistribuite
Echipa este fizic în același birou, dar nu în biroul tău.
- Aveți la dispoziție o echipă pregătită
- Antreprenorul preia controlul asupra problemelor legate de resursele umane, înlocuind angajații
- Abilitatea de a "asambla" orice echipă pentru nevoile dvs.
- Contractorul rezolvă problemele de scalare rapidă a echipei (retrage din proiect persoane suplimentare sau extinde echipa de două ori)
- Structura costurilor este de înțeles și toate riscurile sunt stabilite în costul final al echipei
- Dificultăți de comunicare la distanță (dacă contractantul se află într-un alt oraș)
- Serviciile echipei pregătite vor fi mai scumpe decât serviciile freelancerilor
- implicarea emoțională scăzută a echipei în proiect
Cu alte cuvinte, trebuie să pornim de la nevoi și oportunități - nu este nimic greu aici.
Există două tipuri: pentru livrarea proiectului și pentru timp.
În cazul unei plăți fixe pentru proiect, totul este clar: contractorul renunță la proiect, clientul acceptă, banii sunt transferați. Poate în parte și cu o plată în avans. Schema ar funcționa perfect în cazul în care obiectivele au fost bine definite la început, cerințele nu au fost modificate, iar rezultatul final este o șansă de 100% imediat acceptat de către client (el nu se abate de la TOR).
În realitate, cu atât mai mult în dezvoltarea start-up-urilor, totul este mult mai complicat. Personal, experiența noastră arată că după 1-2 luni de muncă de către client mai mult decât se îngropa în subiect, prioritățile proiectului se schimbă, există noi provocări. Acest lucru este pur și simplu inevitabil și trebuie să fim gata pentru asta. O astfel de schemă de plată fixă poate fi apelată cu rezervări foarte mari.
Prin urmare, atunci când sunteți numit o sumă tare după evaluare - nu credeți. Cea mai bună modalitate de a rezolva un astfel de conflict este să începeți să lucrați la o plată fixă, verificați echipa în acțiune pentru a trece în cele din urmă la plata pe bază de timp.
Plata pentru timp și resurse (Timp Material) este plata pe oră a specialiștilor implicați în proiect, "creierul este închiriat până la ora". Fiecare specialist are propriul său rating (cost pe oră): managerul de proiect costă mai mult decât programatorul, programatorul este mai scump decât testerul și așa mai departe. Pe de o parte, circuitul este potrivit pentru start-up-uri: orice cereri noi, doresc ceva remake - vă rugăm să plătească la rata de, nu neapărat toate trebuie luate în considerare în evaluarea de la început. Dar există complicații. De exemplu, circuitul necesită un anumit nivel de încredere între client și conversațiile altfel inevitabile vor apărea dintr-o serie de „ce lucrează atât de încet, eu te plătesc banii!“.
Alte dezavantaje importante ale remunerării orare sunt:
- Echipa, care este închiriată de oră, orele rămase lucrează pe alte proiecte. Concentrarea se pierde și este imposibil să se obțină o întoarcere de 100% de la oameni.
Închiriați o echipă pentru o perioadă fixă (de exemplu, o lună). Schema mai preferată, aveți o echipă care vă este desemnată specialiștii potriviți, ale căror costuri sunt calculate conform formulei "prețul de cost + taxa suplimentară". Echipa lucrează exclusiv pe proiectul dvs. și este pregătită să rezolve orice probleme în timpul programului de lucru. În plus, multe echipe oferă reduceri dacă sunt angajate "în vrac".
Există un detaliu mic, dar foarte important. Se numește "specialist de volum de lucru".
În experiența noastră - o echipă de lucru de 5 persoane costă 450-550 mii de ruble pe lună.
Există multe riscuri. De exemplu:
- Lipsa controlului asupra dezvoltatorilor
Consecințele pot fi destul de neplăcute: de la refacerea constantă a codului la experimentele programatorilor cu "noi tehnologii interesante". Ca urmare, în jumătate de an va fi necesar să se rezolve consecințele experimentelor.
- Proiectul a fost în faza "făcută pentru 80%, începând cu 2 săptămâni" timp de 6 luni deja
Datorită arhitecturii construite incorect, proiectul cu fiecare lună poate fi făcut mai mult și mai mult. Motivul pentru o arhitectură greșită nu este doar lipsa de vizibilitate a programatorilor, ci adesea schimbările constante ale conceptului de proiect. De exemplu, un serviciu care a fost inițial destinat cititorilor de cărți, a decis brusc să redea editorul. Publicul sa schimbat, iar arhitectura nu a fost. Dacă fiecare activitate nouă se face mai mult și mai mult, fiecare acțiune efectuată generează una sau mai multe erori noi - acesta este primul simptom al problemei descrise.
- Probleme cu resursele umane
Cineva poate să renunțe, să se îmbolnăvească și cineva va promite condiții mai bune într-un alt start-up. Când un programator lasă un proiect neterminat, există un cod neterminat. Pentru a găsi o înlocuire a codificatorului, este nevoie de o medie de 2 luni. Și îi va lua tot atât de mult pentru a obține un nou angajat pentru a se obișnui cu proiectul. Și nu faptul că el va aranja totul și el va rămâne în echipă (sau - că vă va aranja).
- Nu este suficientă atenția QA
Testarea este aproape sarcina cheie a echipei de proiect. Modificările frecvente ale codului garantează că vor duce la erori, indiferent de calitatea cadrelor. Dacă nu există un tester (sau mai bine decât mai multe), greșelile se vor suprapune unul pe celălalt, iar prinderea motivelor lor va deveni mai dificilă cu timpul. Programatorii poate vorbi despre un test de sine, dar auto-testele oferă un control pe partea din spate-end, și nu am găsit probleme de genul „buton este glisat spre stânga.“
Riscurile startup sunt un subiect separat pentru un articol greu. Sau chiar cărți. Prin urmare, nu ne vom concentra prea mult pe ea, vă voi spune în detaliu data viitoare.
Totul este deja mai mult sau mai puțin în ceea ce privește, care este diferența dintre abordări. Dar, doar în caz, explicați pe scurt.
Cascada Waterfall (sau "cascada")
Acesta este momentul în care proiectul este dezvoltat în întregime, non-iterativ. Aceasta înseamnă scrierea unei documentații cuprinzătoare și a unor obiective clar definite ale proiectului.
- obiective clar definite, cerințe stabile
- Procesul de dezvoltare este ușor de înțeles și bine structurat
- Timp greu
- Predictibilitatea cheltuielilor de timp, de resurse
- necesitatea de a defini funcționalitatea proiectului deja în stadiul discuțiilor preliminare
- Lipsa de proiect, incapacitatea de a face schimbări rapide
- Dezvoltarea lungă și costisitoare a specificației tehnice a proiectului (care este deja depășită cu două luni)
Modelul agil (sau "flexibil")
Atunci când un proiect este dezvoltat în pași mici, obiectivele se schimbă în deplasare, se acordă mai puțină atenție documentației.
- Etapa-cu-pas, iterativă, emiterea unui proiect funcțional în "porțiuni" mici
- Abilitatea de a lansa rapid piața
- ajustări anticipate ale proiectului ținând cont de feedback-ul utilizatorilor finali
- Prioritățile se schimbă ușor fără a afecta procesul de lucru și bugetul
- Probabilitatea dezvoltării "infinite", având în vedere incertitudinea obiectivelor finale
- Creșterea continuă a "datoriilor tehnice". Deseori, printr-o abordare flexibilă, încearcă să lanseze o altă versiune brută a produsului, amânând să-l aducă în minte pentru mai târziu. În consecință, acest lucru poate duce la acumularea așa-numitei "datorii tehnice", pe care contractantul nu o poate întotdeauna să "plătească"
- Într-un moment critic, este posibil să nu existe documentație reală pentru proiect, dacă nu a fost acordată suficientă atenție
Este imposibil să numiți fără echivoc orice abordare bună sau rea. Aceeași echipă poate lucra pe agilă sau cascadă în diferite moduri. Dar flexibilitate pentru startup-uri încă suprascrie stabilitate - astfel încât deja proiecte nedovedite trec la modele mai flexibile de dezvoltare (de exemplu, DevOps, în cazul în care sute de modificări aduse proiectului în fiecare zi, se execută o mulțime de A / B-test și experimentul se dovedește, la fel ca mai mulți utilizatori) .
La această întrebare a fost deja răspuns parțial.
HR este un loc foarte problematic pentru o pornire. La început, pe lângă recrutare, veți avea destule dureri de cap. Dar recrutarea echipei este, de asemenea, o căutare: nu există suficient personal pe piață. Opțiunea de a crește propriii dvs. specialiști la o pornire nu se potrivește: e lungă și avem nevoie de o decolare rapidă. Vânătoare de la alte proiecte? Sau ar trebui să aveți un proiect foarte interesant și promițător sau ar trebui să aveți un portofel foarte gras.
Chiar dacă ați reușit și ați introdus prima echipă - cine a spus că acești oameni vor lucra împreună? Că nu va trebui să înlocuiți pe cineva? Sau obțineți mai mulți specialiști? Și dacă o persoană se îmbolnăvește brusc sau demisionează? În general, se poate îmbina doar în liniște, mai ales dacă lucrați cu utilizatori la distanță. Toate acestea nu trebuie trecute cu vederea.
Despre ce să căutați atunci când căutați oameni, precum și despre argumentele pro și contra ale echipei lor și "echipa de închiriat", am scris în răspunsul la întrebarea 2.
Bineînțeles, problema este pur individuală, dar există câteva termene tipice.
Distingem astfel de repere în dezvoltarea unui start-up:
- 1,5-2 luni - timp de lansare pentru MVP (produs funcțional minim) Acest lucru poate fi rulat cu acces închis sau restrâns, verificați iepurii și trageți concluzii cu privire la dezvoltarea ulterioară.
- 4-5 luni - termenele limită pentru lansarea versiunii finale a proiectului de orice complexitate
Într-o sută la sută din cazuri, cerințele de proiect se modifică după lansarea MVP și evaluarea impactului. Prin urmare - nu, nu.
Apropo, participarea a 50.000 de oameni pe zi - acest lucru nu este un motiv de panică, ei vor rezista confortabil și un server bun.
Amintiți-vă că fiecare membru al echipei își urmărește propriile scopuri egoiste. Este puțin probabil să puteți crea aceeași motivație pentru persoanele pe care le aveți personal. Programatorul va prefera să lucreze cu tehnologie interesantă, iar designerul va oferi cu plăcere o interfață nouă pentru Behance. au obiective diferite de obiectivul de pornire.
Cea mai evidentă modalitate de a preveni o situație în care dezvoltatorii învață pe tehnologia dvs. necunoscută bugetul dvs. - să vorbească despre tehnologia de pe țărm. Având un technicalad este un mare plus. Specializarea echipei pe anumite tehnologii (de exemplu, Ruby, Python și PHP pentru web, Swift pentru iOS, Java pentru Android) este un alt plus.
Ca o dorință: nu vă lipiți de noile tehnologii la modă. Există o mulțime de limbi și cadre de astăzi, dar nu există nici o garanție că vor trăi și vor fi amintiți despre ele într-un an și jumătate. Este puțin probabil să aveți nevoie de un proiect scris cu tehnologii moarte.
Un criteriu cheie pentru o pornire: tehnologiile trebuie să fie astfel încât să puteți găsi rapid o echipă de înlocuire în viitor.
Compararea riscurilor la utilizarea diferitelor tipuri de echipe și a schemelor de lucru.
Trimiteți-le prietenilor: