Entrega de solución

Entrega de solución

Es por ello que un proyecto entrega una solución y no software construido ni un sistema funcionando. Un proyecto entrega un sistema que se usa, que es efectivo, que responde a procesos de negocio acordes con el trabajo del usuario final y que puede responder a un roadmap relacionado a la estrategia del cliente.

Cuando un proyecto está en proceso y no lo estamos gestionando bien, nos podemos encontrar con este tipo de respuestas:

Pero es fácil, tenemos que entregar el sistema.

El problema con estas situaciones es que, en parte, obviamos al fenómeno de Newton que involucra tanto acción como reacción. Esto quiere decir que antes de pensar en la consecuencia, es decir, el software o sistema, debemos dedicarle atención a la causa, en otras palabras, la programación. Pues obviamente, sin programación no hay software.

La programación está muy ligada al arte de la creación del software, y al tocar este tema, nos encontraremos con conclusiones muy interesantes:

1. Si nos enfocamos en que el software se desarrolla o se programa, las líneas de código se convertirán en el tema principal y creo que sería muy injusto no mencionar al diseño de la interfaz y más aún, la experiencia del usuario.
2. Si abarcamos el diseño del software, al igual que en el caso anterior, elementos tan importantes como la programación o el diseño de la interfaz de usuario, pasarían a segundo plano.
3. Hablar del diseño de interfaz de usuario o de la experiencia del mismo, implica específicamente cómo se percibe la aplicación.  La descripción nos confirma que, se diseña la interfaz y se busca que el usuario tenga una experiencia agradable, por lo que la factibilidad técnica y otras veces, la funcional, podrían hasta dejar de ser consultadas.

Hasta aquí creo que queda claro que desarrollar software implica más que programar. Y eso que no hemos considerado elementos como gestión, pruebas y aseguramiento de calidad.

Es por ello que hace muchos años, Steve McConnel concluyó de manera muy interesante, que por esa y muchas otras razones, el software se construye.

Han pasado veinte años desde la primera mención que hizo McConnel, pero los fundamentos se mantienen. El software se construye y lo que se debe confirmar y ser de conocimiento general, es el alcance de las actividades implicadas.

De obviar este paso, alguna de las actividades perderá importancia o en el peor de los casos, será depurada de nuestro plan de trabajo.

 ¿Qué se entrega al finalizar el proyecto?

La respuesta obvia es y será “software funcionando”, pero en serio, ¿qué entregamos? ¿Un programa con su respectivo manual de uso?

De todo lo mencionado, el trabajo de un proyecto siempre refleja al software que el equipo construye. Esto considerando que la construcción implica juntar piezas como:

1. Necesidades del usuario, que al ser traducidas a líneas de programación (en resumen, código), servirán de apoyo para que el trabajo sea más productivo que el ejecutado en la actualidad.
2. Código que responde a un diseño de componentes. Lo cual implica cumplir con el plano de las conexiones entre módulos internos y sistemas involucrados.
3. Interfaces de usuario que responden a recomendaciones y prácticas en las que la experiencia juega un papel importante. Sin esto, el usuario se aburre y con ello, no usará el sistema así éste funcione!

Si bien es cierto la culminación de un proyecto involucra la entrega de software, tenemos que diferenciar y/o aclarar algunos conceptos clave:

1. Programa: Es el ejecutable que puede representar a un módulo, parte de uno o incluso más de uno. Y gracias a esta ambigüedad, es que se recomienda evitar el término a menos que hablemos de artefactos del proyecto.
2.  Aplicación: Este concepto involucra más que un conjunto de programas. Incluso hay situaciones en las que se incluye el manual de uso y/o instrucciones de instalación.
3. Solución: Este es el que más me gusta ya que de por sí engloba los elementos anteriores y agrega aspectos como:
   1. Manual o resumen de procesos que son soportados por la aplicación
   2. Biblioteca de preguntas frecuentes con sus respectivas respuestas e idealmente, ejemplos documentados.
   3. Manual de operación que ayuda a responder a la pregunta ¿qué hacer en casos de emergencia?

Elementos como estos, y muchos más, son parte de la solución integral por la que el proyecto debe luchar hasta que la necesidad esté satisfecha.

Es por ello que un proyecto entrega una solución y no software construido ni un sistema funcionando. Un proyecto entrega un sistema que se usa, que es efectivo, que responde a procesos de negocio acordes con el trabajo del usuario final y que puede responder a un roadmap relacionado a la estrategia del cliente.