Understand your programmer

Comments

1. Heheheh… "Gange med pi" Ret god regel faktisk 🙂

   Godt indlæg, Martin!

2. Jeg har siddet på begge sider, som både tekniske, der tager imod opgaver, og som kunden, der skal afgive opgaver, og uanset hvilke side jeg har været på, har jeg oplevet problemer, som du nævner.

   Softwarespecifiering ER en uhyre svær disciplin 🙂

3. Hej Martin,

   Nuvel, jeg er fra Mars – men forstår godt din og andres ”frustration”, men kan til gengæld berette af det er lige over. Alt for mange gange ser man teknologi virksomheder etc. der ledes af folk der ikke forstår hvad de har med af gøre.

   Du nævner projektlederne som skal være det bærende, og her går det gerne galt. Jeg har se et utal af grønne CBS folk lande i netop sådan en stilling, og set hvordan en hel afdeling nærmest gå i opløsning grundet uvidenhed.

   Så er det fint de kan rode rundt med Porter’s 5 Forces, lave en SWAT analyse og en fin powerpoint. Men når det kommer til kravspecifikation eller problemanalyse vælter hele læsset. Jeg forsøger personligt at værre åben og imødekommende når en ny udfordring ligges på bordet, men vanen tro ender det altid med endnu flere spørgsmål end da mødet startede. Desuden er talknuser også socialt set lidt afstumpet, og har en tendens til at være lidt bombastiske, hvilket godt kan føles irriterende over for dem fra Månen.

   Ang. PI – her må du forstå dem fra Mars. Selv om vi kan diagnosticeres (jf. dine erfaringer) så søger vi(os fra Mars) altid at gøre os selv bedre, og vi har en indre konkurrence med os selv ang. løsningen af opgaven. Mange gange er det sagte estimat udviklerens eget ønske mål, men i dette estimat er der ikke indregnet de tekniske detaljer der kræves for at løse opgaven dvs. når en opgave er DONE DONE.

   Sidder man i den situation at man skal tale med en marsmand, er det utroligt vigtigt at du sætter dig lidt ind i hvad det er du gerne vil, og ikke bare giver os fra Mars en tandstik og forventer et storcenter. For så er der kun en vej, og der skal to til tango som alle ved.

4. Dine generaliseringer og manglende viden her minder mig om dem, der siger, at "alle chefer er psykopater," hvilket er lige så dumt som at kalde alle programmører autister.

   Vi er ret mange programmører, der rent faktisk godt finde ud af "de andre ting," (inkl. de usagte), aflevering til tiden, brugervenlighed, tekstforfatning, markedsføring osv. Måske har du bare været dårlig til at ansætte de rigtige.

   Men generelt kan man sige, at der inden for alle fag findes mennesker, der fokuserer for snævert på deres eget lille arbejdsområde, og har svært ved at danne bro til andre arbejdsområder. Og det er du jo sådan set selv et godt eksempel på: Du har en "dem og os"-attitude i stedet for at danne bro. Samme ting ser man på alle andre fagområder (arktekter kontra bygningskonstruktører, læger kontra sygeplejesker osv.).

   Så folkens, prøv at se uden for jeres eget lille arbejdsområde – det gælder både chefer, programmører og alle mulige andre. Men hvis din holdning til programmører er, at de er autister uden sans for andet end programmering, så skal du nok ikke regne med at være succesrig i din projektledelse.

5. @Claus, Du har helt ret, at finde de rette projektledere er uhyre svært. Det kræver mange års erfaring før de bliver gode, da de basalt set skal lære at begå sig i en helt anden verden og danne bro til den de kommer fra og ofter dertil forstå at begå sig i en organisation.

   @Hosting 4, jeg jeg regnede også med at den ville nive lidt, men 15 års erfaring med programmører i hundredevis taler sit sprog. Men du har ret, jeg har også haft et fåtal som er som du nævner og lige nu har har jeg faktisk et par stykker i folden og det er en fornøjelse. Men langt de fleste er som jeg beskriver dem og det kan jeg love dig for at 99% vil give mig ret i 🙂

   Dbh Martin

