Tankar kring utvecklingsarbete

Jag har arbetat en längre tid med mjukvaruutveckling. Mitt fokus och intresse har med åren glidit alltmer över mot området sälj, marknad och kundkommunikation i olika former, med diverse nya arbetsuppgifter inom detta som följd. Dock ligger en hel del av drivkraften och arbetsglädjen kvar i att hitta nya lösningar på existerande problemställningar inom teknik och verksamhet. Fortfarande utför jag en hel del av implementeringen av dessa lösningar.

Gissningsvis är ni några läsare som på något sätt är en del i en kedja som berörs av olika system i någon form, samt kanske även utveckling av sådana.

Något som slog mig nyligen, är hur ofta utvecklingsarbete i olika former fortfarande är strukturerat på ett sätt där det finns en beställare som vill ha en produkt för att fylla ett behov i sin verksamhet, en projektledare som leder utvecklingsarbetet rent organisatoriskt, kanske en arkitekt som ritar ut den strukturella skissen för systemet, och slutligen personerna som skall bygga lösningen. Fler roller finns naturligtvis många gånger, men de är som jag ser det inte relevanta för just den här diskussionen.

Hur många gånger har det inte, trots diverse avstämningar, uppföljningar och testkörningar under utvecklingsarbetets gång, ändå inte blivit rätt? Ibland rent av helt fel i slutändan? Att funktionaliteten som utvecklats, trots noggrann planering, exempelvis inte går att anpassa i linje med systemets fortsatta existen och de nya behov som oundvikligen uppkommer på vägen?

Den miss eller risk jag dock oftast stöter på, är när man vill göra just sådana anpassningar till nya behov. En snabb fix för att släcka den aktuella branden och rädda situationen för den aktuella leveransen.

Ett konkret, men ändå generellt exempel på den problemställningen är när ett projekt inför leverans gör diverse tester för att säkerställa utformningen på det som skall skickas iväg. I sista stund inser projektansvariga att ändringar krävs för att kunden skall få det som förväntas. Alltför ofta tas då mer eller mindre medvetna skygglappar på. Ändringen är ju enkel och snabb att göra, eller hur?!?

Ja. Och, nej. Många gånger slår förändringar igenom på fler fronter, för fler aktörer än det projekt som använder och levererar materialet här och nu. Ansvariga kan eller väljer att inte se åtgärden ur det perspektivet, men för dig som genomför förändringen är de långsiktiga negativa effekterna glasklara.

I slutändan är det, trots kloka tankar bakom system och stor verksamhetskunskap hos beställaren, ofta den som bygger det hela som har chansen att upptäcka missar i föregående strukturerings och planeringsarbete när denne rent handgripligen bygger lösningen. Att se lösningen ur ett annat perspektiv, kanske inte lika förblindat av krtsiktiga prestationskrav.

Min tanke och fråga är nu; brukar du som ”byggare/utvecklare” gå tillbaka och ifrågasätta den tänkta lösningens utförande? Detta innebär ofta att ifrågasätta det planeringsarbete och beslutsfattande personer lagt ned mycket tid och arbete på.

En i mina ögon bra kollega/medarbetare/chef i projektgruppen tar emot dessa upptäckter som en god hjälp på vägen mot målet, eller i alla fall som konstruktiv kritik. Trots det finns det alltid personer som istället känner sig trampade på tårna, och ifrågasatta på ett negativt sätt.

Tar du fighten, eller jobbar du vidare och gör som du blivit tillsagd och instruerad? Fyller förväntningarna på din roll som den som bara bygger tekniken/lösningen, eller känner du dig även delaktig i och faktiskt ansvarig för de övriga delarna i arbetet?

Jag tycker att man som utföraren av det arbete andra planerat, har ett ansvar att berätta om tankar och åsikter man får under arbetets gång för övriga delar av projektet. Att man så långt det är möjligt även som utvecklare har verksamhetsaspekten i åtanke när man bygger sin lösning. Det kan sätta dig i blåsväder, men uppskattas också ofta av beställaren.

Många gånger har jag upptäckt fel som byggts in från första början. Uppenbara brister som till synes borde varit svåra att miss för den som skapade den första lösningen. Ofta hör jag också resonemanget att ”det fungerar nu” och ”det är vad de har beställt”.

Bättre att istället förebygga och undvika framtida problem redan vid byggandet, än att krascha som förväntat när förutsättningar planeringsarbetet inte förutsåg kommer och belastar den lösning man skapat.

Jag känner att de här tankegångarna även borde vara tillämpbara på andra områden, som till exempel vid verksamhetsutveckling?

Annonser
Det här inlägget postades i Stil och har märkts med etiketterna , , , , , . Bokmärk permalänken.

