Haz un contrato ágil que funcione (con Alexa Huston de Crema)

Lee la transcripción:

Estamos probando la transcripción de nuestros podcasts usando un programa de software. Por favor, perdona los posibles errores, ya que el bot no es 100% preciso.

Ben Aston:

Bienvenido al podcast de Digital PM, donde vamos más allá de la teoría para darte consejos expertos de gestión de proyectos digitales para liderar mejor los proyectos.

Gracias por sintonizar, soy Ben Aston, fundador de The Digital Project Manager. Me pregunto si estás familiarizado con este clásico embrollo de la gestión de proyectos, donde heredas un proyecto de un equipo de desarrollo de negocio y, por alguna razón, una razón extraña, el presupuesto asignado al proyecto no parece tener ninguna relación con el trabajo que se está realizando.

Bueno, esto sucede todo el tiempo, ¿verdad? Y es increíblemente estresante para el gestor de proyectos, para el equipo de entrega, y finalmente para el cliente, quien, más veces de las que uno quisiera, termina decepcionado con el resultado.

Este episodio está patrocinado por Resource Guru, la herramienta de programación de recursos utilizada por equipos de empresas como Apple, Ogilvy, Deloitte y Publicis. Los oyentes de DPM pueden obtener un 20% de descuento de por vida en su cuenta con el código de cupón DPM2018.

Conoce más en resourceguru.io/dpm

Así que hoy vamos a hablar sobre una mejor manera de enfrentar la locura de la contratación que muchos de nosotros sufrimos. Realmente, creo que esta es una conversación que va más allá de la gestión de proyectos, es una conversación más grande. Es el tipo de charla que está... cruzada entre gestión de proyectos y nuevos negocios, entre contrataciones y operaciones, y realmente tenemos que encontrar una mejor forma. Si te suenan las luchas de la gestión de contratos y statements of work que he mencionado, te va a encantar el programa de hoy, el cual trata de un modelo de colaboración diferente. Así que sigue escuchando para descubrir cómo puedes evitar todo un mundo de sufrimiento intentando recortar los proyectos antes de que empiecen.

Mi invitada especial hoy en el programa es Alexa Huston, de Crema. Alexa es una exgestora DPM convertida en la chica de nuevos negocios. Así que entiende este reto desde dos perspectivas: la de vender y la de entregar el proyecto. Va a ser una conversación interesante.

Además, Alexa es una de nuestras expertas DPM residentes en la Digital Project Management School, así que si quieres aprender más de ella, revisa nuestra escuela Mastering Digital Project Management, donde hará una aparición. Ve a Resourceguru.io/dpm.

¡Hola y bienvenida, Alexa!

Alexa Huston:

¡Gracias por invitarme!

Ben Aston:

Entonces, Alexa, cuéntanos, ¿qué hay de nuevo en tu vida? Creo que vas a comenzar una gran aventura.

Alexa Huston:

¿Conoces la frase, “Cuando llueve, diluvia”?

Normalmente es algo negativo, pero están pasando muchas cosas positivas, así que me comprometí hace mes y medio, y luego una semana después, la empresa de mi prometido le ofreció un nuevo puesto en Phoenix, así que nos mudamos al desierto.

Y, como resultado de eso, preparé una propuesta para conservar mi trabajo en Crema, porque lo amo. Y tengo la suerte de decir que la aceptaron, así que voy a trabajar en remoto por primera vez en mi vida. Y, ya sabes, estamos planeando una boda, hay muchas cosas pasando.

Ben Aston:

Entonces, cuéntanos sobre la organización de la boda. Obviamente, ya sabes, planear una boda es gestión de proyectos. ¿Tienes una wedding planner? ¿Estás gestionando el proyecto tú misma?

Alexa Huston:

Tengo una gran sonrisa. Al final contratamos a una coordinadora y planificadora de bodas porque la vamos a hacer en México, y elegimos un lugar que ni siquiera hemos visitado, en una ciudad que no conocemos. Así que, a ciegas, da un poco de miedo y nos casamos en ocho meses, así que considerando todo eso dije: “Necesito ayuda”.

Ben Aston:

Así que tu estrategia de gestión de riesgos es contratar una planificadora de bodas y confiar en que lo logrará.

