Ik ben betrokken geweest bij softwareontwikkeling in zowel mijn eigen bedrijven als die van onze klanten. Er zijn een paar dingen die ik in de loop der jaren heb geleerd over softwareontwikkeling. Misschien vindt u enkele van deze ervaringen nuttig.
Ik denk dat er in wezen twee paden zijn naar softwareontwikkeling: probleemgericht en idee-gebaseerd . Beide benaderingen kunnen geweldige resultaten opleveren. Het eerste biedt echter vaak een gemakkelijkere weg naar succes.
Een probleem met software oplossen
Meer dan tien jaar geleden hielpen mijn collega's en ik bepaalde organisaties bij het verbeteren van hun IT-governance en projectmanagement. We ontdekten dat ze niet goed waren in het managen van al hun projecten, de projectportefeuille. Een portfolio kan jaarlijks honderden projecten bevatten ter waarde van miljoenen.
Een typisch probleem voor onze klanten was het kiezen van de projecten waarin ze zouden investeren. Ze gebruikten financiële maatstaven – voornamelijk kosten – en hadden slechts een vaag idee van de voordelen die het project zou opleveren. Ze hadden ook moeite om te bepalen welke projecten strategisch de moeite waard waren.
Het derde probleem was communicatie. Er waren formulieren voor projectvoorstellen en projectbeheersing, maar het algemene beeld was onduidelijk. Functionele afdelingen gebruikten spreadsheets om hun respectieve projectportfolio's op te sommen. Managementteams wisten niet zeker of ze de juiste projecten hadden, de algehele impact van de portefeuille en de risiconiveaus van de projecten.
We zagen de pijn van onze klanten en realiseerden ons dat ze hulp nodig hadden bij zowel het beheer van het proces als de portefeuille. Geïnspireerd door de voor de hand liggende behoefte, heb ik een paar prototypes van portfoliomanagementsoftware gemaakt. Het zou visueel de nodige informatie van een enkel project en de hele portefeuille communiceren.
Toen de klanten mijn prototypes zagen en begonnen te vragen waar ze de software konden kopen, wisten we dat we iets op het spoor waren. Tegenwoordig heeft onze software-as-a-service, genaamd Thinking Portfolio , tienduizenden gebruikers in meer dan 50 landen.
Veel softwareontwikkelaars die ik heb geïnterviewd voor mijn blog en podcast, hebben een soortgelijk verhaal gedeeld. Ze hebben in het bedrijf gewerkt of waren ermee verbonden en ontdekten een probleem dat al jaren bestaat. Het probleem is niet pijnlijk genoeg geweest om een goede oplossing te vereisen. Niemand staat stil bij de werkelijke kosten die het niet oplossen van het probleem door de jaren heen genereert. Wanneer iemand op het probleem wijst en een haalbare oplossing bedenkt, zijn ze klaar om het te kopen.
Dit is wat ik essentieel vond bij het ontwikkelen van een succesvolle probleemgebaseerde oplossing:
- U moet de zaken van de klant begrijpen en 'hun taal spreken'
- Het management van de klant, bij voorkeur het uitvoerend management, moet weten dat het probleem bestaat en moet ook een oplossing willen
- Uw oplossing moet het probleem op een nieuwe, misschien onverwachte manier oplossen
- Uw oplossing mag geen nieuwe problemen opleveren; het mag niet te traag, moeilijk of duur zijn om te implementeren
- Sociaal bewijs is goed; het hebben van gelijkaardige klanten die dezelfde keuze hebben gemaakt, schept vertrouwen
- Uw oplossing moet zowel de beslisser als de gebruikers tevreden stellen
Een idee omzetten in software
Ik heb altijd veel ideeën voor softwareoplossingen gehad en heb er enkele commercieel van weten te maken. De ideeën zijn het resultaat van het verkennen van nieuwe technologieën en het bedenken van toepassingen die vaak verband houden met een hogere productiviteit.
Toen internetapps nog vrij zeldzaam waren, kwam ik op het idee om een eenvoudige tool te maken voor het maken van online enquêtes. Ik ontwierp de tool en maakte er met behulp van een programmeur, Timo Gunst , een product van. We hebben het verkocht aan professionele onderzoeksbureaus. Ze installeerden het op hun eigen servers en konden onbeperkt enquêtes produceren zonder externe hulp, wat hen veel tijd en geld bespaarde. Onze tool was ook redelijk betaalbaar in vergelijking met andere oplossingen op de markt.
Later heb ik andere op ideeën gebaseerde tools gelanceerd, bijvoorbeeld voor ideevorming, projectcommunicatie, risico-identificatie, beoordelingen van managementvolwassenheid en het verzamelen van feedback van klanten.
Bij het maken van software die op ideeën is gebaseerd, is het een goede gewoonte om te beginnen met een werkend prototype. Het kan een visueel of functioneel prototype zijn. Klanten kunnen het uitproberen en zeer snel feedback geven over het nut ervan en hoe het kan worden verbeterd. Pas daarna moet u beslissen of u meer geld in ontwikkeling wilt investeren.
U mag nooit iets aannemen bij het ontwikkelen van op ideeën gebaseerde software. Je eigen aannames doen er niet toe als de klant zegt dat 'dit niet werkt' of 'ik zou dit niet gebruiken'.
Veel ontwikkelaars willen hun product perfect maken voordat ze worden gelanceerd. Guy Kawasak i heeft notoir gezegd: “Maak je geen zorgen. Wees waardeloos. " Hij bedoelt duidelijk niet dat u software met fouten moet verkopen. Hij bedoelt dat uw software niet in alle opzichten compleet of perfect hoeft te zijn om bruikbaar en verkoopbaar te zijn.
Een bijzondere uitdaging bij het verkopen van op ideeën gebaseerde software is dat uw klant de waarde ervan misschien niet op voorhand ziet. Daarom is het essentieel om klanten te vinden die uw enthousiasme en bereidheid delen om nieuwe dingen uit te proberen.
Enige tijd geleden presenteerde ik aan een vereniging een prototype van een simpele 360 graden smartphone feedback app. Werknemers en managers op een bouwplaats zouden het gebruiken om elkaar feedback te geven en te ontvangen.
De vereniging kocht het idee niet. Het was "te licht" naar hun zin. Later ontdekte ik dat iemand anders een vergelijkbare app in een andere branche had gemaakt en lovende recensies kreeg. Ik weet zeker dat sommigen van jullie hetzelfde hebben meegemaakt!
Doe Maar!
Tegenwoordig is het gemakkelijker dan ooit om ideeën en oplossingen voor een probleem om te zetten in software. Het kan een op zichzelf staande oplossing zijn of een uitbreiding op bestaande software.
Er is veel ruimte voor digitale tools in de bouw. Ik raad je aan om open standaarden te gebruiken om te communiceren met andere systemen en diensten. Op die manier is uw software niet zomaar een app, maar onderdeel van een groter ecosysteem.
Via: AEC