7 kommentarer till Tankar kring utvecklingsarbete

  1. Kaskar skriver:

    Intressanta tankegångar.

    Som jag ser det finns det två områden. När du arbetar för en kund och när du arbetar för dig själv.

    Jag upplever ofta när jag jobbar med kunder att det, som vanligt, är pengarna som styr. Ofta när jag presenterar en framarbetad lösning, med kostnadskalkyl, för en kund så börjar de direkt förhandla om pris. Vilket ju är naturligt och en del av jobbet, speciellt för en inköpare. Nu är jag ju inte dummare än att när jag förhandlar så stryker jag bort vissa delar av leveransen om vi förhandlar ner priset. ”Du får det billigare, men då får du inte det här. Och då kommer det inte att lösa de uppgifter ni förväntar er att det ska lösa”. I många fall ser kunderna inga som helst problem med det. Bara de klarar budget är utkomst i stort sett oväsentligt. Därför levererar jag många gånger vad jag vet är en undermålig produkt, men beställaren har som sagt beställt just det.

    När jag arbetar ”själv”så kompromissar jag aldrig. Jag jobbar ständigt med att förbättra mig och mina processer. Till exempel har jag arbetat fram ett system för att dokumentera förhandlingar, ändringar av beställningar och hur det påverkar en leverans. Samt ett flödesschema så att jag aldrig missar att få ett godkännande från kund att de inser att det lägre pris de förhandlat fram kommer att ge en annan leverans. Så att de inte kan komma och gnälla på att sakerna inte fungerar eftersom de själva valt det.

    • Archibald skriver:

      Låter mycket som mitt sätt att resonera. Pengarna blir i kundsammanhang nästan undantagslöst det avgörande, vad beställaren än vill hävda rörande månande om kvalité osv. 🙂

      Det jag tänker i texten ovan, har en del att göra med situationen då du gör jobb för en kund, vars verksamhet du hunnit bli ganska insatt i. När den beställning de gör innebär att du implementerar något som i förlängningen kommer att utgöra problem för andra delar av verksamheten.

      Där ser jag det som en nödvändighet att att även som utvecklare belysa de verksamhetsmässiga krockar man upptäckt att jobbet skulle innebära. Även om det innebär att ifrågasätta kundens åsikter och redan utfört utredningsarbete. Givetvis får man känna av situationen, och avgöra om/hur hårt man bör argumentera för sin åsikt.

      Ibland får man ju ändå genomföra den bitvis bristfälliga lösningen för att säkra leveransen, och på i efterhand göra nödvändiga ändringar för en även på sikt robust lösning. Är det möjligt tror jag dock den bästa investeringen är att göra rätt från första början. Sen kommer alltid frågan, vilken projektbudget skall bekosta det mindre roliga upprättningsarbetet? 😉

      Inte sällan

  2. Karl Laurentius Roos skriver:

    Så länge du levererar enligt specifikation kan du ju alltid understryka detta. Självklart skall man dela med sig av tankar och idéer kring projektet i fråga, av egen erfarenhet så brukar det i nästan alla fall också leda till en bättre produkt i slutändan.

    Vid tvister så brukar jag försöka kompromissa, kanske bjuda på något så länge kunden har en bra attityd. Men när man börjar ge sig för mycket så sitter man i skiten, det är en balansgång.

  3. Lord Sidcup skriver:

    Kära Archibald et al.,

    Jag uppskattar verkligen era försök att sprida den goda, brittiska tweedkulturen i vårt
    avlånga land. Ingen kan invända mot en blogg tillägnad kostymer, cap toe-skor,
    plommonstop och diverse accessoarer och badrumsattiraljer.

    Inget kan ju tänkas vara mer drönaraktigt än att skriva ett inlägg om canvastofflor, när London står i lågor.

    När man däremot läser sådana här inlägg om, uuuurk, arbete… *får en kväljning* …så blir man tveksam om ni verkligen är att betrakta som drönare.

    För att fastslå er korrekta drönarstatus, skulle jag vilja att ni svarade på följande
    frågor:

    1. Hur många av er har i sin ägo en stulen poliskkask/-mössa?
    2. Vilka drönarrelaterade idrotter (kappspelning på mandolin, tornering med hoprullad tidning som svärd, bullkastning etc.) ägnar ni er åt?
    3. Hur många av er avviker från det korrekta drönaridealet genom att faktiskt ha
    ett arbete?
    4. Hur många gånger har era medlemmar gripits och åtalats under falskt namn, i
    full minstrelmundering, inklusive ansiktsfärg?
    5. Vad är frekvensen av butlers/betjänter bland era medlemmar?
    6. Exakt hur många av er är portade från minst ett svenskt eller brittiskt slott?
    7. Försöker ni skrämma slag på mig med den här sortens osmakligt arbetsrelaterade inlägg?

    Toddle pip,

    Spode

    • Archibald skriver:

      Tack Spode för din glädjande respons.

      I sammanhanget får jag nog snarare se mig som en Kronblom, med en stark kläd- och kostymfetishistisk ådra.

      Kan jag idrottsmässigt tiilgodoräkna mid dagliga seglatser på fåfängans fullriggare?

      Jag är stum av häpnad inför din imponerande kreativa och inspirerande meritförteckning. Som bäst skulle jag eventuellt kunna kontra med den, i och för sig digra, lista över saker fru Mulliner skulle önska att jag genomförde på hus och tomt.

      Risken är dock överhängande att WordPress då skulle kasta ut oss, som följd av att jag konsumerat alldeles för mycket serverutrymme.

      Det skulle i sin tur kräva att vi upprättade och underhöll en egen domän, vilket jag känner innebär på tok för mycket arbete.

      Trevlig helg på dig!

      /Arch

      • Cedric Basset Nelson-Spode, Lord Sidcup skriver:

        Vi får väl ändå se er berömda imitation av en värpande höna? Och er strumpsamling?

  4. Johan skriver:

    Nu arbetar jag inte inom samma område utan istället mekanisk konstruktion men jag känner igen problematiken efter bara några års aktiv tid i branchen. Jag sitter inte på en post som ger speciellt stort inflytande i beslutsfattning men tänker ändå ofta på detta.
    Självklart skall man se till att det blir rätt från början i längsta möjliga mån. En stabil grund är alltid en förutsättning för en bra slutprodukt och detta är ju väldigt basic projektmetodik. Förstudier skall inte snålas med.

    Så enkelt är det ju tyvärr sällan. Men å andra sidan så kan även ett misslyckat projekt vara en väldigt bra erfarenhet för samtliga inblandade. Ett företag som kan se de ljusa sidorna av ett misslyckande har kommit långt.

    Att som konsult påtala detta faktum är dock sällan att tänka på utan då får man helt enkelt ta i skiten och göra det bästa möjliga av situationen.

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s