Archivo de la categoría: Productividad

Optimiza el uso de tu memoria (mental)

¿Cuantas cosas sabes hacer a la vez? ¿y hacerlas realmente bien? ¿Y además en un tiempo aceptable? Antes de responder a estas preguntas, me gustaría que conocieras cómo funciona nuestra mente.

El cerebro está compuesto de bloques de memoria de cortisimo plazo o de trabajo, de corto plazo y de largo plazo. Cuando realizamos un trabajo utilizamos una combinación de todos estos bloques a la vez. Por ejemplo, un desarrollador de software necesita tener en la mente el lenguaje de programación a usar, el diagrama conceptual del proyecto que está modificando, el objetivo de la funcionalidad que está desarrollando y en la zona de cortísimo plazo el algoritmo que se está escribiendo en ese momento. Un ingeniero de soporte puede tener el sistema del cliente, los detalles del problema en cuestión y el producto del cual está dando soporte. Un comercial puede tener detalles del producto que vende y detalles del cliente al que quiere vender.

Bloques de memoria de un desarrollador concentrado
Bloques de memoria de un desarrollador concentrado

Contínuamente tenemos que reemplazar estos bloques. Esto puede ser  por una interrupción que provoca un cambio de contexto y necesitas modificar tu memoria de más corto plazo. Pero también puede ser cuando cambias a desarrollar otro programa, otra historia de usuario u otra funcionalidad, incluso por un cambio de lenguaje de programación. Cada cambio requiere que uno o más bloques de memoria se reemplacen. Y ese reemplazo tarda tiempo. Si es memoria a corto plazo puede tardar incluso más de 15 minutos pero si es memoria de medio plazo como el lenguaje de programación se puede tardar días en sustituirlo completamente.

Cambio de tarea en otro lenguaje de programación
Cambio de tarea en otro lenguaje de programación

Hasta que un bloque es completamente sustituido, el bloque tiene una mezcla de distintos contenidos. Es el momento en el cual se toman decisiones incorrectas y se cometen fallos. Es cuando lo justificamos a que no estamos completamente concentrado y se producen frustraciones.

Para tomar mejores decisiones, realizar un trabajo de mejor calidad y más rápido hay que reducir el WIP. WIP significa trabajo en curso (Work In Progress) y hay que intentar que como máximo se tenga una tarea en la cabeza,  o una característica nueva a la vez por equipo, o una incidencia de soporte a la vez. Ya existen herramientas como Kanban, GTD y la Técnica Pomodoro para ayudarte a enfocarte en una tarea o con un mínimo de trabajo a la vez. Pero ninguna de estas técnicas ayuda a decidir con qué tareas ponerse o qué trabajo empezar una vez se ha terminado para minimizar el reemplazo de la memoria de trabajo.

Para ello propongo hacer una lista de los 5  elementos que más se tienen en cuenta a la hora de realizar una tarea . En el ejemplo del desarrollador de sofware, haríamos esta lista:

  • El tipo de tarea a hacer: desarrollo, administrativo (emails, imputar,…) , test, formación…
  • El lenguaje de desarrollo a usar
  • La estructura del programa a modificar
  • El framework o API que se usa: ASPNET MVC, Backbone, Angular,…
  • Las características del cliente que usará la funcionalidad

Para cada característica distinta a la de la tarea que se ha terminado se suma un punto. Si hacemos un tipo de tarea completamente distinta tendríamos 5 puntos porque seguramente necesita reemplazar todos los bloques de memoria. Si es del mismo programa pero hay que cambiar de lenguaje es un punto por el cambio de lenguaje y seguramente otro por el cambio de framework llegando a 2 puntos. Cada vez que se elige una nueva tarea hay que evaluar los puntos de lo que podemos empezar dentro de las que tengan igual prioridad. Idealmente se elegirá una tarea del mismo lenguajes, del mismo programa, con el mismo framework y para el mismo cliente. De este modo reducimos el número de bloques de memoria a reemplazar consiguiendo un resultado con mejor calidad, en menor tiempo y sin frustraciones.

 

