Ai nevoie de un erou: managerul de proiect

Acest articol este pentru tine, antreprenorul curajos cu o idee de aplicație în suflet și puțini bani în bancă. Diagramele pe care le-ați mâzgălit pe șervețele de cocktail vor perturba întreaga lume, iar basculantele pline de bani au fost deja trimise acasă. Pentru a vă asigura că sosesc la timp, iată câteva sfaturi simple pentru ca ciclul dvs. de producție să funcționeze fără probleme.

De ce aveți nevoie de un manager de proiect în primul rând

„Programele de calculator sunt cele mai complexe lucruri pe care le fac oamenii”, spune Douglas Crockford. Poate că nu ați mai auzit acest nume înainte, dar el este destul de faimos pentru un programator. În prezent, este un arhitect de software senior la PayPal și a fost pionier în tot felul de tehnologii interesante care depășesc domeniul de aplicare al acestui articol. Este cineva care știe multe despre lucrul la proiecte mari.

În ceea ce mă privește, programez de 13 ani și chiar și acum, la un moment dat, fiecare proiect mă duce pe un teritoriu neexplorat. Există atât de multe tehnologii diferite, iar noi tehnici sunt concepute într-un ritm atât de alarmant încât nu simt niciodată că sunt complet la curent cu ceea ce se întâmplă. Deși fiecare proiect are provocările sale unice, există câteva constante:

• Proiectul are presiune de timp.
• Bugetul este mai mic decât mi-aș dori.
• Sunt mai scump decât și-ar dori clientul.
• Nu ascult atât de perfect pe cât și-ar dori clientul.
• Clientul nu explică lucrurile atât de perfect pe cât mi-aș dori.

În mod clar, avem nevoie de o dădacă. Cineva trebuie să intervină pentru a stabili regulile de bază, pentru a-i menține pe toți sinceri și pentru a se asigura că nu uităm nimic important. Cineva trebuie să faciliteze comunicarea între toate părțile.

Acest cineva, acest erou, este managerul de proiect.

Toptal nu a oferit contracte cu managerii de proiect când am început să scriu acest articol, dar acum o fac. Sinergie! Nu pot decât să-mi imaginez că puterile au citit următoarele sfaturi și au realizat că au ratat o mare oportunitate.

De ce un programator nu face un bun manager de proiect

Pe lângă certificarea de către Project Management Institute, cel mai important lucru pe care un manager de proiect îl poate aduce la masă este experiența. Ca rezultat, mulți programatori ar fi manageri de proiect destul de decente; avem mai multă experiență în proiecte tehnice decât oricine altcineva, iar mințile noastre analitice sunt adepte în catalogarea informațiilor și stabilirea de obiective concrete.

Dumnezeu știe, ne plătești suficient, așa că pare rezonabil să ne așteptăm să ne descurcăm singuri decât să te obligă să plătești și pentru timpul altcuiva, nu?

Ei bine, pentru început, ne plătiți pentru codificare.

Când ieșim din nebunia programării pentru a lua decizii cu privire la ce să acordăm prioritate sau pentru a ne certa despre cât de mult se va face de fapt în această săptămână, codul nu este scris. Apoi este nevoie de cel puțin 10 minute pentru a reveni în „zonă”, mai ales dacă suntem stresați de conversația pe care tocmai am avut-o, ceea ce este probabil dacă ne certăm prioritatea caracteristicilor. Boo hoo, știu, dar totul este despre utilizarea cât mai eficientă a resurselor costisitoare.

Cel mai important, chiar nu putem vedea pădurea pentru copaci. Dacă nu luați nimic altceva din acest articol, vă rugăm să înțelegeți acest lucru: când îmi petrec toată ziua uitându-mă la câteva bug-uri specifice, creierul meu pierde urma imaginii de ansamblu.

Creierul meu mă răsplătește atunci când repar acele erori și presupun că am făcut lucruri grozave și că pot juca jocuri video acum. Când cineva îmi amintește că pagina de pornire este încă ruptă, este o surpriză completă, deoarece mi-am petrecut ziua umplându-mi mintea cu cunoștințe foarte detaliate despre o mică parte din proiectul general și am uitat oarecum de restul. Așa funcționează creierul meu și mulți alți programatori au o alcătuire psihologică similară.

De ce un client nu face un bun manager de proiect

