En aquest article, compartiré la meva experiència en la selecció d'idees per desenvolupar la funcionalitat dels nostres productes i us explicaré com mantenir els principals vectors de desenvolupament.
Estem desenvolupant un sistema de liquidació automatitzada (ACP): facturació. Terme
La vida útil del nostre producte és de 14 anys. Durant aquest temps, el sistema ha evolucionat des de les primeres versions d'un sistema tarifari industrial fins a un complex modular format per 18 productes que es complementen. Un dels aspectes més importants de la longevitat dels programes és el desenvolupament constant. I el desenvolupament requereix idees.
Idees
Fonts
Hi ha 5 fonts:
- El principal amic d'un desenvolupador de sistemes d'informació corporatiu és client. I el client és una imatge col·lectiva de qui prenen decisions, patrocinadors de projectes, propietaris i executors de processos, especialistes informàtics interns, usuaris corrents i un gran nombre d'individus interessats en diferents graus. Per a nosaltres és important que cadascun dels representants del client sigui potencialment un proveïdor d'idees. En el pitjor dels casos, només rebem comentaris negatius sobre problemes del sistema. En el millor dels casos, hi ha una persona al costat del client que és una font constant d'idees de millora, aportant informació estructurada sobre les necessitats del client.
- El nostre venedors i gestors de comptes són la segona font més important d'idees de millora. Es comuniquen de manera activa i extensa amb els representants del sector i reben consultes de primera mà sobre la funcionalitat de facturació de clients potencials. Els venedors i els comptes han de ser conscients de tots els canvis significatius en la seva funcionalitat i de les últimes actualitzacions del programari de la competència, i ser capaços de justificar els avantatges i els contres de les diferents solucions. Aquests són els nostres empleats que són els primers a detectar si algunes capacitats de facturació es converteixen en un estàndard de facto, sense el qual el programari no es pot considerar complet.
- Propietari del producte — un dels nostres alts directius o un gestor de projectes molt experimentat. Té presents els objectius estratègics de l'empresa i ajusta els plans de desenvolupament de productes d'acord amb ells.
- Arquitecte, una persona que entén les capacitats i limitacions de les solucions tecnològiques escollides/utilitzades i el seu impacte en el desenvolupament del producte.
Equips de desenvolupament i proves. Persones que estan directament implicades en el desenvolupament del producte.
Classificació de les peticions
Rebem dades en brut de fonts: cartes, bitllets, peticions verbals. Tots
Els recursos es classifiquen:
- Consultes amb el significat “Com fer-ho?”, “Com funciona?”, “Per què no funciona?”, “No entenc...”. Les sol·licituds d'aquest tipus van a la línia de suport de nivell 1. És possible readaptar la consulta a altres tipus de peticions.
- Incidències amb el significat "No funciona" i "Error". Processat per 2 i 3 línies de suport. Si calen correccions ràpides i llançament d'un pedaç, es poden transferir del suport directament al desenvolupament. És possible reclassificar-lo com a sol·licitud de canvi i enviar-lo al backlog.
- Peticions de canvis i desenvolupament. Entren a la cartera de productes, obviant les línies de suport. Però hi ha un procediment de processament separat per a ells.
Hi ha estadístiques sobre les sol·licituds: immediatament després del llançament, el nombre de sol·licituds augmenta entre un 10 i un 15% durant un curt període de temps. També hi ha augments de sol·licituds quan un nou client amb un gran nombre d'usuaris arriba als nostres serveis al núvol. La gent està aprenent a utilitzar noves capacitats de programari, necessiten consell. Fins i tot un client petit, quan comença a treballar en el sistema, crema fàcilment més de 100 hores de consultes al mes. Per tant, quan connectem un nou client, sempre reservem temps per a les primeres consultes. Sovint fins i tot seleccionem un especialista específic. El preu del lloguer, òbviament, no cobreix aquests costos laborals, però amb el temps la situació s'iguala. El període d'adaptació sol durar d'1 a 3 mesos, després dels quals la necessitat d'assessorament es redueix significativament.
Anteriorment, vam utilitzar solucions autoescrites per emmagatzemar les sol·licituds. Però a poc a poc vam anar canviant als productes Atlassian. Primer, vam transferir el desenvolupament per facilitar el treball segons Agile, i després el suport. Ara tots els processos crítics viuen a Jira SD, a més són compatibles amb diversos connectors per a Jira, a més de Confluence. Les solucions autoescrites es van mantenir només per a processos que no eren crítics per a les activitats de l'empresa. Resulta que les nostres tasques ara són transversals i es poden transferir entre suport i desenvolupament sense saltar d'un sistema a un altre.
Des d'aquest enllaç podem obtenir dades de totes les tasques, costos laborals previstos i reals, utilitzar diverses opcions de preus per als clients i generar documentació per a les necessitats internes i informes als clients.
Processament de sol·licituds de canvi
Normalment, aquestes sol·licituds es presenten en forma de requisits de funcionalitat. El nostre analista estudia la sol·licitud, elabora un plec i unes especificacions tècniques de primer nivell. Transmet l'especificació i les especificacions tècniques a la persona que ha presentat aquesta sol·licitud d'aprovació: hem d'assegurar-nos que parlem el mateix idioma amb el client.
Després d'haver rebut la confirmació del client que ens hem entès correctament, l'analista introdueix la sol·licitud a la cartera de productes.
Gestió de la funcionalitat del producte
L'endarreriment acumula les sol·licituds entrants de canvi i desenvolupament. El consell tècnic, format pel director, els responsables de suport, desenvolupament, vendes i l'arquitecte de sistemes, es reuneix semestralment. En un format de discussió, el consistori analitza i prioritza les aplicacions de l'endarreriment i acorda 5 tasques de desenvolupament per implementar-les en la propera versió.
En efecte, el consell tècnic respon a les demandes de la indústria i del mercat revisant les necessitats expressades en les sol·licituds. Tot el que té poca rellevància queda en l'endarreriment i no arriba al desenvolupament.
Classificació de Sol·licituds de Canvi i Finances
El desenvolupament és car. Per tant, de seguida us informarem de quines opcions podem tenir si la sol·licitud de canvi prové d'un client i no d'un empleat.
Classifiquem les sol·licituds de canvi de la següent manera: necessitat del sector o característica individual de l'empresa; una quantitat significativa de noves funcionalitats o una correcció menor. Les correccions menors i les sol·licituds individuals es processen sense cap tipus de luxe. Les sol·licituds individuals es calculen i s'implementen per a un client específic com a part del treball del projecte amb ell.
Si aquesta no és una necessitat massiva de la indústria i el volum de funcionalitats és gran, es pot prendre la decisió de desenvolupar un nou mòdul independent que es vendrà a més de la funcionalitat principal. Si es rep una sol·licitud d'aquest tipus d'un client, podem cobrir els costos de desenvolupament del mòdul, proporcionar-li el mòdul de manera gratuïta o amb pagament parcial i posar el mòdul en si mateix a la venda. En aquesta situació, el client assumeix part de la càrrega metodològica i, bàsicament, realitza una implementació pilot del mòdul sobre ell mateix.
Si aquesta és una necessitat massiva de la indústria, es pot prendre la decisió d'incloure noves funcionalitats al producte base. Els costos en aquest cas recauen totalment sobre nosaltres, i la nova funcionalitat apareix a la versió actual dels programes.
Els clients antics reben una actualització.
També pot ser que diversos clients tinguin una necessitat similar, però no es qualifica per a un producte massiu. En aquest cas, podem enviar l'especificació a aquests clients i oferir-nos repartir els costos de desenvolupament entre ells. Al final, tothom hi guanya: els clients reben la funcionalitat a baix cost, enriquim el producte i, al cap d'un temps, altres participants del mercat també poden obtenir la funcionalitat per al seu ús.
DevOps
El desenvolupament prepara dos llançaments importants a l'any. En cada llançament, es reserva un temps per a la realització de 5 tasques rebudes del consell tècnic. Així, enmig de la rutina, mai ens oblidem del desenvolupament de productes.
Cada versió es sotmet a un conjunt adequat de proves i documentació. A continuació, aquesta versió s'instal·la a l'entorn de prova del client corresponent, que, al seu torn, ho comprova minuciosament tot i només després d'això es trasllada la versió a producció.
A més del sistema de llançament, hi ha un format per a correccions ràpides d'errors perquè els clients no visquin amb errors durant sis mesos. Aquest format intermedi us permetrà respondre ràpidament a les incidències de primera prioritat i complir els SLA establerts.
Tot l'anterior s'aplica principalment al sector corporatiu i a les solucions locals. Per als serveis en núvol destinats al segment de les pimes, no hi ha oportunitats tan àmplies perquè els clients participin en el desenvolupament del producte. El format de lloguer SMB ni tan sols assumeix això. En lloc d'una sol·licitud de canvi en forma de requisits clars de la part corporativa, aquí només hi ha comentaris i desitjos habituals pel servei. Intentem escoltar, però el producte és massiu i el desig d'un client d'aportar alguna cosa familiar del seu antic sistema històric pot contradir l'estratègia de desenvolupament del sistema en conjunt.
Font: www.habr.com