Cambiando de Contratos Waterfall a Contratos de Duración y Precio (Con Tucker Sauer-Pivonka de Crema)

Lee la transcripción:

Estamos probando transcribir nuestros podcasts usando un programa de software. Por favor disculpa cualquier error tipográfico, ya que el bot no es 100% preciso siempre.

Ben Aston:

Bienvenido al Podcast DPM, donde vamos más allá de la teoría para darte consejos que funcionan, para liderar mejores proyectos digitales. Gracias por escuchar, soy Ben Aston, fundador de The Digital Project Manager. Ahora, raramente los proyectos salen como lo planeado, y cuando los planes cambian, suele crear mucho estrés. Hay que hacer llamadas, programar reuniones, actualizar planes, recalcular estimaciones y, usualmente, emitir solicitudes de cambio. Pero, ¿y si hubiera otra forma de gestionar el cambio en tus proyectos? En este podcast, vamos a levantar la tapa para mostrarte una forma diferente de abordar la gestión del cambio con contratos ágiles. Así que sigue escuchando para entender cómo lograr que los contratos ágiles trabajen para ti, y comprende los beneficios y desafíos de hacer funcionar este enfoque.

Hoy me acompaña Tucker Sauer-Pivonka, es el Director de Gestión de Producto y realmente ayuda a los gestores de producto, a crecer y desarrollarse. Además, está a cargo de evolucionar las mejores prácticas. Hola, Tucker.

Tucker Sauer-Pivonka:

Hola Ben, es un gusto hablar contigo hoy.

Ben Aston:

Sí, igualmente. Una de las cosas que quería preguntarte, de hecho, al comenzar; sé que parte de tu rol es desarrollo del equipo, y me pregunto si puedes compartir algunas de tus percepciones sobre lo que realmente ha funcionado para ayudar a tu equipo a desarrollarse y evolucionar. Quizá en torno a los contratos con los que están trabajando o experimentando. ¿Cómo cultivas al equipo y los ayudas a crecer? ¿Qué te ha funcionado?

Tucker Sauer-Pivonka:

Sí. Creo que lo primero que debes reconocer desde el principio, es que cada persona aprende de manera diferente, todos necesitan diferentes formas de orientación. Así que una de las primeras cosas que hago con mis miembros de equipo, es sentarme con ellos y empezar a evaluar eso. ¿Cómo aprenden? ¿Cómo prefieren recibir retroalimentación? ¿Cómo les gusta que se les reconozca? Llevo registro de todo eso, para poder adaptar mi enfoque a algo que responda mejor cada uno. Paso mucho tiempo en sesiones individuales, revisando diferentes temas y áreas de mejora. Realmente los oriento en lo que tengan problemas en ese momento. Surgen situaciones, y las enfrentamos conforme aparecen. Además, tenemos un club de lectura en Crema, sobre un libro llamado Multipliers.

Eso es un aspecto importante de nuestro crecimiento. Claro que también, conferencias. Tenemos una conferencia próxima, creo que al final de septiembre, a la que vamos a asistir. También está relacionada con gestión de producto. Así que vamos como equipo, no solo para hacer team building, sino también para aprender sobre nuevos temas.

Ben Aston:

Bien, ¿cómo se llama esa conferencia?

Tucker Sauer-Pivonka:

Industry: The Product Conference, así se llama, es en Cincinnati, si no recuerdo mal.

Ben Aston:

Fiesta en Cincinnati, si quieres unirte a Tucker y su equipo. Pero quiero profundizar... mencionaste que con el equipo cubren distintas temáticas. Me interesa saber si puedes compartir alguna de las temáticas o áreas que estás ayudando al equipo a superar, y cuáles son los desafíos a los que se están enfrentando y que tú les ayudas a manejar.

Tucker Sauer-Pivonka:

Sí, creo que se ve un poco diferente en cada persona, porque tenemos diferentes niveles de habilidades en el equipo. Pero algunas de esas cosas han sido, sobre todo, en sesiones grupales, sobre gestión del cliente. Por ejemplo, “Mi cliente dijo esto, o está pidiendo que hagamos tal cosa, pero no hemos hablado de eso ¿cómo debería manejarlo?” Estoy siendo general, porque ahora mismo no se me ocurre un ejemplo perfecto, pero va por ahí.

