Tämä artikkeli on tarkoitettu sinulle, rohkealle liikemiehelle, jolla on idea sovelluksesta sydämessäsi ja vähän rahaa pankissa. Lautasliinoille kirjoittamasi kaaviot häiritsevät koko maailmaa, ja täynnä rahaa olevat rahat on jo lähetetty kotiisi. Seuraavassa on muutamia yksinkertaisia ​​vinkkejä, joiden avulla tuotanto sujuu sujuvasti.

Syy, miksi tarvitset projektipäällikön

'Tietokoneohjelmat ovat monimutkaisimpia asioita, joita ihmiset luovat', sanoo Douglas Crockford. Et ehkä ole kuullut tuota nimeä aiemmin, mutta ohjelmoijalle se on melko kuuluisa. Hän on tällä hetkellä vanhempi ohjelmistoarkkitehti PayPalissa ja on edelläkävijä kaikenlaiselle huipputeknologialle, joka on tämän artikkelin ulkopuolella. Hän on henkilö, joka tuntee suurten projektien työskentelyn.

Minusta olen ohjelmoinut 13 vuotta, ja on vielä aikoja, jolloin jokainen projekti vie minut tuntemattomalle alueelle. On niin monia erilaisia ​​tekniikoita, samoin kuin uusia tekniikoita suunnitellaan niin hälyttävällä nopeudella, että en koskaan tunne olevani täysin tietoinen siitä, mitä tapahtuu. Vaikka jokaisella projektilla on omat haasteensa, on olemassa muutama vakio:

• Projektilla on ajan paine.
• Budjetti on pienempi kuin haluaisin.
• Maksuni ovat kalliimpia kuin asiakas haluaa.
• En kuuntele niin täydellisesti kuin asiakas haluaa.
• Asiakas ei selitä asioita niin täydellisesti kuin haluaisin.

Tarvitsemme tietysti lastenhoitajan. Joku joutuu asettamaan pelisäännöt, pitämään kaikki rehellisinä ja varmistamaan, ettemme unohda jotain tärkeää. Jonkun on helpotettava viestintää kaikkien osapuolten välillä.

Tämä henkilö, tämä sankari, on projektipäällikkö.

Miksi tuotepäällikkö on laatikossa? Hän on kissa. Kissat rakastavat laatikoita.

ApeeScape ei tarjonnut sopimuksia projektipäälliköiden kanssa, kun aloitin tämän artikkelin kirjoittamisen, mutta nyt he tekevät ( ApeeScape-projektit ). Synergia! Voin vain kuvitella voiman, jonka seuraavien vinkkien lukeminen toi, ja tajuan, että menetit suuren mahdollisuuden.

Syy miksi ohjelmoija ei ole hyvä projektipäällikkö

Sertifikaatin asettaminen sivuun Projektinhallinnan instituutti Tärkeintä, jonka projektipäällikkö voi tuoda pöydälle, on kokemus. Tämän seurauksena monet ohjelmoijat olisivat melko kunnollisia projektipäälliköitä; meillä on enemmän kokemusta kuin kenellekään teknisistä projekteista, ja analyyttinen mielemme on taitava tietojen luetteloinnissa ja konkreettisten tavoitteiden asettamisessa.

Maksat selvästi meille tarpeeksi, joten on järkevää olettaa, että voimme itse hoitaa erilaisia ​​tehtäviä sen sijaan, että pakottaisit sinua maksamaan myös jonkun toisen ajasta, eikö?

Ensinnäkin, maksat meille koodin.

Kun tulemme ulos ohjelmoinnin hämmennyksestämme tekemään päätöksiä tärkeysjärjestyksestä tai keskustelemaan siitä, kuinka paljon työtä todella tehdään tällä viikolla, koodi lakkaa kirjoittamasta. Tämän jälkeen paluu 'vyöhykkeelle' kestää vähintään 10 minuuttia, varsinkin jos juuri käymämme keskustelu korostaa meitä, mikä on todennäköistä, varsinkin jos keskustelemme toimintojen prioriteetista. Se ei ole iso juttu, tiedän, mutta tämä kaikki tehdään kalliiden resurssien tehokkaamman käytön kannalta.

