Soy un gerente. ¿Cómo puedo mejorar las relaciones laborales y la comunicación con los programadores? [cerrado]

Un poco de historia primero. Soy gerente de proyectos en una empresa mediana. Comencé como estudiante de CS y tuve un poco de exposición a la programación, pero después de unos meses supe que no era mi camino, así que me cambié a la gerencia. Esa resultó ser una buena decisión, y después de graduarme he trabajado en gestión de software en varias empresas (durante 5 años).

Recientemente, tuvimos un proyecto muy doloroso. Fue lo peor de lo peor, con muchos errores tanto de nuestro lado como del lado de los clientes y apenas lo terminó sin pérdidas. Ha llevado a muchas situaciones frustrantes, una de las cuales se intensificó hasta el punto en que uno de nuestros desarrolladores principales dejó la compañía después de una discusión vocal con nosotros (la gerencia). Esto fue una bandera roja para mí: hice algo terriblemente mal. (para que conste, el argumento fue sobre varias estimaciones de tiempo equivocadas)

Busqué respuestas en muchos lugares y un amigo me señaló este sitio. Aquí hay muchas preguntas sobre las frustraciones con la administración. Puedo entender que las malas experiencias generales conducen a una renuencia general contra "esos tipos en los trajes".

Soy ese chico del traje. Puede que no lo parezca, pero todo lo que quiero es un proyecto exitoso, y con recursos limitados toma decisiones dolorosas. Ese es mi trabajo. Una de las cosas de las que se quejó el desarrollador senior antes mencionado fue el equipo de trabajo. Francamente, no tenía idea de que las computadoras que teníamos no eran adecuadas para trabajar. Después de esto, pregunté a muchos programadores y el consenso general fue que necesitamos mejores máquinas. Lo arreglé desde entonces, pero obviamente había una gran brecha de comunicación entre los programadores y yo. Algunos de los desarrolladores más brillantes son las personas más tímidas y silenciosas. Lo sé, y nunca fue un problema durante una entrevista. Las personas son diferentes y tienen fortalezas en diferentes áreas.

El caso de las PC con poca potencia es solo una de las muchas que me llevaron a pensar que hay un problema de comunicación. ¿Cómo puedo mejorar la comunicación con los programadores sin ser intimidante y repetitivo?

Lo que espero es que la gente no se queje de cosas buenas. Si ama su lugar de trabajo y ama (o al menos le gusta :)) a su gerente, cuénteme sobre ellos. ¿Que estan haciendo bien? Del mismo modo, si lo odias, describe en detalle por qué. Estoy buscando respuestas para mejorar la comunicación porque creo que ese es mi problema, pero podría estar equivocado.

¡Guauu! Gracias por preguntar. Técnicamente, como tú, supongo que soy gerencial, ya que paso mucho más tiempo comunicando y liderando equipos que escribiendo código ... pero aquí está mi opinión desde ambos extremos del horizonte de gestión. Ya sea que sea un desarrollador o un gerente que trabaje para otro gerente, aquí hay algunas cosas que ayudan en mi comunicación con mi administración:

• ¿Por qué? es una pregunta muy importante: casi cualquier respuesta objetiva tiene un "por qué" detrás y ese "por qué" puede ser más importante que la pregunta real. Hay algunas tangentes en esto:
  • El desarrollador Por qué : los desarrolladores tendrán muchas respuestas que no tienen absolutamente ningún sentido para la administración. Ciertamente lo hice, y una de las formas en que me metí en la gerencia fue ser muy bueno para explicar los "por qué" de los equipos en términos que la gerencia pudiera entender. Si no tienes un "orador para los geeks" a mano, puedes aprender a hablar geek repitiendo sus respuestas a la pregunta de por qué en metáforas más comúnmente entendidas. Sigue así hasta que ambos entiendan y estén de acuerdo en lo que está sucediendo.
  • La gerencia por qué- Tu "por qué" es igual de importante. ¿Por qué necesitas las estimaciones de tiempo? ¿Para qué los estás usando? ¿Qué tan jodidos estaremos como empresa si son demasiado altos o demasiado bajos? Esto es algo en lo que usted, como gerente, probablemente tenga una gran comprensión, pero todo esto es vudú para el desarrollador. El truco es que el desarrollador no puede preguntar. La gerencia le ha pedido algo, y él hará lo mejor que pueda para ser preciso, oportuno y atento, pero si no sabe el "por qué", puede optimizar de la forma en que preferiría que no lo hiciera. Ofrezca su por qué y pídale que haga lo mismo: repita la respuesta en sus propios términos.

Sobre las estimaciones de tiempo específicamente: he tenido que hacer mucho, y me he beneficiado absolutamente de decirle a mi equipo de desarrollo "Necesito esto porque voy a pedir más dinero para pagar nuestros salarios, confiaré en lo que me diga y Usaré sus números ... eso significa que si me critica, todos estamos jodidos porque no podré pedir dinero por segunda vez, tenemos que vivir con lo que proponemos ". Con ese contexto, los desarrolladores cambiaron de estimaciones bajas que intentaron mostrarme cuán seguros y brillantes eran a estimaciones altas que se acercaban mucho más a las expectativas reales.

• Nadie se equivoca : la pregunta del "por qué" lleva mucho tiempo con un corolario: preguntar "por qué" en lugar de decir "¡eso es indignante! ¡De ninguna manera!" mantiene fluida la conversación. A veces hay una desconexión severa entre lo que se le pregunta a alguien y lo que pregunta el que pregunta. Mi mejor gestión ha quedado terriblemente sorprendida por mis respuestas, y cuando se sorprenden, parpadean asombrados y luego preguntan "¿por qué dices eso?". No dicen (inmediatamente): "necesitas cambiarlo". He reducido el número de propuestas para alcanzar un objetivo competitivo, pero solo después de hablar intensamente sobre cómo podríamos cambiar la escena y crear un contexto diferente para la pregunta.

