¿Ideas para trabajar con un compañero que no sigue los estándares definidos por el equipo?

Question

Al trabajar en un entorno de equipo, ¿cómo manejarías a un desarrollador que se niega a seguir los estándares definidos por el equipo?

1) desarrollador está en un nivel menor

2) desarrollador está en un nivel de pares

3) desarrollador está en un nivel alto

Sé que esto es sugerente pero siento que beneficiaría a los desarrolladores haciéndolos más profesionales. ¡Gracias!

Answer 1

1) desarrollador está en un nivel menor - Mentor; sea ​​amable & suave. Explique la necesidad de estándares en general y luego explique la necesidad del estándar particular que no se está siguiendo. Haz esto con una mente abierta; si no puede justificar el estándar, ¿entonces quizás no debería ser un estándar?

2) Desarrollador está en un nivel de igual - esto debería ser lo suficientemente fácil - si puede mantenerlo técnico y no dejar que se disuelva en un choque de personalidades. Nuevamente, si puede justificarlo, probablemente debería ser un estándar, pero si tiene un argumento igualmente convincente en contra, entonces tal vez no. Sin embargo, haga no acepte que no debe haber un estándar. Pídale un estándar sugerido para reemplazar el que no le gusta. Si él no cumple, entonces escala. Si no te gusta, ponlo a votación/escalar. Intente evitar la escalada, pero intente asegurarse de que es estándar.

3) desarrollador está en un alto nivel de tratar de razonar. Escuche atentamente, puede estar en lo cierto. En caso de duda, póngalo a votación/intensifique.

Advertencia: las normas son agradables (imo, absolutamente necesaria, pero tu caso es distinto), pero son difíciles de “hacer cumplir” a no ser alcanzado por consenso.

Excepción: "codificadores de vaquero" deben ser abofeteados difícil; sin expectativas.

No se sienta mal por “acusar” al jefe. Cuando se trata de un codificador de vaqueros, sigue el lema del vaquero: "este equipo no es lo suficientemente grande para los dos"; o deja de hacer vacas o uno de ustedes tiene que irse de Dodge.

Answer 2

Si hay un documento de estándares en su lugar, a continuación, simplemente apunta al documento y diles que tienen que cumplir con la norma. Si no hay ningún documento en el lugar y es algo ad hoc "esto es de facto cómo este equipo ha estado codificando", entonces organice una reunión para crear un consenso sobre cuáles deberían ser los estándares del equipo y crear un documento de estándares. Creo que es bastante difícil argumentar con la necesidad de un estilo consistente en aras de la legibilidad y el mantenimiento, y cuando existen reglas que dicen "hazlo de esta manera", es mucho más difícil diferenciarlo de lo que es. simplemente práctica establecida.

Answer 3

Par de programación puede ser mi mejor sugerencia ya que esto puede ayudar a asegurar que todos se incorpora al mismo nivel y ayudar a fomentar un sentido de comunidad dentro del equipo. Esto cambia la responsabilidad hasta cierto punto, pero la idea es hacer que alguien intente hacer que la otra persona haga las cosas como lo hacen los demás.How to Win Friends and Influence People tiene los siguientes puntos que pueden ocurrir aunque éstos son generales:

técnicas fundamentales en el manejo de personas

1. No critique, condenan, o se quejan.
2. Dale sincero y sincero agradecimiento.
3. Despierta en la otra persona un deseo ansioso.

Seis maneras de hacer que personas como usted

1. Se convierte genuinamente interesado en otras personas.
2. Sonrisa.
3. Recuerda que el nombre de un hombre es para él el sonido más dulce e importante en cualquier idioma.
4. Sea un buen oyente. Aliente a otros a hablar sobre ellos mismos.
5. Hable en los términos del interés del otro hombre.
6. Haga que la otra persona se sienta importante y hágalo sinceramente.

Doce maneras de ganarse a la gente a su forma de pensar

1. evitar discusiones.
2. Muestre respeto por las opiniones de la otra persona. Nunca le digas a alguien que están equivocados.
3. Si te equivocas, admítelo rápida y enfáticamente.
4. Comience de manera amistosa.
5. Comience con las preguntas que la otra persona responderá sí a.
6. Deje que la otra persona hable.
7. Deja que la otra persona sienta que la idea es suya.
8. Intente honestamente ver las cosas desde el punto de vista de la otra persona.
9. Simpatice con la otra persona.
10. Apelación a motivos nobles.
11. Dramatice sus ideas.
12. Lanzar un desafío & no hablar negativo cuando la persona está ausente, hablar de positivo solamente.

ser un líder: Cómo cambiar personas sin ofender o Arousing resentimiento

1. Comience con elogio y aprecio sincero.
2. Llamar la atención a los errores de otras personas indirectamente.
3. Hable primero de sus propios errores.
4. Haga preguntas en lugar de dar órdenes directamente.
5. Deje que la otra persona guarde la cara.
6. Elogie cada mejora.
7. Deles una excelente reputación para vivir.
8. Aliéntelos haciendo que sus fallas parezcan fáciles de corregir.
9. Haga que la otra persona esté contenta de hacer lo que sugiere.

Answer 4

Utilizamos TFS y Código de políticas para la llegada como una manera de hacer cumplir las normas del código. Las otras respuestas estoy de acuerdo completamente con la parte del pueblo. Para algunos estándares de codificación como los estándares de nomenclatura variable, puede dedicar un poquito de tiempo (tal vez el desarrollador en cuestión puede escribir estos) y escribirlos. Si los incorpora en su proceso de compilación, parte de la validación de una compilación implica verificar la fuente de los estándares de código correctos. Usamos MSBuild con Visual Studio 2008 y funciona muy bien. Eso ayudará algo cuando se haya desarrollado un sistema para hacer cumplir las normas, ya que a veces es más difícil discutir con un sistema de compilación. Además, es útil que las construcciones traten esas violaciones como errores en el estudio visual en lugar de solo advertencias para su posterior aplicación. Sobre todo, la parte "por qué" de los estándares es lo más importante para un desarrollador de cualquier rango. Si entienden por qué los estándares son útiles y entienden el foro/oportunidad (reunión de desarrollo mensual) donde pueden expresar el razonamiento en contra de un estándar particular, con suerte pueden comenzar a seguirlos junto con el equipo exitoso.