I den här artikeln kommer jag att dela med mig av min erfarenhet av att välja idéer för utveckling av funktionaliteten hos våra produkter och berätta hur du behåller de viktigaste utvecklingsvektorerna.
Vi utvecklar ett automatiserat avvecklingssystem (ACS) - fakturering. Termin
Vår produkts livslängd är 14 år. Under denna tid har systemet gått från de första versionerna av en industriell bedömare till ett modulärt komplex bestående av 18 produkter som kompletterar varandra. En av de viktigaste aspekterna av livslängd för program är kontinuerlig utveckling. Och idéer behövs för utveckling.
idéer
källor
Det finns 5 källor:
- Den främsta vän till utvecklaren av företagsinformationssystem är kund. Och uppdragsgivaren är en samlad bild av beslutsfattare, projektsponsorer, ägare och utförare av processer, interna IT-specialister, vanliga användare och ett stort antal personer som är intresserade i varierande grad. Det är viktigt för oss att var och en av kundens representanter potentiellt är en idéleverantör. I värsta fall får vi bara negativ feedback om problem i systemet. I bästa fall finns det en person på kundsidan som är en ständig källa till idéer för förbättringar, som ger strukturerad information om kundens behov.
- Vår säljare och kontoansvariga är den näst viktigaste källan till idéer för förbättringar. De kommunicerar mycket och aktivt med branschrepresentanter, tar emot förstahandsförfrågningar om faktureringsfunktionalitet från potentiella kunder. Handlare och konton måste vara medvetna om alla betydande förändringar i deras funktionalitet och de senaste mjukvaruuppdateringarna från konkurrenter, kunna motivera för- och nackdelarna med olika lösningar. Det är dessa anställda hos oss som är de första att känna om vissa faktureringsfunktioner blir en de facto-standard, utan vilken programvaran inte kan anses vara komplett.
- Produktägare är en av våra högsta chefer eller en mycket erfaren projektledare. Håller företagets strategiska mål i åtanke och anpassar produktutvecklingsplanerna i enlighet med dem.
- arkitekt, en person som förstår möjligheterna och begränsningarna hos de valda/använda tekniska lösningarna och deras inverkan på produktutvecklingen.
Utvecklings- och testteam. Personer som är direkt involverade i produktutveckling.
Klassificering av träffar
Vi tar emot rådata från källor - brev, biljetter, muntliga förfrågningar. Allt
överklaganden klassificeras:
- Samråd med betydelsen "Hur gör man?", "Hur fungerar det?", "Varför fungerar det inte?", "Jag förstår inte...". Samtal av denna typ går till nivå 1 Support Line. Det är möjligt att omskola samrådet till andra typer av överklaganden.
- Incidenter med betydelsen "Fungerar inte" och "Fel". Hanteras av 2 och 3 stödlinjer. Om det är nödvändigt att snabbt fixa och släppa en patch kan den överföras från support direkt till utveckling. Det är möjligt att omklassificera den till en ändringsförfrågan och skicka den till backloggen.
- Önskemål om förändringar och utveckling. Gå in i produktstocken och kringgå supportlinjerna. Men för dem finns det ett separat bearbetningsförfarande.
Det finns sådan statistik på träffar - direkt efter releasen växer antalet träffar med 10-15% under en kort tid. Det blir också skurar av samtal när en ny klient med ett stort antal användare kommer till våra molntjänster. Människor lär sig att använda nya mjukvarufunktioner, de behöver råd. Även en liten kund bränner lätt mer än 100 timmars konsultationer per månad när de börjar arbeta i systemet. När vi ansluter en ny kund reserverar vi därför alltid tid för inledande konsultationer. Ofta pekar vi till och med ut en specifik specialist. Kostnaden för hyran betalar naturligtvis inte dessa arbetskostnader, men med tiden planar situationen ut. Anpassningstiden tar som regel från 1 till 3 månader, varefter behovet av rådgivning minskar avsevärt.
Tidigare använde vi egenskrivna lösningar för att lagra samtal. Men gick gradvis över till Atlassian-produkter. Först överfördes utvecklingen för att göra det lättare att arbeta på Agile, sedan stödet. Nu finns alla kritiska processer i Jira SD, plus att de är försedda med olika plugins för Jira, plus Confluence. Självskrivna lösningar fanns endast kvar på icke-kritiska processer för företagets verksamhet. Det visade sig att våra uppgifter nu är end-to-end, de kan överföras mellan support och utveckling utan att hoppa från ett system till ett annat.
Från detta paket kan vi få data om alla uppgifter, planerade och faktiska arbetskostnader, använda olika faktureringsalternativ för kunder och generera dokumentation för interna behov och en rapport till kunder.
Bearbetar ändringsförfrågningar
Vanligtvis kommer dessa förfrågningar i form av funktionskrav. Vår analytiker studerar begäran, genererar en specifikation och en TOR på toppnivå. Överför specifikationen och TOR till den som skickat in denna begäran om godkännande - vi måste vara säkra på att vi talar samma språk med kunden.
Efter att ha fått bekräftelse från kunden att vi förstått varandra korrekt, lägger analytikern in förfrågan i produktbackloggen.
Produktfunktionshantering
Eftersläpningen samlar in mottagna önskemål om förändring och utveckling. En gång i halvåret träffas tekniska rådet, bestående av direktören, cheferna för underhåll, utveckling, försäljning och systemarkitekten. I diskussionsformatet analyserar och prioriterar rådet ansökningar från eftersläpningen och kommer överens om 5 utvecklingsuppgifter för implementering i nästa release.
Faktum är att tekniska rådet svarar mot branschens och marknadens krav, med hänsyn till de behov som registrerats i ansökningarna. Allt som är av ringa relevans ligger kvar i eftersläpningen och når inte utveckling.
Klassificering av ändringsförfrågningar och ekonomi
Utveckling är dyrt. Därför kommer vi omedelbart att berätta vilka alternativ vi kan ha om en ändringsförfrågan kom från en kund, och inte en anställd.
Ändringsförfrågningar klassificeras enligt följande: branschspecifika behov eller individuella egenskaper hos företaget; en betydande mängd ny funktionalitet eller en liten fix. Små korrigeringar och individuella förfrågningar behandlas utan krusiduller. Individuella förfrågningar beräknas och implementeras för en specifik kund som en del av projektarbetet med denne.
Om detta inte är ett massivt branschbehov och mängden funktionalitet är stor, kan beslut fattas om att utveckla en ny separat modul som kommer att säljas utöver huvudfunktionaliteten. Om en sådan förfrågan tas emot från kunden kan vi stå för kostnaderna för att utveckla modulen, förse kunden med modulen kostnadsfritt eller med delbetalning och lägga ut modulen i offentlig egendom till försäljning. I en sådan situation tar klienten på sig en del av metodbördan och genomför faktiskt en pilotimplementering av modulen.
Om detta är ett massivt industribehov kan beslut fattas om att inkludera ny funktionalitet i basprodukten. Kostnaderna i det här fallet bärs helt av oss, och den nya funktionaliteten visas i den aktuella versionen av programmen.
Gamla kunder förses med en uppdatering.
Det kan också vara så att flera kunder har ett liknande behov, men det drar inte på en massprodukt. I det här fallet kan vi skicka specifikationen till dessa kunder och erbjuda att dela utvecklingskostnaderna mellan dem. I slutändan vinner alla: kunder får implementering av funktionaliteten till en låg kostnad, vi berikar produkten, efter ett tag kan även andra marknadsaktörer få funktionaliteten för sin användning.
DevOps
Utvecklingen förbereder två stora releaser per år. I varje release reserveras tid för genomförande av 5 uppdrag som erhållits från tekniska rådet. Därför, bakom omsättningen, glömmer vi aldrig utvecklingen av produkten.
Varje release går igenom en lämplig uppsättning tester och dokumentation. Vidare installeras denna version i testmiljön för motsvarande kund, som i sin tur kontrollerar allt noggrant, och först efter det överförs releasen till produktion.
Utöver releasesystemet finns ett format med snabba buggfixar så att kunderna inte lever med fel under ett halvår. Detta mellanformat gör att du snabbt kan reagera på incidenter med första prioritet och uppfylla den angivna SLA:n.
Allt ovanstående gäller i första hand för företagssektorn och lokala lösningar. För molntjänster fokuserade på SMB-segmentet finns det inte så stora möjligheter för kunder att delta i produktutveckling. Leasingformatet för SMB tyder inte ens på detta. Istället för en ändringsförfrågan i form av tydliga krav från en företagspart finns bara sedvanlig feedback och önskemål om tjänsten. Vi försöker lyssna, men produkten är massiv och en kunds önskan att ta med sig något bekant från sitt gamla historiska system kan motsäga utvecklingsstrategin för systemet som helhet.
Källa: will.com