Pensemos en un ejemplo hipotético: una empresa lanza un sistema para que los empleados soliciten el reembolso de gastos. El equipo entrega lo acordado, las pruebas pasan y el proyecto se cierra. Los desarrolladores pasan a otro trabajo. Después, las solicitudes empiezan a volver a quienes las enviaron porque falta información, y el área de finanzas sigue resolviendo los pendientes por correo electrónico.
El sistema funciona, pero todavía no redujo el trabajo de revisar las solicitudes. Puede haber una instrucción confusa, un campo mal elegido o una regla que nadie notó durante las pruebas. Para descubrirlo, alguien tiene que seguir las solicitudes devueltas y hablar con las personas que intentaron usarlo.
¿Quién lo hará ahora? Si el equipo ya fue reasignado y soporte solo puede corregir fallas, un cambio pequeño puede depender de la aprobación de otro proyecto. La empresa pagó por la entrega, pero dejó sin responsable la verificación de que resolvió el problema.
Lo que falta saber después de la entrega
El plazo y la lista de funcionalidades ayudan a organizar el trabajo. En el ejemplo del reembolso, permiten comprobar que se puede adjuntar un comprobante, aprobar un gasto y registrar el pago. Esas comprobaciones son necesarias para poner el sistema en uso.
Todavía falta saber si los empleados pueden hacer todo eso sin pedir ayuda. Una solicitud puede pasar por todas las pantallas y llegar incompleta a finanzas. En ese caso, contar cuántas solicitudes se enviaron dice poco sobre el trabajo que la herramienta debía ahorrar.
Sería más útil examinar qué solicitudes vuelven para corrección y por qué. Quizá falte la misma información en muchas de ellas. El equipo podría ajustar la instrucción de ese campo y observar las solicitudes siguientes. Si las devoluciones continuaran, tendría motivos para investigar otra causa, en lugar de dar la tarea por resuelta porque la pantalla cambió.
En Products Over Projects, publicado en 2018 en el sitio de Martin Fowler, Sriram Narayan defiende equipos que siguen ligados al problema después de entregar el software. Distingue entre financiar una solución definida de antemano y mantener un equipo capaz de verificar los resultados y revisar lo que construyó.
Aplicada al ejemplo, esa propuesta exige reservar tiempo para seguir el reembolso después del lanzamiento. También exige decidir quién puede interrumpir una nueva funcionalidad para resolver una dificultad que apareció con el uso. Sin ese acuerdo, incluso un equipo que conoce bien el sistema puede quedarse sin margen para mejorarlo.
Quien sigue el sistema tiene que poder cambiarlo
Darle a alguien la responsabilidad del sistema solo ayuda si esa persona o equipo puede actuar sobre los problemas que encuentra. Recibir quejas, sin tiempo ni autorización para cambiar el software, suele convertir esa responsabilidad en una cola de pedidos.
En el caso del reembolso, supongamos que la exigencia de un documento está causando las devoluciones. El desarrollador puede cambiar la pantalla, pero necesita entender con finanzas si ese documento es obligatorio en todas las situaciones. El cambio depende de una decisión sobre el proceso, además del trabajo de programación.
Por eso, el acuerdo entre las áreas tiene que ser específico. ¿Quién puede revisar la exigencia? ¿Quién comprueba si el cambio funcionó? Si finanzas cambia una regla, ¿cómo se enterará el equipo de desarrollo? Son detalles que determinan si una queja podrá resolverse o solo reenviarse.
El equipo que mantiene el sistema también debería poder consultar los motivos de las devoluciones, con acceso limitado a los datos necesarios. Pedirle que mejore el proceso sin permitirle ver dónde falla deja la investigación en manos de relatos incompletos.
Esto tiene un costo que debe aparecer en la planificación. Las horas dedicadas a seguir solicitudes y corregir el flujo dejan de estar disponibles para otras entregas. El liderazgo tiene que decidir si la reducción de trabajo en finanzas justifica esa dedicación, en lugar de esperar que el equipo haga ambas cosas con el mismo plazo.
El traspaso a otro equipo necesita tiempo
Mantener un equipo responsable de un sistema no exige conservar a las mismas personas indefinidamente. Los profesionales cambian de función, los proveedores terminan contratos y los productos pasan a necesitar menos desarrollo. La continuidad depende de cómo se transfiere la responsabilidad en esos cambios.
Si otro equipo asume el sistema de reembolso, la documentación puede explicar las reglas de aprobación y cómo publicar un cambio. Para recibir el trabajo, sin embargo, también necesita conocer los problemas que siguen abiertos. Conviene recorrer una solicitud devuelta junto con quien la investigó, revisar las pruebas existentes y acordar a quién recurrir si surge una duda.
Ese traspaso ocupa tiempo de los dos equipos. Dejarlo para el último día del contrato reduce la oportunidad de notar lo que falta. Un problema descubierto después puede exigir localizar a alguien que ya se fue para entender una decisión antigua.
También hay sistemas estables que no justifican un equipo dedicado. Un equipo compartido puede ocuparse de ellos, siempre que tenga capacidad para atender las demandas y que esté claro cómo se priorizarán. El tamaño del equipo puede cambiar según el trabajo; la atención no debería depender de encontrar por casualidad a alguien dispuesto a ayudar.
Antes de cerrar el proyecto, ese arreglo tiene que estar acordado. En el ejemplo del reembolso, habría que indicar quién examinará las solicitudes devueltas después del lanzamiento y de dónde saldrá el tiempo para corregir lo que se encuentre. Si nadie puede asumir ese trabajo, la decisión de reasignar a todo el equipo todavía debe revisarse.
