Twijfel over kwaliteit internetsite-bouwers

[alterEwo]

Goedenmiddag,

 

Graag jullie mening over het volgende wat ik nu in mijn werk tegenkom. Ik ben adviseur op marketinggebied. Ik weet wat over de "buitenkant" van internet sites, maar over verdere techniek weet ik te weinig.

 

De achtergrond : mijn klant is een kleine bank, die graag financiele producten online wil verkopen. Klanten moeten dit zonder tussenkomst zelfstandig kunnen doen. Er is goed over nagedacht en de interne IT-club kreeg de opdracht om het geheel van mainframe tot en met website te maken.

 

Maar al snel kreeg ik een wat ongemakkelijk gevoel : men bleek bij eerdere websites gewoon jpeg's in een site geplakt te hebben, ipv stylesheets te gebruiken. Flash was niet mogelijk, ivm beveiliging - totdat we hier druk op zetten, toen bleken een vorm van rich internet toch wel mogelijk. Deadlines werden gehaald, maar het werk bleek op de achtergrond toch nog niet helemaal klaar te zijn.

 

Mijn vraag : we zijn nu 6 maanden bezig om de site van de grond te krijgen en het eerste product gaan (hopelijk !) pas "life" na 7 maanden.

Ik vraag mij serieus af of dit niet veel te lang is.

 

In deze tijd hebben we gedacht over de site, de opzet, het design gemaakt, hebben we een goed framework gemaakt voor de site en hebben we ook gekeken naar usability. We hebben een protoype gebouwd. Wel gezegd moet worden dat tijdens de rit een aantal (grotere) nieuwe inzichten er alsnog in moesten, wat de oplevering natuurlijk niet ten goede kwam.

 

N.B. : het is wel een structurele site : men wil geen makkelijke, oppervlakkige oplossing waar ze achter de site met veel handwerk de overeenkomsten moeten inkloppen. Nee : er wordt direct uitgewisseld met het mainframe van de bank. Daartussen in zit nog een midoffice tussenlaag, die er voor zorgt dat er goede berichtenuitwisseling tussen het frontoffice en backoffice plaatsvindt.

 

Ik begrijp dat ik nog maar ruw de situatie schets, maar kunnen jullie mij een gevoel geven hoe lang het duurt voor je zo'n goede, structurele site hebt opgezet ?

[Sanne Roemen]

Hoi.

Ik herken je verhaal. Het gebeurt vaak dat bedrijven een interne IT afdeling inzetten voor de bouw van geavanceerde applicaties (al dan niet web-based). Terwijl die IT afdeling vaak meer gericht is op beheer en uitbouw van bestaande systeemen. Dat is een heel ander kopje thee dan ontwerp en ontwikkeling, grafisch, technisch.

Vaak moet voor die nieuwe systemen gebruik gemaakt worden van up -to- date technieken. Bijvoorbeeld Flash in combinatie met PHP, Linux, PostgreSQL, XML en CSS. Daar kan tegenwoordig heel veel mee, maar bestaande IT afdelingen zijn meestal niet dagelijks bezig met het bijhouden van deze ontwikkelingen maar met de bestaande IT omgeving. Als wat jij hier beschrijft werkend wordt opgeleverd, het is gebruiksvriendelijk en toegankelijk, en er wordt door de klanten gebruik van gemaakt, dan PETJE AF!! De IT afdeling heeft dan kennelijk haar grenzen verlegd.

 

Als je vraag alleen de tijdsduur betreft: moeilijk in te schatten, ik vind een half jaar niet zo heel gek, vooral als de afdeling daarnaast ook nog belast is met beheer van de bestaande systemen. Daarnaast doen 'interne' deadlines vaak niet zoveel 'pijn' als externe deadlines. Ik bedoel als een externe leverancier een deadline opgelegd krijgt, dat die dan vaak wat zwaarder weegt dan bij een interne afdeling.

 

Ik hoop dat ik je hiermee enigszins helderheid heb verschaft?

 

[alterEwo]

Oomph,

 

Zeker en inderdaad : de dingen die je schrijft herken ik ook ! Mijn angst is alleen het laatste deel : als het ze lukt, dan petje af. Ik ben o.a. bang dat ze tot in het eind der tijden bezig zijn om loshangende draadjes weg te werken. :P

[Sanne Roemen]

Ik begrijp. Dan sta je lichtelijk machteloos want als zij zeggen dat het nog niet in orde is met de koppeling backoffice - frontoffice of met beveiliging of weet ik wat niet, dan moet je dat maar van ze aannemen. Ik ken het gevoel. Kennis is macht in dezen.

 

