Sunday, 10 December 2017

¿Tienes dependencia de tu proveedor de software?

En algunas ocasiones nos encontramos con clientes que están atados de pies y manos por su proveedor de software. Usan un software que es sistémico para la empresa pero no están contentos con el mantenimiento que el proveedor realiza, los tiempos medios para la corrección de errores y lo tarde y mal que entrega nuevas características del programa. A veces el servicio no es del todo malo pero sí caro pero no pueden pedir ofertas a otros proveedores y estimular la competencia porque ellos son los únicos que conocen el software o quienes tienen contratados a los expertos en esa solución.

Se les suele pedir a estos proveedores que continuamente documenten todo lo que hacen para así asegurarse un traspaso tranquilo y cómodo a otro proveedor si se diera el caso. La empresa probablemente asegure que sí, que todo está bien documentado y esto da cierta tranquilidad al cliente pero ¿pueden estar tranquilos con esta afirmación? ¿basta con documentar el código para evitar la dependencia de proveedores? Probablemente no.

En la empresa proveedora cada vez que llega una nueva andanada de peticiones de documentación, ésta se vuelve como loca a producir documentos pero pueden pasar estas cosas:

  • El proveedor puede ser reticente a documentar las partes más sensibles de su código porque contenga las claves que permitan que su trabaje se copie a otras soluciones.
  • Puede que al proveedor no le interese documentar bien el código para mantener su situación de vendor lock-in (dependencia del proveedor) y que el cliente tenga unos costes inasumibles si intenta cambiar de proveedor.
  • Se producen documentos como si los pagaran al peso pero su principal objetivo no es el de clarificar qué se ha hecho en el código sino poder facturar documentos, enseñarle papeles a un auditor o justificar el trabajo.
  • La documentación no está actualizada porque a medida que se han ido haciendo más y más cambios nadie ha ido actualizando cada diagrama y cada nota de unos documentos que cada mes que pasa se hacen más viejos. Documentar y mantener actualizada una documentación es un trabajo muy costoso que consume mucho tiempo y recursos.
  • La calidad del código es mala y algunas partes del código sólo son entendibles por la persona que lo hizo haciendo muy difícil que nadie pueda escribir un documento que los describa.

¿Podemos quedarnos tranquilos con nuestro código ya documentado? ¿Qué podemos hacer si ya sabemos que documentar no es suficiente?
  • Asegurarte que se usan buenos estándares de programación para que el código sea claro y fácilmente entendible por cualquiera que lo retome.
  • Procurar que todas las personas trabajen en todas las partes y módulos del código (Collective Ownership) evitando que quede en manos de unas pocas personas todo el conocimiento de algunas áreas del código.
  • Seguir el principio KISS (Keep It Simple Stupid) evitando diseños y soluciones demasiado complejas de entender. Ya se sabe que 'lo bueno, si sencillo, dos veces bueno'.
  • Utilizar un buen sistema de control de versiones que te permita mantener la propiedad y el control de todo el código de forma que sea fácilmente transmitible a cualquier nuevo proveedor que llegue con sólo pasarle una url y un usuario y contraseña.
  • Usar APIs de Servicios Web y estándares XML o JSON de forma que puedas extender tu aplicación con las mínimas interferencias con el resto del código de tu producto.
  • Tecnologías como Docker te permitirán aislar tu código del entorno hardware donde están para controlarlo tu mismo evitando hacer peticiones a la empresa que controla el hardware y middleware donde está desplegado tu aplicación.
  • Herramientas de gestión de la configuración como Chef y Puppet te ayudarán a automatizar la configuración de la infraestructura en la que tu software se ejecuta simplificandola drásticamente.

Referencias:

Sunday, 3 December 2017

No te dejes engañar por un diagrama de Gantt y la Falacia de la Planificación

¿Cuántos proyectos conoces que hayan acabado dentro del tiempo y presupuesto estimado sin que haya habido que reducir el alcance del proyecto? Muy pocos ¿no? Yo tampoco conozco muchos casos. Esto pasa en casi todos los sectores, no sólo en la industria del software, pero me temo que nuestra industria tiene una tasa de proyectos fracasados más alta que otras industrias. El estudio realizado para el Informe CHAOS 2015 revela que sólo el 29% de los proyectos TI pudo considerarse un éxito.

