Cuándo enfrentar a un buen líder o jefe de proyecto

Nuestro jefe de proyecto es un arquitecto de software genio, una persona gentil y considerada en general, un geek por naturaleza y delicado por voz. Pero, a veces, nosotros (mis compañeros de equipo y yo) diferimos en las opiniones, especialmente sobre problemas de arquitectura de software, problemas de diseño del sistema, problemas de interfaz de usuario, etc., con nuestro líder.

¿Cuándo y cómo (si alguna vez) debemos expresar la diferencia en las opiniones?

Supongamos que piensas que tu jefe está equivocado. Tienes tres opciones

• haz lo que dice y termina frustrado pensando que haces algo estúpido, no muy bueno a largo plazo
• dígale que es un idiota, que lo ignorará o que tendrá problemas de comunicación, no le hará nada ni le hará daño.
• dígale que tiene inquietudes específicas sobre las ideas que propone y explique esas inquietudes : cualquier buen jefe explicará su posición y luego podrá tomar una decisión que sea buena para el negocio. Es muy probable que veas que su idea es mejor que la tuya y que has estado ignorando algo muy importante.

Siempre piensa en el resultado. En la mayoría de los casos, no desea tener la razón por tener razón, solo tiene que hacer un buen trabajo. La tercera opción ayuda a lograr eso.

Trátelo de la misma manera: con suavidad y respeto cuando exprese su oposición.

Ser profesional implica ser respetuoso con sus compañeros y superiores, no significa que no pueda estar en desacuerdo, solo significa que debe ser cortés y respetuoso por naturaleza.

Cuando mi equipo tiene dudas u opiniones discrepantes sobre mis instrucciones, lo veo como una oportunidad para la educación, tanto para mí como para los miembros de mi equipo.

¿No es este un ejemplo de la vieja falacia agresiva o pasiva?

La tercera opción clásica es la asertividad, que permite críticas constructivas y corteses. desacuerdo .

Igualmente importante: aceptar la crítica constructiva (sin estar necesariamente de acuerdo con ella) y aceptar un desacuerdo razonable (no obsesionarse con un concurso de quién está en lo correcto y quién está equivocado).

http://en.wikipedia.org/wiki/Assertiveness

Y al final del día, siempre será necesaria una especie de pasividad, que difiere de tu superior. Él es el que tiene la responsabilidad final de la decisión: capacidad, autoridad y responsabilidad no son lo mismo, pero al menos deberían ir juntas.

Por cierto, "People Skills" de Robert Bolton es un buen libro (y bastante barato) para cosas como esta: habilidades de escucha, asertividad y más.

http://www.amazon.com/People-Skills-Yourself-Resolve-Conflicts/dp/067162248X

Como pareces respetarlo y él parece un tipo inteligente, ¿por qué no preguntarle de la siguiente manera:

"¿Cómo maneja su método / forma / arquitectura el problema x?" Si no es así, diga algo como: "Bueno, ¿qué tal si lo hacemos así, de esa manera se maneja el problema x?"

De esta manera, puede aprender si ya ha pensado en "x problema" y si ha aprendido algo. O si no lo tiene, lo pensará y tal vez use su solución o piense en otra (tal vez lo resolverán juntos).

Desearía poder llegar a un ejemplo más concreto, pero creo que deberías poder entender la idea.

No creo que primero llegues a tu jefe, especialmente si no es un programador o algo así.

Y no hay necesidad de decir que su camino es malo, pero al preguntar cómo maneja ciertas situaciones, podría darse cuenta de un problema o ser capaz de decirle por qué no es un problema.

Espero que esto ayude.

Al usar la palabra CONFRONT, está demostrando que no está abordando el problema con la mentalidad correcta.

No es una confrontación. No es hostil No es beligerante ni enojado. Es una discusión de diferentes enfoques, costos y beneficios.

No entres con seis armas encendidas. Solo dile algo en lo que hayas pensado. "¿Y si tuviéramos que hacerlo así?" Quién sabe, podrías convencerlo.

Y si no lo hace, y a veces no lo hará, recuerde que él puede saber cosas que usted no sabe, sobre presupuestos, horarios, requisitos, otras prioridades, etc. No es necesariamente un idiota solo porque no está de acuerdo contigo.

