Antecedentes
Trabajo en un equipo de desarrollo de software dentro de una gran corporación cuyo negocio principal no es el software. Estamos tratando de desarrollarnos de una manera "ágil", pero esto a menudo está en desacuerdo con la estructura de gestión más burocrática y pesada en la que trabajamos. Hay un aire general de insatisfacción tanto de nosotros mismos como de la gerencia acerca de nuestra capacidad para cumplir con los plazos, pero no tanto como para esperar que trabajemos horas extras no remuneradas.
Soy un desarrollador con 6 años de experiencia, 4 de los cuales en esta empresa, estoy entusiasmado con mi trabajo y quiero mejorar nuestra situación. En mi tiempo libre, a veces analizo prácticas de desarrollo y nuevos lenguajes de programación. Considero que tengo la perspicacia y los conocimientos suficientes para ayudar a mejorar la productividad del equipo, pero soy consciente de las limitaciones de mis conocimientos debido a mi relativa inexperiencia y falta de responsabilidad en la gestión. No manejo bien los conflictos y tiendo a retroceder o a responder de forma demasiado agresiva.
Situación
En una reunión de scrum reciente, nuestro jefe de control de calidad (llamémoslo "John") entró y se quejó de que no estábamos agregando comentarios en nuestro rastreador de problemas cuando los movíamos de un estado a otro, exigió que lo hiciéramos y declaró que esto era "no negociable", citando esto como necesario para fines de auditoría externa y acreditación. Cansado del comportamiento similar de John en el pasado (él es el administrador del servidor de seguimiento de problemas y, a menudo, realiza cambios en un intento de hacer que trabajemos de una manera particular), y bastante seguro de que las acreditaciones externas no son tan prescriptivas con respecto a flujo de trabajo, me reí y medio en broma pregunté "¿podemos hacerlo negociable?". (Es cierto que no es el movimiento más inteligente que ahora reconozco). John dijo rotundamente que no. Le pregunté si podía señalar algo en nuestro wiki interno que nos dijera qué tipo de comentarios deberían hacerse y cuándo/dónde, pero dijo que era simplemente "sentido común". Respondí que "claramente tiene requisitos específicos en mente con respecto a la auditoría. Es completamente irrazonable hacernos demandas si [él] no las va a hacer explícitas". Siguieron algunos intercambios acalorados pero relativamente intrascendentes.
Al salir de la reunión de scrum, John y yo estábamos detrás. Fuera del alcance del oído del resto del equipo, me dijo que "tendría una pequeña charla conmigo" ya que yo estaba "siendo antagónico". No cumplió con esto, pero estuve nerviosa toda la tarde esperando que lo hiciera.
La razón principal de mis objeciones fue/es que, según tengo entendido, como jefe de control de calidad, John no tiene la autoridad para dictar órdenes al equipo de desarrollo de esa manera. Con respecto al uso del rastreador de problemas, estoy a favor de incluir información útil, pero en aras de conservar una buena relación señal-ruido, estoy totalmente en contra de los comentarios de "sello de goma" que sirven solo como un ejercicio para marcar casillas. Soy consciente de que las auditorías externas nos imponen ciertos requisitos que deben cumplirse, pero creo que John estaba (intencionalmente o no) fusionando estos requisitos con sus propias opiniones sobre cómo deberíamos trabajar. No me importa tanto el tema en cuestión como el principio de que, como equipo, debemos ser tratados como profesionales que pueden asumir la responsabilidad de nuestro propio flujo de trabajo.
A la mañana siguiente, le expliqué la situación a mi gerente de línea para que me diera algunos consejos sobre cómo resolver la situación, durante lo cual estuvo de acuerdo con mi evaluación de que John se está excediendo en sus límites. Luego envié un correo electrónico a John para expresar mejor mis objeciones, pero no le hice ninguna acusación sobre su autoridad o de otra manera en esta situación. Esto resultó en una reunión solo entre nosotros dos, en la que explicó que a menudo hay ocasiones en las que implementamos funciones de una manera que difiere de los criterios de aceptación establecidos, lo que genera confusión entre el equipo de prueba. Yo no sabía esto y estuve de acuerdo con él en que sería bueno resolver este tipo de problemas de comunicación dentro del departamento.
Sin embargo, al día siguiente, John distribuyó una publicación de wiki que lamentablemente estaba mucho más cerca de la queja verbal que planteó en nuestra reunión de scrum. Parece que tomó algo de lo que dije al prometer estar "abierto a sugerencias", pero aún así dejó tanto énfasis en los requisitos sobre auditorías externas sin ser explícito sobre cuáles son que mi impresión general es que él está difundiendo suficiente FUD para que trabajemos en su forma reglamentaria. Lamentablemente, solo se refirió tangencialmente a los puntos genuinamente buenos sobre los problemas de comunicación que me contó en nuestra reunión privada.
Mi análisis
Creo que John se comporta de esta manera porque realmente cree que sus ideas mejorarán nuestra productividad (en contraposición a una toma de poder cínica por sí misma), tal como creo que lo harían mis ideas. La mejor solución para tales problemas es un compromiso pragmático entre sus puntos de vista y los de nosotros, un equipo de desarrollo, pero no estoy seguro de cómo lograr que se comprometa con nosotros de esta manera. Tengo la impresión de que otros miembros del equipo tienen frustraciones similares con él, pero se sale con la suya porque a menudo es más fácil someterse a sus caprichos que convencerlo de lo contrario.
He estado leyendo otras preguntas en este sitio en preparación para hacer esta y he visto muchos consejos sensatos de "Cómo ganar amigos e influir en las personas" que sugerirían que trate de presentar mis inquietudes de una manera más colaborativa que permita ambas partes a ceder terreno sin perder la cara. Sin embargo, toda mi experiencia con él me lleva a creer que esto nunca puede ser productivo mientras él tenga la creencia errónea de que tiene la última palabra sobre cómo hacemos nuestro trabajo.
La pregunta
¿Cómo puedo ayudar a corregir el equilibrio de poder entre nuestro equipo y este colega, de modo que podamos llegar a los acuerdos que mejor se adapten a todas las partes, sin crear conflictos innecesarios o comportarnos de manera poco profesional?
Es un cliché, pero la respuesta es ser el hombre más grande.
Crees que las intenciones de John son buenas, eso es clave. Complácelo, sé su abogado. No le des ninguna oportunidad de pintarte como antagonista. Si él cree honestamente que agregar comentarios mejorará la productividad, entonces siga el juego.
La próxima vez que esté a punto de mover un problema, piense detenidamente si hay algún contexto significativo que pueda agregar como comentario. De verdad, de verdad, honestamente, piénsalo bien. Solo porque algo es obvio para ti y sientes que debería serlo para todos, a menudo no lo es. E incluso si lo es, la información suele ser efímera, flotando verbalmente y enterrada en hilos de correo electrónico. ¿La próxima persona que trabaje en este problema, incluso si acaba de aterrizar de unas vacaciones de dos semanas, tiene toda la información que necesita para continuar allí mismo con el problema? Si no, actualice y comente hasta que lo hagan. Se aplican los principios de los boy scouts: déjelo en mejor forma de como lo encontró, no importa quién tuvo la culpa. Siempre errar por el lado de subestimar y sobrecomunicar.
Ahora, si su versión de los hechos es correcta y John está equivocado, muy pronto se encontrará con un problema en el que, literalmente, nada podría mejorarse. Ahora golpea: "John, ¿tienes un segundo? Esto es de lo que estaba hablando. Estoy totalmente perdido aquí, ¿qué debo comentar aquí?" NO sea agresivo ni se regodee, esta es una pregunta honesta: recuerde, John solo quiere lo mejor para el equipo.
Una vez que haya hecho eso varias veces, y John se haya quedado corto, agregue casualmente una sección a la página wiki de John titulada "Excepciones" y alinee las excepciones. A medida que esta sección crece con las excepciones aprobadas por John, se vuelve vergonzoso para él y revisará su posición, haciéndola menos rígida. John se dará cuenta de que eres una persona razonable y será más probable que considere tus preocupaciones en el futuro.
Y si no termina con esa lista de excepciones, tal vez John tenía razón después de todo, y sus sugerencias, aunque las compartió de manera torpe y sin gracia, en realidad mejoraron su trabajo, y usted no se interpuso en su camino.
Esta no será una respuesta popular, o algo que quieras escuchar. Creo que el verdadero problema está resumido en esta oración aquí:
Creo que un gran problema en nuestra empresa es que a nosotros (los desarrolladores) nos dictan tanto que esto sofoca cualquier impulso o sentimiento de responsabilidad para mejorar nuestra productividad.
Parece que su lugar de trabajo tiene muchas reglas, burocracia y una cultura general que sofoca parte del placer de programar, y eso es (comprensiblemente) muy frustrante. Entonces, parece que estás arremetiendo contra la solicitud de John, no porque su solicitud sea realmente un gran problema, sino porque estás frustrado y él no está en tu cadena de mando directa, por lo que es fácil atacarlo.
La solicitud de John es razonable y está motivada por una necesidad real. Las auditorías y acreditaciones externas son una preocupación válida para un jefe de departamento de control de calidad y sus superiores en la alta dirección (incluso si su empresa no es rigurosa al realizarlas). Si alguna vez se realiza una auditoría y encuentran un problema con el software defectuoso que se deslizó a través de su rastreador de errores o (peor) una falla de seguridad que navegó a través de su rastreador de errores, y no hay comentarios para proporcionar algún contexto para el proceso de pensamiento de los programadores, entonces la óptica es muy mala para John y su departamento de control de calidad. Lo primero que querrán saber es, "¿por qué sus programadores no comentan sobre las correcciones de errores?" Y su mejor respuesta será, "porque dejé que se salieran con la suya sin hacerlo". Esa no es una respuesta aceptable.
No es que John te esté pidiendo que hagas algo arduo. Si el error era "el botón está deshabilitado cuando se hizo clic en la casilla de verificación; no debe deshabilitarse", entonces simplemente agregue una sola línea (tal como lo hace (con suerte) en Subversion / Git: "botón fijo: ya no está deshabilitado cuando se hace clic en la casilla de verificación "). Si lo está moviendo desde el carril de natación En progreso a la Revisión completa / de aceptación (o cualquiera que sea el proceso de su empresa), simplemente déle a John un comentario de una línea. Incluso un comentario estúpido / repetitivo. Lo principal que Johns necesita es una idea del espacio mental de los programadores. Tarda como 10 segundos y ayuda a satisfacer una necesidad válida.
Parece que su empresa quiere (al menos intentar ) escribir un buen software, razón por la cual pagan los salarios de su departamento de control de calidad. Luchar contra la capacidad de su departamento de control de calidad para proteger a su empresa del software defectuoso (incluso si no lo están haciendo bien (en su opinión)) hace que la gerencia parezca que está siendo difícil y que trabaja en propósitos cruzados para un negocio válido. necesidad. Tu jefe no va a pelear esta batalla porque sabe que es una campaña inútil. Su empresa no impedirá que su departamento de control de calidad (intente) hacer su trabajo. Y el argumento de John ("necesitamos que esta pequeña cosa sea más a prueba de auditoría") es más fuerte que el suyo ("él no es mi jefe").
Seguramente, como desarrollador, ya está familiarizado con el concepto de alguien que sabe lo que quiere y lo que no está bien, pero no puede articular un conjunto de reglas claras y obvias que lo describan. La ironía de que su líder de control de calidad no pueda escribir requisitos para estos comentarios sobre un cambio de estado es rica, pero no lo ayuda a hacer su trabajo.
Le sugiero que se acerque al compañero de trabajo y le ofrezca (pregunte si está bien, sugiera que ustedes dos) agreguen una serie de buenos y malos ejemplos de comentarios al wiki que se inició. Sugiera trabajar juntos en voz alta antes de que se actualice el wiki. Dado que no le gustan los comentarios de sellos de goma sin contenido, puede incluir algunos de ellos ("listo para probar", "codificación completa", "como se discutió en scrum hoy") en el lado malo, y con un poco de suerte su líder de control de calidad sugerirá algunos por el lado bueno que abordan los problemas que la nueva regla está tratando de evitar ("pasar a la prueba aunque las categorías no estén en orden alfabético; el cliente ha aceptado que no necesitamos eso", "volver al código porque el cliente ahora quiere que todas las columnas estén centradas" ) o le ha gustado en el pasado.
Deberías salir de la reunión con
¿Qué puede doler?
Este es el trabajo de su gerente, si el equipo tiene un problema con un miembro, el gerente ya debería haberlo notado. Si no, llévelo a su atención.
Cualquier cosa que afecte el flujo de trabajo y la moral del equipo debe ser entregada al gerente para que la resuelva. Esa es la forma profesional, no andarse con rodeos ni inventarse sus propios protocolos. Es uno de los roles principales de los gerentes.
Robar
keshlam
Robar
Remojar