Liderazgo (II)

En el post anterior hablamos un poco de cuales son las características deseables en un Líder, parte de una discusión que se dio en la lista de metodologías ágiles y Scrum , llamada "foro-agiles" (un grupo de yahoogroups). Vamos ahora a ver como encara este tema de como debe ser un líder de un equipo, Gerald Weinberg, autor de entre otros excelentes libros de "The Psychology of Computer Programming.", "Secrets of Consulting: A Guide to Giving and Getting Advice Successfully", etc.

El libro de Weinberg, "Becoming a Technical Leader" es un libro muy interesante adonde el autor aborda el tema del liderazgo desde una óptica poco común. En uno de los capítulos habla de la relación entre el líder y las personas que están a su cargo, para plantearse en síntesis como tiene que ser esta relación, definiendo la conclusión en forma de ciertas "leyes" sobre el liderazgo.

Comienza contando sobre un test que se realizaba en un curso sobre Liderazgo y Management Tradicional. En él se solía plantear una determinada pregunta proponiendo lo que es básicamente:

El dilema por excelencia del liderazgo

Usted esta a cargo de un equipo, y tienen una tarea a terminar. Si el éxito de la tarea se encuentra amenazado, usted probablemente:

a. Pondrá la finalización de la tarea por encima del bienestar de su gente.

b. Pondrá al bienestar de la gente por encima de la finalización de la tarea.

c. Balanceará la importancia entre su gente y la tarea.

d. Escapa de la situación.

e. Ninguna de las anteriores.

Una tarea debe ser completada con un cierto resultado dentro de un tiempo determinado o sino alguna consecuencia negativa sucederá, consecuencia que en principio solo conoce el Líder. Que actitud tomar?, Si uno requiere que todas las personas del equipo trabajen tiempo extra o hagan lo que sea necesario hasta terminarlo están poniendo a la tarea por encima de las personas. Si uno por otro lado comparte con su equipo las consecuencia del no cumplimiento, así como también el motivo por el cual tiene que ser realizada la tarea permitiendo al equipo decidir ellos mismos cuanto trabajar, como, e incluso si van a terminar la tarea entonces están poniendo a la gente por encima de la tarea.

La pregunta, que todos deberíamos hacernos es, Está bien planteado el test? Existe realmente una dicotomía entre tareas y personas? Porque en realidad la tarea que debe hacerse es realizada para conseguir un objetivo para otras personas, es decir que, en realidad el dilema es elegir entre un grupo de personas, diríamos los Interesados (stakeholders) en que se complete la tarea y las personas del equipo que debe realizarla, llamemoslos, Los trabajadores.

El capitulo en cuestión es sumamente interesante, y aquí van algunas de las lecciones más importantes que se destilan de él, que nos ayudan, de alguna manera, a razonar sobre el dilema.

Algunas Leyes sobre Liderazgo

Ley Numero 4: El líder que no le importa la gente no tiene a nadie a quien liderar, a menos que sus seguidores no tengan alternativa.

Ley Número 7: Hay muy pocas tareas que sean realmente tan importantes como para que justifiquen sacrificar las futuras posibilidades de las personas que están realizando el trabajo.

Ley numero 9: Para ser un líder efectivo debemos tener en cuenta y bien presente en todo momento los motivos y sentimientos de todas las personas afectadas por la tarea: los interesados y los trabajadores.

La Solución (como nosotros la vemos)

En mi opinión entonces, un líder efectivo puesto ante el dilema antes mencionado, encontraría la solución eligiendo e. Ninguna de las anteriores:

Primero debe pedir, obtener y entender los motivos, objetivos y sentimientos detrás de los Interesados en la tarea. Luego compartir con el grupo los motivos y consecuencias de la mismas, para que de manera seria y profesional todos tomen la responsabilidad de llevarla a cabo. Y teniendo en cuenta que nunca vale la pena sacrificar algunas personas por otras, conseguir llevar adelante la tarea dentro de tiempos y parámetros razonables para ambos grupos (la única excepción, claro, es que haya riesgo de vida, en este caso obviamente se puede sacrificar el bienestar de un grupo de manera temporal si la tarea salvará vidas).

Deje para terminar este post mi ley favorita:

Ley numero 10: Si tu eres un Líder , La Gente ES tu trabajo. No hay ninguna otra cosa que merezca tu atención.

Liderazgo (I)

Hace tiempo, más tiempo del que me gustaría, en uno de mis primeros trabajos, se me acercó mi jefe de ese momento y sin más preambulo que una aclaración de garganta, en un tono seco y muy cortante me informó:

