Customer Centric Process... un enfoque de procesos incusivos y alineados.
Hace poco tuve la oportunidad de escuchar a Monique Jansen, en una videoconferencia sobre "Customer Centric Process" y creo que amerita dediarle unas palabras, especialmente por lo clara que fué al describir las tres grandes áreas de Process Design, Process Healthcheck, Process Alignment
Especialmente porque a raiz de esto, me topé con una guía de autodiagnostico, en el tema de medición del estado de salud, y
Autodiagnostico "Process Healthcheck "
1. Entrega frecuente
¿Ha entregado funcionalidades en ejecución, probadas y utilizables a los usuarios al menos dos veces en los últimos seis meses?
Los requisitos de software a menudo son especulativos hasta que realmente se validan mediante inspección y uso. El valor del software en última instancia proviene de ese uso. Califique su proyecto alto si se entrega con frecuencia.
2. Mejora reflexiva
¿Se reunieron en los últimos tres meses para discutir y mejorar los hábitos de trabajo de su grupo?
Los elementos de un proceso, como las habilidades de sus participantes, la distribución geográfica y las demandas del producto que se está creando, deben ajustarse para que coincidan con el contexto. A medida que cambia el contexto del proyecto, el proceso debe adaptarse. El uso frecuente de retrospectivas del proyecto, o sesiones de reflexión dirigidas a identificar mejoras en el proceso, son críticas. Califique a su equipo alto si su equipo reflexiona regularmente y cambia su proceso.
3. Comunicación cercana
¿Le lleva menos de treinta segundos llevar su pregunta a la atención de la persona de su equipo que podría tener la respuesta? ¿Oyes algo relevante de una conversación entre otros miembros del equipo cada pocos días?
Tomar mucho tiempo para responder las preguntas o resolver problemas ralentiza al equipo. Peor aún, proceder con información errónea puede causar retrocesos innecesarios. Los arreglos de asientos colocados con la capacidad de hacer contacto visual con sus compañeros de trabajo son ideales. Sentarse lo suficientemente cerca como para levantarse fácilmente y hacer preguntas es bueno. Si no pueden verse o hablar fácilmente, puede ser útil desarrollar el hábito de la mensajería instantánea rápida cuando surge una pregunta. Si las preguntas se responden rápidamente dentro de su equipo, califique a su equipo alto.
4. Enfoque
¿Todos entienden el objetivo y el resultado deseado del software entregado? ¿Las personas conocen los elementos de máxima prioridad en los que deberían estar trabajando? ¿Están garantizados al menos dos días seguidos con dos horas ininterrumpidas cada día para trabajar en ellos?
Saber lo que está haciendo y por qué y tener el tiempo para hacerlo es fundamental para el éxito. En algunas organizaciones, puede saber lo que debe hacer, pero tiene poca comprensión del propósito del software que está creando y cómo beneficia a sus usuarios. En algunas organizaciones, las interrupciones dominan o los miembros del equipo pueden programarse en múltiples proyectos para que tengan poco tiempo en un solo proyecto. Califique a su equipo alto si tiene claridad de propósito en el equipo y en los niveles individuales y tiene tiempo suficiente para progresar.
5. Seguridad personal
¿Puedes darle malas noticias a tu jefe? ¿Pueden las personas terminar largos debates sobre los diseños de los demás con desacuerdos amistosos?
Idealmente, los miembros del equipo tendrán confianza en las habilidades, opiniones y juicio de los demás. El primer paso para generar esa confianza es poder hablar libremente sin preocuparse por el riesgo político o social. El hecho de no dar malas noticias por miedo evita que un proyecto se recupere y mejore de los contratiempos. El miedo a compartir opiniones puede impedir las actividades de colaboración. Califique su proyecto alto si los miembros de su equipo pueden y hablan libremente.
6. Fácil acceso a expertos externos
¿Tarda menos de tres días desde que tiene una pregunta hasta que un experto la responde? ¿Qué tal unas pocas horas?
Para comprender el contexto que lo ayuda a tomar decisiones sobre los requisitos del producto, necesitará acceso a expertos en la materia, partes interesadas del negocio y usuarios de todo tipo y niveles de experiencia. Necesitará acceso a estas personas para validar posibles diseños de software y software terminado. Idealmente, el acceso es fácil y frecuente. En el peor de los casos, no obtendrá la información que necesita ni podrá validar las decisiones hasta después del parto. Califique su proyecto alto si sabe quiénes son sus expertos y tiene acceso fácil y frecuente a ellos.
7. Ambiente técnico fuerte
¿Sus desarrolladores utilizan el sistema de gestión de configuración? ¿Sus pruebas de verificación están automatizadas? ¿Integran el sistema al menos dos veces por semana?
Para realizar adiciones y cambios al software rápidamente se requiere un entorno técnico que minimice los riesgos asociados con el cambio. La gestión de la configuración y la integración frecuente del código, seguidas de pruebas de regresión automatizadas, reducen el riesgo asociado con el cambio. Califique su proyecto alto si su equipo tiene herramientas y prácticas técnicas sólidas.
8. Visibilidad de día soleado
¿Todos los miembros del equipo entienden la tasa de progreso del producto? ¿Los comentarios de los usuarios y las partes interesadas? ¿Los riesgos para la entrega actual?
Como la construcción del producto está en movimiento, es importante poder ver la tasa de progreso y cómo eso afecta los planes. A medida que recopilamos los comentarios de los usuarios, es importante que todos comprendan cómo las soluciones del producto están soportando el uso real del producto. Califique su proyecto alto si alguien en el equipo puede responder rápidamente preguntas sobre la tasa de entrega en relación con el plan y cómo el producto realmente está respondiendo a los comentarios de los usuarios.
9. Cadencia o ritmo regular
¿Las actividades importantes del proceso ocurren en un ciclo regular y predecible?
Una característica común a la mayoría de los enfoques ágiles, incluido Scrum, es una cadencia o ritmo regular para trabajar. Los ciclos de sprint tienen una duración fija y deben comenzar y detenerse el mismo día cada semana. Se celebra una reunión diaria a la misma hora todos los días. Las actividades tales como las sesiones de planificación de sprint idealmente comienzan a la misma hora del día en cada día que ocurren. Este ritmo regular, que se encuentra en la mayoría de las cajas de tiempo y actividades ágiles, es tan común que muchos se refieren a él como un "latido cardíaco". La alternativa son muchas reuniones ad hoc que motean su calendario y crean días impredecibles. Califique su proyecto alto si las actividades importantes se programan con una frecuencia regular y en el futuro. Califique su proyecto más bajo si las actividades importantes se piensan en el último minuto o se programan para tiempos ad hoc.
¿Ahora que?
Si realizó este ejercicio, es probable que haya puntuado más alto en algunas propiedades y más bajo en otras. Comience con las áreas en las que obtiene la puntuación más baja y discuta qué podría cambiar para mejorar las cosas. Introduzca solo un par de cambios a la vez, asegúrese de que todo el equipo los entienda y esté de acuerdo con ellos, y luego acuerde un momento para regresar y reevaluar al equipo para ver si los cambios han ayudado. La evaluación y los cambios que discute son un ejemplo de mejora reflexiva: la segunda propiedad anterior.
