Hvordan starter jeg selvstændig virksomhed?

Svar: It projekt planlægning hvordan ??

Dan — Wed, 22 Sep 2010 20:50:01 GMT

Nu er der stor forskel på hvilke størrelse projekt vi taler om, og det skal du have i mængde.

Jeg er selv programmøren, men jeg ser det oftest gå galt pga for lidt motivation fra programmørens side og for dårlig projektstyring fra idemandens side. Da jeg er lidt af begge dele har alle projekter jeg har været i stort set altid overholdt deadlines, da jeg kan give realistisk bud på tid, er helt inde i sagerne og ved hvordan projekter oftest skrider frem. En stor del er selvfølgelig forståelsen af hvad idémanden mener, at føre det over til en teknisk løsning der er i harmoni med idémanden's tanker. Det er her du må finde bindeledet.

Det er ret vigtig at idémanden ikke fylder på konstant, der er stop for kravspecifikation når der er stop, og så må projektet gøres færdig og alt det som kommer op undervejs må tages i version 2. Men følg konstant hver eneste skridt som programmøren tager og se at det følger de tanker idémanden har. Vær med i hele projektet, og det er det jeg mener med at motivationen og projektstyringen skal være i orden.

Nu er det også forholdsvis små projekter jeg har at gøre med. På de rigtig store projekter hvor man har et hold på 20+ programmører f.eks. hos IBM der er det lidt andre spilleregler, men der forventer jeg så også at du vil ansætte en kompetent projektleder der kan formidle idéer til logisk løsning :)

Oscar har dog et vildt svar der nok kan give lidt pointers. Håber dog også min version kan give lidt idéer (vi taler om noget mindre systemer, tænk 2-5 personers).

EDIT: Ikke lidt pointers, MANGE, utrolig uddybende svar Oscar :)

Svar: It projekt planlægning hvordan ??

Oscar Eg Gensmann — Wed, 22 Sep 2010 18:59:42 GMT

hehe, det er lidt en personlig kæphest, så derfor blev det uddybet lidt. Jeg ser alt for mange steder hvor programmører bliver behandlet som nogen fra de ydre rum og sjovt nok er tilfældet oftest at de bare gerne vil behandles som alle andre. :-)

Rent teknisk i forhold til projektbeskrivelsen så oplever jeg at det er vigtigt at forstå hvordan den enkelte programmør arbejder bedst. Nogen har brug for en mere mundtlig overlevering og en "snak om tingene" og andre vil helst læse 200 siders dokumenter hvor alt er beskrevet i detaljer. Min erfaring siger mig dog at den sidste metoder giver projekter hvor alting laves "bogstaveligt" og den første giver projekter hvor man risikerer at ikke alting kommer med og tiden skrider fordi man har glemt hvad der blev sagt, tilgengæld kan der ofte komme nogen meget mere spændende ting ud af det end hvad man først troede var muligt.

Inde hos os (Ubivox/GMTA) bruger vi et Ticket system til den daglige planlægning og prøver at splitte opgaverne op i håndterbare bider. Det gør at man næsten med sikkerhed kan nå at blive færdig med en ticket inden dagen er omme og på den måde så arbejder man ikke på tværs af dage hvor man ofte glemmer hvad man sad med af idéer.

En generelt ting der virker for mange mennesker (også programmører) er at krydse ting af på lister for at synliggøre at man har nået noget (dvs der var en mening med at stå op og slæbe sig hen på kontoret). Tickets hjælper på den måde at synliggøre (også overfor andre) at man har været på arbejde. Vi bruger Jira som koster lidt mere end de mindre ticket systemer, men efter at have været igennem en lang række alternativer er det helt klart det vi er gladest for til dato:

http://www.atlassian.com/software/jira/

Når vi skal lave et nyt projekt forsøger vi så så vidt muligt bare at udnævne en ansvarlig og han kaster sig så ud i det og begynder at skrive kode og prøve en masse af ud fra en meget generisk beskrivelse af hvad vi ønsker at opnå (ikke hvordan) indtil et punkt hvor tingene rulles ud til de andre deltager via et mercurial kode repositorie og derfra begynder vi så at skrive tickets og opgaver ind som man så kan "byde" ind på. Ofte er der dog en specific ejer af opgavetyper (da vi ikke er så mange), som f.eks. at jeg sidder som lead på brugerflade og frontend ting og Christian på backend osv, men det er frit for alle at løse en ticket hvis de føler de kan. Tickets gør at vi alle kan se hvis der er noget vi synes der mangler og så skrive det ind. De fleste softwarehuse har denne arbejdsmodel allerede, nogen mere strikse end andre.

Mange af vores projekter (især de interne) eksisterer i meget lang tid i taleform (nogen gange i flere måneder, sågar år) hvor vi taler om dem over frokosten, til en fredagsøl og lignende. Det skaber momentum og gør at man tænker over dem når man står i netto og handler, før man lægger sig til at sove osv. Mange gange har Christian kodet en opgave i hovedet før han overhovedet har sat sig ned foran sin skærm (bogstaveligt talt). Det er derfor vigtigt efter min mening at give tid til den process når man sætter en deadline hvis muligt (det er den tid martin omtaler som ekstra tid man får når man ganger det oprindelige estimat med 3,14 :).

