Modelo RACI - Qué es y para qué se usa

Hola de nuevo. Hoy quiero hablaros de una técnica que es a la vez tan simple como necesaria, y que sin embargo, se tilda de teórica e inútil en muchas ocasiones...incluso cuando nos damos cuenta de que hace falta.

Es una técnica de gestión de proyectos, por lo que efectivamente, aquellos proyectos que carezcan de una adecuada gestión, son los principales candidatos a quejarse de esta técnica.

El modelo RACI es una técnica que permite identificar quién se encarga de qué en el proyecto. Pero va mucho más allá, identificando los principales roles intervinientes en cada tarea. Los roles que identifica esta técnica son cuatro, cuyas iniciales en inglés dan nombre al modelo:

• Responsible: responsable de ejecutar la tarea. Vamos, quien la hace físicamente, el que se pone manos a la obra, y se "mancha" las manos.
• Accountable: responsable de que la tarea se ejecute, es quien rinde cuentas. ¿Porqué separar este rol con el anterior? En muchas ocasiones, yo puedo ser el responsable de que algo se haga, pero no lo hago directamente yo. Lo subcontrato, o lo asigno a un tercero. Y es importante diferenciar las tareas que hago yo directamente, de las que encargo a otros.
• Consulted: este rol tiene información útil o valiosa para la realización de las tareas, aunque no sean responsables de las mismas ni participan activamente en su ejecución. Por ejemplo, grupos de expertos en un tema, grupo de calidad, etc. Es importante destacar, que este rol interacciona bi-direccionalmente, es decir, se le consulta, y él responde, o bien participa de forma espontánea aportando su conocimiento.
• Informed: informado. En este rol incluiremos a todos los grupos que hay que mantener informados, poner en copia de los correos, etc. La principal diferencia con otros roles es que con éste se tiene comunicación unidireccional.

¿Cómo se hace todo esto?.

Una forma simple es hacer una tabla, donde por cada fila, escribiremos en la primera columna el nombre de las tareas. De esa forma, por cada fila (por cada tarea), rellenaremos a su derecha unas columnas adicionales, una por cada persona o grupo involucrado. En esas columnas adicionales, indicaremos su rol por las iniciales antes mencionadas: R, A, C, I.

A la hora de rellenar con estas letras/roles, tendremos en cuenta una serie de reglas:

• No es necesario usar todas las letras (R,A,C,I) en cada fila/actividad.
• Al menos, sí deben aparecer en cada fila/actividad, los roles R y A (es decir, responsable y encargado de ejecución). Los roles C,I, son por tanto opcionales en cada fila.
• En cada fila/actividad, debe aparecer un único R (responsable de ejecución), y un único A (responsable de la tarea).
• En cada fila/actividad, los roles C,I pueden repetirse.
• Una misma persona/grupo, puede asumir varios roles para una misma tarea. En ese caso, se anotaría algo como "R/A" si por ejemplo fuese a la vez responsable de la tarea y de su ejecución.

La imagen siguiente ejemplifica lo comentado:

¿Dónde se utiliza esto?

Yo lo he usado principalmente en documentación funcional para definir el "As-Is" o el "To-Be" de los procesos de negocio, o en contratos, o propuestas, donde es fundamental dejar claro el papel de las distintas partes durante el ciclo de vida de una tarea.
Es importante hacer notar, que el rol de las distintas partes puede cambiar en el tiempo. Por ejemplo, en un mantenimiento, el proveedor anterior de mantener la aplicación puede pasar de R/A, a solamente A/C (en la fase de transición) y finalmente solo C en un período de soporte en el que el nuevo proveedor de mantenimiento tiene ya el control total del soporte.

¿Y ya está?
Pues no. Como siempre, hay variantes para todos los gustos. Por ejemplo veremos dos a continuación.

RACI-S

Existe la variante RACI-S, que añade un rol adicional de Soporte ("Support"). Ésta es la variante que he visto en la práctica. EL rol Soporte, se encarga de dar soporte de todo tipo al rol "R" (que es quien hace la tarea), en todo lo que éste necesite. No confundir con el rol "C", que sería más bien un experto en la materia, y que si bien también da soporte, digamos que dicho soporte sería más "pasivo" que el del rol "S".

RACI-VS

También existe la variante RACI-VS que añade dos roles:

• Verify (verificador): este rol se encarga de actividades de verificación, es decir, de comprobar si el producto está conforme con los criterios de aceptación establecidos en su descripción/diseño/calidad.
• Sign (aprobador o supervisor): este rol aprueba las decisiones del rol Verificador y autoriza el producto. Lo lógico es que el trabajo de un S preceda siempre al de un A.

Material para preparar ISTQB

Hola, aquí dejo un enlace bastante interesante con material que ayuda a la preparación de la certificación ISTQB:

ISTQB es una certificación que pretende cubrir en diversos niveles, las áreas de conocimiento relacionadas con la ingeniería de pruebas.

Si alguno más se anima a la certificación, mucho ánimo.

Se me olvidaba! El enlace: https://sites.google.com/site/softwaretestingbooks4u/manual-testing

Por cierto, este post es el número 200 en este blog. Vaya, ya tenemos unos cuantos.
Un saludo.

24h - El complejo de Jack Bauer

Ocurre en muchas ocasiones: más de las que nos gustaría y más de las que queremos admitir. En esta profesión de desarrollo de software, en la que tenemos metodologías, métricas, procesos, calidad, más de una vez nos habremos encontrado sufriendo el complejo de Jack Bauer.

Ocurre de forma progresiva: primero tenemos todo planificado y bajo control, todo parece ir sobre la seda, y cuando menos te lo esperas, salta un problema para el cual no tenías un plan de contingencia. La cuestión no es tanto si sabemos o no planificar, sino más bien cómo afrontar los problemas. Esos problemas que se suelen manejar en un comité y que en más ocasiones de las que nos gusta admitir, tememos escalarlos a ese comité por no asumir responsabilidades.

¿La consecuencia? Pues que trasladamos a nuestros equipos esa responsabilidad, enmascaramos la culpa con una falsa urgencia (o no tan falsa), y movilizamos nuestros ejércitos para afrontar lo que parece ser un capítulo de la serie de televisión "24". Con un plazo imposible de cumplir, nos embarcamos en una tarea sobrehumana, y sustituimos la culpa, la gestión y las metodologías por un compromiso y resolución que nos lleva a ser protagonistas de esa serie, donde hay que salvar el mundo, hacer tareas imposibles, recorrer varias veces toda la ciudad y todo ello en 24 horas.

¿Os suena? Pues sí, esto es el complejo de Jack Bauer, personaje protagonista de esa serie de televisión, y que representa muy bien las situaciones de "bombero" o "apagafuegos" en las que nos vemos inmersos.

Esta forma de afrontar los problemas, la podéis encontrar en la red con otros nombres. Uno que me ha gustado es el antipatrón "apagafuegos". Os recomiendo leer esa web de antipatrones.

Hay que tener mucho cuidado con esta forma de actuar, porque lleva a ser estimulante. Nos podemos sentir héroes salvando el mundo, apagando fuegos constantemente, en ese complejo de Jack Bauer. En lugar de afrontar los problemas como lo que son, no podemos tratar de resolverlos todos a la primera de cambio, en ese ciclo de subida (esfuerzo heroíco de resolver el problema) y de bajada (bajón inevitable que tenemos cuando la situación ya es estable y la adrenalina se agota...hasta el siguiente fuego).

Hay quien ve esta forma de actuar como una adaptación al cambio. Pero adaptarse al cambio no significa afrontar los problemas con sesiones a lo Jack Bauer (es decir 24 horas sin dormir y con esfuerzos histéricos para resolver las cosas). Hay que atajar los problemas de base, porque distraer al equipo de esa forma significa alejarlo del objetivo del proyecto. Esa distracción no supone 24 horas, sino mucho más: el coste de recuperar el ritmo, y también de recuperarse de ese esfuerzo.

Los cambios los gestionamos nosotros, no al revés.

No borres tus huellas, vaquero

Esta entrada en mi blog la dedico a todos aquellos que borran sus huellas en el trabajo. Los que sólo guardan los ficheros en su última versión. Los que no versionan los documentos. Los que cuando tienen un fichero incompleto lo destruyen al comenzar uno nuevo.

Son los amigos de lo imperfecto. Tal vez sea la obsesión de aparentar perfección, o no mostrar debilidad, tan habitual en algunas empresas.

No se trata de guardar un registro de todo lo que hacemos, sino más bien de protegernos de nosotros mismos. Después de todo, la mayoría de herramientas de versionado de código nos protegen de nuestras ganas de cambiar el código en exceso, permitiéndonos recuperar una versión previa que funcionaba o que simplemente queremos revisar. Si estamos de acuerdo en el caso del código fuente...¿qué pasa con la documentación?

La documentación es parte del proyecto.

Debemos cuidar la documentación, tal y como hacemos con el código. De nada servirá esto a los que entienden que la documentación se hace "después del código".
Cómo me duele ver en los diseños técnicos o funcionales, código fuente o pantallas que se han obtenido de la versión final.
Los documentos  hay que versionarlos y cuidarlos como cualquier otro resultado de nuestro trabajo.

La necesidad del versionado.

Algunas ventajas de tener la documentación versionada en un repositorio:

• Documentación alineada con cada versión del código.
• Es fácil identificar los cambios en los objetivos, del mismo modo que el versionado del código permite identificar los cambios en los resultados.
• Acceso centralizado. Al estar la documentación versionada y centralizada, todo el mundo accede a la última versión.
• Notificaciones de versionado. Muchos repositorios de documentos avisan de nuevas versiones. Esto es útil porque el equipo de desarrollo puede estar informado de cualquier cambio en una Historia de Usuario, un Requisito (o como lo queráis llamar).
• Permite escalar proyectos. Es muy sencillo trabajar con post-its para documentar requisitos, pero escalarlo a un equipo de 50 personas en 10 países, no es sencillo. En un repositorio documental, incorporar a un nuevo equipo en otro país es tan simple como darles acceso.
• Utilizar un repositorio permite ahorrar reuniones: todo el mundo puede estar al tanto de que se está cociendo una nueva versión de los requisitos, o de que se han modificado 5 de las 10 historias de usuario de nuestro producto. Esto no significa que no sean útiles las reuniones. Simplemente se trata de que las herramientas hagan el trabajo más simple.

