Cuando la dirección ignoró las advertencias de TI, el equipo técnico respondió con contundencia
(theregister.com)La respuesta aleccionadora del equipo de TI
- La historia de "Bruce", quien trabajaba en el equipo de infraestructura de internet de un banco australiano.
- En los primeros días de la banca por internet, el equipo creció rápidamente y también aumentó la carga de trabajo.
- Antes de que el uso de los enlaces ISDN superara la mitad de su capacidad, identificaron la necesidad de comprar enlaces adicionales y presentaron una propuesta al CIO.
El rechazo de la dirección y la respuesta del equipo de TI
- El CIO trasladó a la dirección la solicitud de comprar enlaces ISDN adicionales, pero fue rechazada porque el uso actual ni siquiera llegaba a la mitad.
- Cuando el uso de los enlaces superó el 50%, el equipo de TI volvió a hacer la solicitud, pero recibió la instrucción de esperar hasta que se acercara al 100%.
La medida estratégica del equipo de TI
- El equipo de TI decidió ajustar la conectividad de red de la dirección para que percibiera el problema.
- La primera semana redujo un 10% y luego añadió una reducción adicional del 10% cada semana.
- Un mes después, se aprobó la instalación de enlaces ISDN adicionales, y la dirección celebró haber resuelto los "problemas de internet".
La opinión de GN⁺
Lo más importante de este artículo es la respuesta estratégica del equipo de TI al cuestionar la decisión de la dirección y convencerla de la necesidad de invertir en infraestructura a través de la experiencia real de uso. Esto muestra un enfoque creativo y eficaz para cerrar la brecha entre los problemas técnicos y las decisiones de negocio. La historia no solo resulta interesante para los profesionales de TI, sino que también ofrece una lección que puede ayudar a quienes toman decisiones sin perfil técnico a comprender la importancia de la infraestructura tecnológica.
1 comentarios
Opiniones de Hacker News
Hace tiempo usé un software de terceros pésimo que les causaba grandes problemas a los clientes.
Estábamos creando una solución interna de reemplazo, pero algunos querían renovar el contrato y seguir usando el mismo software lleno de bugs.
Hice que todos los tickets abiertos por clientes fueran a quienes querían mantener la solución existente y, al final, después de migrar a nuestro sistema, los problemas casi desaparecieron.
Muchas veces, quienes están en la operación contienen heroicamente el dolor para que no llegue arriba, y la organización, en lugar de eliminar el problema, termina metiendo gente como analgésicos y se vuelve adicta a ese estado.
El sistema antiguo no podía hacer nada fuera de lo que ya hacía sin una reingeniería masiva, y el equipo a cargo creía que, si no compartía conocimiento, tendría empleo garantizado de por vida.
El sistema nuevo tenía mucha latencia en la base de datos porque creían que, en vez de corregir las consultas, bastaba con agregar más CPU.
Los dos equipos se sentaban uno al lado del otro, pero no se hablaban, y el equipo del sistema antiguo llegó incluso a reportar como bomba un paquete debajo del escritorio del director de IT.
Al final, el equipo del sistema nuevo llamó a Oracle, y Oracle reescribió las consultas.
La capacidad de explicar claramente los riesgos y de decir cómo las consecuencias técnicas impactan al negocio es una competencia clave para quienes trabajan en IT.
Es posible que la dirección de este banco haya sido realmente muy torpe, pero también existe la posibilidad de que el equipo técnico no lo haya explicado bien.
Quizá porque estoy dentro de IT, pero siento que nos comunicamos bastante bien y con precisión.
El verdadero problema es que la política de los mandos medios enturbia todo.
A tu equipo le puedes decir “yo la regué, así que tengo que arreglarlo”, pero hacia arriba hay gente que pone toda clase de excusas para no revertir incluso decisiones poco importantes.
Tal vez alguien ya le vendió a su jefe que ese equipo podía usarse otros 10 años.
Trabajando con colegas, veo que se esfuerzan bastante por explicar en distintos niveles de profundidad según la persona que escucha.
Lo que ocurre con más frecuencia es que la alta dirección y los gerentes debajo de ella simplemente no prestan atención.
Ya tienen en la cabeza un “gran plan”, y no cambia por más que los desarrolladores les digan que esa fantasía no puede hacerse realidad.
La mayoría entiende perfectamente lo que decimos.
No es que estemos soltando jerga incomprensible que solo conocen los nerds de rango superior; simplemente no les importa.
Ojalá hubiera menos casos de empresas dirigidas al estilo MBA por gente sin cabeza ni corazón, y más organizaciones donde los ingenieros asuman más responsabilidad, pero así es la vida.
IT corporativo creció a partir de funciones de soporte administrativo, y como no hacía falta planificación estratégica para que funcionaran una máquina de fax o una PC, al principio se lo trataba como un departamento poco importante.
Es fácil pensar que la gente de traje es tacaña o tonta, o que no entiende la tecnología, pero en realidad muchas veces se trata de falta de habilidades de comunicación.
En mi primer trabajo, el CFO seguía rechazando la solicitud de un sistema de respaldo adecuado para el AS/400.
Ese AS/400 contenía todo el trabajo de la empresa: ERP, CRM, contabilidad, etc., y respaldar el trabajo de 300 personas en disquetes de 8 pulgadas era inviable desde el principio.
Un día hubo una falla grave de discos y toda la empresa quedó detenida durante semanas; el procesamiento de pedidos, las solicitudes de soporte, las propuestas comerciales y la consulta de números y direcciones de clientes quedaron bloqueados.
Recuerdo que algunos discos se enviaron a Kroll Ontrack.
Solo después de ese desastre compraron un equipo de respaldo adecuado.
Unos meses después, un desarrollador estudiante ejecutó en producción una consulta de borrado con la cláusula
wherecomentada, y una tabla completa desapareció.Había respaldo, pero un proceso en segundo plano lo detectó y regeneró cuatro años de facturas, enviando correos a todos los clientes históricos para cobrarles de nuevo.
El entorno de pruebas apareció poco después.
Hace poco trabajé en una universidad comunitaria remota de dos años, donde todos los datos estaban en un AS/400 viejo que se caía uno o dos días cada pocas semanas.
No había respaldos, la unidad de cinta estaba descompuesta y piezas como una NIC de 10 Mbps, ya obsoleta incluso para la época, no tenían reemplazos.
Seguía pidiendo que lo reemplazaran o lo migraran a un servidor en la nube, pero la respuesta siempre era “no está en el presupuesto” o “es demasiado caro”.
Según el uso real, habría costado unos cientos de dólares al mes, algo absurdo comparado con el riesgo de que, si el sistema caía, toda la universidad colapsara e incluso pudiera cerrar permanentemente.
Al final ocurrió una falla y, durante varios días, se podía acceder desde la terminal principal, pero no se comunicaba en absoluto con la red.
La gente empezó a entrar en pánico, e incluso se habló de llamar a un experto en reparación de AS/400 que cobraba más de 100 dólares por hora.
Como último intento, logré arreglar la NIC y, al avisar que había vuelto a la vida, dejé claro que ese podía ser el último arranque, así que había que hacer un respaldo en algún lugar antes de que pasara algo.
Seis semanas después teníamos un reluciente AS/400 basado en la nube, y apagamos por última vez aquella vieja y pesada bestia, dándole sepultura.
Su tiempo final de servicio fue de casi 25 años.
Se podría decir que esta historia es poco probable o totalmente inventada, pero no lo veo así.
Para lograr algo en una organización grande, hay que hacer que la gerencia sienta tu dolor.
No es cinismo; así funciona el mundo.
Quien espere que la otra persona dé por su cuenta todos los pasos mentales necesarios para entender la situación se va a llevar una sorpresa fuerte.
Incluso a principios de los 90, ISDN no habría sido común fuera de oficinas sucursales.
Además, cuando aparece el tema de traffic shaping/QoS, se vuelve aún más difícil de creer.
Según entiendo, los routers Cisco 2500/2600 que usaba casi todo el mundo en esa época no soportaron esas funciones sino mucho después.
Quizá se referían a T1, pero tiene mucho aire de r/thathappened.
Por definición, los gerentes hacen un trabajo distinto al de quienes ejecutan.
Por ejemplo, ¿cómo podrías hacer que un gerente sienta el dolor de una base de código desastrosa?
En el trabajo teníamos un router Cisco 1604 ISDN configurado con marcado automático, en vez de dejarlo siempre conectado, para ahorrar costos.
Pero descubrimos que un IBM AIX con un paquete de navegador web instalado estaba llamando periódicamente a Big Blue cada hora para enviar telemetría, así que la red del laboratorio nunca podía bajar a estado inactivo.
Agregamos una regla de firewall en el router para bloquear esa maniobra discreta.
Incluso a finales de los 90, Microsoft, Sun y Novell no eran tan descarados como IBM con la telemetría.
El verdadero problema que se ve aquí es que el área de IT necesita autonomía para ejecutar, con cierto grado de independencia respecto del negocio, aquello que sabe que es correcto.
Al final, la confianza determina cuánta supervisión hay que tolerar dentro de una organización.
Donde estoy, si no es algo que afecte a los clientes, no necesitamos pedir permiso.
Si una máquina parece estar al límite o un plan SaaS se acerca a su tope, simplemente lo actualizamos.
A veces alguien pregunta por una nueva factura o por un aumento de costos, pero no tenemos que pasar por varios interrogatorios para poder avanzar.
La gente de traje debería pensar en las desventajas de un entorno donde hay que rogar permiso hasta para la tarea técnica más trivial.
¿Cuánta innovación está yéndose directo a un basurero en llamas por culpa de políticas de cambio complejas creadas en una torre de marfil hace más de 10 años?
¿No podríamos replantear la organización modelando al negocio como cliente del equipo de IT?
Si la empresa fracasa, la organización de IT tampoco tiene razón de existir, así que parece una forma de pensar mucho más simple.
Por eso cambia la relación costo-beneficio, así que hace falta comunicación.
Cuando veo respuestas del tipo “tu trabajo es respetar las decisiones de la jerarquía”, me recuerda cuánto siguen atrapadas las organizaciones empresariales en una mentalidad militar.
En el antiguo ejército prusiano, las misiones se comunicaban en torno a objetivos.
Algo como: “quiero lograr X, tú te encargas de Y y otra unidad hará Z”, y la ejecución quedaba en manos del oficial local, que era quien realmente veía el terreno y tenía el conocimiento necesario.
Además, si un oficial o suboficial se oponía a una orden de su comandante directo, también podía apelar a un nivel superior.
Sumado a un sistema de Estado Mayor en el que los oficiales de Estado Mayor debían tener experiencia de mando durante su formación y podían contrarrestar órdenes del comandante, se convirtió en un sistema fuerte y flexible, capaz de adaptarse a situaciones cambiantes.
Los oficiales no dudaban en discutir con sus superiores, escalar el tema o, si realmente lo consideraban necesario, rechazar una orden.
Eso genera acuerdo y participación de los rangos inferiores.
Es un enfoque en el que las decisiones se toman en el nivel más bajo posible.
En la era moderna perdió algo de popularidad, pero hasta donde sé ningún ejército opera puramente bajo la idea de “tu trabajo es obedecer las decisiones jerárquicas”.
Por ejemplo, libros como Extreme Ownership.
Quizá estoy siendo demasiado malicioso, pero con un liderazgo así creo que simplemente habría buscado otro trabajo y dejado que todo el barco se hundiera.
Simplificándolo desde la perspectiva del liderazgo: supongamos que cada año llegan 100 propuestas parecidas y cada una cuesta 1 millón de dólares.
Entonces, incluso dejando de lado amortizaciones o juegos fiscales, eso son 100 millones de dólares de costo puro al año.
Incluso para un banco es mucho dinero, y hay que gastarlo estratégicamente, no desperdiciarlo.
En ese esquema, hacer que el liderazgo sienta el dolor y entienda de manera instintiva por qué este millón de dólares en particular está bien gastado es, en cierto sentido, una estrategia saludable para el liderazgo, para IT y para el negocio.
También está el hecho de que los ejecutivos administran el tiempo, el personal, los costos y demás recursos finitos de la empresa.
Claro que, en general, no son especialmente buenos en eso, y desde la perspectiva de la empresa la opción puramente racional sería pagarles una compensación menos lujosa, más parecida a la de un empleado común.
Pero no decide “la empresa”; deciden personas, y ahí entran juegos políticos, incentivos e intereses propios.
Los ejecutivos controlan el flujo de información, decisiones, recursos y dinero, así que actúan como parásitos que extraen una porción excesiva de la empresa huésped.
Resolver este problema queda como ejercicio para el lector.
Si solo escucharon “predecimos que la línea estará saturada al 50% alrededor de la fecha X”, entonces IT realmente lo explicó mal.
Nosotros sabemos que, en esta tecnología, 50% de saturación implica demoras para los clientes o errores de conexión.
Entonces habría que decir: “prevemos que alrededor de la fecha X los clientes empezarán a tener problemas de conexión”.
Si se sabe que el límite del 100% es un valor teórico posible solo en condiciones ideales, entonces hay que hablar en función del límite realmente utilizable.
Para que la gente tome decisiones informadas, hay que darle la información correcta; y si a IT le pagan por entender la tecnología, también es trabajo de IT comunicar esas características de manera que la gente de traje pueda entenderlas.
Por supuesto, quizá hicieron lo mejor posible, pero por lo que se lee, parece que solo enviaron memos sin esa información.
No entiendo muy bien que la expresión “50% de uso” se use como si fuera abrir una llave de agua a la mitad.
Si la carga se concentra en picos sobre una sola tubería, ¿no se producirán de todos modos degradaciones intermitentes del rendimiento?
Según la distribución, la proporción de tiempo con una “mala experiencia” subiría bruscamente, así que incluso con 60% parecería difícil de soportar.
En comparación, es como si un bar decidiera tener un solo mesero basándose únicamente en la demanda promedio, justo cuando se acerca la noche del viernes.
Eso es justamente lo que dice la fórmula de Kingman.
“Cuando el uso superó el 50%, el equipo de IT volvió a proponer pedir ISDN. Y volvió a ser rechazado, con la instrucción de no volver a preguntar hasta que el uso estuviera cerca del 100%.”
Esto se parece mucho a cómo las autoridades percibieron el COVID.
Parece que los responsables miran las tendencias existentes, no logran hacer ningún tipo de pronóstico y solo reaccionan cuando el desastre ya está encima.