Cómo el stress afecta a la calidad del software

El uso de las metodologías ágiles en el desarrollo de software ha supuesto un antes y un después en relación a la calidad de los productos. Webs, aplicaciones, juegos, son cada vez más elaborados, imaginativos y más seguros.

Uno de los principios ágiles habla de ritmo sostenible (sustainable pace). La interpretación más aceptada es la de jornadas de trabajo de 40 horas semanales. Está más que demostrado empíricamente que las horas extras en desarrollo de software está linealmente relacionado con un incremento en los bugs cometidos.

Bien, pues aquí tenemos la razón.  La culpa la tiene el stress.

El stress envía hormonas a la sangre para preparar al cuerpo y la mente para la situación amenazante. Durante miles de años, para los humanos, las situaciones amenazantes tenían que ver con peligros físicos de animales depredadores, posibles accidentes o peleas entre tribus y estas sustancias preparaban al cuerpo para afrontarlas. Sin embargo en la época de la información y para trabajadores del conocimiento tienen precisamente el efecto contrario.

Estas dos simpáticas hormonas son la famosa adrenalina, que produce un incremento en el ritmo cardíaco, la presión de sangre y la respiración; y glucocorticoides como el cortisol. Bueno, pues estos últimos producen entre otros, unos efectos muy perjudiciales a la memoria de corto plazo y la memoria de trabajo.

La memoria de trabajo es la parte del cerebro en la que almacena los datos que tenemos que combinar, comparar y analizar para resolver los problemas. Nuestra memoria RAM. Tipicamente un cerebro  normal mantiene y trabaja con 7+-2 chunks o bloques de datos simultáneamente para resolver los problemas. Los glucocorticoides reducen este número por lo que la mente se ve limitada a trabajar con menos datos y menos alternativas para intentar resolver ese diseño o ese código que hay que hacer que funcione.

Los militares han hecho muchos estudios relacionados con la reacción de las personas en situaciones de stress (ver referencias). En un estudio se demostró que el stress tenía el efecto positivo de reducir el tiempo de reacción, sin embargo esto tenía el efecto colateral de crear un mayor número de falsas alarmas y errores que las surgidas en condiciones de tranquilidad. Es decir, estresados fallamos más que una escopeta de feria. Mantenemos nuestra atención en la parte negativa del problema para intentar resolverla lo cual nos impide mirarlo desde fuera, afrontarlo lateralmente para poder ver otros ángulos y encontrar mejores soluciones.

En otro estudio se demostró que las personas, en situaciones de stress experimentamos una percepción superficial de la realidad, poniendo nuestra atención sólo a una pequeña parcela del problema a la hora de tomar una decisión o encontrar una solución. En este estado de alta tensión tomamos decisiones basadas en un conjunto incompleto de información y tomamos atajos basados en experiencias pasadas.

En resumen, tenemos que un desarrollador o u trabajador en general cuando está estresado reduce  su memoria de trabajo, no es capaz de tener visión lateral y creativa y toma atajos para resolver el problema lo más rápidamente posible sin pensar en más allá que el alcance de su problema… Conseguimos al DESARROLLADOR BOMBA. Preparaos para bugs por doquier, deuda técnica acumulandose, software de baja calidad y clientes decepcionados.

Todo esto se puede evitar manteniendo el ritmo de trabajo a un ritmo mantenible. Respetando la capacidad del departamento de desarrollo mediante sistema PULL con Kanban o de compromiso de equipo en el  sprint de Scrum. Respetando la definición de DONE sin saltarse por la presión y manteniendo un ambiente de trabajo animado y relajado. Todo esto no debe ser un lujo, sino un requerimiento.

 

 

 

 

 

 

 

 

 

 

Referencias

 

