¿Cuánto tiempo lleva construir un software?

Depende de su complejidad. Tomemos un ejemplo: una función simple, como un gráfico que muestra el número de usuarios registrados puede tomar tan poco como 10 horas, o terminar siendo 200 horas. Será completamente diferente si necesita actualizarlo en tiempo real, si necesita acercar y alejar el gráfico, si necesita mostrar comparaciones de las diferentes líneas de tiempo, si necesita cambiar los datos granulares para recopilar algo cada hora, si quieres ver el resultado diariamente o semanalmente.

Como puede imaginar, también se pueden encontrar las mismas dependencias en otras características o componentes. Cuanto más complejos sean, más se necesitará para desarrollarlos.

También depende de lo que esperas obtener. Si necesita alguna prueba de concepto, la versión más pequeña de su producto que demuestre su valor, debería ser posible entregarla en unas pocas semanas. Si desea saber cuánto tiempo tomaría construir un producto con todas las funciones, con un montón de integraciones y diferentes versiones de idiomas, probablemente tomará años.

Gran parte de ese tiempo se dedicará a la investigación y a la recopilación de comentarios. ¡Crear software no es solo escribir un código!

Si desea obtener más información sobre las etapas de desarrollo de software, consulte este libro electrónico: Desarrollo de software, paso a paso o visite el blog Neoteric (Matt Kurleto escribe muy buenos artículos para startups).

Depende de cuán complejo sea el software. Es posible crear una pieza de software que haga algo genial en solo uno o dos días. Ludum Dare es una competencia donde las personas crean un juego original desde cero en solo un fin de semana, y las entradas ganadoras logran ser jugables y divertidas a pesar de esas limitaciones de tiempo. Sin embargo, el software comercial generalmente toma más en el rango de ‘meses a años’ antes de que alguien sienta que vale la pena.

Si se hace un intento para estimar cuánto tiempo tomará por adelantado un proyecto de software dado, entonces con frecuencia la respuesta será “más larga de lo esperado”, ya que los proyectos de software son notorios porque a menudo no se realizan en el tiempo planificado para ellos. La razón de esto es que una parte significativa del tiempo que lleva construir software se gasta en cosas inesperadas: errores, dificultades técnicas, requisitos que cambian repentinamente a la mitad, etc.

El primer 90 por ciento del código representa el primer 90 por ciento del tiempo de desarrollo. El 10 por ciento restante del código representa el otro 90 por ciento del tiempo de desarrollo.

– Tom Cargill (atribuido)

Pero este problema de no saber cuánto tiempo llevará construir su software puede evitarse al no tener una fecha de finalización para el proyecto. Recientemente, gracias a la capacidad de transmitir actualizaciones de software a través de Internet, la entrega continua se ha vuelto popular. En lugar de crear un solo software pulido y grabarlo en un CD-ROM, se pueden priorizar las características deseadas del software para crear el producto más pequeño posible que aún sea lo suficientemente bueno como para ser lanzado como la primera versión. Tan pronto como se completan estas funciones, se lanza el software, después de lo cual se actualiza automáticamente cada pocas semanas con una nueva versión que contiene nuevas funciones y correcciones de errores. ¿Significa eso que dicho software tarda unos meses en construirse (para la primera versión) o varias décadas (si ese es el tiempo que el equipo que trabaja en el software terminará lanzando nuevas versiones)? ¡Tú decides!

En el mundo real, lleva de seis meses a cinco años llevar una versión particular de una aplicación al mercado.

Incluso una aplicación simple o una nueva versión de una aplicación existente que sea más compleja que una corrección de errores trivial tardará al menos un mes en codificarse. En general, puede decir que la depuración lleva el doble de tiempo. Luego, el equipo de prueba se apodera de él e informa docenas de problemas. Como regla general muy aproximada, quizás cincuenta errores por mes de tiempo de desarrollo. Los arreglas y se envía a los beta testers que informan docenas más. Todo eso lleva tiempo y el desarrollador no está gastando todo ese tiempo en la aplicación. Puede ser un 50% esperando a que lleguen los informes, pero el tiempo todavía está pasando. Mientras tanto, otras personas escriben la documentación del usuario y hacen la magia negra de marketing.

Con una aplicación grande y compleja, dos años pueden ser demasiado cortos.

Las escalas de tiempo son similares en el mundo de código abierto o si usa el proceso de lanzamiento alfa público que le gusta al software de juegos indi. Probablemente, inicialmente dejaría de lado las funciones menos vitales y publicaría la aplicación en el momento en que de lo contrario saldría a los beta-testers. La versión inicial de buggy atrae el interés y mientras espera que lleguen los informes de errores, pasa el tiempo agregando funciones. Lleva el mismo período de tiempo, pero si lo hace bien, sus desarrolladores están 100% ocupados, tiene miles de probadores que se aseguran de que se encuentren todos los errores, y la versión final desaparece tan pronto como se implementa la última característica.