6. Tør man gætte på, at størstedelen af dem, du har dårlige erfaringer med, var ret unge? Helt generelt bliver man nemlig bedre til at se ud over sit eget fag, når man bliver lidt ældre.

   Det slår mig bare, at du taler om menneskelig forståelse, kommunikation mv., men – med al respekt – stort set ikke evner at se ud over din egen måde at tænke på. Igen: Dem, der kommer langt, er dem, der kan danne bro.

   Det, du siger om programmører, har jeg i forskellige udgaver hørt bygningskonstruktører sige om arkitekter, designere sige om projektledere, chefer sige om ansatte osv.: "Hvorfor kan han/hun ikke selv tænke sig til, at…" osv. Ser man ikke ud over sit eget fag, så kommer man ikke langt. Nedgør man den anden faggruppe (ved f.eks. at kalde alle chefer "psykopater", alle programmører "autister" eller alle arkitekter "fimsede"), så gør man ikke rigtigt noget for at få et godt samarbejde til at køre.

7. Hehe… Meget sjovt faktisk, at Martin ikke må generalisere, men du må gerne mht din kommentar om, at de må have været unge, han havde samarbejdet med 😉

   Jeg har prøvet programmører i alle aldre og selv den allerbedste af dem alle, havde ind imellem udfordringer mht at levere til tiden… Som Martin siger, så kan 99% tilslutte sig de oplevelser – og han har med garanti prøvet det i mange flere år end mig – og alle dem jeg kender i mit netværk, som også har brugt programmører til deres Internet forretninger.

8. @Hosting, jeg tror helt ærligt ikke at du har lyttet ordentligt efter.
   Jeg nedgør ingen og nej, jeg har haft programmører i alle aldre.
   Det jeg siger er, at programmører ofte har deres egen måde at tænke på, som ligger milevidt fra den måde andre mennesker tænker på og at andre mennesker har svært ved at sætte sig ind i den tankegang.

   Det har ikke noget at gøre med hvem der er bedst, rarest eller noget som helst andet, det er bare kolde facts.

   Prøv at spørge folk der arbejder med programmører. De vil så godt som alle bekræfte det jeg siger…

   Dbh Martin

9. Hamrende i orden indlaeg! -God tommelfingerregel.

   Problemet er ogsaa at man som projektleder paa en maade er "bankraadgiver/saelger" .

   Man vil gerne saelge en opgave (kender pi) men enten kommer man med en realistisk tidshorisont og en realistisk pris, eller ogsaa giver man en horisont for den konkretiserede opgave (vel vidende at mere tager mere).

   Det er en ufattelig svaer balancegang som projektleder at sige sandheden om en realistisk tidshorisont, og derudover er det ikke altid at kunderne selv er i stand til at se kompleksiteten i en opgave. Kunder er naturligvis ogsaa interesserede i at krejle pris og tidshorisont. Derfor er der kun en ting at goere og det er at indse at for at undgaa skuffelse maa man inkludere "pi" i sit tilbud, -det betyder faerre opgaver men gladere kunder.

10. Thorborg: Min pointe er ikke, at programmører ikke tænker anderledes end dig – hvis de tænkte præcis ligesom dig, ville de lave det, du laver.

    Min pointe er, at det, du siger, stort set gælder alle fag, jeg kender til: At bestemte typer søger mod bestemte fag, sådan at læger f.eks. oftere vil have en lidt anden personlighedstype end sygeplejersker. Og så er det, det gælder om at bygge bro i stedet for at sprede fordomme.

    Det, jeg opponerer mod, er ideen om, at der er programmører, og så er der "almindelige" (det var det ord, du brugte). Programmørerne er så tilsyneladende "autister," hvilket ikke blot er nedladende, men også forkert (ligesom ideen om, at alle chefer er psykopater, er forkert). Ægte autister ville ikke umiddelbart kunne begå sig i programmørjob uden, at at der blev taget helt specielle hensyn, sådan som et testhus i Århus, der beskæftiger autister, gør).

    Vi står i den situation, at der i det meste af den vestlige verden er mangel på programmører, og at programmeringsfaget har svært ved at tiltrække bl.a. kvinder og nydanskere (i USA er problemet ligesådan, bare med kvinder og afroamerikanere). I den situation er det ikke smart at holde liv i eller forstærke fordomme, der kan gøre, at folk fravælger programmeringsfaget før de overhovedet har set, hvor kreativt og spændende det er.