Nuestras estimaciones de tiempo y coste de un proyecto se salen de toda escala e incumplimos habitualmente nuestros relucientes diagramas de Gantt hechos al inicio del proyecto ¿A qué se debe esto? Bueno, al menos tiene una explicación científica. Se debe a un sesgo cognitivo que tenemos todas las personas no deprimidas y que hace que caigamos, una y otra vez, por exceso de optimismo en la llamada falacia de la planificación.

Este fenómemo, el de la falacia de la planificación, es debido a que los seres humanos tendemos a subestimar cuanto nos va a llevar terminar una tarea. Somos demasiado optimistas y siempre pensamos que vamos a tardar mucho menos de lo que finalmente nos va a llevar terminarla.

Lovallo y Kahneman, los autores de esta teoría, realizaron un estudio en el que preguntaron a 87 estudiantes de una universidad cuánto tiempo creían ellos que necesitarían para terminar su proyecto de fin de carrera. De media estos estudiantes estimaron que tardarían 34 días en finalizarlo el proyecto pero sólo el 30% de ellos fueron capaces de hacerlo en ese tiempo. La media real empleada en terminar sus tesis fue de 55.5 días, un 63% más de lo estimado.

Este exceso de optimismo es provocado en parte por la llamada ceguera de ausencia (absence blindness) que nos dice que por muy bien que planifiquemos nuestro proyecto nos será muy difícil planificar los imprevistos porque son eso, imprevistos, y no los conocemos de antemano. Planificamos todo lo relacionado con las especificaciones del proyecto pero olvidamos calcular los tiempos para las vacaciones, bajas por enfermedad, paternidad, maternidad, reuniones, otras tareas que causan overhead, dependencias de otros proyectos, requisitos que no están bien definidos y un larguísimo etcétera. Como dice Forrest Gump en su película, shit happens (esas cosas pasan).

Todo esto nos lleva además a tener en cuenta la Ley de Hofstadter: "Todo proyecto lleva siempre más tiempo del previsto incluso si se tiene en cuenta la propia Ley de Hofstadter". Y si esto ocurre y nuestro proyecto se alarga más de lo previsto, probablemente caigamos todavía en más costes de lo que supone terminar más tarde. Como no llegamos a la fecha del fin del proyecto la presión nos llevará a meter a más gente dentro del proyecto para terminaar a tiempo haciendo que tengamos que contabilizar gastos extra directos como el salario de estas nuevas personas pero también indirectos de los cuáles no siempre somos conscientes.

Al incluir más personas olvidamos que necesitarán formación en el proyecto y que cometerán más errores al ser nuevos, errores que habrá que dedicar un tiempo a corregir. Se estima que un nuevo perfil en un proyecto tarda unos tres meses en ser totalmente productivo. Por otro lado, alguien que ya estaba trabajando en el proyecto tendrá que parar lo que estaba haciendo para enseñar a los nuevos. Como ya nos decía Brooks en los 70: "Añadir más gente a un proyecto retrasado, hará que se retrase aún más".

Pero la presión aún nos hará incurrir en más costes en el proyecto. Las prisas nos harán bajar la calidad del producto que producimos, aparecerán más errores que también necesitarán tiempo para ser corregidos, o nos saltaríamos las pruebas del software con lo que saldrá a producción con bugs que nos harán perder la confianza y credibilidad con nuestro cliente. Y queremos que nos contrate de nuevo ¿no?


¿Qué podemos hacer para evitar esto?

En primer lugar debemos hacer un esfuerzo para tener en cuenta el máximo número posible de imprevistos que puedan surgir calculando así un tiempo extra para esos inconvenientes del día a día y aquellos otros que puedan ser aún más imprevisibles.

Podemos también intentar apoyarnos en las estadísticas de proyectos similares al nuestro. Si comprobamos cuanto tardaron probablemente nos llevemos una sorpresa si lo comparamos con lo que nosotros hemos previsto inicialmente.

Por último, sería bueno apoyarnos también en pruebas empíricas y no en estimaciones predictivas y medir la velocidad del equipo para calcular cuantas tarjetas podemos consumir en cada sprint. Así sabremos calcular un poco mejor qué podremos tener terminado en determinadas fechas. Los equipos de trabajo no son siempre iguales y si nos basamos en la cantidad de puntos o historias de usuario que nuestro equipo ha podido hacer durante los últimos sprints, podremos calcular algo mejor la cantidad de tiempo que nos llevará hacer otras funcionalidades similares en las próximas semanas o meses.


Otros artículos que pueden ser de tu interés:

Referencias: