¿Quieres ser más productivo?... recuerda afilar la sierra (I)

En tiempos de "vacas gordas" las organizaciones tienden a sobredimensionarse. Los ingresos van como un tiro y la cuenta de resultados no se ve demasiado afectada por los gastos... necesitamos capacidad productiva que nos permita obtener más ingresos aunque esta capacidad productiva resulte cara o ineficiente...da igual, los ingresos están garantizados, los márgenes son grandes, las comisiones jugosas, todo el mundo está contento... ¿por qué preocuparse? En España ocurrió de forma exagerada en el sector de la construcción por lo que gran parte de una generación abandonó las aulas para incorporarse a un mercado laboral que ofrecía sueldos significativamente superiores que a titulados universitarios... El sector IT, por supuesto, también se subió al carro... había un tiempo en que "recién licenciado + 1 año de experiencia en el lenguaje X" era una pieza cotizada en el mercado laboral... y si me apuras... lo de "recién licenciado" era opcional...

El sueño se acabó, primero en nuestro sector cuando "descubrimos" (con el pinchazo de las punto-com) que la nueva economía no tenía nuevas reglas... que no existía fórmula secreta para evitar los ciclos económicos y que la cuenta de resultados tarde o temprano debe abandonar el rojo. Posteriormente se acabó el sueño para todos... de nuevo al "descubrir" que no existe ninguna regla económica que obligue al precio de la vivienda a crecer eternamente (tesis defendidas por reconocidas publicaciones de color salmón) e incluso pueden bajar.

Ahora los ingresos son moderados (por decir algo...), las tarifas se tiran por los suelos hasta el punto que en ocasiones da la sensación de que se ganan proyectos por el mero hecho de tener a la gente ocupada... En este contexto (ciñéndonos de nuevo a nuestro sector IT) parece tener mayor sentido lo que comentábamos en  ¿Restricciones en el demanda TI, de costes, de presupuesto? Tal vez te interese el pensamiento Lean. El término Lean Software Development  se acuñó en 1992,  ufff... en aquella época España estaba a punto de iniciar su "milagro español" como para preocuparnos de eficiencias, mejoras continuas y eliminación de desperdicios...¿verdad? Lo nuestro era el "dame más madera"...

Sin embargo, ahora resulta imprescindible preocuparnos de estos temas porque debemos mejorar nuestra productividad y de ahí que me viene a la memoria el libro de Stephen Covey, Los 7 hábitos de la gente altamente efectiva [1] que descubrí años atrás gracias a un proceso más que recomendable de Coaching. Los hábitos descritos por Covey son interesantes para cualquier situación pero vienen al pelo en épocas en que necesitamos que tanto nosotros individualmente como los equipos y organizaciones de los que formamos parte seamos los más productivos posibles.

Covey realiza la siguiente clasificación de los 7 hábitos:

PARTE PRIVADA

• Primer hábito: Se proactivo
• Segundo hábito: Empieza con un fin en mente
• Tercer hábito: Establece primero lo primero

PARTE PÚBLICA

• Cuarto hábito: Piensa en ganar/ganar
• Quinto hábito: Procura primero comprender y después ser comprendido
• Sexto hábito: La sinergia

RENOVACIÓN

• Séptimo hábito: Afila la sierra.

Aunque sea empezar la casa por el tejado únicamente me centraré en el último porque es el que hace posible al resto y además es más que suficiente (creo) para que puedas intuir qué hay detrás y si te interesa o no profundizar en el tema. Covey nos introduce el séptimo hábito a través la parábola del leñador y de ahí coge su nombre. Un visitante inesperado en medio del bosque se encuentra con un leñador:

—¿Qué está usted haciendo?
—¿No lo ve? Estoy cortando este árbol.
—¡Se le ve exhausto! ¿Cuánto tiempo hace que trabaja?
—Más de cinco horas, y estoy molido. Esto no es sencillo.
—¿Por qué no hace una pausa durante unos minutos y afila la sierra? Estoy seguro de que cortaría mucho más rápido.
—No tengo tiempo para afilar la sierra. Estoy demasiado ocupado aserrando.

Si sustituimos al leñador por España, al visitante por Alemania y recordamos nuestra filosofía de "más madera" durante el "milagro español"...creo que la parábola resume perfectamente nuestra situación. Lo malo es que, hasta el momento, las propuestas desde los diferentes gobiernos que nos intentan sacar de esta situación es básicamente la bajada de salarios y de beneficios sociales, con lo que se supone ganaremos la ansiada mejora de productividad... pero me temo que de afilar la sierra se habla poco. Curioso porque otros países como Estados Unidos o Inglaterra están considerando necesario incluir la tecnología y la programación como materia básica en las escuelas... hasta Obama hizo mención de ello en su último Discurso de la Nación.

Como no tenemos demasiada capacidad de decisión en esos niveles al menos intentemos desde el nuestro hacer todo lo posible por afilar la sierra. Tal vez tus decisiones sólo te afecten a ti (esta será tu mejor inversión) o a tu departamento o a tu empresa...pero la suma de cada pequeña mejora es lo que hace cambios importantes.

Detrás de afilar la sierra está por supuesto la formación, pero hay mucho más, como la administración eficiente de nuestro tiempo, aunque va más allá que el hecho de utilizar este o aquel método de planificación que aunque es necesario se queda muy en la superficie. Afilar la sierra te va a resultará más costoso que aplicar un método de gestión personal del tiempo,... de hecho considera que ya has trabajado en los seis principios anteriores y se enfoca en trabajar sobre las cuatro dimensiones de nuestra naturaleza: la física, la espiritual, la mental y la social/emocional. En el próximo post comentaremos cómo de relacionadas están estas cuatro dimensiones y qué hay detrás de cada una de ellas.


Referencias:
Stephen R. Covey, (2005). Los 7 Hábitos de la Gente Altamente Efectiva: La Revolucion Etica en la Vida Cotidiana y en la Empresa, Ediciones Paidos Ibérica.

KANBAN, el origen: The Goal (Theory of Constraint)

¿Por qué podría interesarle a un ingeniero de software leer una "novela" sobre organización industrial? Bueno, si estás interesado en la aplicación del método Kanban en el proceso de desarrollo de software es muy posible que te interese leer The Goal: A Process of Ongoing Improvement  (Theory of Constraint) de E. Goldratt [1] puesto que fue la Teoría de Restricciones la que llevó a David J. Anderson a aplicar una primera aproximación de Kanban en un equipo de desarrollo en Microsoft. De hecho, en From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department no encontrarás ninguna referencia a Kanban puesto que se trata de la aplicación de Theory of Constraints (TOC). Después de esta publicación, Donald Reinertsen hizo ver a Anderson que su adaptación de TOC se ajustaba al método Kanban por lo que Anderson continuó utilizando Kanban en lugar de TOC, entre otras razones porque es un método asociado a la filosofía Lean (más de moda en estos momento). En cualquier caso, ambos métodos tienen muchos puntos de unión y una visión común: la mejora continua o Kaizen (que lo llaman los japoneses).

Alguna razón para "invertir" el tiempo en su lectura:

• El libro fue editado en 1984 por lo que está a punto de cumplir 30 años. Si pasado tanto tiempo continúa editándose y se ha aplicado en empresas de la talla de General Motors o Microsoft... algo debe tener.
• Trata muy diversos e interesantes temas como las competencias de un buen gestor, la influencia de la presión profesional en la vida personal , las relaciones laborales, gestión del cambio, innovación, el método Socrático... y por supuesto mucho de Teoría de Restricciones... Hmmm, de software lo único que menciona es su incapacidad para localizar los cuellos de botella...
• Si tienes algún interés profesional o vocacional en la formación o divulgación de conocimiento The Goal  es todo un ejemplo de didáctica. Es capaz de introducirte, por ejemplo, en la relación que tienen los eventos dependientes y las fluctuaciones estadísticas en el rendimiento de una planta industrial, de tal forma que te acaba por resultar hasta interesante. La combinación del método Socrático con el formato novela es la clave para conseguir que aquellos que no estamos interesados en la reorganización industrial nos resulte interesante el libro y encontremos nuevas formas de aplicación de sus principios...es una buena forma de transferir conocimientos y de hecho me recuerda por un lado los Cibercuentos de @jgarzas, (este es un ejemplo), y el prólogo que escribe @jmbeas en Deseño Ágil con TDD de Carlos Blé. Es curioso que la gente que probablemente tiene más que decir es capaz de simplificarlo de forma que todo el mundo lo entienda.

Ahora bien, como el tiempo es escaso y los recursos de lectura prácticamente ilimitados te diría que yo no leería el libro:

• Si lo que te interesa es conocer por encima qué hay detrás de alguna palabra de moda como Lean o Kanban. Para eso te aconsejo "googlear" un poco. Existen suficientes recursos Online en castellano como para hacerte una idea. 
• Si quieres profundizar un poco más y te estás planteando si esta u otra práctica puede resultarte interesante...te aconsejo que te hagas con un ejemplar de Gestión Ágil de Proyectos Software [2]. Aquí encontrarás toda esta información procesada y ordenada. Es un buen punto de partida si tu equipo/departamento necesita un cambio pero todavía no estás seguro del camino a seguir. 
• Si te estás planteando la aplicación de Kanban al desarrollo de software te aconsejo que primero leas [3] y [4] y luego, si te interesa, profundices en The Goal. 
• Si nada de lo anterior te interesa deja aquí este post (es algo extenso) y salta a otra lectura que seguro las encontrarás más interesantes...

Estas son algunas de las reflexiones que te puedo dejar de su lectura:

• La importancia de las métricas. El libro continuamente refleja la necesidad de tomar medidas a lo largo de toda la cadena productiva, tanto en tiempos de procesado como en calidad del producto; hay que tener en cuenta que sin una referencia clara de "donde estamos" en muy difícil decidir si aplicando determinadas medidas mejoramos. Las métricas no les gusta a nadie (tampoco en el entorno industrial) pero son imprescindibles. En el mundo del software me temo que acostumbramos a situarnos en uno de los extremos: Un gran número de proyectos no mide ni el rendimiento del proceso ni la calidad del producto, pero cuando nos planteamos la necesidad de las métricas, dado que tenemos una gran facilidad para generar/manejar datos (es lo nuestro, claro) nos solemos pasar de largo y empezamos a medir a discreción. Si actualmente no utilizas ninguna métrica, deberías plantear unas pocas interesantes (en Kanban las básicas son LeadTime y CycleTime)... el ratio de errores, el acoplamiento de clases, la complejidad ciclomática, la profundidad de herencia, las adecuación a normas de programación, están muy bien, pero deberías introducirlas poco a poco...y sobre todo después de plantearte por qué tiene importancia determinada métrica en el contexto de un proyecto concreto.
• Debe de existir más de una docena de referencias al sentido común en el libro, para acabar concluyendo que "el sentido común no es tan común"... Y lo cierto es que The Goal basa la mayor parte de su plan de mejora en tomar decisiones de "sentido común" a simple vista nada excepcionales. Por otra parte, como finalmente acabó recalcando Anderson en [3] no se necesita de mentes prodigiosas ni de disponer de los mejores técnicos del mundo (que no digo yo que esté mal...en cualquier caso no te costará encontrarlos, el 80% de la gente se considera más inteligente que la media...), sino que la mayor parte de las mejoras introducidas es fruto de aplicar medidas de sentido común que habitualmente no se aprecian porque chocan con la cultura preestablecida, por lo que al sentido común yo añadiría valentía para cambiar la forma habitual de hacer las cosas.
• Respecto a la innovación y el rechazo al cambio muestra la dificultad que presentan determinadas organizaciones para introducir un cambio de pensamiento incluso en situaciones críticas como la descrita en The Goal. La novela trata este rechazo al cambio dejando patente que es capaz incluso de llevar a la quiebra a una empresa. De hecho, el "no tener nada que perder" es lo que en este caso finalmente impulsó el cambio. Si hubiera existido alguna posibilidad de salvar la situación con las normas preestablecidas probablemente no se habrían tomado las medidas que mejoraron el rendimiento de la planta de producción que finalmente salvó el resto de la división. Esta idea es el eje central de El Dilema de los Innovadores [5] donde puedes encontrar documentados casos concretos de agentes dominantes de un mercado que acaban desapareciendo ante su incapacidad de adaptación a determinadas innovaciones. Se detallan dos casos en sectores muy diferentes: las maquinarias de perforación con la aparición de los cilindros hidráulicos en sustitución de las poleas y las empresas tecnológicas de fabricación de dispositivos de almacenamiento (discos duros) con su necesidad continua de duplicación de capacidad. 
• En la cadena de producción la reducción del tamaño de los lotes repercute en una reducción del inventario en los buffers intermedios, disminuyendo, por tanto, el tiempo perdido en estos buffers a la espera de capacidad productiva, lo que deriva en una condensación del LeadTime (tiempo transcurrido desde la aceptación del pedido hasta la entrega). Lo anterior tiene un punto débil: implica "perder" más tiempo en configuración de la maquinaria... pero si estas máquinas no son cuellos de botella del proceso, el rendimiento global no se ve penalizado.  Ufff, complicado analizarlo en un párrafo... pero resumiendo mucho, la idea es que cuanto menores sean nuestros trabajos (tareas de desarrollo) menos tiempos de ingeniería (obviamente) y de espera a que alguien pueda hacerse cargo de ellos, por lo que el tiempo de ciclo disminuye.
  En líneas generales los trabajos en nuestros procesos de desarrollo consumen tiempo en:

• Actividades de ingeniería (análisis, diseño, construcción,...).
• Configuración del entorno.
• Tiempo de espera para iniciar el trabajo en una determinada actividad de ingeniería.
• Tiempo en espera de otras partes (en el caso de trabajos más grandes: temas o epopeyas).


Si los trabajos son muy grandes desperdiciaremos tiempo principalmente en los dos últimos puntos. 

El problema es que disminuyendo el tamaño aumentamos el tiempo de configuración (puesto que tendremos que preparar el entorno más veces). En el mundo industrial este tiempo se pierde configurando la maquinaria para que comience a trabajar con una pieza concreta pero en desarrollo de software se pierde en, por ejemplo, configuración del entorno y escenarios de pruebas... de aquí la  necesidad de automatización de las pruebas y del proceso de despliegue.

• Otro tema interesante es el tiempo "ocioso". The Goal muestra la dificultad de hacer entender a la dirección que el hecho de parar una maquinaria (y sus operarios) en intervalos concretos sea rentable a la empresa. El "sentido común" decía que para amortizarlas, esta máquinas debían trabajar al 100% de su capacidad. En realidad esto generaba inventario innecesario en los buffers intermedios ¿recuerdas el efecto en el tiempo de ciclo? Goldratt concluye que tener a maquinaria y personal parados bajo determinadas circunstancias resulta rentable...
  Hmmm, un poco duro de aplicar al mundo del software, ¿verdad? Pues bien, te recomiendo el artículo Scaling Agile @ Spotify donde explican cómo gestionan ellos estos "tiempos ociosos". Te lo resumo: todo el mundo dispone de un 10% de su tiempo para dedicarse a actividades que consideran interesantes pero no directamente asociadas a compromisos de sus proyectos. Generalmente suelen agrupar ese 10% y cada dos semanas disponen de un "hack day" (algo así como un "día de escaqueo en el trabajo"). Se podría argumentar que estos "hack days" no tienen el mismo objetivo que en The Goal, de hecho en la planta industrial pretendían eliminar inventario intermedio mientras que en Spotify buscan generar innovación, pero en ambos entornos resulta rentable que los recursos no trabajen siempre al 100%. La aproximación de Anderson (y la mía personal) es aprovechar los tiempos de bloqueos producidos por los WIP del tablero Kanban para generar estos espacios de innovación, de esta forma no existe tanta tensión cuando una persona del equipo no puede coger ningún trabajo puesto que puede dedicar ese tiempo a asuntos de interés general no asociados a proyectos concretos. Reconozco que me sigue gustando más la idea de los "hack day" pero... no todos trabajamos en Spotify...

Aquí lo dejo, pero ten en cuenta que está todo muy destilado, si te resulta interesante en The Goal encontrarás otros asuntos que por extensión no he querido tratar como el concepto de contabilidad de costes, la definición de trabajo finalizado, la inercia del proceso de mejora, la aplicación de TOC a actividades "no materiales" como la gestión, el flujo continuo y regular,...

Referencias:
[1] Goldratt, E. y Cox, J. (2012). THE GOAL: A Process of Ongoing Improvement (Third Revised Edition), North River Pr.
[2] Garzás, J., Salamanca, J.A., e Irrazábal, E. (2012). Gestión Ágil de Proyectos Software, Kybele Consulting.
[3] Anderson, David J., y Dumitriu, D. (2005). From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department. Proceedings of the TOC-ICO World Conference, Barcelona.
[4] Anderson, David J. (2010) Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press.
[5] Christensen, C.M. (2000). El Dilema de los innovadores, Granica.