http://en.wikipedia.org/wiki/Effects_of_stress_on_memory

http://en.wikipedia.org/wiki/Short-term_memory

http://en.wikipedia.org/wiki/Working_memory

http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two

Haz clic para acceder a StressAndPerformance.pdf

http://www.researchgate.net/publication/259781769_Impact_of_Overtime_and_Stress_on_Software_Quality

Antipatrón, midiendo el esfuerzo

<ironic>

Es muy dificil encontrar una métrica que evalúe el rendimiento de los miembros del equipo por separado. Cualquier libro moderno de gestión de personas recomienda evaluar al equipo globalmente pero nosotros, los buenos jefes de equipo, tenemos que recompensar a los que se están dejando el pellejo y localizar a los que no tienen suficiente compromiso con el proyecto.

Una cosa que hacemos bien en España, y por eso somos de los países más competitivos, es nuestra orientación al esfuerzo. Si no dedicamos mil horas diarias a algo y nos dejamos hasta la ultima gota de energía de nuestro cuerpo, un trabajo no está bien hecho. Otros países «más modernos» prefieren buscar formas de hacer el trabajo más comodamente… ¡Nenazas!

El esfuerzo es algo muy dificil de medir. Lamentablemente, las leyes de privacidad nos impiden usar electrocardiogramas en los trabajadores. Con ellas podríamos obtener de manera muy fiable el ritmo de trabajo de cada uno.

Afortunadamente hay otras formas más legales:

Medidor de sudor. Es una sencilla banda adhesiva que se pone en la frente de los trabajadores. Esta banda tiene un pequeño chip y un emisor bluetooth. La banda obtiene el nivel de sudoración en tiempo real y lo envía al servidor central. Cada día los trabajadores tienen que cambiar la banda adhesiva ya que queda (debería quedar) llena de sudor. Es importante tener consumibles  disponibles para que no haya trabajador sin banda. El único problema es que  cada persona sudora de manera distinta y el dispositivo es difícil de calibrar.

Medidor de sudor
Medidor de sudor

Dinamómetro de nalgas. Este es el más fiable  Es un sencillo dispositivo que se coloca entre las nalgas de cada trabajador. Mide la presión ejercida durante el trabajo por su parte trasera y se envía igualmente por bluetooth. A más presión recibida, mayor esfuerzo es el que está efectuando el trabajador. El dinamómetro es personal y cada trabajador debe ser responsable de su limpieza diaria.

Dinamometro de nalgas
Dinamometro de nalgas

Los datos recibidos del esfuerzo son monitorizados en tiempo real. De este modo, nosotros como jefes podemos alentar o castigar a esos trabajadores que no tienen los valores esperados. Se puede definir un máximo y mínimo para que el sistema genere una alarma en tiempo real. Todos los valores son almacenados por un servidor y pueden servir para una recompensa en retribución variable o ascensos. Igualmente, si los datos no son buenos, si por ejemplo no ha ocurrido ninguna presión de nalgas en un mes, con estos datos se dispone de una herramienta objetiva para un despido.

Naturalmente usando este sistema hay que evitar cualquier cambio que suponga una reducción en el esfuerzo. Iría en contra de nuestra política de recompensar el esfuerzo. Las metodologías ágiles son totalmente contraproducentes ya que se ha demostrado que su uso continuado puede bajar el nivel de esfuerzo global. Hay que evitarlas a toda costa.

</ironic>

Índice de emparramiento y problemas del multitasking

La sociedad de la información nos inunda con información desde todos los lados. Notificaciones de mensajes por whatsapp, actividad de tweeter, etiquetados en facebook, emails que llegan, artículos nuevos al blog que estas suscrito. Estamos acostumbrados a hacer como mínimo dos cosas a la vez, vemos la tele mientras navegamos, vemos las redes sociales mientras estamos en el trono, trabajamos con dos monitores para estar atento  a los emails mientras se está programando o escribiendo algún documento…

