Estos últimos días he estado rememorando todos los proyectos en los que he participado, que desde el 95 a esta parte son unos cuantos. Recopilando esa experiencia voy llegando a la conclusión de que casi todas las metodologías comunmente empleadas se equivocan en el objetivo fundamental. A renglón seguido voy a proponer mi conjetura sobre el error de base, que se aplica no sólo a los proyectos informáticos sino también a cualquier proyecto vital.
Veamos, históricamente teníamos waterfall. Waterfall, en resumen, viene a decir que el cliente te da una serie de requisitos, digamos: el logro profesional, la casa, el coche, los niños, las vacaciones en la Costa del Sol, etc. Y tú diseñas como implementarlo: el empleo, la hipoteca, el leasing, la clínica de fertilización in vitro, la multipropiedad costera… El problema de waterfall es que resultaba muy difícil cambiar la salida del sistema una vez que se habían introducido las entradas, ya que no te puedes cambiar fácilmente de empleo, ni puedes divorciarte del banco, y a los hijos bien les quieres a morir bien preferirías haber tenido un perro según te hayas levantado de la cama ese día con el pie izquierdo o con el derecho.
Entonces alguien propuso Agile, que grosso modo es una herencia de metodologías japonesas para incrementar la productividad. El manifiesto agilista afirmó que lo importante ya no era saber exactamente desde el principio qué es lo que se quería hacer, sino maximizar la productividad y facilitar la incorporación de cambios de la mejor forma posible. Creo que fué entonces cuando aparecieron los yuppies 100% enfocados en ganar más dinero por día del que pueden razonablemente gastar.
Incrementar la productividad sin incorporar controles contínuos de calidad era suicida y es por eso que todos los equipos ágiles hacen también Test Driven Development (en la vida real el TDD es como acostarse con una persona antes de casarse con ella).
Hasta aquí teóricamente muy bien. Tenemos una idea aproximada de lo que queremos, tenemos una buena metodología de gestión de cambios y somos productivos. Excepto que por el camino se nos ha perdido el factor humano, concretamente, se nos ha olvidado cuánto miedo y cuánta frustración experimentan las personas durante el proceso de alcanzar los objetivos.
Y aquí vienen mis diez postulados sobre la gestión de proyectos basada en expectativas:
1. El cliente no sabe lo que quiere. Sabe cuales son sus objetivos de negocio. Pero no sabe cómo traducir estos objetivos en una lista de tareas técnicas. El gerente de cuenta tampoco lo sabe (porque tampoco es técnico). El único que sabe exactamente lo que hay que hacer es el programador. Pero al programador se le ocultan normalmente los objetivos de negocio. Por consiguiente, el programador va a ciegas respecto de los objetivos reales del proyecto.
2. El éxito se mide sólo en función de las expectativas. La productividad no importa. Con las herramientas modernas la productividad es tan grande que normalmente sobrepasa cualquier requisito de la demanda. El éxito de un proyecto no es lo que se alcanzó en términos absolutos, sino la diferencia entre lo que el cliente esperaba obtener y lo que obtuvo realmente. He aquí el gran malentendido de los story point. En Agile, el story point es una métrica abstracta del valor que obtiene el cliente. Se supone que cuantos más story points por sprint obtenga el cliente más satisfecho estará. Pero esto, en general, es falso. Lo que el cliente quiere realmente (aunque a veces pida otra cosa) es saber a priori cuántos story points obtendrá de forma segura por unidad de tiempo en el futuro próximo. En la vida cotidiana así es como mucha gente termina con el superpuesto directivo, la mansión, los niños, el perro, el smartphone, el superdeportivo y profundamente amargada y decepcionada.
3. La mayoría de la gente no aguanta trabajar bajo presión. La predictibilidad y la tranquilidad son mucho más importantes que la productividad. Esto es debido a que la mayoría de la gente es incapaz de gestionar la incertidumbre, pues la duda sobre lo que va a suceder les causa una ansiedad insoportable incluso cuando el resultado más probable de la incertidumbre sea un éxito rotundo. Es decir, la sensación de «éxito» en un proyecto no se percibe tanto por la velocidad a la que avanza sino por la cantidad de incertidumbre que reduce.
4. Los detalles sobre lo que está sucediendo no son para corazones sensibles. La mayoría de las personas se desmayan o entran en pánico cuando ven sangre. Es por esto, en parte, que al paciente lo sedan y a los médicos no les gusta tener público observando cómo trabajan, pues cuanta más gente haya mirando cómo está el pulso del paciente mayor es la probabilidad de que cunda el pánico si tiene un latido más rápido o lento que otro. El veto informativo no sólo se aplica al cliente o a los familiares del paciente, sino también a los propios gestores de cuenta. Por dicha razón, el Doctor House va por libre y no le comenta a nadie lo que está haciendo. Aunque si no se tratase de una ficción televisiva en la vida real a House lo habrían despedido tres veces en cada temporada por saltarse los protocolos.
5. Los planes son papel mojado, pero la planificación es imprescindible. Es imposible especificar a priori de forma completa y rigurosa todo lo que se requiere en un proyecto. Pero, por otra parte, si no se hace tal esfuerzo, a posteriori en el mismo instante en que algo salga mal (y siempre hay algo que sale mal) los incumbentes empezarán a culparse unos a otros sobre quién no se había enterado de qué. El desarrollo iterativo basado en adaptarse a las necesidades cambiantes del cliente es un plan suicida debido a que termina inexorablemente en una discusión acalorada sobre quién cambió qué y cuándo, en la cual el proveedor (aunque sea inocente) lleva siempre las de perder.
6. La metodología debe cambiar con la fase del proyecto. No era posible descubrir América calculando exactamente dónde estaba, ni agua para cuántos días se requeriría en el camino. Por otra parte, no es posible mantener un asentamiento colonial viable sin saber cuánta agua se necesita a diario. Es decir, con una metodología de colono nunca descubrirás América y con una metodología de descubridor nunca sobrevirás en América.
7. Obsesionarse con hacerlo todo bien conduce a resultados indeseados. El objetivo de un proyecto es lograr un resultado excelente y para ello hay que hacerlo todo siempre lo mejor posible. Nunca hay que despreciar las buenas prácticas pues se crearon por muy buenas razones, pero no se debe confundir el fin con los medios. Algunas personas se obsesionan tanto con las metodologías y los protocolos que estos acaban siendo un fin en si mismos. Y el día en que la metodología empieza a gobernar tu vida es que has perdido el norte, lo mismo seas un fanático del gantt o del sprint board o un fanático religioso. Las personas se aferran a rajatabla las metodologías y a los rituales porque les proporcionan una falsa sensación de seguridad.
8. Sólo un profesional puede juzgar el desempeño de otro profesional. Todos los programadores que he conocido son geniales. Y todos los médicos que he conocido son los mejores en su especialidad. Pero yo carezco de criterio para determinar si mi médico de cabecera es un milagrero o un matasanos.
9. Nunca hay que hacer caso de lo que dice la persona presuntamente a cargo. Esto es debido a que por el Principio de Peter las personas ascienden en la jerarquía hasta que no son capaces ni de formular sus propios objetivos. Hay que tener en cuenta que la explicación que da el responsable de algo consiste en un conjunto de justificaciones para demostrar porqué no es su responsabilidad. Los mayores desastres son siempre causados por los «mejores» gestores debido a la confianza ciega que la gente deposita en ellos.
10. Cualquier metodología que ignore el factor humano está condenada al fracaso. No se puede poner en práctica un proceso sin tener en cuenta cómo se sentirán las personas implicadas en ese proceso. Esto los militares lo saben muy bien y es por eso que se pone a los soldados a cantar en grupo, además de muchísimos otros rituales castrenses. Como por alguna absurda razón nos parece ridículo que los programadores se junten para cantar, lo que hemos hecho es tratar de eliminar el factor humano de la metodología, automatizarlo todo con sistemas de integración contínua y reducir al empleado a un robot que produce story points bajo una estricta supervisión. Lo cual sería una idea fantástica de no ser porque el empleado no es un robot dotado de inteligencia.
Como conclusión, todo tiene que ver con el difícil equilibrio entre nuestras grandes esperanzas y la conciencia sobre lo que podemos alcanzar realmente. Si no fracasas y te equivocas lo bastante entonces es que tus objetivos no eran lo suficientemente ambiciosos. Por otra parte, los humanos reaccionan de forma muy desagradable ante el fracaso, e incluso sólo ante la idea imaginaría de fracasar. La solución a este dilema es ser capaz de encapsular los riesgos en una caja de seguridad, de modo que si todo explota los daños estén controlados. Es como correr Fórmula 1. No se trata de ir despacito por la pista para no salirte de ella. Sino de correr a la mayor velocidad posible en la confianza de que si te sales del trazado y das tres vueltas de campana destrozarás el bólido pero tú aún conseguirás salir de él en una sola pieza.
Post relacionado: Las zonas grises de Agile.
Pingback: Muerte por agilismo | La Pastilla Roja