Categorías
Metodología

Reuniones efectivas #NoMeetings

Mantener el foco es uno de los elementos más importantes para conseguir cualquier objetivo. La hiperconectividad, la necesidad de inmediatez en tener respuesta o resultados, son algunos de los elementos que nos generan un ruido inmenso en el camino para conseguirlos.

Un reflejo de este síntoma lo encontramos en el volumen de reuniones poco efectivas que inundan las agendas de todo el mundo. Cuanto más grande sea la compañía, mayor tiempo de dedicación será necesario a las reuniones.

Pero este problema ya pasaba antes de la pandemia, el efecto COVID solo lo ha agravado al poder realizar facilmente muchas más reuniones en el mismo margen de tiempo.

Reunirse no es malo en si mismo, al contrario, favorece la comunicación y el crecimiento de ideas, el problema está en la poca efectividad de la reunión. “Qué hemos conseguido al finalizar la reunión?” seguramente muy poco, en la mayoría de los casos será necesario otra reunión adicional para continuar hablando de los mismo. Pensemos que, por ejemplo si en una reunión hay 3 personas durante una hora, esto tiene un coste para la compañía, si a esto le sumamos las múltiples reuniones que pueda tener una persona a lo largo de la semana, el coste se dispara…

Y si el coste invertido tiene su efectividad, puede tener sentido, sin embargo, el problema viene cuando reunirte con otros se convierte en tu trabajo y apenas tienes tiempo para dedicarle a las tareas relacionadas con tu rol, que son realmente las importantes.

La mala gestión de las reuniones es sin duda un síntoma de la mala gestión del tiempo de una persona. Y es esto lo que nos hace perder el foco de lo realmente importante.

Para mejorarlo, tendremos que empezar por gestionar mejor nuestro tiempo, principalmente priorizando la agenda y haciendo efectivas las reuniones.

Nuestra agenda es un reflejo de a lo que realmente estamos poniendo foco, estar siempre reunido no es bueno, no tener tiempo para dedicarle a las tareas en las que aportamos afecta a nuestro resultado final. Estar en todas las reuniones sin aportar ni que te aporten tampoco ayuda. Nuestra compañera Macarena Sirera ha estado impulsando en el equipo la optimización de las reuniones para ser más efectivas, para lo que propone diferentes medidas del movimiento #NoMeetings.

Por un lado, debemos trabajar en la preparación de la reunión de manera que:

  • Empecemos a seleccionar las reuniones a las que realmente nos aportan o podemos aportar. No tengamos miedo a rechazar reuniones.
  • La gestión del calendario debe estar orientada a alcanzar nuestros objetivos semanales y anuales. Ayuda utilizar colores en la agenda para diferenciar la importancia o el propósito de las reuniones.
  • Fijar por adelantado huecos consecutivos para reunirte y otros para realizar tus tareas ayuda muchísimos, no hay nada peor que los cambios de contexto.
  • Exijamos que el convocante tenga una agenda y un objetivo, tengamos claro para que es la reunión y que queremos conseguir al final. Aseguremos que está bien marcado los temas a tratar para no divagar.
  • Exijamos al convocante que el tiempo de duración sea el mínimo posible, “Menos es más”.
  • En modelo de trabajo remoto, exijamos que no acabe en bloques de media hora, por ejemplo que duren 25 minutos o 50 minutos, de este modo tendremos tiempo para chequear el correo antes de la siguiente reunión o levantarnos, lo que ayudará a mantener el foco en la reunión.
  • Exijamos puntualidad, tanto para llegar a la reunión, como para terminarla. Y en caso de llegar tarde, avisar ayuda al resto 😊. En mi caso, si el convocante llega tarde y no avisa en 5m, salgo de la reunión.

Durante el transcurso de la reunión:

  • Debemos asegurarnos que se respeta la agenda.
  • Si la reunión no se ha preparado anteriormente, si no se lleva algún documento, la idea trabajada o no hay nada que enseñar, es síntoma de una reunión en la que se va a divagar. Aplacemos la reunión, no pasa nada. También ayuda mucho enviar la documentación antes para que haya oportunidad de leerla.
  • Exijamos puntualidad, la agenda ayuda a marcar esos tiempos, si quedan 5 minutos, es tiempo de ir a las conclusiones y siguientes pasos.
  • Grabar las reuniones no sirve de nada para el que no va, es muy complicado sacar tiempo para ver una grabación de una reunión a la que no has podido ir…
  • Al finalizar la reunión, compartamos las conclusiones y tareas en caso de tener que hacer seguimiento. Por ejemplo, respondiendo sobre el appointment con lo acordado.

En definitiva, hay muchas técnicas para mejorar la gestión del tiempo, pero la más importante empieza por nosotros mismos por luchar para mantener el foco.

Categorías
Estrategia digital Metodología

10 pasos para implantar un modelo de gobierno para soluciones Low Code

Para implantar nuestro modelo de gobierno debemos tener en mente estos pasos básicos:

  1. Entender en qué nivel de madurez nos encontramos.
  2. Identificar el modelo que encaja en nuestra organización.
  3. Definir un modelo de gobierno “inicial” según madurez.
  4. Identificar las herramientas para implementar el modelo.
  5. Dimensionar el equipo y modificar los procesos operativos de TI.
  6. Definir métricas de éxito del modelo de gobierno y adopción.
  7. Comunicar el modelo a los diferentes perfiles.
  8. Acompañar a los usuarios y recibir feedback.
  9. Monitorizar el comportamiento.
  10. Ajustar el modelo y comunicar cambios.
Categorías
Metodología Estrategia digital

De Proyecto de software a Producto Digital

Desde hace unos años existe una tendencia en las compañías de aprovechar los recursos destinados a un proyecto de software internos para convertirlos en un producto digital. Los motivos son variados, algunas compañías intentan abrir nuevos modelos de negocio, otras rentabilizar la inversión realizada o incluso ofrecer la misma calidad al usuario interno que la que se ofrece a un cliente final. Según Sriram Narayan en el artículo “Products Over Projects”, entre las ventajas organizativas que encontraríamos al orientar un proyecto en producto se encuentran:

  • Habilidad en adaptación rápida.
  • Reducir los ciclos de tiempo End-to-end.
  • Ser capaces de iterar.
  • Integridad de arquitectura.
  • Construir equipos motivados y con un propósito.

Pero “¿Qué factores diferencian a un proyecto de un producto?. Se podría decir que un producto parte como un proyecto que pretende resolver un problema, pero con el objetivo de poder “utilizarse” para diferentes clientes a lo largo del tiempo. De ahí que las nuevas funcionalidades de los productos se centren en resolver problemas o aportar valor al mayor número de clientes posibles, en lugar de a un área de negocio o departamento concreto como podría ocurrir en un proyecto. Pero cuando hablamos de enfocar el proyecto para que pueda “reutilizarse” no estamos hablando de construir un framework o plataforma con la que poder hacer más proyectos, si no el de orientar todas las funcionalidades y arquitectura a un propósito más global sobre el que poder definir un modelo de servicio.

Valor o funcionalidad

Cuando se implementa un proyecto para uso interno, las funcionalidades se enfocan en resolver la problemática de nuestro cliente interno, puede haber más o menos usuarios, pero solo debemos preocuparnos de un único cliente. Sin embargo, al crear un producto tendremos la necesidad de cubrir las problemáticas de diferentes tipos de clientes, cuanto más amplio sea el sector al que vaya dirigido el producto, mayor complejidad tendremos para poder cubrir las diferentes casuísticas. Con un producto, orientaremos las funcionalidades al valor percibido en lugar de a otros factores más relacionados con optimización de costes o resolución de problemas.

El valor percibido es un concepto curioso, que depende en gran medida de cómo perciben los clientes nuestro producto o una funcionalidad más que en su comportamiento o prestaciones. El valor percibido podría decirse que son todos aquellos elementos o características por las que un cliente adquiere o sigue utilizándolo nuestro producto. Para una misma funcionalidad, el valor percibido puede ser muy diferente por clientes diferentes. Unos, pueden apreciar más la capacidad de uso, otros, su rendimiento, otros valorarán el precio y otros, simplemente por la marca.

