Paradigmas.

Los desarrolladores somos –¿hipótesis?- ante todo humanos, luego usuarios, luego desarrolladores.

Como humanos –entre otras cosas-, tendemos a sobrevalorar la propia experiencia. Por ejemplo, si el sistema que desarrollamos nos es fácil de utilizar solemos atribuirle esta característica obviando el hecho de que hemos aprendido a utilizarlo “desde atrás” (es decir, desde el código, el diseño o los requerimientos) y no “desde adelante” (desde la pantalla, los manuales o la capacitación). Para cuando nos enfrentamos a la pantalla de inicio ya sabemos casi de memoria todo lo que sigue. Abstraerse de este conocimiento es –por más que me juren y recontrajuren- imposible, y es por eso que nuestras pruebas y experiencias personales son bastante objetables como medida de lo que sucederá en el mundo real. Esto se aplica, con variaciones, tanto a desarrolladores como a analistas, testers, líderes de proyecto y a cualquiera implicado en el desarrollo de software (excepto, claro está, al cliente y al usuario).

Además de humanos –si es que damos por válida la hipótesis-, somos usuarios de sistemas de un determinado negocio: entornos de desarrollo, clientes de bases de datos, herramientas de diseño y documentación de requisitos, entre muchos otros, conforman el software de soporte al negocio del desarrollo de software. Negocio en el que estamos inmersos y que, como todos, tiene su paradigma establecido y materializado en la forma de determinados estándares: flujos de trabajo, herramientas visuales, disposición física de los objetos en una oficina… todo lo que nos rodea se deriva de éste en alguna medida.

La importancia de estos elementos –paradigma y estándares- que sobre el papel parecen un conjunto arbitrario de caprichos funcionales -¿por qué Ctrl+U y Ctrl+Shift+U? ¿Por qué un árbol y no una serie de listas encadenadas?- radica en que condicionan toda nuestra visión de la realidad (¡vaya si estamos condicionados por los paradigmas de nuestro negocio!). Los sistemas -si pretenden ser exitosos- deberán respetar –o revolucionar, pero esto es más difícil-, sobre todo en la interacción con sus usuarios, los paradigmas del negocio para el que fueron diseñados.

Como desarrolladores que somos –de eso sí estamos seguros- nos sería imposible, si estuviésemos librados a nuestro criterio, no aplicar el paradigma y los estándares propios del negocio al que pertenecemos –el desarrollo de software- a los sistemas que desarrollamos.

El problema es que, como establecimos más arriba, otros negocios o actividades tienen estándares y paradigmas diferentes. Internalizarlos es prácticamente imposible (deberíamos ser, por ejemplo, tan usuarios de distintos sistemas de gestión como lo somos de distintos entornos de desarrollo, tanto como lo es un empleado administrativo que ha transitado por diferentes empresas y puestos). Sólo podemos pretender, a lo más, conocerlos. Y para ello se requiere de una experiencia… “presencial”. Es la experiencia que trata de transmitir el analista funcional, el área comercial o quienquiera que tenga contacto directo con el cliente.

Pero un modelo mental es algo realmente difícil de describir, los estándares que se deriven de éste serán en su gran mayoría reglas y prácticas comunes y no estarán explicitadas en ningún lado. Es, en definitiva, difícil de transmitir. Por todo esto, cuantos más intermediarios haya entre aquellos que conocen a los clientes y usuarios y los desarrolladores, más probabilidades habrá de que nos apartemos del paradigma y los estándares a los que ellos están acostumbrados.

Entre la formación y la realidad.

Creo que hay una gran brecha entre la orientación que brindan las distintas carreras de sistemas y la realidad del mercado del desarrollo de software, por lo menos aquí en Buenos Aires y con respecto a la UBA (la Universidad de Buenos Aires, que es la universidad pública, gratuita y –por lo menos para las carreras que nos ocupan- de acceso irrestricto).

