El desarrollo de software como sistema, y nosotros adentro.

Un emprendimiento de desarrollo de sistemas puede encuadrarse en infinidad de teorías, modelos, directivas, recetas. La teoría de sistemas ofrece la gran ventaja de ser conocida por la mayoría de los involucrados (o por lo menos debería serlo). Al fin y al cabo, en un emprendimiento de desarrollo de sistemas estamos desarrollando exactamente eso. El emprendimiento es un sistema (administrativo) que desarrolla sistemas (de computadora).

Ok. Este sistema es una secuencia E-P-S-R: Entrada-Proceso-Salida-Retroalimentación. ¿Les suena? En informática describimos casi todo de esta manera: algoritmos, software, hardware, negocios. ¿Por qué no describir así el proceso de desarrollo? ¿No es acaso un "negocio" como cualquier otro?

Utilizamos entonces la misma secuencia de que utilizaríamos para analizar cualquier requerimiento: establecer la salida (qué es lo que el sistema debe hacer), la entrada (qué necesita para hacerlo), y luego abrir esa caja negra llamada proceso (cómo lo hace).

En nuestro caso la salida (del sistema de desarrollo de software) es un sistema compuesto por piezas de software, hardware y documentos orientados a una tarea específica. En la entrada del sistema tenemos los requerimientos del usuario, palabra santa. Y en el proceso tenemos todos los subsistemas necesarios para transformar una lista de requerimientos en software, hardware y documentación: analistas, programadores, líderes de equipo, líderes de proyecto, testers, expertos en base de datos, expertos en infraestructura... Pero también, y esto es algo que en general no se tiene muy en cuenta: personal de ventas, de atención al cliente, de facturación, de recursos humanos. Tenemos computadoras, redes, software de desarrollo de todo tipo (para el análisis, entornos de programación, compiladores, versionado), software de administración de base de datos... Pero también tenemos software de administración de todo tipo (ventas, facturación, atención al cliente, pago de sueldos), un lugar físico, escritorios, cafeteras (espero), plantas (donde yo trabajo no), baños (sí, eso sí tenemos, pero...), personal de limpieza... la lista es interminable, pero la idea final ya tiene que haberse entendido: tenemos una empresa, grande o chica, miles de empleados o dos amigos programadores con un cliente ocasional, con todo lo que ello representa.

Para la descripción del proceso de desarrollo se han escrito selvas enteras de papeles, y llenado varios gigas de información. Las teorías y procesos tradicionales pueden resumirse en una secuencia de: análisis, diseño, construcción y pruebas (todo en uno), implementación. Con sus variantes, por supuesto. Luego tenemos una infinidad de variantes iterativas: en esperial, escalonadas en tirabuzón o calesita, todas ellas repiten de alguna manera la secuencia arrojando porciones del producto final en cada iteración.

Pero falta algo... dijimos entrada, proceso, salida... retroalimentación. ¿Dónde está la realimentación en un sistema de desarrollo de sistemas? Empezemos por el principio: ¿Qué es la retroalimentación en este contexto? Voy a tratar de atrapar la idea: una vez que un proceso de desarrollo alcanza cierta madurez, puedo examinar el resultado con el ánimo de mejorar el proceso. Retroalimentación implica que la salida de un sistema lo modifica. En todo desarrollo se examina el resultado (el software, por ejemplo, o los documentos) y se habla de control de calidad, excelencia, 0 defectos... pero no es esto de lo que hablamos aquí. Podemos tener un producto excelente en tiempo y forma y clientes satisfechos, pero al mirar hacia atrás nos damos cuenta de que hemos atravesado un infierno para llegar a ello: requerimientos contradictorios, problemas con los equipos, tiempos muertos, personal inexperto... ¿Qué importa, si al fin y al cabo el producto es bueno y el cliente está contento? Dirección por resultados, que le dicen.

Ok. Los resultados son indispensables. Sin resultados no hay desarrollo... pensemos un poco en esto. Si no hay desarrollo sin resultados entonces no hay empresa de desarrollo sin resultados... entonces... Todas las empresas y emprendimientos existentes brindan resultados. Algunas brindan mejores con mayor frecuencia. Pero si no lo hicieran no sobrevivirían. Es la lógica darwiniana de cualquier mercado. Así que tenemos que mejorar el proceso para competir.

Pero lo más importante: nosotros como personas somos parte del proceso, estamos dentro de él. Digo, nuestro trabajo (analista, programador, administrador de base de datos, el que sea) ocupa buena parte de nuestro tiempo, y no es sostenible sólo por los resultados. Puedo ganar buen dinero y estar contento con las felicitaciones de mi cliente... mientras me repongo de mi pico de estrés, de mi ataque cardíaco, o simplemente mientras duermo las 72 horas que tengo atrasadas o trato de recordar el nombre de alguien de mi familia, etc.

Muchas veces, cuando al final "todo" sale bien tendemos a creer que hicimos bien las cosas, y puede estar pasando una de dos: los problemas están por venir (muy probable) o en algún momento alguien lo hará mejor. Pero incluso si eso no se da y todo sigue bien... podríamos hacerlo con menos esfuerzo que y dedicarlo a cualquier cosa que nos guste (no necesariamente trabajar).

Conclusión: como profesionales, como personas, nuestro interés está en la retroalimentación positiva a partir no sólo de los resultados sino de examinar cómo hemos atravesado el proceso. El buen producto mejorará más o menos la vida del cliente, pero la retroalimentación mejorará la nuestra.