Kaip efektyviai pritaikyti savo programinės įrangos projektus

Nuo savo programinės įrangos inžinieriaus karjeros pradžios sužinojau, kad taikymo srities nustatymas yra vienas iš sunkiausių dalykų. Deja, CS programos universitetuose nelabai moko, kaip vykdyti projektus. Taigi čia bandau įtvirtinti tai, ką išmokau šia tema.

Apimtis nėra dalykas, kurį galite praleisti dieną projekto metu ir daugiau niekada nebegalvoti. Tiesą sakant, norint tiksliai išplėsti projektą, turite atkreipti dėmesį viso projekto metu:

  1. Planavimo etapas: ankstyvasis projekto ir jo tikslų apibrėžimo etapas
  2. Apimties nustatymo etapas: laikas, kai dauguma žmonių galvoja apie taikymo sritį. Čia bandote išvardyti darbus, kuriuos reikia atlikti atsižvelgiant į projekto tikslus, ir įvertinti, kiek laiko reikės jiems atlikti.
  3. Vykdymo etapas: kai jūs iš tikrųjų įgyvendinate projektą.

Planavimo etapas

Vienas iš svarbiausių dalykų, kurį reikia padaryti per šį laiką, yra apibrėžti labai konkrečius projekto tikslus . Pvz., Užuot „patobulinti X, kad būtų labiau keičiamo dydžio ir našesnis“, geresnis ir konkretesnis tikslas gali būti „patobulinti X, pridedant vieneto testus, palaikant 20 000 užklausų per sekundę ir sumažinant ribotą vartotojo delsos vidurkį iki <= 200 ms . “

Turėdami labai konkrečius tikslus, galite negailestingai iškirpti viską, kas neprisideda prie šių tikslų, kad nenukentėtumėte nuo ypatybių. Laikydamiesi šių nuostatų, taip pat galite apsvarstyti galimybę aiškiai apibrėžti anti-tikslus ir atskirti privalomus ir malonius turtus .

Sumažinkite projekto partijos dydį (1) nustatydami aiškius projekto etapus ir kontrolinius punktus ir (2) palengvindami tik projekto dalį. Tai ne tik padeda suskaidyti projektą, bet ir leis komandai anksti pristabdyti ar nutraukti projektą, jei iškils kita, aukštesnio prioriteto užduotis.

Kuo greičiau rizikuokite projektu . Du įprasti projekto rizikos mažinimo būdai yra (1) darbas su rizikingiausiomis dalimis iš anksto ir (2) rizikingiausių dalių prototipų sudarymas naudojant manekeno duomenis ir (arba) pastolius. Kai naudojama nauja atviro kodo sistema ar išorinė paslauga, tai paprastai kelia didelę riziką.

Neoptimizuokite viso atlikto darbo kiekio. Verčiau optimizuokite, kad laikui bėgant susidarytų visas poveikis . Kai pašalinsite rizikingiausią dalį, pirmenybę teikite tam projekto projektui, kuris iškart sukeltų didžiausią poveikį.

Štai vienas būdas galvoti apie tai: nubraižykite projekto poveikį laikui bėgant, kur Y ašis yra smūgis, o X ašis - laikas. Projekto pradžioje poveikis yra 0%, o projekto pabaigoje - 100%. Pirmiausia atlikdami didelių IG užduotis norite padidinti plotą po kreive.

Stenkitės kuo labiau vengti didelių sistemų perrašymo nuo nulio . Atlikdami perrašymą, mes linkę (1) neįvertinti, kiek tai būtų darbo, (2) susigundyti pridėti naujų funkcijų ir patobulinimų ir (3) sukurti pernelyg sudėtingą sistemą, nes esame per daug susitelkę į visus trūkumus. pirmoji sistema.

Užuot atlikę didelį perrašymą, apsvarstykite galimybę palaipsniui pakeisti posistemes. Turėkite gerus abstrakcijos sluoksnius, kurie palaiko vienos senosios sistemos dalies keitimą vienu metu, todėl jums nereikės laukti, kol viskas bus padaryta norint išbandyti naują sistemą.

