La interfaz del usuario en un sistema de gestión.

Hablando puntualmente de sistemas de gestión tenemos en realidad varias interfaces de usuario:

1. Orientada a la captura de datos.
2. Orientada a la obtención de información.
3. Orientada al análisis o búsqueda de información.

Recorramos cada una de ellas.

Orientada a la captura de datos: El usuario es un operario o empleado abocado a una tarea cuyo foco está fuera del sistema de gestión: atender a un cliente, a un proveedor, pagar una factura, recibir materiales. Otra posibilidad es que la carga de datos sea el objetivo en sí mismo (un data entry).

En el primer caso contamos con la mínima atención por parte del usuario, que tal vez ni siquiera mire la pantalla. En el segundo estará concentrado en el ingreso y verificación y su atención al resto de la pantalla será nula.

Lo esperable es una infinidad de pantallas prácticamente iguales, los clásicos ABM o CRUD. Aquí la regla número uno es simplemente no innovar. El usuario probablemente trabaje o haya trabajado con otros sistemas de gestión y espera algo muy específico: dato – [enter o tab] – dato – [enter o tab] – dato – [enter o tab] – fin. Cualquier cosa que se aparte de este camino le resultará molesta y probablemente inútil.

Este escenario sugiere el minimalismo, la simplicidad absoluta en el diseño de la interfaz. Esto coincide con las necesidades del desarrollo: es casi imprescindible generar estas pantallas a través de algún método en el que se ingresan los campos necesarios y la pantalla se genere automáticamente, asegurando la consistencia en el método de ingreso.

Orientada a la obtención de información: Nuevamente el objetivo central no es la información en sí. Será el control de la facturación, del inventario, de un envío o despacho de mercadería, etc. Son informes estándar, rutinarios y usualmente orientados al control de la operación.

Debería primar el minimalismo. Pocas opciones, pocos datos, y dispuestos de manera tal que facilite el control para el que fueron diseñados.

Aquí es donde fallan algunos sistemas. Estos reportes son usualmente puestos en la misma bolsa de los reportes de análisis, cuyo objetivo es otro (ya veremos). Es cuando el usuario se encuentra con un sinfín de posibilidades (vendidas como reportes “personalizables”, “configurables”, “autocustomizables” u otra palabra más o menos rara) en un momento poco oportuno. Si la tarea es rutinaria, ¿por qué el sistema me pregunta cada vez qué es lo que quiero?

Otras veces el reporte entorpece más de lo que ayuda, usualmente por algún detalle menor, que se vuelve terriblemente molesto.

Caso típico: el orden. Un ejemplo que me toca de cerca: cada vez que voy a buscar el recibo de sueldo me preguntan por el número de legajo que, obviamente, nunca recuerdo. Así que doy la única información de la que dispongo: mi nombre. Se imaginarán lo que sucede: hay que buscar secuencialmente entre todos los recibos, una y otra vez.

La “solución” a veces viene en forma de parche delirante: una segunda lista de empleados ordenada por nombre. Primero se busca allí el legajo, luego en la pila de recibos el correspondiente… un índice. Se le ha transferido al usuario parte del trabajo de la base de datos. Debería transferírsele también parte del sueldo del analista que diseñó el reporte.

La “customización” debería estar del lado del desarrollo, o de la parametrización, pero en todo caso del lado del proveedor de software. Al fin y al cabo éste debería ser producto de las horas de análisis funcional presupuestadas.

Muchas veces, amparado bajo el rótulo de “informes configurables”, el proveedor de software transfiere parte del análisis funcional al cliente -o lo que es peor, al usuario- al desligarse de la responsabilidad de decirle al sistema qué es lo que necesita. Esto no será un defecto siempre y cuando esa transferencia de costos se refleje en la factura del software.

Sin embargo, el problema de transferir esta decisión al usuario final es la posibilidad constante de error. Si para cada operación de control se solicitan más parámetros de los estrictamente requeridos para el reporte, un error en el ingreso de éstos es un error en el control.

Si se transfiere la responsabilidad al cliente –no al usuario, al cliente- y el personal -no necesariamente expertos en la administración del sistema- se equivoca en el armado de un reporte customizable podrían estar viciadas todas las operaciones de control derivadas.

Éstos son los “ABM” de los reportes. También deberían ser generados automáticamente durante el desarrollo. Es, en mi experiencia, la opción más simple.