11. @Hosting, Autister findes i alle grader, både dem der ikke kan fungere og dem der fungerer aldeles glimrende. Autist er i min bog bestemt ikke nedladende og hvis du hørte efter hvad jeg sagde i videoen, så sagde jeg tydeligt at jeg brugte ordet "Almindelig" i mangel på et bedre udtryk.

    Jeg tror du misforstår min hensigt med videoen. Den er ikke at bashe programmører, men forklare "kunderne" hvordan de skal tackle dem.
    Jeg sidder næsten hver dag med folk der har bestilt noget hos en programmør og hvor alt går galt. Og da jeg ved hvorfor det går galt, så ser jeg det som rart at forklare folk hvorfor tingene er som de er.

    Så nej, jeg har ikke fordomme, jeg har arbejder bare sammen med rigtigt mange af slagsen og vi har det hammer godt og sjovt, men de er bare meget anderledes tænkende end alle de andre mennesker jeg kender som ikke er programmører.

    Min far er forøvrtigt ingeniør og er præcis på samme måde, så jeg har et godt forspring der 🙂

    Og så er der forøvrigt mange chefer der er psykopater 🙂

    Dbh Martin

12. God video! Vi kender det jo alt for godt for statens IT-systemer, som ofte går i vasken.

13. Super godt sagt… Jeg vil sige at jeg tror dog jeg har taget meget til mig med årene, plus, at alle vore kunder har vi en aftale med at den tid de får oplyst er den de betaler for…. Dermed kræver det jo at man sætter sig + kunden ordentligt ind i opgaven og hvad der skal laves inden man giver en pris, så lipper alle også for at skulle huske på pi reglen 😉

    Derudover har vi en stående historie, om "bare lige knappen", du ved den knap der bare lige skal ligge nede i det ene hjørne nærmest skjult, den må være billig, tiltrods for at det sikkert er den der har den mest komplekse situatuion…. Det er som om at kunderne ikke altid har forståelse for at det ikke kun er hvad man ser, men den faktiske funktionalitet, der tit koster.

14. There are 10 types of people – those who understand binary, and those who don’t…

    En måde at måle en programmørs kommunikationsevne på er at stille en forholdsvis simpelt opgave med et par ting der kan forstås på flere måder, eller som har et logisk flow der kun beskriver hvad man ønsker der skal ske – og udelader hvordan tingene skal fungere hvis der er nogle af præmisserne (eksterne faktorer som f.eks. utilsigtede brugerhandlinger) ikke bliver overholdt.

    Hvis programmøren stiller dig en røvfuld af spørgsmål, får du sansynligvis det du har behov for – hvis han ikke stiller spørgsmål får du det du beder om.

    mvh
    Jan

15. Det er da nogle utrolig dårlige programmører du er stødt ind i, for det er altså ikke os alle som er autister og dovne tosser, som ikke laver deres ting.

    Jo, rigtig mange er, men der er sgu undtagelser kammerat 😉

16. @Mikael, langt de fleste programmører jeg har arbejdet med har været super fede, kvikke og arbejdsomme mennesker.
    Men jeg kan love dig for at det kræver meget erfaring at få tingene til at glide perfekt.

    Så nej, jeg har ikke været uheldig, programmører er bare ofte meget anderledes tænkende og hurra for det 🙂

17. @Mads, "bare lige knappen" er en klassiker og enhver programmørs mareridt. Den viser også med al tydelighed hvor lidt kunderne ved om programmørarbejde og hvorfor ting ofte går galt.