"La empresa necesita destruir unos papeles. Te vas mañana por la mañana a una planta de desechos en Loma-del-Ortis."
Y se dio la vuelta para Irse. Mi respuesta fue casi automática, visceral e inmediata:
"No", le dije.
La espalda se detuvo, y juro que percibí como se contracturaba todo antes de volverse con cara de pocos, poquísimos amigos:
"Como? que no vas a ir?"
"No, porque no me pagan para eso, soy programador."

La discusión que siguió fue bastante fea, con acusaciones de "Sos un principista", "no estas alineado con la empresa", etc.

La discusión fue doblemente fea porque podría haberse evitado totalmente. Que les parece que hubieran contestado si lo planteaba de la siguiente manera:

"La empresa tiene que mandar a destruir unos papeles. El que quiera ir tiene que levantarse un poco mas temprano, lo pasan a buscar en remise, el desayuno lo paga la empresa y a las 15 horas esta libre y se puede tomar el resto del dia libre. Quien quiere ir?" Porque realmente esas eran las condiciones.

Hace poco Martin Alaimo preguntó en la lista de foros-agiles que rol de Scrum era mejor para "reciclar" a un PM de la escuela PMI-stica, si era mejor que se transformara en un Product Owner (PO) o en un Scrum Master (SM).

Mas allá de la parte metodológica de la discusión que siguió: que en general se los asocia mas como Scrum Master, que los Analistas Funcional hacen mejor de PO, incluso mejor que los propios clientes , que depende del PM, que mejor continua fuera de Scrum llenando planillas o projects, etc., mas allá de todo esto, decia, de manera subyacente se estaba discutiendo el tema del Liderazgo y de que características deben tener un buen líder para ser efectivo (tanto si se hablaba del rol como PO, SM u otro).

Pueden ver la discusion original aqui, pero para resumir hubo excelentes aportes de Ingrid Astiz, Jose Manuel Beas, Pablo Rodriguez Facal y varios otros que fueron desgranando características (a veces por la negativa) entre las que rescato:

• Un líder debe poner de costado su "propio ego"
• Debe tener humildad y poner lo menos posible de su propio ruido
• Aportar herramientas practicas y dejar que el equipo descubra su potencial.
• Renunciar a la ilusión de importancia personal
• No ser burócrata
• Sentirse incomodo con forma de Gestionar de "Comando y Control"
• Ayudar al equipo a triunfar
• Escuchar a la gente
• No adjudicarse el merito de los demás
• No crear conflictos
• No manipular
• No caer en la inercia y tratar siempre de mejorar
• No caer en la ilusión del control
• No culpar al equipo por los fracasos
• No tiene que estar encima de todos
• debe confiar en las personas del equipo

¿Que les parece eh?! Pavada de listita!! Interesante para chequear a nuestro alrededor, verdad?

Flexibilidad ante el cambio

Inmaginense la siguiente situación: Comienzo de un proyecto, el Gran-Gerente de proyecto, Gran-Jefe-Saco-Agua-De-Las-Piedras reune a todo el equipo y anuncia "El equipo de funcionales va a comenzar con la (Gran)Etapa de relevamiento, durará unos 10 meses. Queremos lograr entender completamente lo que quiere el usuario asi no vamos a tener ningún cambio y vamos a saber todo para cuando entremos en la etapa de desarrollo, que durará unos 3 meses.". Esta es una situacion real, números de meses incluidos. Me sucedió a mi.

Una y otra vez todos hemos estado en proyectos adonde pasa mas o menos lo mismo: Una Gran Etapa De Relevamiento al principio del mismo para "evitar" tener que realizar Cambios y para aprender TODO lo que hay que aprender. Una y otra vez hemos llegado a la mitad o al final del proyecto, con varios meses de retraso respecto de la fecha original, cuando, al mostrarsele el sistema a los usuarios comienzan a aparecer estos "cambios-que-se-suponian-que-no-tenian-que-existir".

Porqué pasa esto? Son los usuarios una fraternidad de sádicos a los que les gusta torturarnos? Son los funcionales, los desarrolladores personas altamente perturbadas y disfuncionales (eh... mejor no contestemos esto) que no pueden entender lo que el usuario les pide? Existe el destino y se empeña en ponernos piedras en el camino?

O será que el cambio es una parte normal de todo proyecto?

Hasta el surgimiento de las metodologías ágiles el cambio se trataba (se sigue tratando) como una anomalía, como un error del usuario o como un síntoma de que alguien se equivocó y no relevó lo suficiente. Cuando hablamos de cambio lo hacemos en todo sentido pero particularmente de los requerimientos y necesidades del usuario.

