En este artículo, compartiré mi experiencia en la selección de ideas para el desarrollo de la funcionalidad de nuestros productos y les diré cómo mantener los principales vectores de desarrollo.
Estamos desarrollando un sistema de liquidación automatizado (ACS) - facturación. Término
La vida de nuestro producto es de 14 años. Durante este tiempo, el sistema ha pasado de las primeras versiones de un clasificador industrial a un complejo modular formado por 18 productos que se complementan entre sí. Uno de los aspectos más importantes de la longevidad de los programas es el desarrollo continuo. Y se necesitan ideas para el desarrollo.
Ideas
fuentes
Hay 5 fuentes:
- El principal amigo del desarrollador de sistemas de información corporativos es cliente. Y el cliente es una imagen colectiva de tomadores de decisiones, patrocinadores de proyectos, propietarios y ejecutores de procesos, especialistas en TI internos, usuarios comunes y una gran cantidad de personas interesadas en diversos grados. Para nosotros es importante 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 problemas en el sistema. En el mejor de los casos, hay una persona del lado del cliente que es una fuente constante de ideas de mejora, proporcionando información estructurada sobre las necesidades del cliente.
- Nuestro vendedores y administradores de cuentas son la segunda fuente más importante de ideas de mejora. Se comunican mucho y activamente con representantes de la industria, reciben solicitudes de primera mano para la funcionalidad de facturación de clientes potenciales. Los comerciantes y las cuentas deben estar al tanto de todos los cambios significativos en su funcionalidad y las últimas actualizaciones de software de los competidores, ser capaces de justificar los pros y los contras de las diferentes soluciones. Son estos empleados nuestros los primeros en sentir si algunas funciones de facturación se convierten en un estándar de facto, sin las cuales el software no puede considerarse completo.
- Dueño del producto uno de nuestros mejores gerentes o un gerente de proyecto con mucha experiencia. Tiene en cuenta los objetivos estratégicos de la empresa y ajusta los planes de desarrollo de productos de acuerdo con ellos.
- Arquitecto, una persona que comprende las posibilidades y limitaciones de las soluciones tecnológicas seleccionadas/utilizadas y su impacto en el desarrollo de productos.
Equipos de desarrollo y testing. Personas que están directamente involucradas en el desarrollo del producto.
Clasificación de golpes
Recibimos datos sin procesar de fuentes: cartas, boletos, solicitudes orales. Todo
Las apelaciones se clasifican:
- consultas con el significado "¿Cómo hacerlo?", "¿Cómo funciona?", "¿Por qué no funciona?", "No entiendo...". Las llamadas de este tipo van a la Línea de Soporte de Nivel 1. Es posible reconvertir la consulta en otros tipos de apelaciones.
- Incidentes con el significado "No funciona" y "Error". Manejado por 2 y 3 líneas de apoyo. Si es necesario corregir y lanzar rápidamente un parche, se puede transferir directamente del soporte al desarrollo. Es posible reclasificarlo en una solicitud de cambio y enviarlo al backlog.
- Solicitudes de cambios y desarrollo. Ingrese a la cartera de productos, sin pasar por las líneas de soporte. Pero para ellos hay un procedimiento de procesamiento separado.
Existen tales estadísticas sobre los hits: inmediatamente después del lanzamiento, la cantidad de hits crece en un 10-15% por un corto tiempo. También hay ráfagas de llamadas cuando un nuevo cliente con una gran cantidad de usuarios llega a nuestros servicios en la nube. Las personas están aprendiendo a usar las nuevas funciones del software, necesitan asesoramiento. Hasta un pequeño cliente, al empezar a trabajar en el sistema, fácilmente quema más de 100 horas de consultas al mes. Por lo tanto, cuando conectamos a un nuevo cliente, siempre reservamos tiempo para consultas iniciales. A menudo, incluso destacamos a un especialista específico. El costo del alquiler, por supuesto, no paga estos costos laborales, pero con el tiempo la situación se nivela. El período de adaptación dura, por regla general, de 1 a 3 meses, después de lo cual la necesidad de asesoramiento se reduce significativamente.
Anteriormente, usábamos soluciones escritas por nosotros mismos para almacenar llamadas. Pero poco a poco cambió a los productos de Atlassian. Primero se transfirió el desarrollo para facilitar el trabajo en Agile, luego el soporte. Ahora todos los procesos críticos viven en Jira SD, además se les proporcionan varios complementos para Jira, además de Confluence. Las soluciones autoescritas se quedaron solo en procesos no críticos para las actividades de la empresa. Resultó que nuestras tareas ahora son integrales, se pueden transferir entre soporte y desarrollo sin saltar de un sistema a otro.
De este paquete, podemos obtener datos sobre todas las tareas, costos de mano de obra planificados y reales, usar varias opciones de facturación para los clientes y generar documentación para las necesidades internas y un informe para los clientes.
Procesamiento de solicitudes de cambio
Por lo general, estas solicitudes vienen en forma de requisitos de funciones. Nuestro analista estudia la solicitud, genera una especificación y un TOR de primer nivel. Transfiere la especificación y los TOR a la persona que envió esta solicitud de aprobación; debemos asegurarnos de que hablamos el mismo idioma con el cliente.
Habiendo recibido la confirmación del cliente de que nos entendimos correctamente, el analista ingresa la solicitud en la cartera de productos.
Gestión de características del producto
El backlog acumula las solicitudes de cambio y desarrollo recibidas. Una vez cada seis meses se reúne el consejo técnico, integrado por el director, los jefes de mantenimiento, desarrollo, ventas y el arquitecto de sistemas. En el formato de discusión, el consejo analiza y prioriza las solicitudes del trabajo pendiente y acuerda 5 tareas de desarrollo para implementar en la próxima versión.
De hecho, el consejo técnico responde a los requerimientos de la industria y del mercado, considerando las necesidades registradas en las solicitudes. Todo lo que tiene poca relevancia se queda en el backlog y no llega a desarrollo.
Clasificación de Solicitudes de Cambio y Finanzas
El desarrollo es caro. Por lo tanto, le informaremos de inmediato qué opciones podemos tener si una solicitud de cambio proviene de un cliente y no de un empleado.
Las solicitudes de cambio se clasifican de la siguiente manera: necesidades específicas de la industria o características individuales de la empresa; una cantidad significativa de nuevas funciones o una pequeña corrección. Las pequeñas correcciones y las solicitudes individuales se procesan sin lujos. Las solicitudes individuales se calculan e implementan para un cliente específico como parte del trabajo del proyecto con él.
Si esta no es una necesidad masiva de la industria y la cantidad de 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 cubrir los costos de desarrollo del módulo, proporcionar al cliente el módulo de forma gratuita o con pago parcial, y poner el módulo a la venta en el dominio público. En tal situación, el cliente asume parte de la carga metodológica y, de hecho, realiza una 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 corren completamente por nuestra cuenta, 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 tira de un producto masivo. En este caso, podemos enviar la especificación a estos clientes y ofrecer compartir los costos de desarrollo entre ellos. Al final, todos ganan: los clientes obtienen la implementación de la funcionalidad a bajo costo, enriquecemos el producto, después de un tiempo, otros participantes del mercado también pueden obtener la funcionalidad para su uso.
DevOps
El desarrollo prepara dos grandes lanzamientos al año. En cada lanzamiento, se reserva tiempo para la implementación de 5 tareas recibidas del consejo técnico. Así, detrás de la facturación, nunca nos olvidamos del desarrollo del producto.
Cada versión pasa por un conjunto adecuado de pruebas y documentación. Además, esta versión se instala en el entorno de prueba del cliente correspondiente, quien, a su vez, verifica todo meticulosamente y solo después de eso, la versión se transfiere a producción.
Además del sistema de lanzamiento, existe un formato de corrección rápida de errores para que los clientes no vivan con errores durante seis meses. Este formato intermedio te permitirá responder rápidamente a incidencias de primera prioridad y cumplir con los SLA establecidos.
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 existen oportunidades tan amplias para que los clientes participen en el desarrollo de productos. El formato de arrendamiento para SMB ni siquiera sugiere esto. En lugar de una solicitud de cambio en forma de requisitos claros de una parte corporativa, solo hay comentarios y deseos habituales para el servicio. Tratamos de escuchar, pero el producto es masivo 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.
Fuente: habr.com