Menos es más. Personas, problemas y herramientas

WP_20151225_001

Disclaimer: Este post no pretende ser divertido, ni entretener. Se trata de mis reflexiones más o menos estructuradas acerca de productos, gestión de proyectos, implantaciones de software, escalar procesos, mejorar organizaciones y en definitiva, cómo trabajar mejor.

Simplicidad

Cuantos más objetivos hay en un proyecto, más complicado es cumplirlos.

Cuantas más personas haya implicadas, más difícil es coordinarlas y más opiniones deben ser tenidas en cuenta.

Cuantos más largos son los periodos entre desarrollo y producción, menos feedback recibimos, menos útil resulta y por tanto más difícil es cumplir los objetivos del proyecto.

Cuanto mayor sea el presupuesto de un proyecto, mayor número de personas tendrán que implicarse en él y más objetivos necesitará para justificar su arranque.

Cuanto mayor sea el presupuesto gastado más difícil (políticamente) se hace cancelar un proyecto fallido o innecesario.

Con estas premisas, suposiciones o experiencia, podemos deducir que en los proyectos de software, menos es más, y por lo tanto tener claro estos consejos, best practices o máximas, para mejorar nuestros resultados:

  1. Focalízate en un único objetivo.
  2. Entrega un MVP lo antes posible al menor número de personas posible.
  3. Itera en base al feedback y amplía el alcance.
  4. Evita lastre, reduce la inercia: personas, presupuestos, objetivos, tiempo.

Variabilidad

Si puedes hacer algo siempre de la misma manera o buscando el mismo resultado, puedes llegar a perfeccionar tus procesos hasta el punto de acortar tiempo y coste cada vez que hagas lo mismo o busques el mismo resultado.

No importa lo complejo del proceso: siempre y cuando no varíe puedes automatizarlo, convertirlo en un hábito, en un acto reflejo. Eso significa que reducir la variabilidad conducirá a mejorar el resultado de tus procesos y por extensión de los proyectos que los requieran. También se deduce que la variabilidad afecta negativamente a los procesos y por extensión a los proyectos que los requieran.

Un proceso automático es un proceso optimizable (es repetible, medible, comparable y se puede cambiar) y uno que no necesita a nadie para realizarse por lo que además puede escalar (no importa si tienes que ejecutarlo 1 vez o 1 millón de veces). Si está completamente automatizado ni siquiera necesitas que nadie lo entienda por lo que tampoco requiere formación o esta es mínima.

Para reducir la variabilidad necesitas reducir opciones, simplificar: menos objetivos, menos personas, menos tiempo, menor coste, todo debe ser lo mínimo posible.

Para lidiar con la variabilidad restante, necesitas entender la naturaleza de esta, sus causas, y así tratar con esta en su origen, ya sea eliminándola, resolviéndola o minimizando su impacto.

Productos

Uno de los motivos por los que el software como producto dé en general mejores resultados que el software a medida (buy vs build) es que la variabilidad es menor. Se “estandariza” todo lo posible y el resto se deja fuera o se trata mediante integración, plug-ins, desarrollos, etc. Esto permite focalizarse en menos objetivos e implicar a menos gente.

Un producto de software resuelve un problema o conjunto de problemas bien definido mediante un número finito de funcionalidades que no puedes modificar a capricho y que siempre actúan de la misma forma (automatismos, estandarización). Esa limitación hace que escale mejor (por estandarización) y esté más optimizado que un desarrollo a medida (por ejemplo: se le hace más y mejor testeo).

Lo anterior deja de ser cierto cuando retorcemos un producto para adaptarlo a un problema para el que no está diseñado. Y pasa mucho, particularmente en productos complejos. Tampoco sucede en “productos” para un solo cliente, que se mire como se mire, son proyectos a medida.

Comprensión

Cuando al tratar de resolver un problema, o no tenemos éxito, o el problema reaparece, o se provoca una sucesión de efectos secundarios al “solucionarlo“, debemos darnos cuenta de que:

  1. No entendemos el problema.
  2. Hay más de un problema.

A partir de aquí tenemos dos opciones:

  1. Nos paramos a analizar los problemas.
  2. Lanzamos “soluciones” (tiempo y dinero de alguien) al problema hasta que estos desaparezcan.

La segunda opción puede no funcionar, o funcionar solo temporalmente o provocar una sucesión de problemas en cascada, así que voy a dar por hecho que continuamos por el camino de pararnos a pensar para entender el problema y elementos adicionales que no hayamos visto antes. Aquí corremos el riesgo de “parálisis por análisis” por lo que deberíamos intentar focalizarnos en objetivos que puedan producir feedback rápido.

