El campo de cama a tiempo, o 5 signos de problemas ocultos en el equipo.

Hay muchos problemas en las comunicaciones y su solución siempre es muy específica para cada caso. La dificultad con algunos problemas radica en el hecho de que están ocultos y se hacen sentir claramente cuando ya es demasiado difícil o demasiado tarde para arreglar algo. Recordé cinco casos que personalmente encontré. No todo resultó estar resuelto, no todo se decidió conscientemente. Debajo del corte, encontrará cinco historias que ilustran los cinco signos de problemas. Complementé cada historia con una pista muy seca sobre la corrección porque la solución real es muy subjetiva.

El comienzo de febrero es un buen momento para pensar en la primavera, el verano, la cabaña de verano, las camas, las camas grandes y largas ... Es bueno que sea febrero, así que hablemos del trabajo en equipo. ¿Cómo es el libro de Tolstoi en Anna Karenina? "Todas las familias felices son iguales, cada familia infeliz es infeliz a su manera". Todos tienen su propia comprensión de lo bueno y lo malo. En mi opinión, cada equipo o empresa tiene ciertas características de la relación dentro del equipo y el liderazgo con sus empleados, que son el resultado de las características del comportamiento inconsciente de las personas. Es el factor de la inconsciencia lo que oculta estos problemas, porque a menudo si una persona no ve el problema, entonces el problema, por así decirlo, no lo es. En realidad, resulta que el comportamiento es diferente de lo declarado por el equipo o la empresa, pero implícitamente. Puede notarlos solo después de varios meses de trabajo en la empresa. Recordando problemas similares en diferentes compañías de TI, hice una lista de tales características que podrían descubrir rápidamente la naturaleza de los problemas existentes y la forma de encontrar soluciones.

1. Los desarrolladores son solo otro recurso

Tipo de problema: empresa vs. empleado

Un gerente me dijo: “Reporto a los CEO y partes interesadas. Y usted es solo un desarrollador ". Se suponía que tenía una gran responsabilidad, y para mí, como desarrollador, no había tal responsabilidad. Más tarde resultó que él no tenía su propia opinión sobre las personas que estaban bajo su mando y simplemente transmitió las ideas de su jefe. Y su jefe no se comunicaba muy de cerca con los desarrolladores. Como resultado, la gestión fue mínima y solo los informes fueron una prioridad. Debido a esto, la actitud hacia las personas era como si fueran engranajes en el mecanismo. Nadie podía decir esto directamente en virtud de las normas aceptadas, pero las cosas hablaban por sí mismas. Nadie le dirá que sus objetivos no son importantes porque perderán la cara. Pero, al mismo tiempo, nadie tendrá en cuenta sus intereses, ya que Su gerente sabe exactamente qué debe hacer, cómo pensar y qué sentir. Cuando discuta las perspectivas, puede decirle cosas agradables que desea escuchar. Pero la acción real no sigue esto, y siempre hay una razón por la cual algo más es más importante. Y si comienza a estar en desacuerdo, se le acusará de no escuchar, no comunicarse o, lo que es peor, de introducir grandes riesgos en el proyecto. Obviamente, su jefe se niega a encontrar una solución que sea beneficiosa para ambos. La solución más simple para él eres tú, haciendo solo lo que dijiste. En la empresa, esta actitud hacia los empleados se mantuvo a un alto nivel. Como resultado, la rotación de personal ha aumentado. Y varias personas clave ( desarrolladores y socios de productos (ing.: Propietario del producto) ) abandonaron la empresa.

Sugerencia: busque sinergia

Es normal que las personas tengan sus propios objetivos personales, y la compañía tiene los suyos. En particular, no coinciden, pero es importante comprender cuánto divergen las personas y la empresa en los objetivos. Al encontrar sinergias con los empleados, aumenta la ganancia en comparación con el caso en que las personas simplemente hacen lo que se les dice.

2. Alguien está constantemente monitoreando tus errores

Tipo de problema: gerente vs. empleado

Esto es normal cuando las personas en el trabajo intentan ayudar a sus compañeros de equipo discutiendo abierta y respetuosamente los problemas. Esta atmósfera de apoyo se rompe si los roles gerenciales (líderes de equipo o gerentes) la utilizan de manera incorrecta. La situación puede desarrollarse involuntariamente y puede ser más notable con la participación del gerente que el líder del equipo. Por ejemplo, un gerente le pregunta qué le gustaría mejorar como equipo. Tú, bien intencionado, estás diciendo, en un montón con el resto, que sería bueno si Vasya escribiera más pruebas unitarias. El gerente, cuando se reúne con Vasya, le dice, como si hiciera un reproche, que no escribe pruebas unitarias. Este párrafo puede ser un párrafo, por ejemplo, en una evaluación de desempeño. Vasya, al ver las afirmaciones del gerente, intentará averiguar por parte de sus colegas qué está mal, pero todos dicen que todo está bien. Porque para los colegas, el problema de las pruebas unitarias, como tal, no lo es. Pero en ese momento, la confianza comienza a deteriorarse. Para Vasya, todo parece como si alguien detrás de él lo estuviera ennegreciendo a los ojos del gerente, pero no lo dijo a los ojos. La situación es mala porque nadie la ennegrece específicamente. Entonces empeora, porque Si el gerente no puede resolver este problema, entonces, en tal atmósfera, la inseguridad de las personas en el equipo se intensifica y obliga a probar constantemente algo a los demás.

