de Angela Zhang

Cum să vă atingeți în mod eficient proiectele software

Cum sa va atingeti in mod eficient proiectele software

De când mi-am început cariera ca inginer software, am aflat că scopul este unul dintre cele mai dificile lucruri de corectat. Din păcate, programele CS din universități nu vă învață cu adevărat cum să abordați proiectele. Iată deci încercarea mea de a consolida ceea ce am învățat pe această temă.

Scoping-ul nu este ceva pe care să îl petreceți o zi în timpul proiectului și să nu vă mai gândiți niciodată. De fapt, pentru a acoperi cu exactitate un proiect, trebuie să acordați atenție pe tot parcursul proiectului în timpul:

  1. Faza de planificare: etapele incipiente ale definirii proiectului și a obiectivelor acestuia
  2. Faza scoping: momentul în care majoritatea oamenilor se gândesc la scoping. Aici încercați să enumerați lucrările care trebuie făcute având în vedere obiectivele proiectului și să estimați cât timp va fi necesar pentru a le realiza.
  3. Faza de execuție: când implementați efectiv proiectul.

Faza de planificare

Unul dintre cele mai importante lucruri de făcut în acest timp este să definiți obiective foarte specifice pentru proiect. De exemplu, în loc să „îmbunătățim X pentru a fi mai scalabil și mai performant”, un obiectiv mai bun și mai specific ar putea fi „îmbunătățirea X prin adăugarea de teste unitare, acceptarea de 20K de interogări pe secundă și reducerea mediei limitate a latenței utilizatorului la <= 200ms . ”

A avea obiective foarte specifice vă permite să tăiați nemilos orice nu contribuie la aceste obiective, astfel încât să nu suferiți caracteristica fluaj. În acest sens, ați putea lua în considerare și definirea explicită anti-goluri, și separarea must-have și drăguț de a avea.

Minimizați dimensiunea lotului proiectului (1) stabilind repere clare și puncte de control pentru proiect și (2) facilitând lansarea doar a unei părți a proiectului. Acest lucru nu numai că ajută la descompunerea proiectului, dar va permite, de asemenea, echipei să întrerupă sau să taie proiectul mai devreme dacă apare o altă sarcină cu prioritate mai mare.

Riscați proiectul cât mai curând posibil. Două modalități obișnuite de a risca un proiect includ (1) lucrul la cele mai riscante părți în avans și (2) prototiparea celor mai riscante părți folosind date fictive și / sau schele. Ori de câte ori este utilizat un nou sistem open-source sau un serviciu extern, acesta reprezintă de obicei un risc mare.

Nu optimizați pentru cantitatea totală de muncă realizată. In schimb, optimizați pentru impactul total în timp. Odată ce ați scăpat din partea cea mai riscantă, acordați prioritate lucrării la partea proiectului care ar duce la cel mai mare impact imediat.

Iată o modalitate de a vă gândi la acest lucru: trasați impactul unui proiect în timp, unde axa Y este impact, iar axa X este timpul. La începutul proiectului, impactul este de 0%, iar la sfârșitul proiectului, impactul este de 100%. Doriți să maximizați zona de sub curbă efectuând mai întâi sarcini cu rentabilitate ridicată.

Încearcă evita cât mai mult posibil rescrierea sistemelor mari de la zero. Când facem o rescriere, avem tendința să (1) subestimăm cât de mult ar fi munca, (2) să fim tentați să adăugăm noi caracteristici și îmbunătățiri și (3) să construim un sistem excesiv de complicat, deoarece suntem prea concentrați pe toate neajunsurile primul sistem.

În loc să faceți o rescriere mare, luați în considerare înlocuirea incrementală a subsistemelor. Aveți straturi de abstractizare bune care acceptă schimbarea unei părți a vechiului sistem la un moment dat, astfel încât nu trebuie să așteptați să se facă totul pentru a testa noul sistem.

