Op de Mobile Convention Amsterdam waren veel verschillende verhalen te horen. Een interessant verhaal werd gehouden door Ton van Dijk (KPMG) en Arco van der Velde (BLiS) over het ontwikkelen van mobiele applicaties voor KPMG. Hun stelregel was eigenlijk dat alleen door mislukkingen je leert iets succesvol te maken. Hun verhaal beschreef de samenwerking van de afgelopen paar jaar en de verschillende apps die samen zijn ontwikkeld.
Ton van Dijk (KPMG) en Arco van der Velde (BLiS) presenteerden hun verhaal als een tweepersoons stand-up comedy. Met een lach en een traan werd verteld over hun gezamenlijke ervaringen. KPMG is een grote wereldwijde organisatie die de behoefte heeft om een aantal zaken voor medewerkers en klanten te vereenvoudigen. Mobiele apps zijn ontwikkeld om in die behoeften te voorzien. BLiS is een kleine partij die goed is in het ontwikkelen van apps. Maar het is niet eenvoudig om als grote multinational een contract te sluiten met een kleine developer.
De lessen die daarbij werden gegeven:
* Een partnership kost tijd en
* Een partner moet je kunnen vertrouwen
Een van de eerste projecten was niet op tijd klaar. Het leerpunt daar was: De noodzakelijke koppeling met de back-end en de infrastructuur zijn sterk bepalend voor het gereed zijn van de mobiele app.
Een volgend project betrof de KPMG One app, waarbij gebruikers nieuwscontent kunnen personaliseren, waarmee kennis en inzicht makkelijk gedeeld kunnen worden. De app geeft informatie die uit allerlei bronnen worden gehaald. Het leerpunt hier was: De kwaliteit van de app is sterk afhankelijk van de content managers, de app is slechts een framework voor de informatie.
Een volgend leerpunt betrof project uitvoering: Agile werkt goed als methodiek, maar je weet van te voren niet wat je krijgt. Neem iedereen mee in het proces en neem er de tijd voor. Een project dat gestart is met een vaste prijs en een vaste scope gaat niet samen met een Agile-uitvoering!
Klein werd viraal
In de afgelopen jaren is ook gewerkt aan een app om samenwerking te bevorderen en review te vereenvoudigen. Dat was klein begonnen maar werd als snel een viraal project. Het is door twintig landen binnen KPMG getoetst. Uiteindelijke zou de app vijftig verschillende talen moeten ondersteunen en aan hoge security eisen moeten voldoen. Het leerpunt was hier: Een app kan steeds groter en groter worden tot het nagenoeg onwerkbaar is. Je loopt het risico op een app uit te komen die misschien beter door Microsoft of Adobe geleverd kan worden.
Een ander leerpunt was: Bij de start is iedereen enthousiast, maar het kan toch maanden duren om de beslissing genomen te krijgen. Een jaar verder was er nog geen go voor het budget. Het lijkt daarmee op een marathon lopen. Het advies was: hou vol, soms is het gewoon bijzonder lastig.
Bij een volgende app werd besloten om de ontwikkeling anders te doen: Als je wil innoveren, moet je soms buiten de hokjes durven kleuren en onder de radar blijven
Bij innovatie gaat niet alles goed, je gaat vaak op je bek. Het is belangrijk om samen op pad te gaan en je boerenverstand te gebruiken. Blijf goed nadenken, je kunt niet alles voorzien.
Tot slot een wijze les: Wees jezelf, heel veel innovaties lukken niet, maar blijf het doen! We leven in een gave tijd met veel mogelijkheden.
Ik zie een reeks van …. lees hier, les daar….
Het bouwen van een app verschilt in niets van het bouwen van software. Requirements en proces zijn namelijk volkomen dezelfde en heb je die niet op een rij, dan krijg je …. een geleerde les?
Leerpunt een back-end en die sterk bepalend zijn voor het gereed zijn van je app?
Dan schud ik mijn hoofd. Immers, in de meest basale denkbare keten iets te produceren ga je na wat je requirements zijn en als je back-end en infrastructuur hier naar voren komen als showstopper, zeg ik zelfs, wat doe je in de app bizz?
De wetmatigheden en de ketens zijn namelijk geheel en al dezelfde als die voor IT en telefonie. Als de klant dit soort triviale zaken mag betalen dan is dit tekenend voor je naam en reputatie.
Er zijn wat zaken die een app een succes maken.
– Het werkt
– Het werkt
– Het werkt
– Het smoelt goed
– Heeft op de ene of andere manier toevoegende waarde
– Is voor gebruikers aantrekkelijk
– Gebruiks en installatie gemak
– Hij word gehyped en wordt in korte tijd heel populair
– Hadden we al genoemd dat het moest w…. oh ja….
Kortom, een app is een eenvoudig stukje software met toevoegende waarde voor de gebruiker en niet iedereen hoeft die toevoegende waarde te zien natuurlijk, daarom is het een app. Niet iedereen hoeft hem te willen zien.
Ga je een stuk software maken dat feitelijk niet als app is geschikt omdat het daar te groot voor is? Dan begrijp ik deze stelling wel, Had ik overigens ook vermeld dat mijn vermoeden is dat men tijdens de bouw en ontwikkeling hoogstwaarschijnlijk zaken aan het toevoegen is geweest?
René, ja een app bouwen is software, maar een app bouwen voor een mobiele telefoon is niet zoals je schrijft (“Kortom, een app is een eenvoudig stukje software”) een eenvoudig stukje software.
Wie dat schrijft…. heeft *geen* *clue*.
“De wetmatigheden en de ketens zijn namelijk geheel en al dezelfde als die voor IT en telefonie”
Je simplicificeert extreem. Het is alsof je zegt “Oh, software, uiteindelijk zijn dat gewoon nullen en eenen.”
Om je een paar hints te geven waarom app ontwikkeling rocket science is.
– Background processes.
– Offline / online data opslag
– multulingual en zoiets simpels als tijdzones
– security
Maak jij maar eens een mooie app die ook nog goed met beacons kan praten en liefst zonder de stroom van een batterij op te eten tijdens background processes. Good luck with that.
Als mensen zo simpel over software en apps praten dan klinkt dat in mijn oren hetzelfde als Ton Elias die niet weet wat een IP adres is.
Ik vind dit een heel leuk artikel!
En wat je hier hoort lijkt ook op een typisch geval van “Valley of death innovation”
Een innovatie omzetten naar een marktproduct is een pittige reis die het product vaak niet overleefd.
Innovatieve Apps zijn een stuk complexer dan hun desktop counterparts. Laat de beperkte scope je niet van de wijs brengen.
@Henri
Sec, er is heel eenvoudig een keten die je het beste volgt, maar die klaarblijkelijk door mensen niet word gevolgd met als gevolg publicaties als deze. Ik vind dat natuurlijk heel erg prima, ik hoef namelijk de rekeningen niet te betalen maar het is telkens weer verrassend herhalend.
Het maakt mij feitelijk niet uit hoe jij aan kijkt tegen dit gegeven en telkens weer de diepte in duikt, feit blijft dat dat proces en de wetmatigheden die daar mee gepaard gaan gewoon onveranderd dezelfde blijft, wat het dan weer, wat mij betreft voorspelbaar blijft houden.
Simpel gesteld, sla je een stap over in dat proces, hou je je niet aan dat proces, heb je geen idee van dat proces, krijg je dit soort publicaties en dito heel veel rekeningen. Ik weet niet hoe jij daar tegen aan wil kijken maar voor mij is automatiseren/mechaniseren nog steeds een zaak van proces versnellen en daar je winst uit halen. Niet lessen leren die je feitelijk nu niet meer zou hoeven leren.
Om even jouw voorbeeld aan te halen wat Ton Elias betreft, Ton had het ‘jargon’ aardig op zijn netvlies, maar weet niets van een proces. Uitkomst, wederom zeer voorspelbaar, vijf mensen, geen idee van IT, ruim een jaar en enkele miljoenen verder, komen met een dik boekwerk die aan een dame word gegeven die die ochtend toch nog even moest googlen wat ICT toch ook alweer niet was.
Uitkomst van dat onderzoek, BIT, ofwel heel eenvoudig IT Change management standaard uit het boekje en de kast.
Even terug naar dat procesje mijn beste Henri, volkomen los van wat jij vanuit jouw kennis en expertise respectvol aan brengt, aan dat proces ben ook jij gebonden en hou jij je niet aan dat proces, dan krijg je daarvoor gegarandeerd tijdverlies en hoge rekeningen terug. Tenminste, als je dat voor een opdrachtgever doet.
Software
Jij vult hier iets in voor mij dat je mij niet hebt zien plaatsen. De werkende apps die ik heb getest, dat zijn er best wel wat in die tussentijd, zijn relatief eenvoudig, zitten goed doordacht in elkaar en werken omdat het doel helder was. Gemene deler daar, meisjes/jongens die een leuk idee hadden en daarmee stoeiden en daar iets leuks uit kregen dat vervolgens een soort van viraal gaat. Goh, als ik dan kijk naar de succesvolle andere apps…..
De benadering en proces van software en app zijn gelijk Henri, volkomen gelijk, like it or not.
Henri,
Zie opmerking van René over toegevoegde waarde voor de gebruiker, factorisatie-probleem in de keten komt uiteindelijk neer op P ≠ NP die stelt dat je snel ziet of duizend stukjes van een puzzel op de juiste wijze gelegd zijn maar vice versa zegt het niets over de moeilijkheid van de puzzel (proces?) zelf. Ontwikkelen van software of apps is in wezen niet verschillend, de wijze van testen helaas wel.
Ewout, en testen van software is geen onderdeel van het maken van apps?
René verwart IT met project processen.
Ewout; laat ik het naar jouw wereld vertalen. Storage is niets anders als input/output. Dus storage leveren is altijd hetzelfde, of is dat nu Rene zijn verhaal? Als iemand zoiets roept weet jij toch ook wel beter?
Wat is in hemelsnaam nu de definitie van “Het werkt”? Dat is net zo onzinnig als “Het is veilig”. Of IT is 100% voorspelbaar.
Het verhaal en de argumenten van dit artikel zijn gewoon valide. Er is niet zoiets als zekerheid over het succes van een software (of app) project.
Oh Jee . . .
“Ontwikkelen van software of apps”
laat ik nu toch gedacht hebben dat “apps” en “software” precies het zelfde zijn.
Om met Rene te spreken, is dat een “les”: een “app” is volgens Guru Ewout geen Software!
Interessant!
Henri,
Mijn wereld is Enterprise Architectuur en vanuit het software perspectief is met name de Enterprise Lifecycle hierin interessant. Storage is trouwens heel wat meer dan I/O als we kijken naar CIA principe hierin, digitale residu van apps in de vorm van data moet vaak heel wat langer bewaard worden dan de app zelf. De P ≠ NP van ongestructureerde data en alle
beloften van moderne datasynthese levert weer prachtige puzzels op;-)
Lezen kost niets maar schrijven daarentegen…..
Een app is gewoon een C/S oplossing op een ander apparaat, ontwikkeling ervan is exact
hetzelfde als eerdere desktop software. De lifecycle (Consumerization of IT?) van devices is echter geheel anders wat een andere manier van testen (CI) vraagt. Onderhoudbaarheid van een app wordt dan ook grotendeels bepaald door de modulariteit ervan. Hints die je geeft over de complexiteit zijn al lang opgelost met architectuur lagen zoals middleware.
P.S.
Veel apps zijn afhankelijk van een framewerk (Domino?) welke uiteindelijk ook weer legacy wordt als we kijken naar het probleem van lifecycles,
Ondanks mijn geintje, super samengevat.
Vooral “digitale residu” is een ijzersterk punt.
Bij de korte levensduur van vele “apps” wordt de toekomst spannend, kun je in 5, 10, 15 jaar die data nog op een zinvolle manier lezen/gebruiken?
Typisch geval van “doelgerichtheid van techniek in ruimte en tijd”. Techniek kent de begrippen doelgericht, ruimte en tijd niet. Voor ons mensen heel gewoon (?), voor softwareontwikkelaars dus ook.
De paradox ontstaat door de veranderingen in de samenleving. Middelen, bv informatie, zijn doelen geworden. Informatie is echter niet “los verkrijgbaar”. Door er toch in te handelen is een informatiemarkt (aan het) ontstaan die qua omvang de geldmarkt zal overstijgen. ICT heeft de techniek geleverd waardoor een virtuele geldmarkt is ontstaan die ongeveer 25x zo groot is als de reële economie. De paradox van een aandeel”houder” is dat hij veranderd is tot aandeel”wisselaar” met een transactiekosten optimalisatie ipv een aandeel in de waarde van een bedrijf voor de samenleving.
“KPMG is een grote wereldwijde organisatie die de behoefte heeft om een aantal zaken voor medewerkers en klanten te vereenvoudigen”. De paradox hiervan is dat de samenleving als geheel hier baat bij heeft. Maar dat is waarschijnlijk niet het doel van KPMG.
De vraag is derhalve: hoe kunnen we met ICT bijdragen aan een – mondiale – samenleving werken waarin we een aandeel hebben in elkaar? Of is dat doel ook al geframed in een verdienmodel?
@Jan
Noem mij eens een app die je na 5, 10, 15 jaar nog wilt lezen/gebruiken.
Je bent toch niet in het WordPerfect / AstonTate / Microsoft tijdperk blijven hangen?
Maakt ’t uit was ook laat voor je gisteren… dan gebeuren zulke ‘dingen’. ;D
Wij schrijven onze app’s in Java – hoe moeilijk kan dat zijn?
Inderdaad, bijzonder is het Zeker niet, maar (intern) zeer bruikbaar.