Sugerencia: insista en una discusión abierta

Aquí el gerente debe ser forzado. En primer lugar, no todas las quejas son realmente un problema. En segundo lugar, debe escuchar al empleado, porque él puede dar pistas de una situación similar. Y en tercer lugar, el gerente debe alentar a las personas a hablar sobre los problemas solo en presencia de otra persona. Las razones y los hechos de ambas partes deben tenerse en cuenta.

3. Siempre hay alguien a quien culpar por el error

Tipo de problema: equipo vs. empleado

Si bien el análisis de errores es la norma, un recordatorio constante de errores pasados ​​no es normal. La falla puede ocurrir debido a la falta de requisitos o falta de conocimiento, o debido a fallas sucesivas en diferentes etapas de desarrollo, como el código de revisión, QA, UAT. En este caso, la atención prolongada a una persona que cometió un error, burlarse de él tendrá un efecto negativo. Si este comportamiento es la norma en el equipo, pueden aparecer marginados en el equipo. Este comportamiento generalmente es compatible con uno de los roles principales. El resto de las personas en el equipo simplemente se ajustan y siguen el estilo del líder. En ausencia de apoyo desde arriba, este comportamiento no será largo y terminará rápidamente. Por supuesto, la persona que cometió el error debe saberlo y comprender cómo podría evitarse para no volver a pisar el rastrillo. Pero no te aferres a eso.

Sugerencia: deja de centrarte en los errores

La discusión de las fallas debe terminar inmediatamente después de que se hayan hecho todas las conclusiones. Los compañeros de equipo deben sentir apoyo en tal situación.

4. El equipo comienza las tareas sin descripción y planificación.

Tipo de problema: equipo vs. cliente

La fase de planificación es importante y nadie le dirá que no debe hacerlo. Al mismo tiempo, el equipo puede carecer de autoridad o falta de apoyo de la gerencia para retrasar tareas que no tienen una descripción. La gerencia puede decir que lamentan mucho y reconocen los errores de planificación que les hicieron aceptar acuerdos que no pueden demorarse. En tales circunstancias, los desarrolladores son los que pagan el precio final. La gerencia repetirá los mismos errores una y otra vez, porque los desarrolladores simplemente hacen lo que se les dijo. Al mismo tiempo, todos mantienen su cara, porque hay un reconocimiento formal del problema y una promesa de solucionarlo ... algún día. En el curso del trabajo, los desarrolladores se enfrentan constantemente a una situación en la que algo no se describe en las tareas. Comienzan a retrasarse, se apresuran y sienten una presión constante del liderazgo. Como resultado, los desarrolladores siempre son extremos.

Sugerencia: protege al equipo, no a ti mismo

El líder del equipo, o gerente, debe asumir la responsabilidad de proteger al equipo de otros gerentes y clientes, resistir su ataque y no decepcionar la responsabilidad al nivel del equipo. La definición de Listo para tareas debería ayudar a los gerentes a preparar las tareas lo suficientemente bien. En este caso, debería convertirse en una regla estricta.

5. Solución

Tipo de problema: procesos vs. empleados

En forma vívida, conocí esta característica en una empresa joven, donde los procesos se desarrollaron a un ritmo muy rápido. En una conversación personal, el jefe me dijo: "Tenemos un proceso, pero debe comprender cuándo vale la pena moverse para completar la tarea más rápido". Esto es cierto: a veces pasar por alto el proceso ayuda a alcanzar los objetivos más rápido, e incluso es necesario. Pero cuando es necesario pasar por alto el proceso en el 50% de los casos, el proceso en sí comienza a percibirse como algo formal. En este caso, es obvio que el proceso es más un obstáculo. Por otro lado, sin un proceso, la administración se siente insegura debido al mal control y la falta de confianza en los desarrolladores. Como resultado, todos entienden el problema, pero cambiar el proceso es difícil debido a la burocracia (todos necesitan consentimiento, esto es un montón de manifestaciones, etc., etc.). Por lo tanto, algunos gerentes pueden sugerir que los desarrolladores omitan el proceso basándose en los mejores motivos. Pero al ofrecer esto, ponen a los desarrolladores en una posición vulnerable donde cualquier paso puede considerarse de manera diferente dependiendo de las personas y las ocasiones.

Sugerencia: siga el proceso más fácilmente

Es posible que no necesite un proceso o reglas. En cambio, es posible que solo necesite recomendaciones sobre cómo hacer algo con la posibilidad de una ejecución diferente. Bueno, o puedes pensar en el proceso oficial de pasar por alto el proceso estándar, en algunos casos. Pero en este caso, ¿necesita un proceso que sea más lento?

¿Viste algo similar? Agregue sus comentarios de casos.