No está mal dudar sobre cualquier decisión, o una arquitectura de diseño / software dada. A menos que recién comience su primer trabajo, en cuyo caso se equivocará el 99% del tiempo porque le faltan algunas partes de la imagen más grande .

Cuando usted (y / o el equipo) difieran de opiniones, pregúntele al líder del proyecto si tiene tiempo para discutirlo, o tal vez incluso planifique una pequeña reunión (15-30 minutos). Expresa tu propia opinión de manera respetuosa y escucha por qué tomó su decisión de otra manera. Si veo cómo lo describiste, estará encantado de discutir y compartir sus ideas sobre el problema. Él no dirá "porque yo lo dije" (esas personas existen tristemente). En ese caso, simplemente ignore su propia opinión si desea conservar su trabajo, o desahogarlo y salir para otro trabajo porque se sentirá infeliz.

Una buena discusión puede terminar de varias maneras:

• El líder del proyecto aceptará su solución como una mejor manera de resolver el problema (y tal vez aprendió una nueva tecnología, patrón, ... con el que aún no tenía mucha experiencia).
• Usted y el equipo pueden ver una parte más grande de la imagen u obtener una buena explicación de por qué deberían hacerlo de esta manera. Aprenderá algo nuevo y comprenderá que la solución inicial fue la correcta, o tal vez incluso encuentre una manera de mejorarla con la nueva información (aunque en algún momento tendrá que estar de acuerdo).
• La discusión no ayuda y aún no estás de acuerdo. Respira e implementa su solución (porque lo más probable es que tenga más experiencia), o vete.

De todos modos, debe verlo como una oportunidad para aprender y, siempre y cuando lo mantenga civilizado y respetuoso, tendrá grandes experiencias con estas discusiones.

¡Solo tráelo!

De la manera más civilizada y hábil que pueda, típicamente diré "Me preocupa este aspecto, ¿qué piensa sobre este problema potencial?"

Pondré la pelota en su cancha para educarme.

El signo # 1 de un desarrollador y gerente maduro es que pueden admitir que están equivocados. Primero demuestre a su jefe que todos ustedes están perfectamente dispuestos a admitir que están equivocados cuando lo están, y deje en claro a su jefe que espera la misma cortesía de ellos.

Si tienes un buen jefe (y dices que lo tienes), ¡esto generalmente no será un problema en absoluto! Verá que puede tener una discusión constructiva y llegar a la mejor solución para todos ustedes.

Una cosa que debe tener cuidado: asegúrese de que la mayoría de las veces tenga razones técnicas y fundadas para dudar del diseño propuesto. "Se siente mal" generalmente no es suficiente y no contribuirá a una discusión constructiva. Si esto sucede con demasiada frecuencia, su jefe no tendrá más remedio que hacer un cortocircuito en la "discusión" (que es un hecho ligero, por lo que no es realmente una discusión) y decir "lo siento chicos, pero harán lo que les sugerí hasta que puedan demostrar con hechos por qué alguna otra idea es claramente mejor ".

Es por eso que su jefe es el jefe: para tomar las decisiones que los desarrolladores pueden encontrar difíciles de tomar.

En mi opinión y cómo me comporto generalmente con mi jefe:

Siempre da tu opinión y hazlo CUANTO ANTES mientras el tema sea candente. Idealmente, cuando tiene un scrum sobre un nuevo tema o proyecto en lugar de hacerlo más tarde, cuando ha reunido su coraje y las decisiones ya se han establecido.

Debe sugerir sus opiniones, inquietudes y problemas abiertamente y asegurarse de que se presenten como sugerencias o inquietudes en lugar de imponer que debe hacerse de esa manera.

Conviértase en un hábito y conviértase en un mejor comunicador, miembro del equipo y, a su vez, en un mejor equipo. Un buen equipo hablará abiertamente sobre lo negativo y lo positivo. Un buen líder de equipo escuchará a su equipo y tomará una decisión teniendo en cuenta la información provista.

Buena suerte.

Si es tan buen arquitecto como usted describe, simplemente acérquese a él de una manera educada con razones lógicas y específicas para sus inquietudes.