18. Helt grundlæggende er programmører bare en anden type mennesker end alle andre. Det gør sig flot gældende indenfor mange fag, men bliver ekstra tydeligt når vi taler om ting der skal fungere for normale brugere.

    Om en bygningskonstruktør er en flippet autist som ved alt om fugtspærre betyder ikke så meget for mig så længe taget er tæt – men problemet overført til programmører er at taget ER tæt, men jeg har et par krav om at jeg også gerne skal kunne smide ting deroppe, lave et lille værksted og desuden have mulighed for at ruminddele og i visse tilfælde "kun hvis jeg lige får lyst"

    De programmører jeg har arbejdet med er typisk geniale til at løse problemerne præcis som beskrevet. Derfor arbejder vi konsekvent med at beskrive alle processer og tanker bag et website når grafikerne har lavet deres arbejde. VI beskriver hvor knapper fører hen, hvad vi forventer der skal ske når man holder musen over et link osv. osv. –

    På den måde skal programmøren kun løse opgaven og ikke tænke selv.

    Jeg har set eksempler på problemer der er løst, men hvor programmøren bare lige har glemt at brugeren ikke har adgang til at skrive kald i mysql sprog. Og det er simpelthen fordi vi tænker forskelligt.

    Så ja Martin jeg vil give dig ret ting ganges med pi, men med lidt mere end 3 decimaler. – og det er vigtigt at udspecificere hvad man vil have, da en simpel løsning ellers risikere at blive kompleks og tage 14 timer og kunne lave kaffe og ringe til konen på bryllupsdagen, hvor det du ønskede faktisk kunne være klaret på 2 timer og kun skulle sende en e-mail.

19. Grundlæggende har det meget at gøre med kommunikation og empati – jeg er projektleder, og har haft fornøjelsen, og besværet med programmører – fornøjelsen fordi når det svinger og vi taler sammen og med hinanden og er enige om indhold og løsning så kan jeg trylle den realistiske tidsplan op som alle har bidraget til, mens besværet opstår når der ikke er bølgelængde mellem mig og programmøren, primært fordi jeg ikke bruger dén tid der skal til for at skabe relationen til programmøren – og sætter mig ind i hvad der er vigtigt for ham/hende – erfaringsmæssigt er PI ikke helt forkert, men jeg vil dog sige at det er vigtigt at PL gør sig tanker om hvad færdiggørelsesgraden skal være – og at det er klart kommunikeret og accepteret af de udviklere der skal give et estimat…

20. Et af de største problemer er nok, at gode programmører ved, at tingene tager tid, for det gør de. Hvis man laver tingene selv, som en ordentlig programmør naturligvis gør, så tager det altså lang tid at bygge et skræddersyet CMS-system, webshop eller andet modul op.

    Så det er vigtigt at sætte sig i den tekniske viden, som programmøren sidder med. For det ser fint og let ud når det er færdigt, men der ligger ofte mange arbejdstimer i et projekt – mange gange flere end kunden kan forestille sig.

    Derfor er det jo totalt ødelæggende for et webbureau, hvis rygtet går på, at de er lang tid om tingene, og kommunikationen ikke fungerer osv osv. Web-verdenen har brug for en revolution i mine øjne, for der er alt for mange, som hopper over hvor gærdet er lavest, og bruger de færdige systemer, og sælger den som om det er deres egne kreationer.

    Hvis man skal levere noget ordentligt, skal man have en ordentlig viden – og den tager tid at få. Det er derfor vigtigt at lægge mærke til, hvilke bureauer som rent faktisk ved hvad de sidder og laver.

21. Hos os optager vi samtalerne vi har med kunderne, på den måde kan vi a) gå tilbage og lytte til det som er aftalt b) hvis vi er uenig med kunden, så kan vi give kunden et transcript.
    Det er nemt og lige til, der findes et hav af programmer som kan optage Skype samtaler, men man skal naturligvis huske at fortælle at man optager samtalerne.

