martin frederiksen bloghoved

Fra det virkelige liv: Når sælgerne bestemmer over koden ...

I mit arbejde er jeg så heldig at få lov til at hjælpe andre. Jeg rydder op i it-projekter, der er gået galt (for andre), og det er et spændende job. De fleste problemer handler ikke om kode, men om mennesker, der ikke forstår hinanden.

Når sælgerne får lov til at bestemme

En gang var jeg involveret i et projekt, hvor en udviklingsafdeling producerede software, der blev solgt af et team af sælgere. Det er fint nok, at udviklerne skriver kode og sælgerne leverer løsninger, men hvem bestemmer egentlig over nye features i sidste ende? Det gør sælgerne, naturligvis. De har jo en direktør, der også er fra en business school, og han forstår sælgerne bedst: "Alle ved jo, at sælgerne har mest forstand på markedet". Ikke?

Problemet er bare, at sælgerne ikke har forstand på fremtiden. Kun på fortiden. De fleste sælgere husker den sag, de sidst tabte. Den vigtigste feature er den, der kunne have vundet sidste sag. Sælgerne må ikke bestemme road map. Så er man kun bedst, når man ser ind i fortiden.

Prisen skal sættes efter, hvad det er værd

Sælgerne fandt ud af, at noget skulle laves om. De synes ikke om refaktorering af kode eller bedre usability. "Det kan man jo ikke tjene penge på". Man tjener penge på features. Sælgerne valgte prisdifferentiering som næste store indsats. Systemet blev kodet om, så man kunne tage højere priser fra de største kunder. Der skulle betales efter antal brugere. Det tog måneder, men så var man klar.

Fail fast

Blev kunderne så glade for højere priser for samme produkt? Selvfølgelig ikke. Nogle gik. Set udefra er det jo en tosset historie. Hvordan kunne man tro, det ville gå godt? I første omgang fordi man aldrig talte om projektet. Sælgerne og udviklerne mødte hinanden til frokost, men man talte ikke om road map.

Beslutninger om road map blev truffet af ledelsen, som var dem, der vidste mindst om platformen. Det er en typisk måde at arbejde på, og den er ikke god. Hvad skulle man have gjort i stedet for? Hvis udviklerne og sælgerne havde fået lov til at mødes, diskutere med hinanden og vende alternativerne, så var det måske gået sådan her:

Sælgerne havde forstået, at det de troede var et mindre indgreb, faktisk ville lægge udviklingsafdelingen ned i flere måneder. Udviklerne havde haft mulighed for at forklare, hvilken gavn man ville have fået af refaktorering - for eksempel kortere udviklingstid fremover. I fællesskab kunne man have opfundet nye features, der ville have større forretningsmæssig værdi og som ville hjælpe sælgerne bedre. I det konkrete projekt ville det have været utrolig let.

Du har sikkert selv været en del af sådan et projekt. Del dine erfaringer. Hvad bør man gøre?

Læs også præsentationsartiklen om Martin Frederiksen her.

Kommentarer (16)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Casper Olsen

Jeg har tidligere oplevet samme problematik på freelance projekter, hvor jeg har lavet programmerings-delen. Designerne der stod for salget lovede kunden guld og grønne skove med nye features og store ændringer undervejs, som ikke var en del af den første løsning.

Resultatet var en overskridelse af deadline og budgettet, endda flere gange, da jeg var nød til at bruge mange flere timer end først antaget da kontrakten blev skrevet. Hovedsageligt fordi at det næsten altid var nødvendigt at ændre i kernen af produktet, da de bare antog at det var et lille indgreb der var nemt at lave.

Så rådet fra mig til sælgere og designere: Snak nu lige med dem, som laver koden inden du siger "Jamen det laver vi da, det tager kun 5 minutter" når det faktisk måske tager 2 timer eller endnu mere.

Ole Elkjær Christensen

Dette er jo et ganske kendt problem med at kunder, sælgere og udviklere ikke taler sammen.
Den mest interessante løsning på dette problem er, som jeg har set mere end en gang, er at indføre endnu et lag mellem sælgere og udviklere. Dette lag består så af en blanding af projektledere, processfolk, forretningsudviklere o.s.v. som primært har som opgave at afskærme udviklere endnu mere fra kunder og de reelle ønsker til produktet.
Dette lag ser så formidabelt ud i forhold til ISOxxxxx m.m. men har det løst problemet ???
Det jeg har set ind til nu er at produkterne er blevet dyrere og tager længere tid at lave, men jeg er rimelig sikker på at det generelle problem med at kunderne og udviklerne taler sammen om reelle ønsker til produktet ikke er blevet løst :-)

Jesper Lund Stocholm Blogger

Jeg synes faktisk, at det er en falsk modsætning, at det skulle være sælgerne, der er årsagen til alskens bøvl og besvær. For hvem skulle ellers være med til at afgøre, i hvilken retning et produkt skal gå? Dem uden kontakt til kunderne?

Løsningen er ikke, at nogen andre end sælgerne er med til at fasstlægge retningen for produktet - løsningen er, som andre også er inde på, at man snakker mere sammen og skaber en større bevidsthed om hvad ting koster at lave.

Martin Frederiksen

I nogle organisationer er problemet, at sælgernes synspunkter bliver favoriseret af ledelsen, og de har oftest samme uddannelsesmæssige baggrund og forstår hinandens sprog godt.

Når man læser systemudvikling bliver man sjældent undervist i at lave business cases eller argumentere for de totale levetidsomkostninger ved en given feature, så ofte er modspillet fra udviklerne ikke i top, og de taber derfor argumentationen med ledelsen. Det er et problem, jeg ofte møder. Er helt enig i at bedre dialog er vejen frem, naturligvis.

Jesper Lund Stocholm Blogger

I nogle organisationer er problemet, at sælgernes synspunkter bliver favoriseret af ledelsen, og de har oftest samme uddannelsesmæssige baggrund og forstår hinandens sprog godt.

Det tror jeg er korrekt, men så er løsningen og rådet jo ikke, at "det er et problem når sælgerne bestemmer over koden" - løsningen er "så må I udviklere sgu mande op og få lært jer at tale ledelsens sprog (eller i det mindste skal nogle af jer kunne det)".

Din fremstilling er jo ikke fuldstændig ukendt - den høres ofte og tit. Jeg mener blot, at det er at skyde forbi målet og reelt misforstå dynamikken. Jeg er enig i, at udviklere ofte ikke kan tale "ledelsessprog", men det er altså udviklernes problem, at de ikke kan tale med dem, der bestemmer - ikke sælgerne.

Jeg hører ofte udviklere sige, at de ikke gider tage kampe eller endsige snakke med ledelseslaget, "for de forstår os ikke". Til det kan jeg kun sige, at hvis du har en idé du gerne vil frem med, så er det dit ansvar at formulere den på en måde, så modtageren forstår det. Det er ikke alle andres ansvar selv at regne ud, hvad pokker du mener.

Spg: Hvordan ved du, at du taler med en udadvendt programmør?
Sv: Han ser på dine sko imens I taler sammen.

Martin Filtenborg

Til det kan jeg kun sige, at hvis du har en idé du gerne vil frem med, så er det dit ansvar at formulere den på en måde, så modtageren forstår det.


Det ku' man så meget passende sige til sælgerne. For de har vel osse ideer de gerne vil frem med ;)

Til sammenligning: Du har en ide til en træterrasse. Betyder det så at det er tømrerens opgave at formulere ideen? Nej, vel.

Det er en FÆLLES opgave.

Casper Thomsen

løsningen er "så må I udviklere sgu mande op og få lært jer at tale ledelsens sprog (eller i det mindste skal nogle af jer kunne det)".

Jeg synes, det er at hoppe i den anden grøft.

Hvis udviklere og sælgere ikke kommunikerer fornuftigt sammen med den konsekvens, at det går ud over produktet eller skaber unødvendige omkostninger, så er det firmaet som helhed, der har et problem.

Dermed er det heller ikke et problem, der skal fedtes af på enten udviklere eller sælgere. Det er ledelsens ansvar sammen med de ansatte at sørge for at skabe et miljø og processer, der understøtter dette. Som Martin siger - det er en fælles opgave.

Det kan handle om, at udviklerne skal forstå de overordnede forretningsbehov, så de ikke fordyber sig i tekniske detaljer. Og det kan handle om, at sælgerne skal forstå de tekniske overvejelser, som ligger bag det produkt, de sælger - der var for nylig et interessant eksempel med firmaet, hvor alle ansatte, også sælgere, kom på Javascript-kursus
http://www.version2.dk/artikel/softwarefirma-tvinger-alle-ikke-tekniske-...

