Lycka Bonita

Siempre es más fácil fijarse en los errores que de los aciertos, especialmente si son ajenos, pero también son más fácil de corregir o evitar en el futuro.

En este ejercicio puramente recordatorio para mi yo del futuro, me incluyo dentro de la organización que los ha cometido (la asociación cliente + mi empresa proveedora) ya que en casi dos años no he sido capaz de cambiar lo suficiente para corregirlos, algunos de ellos son errores de libro pero se siguen cometiendo.

Algo me dejaré entre tanto que contar…

Estructura piramidal inversa. De esta mala práctica poco tengo que decir que no se sepa ya. Los “jefes” son elementos no productivos de la cadena de producción, por tanto si la productividad de un equipo de 10 personas es 10 productos al día, nos dice que cada persona aporta 1 producto al día; si al equipo se le añade un “jefe” y mantiene la productividad de 10 productos por día, la productividad por persona desciende : los responsables deben aportar más valor del que restan.

Un caso particular más dañino aún es tener casi toda la estructura productiva como “jefes” de un proyecto (sin más recursos que ellos mismos, o poco más), o de un equipo que sólo tiene un proyecto, peor aún si la misma persona es jefe de varios simultáneamente, y peor aún si se nombran jefes por antigüedad o compensaciones en lugar de por méritos.

En este país además de titulitis tenemos jefitis.

Jefes en lugar de responsables. Creo que el término “jefe” debería eliminarse de nuestro lenguaje para utilizar la palabra “responsable”, porque en realidad un jefe no está para que se le obedezca, no debería tener poder, sino debería estar para optimizar la productividad de sus compañeros.

Un equipo, una única entrada de trabajo. Para que el trabajo de un equipo pueda ser eficiente, sostenible y predecible, es vital que exista un único punto de entrada de trabajo. En este punto de entrada es en el que se debe priorizar, planificar y asignar el trabajo. Saltándonos la entrada del trabajo empeoramos la comunicación (cada persona no sabe qué está haciendo el resto ni cuándo van a terminar entregables que pueden afectarles), las prioridades desaparecen (primero en llegar, primero en servirse), no sabemos cuánto se puede producir cada semana ni cuándo podremos entregar.

Si quieres que algo se haga, asígnalo a alguien. Es prácticamente lo único que recuerdo de las clases de organización, y es una verdad como un templo. Especialmente indicado para tareas que involucran varias organizaciones (ya sean empresas, departamentos o equipos del mismo departamento)

Zapatero a tus zapatos. Para cada tarea deben existir al menos tres roles : el ejecutor de la tarea, el owner (debe decidir qué hacer y si se ha realizado bien) y el responsable de que la tarea se llegue a ejecutar bien. Las personas que se asignen a un proyecto deben tener claro qué tareas deben llevar a cabo y con qué rol, y lo más óptimo es asignar las tareas al mayor experto con mejores habilidades y herramientas.

Reuniones útiles y eficientes. De esto podría hablar muuuuuucho, pero ya lo tenía escrito hace años .

Baja motivación. La motivación es el factor más correlacionado con la productividad, cuidarlo es crucial. Es importante recordar que no todos respondemos igual a los mismos estímulos, y desgraciadamente que la experiencia demuestra que la gente funciona mejor con palos que con mieles. El momento en el que todo el equipo ha perdido la motivación es el último paso antes del KO.

Gestión de la expectativa. En este caso el cliente realmente necesita que construyas una furgoneta, pero te pide un coche porque no sabe explicarlo bien o no sabe exactamente qué necesita, y te da presupuesto e instrucciones para construir una scooter poniendo un motor en el sillín de una bicicleta, porque sabe más de física y mecánica que tú. Una vez le entregas un vehículo motorizado con dos ruedas se piensa que es inmediato que le pongas dos ruedas más y que los estudios de aerodinámica, reparto de pesos, frenos, aceleración… son todo chorradas : un coche no es más que dos de estos engendros unidos. Una vez le atas con una cuerda otra bici con otro motor a tu engendro, se dan cuenta que realmente necesitaban la furgoneta y te piden que soporte una mudanza. Es extremadamente importante y básico, y no hay que confundirlo con problemas de comunicación : son frutas, pero ésta es otra fruta diferente.

