Controlando el (Alcance) Creep (con Suze Haworth)

Lee la transcripción:

Estamos probando la transcripción de nuestros podcasts usando un programa de software. Por favor, disculpa cualquier error ortográfico, ya que el bot no es 100% preciso.

Ben Aston:

Bienvenido al podcast de DPM, donde vamos más allá de la teoría para darte consejos de expertos sobre cómo liderar mejores proyectos digitales. Gracias por sintonizar. Soy Ben Aston, fundador de The Digital Project Manager. Ahora, si hay algo que descarrila casi todos los proyectos, es el scope creep (desviación del alcance). Todos sabemos que es negativo. Todos sabemos que queremos evitarlo. Pero, ¿cómo lo identificas en todas sus variantes? ¿Qué lo causa? ¿De quién es la culpa? Y, lo más importante, ¿cómo lo enfrentas realmente? Todo esto será revelado en el podcast de hoy, donde hablamos sobre controlar "creeps" del alcance del proyecto.

Este podcast es patrocinado por Clarizen, el líder en software de gestión de proyectos empresariales.

Más información en clarizen.com

Hoy estoy con Suze Hayworth. Suze es una de nuestras expertas DPM en The Digital Project Manager y trabaja como directora de proyectos digitales freelance en Londres, Reino Unido. Tiene más de 10 años de experiencia trabajando en agencias y ha vivido mucho scope creep, así que es la persona ideal para hablar con nosotros hoy. Suze, bienvenida.

Suze Hayworth:

Hola, Ben.

Ben Aston:

Entonces Suze, estábamos conversando antes de empezar a grabar. ¿Puedes contarnos un poco sobre los proyectos en los que estás trabajando actualmente y, ya sabes, algunos de los retos que estás enfrentando?

Suze Hayworth:

Sí, ahora mismo estoy trabajando en una agencia en Londres como freelance, así que estoy repartida entre un rol de directora de proyectos y directora de cuenta en dos clientes. Uno de ellos es IKEA, una gran compañía de retail y comercio electrónico. Estamos desarrollando un sistema de diseño para ellos, una especie de prototipo de sistema de diseño. Y también estoy con otro retailer online en Reino Unido. Así que muchos proyectos de retail por ahora. Sí, y los retos, supongo, siempre es difícil hablar de los retos... especialmente cuando todavía están vigentes. Sí, creo-

Ben Aston:

¿Es ese cliente fastidioso?

Suze Hayworth:

Sí. No, en realidad. Son muy buenos clientes con los que trabajo actualmente, tengo que decirlo.

Ben Aston:

Debes hacerlo.

Suze Hayworth:

Es cierto. Son clientes muy buenos los que tengo en este momento. Creo que lo bueno y lo malo de los proyectos, y del rol en gestión de proyectos en general, es trabajar con personas. Me encanta trabajar con diferentes personas, personalidades y particularidades. Pero a veces llegas al punto en que te frustra tratar de sacar cosas de quienes no quieren cooperar. Así que sí, he tenido un poco de eso recientemente.

Ben Aston:

Diversión y juegos. Bueno, cuéntanos sobre el proyecto para construir un sistema de diseño, porque creo que es interesante, y de hecho, es el tipo de proyecto que cada vez se ve más. Antes quizás, todos trataban cada proyecto como algo único, y los creativos querían ser creativos. Así que cuéntanos, ¿qué es un sistema de diseño? ¿Y cómo... en qué consiste el proyecto? ¿Cómo lo estáis desplegando?

Suze Hayworth:

Sí, es un proyecto realmente emocionante porque, como dijiste, los sistemas de diseño están ganando relevancia en el mundo digital. Básicamente son como una biblioteca de estilos para el diseño digital de empresas y marcas. Establecen una base de componentes, módulos, plantillas que cualquier diseñador o desarrollador que trabaje con la marca puede usar para crear sus propios diseños y código. Es como una base, un diseño base que promueve eficiencia; código y diseños reutilizables, además de eficiencia y coherencia en la empresa.