Estamos acostumbrados a trabajar en multitarea (o multitasking en inglés). Alardeamos de que podemos resolver varias incidencias o problemas a la vez. Sin embargo acostumbrarse a la multitarea tiene su lado negativo, no llegamos a establecer concentración plena en ninguna de las tareas que tenemos delante. El tener capacidad de multitasking nos permite cambiar de una a otra sin problemas pero no llegamos a usar nuestro pleno potencial en ninguna de ellas.

El multitasking no sólo afecta al trabajo. El navegar mentalmente de un tema a otro nos hace vivir el día a día en modo automático mientras pensamos en cómo resolver ese problema del trabajo, en que hay que llevar el coche al taller,  en que queda poco dinero en la cuenta, que la próxima semana hay que ir a la reunión del niño, las cosas que quieres hacer el siguiente mes, etc, etc, etc y… etc.

Yo soy una víctima de ello. Pensaba que mi navegación mental era una aptitud que me permitía encontrar soluciones a las que nadie más llegaba. Esto hasta que me di cuenta que había perdido el control del timón. Esta perdida de concentración estaba afectando a mi trabajo y a mi vida fuera de él.

Leyendo este hallazgo sobre «The Effects of Mindfulness Meditation Training on Multitasking in a
High-Stress Information Environment» encontré este test. Te mide el índice de atención plena que sería lo contrario al índice de emparramiento, que es la capacidad de «estar en la parra», con la mente en otro lado distinto al presente.

Sólo ver el test, si eres de los mios, te sentirás identificado. Tranquilo, parece que hay solución al problema. Se llama Mindfulness. Es un modo de meditación en la que solamente hay que centrarse en la respiración o en las sensaciones del propio cuerpo. Solamente existe el presente y uno mismo. Cualquier pensamiento ajeno hay que descartarlo y volver al presente. Iré contando resultados.

¿Está TDD muerto? Resumen del videodebate

Mientras hacen subtitulos para el Hangout entre David Heinemeier Hansson, Kent Beck y Martin Fowler, voy a escribir un poco lo que han hablado para que los que no entiendan el inglés, o no tienen los 30 minutos para verlo entero, puedan quedarse con las claves. En mi anterior artículo hablo de los artículos y tweets que empezaron la discusión.

El link al video es éste.

Empieza David hablando de los 3 problemas que ve al TDD: la insistencia en que los tests tienen que correr en milisegundos, que termina creando un diseño feo y complejo y que el bucle de rojo-verde-refactor es poco natural para el programador.

Kent cuenta que el TDD le da la confianza que necesita a la hora de dar un desarrollo por completado y funcionando. Sin TDD, uno se va a casa sin la seguridad de que el código que ha escrito funcione bien. Además le ayuda a pensar primero en el problema. Cuando no se tienen especificaciones concretas TDD sirve para empezar de lo más concreto (ejemplos en los tests) a la implementación más genérica.

David entiende en que Kent piense en la seguridad como un factor de felicidad del programador. Él mismo dice que le da prioridad a la felicidad del programador cuando empezó Ruby on Rails. Sin embargo, la seguridad de que todo va a funcionar es sólo un factor de felicidad del programador pero hay otros. El tener que cambiar el flujo de pensamiento a pensar primero el test antes de empezar lo ve como una forma de confundir al programador y no dejarle crear del modo que le es más natural. Además dice que la seguridad de que el código funciona no debería venir unicamente del TDD

Ante un ejemplo reciente de Kent sobre un uso idoneo del TDD, David responde que en los desarrollos que él hace no es normal tener un código tan aislado como el que Kent comenta. Que para poder conseguir un codigo perfecto testeable típico de un input consigue un output tiene que separar capas y capas y crear muchos mocks. Que tiene que hacer un gran sacrificio para conseguir ese código perfecto para TDD.