Los temas de gestión de cliente suelen ser los más difíciles enseñar a alguien, así que son conversaciones tipo, “Me sentí raro con esto, no sé si lo manejé bien. ¿Debería hacerlo diferente la próxima vez?” Así suelen ser nuestras charlas.

Ben Aston:

Cierto, es verdad. Creo que hay habilidades blandas soft skills sobre gestión de clientes y de equipo, igualmente ¿no? Nunca hay una sola respuesta correcta... Siempre depende. Pero siempre podemos crecer y mejorar. Y mencionaste ir a una conferencia en equipo, lo cual me parece excelente. Me gustaría saber un poco más de dónde obtienes inspiración, y cómo te mantienes actualizado. ¿Cómo te mantienes al día, y cómo te inspiras?

Tucker Sauer-Pivonka:

Sí, busco inspiración de varias fuentes. Una de ellas son los libros que leo. Leo muchos artículos—por ejemplo, Medium es un sitio que suelo visitar bastante para inspirarme sobre gestión de productos o gestión de equipos y cómo debería o podría ser. Pero me recuerdo a mí mismo que Medium es un gran recurso, pero a veces hay que tomarlo con cautela, porque cualquiera puede publicar ahí. Simplemente porque publican en internet, no los hace expertos, pero te da contexto para manejar ciertas situaciones.

Uso bastante eso, y luego temas de la industria en general. Me gusta mucho la revista Wired; leo prácticamente todos sus artículos cada edición. Eso me ayuda a mantenerme al tanto de tendencias tecnológicas fuera del mundo PM, más allá, sobre lo que ocurre en la tecnología.

Ben Aston:

Genial. Y, en cuanto a tecnología, ¿eres alguien que se mantiene en la vanguardia de la tecnología? ¿Cuál es el último gadget que has comprado?

Tucker Sauer-Pivonka:

Buena pregunta. Ojalá tuviera algo súper emocionante que contarte. Pero no puedo decir que estoy en la frontera de la tecnología; me considero un early adopter, pero no antes que eso. Trato de conseguir productos nuevos cuando salen, si puedo. Ahora mismo, estoy deseando tener el nuevo iPad. Tengo el iPad Pro, que está bien, pero quiero la versión más reciente y no encuentro justificación, porque el que tengo funciona perfectamente. Esa es la maravilla de los productos Apple ahora; funcionan bien y no hay necesidad real de reemplazarlos. Así que no lo puedo justificar.

Pero últimamente, lo más reciente, mostrando mi lado Apple-nerd aquí, ha sido la última versión de iOS y iPadOS, y todo lo que presentaron en WWDC, me resultó súper interesante. He estado pensando bastante en cómo esos lanzamientos impactarán a la industria, e incluso en los productos que hago. Además—no lo niego—soy un poco nerd de Zelda, y la secuela de Breath of the Wild acaba de anunciarse, así que también estoy emocionado por eso.

Ben Aston:

Genial. Lo que yo tengo en la mira ahora es el DGI Rover. No sé si se llamaba Rover, o cómo, pero anunciaron una camarita con orugas, que construyes tú mismo, parece genial. Está en mi lista de compras como próximo gadget.

Tucker Sauer-Pivonka:

Eso suena divertido.

Ben Aston:

Sí, de nuevo, esas cosas ¿no? ¿Realmente la necesito? ¿No la necesito? Pero será bueno para los niños, ellos lo disfrutarán. Por cierto, me da curiosidad, decías que te encanta tu iPad Pro. A nivel de hardware o software, ¿hay algo más que hayas encontrado últimamente que hace tu vida increíble y que todos deberían conocer?

Tucker Sauer-Pivonka:

Sabes, he batallado en los años en buscar el equilibrio entre tomar notas a mano, notas escritas, tareas… Busco ese balance porque hay estudios que dicen que escribir a mano hace que comprendas las cosas de otra manera comparado con teclear, y eso me intriga. Siempre trato de encontrar ese balance. Por un tiempo, tomaba notas en el iPad con el Apple Pencil. Pero últimamente, lo que hago es... es un término medio.

