Neste artigo, compartirei a miña experiencia na selección de ideas para desenvolver a funcionalidade dos nosos produtos e explicarei como manter os principais vectores de desenvolvemento.
Estamos a desenvolver un sistema de liquidación automatizada (ACP) - facturación. Prazo
A vida útil do noso produto é de 14 anos. Durante este tempo, o sistema evolucionou dende as primeiras versións dun sistema tarifario industrial ata un complexo modular formado por 18 produtos que se complementan. Un dos aspectos máis importantes da lonxevidade dos programas é o desenvolvemento constante. E o desenvolvemento require ideas.
Ideas
Fontes
Hai 5 fontes:
- O principal amigo dun desenvolvedor de sistemas de información corporativa é cliente. E o cliente é unha imaxe colectiva de tomadores de decisións, patrocinadores de proxectos, propietarios e executores de procesos, especialistas internos en TI, usuarios comúns e un gran número de persoas interesadas en diferentes graos. É importante para nós que cada un dos representantes do cliente sexa potencialmente un provedor de ideas. No peor dos casos, só recibimos comentarios negativos sobre problemas no sistema. No mellor dos casos, hai unha persoa do lado do cliente que é unha fonte constante de ideas para mellorar, proporcionando información estruturada sobre as necesidades do cliente.
- A nosa vendedores e xestores de contas son a segunda fonte máis importante de ideas para mellorar. Comunícanse de forma activa e extensa cos representantes do sector e reciben consultas de primeira man sobre a funcionalidade de facturación dos potenciais clientes. Os vendedores e as contas teñen que estar ao tanto de todos os cambios significativos na súa funcionalidade e das últimas actualizacións do software dos competidores, así como poder xustificar os pros e os contras das diferentes solucións. Estes son os nosos empregados que son os primeiros en sentir se algunhas capacidades de facturación se converten nun estándar de facto, sen o cal o software non pode considerarse completo.
- Propietario do produto — un dos nosos xestores superiores ou un xestor de proxectos moi experimentado. Ten presentes os obxectivos estratéxicos da empresa e axusta os plans de desenvolvemento de produtos de acordo con eles.
- O arquitecto, unha persoa que entende as capacidades e limitacións das solucións tecnolóxicas elixidas/utilizadas e o seu impacto no desenvolvemento do produto.
Equipos de desenvolvemento e probas. Persoas que participan directamente no desenvolvemento do produto.
Clasificación das solicitudes
Recibimos datos brutos de fontes: cartas, boletos, solicitudes verbais. Todos
os recursos clasifícanse:
- Consultoría co significado “Como facelo?”, “Como funciona?”, “Por que non funciona?”, “Non entendo...”. As solicitudes deste tipo van á liña de apoio de nivel 1. É posible readaptar a consulta a outro tipo de solicitudes.
- Incidentes co significado "Non funciona" e "Erro". Procesado por 2 e 3 Liñas de Apoio. Se son necesarias correccións rápidas e a liberación dun parche, pódense transferir directamente do soporte ao desenvolvemento. É posible reclasificalo como solicitude de cambio e envialo ao backlog.
- Solicitudes de cambios e desenvolvemento. Entran na carteira de produtos, evitando as liñas de soporte. Pero hai un procedemento de procesamento separado para eles.
Hai estatísticas sobre as solicitudes: inmediatamente despois do lanzamento, o número de solicitudes aumenta nun 10-15% por pouco tempo. Tamén hai aumentos nas solicitudes cando un novo cliente cun gran número de usuarios chega aos nosos servizos na nube. A xente está aprendendo a usar novas capacidades de software, necesitan consellos. Incluso un cliente pequeno, ao comezar a traballar no sistema, queima facilmente máis de 100 horas de consultas ao mes. Por iso, ao conectar un novo cliente, sempre reservamos tempo para as primeiras consultas. Moitas veces mesmo seleccionamos un especialista específico. O prezo do aluguer, por suposto, non cobre estes custos laborais, pero co paso do tempo a situación vaise igualando. O período de adaptación adoita durar de 1 a 3 meses, despois do cal a necesidade de asesoramento redúcese significativamente.
Anteriormente, utilizabamos solucións autoescritas para almacenar solicitudes. Pero aos poucos pasamos aos produtos Atlassian. En primeiro lugar, transferimos o desenvolvemento para facilitar o traballo segundo Agile, despois o soporte. Agora todos os procesos críticos viven en Jira SD, ademais de que son compatibles con varios complementos para Jira, ademais de Confluence. As solucións autoescritas permaneceron só para procesos que non eran críticos para as actividades da empresa. Resulta que as nosas tarefas son agora transversais e pódense transferir entre soporte e desenvolvemento sen pasar dun sistema a outro.
Desde esta ligazón podemos obter datos de todas as tarefas, custos laborais previstos e reais, utilizar varias opcións de prezos para os clientes e xerar documentación para necesidades internas e informes aos clientes.
Procesando solicitudes de cambio
Normalmente, tales solicitudes veñen en forma de requisitos de funcionalidade. O noso analista estuda a solicitude, crea unha especificación e especificacións técnicas de primeiro nivel. Transfire a especificación e as especificacións técnicas á persoa que presentou esta solicitude de aprobación; debemos asegurarnos de que falamos o mesmo idioma co cliente.
Despois de recibir a confirmación do cliente de que nos entendemos correctamente, o analista introduce a solicitude na carteira de produtos.
Xestión da funcionalidade do produto
O atraso acumula solicitudes de cambio e desenvolvemento. O consello técnico, integrado polo director, os xefes de soporte, desenvolvemento, vendas e o arquitecto do sistema, reúnese semestralmente. Nun formato de discusión, o concello analiza e prioriza as solicitudes do atraso e acorda 5 tarefas de desenvolvemento para a súa implementación na próxima versión.
En efecto, o consello técnico responde ás demandas da industria e do mercado revisando as necesidades expresadas nas solicitudes. Todo o que ten pouca relevancia queda no atraso e non chega ao desenvolvemento.
Clasificación de solicitudes de cambio e finanzas
O desenvolvemento é caro. Polo tanto, de inmediato dirémosche que opcións podemos ter se a solicitude de cambio proceda dun cliente e non dun empregado.
Clasificamos as solicitudes de cambio do seguinte xeito: necesidade do sector ou característica individual da empresa; unha cantidade significativa de novas funcionalidades ou unha corrección menor. As correccións menores e as solicitudes individuais son procesadas sen luxos. As solicitudes individuais calcúlanse e impléntanse para un cliente específico como parte do traballo do proxecto con el.
Se esta non é unha necesidade masiva da industria e o volume de funcionalidades é grande, pódese tomar a decisión de desenvolver un novo módulo separado que se venderá ademais da funcionalidade principal. Se se recibe unha solicitude deste tipo por parte dun cliente, podemos cubrir os custos de desenvolvemento do módulo, proporcionarlle ao cliente o módulo de xeito gratuíto ou con pago parcial e poñer o propio módulo á venda. En tal situación, o cliente asume parte da carga metodolóxica e realiza esencialmente unha implementación piloto do módulo sobre si mesmo.
Se esta é unha necesidade masiva da industria, pódese tomar a decisión de incluír novas funcionalidades no produto base. Os custos neste caso recaen enteiramente sobre nós, e a nova funcionalidade aparece na versión actual dos programas.
Os clientes antigos reciben unha actualización.
Tamén pode ser que varios clientes teñan unha necesidade similar, pero non cualifica para un produto masivo. Neste caso, podemos enviar a especificación a estes clientes e ofrecernos repartir os custos de desenvolvemento entre eles. Ao final, todos gañan: os clientes reciben a funcionalidade a un custo baixo, enriquecemos o produto e, despois dun tempo, outros participantes no mercado tamén poden obter a funcionalidade para o seu uso.
DevOps
O desenvolvemento prepara dous lanzamentos importantes ao ano. En cada lanzamento resérvase tempo para a realización de 5 tarefas recibidas do consello técnico. Así, no medio da rutina, nunca nos esquecemos do desenvolvemento de produtos.
Cada versión sometese a un conxunto adecuado de probas e documentación. A continuación, esta versión instálase no ambiente de proba do cliente correspondente, quen, á súa vez, verifica todo meticulosamente e só despois transfírese a versión a produción.
Ademais do sistema de lanzamento, hai un formato para a corrección rápida de erros para que os clientes non vivan con erros durante seis meses. Este formato intermedio permitirache responder rapidamente a incidencias de primeira prioridade e cumprir os SLA indicados.
Todo o anterior é certo principalmente para o sector corporativo e as solucións locais. Para os servizos na nube dirixidos ao segmento de pemes, non hai oportunidades tan amplas para que os clientes participen no desenvolvemento de produtos. O formato de aluguer SMB nin sequera o asume. En lugar dunha solicitude de cambio en forma de requisitos claros da parte corporativa, aquí só hai comentarios e desexos ordinarios para o servizo. Tentamos escoitar, pero o produto é masivo e o desexo dun cliente de traer algo familiar do seu antigo sistema histórico pode contradir a estratexia de desenvolvemento do sistema no seu conxunto.
Fonte: www.habr.com