Alexa Huston:

En serio, y justo tuvimos nuestra primera llamada con ella anoche y es genial. Pero al ser una project manager en recuperación, le he estado preguntando, es como gestión de interesados, le pregunto: “Oye, ¿cuál es tu preferencia en este proceso? Veo que haces las cosas así, ¿es como prefieres trabajar o habría algo que podríamos hacer diferente?”. Así que ha sido un buen equilibrio.

Ben Aston:

Sí, creo que gestionar un gestor de proyectos cuando tú también lo eres y lo contratas, siempre te pone nervioso al principio y piensas: “¿Sabrán cómo hacerlo?”

Alexa Huston:

Sí, incluso ayer le dije: “Oye, ¿puedes enviarme un contrato firmado completamente? Porque solo tengo una versión con mis líneas de firma”. Y ella probablemente pensó: “Claro”.

Ben Aston:

Qué divertido. Buena suerte organizando la boda.

Alexa Huston:

¡Gracias!

Ben Aston:

Y, en México, en un lugar donde nunca han estado, así que …

Alexa Huston:

Todo irá bien, es un huerto de mangos / restaurante / tienen casas en los árboles donde alojarse. Es hermoso.

Ben Aston:

Estoy ya deseando verlo.

Alexa Huston:

Sí.

Ben Aston:

Genial, cuéntanos más sobre cómo va a cambiar tu rol. Creo que es un tema interesante pensar en cómo cambia cuando pasas de ser empleada interna a trabajar en remoto. Para otros que estén pensando “me gustaría trabajar en remoto y no tener que ir a la oficina”, ¿cuál fue tu estrategia, considerando que ya te mudabas? ¿Cómo lo planteaste y qué enfoque tendrás para trabajar a distancia?

Alexa Huston:

Totalmente, mi estrategia era, “me mudo sí o sí, pero déjame enlistar los beneficios para el negocio si trabajo en remoto”. Tengo suerte, porque en el último año y medio en Crema, cada vez más empleados han ido trabajando en remoto, especialmente los últimos tres meses. Es una tendencia interesante.

Así que ya era un tema en la empresa: cómo pensar en una fuerza de trabajo distribuida, en un equipo remoto. Pero encuadré las oportunidades en un nuevo mercado y cómo beneficiaría al estar allí, y respaldé con los resultados que he obtenido en nuestra cultura orientada a logros. Aunque normalmente estaba en la oficina, podía trabajar desde casa. Destaqué por qué era bueno para la empresa y preparé una estrategia de comunicación y un cronograma general para que todos estuvieran cómodos con el cambio.

Además, hay un giro: hay otro compañero de desarrollo de negocio y ambos hacíamos lo mismo. Al crecer, vimos que debíamos especializar más los roles y me recomendaron el libro Predictable Revenue, que ha sido increíble, y lo estamos adaptando a nosotros.

Voy a ir hacia el tope del embudo, ventas outbound, que es nuevo para mí. Campañas de email a empresas que no nos conocen, esperando generar más leads, que luego calificaré y pasaré a Nate, mi colega, para que los lleve por nuestro embudo de ventas.

Hasta ahora dependíamos de referencias y otras estrategias menos predecibles, así que ese es el otro cambio al que me estoy adaptando.

Ben Aston: Todo cambia... porque empecé a trabajar para una agencia, haciendo contratos, y sí, es totalmente remota. Es muy diferente trabajar con un equipo completamente distribuido que cuando todos están en la oficina y puedes acercarte a ellos. Contactar con la gente es todo un desafío.

Alexa Huston:

Es un reto y es nuevo; incluso esta semana, estaba enviando mensajes y sentía que no me respondían, pero simplemente tengo que estructurar mis conversaciones de forma diferente, hacerlas más orientadas a la acción si necesito respuesta, o no tener miedo de llamarlos si están disponibles.

Buscar maneras de cerrar la comunicación con…

Ben Aston:

Sí, definitivamente. Algo que me ha estado ayudando es usar Zoom todo el tiempo. Es fácil vivir en Slack, pero forzarme a conversar por Zoom requiere más esfuerzo, tienes que asegurarte de no tener comida en la ropa, pero el esfuerzo de hablar de verdad ayuda más que solo mensajear.

Alexa Huston:

Totalmente de acuerdo.

Ben Aston:

¿Has encontrado algo más últimamente que te esté facilitando la vida?

Alexa Huston:

Es sencillo, pero me ha ayudado. Compré una libreta bonita en Amazon con un marcador de cinta y compartimento para el bolígrafo, y estoy equilibrando entre digital y escribir a mano. Antes usaba una libreta sin marcador, así que mis notas estaban todas desordenadas y me volvía loca. Es un cambio simple, pero me ayuda mucho tener todo en orden.

Ben Aston:

El efecto del marcador.

Alexa Huston:

El efecto del marcador, sí.

Ben Aston:

Genial. Yo también he vuelto a usar libreta porque con mis tarjetas en Trello, Evernote, etc., acabo distraído. Escribir me ayuda a centrarme, más que digital.

Si quiero pensar y anotar cosas, soy más eficaz así, escribiendo, en vez de estar en el móvil o PC, donde siempre hay distracciones.

Alexa Huston:

Totalmente, creo que es un buen ejemplo de autoconciencia y experimentar con métodos, porque yo también uso mil herramientas y a veces sufro fatiga de herramientas, por eso intento simplificarlo y escribirlo a mano.

Ben Aston:

Sí. Y usar tu marcador. ¡Consigue una libreta con cinta!

Alexa Huston:

¡Consigue una cinta!

Ben Aston:

Incluiremos el enlace en la transcripción.

Bien, hablemos de tu artículo y revisitemos ese escenario que mencioné al inicio y que todos conocemos demasiado bien. Nuestro equipo de negocio quiere vender. Esa es tu función. Yo también acabo de salir de un rol en desarrollo de negocio. Queremos vender, así que hacemos una gran oferta aparentemente generosa al cliente para conseguir el proyecto. Muchas veces la tentación es bajarle un poco el precio. Así parecemos más competitivos que otros. A veces la idea es: el primer producto se vende a pérdida. Lo cual, por cierto, creo que es una terrible idea.

Y a veces es por falta de definición en el alcance. Pensamos que es poco probable que salga, le decimos al cliente: "Claro, te lo hacemos por 100k.", pero es un proyecto de 200k.

Normalmente, en una agencia, intentamos vender un retainer, que es lo ideal. Contrato de tarifa fija, de tiempo y materiales, ahora hay mucho interés por contratos basados en valor. Pero con cualquiera de estos, tras la firma, empiezan los problemas: el PM recibe el proyecto con presupuesto insuficiente para hacerlo bien.

¿Cuál es la mejor forma? Alexa escribió un artículo sobre un tipo de contrato diferente, léelo para más detalles. Hoy hablaremos de eso: un contrato basado en duración y precio.

¿Podría ser la solución a nuestros problemas de contratación? Alexa, cuéntanos qué es un contrato basado en duración y precio. ¿Cómo funciona?

Alexa Huston:

Aviso: este término lo inventamos nosotros. Así terminamos llamándolo hace un par de años. Pero alude tal cual a lo que es: acuerdos que apoyan nuestras metodologías ágiles y se centran en el valor y los resultados del proyecto, no en un alcance fijo ni en detalles exhaustivos.

En pocas palabras, la duración es el tiempo de colaboración con el equipo y el precio es el resultado del tiempo por tarifa por hora. Es diferente de lo que describías, como un retainer, tarifa fija o valor, que es muy difícil en agencias. Es una forma más simple, aunque tiene sus complicaciones y mucho trabajo educativo.

Pero sentimos que así nuestros clientes saben qué pagan y nuestro equipo no necesita ceñirse a un alcance definido sin todos los datos previos.

Incluso el mejor contrato de alcance fijo puede tener buenas razones para existir, si está muy bien definido. Pero en desarrollo de productos, los equipos gastan mucho tiempo pensando en hitos y funcionalidades que luego cambian sobre la marcha.

Buscábamos mitigar esos riesgos y evitar sobrecargos que suelen surgir con contratos de tarifa fija.

Podcast relacionado: Encontrando el acoplamiento perfecto entre operaciones y PMO (con Alyson Caffrey de Operations Agency)

Ben Aston:

Entonces, como nuevo negocio, vendes un equipo de cinco personas a 5k por semana, y al cliente le dices: "Eso son 25,000 semanales." ¿Cómo llegas a un presupuesto? ¿Dices que es un proyecto de cuatro semanas (100k) y buscas esa aprobación? ¿O dices simplemente: "No sabemos cuánto durará, son 25k semanales"? ¿Cómo funciona?

Alexa Huston:

Buena pregunta. Sin entrar en detalles, intentamos empezar con un alcance pequeño y definido (por ejemplo, de cuatro a seis semanas de diseño y testing de prototipo). Pero también fomentamos la idea de dar equipos de producto dedicados: los cinco roles, QA, estrategas de proyecto, diseño y desarrollo. Y decimos: "Según experiencia, para llegar a X fase o lanzamiento, pueden ser tres a seis meses." Negociamos ese plazo, pero el objetivo es que durante ese tiempo el cliente tenga acceso a todo el equipo para iterar la aplicación o el producto hasta que termine la duración, y ojalá surjan nuevas oportunidades de seguir colaborando.

Trabajamos con un backlog o algún kind de roadmap, y generalmente al final del primer contrato hay más trabajo pendiente, y es sencillo renovar y seguir adelante.

“Nuestra relación ha sido buena, sabemos que hay más cosas por delante, extendamos esto y sigamos trabajando juntos, porque hemos cumplido los objetivos.”

Ben Aston:

Entonces, dais al cliente una estimación de la duración, y ¿cómo gestionas la expectativa sobre la calidad de lo que producirán? ¿Cómo apoyáis al cliente para que lo venda internamente y consiga ese presupuesto si no está seguro del resultado exacto, pero sabe que durará entre tres y seis meses?

Alexa Huston:

Es complicado, no lo niego. Ayuda explicar que no es un cheque en blanco, sino enfocarse en los problemas específicos del cliente y en cómo este acuerdo lo resuelve: ser específicos sobre el retorno potencial de la inversión, si es posible.

Muchos clientes compran en grupo y tienen que reportarlo internamente. Así que nos enfocamos en nuestras metodologías ágiles y mostramos casos de éxito similares.

Lectura relacionada: ¿Qué es el marco ágil escalado (SAFe)? Explicación para gestores de proyectos

Esto ayuda a mostrar la calidad esperada. Nos importa mucho la calidad porque invertimos mucho en nuestro proceso de desarrollo y queremos que el cliente tenga un equipo de producto experto. Y que es la mejor alternativa para su reto.

Una forma sencilla de explicar el precio es, literalmente, escribirlo en la pizarra: “Necesitas estos cinco roles, a esta tarifa por hora”, lo ponemos en una tabla para que vea cómo se calcula el precio. Y empoderar al cliente para que vea el valor: él dirigirá cada sprint, con nuestras recomendaciones.

Esto pone al cliente en el centro para tomar decisiones sobre el producto, priorizar el backlog y revisarlo junto con nuestro equipo cada sprint.

Ben Aston:

¿Pasa que el cliente diga: "Este equipo no está produciendo suficiente, tenemos mucho backlog y van muy lento"? Eso es lo que me da miedo.

Alexa Huston:

Totalmente, y ahí es vital aplicar scrum o prácticas ágiles porque idealmente deberías lanzar algo visible para el cliente en las primeras semanas. Suele pasar lo contrario, hay ansiedad al principio, pero una vez que empieza el desarrollo y ven avances frecuentes, los invitamos a nuestro software de gestión de proyectos y Slack, así que observan el progreso. Hace falta construir confianza pronto, pero suele disiparse cuando ven lanzamientos frecuentes, aunque todavía no sean utilizables, ya pueden imaginar lo que será y extrapolarlo al plazo que hemos acordado.

Ben Aston:

Entonces, dais transparencia al proceso. ¿Tienen visibilidad total de los canales internos, herramientas y todo el avance?

Alexa Huston:

Sí. Hacemos dos canales de Slack por proyecto. Uno interno (por si hay que reportar algún problema grave y decidir cómo abordarlo) y otro que llamamos, por ejemplo, nombreproyecto_collab, donde están todos los interesados y se actualiza muy seguido el status.

Eso da un alto nivel de transparencia.

Ben Aston: Genial. Y en tu artículo decías, que esto tiene que ver con la confianza: negociar el alcance con el cliente durante todo el proceso. Me interesa saber cómo acompañan al cliente en eso, considerando que normalmente los clientes no tienen mucho poder y reportan a otros. ¿Intentan llegar más arriba para tener acceso al decisor o cómo lo gestionan?

Alexa Huston:

Para que esto funcione, necesitas un decisor empoderado del lado del cliente. A veces hay trabas para identificar quién toma las decisiones y tratamos de detectarlo en la venta. Lo ideal es que haya un product owner técnico o de diseño. Entonces trabajamos con él para que, además de tener acceso a todo y tomar decisiones, revise el roadmap y priorice el backlog antes de cada sprint, con nuestro apoyo y recomendaciones. Porque puede pasar que surja algo inesperado y haya que girar rápido.

Por ejemplo, hace unos años, íbamos a licenciar un producto, pero la empresa cerró, así que tuvimos que pensar rápido y decidir juntos la mejor opción, sin preocuparnos de un cambio de alcance formal porque no estábamos atados a un contrato rígido, solo discutimos y avanzamos, con la confianza del cliente.

Ben Aston:

Mencionaste el contrato. ¿Cómo es el statement of work?

Alexa Huston:

Es bastante sencillo. También tuvimos que adaptar nuestro MSA para que encaje. Modificamos eso y el contrato es simple.

En el artículo enseño capturas de PandaDoc, la herramienta que usamos, pero es muy de alto nivel y enfocado en “objetivos de negocio y el camino para lograrlos”. Recomiendo tener claro qué se va a construir, enlazar a user stories, prototipos o algún diseño si es posible.

Eso ayuda a que todos, tanto involucrados directos como externos, entiendan el proyecto. Hacemos una tabla con los recursos, tarifas y duración en el proyecto.

Ponemos cláusulas adicionales si requieren soporte fuera de horario o lo que aplique. Pero en general es directo y fue todo un cambio: antes los contratos eran de ocho o nueve páginas y nadie los leía, así que simplificamos para que el cliente sepa en qué se está metiendo.

Si todo va bien, el papeleo no estorba. Hay que firmar y tener un acuerdo, pero si se implementa bien, puedes olvidarte del contrato y enfocarte en cada sprint.

Ben Aston:

Dices que idealmente empiezas con user stories, una imagen, una idea. ¿Entonces inviertes más en la venta, definiendo más antes de arrancar, para mitigar riesgos?

Alexa Huston:

Evitamos regalar trabajo, así que es un equilibrio entre detectar necesidades y no dedicar demasiado tiempo de nuestro equipo. A veces empezamos con una discovery técnica de una o dos semanas para estrategia y alineamiento y luego el equipo se amplía.

Quizá las primeras dos semanas es menor la dedicación de todos, y luego aumenta; la tabla de recursos y tarifas cambia en consecuencia. Así amplías el equipo y avanzas a fondo en lo visto en el comienzo del proyecto.

A veces los clientes llegan con la especificación hecha: “Tengo esto y quiero arrancar”, y les decimos: “Genial, hablemos de ello, veamos cómo te sientes si cambia, porque seguramente lo hará”. Así que toca educar antes y durante el proceso.

Ben Aston:

¿Dónde crees que esto puede fallar? ¿Tienes historias donde no haya funcionado y el cliente haya quedado insatisfecho o el PM perjudicado?

Parece muy bonito…

Alexa Huston:

No es la panacea. Requiere un equipo con madurez ágil. Si el equipo es muy nuevo en ágil, o no ha estado unido suficiente tiempo, quizá no aplica. O si el alcance está súper definido y es waterfall, pues no hay por qué forzar nada.

Falló cuando intentamos alejarnos de nuestra mejor forma de construir productos y tratar de adaptarnos demasiado al proceso del cliente, y eso fue en nuestra contra. Hay una unión y compromiso, pero el PM puede sentirse empoderado para proponer lo mejor para el producto en vez de temer que un cambio descarrile todo por estar amarrado a un alcance fijo.

Ben Aston:

A veces, como PM, queremos ser estratégicos, pero cumplir con plazo y presupuesto, incluso si no es lo mejor para el cliente, pasa a ser la prioridad.

