Todas las cosas que no importan

Y la única que sí

Así es como va la historia.

Tú ves algo que está en las últimas etapas de desarrollo, y caes en la cuenta que le falta algo para estar listo. Está unos cuantos grados descentrado. Un poco confuso.

Lo mencionas de pasada. Tal vez hagas algunas preguntas. Lo que realmente quieres decir es oigan, ésto no está bien, pero no quieres sonar como una idiota. O una imbécil.

Porque sucede lo siguiente, hay un contexto que no conoces.

Por ejemplo, cómo el equipo está tratando de equilibrar un montón de diferentes objetivos al mismo tiempo: metas para aumentar X mientras haces que la persona promedio se sienta Y al mismo tiempo que tratas de no molestar a las personas que hacen Z, y esto es casi imposible de lograr. Es como tratar de mantener una silla en la parte superior de una pila de plantas en la parte superior de un perro que está por caerse. Una locura, ¿cierto? Pero una vez que entiendes las metas, puedes ver cómo el equipo llegó a esa solución, ¿cierto?

Es cuando necesitas ver más allá de la encarnación actual y hacia el futuro para entender el potencial — ¡el increíble poder! — que este desbloquea una vez que la gente lo usa a gran escala. ¡Lo mágica que puede ser esta funcionalidad conforme crezca! ¡Cuántos problemas va a resolver! Pero esta cosa existente es sólo el paso 1: tienes que proyectar hacia el futuro para apreciar completamente su visión.

Es como cuando crees que un enfoque diferente Q sería más provechoso, pero lo que no sabes es que ya otras personas anteriormente se habían entusiasmado con algo similar a Q, y luego el equipo hizo una prueba, y los resultados no fueron prometedores, y ahora ya sabemos que no debemos emocionarnos por nada similar a Q otra vez.

Es cuando todo mundo está diciendo vamos-vamos-vamos-vamos y le piden al equipo que lo termine rápidamente, y debido a que este equipo trabaja muy bien, establecen una fecha de lanzamiento agresiva y no se echan para atrás de cumplir con su compromiso.

Es como cuando esta iniciativa se encuentra dentro de la organización Z, y la organización Z se preocupa por X, y es por eso que este proyecto se centra en X en lugar de Y.

Es cuando había una cantidad increíble de agitación en este proyecto que involucraba una historia de muchos intentos fallidos largos, sórdidos y dolorosos, y las docenas de personas que aguantaron esa terrible tormenta e hicieron que esto pasara merecen medallas, porque el sudor y las lágrimas que derramaron en el desarrollo de esto podría llenar una represa.

Es como cuando esto era lo que quería la persona que estaba a cargo del proyecto, y punto.

Si tuvieras este contexto, entenderías cuan nobles eran las intenciones. Cuan razonablemente estaban actuando los que lo desarrollaron. Lo duro que todo mundo está trabajando.

Si tuvieras este contexto, tal vez tu perspectiva cambiaría.

Esta es la trampa en la que caemos frecuentemente.

Hay dos tipos de contextos. El primero son las cosas que anteriormente no sabías acerca de las personas para las cuales estas desarrollando. ¿Qué es importante para ellos? ¿Qué hemos aprendido de ellos en el pasado? ¿Qué problemas están enfrentando? Ese tipo de contexto es invaluable. Ese tipo de contexto te ayuda a desarrollar cosas mejores.

El segundo tipo de contexto son las excusas.

¿Le importará a tus usuarios que el problema tuviera muchas limitaciones? ¿Que la estructura de la organización fuera extraña? ¿Que tu jefe fuera irracional? ¿Que la visión como fue proyectada hace dos años es increíble?

¿Entonces, por qué te importa a ti?

Al final del día, el viento se lleva todos los por qués.

Lo que queda — la única cosa que importa a los builders [generadores de códigos]— es que lo que ellos desarrollen funcione bien para las personas hacia las cuales era dirigido.

Dichosos son los builders con amnesia selectiva, que pueden ver la cosa exactamente como es, sin la historia. Sin las excusas.