Una vez entendido e identificado el problema y sus causas (variabilidad), deberíamos automatizarlo. Digo esto, porque la única forma de demostrar que hemos resuelto un problema es automatizarlo. De otro modo puede que solo hayamos resuelto un único caso particular de un problema. Esto no tiene nada de malo per se, pero no podemos escalar esa solución (aprovecharla en otros casos). También hay que intentar no retorcer los problemas para que nuestra solución sea válida, ni tratar de resolver todos los problemas posibles. Es complicado saber dónde parar para no generar burocracia y sobre-ingeniería.

Por todo esto, deduzco que tratar de resolver un problema (no un caso concreto) sin entender su naturaleza resultará en un fiasco, ya sea reconocido o envuelto en marketing. En el primer caso habremos aprendido algo, en el segundo solo habremos desperdiciado el tiempo y el dinero de un montón de gente.

Conclusiones

Si no entendemos el problema a resolver, tendremos que enfrentarnos a una gran variabilidad y por lo tanto emplearemos una gran cantidad de tiempo y recursos en algo que va a acabar mal, por lo que es mejor que vayamos preparando el marketing.

Esto aplica tanto a tratar de resolver nosotros el problema, como a comprar una herramienta o proceso que resuelva el problema. Este último caso es muy habitual y transcurre del siguiente modo:

  • Fulano tiene un conjunto de problemas que desconoce: X, Y, Z.
  • Mengano tiene un producto que resuelve un problema concreto X.
  • Fulano compra el producto de Mengano pero su conjunto de problemas no se resuelve.
  • A partir de aquí, pueden pasar dos cosas:
    1. Que Fulano se dé cuenta de que tiene problemas que desconocía y trate de aprender más sobre estos para resolverlos.
    2. Que se recurra al látigo, el marketing y cursos de formación para ñapear con el producto de Mengano hasta que la gente se canse o se acabe el dinero.

Si todo lo anterior es correcto, es posible que una forma de detectar cuándo no se entiende un problema en un proyecto de software sea observar lo siguiente (vago y subjetivo, pero identificable si se cuenta con experiencia):

  • Un numero amplio de objetivos.
  • Un número elevado de personas implicadas.
  • Feedback escaso y espaciado (implantación Big Bang).
  • Presupuesto elevado.

Mi última reflexión al hilo de todo esto es que me parece mucho más importante disponer de las personas adecuadas (con experiencia, buena actitud, cultura sana, curiosidad…) que cualquier tecnología. Quizá no sea una gran reflexión, pero creo que es importante recalcar de vez en cuando que la tecnología es la parte menos importante de cualquier proyecto o producto de software.

Anuncios

Muerte por atajo en la gestión de proyectos

WP_20151031_032

Un atajo es un camino que sigues para llegar antes a un lugar al que habitual u oficialmente se llega por otro sitio.

Un atajo no es evidente y requiere de conocimiento del lugar, exploración, un accidente o la revelación de algún conocedor, para poder ser usado.

En general, si se sabe lo que se está haciendo, se puede tomar el atajo sin problemas. Si por el contrario no tenemos suficiente conocimiento, medios o experiencia, suele suceder que acabemos perdidos, con una multa o en peligro en los peores casos (ej: cruzando una autopista).

En los proyectos de software (particularmente los fallidos), los atajos toman muchas formas y el emplearlos alegremente como forma de ahorro (tiempo, dinero, esfuerzo) es una apuesta que suele provocar graves problemas en el resultado del proyecto, afectando tanto al cliente como al proveedor.

Mi top 5 de atajos típicos en los proyectos, es el siguiente.

Definición: Hazme una propuesta

El primer atajo que se suele coger es el de la definición. En lugar de invertir tiempo en definir qué se quiere obtener, se deja de lado el pensar en cualquier detalle que requiera algo de esfuerzo (precisamente los más esenciales) y se deposita una fe mística en la “agilidad” y el “proponme algo” para avanzar.

Esto provoca que, tarde o temprano, proveedor y cliente tengan que desandar un buen trecho del camino del proyecto para poder aclarar indefiniciones o arreglar elementos que se delegaron en técnicos sin conocimiento del negocio.

Por supuesto, si se emplea este atajo, las expectativas del cliente serán inexistentes o equivocadas, por lo que cualquier intento de satisfacerlas y por tanto de completar con éxito el proyecto, estará condenado al fracaso de antemano.

El resultado general suele ser: mucha tensión entre quienes deberían estar colaborando (cliente y proveedor), soluciones de compromiso y un tremendo retraso en el cierre del proyecto debido a la necesidad de rehacer una y otra vez cada parte del proyecto.

