Zoek:
Webwinkels Webwinkel Marketing Webwinkel design Webwinkels in de praktijk Webwinkel SEO Handige links
  Home > Webwinkels > De valkuilen bij software ontwikkeling

De valkuilen bij software ontwikkeling

U heeft een uniek idee, een aanpassing of nieuwe module voor uw webwinkel, of gaat een traject in om een geheel eigen applicatie te laten ontwikkelen. Wanneer u weinig of geen ervaring heeft met dergelijke ontwikkelingen, ga er vanuit dat dit bijna nooit echt soepel zal gaan lopen. Sterker nog: 80% van alle nieuwe ontwikkelingen lopen uit in tijd en geld, zeker als deze wat complexer zijn.

Dit heeft te maken met meerdere factoren  en wij hopen u met onderstaand voor een aantal te kunnen behoeden en u te wijzen op andere dingen die meespelen.

  1. Communicatie
  2. Concept goedkeuring: functioneel design
  3. Prijs
  4. Tussentijdse aanpassingen en aanvullingen
  5. Tijdschema's
  6. Uitvoerende partijen
  7. Eigendomsrecht
  8. Verantwoordelijkheid en aftersales

 

1) Communicatie

Het allerbelangrijkste en tevens de moeilijkste: communicatie

U heeft een idee  en wilt dat uitgevoerd hebben. Een groot deel van de uitvoering wilt u in handen leggen van uw programmeur of webdesigner. Zij zijn tenslotte de professionals  en daar betaalt u ze voor en zullen vast wel weten wat ze moeten doen. Dit is de grootste fout die u kunt maken en zorgt ervoor dat projecten niet naar wens opgeleverd worden, of zullen uitlopen.

Praktijkvoorbeeld, deze week ontving ik de vraag van een klant die graag een cadeaubon wilde integreren in zijn webwinkel, of ik daar een prijs voor wilde maken. Op zich een prima idee, dus ging ik verder vragen wat en hoe hij het voor zich zag.. " Gewoon een cadeaubon, dat hoeft toch niet zo moeilijk te zijn ?" 

De basis van een cadeaubonsysteem is inderdaad relatief simpel, je voert een unieke code in, deze is gerelateerd aan een bedrag, welke afgetrokken wordt in de kassa pagina. Daarnaast zal je nog wat aandacht moeten vestigen op het ' hufterproof' maken van het systeem, want al is het virtueel geld, we praten wel over echte euro's.

Maar waarover mijn klant niet  had nagedacht , hoe wilt hij deze cadeaubonnen verspreiden  en zo wees ik hem op een paar mogelijkheden...

  • Als product verkopen in de shop en deze kan uw klant schenken aan een ander?
  • Blijft deze digitaal, of stuur je een pasje op met de code?
  • Handmatig cadeaubon aanmaken en deze versturen per email?
  • Automatisch cadeaubonnen aanmaken+ versturen wanneer een klant jarig is? Zo ja, zijn er hier nog regels voor (klant moet afgelopen jaar iets gekocht hebben met een minimaal bedrag?)
  • Moet het mogelijk zijn om de cadeaubonnen ook buiten de eigen shop aan te bieden zoals verkoop via andere websites?
  • Fysieke cadeaubonnen die je bijvoorbeeld in een filiaal kunt kopen bij Halfords of Albert Heijn?
  • Moet er een optie vermeld worden voor het ' verlopen' van een cadeaubon?
  • Moet dit in eigen beheer blijven, of via een externe partij, gespecialiseerd in cadeaubonnen, waarmee de cadeaubonnen  breder inzetbaar zijn?
  • Zijn de cadeaubonnen algemeen inzetbaar, of zijn deze heel klantspecifiek?


En er zullen nog wel veel meer toepassingen en opties te bedenken zijn...
Al deze mogelijkheden bepalen of de opdracht eenvoudig uit te voeren is, of een redelijke impact zal hebben op verschillende onderdelen van de webwinkel.