Entrepreneurs always need to be reminded that it’s not the job of their customers to know what they don’t know.

Mark Cuban

Ligado a esto es muy común la filosofía cortoplacista de pan para hoy y hambre para mañana, las huidas hacia adelante pueden ser ocasionalmente la solución, en ocasiones son movimientos geniales estudiados en las escuelas, pero si es tu única solución siempre tarde o temprano el mañana llegará, y es entonces cuando tu empresa estará haciendo la mudanza con dos bicis unidas con una cuerda con un motor en el sillín.

Intentando unir los anteriores puntos mostraré un ejemplo de cientos que podría contar. Cuando arrancamos el proyecto éramos 3 personas en el equipo en el que yo era el Jefe de Proyecto no sólo nominalmente sino que ejerciendo de ello. Sin embargo en las reuniones maratonianas sin compromisos había un Jefe de Proyecto de la plantilla del cliente (que nunca hizo nada), el director de IT, la usuaria, el director de Operaciones y el responsable comercial de mi empresa, imponiéndonos planificaciones y prioridades.

· Mucho “jefe” (6) para tan poco recurso productivo (2)

· ¿Quién era el “responsable” de que el proyecto tirase para adelante? Yo, independientemente del estatus del resto de personas.

· La entrada de trabajo debería ser el Jefe de Proyecto de la plantilla del cliente ya que no sólo el departamento de operaciones nos asignaba trabajo, y sin embargo era yo. Llegamos a extremos tan ridículos como convocarme a una reunión para hablar de una VPN del cliente.

· El director de IT debería dedicarse a conseguir los recursos necesarios y facilitarnos nuestro trabajo.

A la vuelta de mis 3 semanas de vacaciones sabía que habría problemas, pero la realidad fue mucho peor y me encontré un gran desastre, todo se había descontrolado hasta el punto de quitar la versión que había en producción y que llevaba una semana funcionando antes de mi marcha por las repentinas quejas por parte de los usuarios, se manipuló erróneamente la base de datos de producción perdiendo todos los datos de una columna de una tabla, todas las incidencias se reportaron vía correo (más de 250 mails me esperaban), mi cuenta de correo sufrió problemas (pérdida de unos mails, duplicación o triplicación de otros)…

Desalentador. Para la versión 2.0 de la aplicación me prometieron cambios, que no han llegado. Meses diciendo que esto iba a ocurrir y ahora soy yo quien recoge la basura y paga los platos rotos. El resultado no podía ser otro que la peor reentrada al trabajo de mi vida.

A pesar de todo esto no todo era negativo, me encontré 3 sorpresas positivas :

• Por fin tenemos el equipo aceptablemente dimensionado.
• Hay nuevo PM del equipo de Unit Link, sucesor de un técnico mejor que yo, un PM con más de 10 años de experiencia en una de las grandes, otra persona con 20 años de experiencia en seguros y otro PM con un CV 10 veces mejor que el mío (ITIL, CMMI, PMP…). El 5º elemento se llama José Manuel Beas y es una de las referencias del agilismo en España.
• El cliente cuenta con nueva Manager en el departamento de IT que ha parado el movimiento de su departamento en la mala dirección. Discrepo en detalles (hoy por hoy prefiero no utilizar el MS Project y en que prefiere plantear la Arquitectura como un proyecto propio a precio cerrado con tareas, fechas, recursos…), pero se puede hablar, trabajar y razonar.

El impacto positivo ha sido brutal.

Después de una semana de duro trabajo para retomar el control, por primera vez que tengo el proyecto bajo control de verdad, por primera vez que participo en un proyecto bajo control, que tenemos un plan sin márgenes y confianza en él, que tengo a todos los stakeholders relativamente controlados, que hemos cumplido plazos de dos entregas con calidad, que hemos cambiado por fin los procesos con el cliente y que soy optimista de cara al futuro inmediato a pesar de que la versión 2.0 implica cambiar por completo el core de una aplicación que no tiene la calidad suficiente ni test implementados.

