Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Geboden IT-oplossingen eerst zien, dan geloven

 

Expert

ing. W.Y. Wong
Unisys Technical Consultant, Unisys N.V. Nederland. Expert van voor het topic .

Een salesteam staat er om bekend dat zij zo snel mogelijk een order willen. Het verzoek vanuit het salesteam om op korte termijn een oplossing te vinden voor een klantvraag valt dan niet te vermijden. Die worden dan bij de (potentiële) klanten ingezet ter motivatie en inspiratie voor het verder uitwerken van de voorgestelde ideeën. Oplossingen bedenken en ontwikkelen vanuit zulke verzoeken belanden dan ook onmiddellijk in een 'quick-and-dirty'.

Het oplossen van de geïnitieerde vraag kan op vele manieren uitgevoerd worden. Met een beetje creativiteit en innovatie kan men al spijkers met koppen slaan. Het pijnpunt is meestal al bekend en het gewenste eindresultaat is duidelijk. Het probleem is de route die afgelegd moet worden om het doel te bereiken. Toch zal de ontwikkelaar aan de hand van onduidelijke, onjuiste of onvoldoende specificaties de gewenste oplossing proberen te vinden, en wel binnen zeer korte tijd.

Een oplossing wordt dus snel bijeen gesprokkeld. Tijd voor een grondig onderzoek en een goede voorbereiding is er niet. Alle mogelijke opties voor de ontwikkeling worden mede hierdoor open gehouden. De eerste opzet blijft compact en simpel opgebouwd. De instellingen worden keihard in de code bewaard en de bouwstenen voor verschillende lagen ontbreken. Eenvoud speelt hierbij een doorslaggevende rol, want in een 'quick-and-dirty'-scenario staat snelheid boven kwaliteit.

Uiteraard nadat de oplossing aan de (potentiële) klant wordt gedemonstreerd zullen de specificaties duidelijker worden. De specifieke route naar het eindresultaat is helder geworden en de wensen worden dan ook nauwkeuriger gedefinieerd. Met deze nieuwe informatie wordt de oplossing aangepast en verbeterd voor een vervolg demonstratie of zelfs een (eerste) versie van het eindproduct.

Waar wel voor gewaakt moet worden is dat de instellingen die keihard in de code bewaard zijn configureerbaar worden. Ook de bouwstenen zullen opnieuw moeten worden geïnspecteerd. Daarnaast is het van belang dat de specifieke route naar het eindresultaat, inclusief de creativiteit en innovatie die gebruikt is bij het opzetten van de 'quick-and-dirty'-oplossing, gedocumenteerd wordt. De (potentiële) klant geeft bijvoorbeeld aan waar flexibiliteit moet bestaan voor het gebruik van variabelen in tegenstelling tot harde code. De snelheid van 'quick-and-dirty' wordt in deze fase vervangen door kwaliteit. Deze modificatie neemt echter meer ontwikkeltijd in beslag en dat moet de (potentiële) klant wel duidelijk gemaakt worden. Tenzij de (potentiële) klant kan leven met weinig flexibiliteit in de toekomst en intensieve onderhoudskosten van de oplossing.

'Quick-and-dirty' is ideaal voor een simpele demonstratie aan (potentiële) klanten, maar het is uiteraard niet de fraaiste aanpak. Het is tegen alle principes in voor het ontwikkelen van een degelijke oplossing. Maar om de (potentiële) klanten te kunnen overtuigen van de aangeboden oplossing kan dit wel noodzakelijk zijn.

Uiteraard is dit een ideale uitgangspunt voor het binnenhalen van een opdracht en kunnen we deze methode wel een keer door de vingers zien, want wat voor de (potentiële) klant doorgaans geldt: eerst zien, dan geloven!

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4543496). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Ik mis om te beginnen een duidelijk standpunt over de mate waarin de auteur “quick & dirty” nu wel of niet acceptabel vindt. Moet ik mij zorgen maken als ik hem vanuit een klantrol als technisch consultant tegenkom? Doet hij hier een uitspraak over de sales mensen van Unisys? Ik ken genoeg sales mensen die heel veel tijd (willen) investeren in het ontwikkelen van een voor alle partijen goede deal.

Een deel van de problematiek van “te snelle Sales” kun je voorkomen met een duidelijke werkafspraak over de “handshake” tussen Sales en Delivery (productie in goed NL). Betrek de operatie bij een bid/ no bid beslissing, maak intern duidelijk welke eisen je als operatie stelt en betrek een “productiemedewerker” bij het verkooptraject. Daarnaast zou ik Sales bij eventuele moeilijkheden later in het traject een rol geven om e.e.a. te repareren. Vaak heeft Sales (gelukkig) ook een relatiefunctie naast een verkoopfunctie. Ja, wellicht moeten persoonlijke targets van die nare verkopers hiermee wel in evenwicht zijn.

