Pero en el mundo del desarrollo web esto nunca ocurre.

Todo cambia respecto a lo inicialmente previsto, y lo hace por varias razones:

1. El cliente no sabe lo que quiere

En muchas ocasiones, ni siquiera el cliente sabe muy bien lo que quiere. Tiene una idea de cuál es su problema, es verdad, pero a menudo desconoce sus necesidades reales. Y en muchos casos, cuando estamos diseñando un sistema nuevo, solo tenemos una idea aproximada en nuestra imaginación.

Por eso el “diagnóstico” no resulta sencillo, y los primeros pasos del proyecto no siempre avanzan en la dirección adecuada. Más tarde o más temprano, esto nos obliga a rectificar.

¿Como podemos hacer un plan para construir un sistema que no sabemos como es?

Un proverbio árabe dice que “cuando no sabes donde vas cualquier camino te llevará al lugar equivocado”.

2. La comunicación es imperfecta

El proceso de comunicación siempre es imperfecto. El cliente no puede proporcionar una imagen completa sobre sus procesos y las necesidades de su empresa. Es inevitable que deje de contar cosas: porque no las conoce, porque las olvida, o incluso porque no cree oportuno contarlas.

Y, también de forma inevitable, el informático no es capaz de interiorizar todo lo que oye: hay cosas que no entiende bien, y otras a las que no es capaz de asignar la relevancia que merecen.

La información correcta y precisa no aparece hasta más adelante, como fruto de las diferentes iteraciones. Y cuando aparece, se traduce en cambios.

3. Al principio sabemos muy poco sobre el proyecto

Al inicio del proyecto, nuestro nivel de conocimiento de la realidad es muy limitado.

Conforme el trabajo avanza, vamos descubriendo cosas nuevas que antes no sabíamos, obtenemos información muy valiosa -está basada en situaciones reales, no en previsiones- y podemos tomar por tanto decisiones mejor informadas.

Estas decisiones se traducen en cambios frente a lo inicialmente previsto.

4. La realidad cambia

Además de que la realidad que tenemos en frente es distinta de la que sería posible construir en un mundo con información completa, y comunicación perfecta. La realidad cambia de verdad, con cosas como:

• Cambios  (impuestos, exigencias de LOPD, LSSI, etc.)
• Movimientos de la competencia
• Cambios tecnológicos
• Cambios en las organizaciones (Fusiones, compras, etc.)
• etc.

Conclusión

Podemos extraer un conclusión muy clara: la realidad cambia, y no queda más remedio que aprender a cambiar con la realidad.

A estas alturas no debería ser ninguna sorpresa. Pero parece que muchas empresas de desarrollo todavía no lo han asumido. Por eso siguen aferradas a los métodos de ingeniería tradicionales.

Ahora voy a tratar de explicar en qué consiste de la forma más sencilla posible.

I. Las tres variables del proyecto

En todos los proyectos hay 3 elementos fundamentales:

• La fecha de entrega
• El conjunto de funcionalidades
• Los recursos necesarios para ejecutar el proyecto

II. El enfoque tradicional

Hasta ahora, en casi todos los proyectos se ha seguido el procedimiento tradicional, que pasa por fijar la funcionalidad y dejar que el equipo técnico (interno o externo) se pelee con las otras dos variables: fecha y recursos.

III. El resultado

El resultado final de esta forma de actuar suele ser el que sigue:

A. Los proyectos se retrasan (la opción más común)

B. Los recursos superan los inicialmente previstos

Es evidente que ninguna de las dos opciones resulta satisfactoria. Lo más usual es que los proyectos se retrasen, y que casi todas las previsiones iniciales acaben en la papelera, incluido, por supuesto, el documento de especificaciones.

Lo peor de todo es que habremos malgastado tiempo y esfuerzo tratando de ajustarnos a un plan que no tenía futuro.

IV. El problema está en la pregunta

Como tantas otras veces ocurre, el problema no está en la respuesta. El problema es la pregunta.