Después de este primer plan (que pronostica una entrega retrasada más de 7 meses para primeros de diciembre) el futuro próximo pinta bien, con un nuevo proyecto (esta vez una migración de una cartera en producción a nuestro sistema).

Por primera vez en la vida de este proyecto no sólo estoy orgulloso de mi trabajo sino también de mis resultados. Tengo el proyecto en mis manos.

Durante más de año y medio nunca había conseguido lo que quería para trabajar : únicamente conseguía lo que necesitaba para sobrevivir. Y a pesar de todo el esfuerzo que he realizado y la mierda que he tragado, a pesar de que ahora tengo todo lo que quería, el viernes entregué una carta de preaviso de mi baja de mi empresa, y por tanto de mi proyecto y de mi cliente.

La Gestión de Riesgos consiste en identificar los riesgos del proyecto (es decir los eventos inciertos), analizarlos, monitorizarlos, evitarlos cuando sea posible y responder a ellos cuando no lo sea, tratando de maximizar tanto las probabilidades como el impacto de los eventos positivos, y minimizarlas en el caso de los eventos negativos.

Lo primero que se debe realizar es un listado de activos sobre los cuales se pueden materializar riesgos con una determinada probabilidad de ocurrencia mediante vulnerabilidades de dicho activo, causando un impacto (positivo o negativo) en el proyecto.

Esta información se debe analizar y plasmar en una matriz de riesgos:

• Descripción del Riesgo
• Activo afectado
• Vulnerabilidad
• Impacto (consecuencias previsibles)
• Posibilidad de ocurrencia. Dado la dificultad de cuantificar estas probabilidades, se suele utilizar estimaciones cualitativas.
• Plan de Mitigación
• Plan de Contingencia
• Coste en caso de materialización
• Coste de Mitigación
• Coste de Contingencia

Una planificación sólo es válida si va acompañada de una correcta gestión del riesgo. Depende del proyecto puede ser algo tan simple como una estimación de x jornadas +- el 15% según nuestro instinto o experiencia previa en proyectos similares, o en proyectos de mayor envergadura y criticidad una tarea de varios días en la planificación con revisiones semanales. 

En este proyecto

Pero en casa del herrero, cuchillo de palo. En una empresa que vive del riesgo, una empresa de seguros, no he visto que hayan dedicado ni un sólo minuto a esta faceta, no sólo en nuestros proyectos, no sólo en el departamento de IT.

En el comienzo de los tiempos realicé una estimación por puntos-función ponderando sus pesos según la complejidad y la criticidad de las tareas. Por otro lado identifiqué un listado típico de riesgos y di un margen mínimo y máximo de variación basándome en mis experiencias previas. Resultó un trabajo inútil ya que finalmente se dividió por 2 (ya he contado esta historia)

Al ver que se prestaba poca atención a los riesgos, decidí incluir el caso pesimista en las estimaciones originales, pero ni aún así ya que seguían dividiendo por 2 mis estimaciones. Después probé a estimar y a añadir una bolsa de horas en previsión de desviaciones, con idéntico resultado : trabajo inútil.

Finalmente empecé a decir que esto estará "tan pronto como podamos", ya que nunca se ha respetado una planificación o un sprint, siempre se ha añadido trabajo "urgentísimo" y "supercrítico".

Ejemplo

Un ejemplo de riesgo continuamente ignorado, el perder un % significativo de productividad por la pérdida o ausencia de personas :

Me he cansado de pedir que se forme un único equipo/departamento de Java, y según las necesidades vamos asignando recursos de un proyecto a otro. Así todas las personas tienen conocimientos globales de cada proyecto, se fomenta más el trabajo en equipo, se pueden alternar mejor roles y cubrir ausencias… Sin embargo se ha preferido formar varios equipos pequeños, algunos de una persona o de dos. Es tan difícil ver que si en uno de estos equipos la persona no asiste a trabajar (enfermedad, vacaciones, cambio de proyecto o empresa), se reduce la producción en un 50% o en un 100%? Sabiendo que la gente tiene la costumbre de trabajar menos de 11 meses cada 12…

La Gestión de la Comunicación es siempre complicada porque no depende enteramente de una única persona, sino de dos o más partes. En tu mano está mejorar una comunicación, facilitarla, dejarla registrada por escrito… Pero no puedes obligar a una persona a que te entienda mejor ni a que se explique mejor

