Even een les uit ons eerste anderhalf jaar van ons web software bureau zorros.be: elk van onze klanten is als bij toeval bij ons terecht gekomen. Dus een bedrijf opstarten is een loterij? Neen. Toeval lok je uit!

Het is niet de beste die de klanten binnenhaalt. Het is diegene die zich als beste voordoet naar de markt toe. Klanten rekenen je af op die eerste indruk. Er moet dus in de eerste plaats een eerste indruk zijn. Door in je kot te blijven zitten kan je geen indrukken nalaten. Je mag dan nog op je zolderkamer de beste code schrijven, de mooiste Photoshops uitwerken, of de meest zuinige elektrische motor uitvinden, als je er niet mee naar buiten komt, heb je geen klanten. Nul. Een middelmatige web developer die zich laat zien, zal eerder klanten vinden dan een top developer die alleen op zijn kamer blijft zitten.

Door naar buiten te komen, lok je de kans uit dat klanten je vinden. Dat kan bijvoorbeeld door:

• Naar beurzen te gaan. En dan liefst beurzen waar je klanten zitten, en niet je collega’s. Als designer is het uiteraard interessant om naar bijeenkomsten te gaan voor designers, maar daar zitten (1) niet veel klanten en (2) als er al zitten, loopt er een leger aan concurrenten rond je. Indien je klanten wil tegenkomen, ga dan naar andere beurzen: beurzen voor starters (die hebben allemaal een website nodig), beurzen voor bedrijfsleiders, beurzen voor zelfstandigen, voor KMO’s, … Raak er aan de praat, en begin geen verkooppraatje. Men vraagt toch wat jij doet van werk. Gewoon aanhalen wat je doet is al genoeg: indien men (nu of later) op zoek is naar wat jij aanbiedt, krijg je vroeg of laat van die persoon een telefoon. Bingo!
• Te bloggen. Blog over eender welk onderwerp, zolang het je maar interesseert en je van dat onderwerp meer af weet dan 90% van de mensen om je heen. (trek je niets aan van die 10% die er meer van afweet.) Het belangrijkste is dat je blogt en dat 90% vindt dat je een expert bent in je onderwerp. Er is altijd wel iemand op deze wereld die wil lezen wat jij schrijft. Hoe specifieker het onderwerp waarover je schrijft, hoe minder lezers, maart des te trouwer je fans. En vroeg of laat is er één van die fans, of iemand uit de kennissenkring van die fans, die nét de dienst nodig heeft die je aanbiedt. Bingo!
• Dingen te doen. Dat wil zeggen: andere dingen dan je hoofdactiviteit (designen, programmeren, schilderen, …). Ga eens bij familie langs, maak een bedrijfsvideo, ga klanten interviewen, organiseer een bijeenkomst, ga presenteren op een beurs, nodig je klanten uit voor een drink zodat ze elkaar leren kennen, maak sweaters en geef die weg, ga eten met je bedrijf, doe een brainstorm met andere bedrijven. Je zou er van versteld staan over hoeveel mogelijke opdrachten hier uit voortvloeien!

O ja, en volg me even op twitter aub: @pietereer

De wereld verandert constant. Elke seconde wordt er een kind geboren en elke dag worden er 500.000 nieuwe Twitter accounts aangemaakt. 15 jaar geleden kende niemand Internet, terwijl binnen 5 jaar allicht 70% van de Belgen continu met zijn mobieltje met het net verbonden zal zijn. E-commerce groeit met 15% per jaar, en we rijden binnenkort met elektrische wagens. En toch zijn er bedrijven die op hun wolk blijven zitten tot ze eraf vallen. Denk maar aan Nokia dat ooit marktleider was, en zich als een slak heeft laten inhalen door Apple, Google en vele anderen.

Kunnen inspelen op een continu veranderende wereld is geen optie. Het is hét criterium voor het opstarten én onderhouden van een succesvolle business. In de woorden van Darwin:

Business modellen moeten steeds heruitgevonden worden. Interne processen moeten hertekend worden. Niet innoveren in een constant veranderende wereld is achteruit gaan. En dat zeker in de laatste decennia waarin alles aan een record temp wijzigt.