¿Y qué hacemos en un proyecto pequeño?

Si tu proyecto es muy pequeño, puedes hacer el versionado de forma manual. Guarda el archivo como "requisitos_v02" y ya está. También puedes integrar la documentación como parte del código, y que tu herramienta (Subversion, Git, etc), se encargue del resto.
De todas formas, es útil seguir con la documentación, las mismas técnicas que un repositorio de código:

• Check-out: Avisa de que el documento lo vas a modificar. Que la gente tenga claro que hay una nueva versión en curso. Eso les hará organizarse mejor y centrarse en las áreas que menos cambios vayan a tener. Pocas cosas molestan más que ver cómo llega un gran cambio sobre algo en lo que hemos dedicado varias semanas con sus larguísimas jornadas. Y más cuando hay otras tareas que podríamos haber avanzado en su lugar. Avisa de la fecha prevista para terminar la nueva versión.
• Check-in: Avisa de cada nueva versión. Que la herramienta (o tú mismo mediante un correo), notifique al equipo de una nueva versión de lo que sea (requisitos, análisis, etc). Hazlo ágil y simple. Tanto para el que lo lee, como para tí que lo escribes y que lo vas a tener que actualizar.

Actitud y respeto, fuentes del problema.

Al final, es una cuestión de respeto profesional, de velar por que nuestras acciones ayuden en lugar de interferir al resto del equipo. De intentar prever las consecuencias de nuestros actos, no limitarnos a soltar nuestro (llámalo código, documento o lo que sea), y darnos la vuelta para no ver los resultados.

Muchas veces oigo a la gente quejarse de lo mismo repetidas veces: "para qué documentar si nunca voy a tener la documentación actualizada". Es deprimente, ya que muestra un grave problema de actitud. Hazlo o no lo hagas, pero no lo intentes. Deja ya esa actitud derrotista, por favor. ¿Somos ágiles y por tanto capaces de abrazar los cambios en el código? ¿Y sin embargo no somos capaces de hacer lo propio con la documentación? Claro que van a llegar cambios, es algo inherente en el software. El problema está en que no documentamos, sino que escribimos novelas.

Yo no sé si hay falta de programadores, pero de lo que estoy seguro de que sobran novelistas, y faltan buenos analistas o arquitectos que documenten los objetivos técnicos y funcionales. Menos verborrea, y más UML, casos de uso, historias de usuario.

ITIL - Cómo aprobar el examen Foundations

Hola, hoy me apetece hablar del examen ITIL Foundations, y algunas recomendaciones para facilitar el superarlo y dar una guía y seguridad a los que se presentan a este reto.
Podéis leer en este mismo blog un post con una introducción sobre ITIL.

En primer lugar debo decir que escribo esto desde el punto de vista de mi experiencia personal. A mí me sirvió (superé con un 95% el examen oficial ITIL Foundations). Empecemos:

Y todo esto...¿para qué?

Al superar el examen ITIL Foundations, recibes una certificación que te acredita profesionalmente a tí, como conocedor del marco de servicios y buenas prácticas ITIL.
Profesionalmente, la acreditación ITIL Foundations está entre las más solicitadas. Este enlace, lo presenta en el 9º puesto, al mismo nivel que otras certificaciones mucho más costosas de conseguir desde mi punto de vista.

El examen.

El examen ITIL Foundations, para la edición 2011, está basado en 40 preguntas para las cuales se exige un 65% de acierto (es decir, acertar al menos 26 de esas 40 preguntas).
Para ello, los exámenes se realizan desde centros autorizados, y cualquier búsqueda en Google os dará centros para hacer cursos, normalmente acompañados de un examen final.
Para el examen, nos darán 60 minutos. Yo no fui el primero en entregar mis resultados, y me costó apenas 20 minutos responder a las preguntas. Mi consejo es que hay tiempo más que suficiente. Marcarse un ritmo, no más allá de un minuto por pregunta, de forma que nos quede margen para revisar las respuestas, preguntas que nos hayan quedado sin contestar, etc.
El examen se hace mediante ordenador, que conectado al centro evaluador, te permite hacer las preguntas, revisarlas, controla qué preguntas han sido contestadas, cuáles no...etc.
El idioma del examen: se puede elegir hacerlo en inglés o en castellano. Mi experiencia es que no notarás mucha diferencia. Cuidado con las traducciones de los exámenes que encontrarás por internet, porque muchos conceptos estamos acostumbrados a escucharlos en inglés, y la traducción se nos puede hacer extraña. Los de habla hispana encontrarán muy diferentes traducciones en función de la nacionalidad, así que cuidado. En mi caso, he llegado a dudar en preguntas solamente por leerlas en español (la traducción no era del todo afortunada).

Las preguntas.

Las preguntas son de tipo test, y son realmente sencillas si has estudiado. No tiene mucho misterio. Yo recomiendo hacer el curso de preparación que suele anteceder a los exámenes en los centros oficiales. Yo en mi grupo de estudio, detecté que simplemente atendiendo al curso y estudiando un poco en los 4 días de curso, era suficiente para superar todos los test de prueba que hicimos el último día.

El material de preparación.

Recomiendo hacerse con:

• Un buen libro o material de estudio, normalmente facilitado en el curso oficial. Sólo si no tienes el anterior, me plantearía comprarme un libro. Para el que ya tenga el material de presentación del curso, le será de rara utilidad comprar un libro aparte.
• Un buen paquete de test de exámenes. Intenta que no estén marcadas las respuestas. Normalmente los harás N veces antes de presentarte al examen final.

Dónde prepararse.

Buscando en google, encontrarás centros formativos. Yo estuve bastante contento de la formación que recibí durante 4 días, a unas 5 horas al día.
Si prefieres la autoformación, hay muy buenos libros en el mercado.
También, encontrarás en internet gran cantidad de exámenes en inglés y español. Luego os hablaré de ellos.
Yo lo digo por activa y por pasiva en este blog: yo no vendo, así que no esperéis que os venda un libro o una empresa certificadora. Yo tampoco me dedico a esto, no estoy en este blog para vender. Usad internet, basta poner ITIL en el buscador, Empresa Certificadora, etc.

Cómo prepararse.

Mi plan de trabajo fue el siguiente:

1. Asistir a un curso oficial
2. Hacer test de certificación
3. Recopilar las preguntas en que había fallado, y estudiarlas/razonarlas revisando de nuevo todo el material, de forma que me quedara claro la respuesta buena, y no la que yo erróneamente había escogido.
4. Repaso de teoría. Usar un resumen/esquema.
5. Volver al punto 3 hasta que la puntuación obtenida en los test mejorara sustancialmente hasta el 80% al menos.
6. El día antes del examen, hice un buen repaso de todas las preguntas en las que en algún momento había fallado (y que luego había razonado/estudiado la respuesta).

Que no se le ocurra a nadie ponerse a hacer tests sin haber estudiado a conciencia, o haber recibido un curso intensivo y completo. Ese es uno de los peores errores, porque aunque no hay preguntas trampa, sí lo pueden parecer al neófito.

Si el examen se hace al terminar un curso, mi consejo es estudiar todos los días al menos 2h aparte del tiempo dedicado al curso.

Si como me ocurrió a mí, pasa mucho tiempo desde el curso hasta el examen, tómate al menos una (o mejor dos) semana(s) dedicando entre 1 y 2 horas al día. Habrá quien le baste con menos...tú mismo.

Consejos.

Aquí van algunos consejos, obtenidos tanto de mi experiencia personal, como de otras personas que hicieron el examen y tuvieron a bien compartir esto conmigo:

• No es nada complicado. Es más importante calidad que cantidad al estudiar.
• Concentración. Es bastante teórico, por lo que merece la pena un ambiente silencioso y estar centrado. Los conceptos pueden parecer liosos a quien está fuera del ámbito de la prestación de Servicios IT.
• Una o dos tilas antes del examen, vienen bien ;)
• No te fies de los exámenes de test que verás por internet. Revisa toda las preguntas contrastando el material teórico que tengas (libros).
• Cuidado con la versión de los exámenes. Internet tiene mucha información (demasiada), y está mal clasificada, y mal presentada.
• Piensa que todo el material anterior a 2011 (y gran parte del de 2011), es anterior sí o sí a la última versión de ITIL. Además, por mi experiencia, mucho material presentado como de 2012 también está obsoleto. Los tests de versiones anteriores de ITIL no es que contradigan el ITIL 2011, sino que simplemente no están en el temario o pueden enfocarse de forma ligeramente distinta. Te harán perder tiempo.
• Mientras se estudia el temario, e incluso durante el mismo curso, hazte un esquema. Algo que parece imposible al principio (como identificar a qué área de procesos ITIL pertenece cada proceso individual), acaba siendo natural tras N repasos del esquema.
• No te agobies con descargar libros y libros de internet. Utiliza un solo material, preferiblemente en el mismo idioma en que te vayas a examinar (inglés o español). Es decir, que si ya te dieron material en el curso, céntrate en él y no pierdas tiempo en N libros que sólo te van a distraer.

Mucha suerte, si te animas a certificarte.

La oportunidad de los becarios

La oportunidad de los becarios.

Se supone que los becarios se quedan a solas en verano: al frente del trabajo, ya que el resto de trabajadores (no becarios), han cogido todos vacaciones. Y claro, a los únicos que no les dejan coger vacaciones son a "los últimos en llegar".
Esto es un mito, y en cualquier cao no siempre es así. Los becarios exigen tiempo y esfuerzo para desarrollar sus capacidades, pero...¿realmente les estamos dando lo que necesitan para brillar?

La presión.

La presión suele ser el primer escollo. Siente que le vigilan, que le están evaluando de forma constante. El truco está en verlo como una motivación, una oportunidad.
Es una fuente de aprendizaje. La beca es así, y con ello, hemos de verlo en positivo. Salvo que estemos en una de esas empresas en las que los becarios se limitan a llevar cafés (por suerte, en mi empresa jamás he visto eso a un becario).
La presión hay que volverla en nuestro favor, que nos motive y nos dirija, no que nos bloquee y nos impida llegar a nuestros objetivos.
Otra forma de aliviar la presión es mediante  un tutor. En mi empresa existe la figura del counsellor, que viene a ser lo mismo. Y si bien es una gran idea, el problema viene dado cuando el tutor no se toma su trabajo en serio.

