Lo más importante es saber cambiar...

En un post anterior comentaba lo cansado que estaba de escuchar hablar del movimiento ágil. Cuidado, no es que esté en contra o no me guste, todo lo contrario. Lo que ocurre es que llega un momento en que la misma etiqueta se usa para todo y entonces pierde un poco de sentido (los últimos quince años están repletos de ejemplos: reingeniería, gestión del conocimiento, orientación a objetos, componentización, etc., etc.)

Personalmente, creo que SCRUM y FDD son lo mejor que ha surgido en los últimos años. Su visión de cómo organizar el trabajo es una verdadera bocanada de aire fresco en medio de tanta obsesión por el control (ver post acerca de Tom DeMarco).

Sin embargo, implementarlas no es tarea fácil. Si bien casi todas resultan "simpáticas", conseguir que se adopten masivamente es todo un desafío.

Caminando un poco el mercado, lo que se puede observar es la marcada incapacidad de muchas organizaciones de poner en marcha cualquier tipo de práctica que altere el status-quo.

Esa tendencia a mantener viejas costumbres está en la misma naturaleza del ser humano. Nuestro cerebro consume menos energía cuando dirige automáticamente actividades rutinarias. En cambio, cuando aprendemos algo nuevo usamos la corteza prefrontal, una zona que devora recursos.

El cerebro intentará usar lo menos posible la corteza prefrontal para ahorrar energía. Esa es la razón por la cual nos cuesta abandonar hábitos arraigados: Cambiar produce una respuesta fisiológica en el cerebro.

El cambio también está condicionado por las variables sociales. Los grupos se mueven cuando hay una masa crítica que apoya el cambio. Una minoría jamás lo conseguirá.

Por lo tanto, ya se trate de un nuevo sistema, de una metodología ágil o de un nuevo entorno de desarrollo, es fundamental saber cómo implementar el cambio efectivamente.

Lamentablemente, a lo largo de los años me ha tocado ser testigo de cómo muchos programas de mejora han quedado solamente en promesas por no saber cómo encarar la necesaria transformación.

Aprender a cambiar es vital para la supervivencia de cualquier organización. Sin esa habilidad, poco éxito tendremos en la implementación de nuevas prácticas y procesos.

¿Por qué son malos los servicios?

Estamos en una economía signada por la provisión de servicios. Sin embargo, son muy pocos los que toman conciencia de la importancia de diseñarlos. Resulta muy natural diseñar un producto, pero diseñar un servicio suena como algo raro.

En nuestro país tenemos muchos ejemplos de servicios mal pensados y pésimamente implementados. Los encontramos todos los días, en los lugares más diversos: en el consultorio del médico, en el banco, en los organismos públicos, en las mesas de ayuda...

En muchos casos, es uno el que tiene que hacer el follow-up de los trámites: "Ah, estábamos por llamarlo para avisarle que..."; "Cruce enfrente y saque fotocopias de las páginas 2 y 3"; "Tiene que traer una copia del resumen de cuenta"; etc; etc.

¿Tan difícil es organizarse? ¿Tan difícil es entender que si somos una empresa de servicios tenemos que diseñarlos para que nuestros clientes/usuarios tengan una experiencia agradable y no se vayan agobiados o desalentados por la mala experiencia de tener que interactuar con nosotros? ¿Tan complicado es publicar en la web los requisitos para realizar un trámite o para solicitar un servicio?

Lo mismo es válido para los servicios entre áreas internas: ¿Cómo hago para reportar un incidente con una aplicación?; ¿Cómo hago para pedir una PC?; ¿Cómo hago para...?

Es fácil demostrar cuán negativamente impactan los servicios que se brindan mal. No sólo hay problemas con la imagen de las organizaciones ("Me atendieron remal") sino también consecuencias económicas: duplicación de esfuerzo, información redundante, mal clima general por la desorganización, focalización en lo urgente y no en lo importante, etc., etc...

