Software - un Organismo que Respira

El software nunca está terminado. Sin embargo, la mayoría de las empresas lo cotizan y lo tratan así. Cómo evitar poner tu presupuesto en llamas mientras haces a tus usuarios tan felices que se lo cuentan a sus amigos.

¿Sabías que tenemos Arquitectos de Software en tech? A los desarrolladores de software también se les llama a menudo Builders o Engineers (desarrolladores más experimentados). Hay una razón por la que hay tantos paralelos entre Tech y la ingeniería civil real (como la construcción de edificios, etc.).

Entonces, ¿cuáles son los paralelos y qué podemos aprender de ellos?

Paralelos entre Ingeniería Civil y de Software

Si piensas en construir un edificio 🏗️ - necesitas..

1. ..planear qué quieres construir, hacer planificación de recursos, etc.
2. ..analizar una variedad de factores externos para asegurarte de que tu proyecto es factible dentro del contexto del proyecto.
3. ..diseñar el interior y exterior, y cómo quieres estructurar las habitaciones, dónde colocar ventanas, etc.
4. ..luego construirlo realmente desde cero.
5. ..luego integrarlo en infraestructura existente como internet, red eléctrica, red de agua, etc., y testear si todo es seguro y como se planeó.
6. ..luego mantener el edificio, posiblemente renovar partes en algún momento, o incluso extender el edificio si la demanda crece.

Tenemos un proceso relativamente similar para desarrollar soluciones de software, este proceso inevitablemente también viene con los mismos riesgos y desafíos.

En la ilustración, ves el típico ciclo de vida del software. Cada feature y cada milestone pasa por este ciclo. Siempre empieza con el plan de qué quieres construir, y termina manteniendo el set actual de features.

Una vez que tus usuarios proponen nuevas peticiones de features o tu software se vuelve demasiado viejo para competir en el mercado el ciclo se repite.

No te saltes una fase

Cada paso en el ciclo de vida del software es vital para el éxito. Vamos uno por uno.

1. Descuidar la fase de planificación

¿Iniciarías la construcción de un edificio sin un plan? Probablemente no.

Esta fase implica definir el scope del proyecto, los objetivos y los requisitos del cliente, y crear un plan detallado del proyecto. Hay dos enfoques principales para construir productos de software: el método Waterfall y la gestión de proyectos Agile.

El enfoque waterfall requiere que tanto la agencia de software como el cliente especifiquen una lista exhaustiva de funcionalidades y que el plan completo esté totalmente desarrollado antes de que se escriba la primera línea de código. Como puedes imaginar esto es muy desafiante, especialmente porque los requisitos pueden cambiar en el proceso debido a nuevo feedback de mercado u otros factores externos.

La mayoría de proyectos de software usan el enfoque ágil para mantenerse dentro del presupuesto y reaccionar a desafíos imprevistos. Pero aquí viene el truco: la mayoría de las empresas toman la metodología ágil como excusa para no planificar en absoluto. Echemos un vistazo.

Usar la gestión ágil de proyectos como excusa para "simplemente arrancar" el proyecto y no hacer ingeniería de requisitos adecuada indudablemente matará tu proyecto. Los desarrolladores muy probablemente fallarán al priorizar adecuadamente los features más urgentes. Y en el peor de los casos, el software ni siquiera funcionará, y si lo hace con un retraso significativo. Si trabajas con un proveedor de software externo, entonces asegúrate de que tienen un proceso cohesivo y reporting en su sitio.

La gestión ágil de proyectos todavía requiere un plan. La diferencia principal con el método waterfall es que tenemos ciclos de feedback regulares, iteraciones y realineamos las prioridades cada día, semana y quincena, etc.

"Fallar al planificar es planificar fallar."

2. Saltarse el análisis

En esta fase, la agencia de software trabaja con todos los stakeholders para definir los features y funcionalidades específicos que el software debería incluir. Saltarse esta fase probablemente resultará en que los features deseados no se construyan dentro del presupuesto planificado.