Permitidme un ejemplo para ilustrar lo que ha sido la comunicación en este proyecto.

Antes de marcharme de vacaciones realicé una estimación (informada, con todos los requisitos en la mano ya que era realizar prácticamente otro desarrollo igual que ya habíamos hecho) de un nuevo desarrollo con un socio, y di tres cifras en función de las entregas de este socio: 65, 70 ó 90 jornadas. Estas cifras eran conocidas por mi equipo, el comercial, y por el departamento de IT.

A la vuelta me encuentro con que se ha vendido (y comprado) en 30 jornadas cerradas… Como era prácticamente igual (según operaciones e IT) que un desarrollo previo, empezaron a quitar tareas y a dividir por dos el tiempo, achantando a mi backup. Fue francamente desagradable tener que abroncar tanto al cliente como al comercial.

En este proyecto y a pesar de mis muchos esfuerzos, la comunicación ha sido caótica e informal porque al resto de partes implicadas le interesaba. En nuestro equipo al menos he mantenido las entradas lo más centralizada que he podido en mí, para cumplir que únicamente haya una entrada de trabajo y descargar al resto del equipo de este caos y lo que antes era blanco ahora es negro…

Por supuesto, no existe nada parecido a un Plan de Comunicaciones.

Comunicación caótica

Comunicación caótica porque el elevado número de interlocutores, que no ha hecho más que aumentar con el tiempo. Podríamos pensar en que la comunicación en un principio sería simple, únicamente entre dos partes (el cliente y nosotros como proveedores), y que luego simplemente se añadió otra parte (Mutua Madrileña como socio) con la que no deberíamos de tener contacto directo, y más adelante otros productos y socios…

La realidad ha sido diferente. Primero el cliente era el departamento de IT, y el usuario el departamento de operaciones, cada uno con intereses contrapuestos : el cliente quiere pagar lo menos posible y el usuario quiere las máximas funcionalidades y servicios. Esta dualidad ha sido un auténtico lastre en las negociaciones y en toda conversación, siendo la causa de que siempre ha habido más trabajo del que se puede completar, y por tanto uno de los orígenes de los problemas de indefinición del alcance, planificaciones imposibles de cumplir y calidad deficiente.

La comunicación con el departamento de IT comenzó siendo a través de un único interlocutor, pero ante su temprana saturación de trabajo que le convertían en un cuello de botella que nos impidiera cumplir con las fechas previstas, y el hecho de que nosotros como proveedores estábamos físicamente en la misma sala que el departamento de IT, comenzamos a atacar directamente a cada responsable de nuestras necesidades (SQL Server, Sistemas, Host…) descargando a la persona responsable de estas gestiones. Es decir comenzamos a realizar trabajo que no era nuestro, además de aumentar el número de personas involucradas directamente en el proyecto, complicando la comunicación y llegando a asumir la gestión incluso del trabajo del personal del cliente.

Pronto las excepciones se convirtieron en norma, y yo de Jefe del Proyecto dentro de nuestra empresa en Jefe de Proyecto a secas. Fue surrealista recibir una bronca por no obligar a una persona del cliente a priorizar una tarea nuestra.

Con la irrupción de socios la comunicación también se complicó, ya que la comunicación no se realizaba de una única persona a otra única persona, sino que nuestro departamento de IT conversaba con su departamento de IT, operaciones con su departamento de operaciones…

Finalmente, con la puesta en producción del aplicativo aumentamos la complejidad, ya que duplicamos las conversaciones : ahora tenemos desarrollos nuevos y tenemos mantenimiento de producción. Y también operaciones, que mantenía un único punto de entrada, pasa a tener varios ya que los gestores de cada producto nos atacaban a nosotros directamente.

Suficiente caos? Alguna cosilla más había por ahí, ya que nos llamaban a nosotros en lugar de a IT en cada problema de comunicación, nuevos productos…

Comunicación informal en un sentido, formal en otro.

