- Gegevens
Nadenkend over Poisson-statistieken vroeg ik me af hoeveel nut een klok zou hebben die de seconden zou tellen met telstatistiek ofwel Poisson-statistiek. Dat wil zeggen: een klok met de onregelmatigheid van radioactief verval. Sommige mensen zetten hun horloge een paar minuten voor op de werkelijke tijd om er zeker van te zijn dat ze nooit te laat zijn, maar het probleem is dat ze daar na een tijdje op kunnen gaan rekenen. Een echte willekeurige klok kan zo onbetrouwbaar zijn dat je altijd voorzichtig voor moet blijven lopen….
Lees meer: Kan je een klok met Poissonstatistiek gebruiken in plaats van een horloge?
- Gegevens
Computerinfrastructuur die op universiteiten wordt gebruikt, maakt geen deel uit van een markt, laat staan van een "transparante markt" waarin iedereen een duidelijk zicht heeft op de alternatieven die er zijn en wat hun relatieve baten en kosten zijn.
Niemand in een universitaire onderzoeksgroep vindt het vreemd om te betalen voor pennen en papier.
Niemand in een onderzoeksgroep vindt het vreemd om te betalen voor ultramoderne laboratoriumapparatuur.
Maar heel vaak worden computerdiensten gratis aangeboden. Net als water en elektriciteit zijn ze verdisconteerd in de algemene kosten van het runnen van de universiteit.
Deze situatie is onhoudbaar in een wereld waarin biowetenschappelijk onderzoek wordt gedreven door big data. En het wordt ook onhoudbaar in een wereld waar grote opslag- en computerinfrastructuur die geschikt is voor routineklussen, commercieel kan worden gehuurd.
De duurzame weg naar de toekomst is een goed budget voor gegevensverwerking en -opslag. Budgettering voor computerbehoeften betekent dat mensen kosten en baten moeten afwegen, zoals bij elk ander aspect van een onderzoeksproject.
- Gegevens
Bij de RAMIRI-training (Realising and Managing International Research Infrastructure) die ik deze week in Triëst volgde, sprak één zin mij bijzonder aan. Deze was van Kimo Koski (CSC Finland) die opmerkte dat het moeite kost om een organisatie klantgericht te houden terwijl deze groeit.
Vanaf ongeveer 100 mensen kan een organisatie zichzelf volledig bezig houden zonder ooit een klant te bedienen.
Toen ik voor Bruker AXS werkte, zei onze verkoopdirecteur Paul Ulrich Pennartz soms iets verwants als hij in een cynische bui was:
Zonder die vervelende klanten zouden we ons eindelijk kunnen concentreren op ons werk.
Als je je ooit hebt afgevraagd waarom kleine bedrijven sneller reageren dan grote, dan denk ik dat deze twee mensen de oorzaak vrij goed samenvatten.
(noot: dit is de essentie van wat deze beiden gezegd hebben, dit waren niet hun letterlijke woorden)
- Gegevens
Als er meer dan één taak moet worden voltooid, is het altijd beter om de ene voor de andere te doen. Dat besprak ik eerder in de post Parallelle processen in een projectteam.
Een individuele klant met een nieuwe vraag zou kunnen denken dat het nog sneller gaat als je zijn project ertussen inpast. We moeten die klanten ervan bewust maken dat als we onderbrekingen van welke aard dan ook toestaan in een agile sprint, niets ooit zal worden afgemaakt. Wat kunnen we ze vertellen? Er zullen andere mensen zijn met nieuwe verzoeken terwijl we aan uw taak werken.... moeten we ook hun verzoeken honoreren om ons werk te onderbreken?
Ze moeten begrijpen: agile sprints worden niet onderbroken. Ze worden voltooid of geannuleerd.
Image from Flickr by brittgow
- Gegevens
Chemie als zelfstandig naamwoord heeft in het dagelijks leven twee totaal verschillende betekenissen:
- Een goede sociale relatie:
'Het was zichtbaar dat er chemie was tussen die twee mensen'
- Iets gerelateerd aan een verbinding die zogenaamd slecht is voor mens of milieu. "Chemisch" wordt vaak gebruikt als synoniem voor giftig:
"Er lekte een chemische stof uit de container in zee, waardoor de vissen in gevaar kwamen"
Hoe komt het dat deze twee betekenissen van hetzelfde woord zulke extreem verschillende connotaties hebben? Het wetenschappelijke woord chemie vertegenwoordigt immers elke vorm van reactie tussen twee verbindingen en heeft op zichzelf geen positieve of negatieve betekenis. Water is een chemische stof. Het leven is chemie.
Als chemicus zou ik willen dat ik de negatieve connotatie van moleculaire chemie in het nieuws kon veranderen. Maar als het me echt niet lukt, kan ik misschien de maatschappelijke betekenis van chemie beïnvloeden om dingen consistent te maken:
"Er was chemie tussen die twee! Toen ze elkaar voor het eerst ontmoetten, probeerde ze hem te vergiftigen. Zodra hij hersteld was, explodeerde hij in woede."
Op de een of andere manier heb ik het gevoel dat dit niet zo bevredigend zou zijn.
[afbeelding: Nic McPhee op flickr]
- Gegevens
Hoe belangrijk is het om prioriteiten te stellen?
Laten we aannemen dat we 4 ideale projecten A, B, C, D en een ideaal projectteam hebben. Elk van deze projecten neemt 3 maanden in beslag. Ze zijn allemaal even belangrijk. We werken er parallel aan. Wanneer zijn de projecten klaar? Project A is na 12 maanden klaar. Project B is na 12 maanden klaar. Project C is na 12 maanden klaar. Project D is na 12 maanden klaar.
Wat gebeurt er als we prioriteiten stellen en aan de projecten in alfabetische volgorde werken? Wanneer zijn de projecten nu klaar? Project A is na 3 maanden klaar. Project B is na 6 maanden klaar. Project C is na 9 maanden klaar. En project D is na 12 maanden klaar. Iedereen behalve de klant van project D wordt er beter van! Fantastisch, toch?
Helaas is dit niet de perceptie van de klanten. Elk van hen ziet een project van 3 maanden en wil het in 3 maanden af hebben. De klant in project D wil niet horen "we gaan over 9 maanden aan je project beginnen". Prioriteiten veranderen daarom maar al te vaak. Elke maand, tijdens een evaluatie van het projectteam, zul je gedwongen worden om nieuwe prioriteiten te stellen. Wat is het effect? Project A is na 9 maanden klaar. Project B is na 10 maanden gereed. Project C is na 11 maanden klaar. Project D zal na 12 maanden klaar zijn.
Wat een verspilling. Trap niet in deze val. Stel prioriteiten en blijf bij de keuze.
[Afbeelding: goldstardeputy]
- 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
Na elke ingrijpende verandering in een organisatie is er behoefte aan een fase van rustige doordachte verbeteringen. Wonderen verwachten van enorme bedrijfsreorganisaties is een misvatting die leidt tot reorganisatie na reorganisatie, mogelijk resulterend in volledige vernietiging van de organisatie.
Heb je ooit een spelletje Pac-man gespeeld? Het is een eenvoudig spel waarbij je een kleine figuur bestuurt die stippen op het scherm eet, terwijl geesten je achtervolgen. De game is een uitstekende spiegel van het zakenleven in een veranderende omgeving:
- In Pac-man probeer je bij elke stap je gezondheid te verbeteren door een stip te eten en uit de buurt van de geesten te blijven.
- In het zakenleven brengt u kleine wijzigingen aan in uw producten en procedures om meer te verkopen en uw concurrenten uit de weg te blijven.
Er is nog een analogie:
- In Pac-man lopen dingen soms vast. Geesten komen van alle kanten dichterbij en er is geen ontkomen aan. Op zo'n moment kun je gebruik maken van de teleport: een paniektoets die je in een oogwenk naar een willekeurige plek in de scene brengt.
- In het zakenleven loopt het soms vast. Concurrenten komen dichterbij en het lijkt erop dat er geen uitweg meer is. Op zo'n moment roept de CEO (vaak snel zonder alle betrokkenen te raadplegen) om een ingrijpende reorganisatie.
In het bedrijfsleven is er een belangrijke les die we kunnen leren van de teleportfunctie in Pac-man: een teleport is verre van een gegarandeerde redding! Het kan je in een zeer gevaarlijke situatie brengen. Het doel van de teleport is niet een onmiddellijke verbetering van het verloop van het spel, het is om te ontsnappen aan een hopeloos vastgelopen situatie, aan een dreigende ramp. Direct na een teleportatie moet je handelen en stappen ondernemen om de controle terug te krijgen. Evenzo zal een ingrijpende reorganisatie in het bedrijfsleven zelden direct een betere situatie brengen. Een reorganisatie is bedoeld om de boel op te schudden en te ontsnappen uit een hopeloos vastgelopen situatie (vaak onzichtbaar voor veel van de medewerkers). Na de relatief gedachteloze sprong die snel moet worden uitgevoerd om een onmiddellijke game over te voorkomen, zal de organisatie een doordachte fase moeten ingaan waarin kleine verbeteringen worden aangebracht om de situatie te optimaliseren.
Als u zich realiseert dat een reorganisatie u niet onmiddellijk winst heeft opgeleverd, probeer dan af te zien van verdere reorganisaties. Zoek in plaats daarvan naar mogelijkheden voor kleine veranderingen en geef het wat tijd.
- Gegevens
Als je geen gebruikersfeedback krijgt voor je software, zijn er twee mogelijke redenen.
- Het is slecht. Niemand gebruikt het.
- Het is goed. Iedereen is blij.
Als dit je overkomt, denk dan eens terug. Heb je al eerder feedback gekregen? Hoe reageerde je?
- Heb je naar je gebruikers geluisterd en hun problemen opgelost?
- Heb je je gebruikers verteld hoe je vindt dat de software moet worden gebruikt?
Door deze twee vragen te beantwoorden kun je zelf uitzoeken waarom je geen feedback meer krijgt. Als je hebt geluisterd en de stroom vragen is gestopt, betekent dit waarschijnlijk dat de gebruikers nu tevreden zijn. Als je hebt geprobeerd het gebruik te corrigeren, gebruikt waarschijnlijk niemand het meer.
Je bent toch niet vergeten je contactgegevens te vermelden?