Mi experiencia es que los equipos de desarrollo (pero en general, cualquier equipo) constan de 3 tipos de personas:
- aquellos con un disco incorporado de calidad,
- aquellos que solo están por el dinero (cerveza / chicas / lo que sea) y no les importa lo que trates de motivarlos,
- los "mediocres" (por falta de una palabra mejor).
El último grupo es el más grande y tienden a seguir al partido gobernante. Si hay suficientes personas de calidad en el equipo, pueden atraer a la mayoría consigo mismos, creando una fuerte espiral ascendente en el espíritu y la motivación del equipo. Sin embargo, si hay demasiados holgazanes, pueden crear fácilmente el efecto contrario, una espiral de muerte.
Entonces, la tarea principal para el gerente es elegir y mantener a las personas adecuadas y deshacerse de los malos lo antes posible . Sin embargo, no son los "mediocres": pueden verse influidos para comenzar a mejorar, para prestar apoyo a las buenas ideas de los demás, y algunos de ellos eventualmente podrían convertirse en creadores de tendencias positivos por derecho propio.
[Actualización2] reflexionando sobre la respuesta de Alb : en mi opinión, no es necesario que los desarrolladores de calidad tengan una clara mayoría dentro del equipo (aunque no hace daño :-). Hay un "umbral de establecimiento de tendencias" , por encima del cual las opiniones y el comportamiento de un subgrupo pueden convertirse rápidamente en la "corriente principal" dentro de una comunidad , por lo que otras personas se dan cuenta y comienzan a seguir. Puede ver esto en el trabajo en la sociedad en general todo el tiempo (por ejemplo, hábitos (no) de fumar, salud y dietas, modas, alimentos orgánicos). Mi estimación aproximada es que puede estar en algún lugar alrededor del 25-30%, pero depende de muchos factores. Aquí es donde las personas malas pueden lastimar mucho. Incluso un par de personas malas dentro de su equipo pueden aumentar ese umbral significativamente. [/ Actualización2]
Por supuesto, no siempre es posible contratar suficientes de los mejores. Entonces, cuando la primera facción no es lo suficientemente fuerte como para manejar las cosas por sí misma, la gerencia necesita ayudarlos. Un par de pensamientos sobre esto:
Creo que Scrum tiene una buena idea para esto con demostraciones de productos. Demostrar la función que implementó frente a una audiencia que consiste no solo en sus compañeros de equipo, sino también en desarrolladores de otros equipos, la administración e incluso los usuarios de la aplicación puede ser una gran fuente de orgullo y también un factor importante para ayudar al equipo a meditar.
Otra cosa es que la gerencia escuche en serio al equipo de desarrollo con respecto a la calidad. DeMarco y Lister incluso mencionan que hay empresas / departamentos donde los equipos de desarrollo tienen un veto sobre lo que puede pasar a la producción. Si consideran que la aplicación aún no está lista para el horario de máxima audiencia, pueden posponer el lanzamiento independientemente de lo que le gustaría a la administración. Ahora, eso es difícil para la administración, pero puedo imaginar que desarrolla el espíritu de equipo y comunica fuertemente el mensaje de que la calidad es realmente importante aquí, no solo en el nivel de las palabras.
Esto lleva al siguiente punto: para crear un "culto a la calidad", la gerencia debe comprender a fondo lo que la mayoría de los desarrolladores experimentados ya saben: que la calidad no es una ocurrencia tardía: debe integrarse en el producto desde el principio. Por lo tanto, se debe alentar a las personas (y recompensarlas) a pensar en la mantenibilidad a largo plazo, esforzándose por las buenas soluciones, en lugar de las rápidas .
Actualizar
@Machado en su comentario dio un nuevo giro a la pregunta (al menos para mí):
¿Qué puedo hacer yo, como miembro del equipo, no como gerente, para mejorar la calidad del código de mi equipo?
Algunas reflexiones:
- Sigue aprendiendo y difunde el conocimiento a cualquiera que escuche. Aprenda y use las mejores prácticas dentro de sus áreas de especialización.
- Enorgullécete de tu trabajo .
- Estos dos casi naturalmente te permitirán convertirte en un modelo positivo para otros , especialmente para los recién llegados y los juniors; sea consciente de esto y aproveche su papel para el beneficio de todo el equipo. La mejor manera de influir en los demás es con un ejemplo positivo.
- Mire no solo el código, sino todo el proceso de desarrollo de software; siga haciendo preguntas y proporcionando comentarios para optimizar el proceso de desarrollo .
Y por último, pero no menos importante: encuentra un lugar donde puedas ser un "tipo superior" . Si estás en el grupo "mediocre" en este momento, esfuérzate por desarrollarte, ojalá las ideas anteriores te ayuden. Pero si se encuentra en el "estrato inferior" de su equipo actual, le recomiendo que analice los motivos. ¿Qué es lo que te desmotiva? Malas condiciones de trabajo? Compañeros de equipo? ¿Administración? ¿Tipo de trabajo? ¿Y qué es lo que te emociona e interesa? Es posible que deba hablar con sus compañeros de trabajo y / o jefe al respecto. O puede que necesite buscar un mejor trabajo, o incluso una nueva profesión, donde pueda comenzar a brillar. Realmente no vale la pena pasar una parte importante de la vida con actividades insatisfactorias o deprimentes.
También puede ser que se vea obligado a continuar su trabajo actual, subóptimo debido a factores externos (falta de mejores oportunidades de trabajo, necesidad de pagar las facturas, etc.): esto sucede de vez en cuando. Incluso en este caso, intenta sacar lo mejor de él. Producir un trabajo de calidad (en la medida en que las circunstancias lo permitan) es una recompensa en sí misma, que ayuda a mantener su autoestima y mantenerse sano y abierto a largo plazo. Por lo tanto, cuando aparece una oportunidad para algo mejor, está mejor preparado para aprovecharla.