Meer dan ooit is wendbare software op maat een troef om het verschil te maken. Voor al wat commodity is bestaan er schitterende standaard pakketten. Maar als je bedrijf enkel uit commodity bestaat, wat is dan je bestaansreden? Door te innoveren breek je op bepaalde vlakken uit standaard patronen. En doordat je uit standaard patronen breekt, ben je (op bepaalde vlakken) niets met standaard software pakketten.

U wil als eerste fruit online verkopen? U wil uw interne processen verbeteren door middel van gebruik van eID? U wil uw klanten een bijzonder goede service bieden waarbij ze online de status van hun bestelling kunnen opvolgen? U wil een iPhone applicatie om klanten beter op de hoogte te houden? Telkens opnieuw een razend interessant concurrentieel voordeel. En dus telkens ook iets waarvoor geen standaard pakket bestaat. Indien er een standaard pakken voor zou bestaan, was het geen concurrentieel voordeel!

Door zijn business af te stemmen op wat “de standaard” informatica pakketten bieden, stem je je business af op de commodity. Je business wordt niet efficiënter dan de concurrentie, wordt niet innovatiever, beter, goedkoper of creatiever. Enkel door verder te denken dan wat bestaande oplossingen bieden, kan je je concurrentie beter afzijn.

In ons web applicatie en software bedrijf Zorros maken we overtuigd gebruik van het web applicatie framework “Ruby on Rails”. “So what” hoor ik u denken. “Ik ben enkel geïnteresseerd in het eindresultaat en de business value. Technologie interesseert me niet, zolang het onze business maar ondersteunt.“ Leest u dan zeker verder…

Ruby on Rails (RoR) is een web applicatie framework: een stevige verzameling code die toelaat om op een zeer efficiënte en doelgerichte manier web applicaties te maken. Ruby on Rails focust sterk op het ondersteunen van de business en het oplossen van problemen door middel van IT en (web) applicaties. Deze business oriëntatie en filosofie zit in Ruby on Rails ingebakken door middel van volgende eenvoudige principes:

• Don’t Repeat Yourself (DRY): informatie, code, business logica en layout wordt slim gebundeld en verzameld op centrale plaatsen in de architectuur van de applicatie. Hiernaar wordt vanuit de rest van de code verwezen. Dit betekent dat een wijziging in je bedrijfsproces, in de business logica, in de code, of in je kleurenschema steeds maar op één centrale plaats moet gebeuren. Een veranderende business vraagt een flexiebele applicatie.
• Convention over configuration: Rails vraagt je geen overbodige zaken te configureren die er in 99% van de gevallen niet afwijken van “het typische scenario”. In een applicatie om foto’s te beheren, gaat Rails er van uit dat je (1) foto’s kan uploaden, (2) foto’s kan bewerken, (3) foto’s kan verwijderen en (4) je foto’s kan bekijken. Hiervoor moet je als developer niets doen. Rails neemt dat aan, aangezien dit voor 99% van de gevallen zal kloppen. Moest je toch willen afwijken van wat Rails standaard voorziet, dan kan dat uiteraard. Werken met zoveel mogelijk “conventies” en dus minder “configuratie”, zorgt voor minder code. Minder code is minder frustratie, problemen, verrassingen, maintenance, vergissingen. En dus meer tijd voor je échte business.
• Test driven development: Rails moedigt developers aan om automatische testen te schrijven, en voorziet out of the box een mooi test framework. Deze geautomatiseerde testen gaan de applicatie zeer regelmatig testen. Bij een groeiende en meer complexe applicatie wordt het voordeel hiervan zeer duidelijk: je laat je testen lopen, en op enkele minuten gaat een “robot” heel je applicatie na op bugs, fouten of onverwachte scenario’s. Eventuele problemen kunnen snel ontdekt worden. Dit geeft beslissingsnemers een gerust gevoel wanneer aan de business logica wordt gesleuteld die gevolg heeft op de code. De automatische tests geven ons eventuele problemen aan, ook inconsistenties in de business logica. Ook kunnen er wekelijks nieuwe functionaliteiten gereleased worden, zonder dat een 10-koppig test team telkens door de hele applicatie moet gaan om na te gaan of er nergens problemen opduiken. Dat doet onze geautomatiseerde test omgeving wel wekelijks voor ons!

