El puffin (frailecillo en inglés) es un perfil que, dirigiendo un equipo de desarrolladores, dispone de interminables funciones de software con dudodo o ningún impacto en el negocio, los clientes o el resto de los empleados.
Un PUFFIN —( Plans unending feature factory initiatives), en español equivalría a planes interminables de iniciativas de funciones.
Este término de perfiles suponen coste y ningún beneficio, además de una gran fustración de los equipos que no tienen ninguna visibilidad en la organización.
El término Feature Factory (factoría de funciones) surge cuando un amigo desarrollador de software se quejó de que estaba “simplemente sentado en la fábrica, creando funciones y enviándolas a otros desarrolladores”.
¿Cómo saber si se está trabajando en una fábrica de funciones? Hay síntomas claros que permiten identificar estas estructuras.
- Sin métricas. Los equipos no tienen por que medir el impacto del trabajo. O, si se realiza la medición, el equipo de gestión del producto la realiza de forma aislada y se comparte de forma selectiva. No se conoce si el trabajo realizó funcionó correctamente.
- Mezcla rápida de equipos y proyectos (también conocido como Team Tetris). En lugar de misiones o iniciativas sensatas y comprensibles, los equipos se ocupan de asignaciones de funciones y proyectos sin conocer la motivación de las mismas o quién debe ser responsable de qué. Multitárea en todas las operaciones y sobreutilización de recursos.
- Teatro de éxito en torno al “envío” con poca discusión sobre el impacto. Se puede decir mucho sobre una organización por las cuestiones que celebra.
- Fallos poco frecuentes (reconocidos) y trabajo desechado. Sin eliminar o mejorar sensiblemente funciones previas. La medida principal del éxito son las características entregadas, no los resultados entregados. El trabajo rara vez se descarta a la luz de los datos y el aprendizaje. El equipo carece de la medida necesaria para admitir fallos de puesta en producción.
- Sin vinculación con las métricas de negocio. No existen o son poco frecuentes conversaciones sobre los resultados comerciales o de clientes. El equipo no puede relacionar el trabajo con las métricas clave de satisfacción del cliente y del negocio. No se puede conectar el trabajo con lo sustancial del negocio.
- Sin análisis de impacto. Los gerentes del producto no analizan periódicamente la calidad de las decisiones sobre los productos y por tanto no comparan los beneficios esperados con los beneficios reales obtenidos. Los desarrolladores tienen “requerimientos aprobados”, pero los gerentes de producto no tienen objetivos de negiocio. Sólo se tiene en cuenta la velocidad y la producción como indicador clave del desempeño
- Obsesión por la priorización. Aparecen discrepancias entre el rigor de la priorización (decidir en qué se trabaja) y el rigor de la validación (decidir si, de hecho, era lo correcto para trabajar). El rigor de la priorización está diseñado exclusivamente para moderar las agendas internas para que las personas “se sientan seguras”. Se dedica mucho trabajo a determinar en qué ideas trabajar, dejando poco margen para ajustes e improvisaciones basadas en resultados. Las hojas de ruta, los planes, muestran una lista de características, no áreas de enfoque y / o resultados.
- Sin ajustes. Una vez que el trabajo está “hecho” (de acuerdo con los principios de los gerentes de desarrollo), el equipo pasa inmediatamente al siguiente “proyecto”, sin dejar tiempo para iterar con datos cualitativos y cuantitativos que deriven en planes de mejora y de calidad.
- Cultura de traspaso del entregable. El equipo no está directamente involucrado en la investigación, exploración de los problemas/retos a afrontar o experimentación y la posterior validación. Una vez que se finaliza el trabajo, el desarrollador tiene poco contacto con el soporte, la satisfacción del cliente y los resultados comerciales.
- Grandes conjuntos de paquetes. Sin el mandato de experimentar, las funciones se entregan en grandes paquetes de funciones, en lugar de entregas incrementales. Si se aplica medología agile, puede darse el caso que, aún trabajando en sprints, pero nada nuevo llege a los clientes al final de cada entrega.
- Búsqueda de ingresos por adelantado. Se implementan funciones para cerrar nuevos acuerdos puntuales. Si bien este engoque no es intrínsecamente incorrecto, las justificaciones económicas a menudo son endebles (en el mejor de los casos) y no tienen en cuenta el aumento no lineal en la complejidad del producto (se obtienen beneficios a corto plazo, que repercuten más adelante) . Denuevo se refuerza la idea de que las características son la unidad de medida del valor. Las decisiones sobre productos carecen de una visión y estrategia económica sólida.
- Proyectos “estrella”. La entrega constante de nuevas funciones eclipsa otro tipo de iniciativas necesarias. Tienen baja visibilidad los trabajos de rengeniería, reducción de costes y entrega de valor. Enfocarse en esas funciones estrella resta relevancia a las tareas sobre el impacto de las nuevas funciones en la usabilidad, la capacidad de mantenimiento, la esalabilidad,etcétera.