Ei bine, atunci, dacă noi, programatorii, nu vrem să ne asumăm responsabilitatea pentru a duce la bun sfârșit lucrurile manageriale de proiect, atunci trebuie să vă revină dvs., clientul. Sunt banii tăi. Este viziunea ta. Oricum, ești responsabil pentru toată treaba.

Totuși, ai și tu multe în farfurie.

Mulți clienți sunt simpli muritori cu slujbe de zi ca noi ceilalți, iar unii chiar sunt cunoscuți că suferă de amânare sau uitare. Deși acest lucru nu vă descrie neapărat, în mod specific, vă rugăm să vă gândiți să aveți un Rememberer profesionist în preajmă, astfel încât să puteți reveni la munca importantă de a menține întregul proiect în viață.

Dacă ați lucrat la, sau ați supravegheat, un proiect tehnic de anvergură similară, puteți fi într-adevăr un bun manager pentru proiectul dvs. Dacă nu ați făcut-o, vă rugăm să nu subestimați valoarea cuiva care poate prezice problemele care pot apărea. Estimările de timp sunt întotdeauna doar estimări, iar erorile tind să apară în momentele cel mai puțin oportune. Merită costul unui alt angajat (dacă doar cu normă parțială) să aibă pe cineva în preajmă care știe care părți ale procesului necesită sau este probabil să aibă nevoie de cea mai mare atenție.

Luați, de exemplu, asigurarea calității (QA). Un QA adecvat este esențial pentru a obține ceea ce doriți de la orice proiect și nu primește niciodată atenția pe care o merită. Un bun manager de proiect va profita la maximum de resursele limitate de QA și, de asemenea, va asigura calitatea programatorilor dvs. Uneori, ieșim din profunzimea noastră, iar uneori facem greșeli. Aveți nevoie de o persoană competentă din punct de vedere tehnic, cu rol de supervizare, pentru a determina dacă programatorul dvs. are doar o zi liberă sau dacă el sau ea este, de fapt, o persoană potrivită pentru proiect. Îndepărtarea devreme a problemelor de personal ar putea însemna diferența dintre viață și moarte pentru proiectul tău.

În cele din urmă, chiar și dvs., clientul, aveți nevoie uneori de un mic control și/sau echilibru. Mi-e greu să scriu, deoarece noi, programatorii de computere, nu suntem bine cunoscuți pentru natura noastră deschisă. Este suficient să spunem că am lucrat la multe proiecte în care clientul a fost hotărât că totul este prioritate maximă și absolut tot ce trebuie să fie realizat. Deși nu am nicio îndoială că acest lucru a fost absolut adevărat, acești clienți, din păcate, nu au avut control asupra numărului de ore dintr-o zi. Nu au avut rezultatul pozitiv pe care și-au dorit și/sau meritat și cred că acest rezultat ar fi putut fi evitat dacă clientul i-ar fi încredințat unui manager de proiect autoritatea de a evalua volumul de muncă și, cu tact, dar ferm, să țină lucrurile sub control. . Este dificil să faci apelurile de judecată nepasională pe care le cer majoritatea proiectelor tehnice atunci când e ideea ta și banii tăi pe linie și computerului nu-i pasă dacă tu sau eu plângem și țipăm la el. (Știu că este adevărat pentru că l-am încercat de multe ori.)

O listă incompletă de tehnici de gestionare a unui proiect tehnic

Fie că ați decis să ignorați cele 1.000 de cuvinte anterioare și să vă gestionați singur proiectul, fie că veți angaja pe cineva, dar doriți să aveți mai multe cunoștințe despre proces, această listă vă va ajuta. Nu am fost niciodată (oficial) manager de proiect, așa că nu pot spune ce instrumente ar folosi un anumit manager de proiect, dar am avut succes cu toate aceste tehnici:

Repere

Când încep un nou proiect, majoritatea oamenilor știu intuitiv că este important să împărțiți proiectul în bucăți puțin mai ușor de gestionat, fiecare bucată variind de la câteva săptămâni la câteva luni de muncă. La începutul proiectului, este bine să aveți o întâlnire de lansare pentru a stabili aceste repere. Este în regulă să fii puțin vag cu privire la modul în care îi vei ajunge, cel mai important lucru este să continui să te verifici după fiecare etapă, pentru a beneficia de înțelegerea îmbunătățită a proiectului de către toată lumea și pentru a te asigura că reperele proiectului sunt încă ( aproximativ) de aceeași dimensiune pe care s-a crezut inițial.

