Cuando pensamos en los hitos de un proyecto, seguramente los primeros que nos vienen a la cabeza son la firma con el cliente, el análisis y definición o la puesta en producción. Sin embargo, hay un evento que muchas veces se pasa por alto y que es igualmente importante: cuando el proveedor se desconecta del proyecto. En Kaleidos sabemos que es un hito relevante y delicado y tiene nuestra atención desde el principio; los proyectos se diseñan con vocación de transferencia y con un horizonte temporal compartido desde el principio, lo que tiene implicaciones en las decisiones que se toman a lo largo de todo el proyecto.
Asegurar una desconexión limpia y sostenible es vital para todos los implicados ya que habilita espacios de confianza donde ser honestos desde el principio. Por ejemplo, la continuidad de un proyecto es un valor muy extendido en las negociaciones de un presupuesto, y se pueden generar falsas expectativas; en el caso de Kaleidos, desde el minuto cero el cliente sabe que vamos a necesitar mucha implicación por su parte, pero que no necesitamos la promesa de continuidad en el proyecto más allá de ese primer alcance.
A su vez, esto significa que, por diseño, no hay conflicto de intereses con los equipos que vendrán después de nosotros, donde somos los más motivados por asegurarnos de que el equipo entrante pueda ser autónomo desde muy pronto.
En definitiva, hacer explícito desde el principio que habrá una transferencia y una desconexión es otro mecanismo donde la transparencia y la honestidad funcionan para todos los interlocutores y redunda en beneficio del proyecto.
Vale, pero ¿cómo, específicamente, ponemos todo esto en marcha?
El proyecto nace transferido
Como he señalado al comienzo, todos los proyectos de consultoría y aceleración se diseñan con la transferencia en mente. Desde las primeras conversaciones ya nos planteamos escenarios de transferencia: ¿el cliente tiene equipo para mantener y evolucionar el producto? ¿va a montar el equipo tras el MVP (Mínimo Producto Viable)? ¿cuentan con nuestra ayuda para montar el equipo?
Junto a lo más operativo, como es el equipo, también mencionamos desde el principio cuestiones estratégicas, como la creación de un gran roadmap, más allá del alcance de nuestra colaboración, para que desde el comienzo tengamos una visión compartida; este roadmap (su versión actualizada tras un año y medio de proyecto) se empaqueta para que el cliente pueda continuarlo.
Y aunque la tecnología a priori no parezca tan estratégica como el roadmap, pasa a serlo en el momento en que desde el comienzo proponemos y usamos tecnologías y formatos libres, lo que asegura que el cliente nunca va a estar sujeto por el vendor locking (imposibilidad de cambiar de proveedor) y garantiza poder explorar cualquier escenario futuro.
Estas conversaciones tan al principio también nos obligan a responder “¿por qué?”, ¿por qué es tan importante que Kaleidos se asegure una salida adecuada? Ya hemos mencionado que habilita espacios de confianza con el cliente, pero no es la única razón. Esta libertad que en todo momento garantizamos al cliente, es exactamente la libertad que nos garantizamos a nosotras mismas. No querríamos tener un cliente unido a Kaleidos por los motivos incorrectos, y desde luego no querríamos sentirnos atados a un cliente.
Además, con los ciclos de proyectos de año o año y medio, tenemos la oportunidad de actualizarnos técnicamente con frecuencia, algo que es crucial para nuestro desempeño.
Decisiones durante el desarrollo
Todo lo anterior establece un mindset que acompaña a las decisiones de diseño y técnicas. En Kaleidos desarrollamos nuestros propios productos también, así que entendemos la necesidad de que un proyecto sea sostenible. Y para asegurarnos de que sea sostenible, es importante diseñar teniendo en mente qué hipótesis hace falta validar primero y cómo hacer que una plataforma salga rápido al mercado y a la vez sea después escalable y adaptable.
De la mano del diseño, las tecnologías que elegimos para los proyectos reflejan también esta ambición de sostenibilidad. La elección tecnológica se hace respondiendo preguntas como: ¿cuál es la más adecuada para el proyecto? ¿el cliente tiene equipo propio? ¿conocen esta tecnología? ¿hay oferta profesional en esta tecnología? ¿es un lenguaje con proyección y perspectivas o todavía es the fancy new kid?
Por ejemplo, UXBOX, la plataforma de prototipado colaborativo que estamos desarrollando (echa un vistazo si quieres), está hecha con Clojure y ClojureScript. Es un stack potente y robusto, y consideramos que es la tecnología adecuada para esta herramienta; sin embargo, si tuviéramos que crear un producto para un tercero, no le propondríamos Clojure como tecnología base pues sabemos que no tiene tanta tracción como otros lenguajes y encontrar talento podría ser un problema.
Tras la elección de las tecnologías más adecuadas atendiendo a distintos factores, seguimos teniendo ocasión de asegurar una transferencia durante el desarrollo. Las buenas prácticas de desarrollo son especialmente útiles para que el siguiente que venga no tenga que navegar en el proceloso mar de las “decisiones personales difíciles de interpretar”. Procuramos usar convenciones, el lenguaje o framework de forma idiomática, bibliotecas consolidadas en lugar de soluciones propias, y desarrollar de forma que se pueda iterar.
A veces es difícil el equilibrio entre la necesidad de “salir al mercado cuanto antes para validar hipótesis” y “hacer una arquitectura que aguante distintos devenires”; precisamente en la búsqueda de este equilibrio nos sentimos cómodos; si bien entendemos que a veces toca sacrificar una visión tecnológicamente más robusta, en otras ocasiones nos aseguramos (con vehemencia incluso) de que se respetan ciertas pautas, para que esos futuros desarrolladores no se encuentren ante callejones sin salida.
Transferencia de calidad
Finalmente, cuando nuestra colaboración está por terminar, insistimos mucho en tener sesiones técnicas con el equipo de desarrollo; no hay documentación que pueda mejorar la experiencia de tener a los equipos saliente y entrante resolviendo historias de usuario en paralelo, funcionando como un solo equipo.
En este escenario se transfiere el conocimiento, los caveats, las razones detrás de las decisiones, y también se transfiere metodología y conocimiento del dominio; todo esto representa un boost de implicación y productividad en el equipo entrante difícilmente sustituible.
Creemos que es muy importante que exista un equipo al que transferir, tanto dirección como desarrollo, y es en esta segunda parte donde típicamente hemos sido más útiles. Nos hemos implicado desde algo ligero como recomendar una configuración de equipo ideal para continuar con el proyecto en la siguiente fase, hasta en los procesos de selección del equipo entrante. Es una labor intensa e interesante en la que podemos ayudar a encontrar al equipo que mejor heredará el proyecto.
No siempre nos encontramos con la situación ideal de tener un equipo formado y funcional al que entregar un producto ya en producción; en estos casos, hacemos especial hincapié en cerrar funcionalidades abiertas y pulir muy bien, para garantizar que el servicio aguanta bien los primeros meses que echa a andar.
Con independencia del escenario de transferencia de equipo, también nos aseguramos de una transferencia de la idea. A pesar de que no fue originalmente idea nuestra, a estas alturas de la colaboración, solemos tener una visión del producto y su potencial, y la podemos conectar muy bien con nuestra experiencia poniendo ideas en el mercado. Esta entrega puede tener distintos formatos: desde historias de usuario conectadas con la visión del roadmap, hasta pantallas de inspiración de por dónde se podría continuar. Nuestros clientes también encuentran muy útiles los materiales de diseño que se pueden usar para las siguientes fases de financiación.
En definitiva, en esta fase entregamos repositorios de código, problemas detectados y visión, documentación, diseños a medio y largo plazo, materiales más de inspiración; el objetivo es que el cliente y su equipo se sepan realmente autónomos para seguir tomando decisiones desde este momento.
Problemas
Si bien esta aproximación tiene muchas ventajas para nosotros, no está exenta de ciertas contrapartidas:
muchas veces nos toca desconectar en el momento más dulce del proyecto; cuando hemos cogido velocidad de desarrollo y tenemos el foco total; cuando ya hay una versión en producción con la que un equipo de ventas puede “hacer su magia”, y el equipo de desarrollo puede coger aire de nuevo y mirar más allá. Hay un gran disfrute en desarrollar a buen ritmo sabiendo que se tiene el control.
alguna vez nos ha pasado que hemos tenido que retrasar nuestra salida para asegurarnos de hacerla bien y porque forzar nuestra salida (aunque estuviera legitimado) nos parecía irresponsable; por ejemplo, si el cliente no ha podido conseguir el equipo al que transferir, o está todavía en el proceso. De alguna manera, también tenemos una dependencia de que este proceso se haga bien, para que podamos dar la etapa por cerrada y saltar al siguiente proyecto sin arrastrar cuestiones parciales.
Conclusión
La desconexión es un momento importante dentro de un proyecto, que merece tiempo de calidad y total transparencia. Al final de un proyecto, el cliente puede sentir vértigo por el cambio total de contexto y responsabilidad, ya que Kaleidos típicamente “se mete hasta la cocina”. Así que es vital para el futuro de los proyectos que aseguremos las vías para tal continuidad. Nada de esto se puede improvisar, hay que prepararlo con tiempo y dedicación, y tenerlo en cuenta durante todas las fases del diseño y del desarrollo.