käsittelen kysymystä ohjelmistotekniikan näkökulmasta, vaikka monet opituista asioista koskevat myös muita projekteja. Tuottaa tarkkoja projekti arvioita on yksi vaikeimmista tehtävistä tehdä ohjelmistotekniikan ja usein unohdetaan taito, että useimmat insinöörit (itse mukana) eivät tiedä, miten tehdä hyvin. On myös niin, että ihmiset, joiden ei ole tarvinnut arvioida hankkeiden valmistumisaikoja ennen, aliarvioivat vaikeuden ja saavat usein arvionsa väärin vähintään kahdella kertoimella. Kuten mikä tahansa taito, se vain paranee harjoittelulla.
elävin muistoni pieleen menneistä projektiarvioista tapahtui muutama kuukausi sen jälkeen, kun liityin insinööriksi ooyalassa, startupissa, joka tarjosi päästä päähän-nettivideoalustan. Elokuussa 2008, vain hieman yli vuosi yrityksen perustamisen jälkeen, suunnittelutiimi aloitti tuotteen Flash-pohjaisen videosoittimen uudelleenkirjoittamisen. Tavoitteemme oli tehdä pelaajasta modulaarisempi ja suorituskykyisempi sekä saada myös puhtaampi ja paremmin testattu koodebaasi. Alkuperäinen 3-henkinen tiimi suunnitteli ja kirjoitti joitakin perusinfrastruktuuria ennen kuin vedin itseni ja loput ~10-hengen insinööritiimistä. He arvioivat projektin valmistumiseen kuluvan 4 kuukautta, ja teknologiajohtaja ja tuotepäällikkö laativat Gantt-kaaviot, joissa on yhteenveto työn jakautumisesta ja riippuvuuksista. Uusi pelaaja päätyi täysin markkinoille 9 kuukautta myöhemmin toukokuussa 2009 .
emme jääneet tavoitteesta kovan työn tai lahjakkaiden insinöörien puutteen vuoksi; oli useita kuukausia, jolloin suurin osa tiimistä veti 70-80-tuntisia työviikkoja (ei suositella). Osana projektia kävimme jopa vaivalloisesti läpi muutaman päivän harjoituksia, joissa annoimme tuntiarviot melko rakeisiin tehtäviin. Suurimmat viivästykset johtuivat lähes aina monista ulkoisista tekijöistä, joita emme ottaneet huomioon alustavissa arvioissa.:
- erittäin tärkeiden asiakassopimusten allekirjoittaminen, joka vaati insinöörejä siirtymään tilaustyöhön,
- Adoben flash player-koodissa olevat virheet, jotka vaikeuttivat videon todellisen pysähtymisen tarkkaa määrittämistä, puskurointi ja toisto,
- vaikeasti Toistettavat videon korruptiovirheet, jotka kaataisivat soittimen etsiessään tiettyjä VIDEONKEHYKSIÄ IE: ssä,
- tuotekehityksen tarve jatkaa 4 projektiin kului kuukausia, jotta nykyinen asiakaskunta pysyisi tyytyväisenä,
- skaalautuvuusongelmat, joihin oli puututtava analytiikkadata kasvoi,
- varhainen insinööri lähti tiimistä kesken projektin, mikä edellytti suuren määrän koodebaasin pääosien tiedonsiirtoa,
- jne.
vaikka pelaajan uudelleenkirjoittaminen oli ehdottomasti välttämätöntä yhtiölle, ennakoimaton tapa vetää ulos vaati suuren veron varhaisesta käynnistymisestä. Muut Projektit olen työskennellyt, nähnyt second hand, tai keskustellut muiden insinöörien, ovat noudattaneet samanlaisia malleja, joissa todellinen valmistumisaika usein kaksinkertaistaa alkuperäiset arviot.
Tässä muutamia tähänastisia oppejani näistä kokemuksista:
niin paljon kuin mahdollista, ovatko ne ihmiset, jotka laativat arviot tehtävää varten, niitä todellisia ihmisiä, jotka työskentelevät sen parissa. Tämä on samanlainen kuin Ian McAllisterin pointti käyttää B-soittimen arviota – yhden henkilön on jo uskomattoman vaikea ennustaa tarkasti, kuinka kauan tehtävälista kestäisi itseltään, vaikka tehtävät olisivat melko rakeisia; on vielä vaikeampaa ennustaa, kuinka kauan kestäisi joku muu, jolla on erilainen perehtyneisyys ja erilainen taito. Ooyalan pelaajan uudelleenkirjoittamisen aikana kävi ilmi, että monet alkuperäisistä arvioista olivat erittäin aggressiivisia ja jättivät huomiotta insinöörin rampup-ajan koodebaasin osissa, joita hän ei tuntenut yhtä hyvin.
varo toisen järjestelmän vaikutusta. Myyttisessä Ihmiskuukaudessa Frederick Brooks kuvaa projektikokemuksistaan IBM: llä, kuinka ihmisen taipumus toisen järjestelmän ylisuunnitteluun johtaa monimutkaistumiseen huomattavasti aiheuttaen uudelleensuunnitteluprojektien aikataulujen lipsumisen :
arkkitehdin ensimmäinen työ on helposti säästeliäs ja siisti. Hän tietää, ettei tiedä mitä tekee, joten hän tekee sen huolellisesti ja hyvin maltillisesti.
kun hän suunnittelee ensimmäistä teosta, frillit frillit toisensa jälkeen ja kaunistus toisensa jälkeen tulevat hänelle mieleen. Nämä varastoidaan pois käytettäväksi ” seuraavalla kerralla.”ennemmin tai myöhemmin ensimmäinen järjestelmä on valmis, ja arkkitehti, jolla on luja luottamus ja joka on osoittanut hallitsevansa tämän luokan järjestelmiä, on valmis rakentamaan toisen järjestelmän.
tämä sekunti on vaarallisin järjestelmä, jonka ihminen on koskaan suunnitellut… Yleinen suuntaus on toisen järjestelmän ylisuunnittelu käyttäen kaikkia ensimmäisessä varovaisesti sivuraiteille jääneitä ideoita ja hienouksia.
erityisesti projektissa, johon liittyy olemassa olevien ohjelmistojen uudelleenkirjoittaminen, on houkuttelevaa niputtaa joukko uusia ominaisuuksia siihen, mikä muuten olisi voinut olla suoraviivainen portti, käyttäen argumenttia, että tiimi voisi yhtä hyvin tehdä sen, jos he aikovat kirjoittaa koodebasen joka tapauksessa. Monimutkaisuuden lisääntyminen voi johtaa siihen, ettei uudelleenkirjoitusta tai uusia ominaisuuksia käynnistetä vasta huomattavasti myöhemmin.
varo sekoittamasta, kuinka paljon aikaa projektin tehtävät vievät ja kuinka pian projekti valmistuu. Mitä kauemmin projekti kestää, sitä suurempi on todennäköisyys, että ulkoiset ympäristömuuttujat tulevat mukaan ja pidentävät projektin kokonaisaikataulua. Ianin mainitsema toistuva drag vaikuttaa projektin aikajanaan, mutta niin vaikuttavat myös yllättävät tapahtumat. Hankkeisiin, jotka olen työskennellyt aiemmin tänä vuonna Quora, monet niistä kesti kauemmin käynnistää kuin odotettiin, koska kumulatiivinen aika kustannukset:
- odottamattomaan, usean päivän AWS-häiriöön vastaaminen ja siitä toipuminen,
- perioidisten hakulaitteiden hälytysten käsittely sivuston ylläpitämiseksi,
- aikataulutetut lomat, jotka kerran tuntuivat kaukaisilta hankkeilta mutta jotka päätyivät päällekkäisiksi sen kanssa,
- rekrytointitapahtumiin valmistautuminen ja niihin osallistuminen,
- asiayhteys hankkeita, jotka osoittautuivat hankalammiksi kuin aluksi odotettiin.
minkä tahansa projektin kohdalla voidaan todennäköisesti luetella mikä tahansa määrä tapahtumia ja häiriötekijöitä, jotka yksittäisinä saattavat olla epätodennäköisiä tai epätarkoituksenmukaisia, mutta jotka yhdessä väistämättä tapahtuvat ja täsmäävät riittävän pitkän ajan kuluessa. Mitä pidempi projekti, sitä enemmän häiriötekijöitä on, ja on tärkeää budjetoida puskuriaikaa ulkoisille, tuntemattomille tekijöille.
budjetoi riittävästi aikaa kotoutumiseen liittyviin tehtäviin. Erityisesti projekteissa, joissa on monia toisiinsa liittyviä osia, monet insinöörit pyrkivät 1) lykkäämään päästä päähän-integraatiotehtäviä aivan loppuun ja 2) aliarvioimaan merkittävästi aikaa, joka tarvitaan kaikkien palojen integroimiseen toimivaksi järjestelmäksi. Koska integraatio on yleensä niin kaukana ja koska riskit ovat tyypillisesti tuntemattomia — oletus integraatioajan mukaan on, että kaikki komponentit toimivat onnistuneesti erillään — integraatioajan aliarviointi on yleensä melko yleistä. Projektit saavat usein vain pienen osan projektin kokonaisajasta päästä päähän-testaukseen, vaikka se on tyypillisesti yksi projektin riskialttiimmista puolista ja vaatii aikaisempiin virstanpylväisiin verrattuna huomattavasti enemmän yhteydenpitoa tiimin jäsenten välillä.
tästä seuraa, että päästä päähän-testaus on aloitettava mahdollisimman aikaisin, jotta integraatioriskit ja-ongelmat voidaan tunnistaa nopeammin, jotta niihin on riittävästi aikaa puuttua.
arvio perustuu siihen, kuinka kauan tehtävät oikeasti kestävät, ei siihen, kuinka kauan sinä tai joku muu haluaa niiden kestävän. Aina tulee olemaan paineita saada projektit nopeammin päätökseen joko itseltä, tiimisi jäseniltä, johdolta tai asiakkailta, ja usein tunnereaktio tuohon paineeseen ankkuroi meidät ulkoisesti vaadittuihin aikatauluihin ja johtaa meidät systemaattisesti aliarvioimaan tehtäviä. Psykologisesti kukaan ei halua tuottaa muille pettymystä, ja on helppo sanoa itselleen, että jos vain tekee vähän kovemmin tai tehokkaammin töitä, voi täyttää tietyn määräajan. Varsinkin pitkissä hankkeissa tällainen toiveajattelu on kuitenkin lopulta kestämätöntä.
tarkista määräajoin hankearviot hankkeen edetessä. Aivan kuten se, miten useimmat hyvät ohjelmistot rakennetaan ja parannetaan vähitellen, niin ovat myös Projektiarviot. Projektiarvioiden tarkistaminen ja kuluneen viikon tehtävien arvioiden vertaaminen toteutuneeseen aikaan auttaa selvittämään arviointivirheitä ja tarkistamaan aikatauluja, jotka perustuvat aiemmin ennakoimattomiin riskeihin.
Hankearviot ovat lähes aina pikemminkin aliarviointeja kuin yliarviointeja; harvoin kuulee pitkien hankkeiden päättyvän etuajassa. Tietoisena siitä, että hankkeen arviointi on vaikeaa ja pohditaan, miksi arviot menivät pieleen tietyssä hankkeessa, opastaa sinua kohti pienempiä arviointivirheitä myöhemmissä hankkeissa.
projektissa voi toteuttaa paljon muutakin kuin vain tuottaa tarkkoja arvioita. Jos olet insinööri ja haluat hallita tekniikoita, joita parhaat ohjelmistoinsinöörit käyttävät kääntääkseen projektinsa menestyksiksi, lataa ilmainen, näyte luku kirjani, tehokas insinööri. Se on täynnä satoja tarinoita, oivalluksia ja toiminnallisia strategioita johtajilta ympäri Piilaaksoa.
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html