Tämä artikkeli on tarkoitettu sinulle, kiusalliselle yrittäjälle, jolla on sovellusideo sydämessäsi ja vähän rahaa pankissa. Kaaviot, jotka olet kirjoittanut cocktail-lautasliinoille, häiritsevät koko maailmaa, ja täynnä rahaa olevat kippiautot on jo lähetetty kotiisi. Seuraavassa on muutamia yksinkertaisia ​​neuvoja, joiden avulla tuotanto sujuu sujuvasti.

Miksi tarvitset ensin projektipäällikön

'Tietokoneohjelmat ovat monimutkaisimpia asioita, joita ihmiset tekevät', Douglas Crockford sanoo. Et ehkä ole kuullut tätä nimeä aiemmin, mutta hän on melko kuuluisa ohjelmoijasta. Hän on tällä hetkellä vanhempi ohjelmistoarkkitehti PayPalissa, ja hän on edelläkävijä kaikenlaiselle hienolle tekniikalle, joka ei kuulu tämän artikkelin piiriin. Hän on joku, joka tietää paljon suurten projektien tekemisestä.

Itse olen ohjelmoinut 13 vuotta, ja jopa nyt, jossain vaiheessa jokainen projekti vie minut tuntemattomalle alueelle. Siellä on niin paljon erilaisia ​​tekniikoita, ja uusia tekniikoita suunnitellaan niin hälyttävällä nopeudella, että en koskaan tunne olevani täysin sen päällä, mitä tapahtuu. Vaikka jokaisella projektilla on omat haasteensa, on joitain vakioita:

• Projektilla on aikapaineita.
• Budjetti on pienempi kuin haluaisin.
• Olen kalliimpi kuin asiakas haluaisi.
• En kuuntele niin täydellisesti kuin asiakas haluaisi.
• Asiakas ei selitä asioita niin täydellisesti kuin haluaisin.

Tarvitsemme selvästi lastenhoitajan. Jonkun on astuttava sisään vahvistamaan perussäännöt, pitämään kaikki rehellisinä ja varmistamaan, ettemme unohda mitään tärkeää. Jonkun on helpotettava viestintää kaikkien osapuolten välillä.

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

Projektipäällikkö helpottaa viestintää kaikkien sidosryhmien ja tiimien välillä.

ApeeScape ei tarjonnut sopimuksia projektipäälliköiden kanssa, kun aloitin tämän artikkelin kirjoittamisen, mutta he tekevät nyt . Synergia! Voin vain kuvitella, että voimat, jotka luetaan seuraavat neuvot ja tajusivat, että heiltä puuttui suuri mahdollisuus.

Miksi ohjelmoija ei ole hyvä projektipäällikkö

.Todistus Projektinhallinnan instituutti syrjään, tärkein asia, jonka projektipäällikkö voi tuoda pöydälle, on kokemus. Tämän seurauksena monet ohjelmoijat tekisivät melko kunnollisia projektipäälliköitä; meillä on enemmän kokemusta teknisistä projekteista kuin kenellekään muulle, ja analyyttinen mielemme on taitava tietojen luetteloinnissa ja konkreettisten tavoitteiden asettamisessa.

Hyvää tietää, maksat meille tarpeeksi, joten näyttää järkevältä olettaa, että voimme hallita itseämme eikä pakottaa sinua maksamaan myös jonkun toisen ajasta, eikö?

Ensinnäkin, maksat meille koodin.

Kun tulemme ulos ohjelmointihäiriöstämme tekemään päätöksiä siitä, mikä on tärkeysjärjestyksessä, tai keskustelemaan siitä, kuinka paljon tällä viikolla todella tehdään, koodia ei kirjoiteta. Sitten kestää vähintään 10 minuuttia paluu 'vyöhykkeelle', varsinkin jos juuri käymämme keskustelu korostaa meitä, mikä on todennäköistä, jos väitämme ominaisuuden prioriteettia. Heppu, tiedän, mutta kyse on kalliiden resurssien tehokkaimmasta käytöstä.

Mikä tärkeintä, emme todellakaan näe puiden metsää. Jos et ota mitään muuta pois tästä artikkelista, ymmärrä tämä: Kun vietän koko päivän tuijottaen muutamia tiettyjä vikoja, aivoni menettävät kuvan suuremmasta kuvasta.

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

Projektipäällikkö varmistaa, että suurempi kuva ei kadota. Tweet