Mikä tärkeintä, keskittyminen yksityiskohtiin ei anna sinun arvostaa yleistä ympäristöä. Jos tämä artikkeli ei jätä sinulle mitään, yritä vain ymmärtää tämä: Kun vietän koko päivän tiettyjä vikoja, aivoni menettävät näkymän suuremmasta kuvasta.

Aivoni palkitsevat minut, kun korjaan nuo virheet, ja luulen, että olen tehnyt hienoja asioita ja nyt voin mennä pelaamaan videopelejä. Kun joku muistuttaa minua siitä, että kotisivu ei vieläkään toimi, se on täydellinen yllätys, koska olen viettänyt koko päivän täyttäen aivoni hyvin yksityiskohtaisella tietämyksellä hyvin pienestä osasta koko projektia, ja unohdan levätä. Näin aivoni toimivat, ja monilla muilla ohjelmoijilla on samanlainen psykologinen meikki.

Kun pääsemme ulos ohjelmoinnin hämmennyksestä tekemään päätöksiä, koodi lakkaa kirjoittamasta.

Syy miksi asiakas ei ole hyvä projektipäällikkö

No, jos me, ohjelmoijat, emme halua ottaa vastuuta projektinhallintatoimien tekemisestä, vastuu säilyy sinulle, asiakkaalle. Onko rahasi. Se on sinun visiosi. Joka tapauksessa olet vastuussa kaikesta tästä.

Sinulla on kuitenkin myös paljon tehtävää.

Monet asiakkaat ovat vain kuolevaisia, joilla on päivätöitä, kuten me kaikki muut, ja jotkut kärsivät jopa viivytyksistä tai unohduksista. Vaikka tämä ei todellakaan kuvaa sinua, harkitse ajatusta a Ammattimainen Muistaja (Professional Reminder) ympäri, jotta voit palata tärkeään työhön projektin elossa pitämiseksi.

Jos olet työskennellyt tai valvonut vastaavanlaista teknistä projektia, saatat olla hyvä projektipäällikkö. Jos ei, älä aliarvioi sellaisen henkilön arvoa, joka voi ennustaa mahdollisia ongelmia. Aika-arviot ovat aina vain arvioita, ja vikoja esiintyy yleensä vähiten sopivina aikoina. Se on hyvin arvoinen toisen (vaikka vain osa-aikaisen) työntekijän, sellaisen henkilön, joka tietää, mitkä prosessin osat tarvitsevat tai saattavat tarvita eniten huomiota.

Suorita esimerkiksi laadunvalvonta. Oikea laadunvalvonta on välttämätöntä, jotta saat haluamasi projektista, eikä se koskaan saa ansaitsemaansa huomiota. Hyvä projektipäällikkö hyödyntää laadunvalvonnan rajalliset resurssit parhaalla mahdollisella tavalla ja varmistaa myös ohjelmoijiesi laadun turvallisuutesi vuoksi. Joskus pääsemme syvyydestämme ja joskus teemme virheitä. Tarvitsee teknisesti pätevä henkilö, jolla on valvontatehtävä, selvittääkseen, onko ohjelmoijalla huono päivä vai onko hän itse asiassa huono lisäys projektiin. Henkilöstökysymysten korjaaminen alusta alkaen voi tehdä eron elämän ja kuoleman välillä projektissasi.

