Otkako sam započeo karijeru softverskog inženjera, naučio sam da je opseg opsega jedna od najtežih stvari za ispravljanje. Nažalost, CS programi na sveučilištima zapravo vas ne uče kako opseg projekata. Dakle, evo mog pokušaja da objedinim ono što sam naučio o ovoj temi.
Opseg nije nešto na što možete potrošiti dan tijekom projekta i nikad više ne razmišljati. Zapravo, da biste točno obuhvatili projekt, morate obratiti pažnju tijekom cijelog projekta tijekom:
- Faza planiranja: rane faze definiranja projekta i njegovih ciljeva
- Faza utvrđivanja opsega: vrijeme kada većina ljudi razmišlja o opsegu. Tu pokušavate nabrojati posao koji treba obaviti s obzirom na ciljeve projekta i procijeniti koliko vremena će biti potrebno za njihovo obavljanje.
- Faza izvršenja: kada zapravo provodite projekt.
Faza planiranja
Jedna od najvažnijih stvari koje treba učiniti tijekom ovog vremena je definiranje vrlo specifičnih ciljeva za projekt . Na primjer, umjesto „poboljšati X kako bi bio skalabilniji i učinkovitiji“, bolji i specifičniji cilj mogao bi biti „poboljšati X dodavanjem jediničnih testova, podržavanjem 20K upita u sekundi i smanjenjem srednje vrijednosti korisničke latencije na <= 200 ms . "
Imati vrlo specifične ciljeve omogućuje vam bezobzirno rezanje svega što ne doprinosi tim ciljevima, tako da ne patite od puzanja značajki. U skladu s tim linijama, mogli biste razmotriti i izričito definiranje protuciljeva i razdvajanje obveznih i lijepih stvari .
Minimizirajte veličinu serije projekta (1) postavljanjem jasnih prekretnica i kontrolnih točaka za projekt i (2) olakšavanjem pokretanja samo dijela projekta. To ne samo da pomaže u raščlanjivanju projekta, već će timu omogućiti da zaustavi ili ranji projekt rano ako se pojavi drugi zadatak višeg prioriteta.
Što prije riskirajte projekt . Dva uobičajena načina uklanjanja rizika iz projekta uključuju (1) unaprijed rad na najrizičnijim dijelovima i (2) izradu prototipa najrizičnijih dijelova pomoću lažnih podataka i / ili skele. Kad god se koristi novi sustav otvorenog koda ili vanjska usluga, to obično predstavlja velik rizik.
Nemojte optimizirati za ukupnu količinu obavljenog posla. Umjesto toga, optimizirajte za ukupnu količinu utjecaja tijekom vremena . Nakon što maknete najrizičniji dio s puta, dajte prioritet radu na dijelu projekta koji bi odmah rezultirao najvećim utjecajem.
Evo jednog načina da razmislimo o ovome: zacrtajte utjecaj projekta tijekom vremena, gdje je Y os utjecaj, a X os vrijeme. Na početku projekta utjecaj je 0%, a na kraju projekta utjecaj je 100%. Želite maksimizirati područje ispod krivulje radeći prvo zadatke s visokim ROI-jem.
Pokušajte što više izbjegavati prepisivanje velikih sustava od nule . Kada prepisujemo, skloni smo (1) podcijeniti koliki bi to posao bio (2) u iskušenju da dodamo nove značajke i poboljšanja i (3) izgradimo previše komplicirani sustav jer smo previše usredotočeni na sve nedostatke prvi sustav.
Umjesto velikog prepisivanja, razmislite o postupnoj zamjeni podsustava. Imajte dobre apstraktne slojeve koji podržavaju zamjenu jednog dijela starog sustava odjednom, tako da ne trebate čekati da se sve učini za testiranje novog sustava.
Faza opsega
- Samo inženjeri koji pišu kôd trebaju biti oni koji zadaju zadatke. Ni njihovi menadžeri, ni premijer, ni ključni dionici u tvrtki.
- Oduprite se iskušenju premalom . Budite iskreni u vezi s tim koliko će dugo trajati zadaci, a ne koliko vi ili netko drugi (poput vašeg menadžera ili tima za Go To Market) želite da potraju.
- Podijelite projekt na male zadatke, svaki od kojih traje dva dana ili manje . Kada imate zadatke koji imaju opseg " otprilike 1 tjedan ", oni često završe duže, jer niste nabrojali sve podzadate koje biste mogli obaviti.
- Definirajte mjerljive prekretnice kako biste došli do cilja projekta. Zakažite svaki s određenim kalendarskim datumom koji predstavlja kada očekujete da će se postići ova prekretnica. Zatim uspostavite neku vrstu vanjske odgovornosti za ove prekretnice tako što ćete ih, na primjer, predati svom upravitelju i postaviti provjere prekretnica.
- Procjene vremena projekta shvatite kao raspodjelu vjerojatnosti , a ne kao najbolji scenarij. Umjesto da nekome kažete da će neka značajka biti gotova za 6 tjedana, recite joj nešto poput „postoji 50% vjerojatnosti da dovrši značajku za 4 tjedna i 90% šanse da ćemo je završiti za 8 tjedana . ”To obično tjera ljude da budu realniji.
- Dodajte međuspremnik na račun: (1) Vrijeme izrade! = Kalendarsko vrijeme zbog sastanaka, intervjua i praznika. Obično pomnožim razvojno vrijeme s 1,5 da bih došao do kalendarskog vremena. (2) Vrijeme neočekivanih projektnih zadataka, jer uvijek postoje zadaci za koje niste shvatili da ih trebate učiniti puno kasnije, poput refaktoriranja starog koda, uklanjanja pogrešaka naizgled neobjašnjivih ponašanja, dodavanja testova. Što ste iskusniji u opsegu, ovaj množitelj će dobiti manji.
- Koristite povijesne podatke. Pratite jeste li u prošlosti imali tendenciju pretjerivanja ili podcjenjivanja projekata (većina ljudi ima tendenciju premašiti). U skladu s tim prilagodite opseg.
- Imajte na umu da dvostruki broj ljudi ne znači 1/2 puta više vremena za razvoj , kao rezultat općih troškova komunikacije, vremena povećanja itd.
- Razmislite o vremenskom okviru za otvorene dijelove projekta . Umjesto da „pronađete najbolji okvir za obradu streama za ovaj sustav“, što može potrajati mjesecima istraživanja i izrade prototipa, vremenski ga „pronađite odgovarajući okvir za obradu prijenosa za tjedan dana“. Koristite svoju prosudbu ovdje kako biste to uravnotežili s dugoročnim operativnim režijskim rezultatima.
Faza izvršenja
Redovito mijenjajte opseg tijekom izvršenja projekta. Za svaki zadatak pratite koliko ste vremena procijenili da će vam trebati zadatak, a zatim koliko vam je zapravo trebalo da ga izvršite. Učinite to za svaku mjerljivu prekretnicu. Ako vam je opseg isključen za 50% za prve dijelove projekta, izgledi su da će i vaš opseg biti isključen za 50% za ostatak projekta.
Upotrijebite prekretnice da odgovorite "kako ide projekt?" Kao inženjeri, primamljivo je odgovoriti "to će biti učinjeno do sljedećeg tjedna" ili "do kraja ovog mjeseca". Ali ove vrste neodređenih odgovora obično stvaraju projekte koji su uvijek potrebni za dva tjedna do završetka. Umjesto toga, upotrijebite (preobuhvaćene) prekretnice kako biste dali konkretan odgovor na temelju preostalog posla.
Ako projekt promakne, pobrinite se da svi razumiju zašto je projekt kliznuo. Zatim izradite realnu i revidiranu verziju projektnog plana . Ispuštanje projekta ili njegovo skraćivanje potencijalna je opcija koju treba razmotriti. Pročitajte više o Zabludi potonulih troškova ako vas zanima zašto ljudi imaju tendenciju pristranosti protiv smanjivanja projekta na pola puta.
Dajući kredit tamo gdje je kredit potreban, puno informacija ovdje dolazi iz razgovora s inženjerima i menadžerima poput Spencera Chana i Nikhila Garga, čitanja knjiga poput Efektivnog inženjera Edmonda Laua i osobnog pregledavanja mnogih projekata s različitim stupnjevima točnosti.
I na kraju, ako sam iskren, nikako nisam stručnjak za opseg i još uvijek redovito griješim poput toga da ne slijedim neke od najboljih praksi gore. Samo sam zaključio da ću dokumentirati svoja dosadašnja učenja kako bih se na to mogao vratiti u budućnosti.
Ako vam se sviđa ovaj post, slijedite me na Twitteru za više sadržaja o inženjeringu, procesima i pozadinskim sustavima.