Kent afirma que en todo esto tiene que haber un balance. Hay que tener en cuenta el coste de aislarlo todo para testearlo de manera independiente y su beneficio. Que no hace falta hacer mocks de todo. Si tienes unos tests de objetos que usan otros objetos reales o un sistema real y se es capaz de tener así la prueba de si va o no va, es suficiente. Cuenta que mucha gente se queja de que el Unit Test no le deja refactorizar. Esto ocurre porque sus tests complejos que tienen mocks que devuelven mocks y como fruto estos tests están muy acoplados a la implementación.

Segun David, el problema está en la definicion de TDD segun algunos sectores del desarrollo. Estos sectores afirman cosas como que cualquier test tiene que estar basado en mocks y que si no usas TDD no eres buen profesional. Incluso que si el diseño del programa no está dirigido por tests, no es buen diseño. Para David es al contrario, TDD fuerza a tener un diseño no natural.

Martin Fowler, quedandose un poco en medio y actuando un poco como arbitro del debate, también dando su opinión más pragmática. Dice que hay en la calle muchas definiciones de TDD. Algunas de ellas dicen que todo tiene que estar con mocks. Sin embargo la realidad es que si no usa mocks y el test es util, perfecto. Dice que el TDD y el Unit test son dos cosas aisladas y hay que tratarlas como tal. Se puede hacer TDD sin que todo el codigo testeado esté aislado. Para él, como ya dijo en su artículo, lo importante es que el código sea autotesteable, que haya un botón que pueda probar todo el código. TDD está bien porque ofrece esto como uno de sus beneficios.  Está de acuerdo en que en ocasiones no se puede usar TDD, cosa que le apena ya que dice que es una herramienta que le gusta. También opina que incluso hay que separar conceptualmente el Unit testing aislado y el no aislado.

El debate termina barajando un posible futuro debate hablando unicamente de si el TDD crea un buen diseño o no.

 

 

 

Motores, lastres y minas en retrospectivas

¿Cuánto tiempo tardas en ir de casa al trabajo? Normalmente ese tiempo varía un poco cada día. Por ejemplo un día tardas 20 minutos, otro 23, otro 19, 20,… Esa variación de tiempo que ya tienes asumida se llama «Variación de causa común«. Ahora piensa en la última vez que llegaste tarde. Pudo ser por un problema de tráfico, tu hijo estaba enfermo y hubo que llevarlo a casa de la abuela… Esa vez tardaste 40 minutos. Ese tipo de variación se llama «Variación de causa asignable«. Es asignable porque puedes asignarle una razón (o una excusa).

En VSN trabajamos desde hace unos meses  la retrospectiva con la analogía de la lancha. El equipo es una lancha en la que los motores representan aquellas cosas que nos hacen ir rápidos y con calidad.  Los lastres atados son las cosas que nos hacen ir más lentos. Desde hoy tenemos un elemento nuevo. Ahora identificamos también las minas con las que se encuentra esta lancha por el camino. Estas minas representan esos problemas de causa asignable, esos problemas ocasionales que han ocurrido y pueden volver a ocurrir, o no.

20140411_145919_pq

Cuando trabajamos estas retrospectivas, el equipo escribe en los Post-It amarillos los elementos a destacar del sprint: los motores, los lastres y ahora las minas. Una vez están todas las etiquetas en la pizarra las organizamos juntando las comunes y las analizamos. Primero buscamos soluciones para los lastres, después confirmamos que los motores que tenemos siguen siendo útiles y debemos seguir usandolos y por último analizamos las minas para ver cómo actuar cuando nos las volvamos a encontrar.