Es un error muy común creer saber lo que quiere el cliente, pensar que una nueva funcionalidad pueda ser percibida por los usuarios como algo muy útil requiere de objetividad, de cifras. Con un proyecto, la percepción se basa en recoger el feedback de un grupo limitado de usuarios, pero con un producto, se hace complicado conocer la percepción de todos los clientes. Durante mucho tiempo se han utilizado mecanismos para recoger feedback como puedan ser las encuestas o focus groups para determinar si una funcionalidad tendrá un impacto importante en los usuarios, pero se ha demostrado que los usuarios no se comportan igual en contextos en los que se sienten observados que en su entorno habitual. Es por eso que recurriremos al uso de herramientas de monitorización con las que poder medir el comportamiento de los usuarios, conocer las funcionalidades más utilizadas, cómo las utilizan o para qué las utilizan. Por tanto, a la hora de lanzar nuevas funcionalidades, es recomendable enfocarlas como un MVP sobre el que observaremos el comportamiento y aceptación de los usuarios para decidir si darle continuidad o bien modificar la funcionalidad inicialmente ideada.

Cuando un producto se inicia exclusivamente para uso interno, ¿cuál será el valor percibido entonces por nuestro cliente interno?. En este caso, una opción sería operar todo el proyecto como si se tratara de un cliente externo, desde el principio hasta el fin. De este modo, no solo nos centraremos en la implementación del producto, también en toda la operativa necesaria en los procesos de definición de producto, acciones comerciales y la post-venta/soporte. La clave también puede estar en conseguir que el Product Owner pertenezca a un área/departamento diferente del cliente interno, de manera que pueda tener una visión más amplia del producto al no tener una dependencia directa del área interna.

La figura del Product Owner y Product Manager

En un producto toma especial importancia la figura del Product Owner (PO) o Product Manager (PM), a la hora de priorizar e identificar nuevas funcionalidades orientadas a aportar valor, sobre todo, a entender el proceso. Un proceso basado en la experimentación, la medición y el incremento iterativo. El PO/PM no solo debe conocer el negocio, también debe entender las diferentes metodologías.

El PO deberá ser el mayor defensor del producto, un PO poco motivado no luchará por asegurar la continuidad del producto, que no se quede en un mero proyecto. En una corporate el PO deberá “pelear” con los diferentes procesos de la compañía para conseguir captar presupuesto, lanzar campañas de marketing, definir los procesos de soporte, … y lo más importante de todo, que la dirección entienda el valor del producto para que le den el apoyo necesario.

El PO también se encargará de participar en la definición del roadmap. El roadmap es una herramienta muy útil con la que compartir con los diferentes stackeholders la visión del producto. Un buen roadmap ofrecerá la visión en diferentes contextos: estrategia de negocio, funcional y técnico.

La captación de presupuesto en una corporate dependerá en gran medida de los resultados obtenidos durante el año anterior, por lo que suele ser complejo hacer entender a la dirección un modelo basado en la experimentación. El PO deberá trabajar entonces muy de cerca de la dirección para ayudar a traducir los procesos y la estrategia a los resultados. Disponer de un roadmap realista y con diferentes visiones facilitará la aprobación de presupuestos para las diferentes fases.

Por el contrario, la aprobación de presupuesto en un proyecto estará acotado a unos objetivos definidos en fases previas a su implementación a partir de business case que, en la mayoría de los casos diferirán de la realidad una vez puesto en marcha.

Metodologías

Existen diferentes metodologías y marcos de trabajo que podemos aplicar a nuestro producto para cada una de las fases en la que nos encontremos. Personalmente me encanta el concepto de Lean Startup, con el que ofrecer valor al cliente lo antes posible con el mínimo de desperdicio, utilizando un proceso de experimentación, medición y aprendizaje.

Si bien Lean Startup puede ser el marco principal, podemos aplicar otras metodologías como Design Thinking para idealizar y definir nuevas funcionalidades o SCRUM/KANBAN para la implementación de las features.

Cualquiera de los marcos que escojamos deberá ir en consonancia con el roadmap, la dirección o los inversores querrán entender cómo se están invirtiendo los recursos.

Estrategia de negocio

Otra complejidad adicional que tiene producto frente a un proyecto es la necesidad de definir una estrategia de negocio. No basta con tener una buena idea o realizar la mejor implementación técnica, construir un producto requerirá tener en mente aspectos como:

  1. El mercado
  2. En qué nos diferenciaremos del resto de producto.
  3. A qué público está dirigido.
  4. Modelo de uso
  5. Modelo de pricing.
  6. Modelo de distribución.

Estos aspectos determinarán en gran medida el grado de penetración de nuestro producto en el mercado. Podremos tener el mejor producto del mercado, pero si no tenemos una buena propuesta adaptada al mercado y el público objetivo, no seremos competitivos.

Como primer punto, trataremos de entender el mercado al que irá dirigido nuestro producto/servicio, identificando la competencia y su estado, las barreras de entrada, la tipología de clientes, … Lo ideal es que nos centremos en mercados similares al core de nuestra compañía o a nuestro expertise. Algunas compañías intentan diversificar mercados creando nuevos productos en mercados en los que no son expertos, lo que aumenta el riesgo a no entender las verdaderas necesidades del mercado y sus problemáticas.

En ciertas ocasiones puede ocurrir que nuestro producto no encaje en ningún mercado existente, puede que no exista debido al grado de innovación de nuestro producto, en lo que se denomina un océano azul. Este será el escenario ideal, aunque muy pocos son capaces de conseguirlo.

El siguiente punto será definir los elementos por los que nos diferenciaremos del resto de productos del mercado: en costes, precio, funcionalidad, eficiencia. Si por ejemplo decidimos ser competitivos a nivel de prestaciones funcional, será complejo que podamos competir en precio. Si por el contrario decidimos ser líderes en precios, no seremos los mejores en eficiencia o innovación. Cualquiera de las opciones serán válidas siempre que nos especialicemos en una de las áreas, dar cambios bruscos en la estrategia puede provocar que no se entienda nuestra propuesta de valor.

Conocer el público al que va dirigido (segmentación) asegura un mayor impacto en las acciones comerciales y de captación. Con el lanzamiento de un nuevo producto no podemos pretender llegar a todas las tipologías de clientes potenciales, siendo preferible comenzar identificando un conjunto de potenciales clientes muy reducido, pero muy asequible (que conozcamos bien, cercano,…), con el objetivo de validar nuestra propuesta antes de escalar al resto de sectores. En los productos digitales la clave estará en conseguir escalar a un coste reducido, pero debemos hacerlo en el momento adecuado.

Otro factor importante que tendrá implicaciones técnicas,de soporte y distribución será decidir el modelo de uso de nuestro producto, como SaaS, suscripción o adquisición.

El modelo de pricing (tiered pricing) ayudará a entender mejor nuestra oferta. Existen diferentes estrategias de pricing en productos digitales, pero lo realmente importante será tener una propuesta clara unida a la estrategia y la operativa.

Por último, quedaría por definir un modelo de distribución con el que podamos ampliar nuestra fuerza de venta, pero sin perder nuestros estándares de calidad y valores. En productos maduros es común apoyarse en un modelo de partners, que aunque puede tener sus ventajas a la hora de escalar, debemos asegurarnos de haber construido antes un buen plan que permita al partner entender el producto, que entienda los mensajes y los valores.

El ciclo de vida

El ciclo de vida de un proyecto es muy diferente al de un producto, la principal diferencia radica en cómo varía los modelos de adopción a lo largo del tiempo. Si en un proyecto debemos enfocarnos en que los usuarios entiendan las funcionalidades y la incorporen en sus procesos, en un producto, el proceso de adopción dependerá del momento de vida del mercado en el que nos encontremos, siendo los early adopters los primeros usuarios que aceptarán un producto incompleto con la ventaja de ser los primeros en poder utilizarlo (fase de introducción). A medida que avance la penetración del producto en el mercado evolucionará a las fases de crecimiento, madurez hasta terminar en el declive.

The Product Life Cycle: A Guide from Start to Finish | Geile/Leon Marketing  Communications
Ilustración de assignmentpoint.com/business/marketing-business/product-life-cycle.html

La continuidad del producto

Una vez puesto en marcha un sistema comienza la fase de explotación, fase en la que deberemos dedicar recursos a mantener el sistema en funcionamiento. En el caso de un producto, existen varios factores adicionales relacionados con el servicio post-venta del cliente que debemos tener en cuenta como:

  • Soporte a clientes finales: es necesario un soporte 24×7? Qué tipo de herramientas de ticketing utiliaremos para el siguiemiento de los casos de soporte?, cómo se pondrá un cliente en contacto con el servicio de soporte? Se atenderán dudas funcionales? Existirá un sistema de KB?, …
  • Cumplimiento de SLA: cuáles serán los niveles de servicio que ofreceremos? Niveles de disponibilidad?, qué tiempo de resolución de incidencias dispondremos?, cuáles serán las contraprestaciones en caso de incumplimiento?, qué sistemas de contingencia dispondremos?, …
  • Niveles de calidad del servicio: cómo mediremos la calidad del servicio ofrecido en su conjunto?, qué mecanismos de control introduciremos para mantener los niveles mínimos definidos?