Det kan vi gøre fordi vi kører alting meget løst, åbent og uformelt og alle der arbejder på et projekt har et ejerskab i projektet og er ansvarlig for det bliver en success for ellers er det "pinligt" for fællesskabet hvis vi ikke gør det bedste vi kan og ingen har lyst til at være den synlige årsag til at vi fremstår som pinlige.

Vi holder så ticketen opdateret med kommentarer og debat, så vi hele tiden har et nogenlunde "papirspor" på hvad vi har lavet som alle kan kigge i (også ikke-programmørerne) og ellers så er det også et krav herinde at man ikke er bange for at kigge i andre folks kode eller lege med et testsystem og se hvad der er ændret og prøve at forstå det så man kan kommentere. Alt sammen meget lavpraktisk, og kræver en masse snak frem og tilbage, men det virker så længe man er et lille team fordi man kan tale sammen og reagere hurtigt på forandringer.

Den metodik plejer vi så vidt muligt at forklare vores konsulentkunder ved at synliggøre for dem at de hellere vil have en løsning der er drevet af lyst og glæde frem for en løsning der er pisket frem pga en alt for stram deadline, eller strikse kravsspecs. som ofte er skrevet af en der ikke har føling med teknologien og udfordringerne. Hvis man ikke kan nå en specifik deadline så oplever vi ofte at det er bedre at lancere en "light"-version (den begynder vi at planlægge et par uger før deadline hvis vi kan se det skrider) og så arbejde videre på den fulde bagefter, end at vente til alt er perfekt og dermed misse en deadline. Så længe det sker i fælles forståelse. Det er også derfor at opgaver som bliver leveret med den klassiske "den skal helst være klar i går" aldrig bliver taget seriøs af en programmør, for det betyder at kunden ikke har tænkt over hvornår han reelt har brug for den, hvilket igen tyder på at kunden ikke har styr på sine ting.

Det er i den forbindelse vigtigt at huske på at bare fordi man kører tingene løst så betyder det ikke at man kan bruge alt den tid i verden man vil på en opgave. Netop en del af enhver opgaves beskrivelse er at den har et tidspunkt for hvornår den er nødvendig, det er en del af det der gør den til en udfordring/problem. F.eks.: "Vi har følgende funktion vi vil have i luften senest, den x i x". opgaven er så at finde en måde at løse det på inden for den givne tid. hvis det betyder at funktionen ikke kan blive 100% som man forestillede sig, så går det nok fordi man så senere itererer over den en gang til.

Det betyder så tilgengæld at der er visse typer af projekter vi aldrig vil kunne arbejde på fordi de kræver for meget kontrol, dokumentation, projektledelse og kravsspecs i forhold til hvad vi synes er sjovt, men så plejer vi ret ærligt op-front at fortælle kunden at vi nok ikke er det rigtige team til den opgave.

Personlig tror jeg ikke på der er en universel rigtig måde at "føde" et it-projekt på da det afhænger af menneskerne og projeket. IT er lidt blevet et fællesbegreb for rigtig mange discipliner og opgavetyper og jeg tror ikke man kan putte dem i samme boks.

Jeg er ikke stor fan af projektstyringssystemer som Prince 2 og lignende selvom jeg med al respekt anderkender at de virker i visse situationer og især i rigtig store virksomheder med stor udskiftning af medarbejdere og behov for fælles regelsæt for hvordan man gør tingene. Det betyder så bare ofte at man kun får det man bestiller og ikke den bedste løsning på problemet som kunden egentlig forsøger at løse. Scrum er et interessant system men findes i så mange varianter og ideologier at det ofte minder mest om sund fornuft når man ser det implementeret.

http://en.wikipedia.org/wiki/PRINCE2

http://da.wikipedia.org/wiki/Scrum

Jeg er nok selv i høj grad mest fortaler for den tekniske projektleder der selv har prøvet at være programmør, men også har været i stand til at forstå hvilke udfordringer en kunde sidder i, og kan fungere som mellemmand og oversætter på de svære ting og så ellers et helt simpelt projektsystem baseret på tickets. De hænger ikke på træerne og ofte er de forklædt som programmører, der er blevet familiefædre og har lidt år på bagen så de har lagt hardcore nørderiet lidt på hylden og de lange nattetimer, men stadig drømmer om at kode lisp og perl når konen er gået i seng eller lignende.

Derimod går det ofte galt hvis man tager en ren projektledertype uden nogen teknisk fortid og kaster ind til en flok programmører, for det er lige som en flok løver der lynhurtigt vil synes det er sjovt at teste projektlederen med jokes og "hvide løgne" medmindre respekten for hinandens arbejdes nødvendighed bliver slået fast med syvtømmersøm :-)

Svar: It projekt planlægning hvordan ??

kruger — Wed, 22 Sep 2010 17:54:10 GMT

Hold da ferie et svar, det havde jeg ikke forventet. Det har helt sikkert givet stof til eftertanke. Det lyder lidt som om nøgleordene er noget i stil med -respekt, dialog og belønning- men hvis man skulle være lidt mere teknisk i forhold til projekt beskrivelsen, er der så noget man skal være opmærksom på ?

Mange tak svaret, er super at se at alle svar ikke er nogle på 5 linjer ;-)

Hilsen Jesper

Svar: It projekt planlægning hvordan ??

Oscar Eg Gensmann — Wed, 22 Sep 2010 17:22:59 GMT

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.

It projekt planlægning hvordan ??

kruger — Wed, 22 Sep 2010 15:21:24 GMT

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