Historia de dos presupuestos

En los últimos meses me contactaron para presupuestar dos proyectos en distintos contextos. Fueron dos casos radicalmente distintos a lo que suelen ser mis presupuestos.

En un caso el contacto llegó por medio de un colega que me recomendó. Resulta que la organización que me contacto estaba buscando una persona con perfil de «arquitecto» para trabajar en un proyecto de 3 meses que consistía en armar una especificación técnica/funcional para con eso salir a buscar un proveedor que se encargara de desarrollar un software acorde a la especificación. ¡Recorcholis! tres meses para armar una especificación y que luego otra organización construya acorde. Sinceramente me interesaba trabajar con la organización así que apenas terminaron de contarme la idea les dije: «no creo funcione» y a continuación les ofrecí mi ayuda para armar un plan con mejores probabilidades de éxito. Creo que no lo convencí pues no me han vuelto a llamar 🤷‍♂️.

El otro caso fue bastante distinto me contactaron unos colegas de confianza, con quienes ya he trabajado, para armar una propuesta para un servicio de mentoring/capacitación/acompañamiento. Si bien es el tipo de trabajo que realizo habitualmente en este caso la propuesta era para un trabajo de +4 meses. En general mis propuestas, al menos inicialmente, son bastante más acotadas, unas 10 o 20 horas y luego vamos viendo y extendiendo si resulta necesario. De todas formas, en este caso parece que la propuesta ya está en proceso de aprobación, en un par de semanas les cuento ✌️.

Estimación y Planificación en contextos de Entrega Continua

Cuando una organización y/o equipo pretende comenzar a trabajar en un esquema de entrega continua, se pone un esfuerzo casi exclusivo en cuestiones de automatización lo cual en muchos casos no resulta bien.

Trabajar en un esquema de entrega continua requiere automatización pero también algunas otras cuestiones que son incluso necesarias para poder automatizar. La automatización en un contexto de entrega continua incluye principalmente la automatización de pruebas y de despliegues. Ahora bien, para automatizar pruebas y despliegues es necesario tomar ciertas «precauciones» en términos de arquitectura y diseño. Pero eso no es todo, si queremos trabajar en un esquema de entrega continua, entonces nuestro trabajo de planificación debe estar en línea con ello.

Es muy difícil (por no decir imposible) trabajar en un esquema de entrega continua si cada story/funcionalidad lleva semanas de desarrollo. Es clave que podamos particionar las stories/funcionalidades de forma tal de poder completarlas en un par días. Al mismo tiempo, la entrega continua implica, como su nombre lo indica, entregar continuamente, o sea: (casi) todos los días. Si cada story/funcionalidad lleva semanas, entonces es posible que nuestras entregas sean cada un par de semanas. En cierto modo es como un efecto en cadena: cuando más grandes las stories, más tiempo insume su desarrollo y más tiempo insume su pruebas y más tiempo insume su despliegue y más riesgos enfrentamos, etc, etc.

Desde otras perspectiva, ocurre que cuanto más diferimos la entrega, mayor relevancia toman nuestras estimaciones. Si hacemos esperar a nuestros usuarios/clientes, aumentamos su «ansiedad» y su necesidad de saber cuanto más tendrán que esperar.

Por otro lado, si trabajamos en pequeños incrementos habilitamos la entrega más rápida y continua, lo cual nos saca presión de estimación. Al mismo tiempo, las técnicas y dinámicas de estimación no son precisamente las mismas de cuando pretendemos hacer entregas frecuentes/continuas que cuando apuntamos a entregas esporádicas a mediano y largo plazo.

En línea con todo esto, estoy armando un taller muy práctico sobre diversas técnicas para estimar y planificar en contextos de Entrega Continua. Aún no tengo fecha, pero los potenciales interesados pueden escribirme para que los mantenga al tanto.

Libro Recomendado: Getting Real

Hace un par de días que terminé de leer Getting Real. Me parece que no es un libro demasiado conocido a pesar de tener casi 20 años. Yo lo tenía en mi lista de pendientes desde hace un tiempo porque uno de sus autores es David Heinemeier Hansson (conocido como «DHH», creador de Ruby on Rails).

La lectura me resultó muy amena, en parte por sus capítulos cortos (1 o 2 páginas) y en parte por ser contenido muy práctico: en cierto modo cada capítulo es un consejo sobre algún tema concreto sobre el desarrollo de productos web.

Creo que este libro es una lectura obligatoria para todo aquel que pretenda crear productos online/digitales.

Debo admitir que no estoy de acuerdo con todo lo que dice pero sí estoy totalmente de acuerdo con la mayoría de las cuestiones que plantea.

Es importante destacar que varias de las cuestiones que proponen los autores son, a mi parecer», de aplicación «universal» pero algunas otras claramente aplican puntualmente a escenarios de «startups».