Métricas

Los KPIs de rendimiento para un proyecto se centran principalmente en la velocidad de los equipos a la hora de hacer el delivery de nuevas funcionalidades y de la calidad de las mismas. Sin embargo, en un producto, las métricas suelen estar orientadas a cómo se comporta nuestro producto, desde un punto de vista de ventas, adopción, retención y calidad del servicio.

Las métricas estarán my asociadas a la estrategia elegida, no siempre será importante el volumen de clientes nuevos, factores como el churn rate, el valor del ticket medio y coste de adquisición serán indicadores con los que tengamos que jugar para entender lo que está sucediendo.

Crear producto desde una corporate

El tipo de compañía puede afectar en gran medida a la evolución y ritmo del nuevo producto. Podemos pensar que solo las compañías de tipo “startup” son las únicas que pueden crear producto, pero son las compañías consolidadas en un mercado o corporate las que realmente tienen muchas posibilidad de crear nuevos productos/servicios sobre mercados existentes.

Sin embargo, la creación de nuevos productos en corporates debe cumplir con los procesos definidos en la casa, cuanto más grande sea la compañía, mayor complejidad nos encontraremos. Esto puede afectarnos a aspectos como: aprobación de presupuestos, promoción del producto, niveles de seguridad, definición de SLAs o acuerdos comerciales.

Por otro lado, la apuesta de las coporate por la creación de nuevos productos sirve como mecanismo de innovación en la compañía, fuerza a abrir nuevos modelos de negocio con el objetivo de diversificar o afianzar una posición. Algunas compañías deciden apostar por la creación de producto in-house, es decir, con personal propio, lo que conlleva un mayor esfuerzo por la cantidad de procesos necesarios para construirlo. Otras, sin embargo, invierten en colaboraciones/compras de startups, pequeñas soluciones con un gran potencial dentro de la estrategia de la compañía que pueden desarrollarse inicialmente fuera de la compañía para ser absorbida posteriormente se haya validado el modelo.

Categorías
Metodología

Lecciones aprendidas al aplicar metodologías ágiles en un proyecto de implantación ERP

Estas son algunas de las  reflexiones que hemos compartido en el pasado #beERDays bajo la perspectiva inicial de la charla del pasado D365 Saturday, donde ya comentábamos las opciones de aplicar SCRUM en un proyecto de Dynamics 365, pero ahora con la experiencia de aplicarlo en un proyecto más amplio en #Aenor.

Y es que en muchas ocasiones nos encontramos con que durante la fase comercial, se ha vendido la magia de las metodologías ágiles mediante una serie de slides, que rara vez los decisores entienden en profundidad lo que conlleva. Es aquí, dónde me gustaría comenzar la reflexión, en el momento de empezar el proyecto, cuando el equipo se encuentra con debe aplicar Agile pero nadie antes le ha explicado cómo articularlo en un proyecto real.

Resumen de las lecciones aprendidas al aplicar metodología ágil a un proyecto de implantación de ERP

Deadline vs Proyecto Abierto

Una de las primeras cuestiones que debemos enfrentarnos al comenzar un proyecto de implantación/migración de ERP es sobre el modelo de proyecto, ¿estamos en un proyecto donde tenemos un deadline o en un proyecto abierto sin una fecha fija?.

En la mayoría de las ocasiones, un proyecto de ERP tendrá un deadline debido a la dependencia de los ciclos financieros y la integración con el resto de sistemas del cliente. De modo que, si bien el equipo puede trabajar por sprints, al final el cliente querrá que se implante en una fecha concreta independientemente del estado del backlog y los sprints definidos. Corremos entonces el riesgo de que el cliente pueda malentender que los sprints son pequeñas fases dentro del proyecto y que en la fecha del arranque tendrá “todo”.