Conclusie: des te duidelijker uw brieving naar uw uitvoerend partner, des te minder vragen er zijn.
Denk uw gewenste concept goed door, van A tot Z, voor u de vraag aan uw programmeur / webdesigner voorlegt.
Uw programmeur zal ongetwijfeld u nog kunnen wijzen op een aantal andere punten van aandacht en zo kunt  u samen sparrend tot het beste concept komen.


Dit heeft niets te maken met het vermogen of inzicht van de uitvoerende persoon, maar wel het feit dat inzichten kunnen verschillen.
Des te meer u op een lijn ligt, des te groter de kans is dat het traject soepeler verloopt..

 

2) Concept goedkeuring: functioneel design

 

Nu bekend is wat er gemaakt moet worden, zorg dat er een functioneel design gemaakt wordt.
Het functionele design is een gedetailleerde omschrijving van alle mogelijkheden, functies en workflows.

Vaak wordt de omschrijving ook vergezeld met grafische (schematische) interface opzetten, die een hoop kunnen verduidelijken. Voor u akkoord gaat met het gemaakte voorstel, probeer elke stap te visualiseren, wat de functionaliteit doet en welke impact dat heeft  en waar het mogelijk alsnog fout kan gaan.

Het is niet uw core-business en is het mogelijk lastig om iets te beoordelen wat nog heel abstract lijkt, maar neem hier de tijd voor en vink elke functie stap voor stap af, tot u tevreden bent met het concept. Dit concept zal de basis worden waarop de prijs gebaseerd wordt en is de blauwdruk voor de programmeurs.

Denk ook net een stapje verder dan alleen de gevraagde basisfunctionaliteit. Bijvoorbeeld: behoort een ' zoekfunctie'  in de categorie ' toeters en bellen'  of zal dit na 1000en cadeaubonnen uitgegeven te hebben ,een belangrijke toegevoegde waarde krijgen? Moet er een pagina overzicht splitsing komen? Of koppelingen in het adresbestand? Dit soort functionaliteiten zullen belangrijk zijn, wil een systeem prettig werkbaar worden, maar zullen een prijs doen stijgen.

 

3) Prijs

U heeft akkoord gegeven voor het functionele design  en vervolgens kan de uitvoerende partij een ureninschatting en een offerte maken. De prijzen die geboden worden, kunnen verschillen per aanbieder. Dit kan te maken hebben met de overhead, hoe succesvol de naam is van een bedrijf en bijbehorende uurlonen, hoe de software wordt opgebouwd (deels van bestaande projecten, of op basis van opensource software) maar ook wat er uiteindelijk geboden wordt.  Vergelijk geen appels met peren door alleen onder de streep te kijken, maar kijk ook wat er inhoudelijk geboden wordt, hoe sluit het bedrijf zich aan bij uw behoeftes op langere termijn. Bij grotere projecten, vraag zeker een second opninion, indien u niet geheel bekend bent met de termen en prijzen...

De goedkoopste aanbieder hoeft niet direct uw beste optie te zijn...

Prijsstijgingen
Bij de ontwikkeling van een nieuwe applicatie heb je altijd kans dat er factoren om de hoek komen kijken waar niemand rekening mee gehouden heeft. 

Technische factoren, bijvoorbeeld tijdens de ontwikkeling van uw applicatie komt Internet Explorer versie 9 uit en die blijkt de gekozen techniek niet meer te ondersteunen. Of - wat ik zelf heb meegemaakt - is dat taxiritten per email bevestigd moesten worden, maar toen bleek dat op de taxicentrales de operators alleen maar emails mochten ontvangen  en niet versturen, dus zo ook niet konden bevestigen.

Dit zijn onvoorziene factoren, die je niet naar alle redelijkheid kunt afschuiven op de ontwikkelaar en kunnen zorgen voor meerwerk, buiten het plan waarop de prijs gebaseerd is.