La informalidad ha sido otra gran carga de profundidad, y lo que más me ha molestado a mí en lo personal por el doble juego : el cliente tiene carta blanca para decir y desdecirse, y a nosotros se nos busca una cifra optimista con sólo el 10% de los requisitos definidos para luego exigirnos compromiso sobre ella sin un mínimo análisis de riesgos y aumentando el alcance constantemente.

Dentro del equipo esta falta de comunicación única provocaba que las soluciones no se reutilizasen, diseños diferentes, estilos heterogéneos…

Almacenaje

Los documentos de requisitos eran diferentes en el cliente y en nuestro equipo, almacenados en diferentes sistemas, con diferentes versiones y desactualizados con el tiempo. Costó meses poner fin a esto y unificar la documentación. Imposible hacer análisis ni diseños en un ambiente tan cambiante. Respecto a los casos de pruebas, peticiones que caen en el olvido al llegar a los usuarios.

Reuniones de seguimiento

Esto ha sido lo más parecido a un Plan de Comunicaciones, reuniones semanales (semanas sí, semanas no) para evaluar el estado del proyecto. A nivel personal, han sido lo más desagradable del proyecto.

Cada reunión se planificaba el trabajo para el desarrollo de la siguiente semana, y constantemente esta programación se incumplía (como todas las planificaciones de todos los proyectos que gestiona este cliente). Las causas, más que identificadas:

• Por supuesto ha habido retrasos achacables a mí y a mi equipo, sin lugar a dudas. Pero echando la vista atrás, suponen una inmensa minoría.
• En otras ocasiones se retrasaba el desarrollo por la entrada prioritaria de trabajo sin planificar, principalmente mantenimiento de producción, que al ser tan inestable la aplicación es impredecible estimar la entrada de la semana siguiente.
• Pero la gran mayoría de los retrasos se debían a retrasos en las entregas del propio cliente. Pero claro, yo no puedo escudarme en un retraso de IT para justificar que una tarea no está completada, porque se enfadan si les saco los colores delante de operaciones (las mayores broncas que he recibido han sido por esto); y viceversa. Baste decir que llevamos 8 meses, OCHO, esperando a que nos definan una tabla, UNA. Y a día de hoy seguimos esperando.
• Y por supuesto, una planificación en la que no se hace ningún análisis de riesgos no puede llamarse planificación. Ya sabéis que todos los días son buenos, nadie enferma, nadie se va de vacaciones, nadie deja la empresa, nadie se retrasa, no nos topamos con problemas al desarrollar sobre una aplicación inestable…

De paso comentar que estoy plenamente convencido en que utilizar los Test como métrica de progreso de un proyecto es lo más realista, además de las ventajas que aporta ya de por sí una adecuada gestión de la Calidad. En este proyecto, sin Test unitarios ni de integración durante gran parte de su vida, ha sido imposible llevar TDD a la práctica.

Las actas de reunión una utopía inútil ya que sólo servían para recordarnos nuestros compromisos que se nos exigía cumplir a rajatabla y los compromisos del cliente casi inexistentes y rompibles (antes de llegar aquí me parecía un buen chiste, ahora es que me parto el pecho).

Éxitos

• Arroz para todos. Al arrancar el proyecto, el resto de partes implicadas disfrutaban las ventajas de una comunicación caótica e informal mientras mi equipo era el único que sufría las consecuencias. 

Oportunidades de mejora

• Formalizar la comunicación en momentos clave, aún retrasando o parando el proyecto. 

Imprescindible para el futuro

• Retrospective, o cierres de proyecto. Sacar las lecciones aprendidas individualmente es bueno, pero en grupo es mejor. 

Un aspecto clave del éxito de un proyecto son las personas que participan en él, especialmente cuando los procesos son inexistentes y las herramientas escasean. En este escenario, la Gestión de los Recursos Humanos es crítica para convertir una idea en realidad.

La principal dificultad en la Gestión de los Recursos Humanos en este proyecto ha sido la falta de un plan realista y fiable, por lo cual es imposible anticiparse, difícil dimensionar correctamente un equipo y complicado asignar roles fijos a cada persona, generando inestabilidad y obligándonos a contar con los recursos disponibles en lugar de los recursos necesarios.

