Mini proyecto D3: Calendario laboral 2016

calendariojbr

Como parte de mi plan para tratar de hacer de 2016 un año mejor que los anteriores y basándome en la experiencia del año pasado he pensado que debería contar con un calendario completo, algo fácil de visualizar, fácil de tener a mano, con posibilidad de usarse a nivel de múltiples proyectos cortos y largos, que incluya información a nivel de mes y semana, etc.

Tras pensarlo, decidí que los calendarios tradicionales no eran adecuados, por lo que decidí buscar uno mejor. Al no encontrarlo, pero sabiendo que D3.js permite hacer uno a medida, decidí implementarlo basándome en algunos parecidos ya existentes. En realidad podría haberlo hecho en Excel, pero tengo otros planes en marcha que hacen deseable la opción de usar D3.js.

La forma en que estoy empezando a usar este calendario es en formato impreso para tener a mano y marcar hitos. De esta forma tengo facilidad para tenerlos a la vista, junto con días no laborables y otros eventos (jornada intensiva, etc.). También puedo llevar mejor control de a qué altura del año estamos dado el formato de fila con 7 columnas que tiene.

El usar la semana basada en lunes en la parte inferior facilita visualizar los fines de semana y los colores oscuros indican festivos, siendo los claros usados para marcar mi jornada intensiva o para resaltar los fines de semana.

En resumen creo que este calendario impreso puede resultar de ayuda para mantener a la vista el año completo y los diferentes hitos tanto a nivel de proyectos como de actividades recurrentes.

Para quien esté interesado en el código puede obtenerlo de mi repositorio de GitHub: Noradrex/D3Calendar

Para quien solo necesite una imagen que imprimir puede usar la que encabeza el artículo, aunque dada la personalización que tiene, recomendaría modificar los datos embebidos en el código y usar el calendario resultante. Es sencillo.

Por ultimo, si alguien tiene curiosidad por como lo estoy usando, este sería el aspecto de mi planificación en 4 categorías de todo el año, desenfocado para preservar cierta información. Haré más, pero es interesante lo mucho que me recuerda a una partitura.

WP_20160110_001

 

 

 

Anuncios

Productividad: Contexto y priorización de proyectos

Nota: tenía esto guardado desde 2013, pero por alguna razón olvidé que estaba en el cajón de “para publicar” hasta la limpieza de enero de 2016.

En mi carrera como desarrollador me he encontrado bastante a menudo, supongo que como todos, con una cantidad excesiva de proyectos sobre la mesa y por eso me gustaría comentar una estrategia para abordarlos que, sin ser mágica, me permite establecer un flujo de trabajo operativo.

Empezaré aclarando que pienso que la abundancia de proyectos es por un lado algo bueno, porque significa que voy a tener trabajo durante un tiempo (hola Crisis), pero por otro lado, resulta que me encargo de casi todas las funciones de cada proyecto por lo que soy yo quien debe organizar mi propio tiempo (al menos cuando me lo permiten) no solo entre proyectos sino entre tareas del proyecto… y rendir cuentas y plazos.

Así que ahí estoy, el equipo de un solo hombre, viviendo fuera de mi zona de confort (habilidades técnicas variadas VS sociales, de gestión, de comunicación, de diseño…), y tratando con una miríada de proyectos concurrentes. Y con todos estos cambios de sombrero, entorno, tecnología y negocio, sufro de manera crónica los cambios de contexto. Cambios que se cargan la productividad, claro.

Los cambios de contexto

Todo el que haya trabajado (de verdad) en varios proyectos a la vez, sabe que un cambio de contexto, supone “sacar” de la cabeza todo lo que tengas sobre una tarea X y llenarla con la tarea Z que quieras acometer. A mayor complejidad del proyecto, y a mayor número de elementos implicados (gente, documentación, herramientas, productos…), mayor es el tiempo empleado en cambiar de contexto, especialmente si además se trata de proyectos en áreas de negocio diferentes (cine, logística, auditoría legal, banca de inversión, marketing…). Algunos autores calculan una media de 20 minutos perdidos por cada interrupción en un trabajo intelectual que requiera concentración, pero personalmente creo que los cambios de contexto entre proyectos donde uno se encargue de casi todas las áreas, que además sean de áreas muy diferentes, y que impliquen un gran número de herramientas diversas, suelen ser mucho más pesados que una interrupción media, precisamente por las dimensiones de roles, ámbitos, conocimientos y entornos que se añaden al problema. Y todo esto sin entrar a comentar el desgaste intelectual de todo esto.