IMHO, por un lado el mercado requiere programadores para satisfacer una demanda creciente (incluso en estos tiempos de crisis) de desarrollo, mantenimiento (sobre todo), adaptación o implantación de sistemas de gestión de la información. Sistemas de pago, de facturación, de cuentas corrientes, de control de la producción, etc., y cada vez más orientados a negocios o rubros específicos (panadería, gestión de un taller mecánico, de una tienda de ropa), donde pequeñas empresas o equipos de desarrollo y profesionales independientes encuentran un nicho al que no pueden llegar los sistemas más conocidos como SAP o Tango (supongo que sólo tiene vuelo local, pero es muy conocido aquí).

Desde el punto de vista de la programación o codificación estos sistemas no son muy complejos… de hecho no son complejos en lo absoluto. Como se mencionaba hace algún tiempo en ¿Aburrido?, básicamente existe una base de datos que representa objetos y transacciones de la vida real, un software que materializa en múltiples pantallas de ingreso las reglas que indican cómo y cuándo esa información puede ser actualizada y un montón de reportes a través de los cuales es distribuida a través de la empresa o, hablando más en general, la organización.

Cada sistema tendrá algunas funcionalidades únicas (si no es así probablemente esté condenado al fracaso) o problemas particulares que representarán un verdadero desafío, pero no suelen representar más que un pequeño porcentaje de la funcionalidad total, y muchas veces son extras más orientados a diferenciarlo en la venta que al uso real y cotidiano.

El éxito o fracaso de un proyecto dependerá, más que de la pericia o ingenio de los programadores para crear algoritmos complejos que resuelvan problemas complejos, del conocimiento que posean, tanto éstos como los analistas y líderes del proyecto, del negocio que están modelando.

Este conocimiento tiene más que ver con facturas, recibos, remitos, balances, arqueos, tickets, inventario, impuestos, control de costos y esas cosas que con optimización, índices, grafos, métodos de ordenamiento, operaciones por ciclo de máquina, lenguajes, compiladores.

Eso por el lado del mercado.

El problema es que, del lado de la formación, las carreras de sistemas con contenido de programación poco y nada tienen que ver con el mundo de los negocios, y viceversa. Esa fue siempre mi sensación. Para este artículo estuve haciendo un poco de investigación tratando de verificarla o refutarla.

De las carreras de grado de la UBA, las que tienen algo que ver con sistemas son:

• De la Facultad de Ingeniería, la Licenciatura en Análisis de Sistemas y la carrera de Ingeniería en Informática. Esta última cuenta con tres orientaciones: en Gestión Industrial de Sistemas, en Sistemas Distribuidos y en Sistemas de Producción.

• De la Facultad de Ciencias Exactas, la Licenciatura en Ciencias de la Computación.

• De la Facultad de Ciencias Económicas, la Licenciatura en Sistemas de Información de las Organizaciones.

Más o menos a ojo (espero no haber pifiado mucho, si alguno de ustedes es o fue alumno de esas carreras me gustaría conocer su opinión al respecto), por los nombres de las materias, se deduce que:

• Para Análisis de Sistemas (Fc. de Ingeniería, 1739 alumnos) el 27% de las materias están orientadas a la programación propiamente dicha, y sólo el 7% tiene que algo que ver con lo administrativo, lo contable o la gestión de una organización.

• En Ingeniería en informática (Fc. de Ingeniería, 3194 alumnos), la programación ocupa entre el 26 y el 33%, contra un 4%, 2% y 15%, con la salvedad de que éste último porcentaje corresponde a la Orientación en Sistemas de Producción, por lo que imagino que estará enfocado a esa área.

• En la Licenciatura en Ciencias de la Computación (Fc. de Cs. Exactas, 1573 alumnos), los porcentajes son 38% contra… 0%. 38% para el lado de la programación, por supuesto. Debe ser duro para un egresado de esta carrera enfrentarse a un ERP o a un CRM armado sólo con lo que la universidad le ha enseñado.

