En algún momento de nuestras vidas como desarrolladores de software vamos a encontrar a alguien del negocio pidiendo algo técnicamente imposible o que costaría tanto tiempo (dinero) y esfuerzo, que ante nuestros ojos técnicos no tiene sentido.
Así que: ¿cómo decimos manejamos esa expectativa?
Resistir el impulso
Es muy fácil sentir miedo en cualquier conversación y que nos pongamos a la defensiva cuando queremos proteger algo que consideramos valioso. En el escenario laboral, probablemente queramos proteger nuestra estabilidad de nuestros cargos o seguir trabajando sobre las funcionalidades que ya tenemos bajo control.
Lo desconocido causa miedo, así que quizás el primer impulso que tengamos sea responder NO de entrada: "eso no se puede hacer", "eso rompería todo lo que ya tenemos", "nos tomaría dos años reemplazar lo que ya existe".
Por eso, a pesar del primer impulso, necesitamos pausar y aproximarnos al problema con curiosidad y apertura. Las siguientes preguntas pueden servir de guía:
- ¿Qué problema estás tratando de resolver con eso que me propones?
- ¿Qué es lo que necesitas lograr sin pensar en la implementación?
- ¿Qué restricciones tenemos en tiempo y recursos?
- ¿Qué otras personas podrían estar involucradas en este problema, a las que se puede acudir para buscar más información?
- ¿Cuál es el punto de partida? ¿Hay algún avance, prueba de concepto o prototipo?
A veces el origen del miedo es la falta de información y ante este problema debemos llenar los vacíos preguntando.
No hagas una promesa si no puedes cumplirla
Trabajé para una empresa X, donde un compañero de trabajo, que voy a llamar "Juan", tenía un cargo muy alto y se encargaba de administrar varios equipos móviles a alto nivel. Cierto día le preguntaron cuánto tardaría mi equipo en completar una tarea muy grande, a lo que dio una cifra en meses (voy a decir 4, pero no recuerdo el número exacto), pero que aún así se quedaba corta para el tiempo real que yo creía que tomaría hacer ese trabajo.
Juan no había abierto el proyecto ni una sola vez, no tenía ni idea de cómo estaba estructurado, cuán acoplado estaba por dentro ni tenía idea de la baja cohesión de las clases. Además, no había considerado que el módulo en cuestión no tenía ni una sola prueba automatizada.
¿Con base en qué dio esa respuesta? En ese momento me sentí atrapado. ¿Con qué recursos voy a completar esta tarea? Me falta personal capacitado para enfrentarme a ella y no tengo tiempo suficiente.
Cuando le pregunté porqué se había comprometido su respuesta fue: "Ante estas iniciativas tan grandes, el negocio jamás va a aceptar la estimación real. Por eso hay que dar una fecha convincente y cuando se incumpla, solo hay que mamar gallo y pedir más tiempo. Una vez empezado es más barato terminar que dejarlo tirado."
Honestamente me sentí estupefacto. No podía creer lo que acaba de escuchar. Lo consideré deshonesto (y aún lo hago). En mi opinión, ante esa solicitud habría respondido algo como: "Puedo ver que esa necesidad es muy valiosa para el negocio, sin embargo, tal como lo describe parece tener una complejidad muy alta. Voy a revisarlo con el equipo, pero no quiero que se vaya con la expectativa de que es algo que se pueda hacer en poco tiempo".
Ofrecer alternativas siempre que sea posible
Llegar a una reunión simplemente con un "no se puede hacer" no es suficiente. En nuestro trabajo hay problemas y nosotros estamos mandados a traer soluciones.
Si es posible, fuera de la reunión con el cliente hay que hacer una estimación a alto nivel de la funcionalidad a realidad. Y, cuando algo es muy costoso o técnicamente muy complicado, trato de preparar al menos dos o tres alternativas antes de la siguiente conversación. No para esconder la complejidad, sino para que el cliente tenga opciones dónde moverse.
A veces una versión reducida del feature que resuelve el 80% del problema con el 20% del esfuerzo puede servir como solución temporal mientras se estudia el problema a profundidad y se implementa o se consigue la solución final.
Tengamos en cuenta que una opción muy válida puede ser adquirir una licencia para usar un producto de un tercero, en lugar de construir algo desde cero.
¿Cuál es mi rol para el negocio?
Recordemos que el cliente no pide cosas imposibles para complicarnos la vida. Las pide porque tiene una necesidad de negocio real y acude a nosotros porque somos precisamente nosotros quienes tenemos el conocimiento técnico para resolver el problema o, por lo menos, hacerles saber cuáles son las implicaciones técnicas de cierta solicitud.
Y tú, amigo lector, ¿te ha pasado algo así? ¿Hay alguna técnica que te haya funcionado bien para manejar estas conversaciones?
Top comments (0)