¿Es lo mismo desarrollar un producto software que realizar un proyecto?

Durante mis primeros años como desarrollador de software tuve la enorme suerte de participar en un equipo que estaba dedicado íntegramente al desarrollo de un producto. Incluso teníamos quienes se dedicaban exclusivamente a escribir pruebas (lo que era un auténtico lujo). Hace tiempo de eso y aunque usábamos tecnologías ahora obsoletas o de menos uso (Visual C++, ActiveX, COM, DCOM, etc), la dinámica para la creación de un producto software no ha cambiado en absoluto, aunque desde entonces he abrazado el desarrollo ágil como mejor forma de realizar software.

Estos dos últimos años, sin ir más lejos, me he dedicado íntegramente a dirigir un equipo de desarrollo para la creación de un producto software muy específico para compañías del sector eléctrico. Han sido dos años muy duros en los que hemos escrito muchísimo código, hemos sacado unas cuatro versiones comerciales del producto con éxito (con clientes consolidados) y hemos tenido siempre presente la necesidad de refactorizar, de esforzarnos por mejorar y ampliar las pruebas, de escribir una documentación de despliegue correcta y mantener una gestión de la configuración eficiente. Nada es perfecto, pero el resultado, en mi opinión, me indica que hemos hecho las cosas aceptablemente bien.

Programar algo que funcione es relativamente fácil, crear un proyecto muy particular para un cliente requiere de algunas habilidades más, hacer un proyecto similar pero de mayor tamaño con un equipo de varias personas añade un nuevo nivel de dificultad pero, sobre todo, realizar un producto software que sea válido no para uno sino para cientos de clientes distintos, es otro nivel completamente distinto que requiere de una dinámica muy diferente a la del trabajo en un proyecto particular.

Hay muchas diferencias técnicas y de gestión entre uno y otro escenario y no siempre se distinguen claramente.

¿En qué consiste la diferencia?

La dinámica es tan diferente hasta el punto de que en ocasiones se intenta afrontar el desarrollo de un producto con la presión al mismo tiempo de entregar proyectos con ese mismo producto (haciéndolo todo el mismo equipo). Lo he visto, lo he vivido y es un absoluto desastre.

Aunque cada producto y cada proyecto tienen su propia idiosincrasia, en mi opinión es mucho más fácil entregar un proyecto para un cliente que te indica lo mejor posible qué necesita. Otra cosa distinta es saber productivizar algo a partir de las necesidades de un conjunto de clientes: esto es ni más ni menos que el desarrollo de un producto software.

Muy resumidamente, en un proyecto:

• Hay un trato directo con un cliente que puede ser más o menos difícil de llevar (especificaciones que cambian sobre la marcha, exigencia de tiempos de entrega, etc).
• La funcionalidad a implementar está perfectamente acotada (sí, ya sé, al menos debería estarlo).
• La gestión de la configuración, o sea, la definición de flujos de trabajo, la gestión de versiones de desarrollo y la de producción final, etc., es relativamente más sencilla. No digo que sea trivial, sino que es más sencilla que la gestión de configuración para un producto.
• La gestión del grupo de trabajo se orienta a la entrega del proyecto al cliente en fechas determinadas.
• Las reuniones con el cliente absorben mucho tiempo, sobre todo si se le van haciendo entregas tempranas para su evaluación y corrección.
• El equipo de desarrollo o quien lo dirige no necesita conocer con todo detalle el universo en el que trabaja el cliente y su propio negocio.
• No hay necesidad de hacer partes del sistema flexibles y adaptables a gustos y diferentes exigencias de posibles clientes, ya que sólo hay uno.
• En cuanto al mantenimiento, nos podemos permitir que no sea lo más fácil de mantener (ya que va a haber un sólo cliente), aunque lo deseable es que sea extremadamente sencillo de mantener sin acumular deuda técnica que luego nos pase factura en el tiempo dedicado al cliente, tanto si éste paga ese mantenimiento como si no. Un proyecto difícil y costoso en tiempo de mantener en producción, es un fracaso.
• No hay tantas restricciones en la elección de las tecnologías a usar, sobre todo el proyecto no va a evolucionar demasiado con el tiempo.
• Puesto que existe un único cliente, se puede conocer con antelación el entorno en el que se va a desplegar el proyecto (sistema operativo, tipo de base de datos, hardware, etc.), al menos se puede acordar con el cliente.

En cambio, el desarrollo de un producto es otro nivel distinto y mucho más exigente en el desarrollo de software, porque:

• Hay que conocer profundamente el universo de los clientes potenciales hacia los que te diriges. El producto tiene que resolver algo y aportar funcionalidad para el negocio de los clientes, por tanto, tienes que conocer ese negocio muy bien. No es necesario que todo equipo conozca esto, pero quien lo dirige o determina la funcionalidad sí.
• De este conocimiento del negocio de los clientes potenciales hay que extraer la funcionalidad a implementar: especificar es algo muy pero que muy difícil, especificar bien para extraer historias de usuario o requerimientos técnicos lo es todavía más.
• La gestión de la configuración tiene que ser más exhaustiva, sobre todo si con el tiempo terminas teniendo en el mercado distintas versiones del mismo producto.
• Puesto que la vida del producto puede ser muy larga, hay que hacer mucho más énfasis en la testeabilidad del software y todo o casi todo tiene que estar cubierto por pruebas automáticas. De no ser así, el probar el sistema puede suponer tal agujero de tiempo que puede incluso poner en peligro la viabilidad económica del producto.
• Es mucho más difícil elegir las tecnologías a usar más adecuadas, sobre todo si se estima que el producto software tenga una vida de muchos años, que es lo deseable para rentabilizar la inversión en su desarrollo, claro.
• Hay que ponerse en el lugar de los posibles clientes y adivinar o averiguar cuáles pueden ser sus necesidades específicas y particulares para incorporarlas al producto en forma de capacidades de integración, funcionalidad de particularización, etc.
• Hay que definir el entorno ideal de despliegue del producto, lo que puede ser muy delicado porque esto afectará al coste que tenga el mismo. Cuantos más entornos distintos que tengan que ser compatibles con el producto, mucho más esfuerzo por nuestra parte para probar y probar. Un error fundamental es ignorar el tipo de entorno de despliegue hasta el final.
• Si queremos mejorar el producto para ganar cuota de mercado, es imprescindible recibir mucho, muchísimo feedback desde el momento en que tenemos un primer cliente usándolo. Es más, si podemos liberar un MVP (minimum viable product) cuanto antes, mejor, corregiremos así deficiencias lo antes posible y enfocaremos mejor el desarrollo del producto.

Aunque estas diferencias las debe considerar el responsable del desarrollo del proyecto o del producto, también afectan al día a día de los desarrolladores del equipo de trabajo.

Me pregunto por qué nunca he visto en un currículum una mención del tipo "Desarrollador de productos software" o "Desarrollador de proyectos para clientes finales"; para mí la diferencia es enorme. 

Sin duda, el desarrollar un producto software (o dirigir su desarrollo) requiere de mucha más experiencia y de controlar muchos más parámetros que el desarrollo de proyectos específicos, bastante más cómodos de gestionar (aunque el trato con el cliente siempre es difícil de llevar).