Estimări de timp

Noi programatorii detestăm absolut estimările pentru că știm că vor fi greșite și știm că vor fi folosite împotriva noastră. Este în regulă că greșesc pentru că, prin definiție, se bazează pe o mână de necunoscute. De asemenea, este în regulă că sunt folosiți împotriva noastră pentru că slujbele noastre sunt destul de comode și nu strica să se spargă biciul din când în când.

Așadar, nu ezitați să solicitați estimări de fiecare dată când începe lucrul la o nouă etapă. Ar trebui să vă așteptați la o linie sau două pentru fiecare caracteristică majoră, împreună cu o estimare aproximativă a cât timp va dura această caracteristică. De obicei fac o estimare optimistă, apoi o dublez. De cele mai multe ori, acest timp suplimentar reprezintă capcane nevăzute.

Poveștile utilizatorilor

Poveștile utilizatorilor sunt descrieri scurte ale unei singure piese de funcționalitate din aplicație. Sunt utile ca o înregistrare a caracteristicilor importante și ar trebui să fie de dimensiuni mici, capabile să încapă pe o fișă și adesea însoțite de un mic desen. Mai important, ele servesc ca o punte între ceea ce își dorește clientul și ceea ce trebuie să spună programatorul computerului. Sunt suficient de simple pentru ca tu, clientul, să le elimini în câteva minute, dar suficient de detaliate pentru ca noi, programatorii, să ne înfundăm dinții.

Pentru câteva informații rapide despre poveștile utilizatorilor, am găsit aceste tutoriale de la Mountain Goat Software și Roman Pichler a fi de înaltă calitate și succinte. Pentru mai multe informații despre întreaga filozofie a managementului agil de proiect, încercați această postare de blog Toptal The Ultimate Introduction to Agile Project Management de Paul Barnes.

Compoziții (modele)

Acesta nu este un articol despre motivul pentru care aveți nevoie de un designer, deoarece cred că majoritatea clienților înțeleg deja asta, dar merită repetat pentru că veți vedea câștiguri enorme de productivitate dacă puneți o palmă în fața programatorilor dvs. cu un design concret și bine gândit. De fiecare dată când trebuie să luăm o decizie de proiectare, trebuie să părăsim „zona” și de fiecare dată când trebuie să ne întoarcem și să schimbăm ceva pentru că nu ni s-a furnizat schița finală, ei bine, tu faci calculul... Nu mă plâng, pentru că designul este distractiv, dar, din experiența mea, aceasta este sursa nr. 1 de ore evitabile și facturabile suplimentare.

Majoritatea designerilor oferă compoziții, cunoscute și sub numele de comps, în Adobe Photoshop, Adobe Illustrator sau Sketch. Dacă o faci singur, poți folosi unul dintre nenumăratele instrumente online precum Balsamiq sau InVision. Compania nu trebuie să aibă aceleași culori și stiluri ca și produsul finit (deoarece acestea pot fi modificate cu ușurință mai târziu), dar vă rugăm să acordați mai mult timp pentru a vă asigura că toate elementele UI sunt prezente și luate în considerare.

Întâlniri stand-up

Întâlnirile lungi sunt uneori inevitabile, dar chiar nu doriți să vă supraîncărcați programatorii sau să le ocupați mai mult timp decât este necesar. Am avut clienți care păreau să se aștepte să-mi amintesc tot ce s-a spus în timpul unei întâlniri de două ore și jumătate; erau amarnic dezamăgiți. O întâlnire stand-up este, în general, limitată la 15 minute și se obișnuiește să stea în picioare pentru toată durata. Aspectul în picioare ar trebui să asigure participarea tuturor, precum și să mențină întâlnirea scurtă.

În timpul stand-up-urilor, toată lumea se învârte într-un cerc pentru a furniza un scurt raport de stare, ținând toți membrii echipei la curent cu progresul fiecăruia. Puteți găsi mai multe despre stand-up la ExtremeProgramming.Org. Dacă lucrați cu toții de la distanță și nu doriți să puneți pe toată lumea pe Skype în fiecare zi, puteți încerca un instrument distractiv, cum ar fi 15Five, ca alternativă la stand-up-urile. 15Five le permite membrilor echipei să-și ofere contribuția ori de câte ori le este convenabil și le va pune întrebări la sondaj pentru a obține răspunsuri mai aprofundate.

