¿Cómo puedo manejar las distracciones del equipo como las charlas?

La conversación no es inherentemente disruptiva

Trabajo con un equipo de desarrolladores que tienen talento pero que a menudo se distraen con charlas.

Dices que son "talentosos pero distraídos". ¿Qué te hace pensar que tienen talento? ¿Por qué crees que están distraídos? ¿Cuál es su métrica para determinar que el equipo o el proceso está operando a un nivel subóptimo?

Realmente no has defendido ninguna de esas cosas, excepto en la medida en que se supone que debemos estar de acuerdo ab initio en que la "charla" (que tiene una connotación bastante peyorativa) es perjudicial para el proyecto. ¿Cómo ha determinado que el estilo de comunicación del equipo está impidiendo que su proyecto tenga éxito?

Equipos autogestionados y la falacia de utilización del 100 %

Idealmente, los desarrolladores tendrían expectativas que les exigirían mantenerse enfocados y administrar (sic) su propio trabajo.

Si bien estoy de acuerdo en que un equipo ideal se autogestiona, no tengo conocimiento de sus prácticas de contratación, cultura corporativa o incentivos organizacionales para que los equipos se autogestionen. Sin embargo, el hecho de que parezca estar en un rol en el que tiene la tarea de administrar un equipo que no es autogestionado argumenta que esperar tal cosa puede no ser razonable sin cambios en su organización o proceso.

Además, "mantenerse enfocado" es a menudo la jerga de la gerencia para "parecer ocupado". Como se mencionó anteriormente, a menos que pueda argumentar que su equipo no está funcionando, realmente parece que la forma en que se comportan es más importante que los resultados que producen.

De hecho, al convertir el "cómo" en un problema, está actuando en contra del principio mismo de autogestión que parece desear. Incluso si el equipo está realmente desconectado, su tiempo se invertiría mejor en descubrir cómo involucrarlos en lugar de buscar formas de hacerlos parecer comprometidos.

Los desarrolladores son a menudo patos extraños. Algunos desarrolladores trabajan mejor en un silencio similar al de una catacumba o trabajando a las 2:00 am; otros prosperan con las conversaciones cruzadas y el compromiso del equipo en la oficina. Sin embargo, independientemente del estilo de trabajo, todos los desarrolladores necesitan tiempo para pensar para ser productivos: más clics en el teclado (por ejemplo, una mayor utilización) no genera un mayor rendimiento o un código de mayor calidad.

"Responsabilidad" y proceso del proyecto

Incluso cuando pregunto cuánto tiempo me llevará completar los elementos (que puedo completar en un marco de tiempo muy preciso), recibo comentarios negativos que indican un deseo de suprimir la responsabilidad.

Nuevamente, su conclusión no se basa en información en evidencia. Puede haber otras razones por las que su equipo de desarrollo no quiera dar plazos estrictos.

1. "Responsabilidad" es una palabra de moda para una forma de cambiar la culpa.

   Si a su cultura organizacional le gusta culpar y los proyectos a menudo se retrasan o están condenados al fracaso, ¿por qué el equipo debería querer rendir cuentas?

2. Los mandamientos de lo alto no son compromisos.

   Si el equipo no forma parte del proceso de estimación o programación, entonces se les "responsabiliza" de las fechas de entrega en las que no se inscribieron. Pregúntese honestamente si las estimaciones de los desarrolladores se solicitan y respetan como línea de base del proyecto, o si los plazos del proyecto se establecen fuera del equipo.

3. Las estimaciones no son compromisos.

   Si un desarrollador le dice que algo probablemente tomará tres días, pero el trabajo toma cinco, ¿qué sucede en su organización? ¿Alguien tiene la culpa? ¿El desarrollador es castigado o denigrado por la estimación errónea? Si es así, ¿por qué deberían hacer algo más que seguir adelante al ritmo que consideren sostenible?

4. Los compromisos no son garantías.

   Los desarrolladores rara vez son estúpidos. Si saben que algo tardará dos semanas (debido a la complejidad, los gastos generales del proceso o los obstáculos organizativos) y usted cree que tardará dos días, ¿cuál es su incentivo para darle un plazo diferente? Si la organización rutinariamente reduce sus estimaciones y luego los hace responsables, ¿dónde está su incentivo? Si dan estimaciones honestas y no cumplen con los compromisos voluntarios debido a impedimentos externos, ¿espera la organización una garantía de devolución del dinero en forma de horas extra no pagadas en lugar de tratar de resolver el impedimento?

Incluso si asumimos que su conclusión de que el equipo quiere evitar la rendición de cuentas es cierta, no ha profundizado lo suficiente en por qué . Claramente, hay un problema organizativo o de proceso en el trabajo aquí, y resolver el problema percibido no es realmente abordar la causa raíz, ni comprarle nada si finalmente se le "hace responsable" de un proyecto que está fallando.

¿Qué sigue?

Eche un vistazo honesto a su organización, su proceso de gestión de proyectos y los miembros de su equipo. Trate de ser objetivo y vea si los incentivos realmente se alinean con los intereses de los desarrolladores. Si no, ¡empieza por ahí!

