Antes de que el software se convirtiera en mi carrera, pensaba que iba a dedicarme a la música. Programaba desde niña, pero la música era lo que perseguía con suficiente seriedad como para empezar la universidad estudiándola, y hubo una época en la que practicaba unas ocho horas al día solo para mantener el ritmo.
Mucho de lo que aprendí durante aquellos años se ha quedado conmigo. La práctica hace que ciertas decisiones estén disponibles en el momento porque ya has pasado cientos de horas aprendiendo qué ocurre cuando las tomas. La teoría te da más opciones una vez que la entiendes lo bastante bien como para dejar de pensar en ella conscientemente.
La lección a la que vuelvo más a menudo es una que escuché de varias formas durante ese tiempo: no puedes romper las reglas hasta que las conoces. En música, se oye la diferencia entre alguien que cae en una nota porque perdió la armonía y alguien que toca fuera de ella deliberadamente porque sabe qué quiere hacer con eso.
Necesitas escuchar la música que la rodea para distinguirlo. La nota puede sonar extraña cuando llega y cobrar sentido un momento después por el lugar al que la lleva el músico. No esperaba que esa distinción resultara tan útil cuando pasé al software.
Aprender el marco forma parte de aprender el trabajo
Empecé mi carrera en software durante la era Dotcom, así que he tenido tiempo de sobra para ver metodologías ir y venir. Algunas se vuelven a empaquetar con nombres nuevos. Otras se convierten en práctica estándar durante el tiempo suficiente para que alguien acabe construyendo una carrera prometiendo arreglarlas.
Los marcos me han enseñado mucho. Un método compartido da acceso a lo que otras personas han aprendido sin obligar a todo el mundo a repetir los errores que lo produjeron. También da a un equipo una forma de hablar sobre el trabajo cuando sus integrantes llegan con experiencias distintas.
Las cosas se vuelven extrañas cuando el marco es más fácil de evaluar que el trabajo al que debía ayudar. Un equipo puede mantener su tablero al día y reportar sus métricas mientras una decisión importante lleva semanas esperando. Todos pueden ver el estado del trabajo sin que nadie resuelva lo que lo está bloqueando.
Algo marcado como terminado puede seguir siendo inutilizable de la forma que todos daban por supuesta. El equipo ha cumplido el proceso, pero ahora alguien tiene que averiguar cómo entregar lo que se necesitaba. He trabajado en startups y en empresas de miles de millones de dólares, y he visto versiones de ese problema en ambas. Después de suficiente tiempo alrededor de él, una descripción ordenada del trabajo deja de ser evidencia suficiente de que el proceso está ayudando a hacerlo.
La experiencia cambia lo que notas
Al principio de una carrera, seguir una regla de cerca suele ser una decisión sensata porque todavía no sabes de qué fallo te está protegiendo. He cometido suficientes errores para tener un respeto saludable por convenciones que parecían innecesarias justo hasta que entendí por qué alguien las introdujo.
La experiencia también te da ejemplos en la dirección contraria. Una salvaguarda puede sobrevivir mucho después de que cambie el riesgo. Un proceso diseñado para un tipo de equipo se reproduce en una organización distinta porque la gente reconoce su nombre, aunque allí no existan las condiciones que lo hacían útil. Saber implementarlo no te dirá si pertenece a ese lugar.
El software ofrece versiones interminables de este problema. Una abstracción puede hacer un sistema más fácil de razonar y luego aplicarse con tanto entusiasmo que entender la cosa sencilla que hay debajo se vuelve más difícil de lo que nunca necesitó ser. El principio era útil; aplicar más cantidad de él no necesariamente ha ayudado.
Ahora me interesa más qué se supone que debe ayudar a conseguir un método en una situación concreta. Dos personas con experiencia pueden entender el mismo marco y discrepar sobre si utilizarlo. Aun así tienen que explicar en qué esperan que ayude y qué costaría usarlo. Conocer el método les da algo con lo que trabajar, pero no decidirá la cuestión por ellas.
Las empresas tienen reglas que nadie recuerda haber elegido
Las empresas heredan supuestos de una forma muy parecida. El crecimiento suele discutirse como expansión, así que un propietario que quiere una empresa más pequeña puede encontrarse teniendo que explicar esa ambición. La eficiencia suele significar obtener más producción con la misma cantidad de trabajo, con poca discusión sobre qué otra cosa podría hacer posible el tiempo ahorrado.
Cada vez estoy menos dispuesta a aceptar un objetivo empresarial conocido sin preguntar por qué lo perseguimos. El crecimiento puede dar a una empresa los recursos para hacer algo que antes no podía permitirse. Esa es una razón para considerar la expansión. Aun así necesitamos entender qué quiere hacer el propietario con esos recursos y si gestionar una empresa más grande es un compromiso que quiere asumir.
La estandarización merece el mismo examen. Eliminar variación puede hacer un proceso más fiable, pero parte de la variación existe porque la gente está tratando con circunstancias diferentes. Antes de exigir que todo el mundo trabaje de la misma manera, quiero saber qué están haciendo esas diferencias. La familiaridad con una práctica no responde esa pregunta.
La IA y la automatización hacen que algunas de estas decisiones sean más difíciles de ignorar. Podemos automatizar una tarea administrativa repetitiva y devolverle a alguien varias horas de su semana. También podemos aumentar la cantidad de trabajo que esperamos de esa persona porque la tarea ahora lleva menos tiempo. La automatización puede funcionar exactamente como estaba previsto en ambos casos. «Así son los negocios» puede terminar una conversación que sonaría muy distinta si habláramos claramente de lo que esa decisión exige a la persona afectada.
ShanVic llegó después de aprender muchas respuestas de otras personas
ShanVic surgió del trabajo que ya estábamos haciendo juntas. Para entonces habíamos pasado suficiente tiempo dentro de empresas y estructuras de gestión distintas como para saber que los problemas que nos importaban rara vez se quedaban dentro de los límites que esas estructuras les daban.
Un problema de software resultaba involucrar un proceso que nadie había reconsiderado. Examinar ese proceso podía revelar una decisión que nadie tenía autoridad para tomar. Cambiar solo el software dejaría al equipo esperando la misma respuesta a través de una interfaz distinta, mientras que las personas responsables del software podían decir razonablemente que habían hecho lo que se les pidió.
The Cubed Method™ nos dio una forma de trabajar directamente con esas relaciones. People, Processes y Products se están cambiando mutuamente de forma constante. Necesitamos entender lo suficiente de esas relaciones para ver cuándo una mejora propuesta dejará un problema sin resolver o creará más trabajo en otra parte.
Ese enfoque debe mucho a los marcos y disciplinas que lo precedieron. Los años utilizándolos nos ayudaron a reconocer cuándo un método daba a la gente una forma útil de trabajar y cuándo lo seguían principalmente porque era lo esperado. Las personas con experiencia a menudo ya hacían ajustes que el proceso formal no reconocía, y queríamos una forma de examinar esas decisiones como parte del trabajo.
Saber por qué te da más opciones
Una de las cosas que me gustaban de la teoría musical era que aprender más no hacía que la música pareciera más pequeña. Me daba más formas de entender lo que escuchaba y más opciones sobre lo que podía hacer después. Creo que una buena práctica empresarial debería hacer lo mismo.
Un marco debería ayudarme a entender las consecuencias de una decisión lo bastante bien como para tomarla deliberadamente. Cuando nos apartamos de su orientación, deberíamos poder explicar qué esperamos ganar y qué riesgos estamos aceptando.
Hay reglas que agradezco que alguien me enseñara antes de tener suficiente experiencia para apreciarlas. También he seguido reglas hasta entender lo suficiente para ver por qué ya no encajaban con el trabajo que tenía delante. La música me dio una forma de pensar en eso mucho antes de que tuviera una empresa o una metodología, y todavía vuelvo a ella cuando una regla conocida nos da una respuesta que no termina de encajar con lo que intentamos construir.