Fondo -
Trabajo para una empresa de genética del tamaño de unas 100 personas que acaba de ser propiedad de una corporación de más de unas 8000 personas. Durante los últimos 2 años he sido nuestro gerente de proyectos de desarrollo de software y he aprendido cómo hacer este trabajo y las mejores prácticas basadas puramente en la experiencia que he ganado aquí, mis propios errores, libros, blogs, seminarios web, etc. No " entrenamiento formal; pero tengo una maestría en bioquímica, por lo que, por alguna razón, me consideraron una buena opción para este puesto.
Recientemente, un par de miembros de nuestro personal (personal de laboratorio que no forma parte de un departamento de PM) asistieron a un programa de capacitación de cinturones verdes patrocinado por la empresa de 2 semanas para su propio desarrollo personal. Ahora estas personas han regresado y tienen un proyecto para completar y tienen todas estas herramientas de cinturón verde listas para usar. Uno de los proyectos se centra en nuestro software de laboratorio interno, que en realidad es un cambio bastante pequeño. Si estuviera reuniendo requisitos, no planearía tomar más de 1 mes. Sin embargo, a través del uso de la DMAICmodelo, mi colega logró que este pequeño cambio de software tomara 4 meses e innumerables reuniones, y apenas estamos comenzando el paso Analizar. Estoy sentado, mirando cómo sucede esto y simplemente desconcertado por el proceso aparentemente intrincado. (Sin mencionar que estoy algo... confundido acerca de por qué otra persona está haciendo mi trabajo).
Entonces, el quid de mi pregunta es: ¿alguien puede hablar sobre la utilidad de las técnicas de cinturón verde para proyectos de software de tamaño pequeño o mediano? Según mi experiencia y sentido común, esta parece una herramienta demasiado poderosa para el proyecto en cuestión. Pero sin ninguna experiencia real con el entrenamiento de cinturón verde, y solo un par de años de experiencia en PM de software, tengo miedo de decir '¡¡ESTO ES BASURA!' a mi alta gerencia (quien, por supuesto, piensa que el cinturón verde es excelente porque lo hace la empresa).
¿Pensamientos?
¡Bienvenido a PMSE! Todo depende de lo que quieras de él. A menudo, los beneficios de enfoques como Six Sigma se ven en una mejor gobernanza y el desarrollo de flujos de trabajo repetibles. Es posible que no se traduzca en un desarrollo de software más rápido y económico a corto plazo. Pero tiene beneficios para las partes interesadas corporativas.
¡Bienvenido a PMSE! Genial ver a gerentes de fuera de la industria de TI.
Creo que la palabra aquí es sastrería . No es algo exclusivo de las técnicas de un cinturón verde en una empresa ~100, también se aplica para aplicar todas las reglas de PMBoK en un proyecto con 5 personas o administrar un proyecto con un cuaderno de papel para construir un transbordador espacial.
Se supone que las metodologías ayudan, son medios para un objetivo. Cuando proporcionan más daño que beneficio (como parece ser el caso), deben revisarse y... adaptarse.
Si desea algunos argumentos sólidos para usar en esta discusión, creo que la adaptación del proyecto se menciona en los primeros capítulos de PMBoK.
Trabajo para una gran empresa de TI en mi 9-5 donde Six Sigma se presenta como una estrategia de calidad imprescindible para cada proyecto, ya sea grande o pequeño (yo mismo estoy certificado como cinturón verde). Además, tomo trabajos de consultoría de vez en cuando para pequeñas agencias de desarrollo donde he asesorado y dirigido proyectos Six Sigma exitosos.
Como señala, un proyecto DMAIC puede tardar demasiado en completarse y puede dejar de tener sentido en el camino. En mi empresa, los proyectos que tardan más de 3 meses en implementarse se marcan como "fallidos" o no se consideran impactantes (una de las razones detrás de esto es la idea de que la industria de TI cambia demasiado rápido para esperar 3 meses). -mejoras). Otra razón para evitar proyectos extensos de 6 años es que, en algún momento, la mejora real a veces puede ser más costosa que el problema (si las reuniones son semanales e involucran a 10 empleados + 5 gerentes solo para un proyecto de ahorro de centavo, entonces también podría desea verificar si esto es razonable para continuar).
En cuanto a su pregunta real:
¿Alguien puede hablar sobre la utilidad de las técnicas de cinturón verde para proyectos de software de tamaño pequeño o mediano?
Para mí, los proyectos 6s, además de reducir los defectos, son solo una forma de poner mejoras de calidad en números, así que digo que depende totalmente si esto es solo una maravilla en su empresa o si en realidad está comenzando a entrar en un proceso continuo . estrategia de mejora . Probablemente estas personas que están ejecutando estos proyectos se convertirán más tarde en los cinturones verdes/negros y liderarán otros proyectos de mejora dentro de la empresa, y en mi experiencia, tienes que empezar con algo y no todos los proyectos 6s que encuentres serán un gran avance en el empresa. Entonces, como se sugirió anteriormente, el proyecto en cuestión necesita algunos ajustes o tal vez no use una solución tan compleja como DFSS.
En un curso de 6s, un instructor nos dijo: " En teoría , un departamento de Six Sigma/calidad podría cerrarse si se demuestra que el tiempo/esfuerzo invertido en proyectos para crear soluciones y mejoras es en realidad más costoso que las soluciones implementadas ". .". El punto era que 6s en realidad puede convertirse en un defecto en su empresa, en lugar de una solución.
Así que mi opinión es que 6s es un conjunto de herramientas muy interesante, útil y poderoso, sin embargo, en mi experiencia personal, no todos los proyectos de 6s sugeridos son útiles ni deben perseguirse: siempre deben estar presentes los objetivos SMART y un alcance claro del proyecto. , PERO ese es el trabajo del campeón para identificar, en este caso no debe acercarse a la gerencia diciendo '¡¡ESTO ES BASURA!', sino al campeón (es) del proyecto.
Además, recuerde que las mejoras sugeridas en 6s no son exclusivas para grandes corporaciones/proyectos, la idea es reducir los defectos, y estos se pueden encontrar en cualquier proyecto, independientemente de su tamaño.