Realizar una retrospectiva similar a Scrum también podría ayudar. Si el verdadero problema que desea resolver es obtener estimaciones honestas del equipo de desarrollo, las únicas personas que pueden decirle cómo obtenerlas son los miembros del equipo. Por supuesto, tendrá que ganarse su confianza (si la comunicación honesta no ha sido la norma), y no hay balas de plata. Aún así, es una de las mejores herramientas que existen: ¡pregunte a las personas con las respuestas reales!

Siempre hay otras cosas que puede inspeccionar y adaptar. Aún así, debe comenzar en algún lugar, y mantener diálogos honestos y abiertos es casi siempre el mejor lugar para hacerlo.

No sé por qué aclear16 eliminó su respuesta. Su respuesta es perfecta. Hay un montón de aspectos positivos con el tiempo inactivo e improductivo a través del trabajo en equipo. Hace madurar al equipo y tú quieres eso. Incluso iría tan lejos como para decir que, si se está quedando atrás, deje que el tiempo social continúe porque los aspectos positivos de eso ayudarán, no dañarán. Y probablemente el tiempo de inactividad no fue la causa.

Si intentas aplastarlo, corres un riesgo mucho mayor de destruir el equipo y alienarte a ti mismo.

Lo que sientes es que no tienes el control de tu equipo, que ni siquiera tienen la decencia de parecer ocupados cuando estás cerca. Conoce tu inseguridad. Superalo.

El primer problema que debes enfrentar: ¿Las distracciones son buenas o malas? Creo que esto no se puede responder con un claro sí o no.

En primer lugar, ningún desarrollador puede trabajar 8 horas seguidas y permanecer cuerdo. En un buen día, obtienes de 4 a 6 horas de trabajo concentrado. Pero no pienses que, dado que no están sentados concentrados en su escritorio, "no están trabajando". En mi experiencia, las mejores ideas y conocimientos surgen en el tiempo de inactividad.

En segundo lugar, la moral es un aspecto muy importante de la productividad. Un desarrollador motivado puede hacer más trabajo en 2h que uno desmotivado en todo un día. Es importante reconocer que verse ocupado no equivale a "trabajar duro".

Tercero, las distracciones realmente pueden dañar la productividad. No realmente en tiempo perdido, sino en flujo interrumpido. No importa si es el colega que pregunta sobre la última tendencia en tecnologías web o el gerente que quiere hablar sobre el último informe de TPS. Solo toma una eternidad volver a sincronizarse.

Agregar métricas puede ayudar. Sin presionar a los desarrolladores, puede comenzar a recopilar métricas simples como problemas/tiempo. Esto puede generar una sana competencia entre los desarrolladores sobre quién puede obtener la mejor puntuación. Pero tenga mucho cuidado , exagere y la gente comenzará a jugar con el sistema. Al igual que los incentivos, presionar a las personas que necesitan realizar un trabajo creativo reduce su producción.

Al final se trata de tener un ambiente de trabajo saludable.

¡Segunda opinión de @sqreept (+1!), estás tratando de lidiar con el síntoma en lugar de la causa .

Habiendo dicho eso, mi opinión a continuación solo representa algunos entre todos los escenarios posibles.

Ahora, el escenario:

mi equipo está charlando un poco demasiado

¿Por qué? Porque saben que tienen plazos sueltos que cumplir.

¿Por qué? Porque los desarrolladores tienden a ser reacios a proporcionar estimaciones.

¿Por qué? Porque no quieren hacerse responsables de las fechas.

¿Por qué?

• O no tienen buenas especificaciones, y luego el equipo se siente autorizado a agregar un gran relleno a sus estimaciones.
• O las especificaciones no son consideradas lo suficientemente buenas por el equipo de desarrollo, que se niega a trabajar en un plazo más ajustado para especificaciones supuestamente malas.
• O existe una cultura que les permite comportarse de esta manera

Entonces, respondiendo a su pregunta, deberá evaluar las causas de este comportamiento y tratar la causa, no el síntoma.

Sin embargo, tenga en cuenta que nadie trabaja productivamente 8 horas seguidas. Si cree que la charla está CLARAMENTE impactando en el desempeño general del proyecto, es posible que deba actuar. Pero no intente presionar demasiado a su equipo, porque simplemente no funcionará.

Una nota al margen: preguntar cómo va el progreso para claramente terminar con una charla puede sonar grosero. Estás tratando de lidiar con algo que consideras un problema real sin enfrentarlo directamente. Si, después de evaluar el escenario, realmente cree que es un problema, sea sincero con su equipo y permítales exponer sus opiniones. Las acciones secundarias (o preguntas secundarias, en este caso) no agregarán mucho valor, ya que está demostrando que no está enfrentando el problema real. Da un paso adelante y resuelve el problema (si lo hay) sin dar vueltas y más vueltas.

Su pregunta tiene una respuesta y una pregunta oculta: "¿Exagerar con la cháchara sintomática?"

overdoing: ¿Cuándo se vuelve exagerada la cháchara normal? sintomático: Sí, tienes razón. Esto es simplemente un síntoma. No trate de corregir el síntoma.

Pero, por experiencia, si te preocupas por la charla y eso se vuelve visible, inconscientemente harán más de eso :) Lo sé, no tiene sentido.

Lo que debe concentrarse ahora es hacer que el producto sea más "su producto" y menos "su producto". Construya sobre su orgullo, sobre su autoestima. ¡¡¡Nunca en el miedo!!!

¡Y buena suerte! Tienes una tarea más grande por delante que el producto, hagas lo que hagas...