22. Dette er et af de sjoveste indslag endnu, tak Martin, for at belyse begge sider af sagen etc. Som så mange andre er det ikke svært at genkende situationen (jeg er forresten programmør, og flere har også nævnt ordet "Aspergers" for mig). Jeg tror også det er en god ide at finde en erfaren projektleder som mellemmand / bi-sidder, da det er 2 forskellige verdener som bliver snakket om.

    Mange kunder, som f.eks. vil have en hjemmeside, siger "jeg vil have en pæn hjemmeside", men har så foriøvrigt ikke gjort sig nogen tanker derudover. Den modsatte grøft er lige så slem – de der ved alt, og vil have hjemmesider som bryder med alle konventioner og kun de selv finder logiske. Kort sagt – hav tillid. Jeg går til en frisør fordi det vil formentligt se rét dumt ud hvis jeg skulle klippe mig selv (jeg har ikke selv hverken viden eller erfaring) – så jeg stoler på at frisøren ved hvordan. Når jeg går i en tøjforretning, spørger jeg ikke bare om prisen – jeg spørger også gerne flere om tøjet passer sammen da min egen opfattelse ikke altid er heelt mage til resten af verden. Og på samme måde er det når du går til en IT-person – stol på at det som bliver gjort, er rigtigt.

    @Peter Skouhus: hvor er det i grunden mærkeligt at alle misforstår hinanden mere og mere. Den anden dag var jeg hos en håndværker, som idag tager billeder af stort set alt inden han påbegynder arbejdet – sådan var det ikke for blot få år siden. Idag optager mange samtaler, som du nævner, da dét som kunden siger, ikke altid er det som kunden reelt vil have. Nogle vil i bund og grund slet ikke have en hjemmeside, men ser det som et nødvendigt onde…hvorfor ingen løsninger reelt passer.

    @Martin: respekt for at turde tale om emnerne. Mange har problemer med at se ud over deres egen verden, og jeg synes din video tydelig bærer præg af at ville seeren det godt (velmenende). Men som med så mange andre emner skal man nærmest undskylde i forvejen for at belyse ting som alle ved, men som er et følsomt område. Weird 🙂

23. @ Klaus Jakobsen Vores primær grund for at optage samtalerne er for at vi kan gå tilbage og tjekke hvad man har aftalt. Når man holder et teknisk møde på 1 time eller mere, så kan man ikke huske alt det som aftales, her er lydfilerne en kæmpe hjælp. Men ja, det kan også bruges hvis man er uenig med kunde om hvad er aftalt.

24. Tankevækkende nok kan man så ud fra kommentarerne læse, at det oftest er os kodere, som er årsag til at projekter forsinkes, bliver for dyre eller ikke overholder de ønsker, som kunden nu engang har ønsket.

    Projektledere har per definition INGEN problemer med at forstå både kunders og koders tankegange – og er der alligevel en mærkelig uoverensstemmelse mellem kundens tankegang og programmeringens resultat, ja, så er det da klart, at det er programmørens skyld.

    For det er da utænkeligt, at det er projektlederen, som ikke helt har forstået kundens ønsker eller sårn’ tilfældigvis sagde til kunden: – Jo, det der kan sagtens lade sig gøre. Det er nemt nok for programmøren og ta’r næsten ingen tid. Det skriver jeg da lige med på arbejdsopgaverne til programmøren. Hvad siger du? Næh nej, det kommer ikke til at koste ekstra og vil heller ikke tage længere tid.

    Autisterne er sgi de andre. Forskellen er bare, at vi ved, at vi er underlige og ikke så meget med på ‘beatet’, som de der mærkelige folk, der ikke ser aner, hvordan man sætter tuborg-klammen i funktionerne. :o)