La pregunta no es: ¿Cómo se hace todo esto en plazo y tiempo?

La pregunta adecuada es la siguiente: ¿Cómo hacemos un proyecto que sirva a mis objetivos de negocio y que pueda entregar en fecha ajustándome a los recursos planificados?

V. El nuevo método

El método que propongo -y que nosotros ya estamos utilizando- pasa por aceptar que el proyecto es un objetivo en movimiento constante. No tiene sentido malgastar esfuerzos intentando fijar la funcionalidad porque la funcionalidad va a cambiar conforme el proyecto avanza.

Por eso, la clave está en:

• Determinar nuestro objetivo: qué proyecto necesitamos para mejorar nuestro negocio
• Fijar el plazo: cuándo lo necesitamos. Esta variable sigue siendo crítica, porque no sirve de nada llegar tarde al mercado.
• Analizar los recursos disponibles.
• Determinar qué es lo que podemos hacer con esos recursos para esa fecha. Tendremos que asumir que bastantes de nuestros presupuestos irán cambiando a medida que descubramos cosas nuevas sobre el proyecto y conozcamos mejor el mercado. Lo importante es gestionar esos cambios necesarios con agilidad.
• Asignar y reasignar prioridades para “atacar” primero aquellas funcionalidades que realmente son esenciales para el negocio.

De esta forma, al llegar al plazo de entrega habremos construido el mejor proyecto posible, con los recursos de los que disponemos, y  con las funcionalidades esenciales para nuestro negocio.

La respuesta tradicional de los informáticos ante una situación de cambio ha sido la siguiente:

• encorsetar al cliente mediante procesos muy estrictos de ingeniería
• atarle mediante especificaciones, análisis, y actas de reuniones
• construir una representación cerrada de la realidad al inicio del proyecto e intentar bloquear cualquier intento de cambio posterior

Es evidente que esto no funciona. Y quien haya contratado un desarrollo software sabe que cualquier parecido entre la oferta y el documento de especificaciones -por una parte- y lo que se entrega al final -por otra- es pura coincidencia.

Por eso decimos que realizar un proyecto en el plazo estimado y dentro de los costes previstos es tan fácil como caminar sobre el agua. Es decir, resulta muy sencillo siempre y cuando las especificaciones del proyecto y el agua estén congeladas. Algo que nunca ocurre.

Si el cliente le dice al proveedor qué es lo que quiere hacer y lo mantiene hasta el final, entonces no hay ningún problema. Todo es fácil. Pero la realidad es que el mundo en el que vivimos no es así: las aguas raramente están congeladas; las especificaciones, nunca.

La pregunta es: entonces, ¿cómo hacemos para entregar los proyectos en plazo y coste? La respuesta, en el próximo post .

Para entender porque menos es mas hay mucho material en la red, he dejado en slideshare un brevisimo resúmen que lo intenta explicar:

Las bases erán sencillas:

• 48 horas
• Máximo 4 personas

Lo espectacular es el resultado de esas 48 horas, algunas de las aplicaciones tienen un altísimo nivel de calidad.

Es también importante destacar la plataforma tecnológica elegida por cada participante:

Ahh, y enhorabuena a todos los participantes.

Probablemente es eso lo que resulta tan atractivo de los proyectos en la red: tenemos espacio para la imaginación, para crear,  para desarrollar nuevos servicios y para buscar nuevas maneras de hacer las cosas.

Pero también es cierto que cuando te enfrentas a un desarrollo web, esa misma posibilidad de crear e innovar puede convertirse en uno de los mayores problemas del proyecto.

Generalmente empezamos cada nuevo proyecto muy ilusionados con todas las ideas que queremos añadir a nuestra web. Pero la experiencia nos ha enseñado algunas lecciones que no deberíamos pasar por alto:

• Muchas de las funcionalidades contempladas por un proyecto no siguen allí pasados pocos meses.
• Cuantas más funcionalidades tiene un proyecto, más tardamos en acabarlo y más tiempo en salir al mercado.
• El principio de Pareto está también presente en el uso de las aplicaciones, y más en el caso específico de la web: el 80% de los usuarios usa solo el 20% de las funcionalidades disponibles.

