Carta abierta sobre el desarrollo de software en la vida empresarial

Hace un par de años, mientras estudiaba mi maestría en Investigación en Desarrollo de Software, tuve la oportunidad de participar en un foro sobre Especificación de Sistemas Software con estudiantes que no había trabajado nunca en el desarrollo de sistemas dentro de un ambiente empresarial (o de forma profesional, es decir siempre habían sido estudiantes) y preguntaban cuanto de lo que veían en su carrera universitaria se aplicaría en el “mundo real”.

El siguiente extracto, el cual acabo de recuperar, es parte de mi participación en dicho foro, trata sobre todo de la formalización de un sistema mediante documentación previa a la construcción, aunque puede pecar de subjetivo, espero que sirva como orientación para estudiantes de Ingeniera en Software o carreras afines.

Tengo en “activo” en el mundo del desarrollo de software desde finales de los 90. He pasando por todos los puestos imaginables, desde "chico de los cafés", hasta mi puesto actual como encargado de la arquitectura de software. Te diré que yo amo esta profesión, pero en todo este tiempo he pasado por diferentes fases anímicas en cuento a las gratificaciones que me ha ofrecido.

En lo que a mí respecta, existe una brecha entre el mundo académico y el mundo empresarial. Muchas veces es muy difícil aplicar los conocimientos obtenidos en tus estudios directamente, y en “crudo”, en tu trabajo. Muchas de estos conocimientos, por otro lado, no cumplen las necesidades reales de los clientes, que son principalmente:

•  Tener un software útil.
•  Que su software se cree rápido, y sea fácil de modificar.
•  Que su software no tenga errores.

Si no cumples estas expectativas, no importa que metodología, diagramas, UML y demás uses. Si no cumples estas fuera del mercado. El cliente te va a cambiar por otro que si cumpla su necesidad.

¿Qué es lo que tienes que hacer? buscar herramientas que te ayuden a cumplir con los requisitos mencionados, y además, lo más importante, que tu equipo (o el equipo donde estas) hablen el mismo idioma.

Lo mejor es estar siempre en un equipo donde exista una comunicación verbal y clara entre sus integrantes, donde se haga ruido, se discuta y se hable. Si trabajan cada uno en su lugar, con los cascos puestos, cada integrante se concentrara en la tarea que tienen asignada y no entenderá el concepto global del sistema, alargándose el desarrollo muchos más meses de lo previsto.

En cuanto al valor que le va a dar tu cliente a toda la documentación que hagas sobre su futuro sistema, es básicamente nula. El cliente quiere un software, no un documento, un UML, u otro tipo diagrama. El en cualquier caso necesita (antes de la construcción del proyecto) dos cosas:

• El tiempo
• El costo.

Tú (como analista) eres el que necesita documentos que garanticen que has comprendido lo que el cliente necesita, y allí es donde se convierten, dichos documentos, en una necesidad contractual, más que en una necesidad técnica.

Pero, ¿Sabes qué? El cliente no entiende que quiere hasta que lo ve. Es parecido a comprar un coche, hasta que no estás arriba, no sabes que quieres. Hasta que usuario no vea el sistema funcionando no va saber que quiere. El producto define la necesidad. Steve Jobs, por ejemplo, no hacia estudios de mercado precisamente por eso (a Ford, igualmente se le atribuye la frase “Si les hubiera preguntado a mis clientes que quieren me hubiera dicho que caballos más rápidos”).

Entonces el tema de la documentación se convierte mas en una necesidad “hacia dentro”, y no “hacia fuera”. Y allí depende más del estilo de empresa y del equipo que tengas, la necesidad de la documentación requerida.

Generalmente yo huyo de la documentación excesiva al crear un sistema, porque muchas veces es redundante, burocrática, y tiende en exceso a ser obsoleta. ¿Por qué?, porque muchas veces cambia tanto un sistema que la documentación inicial y el producto final, no se parecen en nada. Y si se parecen no será lo que el cliente quiere (por que al ver el producto se dará cuenta que quiere otra cosa).

Si quieres documentación, tienes que buscar herramientas y lenguajes que permitan llevar a la par la construcción y dicha documentación, que desde la documentación se pueda generar el código fuente y viceversa, que desde el código fuente se puede generar la documentación.

Las metodólogas agiles, de las que he hecho muy afín últimamente, dan más importancia a los productos que a la documentación. Solo hay que tener cuidado, porque a veces algún líder de proyecto, considera solo el punto de “poco documentación” de las metodologías Agiles, y se olvida de todo los demás, a lo que dan importancia dichas metodologías, y eso también lleva a un futuro desastre.

Me gustaría igual señalarte un problema que tienen los recién egresado, su trabajo acaba siendo los que llamamos “tareas de escuela”, soluciones técnicamente correctas que no tienen aplicación en el mundo real, ¿Por qué?, porque no vieron su trabajo en el contexto de un sistema real. Su meta fue programar un sistema, y esa, nunca es la meta, la meta es resolver una necesidad al cliente. En su enfoque nunca hubo un usuario manejando el sistema.