• escuche el ruido ambiental, la elección de palabras y el espacio entre las palabras : aquí hay un montón de cosas que me han gustado y robado para usarlas:

  • pasar el rato en el área de trabajo, hacer algo productivo por su cuenta (no intente entrar en el trabajo de desarrollador, saben que no es un desarrollador) y simplemente escuche. ¿Cómo resuelve el equipo los problemas? ¿Cuáles son sus grandes problemas? Nunca escuchará a los verdaderos delgados en su evaluación directa de usted o de la gerencia en general, pero puede tener una muy buena idea de dónde están las áreas problemáticas. Asegúrese de hacer algo propio que sea productivo. A nadie le gusta espiar, pero a menos que la moral sea tan baja que no puedas estar cerca de ellos sin que todos evacuen, la productividad dentro de la proximidad debería ser tolerable.
  • busque opciones de palabras: a menudo son tan importantes como las palabras mismas. Cuando he usado palabras particularmente positivas o negativas, mi gerencia frecuentemente me pregunta por qué elegí esas palabras cuando es una situación con la que no están familiarizados.
  • Busque pausas, huecos y lenguaje corporal. Si hay una distancia de poder entre usted y los desarrolladores (y parece que la hay), es posible que no quieran contradecirlo ni confrontarlo. Pero el instinto básico de decir "hey, estás equivocado" generalmente se manifiesta en alguna parte.

• abra la mayor cantidad de medios de comunicación posible : prepárese para chatear en persona, por teléfono, por correo electrónico, por mensajería instantánea, cualquier cosa y todo para establecer el flujo de comunicación. Las personas son tan diversas que solo un truco no funcionará. Y veo que el trabajo del gerente es ser el comunicador multiformato, no el desarrollador.

• haga que valga la pena hablar con usted. Si alguien le cuenta sobre un problema y tal vez una posible solución, debería y probablemente acepte que usted es el gerente y, por lo tanto, puede decidir a favor de una solución diferente, o ninguna solución porque usted no Creo que vale la pena. Pero después de la tercera vez, esto sucede, especialmente si ocurre sin una explicación, aproximadamente el 99% de las personas dejarán de decirle nada.

Y aquí hay uno que es increíblemente difícil para mí, pero ha funcionado muy bien cuando puedo hacerlo: tenga en cuenta la diferencia entre introvertidos y extrovertidos . Lo más probable es que seas extrovertido, por eso tu trabajo parecía bueno y una posición de desarrollo no. Los desarrolladores son, en su mayor parte, introvertidos. "Introvertido" no significa "no se puede comunicar", pero significa que su patrón, proceso y velocidad son significativamente diferentes y la necesidad de comunicarse incesantemente es prácticamente inexistente. Planifique en el tiempo y en el espacio tranquilo (pero colocado) para que salgan los pensamientos introvertidos. Muchos de mis amigos introvertidos me dicen que solo están esperando que me "calle por unos 5 minutos" para que puedan pensar y responder. Aquí'5 cosas que los extrovertidos deben saber sobre los introvertidos y los Rands en Repose on the Nerd Cave, un ejemplo particularmente revelador de lo que es genial para los introvertidos . Rands es bastante fantástico, por cierto. Él mismo es un geek, por lo que lo hace desde un enfoque de desarrollador, que puede ser desalentador si ese no es su estilo, pero es divertido y tiene algunas ideas realmente buenas sobre el desarrollo del equipo.

Creo que las cosas # 1 que me encantaron de mis gerentes favoritos fueron:

• estaban tan profundamente comprometidos y entusiasmados con el proyecto como yo (si no más)

• Nunca tuve dudas de que me respaldaban; sabía con certeza que cuando estaban frente al siguiente nivel de autoridad, yo (o mis compañeros) nunca sería la cabra fugaz. Siempre sería un fracaso grupal, si hubiera un fracaso.

• Me dieron la propiedad de algo significativo y apropiado para mis habilidades en ese momento, pero con suficientes recursos para expandir mis habilidades y hacer el trabajo.

• Me vieron como un individuo y como parte del equipo: estaban activamente involucrados en conocer mis fortalezas y debilidades y trabajar para ayudarme a jugar con mis fortalezas y aumentar mis debilidades.

• estaban conscientes de mis objetivos personales y estaban interesados ​​en incorporarlos tanto como pudieran

• fueron sinceros cuando hacerme feliz no podía y no sería una prioridad. Hay un valor real en escuchar "Sé que odias este tipo de trabajo, pero necesito que lo hagas, así es como no será para siempre ...".

• siempre hubo tiempo en una semana (tal vez no en el instante) para explicar el panorama general

• hubo una retroalimentación y un estado casi constantes sin señalar con el dedo pero con mucho reconocimiento para el trabajo individual.

• siempre hubo la verdad. Si algo era sensible y no podía ser discutido, lo decían en blanco. Si algo era incierto, daban un nivel de confianza.

La parte fácil primero: hay una bandera roja técnica en su publicación: me estremezco ante su mención de "estimaciones erróneas": es una estimación, NO PUEDE SER ERROR , es por eso que se llama una estimación. Puede estar apagado un poco, puede estar apagado mucho, por eso se llama una estimación. Si está tomando estimaciones como gospel, ese será uno de los principales problemas que "sus" desarrolladores tienen con su estilo.

Sin embargo, estoy 100% de acuerdo con usted acerca de la dificultad de comunicarse con los desarrolladores. Tuve una revelación hace varios años, como desarrollador en una capacitación en gestión de proyectos. Vi a varios de mis colegas desarrolladores criticar absolutamente a la administración después de que se creó una atmósfera abierta de discusión (la administración estuvo presente aquí). Todo lo que estaba mal era culpa de los gerentes a los ojos de los desarrolladores. Lo sorprendente fue que la gerencia no tenía idea de casi todos los grandes problemas que surgieron ese día. Los desarrolladores suponían que todo era tan obvio que la gerencia no podía haberlo pasado por alto, y la gerencia suponía que los desarrolladores les dirían lo que necesitan.

Por lo tanto, en mi humilde opinión, la primera parte de la respuesta debe ser hacerles saber a sus desarrolladores que usted no es psíquico y que, de hecho, probablemente sea completamente estúpido cuando se trata del aspecto técnico. Estás confiando, contando y confiando en que vengan a ti de manera oportuna. Estás allí para hacerles la vida más fácil, no más difícil.

Y hagas lo que hagas, NO les hagas preguntas de las que realmente no quieres saber la respuesta, refiriéndote a las "estimaciones erróneas" anteriores ;-). Esa es la criptonita de un desarrollador.

Hay muchas cosas buenas aquí, pero creo que es necesario decir lo siguiente ... Lo siento por ser duro ... Pero hay que decirlo:

• 5 años como PM, y no saber qué tipo de PC necesita un desarrollador, es indignante.
• Hacer que un desarrollador renuncie debido a las malas condiciones de trabajo como su primera bandera roja real, es una locura.

