Hay una idea muy instalada sobre qué le falta a un desarrollador para «crecer»: que aprenda de negocio, que entienda el contexto, que piense estratégicamente. Suena bien y es casi inútil como consejo, porque no dice qué hacer el lunes.
Lo que efectivamente le cambia el trabajo a quien construye no es una comprensión general del negocio. Son cinco movimientos concretos de conversación, que se pueden describir, practicar y usar de inmediato.
Por qué esto le toca a quien construye y no solo a su jefe
Existe la creencia de que el desarrollador debería poder concentrarse en construir mientras alguien más se ocupa de las conversaciones. Sería razonable y no ocurre en ninguna empresa real.
El desarrollador es quien recibe el pedido informal en el pasillo, quien contesta cuando el área usuaria pregunta por qué algo no anda, quien tiene que decir si algo está listo, y quien queda expuesto cuando una fecha no se cumple. Su jefe no puede estar en todas esas conversaciones, y aunque pudiera, sería peor: el que sabe es él.
La consecuencia es incómoda: el trabajo de un desarrollador se juzga tanto por lo que construye como por lo que dice sobre lo que construye, y solo lo primero se enseña.
Los cinco movimientos
1. Entregar una estimación con estructura
No un número: un rango, los supuestos que lo sostienen, y qué pasa si un supuesto se cae. Es la diferencia entre una cifra que se regatea y una conversación sobre condiciones, que es una conversación mucho más fácil de tener.
Y tiene un efecto secundario valioso: obliga a explicitar dependencias que uno tenía en la cabeza. Muchas veces, al escribir los supuestos, uno descubre que la estimación estaba mal.
2. Preguntar para qué antes de construir
Una sola pregunta —«¿qué vas a hacer con esto cuando lo tengas?»— revela si el pedido es la punta de un proceso o una necesidad aislada. Cuesta treinta segundos y evita semanas de trabajo que nadie va a usar.
Hacerla no es cuestionar al que pide. Es lo contrario: es la señal más clara de que uno quiere que le sirva.
3. Explicar un problema técnico por sus consecuencias
La regla es simple: decir primero qué significa, después por qué pasa. Nadie fuera del equipo puede evaluar una causa técnica; todos pueden evaluar una consecuencia.
«Hay un problema de concurrencia en el módulo de stock» no le sirve a nadie. «Si dos personas cargan al mismo tiempo, el stock puede quedar mal, y eso ya pasó dos veces este mes» le sirve a todos, y recién después conviene explicar por qué.
4. Decir que algo no está listo
Es el movimiento más difícil y el que más credibilidad construye. La versión que funciona no es «no está», sino qué falta, cuánto falta y qué se puede hacer mientras tanto.
La tentación es decir que está y terminar en la noche. Eso funciona una vez. La segunda, alguien descubre que lo que se entregó no estaba realmente terminado, y a partir de ahí todo lo que uno diga se revisa.
5. Dejar rastro sin que cueste
Anotar quién pidió, quién autorizó y qué se acordó. Dos renglones en el ticket, en el momento, no después.
Parece burocracia y es protección personal: a los tres meses nadie se acuerda de la conversación, y el que no tiene el rastro pierde la discusión aunque tenga razón.
Los tres errores que más caros salen
Vale mirarlo también por el lado del error, porque son tres y se repiten en todas las empresas.
Contestar la pregunta técnica que no le hicieron
Alguien pregunta cuándo va a estar y recibe una explicación de por qué es difícil. Es una respuesta honesta y es la equivocada: quien preguntó necesita una fecha para organizarse, y lo que escucha es que no la va a tener.
La regla es contestar primero lo que se preguntó, con una sola frase, y recién después agregar el contexto si hace falta.
Aceptar en la reunión lo que se sabe que no se puede
Pasa por evitar la incomodidad de discutir delante de otros. Se acepta el plazo, se sale de la reunión, y el problema queda entero pero ahora con un compromiso encima. Y quien aceptó va a ser el que quede mal cuando no llegue.
La salida no es negarse en el momento: es «necesito revisarlo y te contesto hoy a las cinco». Nadie discute eso, y da el tiempo de armar la respuesta con estructura.
Resolver el pedido informal sin registrarlo
El pedido del pasillo, hecho de palabra, resuelto en veinte minutos porque era chico. Al final del mes hay veinte de esos, son dos jornadas completas, y no figuran en ningún lado. El equipo aparece como que produjo menos de lo que produjo, y nadie puede demostrar lo contrario.
Registrar no significa negarse. Significa hacerlo y anotarlo, para que el trabajo exista.
Lo que no hace falta
Vale decir también qué no está en esta lista, porque se recomienda seguido y no ayuda.
No hace falta aprender a vender. Un desarrollador no tiene que convencer a nadie de comprar nada. Tiene que ser claro y confiable, que es otra cosa y más fácil.
No hace falta volverse extrovertido. Los cinco movimientos los ejecuta igual de bien alguien callado. De hecho suele ejecutarlos mejor, porque no improvisa.
No hace falta entender el negocio en profundidad. Alcanza con saber preguntar. Quien pregunta «¿qué vas a hacer con esto?» aprende del negocio de a poco y sin estudiar nada.
Cómo se practica
Igual que cualquier oficio: de a una situación por vez, con devolución.
La forma más barata de empezar, sin ninguna formación, es elegir un solo movimiento por mes y usarlo deliberadamente. El primer mes, entregar todas las estimaciones con supuestos escritos. El segundo, preguntar «para qué» en todos los pedidos nuevos. El tercero, explicar los problemas por sus consecuencias.
Uno por vez, porque intentar los cinco a la vez no funciona: bajo presión uno vuelve a lo automático, y lo automático solo cambia con repetición.
Lo que cambia a los seis meses
El cambio no es que las reuniones se vuelvan agradables. Es que el equipo empieza a ser consultado antes en vez de después.
Cuando un desarrollador pregunta para qué, explica por consecuencias y entrega estimaciones que se sostienen, el área usuaria descubre que hablar con él temprano le ahorra problemas. Y entonces empieza a aparecer antes: cuando todavía se puede opinar sobre el alcance, no cuando ya está decidido.
Esa es la diferencia real entre un equipo que recibe encargos y uno que participa de las decisiones. No se consigue reclamando participar; se consigue con estos cinco movimientos, sostenidos.
Por dónde empezar mañana
Si tuviera que elegir uno solo de los cinco movimientos para probar esta semana, elija el segundo: preguntar «¿qué vas a hacer con esto cuando lo tengas?» en el próximo pedido que le llegue.
Es el más barato —treinta segundos—, el que menos riesgo tiene de salir mal, y el que más rápido devuelve algo visible. En una proporción alta de los casos la respuesta va a revelar un paso del proceso que el pedido no mencionaba, y esa revelación es lo que convence de que el resto de la lista también vale.
Es exactamente el contenido del plan de Equipos de desarrollo. Escríbanos si quiere trabajarlo con su equipo.