En resumen, un cliente descontento. Los requisitos detallados ayudan a presupuestar adecuadamente el proyecto y ayudan a alinear expectativas lo cual es crucial para el éxito a largo plazo del proyecto.

3. Dejar pasar el diseño

Hay 2 tipos de diseño en software. El primero es para diseñar cómo el usuario interactúa con tu aplicación. Esto incluye wireframes simples, "mood-boards" y mockups. Las mejores y más fáciles interfaces de usuario han sido cuidadosamente diseñadas para hacer tu app lo más fácil de usar posible.

Como con cualquier profesión, si quieres tener algo genial, trabaja con gente genial. Si te conformas con la mediocridad o tienes un presupuesto ajustado, entonces esto por supuesto puede ser un trade-off aceptable para el arranque.

El segundo tipo de diseño es el Diseño de Software. Mirar todos los componentes de software desde una vista de pájaro se llama Arquitectura de Software.

¿Pero qué es? Pensemos en Netflix, el famoso proveedor de streaming. La arquitectura de software de Netflix consiste en miles de servicios de software que interactúan entre sí para cubrir todo lo que puedes hacer en Netflix. Esto incluye registrar una cuenta nueva, hacer login, hacer streaming de una película y servicios de pago para tu suscripción por ejemplo.

Cada uno de estos servicios también ha sido cuidadosamente diseñado para poder seguir el ritmo de la cantidad de peticiones de usuarios y recuperarse en caso de errores inesperados. Puedes encontrar un diseño de software ejemplo de un feature imaginario abajo.

Arquitecturar adecuadamente tu software y diseñar sus componentes puede decidir si tu software se vuelve inmanejable y muy difícil de extender con nuevos features. Considera un diseño de software adecuado una inversión en el futuro de tu proyecto, para evitar la infame deuda técnica.

4. Apresurar la implementación

En esta fase, los desarrolladores de software realmente escriben el código. Como parte de la metodología ágil de proyectos, los desarrolladores de software deberían reportar regularmente al cliente y darle la oportunidad de dejar feedback temprano. Esto habilita cambios a corto plazo que de otra forma habría que cambiar en un punto mucho más tardío en el tiempo. Te podría gustar nuestro post relacionado con este tema: "Por qué la gente piensa que las Agencias de Software apestan"

5. Sacrificar testing e integración

La fase de testing toma tiempo y recursos como cada fase del ciclo de vida del software. Pero nada romperá tu software más rápido que no tener suficientes tests programáticos. También tenemos un post de blog sobre testing de software: "Test Driven Development".

Como parte del testing, también es crucial asegurarse de que tu software está suficientemente integrado con software externo del que depende tu aplicación. Un ejemplo específico de Web3 aquí serían los oracles, llevar datos off-chain a tu smart contract. Aunque esto es parte de las fases previas, la integración y test en la blockchain mainnet real debería testearse también.

6. Olvidarse del mantenimiento

Acabamos de escuchar que el software tiene dependencias, software que no ha sido desarrollado por tu agencia de software sino por miles de desarrolladores independientes. Además, tu propia aplicación de software evoluciona también, nuevas funcionalidades pueden ser demandadas por usuarios, los usuarios descubrirán bugs y dependencias que necesitan ser actualizadas.

Cuanto mejor trabajo haya hecho tu agencia de software con las fases previas, especialmente con recoger requisitos y diseño de software, más fácil y barato será el mantenimiento. No hay software en la tierra que no necesite mantenimiento, excepto, por supuesto, si nadie lo está usando pero supongo que no es lo que queremos. Algunas agencias de software no les gusta el mantenimiento, así que asegúrate de que tu proveedor de software está dispuesto a hacerlo.

Ver también: mantener un producto de software vivo necesita liderazgo continuo de ingeniería, no un build de una sola vez. Si necesitas eso sin un hire full-time, ver nuestro servicio Fractional CTO Austria.