Muchas veces nos habréis escuchado decir que la tecnología siempre debe ser un medio y nunca un fin. También nos habréis escuchado en muchas ocasiones hablar de «la metodología» de iCarto en los proyectos, que hacer software no es sólo desarrollarlo y ya está, que para que la implantación de ese software sea un éxito hacen falta muchas más cosas… pues bien, hoy es el día en el que vamos a intentar explicar nuestra metodología.
El contexto es el contexto
Hace ya bastante tiempo que en iCarto venimos trabajando con lo que se denominan organismos multilaterales. Estas entidades financian proyectos orientados al desarrollo en diversos países. En este tipo de proyectos hay diferentes actores: el organismo en sí, que financia y controla el desarrollo del proyecto; la entidad final para la que se hace el proyecto, normalmente pública o gubernamental, que es la que tiene una necesidad a resolver; y como no, iCarto, quienes nos encargamos de desarrollar la solución.
Al final todo se reduce a tratar de entender cuál es la necesidad o problemática, a veces hasta conseguir que la propia entidad la entienda, y luego ir dando pasos de la mano para conseguir llegar a una solución. El hecho de trabajar directamente con una entidad o hacerlo a través de un organismo multilateral añade algo más de coordinación en el proyecto, pero no afecta tanto a como enfocarlo (la metodología).
De la misma forma, cuando trabajamos directamente para entidades, públicas o privadas, que tienen una necesidad o que creen que la tecnología puede mejorar sus flujos de trabajo y sus procesos, la situación es muy similar. Muchas veces dentro de las organizaciones se sigue un flujo de trabajo por sistema, y cuesta encontrar el espacio para analizarlo y ver si se puede optimizar. Nuestro trabajo suele empezar por ahí, tratando de entender los procesos internos y ayudando a mejorarlos. La tecnología siempre viene después, como una herramienta que ayuda a implementar la solución diseñada.
Conocimiento del dominio
Lo que sí afecta mucho es el conocimiento sobre el dominio del proyecto. Aunque somos una empresa de desarrollo de software, no hacemos cualquier cosa. Normalmente, trabajamos con entidades de sectores que dominamos, relacionados con la Ingeniería Civil (carreteras, agua…). Este conocimiento del sector es importante tanto para entender bien la problemática como para ser capaces de proponer soluciones, que más allá del mero uso de tecnología, cambien también los procesos.
En iCarto somos una mezcla entre personas expertas en desarrollo de software y en ámbitos de la ingeniería civil. Esta configuración y la relación que hay entre estos dos tipos de perfiles daría para un post en sí mismo, así que no nos vamos a extender ahora. El resumen es que ha habido también un gran proceso interno para que desde un lado y otro haya entendimiento y los mundos confluyan. Todas las personas en nuestro equipo tienen que entender, al menos, los principios básicos de como se desarrolla software y también como acercarse al entendimiento de las necesidades de otras ingenierías.
Por todo esto elegimos trabajar en proyectos en los que no actuamos como una mera empresa tecnológica, sino en aquellos donde conocemos el dominio y creemos que seremos capaces de ofrecer un plus, además de la tecnología.
La metodología
Si sabes como hacerlo, desarrollar software es la parte fácil. Conseguir que ese software resuelva un problema, mejore un proceso y las personas que lo usan se apropien de él es el reto de verdad.
Desde el punto de vista técnico, nuestra metodología de trabajo no tiene mucho de especial. Más allá de nuestra elección sobre el stack tecnológico con el que solemos trabajar, nuestra metodología de desarrollo entraría dentro del agilismo, si bien no usamos ningún marco de gestión estrictamente (léase scrum, lean, etc.). Abrazamos la incertidumbre, creando productos poco a poco, poniéndolos en producción asiduamente y validándolos con quienes los usarán en el día a día. Aplicamos prácticas sueltas de marcos de gestión, que vemos interesantes y que nos funcionan, pero no hemos encontrado «el marco» que nos encaje al 100%. Esto igual también daría para otro post en sí mismo… ¿El marco de gestión de proyectos ágiles de iCarto? Quizás…
El punto clave de nuestra metodología pensamos que está más en la relación con los clientes. Las dos palabras que más nos gustan son acompañamiento y fortalecimiento. En muy pocos casos una organización tendrá muy claro lo que quiere y te dirá: desarróllame esta aplicación así. Lo normal es que como mucho tenga una ligera idea de a dónde quiere llegar, pero no tenga claro como hacerlo ni que pasos son necesarios por el camino. Nos encanta ayudar a descubrir esos pasos, apropiarnos del problema y acompañar a las entidades en su camino. Esto implica un gran esfuerzo de comunicación, que se traduce en inversión de horas para hablar. Hablar con quien dirige para que se involucre en el proceso, pero sobre todo con quien hace, conocer su día a día, su contexto, y pensar en soluciones que se adapten a ello.
Tradicionalmente, un proyecto de desarrollo de software suele tener varias fases: la definición de requisitos, el desarrollo en sí de la solución, la implantación del sistema con formación a las personas sobre cómo se usa, etc. Las metodologías ágiles mejoran esto, los requisitos se van moldeando de forma iterativa, la implantación es progresiva… pero casi siempre se suele dejar la parte del uso para el final con alguna formación de un par de días, con suerte un poco más. Aquí es donde entra el otro concepto que nos encanta, el fortalecimiento, y su gran aliado: Las fases.
Las fases
Nos encanta hacer proyectos por fases. No creemos en las soluciones, cuasi mágicas, que resuelven todo de golpe. Nos encantan los proyectos, y si echas un vistazo a nuestros casos de éxito lo verás, que tienen muchos números distintos después del nombre y en los que cada número representa una fase. Hablábamos antes sobre el contexto, y decíamos que nos gusta trabajar en proyectos donde además del expertise tecnológico, podamos aportar nuestro expertise sobre el dominio. Aquí es donde las fases nos ayudan y mucho. En muchas ocasiones es necesario un fortalecimiento de las organizaciones, ya que no solamente necesitan o les viene bien una solución tecnológica, sino que también necesitan mejorar sus procesos. Muchas veces nos hemos encontrado con que necesitamos hacer una fase con poca tecnología y mucha mejora de sus procesos internos, aportando nuestro conocimiento para formar a las personas y que se apropien de nuevas técnicas de gestión. A partir de ahí, crear tecnología y que se apropien de la misma, será un poco más fácil. A este proceso le llamamos fortalecimiento.
Corolario
Todo esto no es un proceso sencillo y mucho menos rápido. Muchas veces cuesta entender esto, porque al final todo el mundo quiere o necesita resolver un problema lo antes posible. Desarrollar una solución tecnológica y entregarla puede ser más o menos rápido, según la complejidad de la misma. Pero eso no implica que el problema esté solucionado. Implantar tecnología en una organización siempre implica un gran cambio a muchos niveles. Las personas por norma general somos reticentes a los grandes cambios, nos lleva un tiempo aceptarlos, ver las ventajas, encontrar la manera de ajustar los procesos, etc.
Si todos estos problemas surgen de golpe, al final del proyecto y después de haber implantado la solución tecnológica, lo que suele suceder es que esta se termina abandonando y se da por fallida. Sin embargo, cuando encontramos entidades que entienden la complejidad real del proceso y nos dejan ayudarlas a construir la solución poco a poco, los problemas van aflorando paulatinamente, se van afrontando, y el éxito del proyecto es mucho mayor.
Es por todo esto que decimos siempre que la tecnología debe ser un medio y nunca un fin. Nos debe ayudar a ir resolviendo problemas, no crearlos. La mejor tecnología no es ni la más espectacular, ni la más novedosa, sino la que mejor se adapta a cada caso.