Je zou een pilot kunnen afdwingen en die door professionals kunnen laten beoordelen. Is afgesproken wanneer het systeem 'af' te noemen is? In mijn ervaring is iets namelijk nooit af, kan het altijd netter en beter, maar is er wel een punt aan te wijzen dat het 'live' kan gaan of in ieder geval als pilot getest kan worden. Ik zou dan in ieder geval de documentatie en de datadictionary laten beoordelen, en een werkende versie van het systeem. En wel door een representatieve gebruiker en een externe techneut (minstens).

 

Ik neem aan dat het management er alle belang bij heeft dat een en ander zo snel mogelijk werkelijk ingezet kan worden. Ook zij hebben echter te maken met de 'kennis is macht' frustratie. Maar als er ergens een externe partij is die met gezag kan zeggen 'kan niet bestaat niet', een beetje zoals jij hebt gedaan toen ze met jpg-jes in plaats van css aan kwamen zetten, kan het gebeuren dat je iets openbreekt. De klant zal ook wel gevoelig zijn voor de budgettaire druk die misschien inmiddels aan het ontstaan is?

 

[Jacco1]

Ik ben het met bovenstaande reacties eens. De moderne insteek is eigenlijk: alles kan, maar wat wil je eigenlijk? Die vraag is ook een manier van vaststellen wanneer iets af is.

 

Heet hangijzer is over het algemeen de koppeling van verschillende systemen (bijv. website-mainframe). Dat is complex en schiet er vaak bij in. Dus petje af als ze iets moois kunnen opleveren!

[R.I.P. | Peter Bonjernoor]

Ik vraag mij serieus af of dit niet veel te lang is.

 

Het is natuurlijk moeilijk om hier zonder veel details een uitspraak over te doen, maar ik vermoed van wel.

 

Het gaat immers om bestaande produkten die op een andere manier ingevoerd moeten worden - niet door het call-center of zo, maar door de klant zelf. Daar zul je wat extra uitleg en dergelijke bij moeten bouwen, en wat business rules in moeten verwerken, maar verder is het niet veel meer dan een ander invulformulier dan het bestaande.

 

Wat je er niet bij vermeldt is of ze ook de mogelijkheid om zaken in het mainframe ni te lezen erbij moesten maken, of dat ze gewoon op afstand de database konden benaderen. Dat kan nog wat schelen, maar 7 maanden blijft me teveel lijken.

[willemj]

Ik herken de situatie van de andere kant (als techneut) 'Even' communiceren met het mainframe gaat werken als de documentatie van dat mainframe 100% in orde is en je de kennis in de vingers hebt. Maar wijkt de documentatie maar 0,1% af (of jouw intrepetatie daarvan) dan gaat het mis.

 

Voorbeeld wat ik van de week had (op een wat kleinere schaal): ik stuur informatie van een webpagina naar de server in een bepaald formaat. In die informatie zat op een gegeven moment een verkeerd karakter waardoor m'n server 'crashte' met een foutmelding die ongeveer zoveel informatie gaf als 'ik snap het niet meer'. Anderhalf uur lezen en speuren later was het probleem opgelost. Een functie die 5 minuten had moeten duren kostte me dus anderhalf uur.

 

In dit voorbeeld had ik controle over alle onderdelen (webbrowser, netwerk, server), had ik redelijk diepe kennis van alle techniek en was het probleem dus vrij snel op te sporen. Doet eenzelfde soort probleem zich voor bij een mainframe van een bank waar je als ontwikkelaar geen toegang of diepgaande kennis van hebt (die heb je vaak ook niet nodig om het te kunnen gebruiken) dan kan het snel lang gaan duren. Testen, probleem omschrijving maken, versturen naar support afdeling van de maker van de mainframe, een week wachten op antwoord, nieuwe testcase etc etc. Als het probleem een showstopper is voor de doorgang van je project dan kan iets wat een dag moet duren dus snel uitlopen naar een week of meer.

 

Kortom: geen idee of het te lang is ;) Ik weet wel dat (complexe) techniek af toe tot onverwachte vertraging kan leiden. Oplossing is een goede projectleider en creatieve techneuten die noodverbandjes kunnen aanbrengen om van showstoppers technische problemen te maken die later opgelost kunnen worden.

[mediabattery.com]

Een lastig verhaal, alterEwo. Ik vind het moeilijk om er inhoudelijk op in te gaan, omdat ik niet precies weet waar het mis gaat, wat er achter de schermen mogelijk moet zijn en hoe de bouwers de problemen interpreteren.

 

Wat ik wél weet, is dat het vaak mis gaat bij een gebrekkige briefing. Ik wil niet zeggen dat dat bij jullie is misgegaan, ook daar kan ik niet over oordelen. Als een briefing niet uitgebreid genoeg is, weten de bouwers niet voldoende wat er van ze verwacht wordt en heeft de opdrachtgever niets om de kwaliteit aan te toetsen. Natuurlijk krijg je gedurende het ontwikkelproces nieuwe ideeën en inzichten, waardoor de looptijd van het project langer kan uitvallen. Ik vind het de verantwoordelijkheid van de bouwer om de opdrachtgever voor te lichten over de gevolgen hiervan, zodat je als opdrachtgever nooit voor onaangename verrassingen komt staan.

 