Miksi asiakas ei ole hyvä projektipäällikkö?

No, jos me, ohjelmoijat, emme halua ottaa vastuuta projektipäällikkönä tehtyjen asioiden suorittamisesta, sen on kuuluttava sinuun, asiakkaaseen. Se on sinun rahasi. Se on sinun visiosi. Olet kuitenkin viime kädessä vastuussa kaikesta.

Sinulla on kuitenkin myös paljon lautasellasi.

Monet asiakkaat ovat vain kuolevaisia, joilla on päivätöitä kuten me kaikki, ja joidenkin on jopa tiedetty kärsivän viivästyksistä tai unohduksista. Vaikka tämä ei välttämättä kuvaa sinua, ole hyvä ja viihdytä ajatusta ammatillisen muistimen pitämisestä ympärilläsi, jotta voit palata tärkeään työhön, joka pitää koko projektin hengissä.

Jos olet työskennellyt tai valvonut vastaavanlaista teknistä projektia, saatat todellakin olla hyvä johtaja projektillesi. Jos et ole, älä aliarvioi sellaisen henkilön arvoa, joka voi ennustaa mahdolliset ongelmat. Aika-arviot ovat aina vain arvioita, ja vikoja esiintyy yleensä vähiten sopivina aikoina. Toisen (jos vain osa-aikaisen) työntekijän kustannusten arvoinen on, että lähellä on joku, joka tietää, mitkä prosessin osat tarvitsevat tai todennäköisesti tarvitsevat eniten huomiota.

Otetaan esimerkiksi laadunvarmistus (QA). Oikea laadunvarmistus on välttämätöntä, jotta saat haluamasi hyödyn mistä tahansa projektista, eikä se koskaan saa ansaitsemansa huomiota. Hyvä projektipäällikkö ottaa kaiken irti rajoitetuista laadunvalvontaresursseista ja takaa myös ohjelmoijillesi laadun. Joskus pääsemme syvyydestämme ja joskus teemme virheitä. Tarvitset teknisesti ammattitaitoisen henkilön valvontatehtävässä selvittääkseen, onko ohjelmoijallesi vain vapaapäivä vai onko hän itse asiassa huonossa kunnossa projektiin. Henkilöstöongelmien poistaminen varhaisessa vaiheessa voi merkitä eroa elämän ja kuoleman välillä projektissasi.

Viimeinkin jopa sinä, asiakas, tarvitset joskus pienen tarkastuksen ja / tai tasapainon. Minun on vaikea kirjoittaa, koska me tietokoneohjelmoijat eivät ole tunnettuja suorasta luonteestamme. Riittää sanoa, että olen työskennellyt monissa projekteissa, joissa asiakas oli vakuuttunut siitä, että kaikki oli etusijalla ja ehdottomasti kaikki mitä tarvitaan tekemiseen. Vaikka minulla ei ole epäilystäkään siitä, että tämä oli aivan totta, nämä valitettavasti nämä asiakkaat eivät valitettavasti voineet hallita tuntien määrää päivässä. He eivät päätyneet haluamaansa ja / tai ansaitsemaansa positiiviseen tulokseen, 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 silti määrätietoisesti kurissa . On vaikea tehdä kiihkeää tuomiopyyntöä, jota useimmat tekniset projektit vaativat, kun se on ideasi ja rahasi linjalla, eikä tietokone välitä, itkemmekö ja huutammeko sitä. (Tiedän tämän olevan totta, koska olen kokeillut sitä monta kertaa.)

Puutteellinen luettelo tekniikan hallitsemisesta

Olitpa päättänyt jättää huomiotta edelliset 1 000-sanat ja hallita projektiasi itse tai aiotko palkata jonkun, mutta haluat olla perehtyneempi prosessiin, tämä luettelo auttaa sinua. 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 hallittavammiksi paloiksi, joista jokainen osa vaihtelee muutamasta viikosta pariin kuukauteen. Projektin alussa on hyvä järjestää aloituskokous näiden virstanpylväiden asettamiseksi. On OK olla hieman epämääräinen siitä, miten saavutat heidät. Tärkeintä on jatkaa sisäänkirjautumista jokaisen virstanpylvään jälkeen, jotta voit hyötyä kaikkien parantuneesta ymmärryksestä projektista ja varmistaa, että projektin virstanpylväät ovat edelleen ( karkeasti) saman kokoinen kuin alun perin uskottiin.

Aika-arviot