No fue hasta principios del siglo pasado cuando la arquitectura, de la mano de Mies van der Rohe, empezó a hablar de “menos es más“. Y nosotros estamos convencidos de que, efectivamente, es así.

Barry Schwartz lo explica maravillosamente en su libro La paradoja de la elección. El libro Getting Real es sin duda otra lectura recomendable para los que quieren entender por qué “menos es más”.

El problema se plantea cuando debemos elegir entre la enorme lista de cosas que queremos hacer.

De todas las cosas que hemos pensado añadir a la aplicación, ¿cuáles vamos a dejar fuera o para una segunda fase del proyecto?

Dicho en otras palabras:

¿Cómo elegir entre un montón de funcionalidad cuando estás diseñando una aplicación web?

Nosotros lo hemos resuelto acudiendo a la unanimidad.

Cuando estamos diseñando una aplicación proponemos que la decisión sobre la inclusión o no de una funcionalidad se tome por unanimidad. Es decir, basta con que  uno de los miembros del equipo no crea que una funcionalidad deba estar presente para que ésta quede fuera.

El resultado de este proceso es que el producto desarrollado contiene “sólo aquello que todos los miembros del equipo creen que debe estar”, en lugar de “todo lo que alguien del equipo piensa que debería estar presente”.

Necesariamente, las aplicaciones desarrolladas de esta manera:

• son más sencillas y, por tanto, más fáciles de usar, explicar, documentar, etc.
• son más baratas de desarrollar, puesto que hay menos funcionalidad
• son más fáciles de mantener cuando es necesario hacer cambios
• si surgen problemas, son más fáciles de resolver (hay menos líneas de código, por lo tanto, hay menos lugares en los que el error puede esconderse)

Pero lo más importante de todo es que, al ser las aplicaciones más sencillas, podemos ponerlas en el mercado mucho antes, y tenemos la oportunidad de probar con la realidad de nuestros usuarios. A partir de ese punto podemos empezar a desarrollar con datos y feedback reales, y no con previsiones o estimaciones. Podemos mejorar guiados por lo que los usuarios realmente nos piden o utilizan.

Prueba. Puede sonar un poco extraño, pero nuestra experiencia nos ha demostrado que el concepto “menos es más” es una práctica excelente para el desarrollo web.

Para dar con una definición adecuada, creo que lo mejor es ir paso a paso:

¿Qué es una solución?

Según explica la Wikipedia, una solución es una respuesta a un problema complejo.

¿Qué es una solución informática?

Podemos definir una solución informática como la aportación -por parte de un proveedor- del hardware, las redes, el software, el soporte técnico, la formación y el mantenimiento. Es decir todo aquello que hace falta para resolver un problema de negocio mediante el uso de la tecnología.

En los 80 y 90, el concepto de solución iba muy asociado al de servicio integral. Algo así como: “Tú me contratas y yo me encargo de todo”.

¿Qué ha cambiado?

Con el desarrollo de la Nube, las soluciones informáticas han cambiado de forma radical. Hoy ya no es necesario realizar grandes inversiones en infraestructura. Desde el minuto uno podemos contar con toda la capacidad de los mayores proveedores de la red.

Lo verdaderamente importante de este cambio no es tanto la tecnología, sino el hecho de que hoy puedo empezar con una solución que requiere muy poca inversión para luego ir creciendo y cambiando con las necesidades del mercado. La reducción de costes e inversiones, así como la capacidad de crecimiento, hacen que la filosofía de uso de las soluciones también sea muy diferente.

¿A qué llamamos “solución ágil”?

Llamamos solución ágil al conjunto de software, hardware y servicios que permiten a un usuario utilizar una aplicación:

• de la que solo conoce la URL
• en la que no tiene que preocuparse por la infraestructura técnica asociada: la aplicación que presta el servicio, el hardware, las redes, el mantenimiento, los backups (las copias de seguridad)
• y que, sobre todo, le permite afrontar sin riesgos el difícil problema de la escalabilidad de la solución

En otras palabras, nosotros -los proveedores de soluciones ágiles- nos encargamos de proporcionar al usuario toda esta infraestructura básica en colaboración con nuestro proveedor de hosting.

Una solución ágil es, por tanto, una solución informática integral. Y en este sentido, se parece a las soluciones tradicionales. Pero si profundizamos un poco, encontramos diferencias sustanciales.

Las soluciones informáticas tradicionales son complejas, y requieren procesos de planificación y diseño muy detallados. Es decir, no solo es compleja la solución; también lo son la metodología y el desarrollo del proyecto. Por decirlo de alguna manera, son soluciones basadas en los principios tradicionales de la ingeniería, y están fuertemente orientadas a procesos.

Las soluciones ágiles, en cambio, se basan en el desarrollo evolutivo, mediante iteraciones, y están orientadas al usuario final:

• No es necesario hacer complejos estudio de diseño y planificación de la solución.
• El desarrollo de la solución es ágil: es decir, utilizamos herramientas, lenguajes y tecnologías que nos permiten introducir cambios con rapidez.
• El avance se produce mediante ciclos iterativos que nos permiten adaptarnos, paso a paso, a las exigencias reales de los mercados y de los usuarios
• Re-evaluamos las necesidades y exigencias de la solución conforme avanza el proyecto
• El principal valor de la solución se encuentra en la funcionalidad desarrollada y, por encima de todo, en el uso que los usuarios finales hacen de esa funcionalidad

Al final, podemos decir que una solución ágil es el conjunto de hardware, software y servicios que satisface las necesidades del usuario, que normalmente lo hace utilizando la infraestructura de la Nube, y que incluye el soporte, la capacidad operativa y un elemento fundamental: el mantenimiento asociado.

Debemos insistir en que el mantenimiento es clave, puesto que la solución está siempre en evolución. Estos son algunos de los ejemplos típicos:

• Nuevas funcionalidades no previstas al principio o modificaciones de las existentes.
• Nuevas máquinas para atender a la demanda o picos de servicio.
• Cambios en la tecnología de base (versiones, mejoras, etc).

Porque una solución ágil no es una caja que se vende al cliente y ya está. Las soluciones ágiles están en continua evolución, están continuamente en fase beta, o beta perpetua.

Una solución ágil es capaz de evolucionar, de crecer y adaptarse a las demandas de los usuarios finales. Y esto exige un acompañamiento técnico y humano.

Todas estas listas de cosas hacen los proyectos complejos, muy complejos. Cada  funcionalidad requiere:

• Trabajo de definición detallada, donde estará en la pantalla, como funionará, etc.
• Trabajo de  diseño gráfico
• Programación
• Pruebas, etc.

Nuestra experiencia nos dice que además muchas de esa funcionalidades no serán utilizadas, los usuarios no las entenderán o simplemente no habremos acertado. Añadir estas funcionalidades no solo requiere mas trabajo por el hecho de ser más, sino que además,  aumentan la complejidad del proyecto. Y hacer proyectos complejos es muchisimo mas difícil que hacer proyectos sencillos.

La alternativa es construir un proyecto con la funcionalidad indispensable para salir al mercado y que nuestro negocio tenga sentido. Nosotros lo llamamos el Mínimo Proyecto Viable. No vamos a dedicar tiempo a construir nada que no sea absolutamente esencial. Nuestro proyecto web debe contar solo con la funcionalidad que hace falta para probar la viabilidad de nuestra idea. Centrarnos en lo esencial nos va permitir hacer más fácil muchas de las cosas que son imprescindibles en un proyecto web:

• Medir el éxito de cada cosa.
• Cambiar la web, si es necesario.
• Saber que quieren los usuarios.
• Entender el comportamiento de los usuarios en la web.
• Añadir nuevas ideas o algunas de las que teníamos pensadas desde el principio.

