7 minutos con Gerard Plans

Existe una generación de expertos en software que trabajan co-creando herramientas con el usuario final y que se obsesionan en ofrecer productos realmente relevantes y que agilicen de verdad la operativa. Tengo la suerte de conocer a Gerard Plans, que es uno de ellos. Es un verdadero maestro en .NET, la plataforma de Microsoft para desarrollar soluciones que permiten agilizar integraciones entre empresas y facilitar el acceso a la información. Gerard es además un freelance acérrimo, acostumbrado a trabajar en industrias tan distintas como retail o pharma. Su foco es crear soluciones en tiempo récord que permitan dejar atrás sistemas caducos (el famoso legacy) de modo que IT se convierta en un verdadero aliado de las operaciones y funcione al ritmo de las necesidades del usuario final.

En un momento donde simplificar e innovar a nivel global es clave para que las organizaciones no solo prosperen, sino para que sobrevivan, ¿cómo puede inspirarnos el proceso de pensamiento lógico de un ingeniero experto en software?

1.¿Cuál es el proceso que sigues cuando empiezas un proyecto?

El primer paso siempre es conocer qué tipo de sistema de trabajo tiene la organización en general: sus clientes, sus objetivos, su cultura. Una vez tengo la visión general, es el momento de conocer cómo trabaja IT y el método que utilizan. A partir de aquí, el resto del proceso depende mucho del tipo de empresa y su tamaño. En empresas grandes y complejas, el enfoque es algo más conservador en el momento de plantear cambios, ya que, si los procesos funcionan, a priori no ven la necesidad de cambiarlos. La misión la mayoría de veces parte de empezar a introducir mejoras en el programa con el que pueden llevar 20 años trabajando (legacy). Los equipos de IT son más grandes, no te relacionas directamente con el usuario final, sino con managers y al final se trabaja con un enfoque no tan creativo y más centrado en el mantenimiento y la mejora.

Las empresas más pequeñas tienen un enfoque más audaz. Son el escenario ideal para interactuar directamente con el usuario final y ser creativo, programando sin intermediarios.

2.¿Cómo involucras al usuario final en tus desarrollos?

Personalmente, me gusta trabajar 1 to 1 con la persona que viene a hacerme la petición: acompañarla en su día a día, que me cuente directamente observando en su pantalla qué hace o qué necesita … Así puedo también ver si es posible crear una solución que vaya incluso más allá de lo que me está pidiendo el usuario. Todo parte de una necesidad. En muchas ocasiones, el usuario viene algo cohibido a realizar la petición porque no ha tenido buenas experiencias anteriormente. Por otro lado, al no tener experiencia en programación, el usuario tampoco sabe lo que puede llegar a pedir.

Siempre, tras pasar tiempo con la persona viendo la realidad de su trabajo, le pido que me haga “la carta a los Reyes” y que me establezca unos máximos. A partir de aquí voy viendo cómo crear lo más rápido posible la solución.

Este trato tan directo con el usuario solo pasa en las organizaciones más planas. Cuando la empresa es jerárquica, es casi imposible trabajar de este modo, desgraciadamente. En ese caso, mis interlocutores ya no son usuarios finales sino managers o responsables de proyecto.

3.¿Qué relación existe entre cómo está estructurada una empresa y el tipo de plataforma que solicita?

El software utilizado refleja la cultura y ritmos de una organización. Las empresas grandes piensan en grandes plataformas. Tienen muchos clientes internos y cada uno es distinto, con necesidades distintas, así que para ellos es necesario acotar y agrupar soluciones. Cada departamento ha ido utilizando históricamente sus propios sistemas, y al final lo que se busca es un único sistema que pueda responder a todas las necesidades. Existen varias y famosas herramientas en el mercado orientadas a este objetivo, pero la realidad es que estas grandes plataformas encajan en áreas donde las dinámicas son estables o muy procedimentadas, pero no son realmente útiles en entornos donde se requiera flexibilidad y rapidez, ya que su respuesta no es real time: requiere permisos, confirmaciones, verificaciones, etc. que ralentizan su operatividad. Por otra parte, la inversión en tiempo y dinero para este tipo de plataformas es considerable y no siempre tiene el retorno en eficacia esperado.