Cuando el tutor no dedica el necesario tiempo al becario.

El tutor no está para decir al becario lo que tiene que hacer. O al menos no de una forma paternalista. Debe guiar al becario impidiendo que cometa errores demasiado graves. Pero el aprendizaje incluye equivocarse. Cometer pequeños errores controlados. Aquí es donde el tutor entra en acción en su doble objetivo: que el becario aprenda, pero que la empresa no corra peligro.
La libertad del becario ha de ser proporcional a su responsabilidad: es decir, limitada. Pero no tan limitada que no pueda explorar su espacio y cometer esos pequeños errores controlados por su tutor.

Comportamientos a evitar

A continuación, revisamos algunos comportamientos a evitar por parte del becario:

• Individualismo. El excesivo individualismo, y el hambre de prosperar en la empresa, son explotadas por algunas empresas. Por desgracia, a medio y largo plazo los resultados suelen ser nefastos para la empresa. A veces, incluso a corto plazo.
• Impuntualidad. Aunque es complicado, es bueno combinar respeto y disciplina. Entrar a trabajar cinco minutos antes. Nunca después. Y nunca salir de trabajar antes de la hora, pero tampoco es necesario quedarse a trabajar  porque sí. Algún día revisaremos este punto en profundidad.
• Pereza. La pereza es terrible. El no empezar las tareas inmediatamente, el postergar lo importante por lo urgente.
• Problemático. Es una buena práctica el evitar problemas y confrontaciones. La energía generada en situaciones de conflicto está para ser utilizada a nuestro favor, no para embarcarse en disputas nimias que no van a resolver nada.
• Competitivo. La competitividad es buena, pero ha de ser una cualidad secundaria. No es bueno en general presentarse cada mañana pensando en "superar a éste" o "ser más que aquél". Sí es bueno marcarse metas, pero no es bueno dichas metas pasen por ser más que otros. Porque al final, el camino fácil se presenta: si no puedo ser mejor que los demás...quizás sea hora de hacer que los demás sean peor que yo (y aquí es donde la zancadilla fácil, el extender falsas afirmaciones, etc., hacen que el competitivo haga su agosto).
• Pelota. El pelota prefiere halagar en todo momento a sus superiores, o a cualquiera de quien pueda sacar provecho. Suele estar relacionado con un espíritu individualista y competitivo.
• Arrogancia. La arrogancia es uno de los peores males. A pesar de parecer menos agresiva que la competitividad o el individualismo, la arrogancia es difícil de erradicar. Está basada en una creencia profunda en las propias capacidades, y por desgracia, no suele estar alineada con la realidad. Cuántos recién titulados me he encontrado que se creían los reyes del mundo, dueños de la absoluta verdad, e incapaces de dialogar y llegar al mínimo consenso. Su título universitario les convierte en Dioses, o ellos así lo creen. Y por desgracia, yo hace muchos años que aprendí que mi título no está para esgrimirlo en absurdas disputas. El título está para dar soporte a la curiosidad, al esfuerzo, y a la capacidad de ir más allá de las apariencias. Capacidad de aprender, porque más que nos pese, no llegamos el primer día de trabajo con  todo aprendido.

Comportamientos a seguir.

• Aprender
• Jugar en equipo.
• Respeto.
• Atrevimiento.
• Planificación.
• Organización.
• Socialización: conseguir contactos y establecer relaciones.
• Disfrutar.

Sí: disfrutar. Disfruta, suéltate y siéntete cómodo. Que no parezca que estés ahí cada día por un sueldo miserable. Madruga. Llega pronto. Haz las cosas con ilusión. Contagia esa ilusión. Yo personalmente prefiero a gente ilusionada, antes que a un crack, al típico fenómeno tecnológico en cualquier tema pero que lo hace con desgana. Y la desgana se contagia. Y esa desgana se ve en la documentación, en el código...

Y tú, ¿cómo prefieres llevar tu beca?

Fuente: este artículo está inspirado en un artículo que leí hace un tiempo en el periódico dominical de La Vanguardia.

Trucos para un buen informe de seguimiento

Leía hace poco un artículo en el excelente blog de Javier Garzás, sobre lo que nunca debería faltar en un informe de seguimiento. Y me he quedado con una sensación de que me faltaba algo. En primer lugar, los informes de seguimiento no son algo estándar y cerrado válido para cualquier proyecto. Empezaremos por pensar en los objetivos del informe.

Objetivos del informe de seguimiento.

Este tipo de informes, se realizan periódicamente con el cliente en un proyecto (de software o de cualquier tipo). El informe de seguimiento software pretende:

• Identificar brevemente el proyecto. Un par de frases, un resumen del plan o del proyecto en cuestión. Esto es útil en clientes para los que trabajan múltiples proveedores. Hay que tener en cuenta que estas reuniones las sufren constantemente, y el cliente necesita que "les hagamos una introducción". No podemos llegar y empezar a soltar nuestro rollo. Recordad: adaptar el mensaje a lo que necesita el cliente, no a lo que queremos contar nosotros.
• Mostrar los objetivos del proyecto. ¿Qué se quería hacer? ¿Cuáles son los objetivos?
• Mostrar de forma resumida el estado del proyecto (precisamente respecto a esos objetivos). El estado incluye cosas como revisión de posibles desviaciones en la fecha de fin, esfuerzos dedicados, o costes. Seguimiento de hitos y entregables. Cumplimiento del contrato, y los distintos acuerdos alcanzados. El estado supone comparar la situación actual respecto al global del proyecto: el coste total, el esfuerzo total en horas estimado, y la fecha final de entrega (entre otros). Presupone una planificación y un seguimiento respecto a la misma.
• Mostrar los riesgos y su estado. Siempre hay riesgos. No gestionarlos, no dedicar tiempo de gestión, planificación y seguimiento no hace que desaparezcan.
• Mostrar los problemas y su estado. Los problemas, se refieren aquí a problemas de gestión. No a incidentes o fallos del software. Los problemas surgen en cualquier momento (un entorno no disponible, una tecnología que no funciona, un profesional que se va de la empresa...). Los problemas han podido ser detectados previamente (como riesgos), o surgir de imprevisto.
• Hitos clave y su estado. En todo proyecto suele haber fechas clave, que incluso pueden determinar el poder facturar o no todo o parte del proyecto.
• Entregables clave y su estado. Los proyectos no son solo código. Suelen llevar otros entregables (documentos, hardware,...), y que estarán recogidos en el contrato u objetivos iniciales.

Otros posibles contenidos el informe de seguimiento.

Vamos a ver otras cosas que pueden incluirse en un informe de seguimiento, pero que hay que pensarse bien si encajan en el tipo de seguimiento que pretendemos presentar:

• Avance del proyecto. No es lo mismo avance que estado. Al hablar de avance, nos referimos a lo incorporado desde la reunión de seguimiento anterior. Este tipo de reunión sería incremental, y trata de mostrar la diferencia respecto a lo anterior. De nuevo, este tipo de información suele darse en proyectos ágiles. Cuidado con esto, porque estamos mostrando la situación relativa respecto a un estado anterior, pero no respecto al proyecto total (eso sería un estado del proyecto). En proyectos ágiles, habría que dar también un estado, es decir, informar de cómo nos encontramos respecto al total del proyecto, informando de un coste estimado, fecha estimada de finalización, etc, etc.
• Estado de la calidad. Soy defensor de la calidad, y creo que hay que planificarla, establecerla muy al principio, y utilizar para ello indicadores lo más objetivos posibles. Sin embargo, en el tipo de clientes que he visto en mis bastantes años de vida profesional, no metería gráficas ni un análisis semanal de métricas (pocos clientes los entenderían). Eso sí, esos análisis los haría "de puertas para adentro", y lo convertiría en un semáforo donde se indicara si dichos indicadores están bien, o si por el contrario alguno de ellos no se está cumpliendo. Este tipo de indicadores, por ejemplo, lo trataría en un informe de seguimiento técnico, no en un comité ejecutivo. Por desgracia, los indicadores de calidad no son entendibles, y pueden dar lugar a falsos equívocos, preocupaciones innecesarias. Lo que hay que hacer es evidenciar que se trabaja con calidad dentro de un margen, y que se trata no de dar un producto perfecto, sino un producto con un buen balance entre coste y calidad. Por supuesto, siempre es posible que un sistema automatizado, u otra empresa certificadora, sea quien presente el estado de la calidad.
• Demo del software. Una demo del software, no siempre podrá realizarse con los clientes en todas las reuniones del seguimiento. Básicamente, porque una reunión de seguimiento ha de ser algo muy concreto, muy enfocado, y una revisión funcional del software puede llevarnos mucho tiempo. Por otro lado, una demo no se hace cada 1, 2, o 3 semanas. Tal vez sí en proyectos ágiles que lleven asociado un cliente deseoso de ver ese software avanzar. Pero no siempre. Una última cosa. Las demos son caras. Se dedica tiempo y recursos en preparar una demo. Y no sólo por el software: están las personas que asisten (cuyo tiempo es caro, y hay que respetar), están los datos, que han de estar listos para presentar el software (la gente no quiere ver el software, quiere ver las cosas que es capaz de hacer, y eso requiere de una preparación de datos previa).

Al final, no existe un informe perfecto. El informe debe servir al cliente y a los propósitos del proyecto. Todo lo aquí comentado suele incluir se en informes, pero hemos de recordar que no todas las reuniones de seguimiento son iguales.

Antes de presentarnos a una reunión, deberemos: establecer qué necesita el cliente, cuál es el ámbito del proyecto... De todas formas, yo recomendaría siempre al principio del proyecto establecer claramente:

• Modelo de relación: tipos de reunión, quiénes asistirán, decisiones a revisar, periodicidad...
• En cada tipo reunión, definir qué informe se revisará, contenido, roles (quién lo presenta, quién lo aprueba, etc).

El necesario estrés

Hablando el otro día con un compañero de trabajo, me contaba una interesante metáfora.

Había un pescador que pescaba atunes, pero los tiburones diezmaron la pesca. Y para evitar arruinarse, tuvo una gran idea. Decidió crear una piscifactoría, criar los atunes en cautividad, y venderlos para así obtener grandes beneficios. Pronto se dio cuenta de que los atunes no se vendían tanto como él pensaba. El motivo era que tenían demasiada grasa. En cautividad, los atunes se criaban gordos, y no tenían un incentivo que les hiciese hacer ejercicio.

Recordando cómo era la pesca en el mar, pensó que los atunes libres se crian con un sabor perfecto, y hacen mucho ejercicio porque deben sobrevivir. Así que decidió traer un tiburón y soltarlo en la piscifactoría. Pronto, los atunes ganaron en calidad, mejoraron su sabor, y se criaron más sanos y produciendo unas mejores ventas. Incluso considerando las pérdidas producidas por el ataque del tiburón, merecía la pena.

Al final, el motivo era la introducción de un nivel de estrés pequeño, pero suficiente para que los atunes se vieran en la necesidad de sobrevivir, criarse ágiles y sanos.

Al final, la moraleja que comentaba con este compañero es clara: un poco de estrés es bueno. Sin un incentivo, sin la adecuada presión...la gente se relaja. Y demasiada relajación, no nos lleva a los éxitos, ni provoca que la gente se estimule en mejorar su código, su planificación, sus pruebas...

Al final, PON UN POCO DE ESTRES EN TU VIDA. ¿Pero sin pasarse, eh?

PMO III - Ventajas de una PMO

Este es el tercero de una serie de artículos sobre PMO:

PMO I - Introducción
PMO II - Descripción
PMO III - Ventajas de una PMO
PMO IV - Inconvenientes de una PMO

El de hoy va a ser un artículo que espero sea interesante y a la vez breve. Repasaremos brevemente las principales ventajas que ofrece una PMO, y también veremos en un próximo artículo, sus posibles inconvenientes. Vamos allá.

Definición y estandarización de procesos.

• Una PMO ayuda a definir los procesos de la organización. Básicamente no es inventar nada nuevo. Basta con dejar por escrito todo lo que ya se hace, obtenido de quienes saben hacerlo.
• La ventaja, es que esto ayuda a que no se pierda el conocimiento, se estandaricen las formas de trabajar, se aproveche la ventaja de la experiencia adquirida.

Aumento de la eficiencia.

• De una correcta definición de procesos, del aprovechamiento del conocimiento y la experiencia, se obtiene como resultado natural un aumento de la eficiencia.

Reducción del trabajo duplicado.

• Como resultado de la experiencia y eficiencia, se facilita el reducir el trabajo duplicado.
• Si se han detectado duplicidades en ocasiones anteriores, ese conocimiento se aprovecha.

Menores costes de desarrollo.

• Como resultado de los anteriores, los costes disminuyen.
• Esta disminución no tiene porqué ser radical. Todo depende de lo optimizados que estuvieran los procesos y la organización antes de implantarse la PMO.

Mejora de las comunicaciones internas y externas.

• Una PMO ejerce principalmente como órgano gestor de las comunicaciones.
• Se estandarizan no sólo los canales, sino los formatos y los contenidos. Se identifican responsables de realizar la comunicación, el escalado, los distintos interlocutores, etc.

Alineamiento organizativo orientado a unos objetivos comunes.

• El principal objetivo de la PMO es asegurar que los procesos, las tareas que se realicen, estén alineadas con los objetivos de la empresa.
• Estos objetivos comunes, bien establecidos por la PMO, permiten que todo el mundo trabaje para un fin común. Se aprovechan sinergias.

Mejora en la planificación estratégica.

• Ya no sólo hablamos de planificar proyectos, y hacer el seguimiento. Estamos hablando de una planificación a nivel estratégico, totalmente alineada con los objetivos organizativos.

Mejora en la madurez y profesionalización de la gestión a nivel organizativo.

• La gestión se profesionaliza. Aumenta la madurez, apoyada por el conocimiento y unos procesos bien definidos, y una experiencia aprovechada.

Mejor formación a nivel organizativo.

• La formación se alimenta de la experiencia de los proyectos, de las necesidades organizativas, y de las lecciones aprendidas.
• Como resultado, la formación mejora a su vez el rendimiento en los proyectos, satisface las necesidades de la organización, y permite mejorar las lecciones aprendidas. El ciclo se cierra.

Mejora continua: el uso de lecciones aprendidas evita volver a caer en errores anteriores.

• Los errores cometidos, permiten mejorar los procesos.
• La gestión de riesgos mejora, permitiendo sucesivamente el prevenir errores y problemas anteriores.
• La experiencia permite solventar problemas y prevenirlos de forma cada vez más eficiente.

Hasta aquí todo parece de color de rosa. Pero una PMO no es tan sencillo, y puede tropezar con un alto número de obstáculos, que terminen como inconvenientes para la organización que trató de mejorar su gestión. Esto lo veremos en el próximo artículo de esta serie.

Ser ágil no es ser rápido

Hoy vamos a hablar de la diferencia entre agilidad y rapidez. Y porqué las metodologías ágiles, no tienen que ver con hacer un proyecto más rápidamente, y por tanto, con acabar antes. Cuánta confusión veo constantemente, generada precisamente por los desconocedores y los interesados en las metodologías ágiles. Los primeros, porque asocian automaticamente ágil=rápido, ya que la semántica nos induce a ello. Y los segundos, porque siembran la red de confusión en este sentido ya que tienen intereses profesionales y económicos al respecto. No hay mejor argumento de venta que el decir: ágil=rápido=barato.

Sinceramente, creo que hemos llegado a un nivel de información en la red en el que tenemos que empezar a dudar en la credibilidad de todo lo que vemos escrito, y darle un poco de trabajo a nuestro sentido común (que en ocasiones parece el menos común de los sentidos), y a nuestro sentido crítico.

Este artículo, viene inspirado en diversas entradas que estoy leyendo en las redes y que insisten consistentemente en sembrar la confusión entre estos conceptos. Y señores, no son iguales.

Podemos encontrar multitud de artículos en la web en que incluso defensores del agilismo, admiten la confusión entre estos dos términos. Pero vamos a tratar aquí de usar un poco de sentido común para entender un poco más el problema.

El concepto de rapidez en los proyectos ágiles.

En los proyectos ágiles, la medida del avance es la rapidez. Otra contradicción, por otro lado necesaria, ya que la única forma de saber cómo vamos y cuándo vamos a acabar, es utilizar esta métrica.

Al contrario que los proyectos que no usan metodologías ágiles, el estar abiertos al cambio hace que los requisitos estén permanentemente sujetos al cambio. La única forma de anticipar cuándo acabaremos, no está por tanto en medir el avance por requisitos, sino basarnos en la velocidad. La velocidad o rapidez, es por tanto, lo único cierto y medible. El resto: dependerá de cuántos cambios asumamos. Puede que ahora tengamos 20 historias de usuario. Pero pueden cambiar, y ser mañana 30, o 15...

Notemos aquí lo curioso del tema. Al hacer proyectos con metodologías ágiles, también necesitamos predecir y controlar cuándo va a finalizar el proyecto. La diferencia es la que estamos comentando, que no se basa en el cuánto (nº de requisitos), sino en el cómo (rapidez). Es por eso que los diagramas burndown chart son los principales referentes a la hora de conocer el avance y tratar de predecir cuándo tendremos el producto.

La rapidez en estos proyectos con metodologías ágiles será el número de puntos de historia de usuario (u otra métrica relativa) que realizamos por unidad de tiempo. De esta forma, si hemos estimado bien, podremos predecir el futuro.

El concepto de agilidad en los proyectos ágiles.

En las metodologías ágiles, el término agilidad o ágil está relacionado con la capacidad de adaptación al cambio. Pero no tiene nada que ver, e insisto en el NADA, con la velocidad del proyecto.

Agilidad, es la capacidad para adaptar el curso del desarrollo a la evolución de los requisitos y a las circunstancias del entorno (fuente: Navegapolis.Net, "Gestión de proyectos ágil: conceptos básicos").

Es decir, que la palabra "ágiles" en metodologías ágiles, no tiene nada que ver con rapidez del proyecto, sino con la adaptabilidad al cambio: la disponibilidad y facilidad para asumir cambios en el alcance (nuevos requisitos, o requisitos existentes).

¿Confusión interesada?

Llegados a este punto, empiezo a preguntarme si la confusión de términos no es interesada. A ver, no tengo nada en contra de los defensores del agilismo. Yo también defiendo el agilismo. Pero si lees este blog, sabrás que la cuestión no es defenderlo, sino defenderlo si aplica. No defenderlo porque sí. Todo dependerá del proyecto, equipo de trabajo, cliente, y metodologías actualmente en uso.

¿Porqué a los usuarios no les gusta el desarrollo ágil?

Parece que los de ITWorld se han dado cuenta de algo que hace tiempo que vengo diciendo y que por otro lado, no es más que lo que muchos venimos observando: que las metodologías ágiles están en un punto muerto, están en crisis. Y no porque estén mal, sino porque el excesivo bombo y platillo que se ha hecho en los últimos tiempos, han hecho que se usen para todo. Sólo falta que sirvan para lavar la ropa.

Hace poco, leía un artículo de ITWorld con un título similar a este que amigo lector, estás leyendo. Y es que el problema es que por un lado, hay que entender que las metodologías ágiles han subido como la espuma sobre todo por un motivo fundamental: gustan a los programadores. Pero al final, quienes han de pagar las facturas son los usuarios y los usuarios no ven con buenos ojos unas metodologías que presentan para ellos varios problemas:

 

Los usuarios no entienden las metodologías ágiles

Se usan metáforas complejas, conceptos muy novedosos y alejados del mundo de los clientes. El tener que participar para la revisión del producto final en cada iteración, puede ser demasiado para un cliente ocupado que por otro lado, ya ha gastado demasiado en un producto que nunca termina de estar.
El término ágil en en sí mismo contradictorio, ya que no siempre implica rapidez. En muchos proyectos, se prefiere abandonar términos y palabras de moda como "ágil" o "scrum", para centrarse en conceptos más simples y cercanos al cliente.

Los usuarios quieren saber cuánto les va a costar el software.

Claro, desde el punto de vista de los programadores, es distinto. Los programadores quieren hacer un software perfecto, que requiera el mínimo mantenimiento, y que acierte al 100% con la funcionalidad deseada. Y si esto es a costa de entregar las cosas más tarde (obviamente, el tiempo se invierte en realizar iteraciones que nos permitan hacer software cada vez más cercano a lo que querían los usuarios), no pasa nada. Pero el tiempo es dinero. Y el precio final, hay que conocerlo. Los clientes suelen funcionar con presupuestos. No tienen el dinero en un cajón y tampoco lo tienen detenido. Cuesta mucho esfuerzo para un cliente presupuestar el dinero requerido para ciertos proyectos, por lo que ahora no sirve volver al consejo de dirección y decirles: "oye, necesitamos más dinero pero no os preocupéis, porque quedan pocas iteraciones y creemos que terminaremos pronto".

Los usuarios gustan de lo predecible.

A los usuarios les gusta saber no sólo lo que les va a costar el software. Además quieren saber cuándo va a estar disponible, y mucha más información del producto y proyecto final. Que sea difícil de predecir, no deja de ser algo que es problema de los informáticos, no de los usuarios.

Al hablar de iteraciones, los usuarios ven desorganización

En ocasiones, la sensación del usuario es que los informáticos se han rendido a los caprichos de los clientes. "Nos adaptamos a los cambios", decimos. Pero los clientes ven desorganización y falta de control. Y ojo, no nos obsesionemos con que esto no es así. Yo no digo que sea así. Lo importante es que el cliente sí que lo ve así. Y con esto tenemos un problema (unos cuantos ya en este artículo).

Los usuarios quieren ver el final

La sensación que percibe el cliente es que las metodologías ágiles llevan a proyectos sin final. Al no existir una fecha cerrada de entrega, sólo tienen claro que se les va a entregar un producto que sigue los requisitos (al menos, eso les hemos vendido durante muchas iteraciones). Pero no saben cuándo. Y necesitan ver el final. Porque muchas veces, cuando tenemos una fecha planificada y nos retrasamos, el cliente se puede poner nervioso. Pero si estamos iterando, aunque nosotros como informáticos entendemos que nos estamos "acercando progresivamente" al producto final...resulta que el cliente no lo ve así. Es posible, muy posible que lo que el cliente vea es un "retraso iterativo", es decir, se están haciendo cambios, y más cambios, pero la fecha se sigue escapando de las manos.
"¿No eran esto metodologías ágiles? ¿No se supone que tendría que haber terminado esto ya?"

Los usuarios quieren control

Las metodologías ágiles son buenas en entregar cosas, pero el usuario quiere el control, no dejárselo a los programadores. La percepción del cliente es que por mucho que se le involucre en la revisión de historias de usuario que entran en cada iteración, y en la revisión del producto final de dicha iteración...su control es escaso. Y lo que es peor, hay una falsa sensación de control que se confunde con exceso de poder. El usuario tiene el poder de moldear el producto final...aunque esto le lleve a dar bandazos funcionales que en el fondo, no son el control. Porque el cliente no entiende como control añadir y quitar funciones.

¿Estamos ante el fin de las metodologías ágiles? Pues no lo creo. Yo llevo usando y conviviendo con ellas desde 1999. El problema es que han pasado de grandes promesas a grandes decepciones. Se puso demasiado énfasis y demasiadas esperanzas en las que prometían ser las grandes balas de plata del siglo 21. Y no han resuelto nada de lo que prometieron. Por supuesto, en los proyectos y clientes que encajan, las metodologías ágiles suponen una ventaja.

¿Qué podemos hacer con los usuarios? Pues como hemos visto en este artículo, los usuarios, el cliente, pueden no entender o incluso ser poco receptivos a las metodologías ágiles. Y es nuestra obligación RESPETARLOS. Sí, no podemos pedir respeto para nuestra profesión, y luego tratar de imponer cosas al cliente, faltándole al respeto. Tenemos que solventar estos problemas con el usuario a base de:

• Disciplina
• Uso consistente y coherente de buenas prácticas
• Educación
• No agobiar al cliente con conceptos ágiles. Usar terminología adaptada al cliente. Somos nosotros los que debemos esforzarnos en hablar su lenguaje, NO AL REVES.
• Formación
• Introducción progresiva de las técnicas ágiles, aun cuando los proyectos no usen metodologías 100% ágiles.
• Flexibilidad. Si el cliente no encaja técnicas ágiles, buscar sustitutos adecuados (sin obsesionarnos con si son ágiles o no, solamente en que sean adecuados al proyecto/cliente).

Sólo así lograremos credibilidad con nuestros clientes y éxito en nuestros proyectos.

El escalado y la falta de criterio

Hoy, vamos a ver el concepto del escalado. Y aunque os puede sonar un poco teórico, no sólo no es así, sino que por desgracia, se produce habitualmente en cualquier empresa.

En ITIL, se conoce al escalado (entre otros ámbitos) dentro del proceso de Gestión de Incidentes, al caso que se produce cuando algo no se puede resolver de forma inmediata, y es necesario recurrir a un especialista (léase experto, tanto a nivel de conocimientos, como a nivel de decisión o poder), para tomar decisiones que escapan a su responsabilidad.

Es decir, se han de dar una o varias de las siguientes condiciones:

• Ha de haberse producido un problema o incidente real
• Ha de producirse una situación que realmente no podemos resolver
• ...o bien ha de producirse algo que escape a nuestra responsabilidad.

¿Hasta aquí todos me habéis seguido? ¿Alguien se ha perdido? Espero que no.

Hasta ahora hemos hablado del escalado: qué es lo que debe cumplirse para que pueda producirse un escalado, y qué violaciones o negligencias se pueden realizar. Pero aún falta hablar de la otra mitad del post...la falta de criterio.

¿Cuál es el problema? Pues el problema viene cuando alteramos o manipulamos el escalado de una de las siguientes formas:

• No se ha producido el problema o incidente que mencionamos. También puede ser que lo estemos exagerando, o que ocultemos parte de la verdad en nuestro beneficio (o en perjuicio de terceros).
• No hemos intentado resolver la situación. La escalamos sin actuar, esperando que otro se ocupe de ello. También se conoce como "pasar el marrón" o "que le explote a otro".
• No actuamos a pesar de ser nuestra responsabilidad. Claro, si es nuestra responsabilidad, si o si, tendremos que actuar ANTES de escalar. El problema es cuando no queremos responsabilizarnos del problema, y por eso lo escalamos (aunque tal y como hemos visto, técnicamente no sería un escalado, ya que deberíamos habernos responsabilizado primero de ello).

¿Y tú? ¿Escalas?

Deloitte University

Pues ya hemos vuelto de Texas, y en realidad a pesar de mi entrada anterior, la Deloitte University estaba más propiamente en WestLake, no en Dallas. De hecho, estábamos tan al norte, que el famoso desastre de los tornados en Oklahoma nos afectó y bastante. Pero bueno, eso ya es otra anécdota.

Sobre el evento, he de comentar varias cosas:

• Formación. El enorme esfuerzo que se hace en las compañías americanas en formación. En este lugar privilegiado no sólo había directores, gerentes y responsables en general (por algo le llaman el Leadership Learning Center), sino que cantidades ingentes de nuevos y jóvenes empleados (auténticos yogurines de apenas 20 o 23 años), llegaban a cientos a este centro formativo.
• Lujo, belleza y tecnología. Los mejores materiales, un cuidado diseño que hace pensar que estamos en un hotel de cinco estrellas en lugar de un centro formativo, eso sin olvidar que hay un cyber-center donde cualquier cosa que necesitemos, está a nuestra disposición para comprar: iPhones, iPads, portátiles, otros móviles, adaptadores, cables, etc, etc. Wi-fi gratis en todo el complejo, incluyendo la conexión inmediata de los empleados al usar sus portátiles o móviles de empresa.
• Gourmet ¿Alguien tiene hambre? Es difícil salir de este centro formativo sin unos kilos de más. Salas repletas de comida de todo tipo se reparte por las 5 plantas del complejo de habitaciones. Pensado para los que no tienen tiempo para bajar, o simplemente quieren picar algo sin alejarse de la habitación. Después, los restaurantes con buffet o los múltiples espacios para picar habilitados junto a las salas de formación, hacen que el día se pase sin sentir (salvo en el estómago!).
• En forma. Para compensar lo anterior, existe un gimnasio gigantesco: DTFit. En este lugar podemos encontrar desde decenas y decenas de máquinas de todo tipo, gran cantidad de actividades diarias programadas para que nadie tenga que aburrirse por su cuenta, hasta un exterior de varias hectáreas de terreno verde con árboles y muy cuidado para facilitar el running. Doy fe: no es extraño ver a la gente corriendo por las distintas pistas, especialmente a primera hora de la mañana o por la tarde.
• Relax. Un exterior cuidado, con árboles, pistas verdes, zonas ajardinadas con iluminación nocturna, un lago con aves, tortugas, peces...
• Sostenido. Un equipo de alrededor de 200 personas cuidan y mantienen el complejo: seguridad, camareros, cocineros, jardineros, mantenimiento, dependientes, limpieza, etc.

Así que tras este ajetreo, me pongo a pensar en lo importante que es la formación, y lo importante que es cuidar a los empleados. La mentalidad de que para rendir como los mejores, hay que invertir en nuestros empleados dándoles lo mejor, puede ser chocante. Pero no debería ser así, ¿verdad?

Influencia de la carga de trabajo en el ángulo del monitor

Hoy os voy a relatar hechos verídicos y contrastados. Se trata de una nueva teoría científica que creo que va a revolucionar el mundo de la tecnología. Seguramente pueda vender esta teoría y jubilarme. A ver qué opináis.

Vengo observando una correlación bastante acusada entre el ángulo de los monitores de los programadores, y su carga de trabajo, que voy a ir desarrollando a continuación:

Caso 1: alta carga de trabajo.

La experiencia muestra que cuando el empleado tiene una fuerte carga de trabajo, el monitor se encuentra situado justo enfrente del mismo, de forma que éste forma una línea paralela con el eje de los hombros, y habitualmente, también con la mesa, como muestra la figura siguiente.

Además, resulta interesante destacar que esta posición es independiente de la posición en la que se encuentre sentado el responsable/supervisor del empleado.

Caso 2: baja carga de trabajo durante un corto lapso de tiempo.

La gran mayoría de casos observados permiten notar un aumento en el ángulo del monitor, que ya no se encuentra paralelo al eje de los hombros, como se muestra en la figura. Lo que resulta ya sorprendente, es que el ángulo del monitor puede ser a un lado u otro, y esta vez, sí que hay una dependencia a la posición del jefe, de forma que el jefe parece tener la manía de situarse justo donde su posición impide ver correctamente la pantalla del empleado.

Caso 3: nula carga de trabajo durante largo tiempo

De nuevo, los datos empíricos muestran que en la mayoría de casos, el monitor del empleado que lleva mucho tiempo sin recibir trabajo, acaba como muestra la figura siguiente: prácticamente perpendicular al eje de sus hombros. Para evitar el bizqueo o el colapso del empleado, éste tiende a colocarse "ladeado", corrigiendo de esta forma la postura del monitor.

Otro punto a considerar es que como ocurría con el caso 2, el jefe del proyecto tiende a situarse en el lado del empleado desde el que no se puede ver su pantalla, hecho que hemos atribuido a la mera casualidad.

Influencia de la hora.

Otro hecho sorprendente, es que especialmente en los casos 2 y 3, al principio de la jornada, y cuanto más nos acercamos a la hora de salida, el ángulo del monitor se hace todavía mayor si cabe. Sin embargo, en las horas centrales del día el monitor tiende a volver a su posición normal. De nuevo, hemos de suponer que esto es mera casualidad.

Influencia del número de monitores.

Si en lugar de un monitor, analizamos las situaciones anteriores con empleados que tengan dos monitores, ocurre algo muy curioso. El primer monitor, al que llamaremos "1", permanece siempre frente al empleado (esto es, paralelo a lo que hemos llamado su "eje de hombros"). Sin embargo, el segundo monitor, sí parece verse afectado por los casos anteriores, de forma que sufre ángulos escandalosamente extraños en función de la carga de trabajo.
De nuevo, el número de monitores y la hora del día parecen tener una correlación, de forma que el monitor "1" parece usarse en las franjas centrales del día, y es el segundo monitor (el que hemos llamado "2"), el que recibe mayor carga de trabajo en las horas tempranas, y en las horas cercanas al final de la jornada.

 

Influencia de la distancia al jefe.

Otro punto interesante digno de estudio, es que el ángulo aumenta cuanto menor sea la distancia con el jefe. Es decir, el jefe muy alejado, hace que el ángulo del monitor sea pequeño. Pero si el jefe se acerca, el ángulo se hace mayor.

¿Y tú? ¿Has observado también en tu trabajo este extraño fenómeno?

El síndrome de Estocolmo

Podemos encontrar en Wikipedia la definición de este tipo de desorden:

Wikipedia: El síndrome de Estocolmo es una reacción psicológica en la cual la víctima de un secuestro, o una persona retenida contra su voluntad, desarrolla una relación de complicidad, y de un fuerte vínculo afectivo, con quien la ha secuestrado. Se debe, principalmente, a que malinterpretan la ausencia de violencia contra su persona como un acto de humanidad por parte del secuestrador.

Esta definición, que nos parece tan fuera de nuestro ámbito de empresas de desarrollo de software, ocurren en nuestra industria mucho más de lo que creemos.

 

El equipo de desarrollo con el Jefe de Proyecto.

Cuántas veces hemos oído a los programadores o analistas excusar al jefe de proyecto que gestionó algún conocido desarrollo o implantación.

Por desgracia, cuanto mayor es el sobre-esfuerzo, cuanto mayores y más largas son las semanas o meses de brutal agotamiento, mayor es el síndrome de Estocolmo. Se llega a oír cómo las más peregrinas excusas surgen de los labios de quienes han sufrido de primera mano las malas decisiones, la pésima gestión (o la total carencia de la misma) de ese jefe de proyecto.

Es normal que aceptemos las imperfecciones de la gente, es correcto. Pero ya no es normal olvidarnos de las responsabilidades y trasladarlas a otros, como si un jefe de proyecto fuera una imagen de un mártir, un inocente de las circunstancias.

El programador con el Analista/Arquitecto.

Tampoco es extraño oír cómo el equipo defiende a su analista responsable, al arquitecto que definió la estructura, a quien pensó (con tan mala fortuna) las pantallas...

Pues sí, el síndrome de Estocolmo también aplica a los perfiles técnicos altos, pues tantas horas con ellos, tantas excusas ofrecidas, acaban por minar la resistencia moral. Después de todo, están con nosotros en las largas semanas (días y noches incluidos) que necesitamos para hacer funcionar sus incompetentes diseños y sus incongruentemente desorganizadas y sobrecargadas arquitecturas.

El programador con el cliente.

No nos engañemos. También podemos sufrir este síndrome con un programador. Si se trabaja mucho tiempo en las oficinas del cliente, llega a establecerse un vínculo entre el equipo de desarrollo y el cliente. Sin embargo, al pasar el tiempo y si el equipo de desarrollo sigue trabajando en las oficinas del cliente, este equipo pierde su vínculo con su propia empresa.

En este tipo de situaciones, nos encontramos con casos en que los desarrolladores obedecen al cliente, aún en situaciones en que saben que están desobedeciendo o contradiciendo las órdenes recibidas de su jefe de proyecto.

Ocurre en desarrollos, pero también en mantenimientos. En un mantenimiento, es típico ver cómo un programador sale corriendo a resolver una incidencia sin esperar a que sea notificado su registro, sin esperar a que sea revisada, escalada, etc. En estos casos, el equipo de desarrollo se preocupa solamente de contentar al cliente, y acaba trabajando como si formara parte del equipo del propio cliente.

En estos casos, llega a perderse el control de lo que se trabaja. El equipo de mantenimiento está muy ocupado, pero sus responsables no son conscientes de ello. Se registran menos incidencias de las que realmente se resuelven...incluso de llevan a cabo evolutivos a escondidas que con suerte se quedan como simples correctivos.

¿Y tú? ¿Has observado también en algún proyecto el Síndrome de Estocolomo?

De novato a experto en 10 minutos. Manual de gurupollas.

Esto es una guía de cómo actuar como un auténtico gurupollas, y está inspirada, antes de continuar, en el enlace: "De profesión experto. Manual exprés." A los que lean el artículo original, les aviso de que como siempre, aquí hay buena parte de mi cosecha. Vamos allá.

1. Escoja un tema difícil de verificar.

Si no lo puede crear, únase al último de moda. Asegúrese de que sea algo novedoso y poco conocido, de forma que nadie pueda rebatir sus escasos o inexistentes conocimientos. Cuanta más prisa se de en aparecer como referente en ese tema, más fácil será que sus círculos acaben asumiendo que usted efectivamente forma parte de esa nueva corriente de pensamiento.

2. Invente un concepto y nómbrelo en no más de tres palabras.

Una de ellas debe ser un sustantivo sonoro y contundente de no más de cuatro sílabas. Algo así como burbuja o mariposa. No trate nunca de explicarlo. Ya tratarán los demás de darle sentido. Piense en títulos de libros o películas para inspirarse.

3. Abra un blog y escriba a diario contenidos inspirados, agudos e ingeniosos sobre la materia.

Abuse de términos como sinergias, implementar y proactivo. Trate de incluir espasmódica y sistemáticamente referencias a algún libro famoso del término nuevo. O mejor: diga que participó como co-autor de dicho libro y que está en disputas legales con el autor reclamando sus derechos.

4. Tuittee intensivamente y solicite sin pudor que le retuitteen.

Cree hashtags como si no hubiera un mañana (pero nunca diga "como si no hubiera un mañana"). Retuitee cualquier twit en el que se hable del tema en que quiere venderse como experto. Se trata de que por cansancio, le acaben relacionando con ese tema.

5. Haga circular información sobre su omnipresencia digital.

Cuente a todo Dios las veces que ha sido retuitteado.  Exagere detalles y circunstancias del hecho. Siempre alguien se lo creerá. Hable de los muchos blog que escribe, libros, participación en revistas, foros, etc. Tiene que parecer que de cada 10 palabras que se escriben en internet, usted ha escrito al menos 3... y al menos otras 6 están inspiradas en las suyas.

6. Escriba un libro.

En breve será considerado  "la biblia de …" y usted "el gurú de …". Esto enlaza con una de mis últimas entradas sobre los gurupollas. Siempre puede pagar a otro para que escriba el libro...o tomar uno existente y afirmar directamente que ¡usted lo pensó primero! Deje caer en los medios sociales que va a tomar medidas legales y represalias contra el autor del libro por robar su idea. Por supuesto, no haga nada de esto en realidad.

7. Hágase con un buen enemigo. Alguien famoso e intelectualmente disfuncional que ponga en duda su teoría.

No le tema, él lo necesita más a usted. Difunda las opiniones contrarias. No hay corriente sin contracorriente. Es la llamada "dicotomía gurupóllica" (ok, me lo acabo de inventar): es cuando dos gurupollas, cada uno se inventa un término opuesto y lo defiende. En lugar de contradecirse, acaban apoyándose y logrando crear dos escuelas de pensamiento opuestas.

8. Adquiera la última versión del Ipad o IPhoney póngalo en cualquier superficie visible durante sus charlas.

Representa solvencia técnica, intelectual y económica. Vincule toda opinión humana o divina al espíritu de Silicon Valley. Si puede, lleve además otros dos o tres móviles de alta gama para apoyar que usted está metido en tantos proyectos que es capaz de necesitarlos.

9. Contrate por un módico precio a un experto anglosajón que le cite con frecuencia … en Inglés.

Mejor aún: pague a alguien en Linkedin para que haga comentarios positivos y exagerados sobre sus cualidades y participación en los proyectos. Asegúrese mencionar que en sus proyectos ha tenido alrededor de 4 o 5 veces más gente a su cargo que en la realidad. Si ha estado en algún proyecto de pasada, diga que usted fue el arquitecto y principal responsable, con todo el resto de gente a su cargo. Difícilmente nadie se lo va a contradecir, y sin embargo impresionará a mucha más gente. Además tiene que parecer que usted escribe inglés con naturalidad. De hecho, debe quedar patente que los principales diccionarios en inglés le piden a usted que los revise y los valide. Usted no es responsable de anglicismos en el castellano, sino de castellanizar la lengua de Shakespeare.

Si te ha gustado, puedes seguir con el artículo original, algo distinto, pero con muchos más pasos para convertirte de novato a experto. Enhorabuena a su autor.

Conforme lo escribía, me asustaba porque me encontraba a mí mismo tentado de usar varios de ellos en  alguna que otra ocasión. En fin. Ya se sabe que el lado oscuro poderoso es.

La gestión por falsa presión

Hola, tras el éxito del último post sobre los gurupollas, vamos a retomar la temática del desarrollo de software y la calidad.

Hoy el tema versa sobre la metodología de gestión basada en crear una falsa presión en el equipo. Hay varias formas de hacerlo. Repasaremos algunas, y creo que así me entenderéis mejor:

1. Falsa fecha de finalización.

Esta técnica, consiste en trasladar al equipo de desarrollo una falsa fecha de fin de proyecto. Es decir, si por ejemplo sabemos que el proyecto ha de estar entregado el 15 de Junio, podríamos decir al equipo que debemos entregar el 15 de Mayo. Con esto, conseguiremos trasladar una falsa presión, pedir más compromiso, bla bla bla.

¿Y qué ocurre si se llega con éxito a la falsa fecha? Pues tendríamos casi un mes para añadir funcionalidad o corregir errores y preparar documentación.

¿Y si no llegamos a la fecha de fin? Pues no hay problema, porque contaríamos con un mes de margen. Y siempre les podemos decir al equipo que somos nosotros, gracias a nuestra maravillosa gestión, quienes hemos conseguido un mes más de plazo.

Así matamos dos pájaros de un tiro: conseguimos que el equipo se esfuerce desde el minuto cero como si fuésemos retrasados antes de empezar. Y además, podremos defender que gracias a nuestra maravillosa gestión (¿qué gestión?), hemos conseguido un mes más de tiempo para que se pueda terminar con éxito.

En resumen: (a) esfuerzo desde el principio, y gratis. (b) Logramos quedar como los salvadores del proyecto gracias a nuestra gestión. (c) El cliente, consigue tener algo funcional y operativo mucho antes, y hay tiempo asegurado para cambios de última hora, documentación, etc. Eso sí, luego hablaremos del coste humano que tiene.

2. Falsa fecha de entrega parcial.

Este caso es una variante del anterior. Basta que le digamos al equipo que el cliente quiere tener una entrega funcional parcial de la solución final.

Si alguno de nuestros programadores conoce la fecha de fin de proyecto, será el truco que tendremos que usar, ya que no podremos mentirles con una "falsa fecha de finalización".

Los resultados son los mismos, pero por desgracia, los costes (más adelante hablaremos de ellos), también.

3. Funcionalidades falsas por exceso.

Hay ocasiones en que hay funcionalidades extras, que o bien interesan al jefe de proyecto, o bien estaban en el contrato como "extras" o "valor añadido".

También es posible que sean funcionalidades que detectemos que pueden venir bien de cara a la imagen del producto final, aunque realmente no estuvieran identificadas como requisitos.

Si en lugar de tratarlas como requisitos, nos limitamos a decir que son "obligatorias" y estaban "pactadas" desde el principio, tendremos una variante de los casos 1) y 2): logramos trasladar presión al equipo para empezar a esforzarnos al límite desde el principio pero no por una fecha falsa, sino por unas funcionalidades falsas.

4. Funcionalidades falsas por defecto.

Esta es una variante de la anterior (nº3), en la que el jefe de proyecto decide trasladar a su equipo sólo un subconjunto de los requisitos, pero normalmente se combina con las técnicas 1) y 2) para de nuevo, lograr una falsa presión en el desarrollo, y de esa forma, lograr con sobreesfuerzo y sacrificios lo que no somos capaces de hacer mediante nuestra capacidad de gestión.

¿Beneficios?

A continuación, veamos qué hemos logrado con todo esto:

• Esfuerzo del 120% del equipo, desde el minuto 0
• Trasladar un sentido de culpa al equipo de desarrollo, trasladándoles la culpa y la presión. Después de todo, el jefe de proyecto no es que no gestione porque no sepa, sino porque la falsa presión creada hay que justificarla también con una locura organizativa, falta de planes, calendarios y objetivos. Se trata de correr a toda costa para lograr los falsos objetivos parciales.
• El jefe de proyecto consigue reconocimiento, pues es más fácil lograr el éxito, a costa del equipo y su salud.
• El jefe de proyecto consigue quedar bien, pues aparenta que las nuevas fechas y funcionalidades son gracias a su gestión con el cliente y sus enérgicas habilidades negociadoras, y no por haber ocultado y tergiversado los objetivos en fechas y funcionalidades.
• El cliente observa avance, esfuerzo y tiene una falsa percepción de compromiso.

Costes de esta mala praxis

¿Y esto sale gratis? ¿Tiene alguna consecuencia?
Pues claro. Veamos algunos de los costes derivados:

• El equipo se quema muy pronto. Es fácil perder empleados que se van a otras empresas, bajas por depresión o enfermedad, etc.
• El producto conseguido necesita corregirse, bien en el tiempo "extra" conseguido, o bien en una fase de mantenimiento. El producto suele funcionar más o menos, pero suele ser insostenible, del tipo "mírame pero no me toques". La calidad se ve penalizada, y creedme que lo lamentará el pobre mortal que se atreva a mantener este inmundo código.
• El esfuerzo necesario para hacer la aplicación es mucho mayor, ya que la falta de documentación y la tensión necesaria lograr los falsos objetivos hacen que luego haya que retocar todo para que realmente funcione.

¿Te ha pasado alguna vez algo parecido? ¿Has observado en tus proyectos o en proyectos de conocidos alguna de éstas técnicas y/o sus consecuencias?

5 puntos que te salvarán de los cambios (y 3 que te hundirán si no los evitas)

En todo proyecto software, hay cambios. El cambio, hay que aceptarlo como lo que es, y entender su motivación y circunstancias. Hoy nos vamos a centrar en estar preparados para el cambio en el desarrollo de software, mediante 5 puntos clave que hay que conseguir. Además, otros 3 puntos clave que hay que evitar, para que no nos "hundan el chiringuito". Vamos Allá.

1. Puntos Clave a cumplir

1.1. El proyecto tiene designado un equipo/comité responsable de los cambios.

No hace falta que sea un comité sofisticado, ni pensemos en un comité como 20 personas serias y  estiradas reunidas en una sala gigante durante horas. Un comité simplemente es una reunión formal o informal, en la que se revisan temas (cambios en este caso), y donde todas las partes están representadas. Una persona puede representar a varias partes. Por ejemplo, sería interesante que al menos hubiera participantes por parte de:

• Cliente (responsable que defiende los intereses del cliente).
• Equipo de desarrollo (responsable funcional/técnico)
• Dirección del proyecto (responsable económico/planificación)

Puede ser suficiente un foro, un blog, o una lista de correo (ni siquiera se tienen que reunir físicamente esas personas).

1.2. El proyecto tiene un plan o procedimiento escrito y aceptado de gestión de cambios.

Aquí, de nuevo, menos es más. Me  hace gracia cuando en una reunión planteo cómo se van a gestionar los cambios. Todo el mundo asume que los cambios se van a hacer. Ese no es el tema. La gestión del cambio está para decidir qué/cuándo/cómo. De eso hablaremos en detalle otro día.
Como siempre, lo importante es aclarar el funcionamiento y acatar las decisiones tomadas en consecuencia.

1.3. Las peticiones de cambio se evalúan por todas las partes implicadas en el proyecto, antes de resolverse.

Esto es importante, si nos dejamos a alguien fuera al resolver un cambio, tenemos todas las probabilidades de que esa parte decisoria será la que nos haga echar el cambio atrás. De hecho, hay gente que lo hace por el mero placer de ejercer el poder de hacerlo.

1.4. El equipo/comité responsable de cambios, se asegura de que todas las partes implicadas están adecuadamente informadas de cómo se resuelven los cambios.

Otra vez un punto crítico: no nos dejemos a nadie fuera. ¿Te gusta que tu pareja tome una decisión o haga algo sin decírtelo? (no, ya sé que tu pareja lo hace, te estoy preguntando si te gusta!).

1.5. El equipo/comité responsable de cambios evalúa los cambios por paquetes, evitando distraer al equipo de desarrollo de forma constante.

Bastante tienen/tenemos los desarrolladores con lidiar con las complejidades técnicas, las dificultades de las distintas arquitecturas, la definición funcional, etc, etc....como para que encima nos interrumpan cada poco tiempo con cosas nuevas. Hay quien dice que es mejor interrumpir con los cambios, ya que éstos pueden afectar al trabajo en curso. MENTIRA. Déjame acabar lo que estaba haciendo, y luego ya veré cómo aplico el cambio. ¿A alguien se le pasa por la cabeza reformar su casa mientras los albañiles están levantando los pisos y poniendo ladrillos?.

2. Puntos clave a evitar.

2.1. Las decisiones del comité de cambios pueden contradecirse por la dirección, marketing o el cliente.

A ver, hay que ser serios. Respetemos los acuerdos alcanzados.

2.2. El equipo de desarrollo no tiene tiempo suficiente para seguir el plan.

De nada sirve montar un comité ni toda esta fiesta, si el equipo de trabajo está con sobreesfuerzo. Si no hay tiempo, y el plan no se puede seguir, menos aún podremos abordar cambios. Hay técnicas para eso, pero mejor lo dejamos para otro día.

2.3. Los productos del trabajo no siguen el control de cambios.

Esto que dicho así suena muy sofisticado, no es más que hacer el maldito check-in, anotar los cambios, y asociarlos a alguna tarea. Lo mismo cuando estemos preparando una versión al final de un sprint. Etiquetemos adecuadamente las versiones, su estabilidad, etc. Pocas cosas hay más divertidas que después de que nuestro equipo de sufridos testers pierda días y días probando la versión N, ahora vamos nosotros y entregamos al cliente la versión N+1. Manda huevos.

