Cada vez sabemos más, y cada vez entendemos menos.
Albert Einstein

Simon Sinek - How great leaders inspire action

Esta charla tiene un título sugerente que picó mi curiosidad, cómo motivar que otra persona realice una acción sin utilizar la fuerza. Tras este sugerente título, la charla decepciona un poco pero aún así transmite dos ideas importantes.

  • Fecha : 2009
  • OradorSimon Sinek, escritor de Start With Why.
  • Título : How great leaders inspire action
  • Duración : 18 minutos
  • Descripción : Simon Sinek has a simple but powerful model for inspirational leadership all starting with a golden circle and the question "Why?" His examples include Apple, Martin Luther King, and the Wright brothers — and as a counterpoint Tivo, which (until a recent court victory that tripled its stock price) appeared to be struggling.

La primera parte se pregunta por qué los grandes comunicadores triunfan donde no son los únicos que lo intentan. Su respuesta es que la mayoría de gente piensa y se comunica utilizando el orden Qué > Cómo > Por qué (What > How > Why), mientras los grandes líderes utilizan el orden contrario Por qué > Cómo > Qué

Why > How > What

People don't buy you what you do; the buy why you do it. And if you talk about what you believe you will attract those who believe what you believe.

Como ejemplo pone la compañía Apple, el líder Marthin Luther King y los hermanos Wright.

La segunda parte se centra en explicar por qué tienes que atraer a la gente, y su respuesta es la Ley de la Difusión de la Innovación : para que la mayoría de personas adopten una innovación debe de haber sido adoptada y probada previamente por una minoría de gente innovadores.

Un ejemplo de fracaso interesante es TiVo, una tecnología muy innovadora aparecida a principios de la década con más que suficientes fondos pensada para ser adoptada por una gran mayoría de personas, pero en la que no hubo una adopción previa por parte de los innovadores y por tanto que ha fracasado.

 

James Randi - Fraude psíquico

Esta charla de James Randi para alertarnos en contra de los farsantes "psíquicos". No me interesó tanto por la temática, para mí está claro que son unos farsantes, sino por reflexionar cómo es posible que exista toda una profesión de gente que todos "sabemos" que son farsantes que viven de vender humo a gente que sabe que es humo.

Para mí, lo más interesante son los dos primeros minutos, pero os la recomiendo entera.

  • Fecha : Marzo 2007
  • OradorJames Randi, escéptico que ha dedicado su vida a combatir a los farsantes "psíquicos".
  • Título : James Randi's fiery takedown of psychic fraud
  • Duración : 17 minutos
  • Descripción : Legendary skeptic James Randi takes a fatal dose of homeopathic sleeping pills onstage, kicking off a searing 18-minute indictment of irrational beliefs. He throws out a challenge to the world's psychics: Prove what you do is real, and I'll give you a million dollars.

To show you too can make assumptions

07 - Revisión de Siniestros 1.0 - Comunicación (1/2)

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 impidiería 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 reponsable 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 departamente 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 nostros 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 mi 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 exiguirnos 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. 

Charlas que merecen la pena

Soy una persona muy respetuosa con la gente que ya ha estado donde yo estoy, y sobre todo con la gente que ya ha estado donde yo voy, e incluso con gente que ya ha estado donde nunca estaré. Por eso me resulta interesante hablar con esta gente y por supuesto escuchar.

Y por eso me resulta especialmente interesante TED (Technology Entertainment Design), Ideas Worth Spreading, un lugar donde puedes acceder de forma gratuita a charlas de diversos expertos respaldada por una organización sin ánimo de lucro.

Es por eso por lo que abriré una nueva sección semanal en el blog, que a ver si recupera poco a poco su ritmo de un post diario, sobre charlas que merezca la pena ver y repetir. En este primer post de la sección, me gustaría recuperar la charla ya publicada en el blog que debería de verse una vez al año al menos.

  • Fecha : 2005
  • Orador :  Steve Jobs, CEO y fundador de Apple y Pixar
  • Título : Stay hungry, stay foolish
  • Duración : 15 minutos
  • Descripción : Charla de Steve Jobs en la ceremonia de graduación de la Universidad de Standford. Steve cuenta tres historias : Uniendo los puntos, Love and Loss, Muerte.

06 - Revisión de Siniestros 1.0 - RRHH (1/2)

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 como podéis 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 llendo 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ó ú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.

Comenta