Primero indicamos la posibilidad de encontrarnosla. Podría ser eventual, esto quiere decir que el problema ha ocurrido y ya está, que es raro que vuelva a ocurrir.Podría ser frecuente, una vez cada sprint o cada pocos sprints. Si es un problema constante lo más normal es que se encuentre en la parte de lastres.  Despues recordamos el efecto que ha causado en el equipo. En qué nos ha afectado. Ha sido una molestia o ha sido un gran trauma. Por último definimos el plan de defensa, qué hacer con la mina la próxima vez que nos la encontremos. Aquí tenemos 3 opciones:

  1. Preparar contramedida para destruir la mina la próxima vez. Se piensa cómo eliminar el riesgo para que no vuelva a afectar lo más mínimo al equipo.
  2. Mitigar el daño cuando ocurra el choque. Podría ser que lo mejor es que cuando el problema ocurra de nuevo estar preparado para que afecte lo menos posible.
  3. Ignorar la mina. Cerrar los ojos, apretar el culo y sencillamente aceptarla tal cual llega. Esto se decide así cuando las consecuencias de tener un plan de acción podrían sobrepasan el efecto de la propia mina.

Los planes que se hacen con las minas las vamos a recoger en un documento accesible por todo el equipo. Cuando en un análisis de sprint, de historia o en algún Daily asome la sospecha de que se nos acerca una mina conocida, sabremos cómo actuar. Con esta sencilla analogía de las minas vamos a tener  lo que se llama en gestión de proyectos tradicional, Gestión de Riesgos. Sin embargo lo hacemos de una manera Ágil. Primero porque lo hace el propio equipo y segundo porque se minimiza el tiempo gestionando este nuevo artefacto respecto a la mejora en el equipo que esperamos que produzca.

Cuando el manager se convierte en un lastre para el equipo

En nuestro equipo de desarrollo hacemos una retrospectiva al final de cada sprint (como se debe). Nosotros usamos la técnica del barco. Dibujo un barco en la pizarra con un espacio de motores que simboliza los lo que nos hace ir a buena velocidad y unos lastres atados que simboliza problemas que nos dificultan ir a mayor velocidad.

En la retrospectiva anterior que celebramos ocurrió algo que no había pasado y el que ocurriera me llenó de orgullo. Me dijeron que YO era un lastre cuando tocaba código de producción. Ocurrió que para intentar hacer una historia de usuario que parecía que no iba a entrar decidí hacerla yo por mi cuenta. Al final produjo unos problemas que les hizo perder el tiempo arreglándolo 😛

Por un lado, como me gusta tanto programar fue en parte una lástima pero como facilitador de equipo me encantó. De hecho di las gracias personalmente después de la reunión a quien me lo dijo y explico por qué.

1.- Decir algo así a quien en principio «es tu jefe» requiere cierto grado de valentía. No debe ser fácil. Por lo tanto veo que hay CONFIANZA por su parte.
2.- Yo, que me esfuerzo en que el equipo vaya cada vez más rápido y con mejor calidad, si en lugar de tener que hacer algo para ello tengo que dejar de hacerlo, para mi es más sencillo.
3.-  Me hace ver que hay el clima de sinceridad en las retrospectivas que es muy necesario para mejorar sprint tras sprint.

Por lo tanto, no tengáis miedo si un día os dicen que habéis hecho algo que se considera un lastre para el equipo, u os habéis equivocado. Es el mejor indicador de que el trabajo de uno es importante y que el resto de cosas se hacen bien, ya que si no fuera así alguien se lo diría para mejorarlo.

Preguntas que tal vez te hagas de los Coderetreats

Apuntaros esta fecha todos los desarrolladores: Sábado 14 de Diciembre del 2013. Ese día se celebra en distintas ciudades de todo el mundo el Día Global del Coderetreat.

«¿Y qué es esta frikada?» Esta frikada es una oportunidad única de aprender a mejorar la calidad personal del desarrollo de software.