• En la Licenciatura en Sistemas de Información de las Organizaciones (Fc. de Cs. Económicas, 1566 alumnos) nos encontramos que el estudio acerca del funcionamiento de la organización ocupa el 29% de la carrera (menos mal, ya que es de la Facultad de Ciencias Económicas), pero la programación sólo un 12%.

Pueden consultar la lista de materias (fuente oficial aquí, siguiendo el vínculo de cada carrera), cuáles conté para uno y otro lado y cuáles dejé afuera, aquí. La cantidad de alumnos proviene, desgraciadamente, del Censo de Estudiantes 2004, que es el último disponible (ese vicio tan habitual en la cosa pública Argentina, de ir a ciegas por la vida).

Es obligatorio aclarar que esto no dice nada acerca de la competencia de los profesionales que egresan de esas facultades (habrán buenos y malos en todos los casos). La experiencia aporta el resto y si hay algo que hace (en mi opinión) a la UBA una de las mejores universidades (seguro que de Argentina y puede que de Latinoamérica) es que sus alumnos salen con una innegable capacidad de seguir aprendiendo y enfrentarse a nuevos problemas, gracias también a que el resto de la plantilla brinda un conjunto de herramientas teóricas de carácter general que el profesional puede adaptar a su situación específica. Finalmente unos tendrán que aprender qué es eso de la partida doble y otros qué es una lista doblemente enlazada, si es que lo necesitan.

Se me dirá que se requiere de profesionales de más de una de esas carreras para completar un equipo. Cierto. En los papeles. Es verdad que en un proyecto mediano o grande habrán analistas (probablemente egresados de económicas) que interpreten el negocio y lo transmitan a los programadores.

Pero yo veo eso no como una característica inherente a los equipos de desarrollo sino como un problema (tal vez generado por la segmentación de las unidades de formación, las universidades) que afecta directamente al mercado de software “de gestión”.

Para un producto que pretenda concentrarse y especializarse en un nicho pequeño (lo que llamamos con cariño “el programita del verdulero”) un equipo de desarrollo compuesto por analistas y programadores es extremada e innecesariamente caro.

En general es un nicho cubierto por uno o dos profesionales que se ocupan de todo, incluso del management de su propio emprendimiento. Si son egresados de alguna de las carreras mencionadas deben superar un duro aprendizaje acerca de “la otra mitad” del negocio, para la que la carrera no los ha preparado.

Recordemos que en conjunto los sistemas de gestión representan la gran mayoría de sistemas existentes, los más cambiantes y dinámicos (tanto como los negocios que soportan), y por ello los que requieren más mano de obra en desarrollo y mantenimiento. Finalmente es donde van a trabajar la mayoría de los programadores, analistas, líderes de proyecto o profesionales independientes con cualquier orientación.

Pero lo que la universidad está produciendo es una mano de obra sobre calificada técnicamente (son los que o se aburren en el trabajo o resuelven los problemas más simples con los algoritmos más inútilmente complejos y eficientes, o no entienden los requerimientos) o en conocimiento del negocio (que producen ese software que resuelve exactamente lo que el usuario necesita pero que por dentro es un desastre y que finalmente se vuelve imposible de mantener o modificar).

Lo que sucede finalmente es que prima la realidad, la necesidad del mercado, y los profesionales se ven obligados a complementar su carrera con experiencia y cursos. En este contexto devalúa el título obtenido. Antes de llegar a ese punto (del que creo que hoy por hoy estamos lejos, pero acercándonos progresivamente) la UBA debería orientar alguna de esas carreras hacia un contenido más balanceado. Una carrera de la cual egrese un profesional que pueda programar algoritmos simples (validaciones, búsquedas, interacción con bases datos, cálculos, reportes) y que conozca el funcionamiento administrativo de las organizaciones (circuitos administrativos, documentos, conceptos contables básicos). Creo que la Licenciatura en Sistemas de Información de las Organizaciones es la que más se acerca, más que nada por el contexto que brinda la Fc. de Cs. Económicas, su proximidad con la carrera de Administración de Empresas y la de Contador.

