Equipos de depuración

Capítulo 4. Tratar con personas venenosas

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Como sugiere la cita inicial de nuestro libro, la parte más difícil del trabajo creativo es la gente.

Hasta ahora, hemos adoptado un enfoque introspectivo. Empezamos examinando tus propios comportamientos privados y cómo enfocarlos según los principios de humildad, respeto y confianza (HRT). A continuación, exploramos formas de construir una cultura de equipo comunicativa en torno a estos conceptos. En el capítulo anterior, explicamos cómo moldearte para convertirte en un líder eficaz de un equipo de este tipo, si surgiera la necesidad.

En la segunda mitad de este libro vamos a cambiar de marcha y empezar a mirar hacia fuera. ¿Cómo interactúa tu equipo con personas que nopertenecen a tu grupo inmediato? Casi siempre hay gente que desea unirse a tu equipo o colaborar con él. Hay problemas a la hora de tratar con la política de tu organización más amplia. Y, por supuesto, tienes que tener un plan para tratar con las personas externas más importantes de todas: ¡los usuarios de tu software!

En este capítulo, hablaremos de la importancia de evitar que personas externas destructivas destrocen la cultura cooperativa que tu equipo se ha esforzado en construir. Y lo que quizá sea más importante, también hablaremos de cómo tratar a las personas venenosas que ya forman parte de tu equipo.

Definición de "venenoso

Ya hemos repasado la importancia de crear una cultura de equipo sólida y comunicativa. Pasamos la mayor parte del tiempo hablando de lo que debe incluir una buena cultura: cosas como el desarrollo basado en el consenso, el código de alta calidad, las revisiones del código y un entorno en el que la gente se sienta lo suficientemente cómoda como para probar cosas nuevas y fracasar rápidamente.

Igual de importante es la necesidad de hablar de lo que tu culturano debe incluir. Si intentas crear un equipo altamente eficiente y que se mueva con rapidez, es importante que te centres en lo que noquieres. Mientras que los ingenieros brillantes pueden hacer que tu equipo sea más rápido y eficiente, ciertos anti-comportamientos pueden hacer que tu equipo sea más lento y menos eficiente, y hacer que tu empresa sea un lugar menos cómodo para trabajar -y acabar erosionando los lazos que mantienen unido al equipo.

Cuando empezamos a hablar sobre los retos sociales del desarrollo de software, se nos ocurrió una presentación titulada "Cómo tratar con los huevos podridos". El presidente de una conferencia nos sugirió que cambiáramos el nombre de la charla por "Cómo sobreviven los proyectos a la gente venenosa", con la esperanza de que un título más sensacional atrajera a más público. Y tenía razón: dimos la charla una y otra vez en distintas conferencias ante multitudes que se ponían de pie. No es sólo la negatividad de una palabra comovenenoso lo que atraía a la gente, sino el hecho de que todo el mundo parece tener algún tipo de experiencia personal en el trato con personas irritantes. Las charlas casi siempre se convertían en sesiones de terapia de grupo, en las que los asistentes intercambiaban historias de guerra y pedían consejo.

Pero existe un peligro. En general, no es sano pasar el tiempo sumergido en un océano de negatividad: tiende a consumirte y, a la larga, puede crear más conflictos.¹ El término persona venenosa es una etiqueta desagradable y crea automáticamente una línea divisoria entre "nosotros" (los buenos) y "ellos" (esos imbéciles desagradables). Hay una forma mejor de plantearse el problema. En lugar de dirigir tu equipo de como una fraternidad de élite con la misión de "repeler a la gente mala", es más saludable crear una cultura que simplemente se niegue a tolerar determinados comportamientos negativos. Lo que quieres filtrar son loscomportamientos, no individuos concretos. Es ingenuo pensar en los individuos como puramente buenos o malos; es más constructivo y práctico identificar y reprender los comportamientos intolerables.

Por ahora, seguiremos utilizando el término persona venenosa como una retórica simplificadora, que se refiere a una persona que no se comporta bien. En la práctica, sin embargo, ¡no es un término que quieras utilizar en las conversaciones cotidianas!