Es por eso que debemos hacer entender que en metodologías ágiles el hecho de tener un deadline implica que debemos jugar con el alcance y la capacidad del equipo. Se priorizarán entonces las funcionalidades/requisitos totalmente imprescindibles por encima de aquellos que realmente puedan esperar a después del arranque o bien exista un workaround manual. También podremos ajustar la capacidad del equipo disponible, si bien una vez avanzado el proyecto, no es fácil encajar más miembros en el equipo de forma productiva. Si todo esto no lo explicamos antes de arrancar el proyecto, nos encontraremos en un proyecto clásico de implantación.

Es por eso que debemos enfocarnos en las funcionalidades realmente importantes o que aporten valor. Es muy común que al preguntar a los usuarios éstos quieran todo lo que tenían en el anterior sistema o bien que todo sea automático. En el caso de Dynamics 365 FO, es un producto en cloud en constante actualización donde Microsoft marca el ritmo (concepto One Version), de manera que la aproximación del proyecto debe ser siempre la de implementar el menor número de GAPS posibles. Cualquier funcionalidad que se implemente a medida implica un sobrecoste y una herencia que es probable que en el futuro incluso no sea compatible con el roadmap del producto, pudiendo perder incluso nuevas capacidades del producto.

En muchas ocasiones, adaptarse al producto implicará cambiar el proceso que lleva definido durante muchos años y muy condicionado por el anterior sistema. Por lo que dependerá de la madurez y visión de los Keys users la posibilidad de ajustar los procesos al ERP.

Responsabilidad compartida

Existe una falsa percepción de que simplemente con que el proyecto se apoye por la dirección, el proyecto saldrá adelante. Si bien esto es muy importante, existe una responsabilidad compartida entre los negocios, IT y el proveedor.

Como cliente, estaremos cometiendo un error si lanzamos el proyecto y nos lavamos las manos hasta la fecha de arranque. No debemos confundirnos con que este tipo de proyectos son de IT o del proveedor de turno. Si no conseguimos la implicación de los negocios, del equipo financiero y del equipo de TI del cliente, el proyecto tendrá retrasos o bien será un fracaso. Y es que la implantación de un ERP tiene un impacto en todos los negocios de la empresa y si bien el proveedor puede ser solvente, existe una dependencia muy fuerte de los procesos del cliente y de la colaboración de IT para la extracción de datos, integraciones, …

En mi opinión el proyecto debería estar liderado por Financiero, que será el que defina gran parte del proyecto y el momento de salir a producción. Por otro lado, el equipo de IT debe ser un facilitador dentro del cliente, proporcionando los elementos necesarios al proveedor (datos, entornos, integraciones,…), persiguiendo a negocio, validando los FDD y TDD, identificando riesgo y velando por la buena marcha de los hitos definidos. Por último, los negocios deben colaborar en la definición, aprobación y pruebas de los desarrollos.

La metodología ágil requiere de una implicación constante de los diferentes actores durante todo el proyecto, de modo que cuanto antes los involucremos, menos riesgo tendremos al final del proyecto.

Dependencia con negocio

Un aspecto que diferencia un proyecto ERP de uno tecnológico es la alta dependencia con los negocios, provocando que gran parte de las tareas no se puedan cerrar a expensas del negocio.

Durante la fase de definición podemos encontrarnos con reuniones con muchos interlocutores, donde cada uno aporte una visión sesgada de su negocio y que además no sean decisores. Es por eso que debemos identificar desde el principio del proyecto a los Key users de cada negocio. ¿Cúantos Key Users debemos tener? Cuantos menos, mejor. ¿Qué perfil debe tener el Key User? Deben ser personas que tengan una visión amplia de los procesos de su negocio e incluso del resto de la casa, ágiles a la hora de responder y con capacidad de decisión.

Otros de los factores de un Key user es que deben tener disponibilidad casi en exclusiva al proyecto. Esto, que es algo muy complicado de conseguir, es uno de los factores que afectarán claramente al progreso del proyecto.

Del lado del proveedor, se debe identificar todas aquellas dependencias con negocio durante todo el proyecto y marcar fechas límite para cada una de ellas. Estas fechas no deben ser amplias, ni deben esperarse al final del proyecto, ya que se debe trabajar con los Key users durante todo el proyecto. Por ejemplo, no podemos esperar que los Key Users nos proporcionen todas las plantillas de cargas de datos perfectas al final del proyecto.

