Iniciar un proyecto

¡Vamos de cero a héroe mirando las piezas necesarias para un Proyecto que se convierta en un Producto que se convierta en algo útil!

Vas a construir un gran producto, pero tengo noticias para ti. Todo empieza como un proyecto. Está bien. Podemos llamarlo Producto, MVP (Producto Mínimo Viable) o lo que queramos, pero va a empezar como un proyecto primero.

Muchas empresas están discutiendo el por qué y qué beneficios añadiría hacer esta actividad en particular. Consulta el Presupuesto para obtener información sobre NPV (Valor Presente Neto - ¿qué vale ahora?) — cálculos y Construir o Comprar.

Existen muchas metodologías de gestión de proyectos que pueden ayudarte a comenzar, planificar, implementar, probar, lanzar y cerrar tu proyecto. También hay algunas metodologías que lo hacen en iteraciones, es decir, repeticiones cortas, en lugar de fases más largas.

Esto significa que los proyectos tienen grandes implicaciones sobre cómo los configuras, cómo los ejecutas y cómo se entregan. 

Para completar este pequeño libro, voy a explicar rápidamente la gestión de proyectos clásica, también conocida como “Waterfall”. Imagina un río. Este es tu proceso de proyecto. Siempre te mueves por el río y no vuelves atrás para cambiar cosas a medida que avanzas, está fijo y resuelto.

Entonces, te mueves más adelante y entras en diferentes fases, como la fase de implementación donde todo el código se supone que debe codificarse, y luego la fase de pruebas cuando se supone que debe probarse. Todo se basa en especificaciones previas que se escribieron antes de que comenzaras el proyecto.

Sabías exactamente lo que querías construir, hasta el último botón. Así que pasaste meses poniendo esto en un documento, luego tus desarrolladores senior o Arquitectos te ayudaron a escribir las Funciones en el Documento de Especificación Funcional. Luego, en la fase de implementación, construyes exactamente lo que estaba en esta especificación. Luego, lo pruebas para ver si funciona como se especificó.

Esto nunca ha funcionado en ningún proyecto de tecnología. Las mejores entregas de este tipo de proyectos produjeron una aplicación que hizo exactamente lo que se pretendía, pero no tomaron en cuenta los hallazgos o ideas que se encontraron durante el desarrollo.

Además, el tiempo pasó durante la duración del proyecto, y perdiste algunas oportunidades de mostrar esto a un cliente potencial y obtener valiosos comentarios. Ahora has construido algo que no has probado con ningún usuario real. Voy a aventurarme a decir que probablemente no será lo que querías.

Lee más en "El Manual del CTO" disponible en Amazon/Kindle.