Estimemos por ejemplo 10 días para un proyecto corto, luego contemos que cambias de proyecto (por la razón que sea, no por capricho) 2 veces al día. Con esas cifras tan pequeñas es fácil calcular, siendo muy conservador y usando la media de 20 minutos, que acabaré acumulando (10 días x ((20 minutos x 2) / 60)) más de 6 horas de pérdidas. Un cálculo completamente ficticio y en bruto, pero que sirve para poner de manifiesto que los cambios de contexto tienen un coste que no se suele tener en cuenta, y que por tanto deben ser evitados en lo posible, si no queremos provocar una caída a plomo del trabajo efectivo realizado.

El método

Con esta idea en la cabeza, a lo largo de los años he desarrollado un flujo de trabajo que, si bien tiene sus propios problemas, sí me permite ser más productivo y reducir los cambios de contexto. Y lo que es más importante, lo hace sin que tenga que pensar o decidir demasiado.

El método es este:

  1. Trabajar únicamente en el proyecto que tenga la estimación de tiempo más corta e ignorar en lo posible los demás. A menos proyectos en marcha, menor es la probabilidad de tener que cambiar a uno, así que es mejor acabar los más cortos cuanto antes.
  2. Trabajo en el proyecto de los clientes que pagan. Si un cliente es de los que tardan en pagar, o de los que ponen pegas durante meses (no me meto en si con razón o no), su proyecto queda en cola. Esto se debe sobre todo a que un proyecto no cobrado, es un proyecto abierto, y el cliente que no paga tiene poder de imponer cambios no contemplados que alargan el proyecto de manera inesperada más allá del alcance inicial. Con esta regla, minimizo el impacto de los clientes/proyectos “malos”.
  3. Brown dispatching de tareas. Los proyectos más complejos (técnica u organizativamente, o en cualquier otro ámbito) suelen requerir de acción por parte del cliente o de terceros así que para evitar cambiar de tarea, ante una interrupción, trato ganar tiempo decidiendo lo más rápido posible si debo pasar la pelota a otra persona/responsable. Por ejemplo: si hay una incidencia en una aplicación, pido datos, pantallazos, etc; si me piden información, les mando al repositorio del proyecto a buscar (SharePoint es tu amigo); si me piden una reunión, les digo que mañana, que pongan ellos la hora. Y así con todo, bajo la premisa de evitar el cambio de tarea o postergarlo al mañana, cuando el cambio de contexto casa/trabajo es inevitable (hay que dormir) y el daño producido es menor, aunque no evitado.

Obviamente, estas técnicas tienen su propia problemática y en ocasiones no es factible utilizarlas, pero al menos ayudan a NO tomar decisiones y reducir los cambios de contexto, por lo que mejora la productividad y reduce el cansancio asociado a la toma de decisiones, que como sabemos, en el desarrollo de software es algo agotador.

 

Este año, sé un héroe

En 2012 no me decidí a publicar esto debido a su escasa longitud. Se trata de un texto que traduje de Philip Zimbardo acerca de las acciones heroicas en el contexto de su proyecto Heroic Imagination. De cómo podemos mejorar la sociedad.

Creo que el inicio de este año y dada la situación actual nacional y mundial, es un buen momento para recordarlo.

Una acción heróica es:

  1. Iniciada voluntariamente;
  2. Realizada en servicio de una o más personas o de la comunidad como conjunto;
  3. Involucra un riesgo al comfort físico, estatus social, o calidad de vida;
  4. Se inicia sin la expectativa de una ganancia material

Los heroes reactivos son personas que actuan en el momento, usualmente de manera espontánea. Tras lo cual, un heroe reactivo a menudo dirá algo como “no tuve tiempo de pensar, simplemente lo hice.”

Un heroe proactivo es alguien que realiza continuos esfuerzos a lo largo del tiempo para exponer operaciones de fraude, montajes, o corrupción. Tales heroes son más efectivos cuando forman redes con otros que comparten sus valores, atenuando por tanto las críticas (de defensores del sistema malvado) de que son fanáticos o están equivocados.

Texto original:

Heroic action is:

  1. Engaged in voluntarily;
  2. Conducted in service to one or more people or the community as a whole;
  3. Involving a risk to physical comfort, social stature, or quality of life; and
  4. Initiated without the expectation of material gain

Reactive heroes are people that act in the moment, usually spontaneously. Afterwards, a reactive hero will often say something like “I didn’t have time to think, I just did it.”

A proactive hero is someone that makes continual efforts over time to expose the operation of fraud, deception, or corruption. Such heroes are more effective when they form networks with others who share their values, thereby lessening the criticism (by defenders of the evil system) that they are fanatics or misguided.

Recopilación de tweets y citas interesantes

A continuación uno de mis habituales recopilatorios de citas y tweets interesantes recopilados de los meses anteriores.

Por alguna razón, las personas prestan más atención al precio que al valor. El precio es lo que se paga, pero el valor es lo que se obtiene a cambio.
-Warren Buffett

“It is more difficult to define what we want than what we do not want.”
-Russell Ackoff

Al hombre más torpe se le pueden explicar los temas más dificiles si no se ha formado todavía ninguna idea de ellos: pero no se puede aclarar ni aun lo más sencillo al hombre más inteligente si está firmemente convencido de que conoce ya, sin la menor sombra de duda, lo que se presenta ante él.
-LIEV TOLSTÓI, 1897

“Everyone wants to be a ‘designer’, but nobody wants to sew.” The fashion world is full of people who can draw or style but is exceptionally short of craftsmen who actually know how to sew, how to work with beading or leather, how to perform the detailed and highl skilled techniques associated with making haute couture gowns. For me, this signals something everybody knows about the modern educational system. It is preparing people for a white-collar world that no longer exists and has failed to provide people with the real-life skills that give rise to innovation in the real economy.
-@DrPippaM

Agile is like a machine gun instead a snipper. You can shoot a lot, but at a great expense.
Machine gun aproach. By taking so many shoots we may hit our target, but is incredible wastefull in the process.
Until you have data, you don’t know what the real problem is. You are just throwing solutions to the problem too early.
– Gabrielle Benefield

Frameworks, pereza y productividad

WP_20150706_012

 

Un framework es un marco de trabajo. Un conjunto de cosas (tecnologías, estándares, prácticas, ideas…) que nos ayudan a realizar un conjunto de trabajos sin tener que pensar todo de cero. Una framework es una herramienta para acelerar el trabajo y reducir la incertidumbre del resultado. Pero esa misma reducción de la incertidumbre es a costa de reducir la flexibilidad de las soluciones que ofrece.

Diferentes framework están orientados a diferentes tipos de problemas o clientes. O enfocan los problemas de diferente manera, o aprovechan mejoras en la tecnología (memorias más rápidas, procesadores más potentes…) para tratarlos de diferente manera.

Si lo comparásemos con un viaje, el framework es el viaje en crucero, donde no podemos quedarnos más tiempo del establecido en ninguno de los puertos, ni cambiar de destino, ni cambiar de camarote o volver a casa cuando queramos… a no ser que paguemos un alto coste.

La incertidumbre del resultado es insignificante, pero estamos en cierto modo atrapados.

Un framework es cualquier metodología como Scrum, o la gestión de proyectos del PMI. También pueden considerarse frameworks plataformas o productos como Oracle (la base de datos con todo tipo de funcionalidad) o el SharePoint de Microsoft sobre el que yo mismo trabajo.

En desarrollo de software un framework es algo como .NET o Angular, pero no una librería como JQuery. De ahí que JQuery se pueda usar dentro proyectos ASP.NET por ejemplo: una librería es muy flexible y ofrece una solución especializada que completa otros frameworks.

