OSiUX Work In Progress Flow

AUTHOR: Osiris Alejandro Gomez

EMAIL: osiux@osiux.com

DATE: 2022-08-02 01:10

[IMG]

[1]

promesa de fin de año

A principio del año 2021, en plenas vacaciones, como todos los años, reflexiono sobre qué espero hacer todo el año, ya desistí de titularlo *"objetivos"* porque en el fondo sé que me voy a desviar de lo *"planificado"* y por ello intento registrar un punteo de ideas que puedo desarrollarlas o abandonarlas, pero que están ahí para no ser olvidadas, esperando a que las continué de alguna manera en algún momento...

Sin dudas el 2020 fue un año atípico para todo el planeta, yo no logré escribir al menos 1 *post* en todo el año y por ello comencé el 2021 con un `desafío compartido` ^1[2] que dio muy buenos resultados por 2 meses y luego volví a abandonar una vez más mi *blog*... `:)`

punteo de ideas

A un mes de terminar el 2021 vuelvo a mi lucha interna y recordé ese punteo que hice hace 11 meses:

* Analizo para Sistematizar
* Priorizo para Terminar
* Modulo para Mantener
* Registro para Optimizar
* Automatizo para Delegar
* Documento para Independizar
* Libero para Visibilizar

Estas definiciones de acciones estuvieron latentes en mi mente y voy a intentar desarrollarlas o al menos esbozarlas para que empiecen a encajar unas con otras y ver si con una definición concreta se convierten en una suerte de guía metodológica para iniciar un nuevo año un poco menos caótico.

definiciones de acciones

Haciendo una suerte de revisionismo histórico sobre mis años de trabajo como `"Developer vs SysAdmin GNU/Linux"` comprobé una vez más mi falta de disciplina y llegué a aceptar que `"amo el orden pero soy un caos"`

El pegamento que une estas acciones es otro intento para completar las tareas (luego de *"fracasar"* repetidamente con *GTD* ^2[3], *AutoFocus* ^3[4], *SCRUM* ^4[5], etc) pero esta vez pensando que en algún momento no voy a estar para continuar lo abandonado y con la esperanza de que alguien retome las tareas inconclusas o que al menos sirvan de inspiración o como guía de todo lo que esta mal `:P`

No estoy inventando nada nuevo, esto es solo un *remix* muy mezclado de todo lo aprendido, pero "ordenado" de otra manera, tal vez como una `"definición de terminado"` a obtener en solo 7 pasos. `:)`

Analizo para Sistematizar

Lo más importante es `tener clara la tarea a realizar` y sus implicancias:

que subtareas son necesarias ?

cual es el contexto de cada tarea o subtarea ?

dónde hacerlas ?

con qué herramientas ?

en que orden ?

todas debo hacerlas yo mismo? Puedo delegar algunas ?

necesito `MAS DATOS` ?

cuál es bloqueante ?

cuáles se pueden descartar ?

En fin, podríamos resumir en todo esto en simplemente `Analizar` pero sería minimizarlo en cierto punto, porque si no las escribo de manera clara en un *gestor de tareas* o al menos en un *archivo de texto*, no voy a poder contrastarlas para luego poder sistematizarlas, es decir, encontrar qué tienen de similares entre si y con respecto a tareas anteriores, para así definir un mínimo factor en común a establecer de ahora en más y tener mas clara la dependencia de unas con otras.

Priorizo para Terminar

Cientos de ideas para agregar, corregir, modificar y mejorar todas compitiendo entre sí, no hacen otra cosa que llegar a un estado interminable. Si no priorizo, avanzo sin rumbo.

Modulo para Mantener

Mantener un sistema es complejo y más aún cuando el sistema es complicado, grande o simplemente tiene mucho tiempo de uso y nada mejor que dividir el problema, modularlo permite corregir y mejorar pequeñas partes de manera mas acotada y simple de mantener en el tiempo.

Registro para Optimizar

Es vital contar con métricas para entender cómo funciona y dónde convendría optimizar y no solo se trata del funcionamiento de la solución, registrar el progreso del desarrollo es vital para detectar y mejorar todo el proceso a futuro.

Automatizo para Delegar

Teniendo clara la tarea, el primer paso es automatizar, la premisa básica para delegar el conocimiento es contar al menos con un *script* que resuelva un problema de la manera mas automatizada posible, es decir una pieza de código limitada pero completamente funcional en resolver algo puntual a la `UNIX Way` ^5[6].

Documento para Independizar

Sin documentación básica nos atamos a nuestros desarrollos y no permite independizar a las personas que intentan usar eso que hicimos y terminamos gastando tiempo valioso en soporte técnico innecesario.

Libero para Visibilizar

De nada sirve contar con un programa muy *"monono"* que solo vive en mi `localhost`. Hace poco en *gcoop* ^6[7] me hicieron un *Merge Request* de algo que ya había resuelto, pero que ni siquiera hice el *commit* y el problemita estaba ahí latente, bastó que alguien más se topara con él para intentar resolverlo y compartirlo, por este motivo me recordaron *la ley de Linus* ^7[8], `Libera rápido, libera seguido`

Además de compartir soluciones a problemas, liberar sirve para visibilizar que se estuvo trabajando en resolver un problema o mejorar una solución, hacerla mas elegante y/o *"performante"*, pero por sobre todo sirve para tener un registro visible de a qué le estamos dedicando tiempo para no duplicar esfuerzos.

Creer vs Hacer vs Obtener

Entre la realidad y la percepción hay un abismo! No es fácil ser coherente, una cosa es *creer* que puedo solucionar algo, otra cosa es lo que puedo "hacer" para solucionarlo y finalmente muy distinto puede ser lo que "obtengo" como resultado.

Compartir es Bueno

Para contrarrestar estas incoherencias, nada mejor que `Compartir la solución`, aunque este incompleta y llena de errores, porque puede ser el punto de partida para una solución funcional con el aporte de alguien o de toda una comunidad!