«Pero yo ya programo mucho en el trabajo». Sí, pero cuando se trabaja la atención está en acabar lo antes posible. Normalmente se programa del modo que se cree más rápido sin intentar buscar nuevas maneras de hacerlo. Haciendo un kata, como el del Juego de la Vida que es el que se suele hacer ese día, te puedes permitir el lujo de hacerlo de esa forma que has leído u oídopero que nunca te habías atrevido a probar. El objetivo NO es terminar el kata. De hecho, a los 45 minutos tienes que borrar el código que has hecho.

«¿Queeee?, ¿Borrar lo que he hecho?» Cierto. Cada 45 minutos vas a enfrentarte al problema desde distintos ángulos y con determinadas restricciones que van cambiando.

«¿Y crees entonces que aprenderé algo?» Ciertamente. Mejorarás estas habilidades:

TDD: +4 Todas las sesiones se realizan haciendo primero los tests y después la solución.
Código limpio: +3 El foco constante está en trabajar con ese código ideal que nunca te has atrevido a escribir por falta de tiempo
Programación en parejas: +3 Todas las sesiones son en pareja mediante el método de PingPong. Uno escribe el test y hace que falla, el otro lo desarrolla,lo pasa a verde y escribe el test para el otro miembro.
Otros lenguajes: 30% de probabildades En cada sesión podrás trabajar con otros que usan otros lenguajes de programación como su segunda lengua madre
Carisma: +2 Trabajar codo con codo con gente con la que nunca has trabajado servirá para mejorar tus habilidades sociales en el trabajo.

«¿Dónde me puedo apuntar a uno?» En España se están haciendo en varios lugares. Aquí tienes una lista

Alicante http://tinyurl.com/on39bq4
Barcelona http://agile-barcelona.org
Caceres http://tinyurl.com/p52qq3d
Madrid http://tinyurl.com/p884qtw
Ourense http://tinyurl.com/on72tsj
Valencia http://tinyurl.com/q3yyj5d
Zaragoza http://tinyurl.com/pa7xp6r

Para buscar en otros lugares del mundo puedes buscarlo aquí: http://coderetreat.org/events

Date prisa. Normalmente las plazas son limitadas.

Si te pica el gusanillo aquí puedes ver más información de los amigos de Agile Madrid. madridcoderetreat.wordpress.com

Si tienes una empresa o conoces alguna que esté dispuesta a patrocinar algo de estas sesiones. Todos los participantes estarán muy agradecidos de que por ejemplo traiga la comida del día o de algun regalo o alguna licencia de software. Animará mucho el día y todos los asistentes tendrán en muy buena imagen la empresa. Contacta con el organizador de la sesión y preguntale qué necesita si estas interesado.

Enfermería, Desarrollo de Software y Servant Leadership

La ingeniería informática es una profesión joven. Algunos nos orgullecemos de haber empezado hace 25 años con los MSXs y su BASIC. Otros empezaron su profesión con las tarjetas perforadas y sin poder preguntar en aquel entonces a nadie cualquier problema técnico que pudieran encontrar (Oh! Bendito Stackoverflow!)

La medicina, por el contrario,  es una de las profesiones técnicas más antiguas. Desde los antiguos chamanes, pasando por el árabe Avicena (Ali Ibn Cina) a las modernas clínicas y hospitales.  Florence Nightingale, a finales del siglo 19 hizo un gran avance en la medicina separando responsabilidades y posibilitando que enfermeras, entrenadas por ella misma, liberaran a los saturados médicos en las curas sencillas de la Guerra de Crimea mejorando su recuperación. Desde ese momento, mucho ha llovido en en el mundo de la enfermería y han adquirido muchos, diversos y muy importantes roles.