Otra posibilidad, que dependiendo de las circunstancias podría llegar a ser más compleja o no, sería la creación de un módulo de reportes configurable. Pero… ¿no estaríamos recreando de alguna manera una herramienta de reporting, pero con menos posibilidades y orientada a un negocio específico? ¿no estamos reinventando la rueda? ¿no sería más simple utilizar una herramienta ya existente y entregar los reportes ya armados? No hay respuestas únicas. Pero éstas son preguntas que siempre deben estar presentes en la decisión.

Orientada al análisis o búsqueda de información: En este caso el usuario es un gerente, un ejecutivo de alto nivel, enfocado hacia el negocio, no hacia la operación. No sabe qué es lo que quiere, simplemente busca. ¿Qué busca? Muchas veces no lo sabe. Una variación, una anomalía, un producto que se desenvuelve mejor en un área que en otra (¿cuál? ¿en dónde? ¿por qué?).

Es, muchas veces, quien ha decidido, decidirá o puede decidir la compra, la adopción o la continuidad del software. Es El Cliente, con mayúscula.

Éste es el mundo de la “información estratégica”, y es aquí donde puede lucirse un sistema de gestión. Y puede hacerlo de dos maneras:

1. Mostrando un conocimiento profundo del negocio, presentando reportes de análisis desconocidos para el usuario-cliente con información relevante.
2. Presentando una interfaz que le permita navegar intuitivamente, buscar y encontrar aquélla información tan valiosa.

Para el equipo de desarrollo el primer camino es el de la experiencia, el segundo el de la pericia, la creatividad y la inversión en interfaces de usuario (los usuarios de Google Analytics sabrán a qué me refiero con pericia, la interfaz es bastante simple y permite hacer prácticamente cualquier cosa).

Las herramientas de data warehousing o almacenes de datos son una posibilidad, pero usualmente demasiado complejas para este tipo de usuarios. El desafío es adaptarlas de acuerdo al perfil concreto del cliente y del negocio en el que se desenvuelve. Delegar esta tarea en el cliente mismo, si bien es posible, implica arriesgar aquella funcionalidad en la que se podría marcar la diferencia.

En resumen: un sistema de gestión puede ser enorme, pero su desarrollo puede ser prácticamente automático. La energía debería concentrarse en las herramientas de generación automática (para las interfaces de ingreso de datos y reportes de control) ganando en bajo coste y velocidad en el desarrollo, y en la interfaz de análisis estratégico, donde puede diferenciarse de los demás productos o encontrar un nicho de negocio protegido.

Requerimientos de la gestión y soluciones sistémicas.

A la hora de satisfacer las necesidades de información de la gestión de un proyecto informático podemos aplicar esfuerzo adicional (una serie de acciones para recabar esa información intercaladas en el trabajo diario) pero difícilmente logremos mantenerlo durante mucho tiempo.

Sobre todo cuando por “esfuerzo adicional” entendemos hacer una parada en el desarrollo, revolver dolorosamente viejos papeles desordenados (a veces ni eso) y rellenar agujeros de memoria para terminar garabateando con desgano un par de números más o menos dibujados en forma de informe de avance.

Una solución sistémica para esas necesidades requiere una visión más amplia y más esfuerzo inicial pero logra que la información surja naturalmente del flujo de trabajo e incluso que lo acompañe de forma tal que en lo sucesivo el esfuerzo sea menor.

Estuve jugando mucho con esa idea, enfocándola primero hacia el tema de los errores en Parches y soluciones y relacionándola después con el conocimiento que aportan a la organización (plasmado en circuitos administrativos estables), en Implementando y manteniendo soluciones. 

Hoy encontré en Ideas + Ingeniería del Software (aunque llego con un poco de atraso) un artículo sobre trazabilidad que tiene mucho que ver con esto y del que me ha quedado especialmente la frase final:

“¿Moraleja? Si tienes que forzar a tu equipo a algo, la culpa no es del que no te hace caso, sino tuya. Las herramientas adecuadas para las tareas adecuadas.”

Hay que tener en cuenta que no es necesario inventar nada, la solución y las herramientas ya están ahí afuera (aunque habrá que hacer algún ajuste, eso seguro).

Al fin y al cabo son necesidades comunes a todos los equipos de desarrollo –a la gestión de cualquier proyecto-, por lo que en la práctica han surgido muchas alternativas y varias de ellas han sido formalizadas en metodologías. ¿Por qué no utilizar esa experiencia?

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.

Limitaciones de los modelos ágiles (y de todos los modelos).

Navegápolis nos refiere un muy interesante artículo de Bruno Collet: Limitations of Agile Software Development.

En él se describen y analizan algunas limitaciones percibidas en los modelos ágiles de desarrollo:

1. Equipo de estrellas.
2. Encaje con la cultura organizacional.
3. Tamaño del equipo.
4. Ubicación física del equipo.
5. No hay apoyo de procesos.

Obviamente está en inglés, largo pero de fácil lectura. Vale la pena el esfuerzo.

Mi personalísima opinión –bastante en sintonía con el autor del artículo- es que ninguna metodología en estado puro (“de libro”) es aplicable en la vida real sin ajustes, y que por sobre cualquier otro criterio debe primar el pragmatismo, sin olvidar la precaución (no seguir las modas o novedades), y el gradualismo (las revoluciones son muy emocionantes, pero…)

Es importante recordar que el objetivo del desarrollo es crear software, por lo que la metodología es un medio que debe estar en línea con ese objetivo, no un fin en sí mismo.

La situación actual es siempre un punto de partida. Cada problema tiene origen en alguna debilidad del proceso, que de alguna manera permitió su aparición. Sobre esto escribía en Parches y soluciones:

[…] puede pensarse en un parche y una solución para cada problema […] El parche es la actividad que resuelve la situación puntual, mientras que la solución es un cambio en la metodología de trabajo o en el circuito administrativo dentro del equipo que torna imposible la situación que originó el error.

Siempre se parte de una realidad existente, no importa si es el primer proyecto independiente de dos amigos/socios o un proyecto de mantenimiento en una gran corporación. Durante la marcha (o en algún momento de evaluación) surgen dificultades, cuellos de botella, errores, omisiones o indefiniciones.

Son éstos problemas e ineficiencias concretas, nuestros problemas y nuestras ineficiencias las que se deben corregir. Y para ello está disponible no sólo la experiencia volcada en las metodologías ágiles sino en cualquier otra, incluso de diferentes ámbitos o industrias.

En resumen:

• pragmatismo. trabajar sobre lo concreto: problemas concretos, soluciones concretas.
• experiencia: referirse siempre a la experiencia. A la nuestra o a la ajena, pero no reinventar la rueda. Puede que un producto sea original, novedoso y único, pero créanme: los problemas en el proceso que lleva al desarrollo de ese producto no lo son. Antes de ponerse creativos es mejor hacer una búsqueda en google.

Responsabilidades en el desarrollo de software: Del error a la catástrofe.

Este post viene a cuento del intercambio iniciado en Iboisset's Ruminations, en los comentarios de la entrada Responsabilidad de Qué.

La frase que da el puntapié inicial es de diazjc, en Twitter:

En nuestro sector lo que veo es que el informático no sabe el coste real de sus fallos, de sus acciones, su responsabilidad.

Dos artículos me vinieron inmediatamente a la mente. Al primero lo había referenciado en Gestores vs. realidad. Es Cuando los ingenieros se ponen en la piel de los gestores, de Historias de la ciencia. Llegué a él a través de Engañemos a la realidad, artículo de Un Punto Azul Pálido que también viene al caso.

Se comenta el accidente del Challenger. Sin entrar en detalles aquí (el artículo es absolutamente recomendable), resumo lo que viene al caso:

[...]Los ingenieros de Morthon Thiokol volvieron a advertir a sus jefes y a los responsables de la NASA del Centro de Vuelo Espacial Marshall, quienes gestionaban las relaciones con el contratista, que las frías temperaturas de la Florida podían tener un efecto negativo sobre las juntas tóricas.[...]

[...]La presión desde arriba, las dudas sobre los datos y la insistencia en que pensara “como un gestor y no como un ingeniero” fueron suficientes para que Lund cambiara de parecer. Se sumó a los otros gestores de Morthon Thiokol y, pasando por alto la opinión de sus ingenieros, certificó la seguridad de los cohetes aceleradores para el lanzamiento.[...]

[...]Como ingeniero, me vais a permitir unas reflexiones. Estoy seguro que Bob Lund, el ingeniero al que presionaron “para que se pusiera en la piel de un gestor”, se sintió terriblemente responsable por ceder ante la presión. Sin embargo, sospecho que Mason, aquel ejecutivo que le presionó, se lavó las manos de cualquier responsabilidad, ya que él nunca tuvo que estampar su firma para garantizar la seguridad de los cohetes aceleradores y no era responsable de la seguridad de los mismos.[...]

El segundo es uno que referenciaba en La cadena del error. Es un artículo de TCAS Aviation Blog (a cuento de las repercusiones del accidente del avion de Spanair en Barajas) que había aparecido como referencia en Dirección de proyectos:

[...]Que un avión salga en hora es un milagro. ¿O no?

