Tiempo de lectura: 5 minutos
En el desarrollo de software, la premisa de bueno, rápido y barato es difícil de conseguir. ¿Podemos conseguir las tres cosas? Es posible lograr un equilibrio? Te lo contamos aquí.
Muchos de los que trabajamos en la industria del software, cuando empezamos a trabajar en presupuestos de proyectos, consultas o estimaciones, nos hemos enfrentado a una obligación casi inevitable del mercado: desarrollar software bueno, rápido y barato. ¿Es posible tener estas tres variables al mismo tiempo? Es esta idea una utopía?
Para responder a esta pregunta y ver la viabilidad de este postulado, es importante que primero repasemos dos ideas clave.
¿Qué precio se le pone a un ente intangible?
El software es un producto intangible; no podemos verlo, ni saber su bondad hasta que está terminado. Poner precio a un desarrollo de software es algo complejo (a no ser que se compre software empaquetado en lugar de un desarrollo a medida), no sólo por la subjetividad que existe de su valor (basado en muchos criterios), sino también por las diferencias existentes sobre si el proyecto es más fácil o más complejo de realizar.
La estimación, un pilar para el éxito
Dada la coyuntura de lo intangible, realizar una estimación correcta -y lo más precisa posible, dado que se trata de una aproximación-, es muy importante para que se eviten sobrecostes presupuestarios y pérdidas de tiempo.
Contenido relacionado: 10 consejos útiles para la estimación de proyectos de software
Teniendo en cuenta que una buena estimación es la base del éxito de un proyecto de desarrollo, no podemos ignorar que toda estimación se traduce en horas-hombre. La calidad profesional de los miembros del equipo y su experiencia son directamente proporcionales al coste del desarrollo.
En definitiva, sabiendo que la estimación, la planificación y la ejecución de un proyecto son realizadas por personas, podemos deducir que la calidad y la experiencia de los profesionales afectan al coste de un proyecto.
Lo bueno, lo rápido y lo barato
Habiendo entendido que el software es un ente intangible cuyo precio es difícil de definir, sobre todo si no hay una estimación clara, pasemos a explicar los atributos de lo bueno, lo rápido y lo barato y cómo es posible combinarlos pero no tener los tres simultáneamente.
Bueno y rápido
Es posible hacer algo bueno con velocidad. Para conseguirlo, es fundamental hacer una buena estimación y luego tener un buen plan de ejecución del proyecto para que la rapidez no afecte a la calidad del resultado.
La clave para conseguir calidad y rapidez está en las personas que trabajan en el proyecto, que deben estar suficientemente cualificadas para afrontarlo. Recuerde que la calidad de los profesionales es un factor determinante en el coste.
Tenga en cuenta que la velocidad puede ser contraproducente para la productividad: En teoría, un equipo (y sus miembros) alcanza su pico de producción en un tiempo determinado y lo mantiene hasta el final del proyecto. Cuanto mayor sea la velocidad, menor será el tiempo que el equipo estará en su pico de productividad.
Así mismo, la coordinación también será un factor a analizar: Cuantas más personas trabajen en paralelo, mayor será la coordinación requerida (quizás haya que añadir más personas como coordinadores).
Lo bueno y lo rápido se aplica sobre todo a los proyectos críticos o clave, en los que hay que garantizar la calidad del producto a toda costa. En estos casos, es necesario contar con equipos con mucha experiencia. Si este es el caso, la solución será buena y rápida, pero también cara.
Rápido y barato
Aquí está la segunda de nuestras combinaciones de las tres variables: La forma más sencilla de hacer algo rápido y barato es hacerlo sin calidad o, al menos, siendo conscientes de que puede ser inferior a la deseada. Podríamos sacrificar la calidad hasta cierto punto, siempre y cuando el software no maneje información crítica, o no dependa de alguna parte sensible de la organización.
Para efectos de velocidad -ya que en el futuro se puede mejorar la calidad de la aplicación-, es posible entrar en producción con las características clave para que el producto funcione. En estos casos, esto es lo que se puede hacer:
- Minorar la calidad del código
- Simplificar su usabilidad
- Dejar de lado las revisiones de código
- Reducir los controles de calidad y las pruebas.
Haciendo esto, lo más probable es que consigamos una herramienta con una funcionalidad básica, pero no obtendremos un producto 100% satisfactorio. Su usabilidad puede no ser la mejor, así como la calidad del código, y su extensibilidad (posibilidad de cambio o ampliación) y reutilización pueden ser problemáticas.
Esto se aplica a las aplicaciones de demostración, a las pruebas de concepto, al software no crítico o a cualquier aplicación escalable o extensible en el tiempo.
Bueno y barato
Le doy la última de nuestras ecuaciones: Si el cliente quiere una solución buena y barata, no puede esperar una entrega rápida.
Se puede hacer algo bueno y a un coste aceptable pero en detrimento del tiempo. Básicamente, si hay tiempo, es más fácil planificar -ya que no hay tantas tareas en paralelo y no se requiere tanta coordinación-, y el pico de productividad de las personas implicadas va a estar en su punto máximo durante más tiempo.
Conseguir algo bueno y barato es adecuado para proyectos en los que el tiempo no es una variable crítica, así como para proyectos incrementales o con equipos con tiempos parciales (que tienen proyectos o iniciativas internas).
No te pierdas esto: Calidad del software o precio: ¿Cuál importa realmente?
En resumen
En el desarrollo de software, el postulado de desarrollo de software bueno, rápido y barato es muy difícil de conseguir. Siempre podremos conseguir dos de ellos, pero tendremos que abandonar el restante. De este modo, es posible conseguir la calidad en tiempos estipulados y a un coste razonable; sólo hay que saber encontrar el equilibrio entre estas tres variables, conociendo las implicaciones y cómo se interrelacionan entre sí para alcanzar ese equilibrio.
Alcanzar este equilibrio será posible siempre y cuando las estimaciones, la coordinación, la selección del equipo, la metodología de trabajo y el uso de herramientas y tecnologías sean los adecuados.
¿Has conseguido el equilibrio entre estas variables en algún proyecto? ¿Cómo lo has hecho?
