No hace falta ser muy listo para darse cuenta de que no todos los desarrollos son iguales y de que la forma de afrontar un nuevo desarrollo depende del tipo que desarrollo que sea.

Un factor importante que acaba condicionando la forma de desarrollar es si estamos ante el desarrollo de un producto o el desarrollo de un proyecto. La frontera entre ambos escenarios puede ser difusa y no sólo depende de qué estamos desarrollando sino también de para qué y para quién lo estamos desarrollando.

Por ejemplo, si una empresa se dedica a desarrollar un juego para móvil para comercializarlo ella misma, puede considerar que el juego es un producto. Sin embargo, si esa misma empresa desarrolla el juego por encargo para una cadena de hamburgueserías, aunque lo desarrollado es lo mismo (un juego para móvil), seguramente sea más razonable verlo como un proyecto.

Incluso sin cambiar el «cliente» del desarrollo podemos encontrar situaciones similares. Una empresa puede lanzar un proyecto para construir un prototipo que le permita sondear un mercado concreto, y si todo va bien, ese proyecto acabará convirtiéndose en un producto. El enfoque inicial puede ser el de proyecto, pero a medio plazo el desarrollo girará para acabar convirtiéndose en un desarrollo más orientado a producto.

Las implicaciones de enfocar algo como un proyecto o como un producto van mucho más allá de la manera de desarrollarlo y afectan al planteamiento global de la empresa.

Llevo el tiempo suficiente en este mundillo para haber pasado por etapas en las que la empresa estaba más enfocada en proyectos y etapas más centradas en el desarrollo de un producto y, aunque estoy convencido de que cada empresa es un mundo, creo que hay una serie de elementos comunes a muchas empresas, al menos a empresas de un tamaño pequeño/mediano.

En cualquier caso, esto no deja de ser una reflexión personal que no pretende sentar cátedra ni mucho menos. Cualquiera puede aportar su granito de arena en los comentarios.

Proyectos

Al hablar de proyectos me refiero a lo que hace unos cuantos años se conocía como «desarrollos a medida» o «software llave en mano». Probablemente sea la mayoría del software que se desarrolla en el mundo.

Suelen empezar por realizar una captura de requisitos y terminar con la puesta en producción de un sistema, y normalmente se sabe de antemano quienes lo acabarán usando: la empresa (o las empresas) que han contratado ese desarrollo.

Su duración en el tiempo está más acotada, aunque lo habitual es que tras la puesta en producción haya que seguir desarrollando para mantener el sistema y adaptarlo a los cambios que se vayan produciendo en el negocio, pero el desarrollo durante esa fase es mucho menor que al principio.

A nivel de empresa tienen un componente muy apetecible, porque pueden suponer una inyección de ingresos importante y «garantizan» que se amortizarán los costes del desarrollo. A cambio, hay que vender cada proyecto, y dependiendo del tamaño de la empresa, de los sectores en los que se mueva, y de un montón de factores externos, eso no siempre es fácil.

Otro inconveniente es que no es fácil acompasar los proyectos en el tiempo. Lo mismo te llegan 3 proyectos a la vez y tienes que rechazar alguno por falta de personal para atenderlo, que te tiras un par de meses sin que te entre un proyecto y tienes gente parada. Hay empresas que manejan estos tiempos muy bien, pero ya digo que, en mi experiencia, no es algo fácil.

Para el departamento de desarrollo trabajar con proyectos también tiene partes muy atractivas. Es relativamente habitual que cada proyecto parta de cero y con bastante libertad para ejecutarlo (aunque pueda integrarse o actualizar sistemas existentes).

Eso hace que podamos cambiar las herramientas que queremos usar para desarrollar cada proyecto, variando entre distintas librerías, lenguajes o plataformas en función de lo que se supone que va a ir mejor en ese proyecto. Además, como los proyectos no son algo eterno, si el resultado no es el óptimo siempre puedes cambiar de librería en el siguiente proyecto y aprovechar lo aprendido.

Bueno, esa es la teoría. En la práctica muchas veces la presión por recortar plazos es grande y los proyectos se convierten en un copiar-pegar-ñapear el proyecto anterior para intentar cumplir unos plazos arbitrarios.

Para mi, desarrollar proyectos es muy entretenido por esa posibilidad de cambiar de tecnologías y, sobre todo, porque te permite conocer muchos negocios con problemáticas diferentes. En el lado malo, siempre me he quedado con la sensación de que no puedes cuidar la calidad tanto como me gustaría porque no sale rentable.

Cuesta encontrar clientes dispuestos a pagarla y, por desgracia, muchas veces es más rentable hacer un desarrollo peor y poder cobrar un contrato de mantenimiento que hacer algo que funciona. Me han llegado a decir, textualmente, «os pagaríamos un contrato de mantenimiento como hacemos con el resto de proveedores, pero es que llevamos un año en producción y vuestro sistema no ha fallado nunca».

En ese momento es cuando te planteas si no era mejor haber hecho software de baja calidad como el que ofertaban esos otros proveedores que bajaron el precio del proyecto. En ese sentido, es un poco frustrante, la verdad.

Productos

Si pienso en productos, lo primero que me viene a la mente es algo como Microsoft Office (el de siempre, el que se instala en tu PC, no las moderneces esas de la nube de ahora), pero la verdad es que hoy en día muchos productos son realmente servicios o… bueno, o cosas como facebook que no sé muy bien cómo calificar.

Desde el punto de vista de empresa, supone un cambio radical frente a un modelo de negocio basado en proyectos, porque ya no se trata de ir consiguiendo ventas y, a partir de ellas, movilizar al departamento de desarrollo, sino que primero se decide el producto que se quiere construir, se hace una inversión, y luego se intenta rentabilizar. Aquí, claro está, entra en juego el modelo ágil de desarrollo sentido común para intentar minimizar la inversión en desarrollo antes de empezar a conseguir ingresos y poder validar si la cosa tiene futuro o no.