No es tanto un milagro si no un éxito del sistema, que funciona. Pero está claro que no siempre. Normalmente cuando alguno de esos elementos no funciona en el momento que le corresponde o de la manera que toca, se producen incidencias en la operación de mayor o menor calado, y que normalmente afectan tan sólo a la puntualidad o a la economía, nunca a la seguridad.

¿Pero qué pasa cuando son varios elementos los que fallan simultáneamente?

Ahí es donde entra el concepto de la cadena del error. Imaginemos que desde el primer “mal funcionamiento del sistema” hasta el último hay cinco eslabones, y el quinto significa un accidente. Es relativamente fácil que el primero aparezca, puede incluso que el segundo lo haga, es posible que aparezca un tercero, pero alguien, en algún momento (incluso sin llegar a saberlo) debería haber roto alguno de esos eslabones, impidiendo así que llegara el cuarto, y mucho menos el quinto. [...]

Creo que se entiende hacia dónde voy... volvamos al desarrollo de software.

En principio, diferenciemos claramente "error" o "fallo" de "catástrofe" o "desastre". Según la RAE:

• Fallo: Falta, deficiencia o error.
• Catástrofe: (1) Suceso infausto que altera gravemente el orden regular de las cosas. (5) Cambio brusco de estado de un sistema dinámico, provocado por una mínima alteración de uno de sus parámetros.

¿Cuál es el coste real de un fallo de un informático? ¿Cuál es su responsabilidad?

Un negocio es un sistema, diseñado por una o varias personas, con el objetivo de ganar dinero. Un sistema de software es uno de tantos subsistemas de un negocio. Puede ser más o menos importante, central o periférico (no es lo mismo la venta de pañales que una red social con publicidad), pero nunca deja de ser parte de ese sistema más grande, el negocio.

Ese subsistema de software es construído por muchas personas (necesariamente) que conforman, junto con otros elementos, un sistema de desarrollo de software. Ahí están "los informáticos". Muchas veces este sistema de desarrollo excede los límites de lo que llamamos "empresa": puede estar compuesto por personas del lado del "cliente" y del lado de "el proveedor del sistema".

El objetivo del subsistema de software está acotado por el del sistema "negocio" al que pertenece. Lo que quiero dejar en claro en este punto es que el objetivo del subsistema "software" no puede ser "ganar dinero", porque ése es el objetivo del sistema "negocio" que lo contiene.

En el lenguaje cotidiano, cuando hablamos de "desastre" o "catástrofe" informática estamos hablando de pérdida de dinero o de cualquier situación que pueda traducirse en tal. Si hay una pérdida de dinero, el sistema que está fallando es el "negocio", porque ganar dinero es su objetivo, y no lo está cumpliendo, o deja de cumplirlo por un período de tiempo determinado, o en vez de ganarlo lo está perdiendo.

Ahora, ¿quién o quiénes son los responsables del negocio? ¿"El informático"?

El origen de una catástrofe (léase: evento que implica pérdida de dinero, fallo del negocio) puede estar en el subsistema de software. Es como decir que el primer eslabón en la cadena del error (que mencionaba arriba, en el artículo sobre el accidente de Spanair) se encuentra en ese subsistema.

No puedo hablar de otros subsistemas (recursos humanos, gerencia, ventas, facturación...), pero si hay algo que conozco bien son las características generales de un subsistema de software.

Una de ellas es: este sistema, tarde o temprano, fallará (probablemente como cualquier otro, pero yo soy experto en éste, y no quiero pisar terreno desconocido).

Si un programador dice que su código no tiene errores miente o peca de soberbia, y se equivoca.

Si un administrador de base de datos manipula la base sin un resguardo, está pecando de soberbia (eventualmente se equivocará). Si lo están obligando o presionando a ello estamos en una situación como la que describíamos arriba, hablando del Challenger.

Lo mismo sucede cuando se administran redes, proyectos de desarrollo, o cualquier elemento informático.

Cuando un líder de proyecto presiona a los programadores para que escriban código sin errores, no hace más que mostrarle al mundo su absoluto desconocimiento del desarrollo.

Cuando un cliente o empresario se apoya únicamente en un sistema informático para hacer funcionar su negocio está pecando de soberbia, ceguera, optimismo, pensamiento mágico, mala administración, falta de previsión... muchas cosas. Pero bueno, es su negocio y es libre de llevarlo como le venga en gana.

Entonces, cuando un cliente o empresario se queja de que el software le ha hecho perder dinero, demuestra que no ha sabido o sido capaz de crear un sistema de negocio tolerante a un fallo en uno de sus subsistemas. Un subsistema con alta probabilidad de fallo, característica harto conocida por todo el mundo.

