Bliv gratis medlem
|
Hej alle sammen. Jeg var lige inde og se thorborg.tv "Forstå din programør" Og tænkte så over hvordan man rent faktisk sørger for at Idemandens forestillinger er dem som programøren rent faktisk laver ? Altså hvordan sikre man sig bedst muligt mod miskomunikation ? Fandt selv det her program som jeg kunne forestille mig kunne gøre en del af jobbet http://www.axure.com/.. men hvad siger i ?? Er det løsningen eller ?
På forhånd tak Hilsen Kruger |
Som værende en af Thorborgs omtalte tidligere 200 "programmører"/grafiker fra den gang og sidenhen selv har fået ansvaret for et par gutter har jeg noteret mig følgende:
- Forvent at det går galt og noget ikke er som forventet og skal laves om.
- Thorborgs tidsberegning er teoretisk god nok med at gange udmeldingen fra programmøren med 3,14. Min erfaring siger mig dog at derefter kan du så gange den med 3,14 igen for at tage højde for den tid der går med kommunikation omkring opgaven imellem projektledere, ejeren af opgaven, eksterne leverandører til projektet (reklamebureau, grunddata, betalingssystemer m.v.). Den primære årsag til at estimatet aldrig holder er at estimatet gives ud fra hvor lang tid personen vurderer det tager ham at løse problemet, ikke hvor lang tid det tager for eventuelle eksterne folk at melde tilbage til vedkommende m.v.
- Lad være med at antage at noget er "bare lige" eller sige, "hvis du gør sådan her så kan det jo ikke være noget problem". De fleste programmører har et indbygget filter der træder i kraft i det øjeblik "kunden" begynde at gøre sig klog på hvor svært deres arbejde er. Det betyder som regel du kommer nederst i prioriteringsbunken fordi projektet allerede fra start er blevet til et møg-projekt for programmøren.
- Gør alting i itterationer. Lad være med at stille en opgave, vente x uger og så komme tilbage og opdag at tingene har udviklet sig i en hel anden retning. Programmering af et system er en meget mere dynamisk process, hvor hver eneste linje kode kan skabe idéer til nye og bedre måder at gøre noget på som man oprindelig havde tænk på at løse anderledes. Hvis du overlader de beslutninger til programmøren så tager han en beslutning ud fra hvordan han har forstået opgaven eller bliver hurtigst færdig (hvis opgaven er irriterende - se forrige). Sørg for at være med i opgaven, test løbende og forsøg at sætte dig ind i de daglige valg en programmør på dit projekt står overfor (dvs alle de usagte ting) og sørg for at være til rådighed når spørgsmålene opstår. Kodeordet er "vær til rådighed" og ikke som mange misforstår, "mikroadministrer programmørens arbejde".
- Programmører tilbringer rigtig meget tid på nettet og i en række fora hvor der snakkes side op og side ned om hvor stupide folk kan være (f.eks. reddit.com). Det skaber en række sterotypiske opfattelse af andre mennesker og når du kommer til en programmør bliver du målt og vejet baseret på dem. Er du f.eks. den irriterende sælger der altid sælger ting der ikke står på hylden, er du den usikre der ikke aner hvad du taler om og derfor nemt kan trumles, er du pige (efterfølgende, er du lækker), er du fantasten der taler om millioner hvis baaare lige programmøren gider bruge 6 måneder i døgndrift på at kode gratis for dig... osv. Lige så snart du er havnet i en af de bokse så kan det være noget af en kamp af få programmørens respekt tilbage. Du kan derfor gøre dig selv en stor tjeneste ved at sætte dig ind i hvordan "miljøet" fungerer, hvilke ting man ikke siger og hvilke ting man siger. Har du en Star Trek programmør så har du allerede tabt hvis du lidt kluntet forsøger at blive bedste venner med en star wars kommentar fordi du tror det er sådan lidt nørdet agtigt. ;-)
Og hvis man så kigger på de par ting jeg lige har nævnt så opdager man ret hurtigt at det faktisk ikke er så forskellig fra hvordan de fleste andre ansatte i andre faggrupper gerne vil behandles - Respekt for ens arbejde og ens arbejdsbyrde. Samtidig hjælper det at acceptere at Star Trek citater kan være lige så vigtig et samtaleemne som den nye Audi er ovre i sælgernes fine kontorer.
Programmører bliver ofte overladt til sig selv i et hjørne og kun hevet frem når man skal bruge dem eller brokke sig over noget ikke virker og i mange virksomheder jeg har besøgt igennem tiderne, skal de også helst bare holde deres mund omkring projektet hvis der er noget idémanden ikke har tænkt på, eller det ikke giver mening. De bliver set på som en ressource i stil med et produktionsanlæg osv, på trods af at de ofte sidder med en meget dynamisk arbejdsdag hvor det er næsten umuligt at planlægge noget pga forstyrrende elementer og "haste"-sager.
Ligeledes er en udviklingsafdeling ofte omdrejningspunkt og serviceorgan for rigtig mange andre mennesker i en virksomhed og bliver derfor overladt til sig selv hvis der kommer en fra afdeling A med en hasteopgave, mens der arbejdes på en hasteopgave for afdeling B, uden de har nogen ret til at prioritere opgaverne selv og så bliver det som i Martins eksempel hvor programmørerne ret hurtig bliver træt af at folk altid kommer med hasteopgaver, for hvis de altid skulle smide hvad de har i hænderne for at hjælpe en der er rød i hovedet og skriger "haster haster", så ville de aldrig få lavet noget, for de fleste mener oftest deres opgave er den vigtigste og alt andet skal lægges på hylden. I sidste ende er det dog alligevel programmøren der får skylden når de igangværende opgaver ikke bliver leveret til tiden.
Det skaber for mange en super stresset hverdag hvor man planlægger at lave en ting, men inden man har set sig om har man fået 10 nye hastesager, et par fejlmeldinger der lige skal debugges fordi (som martin nævner) kunden er helt oppe i det røde felt, og når dagen er omme så er der ikke sket noget med den oprindelige opgave. Når så projektlederen kommer dagen efter for at høre hvordan det skrider frem, så bliver resultatet at der ikke er sket noget, men det er sjældent at projektlederen er klar over alle de andre hasteopgaver der er blevet presset ind imellem ofte gerne med "trusler" i stil med "Min kunde betaler rigtig mange penge, så jeg er vigtigst".
Så det bedste man kan gøre for at undgå miskommunikation er ikke alverdens værktøjer og software (selvom de kan tage en noget af vejen i planlægningsfaser), men derimod at idémanden gider sætte sig ind i programmørens hverdag, lytte, og skabe respekt om sin person i form af ordentlig researchede idéer og ved ikke at nedgøre programmørens personlige interesser, uanset om det så er samlekort, rollespil eller lignende, der kan virke fjollet.
Hvis en programmør føler at idémanden kan hjælpe ham med at lave noget fed kode eller et projekt der kan give street creds blandt de andre programmører, så forsvinder alle de gnidninger som skaber miskommunikationen, for så sørger programmøren selv for at komme til idémanden når der er et problem. Derimod hvis den idé du kommer med er lige så dum som den alle de andre fantaster konstant kommer med til ham (et typisk amino eksempel er folk der gerne vil have lavet noget der bare er vildt fantastisk, men det skal være helt vildt billigt og helst færdig i morgen. :-) eller dit problem kræver at programmøren skal arbejde 140% for en fast månedsløn til langt ud på natten for at chefen/sælgeren kan tjene penge, mens han sidder derhjemme og slappe af (der er sjældent bonusordninger for programmører, hvilket man kan undre sig over).. Ja så skal du nok også forvente resultatet derefter. :-)
Programmører/nørder har det med at opføre sig "snobbet" eller provokerende (også kendt som Rockstar fænomenet) hvis de føler de bliver overset i hverdagen. Ganske simpelt for at få bare lidt opmærksomhed og respekt, der desværre alt for ofte i en virksomhed gives til de mere udadvente faggrupper som sælgere, marketingsfolk mf.l. fordi den gruppe ofte bruger mere tid på at fortælle om deres resultater og fordi de fleste kan forstå fordelen ved at der er kommet en ny kunde i biksen, men de færeste forstår fordelen af at firewall-maskinen er blevet patchet med en sikkerhedspakke der sikre imod i-love-you virussen.
Det var i høj grad derfor Jubii's udviklingsafdeling virkede så godt i sine kronede dage. Det var programmører der var stolte af deres arbejde og havde respekt for deres arbejdsgivere (i de fleste tilfælde :-) og fandt et fællesskab med projektledere og idé-mænd i små teams der løste opgaver de/vi syntes var sjove. Samtidig gjorde Martin og Co. en rigtig god indsats for at belønne stress- og "slave"-arbejde og overtid i form af fællesrejser, respekt for arbejdet, fester og andet som ikke var en del af den faste løn.
Jeg husker f.eks. at jeg fik en Creative MP3 CD afspiller (det var den gang de knap nok var kommet på markedet i USA) for at omkode samtlige reklametags på Jubii hen over en nat sammen med et par kollegaer. Det var 12 timers dødsygt slave-natte-arbejde, men vi gjorde det frivlligt for mindre end det nogensinde ville have kostet Jubii at betale for timerne og jeg er den dag i dag stadigvæk tilfreds med betalingen for arbejdet fordi vi hyggede os mens vi gjorde det, og dagen efter var folk glade for den indsats vi havde ydet på kort tid fordi det hjalp den fællesforretning med at tjene mere. :-)
Man kan planlægge sig ud af meget med fine gantt charts, prototyper m.v., men hvis der ikke er intern fælles respekt imellem projektdeltagerne, så bliver projektet aldrig til noget.
Opret bruger