Se dice que una característica de las organizaciones con poca madurez en calidad software es que se caracterizan por su alto número y alta dependencia de los llamados “héroes”.
Los héroes son una figura clásica en las organizaciones de desarrollo software. Un héroe del desarrollo software es aquel que cuando todo parece perdido es capaz de resolver un problema imposible para el resto, de cerrar una entrega para el cliente en el último segundo o de resolver un bug en producción cuando todo parecía perdido. Así, todo héroe se ha ganado su fama a pulso, release tras release, paso a producción tras paso a producción, madrugada tras madrugada, sábado a sábado, update en producción tras update en producción.
Una característica del héroe es la eficacia (que no la eficiencia). Como un McGiver, Terminator o militar para operaciones especiales, lo importante es solucionar el problema. No importa cómo. Los medios justifican el fin.
Y para ello son capaces de cualquier cosa: que, por ejemplo, no se puede replicar un entorno en el cliente… en vez de perder horas de configuración echan el PC al coche y lo instalan en el cliente. Es por ello que, muchas veces, una vez resuelto el problema, tiempo después, cuando las tropas regulares inspeccionan la zona encuentran soluciones inimaginables, que nadie entiende cómo funcionan, irrepetibles y que sólo puede tocar el héroe.
Por ello hay quien identifica disponer y fomentar héroes como uno de los grandes problemas de las organizaciones de desarrollo software, colocándolos incluso en listas de problemas tipo y frecuentes.
También hay organizaciones malignas que se aprovechan de la gran benevolencia de muchos héroes, haciendo uso de sus poderes durante horas y horas, sin descanso. Las hay (muchas) que incluso que promueven la aparición de héroes, y que alientan el heroísmo premiando y elogiando a aquellos quienes siempre responden rápidamente y sin pensar con un “sí, yo puedo hacerlo”. Creando un clima de constante heroicidad. Pero también hay sitios en los que el héroe, consciente de su poder y conocimiento, de los scripts, passwords, fuentes y configuraciones extrañas que guarda en su USB personal, toma el control de la organización, amenazando con abandonarla si no se conceden sus deseos (a estos héroes habría que recordarles aquello de que “Un gran poder conlleva una gran responsabilidad”)
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.
- 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
Pingback: Bitacoras.com
Pingback: Los héroes, una figura clásica en las organizaciones de desarrollo software
Sí, vaya por ellos!!
Pero, como siempre, en el punto medio está la virtud. En una organización de desarrollo de software es necesario disponer de ese tipo de perfil profesional que te resuelve todo, cuando sea, como sea y a pesar de lo que sea, pero… no a cualquier coste. En mi opinión, hay dos efectos perversos inherentes a estos perfiles:
+ El equipo de desarrollo. Cuando aparece el héroe, desaparece el equipo, se apartan y, por uno o por otros, ese equipo no aprende nada en esas situaciones y la situación se vuelve endémica a la organización. Ni el héroe ni elequipo tiene interés en «trabajar en equipo» y que quede constancia y se aprenda con las actuaciones del héroe apagando el fuego que tanto nos ha preocupado…
+ La propia organización. ya lo dices tú, Javier, cuando ese héroe toma conciencia de ese «poder», algunas veces se puede volver contra la organización, que depende en demasía de esa persona.
Lo ideal sería crear un ambiente un entorno, en el que el héroe se sintiera cómodo y el equipo y la organización crezcan junto a él. Yo le llamaría la figura del «SABIO» en vez del héroe. Yo quiero sabios!!! no héroes
hola bueno en ningún caso pretendo ni creo ser un héroe tal como se cuenta aquí. Pero ciertamente me siento en gran medida identificado con algunas de las descripciones que narra Javier.
Deseo compartir mi experiencia porque creo que hay una razon válida o al menos razonablemente válida para el actuar a veces un poco hostil del ‘heroe’.
A mi entender uno de los tantos motivos que hacen de una organización, una de aquellas con poca madurez en calidad de software, es la falta de consideración o conciencia de la rigurosidad teórica, técnica y metológica que se requiere para construir soluciones empresariales robustas, de mediana a gran escala y con real calidad de servicio. Y sin esta conciencia menos se podría hablar acerca de aplicar y reglar el uso buenas prácticas, eso si que ya es demasiado utópico para una organización de estas características.
La verdad es que para construir soluciones a la rápida y netamente funcionales, esta san google. Es decir que la cosa funcione, ‘no se como’, pero que funcione y punto.
Pero para el trabajo duro y cesudo de la ingeniera de software de calidad, se necesita de una perspectiva ingenieril seria y no de un mero parcheador de soluciones.
Segun yo, esta perspectiva se logra con una sólida y constante formación teórica y técnica más: oficio, expirencia, inteligencia, creatividad y probablemente algo de intuición.
La verdad que lidiar día a día, para construir sistemas de calidad, contra una organización que no comprende estos valores fundamentales de IS a lo que respecta a la construcción de sistemas es desgastante hasta el punto que uno simplemente aprieta el botón de ignición.
y luego que sucede? exactamente esto: ‘tiempo después, cuando las tropas regulares inspeccionan la zona encuentran soluciones inimaginables, que nadie entiende cómo funcionan…’
y pq no entiende como funcionan? porque no tienen ‘conciencia de la rigurosidad teórica, técnica y metológica que se requiere para construir soluciones empresariales robustas, de mediana a gran escala y con real calidad de servicio…’ A mi me costó mucho esfuerzo saber lo que sé y aun me sigue constando pq aun sigo aprendiendo y yo me hice respetar en este sentido.
A mi me tocó lidiar con esta situación en mi último trabajo y luego lo avandoné. En particular construí 3 sistemas, 2 de los cuales utilizan servicios web que realizan ventas y transferencias de información B2B y un tercer sistema que maneja procesos de negocio inter-areas en la empresa relacionados a finazas, ventas y algo de contabilidad.
A pasado un año, y el sistema sigue allí intacto llenándose cada vez más de información operacional, sin haber madurado absolutamente nada. Han tratado de externalizar el desarrollo con empresas y no han logrado entrar al diseño ni menos programación.
Y así esta organización, con nuevas ideas y necesidades de negocio, está estancada por un sistema que no crece a la par con ellos. ¿por qué? porque simplemente no fueron capaces de entender lo que les explique muchas…muuuuuuuuuchas veces.
Todas las empresas, como esta que mencione, tienen muy bien merecido un golpe de este tipo, porque creo que es casi la única forma para que maduren y entiendan. Estas empresas deben aprender a respetar y valorar el esfuerzo, conocimiento y profesionalismo que se requiere para realizar un trabajo de ingeniería de esta clase.
Bueno eso sería mi aporte…
Saludos
Jaime desde Chile
@Jaime Bravo: Muy buena la história Jaime, una buena aventura «heroica»…
Heroes como Cristian Serradilla, no existen mas! si ustedes vieran las tablas aftdprov y sus dependencias! hacerlo andar fue heroico. Un reconocimiento a este heroe caido en la batalla.
Pingback: ¿Beneficios del pair programming? ¿Dos programadores en un solo ordenador es perder medio equipo? - Javier Garzás, sobre calidad software y otros temas relacionados
Hay profesionales que conocen muy bien su trabajo y saben asumir su responsabilidad, que son capaces de solucionar bugs imposibles o plantear desarrollos de forma creativa y responsable. Profesionales que aman su trabajo y mantienen a flote grandes proyectos de software. Personas capaces de contagiar energía y aportar valor a los equipos. Para mi son aspirantes a héroes porque siempre quieren seguir desarrollando sus habilidades. Profesionales con vocación que son capaces de aunar eficacia y eficiencia.
Conozco algún caso y creo que las empresas deben apostar por estos héroes. No por otros.
Aunque no estoy muy de acuerdo con Javier me parece un buen post.
Saludos
Pingback: Lo mínimo que deberías saber siendo emprendedor no técnico: sobre el equipo técnico - Javier Garzás | Javier Garzás
Al igual que la palabra «lider» no posee el mismo significado que «jefe». Un «héroe» de verdad no es el equivalente a un «bombero» que solo se dedica a apagar incendios (sin desemerecer a los bomberos, que hombre, también son heroes).
He conocido héroes, de verdad, de los que todo el grupo aprende, parte de ser un héroe es compartir el conocimiento, y trabajar en equipo, quizás esto último debiera ser la premisa para aspirar a ser uno de verdad. Pues su afán de conocimiento nuevo y su creatividad, van sumados a su humildad.
Buen artículo.