Planificación: Fail to prepare, prepare to fail

El segundo atajo es el de la planificación. Aun suponiendo que tengamos una definición clara, se empieza a trabajar antes de tener un plan de trabajo adecuado (prioridades, recursos…), se prima la reacción a la planificación (aunque sea mínima), se comienza sin tener disponibles a las personas clave y sin bases para establecer hitos intermedios que aseguren la dirección correcta.

No se sabe desde dónde se parte, cómo se puede llegar a destino, ni con qué recursos contamos. Sin eso obviamente no tenemos una idea aproximada del coste, ni fechas a las que podamos comprometernos.

Se pretende atajar en tiempo echando a andar en cualquier dirección sin llevar el equivalente a un mapa de la zona, ni llevando encima lo necesario (dinero, agua). Contra intuitivamente se comienza a usar los recursos disponibles en algo para tratar de acabar rápido (como forma de ahorrar costes y satisfacer al cliente), cuando el más mínimo sentido común nos indica que NO deberíamos arrancar hasta tener una idea de si necesitamos ir al Este o si encontraremos obstáculos por cierta ruta que es mejor evitar. No hablo de una gran planificación pero si de un mínimo de saber la dirección y disponer de un par de hitos (kilómetros recorridos, horas andadas).

Podemos saber que este atajo se ha tomado cuando no tenemos hitos que aporten valor de forma incremental (el típico hito único de paso a producción), cuando vacaciones, fiestas o proyectos con recursos compartidos nos pillan por sorpresa, cuando “de repente” nos faltan recursos materiales para trabajar (infraestructura, licencias…) o cuando encontramos los mismos problemas en diferentes proyectos una y otra vez sin verlos venir.

El resultado inevitable de este atajo es un aumento importante en costes y tiempo. No falla.

Costes: Bueno, bonito, barato. Elije dos.

El tercer atajo tentador es el de los costes. Probablemente es el más visible, al poder contabilizarse en forma de dinero, pero esa misma visibilidad y capacidad de figurar como dinero, lo convierten en la víctima propicia a la hora de tomar atajos. El marco mental que establece la gente con el dinero como “gasto” en lugar de “inversión” no ayuda, la verdad.

La reducción de costes para el que pone la pasta se produce, bien por reducción de margen del proveedor (reduciendo calidad o sobrefacturando en otro lado), bien por reducción acordada de calidad (lo que acarreará coste adicional a medio y largo plazo), bien por reducción de alcance del proyecto (que de todas formas está mal definido desde el atajo 1). En resumen, el único ahorro de costes es nominal y temporal, pero alguien tarde o temprano va a comerse la diferencia. Creo que los economistas llaman a eso externalidad.

Tradicionalmente  se reduce el coste inicial del proyecto para que sea más fácil justificar su inicio y luego “ya se verá”, en lugar de definir el valor que se va a obtener y justificar así un coste adecuado (o una cancelación o reajuste temprano del alcance de proyecto). Esta decisión provoca de facto un trabajo extra en justificaciones de cara a todo el mundo cuando, o bien el dinero no llega para cubrir todos los costes, o bien los beneficios obtenidos no son los esperados. Porque todo el mundo recuerda la rebaja de precio inicial pero no la reducción de alcance o calidad que la hizo posible.

Por último, la reducción de coste inicial puede provocar negociaciones y renegociaciones durante el proyecto para obtener la aprobación de los inevitables gastos adicionales. De este modo se puede llegar a emplear más horas/hombre en justificar el coste real del proyecto, que lo que cuesta el proyecto, además de generar una cultura de orientación al precio en lugar de orientación al valor. Es fácil ver que se trata de un atajo con efectos perversos en cualquier organización.

Comunicación: Ya si eso hablamos que ahora tengo mucho lío

El cuarto atajo es el de la comunicación. Los iniciadores de los proyectos al ser personal con un perfil alto (directores de X) suelen “delegar” la gestión del proyecto en personal más prescindible o disponible, es decir: sin conocimiento o experiencia en el ámbito de negocio y técnico del proyecto. Personas que no tienen una idea clara de negocio, con poca o nula experiencia en proyectos similares y por tanto con dificultad para entender el objetivo y riesgos de estos, y con escasa posibilidad de aportar algo al proyecto. Delegar en estas personas no es algo malo per se, y es necesario en muchos casos (si no casi todos, por temas de capacidad y tiempo) pero para asegurarse de que estas personas gestionen correctamente se requiere de una inversión en comunicación muy importante, por lo que la ventaja de estos perfiles “baratos” se limita a ampliar equipo (estrategia) o tiempo de personas clave (a largo plazo), pero desde luego no sirve para ahorrar costes en el proyecto.

