5/5 Gestión eficiente

20. Visualización del trabajo

Una gestión eficiente se sustenta en plataformas que permitan dar una visibilidad en 360° de todas iniciativas del proyecto. Esta visibilidad debe ser compartida con todo el equipo, y, obviamente, debe ser de fácil acceso. Si bien hay muchas plataformas que ofrecen este servicio, se deben privilegiar aquellas que puedan integrarse con el repositorio de código, de forma de asociar el trabajo técnico a la historia o requerimiento del usuario.

¿En qué tarea está trabajando el nuevo desarrollador?, o ¿qué tarea deberá realizar al terminar la actual?, o ¿qué bloqueos hay? son preguntas sumamente básicas, pero que en contadas ocasiones no están visibles.

Además de la visualización de las tareas y el trabajo individual de cada profesional, también deberá existir un canal de comunicación de calidad que permita que la información fluya de forma ágil y rápida. Si la herramienta cobra por el historial de las conversaciones u otra característica relevante, la empresa deberá pagar la tarifa del servicio para no restringir o limitar la comunicación.

21. Limitar la carga de trabajo

Es necesario establecer límites para regular la capacidad de trabajo. Es a través de estas restricciones las que habilitan las condiciones mejorar el proceso, y, eventualmente, aumentar la capacidad o límite.

Es uso de límites a la capacidad de trabajo es una practica común en el mundo Lean. No sólo existe, sino que es completamente visible para todos, y se utiliza generalmente para evitar el agotamiento o el exceso de carga de trabajo de los equipos. También permite exponer los obstáculos en la planificación.

Cabe destacar que el sólo hecho de definir un límite a la carga de trabajo no afecta el rendimiento de los equipos. Sólo cuando este límite se incorpora en los tableros de visualización —en un kanban o en el tablero de historias— y forma parte del proceso de retroalimentación con el equipo de negocios, es cuando se genera un efecto positivo en el rendimiento del desarrollo de software.

Por el contrario, cuando no se define un límite a la carga de trabajo —o WIP (work in progress), lo que sucede es que todos los indicadores de desarrollo comienzan a declinar. Sólo imaginen que el equipo de desarrollo está sobrecargado. Los tiempos de entrega aumentan, las revisiones son menos rigurosas y por lo tanto, más riesgo de errores. Como hay poco tiempo y mucho por hacer, se toman “atajos”. Finalmente se genera lo contrario de un círculo virtuoso.

Por último, señala que es difícil implementar un límite a la carga de trabajo en la cultura de las empresas de hoy, ya que es frecuente que éstas busquen aumentar la eficiencia en el uso del tiempo de los ingenieros. Y esto típicamente implica que los ingenieros no pueden tener tiempo libre, y que en todo momento deben tener “algo” que hacer, y por lo tanto, se le solicita todo el trabajo posible.

22. Notificación proactiva

Existen varias maneras de enterarse de un incidente en un servicio o aplicación. Por ejemplo, cuando son los mismos usuarios los que se comunican con la empresa para reportar un problema con el software. Otras formas de notificación son por medio del mismo data center o por nuestro propio servicio de monitoreo  y alertas. Todas ellas son notificaciones reactivas.

Las notificaciones proactivas en cambio, son advertencias previas al incidente. Generalmente corresponden a parámetros o métricas que superan cierto umbral que nosotros mismos hemos definido. Por ejemplo, cuando los CPU del servidor superen el 90%, o cuando el almacenamiento del disco supere el 95%, o cuando la memoria RAM exceda el 60%. O bien pueden ser métricas de nuestros servicios o aplicaciones; cuando el número de queries a la base de datos supere cierto número, o cuando el tiempo de respuesta de un API supera los 10 segundos, etc.

Adicionalmente, a alguien le deben llegar las alertas. Por lo mismo, es frecuente definir un equipo de “guardia”, que idealmente esté compuesto por los mismos miembros del equipo de desarrollo de la plataforma que estén soportando, de forma que cada persona tenga asignado un día de la semana para dar soporte en horarios no hábiles.

23. Monitoreo

Cuando existen muchas plataformas, aplicaciones y servicios distintos, y que, —en el mejor de los casos—, cada cual tiene se propia plataforma de monitoreo y registros, la visualización, alertas, notificaciones y registros se complejiza.

Y como no estamos aquí para reinventar la rueda, este mismo problema lo han tenido Uber, Google y todas las grandes empresas. La solución pasa por la estandarización de los volcados de registros (logs) y de la publicación de las métricas bajo una misma estructura. Luego todas las aplicaciones y servicios, independiente del lenguaje y sistema, podrán ser monitoreados bajo un mismo panel.

Existen varios estándares de publicación de métricas, pero me parece que esta carrera la está ganando Prometheus mediante la publicación de un endpoint por HTTP para la recepción de las métricas y registros. Así, cada servicio deberá publicar e informar sus métricas cada cierta frecuencia, las que luego serán consumidas por la plataforma de monitoreo de forma consolidad.

En este último grupo están herramientas como Kibana o Grafana, que por las métricas que llegan a través de Prometheus, permiten crear dashboards preciosos.

Todo esto sin duda se simplifica bastante con la utilización de contenedores y un sistema de orquestación de contenedores como Kubernetes.

24. Cambiar los procesos de aprobación

Todos las organizaciones tienen algún tipo de proceso para autorizar los cambios a los ambientes productivos. En los casos más simples, bastará con la revisión o aprobación de un colega para empujar los nuevos cambios. En los casos más complejos, existe un equipo, —distinto del que desarrolla—, que valida y certifica los nuevos cambios, que puede demorar días o semanas.

¿Qué funciona mejor? Bueno, de acuerdo al estudio en cuestión, las empresas líderes son aquellas en que no existe un proceso de revisión formal, o bien tienen un proceso sumamente simple —como la validación de un compañero—. Por el contrario, aquellas empresas en que sí hay un proceso de revisión y aprobación formal, aumenta el tiempo de puesta en producción, y por ende, no se genera el loop virtuoso de retroalimentación. Al mismo tiempo, tampoco existe una correlación en que las empresas con un proceso formal de revisión tengan una menor tasa de error como cabría esperar.

La recomendación entonces es tener un proceso simple y sencillo de aprobación para los cambios a producción. Basta con que sea validado por un compañero o par, que, combinado con la pruebas automatizadas de la integración continua, detecte y rechace los errores.

Al fin y al cabo, es el equipo que desarrolla quien tiene el conocimiento necesario para entender los riesgos y validar nuevos cambios. Delegar la aprobación a otro equipo sólo complejizará y retrasará el flujo de desarrollo.