Somos un pequeño equipo de desarrolladores que trabaja en un proyecto de TI dentro de un departamento dedicado. No hay jerarquía entre nosotros en ese departamento, sino un objetivo común: poner en funcionamiento nuestra aplicación principal. Todos trabajamos en el mismo código.
Estoy bastante orientado a los detalles y tengo mucho cuidado cuando se trata de estándares, código limpio y preocupaciones arquitectónicas en general.
Ahora, uno de los desarrolladores más veteranos parcha el código de una manera que produce errores obvios. Además, sus cambios de código no respetan un cierto estándar de calidad. Básicamente, introduce muchos errores debido a una actitud despreocupada, o al menos por una razón que no puedo comprender en este momento.
El Gerente del Departamento no se preocupa por la limpieza y los detalles operativos. Quiere que se ejecute la aplicación principal y que podamos agregarle nuevas funciones. Implícitamente quiere que nos ocupemos de esos detalles. Sí creo que los estándares de calidad y la mantenibilidad del código son importantes, él lo ha aceptado, pero no hay nada formalizado en ese sentido. Más o menos "haz lo que debes, tiene que funcionar, no me importa cómo" territorio.
No tengo la autoridad en términos de jerarquía para 'corregir' al colega. Sin embargo, dado que produce errores, quiero que, por mera influencia amistosa, evite esos errores. Oculto esos errores al gerente y trato de resolverlos primero con dicho colega. Parece estar bien dispuesto, pero no parece que aprenda. También he tenido altercados verbales con él en el pasado porque pensó que me estaba entrometiendo demasiado en "sus asuntos". Pero sobre todo, nos llevamos muy bien y nos respetamos mutuamente. Podría ser percibido como un tipo más santo que tú, lo que no ayuda. Sin embargo, estoy tomando ese manto, sintiendo la necesidad de él.
¿Cómo procede para ayudar de manera cortés pero eficiente a uno de esos colegas a mejorar la calidad de nuestro código? Esto es principalmente una cuestión de comunicación.
Ocultar los errores no te hará ningún favor a largo plazo y en parte te ha llevado a esta situación.
Hay un par de vías para bajar potencialmente:
No arregle los errores usted mismo. Si hay una forma de registrar errores (tiene un rastreador de errores), regístrelos. Realmente necesita intentar conseguir un administrador a bordo para tener algún interés en la calidad del código. Como tener que detectar/arreglar el código de sus colegas, le impide realizar sus tareas.
Todos cometen errores, señalar errores en el código de alguien es como señalar que tuviste tos. Es natural, por muy bien que lo preparemos no puedes evitarlo al 100%, por lo que no debería ser un tabú.
Del mismo modo, dado que todos crean errores, no tiene sentido ocultarlos o no hablar de ellos con las personas involucradas y si la gerencia tiene que saber de los errores existentes, simplemente dígaselo, simplemente no juegue un juego de culpa.
Cuéntale a tu colega sobre el error. Si le importa el proyecto y su integridad como empleado, entonces señale que cree que el error podría haberse evitado siguiendo las prácticas X, Y, puede preguntarle si está de acuerdo con usted o no para asegurarse de conocer sus opiniones. sobre el asunto
Encontramos un error en A después del último parche, necesitamos corregir C, D. Para evitar futuros errores de tipo similar, creo que sería una buena práctica hacer X, Y, ¿estás de acuerdo? Si no, ¿qué crees que podemos hacer diferente para evitar esto?
Si no hay pautas oficiales, entonces no hay mucho que puedas hacer además de tratar de sugerir mejores prácticas, pero si él se niega rotundamente a escuchar y realmente crees que no es adecuado para el proyecto porque en general no le importa un comino cómo él hace su trabajo, entonces usted necesita comentarlo con su gerente más cercano y luego simplemente aceptar el resultado de lo que su gerente quiere hacer o no quiere hacer.
Sin embargo, si desea que la gerencia se preocupe más por la calidad del código, simplemente bríndeles ejemplos sobre cómo el no seguir ciertas prácticas podría y ha llevado a ciertos errores en el pasado, no solo en su proyecto sino en el de otros, y explique el impacto. A las personas no les importan las cosas que no entienden, si entienden por qué se deben seguir ciertas prácticas, es más probable que las apliquen.
Si no desea una discusión abierta con el colega, puede usar sus cosas de una manera que active el error. Lo que haces entonces es
No nos importa eso en este momento, debes concentrarte en X
Esta es una crítica justa que podría enfrentar por dedicar recursos a un problema que aún no es un problema, en cuyo caso es posible que desee eliminar los pasos 3 y 4 anteriores.
Hablar con el colega es, por supuesto, lo mejor que se puede hacer, mi respuesta ofrece una alternativa al ideal.
Creo que estás teniendo dificultades para saber cómo decir algo porque te sientes involucrado en el resultado. Y con razón, ya que ustedes dos son amigos y colegas.
Pero también siento que este es uno de esos momentos en los que tienes que dejarlo ir.
Si valoras tu amistad y el ambiente de trabajo, entonces solo tienes que aceptar este aspecto de tu amigo y seguir adelante.
Luego, armado con esta actitud, puede proceder a resolver realmente su problema.
Sólo díselo directamente.
Es en momentos como estos que recuerdo algo que había aprendido en la escuela secundaria: mensajes-yo.
"Me molesta cuando produce un trabajo con errores porque luego tengo que corregirlos. Realmente desearía que no hiciera más esto".
Siento... cuando tú... quiero.
Si esto no funciona, entonces cambiaría mi enfoque del problema, es decir, igualaría su actitud y dejaría el pasado en el pasado porque, después de todo, nunca se sabe realmente quién es el mejor ingeniero .
"I feel annoyed when you produce work with bugs because then I have to fix them. I really wish you wouldn't do this any more."Esta es una frase bastante hostil. Invoca una mentalidad de "yo contra ti". Compare esto con la sugerencia de Jonast92 de We found a bug in A after the latest patch, we need to fix C,D. To avoid future bugs of similar sort I think it would be good practice to do X,Y, do you agree? If not, what do you think we can do differently to avoid this?Esto es en gran medida una mentalidad de "nosotros contra el problema".¿Tienen revisiones de código obligatorias ? Mi sensación es que la respuesta a esa pregunta es no. Si lo hizo, ahí es donde tales excepciones deben ser capturadas, documentadas y el cambio rechazado.
¿Tiene un sistema de seguimiento de problemas como Jira? Debe documentar sus hallazgos, incluir diferencias de archivo y describir cómo introducen un defecto. Además, describa una serie de pasos sobre cómo reproducir el defecto causado por el cambio de código mal implementado.
Debe hacer que su objeción sea lo más formal posible y utilizar hechos concretos y demostrables, no opiniones. Esto no es una cuestión de "habilidades blandas", personalidad u opiniones. Se trata de una incompetencia fácilmente demostrable y debe documentarla como tal, a la vista de sus superiores. Deben elegir un curso de acción. En mis 20 años de experiencia en programación, amonestar a un compañero de trabajo sobre el tipo de objeciones que tiene y que he tenido muchas veces, es casi inútil. Pero si no puede demostrar lúcidamente su caso de una manera que sea comprensible para alguien con poder de decisión, es probable que caiga en oídos sordos.
Si sus superiores reconocen sus quejas, es de esperar que pueda presentar un caso para implementar revisiones de código obligatorias como parte del SDLC, que sospecho que alguien de sus inclinaciones debería agradecer.
Por lo general, sucede en productos que su empresa no tiene que mantener, o proyectos en los que el gerente del proyecto no tiene suficientes habilidades de programación. Lo único que puede hacer es informar a su jefe de proyecto y a sus compañeros de equipo los problemas que está enfrentando para mantener este proyecto sin cumplir con los estándares de calidad y mostrar números. Si el cliente acepta esta pérdida de dinero, lo más probable es que a nadie le importe, solo a la persona que se enfrenta al infierno. Si se trata de un proyecto de presupuesto cerrado o un proyecto que mantienes habitualmente, tu empresa te escuchará. Lo más fácil es detectar el error y ayudarlo hasta que aprenda lo suficiente como para resolver los problemas por sí mismo.
Probé revisiones de código en un par de equipos, pero son una carga que requiere soporte de administración continuo. Difícil de aceptar. Y no infalible.
Lo que funcionó para nosotros fue que cada desarrollador tenía que producir pruebas unitarias documentadas. De esta manera, generalmente detectaron sus errores antes de la implementación de las pruebas de aceptación del usuario.
Para proyectos complejos más grandes, equipos de 2 o más analistas crearon las pruebas unitarias para los equipos de codificación a partir del diseño/requisitos. Ejecutarían estas pruebas para el equipo en su conjunto. Eso no eliminó el requisito de prueba unitaria, pero agregó la capa necesaria para garantizar que todas las actividades del equipo de desarrollo se mantuvieran juntas como un todo.
Hacer que las pruebas unitarias documentadas formen parte del proceso de confirmación del código para cada persona del equipo garantizó que los desarrolladores del asiento de los pantalones usaran la disciplina adecuada sin señalar a nadie.
Los defectos del equipo se redujeron en un 80 % o más con esta disciplina. El esfuerzo de soporte de guardia se redujo hasta el punto de que casi nunca nos llamaban después de una nueva implementación.
La complejidad/formalidad del plan de prueba se ajustó en función del nivel de impacto... a menudo solo un párrafo para pequeños cambios... pero los resultados esperados y los resultados reales tenían que documentarse (capturas de pantalla, etc.).
Después del éxito de hacer cumplir esto dentro de nuestro equipo durante varios años, el equipo de control de calidad introdujo este requisito en todo el departamento de TI (lo hicieron de forma independiente a medida que maduraba el control de calidad en nuestra empresa).
De vez en cuando hacíamos revisiones de código en nuevos compañeros de equipo o cuando trabajábamos con nuevas tecnologías. Pero eso no suena como su problema.
Con una nueva aplicación que estábamos construyendo, comenzamos a documentar y guardar los planes de prueba de unidad para que pudieran reutilizarse. Estábamos usando Team Track para hacer esto. No era la mejor herramienta, pero era mejor que una biblioteca de documentos de Word. Nos permitió seleccionar qué funciones necesitaban pruebas y pudimos editar los planes para documentar nuestros cambios. Luego, podríamos ejecutar todos los escenarios de prueba relacionados y documentar el éxito o el fracaso.
Carreras de ligereza en órbita
keshlam
darwin
anfibio
HLGEM
Juha Untinen
mwbl
André Werlang