Las soluciones son relativamente fáciles: hay que diseñar la experiencia del usuario/cliente, definiendo los atributos del servicio y estableciendo los procesos adecuados para proveerlo. De más está decir que al usuario/cliente no le interesa si su pedido está trabado en un departamento determinado o en está detenido en el proceso de aprobación: Lo único que considerará en su evaluación es si lo atendieron amablemente, si le pidieron la información indispensable y no tuvo que repetir 25 veces lo mismo ante otros tantos interlocutores, y si el servicio recibido y los tiempos estuvieron acordes con los estipulados por el proveedor ("En 48. hs lo visitará uno de nuestros técnicos").

Entre tantas cosas que andan dando vueltas por ahí, hay un modelo de capacidades para la tercerización de servicios con fuerte base tecnológica. Se llama eSCM (eSourcing Capability Model) y fue desarrollado por el IT Services Qualification Center de Carnegie Mellon (la misma universidad de CMMI, pero en la facultad de Ciencias de la Computación). Vale la pena darle una mirada. Aquí está el link.

Estoy cansado del movimiento ágil...

En mi anterior post reproducía algunos comentarios de Ivar Jacobson acerca del movimiento ágil. Creo que sus dichos reflejan lo que muchos pensamos: las principales ideas del movimiento ágil ya forman parte (o al menos deberían) del background de la mayoría de la gente (de ahí a que las pongan en práctica es otro tema). Se habla tanto de "agilidad" que prácticamente ha perdido su significado (lo mismo está pasando con lean).

Por esa misma razón, creo que no tiene sentido ya hablar de "ágil" versus "no ágil." Los que estamos en este negocio desde hace años sabemos que para cada problema hay un enfoque determinado; para un desarrollo pequeño, de baja complejidad, las herramientas deben ser forzosamente sencillas. Para emprendimientos más complejos, el enfoque debe ser diferente. En todos los casos debemos ser ágiles y estar en condiciones de adaptarnos.

Por supuesto que debemos aceptar que en todos estos años hemos aprendido mucho. Algunos "evangelistas" que se inmolan en el púlpito olvidan que el enfoque "tradicional" era el único que había para desarrollar software, aunque en general lo que se hiciera fuera "codificar y probar". Lo que muy bien ha hecho el movimiento ágil fue integrar ideas que estaban dando vueltas desde hace mucho, tomar prestadas algunas otras de otros dominios (por ejemplo, del desarrollo de productos) y agregar las suyas. Su filosofía y las prácticas que propone ya forman parte del cuerpo de conocimiento de la ingeniería de software.

Lo que creo que nunca terminaremos de entender como profesionales es cuánto es suficiente. Me he topado con gente que no entiende que el planeamiento debe ser gradual y progesivo y piden "planes detallados" cuando no es el momento. O supuestos "especialistas" que hacen planes de proyecto con tareas tan granulares que duran menos de quince minutos ("Agendar reunión"). O gente que quiere cerrar los requerimientos antes de empezar con el desarrollo y se consume la mitad del tiempo y los recursos en preparar una propuesta de proyecto. Hace años que sabemos que en la mayoría de los proyectos los planes y los requerimientos se irán refinando en forma progresiva. Me causa un poco de gracia cuando algunos agilistas acusan al ciclo de vida en cascada de todos los males de este mundo. La verdad, no he visto en veinte años un proyecto con ese ciclo de vida (y dicho sea de paso, muy pocos con algún ciclo de vida). ¿Alguien vio alguno?

En el otro extremo, me he encontrado con desarrolladores que no pueden estimar el esfuerzo de hacer algo. Sus argumentos son que simplemente no pueden hacerlo. "OK, pero estamos hablando de una componente de tal tipo, de tales características, para hacer esto". "No puedo hasta que no lo haga". ¿No es de locos? Por supuesto que el desarrollo de software es buena medida exploratorio, pero sigue siendo imporante para el negocio hacer pronósticos. "¿Vamos a gastar 20 pesos o dos millones de dólares?".

En definitiva, creo que el único camino es balancear constantemente lo que sabemos y aplicar adecuadamente las herramientas. Los extremos son malos...