Hierboven: 467 tests, waarin 686 “assumpties” over de code en business logica positief verlopen. En dat in 38 seconden! Een mens doet hier enkele dagen over. Alle testen zijn “groen”: we kunnen met een gerust hart de code online zetten.

Rails geeft developers de mogelijkheid om meteen op de business logica te gaan focussen. Zaken zoals paswoord management voor gebruikers, converties naar XML, API’s, overbodige configuratie en vaak terugkerende stukken code die onafhankelijk zijn van de business worden allemaal voorzien, telkens met als doel het ontwikkelings team te ontlasten van niet project specifieke taken en beslissingen.

Daarnaast moedigt Rails agile ontwikkeling aan: de brug tussen de ontwikkelaars en de klant wordt zo klein mogelijk gehouden, door middel van vele, snel op elkaar volgende releases en feedback rondes. Feedback van de klant kan snel in rekening worden gebracht, waardoor het project snel kan bijgestuurd worden. Hoe vroeger een fout wordt rechtgezet, hoe minder duur de fout is. Rails doet er alles aan om flexiebel en “vinnig” te zijn, en slaagt hier bijzonder goed in.

Daarnaast is Rails open source. En dat blijft niet bij een theoretisch principe. Een hele gemeenschap van ontwikkelaars deelt op Github stukjes interessante en business onafhankelijke code. Andere developers verbeteren deze code, of breiden ze uit. Na verloop van tijd zijn er honderden interessante, herbruikbare componenten ontstaan die je in je Rails applicatie kan gaan aanwenden, waardoor je weer beter op je eigen business logica kan gaan focussen. Er zijn ook nieuwe frameworks ontstaan bovenop Rails, zoals Spree voor e-commerce of Radiant voor CMS, die een stevige basis vormen voor zulke projecten.

Tot dat iemand me van het tegendeel kan overuigen, ken ik geen beter framework voor complexere (web) applicaties die steeds veranderende business, processen, wereld of markt moeten ondersteunen…

Agile software ontwikkeling is een mooi principe. Het principe zegt dat je snel van start gaat met programmeren, snel iets oplevert (ook al is dat nog niet 100% af), op basis daarvan feedback verzamelt van de klant, en op basis van die feedback de ontwikkeling bijstuurt. Dit herhaal je. Door regelmatig feedback te verzamelen en bij te sturen groeit het project letterlijk in de juiste richting.

Zoals overal, zijn er ook in software development veel dingen kan je onmogelijk op voorhand plannen. Denk maar even aan de renovatiewerken die je ooit hebt laten uitvoeren, of de bouw van je huis. Zelfs niet met een 300 pagina’s dikke functionele design en technische analyse kan je heel het project uitstippelen. En dat is precies het probleem dat agile ontwikkeling wil aanpakken. Planning is guessing. De weg die je op voorhand uitstippelt aan de hand van een gedetailleerde functionele design wordt toch nooit bewandeld. Er zijn onderweg altijd bijsturingen nodig. Die vangen we op door onderweg feedback te vragen en bij te sturen. We proberen niet eens om de weg uit te stippelen. Agile software ontwikkeling.

Daarnaast is het zo dat gaandeweg een project, zeker bij grotere projecten, de functionele vereisten wijzigen. Dit omdat het in het begin nog niet helemaal duidelijk was wat nu eigenlijk de bedoeling was van de software, omdat er nieuwe elementen opduiken die invloed hebben op de uiteindelijke vereisten. Agile ontwikkeling speelt hier mooi op in, aangezien de functionele vereisten pas gaandeweg worden bepaald.