Faza de scop

  • Doar inginerii care scriu codul ar trebui să fie cei care vizează misiunile. Nu managerii lor, nu premierul sau părțile interesate cheie din companie.
  • Rezistați tentației de a nu intra sub acoperire. Fii sincer cu privire la cât de mult vor dura sarcinile, nu cât de mult dorești tu sau altcineva (cum ar fi managerul tău sau echipa Go To Market).
  • Împărțiți proiectul în sarcini mici, fiecare durând două zile sau mai puțin. Când aveți sarcini care au ca scop „aproximativ 1 săptămână,”Deseori ajung să dureze mai mult pentru că nu ați enumerat toate sarcinile secundare pe care ar trebui să le faceți.
  • Defini repere măsurabile pentru a ajunge la obiectivul proiectului. Programați fiecare cu o dată calendaristică specifică care reprezintă momentul în care vă așteptați la atingerea acestei etape. Apoi, stabiliți un fel de responsabilitate externă cu privire la aceste etape, de exemplu, angajându-le către managerul dvs. și configurând verificări de referință.
  • Gândiți-vă la estimările timpului proiectului ca la distribuții de probabilitate, nu cele mai bune scenarii. În loc să spuneți cuiva că o caracteristică va fi terminată în 6 săptămâni, spuneți-i ceva de genul „există o probabilitate de 50% să o finalizați în 4 săptămâni și o șansă de 90% să o terminăm în 8 săptămâni.”Acest lucru tinde să oblige oamenii să fie mai reali.
  • Adăuga tampon pentru a ține cont de: (1) Timp de dezvoltare! = ora calendaristică, datorată întâlnirilor, interviurilor și sărbătorilor. De obicei, înmulțesc timpul de dezvoltare cu 1,5 pentru a ajunge la ora calendaristică. (2) Timpul sarcinilor de proiect neașteptate, deoarece există întotdeauna sarcini pe care nu v-ați dat seama că trebuie să le faceți până mult mai târziu, cum ar fi refactorizarea codului vechi, depanarea comportamentelor aparent inexplicabile, adăugarea de teste. Cu cât sunteți mai experimentat în domeniul de aplicare, cu atât acest multiplicator ar deveni mai mic.
  • Folosiți date istorice. Țineți evidența dacă ați avut tendința să depășiți sau să subliniați proiectele în trecut (majoritatea oamenilor tind să sublinieze). Ajustați-vă domeniul de aplicare în consecință.
  • Ține minte că 2X numărul de persoane nu înseamnă 1 / 2X timpul dev, ca urmare a cheltuielilor generale de comunicare, a creșterii timpului etc.
  • Considera timeboxing părți deschise ale proiectului. În loc să „găsiți cel mai bun cadru de procesare a fluxului pentru acest sistem”, care poate dura luni de cercetare și prototipuri, aruncați-l în timp pentru a „găsi un cadru adecvat de procesare a fluxului într-o săptămână”. Folosiți-vă judecata aici pentru a echilibra acest lucru cu a genera costuri operaționale pe termen lung.

Faza de execuție

Redimensionați în mod regulat în timpul execuției proiectului. Pentru fiecare sarcină, urmăriți cât timp ați estimat că va dura sarcina, apoi cât de mult v-a trebuit să o finalizați. Faceți acest lucru pentru fiecare etapă măsurabilă. Dacă scopul dvs. este dezactivat cu 50% pentru primele părți ale proiectului, șansele sunt ca domeniul dvs. de aplicare să fie, de asemenea, dezactivat cu 50% pentru restul proiectului.

Folosiți repere pentru a răspunde „cum merge proiectul?” Ca ingineri, este tentant să răspundem „se va face până săptămâna viitoare” sau „până la sfârșitul acestei luni”. Dar aceste tipuri de răspunsuri vagi tind să creeze proiecte care sunt mereu La 2 săptămâni distanță de a fi terminat. În schimb, utilizați etapele (re-scopate) pentru a da un răspuns concret bazat pe cât de multă muncă a rămas.

Dacă proiectul alunecă, asigurați-vă că toată lumea înțelege de ce a alunecat proiectul. Apoi, dezvoltați o versiune realistă și revizuită a planului de proiect. Renunțarea la proiect sau scurtarea acestuia este o opțiune potențială care ar trebui luată în considerare. Citiți mai multe despre Eșecul costului scufundat dacă sunteți curioși de ce oamenii au tendința de a influența împotriva tăierii unui proiect pe jumătate.

Acordând credit acolo unde se datorează credit, o mulțime de informații aici provin din discuțiile cu inginerii și managerii Spencer Chan și Nikhil Garg, citind cărți de genul Inginerul eficient de Edmond Lau, și vizează personal o mulțime de proiecte cu grade diferite de precizie.

În cele din urmă, dacă sunt sincer, nu sunt în niciun caz un expert în domeniul de aplicare și încă fac greșeli în mod regulat, ca și cum nu urmez unele dintre cele mai bune practici de mai sus. M-am gândit doar că aș documenta învățăturile mele până acum, astfel încât să mă pot referi la asta în viitor.

Dacă îți place această postare, urmărește-mă pe Twitter pentru mai mult conținut despre inginerie, procese și sisteme backend.