Por ejemplo, una marca como IKEA, que es enorme y tiene muchas agencias, personas y organizaciones involucradas, con ese sistema de diseño se puede fijar un estándar que diseñadores y desarrolladores pueden usar. Así, por ejemplo, un botón de llamada a la acción puede ser coherente en múltiples plataformas, dispositivos y apps.

Ben Aston:

Entonces, háblame del proceso de gestión de estos proyectos porque es... Puede ser un proyecto "infinito". ¿Por dónde empiezas? ¿Sobre qué iteras? ¿Dónde acaba el producto?

Suze Hayworth:

Sí, en el caso de IKEA, muchas marcas hacen estos proyectos internamente. Pero IKEA buscó apoyo externo y nos pidió que colaborásemos en el diseño. Es una decisión inteligente porque como externos podemos revisar todo con una mirada menos influenciada por la cultura interna. Empezamos revisando los principios, los básicos digitales y el concepto detrás del diseño y los principios de marca de IKEA. Esa fue la preparación, una mirada estratégica a la experiencia y los principios de diseño. Luego fuimos bajando a materiales concretos, estableciendo una base de diseño sobre los elementos existentes, como color, tipografía, grids, y luego desarrollamos más a partir de ahí.

Hicimos pruebas de usuario con ese diseño sobre algunas plataformas seleccionadas del ecosistema IKEA y avanzamos hasta diseñar y construir componentes específicos, luego alojarlos en una web interna. Porque lo que buscamos es un prototipo versátil inicialmente, para ponerlo en marcha, que luego se desarrollará en una solución completa al finalizar esta etapa.

Ben Aston:

Genial. ¿Esa solución final es una guía de estilos viva con fragmentos de código y plantillas reutilizables? ¿Ese es el objetivo?

Suze Hayworth:

Sí, creo que cualquier sistema de diseño debe ser un ente activo, en evolución. No termina nunca, no es un producto que se finaliza y ya está. Apenas estamos rascando la superficie, asentando principios, bases y componentes iniciales. Después toca agrupar componentes, desarrollar módulos, crear plantillas... y pensar cómo lograr que la gente lo use, cómo incorporarlo y formarlos. Es un gran, gran proyecto, especialmente con tanta gente y tantos equipos implicados. Así que sí, aunque llevamos casi un año, apenas hemos empezado.

Ben Aston:

Suena divertido. Me intriga saber si has encontrado herramientas nuevas, o algo que te facilite la vida actualmente. ¿Algún descubrimiento que deban conocer los demás?

Suze Hayworth:

No he utilizado demasiadas herramientas nuevas, la verdad. Sigo con lo que conozco. Es irónico estando en un podcast, pero últimamente escucho más podcasts. Antes escuchaba música en el camino al trabajo, pero ahora uso ese tiempo más útilmente para escuchar podcasts diversos, lo que me ha ayudado a aprender y aprovechar un rato en el... iba a decir sentado pero nunca hay asientos; de pie camino del trabajo, jeje. Así que lo uso aparte de música.

Ben Aston:

¿Hay algún podcast que te haya resultado realmente útil o interesante?

Suze Hayworth:

Tengo que decir el podcast de The Digital Project Manager, sin duda. Ese es indiscutible. Hice uno para otro podcast, después de mi sesión en la DPM Summit. También en "The Bureau of Digitalists", con Brett, quien ahora ha lanzado uno llamado "Sprints and Milestones", basado en su libro sobre la gestión digital de proyectos. Es un recurso útil.

Ben Aston:

Genial. Así que toca escuchar podcasts. Algo que me ha llamado la atención es Blinkist. Tengo que ser honesto: apenas escucho otros podcasts más que el mío. Siempre pienso que debería leer más, pero compro los libros y nunca los leo. Blinkist resume libros en unos 15 minutos que puedes leer o escuchar, como si fuera un podcast. Puedes acelerar la reproducción, así te "lees" un libro o lo escuchas en siete minutos y medio.

