Para desarrollar software con eficacia no basta con saber programar muy bien y hacer un código sostenible con buenas baterías de test. Resulta que es imprescindible ponerse en el pellejo de los stakeholders. Uno tiene que pensar a ratos como programador y a ratos como gerente de la empresa o inversor. Hay que ser capaces de entender y hablar el idioma del negocio para dar las mejores soluciones en tiempo, calidad y coste. Para resolver un problema con software hay mil soluciones posibles, muchas de ellas técnicamente excelentes, pero no todas son plausibles desde el punto de vista del negocio. Una solución puede ser excelente técnicamente y a la vez una ruina para el negocio.
Me resulta muy práctico comparar lo que pasa en nuestro día a día con los talleres de mecánica o la construcción de edificios. Hace unos días llevé el coche al taller porque se le fundían los faros con frecuencia. Lo miraron y me dieron un presupuesto de unos 100 euros por hacer varios arreglos. Lo acepté y cuando lo estaban terminando me llamaron a decir que habían visto otra avería que era importante arreglar y que eran 200 euros. Parecía importante así que les dije que la arreglasen. Después me llamaron para decir que al desmontar cierta pieza se dieron cuenta de que había que cambiar otra cosa, y que eran 300 euros más. Entonces ya pregunté qué implicaciones tenía no arreglar esa avería porque mi presupuesto se estaba terminando. Me hubiera gustado que ellos mismos me dijesen qué tan grave era la avería y si podía esperar unos meses para ser reparada, pero lo tuve que preguntar yo. Como me dijeron que era muy importante para la seguridad les dije que fueran adelante. Cuando estaban trabajando en eso me llamaron a decir que tenían que cambiar la transmisión. El coste total ya va por más de 1000 euros. Entonces les dije, “si esta no es la última cosa que hay que arreglar, te dejo el coche en el taller, te lo quedas tú y yo me compro otro”, porque yo ¡lo había llevado por unas bombillas! Está claro que los mecánicos estaban haciendo su trabajo, descubriendo problemas y solucionandolos, seguramente haciendo el mejor trabajo técnico posible con la mayor velocidad posible. Lo que seguramente no hizo ningún mecánico es pararse a pensar si yo tenía dinero ahorro para un gasto inesperado de 1000 euros. Se arriesgaron a que no les pagase, o incluso a que les dejase el coche allí abandonado (no lo hubiera hecho, pero hay gente que puede llegar a verse obligada a hacerlo).
Esto mismo nos pasa en los proyectos de software cuando hacemos tareas como grandes rediseños, refactorizaciones o ampliaciones de la cobertura de test. Si no conocemos las limitaciones de tiempo ni de dinero, podemos refactorizar hasta el infinito, con el máximo cuidado y profesionalidad técnica, pero con consecuencias negativas. Siempre siempre siempre hay limitaciones, otra cosa es que las conocemos. Cuando no las conozco me ocupo de averiguarlas. Necesito conocer cuáles son las expectativas y los planes de negocio de la gente que pone el dinero, que son las personas con mas “skin in the game”. Si no tenemos en cuenta los recursos y la estrategia de negocio de los stakeholders, puede que nuestro trabajo técnico sea totalmente contraproducente. Es imprescindible conocer los planes de negocio, las fechas de lanzamiento, el coste de oportunidad de lo que dejamos de hacer o lo que se retrasa, el presupuesto que tienen para el trabajo, etc. Desde mi punto de vista es muy importante que el rol de project manager se asegure de que todo el equipo de desarrollo cuenta con esta información.
Desgraciadamente no podemos esperar que los stakeholders empaticen con quienes programamos, porque la curva de aprendizaje para que nos comprendan sería demasiado grande. Cuando desde negocio lleguen peticiones que sabemos que van a ser nefastas para el producto, en el medio y largo plazo, también es muy importante que lo sepamos transmitir. El típico ejemplo es cuando meten prisa y piden que hagamos una funcionalidad sin ningún tipo de test automático, porque no hay tiempo. Cuando incurrimos en cualquier tipo de deuda técnica, en general, es nuestra obligación saber explicar al negocio las consecuencias que va a tener, la manera en que va a impedir al negocio en el futuro, que va a costar dinero. Siempre que somos capaces de transmitir estos problemas utilizando el lenguaje del negocio, la gente se piensa dos veces las cosas y se acaban tomando mejores decisiones. Si volvemos al ejemplo del taller, no me gustaría que si rechazo un presupuesto para la reparación de una avería, que va a suponer un accidente mortal, no me avisaran de la gravedad de la misma.
No podemos programar a ciegas, tenemos que hacerlo siempre como si el dinero que se invierte en el desarrollo fuera nuestro. ¿Harías la tarea técnica X si la pagases de tu bolsillo?, ¿dejarías de hacer la tarea Z si tuvieras que mantener el desarrollo con tu dinero en los próximos 5 años?