A la hora de seleccionar personas he intentado ser lo más sincero y transparente posible, reflejando la difícil situación fielmente, y advirtiendo de la inestabilidad a la que se nos obliga a vivir. Si te piden a una persona para mañana para que esté un mes con nosotros, pues no puedes elegir : coges lo que haya que esté dispuesto a este tipo de trabajo. El resultado, un grupo heterogéneo de supervivientes curtido en mil batallas convertido en un buen grupo, mientras el grano se ha ido yendo con el viento.

La formación del equipo ha sido insuficiente, tanto a nivel técnico como a nivel de negocio, debido a que en este cliente nunca ha habido tiempo reservado a este fin. En la medida de mis posibilidades, para mis proyectos he dedicado tiempo a tener un mínimo de documentación útil, y he apartado tiempo de cada persona para que pudiese formarse en las áreas necesitadas, ya sea un framework nuevo, ya sea en el negocio.

Conflictos ha habido, sin llegar la sangre al río, menos de los que se podrían esperar en este difícil ambiente debido a que la profesionalidad de la mayoría de los implicados. Han tenido un impacto globalmente positivo, ya que ha llevado a un grupo más unido y maduro. El hecho de tener un equipo notablemente infradimensionado hace difícil gestionar los conflictos, ya que castigar o prescindir de alguien puede tener un tan impacto negativo a corto plazo (al poder perder un 25% de la productividad del próximo mes pej) como no castigar o prescindir (el resto del equipo se molesta por la ausencia de consecuencias). Solución, bastante mano izquierda a la hora de resolver los problemas.

No se ha impuesto un estilo de liderazgo inamovible, se ha ido adaptando según las necesidades del cliente y del propio equipo, pero manteniendo una orientación a la persona. Se comenzó intentando utilizar metodologías tradicionales, documentar, planificar… y se tuvo que ir abandonando. Nos hemos visto obligados a aparcar soluciones win-win debido a que el cliente no se ha dejado ayudar. Se ha intentado dar a todos el protagonismo y responsabilidad que pedían (y que podían cumplir) para poder ser

• efectivos (hacer las cosas correctas)
• eficientes (hacer las cosas correctamente).

Ha sido difícil mantener la motivación de los mejores porque yo no controlaba todos los factores : no puedo hacer que el cliente haga bien su trabajo por ejemplo. El mayor problema ha venido por hacer un trabajo más participativo y no agobiar con controles : los responsables responden, los irresponsables no y surgen tensiones. Los objetivos trasladados al equipo eran lo más realistas posibles 

He puesto todos los medios para que la comunicación sea lo más transparente y horizontal posible, siempre ofreciendo una oreja para escuchar y poder mejorar, mordiéndome la lengua en alguna ocasión, siempre positivo, buscando soluciones y no culpables…

Ha habido mucho estrés, estrés puntual por entregas o fechas pero sobre todo estrés "institucional" por la forma de trabajar del cliente. Quizás el exceso de positivismo y buen ambiente es un lastre para que el cliente solucione este grave problema. He intentado aislar al grupo para que se quedase únicamente en mí.

La delegación de responsabilidad ha supuesto decepciones puntuales, al fin y al cabo es un hecho que no todo el mundo es responsable. Se comunicaba claramente las expectativas, la medida del rendimiento (performance) era por funcionalidad o tareas cumplidas, el control era insuficiente por la dificultad para resolver un conflicto mencionada antes, y el feedback era casi siempre positivo en los responsables y negativo en los no responsables.

Éxitos

• Adaptación, a las necesidades del cliente, al grupo, y a cada persona. Por supuesto no es una adaptación al 100%

Imprescindible para el futuro

• Mayor supervisión : debí dedicar mayor cantidad de tiempo a la supervisión del trabajo para verificar que realmente somos efectivos y eficientes. A las personas responsables les molesta, pero cuatro ojos ven más que dos y todos podemos mejorar. A las personas irresponsables mejor no tenerlas cerca, pero si se tienen hay que controlarlas más de cerca.
• La confianza se gana, no se da. Es una pena pero en un proyecto con una considerable cantidad de beneficios (libertad de horario, jornada intensiva, buen ambiente, alto grado de libertad y responsabilidad…) las respuestas no han sido todo lo agradecidas que se pueden esperar.