Epic Charter

0

Dentro de la visión de que una épica en el fondo es un proyecto, gestionado de forma diferente, hay técnicas de la gestión de proyectos que pueden ayudarnos a gestionar las épicas.

Hoy os traigo el acta de constitución del proyecto o como sería en inglés: project charter. Pero como no hablamos de proyectos, sino de épicas, lo correcto en este caso es hablar de epic charter.

Os aviso que el primer capítulo olerá a rancio. Pero os prometo “modernizarlo” en el segundo.

Project Charter

Primero de todo, suelo evitar el uso (aunque de vez en cuando se me cuela) de la versión española “acta de constitución” porque tiene una connotación demasiado formal. En cambio Charter (aunque en el fondo es un documento formal) me suena menos formal.

Según el PMBOK, quizás la base de conocimientos más famosa sobre gestión de proyectos, un projecto debe comenzar con una aprobación formal. Y para ello se define el project charter: un documento que describe a grandes rasgos el projecto y que debe ser “firmado” por los patrocinadores, que son los que tienen poder para decidir en qué se gasta la pasta.

El objetivo principal es que todas las partes entiendan de qué va el proyecto y que todas entiendan lo mismo. Y a la vez sirve de contrato entre el patrocinador y todas las partes.

Para conseguir ese objetivo un project charter es un documento que debe incluir:

  • Razones de por qué se hace el proyecto. A ser posible un breve business case.
  • Objetivos del proyecto: Qué se debe conseguir. Es un borrador del alcance del proyecto.
  • Restricciones del proyecto: Qué no se va a hacer. Asegura que todos entienden que algo en concreto no está en el alcance del proyecto.
  • Asunciones: Qué se asume para que tenga validez lo que se indica.
  • Resumen de cómo se conseguirá el objetivo.
  • Principales interesados.
  • Riesgos principales conocidos de antemano.
  • Presupuesto y planificación a alto nivel.

Lo habitual es tener una plantilla con todos estos espacios y el project manager los rellena. Suele ser un documento de una a tres páginas. Y lo normal es que quepa en una.

El documento una vez escrito se manda a interesados y se busca su aprobación, la cual debe quedar clara. Una firma, un mail diciendo aprobado o un click en una pantalla de la herramienta de gestión de proyectos suelen ser aprobaciones habituales.

Epic Charter, la versión modernizada

Un problema con las historias de usuario, y especialmente con las épicas, es que los distintos miembros del equipo y los interesados entiendan cosas diferentes.

Las épicas, por lo que yo he visto, no suelen pasar de una frase como “Nuevo motor de ventas”, o el típico modelo “rol-funcionalidad-razón” que nunca me ha gustado al estilo de “Como cliente quiero comprar on-line de forma que sea más fácil”.

Considero que hacer un charter al comenzar la épica puede ser de gran ayuda a la hora de evitar este problema. Que todas las partes tengan una misma visión de lo que se pretende conseguir con la épica, puede ser muy valioso. Pero la versión clásica de un Project Charter, puede ser un poco burocrática. Así que vamos a sacar lo bueno, y a quemar lo malo del Project Charter.

Un Epic Charter debería incluir un subconjunto de los conceptos que tiene un Project Charter. Personalmente me parecen interesantes:

  • Breve resumen de la épica
  • Objetivos de la épica
  • Valor de negocio, importancia
  • Principales interesados (si es que no son siempre los mismos)
  • Asunciones y Restricciones, si es necesario destacar alguna.
  • Acuerdos, si se han alcanzado.
  • Estimación de plazo (en el formato que estéis acostumbrados, y siempre dejando claro que es una estimación)
  • Riesgos, si vemos algo gordo, y que no sea obvio.

Al final se trata de dejar claro y estar seguros que los interesados y el equipo están hablando de lo mismo. El equipo, una vez realizado el Epic Charter debería ser capaz de responder a preguntas como ¿Por qué hacemos esto? ¿Cómo de importante es para negocio, y por qué es tan importante? ¿Si lo entrego pronto, ganas mucho? ¿Qué partes son las que más importan, y tendríamos que intentar entregar antes? ¿Para cuándo espera recibirlo negocio? Etc.

Pero os he hablado de modernizarlo, y parece que sigue siendo lo mismo, ¿no? La verdad es que sí. Por eso, algunos consejos que le quitarán el toque rancio:

  • Evita las plantillas. El objetivo no es rellenar una plantilla. Es entenderlo. Así que debe ser algo abierto.
  • Escribe lo que sea útil escribir. No es escribir por escribir, es lo que aporte valor.
  • Usa un formato que todos vean. Me gusta especialmente el post-it gigante (esos de tamaño cuartilla) pegado a la pared. Si usas un sistema de ticketing, como JIRA, lo puedes copiar en la descripción. Pero es no quita el post-it gigante en la pared.
  • El objetivo no es el contrato, es entender y asegurar que todos entendemos lo mismo.

Por ejemplo, para el famoso “Nuevo portal de ventas on-line” podríamos tener el siguiente project charter:

El portal actual está demostrando no convertir todo lo bien que se espera y los costes para mantenerlo son exagerados. Se espera que un nuevo portal comenzado de cero suba la conversión en más de un 50%.

Objetivos: Un portal moderno y con muy pocos pasos para la venta. Con nuevas funcionalidades para incentivar a la compra. Con tecnología nueva que cueste menos mantenerla y fácilmente escalable. Que sustituya completamente al anterior.

No queremos dos portales, sino ir sustituyendo el antiguo por el nuevo, funcionalidad a funcionalidad. 

Se espera que el proceso de pago este funcionando en Q3, ya que expira el contrato con la pasarela, y si no hay que renovarlo por dos años más.

Por supuesto que para que tú, lector, entiendas a lo que me refiero, he explicado “de más” algunas frases. Un EPIC charter estaría más resumido. Por ejemplo la última frase podría ser: “Q3: Página de Pago (fin contrato pasarela)”. Todos lo entienden y leen más rápido así.

El Epic Charter, al contrario del Project Charter, se puede cambiar. Pero cambiar un Epic Charter es un golpe de timón importante, por lo que suele revisarse con los interesados.

Beneficios de un Epic Charter

El coste de hacerlo es poco. Normalmente en media hora de reunión está resuelto. Y media hora para lo que implica una épica, es nada.

En cambio los beneficios creo que son muy grandes:

  • Alinea a negocio y equipo. Asegura que ambos esperan lo mismo y evita sorpresas.
  • Permite al equipo conocer las necesidades de la épica. Es una manera de “forzar” el cambio desde “me piden que haga esto” a “sé por qué tenemos que hacer esto”.
  • Ayuda a futuras decisiones. Te recuerda siempre por qué haces esto.
  • Te permite identificar a los interesados, te ayudará a no olvidarte ninguno.

Muchos beneficios y poco coste, es la fórmula perfecta para añadir valor.

Project Charter

Sobre el autor

Jose M. Huerta

Jose es Gestor de TI en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de desarrollo de software, usando metodologías clásicas, o desarrollo ágil, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

Sin comentarios