¿O ha sido engañado por alguien?

Volvamos a la frase:

"[...] no sabe el coste real de sus fallos [...]" : No, no lo sabemos. No lo sabemos porque somos parte de un sistema externo (de desarrollo de software) que crea un subsistema (de software) que es parte del sistema en el cual se puede hablar de "coste" (el negocio)... y a veces ni siquiera eso (si el sistema de software es de depósito, por ejemplo, habría que agregar un nivel más).

A ver, yo escribo una línea de código para un sistema que conozco bien en cuanto a su flujo de información (lo administrativo), pero del cual desconozco completamente sus números monetarios, su aporte al negocio (porque se me ocultan, y en todo caso no me interesan más que como curiosidad). ¿Cómo podría evaluar el coste de un fallo? ¿Si el software falla, puede mantenerse la operatoria "a mano"? ¿Cómo podría saber yo eso?

Sólo saben decir 'ya está arreglado, ya no falla': obviamente. Es lo único que podemos decir. Es la única información de la que, como informáticos, disponemos (cuando la tenemos, que no es siempre).

Ésta es la dura verdad, aunque podemos ser soberbios y pensar que realmente somos responsables por todo lo que ocurre en "el negocio".

Lo demás, es limar asperezas. Podemos asumir responsabilidad sobre un sistema que no controlamos para quedar bien con el cliente. Puedo no decirle al jefe del equipo que el problema no está aquí para quedar bien o para no enojarlo. Puedo no decir "¿dónde están los procedimientos alternativos?", arremangarme y corregir las cosas lo más rápidamente posible. Podemos tener conciencia de equipo y ayudar en todo lo posible.

Si éstas son las actitudes que el autor de la frase siente en falta, puede ser. La vida es más fácil cuando están presentes. Pero hay veces en las que es difícil ser comprensivo y ponerse la camiseta cuando un cliente, líder de proyecto o jefe de lo que sea descarga su ira hablándonos de números sin sentido, pidiendo explicaciones que no quiere escuchar, y exigiendo que hagamos lo imposible: no generar errores.

(Las imágenes en caricatura de este post fueron encontradas en El ciclo de la vida, en "El rincón de Basulto".)

Estimaciones y responsabilidad.

Me han quedado dando vueltas por el fin de semana las cuestiones que planteaba en el último artículo, Estimaciones y compromisos.

Por un lado lo he charlado un rato con los colegas del trabajo. También se lo he referido a Yuki en su blog De consultor a Director de TI. Pueden ver su respuesta en los comentarios de esta entrada.

Quisiera desarrollar el tema de la responsabilidad, que surge de la transformación de la estimación en un compromiso, situación comentada en La masa, el ladrillo, la bota, el bocadillo... de la siguiente manera:

Generalmente cuando recibimos estimaciones es porque nos encontramos en una situación de autoridad dentro del proyecto y nunca debemos olvidar que la autoridad conlleva responsabilidad. Somos responsables de cómo tratamos estas estimaciones. Y la máxima es clara: No conviertas las estimaciones que recibes en compromisos.

Desarrollando esa idea, desde el punto de vista de los desarrolladores que elaboran esas estimaciones, había escrito:

¿Somos responsables del error? Del error de asumir el compromiso en ciertos términos, quiero decir. No digo del error de estimación, ya que no considero que la estimación sea errónea (¿lo es?). Por más desviada que esté, ese desvío refleja nuestro desconocimiento al momento de hacerla. Creo que no es lo mismo que un error (que sí sería uno de cálculo por ejemplo).

El hecho de si una estimación fallida es un "error" o no es una cuestión casi teórico-filosófica. El hecho es que el proyecto se encuentra desviado respecto de ella, y punto.

En las causas del desvío pueden converger un sinfín de factores. Tiendo a pensar ahora que el de más peso es la falta de experiencia. Estamos estimando, y obviamente no tenemos información completa. De todas maneras, toda información está referida al pasado, a un contexto diferente y en situaciones que no tienen garantía de repetirse. Pretender lo contrario sería requerir una bola de cristal.

Estimamos entonces utilizando nuestra experiencia. Y ponemos en juego nuestra habilidad para extrapolar esas situaciones al futuro, reconociendo similitudes y diferencias y tratando de asignarles un valor en horas.

¿Y si no tenemos experiencia? Bueno, por algún lado se empieza. Prueba y error, y probablemente al principio sean todos errores.

Ahora, el tema de la responsabilidad. En un proyecto cerrado hay que comprometer una fecha con el cliente. Esto es inevitable y razonable, son las reglas del juego. Es un compromiso que no puede eludirse.

