Me encantan las series, los cómics, los libros, etc., de zombis y me encanta ‘The Walking Dead’. No sé, quizá sea porque soy informático y eso haga que en mi día a día me sienta identificado. Desde que tengo ‘uso de razón profesional’, desde que me dedico a ayudar a empresas tecnológicas, me parece que, al igual que Rick, el mundo de la tecnología está lleno de… Walking Deads.
En mi caso, afortunadamente, por ahora, los Walking Deads que encuentro no se comen a la gente, pero sí que se comen la productividad de las organizaciones, la calidad del software, la competitividad de las empresas tecnológicas y… la felicidad de todo aquel que se encuentre con uno.
La lista de ‘Walking Dead Software’ es tremendamente larga y la plaga lleva con nosotros demasiado tiempo, así que permítanme que de entre tantos haga una selección personal de 7 Walking Dead Software que asolan nuestro mundo.
Ah, y antes de comenzar, no olviden lo siguiente: en los episodios de ‘The Walking Dead’ el verdadero problema de Rick no son los zombis… son los humanos. A nosotros nos va a pasar algo similar, cuidado que son los humanos los que crean… ‘The Walking Dead Software’.
Índice de temas
Walking Dead Software 1: Planes de proyecto y requisitos inamovibles
Vamos con el primero. La ‘gestión de proyectos’ clásica, esa que tiene como máximo objetivo tener un plan, un plan de proyecto (que hasta incluso se pintaba en un Walking Gantt, de esos peligrosos), fecha inicio, fin y coste. Y que para estimarlo y presupuestarlo pide saber detalladamente qué hay que construir; para ello tener requisitos y cerrarlos para estimar, presupuestar y que una vez que arranque el proyecto los requisitos no se muevan, ya que son la justificación del tiempo y presupuesto dado.
Y, listo el plan, el éxito del proyecto se basa en cumplir eso… tiempos y presupuesto.
Dicho lo anterior, todo se preveía maravillosamente, sino fuera por una cosa, que tan concentrados estábamos en cumplir tiempos y presupuesto que en ocasiones pasamos por alto si aquellos requisitos eran los que debían ser o si habían cambiado mientras el proyecto se desarrollaba. Lo que incluso llevaba a situaciones tan sin sentido como cumplimientos de tiempos y presupuestos, es decir, ‘éxito del proyecto’… pero habiendo creado productos que nadie quería, requisitos erróneos. Ya saben, cumplir ante todo el presupuesto… aunque lo construido no valga para nada.
Consejo, los requisitos van a cambiar, gestionen pensando en el cambio y por ello… los planes (y hasta el propio software) deben poder cambiar.
Walking Dead Software 2: Gestión por proyecto frente a equipos
La ‘visión de proyectos’ hace dejar en un segundo plano la verdadera clave de la competitividad en el mundo de la tecnología… los equipos. Y conlleva que en vez de tener ‘equipos estables’, autónomos y multifuncionales que hacen tareas (que pueden pertenecer a uno o varios proyectos) dispongamos de proyectos que van llegando y a los que se van asignando personas.
Y por ello tenemos una visión nada clara de la situación: personas en un montón de proyectos a la vez, en un montón de tareas, bajo un montón de prioridades, hitos, bajo un montón de responsables… altos desperdicios de tiempo por cambiar de contexto, ir de una tarea medio hecha a otra, sin terminar ninguna.
Estructurarse por equipos estables implica trabajar por todos los medios en aumentar la productividad a largo plazo, a tiempo indefinido y ritmo sostenible, del equipo, lo que implica un entorno físico adecuado, evitar las interrupciones, equipos pequeños, etc., y, sobre todo, motivación y talento.
Estructurarse por equipos estables evita las tentaciones que había en el ‘mundo proyectos’ de saltarse etapas imprescindibles, como el testing, para entregar antes, ya que esos saltos de tareas necesarias lastrarán la velocidad del equipo en las siguientes iteraciones o Sprints (deuda técnica) y esos bajones de productividad se verán muy claramente.
Estructurarse por equipos estables que pudieran hacer tareas de proyectos (en vez de estructurarse por proyectos a los que asigno personas) permite conocer el avance real de las tareas y permite una estimación empírica basada en la velocidad por intervalo de tiempos.
Estructurarse por equipos estables evita las tentaciones que había en el ‘mundo proyectos’ de saltarse etapas imprescindibles, como el testing
Walking Dead 3: Proyectos
Bueno, y ya puestos, después de los dos anteriores, y muchos otros de los que no hay espacio para escribirlos… ¿Proyectos? ¿Por qué proyectos? Esa herencia envenenada de pretender imitar a aquellas profesiones que trabajan creando productos físicos. Pero los puentes y las carreteras no cambian de funcionalidad cada dos por tres. Los puentes y las obras se terminan, fecha fin… ¿Se termina alguna vez un software que es la base de un negocio? ¿Se puede versionar un puente? Sustanciales diferencias con la tecnología, lo que hace que los modelos de trabajo con ‘cosas físicas’ no sean del todo aplicables al software.
Ah, como curiosidad, comentaré que en los cómics y serie ‘The Walking Dead’ si hay una palabra que nunca se ha pronunciado es ‘zombis’, solo hay ‘caminantes’. De manera similar, vamos a intentar eliminar la palabra ‘proyecto’, y será por eso que grandes empresas de tecnología usan eslóganes internos como ‘no projects’, ‘unproject’ o ‘beyondproyect’.
Walking Dead Software 4: Equipos especializados vs multifuncionales
Testing lo más lejos de desarrollo. Desarrollo separado de Operaciones. Operaciones separado de Testing. Todos los anteriores separados de Negocio. Tareas que requieren para completarse de todas los anteriores, pero que van saltando de departamento en departamento, incluso de empresa en empresa. Cada una termina lo suyo… pero en realidad nada está terminado completamente hasta el último momento. Tiempos, desperdicios, saltos, formularios para ‘el comité de cambios en producción’, pulls, horas asignadas… ‘The Walking Dead Software’.
Desarrollo separado de Operaciones. Operaciones separado de Testing. Todos los anteriores separados de Negocio
¿Y si trabajamos en un único equipo autónomo, pequeño, que incluya dentro todas las competencias necesarias para completar el trabajo?
Walking Dead Software 5: Hacer Testing solo al final es de débiles
Hablando de Testing… el Testing ‘al final del proyecto’ (de nuevo, los proyectos), incluso el Testing ‘al final del sprint’. Ese Testing al final, sí, ese, cuando acumula los retrasos de todas las fases anteriores, cuando aquello que encuentra, aquello que habría que solucionar, es tan grande, y se detecta en un momento tan inoportuno… que la presión por dejarlo ahí, así como está… es demasiado fuerte… ‘The Walking Dead’. ¿Y si el testing se hace al principio en vez de al final? Pero es más, ¿Por qué el Testing de siempre era una fase, fecha inicio – fecha fin? ¿Fase? ¿Y si no hacemos una fase de Testing?
¿Y si hacemos tareas de Testing de manera muy frecuente, casi en paralelo al desarrollo? Ya saben, aquello que más duele hazlo cuanto antes y en trocitos lo más pequeños posibles.
Walking Dead Software 6: Gestionar por horas
Toda mi vida profesional me ha perseguido el ‘Walking Dead’ de ‘a ver quién trabaja más horas’ y el de medir el trabajo ‘en horas’ y en la mayoría de las ocasiones… me han pillado. Recuerdo haber programado dando cabezadas (no cuento lo que pudo salir de allí). Una vez tuve un jefe que nos enviaba correos por la noche para, a la mañana siguiente, regañar públicamente a quienes no lo habían leído. Aquel sitio en el que si te ibas a tu hora, al levantarte y coger el abrigo, el jefe te decía “-Oye ¿es que tienes frio? Si eso ponemos la calefacción-”. Cuando trabajaba para una consultora grande, si había algo que te hacían aprender rápido era que el mejor, el más comprometido decían, era el que salía más tarde. Daba igual que estuvieras 12 horas pensando en como organizar la fiesta del próximo fin de semana, lo importante no era tanto tu mente… era tu cuerpo sentado en una silla. Aunque a esas horas las sillas las ocupen… ‘Walking Deads’.
Así, creamos un sector tecnológico estructurado bajo el patrón hora (otra herencia de creer que esto es como la industria): subcontrataciones y facturaciones por horas, bolsas de horas, medir el avance del proyecto en función de horas transcurridas, valorar a la gente por las horas que echa… horas, horas y horas.
Ya saben, lo que mides… lo que obtienes. Si mides horas, tendrás horas. Como si el trabajo intelectual, como es el de crear tecnología y negocios de base tecnológica… fuera el de un copista medieval o el de un mecanógrafo.
- Horas en un lugar físico no equivalen directamente a horas productivas. Es una lastima pero así es. Trabajas con la mente y la mente no entiende de lugares físicos.
- Contar las horas no asegura ni de lejos mejores resultados. No hay relación directa con la motivación, ni con la mejora de prácticas, ni equivalen a avance.
- Si ponen un sistema de fichar le están diciendo a la gente que miden su trabajo por horas. Y horas darán. Y justificarán a malos profesionales, ya que como les miden en horas sentados, pues ellos estarán sentados, no les están pidiendo que aporten ideas, y habiendo cubierto las horas silla… habrán cumplido como el que más. Y los pondrán al nivel de los buenos profesionales.
Consejo: Si quieren medir algo mejor midan velocidad en trabajo completado (terminado y entregado, quizá en puntos historia) o mejor en… valor aportado al negocio (Hypothesis-Driven Development y similares), pero no midan horas que eso está demasiado obsoleto.
Walking Dead Software 7: Documentación y burocracia
Lo sé, es difícil dejar de documentar, produce miedo, abstinencia, el conocido síndrome de abstinencia documental, que ocurre cuando se deja de usar masivamente el Word o el PowerPoint. Estándares, normas, procedimientos, registros, planes de viabilidad, plantillas, guías, manuales, PDF y PDF, Excels y herramientas que automatizan la creación y expulsión de documentos.
Quizá una de las justificaciones más curiosas para documentar es para… “no depender del desarrollador”. Lógico ¿no?. Para no depender de Pepe, hay que sacarle a Pepe las cosas de la cabeza… ¡Y que las escriba en un documento!
¿Con que probabilidad creen que lo que hay en un papel se parece en algo a lo que de verdad se ha programado? ¿O que tener documentos que incluso llegan a explicar cosas tremendamente mal hechas, que de haberse hecho bien… serían auto-explicativas sin necesidad de un documento, es una buena idea?
¿Quieren un consejo? ¿Saben cuál es la mayor garantía de reducir la dependencia de personas? Más que tener documentos que probablemente nadie mantenga, de los que existen dudas de que cuenten la realidad o que justifiquen explicaciones de cosas mal hechas… Hacer las cosas bien. En el caso del desarrollo… Tener buen código (no buenos PDF). Código limpio. Buenos diseños. Buenas Pruebas. Buen control de versiones. Métricas de calidad software en valores razonables. Control de la Deuda Técnica. No tener exceso de líneas de código. No tener aberraciones en el diseño. Etc.
¿Y qué pasa con los documentos? ¿Los eliminamos todos? Hagan documentación inteligente, mínima y útil. Como decía Mike Cohn y Tom Poppendieck: “Cuando los documentos son en su mayoría para pasarse el testigo de unos a otros, son malos. Cuando capturan una conversación que es mejor no olvidar, son valiosos”.
Pero no lo olviden… por muy buena documentación que tengan, recuerden, no serán tan libres como teniendo… buen código. n