Como parte de IT, tendremos que asegurarnos que los Key Users cumplen con sus compromisos y que al mismo tiempo los proveedores proponen un buen planteamiento de proyecto.

Una de las experiencias que hemos aprendido en Aenor es que debe quedar claro desde el principio qué se espera de un Key User y cuales son sus responsabilidades. Aunque se pueda explicar al inicio del proyecto, los usuarios no son plenamente conscientes de las implicaciones hasta pasado un tiempo del proyecto.

Hitos & Sprints

A la hora de montar la planificación del proyecto, debido a la gran dependencia con otros sistemas y dependencia con tareas de negocio, decidimos trabajar con la dirección con modelo waterfall basado en releases e hitos parciales basada en el backlog previamente trabajado.

Cada uno de los hitos tenía como objetivo adelantar los riesgos de la puesta en producción y comenzar con la adopción del nuevo sistema por parte de los usuarios.

Durante la construcción del backlog, utilizamos LCS como sistema de gestión del ciclo de desarrollo de Dynamics 365. El problema que nos encontramos fue que por cada funcionalidad nos aparecieron una gran cantidad de tareas a realizar generando sprints inmanejables. En realidad estas tarea había que realizarlas, pero se volvía complicado poder realizar un seguimiento y planificación para cientos de historias de usuario. Al mismo tiempo, nos encontrábamos con que los consultores no eran capaces de cerrar historias de usuario debido a las dependencias con negocio o incluso IT.

De modo que decidimos separar el backlog en dos, una parte relacionada con el equipo funcional dejaría de utilizar sprints para trabajar en un modelo KANBAN y por otro lado seguir trabajando por sprints con el equipo de desarrollo.

Comunicación

Comunicación, comunicación y más comunicación.  No me estoy refiriendo solo a reuniones de seguimiento o a el uso de herramientas como Teams, si no a cómo debemos conseguir que fluya la información entre los negocios, los business partners, DP’s y el equipo.

En nuestro caso, nuestro proyecto está compuesto por más de 30 personas agrupados en tres equipos diferentes (IT AENOR, CRM y ERP), por lo que la comunicación y el seguimiento del proyecto se hace vital para llegar al deadline.

No existe una receta mágica para todos los proyectos, en nuestro caso hemos aplicado lo siguiente:

  • Por un lado, hemos incorporado las figuras de Business Partners, personas con un perfil funcional y un conocimiento de los procesos de la casa y los sistemas IT. Estas personas están presentes en todas las reuniones ayudando a cerrar funcionales, validar y comunicar al resto del equipo.
  • Hacemos reuniones semanales con los actores más decisores del proyecto (DP’s, BP, Scrum Master y los Leads de equipo) con el objetivo de revisar cada uno de los bloques del proyecto a nivel funcional/técnico y posibles riesgos.
  • Por otro lado, el equipo de trabajo sigue con las liturgias normales de agile (daily, sprint planning, sprint review y retro). A estas dailies se suman los business partners y el DP, identificando riesgos o gaps de información.
  • Como elemento adicional diferenciador, en nuestro caso hemos conseguido un ambiente en el que los diferentes miembros hablan entre ellos de forma rápida y transversal sin necesidad de reuniones ni jerarquías.

Clave: Scrum Master

Aplicar Agile requiere de cierto grado de madurez del equipo, por lo que si no tenemos esa madurez nos encontraremos con un problema serio al intentar aplicarlo. No me refiero solo a que el equipo entienda los conceptos, si no a que debe interiorizarlo de forma natural.

En nuestro caso incorporamos una figura de Scrum Master que ayuda a los diferentes equipos a aplicar la metodología SCRUM de forma adecuada y facilita que los equipos se centren en lo importante y entiendan el trabajo a realizar.

Debemos ser conscientes que el Scrum Master no es un jefe de proyecto. A la hora de gestionar el proyecto, (en nuestro caso) es el DP el que marca las prioridades, el Scrum Master le ayuda a definir los sprints y asegura que el equipo entiende las historias de usuario implementándolas en los diferentes sprints.

Pero no solo debe entender la metodología el equipo, también debe entenderla los DP’s, gerentes, negocio y dirección.