Viimeinkin jopa sinä, oi upea asiakas, tarvitset joskus vähän tarkistusta ja / tai tasapainottamista. Minun on vaikea kirjoittaa, koska me ohjelmoijat eivät ole kovin tunnettuja rehellisyydestämme puhuessamme. Riittää, kun sanon, että olen työskennellyt monissa projekteissa, joissa asiakas oli vakuuttunut siitä, että kaikki oli etusijalla ja ehdottomasti kaikki oli saavutettava. Vaikka minulla ei ole epäilystäkään siitä, että tämä oli ehdottomasti totta, näillä asiakkailla ei valitettavasti ollut minkäänlaista kontrollia päivien tuntimäärästä. He eivät saaneet haluamaansa ja / tai ansaitsemaansa positiivista tulosta, ja mielestäni tämä tulos olisi voitu välttää, jos asiakas olisi antanut projektipäällikölle valtuudet arvioida työmäärää ja pitää tahdikkaasti, mutta tiukasti hallinnassa. On vaikea tehdä valitettavia itsearviointipäätöksiä, joita useimmat tekniset projektit vaativat, kun kyseessä on ideasi ja rahasi ja tietokone ei välitä, itkekö ja huudatko sitä. (Tiedän, että tämä on totta, koska olen kokeillut useita kertoja.)

Puutteellinen luettelo tekniikan hallitsemisesta

Olitpa päättänyt ohittaa yli 1000 sanaa yllä ja haluat hallita projektiasi itse, tai jos palkkaat jonkun, mutta haluat enemmän tietoa prosessista, tämä luettelo auttaa. En ole koskaan (virallisesti) ollut projektipäällikkö, joten en voi sanoa, mitä työkaluja kukin projektipäällikkö käyttää, mutta minulla on ollut hyvä menestys kaikissa näissä tekniikoissa:

Virstanpylväät

Uutta projektia aloittaessaan useimmat ihmiset tietävät intuitiivisesti, että on tärkeää jakaa projekti hieman hallittavampiin paloihin, jokainen osa voi vaihdella työstä muutamasta viikosta pariin kuukauteen. Projektin alussa on hyvä pitää ensimmäinen kokous näiden virstanpylväiden tai tiettyjen kohtien määrittämiseksi. On hyvä olla hieman epämääräinen siitä, miten aiot päästä sinne. Tärkeintä on seurata jokaisen vaiheen jälkeen, jotta voimme hyötyä kaikkien parantuneesta ymmärryksestä projektista ja varmistaa, että projektin vaiheet ovat projektin mukaisia edelleen (enemmän tai vähemmän) samankokoisia kuin alun perin uskottiin.

Aika-arviot

Me ohjelmoijat vihaamme ehdottomasti arvioita, koska tiedämme, että ne menevät pieleen ja niitä käytetään meitä vastaan. On okei, että he ovat väärässä, koska määritelmänsä perusteella ne perustuvat kouralliseen arvoitukseen. On myös hyvä, että niitä käytetään meitä vastaan, koska työmme on melko mukavaa eikä ole haittaa tuntea ajoittain pientä painostusta.

Joten älä epäröi kysyä arvioita joka kerta, kun uuden vaiheen työ alkaa. Sinun pitäisi odottaa yhden tai kahden rivin selitystä jokaiselle tärkeälle ominaisuudelle sekä karkea arvio siitä, kuinka kauan ominaisuus kestää. Teen yleensä optimistisen arvion, sitten kaksinkertaisen sen. Monta kertaa tämä ylimääräinen aika käytetään näkymättömiin esteisiin.

Käyttäjien tarinat

Käyttäjätarinat ovat lyhyitä kuvauksia yhdestä sovelluksen toiminnallisuudesta. Ne ovat hyödyllisiä muistiinpanona tärkeistä ominaisuuksista, ja niiden tulisi olla puremankokoisia, mahtua laatalle ja usein pienen piirustuksen mukana. Vielä tärkeämpää on, että ne toimivat siltana sen välillä, mitä asiakas haluaa ja mitä ohjelmoija on sanonut tietokoneelle. Tarinat ovat riittävän yksinkertaisia, että sinä, asiakas, ymmärrät muutamassa minuutissa, mutta riittävän yksityiskohtaiset, jotta me, ohjelmoijat, voimme saada siitä kaiken irti.

Löydän nämä oppitunnit saadakseni nopean tiedon käyttäjien tarinoista Mountain Goat -ohjelmisto Y Roman Pichler , ovat korkealaatuisia ja ytimekkäitä. Kokeile tätä ApeeScape-blogikirjoitusta saadaksesi lisätietoja koko ketterän projektinhallinnan filosofiasta Ultimate Johdatus ketterään projektinhallintaan kirjoittanut Paul Barnes.

