- Gegevens
De
BiGGrid gebruikersdag wordt georganiseerd in de Beurs van Berlage in Amsterdam. Als je door het moderne glazen plafond breekt komt je in het oude monumentale gebouw. #conference
- Gegevens
De trein die me vanochtend van Rotterdam naar Utrecht had moeten brengen hield er tijdens de trip opeens mee op. Gaf ons een interessant uitzicht over snelweg A20. Voor een behoorlijke tijd... #trip #vertraging #ns
- Gegevens
Wauw, een nieuw strand dit jaar. Mooie rustige avond ook! Watertemperatuur is 14C.
Het strand bij 's-Gravenzande is verbreed door opspuiten van nieuw zand, heel veel zand. Daar waren twee redenen voor: ten eerste was er een probleem van stranderosie dat blijkbaar werd veroorzaakt door een concave (holle) kustlijn. Ze wilden daarom zoveel strand toevoegen dat de kustlijn niet meer concaaf was. Bovendien wordt op de zuidflank een enorme uitbreiding van de Rotterdamse haven gebouwd en moet het verlies aan ecosysteem dat daardoor ontstaat ergens worden gecompenseerd. Een deel van het "oude" strandgebied is nu omgevormd tot vogelvriendelijk natuurgebied.
- Gegevens
Een softwaregroep als de onze moet leveren wat klanten willen... maar dat kan lastig zijn, omdat ze vaak niet vragen wat ze willen. Dit komt omdat klanten denken te weten wat een probleem veroorzaakt en ze denken te weten wat de beste manier is om het probleem op te lossen. Vervolgens formuleren ze hun verzoek langs die gedachtenlijn in een poging ons te helpen.
Een voorbeeld: ik had eens klanten die me vroegen of ik mijn software zo kon veranderen dat het de getallen zou afronden die het zou gebruiken om een robot te positioneren. Het zou gemakkelijk zijn geweest om aan dat verzoek te voldoen, maar ik besloot te vragen waarom? Dit bleek een goed idee. Ik ontdekte dat de klanten de nummers kopieerden naar een ander softwarepakket. In plaats van te doen wat de klanten vroegen, schreef ik uiteindelijk een directe interface naar de andere software. Dit maakte het leven van de gebruikers nog veel gemakkelijker, zonder de mogelijkheden van de robot te beperken.
We kunnen klanten niet kwalijk nemen dat ze niet weten wat makkelijk en wat moeilijk te implementeren is. Beide kanten. Ze kunnen denken dat iets heel gemakkelijk is, terwijl het in feite heel moeilijk is. Maar het komt ook voor dat ze een vraag niet durven te stellen waarvan ze denken dat die moeilijk is, terwijl die in feite heel makkelijk te implementeren zou zijn.
Als je de best mogelijke software wilt maken, moet je blijven vragen "waarom" totdat je gebruikersrapport is gewijzigd in "Als ik A doe, krijg ik B. Maar in plaats van B zou ik C willen zien (omdat ik D nodig heb )". Dit zal u helpen beslissen hoe de klanttevredenheid kan worden gemaximaliseerd. Het maximum kan veel hoger zijn dan uw klanten verwachten.
- Gegevens
Op een bezoek aan Anterwepen in België kom ik in een nieuwe chocoladefabriek deze handtekening op de muur tegen. "Moo! Chocolate is the Linchpin. Keep shipping. Seth” #sethgodin #chocolate #antwerpen
- Gegevens
Een van de eerste fasen in de ontwikkeling van een nieuwe tool (software of hardware) is een functionele specificatie. De functionele specificatie rijpt in discussies tussen de ontwikkelaars (afdeling R&D) en de vertegenwoordigers van de klant (vaak de afdelingen marketing en verkoop).
Natuurlijk is een functionele specificatie handig: het is erg moeilijk om iets nieuws te ontwikkelen zonder een idee te hebben van hoe de nieuwe tool zal worden gebruikt en waarmee deze zal worden vergeleken. Het definiëren van een functionele specificatie kan echter ook te ver gaan. In sommige organisaties zijn de functionele specificaties tot in de kleinste details uitgewerkt. Aan het einde van een lange formele procedure wordt het bestekboek ondertekend als een contract tussen marketing en ontwikkeling. De ontwikkeling kan pas worden gestart als de lijst met handtekeningen compleet is en zal worden uitgevoerd in complete afzondering van de wereld van potentiële gebruikers. Waarom maken organisaties hun specificaties op deze manier? Het is vaak een poging om de verantwoordelijkheden van de afdelingen te scheiden, zodat als er iets niet lukt de juiste partij de schuld krijgt. Als het eindproduct niet voldoet aan de functionele specificaties, kan dit worden toegeschreven aan de ontwikkelaars. En als het product niet slaagt terwijl het wel aan alle functionele specificaties voldoet, wordt dat aan de marketing toegeschreven.
Ik heb een serieus probleem met deze benadering: hoe kan men er met behulp van deze procedure voor zorgen dat het product nuttig zal zijn? Na twee jaar zonder interactie kan ontwikkeling precies opleveren waar marketing om vroeg (alle deadlines halen en binnen budget), maar de markt is veranderd en heeft het ontworpen product niet meer nodig. Of de techniek is veranderd, en betere specificaties zouden binnen handbereik zijn geweest en worden aangeboden door de concurrentie. Of misschien heeft marketing echt een fout gemaakt en gevraagd om iets waar de wereld niet op zit te wachten. In deze gevallen kan de ontwikkelingsafdeling duidelijk niets worden verweten! Maar als je op deze manier een verouderd product ontwikkelt, waar blijft de organisatie als geheel dan? En als dit niet de beste oplossing is voor de organisatie als geheel, is het dan wel goed voor de ontwikkelafdeling? Ook al deed iedereen precies wat er van hem verwacht werd, toch kunnen er mensen ontslagen worden omdat ontwikkelingskosten niet terugverdiend kunnen worden.
De oplossing is, zoals zo vaak, om een middenweg te behouden. Met behulp van b.v. Met Agile- of LEAN-ontwikkelingsmethoden kunnen ontwikkelaars voortdurend in contact blijven met marketing. Iteratieve en modulaire ontwerpprocedures kunnen worden gebruikt om te controleren of de nieuwe tool doet wat hij moet doen, zonder te vertrouwen op het vermogen van mensen om specificaties vooraf in woorden te beschrijven. En omdat de communicatie met de markt niet verloren gaat tijdens het ontwikkelproces, heeft de tool een aanzienlijk grotere kans om daadwerkelijk bruikbaar te zijn op het moment van introductie.
Afbeelding (door QuiteLucid op Flickr): "een kameel is een racepaard ontworpen door een commissie".
- Gegevens
Ons team werkt samen met een aantal taskforces in de bio-informatica. Elk van die taskforces is gestart om samen te werken aan de ontwikkeling van een platform voor hun deelgebied: een set softwaretools die samenwerken om de problemen op te lossen die iedereen in het veld moet oplossen. Voor de ontwikkeling van het platform zijn geen nieuwe bioinformatica-ontwikkelingen nodig: het doel is om bestaande tools samen te voegen.
Het voordeel van het beschikbaar hebben van deze platforms ligt voor de hand:
- voor een bioloog bestaat het voordeel erin dat alle de facto standaard tools met één druk op de knop beschikbaar zijn.
- voor een gespecialiseerde bio-informatica-onderzoeker die aan een nieuwe tool werkt, is het voordeel dat hij niet te maken heeft met de fijne kneepjes van alle andere tools, en zijn nieuwe tool in het platform kan pluggen met behulp van goed beschreven protocollen.
Om tot de ontwikkeling van een dergelijk platform te komen, is er een bootstrapping-probleem. De situatie is als een tafel met aan de ene kant biologen en aan de andere kant bio-informatici. Boven de tafel een dikke (vulkanische?) mist. De lay-out van het platform is in diagrammen op tafel getekend: alle tools die de gemeenschappelijke workflow vormen, met al hun relaties. Aan de kant van de bio-informatici geeft het schema de concrete handvatten weer. Door de mist kunnen ze vaag de workflow aan de andere kant van de tafel zien. Voor de biologen ziet de situatie er heel anders uit: zij hebben een duidelijk zicht op de concrete workflow die ze nodig hebben, maar de tools zijn vage entiteiten die alleen zichtbaar zijn door de dichte mist.
Zonder goede ondersteuning van een projectleider die kan luisteren naar mensen aan beide kanten van de tafel, zullen de bio-informatici de zeer concrete problemen die ze tegenkomen proberen op te lossen met hun zeer concrete individuele tools. Een beetje optimalisatie hier, een betere dataopslag daar. Niets hiervan is zichtbaar voor de biologen.
Daarom zetten we projectleiders van ons engineeringteam in elk van de taskforces. Ze zullen de focus van de bio-informatici richten op meer zichtbare veranderingen. Werk aan gemeenschappelijke gegevensformaten. Werk aan (gemeenschappelijke) gebruikersinterfaces.
Door de vertaalslag ontstaan de echte samenwerkingsvoordelen. Die zal de mist wegblazen. Plots kunnen de biologen zien wat er aan de hand is. Zij kunnen gerichte feedback geven. En de bio-informatici zullen de workflow zelfs van hun kant kunnen zien en erop kunnen voortbouwen.
Afbeelding: drie weergaven van drie tafels, door EJP Photo op Flickr.
- Gegevens
Verboden te parkeren op een parkeerplaats? Ken ik dat bord? En waar mag het dan wél?
Heel leuk, een kermis. Maar in Maassluis parkeren de attractie-eigenaren hun auto op de parkeerplaats bij het station west. En waar moeten de OV-gebruikers hun auto’s dan parkeren?
Grappig ook dat het blijkbaar geaccepteerd wordt om zomaar een “verkeersbord” te verzinnen waarmee gewone weggebruikers de toegang tot een stuk openbare weg wordt ontzegd. Leuk om thuis ook eens te proberen…..
- Gegevens
Workshop over kwaliteit van software bij de 5e NBIC-conferentie. Het onderwerp wordt geintroduceerd door Machiel Jansen van SARA. #nbic5