Ética e Ingeniería del Software

Fuente: http://www.asme.org/

Recientemente, en el blog de Javier Garzás he leído un post donde se propugna algo que llevo repitiendo hasta hartarme desde el primer post: que debemos comportarnos profesionalmente, de forma ética.

No somos charlatanes, patanes de feria que vendemos lo que nos convenga en función del beneficio que nos proporcione. En lugar de eso, damos al cliente lo que necesita en cada momento, maximizando su satisfacción y nuestro beneficio a largo plazo. Porque creemos en que la relación con nuestros clientes se cimenta en una confianza mutua, y ésta sólo puede realizarse a largo plazo.

Esta forma de pensamiento la he visto como eco en algún otro post. Me hace mucha gracia, que Javier afirma: "una metodología no es un equipo de fútbol, ni un partido político, ni una religión". Sin embargo, leo por doquier en la red continuas llamadas talibanistas a defender la religión del bloguero de turno:

• Metodologías ágiles
• Software libre
• CMMI
• Integración continua
• <Pon aquí tu práctica/metodología/marco de trabajo>

El pensamiento que defiendo es similar al promulgado por Alistair Cockburn hace ya unos años:

"Estoy cansado de la gente que es de una escuela de pensamiento y que rechaza las ideas de otra escuela de pensamiento. Tengo hambre de gente que no le importe de donde vienen las ideas, que les importe sólo lo que significan y lo que producen. Así que se me ocurrió esto del “juramento de no lealtad”.
Esto significa el fin de afirmaciones como “eso no está bien – no es ágil / orientado a objetos / puro / etc.”, en vez de discutir sobre si la idea (ágil o tradicional o impura o lo que sea) funciona bien en las condiciones del momento."

Por desgracia, hay gente que incluso afirmando defender estas ideas, confiesa sus prejuicios y reticencias al respecto de ciertas formas de trabajar: "metodologías", "prácticas", "marcos de trabajo"...llamadlo como queráis.

Podemos estar convencidos de una cosa, pero no debemos defenderla si no es con argumentos probados, objetivos y no sólo cualitativos sino también cuantitativos. Por desgracia, esta forma de pensar encaja perfectamente en los que yo llamo "indecisos patológicos" o "charlatanes del depende". Sí, ya los conocéis. Me refiero a los que siempre contestan a todo con un "depende" (hasta aquí todo va bien), pero que cuando se les pide algo más de detalle o chicha en su discurso, podemos tener dos tipos de respuesta:

• Verborrea coherente pero carente de fondo y forma, que al final no termina de dar ningún tipo de argumento veraz ni mucho menos objetivo hacia un lado u otro. Esta verborrea de político le viene muy bien a algunos individuos, que incluso les facilita la promoción profesional. Pero lástima de los clientes que acaben con ellos, y mucho peor: lástima de los que acaben en un proyecto dirigido por estos pseudo-profesionales.
• Verborrea que sólo está orientada a alimentar el ego del que escucha. Son los llamados aduladores, los pelotas, que difícilmente terminan hablando del tema, sino que redirigen la conversación a un terreno menos objetivo y relacionado con el proyecto en cuestión.

Al querer escribir yo este post, me he encontrado con otro post bastante interesante. En él, su autor deriva la conversación a la ética informática, y al colegio profesional. Este autor, plantea la existencia de un tribunal de ética. Yo no sé lo que pensaréis pero empiezo a estar harto de tribunales, comisiones, cortes, comités de supervisión, equipos de trabajo, etc, etc. Y estoy harto de apelar siempre a un "ser superior" que nos proteja y defienda.

Es muy fácil: lo único que puede definir el comportamiento ético o no en un proyecto es la documentación. Los criterios objetivos, y la forma en que se basan y defienden, es lo único que puede usarse como valor ético en un proyecto. Pero claro, decir esto cuando la moda es ir en contra de la documentación, ser ágil, y entregar todo de forma rápida (y sin documentación), es poco menos que escupir al viento. Pero no deja de ser cierto. No es posible verificar la ética en un proyecto sin contrastar el contrato, con las decisiones tomadas (y las decisiones, o se documentan...o se pierden). Y es así en todas las profesiones.

Después de todo, en una profesión en la que no hay estándares cerrados, en los que no hay normas internacionales que establezcan la forma correcta de trabajar, todo vale. No podemos a la vez defender que hacer software es un arte, y al mismo tiempo querer crear Colegios, Comisiones éticas que verifiquen el buen hacer...respecto a qué?

En fin...excelentes Alistair Cockburn en su comentario, y Javier Garzás y Jorge Ubeda en sus respectivos posts. Espero que esta pequeña reflexión mía haya podido aportar algo.

La culpa no es del usuario

Hoy vamos a ver quién tiene la culpa de los fallos del software.
Me acabo de encontrar una referencia a mi antigua entrada "Cuando la culpa es del usuario", en la que yo bromeaba sobre quién tiene la culpa de los fallos en el mundo del software. Yo pensaba contestar o comentar en aquél blog, pero al final, había que registrarse y he desistido. Sin embargo, al ver los argumentos a favor y en contra, he pensado que hay que darle otra oportunidad a mi antigua entrada, y recuperarla, esta vez de forma algo más seria.

¿Quién tiene la culpa de los fallos del software?

Vamos a verlo con un ejemplo. Supongamos que hacemos una casa: planos, diseño, ejecución de la obra...todo. Y el usuario entra en la casa a vivir. Hemos construido la casa en base a las funcionalidades habituales: comer, desayunar, ir a dormir, ir al baño, entradas de luz, etc. Además, hemos cumplido las normativas existentes: seguridad, anchura y altura de puertas y ventanas, acceso de luz, aislamiento térmico, etc.

Supongamos que el usuario hace algo imprevisto como intentar salir por la ventana (y es un 8º piso). Si se muere, ¿está claro que es su culpa, no? Pero si le dejamos abierta la puerta al cuarto de alta tensión y no ponemos ninguna medida de seguridad...si se electrocuta y muere...quizás la culpa SEA NUESTRA.

Ahora supongamos que hace otras cosas como entrar por el garage en vez de la puerta de entrada, o tiene la absurda (o no tan absurda?) idea de comprar un sofá o una cama y éstos no caben por la puerta. Puede también querer mirar por la ventana, y encontrarse conque ésta da a la pared del siguiente edificio al que el nuestro se encuentra pegado (vamos, que sólo va a ver y tocar pared). ¿Quién tiene la culpa de esto?

Volvamos al mundo del software y veamos unos pocos casos más tecnológicos:

• El usuario entra en una parte no permitida del sistema. No podemos impedir que alguien obtenga una contraseña. Hasta ahí es cierto. Pero es nuestra responsabilidad como desarrolladores de software, que no sea posible acceder a partes del sistema restringidas, con una clave no autorizada. Esto me hace mucha gracia, porque tenemos la chulería de exigir que Windows sea super-mega-seguro...pero luego hacemos aplicaciones con más agujeros que un colador. Y entendemos que necesitamos un tiempo razonable para probar y corregir nuestros agujeros de seguridad (somos humanos, verdad?), pero no tenemos la misma tolerancia cuando en vez de desarrolladores, somos usuarios. Exigimos que el programa o sistema operativo que falla, se corrija DE INMEDIATO (los que lo programan no deben de ser humanos, sino robots). Y gratis. Y....vamos, que está claro que sabemos pedir...pero no dar. Exigimos derechos desproporcionados a los deberes que asumimos.
• El usuario juega con el sistema. Pues que juegue. Es el usuario. ¿Que lo rompe o cuelga haciendo alguna tarea prohibida? Para eso están los logs. ¿Que mete datos estúpidos o incorrectos? Para eso están los logs y el sentido común. Por supuesto, también están las validaciones de datos. Si permitimos "XXX" como fecha de nacimiento, probablemente la función de cálculo de Edad fallará.
• El usuario tiene que sacar su trabajo, que no es precisamente saber de la tecnología interna del programa. No tiene porqué saber si es puro Java, o JQuery...o lo que sea.

En fin, habría muchos más ejemplos que ahora mismo no tengo tiempo de abarcar. Pero sí me gustaría comentaros un caso real de un colega de profesión ha tenido, y que creo que va a ser representativo.

Caso real.

• Se trata de una aplicación web.
• En uno de los cambios de especificación, se añade soporte para iPad.
• La aplicación se prueba, y funciona correctamente en varios navegadores, tanto en Windows como en dispositivos iPad (hasta en Android!)
• Cuando llega el usuario, descubre que cierta funcionalidad, sólo está disponible con ratón: al pasar el ratón por encima de los elementos de la página, aparece una información específica de cada elemento. Esto, se introdujo por diseño para disminuir la información de pantalla. Y está genial. Pero un iPad no tiene ratón.
• Resultado: enfado del usuario y rediseño de la aplicación.
• ¿Quién tuvo la culpa?

Conclusiones:

Para acabar, resumamos las conclusiones de lo que hemos visto, y de lo que la experiencia me ha hecho ver en todos (y son muchos) estos años:

• El usuario no tiene culpa alguna de los errores que se producen.
• Es nuestra responsabilidad poner "paredes" y "puertas y ventanas" a la aplicación para permitir el acceso o no a las funcionalidades.
• Es nuestra responsabilidad cumplir las normas y estándares existentes, así como adaptarlos no sólo al tipo de usuario, sino al entorno (hardware y sistemas software con los que interactúe).
• Es nuestra responsabilidad identificar posibles interacciones del producto con otros productos, y ponerlo  como funcionalidades (si funciona) o restricciones (si no funciona).
• Es nuestra responsabilidad probar. Y probar todo, o asumir los riesgos de lo que no se prueba. Leía recientemente un post donde un compañero de profesión decía que no se puede cubrir todo con las pruebas. Y es cierto. Pero eso no significa que nos tapemos los ojos e ignoremos los riesgos.
• Automatizar es la clave: debemos hacer pruebas unitarias, y automatizar también las funcionales en la medida de lo posible. En el caso real que se ha mencionado, el problema no era del usuario, era de que no se hicieron todas las pruebas en todos los entornos. Si probar todo en tu PC cuesta 2 días...añadir un nuevo entorno (iPad), costará el doble (bueno, es una primera estimación).