El problema aparece cuando el día a día se come el tiempo de las personas clave, los iniciadores que entienden el objetivo de negocio o la tecnología, convirtiendo la delegación en “marrón”.

Sin conocimiento, experiencia, o apoyo, el delegado se convierte en la pieza de un “teléfono estropeado” que va degenerando los objetivos como una mala fotocopia y es incapaz de lidiar con los riesgos y problemas que suceden. Esto tiene un impacto brutal en el proyecto cuanto más arriba se produce el atajo (CEO, CTO, responsable de área, departamento, PM, analista, desarrollador…) y cuantas más niveles de intermediación tenemos ocupada con gente sin experiencia y conocimiento de negocio.

Quizá este atajo es el peor para la propia organización y el que más directivos cometen por falta de tiempo, capacidad de delegar o por una cultura corporativa perversa, porque el efecto a largo plazo es el de generar caos y cierto resentimiento o miedo en la propia empresa. Y desde luego el fracaso del proyecto.

El único remedio para este atajo es no tomarlo: como iniciador de un proyecto, si delegas, tienes que hacerlo en la persona correcta y asegurarte bien de que entiende lo que quieres del proyecto. Y por supuesto estar disponible cuando se requiera. Al fin y al cabo, si no tienes recursos humanos para acometer el proyecto, igual no deberías inciarlo.

Control: Atento al volante

El quinto atajo es el del control. Este atajo toma la forma de falta de validación del proyecto a lo largo de su ejecución. El feedback es esencial para conocer si el proyecto se encamina hacia el éxito, el fracaso o un término medio más o menos aceptable y por tanto es necesario para ir realizando las correcciones necesarias cuando aún es posible.

El cliente y en ocasiones el proveedor, como forma de ahorrarse trabajo en ambos casos, prefiere abandonar el control, que requiere tiempo, conocimiento, análisis, decisiones… y no necesariamente reuniones. En su lugar emplea el sucedáneo de la reacción en momentos más o menos aleatorios para dar “algo” que ocasiona reacciones, a menudo a base de palos y peticiones de esfuerzo adicional (otro caso de externalidad).

La analogía que podríamos usar es la del conductor de un coche que, en lugar de dedicar su atención total a la carretera e indicadores, girando apenas el volante en las curvas y con pocos acelerones y cambios de marcha llega a destino sin sobresaltos, frente al que dedica solo parte de su atención a conducir (ocupándose de la radio, conversaciones, móvil), provocando con ello bandazos, volantazos para corregir un rumbo equivocado y frenazos y acelerones que aumentan el peligro de accidente.

Pero la falta de control también se produce al inicio del proyecto, cuando no se ha establecido una forma clara y objetiva de medir el éxito o fracaso del proyecto, ya sea por falta de definición, planificación, costes o fallo en la comunicación.

En cualquier caso, esta falta de feedback (indicador, marcador, métrica…) provoca que el proyecto sea in-gestionable, dado que la única guía disponible para saber si el proyecto va o no en buena dirección pasa a ser la opinión subjetiva de personas que pueden o no saber algo del proyecto. Todo queda a merced del estado de humor de personas individuales en momentos puntuales.

Esta falta de control y guía suele traducirse en presión errática desde lo alto de la jerarquía hasta la base: el proveedor o técnico, con la esperanza de que aplicando el látigo se pueda corregir la ausencia de control. De esta forma la presión termina por cargarse la planificación y la comunicación (caso de haber existido inicialmente) reemplazándola con horas no contratadas, horas extra y deadlines imposibles como forma de intentar hacer más y más rápido algo que nadie sabe si va en la dirección correcta.

Presionar es MUCHO más fácil que conducir y requiere poca experiencia, reflexión o conocimiento, pero aunque me parece un error, creo que hay un caso en que la existencia de esta no es signo de atajo en el control: si el responsable de negocio carece de experiencia o conocimiento (ver atajo de comunicación) y si el proveedor también carece de experiencia y conocimiento en el problema (ver atajo de coste) es prácticamente lo único que puede hacer el gestor para tratar de obtener un resultado adecuado o cualquier resultado.

-o-

No se me ocurren más atajos, pero cuando observo todos juntos sé que la cosa no va a acabar bien. No puede hacerlo.

En resumen: tomar un atajo sin saber dónde se quiere ir, sin conocer perfectamente la zona (o dejarse guiar por nativos) y tomar varios atajos sin reconocerlos como tales, lleva inevitablemente a perderse y en los peores casos a la muerte del proyecto. Muerte por atajo.