Lo que creo que tienes es un problema de confianza , más que un problema de comunicación. Nadie dice qué está mal porque no confían en lo que harás con esa información, e incluso pueden temer que se use en su contra. El desarrollador que le contó sobre todos estos problemas lo hizo porque no hubo consecuencias al hacerlo, estaba renunciando.

Personalmente, nunca contrataría a un primer ministro que no tuviera experiencia en desarrollo en su experiencia. Creo que en tu próximo proyecto, deberías dedicar una pequeña parte de tu tiempo como parte del Dev. equipo . Digamos 8 horas a la semana, trabajando como desarrollador Jr bajo el liderazgo del equipo.

Esto realmente te abrirá los ojos a la dinámica de un equipo de desarrollo, porque en este momento, ni siquiera eres parte de ese equipo, eres un extraño. El hecho de que su desarrollador renunció le sorprendió, lo demuestra. Todos en el equipo sabían que era infeliz. Y ninguno de ellos te dijo:

"Vamos a perder a nuestro mejor chico si no haces algo"

Esa debería ser la bandera roja # 2.

Como gerente, estoy seguro de que escuchó sobre Kaizen , uno de los principios del Sistema de Producción Toyota que significa la mejora continua .

Admitiste que tienes un problema, así que es un gran comienzo.

Kaizen tiene cinco elementos principales:

• Círculos de calidad : grupos que se reúnen para discutir los niveles de calidad en relación con todos los aspectos del funcionamiento de una empresa.

• Mejora de la moral : la fortaleza de la fuerza laboral es un paso crucial para lograr la eficiencia y la productividad a largo plazo, y Kaizen lo establece como una tarea fundamental para mantener un contacto constante con la moral de los empleados.

• Trabajo en equipo : una compañía fuerte es una compañía que reúne cada paso del camino. Kaizen tiene como objetivo ayudar a los empleados y a la gerencia a verse a sí mismos como miembros de un equipo, en lugar de competidores.

• Disciplina personal : un equipo no puede tener éxito sin que cada miembro del equipo sea fuerte en sí mismo. Un compromiso de disciplina personal por parte de cada empleado asegura que el equipo se mantendrá fuerte.

• Sugerencias para mejorar : Al solicitar comentarios de cada miembro del equipo, la gerencia se asegura de que todos los problemas se analicen y se aborden antes de que se vuelvan significativos.

( Fuente )

Si observa detenidamente esto, una constante sobre esos elementos es el énfasis en el trabajo en equipo y la retroalimentación.

Un ejemplo, usted dice que tuvo una discusión sobre el tiempo estimado. ¿Eres el responsable de esas estimaciones de tiempo? ¿Hablas con el equipo sobre eso? Lo siento, pero he visto a los gerentes sacar un número de su as-. Una cosa crucial: nunca regatear con el tiempo las estimaciones que su equipo le da. Muchos gerentes imaginan que si pueden cumplir con plazos más cortos si su equipo trabaja más duro. Esto es una mentira. Nueve mujeres no pueden tener un bebé en un mes, recuerda eso.

Entonces, mi primer consejo:

Escuche : comience con un simple correo electrónico al equipo: "¿Cuál es la mejor manera para que el equipo de desarrollo brinde retroalimentación a la gerencia sobre el desempeño de la gerencia?". Iterar con el equipo e implementar el consenso. Su tarea es permitir que el equipo desarrolle un excelente software, no acumularlos. Mantén esto en mente.

Honestidad y lealtad : si nadie responde cuando preguntas algo, es porque no creen que escucharás o, lo que es peor, creen que los castigarás por eso. Entonces sé honesto. Si alguien dice que apestas, toma esto como un comentario y no te vengues. Comprender sus razones, mejorarlo.

Y, por último, aunque he visto algunas críticas al respecto aquí, me gustaría recomendarle que lea un libro llamado The Mythical Man-Month: Ensayos sobre ingeniería de software . El libro trata sobre la experiencia de Fred Brooks en IBM mientras administra el desarrollo de OS / 360. Si bien algunas cosas aquí y allá pueden estar fechadas, es el paso inicial para comprender cómo funciona el proceso de desarrollo de software complejo. S.Lott cita el Manifiesto Ágil , que no estoy particularmente interesado en él, pero también vale la pena leerlo.

Lee esto:

http://agilemanifesto.org/

• Individuos e interacciones sobre procesos y herramientas

• Software de trabajo sobre documentación completa

• Colaboración del cliente sobre negociación de contrato

• Responde al cambio sobre el siguiente plan

En muchos casos, la organización (es decir, su jefe) exige que usted

• siga un proceso claramente interrumpido hasta su conclusión lógica que conduzca a una "marcha de la muerte". Esto lleva a su vez a argumentos y renuncias.

• crear documentación excesiva, de bajo valor, sin usar.

• participar en el control de cambios complejos a / k / a negociación de contrato. Cada cambio de usuario requiere un elaborado ritual para "calidad" y "priorizar" el cambio. Realmente, se trata de la "congelación": prevenir el cambio.

• siga el plan independientemente de las consecuencias. Algunas organizaciones valoran la entrega a tiempo de software roto (o incluso inútil). Es el plan lo que se valora, no la solución de un problema comercial.

Puede ser que el problema no sean tus habilidades de comunicación personal.

Puede ser que todo el "entorno" o "metodología" de desarrollo se rompa fatalmente, y los malos sentimientos son solo un síntoma de malas prácticas generales.

Para mí, esto suena como si nunca hubieras hablado con los desarrolladores en una atmósfera fácil. ¿Sus conversaciones con ellos fueron meramente de naturaleza oficial? Eso es muy malo.

¿Por qué no los conoce personalmente y así conoce lo que es bueno y lo que es malo de la empresa, su lugar de trabajo y sus proyectos? Respételos y gane su respeto, mostrando sincero interés y aprecio por su trabajo.

Si confían en ti y no necesitan temer ser ofertas de peones, lo más probable es que incluso te digan verdades poco atractivas.

Soy líder de equipo y mi equipo confía en mí. Yo los protejo. Asumo toda la culpa y comparto la fama con ellos. Nuestra gerencia me protege. Eso aumenta la moral. Tuvimos un proyecto realmente difícil y un cliente casi malo, casi imposible de terminar, pero finalmente lo hicimos, porque hablamos de todo de una manera franca y abierta.

¡Aplaudir! ¡Aplaudir! ¡Aplaudir! Sin duda, debe ser una buena persona, ya que ha salido a la luz para ver qué se puede hacer para mejorar en su trabajo.

A continuación, encuentre lo que he presenciado en un gran gerente y lo he adoptado personalmente cuando lidero el equipo como miembro principal.

• M entor más de manejar.
• Unos miembros del equipo de Llow para expresar sus pensamientos y preocupaciones. Sé todo oídos. Toma los constructivos.
• N jamás traiciona los miembros del equipo por jugar a la política de división. Esto es contraproducente antes y en silencio.
• Un negro no. Nunca tenga muecas en su cara cuando esté con su equipo, pase lo que pase. Este es realmente difícil.
• G aprecian abierta y abiertamente al ganador por su buen trabajo. En la misma amplitud, critica muy suave y tácticamente el trabajo, no a la persona por cualquier error, a la persona responsable, aislada y no abiertamente.
• E propiedad omentar y el liderazgo en cada individuo. Esto aumenta la moral y el compromiso de la persona, porque se sentiría respetado.
• R OAM alrededor con su equipo de vez en cuando. Éste induce / aumenta el vínculo dentro de los miembros del equipo.

Te deseo buena suerte en tu sincero esfuerzo :)

En general, los muchachos en las trincheras comienzan a sentirse amotinados cuando sienten que sus quejas no son escuchadas por personas que pueden y solucionarán las situaciones. Cuando ni siquiera sienten que pueden quejarse sin arriesgar su posición en la empresa, eso es aún peor.

Soy un tipo un poco teórico, y la mayoría de los "trabajadores del conocimiento" tienden a serlo; Si tenemos una oportunidad, nos gusta nuestro trabajo y queremos hacerlo bien. Sin embargo, la desventaja de un lugar de trabajo de Theory-Y es que puede no ser inmediatamente aparente que haya un problema, porque las personas, que desean hacerlo bien y, por lo tanto, no quieren hacer olas, encontrarán formas de evitar ese problema o simplemente lo ignorarán. Esto lleva a una frustración acumulada, que finalmente explota en la cara de todo el equipo. Una tienda dirigida por un gerente de Theory-X probablemente tendría muchachos que se quejan mucho antes; los empleados solo lo hacen por el dinero, por lo que si el trabajo apesta más de lo habitual, se quejarán.

En cuanto a lo que puede hacer, en un entorno con personas mayores y líderes en la sala haciendo el trabajo, son su mejor activo. Háblales. Puede programar 30 minutos a la semana para "dos vías", donde los clientes potenciales le brindan actualizaciones y expresan inquietudes sobre el día a día del proyecto, y usted les brinda actualizaciones en el lado comercial y planifica con ellos para resolver inquietudes antes de que se conviertan en problemas que afecten seriamente al equipo.

En Agile, al final de cada "sprint" o "iteración" (que es una unidad de trabajo de desarrollo que suele durar entre una y tres semanas), todo el equipo, desde los miembros más jóvenes hasta el primer ministro, tiene una "retrospectiva ". Miran hacia atrás a lo que hicieron, lo que salió bien, lo que no, e identificaron cosas para seguir haciendo y cosas para cambiar. Hay varios formatos, y puedes inventar el tuyo, pero el resultado del retro debería ser que la gente sienta que se escuchó su voz y que las cosas cambiarán como resultado.

Hablando de ágil; mi primer trabajo fue para una pequeña empresa, y por "pequeña" quiero decir que toda la empresa no podía formar un equipo de softbol. Había cuatro programadores cuando comencé, y eso disminuyó a dos antes de irme. El fundador, presidente, director ejecutivo y el 95% de las partes interesadas de la empresa lo dictaminaron con puño de hierro, y él fue la única fuente de planificación en la organización, lo que significa que no había mucho. El jefe era un adicto al trabajo y esperaba que todos los demás también lo fueran; Todo lo que tenía que dar no era más o menos de lo que esperaba, y por esto pagaba un salario básico a las personas que habían trabajado para él durante una década.

Dejé esa compañía y comencé a trabajar para otra empresa que hacía las cosas MUY diferente; Practicaron la metodología básica SCRUM Agile, con standups diarios, programación de parejas, equipos de sprint y retrospectivas. Durante un día cada dos semanas al comienzo de cada sprint, no hicimos nada más que planificar las próximas dos semanas de trabajo. Por una gran parte de otro día, no hicimos nada más que mirar hacia atrás en lo que habíamos hecho y encontrar formas de mejorar como equipo. Había desarrolladores sentados a mi lado que eran MVP de Microsoft, haciendo el trabajo y alentando y complementando lo que estaba haciendo.

Noche. Y. Día. ¿La principal diferencia? Primero, no sentí que se esperaba que me matara por el proyecto; Un principio fundamental de Agile es el ritmo sostenible de desarrollo. En segundo lugar, tenía voz para decidir cómo se esperaría que hiciera mi trabajo. Tenía que hacer el trabajo, pero si tenía "ardor de estómago" sobre lo que se esperaba que hiciera en el próximo sprint, podría expresar esa opinión y sería escuchada y dada peso. Si sintiera que había una mejor manera, podría decirlo y sería entretenido.

En cuanto a encontrar soluciones y resolver problemas, debe tener cuidado de no parecer que está trabajando de arriba hacia abajo. Para computadoras; digamos que su RMR (ingreso mensual recurrente) solo le permite a la compañía actualizar cuatro computadoras cada dos semanas. Las primeras cuatro computadoras no deberían ir todas a los clientes potenciales y personas mayores; deberían ir a las personas con las computadoras más lentas. Si le das bonos al equipo, no solo los des a "nuestros valiosos mayores y líderes, sin los cuales esto no hubiera sido posible"; TODOS en su equipo de desarrollo lo hicieron posible. Si un menor tiene una queja, escúchelo; solo porque es un joven no significa que no sepa nada.

Mejorando las relaciones: ¿
Acabo de tener un proyecto difícil? Dales un descanso después. Tiempo de vacaciones para relajarse y recuperar el aliento.
Declaración de derechos de los codificadores Estas cosas son un hecho. Cosas básicas que deberían ir sin decirlo. Si viola estos, está abusando de sus teclas de código.
La prueba de Joel estoy de acuerdo con la mayoría de ellos. Pero algunos realmente dependen. Si te falta algo, probablemente estés haciendo la vida más difícil para tus programadores de lo que debe ser.
Deuda técnica . Por lo tanto, puede presionar para que se complete, pero debe darse cuenta de que al cortar esquinas incurrirá en una deuda técnica que tomará más tiempo en una fecha posterior para solucionarlo. Si esa fecha aparece ANTES del final del proyecto, realmente la has jodido.
Animado RSA: MotivaciónEsta es una parte fantástica que realmente muestra cómo motivar a los trabajadores del conocimiento.
Día libre para codificar lo que quieren. Del video de RSA. No recuerdo el nombre, pero la compañía que menciona tiene una breve explicación en su sitio. Me parece una buena idea. En la mayoría de las tiendas hay cosas que todos saben que están rotas, pero nadie tiene tiempo para arreglarlas, y no es una alta prioridad. Esto les permite abordar la deuda técnica. También les permite mostrar sus brillantes ideas.

Y por el amor de Dios, trate de mantener una semana laboral de 40 horas. Además, horario flexible. Flextime puede compensar todo un mundo de mierda. Al menos para mí.

Mejorar la comunicación entre programadores y jefes
Eso es más difícil para mí. Todo ese asunto es más un conjunto de habilidades de jefe que el enfoque de un programador. Podría decir que algunas cosas básicas, como las estimaciones de tiempo, son solo estimaciones. Caminar sobre el agua y cumplir con los requisitos es fácil si están congelados. Tal vez pidiendo a los programadores tímidos que hagan una presentación sobre su proyecto en una revisión de código o algo así. La práctica hace la perfección, ¿verdad? Pero me inclinaría ante los consejos de los demás sobre este.

"Del mismo modo, si lo odias, describe en detalle por qué".
Bueno, eso abrirá las compuertas aquí. Y si no estuviera usando un openID que obviamente podría estar vinculado a mí, probablemente también me desahogaría. Si realmente desea una lista gigante de lo que no debe hacer, pregunte en un foro que sea más amigable para la publicación anónima.

Siempre he descubierto que las personas en general no lo tratarán mejor de lo que lo hace (aunque pueden tratarlo peor). Yo personalmente (soy un desarrollador) respondo a la honestidad con honestidad, al respeto con respeto, a la confianza con la confianza, etc. Debería tener una conversación informal con su equipo en una atmósfera neutral y decirles lo que nos acaba de decir. El punto que se olvida en los ambientes tóxicos "nosotros contra ellos" es que todo debería ser "nosotros". Tanto la gerencia como los trabajadores necesitan saber eso, y la empresa debe respaldar eso.

Buena suerte.

Ahora tiene un historial comprobado de no solo aceptar comentarios, sino también actuar en consecuencia. Usted ha demostrado que tiene influencia en los altos responsables de la toma de decisiones y puede hacer las cosas por su equipo. Eso hace una gran diferencia. Los programadores pueden ser más introvertidos, pero nos gusta hablar de programación. Un ambiente informal es agradable, pero todos deben ser profesionales. Permita que las personas den rienda suelta a algunos, pero asegúrese de que las discusiones sean productivas y no solo una sesión de perras.

Según mi experiencia, el factor más significativo para que me guste o no me guste mi gerente es si él / ella entiende el desarrollo en general y comprende el trabajo que estoy haciendo. Algunos resultados positivos se enumeran aquí:

• No tengo que perder mucho tiempo para justificar por qué un cambio tomaría tanto tiempo o no se puede implementar. Bueno, técnicamente, cualquier cambio puede implementarse y la alta gerencia generalmente exige la implementación de cualquier manera. Pero al menos en tal situación, su gerente directo está de su lado, pidiéndole más tiempo (en lugar de presionarlo o quemarlo).
• Sé que tengo una mejor oportunidad de recibir soporte en caso de una mala situación (un truco de WTF, un problema de producción, etc.). Por lo general, una persona no técnica tiende a culpar al desarrollador por tal situación, mientras que un buen gerente ENTIENDE lo que realmente está sucediendo y apoya a su desarrollador (no solo sabe o está dispuesto a tomarlo de esa manera por ser amable).
• Sé que mi trabajo y desempeño deben ser evaluados por una persona adecuada.

En mi opinión, si ya no realiza la programación y, por lo general, dentro de un cronograma o presupuesto de proyecto ajustado, la posibilidad de que a sus desarrolladores les guste es muy baja. Si ese es el caso, es mejor que suba rápidamente y tenga a alguien más para que sea el gerente directo. Lo siento, sonaba mal en este párrafo, pero así es como lo veo. Tu parece ser una buena persona y merece algo de verdad.

También soy uno de los tipos con traje, y lo he sido por más de 15 años. Era un desarrollador de software cuando comencé, y todavía escribo código cuando tengo la oportunidad. Así que creo que puedo hablar por ambos lados y tengo un poco de experiencia en estas situaciones. También tengo credenciales, como "Empleado del año", elegido por el personal, que me dan confianza para manejar estas situaciones.

De lo que soy testigo con mucha frecuencia es de que existen diferencias sustanciales en los sistemas de valores y los métodos / enfoques operativos adoptados entre la administración y los desarrolladores.

Para muchos desarrolladores, la sinceridad, la honestidad y un entorno de trabajo flexible son muy importantes en la lista. Lamentablemente, los mismos valores no son muy altos en la lista de la alta dirección. Y esto conduce inevitablemente a grandes enfrentamientos, especialmente si la gerencia media (usted y yo) decidimos tomar completamente el lado de la alta gerencia. La única forma de salir de esto (desde mi punto de vista) es adoptar una posición firme frente a su equipo, respaldarlos por completo y construir una relación de confianza a través de una comunicación abierta y, lo más importante, haciendo lo que está diciendo. (que a menudo es lo contrario de lo que obtienes de la alta gerencia, donde la política domina por completo la sinceridad).

Al mismo tiempo, usted mismo necesita mantenerse operativo, por lo que debe encontrar una manera de comunicarse con la alta gerencia en un idioma que entiendan y jueguen. Ese es el verdadero desafío de la gerencia media.

Creo que con la felicidad del desarrollador, la productividad se reduce a las pequeñas cosas. Las matemáticas funcionan bastante bien para la administración. Dame una dona (-25 centavos) por la mañana y trabajaré el doble todo el día (+ muchos dólares). No es que saboteemos las cosas trabajando lentamente cuando no estamos satisfechos, es que estamos trabajando en sistemas extremadamente complicados y es extremadamente difícil enfocarnos cuando estamos frustrados por algo. Probablemente sea mejor que no codifiquemos tanto cuando estamos enojados.