Quizá cuando el cliente no sabe lo que quiere y no está interesado en pensarlo demasiado es cuando más nos deberíamos ceñir a los frameworks, de modo que el cliente esté “obligado” a seguir un guion predefinido, uno que al fin y al cabo alguien sí ha estado pensando. En caso contrario, si permitimos que el cliente dé “bandazos”, podemos acabar con un proyecto a la deriva con mucha facilidad y terminar agotando todos los recursos disponibles sin llegar a un resultado satisfactorio.

Algunos clientes sin embargo, están perfectamente preparados para asumir esa deriva y no tienen miedo a invertir recursos en el viaje. A estos no les hace falta el framework (incluso puede que les perjudique), porque han decidido que no tienen miedo a explorar y a salirse de las rutas establecidas.

Por último existe un peligro en usar los frameworks sin entenderlos. Cuando trabajamos dentro de estos, debemos tener claros sus límites y las ideas que los sustentan, así como el problema que pretendamos resolver. Si no lo hacemos, si nos limitamos a usar el framework porque sí, lo más probable es que terminemos retorciéndolo y mutilándolo hasta destrozarlo, quizá resolviendo el problema del cliente en el proceso, pero sin duda generando decenas de problemas adicionales en el proceso, empleando mucho más esfuerzo del necesario y con un resultado incierto (lo he visto en varias ocasiones).

En estos casos de uso sin conocimiento real del marco de trabajo, su uso genera precisamente el efecto contrario que se buscaba: resultados inciertos, esfuerzo extraordinario y problemas adicionales.

En resumen, el uso de un framework o herramientas de terceros debe estar sujeto siempre que sea posible a una comprensión de los mismos (para qué sirve, como ataca el problema, etc.) y en mi opinión hay dos usos muy claros para estos, siendo el resto discutibles: a) equipos con experiencia que usan su propio framework o uno específico bien conocido para resolver más o menos los mismos problemas de forma recurrente o b) personas con poca o nula experiencia que necesitan un entorno que les guíe para poder ofrecer cierto rendimiento de desarrollo.

Límites en la gestión de proyectos de software

WP_20150709_032

Gestionar implica poner límites: límites a las horas trabajadas, limites a los recursos utilizados, límites al alcance del proyecto, límites a la responsabilidad de cada miembro del equipo, límites a lo que el cliente recibirá, cuando lo hará, etc.

Aunque las diferentes modas, escuelas o prácticas de desarrollo de software difieren en muchos aspectos, me parece interesante pensar en cómo se pueden categorizar, grosso modo, por aquello que limitan. De este modo tendríamos cuatro categorías:

  1. Límites a las tareas en curso, a la atención (KANBAN mediante el WIP).
  2. Límites al tiempo y recursos* empleados (SCRUM mediante los SPRINTS).
  3. Límites al alcance, tiempo y coste (gestión de proyectos clásica: on time, on spec, on budget).
  4. Límites a los recursos* (LEAN mediante la búsqueda de desperdicio).

*Nota: Con “recursos” pienso en personas, dinero y cualquier otro elemento que vayamos a emplear, para diferenciar del énfasis que pone la gestión clásica en los costes económicos, muy por encima de las personas.

Desde este punto de vista, es interesante observar como la gestión clásica trata de ser muy restrictiva y se enfoca en aspectos monetarios y alcances cerrados. Estas características, que funcionan bien y son necesarias en proyectos de construcción (edificios, barcos…), se convierten en una debilidad en el mundo del software, donde los mayores costes son los de personal y el alcance varía con facilidad. Porque el desarrollo de software es un proceso de diseño, no de construcción.

También es interesante observar como Scrum resulta más restrictivo que Kanban y Lean, por lo que podemos pensar a priori que es menos flexible y quizá menos adecuado para un proceso de diseño (software novedoso, entornos cambiantes) que Lean o Kanban. Esta flexibilidad reducida puede ser una ventaja en desarrollos poco novedosos y en cualquier caso es una mejora sobre la gestión clásica al centrarse más en personas y procesos.

Entender estas herramientas es vital para poder emplearlas con éxito. De otro modo caeremos en el cargo cult programming y sólo aparentaremos hacer desarrollo ágil de software, que es lo que temo que se produce en la mayoría de las organizaciones medianas y grandes: empresas con una inercia brutal en su cultura organizativa e incentivos, que tratan de sumarse al hype sin realizar un muy necesario cambio cultural. No puedo dejar de recomendar la lectura de Philip Zimbardo para entender los problemas sistémicos y Nassim Taleb para la gestión de riesgos y sistemas complejos.

