Estoy trabajando como líder de proyecto en un equipo de 5 desarrolladores y yo mismo y tomando el papel de analista. Dentro de la empresa, llevamos varios años aplicando los principios ágiles.
Algunos de los principios que más valoro son la autoorganización y la superación personal, probablemente porque antes trabajé en un entorno jerárquico fuerte donde los niveles más altos pensaban por ti.
Pero a mi equipo no parece importarle demasiado. Les gusta la forma en que están trabajando. Incumplimiento de plazos, exceso de presupuesto, mala calidad, siempre es causado por otros, las soluciones nunca se buscan en el propio equipo. Las retrospectivas a menudo conducen a discusiones interminables sobre culpar a otros, pero falta la introspección sobre el desempeño de nuestro propio equipo. En los días malos, creo que mis desarrolladores son solo niños malcriados que no recuerdan cómo era en los viejos tiempos de "cascada", donde los desarrolladores eran solo monos de programación. Pero sueno como un anciano, ¿no es así?
Mi primera reacción es cambiar al modo de microgestión, que sé que es probablemente la peor solución, pero ¿existen mejores formas de animar a mi equipo a estar más organizado?
Si un programador se hace cargo de un proyecto, desea que tenga éxito; busca formas de mejorarlo y mejorarlo; intenta abordar los problemas difíciles.
Parece que los problemas que está teniendo se derivan de la falta de propiedad del proyecto. Cuando esto sucede, un desarrollador culpará a los demás, no se preocupará por el proyecto, no trabajará bien con otros compañeros de equipo, no se comunicará, etc.
En última instancia, deberá lograr que el equipo tenga un sentido de propiedad en el proyecto.
Estás en el equipo también. Si puede ver problemas específicos, ¿por qué no mencionarlos? Si quiere que los demás sean introspectivos, muéstreles cómo hacerlo siendo usted mismo introspectivo. Es un poco irónico quejarse de cómo los demás se quejan de los demás.
El hecho es que hay muchos factores fuera del control de un equipo de desarrollo de software. Es importante reconocer cuáles son y traerlos a la superficie. Sin embargo, el siguiente paso es identificar formas constructivas de mitigar esos factores. Por ejemplo, si alguien de quien necesita información no es confiable, mueva las tareas que lo involucran en el cronograma y haga un seguimiento más de lo normal. Las personas pueden lidiar con cosas fuera de su control si saben que han hecho todo lo posible.
Hagas lo que hagas, ¡no microgestiones !
Eso es lo peor que podrías hacer. Pondrás mucho estrés en ellos, en ti mismo, matarás la productividad potencial del equipo y te convertirás en el cuello de botella del equipo.
No estoy diciendo que su equipo sea un grupo de niños quejumbrosos, y ciertamente no estoy diciendo que sean inútiles, pero mi experiencia es que aproximadamente 4 de 5 desarrolladores en el campo hoy en día no se motivan a sí mismos, no son emprendedores y necesitan un fuerte liderazgo y orientación para ser productivos.
Es probable que no sientan una orientación sólida sobre los requisitos o que carezcan de liderazgo técnico o ambos. El quid de la cuestión es que están culpando a los demás porque no hay un líder presente para hacerse cargo de la situación y ninguno de ellos está dispuesto o listo para dar un paso al frente y asumir ese papel.
Mucho de esto es la naturaleza humana también. Un individuo fuerte con una inclinación por el crecimiento es introspectivo y puede admitir sus fallas y considerar cómo mejorarlas. Una persona débil no hace nada y culpa a las fuerzas externas fuera de su control por todas sus fallas.
Necesitas un equipo más fuerte o un líder realmente fuerte.
No hay consecuencias por no desempeñarse en su organización, entonces, ¿qué espera? Puede haber razones válidas para que un proyecto se retrase. Deben presentarse al líder cuando los reconozca, para que pueda hacer algo al respecto antes de que sea demasiado tarde.
El líder tiene que saber lo que está pasando y ser capaz de detectar excusas. Si tiene demasiadas excusas para no hacer su trabajo, entonces tal vez el desarrollador de bajo rendimiento y su equipo deban separarse.
Agile no tiene nada que ver con eso. Si esto hace que su trabajo sea más agradable que los 'días de la cascada', entonces deberían estar motivados para trabajar más duro/esforzarse por mejorar.
Busque a los que hacen lo correcto y reconózcalos. No hay necesidad de carteles o pegatinas de "Empleado de la semana" en sus cubículos. Haz tu trabajo; ocurren cosas buenas. No haga su trabajo; suceden cosas malas Así es la vida.
Comenzaría con reuniones uno a uno con los miembros del equipo individualmente. Resalte ejemplos concretos de dónde la culpa recae en el miembro y no en las fuentes externas. Y en general discuta cualquier área donde haya oportunidad para el crecimiento personal.
Los problemas de calidad son un gran ejemplo. Estos deberían conducir directamente al contribuyente que creó el defecto.
Los objetivos generales del equipo no son necesariamente su preocupación (en un entorno más saludable deberían serlo, pero el juego de la culpa hace que sea su problema, no el de ellos). Los problemas de presupuesto/fecha límite finalmente recaen en el gerente del proyecto. Nuevamente, estos tendrían que estar relacionados con áreas específicas de preocupación con el individuo y cómo contribuyeron al problema (como subestimar una tarea, pérdida de productividad, impacto de defectos, etc.).
Cree una estructura de incentivos que los recompense por resolver problemas. Luego déles la responsabilidad y la oportunidad de tener éxito (o fracasar).
Hay un gran programador, llamado The Clean Coder . Es muy motivador y exige que te hagas responsable de lo que escribes.
Creo que es posible que desee echar un vistazo a esta pregunta, muy similar. No cubre la parte de considerar que ya estás en una situación equivocada, sino más bien la motivación para la superación personal.
Gracias por las excelentes respuestas.
He tomado una serie de acciones basadas en ellos:
Pruebe http://www.openagile.com Debería ayudar con el trabajo en equipo y las habilidades generales de resolución de problemas mediante la promoción de ciclos repetidos de acción-reflexión-aprendizaje-planificación.
Consulte también "Software para su cabeza"
http://liveingreatness.com/the-core-protocols.html
Tiago Cardoso
Bartek Kobyłecki