Así que, el iPad o mi compu la uso para dejar todo como repositorio final para el trabajo. Pero ahora cargo una libretita, donde apunto notas y tareas del día a día a mano. Al final del día, transfiero esas tareas a una app llamada Todoist para seguir mis pendientes. Igual, mis notas las transfiero, y las proceso al final de cada jornada.

Ahora, ese estado final, apenas lo estoy integrando a mi rutina, pero ha sido el mayor cambio en mi flujo de trabajo y ha ayudado mucho. Noto que comprendo mejor las cosas, y puedo rastrear mejor las tareas para no saltar a ellas de inmediato. Incluso desde la gestión del tiempo, ha sido útil.

Ben Aston:

Interesante, o sea usas una libreta física para notas. Has vuelto al lápiz y papel, para recordatorios y apuntes, ¿es así?

Tucker Sauer-Pivonka:

Sí, pero al final, todo pasa a lo digital. Para mí, nada reemplaza abrir una libreta, sacar el bolígrafo y empezar a escribir. Lo que más me costaba con el iPad y el Apple Pencil, aunque suene absurdo, era el tiempo de abrir la app, buscar la libreta digital, asegurarme que el pencil tuviera batería… Un montón de cosas mínimas que se convierten en barreras. Así que acababa cargando mi iPad y un millón de post-its, porque si tenía que anotar algo urgente, usaba los post-its. Era absurdo y poco sostenible. Por eso pasé a la libreta.

Ben Aston:

Interesante. Es una lucha que yo también tengo. Lo que hago ahora es usar Evernote. Tengo una libreta como lista de tareas y otra que llamo borrador, donde va todo lo “crudo”. Luego paso lo importante a la de tareas. Suena parecido a tu sistema. Y cargo un notepad diminuto, que es tan pequeño que no se puede escribir mucho, solo recordatorios. Así me obligo a seguir mi método, si no, termino con listas por todos lados y es un lío.

Pero bien, listas de tareas... Vamos a hablar del artículo, que es un caso de estudio que escribiste para nosotros, muy interesante, sobre el cambio de contratos tipo waterfall a contratos de duración y precio. Hemos hablado de contratos ágiles antes y, de hecho, en la escuela DPM alguien preguntó esta semana: “Dame un ejemplo de contrato ágil”, y yo le pasé el enlace. Alexa escribió un gran post sobre contratos ágiles antes. Pero para quien no esté familiarizado, ¿puedes explicar brevemente qué es un contrato de duración y precio y cómo funciona?

Tucker Sauer-Pivonka:

Sí. Explicaré cómo funciona desde nuestro contexto en Crema. No tiene que ser así en todas partes, pero es lo que más conozco. Llamamos contrato de duración y precio a aquellos donde el proyecto gira en torno a un equipo dedicado. Eso puede ser, por ejemplo, dos desarrolladores full-time, un test engineer medio tiempo, un diseñador a cuarto o medio tiempo, y quizá un product manager, más un estratega ambos a cuarto tiempo cada uno.

Así que se enfoca más en el equipo y las metas que buscas, en vez de detallar entregables y funcionalidades específicas, con estimación de horas para cada cosa. Hemos comprobado que el software es demasiado complejo como para estimar todo al principio y suponer que todo saldrá según lo planeado. Sería ideal planear y que todo salga al pie de la letra, pero eso nunca ocurre.

Estos contratos nos permiten a nosotros y al cliente cambiar el enfoque al trabajo de mayor prioridad. Así que al final de la duración, e incluso iterando, entregamos lo que tiene mayor valor para el negocio. En un contrato de precio fijo, las prioridades pueden cambiar en seis meses, y puedes entregar funcionalidades que ya no son relevantes. Con este modelo, cambiamos según lo que el cliente necesita.

Ben Aston:

Genial. Has dicho qué tipo de proyectos hacen sentido para contratos ágiles, por ejemplo desarrollo de software, donde necesitas esa flexibilidad de pivotar. ¿Hay proyectos donde intentaste este modelo y no funcionó tan bien?

Tucker Sauer-Pivonka:

Sí, hay casos—tal vez no tanto para nosotros, pero quizá para otros evaluando si les conviene. Debes evaluar el tipo de trabajo. Como dijiste, Ben, funciona porque hacemos productos cuyo detalle es imposible anticipar, implica riesgos, etc. Muchas veces, terminas sobrepasando presupuesto, sea el proveedor o el cliente quien paga. Hay que analizar bien el proyecto.

Si es algo repetible, digamos que haces sitios web estándar con cierto número de páginas y layout, puedes calcular el riesgo y hacer un contrato fijo. Nosotros no hacemos eso, pero sería un buen caso para precio fijo. Es cuestión de previsibilidad o imprevisibilidad.

Ben Aston:

Otra narrativa de moda es el pricing basado en valor. Es muy distinto al modelo duración y precio, ¿verdad? En el pricing basado en valor, puedes decir: “El valor de esto es 50k, así que te cobro 50k”, esperando gastarte menos haciéndolo, vendiendo el valor y no horas.

¿Puedes hablar de cómo ese pricing basado en valor se relaciona con el contrato simple de duración y precio, donde pagas por las horas que recibes? ¿Cómo afecta eso la rentabilidad? ¿Es más sencillo y rentable? ¿O hay casos complejos donde pierden dinero, y has pensado “Si hubiera cobrado un millón, quizá lo hacía por menos y ganaba más”?

Tucker Sauer-Pivonka:

Buena pregunta. Son dos cosas distintas. Cuando hacemos software bajo este modelo, no siempre sabes cuál será el resultado final. Como no es predecible, es difícil poner precio desde el inicio. El cliente puede cambiar de opinión, el final puede variar. El pricing basado en valor funciona cuando puedes decir “Entregamos esto que da tal valor al negocio”, quizá un design sprint, por ejemplo, es más fácil con algo acotado. En un gran producto, es más difícil.

A nivel de rentabilidad, lo bello de duración y precio es que está incluido en la forma en que trabajas. El cliente tiene asignada una parte del equipo, y eso es lo que obtiene: entregas valor sprint tras sprint. Así, no hay sobrecostes ni preocupación por “pasarse de horas” porque no lo rastreamos de esa forma; el cliente no paga por hora.

Ben Aston:

O sea, ¿compran un equipo por un periodo? ¿Alguna vez el cliente dice, después de varios sprints: “No siento que haya valido la pena”? Todos cometemos errores, sobre todo en desarrollo, las cosas no siempre salen como se espera. ¿Cómo manejan ese escenario?

Tucker Sauer-Pivonka:

Sucede muy rara vez porque trabajamos mucho la alineación con el cliente. No solo al inicio del sprint, sino durante cada sprint, informando sobre cualquier cambio. La gestión y comunicación con el cliente es clave.

Como dije antes, por eso el equipo de producto enfatiza tanto ese tema, porque permite decir humildemente: “Pensamos que tomaría dos sprints, pero serán tres o cuatro por esto”. Expones los hechos claramente, para que el cliente decida y quite la emoción de la ecuación.

En cada sprint, antes incluso de arrancar, nos alineamos sobre qué se va a incluir. Nos aseguramos de que el equipo esté cómodo con el objetivo del sprint. Al final, hacemos demo, y si hay cosas nuevas o pendientes, lo debatimos y aseguramos la comprensión del cliente. Así, no hay sorpresas.

Ben Aston:

Genial. Quiero entrar en el caso de estudio y la línea de tiempo. Dices que sabían que sería al menos siete meses de trabajo. ¿Cómo hicieron esa estimación si no sabían exactamente qué construir? ¿Fue antes o después de la fase de prototipo?

Tucker Sauer-Pivonka:

Buena pregunta. En ese caso, y normalmente, fue después de hacer algún trabajo de prototipado o validación. Esa fase suele durar seis semanas, e incluyó una auditoría técnica del sistema existente. Eso ayudó a definir el plazo necesario para cumplir los objetivos. La estimación se basa en la experiencia, a medida que haces más proyectos comprendes los tiempos y la complejidad.

Luego, el equipo de producción se reúne para ver cuáles son las metas y piezas del proyecto, calcular la complejidad de cada parte, y así darles un “talla de camiseta” (estimación general). De ahí surge la recomendación del tamaño del equipo, cuántos desarrolladores, qué fracciones de tiempo, según la complejidad.