Creo importante comentar que hay muchísimo hype desde hace unos años con todo el tema de ser ágiles, Scrum, etc. Por lo que recomendaría la lectura de un excelente artículo de la MSDN sobre todos ellos: The Lean of Scrum

En el artículo se comenta, entre otras muchas cosas, algo en lo que nunca se insiste lo suficiente: Scrum es un marco de trabajo, un conjunto de prácticas para poder desarrollar software de forma metódica. Lean es una filosofía de desarrollo, una forma de pensar y enfocar lo que hacemos. Kanban es una práctica o técnica para ayudar a optimizar un proceso.

Lo interesante del artículo de Microsoft es que permite contemplar cómo todas estas herramientas pueden tomarse por separado, mezclarse sin problemas o emplearse en diversos contextos, o con nuevas técnicas, filosofías y marcos  de trabajo para poder desarrollar software con éxito. O al menos con mejor probabilidad de éxito, al centrarnos en los elementos más críticos de los procesos de diseño, que lo que permite la gestión de proyectos clásica.

Centrarse en entender qué estamos haciendo, y sobre todo qué necesitamos en cada contexto, permite olvidarse del marketing, las formulas mágica (balas de plata, soluciones milagro) y realizar mejor nuestro trabajo.

Considero importante que los gestores de proyectos de software tengan experiencia real y fresca en el campo, porque gestionar un proyecto de software requiere entender qué estamos haciendo, qué limites debemos o podemos establecer y la naturaleza de lo que estamos haciendo. Sin ese conocimiento, basado en la experiencia, es improbable que hagamos algo diferente del cargo cult, y nuestras posibilidades de terminar un proyecto con éxito se reducen. Sin esos límites la “gestión de proyectos” se convierte en un mero drenaje de recursos, un viaje sin destino, en el que el único límite es cuantos recursos del proveedor pueden absorberse cada día, a ser posible 24/7.

Similitudes entre oficinas y campos de concentración nazis

 

Con el paso de los años he notado algunas similitudes entre oficinas de grandes empresas y los campos de concentración nazi. No creo que se deba tanto a una relación real, como a la necesidad de ser prácticos en muchos aspectos comunes de la gestión de grandes proyectos (la solución final, la implantación de redes de un país…). Sea como sea he confeccionado la siguiente lista exclusivamente por diversión, y obviamente no todos los puntos se cumplen en todas las empresas.

 

  1. Para sobrevivir se requiere proactividad.
  2. Los empleados/presos son marcados con números o algún código de identificación (tatuaje, tarjeta, correo impersonal).
  3. Para obtener elementos básicos (salas de reuniones, teléfonos, internet…) se requiere algún tipo de contrabando o trato con los responsables (guardias/directivos).
  4. Frases motivadoras en zonas visibles: “Be more”, “El trabajo os hará libres”.
  5. Complejos de oficinas con espacios abiertos interiores y grandes bloques en el perímetro.
  6. Mobiliario mínimo… mesas, sillas.
  7. Muchos controles de acceso seguridad (máquinas de rayos X, arcos detectores de metales, guardias, llaves…).
  8. Uniformes diferentes para diferentes roles (traje, sport, monos).
  9. El personal prescindible desaparece de un día para otro (equipos, personas, cámaras de gas).
  10. Los comedores son masivos y la gente se hacina en hora punta.
  11. Se dispone de sistemas informáticos muy caros para la gestión y la contabilidad (IBM, SAP).
  12. Montones de personas llegan y salen de ellas regularmente vía transportes masivos dedicados (convoy de trenes y camiones VS parada de Metro o autobuses dedicados).
  13. Las jornadas que se realizan tienden a ser mucho más largas de lo normal.
  14. Las personas que están allí provienen de diversos lugares geográficos (ciudades, países…) y de diversas organizaciones (ejércitos aliados, subcontratas).

 

Para saber más sobre el tema, pero en serio, puede buscarse “organización como cárcel” en cualquier buscador.