El reinicio lo resolvió. El problema sigue ahí.
Un incident que se cierra sin causa reconstruida no es un episodio aislado. Cómo leer AWR, ASH y change log en frío antes de que llegue el segundo fallo.

Liderazgo técnico y project management IT: decisiones, equipos, método y consultoría, con historias reales y números de 30 años de proyectos.
Esta sección cuenta la parte del oficio que no está en los planes de ejecución: las decisiones, los equipos, el método. Es el espacio del liderazgo técnico, donde personas, sistemas y decisiones deben funcionar juntos.
He visto a project managers hacer llorar a desarrolladores senior en una reunión. He visto equipos brillantes destruidos por PMs que confundían la autoridad con el autoritarismo. He visto software entregado “a tiempo” que no funcionaba, y proyectos de millones de euros acabados en nada.
Y he visto lo contrario: equipos pequeños, autónomos, respetados — que construían sistemas sólidos en una fracción del tiempo y del presupuesto.
La diferencia nunca fue la tecnología. Siempre fue el método.
Después de treinta años en este oficio, hay algo que tengo claro: las personas no dan lo mejor de sí cuando tienen miedo. Lo dan cuando tienen confianza.
Confianza en el equipo. Confianza en el proceso. Confianza en que si se equivocan, no serán castigadas — serán ayudadas.
El project manager que funciona no es el que controla, aterroriza y cuenta horas. Es el que:
Mi enfoque es Scrum — pero Scrum hecho en serio, no la liturgia de los post-it.
El Scrum que funciona se basa en un pacto: transparencia radical, responsabilidad compartida y autonomía en el “cómo”. El PM define el qué y el por qué. El equipo decide el cómo. Porque quien escribe el código sabe mejor que nadie cómo escribirlo.
Y este pacto funciona aún mejor con el smart working. El daily standup? 15 minutos en una llamada. La sprint review? Pantalla compartida con el cliente, que ve el software — no las diapositivas. La retrospectiva? Una hora en la que el equipo dice la verdad, porque no tiene al PM a dos metros mirándolo fijamente.
Mido pocas cosas, pero las mido bien:
| Métrica | Qué dice |
|---|---|
| Velocity | Cuánto entrega el equipo por sprint |
| Lead time | Cuánto pasa desde la solicitud hasta el lanzamiento |
| Bug escape rate | Cuántos defectos se escapan a producción |
| Sprint goal success | % de objetivos de sprint logrados |
| Team happiness | Cómo se siente el equipo — la métrica más importante |
La última — team happiness — es la que los PMs tradicionales nunca miden. Un equipo feliz no es un equipo que se divierte. Es un equipo que se siente respetado, escuchado y valorado. Y un equipo así produce más. No porque trabaje más horas. Porque trabaja mejor.
Historias reales, números concretos y lecciones aprendidas. Nada de teoría de manual. Solo lo que he visto funcionar — y lo que he visto fracasar.
Hablo de inteligencia artificial aplicada al workflow, de consultoría IT y sus costes ocultos, de smart working como ventaja competitiva. Cada artículo nace de una experiencia real — la mía.
No hacen falta revoluciones. Hacen falta decisiones precisas, implementadas con método.
Y la capacidad de decir “no” a quien te vende complejidad cuando la solución es simple.

Datadog y Dynatrace muestran síntomas, no causas. Cómo explicar al board por qué la observability moderna no basta sin un lector competente.

Un incident que se cierra sin causa reconstruida no es un episodio aislado. Cómo leer AWR, ASH y change log en frío antes de que llegue el segundo fallo.

Por qué añadir CPU, RAM o IOPS rara vez resuelve un database mission-critical que va lento — y qué mirar antes de firmar el presupuesto.

Un Commodore 64, un programa modificado para insultar al padre y una puerta cerrada con llave: cómo empieza una carrera de 30 años en ingeniería de bases de datos.

La historia de los Three Amigos de UML y RUP: cómo Booch, Rumbaugh y Jacobson, de rivales, unificaron el object-oriented modeling. Y lo que queda hoy.

Gestión de proyectos: 5 reglas observadas en equipos que aguantan bajo presión. Psychological safety, bus factor, outcome vs output, knowledge transfer.

AI Manager: el rol que gobierna el impacto de la inteligencia artificial sobre arquitecturas, procesos y personas. Reflexiones desde 30 años en IT.

Pagos a 60-90-120 días en consultoría IT italiana: comparación con las reglas europeas. DSO, directiva 2011/7/UE y estrategias para freelancers IT.

Pendolarismo en Roma: Brompton eléctrica vs coche. 18 minutos vs 50, 35€ de aparcamiento ahorrados. La elección de movilidad sostenible, datos reales.

Smart working en consultoría IT: análisis económico y estratégico del trabajo remoto. Números reales, KPIs, presenteísmo y productividad vs oficina.

Gestión de proyectos con AI y GitHub: transformar un proyecto caótico en workflow medible con issue tracking, code review e inteligencia artificial.
Standup meeting Scrum: por qué solo los 15 minutos los hacen funcionar. Timeboxing, parking lot y reglas prácticas del daily meeting que aguantan.

La técnica Yes-And del teatro de improvisación aplicada a la gestión de conflictos en equipos IT. Caso real de una reunión que iba a estallar.

Caso real de gestión de proyectos: cliente asegurador gasta 4 millones en consultoría IT y obtiene cero software funcionando. Lecciones vendor lock-in.
Empieza a escribir para buscar…
Selecciona un resultado para ver la vista previa