Por este motivo es que Waterfall indica que debe realizarse una Gran Etapa de Relevamiento al Principio (en inglés, BRUF, Big Requirements Up Front), seguido de escritura de casos de uso (indicado por el DR. RUP) y terminando con requerimientos firmados por usuarios temerosos (de meterse en camisas de once varas y de estar firmando los "10 mandamientos del sistema" tallados en Mármol!).

PMI lo trata con un proceso de "gestión de cambio" o "Control de Cambio" adonde en base a un pedido de cambio del relevamiento inicial se realiza un "cambio de alcance", lo cual implica reestimar costos, chequear asignación de recursos, reestimar tiempos, replanificar y obtener la autorización del sponsor / Gerentes del proyecto para proceder con el cambio. Cualquier parecido con la tortuga de Mafalda es pura coincidencia (La tortuga se llamaba Burocracia).

Justamente uno de los principios comúnes a todas las metodologías ágiles es: El cambio es parte de la realidad!

No es un hecho excepcional, no es causado por usuarios viles y sádicos que quieren hacer un infierno de nuestras vida. No es causado por analistas funcionales perezosos (bah, vagos) o que no saben como escribir un caso de uso (que los hay, los hay) ni por malos programadores que malinterpretan lo que esta escrito en la lista de requerimientos (de estos también hay). Sencillamente es que no importa cuanto tiempo le dediquemos al relevamiento, no importa cuantas Maquetas, prototipos o casos de uso hagamos para mostrarle al usuario, no importa cuanto esfuerzo le dediquemos a reuniones de validación, siempre siempre siempre va a haber cambios a partir del relevamiento inicial (por favor, vuelvan atras y lean de nuevo esta frase).

Porqué? bueno, los principales motivos son :

1. El usuario ve el sistema funcionando y ahí se da cuenta lo que realmente quería .
2. El usuario descubrió a lo largo de todo el tiempo de trabajo en conjunto con analistas y desarrolladores lo que necesita.
3. Funcionales y Programadores aprendieron del dominio del problema y son capaces finalmente de entender lo que el negocio necesita ahora que el usuario finalmente aprendió.
4. El negocio simple y sencillamente cambió.
5. La legislación cambió.
6. El/Los usuarios cambiaron (y usuarios distintos quieren soluciones distintas).

Es decir, simple y sencillamente porque es NORMAL que la realidad cambie (un cambio en alguna regulación, etc, el mercado cambia, aparece un nuevo producto, etc). Y es NORMAL que el conocimiento cambie a medida que uno va teniendo más información y aprendiendo. Esta información solo se puede obtener a través de la experiencia. Esto es así porque al ser un sistema un modelo abstracto de la realidad el usuario sólo se da cuenta de las consecuencias de lo que pidió cuando lo ve funcionando, cuando lo "toca".

Que mente perversa nos metió en la cabeza la idea de que podemos preveer de entrada la forma en que se va a comportar la realidad!? Que cambios se van a producir en el mercado? que leyes saldrán? que va a querer el nuevo usuario o de que se va a dar cuenta el usuario que tenemos cuando le mostremos el comportamiento de las reglas de negocio que relevamos en casos concretos? seria como predecir el clima, pero de aca a un año!.

Una simple muestra para ver el lugar que ocupa el cambio en las metodologías ágiles, en el primer libro de XP, llamado "XP Explained", de Kent Beck, tenia como subtitulo "Embrace Change", abracemos el cambio!

Escuchemos de nuevo finalmente a Kent Beck, en un fragmento de su libro "Implementations Patterns" :

"Nuestra industria parece adicta a la idea de que solo si diseñamos el software bien de entrada no tendremos que cambiar luego el sistema.

Recientemente lei una lista de razones por las que el software cambia. En la lista estaban los programadores que no hacen bien su trabajo al entender los requerimientos, sponsors y usuarios que cambian de parecer y otros motivos mas. El unico factor que faltaba en la lista era justamente el cambio legítimo. La lista asumía que el cambio es siempre un error.

¿Porque no sirve un pronostico del tiempo para todos los dias? Porque el tiempo cambia de manera impredecible. ¿Porque no podemos listar de una sola vez todas las formas en las que necesitaremos que el sistema sea flexible? Porque los requerimientos y la tecnología cambian de manera impredecible.

Esto no nos releva de nuestra responsabilidad de hacer lo mejor que podamos para desarrollar el sistema que el usuario necesita ahora pero sugiere que hay límites al valor de hacer sistemas a prueba-de-cambios-futuros, a través de la especulación.

Poniendo todos estos factores juntos, la necesidad para que el sistema sea flexible ante el cambio, el costo de esa flexibilidad, la impredecibilidad de adonde será necesaria, me lleva a creer que el momento para introducir esa flexibilidad es sólo cuando la misma es absolutamente necesaria".