Y… todas las demás personas

No nos engañemos. Sigue estando vigente el estereotipo de las programadoras como personas solitarias, resolviendo complejos problemas mientras teclean febrilmente en un ordenador. Pero es un estereotipo, y la realidad, como casi siempre, es mucho más interesante.

También tenemos otro tópico, más frecuente por desgracia, en la que los equipos de desarrollo son vistos, y se ven a sí mismos, como meros ejecutores, sin voz ni voto, de las decisiones de negocio.

Una de las cosas que nos ha mostrado el movimiento ágil es precisamente que el desarrollo de software es una actividad eminentemente social, nunca individual, en la que el código es tan solo una parte más en la construcción de un producto o servicio. Y en la que el equipo de desarrollo forma parte integral del proceso.

Ese producto o servicio trata de satisfacer una necesidad de una cliente potencial de un cierto negocio. Negocio que debe generar los ingresos necesarios como para hacer sostenible el producto, y producir beneficios tras cubrir los gastos e inversiones necesarios.

Un negocio existe porque alguien ha detectado una necesidad y ha sido capaz de entender qué producto podría satisfacerla lo bastante bien como para convencer a inversoras para inyectar dinero y para convencer a clientes para usarlo y pagar por ello.

Convertir una idea en un negocio funcionando requiere del esfuerzo coordinado de muchas personas ejerciendo diversos roles y aportando infinidad de saberes. Como desarrolladoras tenemos que interactuar con gran parte de ellas y entender que nuestro trabajo no consiste en resolver un problema técnico: consiste en resolver un problema de negocio. En otras palabras: programamos para que nuestra empresa gane dinero.

El software es algo que la empresa necesita para poder desarrollar su actividad. Es cierto que puede contribuir de una manera especialmente importante por algo de lo que hemos hablado en otro momento: el software es plástico y adaptable, lo que permite plasmar ideas y prestaciones que serían imposibles de otro modo y que pueden ser clave para diferenciarse y competir con los otros cientos de empresas que se dedican exactamente al mismo negocio. Pero el software no es lo que la empresa vende, excepto que te dediques a eso. Lo que la empresa vende es un cierto producto o un cierto servicio y tiene que convencer al público de que el suyo es el más conveniente.

Cada vez que se desarrolla una prestación del software han tenido que participar analistas de negocio para identificar una demanda de la misma por parte de los clientes potenciales, y se ha tenido que valorar la posibilidad de darle respuesta, examinado los beneficios potenciales y los costes previsibles. Ha sido necesario que expertas averigüen qué ofrecer para satisfacer esa necesidad. Especialistas en experiencia de usuario que diseñen la forma en que esa prestación sea fácil de entender y usar para el público. Personas de marketing que elaboren un plan para darla a conocer y divulgarla. Y, por supuesto, desarrolladoras para implementarla. Y seguro que me dejo más personas necesarias.

Todo este proceso requiere negociaciones y discusiones. No basta con descubrir una necesidad que nuestro producto podría satisfacer e implementarla. ¿Es relevante? ¿Cuánto nos va a costar? ¿Es mejor esa idea o esta otra? ¿Tenemos la capacidad para ofrecer esa prestación? ¿Nos va a diferenciar de la competencia? ¿Y cómo la vamos a hacer más atractiva? ¿Qué requisitos legales y regulatorios debemos cumplir?

Desde el punto de vista de un equipo de desarrollo cada prestación nueva puede requerir un distinto tipo de esfuerzo. En muchos casos, una prestación implica básicamente añadir el código necesario para ponerla en manos de sus potenciales usuarias. Otras veces, requiere realizar cambios significativos en la infraestructura que le da soporte. O iniciar un sistema nuevo. O el cambio nos pide reestructurar equipos y proyectos.

Por supuesto, todos estos elementos, y muchos más, entran en juego en la negociación. El equipo de desarrollo no puede hacer lo que le venga en gana, ni el equipo de negocios puede esperar que sus peticiones se conviertan en realidad tal cual las imaginan. En realidad, no debería darse una separación estanca como la que refleja el fragmento anterior. En su lugar, es necesario desarrollar una relación colaborativa.

Esto es por lo que el Manifiesto Ágil habla de colaboración, y no de contratos, o se usan términos como cocreación, asociación productiva o descubrimiento conjunto, en sus diversas revisiones críticas.

Los equipos de desarrollo no son entes aislados y, si bien su trabajo es materializar los productos y servicios que diseña la empresa, deben tener voz y participación. Es necesario saber concretar los requisitos técnicos necesarios para implementar una prestación, a fin de ofrecer tanto una estimación de costes, como poner sobre la mesa expectativas realistas sobre los productos y como implementarlos y desplegarlos.

Por eso mismo, son fundamentales dos cuestiones:

Los equipos de desarrollo deben conocer el negocio y deben conocer los productos. Tienen que entender cómo gana dinero la empresa y, por tanto, ser capaces de dirigir sus esfuerzos para contribuir a ello. Parafraseando a Luis Artola, en su libro Software Economics, como desarrolladoras debemos saber que trabajamos en reducir riesgos, pagar deuda, controlar costes y añadir valor.

Por su parte, el resto de la empresa tiene que entender la tecnología y como contribuye al desarrollo del negocio, lo que incluye también sus limitaciones y procesos. Porque la tecnología también incluye riesgos, deudas, costes y aporta valor.

¿Tiene sentido mantener una distinción entre equipos de tecnología y equipos de negocios?