Nieuwe dingen ontwikkelen kost nou eenmaal tijd en (goede) programmeurs zijn niet heel goedkoop in Nederland. Houdt er rekening mee dat uw ideeën altijd een investering vragen.

Return of Investment (ROI)
Nu u een prijs(indicatie) weet voor de ontwikkeling, probeer nu ook  de ' break even point'  te berekenen voor uw investering.
Hoeveel bezoekers heeft u nodig, wat moeten zij gemiddeld uitgeven, wat is dan uw brutowinst, wilt u deze ontwikkeling winstgevend maken. Hoe komt u aan deze bezoekers en hoeveel extra geld moet u investeren om deze binnen te halen? Wat is een realistisch haalbare termijn hiervoor?

Ik heb helaas vaker mee gemaakt bij starters dat hier niet serieus over nagedacht werd en vanuit een 'onderbuikgevoel'  gerekend  werd. Verblind door het mogelijke succes van hun unieke applicatie, wil men snel vergeten dat jouw miljoenenpubliek je wel moet weten te vinden en dat  dit ook tijd en de nodige euro's kost. Neem dit altijd mee in de berekening, dit zijn serieuze kosten.

 

4) Tussentijdse aanpassingen en aanvullingen

Het ontwikkelstraject is van start gegaan, of heeft even rust en de inspiratie begint te borrelen!
Ineens ziet u allerlei nieuwe toepassingen, verbeteringen en functionaliteiten voor u  en vraagt de programmeur om dit ook te verwerken. De programmeur wilt u natuurlijk zo goed mogelijk van dienst zijn en voert al uw wensen uit.

En dan komt de eindrekening.. ouch dat is schrikken! Maar dat hadden we niet afgesproken....

Voorkom tijdens de ontwikkeling dat u gaat afwijken van het functionele plan. Hierop is de prijs gebaseerd en dit is afgesproken om uitgevoerd te worden. Tenzij de aanpassingen benodigd zijn voor een goede werking, verzamel deze wensen en plaats deze in  een vervolgopdracht en ga dan weer terug naar stap 1
Het is niet alleen het meerwerk wat er uit voortvloeit, maar ook wanneer de uitvoerende persoon met regelmaat moet overschakelen om nieuwe dingen te bespreken en zijn plan moet wijzigen, zal het ook zijn ineffectiviteit beinvloeden. (en dus uitloop van een project)

 

5) Tijdschema's

Bij een gemiddeld intake-gesprek grijp ik vaak terug op een regeltje: Goed | Goedkoop | Snel
Selecteer 2 woorden uit de regel en plaats voor het overgebleven woord ' niet'  voor.. Je krijgt dan deze oplossingen:

Goed + Goedkoop = Niet Snel
Goed + Snel = Niet goedkoop
Goedkoop + Snel = Niet Goed

Houd altijd rekening met mogelijke  uitloop van projecten. Wanneer uw project in Augustus af moet zijn, vanwege een geplande mediacampagne, zorg dan dat de deadline voor oplevering in Juni is. (afhankelijk van de complexiteit van uw project natuurlijk)
Het is menselijk dat je naar een deadline toewerkt, maar als je te weinig tijd tussen oplevering en ultime deadline hebt, heb je geen kans meer om calamiteiten op te vangen.

Doe tijdig uw huiswerk
U verlangt van uw opdrachtnemer dat deze de werkzaamheden volgens planning uitwerkt. Het is ook mogelijk dat de opdrachtnemer ook van u informatie verlangt  en duidelijke keuzes wilt horen als " kiezen we voor optie A of B?"  Zorgt dat u ook op tijd de juiste en duidelijke feedback geeft en uw huiswerk doet, want anders kan een planning veranderen, of worden op eigen initiatief mogelijk zelf keuzes gemaakt door de opdrachtnemer (want die moet door) waar u naderhand liever toch anders had willen hebben, met gevolg uitloop.