Sävellykset (maketit)

Tämä ei ole artikkeli siitä, miksi tarvitset suunnittelijaa, koska minusta tuntuu, että useimmat asiakkaat ymmärtävät sen jo, mutta se toistuu, koska tuottavuus kasvaa valtavasti, jos näytät ohjelmoijillesi hyvin suunnitellun ja konkreettisen suunnittelun. Joka kerta, kun meidän on tehtävä suunnittelupäätös, meidän on päästävä pois 'vyöhykkeeltä', ja joka kerta meidän on mentävä takaisin ja muutettava jotain, koska lopullista luonnosta ei annettu meille. No, tee matematiikka ... minä ' En valittaa, koska muotoilu on hauskaa, mutta kokemukseni mukaan tämä on # 1 lähde vältettävissä oleville ylimääräisille laskutettaville tunneille.

Useimmat suunnittelijat tarjoavat sävellyksiä, jotka tunnetaan myös nimellä 'comps' Adobe Photoshopissa, Adobe Illustratorissa tai Sketchissä. Jos teet sen itse, voit käyttää yhtä lukemattomista verkkotyökaluista, kuten Balsamiq tai InVision . Pakkauksessa ei tarvitse olla samoja värejä ja tyylejä kuin lopputuotteessa (koska niitä voidaan helposti muuttaa myöhemmin), mutta varaa ylimääräinen aika varmistaaksesi, että kaikki käyttöliittymän elementit ovat läsnä ja tarkistettu.

Stand-up-kokoukset

Pitkät kokoukset ovat joskus väistämättömiä, mutta älä ylikuormita aikataulujasi tai vie enemmän aikaa kuin on tarpeen. Minulla on ollut asiakkaita, jotka näyttivät odottavan minun muistan kaiken, mitä sanottiin kahden ja puolen tunnin kokouksessa; he olivat hyvin pettyneitä. Stand-up-kokous on yleensä rajoitettu 15 minuuttiin, ja sen aikana on tapana nousta seisomaan. Seisomisen on tarkoitus varmistaa, että kaikki osallistuvat, ja pitää kokous lyhyenä.

Stand-upien aikana jokainen liikkuu ympyrässä ja antaa lyhyen tilaraportin, joka pitää kaikki tiimin jäsenet ajan tasalla toistensa edistymisestä. Lisätietoja UPS-tuesta on osoitteessa ExtremeProgramming.Org . Jos kaikki työskentelevät etäyhteyden kautta etkä halua tavata Skypessä päivittäin, voit käyttää hauskaa työkalua, kuten 15 Viisi , vaihtoehtona stand-upeille. 15Five antaa tiimin jäsenille mahdollisuuden antaa palautetta aina, kun heille on sopivaa, ja kysyy heiltä kyselykysymyksiä syvällisempien vastausten tuottamiseksi.

Lippujärjestelmä

Vaikka kuka tahansa voi pitää muistilappujärjestelmää ja Google-dokumentteja (jokaiselle tehtävät on korostettu eri väreillä), se ei todellakaan ole välttämätöntä. Monet ihmiset ovat yrittäneet ratkaista tämän ongelman puolestasi. Basecamp ja Trello ovat kuuluisia helppokäyttöisyydestään, kun taas Pivotal yrittää kapseloida koko 'ketterän' filosofian yhdeksi erittäin hienostuneeksi paketiksi. Riippumatta valinnastasi, hyvä lippujärjestelmä antaa sinulle mahdollisuuden vähintään:

• Luo tehtäviä
• Määritä prioriteetti ja toimituspäivä
• Linkitä tehtävät ja alitehtävät
• Määritä eri tarkkuudet, kuten 'valmis' tai 'testi epäonnistui'
• Näytä kaikki tietylle käyttäjälle osoitetut tehtävät

Kun projektipäällikkö näyttää sinulle 40 kirkkaanpunaista tärkeintä lippua, jotka erääntyvät samana päivänä, ymmärrät todella tämän projektivision arvon.