Echter, ik vind het een probleem als Agile ontwikkeling een excuus wordt om helemaal geen functionele of technische analyse te doen. Er zijn namelijk een heel aantal zaken die je wél perfect op voorhand kan uitstippelen. Agile ontwikkeling is geen reden om de functionele design over te slaan. Een document van een paar pagina’s met een redelijk gedetailleerde uitwerking van de gewenste functionaliteiten is niet overbodig. Agile ontwikkeling is geen reden om helemaal geen technische analyse te doen. Bepaalde belangrijke technische keuzes kunnen pas correct gemaakt worden als er wél een volledig helikopter overzicht is van de volledige scope. Het is dus heus niet overbodig om de data die je ter beschikking hebt en de business logica die later met die data zal werken, even nader te bekijken.

Een goede functionele en technische analyse zorgen ervoor dat je koers zet in de juiste richting, zonder over details te praten. Agile ontwikkeling kan/moet gaandeweg die koers nog bijsturen. Maar als je op basis van “gevoel” en “Agile-we-zien-wel-na-de-eerste-iteratie” je koers kiest, kan je wel eens de verkeerde koers kiezen. Ik geloof dat een deftige functionele en technische analyse vòòr de eerste letter code het project serieus kunnen inperken qua tijd, kost, frustratie en misverstand. Ik geloof ook dat agile ontwikkeling nodig is om het project, na de eerste letter code, op koers te houden, en rekening te houden met onvoorziene omstandigheden die tijdens de functionele en technische analyse niet duidelijk waren.

We horen zoveel over Web 2.0, Twitter, succesverhalen en Sociale Media. Wat is nu waar van die internet hype? Moet je als bedrijf mee op de e-commerce trein springen? Zijn KMO’s die het internet actief gaan inschakelen in hun bedrijf competitiever dan hun concurrent? Groeit de internet markt nog? En vertrouwt de consument dat online handeltje wel?

Een onderzoek van Boston Consulting Group toont aan dat België redelijk wat achter staat op gebied van internet economie, e-business en e-commerce. Het online aanbod groeit zeer geleidelijk, terwijl het aantal internetgebruikers en het vertrouwen in de markt elke dag groeit. Er zijn voor KMO’s dus nog heel wat mogelijkheden op Belgische internetmarkt. Ook blijkt dat KMO’s en bedrijven die het internet juist gaan inschakelen in hun strategie of hun operations, een stuk competitiever staan dan hun concurrenten.

Meer info en het volledige rapport van BCG op www.interneteconomy.be

Of je het nu leuk vindt of niet: een eerste indruk is belangrijk. Ook online. Een juiste profielfoto is zeer belangrijk. Dit heeft niets met ijdelheid te maken, wel met business. Een bezoeker die al dan niet toevallig op je LinkedIn profiel, Twitter account, Facebook pagina, je blog of de “about me” section van je website terechtkomt, vormt zich meteen een eerste indruk. En binnen de 2 seconden beslist die bezoeker of hij/zij blijft, dan wel op de “back button” klikt.

Wat precies een mooie profielfoto is en wat niet, laat ik aan u over. Smaken verschillen. Maar hou toch rekening met het volgende:

• Een neutrale achtergrond is vaak beter dan een stukje natuur, een speeltuin of een café. Met een neutrale achtergrond gaat de aandacht naar de persoon, niet naar de overladen achtergrond.
• Hou er rekening mee dat de foto vaak zeer klein is. Details zijn dus moeilijk zichtbaar. Hou het dus eenvoudig.
• Je haar even kammen en een hemd aantrekken vlak voor je de foto neemt kost geen geld. De foto zal (hopelijk) door enkele duizenden mensen gezien worden, dus die extra moeite kan er nog wel af…
• Zoom in op het gezicht. In klein formaat komt dit vaak beter over dan je hele lichaam in die paar pixels trachten te proppen. Niet heel je gezicht moet trouwens op de foto. Een “geknipte foto” is even goed.
• Je kan natuurlijk naar de fotograaf, en het resultaat zal zeker goed zijn. Maar dat hoeft niet per se. Tegenwoordig heeft iedereen wel een vriend(in) of kennis met een goed foto-aparaat en wat basiskennis om tot een degelijk resultaat te komen.

Ciao!