La duración no se basa en entregables, sino en metas de negocio. Sabíamos que había suficiente trabajo para siete meses y que el equipo podría enfocarse y cumplir metas en ese lapso. También depende del presupuesto del cliente, porque el software nunca se acaba; siempre hay cosas nuevas.

Decidimos que siete meses era lo mínimo necesario para llegar a lo que pedían, aunque podría necesitarse más tiempo, pero así llegamos a esa cifra. Nos centramos en los objetivos del negocio, el apetito de presupuesto y la realidad de que siempre se puede seguir iterando, pero trabajaremos sprint a sprint según las prioridades del cliente.

Ben Aston:

Supongo que parte de esa evaluación fue ver si el cliente solo podía pagar siete meses o tenía presupuesto para seguir más allá…

Tucker Sauer-Pivonka:

Exacto. Por ejemplo, si el cliente sólo quiere tres meses, sin problema. Trabajamos en los principales prioridades en ese lapso. Es como “alquilar un equipo” que entregará lo que pueda en ese tiempo, y adaptamos la prioridad conforme avanza el trabajo.

Ben Aston:

Mencionaste que la primera fase es de prototipo y validación. ¿Es a precio fijo? ¿Dices seis semanas; lo basan en tres sprints de dos semanas y pactan entregables definidos?

Tucker Sauer-Pivonka:

Técnicamente, sigue siendo duración y precio, pero sí, se asemeja más a un precio fijo comparado con el contrato estándar. Ahí sí definimos entregables: prototipo de alta fidelidad, archivos de Sketch, entrevistas de usuario y notas/resultados de la investigación.

Sin embargo, sigue siendo basado en duración; si a la mitad surge algo inesperado que requiere volver a la mesa de diseño, lo hacemos. No se exige “tienes que tener X pantallas exactas”. Es duración y precio.

Ben Aston:

Eso está bien, porque incluso en prototipo suelen surgir cambios y solicitudes antes de probar con usuarios, muchos clientes quieren empezar a modificar sobre la marcha, lo que puede complicar el proceso si se basa en entregables cerrados—pero aquí funciona bien.

Entonces, tras el prototipo y pruebas, dicen “serán unos siete meses de trabajo”. ¿Arrancan de arriba hacia abajo o al revés, por la cifra medio-millón/un millón? ¿Preguntan al cliente por presupuesto o simplemente proponen lo que consideran necesario?

Tucker Sauer-Pivonka:

En este caso, teníamos una idea preliminar del tamaño y complejidad de cada parte, así que podríamos armar una hoja de ruta—dejando claro que podría cambiar. Así sacamos los siete meses.

No sabíamos el apetito de presupuesto al presentar la propuesta. Armamos la propuesta explicando lo hecho, los siguientes pasos, la hoja de ruta y lo que incluiría cada bloque, según prioridades y sujeto a cambios por parte del cliente.

Tener al equipo técnico, a mí mismo y a nuestro estratega, ayudó a definir los siete meses. Por ejemplo, sabíamos que tal sección del app tomaría un mes y medio. Juntamos todo y así salió el cálculo.

Ben Aston:

Genial.

Tucker Sauer-Pivonka:

Al presentarles la propuesta, les decimos que si no funciona, se puede ajustar. Podemos hablar sobre empezar con tres meses, si así lo prefieren. Pero como había confianza y la definición de MVP era clara, pudimos armar la hoja de ruta y llegar a siete meses.

Ben Aston:

Ahora sobre la metodología—describiste un enfoque ágil tipo Scrum. ¿Qué toman de Scrum “biblia” (muy prescriptiva) y qué dejan fuera? ¿Cómo difiere el rol de product owner, por ejemplo, si pertenece al cliente o al equipo? ¿Tienen Scrum Master? ¿Cómo difiere el enfoque respecto a Scrum tradicional?

Tucker Sauer-Pivonka:

Acá tenemos una frase: anteponemos las personas al proceso. Practicamos Scrum con “s” minúscula. Es decir, damos flexibilidad para que el proceso no limite al equipo; si el equipo necesita adaptar algo para su cliente, tiene total autonomía. Así es nuestro enfoque. Con respecto a los roles:

