Overheden wijzigen FreeBalance Product Roadmap jaarlijks class=

Overheden veranderen jaarlijks de FreeBalance Product Roadmap

Internationale stuurgroep FreeBalanceWe hebben onze klanten aan het werk gezet tijdens de 2018 FreeBalance International Steering Committee in Miami vorige maand. De governanceworkshops maakten gebruik van agile ontwikkelingstechnieken aangepast aan de overheidscontext. FreeBalance hanteert een unieke klantgerichte aanpak voor onze product- en diensten roadmap. (Ja, we bieden adviesuitvoeringen duurzaamheid diensten.)
Roadmaps van leveranciers van bedrijfssoftware zijn vergelijkbaar met die van andere leveranciers. Productmanagers ontwikkelen roadmaps op basis van feedback van systeemintegratiepartners en wensen van klanten. De primaire klantverbinding met softwarefabrikanten verloopt via systeemintegratiepartners. Deze systeemintegratiebedrijven genereren inkomsten door aanpassing van de code. Prikkels zijn niet noodzakelijkerwijs afgestemd op klanten. Fabrikanten zijn zelden rechtstreeks betrokken bij implementaties.
Verzoeken om productverbeteringen komen bij softwarefabrikanten binnen via het klantondersteuningskanaal. Fabrikanten staan vaak los van hun klanten. Van productmanagers wordt verwacht dat zij dit gebrek aan feedback compenseren. Geaccepteerde product management praktijken omvatten het beheren en trianguleren van feature requests. Product roadmaps worden "feature loterijen". De resultaten stellen vaak elke verticale markt in gelijke mate teleur.

Project Roadmap Management: Aanpak van Enterprise Resource Planning
Context en Product Roadmaps

Het begrijpen van de context 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 gemeenschappelijk probleem en moet het deel uitmaken van het product? Roadmap management berust vaak op de ervaring en mening van Product Managers. Product Managers moeten vaak meerdere verzoeken abstraheren om patronen te herkennen.
Dit gebeurt na 'briljante' ideeën van leidinggevenden, of tegenwerking van ontwikkelteams met technische voorkeuren. (Er is een gezegde dat Product Managers zijn als mini-CEO's - dat is zeer misleidend omdat Product Managers geen 'hire and fire' privileges hebben).
Product Managers moeten vaak een evenwicht vinden tussen de behoefte aan functies 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 uit over vele jaren. Dit lijkt vreemd gezien de snelheid waarmee de technologie verandert. Wij hebben talloze gevallen gezien waarin fabrikanten niet in staat waren 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 Enterprise Software bedrijven nieuwe markten betreden met optimistische roadmaps? Vaker wel dan niet moeten deze bedrijven wendbare bedrijven overnemen.
De traditionele Enterprise Software roadmap aanpak is gebroken.

Klantgerichte ononderbroken routekaartaanpak

FreeBalance gebruikt al sinds 2007 een roadmap voting aanpak op FISC conferenties. Deze aanpak wordt vergemakkelijkt door onze focus op de overheid. We verkopen niet aan een andere "verticale markt". 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.
Product Roadmap Management: Klantgerichte aanpak
Het FISC biedt de context achter de punten van de routekaart. Onze routekaart wordt elk jaar in het FISC aangepast via een stemprocedure. Zoals ik al in 2014 schreef:
In 2007 probeerden wij de dynamiek te veranderen van productgerichte naar klantgerichte evenementen. Dit betekende dat veel van de ceremonie die met leveranciersconferenties gepaard gaat, moest veranderen:

  • Bedrijf naar de behoeften van de klant: de focus verleggen van wat het bedrijf nodig heeft naar wat de klanten bezighoudt, ongeacht wat de bijdrage van FreeBalance aan oplossingen zou kunnen zijn.
  • Verkopen aan betrokkenheid: het accent 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 de productprioriteiten veranderen, de roadmap aanpassen en samenwerken voor gemeenschappelijke doelstellingen.
  • Controle op het 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 het openbaar financieel beheer (PFM).

FreeBalance Product Roadmap
Dit brengt ons in een interessante situatie, omdat leveranciers van bedrijfssoftware de kopers hebben geconditioneerd in de verwachting van een op de leverancier gericht stappenplan in plaats van een op de klant gericht stappenplan.
feedback loops. Potentiële klanten willen ons stappenplan voor 5 of 10 jaar zien. We zouden een document kunnen opstellen dat aan deze doelstelling voldoet, maar dat is een oefening in futiliteit. Onze roadmap voor producten en diensten 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.
PFM-componentenkaart
Onze routekaart bestaat uit items die voor 1 jaar, 2 jaar en 2+ jaar worden verwacht. Deze veranderen elk jaar. Daarom maken we gebruik van agile processen en integreren we productontwikkeling met implementatiediensten in onze A-i3+qTM methodologie.

FreeBalance Roadmap Trends

Dit was mijn 12e jaar waarin ik feedback verzamelde over onze product roadmap. Het is een fascinerende reis geweest om de aspiraties en pijnpunten van het bestuur bloot te leggen. Enkele trends die ik heb gezien zijn:

  • Toevoeging van een routekaart voor diensten vanwege lacunes bij traditionele dienstverleners en donorpartners
  • Meer aandacht voor niet-functionele eisen, met name voor betere onderhoudbaarheid, lagere bedrijfskosten en betere integratie met niet-FreeBalance-subsystemen.
  • Grotere technologische kennis en capaciteit
  • Usability-oplossingen ontdekken die de trainingsvoetafdruk verminderen

De roadmap van 2018 had producten en diensten met opkomende technologieën zoals "blockchain", machine learning, low-code ontwikkeling en smart government.
Wij hebben dit jaar meer tijd besteed aan het verwoorden van de voordelen van producten of diensten dan in voorgaande jaren. Deze voordelen werden afgestemd op de eisen van de overheid op het gebied van financiën, ambtenarenzaken en transparantie die veel overheden delen. 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% aan stemmen van het toppunt).

Agile breidt Product Roadmaps organisch uit

We hebben onze software herschreven met een op componenten gebaseerde Service-Oriented Architecture (SOA). Zo konden we nieuwe toepassingen samenstellen op basis van herbruikbare bedrijfscomponenten, die we "overheidsinstanties"in een uniform ontwerp. Dit hergebruik vergemakkelijkt onze product roadmap.
FreeBalance Agile 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 een of andere 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 weekDit laat klanten "hoog en droog" 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 aangepast ontwikkelingsproces
FreeBalance past in de meeste situaties code aan voor klanten. FreeBalance heeft een geïntegreerde ontwikkelingsomgeving (IDE) gebouwd op Eclips. Partners en klanten kunnen worden opgeleid. Weinig klanten hebben dat gedaan vanwege de elegantie van de A-i3+qTM methode voor ontwikkeling op maat.

  • FreeBalance on-site diensten medewerkers bouwen storyboards en use cases interactief met klanten
  • De medewerkers van het FreeBalance-productbeheer valideren deze input met behulp van technologische kennis, en stellen vast hoe overheidsentiteiten kunnen worden uitgebreid voor andere vereisten van de PFM Component Map.
  • De gevalideerde storyboards en use cases worden goedgekeurd door klanten
  • De medewerkers van het FreeBalance-productbeheer ontwikkelen specificaties
  • FreeBalance productontwikkeling valideert de specificaties alvorens code te ontwikkelen
  • Het personeel van FreeBalance on-site diensten draagt 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 Client UAT. Dat is een beetje misleidend, want het beëindigt alleen het proces om software in productie te krijgen.....

Onderwerpen

Neem contact op met