Es escuchar.
He aprendido a base de errores que lanzarse a programar sin entender el contexto es la forma más rápida de hacer trabajo que luego hay que rehacer. Y rehacer trabajo en un equipo no solo cuesta tiempo. Cuesta confianza.
Lo primero que necesito entender es el problema real, no el problema que me describen. Muchas veces lo que el cliente o el equipo pide no es exactamente lo que necesitan. Hay que hacer las preguntas incómodas antes de abrir el proyecto para editar.
Lo segundo es mapear quién hace qué. En equipos pequeños hay roles difusos. Alguien hace de developer, de diseñador y de gestor de proyectos al mismo tiempo. Si no tienes claro quién decide qué, cada conversación se convierte en una reunión de consenso que no llega a ningún sitio.
Lo tercero es acordar cómo nos comunicamos. No el canal, eso es lo de menos. Sino la frecuencia, el nivel de detalle y quién necesita saber qué. He visto proyectos hundirse no por problemas técnicos sino porque nadie sabía en qué estado estaba el trabajo del resto.
Lo cuarto es definir qué es "terminado" antes de empezar. Sin una definición clara, cada tarea se convierte en un debate. ¿Terminado es que funciona en local? ¿Que pasó #testing? ¿Que está en producción? Parece obvio y casi nunca está acordado.
Con estas cuatro cosas claras antes de escribir la primera línea de código, los proyectos van diferente. No perfectos pero sí con menos fricciones evitables.
- ¿Cuál de estos cuatro pasos sueles saltarte cuando arrancas un proyecto nuevo?
- ¿Tienes algún ritual propio cuando entras en un equipo o proyecto que no conoces?
- ¿Qué es lo que más tiempo te ha costado aprender sobre trabajar en equipo?
Lo que cuentan las diapositivas
Escuchar primero
La pregunta con la que empiezo siempre es la misma: ¿qué necesitan de verdad? Entre el «lo antes posible», el «pero también» y el «necesito que», la conversación real está en lo que nadie ha ordenado todavía.
Mapear los roles
Quién desarrolla, quién diseña y quién gestiona. Saber por dónde pasa cada decisión evita la mitad de los problemas que luego parecen técnicos.