In dit artikel deel ik mijn ervaring met het selecteren van ideeën voor het ontwikkelen van de functionaliteit van onze producten en vertel ik u hoe u de belangrijkste ontwikkelingsvectoren kunt behouden.
We ontwikkelen een geautomatiseerd verrekeningssysteem (ACP) - facturering. Termijn
De levensduur van ons product is 14 jaar. Gedurende deze tijd is het systeem geëvolueerd van de eerste versies van een industrieel tariefsysteem naar een modulair complex bestaande uit 18 producten die elkaar aanvullen. Een van de belangrijkste aspecten van de levensduur van programma's is constante ontwikkeling. En ontwikkeling vereist ideeën.
ideeën
bronnen
Er zijn 5 bronnen:
- De belangrijkste vriend van een ontwikkelaar van bedrijfsinformatiesystemen is cliënt. En de klant is een collectief beeld van beslissers, projectsponsors, eigenaren en uitvoerders van processen, interne IT-specialisten, gewone gebruikers en een groot aantal geïnteresseerde individuen in verschillende mate. Wij vinden het belangrijk dat iedere vertegenwoordiger van de klant potentieel een ideeënleverancier is. In het ergste geval krijgen we alleen maar negatieve feedback over problemen in het systeem. In het beste geval is er een persoon aan de kant van de klant die een constante bron van ideeën voor verbetering is en die gestructureerde informatie verstrekt over de behoeften van de klant.
- Onze verkopers en accountmanagers zijn de tweede belangrijkste bron van ideeën voor verbetering. Ze communiceren actief en uitgebreid met vertegenwoordigers van de sector en ontvangen uit de eerste hand vragen over de factureringsfunctionaliteit van potentiële klanten. Verkopers en accounts moeten op de hoogte zijn van alle belangrijke veranderingen in hun functionaliteit en de nieuwste updates van de software van concurrenten, en in staat zijn de voor- en nadelen van verschillende oplossingen te rechtvaardigen. Dit zijn onze medewerkers die als eersten aanvoelen of bepaalde factureringsmogelijkheden een de facto standaard worden, zonder welke de software niet als compleet kan worden beschouwd.
- Product eigenaar — een van onze topmanagers of een zeer ervaren projectmanager. Houdt de strategische doelstellingen van het bedrijf voor ogen en past de productontwikkelingsplannen in overeenstemming daarmee aan.
- architect, een persoon die de mogelijkheden en beperkingen begrijpt van de gekozen/gebruikte technologische oplossingen en hun impact op de productontwikkeling.
Ontwikkel- en testteams. Mensen die direct betrokken zijn bij de productontwikkeling.
Classificatie van verzoeken
We ontvangen ruwe gegevens uit bronnen: brieven, tickets, mondelinge verzoeken. Alle
beroepen zijn geclassificeerd:
- Overleg met de betekenis "Hoe moet ik het doen?", "Hoe werkt het?", "Waarom werkt het niet?", "Ik begrijp het niet...". Dit soort verzoeken gaan naar de ondersteuningslijn Niveau 1. Het is mogelijk om het consult om te scholen naar andere soorten verzoeken.
- Incidenten met de betekenis "Werkt niet" en "Fout". Verwerkt door 2 en 3 ondersteuningslijnen. Als snelle correcties en het uitbrengen van een patch nodig zijn, kunnen deze rechtstreeks van de ondersteuning naar de ontwikkeling worden overgedragen. Het is mogelijk om het opnieuw te classificeren als een wijzigingsverzoek en het naar de backlog te sturen.
- Verzoeken om verandering en ontwikkeling. Ze komen in de productachterstand terecht en omzeilen de ondersteunende lijnen. Maar daarvoor geldt een aparte verwerkingsprocedure.
Er zijn statistieken over verzoeken: direct na de release neemt het aantal verzoeken gedurende korte tijd met 10-15% toe. Er zijn ook pieken in het aantal aanvragen wanneer een nieuwe klant met een groot aantal gebruikers naar onze clouddiensten komt. Mensen leren nieuwe softwaremogelijkheden gebruiken, ze hebben advies nodig. Zelfs een kleine klant verbrandt, wanneer hij in het systeem begint te werken, gemakkelijk meer dan 100 uur aan consulten per maand. Daarom reserveren wij bij het aanmelden van een nieuwe klant altijd tijd voor het eerste adviesgesprek. Vaak selecteren wij zelfs een specifieke specialist. De huurprijs dekt deze arbeidskosten uiteraard niet, maar na verloop van tijd egaliseert de situatie. De aanpassingsperiode duurt doorgaans 1 tot 3 maanden, waarna de behoefte aan begeleiding aanzienlijk wordt verminderd.
Voorheen gebruikten we zelfgeschreven oplossingen om aanvragen op te slaan. Maar geleidelijk zijn we overgestapt op Atlassian-producten. Eerst hebben we de ontwikkeling overgedragen om het werken volgens Agile makkelijker te maken, en daarna de ondersteuning. Nu leven alle kritische processen in Jira SD, plus worden ze ondersteund door verschillende plug-ins voor Jira, plus Confluence. Zelfgeschreven oplossingen bleven alleen over voor processen die niet kritisch waren voor de activiteiten van het bedrijf. Het blijkt dat onze taken nu transversaal zijn en kunnen worden overgedragen tussen ondersteuning en ontwikkeling zonder van het ene systeem naar het andere te springen.
Via deze link kunnen we gegevens verkrijgen over alle taken, geplande en werkelijke arbeidskosten, verschillende prijsopties voor klanten gebruiken en documentatie genereren voor interne behoeften en rapportage aan klanten.
Het verwerken van wijzigingsverzoeken
Dergelijke verzoeken komen doorgaans in de vorm van functionaliteitseisen. Onze analist bestudeert de aanvraag, maakt een specificatie en technische specificaties op topniveau. Geeft de specificatie en technische specificaties door aan de persoon die deze aanvraag ter goedkeuring heeft ingediend – wij moeten er zeker van zijn dat wij dezelfde taal spreken met de klant.
Nadat we van de klant de bevestiging hebben gekregen dat we elkaar goed hebben begrepen, voert de analist het verzoek in de product backlog in.
Beheer van productfunctionaliteit
De achterstand verzamelt binnenkomende verzoeken om verandering en ontwikkeling. De technische raad, bestaande uit de directeur, de hoofden ondersteuning, ontwikkeling, verkoop en de systeemarchitect, komt halfjaarlijks bijeen. In een discussieformat analyseert en prioriteert de raad de aanvragen uit de backlog en wordt overeenstemming bereikt over vijf ontwikkelingstaken voor implementatie in de volgende release.
In feite reageert de technische raad op de eisen van de industrie en de markt door de behoeften die in de aanvragen tot uiting komen te beoordelen. Alles wat van weinig relevantie is, blijft in de achterstand en komt niet in ontwikkeling.
Classificatie van wijzigingsverzoeken en financiën
Ontwikkeling is duur. Daarom vertellen wij u direct welke mogelijkheden wij hebben als het wijzigingsverzoek van een opdrachtgever komt en niet van een medewerker.
Wij classificeren wijzigingsverzoeken als volgt: branchebehoefte of individueel kenmerk van de onderneming; een aanzienlijke hoeveelheid nieuwe functionaliteit of een kleine oplossing. Kleine reparaties en individuele verzoeken worden zonder franje verwerkt. Individuele verzoeken worden voor een specifieke klant berekend en geïmplementeerd als onderdeel van projectwerk met hem.
Als dit geen enorme behoefte vanuit de industrie is en het volume aan functionaliteit groot is, kan besloten worden om een nieuwe aparte module te ontwikkelen die naast de hoofdfunctionaliteit verkocht gaat worden. Als een dergelijke aanvraag van een klant komt, kunnen wij de kosten voor het ontwikkelen van de module dekken, de module gratis of tegen gedeeltelijke betaling aan de klant ter beschikking stellen en de module zelf te koop aanbieden. In een dergelijke situatie neemt de cliënt een deel van de methodologische last op zich en voert hij in wezen zelf een pilot-implementatie van de module uit.
Als dit een enorme behoefte vanuit de industrie is, kan er besloten worden om nieuwe functionaliteit in het basisproduct op te nemen. De kosten komen in dit geval volledig voor onze rekening en de nieuwe functionaliteit verschijnt in de huidige versie van de programma's.
Oude klanten worden voorzien van een update.
Het kan ook zijn dat meerdere klanten een vergelijkbare behoefte hebben, maar dat deze niet in aanmerking komt voor een massaproduct. In dit geval kunnen we de specificatie naar deze klanten sturen en aanbieden om de ontwikkelingskosten onderling te verdelen. Uiteindelijk wint iedereen: klanten krijgen functionaliteit tegen lage kosten, wij verrijken het product en na verloop van tijd kunnen ook andere marktpartijen de functionaliteit voor hun gebruik krijgen.
DevOps
De ontwikkeling bereidt twee grote releases per jaar voor. In elke release wordt tijd gereserveerd voor de implementatie van 5 taken ontvangen van de technische raad. Zo vergeten we, midden in de routine, de productontwikkeling nooit.
Elke release ondergaat een passende reeks tests en documentatie. Vervolgens wordt deze release geïnstalleerd in de testomgeving van de betreffende klant, die op zijn beurt alles nauwgezet controleert en pas daarna wordt de release overgezet naar productie.
Naast het releasesysteem is er een format voor snelle bugfixes, zodat klanten zes maanden lang niet met fouten hoeven te leven. Met dit tussenformaat kunt u snel reageren op incidenten met de eerste prioriteit en aan de gestelde SLA's voldoen.
Al het bovenstaande geldt in de eerste plaats voor de zakelijke sector en on-premise oplossingen. Voor clouddiensten gericht op het MKB-segment zijn er niet zulke brede mogelijkheden voor klanten om mee te doen aan productontwikkeling. Het SMB-verhuurformaat gaat hier niet eens van uit. In plaats van een wijzigingsverzoek in de vorm van duidelijke eisen van de bedrijfspartij, is er hier alleen sprake van gewone feedback en wensen voor de dienstverlening. We proberen te luisteren, maar het product is enorm en de wens van één klant om iets bekends uit zijn oude historische systeem mee te nemen, kan in tegenspraak zijn met de ontwikkelingsstrategie van het systeem als geheel.
Bron: www.habr.com