Sobre requerimientos, comunicación y honestidad cuando las papas queman.

En Por dónde comenzar, hablando de gestión de requerimientos, Improbable ha dado a luz un párrafo genial que le da de lleno a mi falta de paciencia para con el área de análisis funcional (por lo menos con la que me toca convivir). Dice:

[…] recuerdo los valores ágiles de responsabilidad, honestidad, y demás virtudes. Pero ocurre que la gente es gente, y cuando las papas queman y alguien pregunta por determinados retrabajos o por qué se ha invertido seiscientas horas de desarrollo en algo que debería haber tardado doscientas, no es descabellado esperar que quien nos ha guiado a través de un camino sinuoso intente endilgarle la responsabilidad a otro. Quiero decir: que un Product Owner que nos ha hecho trabajar y retrabajar haciendo una cosa y luego la contraria continuamente intente explicar el poco valor conseguido luego de un tiempo considerable hablando de la falta de habilidades técnicas de los programadores.

#define evil_mode=1;

Pocas cosas son más molestas que cuando, sin haber cometido ninguna falta –condición más que fundamental para lo que sigue-, la gente se preocupa más por cubrirse que por hacer el trabajo, con actitudes como cambios que no se pasan por escrito, horas que se distribuyen entre otras tareas para ocultar retrabajos, olvidos sugerentes y demás.

Y es porque me da la sensación de que esto genera espejismos hacia la gestión del proyecto, que a falta –razonable y esperable- de conocimientos técnicos se guía por la percepción del desarrollo que nosotros exponemos, acumulada en forma de experiencia. Espejismos que luego nos juegan en contra.

Así, si nos “da vergüenza” pasar una semana con una funcionalidad que parece trivial y para la que estimamos dos horas, y en vez de poner el esfuerzo en explicar lo sucedido distribuimos esas horas en otras tareas, estamos fortaleciendo la imagen, por ejemplo, de que somos buenos estimando y de que lo que parece fácil es fácil. Estamos fijando un piso que difícilmente podamos mantener.

Pero una cosa es “distribuir horas” y otra es tirar la basura al patio del vecino (como describe el párrafo citado), siendo más conveniente (aunque harto más difícil) explicar a la gestión que los requerimientos no eran claros y que por presiones de tiempo se comenzó a programar lo antes posible, por lo que buena parte del tiempo de desarrollo fue en realidad tiempo de aprendizaje, prueba y error, ajuste y corrección sobre la marcha… una situación que simplemente se dio así y que no tiene nada de malo per sé…

…a menos que creamos que no somos tan buenos como deberíamos en lo que hacemos.

#define evil_mode = 0;

Medir la calidad de los requerimientos.

Los requerimientos cambian. Todo cambia.

La revolución de las metodologías ágiles no ha hecho más que establecer el factor cambio como inherente al desarrollo e integrarlo en el proceso (a través de ciclos cortos de desarrollo, reuniones periódicas, programación de a pares, programación orientada al test y un sinnúmero de otras técnicas) en vez de combatirlo (con planeamientos detallados, seguimientos rigurosos, requisitos enciclopédicos, etcétera).

Sin embargo, “eXtreme Programming es un arma peligrosa”:

[…] Se suele utilizar XP menos para desarrollar que para defender lo indefendible y justificar lo injustificable por la supuesta búsqueda de "agilidad" […]

Hablando de requerimientos, tengo la sensación de que muchas veces se esconden gruesos errores bajo una alfombra maloliente etiquetada “cambios en el negocio”. ¿Cuándo hubo un cambio en el negocio y cuándo un error al elaborar los requerimientos?

No estoy hablando aquí de errores de interpretación de un término o de la existencia de ciertas áreas grises en las definiciones, porque errores de ese tipo se van corrigiendo en la medida en que avanzan las iteraciones y el equipo toma conocimiento del negocio.