Tot slot vind ik de in de eerste alinea beschreven stap van “we scoren een snelle deal…” naar “…en dat leidt tot slechte specificaties” wel een hele grote. Volgens mij heeft de klant daar (ook) een verantwoordelijkheid in en kunnen deals met een lang intern voortraject bij de klant (incl. goede specificaties) juist prima in een korte offertefase worden beklonken.

In goed Nederlands gaat het in het artikel om een PoC (Proof of Concept).

Tja er is niets zo definitief als een tijdelijke oplossing, dus als afnemer is het verstandig om standaard acceptatie criteria te definieren waaraan elk opgeleverd product getoetst kan worden op functionele en non-functionele eisen.

Want uiteindelijk gaan makkelijk 60% van de kosten van dit soort oplossingen op aan beheer, en niet aan de ontwikkeling.
(bron: https://eight2late.wordpress.com/2009/07/16/maintenance-matters/)

Verloop in sales afdelingen is groot. ICT sales personen, de goeie hierbuiten gelaten, hebben meestal geen verstand van ICT of de business van de klant en dan komt een salespersoon als snel met meerdere consultants langs om te kijken of zij een oplossing kunnen verkopen aan de klant. De behoefte van de klant staat vaak niet centraal, er wordt gewerkt vanuit een (standaard) aanbod en omdat de klant niet kan specificeren wat zij wil krijg je een mismatch en dan ontstaat twijfel en krijg je Proof of Concepts, Pilots, tijdelijke implementaties en nog meer ellende.

ICT leveranciers zouden moeten beginnen met eerst hun eigen competenties goed op een rijtje te zetten en vervolgens bij klanten aan moeten geven waar ze goed in zijn en vooral waar ze niet goed in zijn. Vervolgens moet je als leverancier investeren in de klant en de oplossing, dit doe je alleen maar als er vanuit beide kanten vertrouwen ontstaat.

Pas dan ontstaat partnership en dan is eerst zien en dan geloven niet meer zo nodig, er is immers een gelijkwaardig belang ontstaan.

Het verhaal van de schrijver geeft mij geen vertrouwen, quick en dirty oplossingen zijn niet meer van deze tijd.

Mij lijkt een quick en Dirty oplossing nooit acceptabel. Ik kom te vaak tegen dat dit al snel tot problemen leid.
De uiteindelijke implelemtatie loopt niet lekker omdat de eindsituatie net even anders is dan de ontwikkelomgeving, de klant wil net even iets anders, of iets erbij/eraf.
Maar vooral het eindresultaat is niet meer onderhoudbaar, kom dit soort elende maar al te vaak tegen, een zeer grote zeer bekende firma stelt 'if it compiles, ship it'
Wellicht moeten ICT leveranciers (ontwikkelaars of implementatie specialisten) gewoon eerst eens afvragen of de klant uiteindelijk wel gebaat is met het resultaat, en wellicht moet de klant eens afvragen of de gemaakte keuze wel is waar het bedrijf mee gebaat is.
Stap dus eens af van die prefered supplier onzin en 'de goedkoopste leverancier' waanzin.
Helaas is het natuurlijk zo dat beide partijen vaak niet goed op de hoogte zijn van de wensen dan wel de niche maar ohhh zo belangrijke technische kwalificaties die vereist worden.

Het is een feit dat de collega`s van Sales hun target willen behalen. Maar dat kan geen kwaad zijn! Als de organisatie met een PoC een project binnen wil halen dan zou al het maken van de betreffende PoC, modulair binnen de unit geregeld moeten zijn. Daar bovenop zou een laag moeten komen van “klant specifieke configuratie” die deze PoC geschikt maakt voor deze klant. De kosten van verder aanpassing (inclusief het Functioneel Ontwerp)kunnen in een offerte aan de klant voorgelegd worden.
Het lijkt me inefficiënt als voor elke aanvraag vanaf het begin iets ontworpen moet worden. Gelukkig zijn er genoeg oplossingen die de stappen van bouwproces geautomatiseerd kunnen maken.

Wat ik van Agile/Scrum weet en ervaren heb, lost dit het hele probleem waar het de schrijver het over heeft op : PoC + kwaliteit vs snelheid vs verschuivende requirements vs planning vs communicatie klant.

Kan nog van alles misgaan, maar das dan door klant die niet meewerkt of niet goed toepassen Agile en communicatie naar klant door eigen club.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×