25. @ Michael, jeg er ret sikker på at de fleste projektledere på et tidspunkt i deres liv har forsøgt at bringe noget til projektet som kunne give kunden en højre værdi og som de (PL) tænkte ikke var en stor ting.
    Nogle gange lykkedes det andre gange springer det projektet – i begge tilfælde er det PL som ikke kender sin rolle og sit ansvar, så hvis du oplever det så er du naturligvis konstruktiv i din feedback til PL om at han har husket at få lavet noget ændringshåndtering på den nye funktionalitet 🙂

    Jeg syntes at tråden tager en drejning som er ret spændende, men som ikke har så meget at gøre med det som Martin på glimrende vis satte på tallerkenen – nemlig at det er super super vigtigt at kunde og programmør forstår hvad, hvorfor og hvor meget/hvor lang tid – hvis der skal bruges en PL til at oversætte så fred med det. Altså kommunikation og dialog der sikre forventningsafstemning og i sidste ende sikre at kunden er tilfreds – hvis kunden ikke er tilfreds så komme han ikke igen, og så er det reelt set underordnet om det er PL eller udvikler der har fejlet.

    @peter, syntes det er spændende at høre nogle der bruger optager under møderne, men understøtter i det ikke med nogle use cases eller anden skriftlig beskrivelse af opgaven der skal løses, selv om I har det på "lydbånd" så er det jo stadig muligt at tale forbi hinanden, eller bruger en en speciel tektik til at gennemgå indholdet af opgaven med kunden?

26. Enig enig enig, hvilket er grunden til at korte daglige statusmøder i den grad er givet godt ud! Så man ikke får de forventelige overraskelser på bagkant…

27. @ Kasper Jørgensen Vi forsøger at få usecases når vi kan, det er bare ikke altid så nemt som det lyder. Hertil kommer at vi altid laver en projekt beskrivelse, men under projektet har man jo også mange møder med kunden, der er change request osv, her er det dejlig at have det hele optaget på MP3 for man kan altid gå tilbage og tjekke tingene.

    Jeg har, som pendant til dette indlæg, lavet en video blog over på Amino om hvordan man mindske problemet: http://www.amino.dk/blogs/outsourcing/archive/2010/09/24/s-229-dan-tjener-kunde-og-leverand-248-re-flere-penge-p-229-de-samme-it-projekter.aspx

    Måske det kan bruges til lidt inspiration…

28. Hej Martin

    Det er SPOT on!

    Jeg er jo selv nørd, programmør, 10-15% Asberger autist (dog ingen officiel diagnose, men jeg har stillet min egen gennem tiden :]), og de problemstillinger du ridser op har jeg selv været igennem mange gange (bare på den anden side af bordet).

    Men ligesom alm. mennesker skal vide ovennævnte om programmører, så skal programmører også vide ovennævnte om "sig selv" og tænke over det i deres daglige arbejde. Så bliver man bedre til at kommunikere med andre (også alm. mennesker) og man bliver bedre til at vurdere omfanget af en opgave (Jeg ganger også selv mine egne estimater med en faktor, dog ikke Pi men 2 :]).

    /Grosen Friis

29. Der er mange grader af udviklere, nogle af de dygtigste kan være som de bliver beskrevet her.

    Selv er jeg en forholdsvist eftertragtet freelance konsulent og har af princip meget kundekontakt. De projekter jeg har været på (som arkitekt med ledelsansvar for udvikler teamet) er vi kommet i mål til tiden og til prisen.

    Der bliver lukket lidt op godteposen i nogen af de sidste kommentarer. Der er forskel på et en "udvikler" der sidder og fisker opgaver på amino freelancer. Han er af princip alene og har ingen "projektleder" eller "sælger" der kan skærme ham og omsætte "forretning til funktionelle krav".

    I min verden er det sjældent udvikleren der gør at et projekt ikke kommer i mål. Ja, det er selvfølgelig udvikleren der kan introducere fejl, men dette bør der tages højde for i processen.

    Nej tværtimod, det er projektledere og sælgere (og ledere der har politiske motiver) der for det meste sørger for at et projekt bliver en fiasko. Når man kommer op i visse størrelse projekter med især offentlige kunder, spænder kunden ofte selv ben for projektet grundet forskellige interesser (en god grund til at jeg godt kan lide SCRUM processen der siger at man kun har een "product owner" og man derfor ikke får forskellige input på samme problemstilling).

    Enkelte gange kan det simpelthen også være mangelende kompetence hos teamet. Det er klart at vil man fx lave en søgemaskine fra bunden, kunne det være en god ide at finde en eller flere til teamet der har erfaring med dette.

    En projektleders arbejder er at gå foran teamet og rydde alle sten fra vejen så teamet buldre der ud af. De fleste går dog mere op i regneark, ressourcebelægning og gantcharts. En sælger er at sælge det der rent faktisk skal laves. Især sælgere har jeg mange sjove historier om. De er typisk så langt væk fra en IT hverdag at de slet ikke aner hvad det er de sælger (i hvert fald hvis man kommer ud over 10-20 mands virksomheden).

    Ved ikke pointen med dette svar var, men det er noget der ligger mig meget på sinde, da det er noget jeg selv har været god til i min karriere, men alligevel har set en masse større projekter være super forsinket.

    Jeg kan dog pege i retning af et værktøj jeg selv har brugt (ud over SCRUM processen). Personprofileringsværktøjer. Hvis man ved hvordan hver enkelt team medlem er som person, ved du også hvordan du skal kommunikere med vedkommende og motivere vedkommende. Halvautisterne som bliver beskrevet her, kan fx godt lide ro og fred. Det er fx en god ide at advare dem via messenger inden man kommer forbi deres bord (også selvom man sidder 2 meter væk :)). De skal også have meget faste rammer, da de ellers bare udfylder rammerne selv.

    "Fx. Skriv denne lille rss komponent der viser et rss feed på siden". Hvis man ikke giver dem meget faste rammer, kan de bruge 200 timer på det, fordi at man jo først lige skal kode et helt framework til at understøtte dette, med 4 lags caching og pinging feature. Her er det vigtigt at projektlederen (eller ofte mig som arkitektekt) kan forklare rammerne af denne opgave til udvikleren. Hvis udvikleren fx. ikke var helt så autistisk, ja så kunne ovenstående beskrive faktisk være god nok.

    Puhash, langt ustruktureret svar… måske skulle jeg skrive et blog indlæg et sted 🙂

30. Jeg har ikke gennemlæst alle kommentarerne – de virkede som om de gled i retningen af en diskussion..

    Hvis man vil konkludere noget værdifuldt skal man jo finde ud af, hvorfor problemet opstår, såvel som hvordan man kan løse det. Og her er parallellen:
    Programmører er omtrent lige så gode (forhåbentligt bedre) til at vurdere hvor meget tid det kræver at implementere et "koncept", som MBA’er er til at projicere omsætning og profit for de kommende år. Begge dele er fuldkommen bullshit.
    Man kan selvfølgelig godt vælge at mene, at problemet ligger i, at arbejdsudbyderen ikke er dygtig nok til at formidle indholdet af opgaven præcist. Men typisk så aner vedkommende ikke selv hvordan slutresultatet skal se ud, selvom de fleste formodentlig bilder sig dette ind.

    Hvordan løses problemet så?
    Ved at fokusere på arbejdsprocessen. Fancy ord som Agile Development lyder skræmmende, men det er faktisk meget basalt. Lad vær med at tro, at du kan overskue nøjagtigt hvordan et helt koncept skal resultere med at se ud og fungere. Programmøren kan ikke, og du kan ikke. Bryd i stedet konceptet op i små dele, og start med at arbejde side om side med programmøren på at få virkeliggjort den vigtigste del først. Er I tilfreds med den del, kan arbejdet fortsætte med en ny del. Sådan en arbejdsprocess sørger ikke kun for at programmøren prioterere rigtigt og leverer til tiden, den er også enorm værdifuld for kunden, fordi den tillader ændringer, når kunden pludselig indser at noget skal fungerer helt anderledes.
    Skulle du være så priviligeret at have en designer på teamet, så lad for guds skyld vær med at tro, at processen for ham er anderledes. En hjemmeside skal Ikke først designes, og derefter skæres ud og implementeres af programmøren. Det er opskriften på et skidt resultat.

    Slutteligt, husk altid at have alting tegnet ud på papir og test det med brugeren før du beder programmøren slå i tastaturet, det er guld.