Estoy apuntando a cuando se producen repetidamente (casi diría sistemáticamente) errores de procedimiento o metodológicos al efectuar los relevamientos o al producir y comunicar los requerimientos. Es decir, errores que afectan a todos y cada uno de ellos porque son fallas de los procedimientos, de la metodología o de las personas involucradas en su producción.

Me mencionaron alguna vez el caso de una empresa en la que los requerimientos llegaban en forma de gráficos perpetrados en un lenguaje pseudo-uml que ningún programador entendía. Finalmente, lo único útil del documento era el nombre del analista. Se fijaban quién era, lo llamaban y (si estaba disponible) le preguntaban qué había que hacer. Pero el problema era que esta charla informal no tenía ningún soporte ni revisión dentro del circuito de desarrollo, y usualmente los requerimientos se… digamos…. “modificaban” durante su transmisión. ¡Un fin de semana largo y su consecuente amnesia podía redefinir sustancialmente el proyecto!

Nótese que en presencia de este tipo de problemas las sucesivas iteraciones pueden alejarnos más y más de lo que el cliente quiere, porque el canal de comunicación entre él y el equipo de desarrollo está roto o tiene demasiado ruido. En nuestro ejemplo, ruido en la forma de dibujos incomprensibles pasados como requerimientos. Más valdría, por ejemplo, formalizar esas “charlas” como una instancia de elaboración de un documento simple y que todo el mundo entienda, tal vez directamente en idioma coloquial y con algunos dibujos hechos a mano.

Si tenemos contacto asiduo con el cliente (deberíamos), los problemas se notarán más temprano que tarde. Él mismo indicará claramente (muy) que no está recibiendo lo que pidió. Pero imaginemos que no sabemos nada del origen de esta discordancia. Puede venir por el lado de los requerimientos, pero no lo sabemos.

De alguna manera hay que medir, al menos aproximadamente, la calidad del proceso de relevamiento y la de los requerimientos mismos. Esto implica analizar, para alguna muestra relevante:

• el ajuste con respecto a la solución finalmente implementada. ¿Estamos contactando a las personas correctas en el cliente?

• el ajuste respecto a lo que el cliente o sus representantes expresaron. ¿Los clientes son bien interpretados?  

• el grado de claridad o precisión que le asignan los desarrolladores (que son finalmente los consumidores de esos requerimientos). ¿Los requerimientos están bien redactados o presentados?

• el grado de ajuste de la herramienta de soporte o metodología utilizada. ¿Es fácil producir un soporte estable para cada requerimiento? ¿Ese soporte los altera de alguna manera? Recordemos que por más ágiles que seamos, deberemos almacenar por lo menos los requerimientos en curso sin que sean modificados (involuntaria y/o inadvertidamente) de manera que alguien pueda consultarlos con seguridad ante alguna duda.

• La calidad del análisis efectuado sobre cada uno. ¿Se detectaron interacciones con otras partes del sistema? ¿Se evaluó bien la coherencia del requerimiento?

El problema está en encontrar indicadores para estas mediciones, ya que me parecen bastante… sutiles.

Por ejemplo, es “normal” que algunas interacciones entre nuevos requerimientos y otras partes del sistema no sean detectadas, ya que el análisis análisis previo es breve y a grandes rasgos. Pero otras interacciones son obvias y que sean pasadas por alto es significativo.

Por otro lado si somos muy ágiles y prima la comunicación informal, medir algunas cuestiones implica “muy poco indirectamente” medir el desempeño. Necesariamente habrá que preguntar “¿Se entiende cuando ZZZ explica lo que hay que hacer?” y esto generaría una recelo excesivo.

Es todo cuestión de encontrar las preguntas… qué novedad.

La realidad de los programadores.

Rebotando por Mi delicious me topé con esta viñeta del muy recomendable Sinergia sin control. Espectacular.

Visto en El Blog de Inwe.