Un ejemplo claro de su importante labor es la de las auxiliares en las consultas médicas. Las ves entrando y saliendo de las consultas, recibiendo llamadas, llamando a pacientes,… Tengo la suerte de estar casado con una de ellas y desde hace poco me he dado cuenta de la similitud de lo que hace con mi trabajo como director de desarrollo. Paso a citar algunas de las cosas que hacen:

  • Preparan todo el material y documentación para que los médicos puedan hacer más productivo el tiempo que pasan con el paciente
  • Bloquean las interrupciones (comerciales, llamadas, preguntas,..) para que se puedan centrar en el paciente hasta que termina la consulta
  • Gestionar prioridades. Dan respuesta personales a los pacientes citándolos según la urgencia de sus problemas.
  • Reducir el Lead Time (Tiempo de Entrega). Citan a los pacientes para analíticas, pruebas de anestesia, cirugía,.. de tal modo que el paciente pase el menor tiempo posible desde que empieza el proceso hasta que termina y sea más rápido y menos traumático.

Esa función en los equipos de desarrollo la tienen los Scrum Masters/Team Leaders/Directores de Desarrollo/Whatever…. Ambos nos ocupamos en que nuestro  equipo (médicos o desarrolladores) sean lo más productivos posible con su tiempo. Los papeles y herramientas de trabajo más importantes tienen que estar en estado READY para que puedan trabajar sin interrupciones y sin que tengan que ocupar su tiempo en algo que puede hacer otra persona. Ambos podemos hacer que la productividad de un equipo aumente o disminuya drásticamente según lo bien o mal que lo hagamos. En gestión de proyectos Ágiles lo llamamos Servant Leadership como si fuera un concepto nuevo pero es algo que lo llevan haciendo hace tiempo las auxiliares, sin tanto bombo y platillo y conceptos en inglés.

La próxima vez que este esperando a entrar al medico fíjate en ellas, las auxiliares o enfermeras, quizá aprendas algo de cómo mejorar la productividad de tu equipo de desarrollo.

Potencia tus reuniones

Llega un momento en la evolución de un equipo de trabajo que empieza a ver las reuniones como el siguiente punto de mejora. Problemas comunes son reuniones que se alargan más de lo debido y falta de conclusiones. Para evitar estos problemas existen una serie de técnicas que conviene utilizar.

1.- Establecer un objetivo claro para la reunión. Cuanto más concreto sea el objetivo mejor. Si hay varios, al principio de la misma debería hacerse un listado de todo lo que se pretende hablar en la reunión y de lo que se tratará en otras.

2.- Intentar que el tema esté preparado con anterioridad. Todo lo que se pueda llevar ya pensado a la reunión será tiempo que se ahorre por parte de todos en la misma. Todos los miembros deberían entender el alcance del problema lo suficiente para que en la misma se vaya directamente a comentar y elegir las soluciones.

3.- Asignar un tiempo máximo y asegurar que sea visible el tiempo restante una vez empezada la reunión. Son muy útiles los relojes web (http://www.online-stopwatch.com/)o alguno de cocina con los números grandes como éste. El ser conscientes del tiempo limitado hace que todos los miembros estén más enfocados en el objetivo de la reunión.

4.- Apuntar los temas paralelos que surjan durante la reunión y tratarlos en otro momento. No cambiar de tema a mitad de la reunión. Esto se acerca mucho a lo que apunta la técnica pomodoro. Si surgen temas nuevos hay que apuntarlos para hablar de ello al terminar  o en otra reunión. El tiempo asignado sólo debería ser para el tema que teníais programado.

5.- Usar toda los elementos visuales que se pueda. Pizarras, dibujos en papel, ver el software en una pantalla grande,…. Visualizar todos a la vez el problema y las posibles soluciones ayuda a definir soluciones más simples y más rapidamente.

6.- Cuando se vaya a terminar la reunión hacer  conclusiones y asegurarse que se apuntan correctamente. Es util tener un secretario que apunte las tareas en papel o en un sistema digital pero debe ser un sistema en el que se pueda añadir de manera rápida las conclusiones.

7.- No pasa nada porque al principio se pase algo del tiempo asignado. El timeboxing de las reuniones es algo que se consigue hacer bien con la práctica. Los sprints de scrum tambien cuesta bastantes iteraciones el ajustarse al tiempo establecido.