Las estimaciones, sin embargo, deben ser abordadas por ellos mismos. Todos los problemas que tengo se pueden resolver entregándome una dona, con la excepción de las estimaciones poco realistas . Verdadero o falso, así es como lo ve un desarrollador: la administración tiene todo para ganar (como un barco nuevo) en una estimación más corta, mientras que los desarrolladores tienen todo para perder (como un mes de sueño). Sin embargo, la gerencia está a cargo, por lo que siempre ganan la guerra de estimaciones. Creo que el sistema de estimación funciona mejor cuando los desarrolladores deciden la fecha límite (es bastante difícil para nosotros dar una estimación precisa, entonces, ¿cómo lo haría un gerente?), Pero la administración los motiva positivamente a ser ambiciosos, con el entendimiento de que ningún desarrollador es engañado. estar un poco fuera de lugar.

Considere qué tipo de reacción le da a un programador que pueda tener una pregunta, comentario o inquietud. ¿Hay un "¿Qué quieres ahora ?" o "¿Por qué me molestas con esto ?" tipo de respuesta? ¿Qué tan bien estás animando a los desarrolladores a expresar sus preocupaciones y comentarios? Sin embargo, ese es simplemente un punto de partida.

En segundo lugar, tenga cuidado de dónde está tratando de tener estas discusiones. Dudo que sea muy abierto hablando de mi máquina de trabajo con alguien en el próximo cubo si supiera que mi gerente estaba al alcance de todo. Si desea que las personas den su opinión abierta y honesta, debe darse cierta privacidad para saber que sus respuestas no se transmitirán públicamente ni se utilizarán en su contra.

Tercero, considere qué tipo de habilidades de Inteligencia Emocional tiene. Inteligencia emocional para gerentes de proyectos: las habilidades de las personas que necesita para lograr resultados sobresalientes por Anthony Mersino sería una recomendación de libro que recibí ayer de un almuerzo y aprender sobre EQ. Si realmente desea profundizar en la psicología, aquí hay varias herramientas de perfil de personalidad que podrían usarse, por ejemplo, Eneagrama, estilos sociales y MBTI.

Por último, considere cuál es la cultura en su empresa. ¿Son los errores algo barrido debajo de la alfombra? ¿Son las quejas un gran no-no que podría meter a alguien en problemas con mucha facilidad? ¿Qué comportamientos son recompensados ​​o alentados y cuáles son tolerados y aceptados? Si bien parte de esto es observación, parte de esto también puede requerir algunas conversaciones que deben mantenerse fuera de la oficina o en una habitación donde no es probable que haya escuchas. Es probable que sea repetitivo al tratar de usar esto al principio. Eso no es malo si está tratando de establecer una nueva práctica y hacer que las personas se unan para hablar si la cultura era principalmente una en la que todos sabían "asimilarla". Esto puede ser más sensible que otras respuestas, pero esto sería lo que yo '

¿Los desarrolladores sienten que eres su defensor? ¿Con eso quiero decir que saben que son libres de compartir con ustedes sus preocupaciones / frustraciones sin ser golpeados? ¿Sienten que luchas por ellos? ¿Sienten que aprecias su trabajo? ¿Sienten que realmente quieres que tengan éxito en su carrera?

Si se sienten apreciados, probablemente tendrá una mejor comunicación.

Como desarrollador, soy un gran nerd y carece de habilidades sociales y no me disculpo por eso. Después de todo, soy el talento, y me has contratado por mi talento. Si necesitaras mariposas sociales para hacer el trabajo, tendrías una habitación llena de gerentes de proyecto en lugar de desarrolladores.

Sé que algunos desarrolladores son muy astutos socialmente, pero creo que la mediana se inclina hacia el nerd introvertido.

Cuando alguien me pide que haga algo, no hago absolutamente ninguna inferencia y hago EXACTAMENTE lo que se solicita. Parece que con algunos gerentes de proyecto siempre termino con problemas porque esperan que haga inferencias sobre su proyecto, lo que no haré, por lo que a veces las cosas no salen como esperan, aunque resultan ser exactamente lo que Han solicitado. Creo que la razón por la que esto sucede con algunos gerentes de proyecto es porque no ofrecen HLD de alta calidad, BRD y otorgan demasiado valor al aspecto social de la gestión de proyectos en lugar de lo que está en blanco y negro.

Creo que aquí es donde chocan los mundos. Creo que en el mundo de la gestión de proyectos, las habilidades sociales y la calidad de la franqueza personal son factores importantes, pero para los desarrolladores como yo no significa absolutamente nada. No me impresiona hablar sobre lo importante que es esta o aquella tarea. Ni siquiera quiero salir a almorzar o tomar cervezas como han sugerido algunas personas aquí.

Lo que realmente quiero son buenos, HLD y BRD de alta calidad. Quiero horarios y plazos que sean alcanzables, y si se introducen nuevos diseños o planes, quiero que el horario y los plazos se reajusten. He trabajado en proyectos en los que los requisitos parecen cambiar sobre la marcha; para mí esta es mi señal de alerta de que estoy lidiando con un liderazgo de proyecto de baja calidad. Como desarrollador, lo peor que puede hacer es traerme nuevos requisitos de proyectos a diario, especialmente después de que ya tenemos un cronograma o hemos hecho compromisos de cronograma. Es intolerable cuando se introducen nuevos requisitos, sin compensación de los plazos. Trabajando más horas, trabajando hasta tarde, no tengo ningún problema con eso, pero no es algo que siempre sea cuantitativo con el desarrollo. Algunos cambios pueden tomar algunas horas adicionales, algunos cambios pueden llevar semanas para una adecuada I + D, pruebas, control de calidad, etc. No siempre es como hornear un pastel, a veces un solo cambio en los requisitos puede ser como cambiar toda la receta. He sido testigo de cómo los gerentes de proyectos se derriten y hacen berrinches en las llamadas de conferencia porque sus plazos no permitirán el desarrollo adicional, sin embargo, están pidiendo un desarrollo que no estaba en sus requisitos iniciales del proyecto.

Solo puedo dar mi propio sesgo personal y experiencia como ejemplo, así que por favor no infiera que estoy hablando en nombre de todos los desarrolladores. Solo veo estas cosas a través del microcosmos de mi propia carrera, pero esta publicación describe las condiciones exactas que me llevaron a tirar la toalla proverbial.

¿Con qué frecuencia estás hablando con tus desarrolladores? No me refiero a reuniones de estado del proyecto, preguntas sobre entregables u otros temas que les traes: con qué frecuencia te sientas con uno de tus programadores, les preguntas cómo van las cosas y simplemente escuchas .