Si tiene el tiempo / los recursos, intente hacer algunas pruebas de los escenarios que demuestren que tiene razón, tener algunos datos de su lado es una gran ventaja.

Una vez que hables con él, solo podrá:

a) De acuerdo con usted: ¡Problema resuelto!

b) Rechazarlos y explicar por qué: quizás después de todo, es usted quien está equivocado.

c) Rechazarlos sin razón: si él no está siendo razonable y usted está totalmente seguro, exprese su preocupación al responsable del proyecto, en este caso realmente necesita datos fríos, y si puede, el apoyo de los otros miembros del equipo. No hará al arquitecto muy feliz, pero es lo ético (imagínese que estaba diseñando un edificio y vio una falla en la estructura ...)

Mi pregunta es: cuándo y cómo (si?) Expresar las diferencias de opiniones.

Absolutamente sí es la respuesta. A menos que tenga una situación rara fuera de su control en la que incluso el potencial de turbulencia o la pérdida de su trabajo debido a él sea tan grande, debe confrontar a los demás cuando tenga opiniones diferentes.

La verdadera clave aquí es cuándo y cómo.

Primero, el "cuándo": cada entorno es diferente, pero algunos lugares tienen reuniones semanales o debates abiertos / en mesas redondas en las que plantear ciertos temas es el escenario apropiado para hacerlo. Lo principal que no desea hacer es que parezca que está menospreciando o haciendo público algún argumento de diseño personal que se encuentre entre usted y solo 1 o 2 personas más. Las personas a las que desafías no apreciarán ser desafiadas e incluso avergonzadas en público. Para estas situaciones, intente programar una reunión 1 a 1 con las personas en cuestión para detallar sus pensamientos.

2.o el 'Cómo': si vas a una persona de la tercera edad, asegúrate de tener todos tus patos en fila para respaldar tus pensamientos. No puede simplemente ir a una oficina de personas de nivel superior diciendo "¡Todos los formularios web deben ser detenidos y debemos hacer MVC!". Cuando se le preguntó "¿Por qué?" y usted dice: "Bueno, eso es lo que todos están haciendo y está en todas las revistas", no irá muy lejos. Prepárese para una discusión de ida y vuelta y para que le pregunten sobre justificar sus pensamientos sobre arquitectura, codificación, diseño, mejores prácticas, etc. Si tiene ejemplos de código de trabajo para justificar (es decir, un pequeño arnés de prueba para probar un pensamiento) Ayuda también. Lo importante aquí es no entrar en una batalla de ego o permitir que surjan las emociones.

Al final, si tiene sugerencias sólidas, justificables y lógicas, entonces deben tenerse en cuenta. Sin embargo, también esté preparado para que haya algunas personas irracionales en este mundo que no quieran escuchar a nadie más que a sí mismas. Esperemos que no te arrinconen con este tipo de personalidad.

¡Buena suerte!

No estoy seguro de cómo puede convertirse en un brillante arquitecto de software sin cometer errores y ser cuestionado sobre ellos. Creo que es seguro asumir que él ha estado en esta situación antes.

Las personas inteligentes, maduras y profesionales no pueden resistir el atractivo de mejores ideas. Incluso si está molesto al principio por haber cuestionado sus ideas, al final debería volver y ganarás respeto por ello. Si no es maduro ni profesional, tiene un problema mayor, y quizás esto lo ilumine.

Si es un arquitecto profesional, respetará y aceptará una segunda opinión. Sin embargo, en cualquier caso, debe preparar bien la alternativa basada en hechos / experiencia y también presentarla bien. También tenga en cuenta que, con respecto a la arquitectura, existen básicamente dos posibilidades diferentes para tales problemas:

1. Un enfoque / diseño puede ser simplemente correcto o incorrecto, como en matemáticas 2 + 2 = 4 y no cinco. En caso de que esté mal, debe encontrar la solución correcta lo antes posible, basándose en objeciones objetivas.
2. Con mucho, la mayoría de los temas en el diseño de sistemas son posibles enfoques que no son exclusivos. También hay otras alternativas que funcionan, las cuales elegir dependen de la experiencia, el sabor, el sesgo, la imagen general, etc. Pero también tenga en cuenta que hay períodos para discusiones y períodos para implementar, en la programación ágil estas etapas están bien definidas.