Me ohjelmoijat inhoamme ehdottomasti arvioita, koska tiedämme, että ne ovat väärässä, ja tiedämme, että niitä käytetään meitä vastaan. On OK, että he ovat väärässä, koska määritelmänsä perusteella ne perustuvat kouralliseen tuntemattomaan. On myös OK, että heitä käytetään meitä vastaan, koska työpaikkamme ovat melko mukavia ja ei ole haittaa, että ruoska murtuu aina silloin tällöin.

Joten kysy vapaasti arvioita aina, kun työ alkaa uuden virstanpylvään kanssa. Sinun pitäisi odottaa viiva tai kaksi kullekin pääominaisuudelle sekä karkea arvio siitä, kuinka kauan ominaisuus kestää. Teen yleensä optimistisen arvion, sitten kaksinkertaisen sen. Useimmiten tämä ylimääräinen aika aiheuttaa näkymättömiä sudenkuoppia.

Käyttäjien tarinat

Käyttäjätarinat ovat lyhyt kuvaus yhdestä sovelluksen toiminnallisuudesta. Ne ovat hyödyllisiä tärkeiden ominaisuuksien ennätyksinä, ja niiden tulisi olla puremankokoisia, mahtua hakemistokortille ja usein pienen piirustuksen mukana. Vielä tärkeämpää on, että ne toimivat siltana sen välillä, mitä asiakas haluaa ja mitä ohjelmoijan on kerrottava tietokoneelle. Ne ovat riittävän yksinkertaisia, jotta asiakas, asiakas, voi pudota muutamassa minuutissa, mutta riittävän yksityiskohtaisia, jotta me, ohjelmoijat, voimme upottaa hampaamme.

Jotkut nopeat tiedot käyttäjien tarinoista, löysin nämä oppaat Mountain Goat -ohjelmisto ja Roman Pichler olla laadukas ja ytimekäs. Jos haluat lisätietoja koko ketterän projektinhallinnan filosofiasta, kokeile tätä ApeeScape-blogikirjoitusta Ketterän projektinhallinnan perusedustus kirjoittanut Paul Barnes.

Sävellykset (maketit)

Tämä ei ole artikkeli siitä, miksi tarvitset suunnittelijaa, koska minusta tuntuu, että suurin osa asiakkaista ymmärtää sen jo, mutta se toistuu, koska näet valtavia tuottavuuskasvuja, jos lyö konkreettinen, harkittu muotoilu ohjelmoijiesi edessä. Joka kerta, kun meidän on tehtävä suunnittelupäätös, meidän on poistuttava 'vyöhykkeeltä', ja joka kerta meidän on mentävä takaisin ja muutettava jotain, koska meille ei annettu lopullista luonnosta. No, sinä suoritat matematiikan ... minä ' En valittaa, koska muotoilu on hauskaa, mutta kokemukseni mukaan tämä on vältettävissä olevien, ylimääräisten laskutettavien tuntien lähde nro 1.

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 muuttaa myöhemmin), mutta varaa ylimääräinen aika varmistaaksesi, että kaikki käyttöliittymän elementit ovat läsnä ja huomioitu.

Liittyvät: Palkkaa 3% parhaista freelance-UX-suunnittelijoista.

Stand-up-kokoukset

Pitkät kokoukset ovat joskus väistämättömiä, mutta et todellakaan halua ylikuormittaa ohjelmoijiasi tai viettää enemmän aikaa kuin on välttämätöntä. Minulla on ollut asiakkaita, jotka näyttivät odottavan minun muistan kaiken, mitä sanottiin kahden ja puolen tunnin kokouksessa; he olivat erittäin pettyneitä. Stand-up-kokous on yleensä rajoitettu 15 minuuttiin, ja on tapana seistä koko sen ajan. Pysyvän näkökohdan on tarkoitus varmistaa, että kaikki ovat mukana, ja pitää kokous lyhyenä.

Stand-up-tapahtumien aikana kaikki menevät ympyrään ja antavat lyhyen tilaraportin pitämällä kaikki tiimin jäsenet ajan tasalla toistensa edistymisestä. Löydät lisää stand-upeista osoitteesta ExtremeProgramming.Org . Jos työskentelet kaikki etänä etkä halua saada kaikkia Skype-sivustoon päivittäin, voit kokeilla hauskaa työkalua, kuten 15 Viisi vaihtoehtona stand-upeille. 15Five antaa tiimin jäsenten antaa panoksensa aina, kun heille on sopivaa, ja se saa heidät kyselykysymyksillä kiusata syvällisempiä vastauksia.