Virheiden seuraamiseen ei tarvitse käyttää muistilappuja.

Versiohallinta

Et ehkä edes pääse katsomaan koodia projektisi versionhallintajärjestelmässä, mutta versionhallinta (tai versiointi) on yksi tärkeimmistä työkaluistamme, suurin kuviteltavissa oleva varmuuskopiointijärjestelmä.

Useimmat nykyaikaiset projektit käyttävät Gitiä, vaikka joskus kohtaatkin Subversionin (SVN) työskennellessäsi projektissa, joka on ollut julkisuudessa jonkin aikaa. Github voit isännöidä rajoittamattoman määrän julkisia arkistoja ilmaiseksi (lisäksi se sisältää suurimman osan maailman avoimen lähdekoodin projekteista), kun taas Bitbucket Sen avulla voit isännöidä rajattomasti yksityisiä arkistoja ja se on siksi suosituin vaihtoehto kaupallisissa projekteissa.

Valitun versionhallintajärjestelmän se tallentaa koodimme etäyhteyden varalta, jos jotain tapahtuu, samoin kuin seurannan joka kerta, kun 'kompromisoimme' koodia, samalla kun se pakottaa meidät kirjoittamaan pienen viestin, joka kuvaa mitä työskentelivät. Tämä estää eri kehittäjiä korvaamasta toistensa koodia, antaa meille mahdollisuuden nähdä kaikki tietyn ajanjakson aikana tehdyt muutokset ja antaa meille mahdollisuuden luoda uusia koodihakuja sellaisten ominaisuuksien tallentamiseen, jotka eivät tule heti näkyviin. Siinä on jopa komento nimeltä 'vika', joka osoittaa, kuka on vastuussa tietystä koodirivistä ja milloin se on tehty.

Versionhallinta on paras.

Testiohjattu kehitys

Tämä on suhteellisen kallis käytäntö, mikä tarkoittaa, että sitä ei käytetä usein hankkeissa, joissa budjetti on rajoitettu muutamaan freelanceriin. Joten aluksi sinun ei pitäisi tuntua liian pahalta, jos et tee tätä, mutta minun on esitettävä sinulle idea, koska se tarjoaa parhaan suojan vikoja vastaan. Pohjimmiltaan ohjelmoijat käyttävät arvokkaita ylimääräisiä tunteja testien (pienten koodilohkojen) kirjoittamiseen varmistaakseen, että tietyt sovelluksen osat käyttäytyvät tietyllä, ennustettavalla ja toistettavalla tavalla. Voit esimerkiksi kirjoittaa testin, jolla varmistetaan, että kun 'login' -painiketta napsautetaan, avautuu ponnahdusikkuna, jossa on käyttäjätunnuskenttä.

Testien kauneus on, että kun olen kirjoittanut ne, voin suorittaa ne kaikki yhdellä komennolla. Jos minulla on kirjoitettu 200 testiä, voin suorittaa ne uuden sovelluksen version julkaisemisen jälkeen varmistaakseni, ettei mikään 200 ominaisuudesta ole sisältänyt virheitä. Se ei ole täydellinen, mutta se on lähinnä vikattomien sovellusten takaamiseen (ainakin bug-lite).

Sulkea

Se on kaikki mitä tiedän projektinhallinnasta. En ole varma, kuinka paljon tästä tentistä läpäisisi Project Management Institute, mutta se on kaikki aineisto, jonka olen kerännyt työskentelemällä verkkoprojekteissa viime vuosikymmenen aikana. Tietysti suosittelen, että palkkaat jonkun saadaksesi hyötyä heidän kokemuksestaan, mutta toivon, että nämä tiedot ovat hyödyllisiä, vaikka sinulla ei ole mahdollisuutta tehdä niitä. Sinusta tulee tämän projektin perimmäinen auktoriteetti, joten mitä enemmän tiedät sen sisäisestä toiminnasta, sitä todennäköisemmin aiot johtaa sen voittoon.