- Gegevens
NBIC
hackathon net begonnen. Wat kunnen we aan elkaar knopen? #nbic #hackathon #work
- Gegevens
Een foutje in de interface van twitter net na de introductie van de "retweet" functionaliteit. Nadat ik dit bericht heb geretweet zegt het systeem "retweeted by you and 7 others", maar "you" is blijkbaar een heel ander twitter account.... #oops #twitter
- Gegevens
Ik realiseerde me dat ik over de afgelopen jaren een behoorlijk aantal uithoeken van de wereldbol heb bezocht. Dit heeft me op het idee gebracht om een speciale doorsnede te maken van de foto's uit mijn bibliotheek. De gekozen foto's hebben als eigenschap dat elke twee foto's die je kiest op meer dan 1000 km van elkaar zijn gemaakt. Het resultaat: 21 foto's die 21 totaal gescheiden cirkels van 500 km straal representeren, ongeveer 3% van het aardoppervlak. Ik moet nog even!
- Gegevens
Stel je een mechanische werkplaats voor. Je komt met een probleem dat zij oplossen. Wat verwacht je? Je verwacht met hen samen te werken, grofweg in de volgende vijf stappen:
- Specificeer. Je beschrijft het probleem in de vorm van een functionele specificatie
- Ontwerp. Ze gaan een tekening maken
- Onderdelen. Zij (mogelijk meerdere mensen parallel) zullen het ontwerp gebruiken om onderdelen te selecteren en te vervaardigen
- Product. Ze zullen de stukken aan elkaar lassen tot het ding dat je nodig hebt
- Test. Je test het en het kan kleine aanpassingen vereisen
Stel je nu een softwareworkshop voor. Je komt met een probleem dat zij oplossen. Wat verwacht je?
- Specificeer. Je beschrijft het probleem in de vorm van een functionele specificatie
- Product. Zij zullen de softwaretool maken
- Test. Je alfatest, ze repareren, je bètatest, ze repareren. Herhaal tot bevredigend
Hoe komt het dat deze lijst slechts drie in plaats van vijf stappen bevat? En waarom veroorzaakt de laatste stap altijd zoveel pijn? Zou dit verschil de oorzaak kunnen zijn waarom zoveel softwareproducten falen? Wat is het echte verschil tussen software- en hardwareontwikkeling?
In plaats van te proberen het softwareprobleem in één keer op te lossen, stelt u zich eerst een hardwarewerkplaats voor die als volgt werkt:
- Specificeer. Je beschrijft het probleem in de vorm van een functionele specificatie
- Product. Ze zullen materialen aan elkaar lassen tot een stuk gereedschap
- Test. Je test, zij repareren, je test opnieuw, zij repareren. Herhaal tot bevredigend
Hoe waarschijnlijk is het dat deze procedure sneller is dan de procedure in vijf stappen? Hoe duidelijk is het welke stukken aan elkaar moeten worden gelast? Kunnen hierdoor meerdere mensen samenwerken aan het product? En hoeveel werk is het testen voor jou? Hoeveel afval komt er vrij in het proces? Je zou dit soort beunhazerij niet accepteren! En mijn punt: je moet het ook niet accepteren van een softwarewerkplaats.
Een goede softwarewerkplaats zou dezelfde vijf stappen gebruiken als de goede mechanische werkplaats:
- Specificeer. Je beschrijft het probleem in de vorm van een functionele specificatie
- Ontwerp. Zij maken een (modulair) ontwerp
- Stukken. Zij (eventueel meerdere programmeurs parallel) zullen het ontwerp gebruiken om softwaremodules te bouwen en te selecteren
- Product. Zij zullen de modules gebruiken om de software te bouwen die je nodig hebt
- Test. Je test het en er zijn misschien kleine aanpassingen nodig
Investeren in een ontwerp zal resulteren in een oplossing die het gestelde probleem echt oplost en geen eindeloze iteraties vereist om het goed te krijgen. Het lijkt misschien een trage oplossing, maar dat is bedrog: je krijgt daadwerkelijk een resultaat dat je brengt waar je wilt zijn, ook als je in de toekomst nieuwe aanvullende wensen hebt.
(Ik wil graag een oud-collega bij Bruker AXS bedanken die me deze mooie vergelijking heeft gegeven. Ik weet dat hij anoniem wil blijven op het internet. Beeldcredits: Dystopos op Flickr)
- Gegevens
Het koelsysteem van de schaatsring op de Uithof in Den Haag is lek…. #oops #nh3
- 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?
- Gegevens
Sprekers staan in de rij voor hun 5-minuten voordracht #dswm #conference
- Gegevens
De helft van de treinen valt uit, de andere helft is vertraagd met de helft van het gebruikelijke interval… #trip #koud
- Gegevens
Vandaag hangt de vlag van de VN halfstok om de slachtoffers van de enorme aardbeving in Haiti te gedenken. #vn