Jarle Knudsen

Det er helt korrekt, men som Martin også nævner, så taler de oftest samme sprog som ledelsen, så de har ikke de udfordringer "vi" andre har.


Er det rigtig at IT skal agere sælgere? Her vil jeg gerne vende om problematikken:

Hvordan en leder uden IT-kompetence og forståelse af "IT-sprog" kan lede en IT-afdeling?

Hvordan en IT-sælger uden IT-kompetence og forståelse af "IT-sprog" er i stand at effektivt sælge IT-produkter?

Som et eksempel vil jeg vise til Apple under John Sculley vs. Apple under Steve Jobs.

Jonas Grau

Jeg er selv udvikler og kender bestemt til udviklere der har de træk som denne artikel (og kommentar indlægene) tilegner en "udvikler". Men det er en alt for grov generalisering. Der findes masser af udviklere, der sagtens kan tale med både sælger og ledelse samt få forklaret problemstillinger så andre kan forstå dem.
Der findes også masser af udviklere, der ikke kan.

Anbefalingen er enkel: sørg for at din udviklingsafdeling består af en række forskellige "udvikler-profiler". Og hvis din udviklingsafdeling er lille, så sørg for at du har mindst én, der kan forklare dig hvad problemet er og hvordan man løser det bedst og hurtigst så I i fællesskab kan holde hvad i lover.

Klavs Klavsen

Så fungerer det bedst, hvis sælgere har en tekniker med.

Det er min erfaring at det hjælper rigtig godt til at kvantificere hvad kunden PRÆCIST har behov for - og hjælpe med at sikre at dreje løsningsforslaget så det også bliver noget der umiddelbart kan leveres.

Oftest så er kunden faktisk ligeglad med om det laves som 1+3 eller 2+2 - bare de får resultatet 4 :) - problemet er at så snart udvikleren/teknikeren IKKE snakker direkte med kunden - forsvinder muligheden for at få klarlagt de præcise behov og dermed for at finde en fornuftig løsning der er implementerbar OG opfylder kundens ønsker/behov.

Jens Jakob Andersen

De bedste produkter jeg i min tid på leverandørsiden var med til at udvikle og sælge, var de produkter som udviklerne SAMMEN med sælgerne planlagde.

Der var en unik dynamik nær begge sider sad sammen, og i fællesskab brugte hinandens kompetencer til at lave next-gen produkt-design.

Vi er alle i samme båd ;-)

Jonas Auken

Udemærket blog og fin diskussion - men jeg undrer mig lidt over at ingen nævner agil udvikling (Scrum, XP, osv.) som en del af løsningen. Er det fordi det er så indlysende at vi ikke behøver at nævne det eller er det ikke noget folk her bruger og/eller kender?
Et kort rids af agil udvikling vil være: Et selv-organiserende team med alle nødvendige kompetencer til rådighed. Det vil også sige at der sidder en "sælger" med i teamet. I Scrum hedder han/hun en Product Owner. Samtidig er alle udviklere ansvarlige for hele projektets/produktets succes - og det vil sige at man som udvikler må tage del i snakken om kundernes behov.

Agil udvikling blev "opfundet" for 20 år siden - og har i 10 år været de-facto standard for både små og store succesfulde firmaer. Men jeg har lidt på fornemmelsen at mange danske firmaer ikke har opdaget det endnu - specielt de firmaer som ikke har IT som kerneydelse.

Martin Frederiksen

Jonas, jeg er helt enig i, at agil udvikling med en sælger med i teamet er en rigtig god idé.

Sprintmøderne er en særlig god lejlighed til at vise ting frem for forretningen, og det er for få agile projekter, der for alvor udnytter den mulighed.

Det er også centralt, at product owner er villig til at påtage sig det kommercielle ansvar, uanset om product owner er en person tæt på udviklingsafdelingen eller en person, der normalt sidder i forretningen.

I det konkrete projekt var det blot sådan, at topledelsen egentlig var ligeglade og gav deres egen kommercielle afdeling carte blanche til at køre en dagsorden igennem overfor udviklerne. Det er ikke kønt at se på, og det giver heller ikke et godt resultat.

Log ind eller Opret konto for at kommentere
Brugerundersøgelse Version2
maximize minimize