Preguntar bien para trabajar

Este artículo es el resultado de la aplicación del concepto, técnica, modalidad o como lo quieras llamar que había registrado antes, en ese momento fue ponerle una descripción a lo que hacía de modo intuitivo y medio inconsciente.

Tras todos estos años, ya de modo conciente de aplicarlo, también lo he extendido desde el aprendizaje al trabajo y hace unos pocos días tuve un evento muy ilustrativo que me disparó escribir esto como actualización.

 

Lo que había dicho en la otra oportunidad se podría resumir así:

Estoy con un problema, hago una pregunta y antes de enviarla, me pongo en el lugar de quien podría contestarla y me imagino que me va a pedir que complete. Lo hago, vuelvo a mirar y cuando ya no puedo hacer nada más, lo envío.

Lo interesante es que cerca de tres de cada cuatro veces, no necesito enviar pues el problema queda resuelto.

 

Lo último que ha ocurrido, está relacionado algo que no es de estudio o hobby pero tampoco es de trabajo, llamemoslo de "responsabilidad profesional", mi colaboración el el proyecto CIAA.

En pocas palabras por si no conocés, es un proyecto de Open Source Hardware y Software (Open de Todo) en el cual vengo colaborando, últimamente en arreglar el sitio cuando algo falla.

La última falla fue por una migración automática que produjo una catarata de dependencias. Estando yo con poco tiempo y sabiendo muy poco de la aplicación solicité ayuda en embebidos.

Fuí muy escueto a propósito, estaba filtrando, buscando más alguien que supiera de antemano que alguna persona solidaria que me ayudara a investigar, no quería pasarle el muerto a algiuen en mi misma situación.

Tres minutos más tarde una persona me contestó en privado, Daniel C.B.

En mi borrador de mail primero expliqué qué había ocurrido y cómo había roto, en este caso la esencia del problema era que php había sido actualizado, entonces tiraba unos deprecated.

Cómo había ido solucionando algunos aspectos, armé un listado tipo problema/solución para ir relatándole lo ya hecho y el bloqueo actual.

Luego noté que había estado aplicando de modo desordenado los pasos de migración [*]. Por completitud entonces comprobé los había hecho y completé los faltantes, que igual, como sospechaba y por eso no los había respetado mucho, no hacían mucha diferencia.

Me puse entonces en el lugar de la persona y pensé, si le paso esto como está, aún con este lindo mail, lo mato. Evalué que para poder hacer un mail mejor, me iba a llevar el mismo o más tiempo que quizás arreglarlo. No estamos hablando de veinte minutos, de hecho me llevó varias horas y un esfuerzo mental considerable.

Pero, magia, otra vez, al estar conforme con las dependencias del mail, el problema ya estaba solucionado... en su mayor parte, ahora quedan algunos detalles de terminación.

Pasamos de la perspectiva de "tomá este sitio que no se puede exponer a Internet" a "¿te podrías fijar que parece que quedó un plugin sin instalar o mal configurado?

 

Lo nuevo

Durante todos estos años extendí la técnica debido a las cadenas de mail de trabajo. Estas suelen ir ampliando su audiencia ("sumo a tal que se encarga de ese aspecto") y a veces se extienden durante varios días sino semanas.

Esto provoca dos cosas: que hay gente nueva en la conversación a la que se le obliga a leer toda la cadena con sus idas y vueltas. Las otras personas, si ha pasado algún tiempo y como todo el mundo lleva siempre varios temas adelante, o no recuerdan o les cuesta.

 

Entonces, una práctica que me autoimpongo y recomiendo es cada tanto hacer un resumen e incluso, borrar las partes superfluas de la conversación del cuerpo principal, sí dejarla por si tengo un error de interpretación que pueda ser detectado.

Quedan entonces uno o dos párrafos diciendo el problema es tal, tal persona sugirió esta causa, la otra otra, tal esta solución y estamos más o menos así.

Como ejemplo tengo reciente que gestionando una vulnerabilidad ocurrió esto:

Se estaba reportando que estaba TLS 1.1 activo y había LUCKY13. El problema es que al revisar el sistema, TLS 1.1 ya no estaba activo y LUCKY13 era potencial debido a unas ciphersuites débiles, que de todos modos eran un defecto por si mismo.

Habían personas que retomaban la cadena con el reporte original, lo cual me producía increibles confusiones.

Entonces, el reporte actualizado, es: hay ciphersuites débiles, su eliminación producirán como efecto colateral la desaparición del potencial LUCKY13

Lo que agrego en esta oportunidad es:

No asumir que todos estamos prestando la misma atención a la conversación ni sabemos lo mismo, hacer frecuentes resúmenes y actualizaciones para no retroceder ni confundir.

Nota:

[*] No es el tema, pero esto me recuerda algo que ocurrió en uno de los cursos que doy. Usamos una VM con unos pasos a seguir en la instalación. Uno de los alumnos en lugar de seguir los pasos next->next->next para configurarla e instalarla se buscó algún video en internet y por supuesto luego no le anduvo, argumentó que "Admito que me salí del manual porque no lo sentí tan practico", lo cual, considerando que cerca de 60 personas lo habían transitado previamente y que cada vez está más refinado, es un tanto subjetivo.

Eh, pero es justo lo que vos hiciste, me vas a decir, ¿por qué no respetaste a rajatabla el procedimiento de migración?

Bueno, la verdad es que en uno de los intentos sí lo había respetado, pero el problema es que procedimiento contempla pasar de una versión a la siguiente, no como era este el caso de... no voy a decir cuántas, muchas... demasiadas...

Quizás el paso más crítico que no respeté, ni lo voy a hacer, es leer el historial de cambios, no me alcanza la vida. Usé mi instinto y sumándole la metodología expuesta, funcionó.