Entonces, ante las preguntas que había planteado:

¿Nos hacemos cargo del compromiso asumido, dado que no hemos sido nosotros quienes lo hemos hecho? ¿Cómo? ¿Trabajamos más horas? ¿Aceptamos hacerlo gratis? ¿Hasta qué punto?

Creo que la primera respuesta es sí. Nos hacemos cargo del compromiso, porque no podemos pretender que ignorábamos las reglas del juego al momento de estimar. El tema es cómo.

Tenemos la responsabilidad de llegar a determinada fecha. Y de ser imposible, tenemos la responsabilidad de avisar apenas seamos conscientes de este hecho. Responsabilidad no implica hacer lo imposible, sino hacer todo lo posible.

¿Y qué es "todo lo posible"? Ahí está el punto. Sólo cada uno de nosotros sabe qué es lo que está dispuesto a dar. "Todo lo posible" es, en lo material, muy diferente para un joven recién egresado (digamos que vive solo y sin muchos compromisos familiares) y para una persona casada y con hijos (sobre todo) que siente una responsabilidad "de estar presente" mucho mayor para con ellos. Es, en todo caso, un tema personal.

Lo que no es personal es el compromiso para con el equipo. Que se traduce en dejar en claro de qué manera y bajo qué condiciones estamos disponibles. Se trata de volvernos previsibles, de dar predictibilidad al proyecto, de dar toda la información (incluso aquélla que nos deja en una situación incierta) que tenemos disponible para que los responsables formales puedan tomar una decisión.

Se trata, en definitiva, de ayudar a tomar una decisión con respecto al camino a seguir de forma que podamos estar de acuerdo con ella y apoyarla. Y si no podemos estar de acuerdo y acompañar, se trata de explicitarlo y asumir las consecuencias.

Es, por otro lado, no ceder ante la presión aceptando de palabra una situación que luego, en los hechos, no toleraríamos. Hacerlo sería mentir, engañar. Me imagino, por ejemplo, el clásico lugar común en el que un integrante del equipo "dice que sí a todo" y mientras se busca otro trabajo (pura imaginación, aclaro, es sólo un ejemplo). Esto último sí me parece moralmente reprochable. Es planear "con premeditación y alevosía" bajarse del proyecto mientras se lo envía con rumbo desconocido.

En resumen, ¿cuál es nuestra responsabilidad ante un desvío, error o como se llame en la estimación? Avisar y ser abiertos y sinceros al momento de buscar los caminos de acción posibles, dar información confiable. Creo que es un compromiso más razonable que el aceptar trabajar 15 horas al día sólo para decir, cuando todo se vaya al diablo, "yo hice todo lo posible".

Estimaciones y compromisos.

Hace un par de días que venía con la idea de escribir al respecto, sin encontrar el hilo. Leyendo La masa, el ladrillo, la bota, el bocadillo... encuentro que en el artículo Recibiendo estimaciones se escribe exactamente lo que yo quería transmitir. Algunos extractos (y sigo escribiendo, no se me vayan todavía):

Generalmente cuando recibimos estimaciones es porque nos encontramos en una situación de autoridad dentro del proyecto y nunca debemos olvidar que la autoridad conlleva responsabilidad. Somos responsables de cómo tratamos estas estimaciones. Y la máxima es clara: No conviertas las estimaciones que recibes en compromisos. [resaltado en el original][...]

El otro aspecto a tener en cuenta es que convirtiendo estimaciones en compromisos dañamos la confianza de quien nos dio la estimación. Al fin y al cabo solo estaba estimando y nosostros sin embargo ¡hemos convertido su estimación en un compromiso!. Desde luego no estamos estableciendo las bases de una relación basada en la confianza. Y sin la confianza de los implicados en el proyecto nunca lograremos encontrar información veraz en la que basar la gestión del proyecto.[...]

La pregunta que planteo es qué posturas podemos o debemos tomar, como desarrolladores cuando notamos (es imposible no hacerlo) que estamos muy desviados de lo estimado, si se han asumido compromisos (a más alto nivel jerárquico) basados en esas desviadísimas estimaciones.

¿Somos responsables del error? Del error de asumir el compromiso en ciertos términos, quiero decir. No digo del error de estimación, ya que no considero que la estimación sea errónea (¿lo es?). Por más desviada que esté, ese desvío refleja nuestro desconocimiento al momento de hacerla. Creo que no es lo mismo que un error (que sí sería uno de cálculo por ejemplo).