Apimties nustatymo etapas

  • Tik inžinieriai, užrašantys kodą, turėtų apimti užduotis. Ne jų vadovai, ne premjeras ar pagrindiniai įmonės suinteresuoti subjektai.
  • Atsispirkite pagundai, kad nesiseka . Būkite sąžiningas, kiek užtruks užduotys, o ne tai, kiek laiko jūs ar kas nors kitas (pvz., Jūsų vadovas ar „Go To Market“ komanda) nori.
  • Padalinkite projektą į mažas užduotis, kurių kiekviena užtruks dvi dienas ar mažiau . Kai turite užduočių, kurių apimtys yra „ maždaug viena savaitė “, jos dažnai užtrunka ilgiau, nes nenurodėte visų galimų užduočių .
  • Apibrėžkite išmatuojamus etapus, kad pasiektumėte projekto tikslą. Suplanuokite kiekvieną su konkrečia kalendorine data, nurodydami, kada tikitės pasiekti šį etapą. Tada nustatykite tam tikrą išorinę atskaitomybę šiems etapams, pavyzdžiui, įpareigodami juos savo vadovui ir nustatydami svarbius patikrinimus.
  • Pagalvokite apie projekto laiko įvertinimus kaip apie tikimybės pasiskirstymą , o ne apie geriausius atvejus. Užuot pasakę kam nors, kad funkcija bus baigta per 6 savaites, pasakykite jiems kažką panašaus į „tikimybė, kad funkcija bus baigta per 4 savaites, ir 90% tikimybė, kad ją užbaigsime per 8 savaites . “Tai priverčia žmones būti realistiškesniais.
  • Įtraukite buferį į sąskaitą: (1) Dev laikas! = Kalendoriaus laikas dėl susitikimų, interviu ir švenčių. Aš paprastai padauginu dev laiką iš 1,5, kad pasiekčiau kalendoriaus laiką. (2) Netikėtas projekto užduočių laikas, nes visada yra užduočių, kurių nesuvokėte, kad turite atlikti tik daug vėliau, pvz., Pertvarkyti seną kodą, derinti iš pažiūros nepaaiškinamus veiksmus, pridėti testus. Kuo labiau patyrėte taikymo sritį, tuo mažesnis šis daugiklis.
  • Naudokite istorinius duomenis. Stebėkite, ar anksčiau buvote linkęs viršyti ar per mažinti projektus (dauguma žmonių linkę apimti). Atitinkamai sureguliuokite savo taikymo sritį.
  • Turėkite omenyje, kad 2x žmonių skaičius nereiškia 1 / 2X devo laiko , kurį lemia bendravimo išlaidos, padidėjimo laikas ir kt.
  • Apsvarstykite atvirų projekto dalių langelį . Užuot „radę geriausią šios sistemos srauto apdorojimo pagrindą“, kuris gali užtrukti kelis mėnesius trunkančiais tyrimais ir prototipų kūrimu, laiko juostoje „suraskite tinkamą srauto apdorojimo sistemą per savaitę“. Čia pasinaudokite savo sprendimu, kad tai subalansuotumėte nuo ilgalaikių veiklos pridėtinių išlaidų.

Vykdymo etapas

Vykdant projektą reguliariai pakeiskite taikymo sritį . Kiekvienos užduoties metu stebėkite, kiek laiko užtruksite, tada kiek laiko iš tikrųjų užtruko ją atlikti. Atlikite tai kiekvienam išmatuojamam etapui. Jei jūsų taikymo sritis yra išjungta 50% pirmosiose projekto dalyse, tikėtina, kad jūsų taikymo sritis taip pat bus išjungta 50% likusiam projekto laikotarpiui.

Naudokite gaires atsakydami į „kaip sekasi projektui?“ Kaip inžinieriai, norisi atsakyti „tai bus padaryta iki kitos savaitės“ arba „iki šio mėnesio pabaigos“. Tačiau tokio tipo neaiškūs atsakymai dažniausiai sukuria projektus, kurie visada būna 2 savaičių iki pabaigos. Vietoj to, naudokite (pakeistus) etapus, kad pateiktumėte konkretų atsakymą pagal tai, kiek liko darbo.

Jei projektas paslydo, įsitikinkite, kad visi supranta, kodėl projektas paslydo. Tada sukurkite realistišką ir patikslintą projekto plano versiją . Reikėtų apsvarstyti galimybę mesti projektą arba jį sutrumpinti. Skaitykite daugiau apie „The Sunk Cost Fallacy“, jei smalsu, kodėl žmonės linkę šalinti projekto pusiaukelę.

Skiriant kreditą ten, kur priklauso kreditas, daug informacijos čia gaunama kalbantis su inžinieriais ir vadybininkais, tokiais kaip Spenceris Chanas ir Nikhilas Gargas, skaitant knygas, tokias kaip „Efektyvus inžinierius“, Edmondas Lau, ir asmeniškai pasirinkus daugybę įvairaus tikslumo projektų.

Galiausiai, jei būsiu sąžiningas, jokiu būdu nesu taikymo srities ekspertas ir vis dar dažnai darau klaidų, pavyzdžiui, nesilaikydamas kai kurių geriausių praktikų. Tiesiog supratau, kad dokumentuosiu savo ligšiolinį mokymąsi, kad galėčiau tai dar kartą paminėti.

Jei jums patinka šis įrašas, sekite mane „Twitter“, kad gautumėte daugiau informacijos apie inžineriją, procesus ir vidines sistemas.