En una agencia, tener roles exclusivos para todo es difícil. En empresas de software como Apple, eso es distinto por la estructura de negocio. En agencia es diferente. Por ejemplo, el Product Owner suele ser el contacto principal del cliente. Si tenemos un estratega, puede actuar como co-product owner apoyando y guiando a ese cliente, porque muchos no tienen experiencia construyendo software. El estratega les ayuda a tomar decisiones de dirección estratégica.

A veces, el Product Manager de nuestro lado asume responsabilidades de owner cuando el cliente no puede estar siempre presente, pero siempre reportando al cliente.

El Product Manager también asume el rol de Scrum Master, lo que va contra la ortodoxia Scrum, pero nos funciona bien. Gestionamos todas las ceremonias, las dailys son automatizadas, revisamos los impedimentos, etc. Es práctico porque tenemos toda la información necesaria para decidir.

Así que esas son, probablemente, las principales diferencias con el Scrum “de manual”. Por lo demás, hacemos planning, estimaciones, retros, demos… Todo lo que se espera, a menudo agrupado en una sola reunión semanal, llamada “Kick-Off” de miércoles. Es bastante parecido.

Ben Aston:

Has dicho que a veces el cliente es Product Owner y otras es un Product Manager del equipo. Quiero hablar de la gestión del cambio. En el caso de estudio mencionas prioridades en conflicto: que querían construir lo nuevo, pero los sistemas antiguos, como pagos, había que mantenerlos y empezaban a fallar.

En estos casos, el cliente quiere ambas cosas: avanzar en lo nuevo y arreglar lo viejo, aumentando el alcance. ¿Cómo gestionan esos conflictos y cómo educan al cliente para administrar el backlog? ¿Cómo lo hacen en términos prácticos dentro de la herramienta (Trello, Jira, etc.)?

Tucker Sauer-Pivonka:

Primero, hay que ser empático con las razones del cambio de prioridades. La mayoría de clientes tampoco quiere cambiar el foco, pero si lo piden, es porque realmente lo necesitan.

Hay que entender la causa: ¿es realmente prioritario? ¿O es una petición de stakeholders? Una vez entendido, comunicas que cambiar la prioridad implica cambiar todo el plan.

A menudo pasa: el equipo tiene el foco en una gran funcionalidad, pero aparece una “urgencia” porque un cliente del cliente necesita otra cosa, y debemos actuar. Hay que explicárselo al equipo para que entiendan el porqué y quiten la emoción o frustración.

Luego, aseguramos que el cliente entienda que al hacer esto, las demás tareas se retrasan. No pasa nada, pero hay que advertirlo para que no haya sorpresas.

En el caso de estudio, creíamos saber cuándo acabaría ese trabajo, y no fue así. Requirió mucha comunicación para decir “al atender esto, apartamos la meta general del negocio”. Está bien hacerlo, pero hay que dejar clara la implicación.

En cuanto a herramientas, cualquier visualización ayuda: sea Jira o lo que sea. A veces, una imagen vale más que mil palabras. El cliente pueda ver el impacto visualmente.

Ben Aston:

¿Les das acceso a Jira? ¿Lo usan?

Tucker Sauer-Pivonka:

Sí. Somos totalmente transparentes con nuestros clientes; tienen acceso a todas las herramientas, están como invitados en nuestro Slack. Entran en Jira y revisan prioridades y requerimientos. Así están alineados y no hay sorpresas al final de sprint.

Ben Aston:

Y hablas de confianza y transparencia. En tus lecciones aprendidas mencionas entregar artefactos, actualizaciones de roadmap, burn-down chart… ¿Cómo evitas saturar al cliente poco técnico cuando puede ver backlog, progreso, comentarios en tickets, etc. sin esconder nada?

Tucker Sauer-Pivonka:

Buena pregunta. Una clave es ser humilde y admitir errores ante el cliente. Eso genera confianza porque ven que contamos todo y nos importa mejorar. Ellos entienden que su éxito es nuestro éxito y queremos hacer bien el trabajo.