Además el Mínimo Proyecto Viable:

• tiene menos coste,
• requiere menos tiempo de desarrollo,
• menos esfuerzo de gestión,
• nos obliga a centrarnos en lo esencial,
• nos permite validar nuestra idea en lo esencial, y si es necesaria cambiarla y adaptarla.

Pero quizas la ventaja fundamental del Mínimo Proyecto Viable es que nos permite salir al mercado lo antes posible, e iterar con la realidad.  Como explica muy bien José Cabrera en su entrada sobre el liderazgo adaptativo la solución a los problemas adaptativos, y crear un nuevo servicio web es un problema adaptativo, debe emerger poco a poco, y la mejor forma de que una web emerja es iterando con la realidad. Muchos de los servicios web mas famosos hoy nacieron con un objetivo distinto del que tienen ahora.

Si estas pensando en hacer una nueva web, no lo dudes, elige bien como es tu Mínimo Proyecto Viable.

Hace poco envié el mail que copio a continuación a un cliente que estaba valorando la posibilidad de hacer un proyecto cambiando de entorno tecnológico. En mi opinión lo relevante del mail no es la discusión sobre si la tecnología A o B es mejor, sino cuales son los factores mentales y los frenos que afrontan muchas compañías a cambiar y avanzar.

Hay veces que en desarrollo de software vemos los cambios como un riesgo, y el mail pretendía ser una invitación a ver los cambios de plataforma como una oportunidad para aprender.

El coste de cambio es siempre enorme, y la aversión al riesgo una carácterística tremendamente humana.

Querido cliente:

Llevo unos días dándole vueltas al proyecto que os presentamos, y a como trasmitirte las ventajas que os puede aportar.

En primer lugar, quiero volver a insistir en que entiendo perfectamente la situación en la que estáis.

La plataforma que gestionáis es muy compleja, y sobre todo tiene muchos años de vida (como decimos nosotros: “el mundo se pudo hacer en 7 días porque no había base instalada”). Mantener la aplicación en funcionamiento en un entorno tan cambiante seguro que no es fácil, y mas cuando muchas veces las decisiones hay que tomarlas rápido y no siempre con todos los recursos que serían necesarios.

Entiendo además que la perspectiva de cambiar de plataforma tecnológica introduce mucha incertidumbre, especialmente en lo que se refiere a dependencia de un proveedor, frente a trabajar con tu propio equipo.

Te mando este correo para ofrecerte la posibilidad de ver las cosas de otra manera, para ver este proyecto no como un proyecto que complicará vuestra actual infraestructura haciendo vuestro trabajo mas difícil, sino como una oportunidad para la innovación y la mejora que acabará redundando en un mejor servicio al resto de la empresa, y reforzará una de las ventajas competitivas de tu empresa: su diferencial tecnológico.

Es complicado resumir en pocas líneas todas las ventajas que Ruby on Rails puede ofrecer en un entorno con necesidades de cambio constantes y con presión en plazos y costes. Puedo decirte que las ventajas que estamos experimentando desde hace ya casi 4 años son:

• Velocidad de desarrollo
• Estabilidad de la plataforma
• Escalabilidad
• Disminución del número de errores y necesidades de soporte

Si decidierais ir adelante con el proyecto, podríamos abordar juntos, y poco a poco, algunos de los retos a los que tenéis que hacer frente porque:

• La productividad de Ruby on Rails os permite atender mejor las necesidades de las áreas de negocio sin necesidad de nuevos recursos.
• Adoptar un entorno como Ruby On Rails os permite utilizar la experiencia y pasión de muchos desarrolladores, de mucho software disponible como software libre, y servicios.
• El que Ruby On Rails disponga de tres entornos integrados pero diferenciados (desarrollo, pruebas y producción) hace la gestión de los desarrollos, las pruebas de regresión y las puestas en producción mas estables.
• La estabilidad y escalabilidad de la plataforma reducen drásticamente el tiempo dedicado a incidencias.
• Sabes bien que los informáticos somos gente con pasión por la innovación y seguro que un cambio de plataforma es una oportunidad para tu equipo de aprender algo nuevo. Es verdad que cambiar de entorno es un desafío, pero cuentas con nuestro soporte para hacer ese camino lo mas fácil posible. Nosotros estamos teniendo tiempos de aprendizaje básico de la plataforma de menos de 2 semanas.
• Independencia de proveedores y empleados, las aplicaciones Ruby On Rails tienen todas la misma arquitectura y por tanto cuando un desarrollador llega a un proyecto ya sabe donde está todo y su tiempo de adaptación a un proyecto es muy pequeño. Nosotros lo experimentamos continuamente en la reorganziación de los equipos de trabajo, y en las escasas ocasiones donde ha habido que hacer alguna intervención, cualquier miembro de nuestro equipo es capaz de resolver la incidencia. Dejame compartir contigo que en estos cuatro años no hemos tenido ningún bug que nos haya costado mas de 4 horas resolver.

Si te parece oportuno, podemos quedar un día para discutir este tema con nuestro director técnico y el vuestro,  y explicaros con mas tranquilidad nuestro punto de vista.

El mail no debería ser tan bueno, al final no ganamos el proyecto.

Como he dicho en otras ocasiones nuestro nivel de control sobre un proyecto es limitado:

• Especificaciones en cambio constante
• Incertidumbre sobre las distintas alternativas
• Gestión del cambio
• Cambios en las personas
• Identificación de responsables

La solución habitual para estos problemas ha sido:

• Documentos de especificaciones
• Documentos de gestión de cambios
• Reuniones de seguimiento
• Actas de reunión
• etc.

Parece todo muy razonable. Pero la realidad es que estos documentos, en la gran mayoría de los proyectos, acaban convirtiendose en armas arrojadizas ante los problemas entere el cliente y el desarrollador (ya sean estos internos o externos), en una carga de trabajo para todo el equipo (tanto para los que los escriben como para los que los leen), y además no suelen reflejar bien la realidad del proyecto (por ejemplo la documentación nunca o casi nunca coincide con el producto).

En general la respuesta a estos problemas suele ser todavía mas control, todavía mas reuniones, todavía mas documentos, todavía mas trabajo, y además los mismos resultados. Te invito a consultar la documentación que te han entregado de un proyecto software, o la última que hayas escrito, casi siempre la documentación y el código no están sincronizadas.

Hay otra manera de ver las cosas. ¿Que tal si trabajamos todos en la misma dirección? ¿que tal si cambiamos algunas cosas?. Yo empezaría por cambiar la relación entre usuario y desarrollador, empecemos haciendo un esfuerzo real de confianza mutua.

Ahora aderecemos la confianza con:

• Trasparencia en la evolución del proyecto, toda la información la tiene todo el mundo, o al menos la tiene accesible.
• Trabajamos a corto plazo, no hace falta memoría escrita, las decisiones son mas fáciles.
• Todos nos equivocamos, el miedo al error paraliza, y en la mayoría de los casos el equipo acierta a la primera. Es mejor aceptar los errores, tiene menos coste que evitarlos, sobre todo si vamos avanzando poco a poco.
• Decidamos lo mas tarde posible, cuanto mas tarde tomemos una decisión mas información tendremos sobre ella.

Siempre me ha gustado mucho la escena de “El último emperador” cuando Nobutada le explica a Algren que se deje llevar, que no piense demasiado:

Cuando el control se relaja, las cosas fluyen. Las personas producen al máximo y el proyecto avanza con velocidad porque:

• Se ha mejorado la comunicación entre cliente y desarrolladores
• La creatividad tiene espacio, porque ya no es culpable en caso de que algo vaya mal
• No debo estar pendiente de protegerme del resto del equipo, y por lo tanto la colaboración es mas abierta

En definitiva en nuestra experiencia la incertidumbre se reduce con iteración con la realidad y colaboración.