Alexa Huston:

Sí, y lo bueno del proceso fue revisar legalmente el contrato; nos obligó a pensar en el lenguaje y cómo se traduce en una relación contractual. Merece la pena probarlo primero en proyectos internos, aunque obviamente no te vas a facturar, pero ves el modelo y puedes iterar y preguntar y hacer retrospectivas: ¿Cómo mejorar esto?

Pide opinión a los desarrolladores y diseñadores si han tenido experiencia con este modelo, es mejor para ellos que no estar atados a un alcance cerrado que ni conocen hasta iniciar el proyecto. Eso no es lo ideal.

Pregunta al equipo que lo va a trabajar y escucha cómo se sienten.

Ben Aston:

Me da curiosidad, como primer paso, para quienes estén escuchando y pensando en probar esto con nuevos clientes, ¿hay tipos de proyectos donde funciona mejor o peor?

Alexa Huston:

Buena pregunta. Funciona genial en desarrollos multi-plataforma. El primer caso que tuvimos fue con una startup que quería app iOS, android y web, con más de cien user stories. Era casi imposible acotarlo.

Así que va bien donde hay un runway largo de desarrollo y se requiere mucha gente. No es tan bueno para webs de marketing, contenido, cosas muy lineales. No todo es para esto, y está bien.

Pero si tienes idea de cuánto se puede hacer o cuánta dedicación necesitas semanal o mensual, puedes probar este modelo y ver si encaja.

Además, requiere un equipo que trabaje junto, que se autoorganice según metas del negocio y coopere, y un cliente que pueda decidir.

Ben Aston:

Exacto. Lo valioso de lo que dijiste es que hay que formar equipos. Si ya han trabajado juntos, se entiende mejor. Así que uno de los primeros pasos es crear equipos y probarlos en proyectos internos: ¿cuánto pueden lograr en uno, dos, tres meses? Nada sale perfecto, hay repeticiones, pero es parte del proceso. Así calculas y puedes ofrecerlo al cliente: esto es lo que puedes esperar en tres o seis meses. Buen consejo.

Alexa Huston:

Totalmente, nosotros nos inspiramos en Hanna, una agencia asombrosa que hace tres años publicó sus proyectos y la venta del “equipo por semana”. De ahí pensamos en equipos de producto dedicados, que es distinto a que el cliente solo tenga a un desarrollador dos meses.

Eso genera problemas y silos que no queríamos, esto es para un equipo más grande.

Ben Aston:

Sí, no es bodyshopping.

Alexa Huston:

Así es.

Ben Aston:

Genial. Como nota final, ¿qué consejo darías a quien quiera llevar adelante esta idea y tenga dificultades? ¿Algún “nugget” para implementarlo?

Alexa Huston:

Lo resumiría en una palabra: comunicación. Incluso internamente. Que todo el equipo esté alineado desde el inicio de la creación del contrato. Obviamente comunica al cliente por qué esto les conviene, por qué aporta valor a su negocio y que se adapte a cómo opera tu equipo. De nuevo, tenemos una cultura ágil y esto ayuda a operacionalizarlo. Comunica los beneficios y resultados por encima de la actividad, eso será valioso.

Solo comunica.

Ben Aston:

Buen consejo. A menudo, como directivos, se lanza una nueva metodología sin consultar o involucrar, pero comunicar durante todo el proceso y buscar la adhesión es fundamental.

Alexa, muchas gracias por estar hoy con nosotros, ha sido un placer.

Alexa Huston:

Lo agradezco.

Ben Aston:

Y como mencioné al inicio, Alexa participará en nuestro próximo curso que empieza en septiembre, Mastering Digital Project Management. Si necesitas formación en gestión de proyectos, es un curso intensivo de siete semanas con lecciones en video, tareas, debates y sesiones opcionales de coaching. Visita dpmschool.com e inscríbete antes de que se llene.

Si quieres seguir la conversación sobre cómo contratar de forma ágil, comenta en el post o entra en la sección de recursos de digitalprojectmanager.com, o únete a nuestro equipo de Slack donde hay muchas conversaciones interesantes.

Hasta la próxima, gracias por escuchar.