En este artículo, compartiré mi experiencia en la selección de ideas para desarrollar la funcionalidad de nuestros productos y le diré cómo mantener los principales vectores de desarrollo.
Estamos desarrollando un sistema de facturación automatizado (ASR): facturación. Plazo
La vida de nuestro producto es de 14 años. Durante este tiempo, el sistema pasó de las primeras versiones de arancel industrial a un complejo modular que consta de 18 productos que se complementan entre sí. Uno de los aspectos más importantes de la larga vida de los programas es el desarrollo continuo. Y para el desarrollo, se necesitan ideas.
Ideas
Fuentes
Hay 5 fuentes:
- El principal amigo del desarrollador de sistemas de información corporativos es el cliente . Y el cliente es una imagen colectiva de tomadores de decisiones, patrocinadores de proyectos, propietarios de procesos y ejecutivos, especialistas de TI internos, usuarios comunes y una gran cantidad de personas con intereses diferentes. Es importante para nosotros que cada uno de los representantes del cliente sea potencialmente un proveedor de ideas. En el peor de los casos, solo recibimos comentarios negativos sobre los problemas del sistema. En el mejor de los casos, del lado del cliente hay una persona que es una fuente constante de ideas para mejorar, proporcionando información estructurada sobre las necesidades del cliente.
- Nuestros vendedores y gerentes de cuentas son la segunda fuente más importante de ideas para mejorar. Se comunican mucho con los representantes de la industria y reciben solicitudes de primera mano para la funcionalidad de facturación de clientes potenciales. Los vendedores y las cuentas deben ser conscientes de todos los cambios significativos en su funcionalidad y las últimas actualizaciones de software de los competidores, para poder justificar los pros y los contras de las diferentes soluciones. Son estos nuestros empleados los primeros en sentir si algunas capacidades de facturación se convierten en un estándar de facto, sin el cual el software no puede considerarse completo.
- El propietario del producto es uno de nuestros principales gerentes o un gerente de proyectos con mucha experiencia. Tiene en cuenta los objetivos estratégicos de la empresa y ajusta los planes para el desarrollo de productos de acuerdo con ellos.
- Un arquitecto , una persona que comprende las posibilidades y limitaciones de las soluciones tecnológicas seleccionadas / utilizadas y su impacto en el desarrollo de productos.
Desarrollo, equipos de prueba. Personas que participan directamente en el desarrollo de productos.
Clasificación de apelaciones
De las fuentes recibimos datos sin procesar: cartas, tickets, solicitudes verbales. Todos
las apelaciones se clasifican:
- Consultas con el significado de "¿Cómo hacerlo?", "¿Cómo funciona?", "¿Por qué no funciona?", "No entiendo ...". Este tipo de llamada va a la Línea de Soporte de Nivel 1. Posible recalificación de la consulta en otro tipo de aplicaciones.
- Incidentes con el significado de "No funciona" y "Error". Manejado por 2 y 3 líneas de soporte. Si es necesario, se puede transferir una revisión rápida y una versión del parche desde el soporte inmediatamente al desarrollo. Es posible volver a entrenar en una solicitud de cambio y enviarlo a la cartera de pedidos.
- Solicitudes de cambio y desarrollo . Ingrese a la cartera de productos del producto sin pasar por las líneas de soporte. Pero para ellos hay un procedimiento de procesamiento separado.
Existen estadísticas sobre las apelaciones: inmediatamente después de la publicación, el número de apelaciones aumenta entre un 10 y un 15% durante un breve período de tiempo. Además, se producen ráfagas de llamadas cuando un nuevo cliente con una gran cantidad de usuarios acude a nuestros servicios en la nube. Las personas aprenden a usar las nuevas funciones del software, necesitan asesoramiento. Incluso un pequeño cliente al comienzo del trabajo en el sistema quema fácilmente más de 100 horas de consultas por mes. Por lo tanto, al conectar un nuevo cliente, siempre reservamos tiempo para las consultas iniciales. A menudo, incluso destacamos a un especialista específico. El costo de la renta, por supuesto, no paga estos costos laborales, pero con el tiempo la situación se nivela. El período de adaptación toma, por regla general, de 1 a 3 meses, luego la necesidad de asesoramiento se reduce significativamente.
Anteriormente, utilizamos soluciones autoescritas para almacenar llamadas. Pero gradualmente se cambió a los productos Atlassian. Primero, desarrollamos el desarrollo para facilitar el trabajo en Agile, luego el soporte. Ahora todos los procesos críticos viven en Jira SD, además de que son proporcionados por varios complementos para Jira, además de Confluence. Las soluciones autoescritas se mantuvieron solo en procesos que no eran críticos para las actividades de la empresa. Resultó que nuestras tareas ahora son transversales, se pueden transferir entre soporte y desarrollo sin saltar de un sistema a otro.
De este paquete podemos obtener datos sobre todas las tareas, los costos laborales planificados y reales, usar varias opciones de tarifas para los clientes y generar documentación para las necesidades internas e informar a los clientes.
Procesamiento de solicitud de cambio
Por lo general, tales solicitudes vienen en forma de requisitos funcionales. Nuestro analista estudia la solicitud, genera una especificación y ToR de nivel superior. Transmite la especificación y la declaración de trabajo a la persona que envió esta solicitud de aprobación; debemos estar seguros de que hablamos el mismo idioma con el cliente.
Después de recibir la confirmación del cliente de que nos entendimos correctamente, el analista escribe la solicitud en la cartera de pedidos del producto.
Gestion de producto
El retraso acumula solicitudes entrantes de cambio y desarrollo. Una vez cada seis meses, se convoca un consejo técnico, compuesto por un director, mantenimiento, desarrollo, ventas y gerentes de arquitectura de sistemas. En el formato de discusión, la junta analiza y prioriza las aplicaciones del trabajo atrasado y coordina 5 tareas de desarrollo para su implementación en la próxima versión.
De hecho, el consejo técnico responde a los requisitos de la industria y el mercado, considerando las necesidades registradas en las aplicaciones. Todo lo que tiene poca relevancia permanece en la cartera de pedidos y no alcanza el desarrollo.
Clasificación de solicitudes de cambio y finanzas
El desarrollo es costoso. Por lo tanto, le diremos de inmediato qué opciones podemos tener si la solicitud de cambio proviene de un cliente, no de un empleado.
Las solicitudes de cambio se clasifican de la siguiente manera: necesidades de la industria o características individuales de la empresa; cantidad significativa de nueva funcionalidad o pequeña solución. Pequeñas correcciones y solicitudes individuales se procesan sin lujos. Las solicitudes individuales se calculan e implementan para un cliente en particular como parte del trabajo del proyecto con él.
Si esto no es una necesidad masiva de la industria y el alcance de la funcionalidad es grande, entonces se puede tomar la decisión de desarrollar un nuevo módulo separado, que se venderá además de la funcionalidad principal. Si se recibe dicha solicitud del cliente, podemos asumir los costos de desarrollar el módulo, proporcionar al cliente el módulo de forma gratuita o con un pago parcial, y poner el módulo a la venta pública. El cliente asume parte de la carga metodológica en tal situación y esencialmente lleva a cabo la implementación piloto del módulo.
Si esta es una necesidad masiva de la industria, entonces se puede tomar la decisión de incluir una nueva funcionalidad en el producto base. Los costos en este caso recaen completamente en nosotros, y la nueva funcionalidad aparece en la versión actual de los programas.
Los clientes antiguos reciben una actualización.
También puede ser que varios clientes tengan una necesidad similar, pero no atrae un producto en masa. En este caso, podemos enviar la especificación a estos clientes y ofrecer compartir los costos de desarrollo entre ellos. Como resultado, todos ganan: los clientes reciben la implementación de la funcionalidad a un bajo costo, enriquecemos el producto, después de un tiempo, los participantes restantes del mercado también pueden recibir la funcionalidad para su uso.
Devops
El desarrollo prepara dos lanzamientos principales por año. En cada lanzamiento, se reserva tiempo para la implementación de 5 tareas recibidas del consejo técnico. Por lo tanto, para el fluido, nunca nos olvidamos del desarrollo del producto.
Cada versión pasa un conjunto apropiado de pruebas y documentación. Además, esta versión se instala en el entorno de prueba del cliente relevante, quien, a su vez, verifica meticulosamente todo y solo después de eso, la versión se traduce en producción.
Además del sistema de lanzamiento, existe un formato para la corrección rápida de errores, de modo que los clientes no vivan con errores durante seis meses. Este formato provisional le permitirá responder rápidamente a incidentes de primera prioridad y cumplir con el SLA declarado.
Todo lo anterior es cierto principalmente para el sector corporativo y las soluciones locales. Para los servicios en la nube enfocados en el segmento SMB, no hay oportunidades tan amplias para que los clientes participen en el desarrollo del producto. El formato de arrendamiento para SMB ni siquiera sugiere esto. En lugar de una solicitud de cambio en forma de requisitos claros de la parte corporativa, aquí están solo los comentarios y deseos habituales para el servicio. Intentamos escuchar, pero el producto es enorme y el deseo de un cliente de traer algo familiar de su antiguo sistema histórico puede contradecir la estrategia de desarrollo del sistema en su conjunto.