Dit klinkt een beetje ' belerend', maar dit zijn wel praktijksituaties die dagelijks voorkomen. Ondanks uw goede wil, krijgt u tussendoor ineens een grote klant die alle aandacht opslokt en dan moet al het andere even wachten.... Met gevolg dat de ontwikkelaars in afwachting zijn om verder te kunnen...

6) Uitvoerende partijen

Wellicht heeft u al een uitvoerend partner in gedachte. En anders heeft u de keuze uit verschillende opties..
Vaak hebben aanbieders een portofolio van klanten of projecten op hun website staan. Schroom niet om informatie op te vragen bij hun klanten, hoe zij de uitvoerende partij ervaren hebben. Daarnaast gebruik uw intuïtie en gezonde verstand voor de beste keuze.

Freelancers / kleine ondernemers
Deze groep zijn de kleine zelfstandigen, die genoeg vertrouwen hebben in hun kunnen en in hun kwaliteiten, om voor zichzelf te beginnen.
Wanneer u een freelancer aanneemt voor een project, heeft u als voordeel dat u één aanspreekpunt heeft, te maken heeft met een gemotiveerd persoon en die waarschijnlijk ook nog wat in huis heeft. Ook kenmerkend is vaak de flexibiliteit en het meedenken in een project.  Gezien de overhead klein is, kunnen zij een project vaak tegen concurrerende prijzen aannemen. En heeft u geen werk meer voor de freelancer, dan stopt de overeenkomst  en heeft u geen extra kosten meer.

Het gebruik van freelancers heeft wel als nadeel, dat alle kennis ook bij 1 persoon berust. Mocht deze freelancer u niet bevallen, of langdurig ziek worden, moet deze kennis opnieuw opgebouwd worden bij de volgende freelancer.
Uit eigen ervaring wil ik u adviseren, tenzij u de freelancer 100% vertrouwt, maak duidelijke afspraken qua oplevering en kosten... Blijf nauw betrokken bij de ontwikkelingen en controleer deze, mocht u een nieuwe freelancer aannemen...

IT bureaus
IT bureaus hebben vaak meerdere programmeurs in dienst, van startende tot senior programmeurs.
Dit heeft als voordeel dat zij sneller kunnen opleveren tov een freelancer en als zij taken onderling verdelen, dat de kennis van uw project  verdeeld is over meerdere personen  en zo uw project minder kwetsbaar is voor verdere ontwikkelingen. Nadeel is wel, u krijgt een accountmanager, de secretaresse neemt de telefoon aan, ze zitten in een mooi kantoorpand, en de auto van de directeur moet ook betaald worden en hierdoor zal hun offerte waarschijnlijk een stukje duurder uit de bus komen.  U krijgt er dan wel meer zekerheid voor terug. (al zijn er genoeg voorbeelden waar ontwikkelingen niet zo vlekkeloos zijn gegaan...)

Outsourcing
Sinds een paar jaar is er een nieuw begrip: outsourcing.
Nederlandse programmeurs zijn prijzig, terwijl de lonen in India, Rusland en Hongarije een heel stukje lager liggen.
Er zijn bedrijven die Nederlandse managers op uw project zetten, maar dat lokaal in Polen uitbesteden.
In plaats van uurlonen van € 70,-, betaald u slechts €30 of zelfs €20 euro per uur.

Persoonlijk heb ik er een negative ervaring mee (wat zeg ik ,door hun fouten had het mij bijna mijn klant gekost) , maar dat wil niets zeggen over de algemene kwaliteit van de geboden programmeurs en hun managers.

Bij outsourcing kan wel de taal een bron van communicatiestoornissen  zijn, mogelijk is Pools niet uw moedertaal en aan de andere kant zal hun Engels mogelijk ook niet optimaal zijn. Ook dingen als " dat lijkt mij toch logisch!" blijken in de praktijk niet zo logisch te zijn... Een Nederlandstalige manager als tussenpersoon is vaak de oplossing, maar hierdoor kan een boodschap ook niet altijd volledig doorkomen.