¿Nos hacemos cargo del compromiso asumido, dado que no hemos sido nosotros quienes lo hemos hecho? ¿Cómo? ¿Trabajamos más horas? ¿Aceptamos hacerlo gratis? ¿Hasta qué punto?

¿Es reprochable si no queremos hacerlo, por las razones que sean? Aunque no sea gratis, ¿por qué debería sentirme o estar obligado a un sacrificio personal? Usualmente se dice que uno elige hacerlo, por ejemplo por razones monetarias o políticas -quedar bien con los superiores, un ascenso, etc.-... elegir implica poder decir que no. ¿Y si decimos que no?

Me imagino que si luego de un gran esfuerzo se llega (tarde pero menos que de seguir normalmente), el diferencial pasa desapercibido. Al fin y al cabo todo ha sido entregado a destiempo y a los apurones, a veces con sacrificios de calidad. Hemos "sacado las papas del fuego" sin ningún reconocimiento extra por ello, de ningún tipo... y ahora tenemos otro muerto esperándonos en el mantenimiento.

Cuando uno realiza un trabajo independiente, por ejemplo, las cosas son más claras. Uno asume todo el compromiso. Pero la relación laboral tiene para con el empleado un compromiso acotado... en los papeles. Esto varía mucho de acuerdo con el contexto económico.

Está en la balanza el querer que a la empresa le vaya bien, aunque no a costa nuestra... querer sacar el proyecto adelante, pero no regalar méritos ni levantar muertos ajenos... hacer esfuerzos pero no sacrificios...

Releo y veo que las preguntas redactadas pueden parecer una toma implícita de posición. Yo aclararía que reflejan más bien un estado de ánimo, que como todo ánimo es circunstancial.

Sé que algunos de los lectores de este blog se desempeñan como líderes de equipo, de proyecto, de área o de lo que sea. Mis opiniones se fundamentan puramente en la teoría, que conozco bastante bien a través de la preparación de mis clases. Pero quisiera conocer sus opiniones que además de la base teórica se sustentan con la práctica y el pragmatismo del día a día.

Ahora sí, los dejo que sigan con el resto del post referenciado.

Actualización: Le referí el post a Yuki en un comentario de su entrada 30 - Mi quinto cliente : Los malteses (III), anécdotas y reflexiones, quien responde con sus opinión al respecto (¡gracias!).

El tema sigue en Estimaciones y responsabilidad.

CMMI. ¿La calidad del proceso es garantía de la calidad del producto?

Ever been to McDonalds? Bet you didn't know that they are CMM Level five? Does anyone think that McDonalds product quality is high?

Enterprise Architecture
Does CMMi encourage worst practices?

Y relacionados:

desDesarrolloDeSoftware: Formalizar hasta paralizar.

Navegápolis: ¿A mayor nivel de CMMI, menor sueldo?

Kybele Consulting: Una certificación de la calidad de los procesos no siempre asegura un producto de calidad.

Del desarrollo de software como sistema de comunicación y la importancia de poder leer y escribir.

A veces me pongo extremista y veo al desarrollo de software solamente como un sistema de comunicación. Si lo vemos como una caja negra, se trata de de transmitir y traducir los requerimientos en una serie de instrucciones que un hardware pueda ejecutar, llevando a cabo la tarea que estos requerimientos representan. Por lo menos idealmente.

Si abrimos esa caja negra, encontraremos varios "puntos de retransmisión y traducción", que más o menos se corresponden con las etapas de relevamiento, análisis, diseño y codificación. Cada etapa nos acerca más desde el lenguaje del emisor (el cliente) al lenguaje del receptor (ese equipo de hardware).

En resumen, los requerimientos son el mensaje, el cliente es el emisor y el hardware que finalmente debe ejecutar la secuencia de instrucciones acorde es el receptor. En el camino tenemos varios retransmisores, algunos humanos y otros no: analistas de negocio, analistas funcionales, programadores, entornos de desarrollo, compiladores, personal de soporte al cliente (al instalar), sistemas instaladores. El mensaje se transmite a través de varias formas y a través de varios medios: oralmente, por escrito, electrónicamente.

Bajo esta óptica, somos retransmisores al tiempo que traductores.

Como en todo sistema de comunicación, hay ruido de fondo y ruido generado por el propio sistema. Ambos tipos de ruido deforman inevitablemente el mensaje. La comunicación perfecta no existe, por tanto tampoco existe el software perfecto.

Siguiendo por este camino, en el que suelo entretenerme inventando y perfeccionando analogías, llego usualmente a la siguiente conclusión (bombos y platillos):