31. Det er det bedste indlæg du har lavet indtil nu, jeg arbejder selv med udviklere til dagligt, og nøøøøøj du har ret.

    Kan man mestre kunsten så kan man nå langt, kan man ikke, ja så ender man i dead end og et dyrt projekt 🙂

    Fantastisk indlæg

32. "Jeg har set eksempler på problemer der er løst, men hvor programmøren bare lige har glemt at brugeren ikke har adgang til at skrive kald i mysql sprog. Og det er simpelthen fordi vi tænker forskelligt."
    Det er da god en måde at tjene flere penge på supporten 😉

    @ #29 og #30
    Good point – enig.

    Autist, Asberger, "Normal"!; Spørgsmålet er vel om at kunne spørge om dét man vil vide – et konkret spørgsmål giver et konkret svar.

    Som person fra "Mars" (med "~10% uofficiel aspergers syndrom"), vil jeg mene at denne analogi ikke er helt urealistisk i dette tilfælde.

    Som jeg ser det, er det i det omtalte eksempel projektlederen der er problemet – hverken product owner eller programører (større end små projekter med få eller enkelte "nørder" tilknyttet)

    En analogi fra automekanikeren:
    – Kunde: Min sprinkler virker ikke. Der kommer ikke noget ud af den. Hvor lang tid vil det tage at lave?
    – Tekniker: 2 minutter.

    (her stopper Thorborg, og går ud fra at kunden stadig sidder hjemme 2 min. senere og ringer til mekanikeren for at brokke sig over at den stadig ikke virker efter de 2 minutter som han lovede!!! – you get my point?)

    – Kunde: Ok, hvornår kan jeg få dem lavet?
    – Tekniker: I morgen kl 9:30.
    – Kunde: Ok, så kommer jeg forbi i mogen kl 9:30.

    Resultatet: Kunden kommer til mekanikeren kl 9:30 for at få fyldt sprinklervæske på bilen, betaler, og kører igen kl 9:32…

33. Har lyttet showet her til morgen. Tak for det – underholdende som sædvanligt.

    Kom lige til at tænke på en artikel med relation til din "Programmører er autister" påstand – http://ing.dk/artikel/72758-psykologer-asperger-er-et-ingenioersyndrom

34. Interessant artikel, tak for den 🙂

    Dbh Martin

35. Hi Thorborg.

    Sider selv med adskillige års afferingen inden for udvikling, og jeg kender problmet du nævner ganske godt, jeg som programmør svare jo på det jeg bliver spurt om.

    dog vil jeg også lige forsvare programmøre, at de der skal ha lave en webshop eller hvad de nu vil have udført ja de er utrolig dårlig til at forklare sig i helhed, når man begynder at sprøger dem om en masse så siger de tit og ofte bare "jamen det skal bare være en webshop" ikke noget med "der skal være fuld lagerstyring, fuld variant styring m.m." nej de vil bare have en webshop, så er det altså også et temlig vidt begrab når der er tale om en opgave. for hvor lang t id tager en webshop at lave 😉

    Skal det være opensoruces eller skal det være noget der er lavet fra bunden som er en custom shop så udgiftere på sigt og flexiblitet er forminskes og forøges? ja der er mange faktore, så jeg vil også mene der mange gange er nogle temlig uviden folk der sider og vil have løst en opgave og forventer man ved nødagtig hvad de vil have selv om de ikke taler om det.

    men ellers hvis der er tale om mindre funktions ændriger eller mindre opgaver, så passer tiden * pi nok ganske godt, har aldrig regnet efter 😉 men ved bare kunden tit kommer tilbage og lige skal have lavet lidt mere for det "havde de jo sagt" mener de, 🙂

    ellers godt indlæg fra dig forsat god søndag.