Muchas de las otras respuestas son realmente buenas: debe considerar el desarrollo ágil. Necesita que sus desarrolladores aprendan y crezcan en sus roles. Pero si en realidad no estás escuchando lo que dicen tus desarrolladores (¡o no lo están diciendo!), Primero debes ocuparte de eso.

Buena referencia sobre uno a uno: http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

Corto y dulce. Excel en lo que haces: esto generará comunicación.

¿Qué significa sobresalir para sus desarrolladores? .. Leer, releer, sí, incluso estudiar PeopleWare

¡Todas las grandes ideas y comentarios en las publicaciones anteriores!

He aquí una idea: envíe a su personal de TI a talleres de comunicación en su colegio comunitario local, pagado por la compañía, por supuesto.

Asegúrese de que a) los talleres tengan buena reputación yb) no envíen a sus empleados juntos. Tienden a mantenerse unidos y no se mezclan con los otros miembros de la clase, no solo reducen el valor de los talleres, sino que causan molestias a los demás.

La comunicación orientada al equipo productivo es una habilidad que cualquiera puede aprender, pero es un tema que siento que falta en la mayoría de los caminos escolares.

Esta idea no es de ninguna manera una bala mágica, pero es una buena pieza fundamental del rompecabezas. Sus asociados no solo aprenderán a comunicarse mejor entre sí, sino que también tendrán la ventaja de que comenzarán a comprender y respetar SU trabajo mejor (la comunicación es el núcleo de PM).

Solo mis 2 bits :)

Solo para responder a una recomendación que ya ha aparecido en algunas respuestas . Michael Lopp (también conocido como rands ) ha estado escribiendo sobre la gestión de desarrolladores y "meterse en sus cabezas" en su blog, Rands in Repose , y en un libro, Managing Humans ( fuentes de libros ). El libro contiene principalmente contenido editado de sus publicaciones anteriores a 2007, y proporciona una buena manera de ponerse al día con las partes relacionadas con la administración de su blog (también habla sobre, por ejemplo, los juegos de azar, y si desea leer eso es otro asunto). Su escritura es generalmente genial y a menudo humorística, por lo que hay poco riesgo al leerlo.

Lleva al equipo a tomar cerveza (y estás comprando).

Llego tarde a la fiesta, pero acabo de ver esta pregunta.

Una cosa que no veo muy bien abordada es esta:

Los gruñidos nunca dicen toda la verdad a los trajes. Rands dice esto en el ADN pero no lo aborda de frente, él está en un tema diferente.

Lleva puesto un traje y firma los cheques. Usted representa el interés de la empresa. No estás representando a los ingenieros. Si es así, no estaría firmando sus cheques, que habían firmará la suya.

Por supuesto, esto no es una novedad para usted o los ingenieros. Pero cuando un ingeniero sabe que plantear ciertos problemas (problemas) con su lugar de trabajo causaría un conflicto significativo, la compensación de riesgo / recompensa no favorece al ingeniero. A los ingenieros se les paga para producir productos, no para iniciar luchas culturales en el lugar de trabajo. Involucrarse en ellos es una vía rápida para hacer el trabajo mal.

Por lo tanto, parte de la tarea de gestión es proporcionar una forma para que los ingenieros sean abiertos sobre los problemas, sin incurrir en políticas corporativas y reacciones negativas en su carrera. Es bueno tener aumentos, después de todo, y no son otras empresas, si éste no se siente agradable.

Me sorprende que nadie haya mencionado este gran libro que trata exactamente su pregunta y tema: "Peopleware: Proyectos y equipos productivos" de DeMarco y Lister . Del editorial: los principales problemas del desarrollo de software son humanos, no técnicos . Las primeras tres reseñas en Amazon serían fácilmente suficientes para convencerme de comprar este libro si estuviera en su situación.

Muchas de las respuestas aquí tienen muy buenos puntos, pero me gustaría agregar un par de recursos que podrían ayudar. He estado en algunas situaciones que se derrumbaron en un desastre gigante o se resolvieron de manera muy eficiente debido a la comunicación entre las personas involucradas. Tres libros me han ayudado personalmente a mejorar mis habilidades de comunicación, especialmente en situaciones de alto estrés donde hay mucho en juego:

• Conversaciones difíciles: cómo discutir lo que más importa
• Conversaciones cruciales: herramientas para hablar cuando hay mucho en juego
• Enfrentamientos cruciales: herramientas para resolver promesas incumplidas, expectativas violadas y mal comportamiento

Al leer su pregunta, creo que ve el valor de la comunicación. Personalmente, creo que la comunicación es más importante para un gerente o líder que las habilidades comerciales o técnicas. Las personas que lideras deben tener las habilidades que necesitas para completar la mayoría del proyecto. Un buen líder técnico o gerente de proyecto debe poder centrarse en la comunicación, ya sea dentro del equipo o entre el equipo y el cliente o el equipo y la entidad comercial (o incluso una combinación de esos tres).

Lea un par de grandes novelas que dan una idea de las perspectivas de la fuerza laboral técnica:

• Hackers, Steven Levy - http://en.wikipedia.org/wiki/Steven_Levy
• Microserfs, Douglas Coupland - http://en.wikipedia.org/wiki/Douglas_Coupland
• Catedral y el Bazar, Eric Raymond - http://en.wikipedia.org/wiki/Cathedral_and_the_Bazaar

Estos son tan importantes como cualquier memoria típica sobre gestión (Drucker et al).

He desempeñado varios roles durante muchos años: desarrollador, desarrollador senior, líder técnico, etc.

A partir de su pregunta, es bastante obvio que sus desarrolladores no le dicen cosas porque no creen que pueda ayudar.

Esto puede deberse a 2 razones.

1. No creen que tengas el poder de arreglar las cosas. Sin embargo, creo que esto es poco probable porque entonces probablemente lo sabrías y también los desarrolladores te lo habrían lamentado.
2. Usted es el tipo de persona que cuando un desarrollador se acerca a usted con un problema, hace una o más de las siguientes cosas
   • Cuando se acercan a usted con problemas, usted les dice: me gustan las soluciones, no los problemas.
   • Los escuchas amablemente y luego les das la tarea de solucionar el problema. Les das una charla sobre el honor que es para ellos tener la responsabilidad de solucionar el problema. Con el tiempo, sus muchachos entienden que cuando acuden a usted con un problema, terminarán con un trabajo extra, por lo que no llegarán con problemas.
   • Niegas que sea un problema. Usted da razones convincentes para esto. Pero a medida que esto sigue sucediendo, con el tiempo sus muchachos aprenden que no tiene sentido acercarse a usted con un problema.
   • Dices "Sí, entiendo". Dices que este tipo de cosas ocurren ocasionalmente y no hay nada que uno pueda hacer. Si este es un patrón, nuevamente sus muchachos lo entienden.

