¿Cuántas veces recibiste algo y te diste cuenta que no es lo que pediste?, o tal vez debería decir ¿… y te diste cuenta que no es lo que esperabas?
Cuando uno avanza en su carrera es normal que le den la responsabilidad de coordinar o revisar el trabajo de otros. Este trabajo por hacer son los requerimientos del sistema en el que estamos trabajando y dependiendo de cómo sea el entorno de cada equipo, estos requerimientos pueden estar mejor o peor definidos, o más bien, mejor o peor documentados.
Últimamente me suele pasar que lo que yo esperaba ver en el momento de la revisión no era lo que recibía. Lo primero que empecé a pensar es que estaba siendo muy exigente y que debía bajar mis expectativas.
Lo importante no es lo que dices sino lo que la gente entiende. Words That Work, Dr. Frank Luntz.
La respuesta “fácil” es pensar que el programador hizo lo que quiso; que no entendió lo que le pedí; o que tiene poca experiencia y por eso interpreta mal las cosas (hay ejemplos reales de todas esas afirmaciones pero no vienen al caso :D). Pero hay un factor clave que no estaba teniendo en cuenta: como comunico lo que quiero a los demás. Haciendo una retrospectiva me di cuenta de que prácticamente les estaba tirando tickets por la cabeza sin mayor contexto.
A partir de estas observaciones es donde comencé a preguntarme qué es lo que estaba haciendo mal y la respuesta a la que llegué se puede resumir como la “maldición del conocimiento”.
La maldición del conocimiento: Una vez que conocemos algo, nos resulta muy duro imaginarnos cómo era no conocerlo.
En el momento en que cae un problema nuevo y uno comienza a definir cómo lo resolvería, ya comienza a tener un pre-concepto de qué es lo que espera uno ver. Si cuando le pedimos a otra persona que resuelva el problema por nosotros, no le transferimos ese conocimiento, es cuando se genera este “roce” que nos hace doler la panza y pensar “¡¿por qué lo implementó de esta manera?!”; o darse cuenta de que hay ciertos casos que no estaban contemplados por la persona que resolvió el problema. Quizás ni siquiera estaban claros que esos faltantes eran un problema.
El efecto que observo de este tipo de problemas es que el proyecto “está atrasado”. “¿No entregábamos ayer?” podría preguntar alguien. Quizás de haber estado bien comunicado de entrada ser podía prever que “ayer” no era posible entregar. Quizás de haber comunicado de manera diferente, la persona que realizó el trabajo podría haber sido más efectiva.
Soluciones a este problema hay varias, según cada equipo y organización puede que una u otra se adapte mejor.
La primer opción y quizás la más tradicional es contar con un Analista Funcional que se encargue de especificar al detalle cada problema de cada proyecto de cada cliente. Si bien no estoy en contra de esto, creo que no escala para el día a día. En nuestra industria los requerimientos cambian muy rápido y dejan obsoleta muchas veces cualquier planificación. Sí nos suele servir, a nosotros como empresa, para el kickoff, donde se puede recolectar una primera aproximación de lo que quiere el cliente.
Una segunda opción es que alguno de los empleados más experimentados haga de “Analista” y se pase horas escribiendo lo que pretende que hagan los demás desarrolladores. Es lo que en general hago ahora, salvo en algunos casos, pero no me funciona por un par de razones.
La primera razón es porque la cantidad de tickets pueden ser decenas o cientos. Y especificar cosas que ni el cliente ni yo sabemos cómo las haríamos (o si siquiera se quieren hacer) carece de sentido práctico y termina siendo una pérdida de tiempo. Además nada garantiza que pueda ver todos los ángulos del problema para dejar claro que quiero.
La segunda razón y tal vez la más importante, es que para que esto sea útil lo tendría que hacer bajo demanda, es decir, cada vez que alguien va a empezar un ticket, agarrarlo, pensarlo, documentarlo y delegarlo. ¿Se imaginan cuánto tiempo les quedaría además para hacer algo realmente productivo?. Cero!. Eso sin contar que pasaríamos a ser el cuello de botella de todos los proyectos.
En el último post hablé de buscar mejores formas de construir software, y si algo me han enseñado mis años participando en comunidades de software libre es que compartir el conocimiento y la responsabilidad es beneficioso para todos.
Los frameworks ágiles, como Scrum, plantean este cambio de conducta. Es por eso que existe la Planning meeting o el refinamiento del backlog, momentos en el que el equipo se reúne completo, junto con el dueño del producto (puede o no ser el cliente real) a entender las tareas pendientes, hacer preguntas y documentar que se va a hacer en cada caso.
Está claro que la premisa fundamental para “estar todos en la misma página” es eliminar los intermediarios y que los temas se discutan abiertamente.
Como ganancia extra, involucrar a las personas les da un sentido de pertenencia que genera una responsabilidad en ellas, y por lo tanto un mayor compromiso hacia su trabajo siendo un beneficio tanto para ellos como para el cliente. Pueden leer más al respecto en Equipos Estables por sobre Pool de Recursos escrito por Martin Alaimo.
Para ir cerrando, les dejo una lista de tareas con cosas que creo que deberían ayudar y que tengo intención de ir mejorando :
- Involucrar a todos, siempre.
- Hacerlos participar, es decir, dejarlos hablar y escucharlos.
- Incentivar el debate, tener dos ideas es mejor que tener una :).
- Analizar pro y contras de las opciones y dejar documentado lo que se decida.
Para terminar, me gustaría cerrar con una pregunta para seguir aprendiendo: ¿Qué hacés en tu equipo/empresa para mejorar la forma en que se comunican?