Esto no quiere decir que en una empresa orientada al producto el departamento de desarrollo sea el que guíe la estrategia de empresa, nada más lejos de la realidad. Sigue siendo crítico decidir qué mercados atacar, qué canales de comercialización se usarán, tener una red comercial, un plan de marketing, etc.

Lo bueno es que si consigues posicionar un producto en el mercado todo se vuelve más predecible y permite vivir con cierta tranquilidad. No es que puedas dormirte en los laureles, pero igual que cuesta más tiempo alcanzar un nivel de ingresos que compense la inversión inicial, es raro que tu producto desaparezca de la noche a la mañana y pierdas todos esos ingresos recurrentes de golpe.

Una diferencia importante con el modelo de negocio basado en proyectos es que podemos mantener un esfuerzo más constante en el departamento de desarrollo. Mientras que con los proyectos podemos tener épocas de saturación (cuando se acerca un deadline o cuando entran más proyectos de los que podemos asumir) y épocas de relax (cuando no hemos conseguido vender dos proyectos seguidos), en el caso del desarrollo de un producto siempre hay cosas que hacer, y las urgencias, aunque existen porque a fin de cuentas tienes unos usuarios/clientes que cuidar, suelen ser menores.

Además cuando desarrollas un producto es más sencillo «vender» la calidad dentro de la empresa. Mientras que en un proyecto necesitas venderle la idea de calidad al cliente, en el caso de un producto hay que venderla dentro de la empresa y suele ser más fácil, primero porque suele saber más sobre desarrollo de software que el cliente (se supone que se dedica a ello), y segundo porque ve los resultados directos.

Es más fácil vender calidad cuando la empresa ve directamente que invertir tiempo en cuidar la calidad del software redunda en poder mantener una velocidad de desarrollo constante sin colapsarse según aumenta la complejidad del producto, que el nivel de incidencias no se dispara por lo que el coste del departamento de soporte se mantiene bajo, que los clientes están contentos y recomiendan tu producto, etc.

Desde ese punto de vista, y teniendo en cuenta que siempre he mantenido que me gusta (intentar) hacer bien las cosas, para mi desarrollar un producto resulta muy gratificante.

Pero no todo son ventajas, claro. El ciclo de vida de un producto suele largo y su desarrollo activo también (no me refiero sólo a mantenimiento y parcheado, que es más típico en proyectos). Eso hace que tengas que convivir con tecnologías «desfasadas». O, mejor dicho, desfasadas según las modas actuales en las que una librería que tenga 2 años ya está obsoleta, aunque haga perfectamente su trabajo.

Por suerte cada vez es más habitual que los productos sean menos monolíticos y haya componentes dentro del sistema que aparecen y desaparecen, permitiendo introducir nuevas tecnologías o retirando algunas que realmente han quedado obsoletas. No obstante, en general desarrollando producto es raro que estés a la última en todo.

Produyectos

Existe un último modelo que podríamos ver como un híbrido de los dos anteriores: el produyecto.

Hay bastantes empresas «de producto» que en realidad son más bien de produyecto. Tienen un producto, sí, pero no es un producto que se pueda vender directamente. Cada venta conlleva un proyecto de relativa complejidad que con frecuencia requiere un desarrollo adicional sobre el producto base.

Esto es muy típico en sistemas de cierta envergadura, el caso más claro son los ERPs. Excepto los ERPs más simples del mercado, todos requieren adaptaciones al montárselos a los clientes.

Desde el punto de vista de empresa no está mal, porque puedes vender licencias de tu producto base (o cuotas si tu producto es SaaS) y además cobrar la personalización que haces para cliente.

Para el departamento de desarrollo puede provocar situaciones un poco incómodas, porque vive entre la tensión de mantener un núcleo coherente y bien desarrollado e introducir las adaptaciones para un cliente concreto.

Si no se hace con cuidado, esto acaba desembocando en un mar de versiones específicas para cada cliente, con módulos copiados y pegados de una otra pero que no son exactamente iguales, o con una especie de monstruo lleno de checks y opciones de configuración imposible de entender para dar cabida a cientos de operativas inconexas y, a veces, incompatibles entre sí.

Como cada instalación es distinta de la anterior, es complicado mantener una buena documentación o tener un departamento de soporte formado, por lo que el soporte y mantenimiento acaba recayendo sobre el propio departamento de desarrollo, y cuando tienes un problema 5 años después de haber instalado el produyecto sigues hablando con el programador que te lo hizo (si sigue en la empresa).

Reconozco que no he desarrollado muchos produyectos, pero he sufrido unos cuantos como cliente y en integraciones con ellos. La sensación que me ha dado es que no es nada cómodo para el equipo de desarrollo, aunque insisto, no tengo demasiada experiencia en esto.

Conclusión

Después de haber pasado por épocas de muchos proyectos y épocas de muchos productos, y haber padecido algún que otro produyecto, lo cierto es que no tengo una preferencia clara entre un mundo y otro.

Sí es verdad que trabajar con producto te lleva a planteamientos más conservadores, especialmente cuando el producto está asentado. Si desarrollando un proyecto fracasas, puedes perder ese cliente, pero con un poco de suerte no será tú único cliente y podrás seguir adelante. Si metes la pata desarrollando un producto que llevas varios años desarrollando, el perjuicio es mayor, por lo que ciertas decisiones las tomas de manera más lenta y reposada.

Precisamente esto hace que trabajar con proyectos pueda resultar más divertido, pero la posibilidad de ver crecer un producto durante unos años también es agradable.