Qué le falta a los equipos de desarrollo de software?

Dado el camino por el que me ha llevado la vida, no es raro que alguien me pregunte qué distingue a un equipo de desarrollo de software. La gente usualmente espera que la discusión se centre en estructuras y tamaños de equipo, SCRUM vs Kanban vs Waterfall vs ShapeUp, Git Flow, si un lenguaje es más chido que otro, pero la verdad es que he encontrado que mucho de eso da igual. He visto equipos que funcionan muy bien con y sin cualquiera de esas cosas.

El problema más recurrente que veo en equipos es que no saben si están resolviendo los problemas correctos. Peor tantito, muchas veces no saben que no saben.

Suena medio estúpido, no? Claro que estamos resolviendo el problema correcto. Hacemos el feature que nos pidió el VP o el CEO, o el PM, o los de UX o los de Servicio al Cliente. Creamos lo que nos pide Ventas, o Legal, Cumplimiento, o el hermano del dueño. La voz que más comúnmente falta en esas discusiones es la de ingeniería.

Resuelve el problema correcto

Un buen equipo de ingeniería no solo ejecuta lo que le piden, sino que también contribuye a la discusión. Negocia alternativas. Llega a mejores soluciones. Sabe decir que no. El CEO, Legal, Servicio al Cliente, o cualquiera de las otras contrapartes que mencioné no saben programar. No conocen las limitaciones o fortalezas de los sistemas, frameworks o lenguajes que usamos. No tienen la experiencia que tenemos nosotros. Si como equipos de ingeniería no participamos en esas discusiones o lo hacemos solo de forma pasiva, casi puedo asegurarles que no estarán ni resolviendo los problemas correctos ni resolviéndolos de la mejor manera.

Una de las cosas más chidas de ser desarrollador de software es todo lo que tienes que aprender sobre el negocio en el que estás trabajando. Los desarrolladores más exitosos, en mi opinión, no solo dominan la programación, sino que también entienden profundamente el negocio y cómo fluye la información en él. Te tienes que poner la cachucha de la chamba que estás afectando. A veces tienes que ser medio contador, medio gerente, medio banquero, medio abogado, medio agente de servicio al cliente. Si no comprendes bien el problema que estás resolviendo, no vas a poder aportar soluciones realmente valiosas.

Una anécdota

Hace años trabajé para una empresa que quería crear software para que su equipo de contadores pudieran hacer más rápido su chamba. Cuando yo llegué, la mayoría de las funcionalidades de la aplicación las decidía un gerente de contabilidad que lideraba a un equipo enorme de contadores. Después de joder mucho, conseguí permiso de que los contadores y sobre todo los ingenieros participaran en el proceso de definición del producto.

Intentamos varias maneras de hacer entender a los ingenieros el problema que estaban atacando pero lo que mejor funcionó fue hacer que cada ingeniero físicamente se fuera a sentar con los contadores durante un mes. Eran épocas prepandémicas y todos estábamos en la misma oficina y se podía implementar fácil. Fue increíble ver que todas y cada una de las personas que mandamos a eso regresaron después de ese mes con 20 ideas de cosas que mejorar.

Cuando recién iniciamos ese programa, me acuerdo que un ingeniero vio que los contadores, para hacer su conciliación, donde tienen que hacer match entre los movimientos en el estado de cuenta vs las facturas emitidas y recibidas, abrían el estado de cuenta en pdf en su computadora y sacaban una regla. Literal una regla como en secundaria, la ponían en su pantalla y la usaban para no perder el renglón en el que iban. Ese ingeniero (y varios otros que vieron lo mismo en lo que lo automatizamos), regresó frustrado y lo que le sigue nomas de ver lo ineficiente que era el contador. Llegó casi gritando todas las cosas que les podíamos automatizar y que podíamos ayudarles.

La parte más interesante de ese aprendizaje fue que ese tipo de problemas no los había visto el gerente de contabilidad, ni los contadores. No eran parte del roadmap. Para ellos era simplemente el cómo hacían ese trabajo. Metimos muchísimas ideas de ese tipo a la planeación (que no fue fácil) y resultaron ser de las cosas que más ayudaron a subir la productividad de los contadores.

Faltaba el ojo de un ingeniero para poder ver que ahí había un área de oportunidad. Tenía que entender el proceso, verlo paso a paso, experimentar el tiempo que se llevaban en hacerlo, y ser capaz de sentir enojo de porqué las cosas se hacían, entre comillas, mal. Combinada esa experiencia con los conocimientos técnicos, las soluciones salían casi en automático.

Pa concluir

Mi recomendación, el mensaje que me gustaría dejarles es que piensen si realmente entienden lo que están tratando de resolver. Si saben lo suficiente de las frustraciones de sus usuarios, sean sus clientes o sean los agentes de servicio, o los vendedores, o las otras personas a las que les están ayudando en su trabajo.

Si no están seguros o si luego luego dijeron que sí, piensen en cuándo fue la última vez que hicieron el proceso de registro de cuenta, o intentaron hacer las operaciones más comunes de su usuario. No sé, cuándo fue la última vez que el equipo de cumplimiento les explicó el porqué de un mensaje, o de un reporte. Cuándo fue la última vez que platicaron con las personas que usan las partes del sistema que ustedes programan? Que repasaron cuál es el flujo de la información y preguntaron porqué se hace así? En mi experiencia, la respuesta suele ser: uuy ya tiene rato, o peor tantito, nunca lo he hecho.

A eso es a lo que me refiero y es algo que comúnmente veo que falta en los equipos. Personalmente, y para equipos de desarrollo de producto, un ingeniero que solo se preocupa en su código y no en el producto, no me sirve.