Esta realidad se plantea claramente en lo personal. Noto que existe una falta de coincidencia llamativa entre mis pensamientos y los de otras personas que respeto en gran número de asuntos. En más de un momento me he preguntado donde nacen las diferencias más fundamentales con otras personas, o si es posible rastrear un único origen para muchas de ellas. Tal vez si.
El punto de partida de mi razonamiento son las palabras de Phillip Armour en su libro “The Law of Software Process”. Armour dice que el software no es un producto, es un medio para transportar conocimiento. Y continúa:
Si el software no es un producto, entonces el desarrollo de software no es una actividad de generar productos, no puede serlo. Si el verdadero producto no es el software sino el conocimiento contenido en el software, entonces el desarrollo de software solo puede ser una actividad de adquisición de conocimiento. Es cierto, podemos considerar que algunas de las funciones de desarrollo de software son una trascripción del conocimiento a una forma ejecutable. Esto es codificar. De todas maneras, codificar es sólo una pequeña parte de la actividad de desarrollar software, y se está volviendo más pequeña. También podemos afirmar razonablemente que si ya tenemos el conocimiento, entonces transcribirlo no requiere mucho esfuerzo. El trabajo real ocurre cuando tratamos de transcribir nuestro conocimiento y nos encontramos con que es incompleto. La actividad se convierte rápidamente en buscar el conocimiento correcto.
El desafío no es crear un sistema sino crear un sistema correcto. Si nosotros sabemos exactamente que es lo que tenemos que hacer, podemos crear sistemas tan rápido como nuestros dedos pueden tipear.
El desafío real es descubrir que es lo que el sistema debe hacer, y como podemos construir un sistema que lo haga.
The Law of Software Process: A New Model for the Production and Management of Software, Phillip Armour
Es algo difícil y extraño tomar esta perspectiva del desarrollo de software porque los desarrolladores tenemos una tendencia a pensar que sabemos todo lo necesario y una seguridad bastante manifiesta en nuestro conocimiento. Esta postura surge posiblemente porque los mejores desarrolladores tienen gran facilidad para aprender y cuando adquieren un conocimiento desarrollan una seguridad (excesiva) en ese conocimiento como si hubieran nacido con él. De pronto, un desarrollador que lo más parecido a control de versiones que había hecho en su vida era llamar a un archivo:
version_final.exe
version_final_final.exe
version_final_definitiva.exe
Trabaja en un proyecto donde se aplica un proceso de desarrollo CMM y a las dos semanas comienza a disertar sobre Gestión de Configuración, líneas base y a reírse de la inmadurez de otros que no tienen trazabilidad entre los requerimientos y los test cases.
Pero retomemos la idea de Phillip Armour. Pensemos por un momento que en realidad no sabemos todo y que lo que hacemos en un proyecto es, esencialmente, aprender.
Es crucial preguntarnos entonces como aprendemos, o más específicamente, cual es la manera más eficiente de aprender.
Aquí es cuando la individualidad de las personas, como siempre, comienza a ponerse en el medio. No todas las personas aprenden de la misma manera y estas diferencias en los estilos de aprendizaje se reflejan en más situaciones que las que uno supondría.
Marcus Buckingham, consultor y orador sobre prácticas de liderazgo y management dice que una revisión minuciosa de la teoría de aprendizaje de adultos revela que existen estilos predominantes que a veces se solapan. Entre ellos, el análisis y el hacer:
Primero, está el análisis. Los analistas entienden una tarea aislándola, examinando sus elementos, y reconstruyéndola pieza por pieza. Como cada componente individual de la tarea es importante a sus ojos, ellos necesitan fervientemente información. Necesitan absorber todo lo que existe de conocimiento sobre un asunto antes de poder sentirse cómodos con eso. Si no sienten que tienen suficiente información, escarbarán y presionaran hasta obtenerla. Ellos leerán el material asignado. Asistirán a las clases requeridas. Tomarán buenas notas. Estudiarán. Y aún así querrán más.
La mejor manera de enseñarle a un analista es darle tiempo abundante en la sala de capacitación. Representar situaciones. Hacer ejercicios de postmortem. Descomponer su performance en sus partes de manera que pueda reconstruirla minuciosamente. Siempre darle tiempo para que se prepare. El analista odia los errores. Un punto de vista común es que los errores alimentan el conocimiento, pero para el analista esto simplemente no es verdad. De hecho, la razón por la cual se prepara tan diligentemente es para minimizar la posibilidad de errores. Por lo tanto, no espere enseñarle mucho lanzándolo a una situación nueva y diciéndole que la maneje.
Lo opuesto es verdad para el segundo estilo dominante de aprendizaje, el hacer. Mientras que los momentos más poderosos de aprendizaje para el analista ocurren antes de la acción, para el hacedor ocurren durante la acción. Prueba y error son parte integral de su proceso de aprendizaje. Ellos aprenden más mientras están resolviendo cosas ellos mismos. Para ellos, la preparación es una actividad árida y poco interesante. En lugar de representar una situación con ellos, tome una tarea específica dentro de su rol que sea simple pero real, déle un breve resumen de los resultados que quiere, y aléjese de su camino. Luego incremente gradualmente el grado de complejidad de cada tarea hasta que haya dominado cada aspecto de su rol. Él puede cometer algunos errores en el camino, pero para el hacedor, los errores son la fuente del aprendizaje.
What Great Managers Do, Marcus Buckingham, Harvard Business Review - Marzo 2005
El analista y el hacedor son dos criaturas con grandes diferencias. Sus estilos de aprendizaje se manifiestan a cada instante y en todos los niveles en un proyecto de desarrollo de software.
¿Cómo llevaremos adelante un proyecto?
El analista quiere definir un proceso detallado, amplio, que considere los casos normales y los excepcionales, que abarque la mayor cantidad de tareas y de la manera más profunda posible. Métricas, estándares, herramientas, toda la definición que se toma hoy es tiempo ahorrado mañana. “Hay que hacerlo bien la primera vez”, “hay que evitar el costo del retrabajo”.
El hacedor quiere definir lo menos posible. Sólo las principales tareas y con mínimo detalle. La experiencia le indicará el camino. No quiere ponerse a pensar en todas las variantes ahora. Lo que quiere hacer ahora es ponerse a trabajar, y discutir sobre proceso, a sus ojos, no ofrece grandes aportes o avances en cuanto a resultados. “Hay que definir un proceso que cubra un poco menos de lo indispensable.”
Llega el momento de planificar y el analista comienza la tarea de llenar su gantt con tareas, responsables, dependencias e hitos. Descompone las tareas en subtareas, reestima cada una de ellas. Evalúa la asignación de trabajo de cada responsable, prueba que sucede si cambia algunas asignaciones, si el recurso X trabaja durante este periodo con una carga del 70 % y luego sube a 100 %. Cambia de orden las tareas. Prueba alternativas planificando ejecuciones paralelas. Podrá pasar horas y horas armando y puliendo esta planificación.
El hacedor hace una planificación con grandes hitos y resultados esperados. Luego descompone todo el proyecto en periodos de tiempo más cortos y solo determina el detalle de los resultados esperados para lo más inmediato. Define los objetivos para cada miembro en un periodo de tiempo y confia sabran hacer lo que haga falta para cumplirlos.
Las dependencias y el detalle de las tareas necesarias para llegar a los objetivos se resolverán sobre la marcha, tal como a él le gusta. Posiblemente ni siquiera arme un Gantt (¡sacrilegio!).
El analista comienza a pensar en requerimientos. La especificación debe ser amplia, detallada, completa y dentro de lo posible, inmutable.
El hacedor detalla sólo lo que necesita y no tiene problemas de que las cosas cambien. Tampoco lo incomoda que no estén especificados todos los requerimientos, igual cambiaran en el futuro.
El analista quiere definiciones de diseño, una arquitectura pensada que anticipe las posibles variaciones que depare el futuro, no importa que hoy no debamos implementar el software en varios idiomas, o para distintas bases de datos, o con distintos navegadores, o lo que sea. Siempre generalicemos, eso evitara retrabajo.
El hacedor piensa en diseño evolutivo, YAGNI, solo implementa la funcionalidad requerida y confía que podrá implementar las extensiones y cambios que sean necesarios, pero pensar hoy en algo que hoy no se necesita es perder el tiempo.
Hay situaciones y entornos que facilitan la postura del analista o del hacedor. Hay proyectos donde el nivel de incertidumbre es muy alto e intentar planificar en gran detalle tareas lejanas en el tiempo es una pérdida de tiempo. Hay otros donde la complejidad de la comunicación entre los diferentes equipos participantes requiere una planificación detallada y una definición clara de entregables, con fechas y criterios de completitud.
Pero el problema está en que nos cuesta realizar una evaluación racional de las necesidades de una situación particular y dejar de lado nuestros gustos.
En realidad en muchos momentos no tomamos decisiones racionales, sólo intentamos darle fundamentos racionales a decisiones basadas en preferencias o gustos.
Esto es un comportamiento bastante habitual en nuestro rol de consumidores, por ejemplo. Cuando vamos a comprar ropa y vemos una campera de marca reconocida pero muy similar a una mas barata, si nos gusta lo suficiente, encontraremos las razones necesarias que enmascaren nuestra compra como una decisión racional. “Mmm, si, me conviene comprar esta campera. Porque al final si compro la más barata no la termino usando. Y, en definitiva, estoy gastando dinero en algo que no voy a usar. En cambio, con esta, que sale un poquito más cara, estoy seguro que le voy a sacar provecho. Además como es de muy buena calidad, voy a tener campera para muchos años. Si, ¡me llevo esta!”
Clink, caja. Acabas de comprar una campera que sale el doble que otra porque tiene una etiqueta roja en la manga. No parece una decisión muy racional.
Cuando un analista o un hacedor tienen que tomar una decisión en un proyecto es muy difícil que dejen sus preferencias de lado.
El analista siempre verá riesgos de retrabajo, de hacer las cosas mal.
El hacedor siempre verá como perdida de tiempo tanta preparación, simplemente hagamos lo que tenemos que hacer y si hace falta algo más nos vamos a dar cuenta.
El analista siempre verá que los problemas de hoy son producto de la falta de preparación y planificación.
El hacedor siempre piensa que los problemas de hoy son inevitables y que lo mejor que se puede hacer es afrontarlos y aprender.
Lo constructivo de todo esto es entender que cuando otra persona realiza un planteo sobre necesidades de realizar más definiciones o de realizar menos definiciones puede estar relacionado con su manera de aprender. También darse cuenta cuando uno esta defendiendo una posición simplemente por una cuestión de gustos, no por necesidades reales de un proyecto.
En resumen, conocerse mejor y conocer mejor a los demás, para facilitar las coincidencias. Esto es positivo para cualquier proyecto.