Sistemul de bilete

Deși oricine poate menține un sistem de note lipicioase și Google Docs (cu sarcinile fiecăruia evidențiate în culori diferite), chiar nu este necesar; mulți oameni au încercat să rezolve această problemă pentru tine. Basecamp și Trello sunt renumite pentru ușurința lor de utilizare, în timp ce Pivotal încearcă să încapsuleze întreaga filozofie „agilă” într-un pachet foarte elegant. Indiferent de alegerea ta, un sistem bun de bilete îți va permite, cel puțin, să:

• Creați sarcini
• Alocați prioritate și data scadenței
• Conectați sarcini și subsarcini
• Atribuiți diferite rezoluții, cum ar fi „terminat” sau „testare eșuată”
• Afișați toate sarcinile atribuite unui anumit utilizator

Atunci când un manager de proiect vă arată 40 de bilete cu prioritate roșie aprinsă, toate scadente în aceeași zi, veți înțelege cu adevărat valoarea acestei vederi panoramice a proiectului.

Controlul surselor

S-ar putea să nu te uiți niciodată la codul din sistemul de control al versiunilor proiectului tău, dar controlul sursei (sau versiunea) este unul dintre cele mai importante instrumente pe care le avem la dispoziție, cel mai mare sistem de backup imaginabil.

Majoritatea proiectelor moderne folosesc Git, deși uneori te vei întâlni cu Subversion (SVN) atunci când lucrezi la proiecte care există de ceva vreme. Github vă permite să găzduiți depozite publice nelimitate gratuit (în plus, conține majoritatea proiectelor open-source din lume), în timp ce Bitbucket vă permite să găzduiți depozite private nelimitate și, prin urmare, este alegerea favorită pentru proiectele comerciale.

Indiferent de sistemul de control al versiunii pe care îl alegeți, acesta stochează codul nostru de la distanță în cazul în care se întâmplă ceva, plus pistele de fiecare dată când „commitem” cod în el, forțându-ne să scriem un mic mesaj care descrie la ce lucram. Acest lucru împiedică diferiți dezvoltatori să suprascrie reciproc codul, ne permite să vedem toate modificările care au fost făcute într-o anumită perioadă de timp și ne permite să creăm noi ramuri de cod pentru a stoca funcții care nu sunt disponibile imediat. Are chiar și o comandă numită „vină” care arată cine a fost responsabil pentru o anumită linie de cod și când a fost comisă.

Controlul sursei este cel mai mare.

Dezvoltare bazată pe teste

Aceasta este o practică relativ costisitoare, ceea ce înseamnă că nu este folosită frecvent în proiecte în care bugetul este limitat la un cuplu de liber profesioniști. Deci, tu, ca antreprenor de startup, nu ar trebui să te simți prea rău pentru că nu ai făcut asta, dar trebuie să-ți pun ideea în fața ta, deoarece oferă cea mai bună apărare împotriva erorilor. Practic, programatorii tăi petrec ore prețioase suplimentare scriind teste (blocuri de cod mici) care asigură că anumite părți ale aplicației se comportă în moduri specifice, previzibile și repetabile. De exemplu, aș putea scrie un test care să afirme că atunci când se face clic pe butonul „autentificare”, se deschide o fereastră pop-up cu un câmp de nume de utilizator.

Frumusețea testelor este că, odată ce le-am scris, le pot rula pe toate cu o singură comandă. Dacă am 200 de teste scrise, le pot rula după lansarea unei noi versiuni a aplicației pentru a mă asigura că nu au fost introduse erori în niciuna dintre aceste 200 de funcții. Nu este perfect, dar este cât se poate de aproape de a garanta aplicații fără erori (cel puțin bug-lite).

Învelire

Cam atât știu despre managementul proiectelor. Nu sunt sigur cât de mult din acest lucru ar trece peste la Project Management Institute, dar sunt toate lucrurile pe care le-am luat lucrând la proiecte web pe parcursul ultimului deceniu. Desigur, vă recomand să angajați pe cineva pentru a beneficia de experiența sa, dar sper că veți găsi aceste informații utile, chiar dacă nu puteți face asta. Veți fi autoritatea supremă în acest proiect, așa că, cu cât înțelegeți mai mult despre funcționarea lui interioară, cu atât aveți mai multe șanse să-l conduceți spre victorie.