Ik kan me voorstellen dat de bouwers-in-tijdnood gekozen hebben voor een paar tijdelijke oplossingen, om het testen van de applicatie mogelijk te maken. Wederom vind ik dat de bouwers je daar voldoende van op de hoogte hadden moeten brengen.

 

Ik heb de volgende tip: Ga om de tafel zitten met de bouwers en bespreek kort en bondig 1) waar jullie nu staan, 2) wat er nog moet gebeuren om een live product af te leveren en 3) binnen welk tijdsbestek dat gaat gebeuren. Indien nodig, vraag ze zelf of ze van jouw kant iets nodig hebben om hun werk goed te kunnen doen, zodat je dat kan leveren. Je kunt heel lang wikken en wegen over wat ze in het verleden niet naar tevredenheid hebben gedaan, maar ik weet uit ervaring met enkele bouwers dat de relatie daar niet veel beter op wordt en het eindproduct al helemaal niet.

 

Ik hoop dat je er iets aan hebt.. en hou ons op de hoogte ;).

 

Sietse Bakker

[Zaphod]

Ik heb een beheer achtergrond, dus ik geef mijn visie vanuit die hoek. Over het ontwikkelen van de site zelf, met de backoffice koppeling e.d., kan ik minder goed adviseren.

 

Wat ik echter in de praktijk heel vaak heb zien fout gaan is dat zoiets gebouwd is, en getest op de PC van de developer. Ze hebben wat unit-tests, integratietest etc gedraaid en nu "zou het allemaal moeten werken". Vol trots wordt het geheel gepresenteert, inclusief bobo's en borrel.

 

En dan gaat het geheel live en stort het als een kaartenhuis in elkaar. Er zijn problemen die niemand kan verklaren. De middle-office bezwijkt onder de druk, omdat de website veel meer load genereert dan verwacht.

 

Vervolgens moet de IT club die het gebouwd heeft dingen gaan uitproberen en testen om het allemaal snel te fixen. De directie hangt hijgend in hun nek, want dit kost imago en dus geld. Bovendien worden de omzet-targets niet gehaald.

 

Deze tests en reparaties moeten ergens worden uitgevoerd. Op het productiesysteem kan dit uiteraard niet. Maar dan ineens blijkt er geen Productie Acceptatie Omgeving te zijn. Dus wordt er weer op die PC van die developer getest. Van die PC is op 1 hand na te tellen dat die config anders is dan op Productie.

 

En zo blijven de fouten zich opstapelen. Wat perfect werkt op die PC van het developmentteam stort volledig in elkaar op Productie. In het beste geval levert dit performanceproblemen op, in het slechtste geval levert dit zelfs onverwachte functionele fouten, met alle gevolgen van dien.

 

Tot zover de schets van de situatie die ik -helaas- te vaak heb zien gebeuren, bij hele grote -professionele?- organisaties.

 

Mijn advies:

- zorg voor een goede teststrategie

- niet alleen een teststrategie zoals men traditioneel onderkent in een softwaretraject, maar ook een testtraject voor het accepteren van de software richting productie. Is het product beheerbaar? Hoe is het te monitoren? Hoe is de performance bij hoge load? Wordt er goed gelogd, zodat fouten te herleiden zijn? Is het dusdanig ingericht en beheerd dat een operator om 3 uur 's nachts ook de meest voorkomende problemen kan oplossen?

- zorg voor acceptatiecriteria voor productie

- overleg met de beheerders. Wat verwachten zij eigenlijk? Wanneer vinden zij een applicatie beheerbaar?

- zorg voor een Productie Acceptatie Omgeving. Deze omgeving moet technisch zo goed als mogelijk gelijk zijn aan Productie. Ja, dit is duur, want je moet alle hardware 2x aanschaffen. Maar het betaalt zichzelf dubbel en dwars terug (zie boven).

- maak iedereen bewust van dat Productie een andere realiteit is.

- doe end-to-end performancetesten, waarbij je op alle schakels van de keten "thermometers" in het proces steekt om de performance te meten. Hier zijn speciale tools voor. Deze tests zijn ERG belangrijk om problemen te vinden voordat je naar Productie gaat.

- maak hoger management bewust van dat deze zaken nodig zijn. Maak duidelijk hoe waardevol een soepele productie is. Maak duidelijk hoe groot de schade kan zijn als het systeem niet werkt / niet performt enzovoort. Dit kan alleen al enorme imagoschade opleveren (zie de problemen die de Postbank had met www.mijnpostbank.nl).

 