Las empresas más pequeñas o de organización más flexible representan el caso contrario. Buscan plataforma que les den soluciones real time, que no representen ningún freno burocrático o conceptual. Para ellas, el software debe ser simple y dinámico para poder mantener su agilidad. En muchos casos trabajan o bien con un programa hecho a medida según sus necesidades o bien con una serie de herramientas que se adaptan perfectamente a lo que necesita cada cliente y se integran entre ellas.

4.¿Cuáles son los principales puntos a tener en cuenta para dejar atrás un modelo legacy?

Es importante tener en cuenta, cuando tu objetivo es evolucionar más allá del software legacy, que la empresa lleva años, incluso décadas, trabajando con ese sistema. Sin duda, tiene muchas áreas de mejora y limita la operativa de la empresa, pero a ojos del usuario, es algo que funciona y es fiable a pesar de sus limitaciones. Así pues, debemos encontrar una manera para empezar a demostrar a la organización las ventajas de otro tipo de software sin “asustarla”.

Es un proceso paulatino de constante work in progress. Es decir, no se pasa de un modelo legacy a uno nuevo de un día para el otro.

Para ello es muy recomendable trabajar con lo que llamamos una Proof of Concept (POC). Consiste en, de manera totalmente paralela y aislada del software que funciona en ese momento en la compañía, crear una propuesta de sistema que cubra una determinada funcionalidad y represente una gran mejora respecto a lo que el software legacy esté ofreciendo en esos momentos. Por supuesto, es necesario tener una perspectiva global y entender muy bien la organización y sus necesidades para que la POC resulte realmente sexy y supere las expectativas de los sectores más reticentes. Plantear y desarrollar una POC requiere pues creatividad y visión sistémica. Una vez presentada la POC, y si ésta es convincente, se convierte en lo que llamamos un MPV (Mínimo Producto Viable), es decir, se prototipa y se convierte ya en una funcionalidad operativa que podemos empezar a evolucionar una vez se pone en marcha. Y así, hasta que vamos cubriendo y ofreciendo versiones mucho más eficaces y útiles de las funcionalidades del sistema legacy, de manera que llega un momento en el que, de modo natural y sin romper la operativa, tienes el 100% del nuevo software en funcionamiento y el antiguo queda en segundo plano hasta su desvinculación.

5.¿Qué herramientas o métodos habituales en el entorno IT pueden ser útiles a otras disciplinas para simplificar y agilizar roles, estructuras, procesos …?

Actualmente ya se está hablando del impacto positivo que la cultura Agile, que es una manera de pensar muy vinculada al desarrollo de software, tiene en la globalidad de la organización. Sin embargo, es importante tener en cuenta que la mentalidad Agile existe desde antes de que le pusiesen nombre: en resumen, se trata de aplicar un sentido lógico y práctico a todo y evitar el exceso de niveles y estructuras que dificultan lo principal: crear soluciones útiles y relevantes para el usuario final.

Como conceptos, herramientas y ceremonias fácilmente aplicables a todas las áreas de la organización veo claramente, además del ejemplo con la POC que os comentaba en la pregunta anterior, incorporar scrum o kanban vinculado a desarrollar más rápidamente productos y herramientas incorporando al usuario final a lo largo del proceso. También veo muy recomendable inspirarse en algo que practicamos mucho en el mundo de desarrollo de software, que es el pair programming o programación por parejas. Es un método muy interesante donde dos personas de distintos roles trabajan directamente con un único ordenador desarrollando una propuesta. Durante el mismo desarrollo, van intercambiando los roles. Es un enfoque muy interesante para obtener herramientas más completas, ya que están hechas desde distintas visiones, y para que los perfiles no trabajen encasillados en un único rol, lo que nos hace más flexibles y productivos.

¡Muchísimas gracias por compartir tu perspectiva con nosotros, Gerard!

1 Comment
  • Caco Martín

    31 mayo, 2020 at 10:59 am Responder

    Muy interesante su enfoque, coincido con él. Cuando desarrollo / diseño webs siempre me meto debajo de la piel del emprendedor o empresa para descubrir oportunidades y soluciones.

    Gracias a darnos a conocer a Gerard!

Post a Comment

Únete a la
COMUNIDAD SHAKER
¡Estaré encantada de mantenerte al día!
APÚNTATE
close-link