Tengo un pequeño problema en mi empresa actual. Estamos implementando Atlassian JIRA como nuestra herramienta de gestión de proyectos tanto para problemas comerciales como para el desarrollo de software y, aunque los equipos de desarrollo de software están entusiasmados y saben bastante bien cómo funciona Agile y cómo deben gestionarse los proyectos, tenemos un problema para "vender la idea" a las empresas. gerentes - que también están integrados en el proceso.
La forma en que funcionan las cosas en JIRA y la forma en que las hemos configurado es la siguiente:
Cada proyecto es un proyecto separado, mantenido por administradores de proyectos y desarrolladores de software separados. Internamente, tiene números de versión en los problemas y cada problema tiene subtareas, que rigen los diferentes estados del problema, como cuando el problema requiere análisis técnico, desarrollo o pruebas adicionales. Una vez que los problemas tienen sus subtareas realizadas, el problema se configura como solucionado y luego, una vez que se activa, el estado cambia a En vivo y el problema se cierra por completo.
Esto funciona.
Pero tenemos un problema con los gerentes comerciales. Su flujo de trabajo de la vieja escuela es el siguiente:
Este enfoque es problemático, ya que es terrible para obtener informes, estimaciones y cualquier tipo de estructura de dicho árbol.
He estado tratando de dejar en claro que no es posible pensar de esta manera de manera efectiva y que al principio simplemente deberían enviar el primer problema a análisis para ver cuántos 'problemas reales' deberían crearse y esos problemas deberían ser luego enviados a sus departamentos apropiados para el desarrollo y, si es necesario, vinculados al problema original, para actualizaciones de estado por su parte.
Pero no está teniendo suficiente agarre, es un clásico 'hemos estado haciendo las cosas de esta manera y estamos bien con eso' bloqueado en guardia y hay un problema para quitarse de la mente el pensamiento de la vieja escuela del 'árbol sin fin' en la gestión de proyectos .
¿Alguna idea de cómo 'vender' la idea de gestión de proyectos basada en sprints de colas y proyectos? Uno de los problemas parece ser que a los usuarios les cuesta saber qué hacer con un problema, si el problema es tan grande que debería ser un proyecto completamente nuevo o simplemente un problema separado y hacia dónde debería ir a continuación.
Rechinando los dientes aquí :) ¡Cualquier idea es bienvenida!
Estoy de acuerdo con el comentario de @salsolatragus... su problema es que el lado comercial no usa Agile en absoluto. Desde mi experiencia, este es un dolor de crecimiento clásico que sucede... Así que obligue al lado comercial a cambiar la forma en que ocurren sus interacciones.
Bloquearlos. (Pero descubra cómo venderlo mejor que eso...) Hágalo como un 'cambio de proceso' que esté respaldado por algún tipo de necesidad. Tal vez solo un poco de reorganización junto con el nuevo año calendario que se avecina.
Con esa reorganización ligera, diría que necesita enseñarles cómo debería ser su proceso. No les importará. Cuéntales de todos modos. Estos son los pasos que tomaría:
Ciérrelo. (Su proceso). Según la metodología Agile con la que es capaz de trabajar, ¿cómo deberían ser sus procesos de desarrollo? ¿Cuánto duran tus sprints? ¿Con qué frecuencia completas las historias? ¿Cuándo te quedas sin nuevos requisitos? ¿Cómo facilita su tecnología las tareas básicas detrás de la recopilación, priorización y ejecución de las tareas del proyecto?
Averigüe cómo cercarlos. El lado comercial debe saber cómo puede usar este proceso. Nadie les ha dicho todavía... nadie sabe cómo deben usarlo, por lo que ha crecido como un árbol fuera de control. Es su trabajo averiguar cómo se les debe permitir interactuar con este proceso. ¿Con qué frecuencia realmente necesitan proporcionarle nuevos requisitos? ¿Con qué frecuencia necesitan recibir actualizaciones de funcionalidades completas? Definir su uso para que puedan actuar de esa manera. [PERO NO LO CAMBIES ANTES DE DECIRLO]
Comuníquese... Si no tiene la influencia individual dentro de la organización para hacer que este cambio suceda, encuentre a alguien que sí lo haga y que entienda sus dolores. Haga que el caso comercial sea muy claro en términos de tiempo perdido debido a confusión, errores o algo así. Y luego comience a configurar la presentación o el manual del usuario o las instrucciones de proceso que respaldarán su 'nueva' forma de hacer esto.
Luego, comunique muy claramente a las partes interesadas del negocio que obtendrá nuevos requisitos de ellos una vez cada X... (¿mes? ¿trimestre?) y que son libres de analizar tanto como quieran en sus requisitos. juntando sandbox fuera de ese tiempo.
Concéntrese especialmente en cómo esto facilita su trabajo y cómo esto hace posible avanzar un paso a la vez.
Si están atascados en la configuración de minitareas porque así es como se sienten más cómodos expresando sus nuevos requisitos de funcionalidad, déjelos. No es necesario que luches con ellos para tratar de obligarlos a cambiar completamente lo que están haciendo... Pero déjales claro que debido a que son del lado comercial, las tareas se tomarán como una sugerencia y que el lado del desarrollo se reserva el derecho de añadir tareas adicionales que deban ser insertadas.
Luego, cercarlos realmente... Si puede encontrar la interfaz adecuada para entregar las solicitudes de requisitos, bloquee a los usuarios comerciales fuera de su interfaz de 'desarrollo de tareas'. Ese no es su trabajo. Y especialmente si no están jugando Agile contigo, entonces no son bienvenidos.
Sea diligente y disciplinado en la entrega real. Si los bloquea, asegúrese de que está haciendo lo que dijo que haría. Una vez cada mes o trimestre... se reúne con las interfaces comerciales individualmente, les dice los éxitos de sprint que se han completado... dígales qué está planeando su grupo a continuación... y luego pregunte si hay otros requisitos nuevos. ..
Salga de esa reunión con un conjunto claro de instrucciones para el próximo período de tiempo en términos de tareas que deben completarse y prioridades. Y luego enjuague y repita.
Cualquier sistema de gestión de proyectos tiende a formalizar los procesos de comunicación que, de lo contrario, se pasarían por alto. Solo necesita imponer una mejor comunicación aquí.
En mi empresa anterior, en el equipo de desarrollo de software cambiamos al proceso de desarrollo ágil. Durante un período de tiempo, los siguientes beneficios se hicieron visibles para la organización más grande:
En parte inspirado por esto, uno de los equipos comerciales comenzó a seguir el proceso de desarrollo ágil para el trabajo de desarrollo que no es de software. Todo lo que hicimos fue invitar a ese Scrum Master a una sesión de almuerzo ocasional para compartir las mejores prácticas.
Es posible que desee probar un enfoque similar. Sin embargo, esté preparado para que sea un proceso muy lento. Si está buscando resultados más rápidos, intente contratar a un buen consultor ágil.
Sven Amann