Wanneer u in zee gaat met een outsourcingbureau, kunt u tegen lagere kosten veel bereiken, maar dit kan wel ten koste gaan van uw rust. Elke gewenste stap zal u in detail moeten uitleggen, controleren en begeleiden. 

Er zullen ongetwijfeld outsourcing bureaus zijn die het wel goed voor elkaar hebben, maar persoonlijk betaal ik toch liever wat meer aan een programmeur die mij met een half woord begrijpt...

 

7) Eigendomsrecht

Een eeuwige discussie is rond de eigendomsrechten na de gedane ontwikkeling. Wie is nou de eigenaar van de code, wie bezit de copyright? Bespreek dit vooraf goed door en zet gemaakte afspraken op papier.

Een denkwijze die bijna altijd wordt aangenomen: Ik betaal voor de ontwikkeling, dus ik ben eigenaar!
Fout!
Althans, bij veel IT bedrijven zal deze regel gelden. U betaalt uiteindelijk voor de uitgevoerde diensten en uren, niet voor het uiteindelijke product & code en opgedane kennis uit het verleden. Met deze geleverde diensten verlenen zij u daarintegen een gebruikerslicentie waarmee u ' onbeperkt'  gebruik mag maken van het resultaat.

Ja maar, als ik een brood koop bij de bakker, dan mag ik toch zelf bepalen of ik het zelf opeet, of het aan de eendjes voer?
Dit werkt precies zo: u koopt in dit geval het brood, maar niet het recept om het brood na te mogen maken....

Ik kan mij voorstellen dat dit krom lijkt en mogelijk ook krom is, dus lees vooraf de algemene voorwaarden goed door van uw uitvoerende partij. Deze copyright is zelfs wettelijk bepaald en valt onder de auteurswet. Net de schrijver van een boek automatisch de copyright heeft over zijn werk, zo geld dat ook voor de ontwikkelaar..

Naast deze wettelijke copyright, spelen er ook de volgende factoren mee:

  • Zij willen u graag als klant houden en dit is een perfecte manier om te voorkomen dat u overstapt.(en u uw investering kwijt bent)
  • Het kan zijn dat zij opgedane kennis, codes en werkzaamheden uit een ander project verwerken in uw project en deze niet (volledig) hebben doorberekend.
  • Gezien de ontwikkelaar verantwoordelijk is voor het gemaakte systeem, staat deze niet toe dat derden aan de code rommelen, gezien daarmee de verantwoordelijkheid vervalt.
  • Daarnaast gebruikt de ontwikkelaar mogelijke technieken, waarbij hij veel eigen tijd en geld gespendeerd heeft, die hij niet graag in handen van zijn concurrenten wil leggen
  • In het verleden is er veel geld gespendeerd om het kennisniveau op peil te krijgen en daar betaalt u niet (direct) aan mee.
  • Het kan een uitbreiding zijn op de basis van een eigen systeem en zo zal uw eigen aanvulling mogelijk niet standalone kunnen draaien
  • Wanneer zij de copyright  geven aan u, wilt dit zeggen dat zij NIETS mogen hergebruiken uit de gemaakte codes, zonder uw toestemming. Zouden zij een algemeen uploadscript willen gebruiken voor een ander project, zouden ze dat dan verplicht opnieuw moeten maken.
  • commercieel oogpunt, wilt u dezelfde code voor iets anders gebruiken, buiten de oorspronkelijke opdracht, kunnen zij weer de werkzaamheden of een nieuwe gebruikerslicentie berekenen

Er zijn zeker wel mogelijkheden om de copyright te bemachtigen, voor u als de betalende opdrachtgever, echter deze voorwaarde zult u vooraf schriftelijk moeten vastleggen. Reken er op dat de prijs die u dan betaalt niet in verhouding staat indien u de werkzaamheden zonder eigendomsrecht zou laten uitvoeren.