Lippujärjestelmä

Vaikka kuka tahansa voi ylläpitää muistilappuja ja Google-dokumentteja (kaikkien 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 erittäin liukkaaksi paketiksi. Riippumatta valinnastasi, hyvä lippujärjestelmä antaa sinulle mahdollisuuden vähintään:

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

Kun projektipäällikkö näyttää sinulle 40 kirkkaanpunaista tärkeintä lippua, jotka kaikki maksetaan samana päivänä, ymmärrät todella tämän lintuperspektiivin arvon projektista.

Voit käyttää Trellon, Basecampin tai Wriken kaltaisia ​​työkaluja edistymisen seuraamiseen projektien kautta.

Lähteen hallinta

Et voi koskaan edes katsoa koodia projektisi versionhallintajärjestelmässä, mutta lähteen hallinta (tai versiointi) on yksi tärkeimmistä käytettävissä olevista työkaluista, suurin kuviteltavissa oleva varmuuskopiointijärjestelmä.

Useimmat modernit projektit käyttävät Gitiä, vaikka joskus törmäät Subversioniin (SVN) työskennellessäsi projekteja, jotka ovat olleet jonkin aikaa. Githubin avulla voit isännöidä rajoittamattomia julkisia arkistoja ilmaiseksi (plus, se sisältää suurimman osan maailman avoimen lähdekoodin projekteista), kun taas Bitbucket sallii rajoittamattomien yksityisten arkistojen isännöinnin ja on siksi suosittu valinta kaupallisiin hankkeisiin.

Valitun versionhallintajärjestelmän se tallentaa koodin etäyhteyden varalta, jos jotain tapahtuu, ja seuraa kappaleita joka kerta, kun 'sitoutamme' koodin siihen pakottaen meitä kirjoittamaan pienen viestin, jossa kuvataan mitä teimme. Tämä estää eri kehittäjiä korvaamasta toistensa koodia, se antaa meille mahdollisuuden nähdä kaikki tietyllä ajanjaksolla tehdyt muutokset ja antaa meille mahdollisuuden luoda uusia koodihaaroja sellaisten ominaisuuksien tallentamiseen, jotka eivät ole heti käytössä. Siinä on jopa komento nimeltä 'syyttää', joka näyttää kuka on vastuussa tietystä koodirivistä ja milloin se on tehty.

Lähteen hallinta on suurin.

Testiohjattu kehitys

Tämä on suhteellisen kallis käytäntö, mikä tarkoittaa, että sitä ei käytetä usein projekteissa, joissa budjetti on rajoitettu muutamaan freelanceriin. Joten sinun, startup-yrittäjänä, ei pitäisi tuntua liian pahalta tekemättä tätä, mutta minun on ripustettava ideasi edessesi, koska se tarjoaa lopullisen suojan vikoja vastaan. Pohjimmiltaan ohjelmoijasi viettävät ylimääräisiä arvokkaita tunteja testien kirjoittamiseen (pienet koodilohkot), jotka varmistavat, että tietyt sovelluksen osat käyttäytyvät erityisillä, ennustettavilla ja toistettavilla tavoilla. Voisin esimerkiksi kirjoittaa testin väittäen, 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 200 testiä kirjoitettu, voin suorittaa ne uuden sovelluksen version julkaisemisen jälkeen varmistaakseni, ettei mikään näistä 200 ominaisuudesta ole sisällytetty virheisiin. Se ei ole täydellinen, mutta se on niin lähellä kuin voimme taata virheettömät (ainakin bug-lite-sovellukset) sovellukset.

Paketoida

Se on kaikki mitä tiedän projektinhallinnasta. En ole varma, kuinka suuri osa tästä siirtyisi Projektinhallinta-instituuttiin, mutta kaikki nämä olen hankkinut työskentelemällä verkkoprojekteissa viime vuosikymmenen aikana. Tietysti suosittelen, että palkkaat jonkun saadaksesi hyötyä hänen kokemuksestaan, mutta toivon, että pidät näistä tiedoista hyödyllisiä, vaikka et pysty siihen. Sinusta tulee tämän projektin perimmäinen auktoriteetti, joten mitä enemmän ymmärrät sen sisäisestä toiminnasta, sitä todennäköisemmin aiot johtaa sen voittoon.