No exigimos que usen las herramientas, pero si quieren ahí están. Hacemos videos personalizados explicando cómo usarla, qué buscar, qué no es relevante para ellos, etc. Si se sienten abrumados, que nos lo digan y lo ajustamos.

En realidad, no hemos tenido muchos problemas en ese aspecto. A veces, lo abrumador es revisar demasiados diseños, pero lo manejamos entregando cosas de manera iterativa para que no les llegue todo de golpe. No siempre se puede evitar, pero advertimos cuando está pasando.

Ben Aston:

A nivel de reporting, ¿das reportes de tiempo invertido, timesheets, etc.? ¿O simplemente confían en que el equipo trabajó el tiempo contratado?

Tucker Sauer-Pivonka:

Nos enfocamos en los resultados. En el cierre de cada sprint revisamos lo completado, lo no completado, la velocidad, y por qué subió o bajó.

No reportamos horas, porque no se paga por hora. El seguimiento del tiempo sirve internamente: si alguien está pasándose del tiempo acordado, hablamos con el cliente para ajustar carga o asignación, o bajar si es temporada baja—aunque lo normal es que las asignaciones sean adecuadas.

Puede haber variaciones semana a semana, pero normalmente se compensan pronto. Sólo reportamos avance y trabajo completado, nunca hemos tenido problemas por eso.

Ben Aston:

Última cuestión: ¿cuándo no funcionan los contratos de duración y precio? ¿Te ha pasado que algo se derrumbe porque el cliente está insatisfecho con el avance? ¿Qué deberían vigilar quienes quieran implementar este modelo?

Tucker Sauer-Pivonka:

Sí, puede salir mal, sobre todo si el cliente está insatisfecho con el avance. Mi consejo es que, si detectas señales de eso, y si te comunicas seguido lo notarás, no lo dejes pasar. Hay que tener la conversación cuanto antes, ser franco y buscar el origen de su malestar. Si esperas al final, será tarde y perderás la oportunidad de reconstruir confianza.

En mi experiencia, nunca ha colapsado un proyecto, pero sí tuve un caso al punto de renovar, que el cliente estaba insatisfecho. Hablé con ellos para entender el fondo, y resultó que cambiamos de foco por prioridades de negocio y eso retrasó cosas clave, pero al explicarlo, lo comprendieron y recordaron conversaciones previas sobre las implicaciones de esos cambios.

Con cada conversación, se construye confianza. Si persiste la desalineación y el cliente no quiere corregir, quizá no eres el partner ideal y está bien. Lo importante es detectar esto pronto en el proceso de venta.

Ben Aston:

Creo que una lección aquí es que este modelo requiere el cliente adecuado—cierta madurez, comprensión de que si cambian prioridades, cambia el costo y el tiempo. Es complejo, porque los clientes quieren todo rápido y barato, y si compites con otros, nadie muestra todas las cartas. Pero eso no genera las condiciones ideales para gestionar expectativas realistas.

En mi opinión, se trata de educar al cliente desde el onboarding hasta la fase de validación, poniendo límites y explicando cómo será la relación y cómo deberá priorizar valor según su visión durante el engagement. Al final, el cliente obtiene mejor resultado que si la agencia toma atajos o prioriza por cumplir presupuesto o deadline.

En fin, los contratos de duración y precio son un concepto interesantísimo. Así que, Tucker, muchas gracias por acompañarnos hoy.

Tucker Sauer-Pivonka:

Claro, ha sido una gran conversación. Gracias por invitarme.

Ben Aston:

¿Y tú qué opinas? ¿Has probado un contrato ágil? Cuéntanos tu experiencia. Comenta en este post y visita TheDigitalProjectManager.com para unirte a nuestro equipo de Slack, donde encontrarás todo tipo de conversaciones interesantes sobre la entrega de proyectos. Tenemos un canal ágil, sería genial discutir esto ahí.

Y si te ha gustado lo que escuchaste hoy, suscríbete y tómate un par de minutos para dejarnos una reseña honesta en Apple Podcasts para el podcast DPM. Las valoraciones y reseñas nos ayudan mucho y son muy apreciadas. Hasta la próxima, gracias por escucharnos.