Suze Hayworth:

Creo que lo he oído. Es genial. Tengo que probarlo porque también intento leer más últimamente. Leer más libros estaría bien.

Ben Aston:

Ese es mi truco de lectura para todos. Genial. Bueno, el tema de hoy es el scope creep. Así que hablemos sobre eso. Para quienes no estén familiarizados, ¿qué es y por qué debemos preocuparnos?

Suze Hayworth:

Básicamente es cuando tu alcance y entregables acordados se expanden sobre lo originalmente pactado, y no se tiene en cuenta en términos de tiempo extra. El proyecto puede verse afectado de muchas formas; las cosas se cuelan, aumentan los plazos y lo que hay que entregar.

Ben Aston:

Genial. Así que sí, es el trabajo adicional que no habíamos calculado y que impacta al presupuesto, al cronograma y al alcance. ¿Cuáles dirías que son los motivos más típicos y cuáles los más "furtivos"?

Suze Hayworth:

Entre los motivos más típicos está la falta de claridad sobre el alcance. Si el statement of work al inicio es vago o ambiguo, lo que entregas puede interpretarse diferente por el cliente o el equipo. Así que el proyecto crece por esa indefinición. Hay que ser explícito y asegurarse de que quien aprueba el alcance entienda bien lo que obtendrá. Y si crees que lo leyeron, asegúrate revisando con ellos en una reunión inicial.

He visto problemas en el pasado donde todo estaba supuestamente definido, pero la gente luego dice "pensé que eso estaba incluido" porque no se explicitó lo suficiente.

Ben Aston:

Así que no ser claros ni asegurarse de que el cliente comprende el alcance son las formas más comunes de generar scope creep.

¿Y de los casos más furtivos? ¿Cómo ocurre ese scope creep sin darnos cuenta?

Suze Hayworth:

Lo típico es pensar que es culpa del cliente, por pedir más, pero lo he visto nacer del equipo interno. Si el equipo no entiende bien qué debe hacer, pueden desviarse y aumentar plazos y funcionalidades sin darse cuenta. Un diseñador puede añadir cosas no contempladas, o querer lucirse con detalles no previstos. Lo mismo con otros stakeholders internos que buscan mejorar la relación con el cliente, ofreciendo más sin avisarte. Eso también pasa mucho.

Ben Aston:

Totalmente de acuerdo, a veces viene del "gold plating" interno. En estrategia, UX, diseño o desarrollo, alguien quiere hacer algo que destaque, pero nadie acordó quién cubre ese trabajo extra.

Suze Hayworth:

Exacto.

Ben Aston:

¿O quién se hace responsable? Así que ir "por libre" es definitivamente un riesgo...

Suze Hayworth:

Buena forma de llamarlo.

Ben Aston:

Sí, y los QA también. Si no hemos definido los criterios de aceptación desde el inicio, o no les decimos a los de QA que no revisen sobre IU9 porque no nos importa, pueden testear plataformas que no necesitamos. O los desarrolladores corrigen cosas sin importancia. ¿A ti te ha pasado?

Suze Hayworth:

Completamente. QA es una de las áreas críticas, especialmente en proyectos con mucha incertidumbre. Si no defines criterios de aceptación, matriz de navegadores y dispositivos, prioridades de bugs desde el principio, el proceso de QA puede crecer y crecer. Es importante ser transparentes y comunicar con el cliente si QA está requiriendo más esfuerzo en algo inesperado y ofrecer alternativas, como priorizar según el uso real.

Lo esencial es definir el alcance lo mejor que puedas y comunicarlo desde el inicio. Pero a lo largo del proyecto, la clave es la comunicación: exponer pronto posibles desviaciones y alternativas de solución.

Ben Aston:

Hemos hablado de varias causas del scope creep: alcance poco claro, trabajo fuera de lo acordado, QA... Ahora, ¿de quién es la culpa? No para buscar culpables, sino para saber cómo actuar. ¿Hasta qué punto es nuestro problema como project managers?

Suze Hayworth:

No se trata tanto de culpar sino de identificar riesgos. Mirar quiénes son las personas que pueden provocar scope creep en tu proyecto ayuda a anticipar riesgos futuros. Y nosotros como PMs podemos ser responsables si no señalamos cuando ocurren desviaciones. Hay una tendencia a intentar solucionar el problema sin contarlo al cliente, para no parecer negativos. Yo también lo he hecho alguna vez. Pero es más fácil ser honesto y enfrentarlo rápido, mejor aún si aportas soluciones y alternativas.

Si el problema surge internamente, se puede intentar corregir y también informar al cliente. Si el cliente pide algo fuera de alcance, no lo asumas para "quedar bien"; analiza el impacto y plantea opciones y prioridades.

Ben Aston:

Ya estamos hablando de cómo afrontarlo, pero como PMs podemos ser más claros en el alcance. Pedir ayuda a QA o a un analista de negocio puede ayudar a identificar lagunas. Y en vez de lanzar el statement of work y esperar que el cliente lo lea y firme, es útil revisar juntos, para evitar malentendidos.

Sobre cómo actuar, lo importante es no "esconder" los desvíos con la esperanza de que no pase nada. Siendo proactivos y transparentes, analizando impactos y prioridades, es mucho más fácil ajustar las expectativas del cliente.

También hay que considerar que, aunque el scope creep se asocia mucho a Waterfall, puede ocurrir en ágil. Es común que, en un proyecto scrum, el product owner intente meter algo en medio del sprint ya planificado. Si no se gestiona bien y no se reprioriza, eso es scope creep. Pero con la periodicidad de ágil, es más fácil reaccionar a esos cambios.

Suze Hayworth:

Eso es. Quería que quedara claro que el scope creep no siempre es negativo. En ágil se trata precisamente de abrazar el cambio, que puede mejorar el resultado final. Lo importante es cómo lo gestionas, no rechazarlo de entrada.

Lo esencial es analizar cada nueva petición, ver el beneficio para el usuario y decidir juntos las prioridades, dejando que el alcance evolucione en base a prioridades reales y manteniendo siempre la conversación abierta con el cliente.

Ben Aston:

Exacto. Cambiar la conversación y pensar en el usuario es fundamental. Scope creep no tiene por qué ser siempre malo; puede ser bueno para los usuarios, para el cliente, el proyecto y los equipos. No hay que huir, sino gestionarlo.

Para quienes sienten que sus proyectos siempre acaban fuera de plazo o presupuesto, ¿qué consejo das para retomar el control?

Suze Hayworth:

Si llegas a un proyecto desde cero, lo fundamental es trabajar bien la estimación y el alcance, asegurarte de que el equipo estime contigo, y no solo tú. Si es un proyecto avanzado y descontrolado, analiza bien cómo de lejos estás respecto a lo previsto, define claramente lo que falta y comunica de inmediato al cliente la situación y opciones.

Ben Aston:

Genial. Suze, muchas gracias por acompañarnos. Ha sido un placer, y como experta DPM, Suze también participará en nuestro próximo curso que comienza en febrero: “Dominando la gestión de proyectos digitales”. Es un curso intensivo de siete semanas, con lecciones en vídeo, ejercicios, webinars, debates en grupo y sesiones de coaching. Ve a DPMschool.com para inscribirte antes de que se agoten las plazas. Y si quieres aportar algo al debate sobre scope creep, comenta en el post y pásate por la sección de recursos de TheDigitalProjectManager.com, donde también puedes unirte a nuestro equipo en Slack y encontrar debates interesantes. Hasta la próxima, ¡gracias por escuchar!