Gestión por fuerza bruta y terror, mal demasiado común en las empresas tecnológicas nacionales

Cuando hace ya unos años trabajaba para una empresa grande, siempre recuerdo, y así lo solemos recordar cuando nos juntamos algunos amigos, en aquel tiempo compañeros que allí trabajamos juntos, que imperaba la gestión por fuerza bruta y terror.
Todos los que allí trabajábamos teníamos, sin exagerar, miedo (que va más allá de respeto) a nuestro jefe, que, a su vez, tenía terror al suyo (terror hasta el punto de que yo una vez lo vi temblar mientras hablaba con él por teléfono).
Las cosas se hacían bajo la llamada gestión por miedo: si algo salía mal sabías que o te caía una bronca de mucho cuidado y/o intentaban dejarte en ridículo delante de cuanta más gente mejor y/o te amenazaban con echarte (fácil en nuestro caso porque todos éramos externos en modo bodyshopping).
Otra “buena práctica” de gestión complementaria que allí solía usarse era la de la fuerza bruta. La idea era que todo saldría mejor si, además de tener asustado a aquel que tenía que hacer el trabajo, se usaba la fuerza bruta.
La fuerza bruta se manifestaba de diferentes formas. En “tiempo”, por ejemplo… si no funciona hay que echar más horas, días, noches, etc., si algo no sale es “porque no le has echado horas suficientes” (y no porqué los que programaron aquello apenas tenían conocimientos sobre diseño u OO). En “personas”… si la versión no es estable es que hacen falta 20 personas más probando… “más gente”, “es porque pocos la han probado” (y no por el churro código que había detrás, que parecía programado con los codos en vez de los dedos, pero eso nadie lo miraba).
Curiosamente, la gestión por fuerza bruta creaba además una extraña cultura bárbara, vikinga, en la que los más valorados eran los más brutos y así mucha gente competía en ver quien era el más rudo, para ganar así el favor de los dioses.
Galones de brutead que hacían ganarse el favor de los jefes eran “el que echaba más horas y se iba más tarde (aunque en realidad estuviera viendo el marca todo el día)”, “el que llegaba primero (aunque dejase la chaqueta bien visible en la silla para que la viera el jefe al llegar y mientras se fuera a tomar cafés)”, “el que contesta más mails a horas raras, tipo las 4:00 am (aunque relamente los escribiera el día anterior y los dejaba listos en borrador, para darle a enviar o programarlos)”, “el que pega más voces a otros subcontratados de menor nivel”, etc.
Muchos en aquellos momentos de inocencia creímos que si empresas y directivos tan importantes gestionaban así… esa debía ser la manera de gestionar que debíamos aprender y replicar en futuras tribus y poblados que pudiéramos gestionar.
Afortunadamente, algunos nos dimos cuenta que era un error, que más allá de la brujería (fuerza bruta) había ciencia (ingeniería software) y abandonamos la cultura bárbara, otros aún no se han dado cuenta.
Y nos dimos cuenta de que la culpa de que el software tuviera incidencias no era de “echar pocas horas”… era de que el testing era prehistórico, y de que quin lo programó no tenía ni idea de lo que era, p.e. la OO, que los problemas en el desarrollo no eran “por gente poco comprometida que no enviaba correos a las 5:00 a.m.”… era culpa de gente que no había visto un libro de ingeniería software en su vida, o eran de que no había control de versiones (y todo andaba en carpetas compartidas), o de que el ciclo de vida era inexistente, etc.
Pero nunca ninguna gestión por fuerza bruta nos enseñó lo anterior.
..
Curiosamente, no hará más de unas semanas, tuve una conversación en twitter con un directivo que había escrito recientemente un libro en el que recomendaba como “clave del éxito y para tener mejores productos” en TI, como “buena práctica” para gestionar un departamento TI, “la tensión entre tecnología y comercial” y que es bueno “que peleen (sin llegar a las manos)” (menos mal, lo de las manos), literal.
Aquella conversación me recordó a las prácticas de “fuerza bruta”, “terror” y su, ahora variante… la “pelea”, rivalidad entre bandas, entre clanes, etc. Al estilo “game of thrones”: que sea un combate el que decida quien llevaba razón, así se manifiestan los dioses.
..
Y ojo, no voy a negar que “la necesidad estimula la mente”, que yo mismo cuando tengo presión hago cosas en tiempos record, que a todos nos afecta la ley de Parkinson (y meter prisa merma dicha ley), etc.
Yo mismo demasiados días trabajo más de 12 horas (porque creo que voy a terminar con algo productivo, no viendo el marca), yo pido a los que están trabajando conmigo que si cae una “bomba nuclear” me cojan el teléfono a las 5:00 am. Pero siempre en contadas ocasiones, sabiendo que es estrictamente necesario, que no es lo normal y que muchas veces eso pasa porque algo antes no se ha hecho bien.
Lo curioso es que ninguno de estos y aquellos directivos mencionó jamás otras maneras de gestionar o resolver problemas, nunca oí de ninguno que más allá de la fuerza bruta y el terror había otras cosas que eran no igual, sino tremendamente más importantes, y que si bien la fuerza bruta y terror podían sacarte en ocasiones de un problema, su uso vnía de no haber tenido en cuenta otros.
Otros, que nunca escuché, por ejemplo…
– Saber conformar un equipo en tamaño, sin interrupciones, multifuncional, motivado y en un entorno productivo
– El papel de la mala calidad software en la productividad, la deuda técnica y la mantenibilidad.
– Tener control de versiones, estrategias
– Saber testear (de verdad)
– Los problemas de un ciclo de vida en cascada, los problemas del proyecto cerrado
…
Esos nunca los escuché como estrategia de gestión más prioritaria en tecnología para que las cosas vayan bien, más prioritaria que la fuerza bruta y el terror.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023