Si es cualquiera o todo lo anterior, entonces debe rectificarlo.

Lo que más odio es que las personas se interpongan entre mí, el desarrollador y el usuario final. Los mejores gerentes me permiten hacer esto y cambiar nuestra solución para que coincida con lo que creo que el usuario quiere o podría hacer.

La peor práctica para mí es a menudo disfrazarse de "bueno", por lo general, el gerente se tiene a sí mismo, o un BA o alguien escribe especificaciones que los desarrolladores tienen que interpretar e implementar, con plazos acordados de antemano.

Si es una solución personalizada, a menudo incluso los desarrolladores no sabrán cuánto tiempo llevará y, por lo general, el cliente no tiene idea de qué es lo mejor para ellos. Es por eso que el desarrollo iterativo es genial. Sin embargo, no es la forma en que se hacen la mayoría de los acuerdos, por lo que un buen gerente luchará para trabajar como se indicó anteriormente.

Finalmente, algunos desarrolladores no son buenos en comunicación y no pueden relacionarse con los clientes. Quizás sean los más adecuados para problemas con requisitos claros, especialmente requisitos técnicos claros. Tal vez necesite desarrolladores que sean mejores comunicadores y quieran trabajar para resolver problemas de negocios, no solo problemas técnicos.

Es muy fácil mantener contento al equipo

Intente escucharlos muchas veces, su pregunta también tiene respuestas. Yo recomendaría a los miembros del equipo que vengan con problemas y la solución probable.

La salida del equipo es una buena idea (podría ser un plan de juego)

si su proyecto requiere algo de trabajo nocturno y de fin de semana y cree que en realidad no agrega mucho valor al equipo, sería una buena idea pasar algo de tiempo para comer y apreciar al equipo sobre sus esfuerzos y, si es posible organizar algún PTO para ellos

haga un bimestral 1: 1 con cada miembro del equipo para asegurarse de que se sientan cómodos.

Por último, pero no menos importante, puede ser una buena idea que comprenda el proyecto funcionalmente y también algo técnico.

Avísame si tienes más preguntas

También soy (francés, así que perdona mi inglés) gerente de software que tiene experiencia en ingeniería científica pero no específicamente experiencia en software de TI originalmente. Por lo tanto, no tengo una afinidad especial con la codificación al principio, pero he sido un ingeniero de calidad estadística de la escuela de Deming, que tiene una enseñanza muy diferente a todas las escuelas "modernas" que siguieron aunque pretenden heredar de Deming. Lo peor es 6 sigma, lean fue mejor, pero desafortunadamente lo que sucedió es este http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

“Originalmente, Six Sigma fue derivado de Toyota Quality Management (TQM) por Motorola para lograr seis niveles de calidad sigma, y ​​luego a través de Allied Signal y GE se transformó en proyectos de Black Belts basados ​​en estadísticas para convertirse en un programa de reducción de costos, cada proyecto necesita un claro ROI. En otras palabras, denigramos el programa desde una filosofía de liderazgo hasta un conjunto de proyectos únicos para reducir costos. Fue una completa bastardización del original, y rara vez condujo a un cambio duradero y sostenible porque faltaban el liderazgo y la cultura.

“Algo similar sucedió con la inclinación cuando se redujo a un kit de herramientas (por ejemplo, mapeo de flujo de valor, tableros de KPI, celdas, kanban).

"Lean y Six Sigma de ninguna manera reflejan el pensamiento original de excelentes compañías japonesas o sus maestros como Deming".

Hoy el movimiento ágil es como magra (ver el curso de Jeff Sutherland y su homenaje a Deming http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -century-of-scrum / ), es mejor que Waterfall, pero todavía está muy lejos de la enseñanza original de Deming porque en lugar de leer a Deming en su texto original, los gurús simplemente lo reenvasan aproximadamente sin citar sus 14 principios de gestión, y vende herramientas y seminarios que tienen poco valor por sí mismos.

Ahora, cuando se trata del campo del software, los problemas son que hay personas que, por un lado, conocen los principios generales pero no tienen ideas reales sobre cómo aplicarlos realmente y, por otro lado, personas que escriben softwares pero ignoran los principios porque simplemente escuchan falsos gurús que les vendieron herramientas sin decirles los principios reales y, de hecho, deberían construir sus propias herramientas de gestión.

Entonces, para mí, el gerente de proyectos de software debería hacer un esfuerzo por profundizar en la operatividad diaria de la codificación de software, no solo haciendo la planificación en Microsoft Project (o el gráfico de análisis con Agile) o una buena presentación en Powerpoint para la alta gerencia, sino también tener algunos valores El equipo de desarrolladores. Cuando el equipo desarrollador tiene problemas, incluso si se trata de problemas técnicos, el gerente del proyecto puede ayudar a orientar el diagnóstico con un ojo externo. Puede mirar el código, incluso si no comprende los pequeños detalles, puede hacer algunas preguntas ingenuas que pueden hacer que los desarrolladores se den cuenta de que no pensaron en esa pista (tengo numerosos ejemplos personales, pero es demasiado largo, así que lo haré más bien escribir un artículo en mi blog).

Otra cosa es que trato de tener una conciencia general de la evolución en el campo, como nuevos marcos, nuevos paradigmas de arquitectura leyendo artículos técnicos. Participaré en algunas pruebas de integración, escribiré algunas documentaciones yo mismo (cosas que los programadores odian, así que hago por ellos, por supuesto, me alimentarían con el núcleo), cualquier cosa que pueda hacer prácticamente para ayudar al equipo.

En general, los desarrolladores sienten que están haciendo el trabajo duro, y es cierto, a menudo les digo que estoy haciendo la parte fácil al mantenerme en la abstracción, sin embargo, trato de ayudar concretamente cuando es necesario, porque la microgestión tampoco es bueno ya que puede generar sentimientos de interferencia.

Como conclusión: elimine los eslóganes con los desarrolladores (de hecho, es uno de los 14 principios de Deming), muéstreles que le importa el software concreto del proyecto, no los documentos o su reunión solo con la alta gerencia.