Fortalecer tu equipo

Recordemos nuestra metáfora de la levadura: cómo crece la cultura de un equipo a partir de una importante cultura inicial. La mayor influencia individual en la cultura a largo plazo de tu equipo es el equipo con el que empiezas, y si el equipo fundador no establece una cultura lo suficientemente fuerte, cepas de otras culturas la sobrecrecerán. Si tu equipo inicial crea un fuerte sentido de los comportamientos aceptables e inaceptables, estas expectativas perdurarán.

Los dos hemos pasado mucho tiempo en el mundo de los proyectos de código abierto, y nuestras propias experiencias coinciden bastante con esta idea.

El proyecto en el que más participamos -Subversion- lo inició un grupo muy reducido de personas. Tenían mucha humildad y, naturalmente, confiaban y se respetaban mutuamente. Después de más de 15 años, el proyecto ha pasado por al menos tres o cuatro generaciones de participantes (la mayoría de los fundadores ya no están) y, sin embargo, persiste la misma cultura: todos son amables, educados y esperan el mismo comportamiento de los demás. La cultura se perpetúa no sólo por los altos niveles de exigencia, sino porque las culturas tienden a autoseleccionarse. Las personas amables tienden a sentirse atraídas por las comunidades amables existentes.

La autoselección también puede funcionar fácilmente en la otra dirección. Cuando un equipo lo inicia un grupo de imbéciles enfadados, el esfuerzo tiende a atraer a más y más individuos de la misma calaña. Algunos proyectos que no mencionaremos en (como la comunidad del núcleo de Linux) son buenos ejemplos de ello: llenos de discusiones interminables y golpes de pecho. Sí, puede que el equipo consiga hacer mucho trabajo, pero la eficacia general de su funcionamiento es dudosa. ¿Cuánto más trabajo se haría si no se gastara tanta energía en ataques personales? ¿Cuánta contribución potencial se pierde porque se ahuyenta a la gente educada en la puerta de entrada?

Volvemos a sacar este tema porque tienes que entender lo que está en juego: las personas venenosas son una amenaza directa para tu equipo de alto funcionamiento. Si permites que persistan los malos comportamientos, no sólo disminuye tu productividad, sino que también puedes descubrir que tu cultura cambia lentamente a peor. La mejor defensa es fortificar tu cultura mediante un sólido conjunto de buenas prácticas y procedimientos. Ya los tratamos enel Capítulo 2, pero aquí tienes un rápido repaso:

• Ten una declaración de misión visible, para mantenerte centrado tanto en tus objetivos como en los que no lo son.

• Establece una etiqueta adecuada en torno a las discusiones por correo electrónico. Mantén los archivos, haz que los recién llegados los lean y evita el filibusterismo de las minorías ruidosas.

• Documenta toda la historia: no sólo la historia del código, sino también las decisiones de diseño, las correcciones de errores importantes y los errores anteriores.

• Colabora eficazmente. Utiliza el control de versiones, mantén los cambios de código pequeños y revisables, y reparte el "factor bus" para evitar la territorialidad.

• Tener políticas y procedimientos claros sobre la corrección de errores, las pruebas y la publicación del software.

• Racionaliza la barrera de entrada para los recién llegados.

• Confía en las decisiones basadas en el consenso, pero ten también un proceso alternativo para resolver los conflictos cuando no se pueda llegar a un consenso.

La conclusión es que cuanto más arraigadas estén estas buenas prácticas, más intolerante será tu comunidad con los comportamientos venenosos. Cuando lleguen los alborotadores, estarás preparado.

Identificar la amenaza

Si vas a defender a tu equipo contra personas venenosas, lo primero que tienes que hacer es comprender exactamente qué constituye una amenaza y cuándo debes preocuparte.

Lo que está específicamente en riesgo es la atención y elenfoque de tu equipo.

Atención y concentración son los recursos más escasos que tienes. Cuanto mayor es el equipo, más capacidad tiene para centrarse en construir cosas y resolver problemas interesantes, pero siempre es una cantidad finita. Si no proteges activamente estas cosas, es fácil que personas venenosas interrumpan el flujo de tu equipo. Tu equipo acaba discutiendo, distraído y emocionalmente agotado. Todos acaban dedicando toda su atención y concentración a cosas distintas de la creación de un granproducto.

Mientras tanto, cabe preguntarse: ¿qué aspecto tiene una persona venenosa? Para defenderte, tienes que saber a qué atenerte.

Según nuestra experiencia, es raro encontrar personas que sean deliberadamente malintencionadas (es decir, que intenten ser gilipollas a propósito). A esas personas las llamamos "trolls" y solemos ignorarlas. Sin embargo, la mayoría de las personas que se comportan mal no se dan cuenta de ello o simplemente no les importa. Es más una cuestión de ignorancia o apatía que de malicia. La mayoría de los malos comportamientos se reducen a una simple falta de TRH.

He aquí algunas señales y pautas clásicas a las que prestar atención. Cuando vemos estas pautas, hablamos de "darle la vuelta a la bozo", es decir, tomamos nota mentalmente de que la persona está mostrando sistemáticamente comportamientos venenosos y de que debemos ser extremadamente cuidadosos al tratar con ella.

Falta de respeto por el tiempo de los demás

Hay ciertas personas que sencillamente son incapaces de averiguar qué está pasando en un proyecto. Su daño suele consistir en hacer perder el tiempo al equipo. En lugar de dedicar unos minutos de su propio tiempo a leer la documentación fundamental del proyecto, las declaraciones de misión, las preguntas frecuentes o los últimos hilos de discusión por correo electrónico, distraen repetidamente a todo el equipo con preguntas sobre cosas que podrían averiguar fácilmente por sí mismos.

En el proyecto Subversion, una vez tuvimos un participante que decidió utilizar el foro principal de debate para desarrolladores como caja de resonancia de su flujo diario de conciencia. Charlie no hizo ninguna contribución real al código. En su lugar, cada dos o tres horas, enviaba sus últimas ensoñaciones y tormentas de ideas. Inevitablemente, recibía múltiples respuestas explicando por qué sus ideas eran incorrectas, imposibles, ya estaban en marcha, ya se habían discutido y/o ya estaban documentadas. Para empeorar las cosas, Charlie incluso empezó a responder a preguntas de usuarios que se le habían pasado por la cabeza, y a responderlas incorrectamente. Los colaboradores principales tuvieron que corregir repetidamente sus respuestas. Tardamos bastante en darnos cuenta de que este participante afable y entusiasta era en realidad venenoso y estaba drenando nuestra energía colectiva. Más adelante en este capítulo hablaremos de cómo afrontamos la situación.

Ego

Quizá ego no sea la palabra perfecta en este caso, pero utilizamos el término para describir a quien es incapaz de aceptar una decisión consensuada, de escuchar o respetar otros puntos de vista, o de llegar a compromisos. Esta persona suele reabrir discusiones que hace tiempo que están zanjadas (y documentadas en archivos de correo electrónico) porque ella no estaba para participar en la decisión. Esta persona no leerá ni pensará en absoluto en la historia, y exigirá que el debate se repita sólo por ella. A menudo hará afirmaciones generalizadas sobre el éxito del proyecto, afirmando que la ruina es inminente a menos que se salga con la suya.

El proyecto Subversion tuvo un episodio notable en el que un programador inteligente apareció un día en la lista de correo electrónico y declaró que todo el producto estaba mal diseñado. Había visto la luz, tenía ideas radicales sobre cómo debían funcionar las cosas e insistió en que todo el proyecto volviera a empezar desde cero. Incluso se ofreció voluntario para dirigir él mismo el reinicio. Sin su liderazgo, proclamó que el fracaso total estaba a la vuelta de la esquina.

Se desperdició una semana entera mientras los fundadores del proyecto discutían interminablemente con esta persona y defendían sus decisiones de diseño originales. Se perdió una enorme cantidad de atención y concentración. Quedó claro que esta persona no estaba dispuesta a ceder ni a integrar ninguna de sus ideas en el producto actual, y el producto (que ya estaba en fase beta y se utilizaba en la naturaleza) no iba a empezar de nuevo. Llegó un momento en que simplemente tuvimos que alejarnos del debate y retomar el camino. Irónicamente, años después, las predicciones de esta persona resultaron ser correctas en muchos aspectos, pero eso no impidió que Subversion se convirtiera en un gran éxito, al menos en el desarrollo de software corporativo. Aquí no se trata de quién tiene razón o no, sino de si está garantizado que un desacuerdo llegue a una conclusión y de si merece la pena mantener un debate. Nunca dejes de hacerte este tipo de preguntas; en algún momento tendrás que decidir cuándo es el momento de cortar por lo sano y seguir adelante.

Derecho

Siempre que tengas un visitante que exija que se haga algo, debería saltar tu alarma. Algo va mal con una persona que pone toda su energía en quejarse de las insuficiencias del programa, pero no está dispuesta a contribuir directamente de ninguna manera.

Este sentido del derecho de a veces desemboca en un comportamiento de troll. Mientras gestionábamos el servicio de alojamiento de proyectos de Google, una vez el propietario de un proyecto nos pidió que prohibiéramos el acceso a un usuario por comportamiento obsceno. El proyecto de código abierto, un emulador de videojuegos, no funcionaba correctamente con su videojuego favorito. El usuario empezó presentando un error bastante grosero en el gestor de incidencias. Los desarrolladores del proyecto explicaron educadamente por qué el juego no funcionaba todavía, y por qué era poco probable que se arreglara en un buen tiempo. Esta respuesta fue inaceptable para el usuario, que empezó a acosar a los desarrolladores a diario. Abría un bug tras otro con la misma queja. Empezó a añadir comentarios a otros fallos diciendo lo "idiotas" que eran los desarrolladores por negarse a solucionar su problema. Su lenguaje se volvió cada vez más obsceno con el tiempo, a pesar de las repetidas advertencias de los desarrolladores y de los administradores de Google. A pesar de todos nuestros esfuerzos por eliminar su comportamiento destructivo, se negó rotundamente a cambiar, por lo que finalmente nos vimos obligados -como último recurso- a expulsarle por completo.

Comunicación inmadura o confusa

La persona no utiliza su nombre real. En su lugar, sólo verás apodos infantiles como "SuperCamel", "jubjub89" o "SirHacksalot" Para empeorar las cosas, a menudo la persona tendrá diferentes apodos en diferentes medios: un nombre para el correo electrónico, otro para la mensajería instantánea y quizás otro para los envíos de código. En casos extremos, verás a estas personas comunicándose en "lol-speak", "1337speak", TODO EN MAYÚSCULAS, o con excesiva puntuación!?!1!!1!!!

Paranoia

Como hemos visto en el ejemplo anterior, a veces un sentido inapropiado del derecho conduce directamente a una hostilidad abierta hacia un proyecto. Muchas veces lo vemos escalar hasta la paranoia total. Cuando un equipo existente no está de acuerdo con el visitante, la persona venenosa empezará a veces a lanzar acusaciones de "cábala" y conspiración. Resulta divertido imaginar que el equipo del proyecto le considera tan importante como para tomarse la molestia de conspirar contra el visitante. Y si ya tienes una cultura de comunicación abierta y transparente (como impulsamos en el Capítulo 2), esto hace que la acusación sea aún más hilarante, puesto que cada conversación ya es un registro público. La recomendación aquí es ni siquiera molestarse en responder a tales acusaciones. En el momento en que la persona venenosa sobrepasa este perímetro, cualquier cosa que digas no hará sino cavar un agujero más profundo en su mente, así que ¿para qué molestarse en decir nada? Es hora de volver al importante trabajo de hacer cosas.

Perfeccionismo

A primera vista, los perfeccionistas no parecen peligrosos en absoluto. Claro, puede haber un toque de extraño comportamiento obsesivo-compulsivo de vez en cuando, pero normalmente la persona es humilde, educada, respetuosa y sabe escuchar. Parece lleno de feliz TRH y buenas intenciones. Entonces, ¿cuál es el problema? El problema es la amenaza de parálisis.

Veamos a una persona con la que hemos trabajado en el pasado. Patrick era un ingeniero brillante. Tenía grandes dotes de diseño, escribía código y pruebas de alta calidad y era fácil llevarse bien con él. Por desgracia, cuando llegaba el momento de diseñar un nuevo software, podía pasarse el resto de su vida retocando y mejorando su diseño. Nunca estaba satisfecho con los planes y aparentemente nunca estaba preparado para empezar a codificar. Aunque ciertamente tenía buenos argumentos y excelentes ideas sobre los problemas que intentábamos resolver, el resto del equipo acabó sintiéndose inmensamente frustrado; quedó claro que en realidad nunca íbamos a escribir ningún código. Varios miembros del proyecto deliberamos bastante sobre qué hacer al respecto. Por un lado, Patrick era una gran ayuda para nuestro equipo. Por otro, nos impedía avanzar como grupo. Cada vez que empezábamos a codificar, nos vetaba educadamente y nos señalaba posibles problemas teóricos que podrían tener importancia en un futuro lejano. Nos estaba paralizando sin darnos cuenta. Hablaremos de cómo resolvimos esto en la siguiente sección.

Repeler el veneno

No somos partidarios de echar a la gente de una comunidad sólo porque sean antisociales o maleducados. Como hemos dicho antes, no es sano crear una camarilla centrada en "nosotros" (la gente buena) frente a "ellos" (la gente mala). En nuestros ejemplos anteriores no nos centramos en expulsar a la persona, sino en expulsar el comportamiento. Deja claro que no se tolerarán los malos comportamientos. Si, tras repetidas advertencias, el comportamiento no cambia, sólo entonces tiene sentido plantearse el rechazo formal.

Concentrar tu esfuerzo en eliminar el comportamiento tóxico suele bastar para convertir a una persona inteligente (aunque quizá socialmente torpe) en un miembro productivo de tu equipo. Hace unos años teníamos un miembro del equipo que era un excelente ingeniero, pero tenía la molesta costumbre de insultar accidentalmente a sus compañeros. En lugar de expulsarle sin más de la comunidad, uno de nosotros le llevó aparte y le preguntó si era consciente de que sus palabras estaban alienando a la gente. Parecía algo sorprendido de que esto estuviera ocurriendo y no entendía exactamente por qué sus acciones estaban teniendo este efecto. Pero estuvo de acuerdo en que valdría la pena intentar moderar sus acciones en aras de ser un mejor miembro del equipo. Y todo funcionó a la perfección. Cambió su comportamiento y el problema se resolvió. ¡No todas las anécdotas acaban en exilio!

Vale, ya has identificado a una persona venenosa. Tal vez haya alguien distrayendo y drenando la energía de tu equipo en este momento. ¿Cómo afrontar eficazmente la situación? He aquí algunas estrategias útiles.

Redirige la energía de los perfeccionistas

Una vez encontrada una solución suficientemente buena para el problema original, señala al perfeccionista otro problema que aún necesite atención.

En el caso del perfeccionista de Subversion, esta estrategia funcionó bien. Al final, llegamos a un punto en el que llevamos a Patrick aparte y le dijimos: "Vale, vamos a empezar a trabajar a partir de este diseño tal y como está ahora, y a ver qué pasa. Esperemos que puedas ayudarnos a sortear cualquier problema que surja por el camino". Para nuestra sorpresa, a Patrick le pareció bien y pasó a otro tema como objeto de su obsesión. De todos modos, no se hirieron sentimientos y Patrick siguió contribuyendo al esfuerzo general.

Hay un viejo refrán que dice que "lo perfecto es enemigo de lo bueno", y en tu afán por crear un equipo de alto rendimiento, tienes que estar tan atento para evitar el perfeccionismo como para llamar la atención sobre los comportamientos perturbadores más evidentes.

Este truco de redirigir la energía también funciona con las personas con demasiados derechos que pasan más tiempo quejándose y criticando que ayudando. Es tentador responder a una persona así con un comentario estándar de "bienvenidos los parches", la versión eufemística de la comunidad de código abierto de decirle a alguien que se calle o se calle. En lugar de eso, intenta que se interese por probar formalmente el software y señalar las regresiones. Así podrá seguir quejándose, pero de forma útil.

No alimentes a la criatura energética

Este es un viejo adagio de Usenet.² En particular, funciona mejor contra los trolls deliberados: personas que intentan a propósito provocarte a ti o a tu equipo. Cuanto más respondas, más se alimentará el troll de tu energía y más tiempo habrás perdido. El simple tratamiento silencioso suele funcionar mejor. Por mucho que te mueras de ganas de soltarle una pulla que le ponga en su sitio, resiste la tentación. Cuando se da cuenta de que nadie le presta atención, suele perder el interés y se va. Ten en cuenta que a menudo hace falta mucha fuerza de voluntad para no responder. ¡Sé fuerte!

No te emociones demasiado

Aunque la persona no esté troleando deliberadamente, es muy fácil ponerse a la defensiva. Cuando alguien te acusa de haber tomado una mala decisión de diseño o de conspiración, o simplemente te hace perder el tiempo haciendo demasiadas preguntas cuyas respuestas son obvias, es fácil enfadarse. Recuerda que tu trabajo es construir grandes cosas, no apaciguar a todos los visitantes ni justificar repetidamente tu existencia. Cuanto más fuertes sean tus emociones, más probable será que pierdas horas o días escribiendo respuestas apasionadas a alguien que no merece tanta atención. Elige tus batallas con cuidado y mantén la calma. Decide cuidadosamente a quién merece la pena responder y a quién dejarás estar.

Busca hechos en la bilis

Siguiendo con el tema de mantenerse alejado de demasiadas emociones, un corolario es buscar activamente los hechos. Si alguien se queja, escucha con atención. Empieza siempre por conceder a la persona el beneficio de la duda, a pesar del lenguaje airado o grosero. ¿Tiene algo de verdad? ¿Hay algo que aprender de la experiencia de esa persona, o una idea a la que merezca la pena responder? Muy a menudo la respuesta es "sí", es decir, que a pesar de la prosa vitriólica de una persona venenosa, realmente hay algo de sabiduría enterrada en ella. Devuelve siempre la discusión a undebate técnico.³

Nuestro ejemplo favorito de esto es el día que recibimos un rencoroso correo electrónico de un conocido líder de la comunidad de código abierto. Se trataba de una especie de informe de error, pero a primera vista era más bien una diatriba sobre la inteligencia general del equipo. El mensaje estaba repleto de calumnias e hipérboles, y parecía destinado a enardecer al equipo más que a conseguir que se solucionara el fallo. Sin embargo, uno de los miembros de nuestro equipo respondió al informe con unas pocas preguntas concretas, centrándose únicamente en el fallo. El informador del fallo respondió con más aclaraciones, pero seguía envuelto en un veneno exagerado. Nuestro miembro del equipo siguió ignorando por completo los insultos, investigó el problema y respondió con un simple "Gracias por el informe de error, ya veo cómo solucionar el problema; publicaremos un parche en breve".

Nos sentimos inmensamente orgullosos del modo en que nuestro miembro del equipo manejó la situación. Mantener la calma y basarse en los hechos sólo hizo que el autor original pareciera más lunático a medida que avanzaba la conversación. Al final del intercambio, el informador de errores había perdido toda credibilidad ante su público y ya no tenía ningún interés en quedarse.

Repele a los trolls con amabilidad

Para llevar aún más lejos el planteamiento anterior (de mantener la cabeza fría y los hechos), ¡a veces es posible asustar a la gente simplemente siendo demasiado amable! Aquí tienes una transcripción de un chat del canal IRC de Subversion:

harry: La subversión apesta. Esto es un fastidio.

sussman: Si necesitas ayuda, pídela.

harry: Quiero cvs los archivos de alguien. No, sólo quiero quejarme. Pero esta persona está colgada por esa cosa llamada Subversion, así que tiene svn en vez de cvs.

sussman: Así que consigue un cliente svn y comprueba sus fuentes.

harry Así que voy y me descargo esta cosa de Subversion... ¿puedes configurar make make install Subversion como puedes hacer con cvs? Por supuesto que no. Le culpo más a él que a la gente de Subversion.

sussman: Que no puedas./configurar; make; make install no significa que haya un gran error generalizado. La gente hace eso con el tarball svn todos los días.

harry No he dicho que haya un error.

sussman: ¿Crees que habríamos publicado el tarball si algo tan fundamental estuviera roto?

harry Me estoy quejando de este payaso. Sólo tengo que instalar expat o libxml. suspiro

sussman: Esas cosas suelen estar preinstaladas en la mayoría de los sistemas.

sussman: ¿Este tipo utiliza un servidor apache? Quizás deberías coger un binario.

harry No sé, sólo dice svn...

sussman: ¿En qué distro estás?

harry: FreeBSD

sussman: Sólo tienes que entrar en el árbol de puertos y hacer el puerto.

harry Me estáis arruinando la bronca... he venido aquí buscando una discusión... sois demasiado serviciales y simpáticos.

sussman: :-)

harry ¿Cuándo demonios llegas a un canal de IRC y todo el mundo intenta ayudarte? bla

- Harry ha renunciado

Saber cuándo rendirse

A veces, por mucho que lo intentes, simplemente tienes que darle la vuelta al bozo y seguir adelante. Aunque ya hayas dedicado mucha atención y concentración a intentar corregir los malos comportamientos, tienes que saber reconocer una causa perdida.

Volvamos a nuestra historia sobre Charlie, el simpático filósofo que posteaba con demasiada frecuencia en la lista de correo electrónico de Subversion. Con el tiempo, hicimos un análisis de las discusiones por correo electrónico y descubrimos que este participante se había convertido en el tercer remitente más frecuente en el transcurso de dos meses; el primero y el segundo remitentes más frecuentes eran colaboradores principales del proyecto, ¡y el 70% de sus mensajes se dedicaban aresponder a Charlie! Estaba claro que nos estaban absorbiendo la energía y la concentración, a pesar de que Charlie no tenía mala voluntad. Nuestra solución final fue enviarle un correo electrónico en privado y pedirle (educadamente) que dejara de publicar tan a menudo. Fue una conversación difícil de mantener, sobre todo porque él era incapaz de ver la cantidad de trastornos que estaba causando. Tras unas semanas más sin que se produjera un cambio significativo en su comportamiento, uno de nosotros mantuvo una larga (y aún más difícil) conversación telefónica con él en la que le pedimos que dejara de publicar. Al final se retiró como se le había pedido, un poco triste y confuso, pero respetuoso con los deseos del equipo. Todos nos sentimos un poco culpables por ello, ya que él nunca llegó a comprender el daño que estaba causando, pero también todos pensamos que era lo correcto. Fue una situación delicada de resolver, pero utilizamos una gran cantidad de TRH para mantener las cosas civilizadas y apropiadas.

Centrarse en el largo plazo

El camino hacia el éxito de un proyecto está bordeado por miles de distracciones. Si hay un tema común a la hora de enfrentarse a la distracción de las personas venenosas, es que resulta demasiado fácil dejarse atrapar por el drama inmediato de una situación. Si eres testigo de lo que crees que puede ser un comportamiento venenoso, debes hacerte dos preguntas críticas:

• A pesar de la pérdida de atención y concentración de tu equipo a corto plazo, ¿crees realmente que el proyecto seguirá beneficiándose a largo plazo?

• ¿Crees que el conflicto acabará resolviéndose de forma útil?

Si tu respuesta a cualquiera de estas preguntas es "no", tienes que intervenir para detener el comportamiento lo antes posible. Es fácil persuadirnos de que la ganancia a corto plazo de tolerar el veneno merece la pena, pero normalmente no es así: por ejemplo, alguien puede ser un gran colaborador técnico pero seguir mostrando un comportamiento venenoso. Existe la tentación de hacer la vista gorda ante el comportamiento para beneficiarse del avance técnico. Pero ¡cuidado! Una cultura fuerte basada en la TRH es insustituible, mientras que las contribuciones técnicas sondefinitivamente sustituibles. Citando a un antiguo compañero nuestro

Tengo varios amigos que le conocen en cierta medida. Uno de ellos me dijo: "A menudo camina por la delgada línea que separa al genio del lunático". El problema es que, hoy en día, la genialidad es un bien tan preciado que ya no es aceptable ser un excéntrico.

Greg Hudson

Por supuesto, Greg no está hablando aquí de "genios" literales; está señalando que el mundo está lleno de programadores muy competentes. Si encuentras a uno que es ofensivo o amenaza tu cultura a largo plazo, es mejor esperar a que aparezca otro.

Una vez nos encontramos con este tipo de situación en el proyecto Subversion. El equipo tiene una política estricta de no poner nombres en los archivos de código fuente (¡la misma política que discutimos enel Capítulo 2!): creemos que crea una territorialidad inmanejable. La gente tiene miedo de cambiar el código si lleva el nombre de otra persona, y mantiene artificialmente bajo el factor colectivo. En su lugar, permitimos que el historial del control de versiones acredite a las personas adecuadamente, y mantenemos un único archivo de nivel superior con los nombres de todos los colaboradores.

Un día apareció un programador inteligente y se ofreció voluntario para escribir una nueva función de gran envergadura que era muy necesaria. Envió el código para que lo revisáramos, y nuestro principal comentario consistió simplemente en pedirle que eliminara su nombre de la parte superior del archivo, para que le acreditáramos en los mismos lugares que a los demás. Sin embargo, se negó a hacerlo, y el debate llegó a un punto muerto. Al final, se tomó la decisión de rechazar su código y se marchó, llevándose sus juguetes. Por supuesto, todo el mundo estaba decepcionado, pero no queríamos violar nuestra política (y diluir nuestra cultura) sólo para conseguir antes la nueva función. Un par de meses después, otra persona acabó reimplementando la función de todos modos.

Para ser explícito: no merece la pena comprometer tu cultura por las ganancias a corto plazo , sobre todosi se trata de un colaborador brillante que no reconoce la importancia de la TRH.

Una reflexión final

En este capítulo se han tratado bastantes situaciones, y después de asimilarlo todo es fácil desarrollar un profundo sentimiento de paranoia. Recuerda que la mayor parte del mundo no está plagada de imbéciles. Un amigo nuestro dijo una vez: "Sí, sólo hay unos pocos locos ahí fuera; Internet sólo hace que parezca que todos viven en la puerta de al lado".

O, como dice el refrán de Robert J. Hanlon

Nunca atribuyas a la malicia lo que se explica adecuadamente por la estupidez.

Preferimos utilizar el término ignorancia en lugar de estupidez, pero la idea es la misma. Como dijimos al principio, es ingenuo pensar que las personas son buenas o malas. Hay muy pocas personas malvadas ahí fuera que intenten aplastar deliberadamente tu cultura; la mayoría de ellas simplemente están mal informadas o mal orientadas. O quizá sólo quieren reconocimiento y son demasiado ineptos socialmente para encajar. En cualquier caso, tu trabajo no consiste en cultivar la condescendencia y dejar fuera de tu proyecto a los campesinos menos ilustrados; más bien, tu trabajo consiste en ser intolerante con los comportamientos destructivos y ser explícito sobre tus expectativas respecto a la TRH. Hace falta sabiduría para comprender la diferencia y verdadera habilidad para llevarla a cabo.

¹ Probablemente Yoda tendría algo que decir aquí sobre evitar el Lado Oscuro.

² Que a su vez puede referirse a aquel episodio original de Star Trek, "El día de la paloma", en el que las emociones negativas alimentaban a una criatura de energía. Kirk y su homólogo klingon Kang ordenaron a sus hombres que dejaran de alimentar a la criatura energética, y ésta se alejó del Enterprise. Mira, todo vuelve a Star Trek.

³ Para más información sobre este tema, véase "The Retrospective Prime Directive" de Norman Kerth, en su libro Project Retrospectives (Dorset House).