Para aquellos que no están familiarizados con el desarrollo de software, puede parecer extraño que un proyecto tenga tanto un gerente de
producto como un gerente de
proyecto . La diferencia es que el primero es responsable de determinar el producto y el segundo es responsable del estado del proyecto y de informar a las partes interesadas si la fecha de entrega está en riesgo.
Los gerentes de proyecto tienden a esforzarse por garantizar la previsibilidad de los plazos mediante la estandarización y los procesos cíclicos. Estos procesos se centran en los informes de estado para rastrear el progreso. En general, se acepta que cuanto más supervise los procesos, más predecible será el cronograma del proyecto y mayor será la probabilidad de que el proyecto se entregue a tiempo.
La maldición del gerente del proyecto es la calidad de las estimaciones para el tiempo que reciben del equipo. Estas estimaciones pueden variar enormemente. Por lo general, varían de persona a persona, y es posible que se requieran actualizaciones diarias. Tal giro en las estimaciones puede hacer que sea imposible determinar el momento del proyecto, pero se espera una fecha firme del gerente. Cuando finalmente se pierden estos plazos, el gerente debe encontrar una manera de explicar por qué se pierden los plazos, sin hacer que los últimos empleados sean directamente responsables de dicho plazo. La diplomacia inadecuada en esta área a menudo lleva al personal a acusar al gerente del proyecto de "arrojarlos debajo del tren", independientemente de la precisión de sus evaluaciones anteriores.
Las siguientes son personalidades problemáticas entre los gerentes de proyecto:
Planificador de reuniones
El gerente del proyecto, que cree que todos los problemas del proyecto son causados por la falta de comunicación y coordinación, y una gran cantidad de reuniones será la solución.
- Puede mutar a estadísticas
- Peligroso en combinación con el gerente de producto como autor de patentes
- Probabilidad de corrección: alta
- Peligro para el proyecto: bajo
El problema
En teoría, las personas se reúnen en reuniones para discutir opciones y tomar decisiones. De hecho, esto rara vez sucede. El planificador de reuniones no es consciente de este fenómeno e intenta programar reuniones con la mayor frecuencia posible, con la mayor cantidad de personas posible. Él cree sinceramente que esto mejorará la colaboración en el equipo: la idea de que la comunicación no es suficiente para el éxito del proyecto se ha fortalecido firmemente en su mente.
Este tipo de gerente exacerba tres problemas principales inherentes a la gran mayoría de las reuniones:
- Como regla general, la selección de los participantes se lleva a cabo de manera deficiente, por lo que algunos escuchan información que no les interesa y expresan una opinión sobre temas que no les conciernen.
- La organización de las reuniones también suele llevarse a cabo de manera deficiente, lo que a menudo conduce a debates caóticos que no son relevantes para el propósito de la reunión, lo que a su vez no lleva a conclusiones prácticas.
- Los proyectos se completan no en reuniones, sino en lugares de trabajo. Si lleva a los empleados a las reuniones en lugar de trabajar, pasan un tiempo valioso.
Solución
Un planificador de reuniones no representa una amenaza grave para un proyecto porque los empleados generalmente no asisten a reuniones que perjudican su productividad. Por lo tanto, el trabajo continúa a pesar de las reuniones en curso.
Este administrador de proyectos se puede solucionar con una simple instrucción:
- Clasifique todos los tipos de reuniones que generalmente convocan: informes de estado, revisiones de proyectos, programación, etc.
- Determine qué resultados (si los hay) de estas reuniones se pueden lograr por otros medios, por ejemplo, por correo electrónico, herramientas de seguimiento, conversaciones informales.
- Para las reuniones obligatorias, determine con qué frecuencia deben celebrarse y quién debe estar presente.
- Programe reuniones en bloques para evitar múltiples distracciones debido al cambio de contexto.
- Deje algunos días de la semana libres de reuniones.
- Exento de la asamblea unas semanas en su conjunto (será amado por ello).
- Programe cada reunión al menos con una semana de anticipación con una agenda publicada y cualquier material que deba considerarse antes de la reunión.
- Al comienzo de la reunión, revise la agenda, los objetivos de la reunión y ayude a alcanzar esos objetivos.
- Finalice la reunión de inmediato: no continúe si se logra el objetivo original.
Se necesitan reuniones para completar el proyecto, pero lo más importante:
- Haga que cada reunión sea lo más efectiva posible.
- Minimice el impacto negativo en el rendimiento.
Tan pronto como el planificador de la reunión entienda esto, su comportamiento cambiará inmediatamente para mejor.
Estadista
Un gerente de proyecto que solo participa en la creación de listas y en la verificación de elementos, independientemente de su contenido.
El problema
Completar cualquier proyecto requiere dos pasos esenciales:
- Haga una lista de tareas pendientes.
- Marque los elementos de la lista que se hacen.
El gerente de proyecto del tipo de estadísticas llegó a la conclusión de que mantener esta lista es la totalidad de sus responsabilidades laborales. No le preocupa lo que está en la lista. Solo por el hecho de que tiene puntos y que se verifican a un ritmo predecible. El estadístico no evalúa y no ofrece ningún enfoque crítico sobre cuáles son los elementos de la lista, sino que se basa en otros, diciéndoles el contenido del elemento y la fecha límite.
La mayor preocupación para tal gerente es que el software de gestión de proyectos puede hacer su trabajo. Por lo tanto, se vuelve innecesario. A menudo se dan estadísticas para liderar proyectos en dicho programa, y él mantiene cuidadosamente la información actualizada. El proyecto en sí puede estar en ruinas, el equipo puede lanzar un producto completamente incorrecto con un retraso de varios meses y una calidad deficiente, pero hasta ahora todo está debidamente documentado, el estadístico no ve problemas.
Afortunadamente, si un estadístico solo mantiene listas y elimina elementos, no hace daño al proyecto, si no tiene en cuenta su ignorancia del verdadero estado de cosas. El principal problema es que las estadísticas pueden mutar rápidamente a algo mucho peor.
Solución
Las estadísticas son difíciles de corregir porque su atención al detalle está profundamente arraigada en la naturaleza, posiblemente desde la infancia. Si alguien considera que las listas son importantes, no cambiará repentinamente su mentalidad después de sus palabras. Además, las listas son realmente importantes, pero son solo un mapa, no un paisaje. Esta confusa paradoja de las listas, que son importantes, pero no primordiales, hace que las estadísticas sean especialmente difíciles de corregir.
Una habilidad clave de la que carecen las estadísticas es la capacidad de trabajar con personas. El gerente interactúa con la lista en lugar de con las personas. Invítelos a hablar con la gente en vivo sobre lo que están haciendo y por qué, y no solo soliciten una lista de artículos. Sin embargo, en el caso de una ejecución deficiente, las estadísticas pueden pasar a la microgestión (ver administrador
inseguro ).
Finalmente, solicite escribir un resumen de un párrafo sobre el estado del proyecto, y no mostrar el resultado como una lista de elementos. Esto hará que presenten el proyecto de manera más integral.
Equivocado
El gerente está tan divorciado de las realidades del proyecto que brinda información falsa a las partes interesadas.
- Puede mutar a optimista o pesimista
- Peligroso cuando se combina con un desarrollador optimista
- Probabilidad de corrección: alta
- Peligro para el proyecto: muy alto
El problema
La responsabilidad principal del gerente es informar sobre el estado del proyecto. Esto se llama “establecer expectativas” y “cumplir expectativas” es la medida por la cual se determina el éxito de un proyecto. Un buen gerente de proyecto establece expectativas basadas en una combinación de datos cuantitativos y cualitativos, así como en su propia experiencia profesional. Por otro lado, un gerente equivocado se basa únicamente en sus instintos.
Las siguientes son frases clave que le permiten reconocer al administrador del proyecto en las nubes:
- "Tengo un mal presentimiento".
- "No creo que lleguemos a tiempo en este momento".
- "Creo que todo estará bien con nosotros".
- "No veo ningún problema".
- "Esta decisión me confunde".
Preste atención al uso de "yo" y "nosotros": estos son buenos marcadores de que la percepción del gerente se basa en impresiones subjetivas y no en los datos recopilados y analizados.
Es importante notar la diferencia entre un gerente equivocado, un
pesimista y un
optimista :
- Un pesimista , basado en su interpretación de la información cuantitativa y cualitativa, cree que el proyecto fracasará.
- Un optimista , basado en su interpretación de la información cuantitativa y cualitativa, cree que el proyecto tendrá éxito.
- El gerente equivocado solo en sus propios sentimientos forma una opinión sobre el éxito o el fracaso del proyecto, lo cual es completamente falso.
Esta es una de las pocas personalidades que puede arruinar un proyecto completo por sí solo. Si dicho gerente a menudo se reúne con las partes interesadas, entonces se debe aumentar la vigilancia porque puede ocurrir lo siguiente:
- El gerente le dice a las autoridades que todo está perdido, el proyecto nunca entrará en producción, como resultado de lo cual el proyecto se cancela.
- El gerente dice que todo está en orden y que todo llegará a tiempo, como resultado de lo cual las autoridades estarán aún más decepcionadas si llegan tarde, lo que conducirá a la cancelación del proyecto.
Solución
Afortunadamente, dicho administrador se puede arreglar en dos acciones:
- Pregúntele por qué siente lo que siente.
- Muéstrele datos cuantitativos y cualitativos contrarios a sus instintos.
¿Por qué pedir articular cómo se siente? Esto lo ayudará a comprender que el juicio no se basa en algo material, sino en una evaluación subjetiva, es decir, en sentimientos. Es vital que llegue a esta conclusión por su cuenta; no es necesario decir que tiene malos instintos. Sigue preguntando "¿Por qué piensas eso?" Hasta que llegues a un avance.
Tan pronto como el gerente lo entienda, muéstrele los hechos sólidos sobre el proyecto. Por ejemplo, si dice "La calidad del producto no es buena", imagine un gráfico que muestre una disminución constante en el número de errores en los últimos meses. Si dice: "Estaremos listos a tiempo", proporcione una lista de tareas incompletas y el tiempo habitual de finalización de la tarea, lo que demuestra lo contrario. En esta etapa, debería ser simplemente un asunto para que prevalezcan la mente y la lógica del gerente. Si permanece en la ilusión, repita el proceso tantas veces como sea necesario.
Pesimista
Un gerente que habla con confianza del fracaso del proyecto, y es imposible convencerlo de lo contrario.
- Puede mutar en el error
- Es peligroso en combinación con un probador como un alarmista
- Probabilidad de corrección: no
- Peligro del proyecto: extremadamente alto
El problema
La mayoría de los proyectos de desarrollo de software pueden considerarse fallidos desde un lado:
- Exceso de presupuesto.
- Exceder plazos.
- Falta de toda la funcionalidad necesaria.
- Problemas de rendimiento, estabilidad o escalabilidad.
- Una gran cantidad de errores.
En el mundo real, esto puede esperarse y, a veces, percibirse como una realidad inevitable. Pero el pesimista hace demandas tan altas que el proyecto no puede cumplir, por lo
que anuncia su fracaso mucho antes del fracaso real del proyecto.
Un pesimista se identifica fácilmente por dos características clave:
- Él elige específicamente métricas negativas sobre el estado del proyecto para enfocarse en lo negativo, ignorando o devaluando cualquier signo positivo.
- Le apasionan sus actuaciones, que a menudo están llenas de drama emocional.
Tal posición puede convencer a las autoridades de que el proyecto no tiene remedio y está realmente cancelado.
Solución
El gerente pesimista no puede ser reparado, ya que a menudo es infeliz en su vida personal, insatisfecho con el trabajo, la carrera o la propia empresa. Por lo tanto, lo negativo no tiene nada que ver con el proyecto en sí, sino que representa un problema personal. Lo mejor que puede hacer es ofrecer asesoramiento psicológico, que pocas compañías hacen. Esto lleva al resultado a menudo inevitable: el gerente se va o la compañía lo despide.
Optimista
Un gerente de proyecto que se ha convencido a sí mismo del éxito del proyecto, independientemente de la evidencia de lo contrario.
- Puede mutar al capitán del equipo o errar
- Peligroso cuando se combina con un desarrollador optimista
- Probabilidad de corrección: baja
- Peligro del proyecto: extremadamente alto
El problema
Como regla general, a las personas les gusta trabajar con personas positivas. La desventaja de un gerente optimista es que su visión positiva del mundo
no deja en claro las señales de advertencia del proyecto . En lugar de tomar medidas para solucionar los problemas, prefiere ignorar estos signos, considerándolos un negativo poco saludable, y en su lugar prefiere informar solo lo bueno. Esto crea una cultura de complacencia o desánimo entre los miembros del equipo, mientras que los jefes tienen la ilusión de que todo va bien.
En cualquier posición de liderazgo, el optimismo frente a la adversidad es una ventaja importante. Para distinguir un administrador optimista de un líder audaz, use las siguientes pruebas:
- ¿Se siente agradecido por las malas noticias?
- ¿Con qué frecuencia hace cumplidos infundados?
- ¿Está siempre de buen humor, no importa cuán baja sea la moral del equipo?
- ¿Evita la confrontación, incluso si está justificada?
- ¿No parece que a la gente le gusta más que el éxito del proyecto?
Un administrador optimista a menudo hace que un proyecto falle, porque ignora los problemas que pueden conducir al fracaso. Cuanto más tiempo lleve el proyecto, peor será el efecto.
Solución
Un optimista se confunde fácilmente con un líder audaz, por lo que rara vez se identifican y, por lo tanto, rara vez se corrigen. Para cuando aparece la apariencia optimista, a menudo es demasiado tarde ya que el proyecto ya ha fallado.
Las organizaciones se esfuerzan por promover líderes valientes. Como resultado, un gerente optimista tiene una mayor posibilidad de ascenso si puede convencer a sus superiores de que el proyecto fracasó por razones que escapan a su control.
Independientemente de la razón por la cual el gerente se comporta de esta manera, para el crecimiento profesional personal, no queriendo enfrentar una verdad incómoda o simplemente ingenuidad, el daño al proyecto es el mismo. La única diferencia es si está siendo promovido o despedido.
Capitán del equipo
Un gerente de proyecto que se enfoca en hacer felices a todos los programadores y no en el éxito del proyecto.
- Puede mutar a optimista
- Peligroso cuando se combina con un gerente de desarrollo de mantenimiento de paz
- Probabilidad de corrección: alta
- Peligro para el proyecto: bajo
El problema
La moral alta es importante para cualquier proyecto: los desarrolladores suelen ser más creativos y productivos cuando la moral es alta. Cuando un proyecto va mal, naturalmente, la moral cae hasta que la situación mejora. En este momento, en lugar de resolver los problemas del proyecto, el capitán del equipo se dedica a mejorar la moral.
El capitán del equipo y el
optimista tienen en común una actitud positiva, pero su manifestación es fundamentalmente diferente:
- El optimista ignora cualquier problema que enfrenta el proyecto e informa información incorrecta a las autoridades.
- El capitán del equipo considera el éxito del proyecto únicamente en términos de moral: la baja moral es un proyecto fallido; la moral alta es un proyecto exitoso. Piensa en los intereses de los clientes y superiores más tarde, si es que lo hace.
El capitán del equipo es muy fácil de detectar:
- Viene espontáneamente con golosinas como café y donas.
- Considera importante mantener conversaciones en privado con cada empleado, "para escuchar sus necesidades".
- Como regla general, a ella le gusta hablar sobre cosas personales, sobre la vida de un empleado fuera del trabajo (pensando que esto puede ser una fuente de insatisfacción).
- Envía cartas positivas, pone motivadores en toda la oficina y generalmente es demasiado positivo.
- Él representa los mejores muebles de oficina, la mejor iluminación y, como regla, el mejor ambiente de trabajo.
- Lucha ferozmente contra las malas condiciones de trabajo, como la falta de desarrollo profesional para los empleados, la capacitación insuficiente y el trabajo extra.
- Organiza reuniones extracurriculares con el equipo, no vinculadas a las etapas importantes del proyecto.
- Muy preocupado de que todos los participantes del proyecto lo amen.
Tal persona parece un gerente de proyecto ideal, pero hay dos razones para preocuparse:
- Todos estos eventos solo aumentan temporalmente la moral, que se desvanece rápidamente cuando las personas recuerdan las realidades del proyecto.
- No eliminan las causas fundamentales de baja moralidad, prefieren incentivos a corto plazo.
Por lo tanto, el capitán del equipo finalmente le gusta a todos, pero en realidad no hace el trabajo del gerente del proyecto.
Solución
El principal problema es que el capitán del equipo generalmente no tiene mucha experiencia como gerente de proyecto. Por lo tanto, la solución es entrenarlo. Afortunadamente, hay una gran cantidad de recursos de capacitación para gerentes de proyecto.
Al proporcionar al gerente las herramientas necesarias, es necesario alentarlo a identificar las causas fundamentales de la baja moral y luego corregirlas. Teniendo en cuenta la tendencia natural del capitán del equipo a mejorar el estado de ánimo de los empleados, seguramente hará intentos agresivos por encontrar y corregir las causas fundamentales del declive moral tan pronto como sepa qué buscar.En esta etapa, obtienes un gerente de proyecto con una mezcla muy poderosa de motivaciones: en primer lugar, usa la moralidad como una medida de los problemas en el proyecto y, en segundo lugar, encuentra estos problemas y los soluciona. Dado que su motivación proviene de la compasión por su prójimo, los problemas subyacentes a la baja moralidad serán rápidamente erradicados.Por cierto, en su carácter de ser amable con los demás, por lo tanto, es poco probable que los "cure" de este componente, y su "corrección" no debe implicar la eliminación de las partes positivas del personaje. Al final, si es posible mejorar el nivel del gerente del proyecto, es difícil encontrar una mejor opción para tales inversiones que el capitán del equipo.Tirano
Un gerente que trata a los miembros del proyecto con desprecio en nombre de su motivación para trabajar más duro.
El problema
Muchas personalidades fuertes suelen participar en proyectos de desarrollo de software, pero todos deben estar subordinados a un objetivo cada uno y centrarse en la implementación del proyecto. Por lo tanto, los gerentes de proyecto tienen la autoridad de liderar a los participantes del proyecto para garantizar el éxito del proyecto. El tirano abusa de estos poderes, utilizando refuerzo negativo para lograr resultados.Si bien los tiranos pueden no ser amados, los jefes a menudo creen que su "mano firme" es exactamente lo que se necesita para que un proyecto tenga éxito, especialmente si está retrasado. Las amenazas y los castigos en realidad actúan como un motivador para muchos tipos de personalidad (vea a un desarrollador como un soldado ), lo que ayuda a difundir a los tiranos.Los problemas reales con los tiranos son difíciles de detectar, pero son increíblemente perjudiciales para el proyecto.Cuanto más tiempo trabaje un tirano, más dramático será este lento drenaje de talento. Al final, una vez que todos los participantes competentes del proyecto sean expulsados, será imposible invitar a participantes talentosos y experimentados al proyecto, ya que los empleados potenciales no querrán trabajar con un equipo incompetente (el hecho aparece fácilmente durante la entrevista).Es importante tener en cuenta que el tirano generalmente se presenta al proyecto en el momento más inoportuno: cuando el proyecto está en problemas. Los proyectos en riesgo de fracaso deben eliminar a los miembros del equipo incompetentes, mientras se mantienen competentes, pero el tirano causa exactamente el efecto contrario.Solución
Para corregir a un tirano, es necesario hacerle saber que tal comportamiento afecta negativamente el proyecto. Hay dos enfoques generales para esto:Primero, proporcione datos cuantitativos que reflejen su estilo de gestión de proyectos:- Cuántos empleados valiosos abandonaron el estado.
- Éxito en atraer talento.
- Cuántas características lanzadas.
- Cuántos errores hay registrados.
- Cuantas fechas faltan.
Al comparar esta información, los plazos son especialmente efectivos.En segundo lugar, hágales saber qué indicadores espera en el futuro cercano. Lo más probable es que muestren irritación y desesperanza, porque no saben cómo mejorar estos indicadores. Pero esta es una oportunidad ideal para ofrecerles asesoramiento y capacitación sobre cómo convertirse en un mejor gerente. La capacitación debe cubrir lo siguiente:- Cómo se comportan con los empleados.
- Cómo discuten los fracasos y los éxitos de los proyectos.
- Cómo identificar y eliminar a los participantes incompetentes del proyecto.
- Cómo atraer y retener participantes competentes.
Siempre que haya un especialista adecuado para dicha capacitación, el administrador-tirano puede corregirse por completo, porque las siguientes características son inherentes a la persona:- La gente no quiere ser mala.
- A la gente le gusta ser amada.
- A la gente le gusta ser efectiva.
Lo principal es que el equipo adopte un nuevo enfoque, a pesar de la reputación del tirano en el pasado. El problema se puede resolver de manera muy simple, por ejemplo, para convocar una reunión con el tema "Lo siento" y "He cambiado para mejor".Obsesionado con el proceso
El gerente está tan obsesionado con el proceso que olvida su tarea: ayudar al proyecto a alcanzar el éxito.
- Puede mutar a tirano
- Peligroso cuando se combina con un gerente de producto de tipo dictador
- Probabilidad de corrección: alta
- Peligro para el proyecto: bajo
El problema
Al final de cualquier curso de capacitación o al leer cualquier libro sobre administración, cada gerente corre el riesgo de obsesionarse con el proceso. Esto puede suceder incluso con los mejores, por lo que la paciencia es importante al corregirlos.Hay dos amplias categorías de procesos que están obsesionados con:- Obsesión cascada
- Obsesión con el desarrollo ágil (Agile)
Quizás el curso o libro de capacitación denominó estos procesos de manera diferente, pero puede colocarlos fácilmente en la categoría correcta aplicando la siguiente prueba:- Obsesionados con la cascada, creemos que todos los problemas pueden resolverse con la ayuda de documentación adicional, por ejemplo, "a partir de ahora escribiremos los requisitos del sistema para cada documento con los requisitos del negocio".
- Aquellos obsesionados con el desarrollo ágil creen que todos los problemas pueden resolverse con la ayuda de frecuentes reuniones cortas, por ejemplo, "a partir de ahora organizaremos reuniones diarias por las mañanas no más de 15 minutos".
El objetivo de cualquier gerente es entregar el proyecto a tiempo y dentro del presupuesto. El proceso que utilizamos facilita esto. Cuando el gerente del proyecto se obsesiona, puede ignorar el objetivo principal y, en cambio, enfocarse en la pregunta "¿El proceso va bien?" en detrimento de otros deberes oficiales.Solución
Hagas lo que hagas, no intentes robarles el proceso ni desafiarlo. Se trata de un fanático religioso en lugar de una persona racional. Se convenció de que su proceso "arreglaría" el proyecto. Si piensan que el proyecto está "roto" e intenta decir "no nos ayudará", simplemente lo considerarán parte de la razón por la cual el proyecto está roto.Es fácil arreglar el proceso obsesionado: simplemente conformarse con todo lo que dice, recordando suavemente que "se necesita tiempo para convertir un gran barco" y "Roma no se construyó en un día". El punto es obligarlo a aceptar la implementación de un nuevo proceso a través de una serie de pequeñas innovaciones, en lugar de un cambio importante. Esto les permitirá aprender de su propia experiencia qué métodos son efectivos y cuáles no. Al obtener esta experiencia, aprenderán cómo adaptar el proceso a la situación en el terreno. Hay esperanza de que lo entiendan: el proceso es un medio para un fin, no un fin en sí mismo.Inseguro
Un gerente de proyecto que solicita constantemente el estado actual de los empleados, considerando que es necesario que se concentren en cumplir con sus tareas.
El problema
Cuando un gerente se sienta en su escritorio lejos de los participantes del proyecto que hacen el trabajo, puede fácilmente tener un sentimiento de inutilidad. Esto los hace hacer lo que sea necesario para sentirse necesarios y útiles. Para un gerente incierto, la forma más obvia de parecer productivo es verificar el trabajo actual de los empleados. Esto a menudo se logra utilizando los siguientes métodos:- Distribución de correos electrónicos solicitando el estado del proyecto.
- Programe reuniones para discutir el estado.
- El requisito de completar las hojas de tiempo en detalle.
- El requisito de romper metas sueltas en pequeñas tareas.
- Organizar reuniones cara a cara espontáneas para preguntar a los miembros del equipo sobre su estado.
Un administrador inseguro es ampliamente conocido por otro nombre: microgerente. Sus métodos de gestión de proyectos son interpretados por los miembros del equipo del proyecto como cualquiera o todos los siguientes:- Nitpicking
- Acoso
- Preocupación
- Distracción
- Interrupción
- Molesto
A menudo, los empleados desarrollan un profundo resentimiento hacia un gerente de proyecto incierto, porque en su percepción:- El gerente no confía en sus habilidades de gestión del tiempo.
- El gerente no cree en su evaluación de los plazos.
- El gerente no comprende la necesidad de estar solo para resolver problemas.
- El gerente no tiene nada que hacer más que preguntar e informar los estados.
Esta percepción crea una confrontación entre el gerente del proyecto y los desarrolladores, suprime la comunicación útil que el gerente podría usar para solucionar problemas reales. En lugar de interactuar con dicho gerente para la cooperación y la cooperación, los desarrolladores evitan cualquier contacto adicional con él, por temor a que (una vez más) se les solicite el estado.Solución
Un administrador inseguro es tan común que tal comportamiento se considera el trabajo principal del administrador. Asumiendo lo inevitable, la mayoría de los desarrolladores forman un cierto umbral, con qué frecuencia se les pedirá su estado actual. Como la mayoría ha aprendido a adaptarse a la búsqueda constante de estatus, un gerente inseguro no representa un alto riesgo para el proyecto, aunque priva al equipo de la posibilidad de comunicaciones útiles que de otro modo podrían haber tenido lugar.Tal gerente nace debido al hecho de que el rendimiento del equipo no es bien visible para él. Entonces, la solución es colocar a este gerente al lado del equipo. De lo contrario, este administrador se ve superado por el deseo de preguntar directamente el estado de cada desarrollador. Si están cerca, entonces el gerente puede entender el estado actual del proyecto, simplemente escuchando las conversaciones de los desarrolladores entre ellos. En este modo, el gerente es más efectivo, ya que solo necesita intervenir cuando la productividad es realmente difícil.Ver también: