2018-04-23

Modularidad



Siempre me gustó la palabra modular. 

La conocí en la facultad, cuando hablábamos de diseño y decíamos que una buena cualidad de un sistema era que fuera modular. En ese entonces David Parnas era la referencia obligada para el tema (algo así como el Mick Jagger del diseño de software) y hablábamos de cohesión, acoplamiento y otras cuestiones.

Hoy, con beneplácito, la encuentro como una característica deseada de los modelos operativos del futuro según el World Economic Forum, que dice:
"To meet market demands in the future, organizations will employ modular capabilities to support various business models. “Modular” is a characteristic that is defined as the ability to develop and deploy a business capability that can be utilized in a flexible, repeatable way across multiple business models with minimal re-design. This is a deliberate, “plug-and-play” approach that is distinctly different from previous eras in business that were focused on driving efficiencies through linear process design for a single business use case (e.g. business process re-engineering). Modular capabilities enable the organization to adapt quickly to market changes and more easily pivot their strategies and business models."
Esto es claramente otro ejemplo de cómo los conocimientos de ingeniería de software y en particular el diseño de software te sirven "para la vida misma".

Más allá del chiste, el futuro parece ser un lugar donde los arquitectos organizacionales tendrán un papel importante. Alguien deberá pensar seriamente en la forma organizacional y operativa que debe ir adoptando (o abandonando) la empresa a medida que los cambios en los gustos del cliente, las reglas de negocio y la tecnología se suceden. Los tiempos en los que estas cosas se definían cada 5 años terminaron.

¿Cómo se resuelven estas cosas en tu empresa? ¿Alguien siquiera las piensa?

Seguimos pensando..

2018-04-20

En gestión del tiempo la herramienta no es un fin sino un medio



Hace tiempo escribí sobre la sobreplanificación de nuestro tiempo personal. Recordé esto cuando, días atrás, tuve una conversación con un colega que me contaba los múltiples cambios de herramienta de gestión de tareas que había tenido en el último tiempo. 

Durante la conversación, no pude evitar pensar en la cantidad de energía que esa persona estaba gastando en pensar acerca de cómo hacer el trabajo, en lugar de sencillamente hacer el trabajo.

No en vano David Allen, en su método GTD, procura mantener la infraestructura de tareas en su mínima expresión. Al hacerlo busca minimizar el riesgo de enamorarse de la herramienta.

Debemos estar atentos a no dejar que nuestra herramienta de gestión de tareas nos domine y pase a ser nuestro principal tema de preocupación. La herramienta no es un fin sino un medio. Es algo que usamos para vaciar nuestra cabeza y poder vivir mejor el momento presente.

Seguimos pensando..

2018-04-18

"The single best predictor of whether employees would stay or leave is..."

Del libro Work Rules de Lazslo Bock (page 193):
"Manager quality was the single best predictor of whether employees would stay or leave, supporting the adage that people don't quit companies, they quit bad managers"
Seguimos pensando.. 

2018-04-16

6 antipatrones que atentan contra DevOps

Una forma interesante de entender por qué una organización tiene dificultades para implementar delivery continuo, testing continuo y, en última instancia, una cultura de DevOps más fluida, es fijarse en ciertos anti-patrones.

La idea es que en lugar de (o además de) focalizarse en aquellos patrones de trabajo que hay que implementar, nos enfoquemos (también) en esos patrones de trabajo que deberíamos romper.

A continuación listo seis anti-patrones muy comunes que deberíamos trabajar para romper, evitar o disminuir:
  1. Los ambientes de testing y producción son incongruentes.
  2. El testing demora mucho.
  3. El testing de regresión y de aceptación se hace en forma manual.
  4. Los lead times son largos.
  5. La deuda técnica es larga.
  6. Los cambios son costosos y lentos.

Si dedicamos parte de nuestro tiempo a romper con ciertas rutinas o comportamientos nocivos estaremos mejorando también el ciclo de vida de desarrollo. De hecho, posiblemente encontremos mucha sinergia entre implementar buenas prácticas y combatir las malas.

Seguimos pensando.. 

2018-04-13

Es cierto! "COOs Should Think Like Behavioral Economists"


Debo reconocer que el título del artículo me intrigó: Why COOs Should Think Like Behavioral Economists. ¿Por qué el COO debería pensar de esta forma? Pero la verdad es que el autor tiene razón. 

Parte de su trabajo es generar un ambiente donde los empleados puedan decidir mejor o sencillamente trabajar mejor. Perdón por la palabra que voy a usar pero el COO debe transformarse en el arquitecto del entorno de trabajo y la cultura de la organización

Podemos pensarlo también como una cuestión de supervivencia. Si la cultura y el entorno no ayudan, sólo nos quedan los paquetes de compensaciones como forma de atracción y/o retención de empleados.

Seguimos pensando..