Wat wel slim kan zijn is zowiezo een aantal clausules in een contract te laten verwerken, mocht de ontwikkelaar zijn werkzaamheden niet meer kunnen of willen voortzetten, dat u alsnog eigenaar wordt van de code. En is uw idee zo uniek en veel belovend, dat de ontwikkelaar geen spinoff mag maken van het script voor uw concurrenten.

 

8) Verantwoordelijkheid en aftersales

Na oplevering zullen er ongetwijfeld nog wat kinderziektes optreden. Zeker bij complexe systemen, is dit meer een regel dan uitzondering. Bespreek goed wie verantwoordelijk is voor deze kinderziektes, afgezien van onvoorziene factoren.

Vaak wordt er een ' bugfix periode' afgesproken van bijv 3 maanden na officiële oplevering. Maar wat als er in de vierde maand een kinderziekte naar voren komt? Uw standpunt is dan, " ja maar dit is gewoon niet goed geprogrammeerd" terwijl de ontwikkelaar verwijst naar de 3 maanden periode..

Het lastige is, deze kinderziektes komen pas aan het licht nadat uw applicatie  door breed publiek gebruikt wordt. (en bezoekers dingen doen zoals ze niet bedoeld en getest zijn). Spreek goed af met de ontwikkelaar hoe hiermee om te gaan...

Lees ook de kleine lettertjes betreffende aansprakelijkheid, mocht het toch mis gaan. Naast dat je wel een snelle bugfix mag verwachten, zullen alle software ontwikkelaars zich indekken dat zij niet aansprakelijk gehouden mogen worden voor eventuele schade, veroorzaakt door hun programmatuur.

Stel, per ongeluk verstuurt het zojuist opgeleverde cadeaubonsysteem naar 2000 klanten automatisch een cadeaubon van € 100,-.... Ouch....  Op zich wel een manier om wat extra media aandacht te genereren, maar ik kan mij voorstellen dat u er niet vrolijker van wordt,,,

U mag niet verwachten dat uw ontwikkelaar levenslang garantie geeft op uw applicatie en zodat u nooit meer een euro hieraan hoeft te spenderen. Aanpassingen en onderhoud zullen  altijd nodig zijn. De wereld om uw applicatie heen, denk aan webservers, beveiliging , besturingssoftware, programmeer technieken, nieuwe browsers, zoekmachines etc, veranderen in sneltreinvaart en daar zal op een gegeven moment uw applicatie mee moeten veranderen. Ook het grote succes van uw applicatie kan hierin meespelen.

 

 


Als website ontwikkelaar heb ik afgelopen 10 jaar ook het nodige custommade werk ontwikkeld en ja, ook ik heb mijn 'leer momenten' gehad.. :-)

Mocht u op dit moment betrokken zijn bij een dergelijke ontwikkeling, of een voorstel op uw bureau hebben liggen, schroom niet om daar iemand anders met een frisse blik er na te laten kijken.  Mocht u twijfels hebben over de geboden prijs of functionaliteit, staan wij  altijd open om objectief een second opinion te geven.

 



Artikelen
1400 nieuwe domeinnaam extenties (TLD's)
Cookie wetgeving
Webwinkel SEO checklist
Klanten uitschelden is goed voor de business
Wees niet bang voor de mening van uw klant
Webhosting kan goedkoper, maar wilt u dat ook?
Wat is uw doel van uw webwinkel?
De valkuilen bij software ontwikkeling
De zwakste schakel in beveiliging van een webwinkel
Onveilige webwinkels
Keuze van uw webwinkel
Wel of niet aansluiten bij een keurmerk?

Categorieen
Webwinkels Webwinkel Marketing Webwinkel design Webwinkels in de praktijk Webwinkel SEO Handige links

Links
Over ons
Eblocks Ecommerce
Art Digital