OSiUX Work In Progress Flow

· osiux's blog

.org | .md | .gmi | .html

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 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:

```

```

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, AutoFocus 3, SCRUM 4, 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:

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.

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 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, 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!

WiP #

18 meses después que comencé este post hoy termino de esbozarlo aunque no deja de ser un Work in Progress, aunque incompleto me completa <3

ChangeLog #

  1. https://osiux.com/2021-02-26-30-dias-de-posts-por-la-birra.html ↩︎

  2. https://osiux.com/gtd-gething-this-done.html ↩︎

  3. http://markforster.squarespace.com/spanish/ ↩︎

  4. https://proyectosagiles.org/que-es-scrum/ ↩︎

  5. https://es.wikipedia.org/wiki/Filosofía_de_Unix ↩︎

  6. https://www.gcoop.coop/ ↩︎

  7. https://es.wikipedia.org/wiki/Ley_de_Linus ↩︎