La calidad del software depende de es la fidelidad con la que el equipo transmite un mensaje, por ello todos los participantes de un equipo de desarrollo de software deben ser excelentes transmisores de información.

De nada sirve ser un experto programador, analista o visionario del negocio si no se puede transmitir fielmente esa información a través del proceso de desarrollo.

Transmitir implica básicamente dos tareas: recibir y enviar. Incluso un programador independiente que trabaja absolutamente solo debe ser un experto escuchando o leyendo al cliente (recibiendo) y programando (enviando).

Recibir es usualmente escuchar, leer. Transmitir es usualmente hablar, escribir.

El problema de escuchar y hablar es que, como se dice coloquialmente, a las palabras (y muchas veces a las personas que las pronuncian) se las lleva el viento.

¡Cuidado! Ahí vienen los pseudo-ágiles: que el exceso de documentación, que la comunicación informal, que los cambios continuos y un largo etcétera.

¿Cuál es la diferencia entre pseudo-agilidad y verdadera agilidad?

En el desarrollo pseudo-ágil no se preserva nada. Llegamos al punto de encuentro con el cliente y estamos solos. ¿Qué pasó? No tenemos idea.

En el desarrollo ágil se preserva solamente lo indispensable: el mensaje, los requerimientos. Es absolutamente minimalista: hay que preservar sólo el mensaje, pero hay que hacerlo como si fuera la vida misma, y verificar continuamente que no haya sido malinterpretado por nadie. Como recalqué muchas veces: tal es así que en XP las historias del usuario las escribe el mismo usuario, y éste es parte del equipo. Creo que solamente por una cuestión legal las cadenas para retenerlo cerca del equipo (que seguramente figuraban en los primeros bocetos) fueron finalmente suprimidas.

Aclarado que tenemos que preservar al menos el mensaje original, los requerimientos, el tema es cómo.

Me agarra el viejazo cuando me vuelvo tradicionalista, pero todavía nadie me convence de lo contrario: el texto es el rey. Es la herramienta más sencilla para el conjunto de actividades que se realizan alrededor de los requerimientos: recibirlos, discutirlos, modificarlos, transmitirlos, catalogarlos, archivarlos, buscarlos.

Pensemos en otros soportes posibles. Omito los puntos "catalogar" y "archivar" ya que con las herramientas disponibles serán sencillos para cualquier soporte.

Los gráficos son más difíciles de producir y modificar, aunque usualmente mejores para discutir y transmitir. La búsqueda no es sencilla, justamente porque contienen poco texto.

En cuanto a imagen y sonido, grabar la descripción de los requerimientos parece una buena idea, pero no me parece un soporte fácil para recibir o discutir, mucho menos de modificar. No me imagino en una reunión diciendo "poné de vuelta esa parte... no... un poco antes... ahí, ¿no debería decir...?" La transmisión es más complicada y la búsqueda sólo puede realizarse bajando el contenido a texto.

Recordemos que hablamos de requerimientos que cambiarán continuamente. A mayor complejidad mayor resistencia al cambio. Y cambio en los requerimientos es moneda corriente.

Así que si me preguntan a mí, texto.

Resumen: habilidades a valorar en un integrante de un equipo de desarrollo (¿o mejor dicho, de un equipo, a secas?): leer y escribir (porque si no a las palabras -o al integrante- se las lleva el viento). ¿Alguna vez los evaluaron en eso en una entrevista de trabajo?

BTW: Menudo título, ya sé, pero estoy cansado de aparecer en cualquier lado por hacer bromitas con los títulos de los post. No lo hagan.

La cadena del error.

El 30 de septiembre se publicó La cadena del error en el blog de aviación TCAS.

Es medio largón el post, para leer con tiempo. Es imposible no estar de acuerdo con las centradas opiniones del autor, que demuestra en ellas la lógica irrebatible de quien conoce de lo que expone, ubicándose lejos de las frases rápidas, baratas y efectistas de los opinadores profesionales.

Los conceptos vertidos son fácilmente extrapolables al desarrollo de software. Vale la pena una segunda leída con esta visión en mente.

Visto mientras navegaba en Dirección de Proyectos.

Def: Sistema

Imperdonable no haber comenzado las definiciones con la más básica de todas.

Sistema: Conjunto de partes o elementos organizadas y relacionadas que interactúan entre sí para lograr un objetivo. Los sistemas reciben (entrada) datos, energía o materia del ambiente y proveen (salida) información, energía o materia.

Extracto de la entrada para sistema del diccionario de Alegsa. Les recomiendo darle una leída a la entrada completa.

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.