Vorige maand hebben we onze klanten aan het werk gezet tijdens de 2018 FreeBalance International Steering Committee in Miami. De governanceworkshops maakten gebruik van agile ontwikkelingstechnieken aangepast aan de overheidscontext. FreeBalance gebruikt een unieke klantgerichte aanpak voor onze product- en serviceplannen. (Ja, we bieden advies, uitvoeringen duurzaamheid diensten.)
De roadmappraktijken van leveranciers van bedrijfssoftware zijn vergelijkbaar. Product Managers ontwikkelen roadmaps op basis van feedback van systeemintegratiepartners en verzoeken van klanten om functionaliteiten. De primaire klantverbinding met softwarefabrikanten is via systeemintegratiepartners. Deze systeemintegratiebedrijven genereren inkomsten door code aan te passen. Prikkels zijn niet noodzakelijkerwijs afgestemd op klanten. Fabrikanten zijn zelden direct betrokken bij implementaties.
Verzoeken om productverbeteringen komen bij softwarefabrikanten binnen via het ondersteuningskanaal van de klant. Fabrikanten hebben vaak geen contact met klanten. Van productmanagers wordt verwacht dat ze dit gebrek aan feedback compenseren. Geaccepteerde productmanagementpraktijken omvatten het beheren en trianguleren van feature-aanvragen. Product roadmaps worden "feature loterijen". De resultaten stellen vaak alle verticale markten in gelijke mate teleur.
![Beheer van projectroutekaarten: Aanpak voor Enterprise Resource Planning]()
Context en productroadmaps
Context begrijpen is de moeilijkste uitdaging voor Product Managers. Product Managers moeten vaak raden waarom klanten om bepaalde functies vragen. Welk probleem lost deze functie op? Is het een gedeeld probleem en zou het deel moeten uitmaken van het product? Roadmap management is vaak afhankelijk van de ervaring en mening van Product Managers. Product Managers moeten vaak meerdere verzoeken abstraheren om patronen te identificeren.
Dit komt in het kielzog van 'briljante' ideeën van leidinggevenden of push-back van ontwikkelteams die technische voorkeuren hebben. (Er is een gezegde dat zegt dat Product Managers een soort mini-CEO's zijn - dat is zeer misleidend omdat Product Managers geen 'hire and fire' privileges hebben).
Product Managers moeten vaak een evenwicht vinden tussen functiebehoeften en technologische ideeën. Opkomende technologie is interessanter, maar Product Managers worden vaak geconfronteerd met het creëren van geavanceerde oplossingen op zoek naar problemen.
Er wordt veel moeite gedaan om de toekomst van producten in kaart te brengen. Visio-diagrammen en PowerPoint-presentaties vliegen je om de oren. Softwarefabrikanten bouwen complexe roadmaps over vele jaren. Dit lijkt vreemd gezien de snelheid waarmee technologie verandert. We hebben talloze gevallen gezien waarin fabrikanten niet in staat waren om toekomstige behoeften te voorspellen. Veel nieuwe producten en nieuwe versies van bestaande Enterprise Software producten hebben te weinig respons gekregen van klanten.
Wat gebeurt er nadat grote bedrijven met Enterprise Software nieuwe markten betreden met optimistische roadmaps? Vaker wel dan niet moeten deze bedrijven wendbare bedrijven overnemen.
De traditionele routekaart voor bedrijfssoftware is kapot.
Klantgerichte aanpak zonder onderbroken routekaart
FreeBalance gebruikt al sinds 2007 een roadmap-stembenadering op FISC-conferenties. Deze aanpak wordt vergemakkelijkt door onze focus op de overheid. We verkopen niet aan andere "verticale markten". Het wordt ook vergemakkelijkt door onze betrokkenheid bij alle implementaties. We krijgen directe input van onze implementatiemedewerkers. En we krijgen indirecte input van systeemintegratiepartners en via directe verzoeken om functionaliteiten.
FISC biedt de context achter de punten van de routekaart. Onze routekaart wordt elk jaar bijgesteld in het FISC door middel van een stemproces. Zoals ik al in 2014 schreef:
In 2007 probeerden we de dynamiek van productgerichte naar klantgerichte evenementen te veranderen. Dit betekende dat veel van de ceremonie die geassocieerd wordt met leveranciersconferenties moest veranderen:
- Bedrijf naar de behoeften van de klant: de focus verleggen van wat het bedrijf nodig heeft naar wat klanten belangrijk vinden, ongeacht wat de bijdrage van FreeBalance aan oplossingen zou kunnen zijn.
- Verkopen aan betrokkenheid: De nadruk van het bedrijf verleggen van verkoop door de conferentie te bemannen met leidinggevenden en managers in plaats van verkopers. Klanten betrekken zodat we producten en diensten kunnen verbeteren.
- Dicteren om samen te werken: de dynamiek veranderen van dicteren welke producten wanneer worden geleverd naar klanten die productprioriteiten veranderen, de roadmap aanpassen en samenwerken aan gemeenschappelijke doelstellingen.
- Controleren op forum: het communicatieparadigma veranderen van gelikte en gecontroleerde presentaties naar een forum waar klanten andere klanten, externe sprekers en FreeBalance-medewerkers betrekken om te leren wat werkt bij de hervorming van Public Financial Management (PFM).
Hierdoor bevinden we ons in een interessante situatie, omdat leveranciers van bedrijfssoftware kopers hebben geconditioneerd in de verwachting van een op de leverancier gerichte roadmap in plaats van een op de klant gerichte roadmap.
feedbacklussen. Potentiële klanten willen onze roadmap voor 5 of 10 jaar zien. We zouden een document kunnen maken dat aan deze doelstelling voldoet, maar dat is een oefening in futiliteit. Onze roadmap voor producten en services verandert jaarlijks. Technologiecycli zijn samengedrukt. Zoals hierboven aangegeven, richten we ons op de overheid en de Onderdeel Kaart van het beheer van de overheidsfinanciën. Dit is de kernvisie achter de FreeBalance Accountability Suite. Onze routekaart wordt begrensd door deze componentenkaart. Effectief, onze routekaart omvat alles in de PFM Component Map.
Onze roadmap bestaat uit items die worden verwacht voor 1 jaar, 2 jaar en 2+ jaar. Deze veranderen elk jaar. Daarom maken we gebruik van agile processen en integreren we productontwikkeling met implementatieservices in onze A-i3+qM TM methodologie.
FreeBalance Roadmap Trends
Dit was mijn 12e jaar in het verzamelen van feedback van onze product roadmap. Het is een fascinerende reis geweest om stijgende aspiraties en bestuurlijke pijnpunten bloot te leggen. Enkele trends die ik heb gezien zijn:
- Toevoeging van een routekaart voor diensten vanwege hiaten bij traditionele dienstverleners en donorpartners
- Meer aandacht voor niet-functionele vereisten, met name voor verbeterde onderhoudbaarheid, lagere bedrijfskosten en verbeterde integratie met niet-FreeBalance-subsystemen
- Verhoogde technologische kennis en capaciteit
- Gebruiksoplossingen ontdekken die de trainingsvoetafdruk verminderen
De roadmap voor 2018 bevatte producten en diensten met opkomende technologieën zoals "blockchain", machine learning, low-code ontwikkeling en slimme overheid.
We hebben dit jaar meer tijd besteed aan het verwoorden van de voordelen van producten en diensten dan in voorgaande jaren. Deze voordelen werden afgestemd op de eisen die veel overheden stellen op het gebied van overheidsfinanciën, ambtenarenzaken en transparantie. Ik ben blij te kunnen zeggen dat het belangrijkste item op de roadmap voortkwam uit de brainstorm van FISC-klanten. (Een van mijn ideeën werd tweede met 98% van de stemmen van het top item).
Agile breidt productroadmaps organisch uit
We hebben onze software herschreven met een component-level Service-Oriented Architecture (SOA). Hierdoor konden we nieuwe applicaties samenstellen op basis van herbruikbare bedrijfscomponenten, die we "overheidsinstanties"in een uniform ontwerp. Dit hergebruik vergemakkelijkt onze product roadmap.
Deze aanpak maakt ook ontwikkeling op maat mogelijk, waaronder de ontwikkeling van unieke overheidstoepassingen. Deze komen voort uit unieke hervormingswetten. Maar bijna alle FreeBalance-implementaties zijn onderworpen aan unieke wetgeving. Onze benadering van deze situatie wijkt af van de marktnormen.
Systeemintegratiebedrijven passen code aan voor specifieke behoeften. Dat is de geaccepteerde praktijk. Zoals beschreven in een bericht van vorige weekHierdoor blijven klanten achter met verweesde code en technische schuld.
FreeBalance maakt altijd deel uit van implementatiecontracten met de overheid. Aanpassing aan unieke behoeften zijn contractuele vereisten.
FreeBalance past in de meeste situaties code aan voor klanten. FreeBalance heeft een geïntegreerde ontwikkelomgeving (IDE) gebouwd op Eclips. Partners en klanten kunnen worden getraind. Weinig klanten hebben dit gedaan vanwege de elegantie van de A-i3+qM TM methodologie voor ontwikkeling op maat.
- FreeBalance servicemedewerkers op locatie bouwen storyboards en use cases interactief met klanten
- De medewerkers van het FreeBalance-productbeheer valideren deze input met behulp van technologische kennis en identificeren aanvullende manieren waarop overheidsentiteiten kunnen worden uitgebreid voor andere vereisten van de PFM Component Map.
- De gevalideerde storyboards en use cases worden goedgekeurd door klanten
- FreeBalance productmanagement medewerkers ontwikkelen specificaties
- FreeBalance productontwikkeling valideert de specificaties voordat code wordt ontwikkeld
- De medewerkers van FreeBalance op locatie dragen bij aan de kwaliteitsborging om ervoor te zorgen dat het resultaat voldoet aan de behoeften van het land.
- Client User Acceptance Testing valideert het gebruik van de code in productie (of toont aan dat de specificaties moeten worden aangepast)
Het bovenstaande diagram suggereert dat het proces eindigt met de goedkeuring van de UAT van de klant. Dat is een beetje misleidend, want het beëindigt alleen het proces om software in productie te krijgen.....