Er is nog veel meer over dit onderwerp te zeggen, maar dit zijn de dingen die het eerste bij mij opkomen in zo'n situatie. Mocht je meer info willen of advies, je kunt me via PM bereiken.

[cd-r80Minute]

Wat ik vaak voor enkele bedrijven moet doen is een functioneel / technisch design maken van een website, waarin precies staat uitgelegd wat de programmeurs moeten doen, welke systemen ze moeten maken. wat ze mogen gebruiken.

 

Misschien een tip voor jou ?

 

 

[Sanne Roemen]

Ik heb zo'n donkerbruin vermoeden dat het met het functioneel ontwerp wel goed zit, maar dat er nu vertraging optreedt aan het 'eind van de harmonica'. Ze hadden zelfs een prototype. Ik heb dus niet het idee dat het komt doordat de implementeerders niet zo goed begrijpen wat ze precies moeten bouwen.

 

Soms is het wel goed om incrementeel te werken, dus wijzigingen voorkomend uit voortschrijdend inzicht moeten ertoe leiden dat er één of meer stappen terug gezet worden in het ontwikkelproces. Dus echt wel aanpassen van het functioneel ontwerp. Werkt ook sterk vertragend, maar leidt wel tot duidelijke afspraken. Andere mogelijkheid is af te spreken dat deze wijzigingen in een 'reservebak' komen. Eerst het hele traject afmaken, na de pilot test een lijst met bugfixes en aanpassingen maken. Aanpassingen onderverdelen in 'must have' 'wannahave' en 'nice to have' en daar dan een planning voor maken. Voor oplevering in ieder geval de bugs fixen en de 'must haves' implementeren. Dan live gaan en in een later stadium de 'wannahaves' en eventueel de 'nice to haves' doorvoeren.

 

Voordeel is dat er als het systeem een tijdje draait ook weer wat bugs op komen borrelen en misschien ook wat 'musthaves', en dat je dan gestructureerd naar een versie 1.2 van het systeem kan werken.

 

[alterEwo]

Soms, als ik dit forum bekeek, had ik zo mijn twijfels over het nut ervan. Maar als ik kijk naar jullie antwoorden op een -ik weet het- gigantisch open vraag met veel onduidelijkheid (expres) en weinig details, dan moet ik zeggen : Ik ben onder de indruk.

 

Ik wil jullie daarom eerst bedanken : Oomph, MediaBattery, Zaphod, cdr80minute, WillemJ en Jacco !

 

Waarom ben ik onder de indruk ?

Omdat jullie zo diep met mij de diepte in zijn gegaan met jullie antwoorden. Sommige waren natuurlijk meer, anderen minder voor ons van toepassing, maar dat ligt meer aan mijn vraag dan aan jullie antwoord.

 

Jullie antwoorden hebben zowiezo zin gehad : ik ben eens flink gaan nadenken over wat julllie schreven en ben hier en daar eens gaan checken, met jullie antwoorden in de hand of achter de rug.

Uiteindelijk ben ik terecht gekomen bij een aantal zeer professionele websitebouwers. En daar kreeg ik bevestiging wat jullie hier al schreven.

 

In het kort : ons idee om binnen 5 maanden een site te bouwen met de opzet die het had werd door vrijwel iedereen als veel te ambitieus gezien, zeker met de ervaring inhouse. Kleine tekens als deadlines die wel gehaald werden, maar aan de achterkant toch eigenlijk niet- waren hier een voorbode van.

Dat de verantwoordelijken ook tijdens het traject maar bleven volhouden dat we het gingen halen, was een teken dat ze simpelweg niet wisten wat ze aan het veroorzaken waren.

Daarnaast was er een gebrek aan project-discipline, wat je op allerlei manieren zag : majeure changes tijdens het traject, onduidelijke verantwoordelijkheden, onduidelijke werkprocessen - het heeft allemaal niet geholpen.

Uiteindelijk werd het doek van dit alles getrokken toen de testfase aanbrak : 'ineens' kwam een gigantische berg bevindingen naar boven, waar we allemaal van onder de indruk waren. Uithuilen en opnieuw beginnen. Nu zitten we op een datum, die ook de professionals als meer logisch achtten.

 

En verder ? Mijn opdrachtgever wil voor het vervolg van het traject eerst duidelijkheid over de fouten uit het verleden, voor hij wil doorgaan. Geen slecht idee. Totdat dit ook weer problemen oplevert, horen jullie denk ik niet meer over dit traject.

 

HigherLevel en jullie zijn dus zeker zinvol. Bedankt, alterEwo.

[Sanne Roemen]

:D

Wat leuk en goed om zo duidelijk een positieve reactie op HL te zien. Ik ben erg benieuwd naar de voortgang, misschien wil je ons op de hoogte houden van het proces.

Ik ga nu met een glimlach de rest van de dag door.