Clavando los Requisitos (con Kelly Suter de BI Worldwide)

Lee la transcripción:

Estamos probando transcribir nuestros pódcasts usando un software. Por favor disculpa cualquier error, ya que el bot no es correcto el 100% del tiempo.

Ben Aston:

Bienvenido al DPM Podcast, donde vamos más allá de la teoría para ofrecer consejos expertos de dirección de proyectos digitales. Gracias por sintonizar, soy Ben Aston, fundador de The Digital Project Manager. Sé honesto, ¿alguna vez tu cliente te ha dicho al final de tu proyecto: “Oye, lo has clavado absolutamente, es exactamente lo que queríamos, es precisamente lo que dijiste que harías al principio del proyecto, y es increíble cómo lograste capturarlo todo sin dejar cosas por el camino"?

Bueno, sospecho que eso no ha pasado. Y probablemente sea porque tus requisitos no estaban bien definidos. Entonces, ¿cómo puedes gestionar los requisitos para no meterte en un lío más adelante en el proyecto, pero darle tanto al cliente como al desarrollador la información que necesitan para hacer su trabajo? De eso va el pódcast de hoy, de los requisitos del proyecto.

La forma en la que definimos un proyecto y sus funcionalidades para nuestros clientes, para que todos sepan lo que se va a entregar. Esencialmente, los requisitos, creo que son una herramienta de comunicación, pero realmente es difícil acertar con ellos, porque si definimos los requisitos demasiado vagamente, nos damos cierta flexibilidad, pero quizá no obtengamos exactamente lo que queríamos. Y si los definimos demasiado estrictos, puede que falten muchas cosas. ¿Cómo logramos el equilibrio adecuado?

Hoy hablaré con Kelly Suter. Kelly es gerente de proyectos técnicos en BI Worldwide, y una de nuestras expertas residentes en The Digital Project Manager. Hola Kelly.

Kelly Suter:

Hola, gracias por invitarme Ben.

Ben Aston:

No, es genial tenerte aquí. Creo que este es nuestro segundo pódcast, ¿verdad?

Kelly Suter:

Sí, lo es.

Ben Aston:

Hicimos un pódcast hace tiempo. Para quienes hayan olvidado quién eres, ¿quieres darnos una visión general, cómo llegaste a la gestión de proyectos? Has seguido un camino interesante, creo, aunque no muy diferente al de muchos gerentes de proyecto. Nadie quiere ser gerente de proyectos cuando es pequeño, pero cuéntanos tu historia, ¿cómo es que ahora eres PM digital?

Kelly Suter:

Sí, empecé mi carrera profesional como reportera deportiva, en realidad, y estudié Comunicación especializada en relaciones públicas y medios. Cuando me di cuenta de que los periódicos ya no eran algo emergente, decidí mirar hacia la industria publicitaria, y fui publicista durante unos tres años, para una marca, Sesame Street Live, y realmente trabajé esa marca durante esos tres años. De hecho, me contactó alguien de una tienda de comercio electrónico personalizada, una agencia digital dedicada al eCommerce.

Ella dijo: "No tenemos un departamento de gestión de proyectos aquí, ¿quieres ser gerente de proyectos?" Y yo dije, "¿Qué es eso?" Mi padre tenía una agencia de diseño gráfico, así que crecí familiarizada con los procesos de agencia, lo suficiente para saber que era loco y siempre muy agitado. Pero pensé: "Sí, me interesa, veamos qué tenéis por ahí." Fui allí, y el primer libro que leí fue de Meghan McInerny, Personas, píxeles y procesos. No sé si lo dije en el orden correcto, pero lo leí, lo apliqué—

Ben Aston:

Lo conozco, sí.

Kelly Suter:

Sí. Yo—

Ben Aston:

Personas, píxeles… Creo que es Personas, píxeles y procesos, sí.

Kelly Suter:

Eso es. Y apliqué lo mejor que pude ese aprendizaje a la agencia en la que estaba, que tenía unas 12 personas. Como dije, hacíamos sitios web a medida de tipo catálogo y de comercio electrónico. Y después de unos cuatro años, había formado un equipo de siete gerentes de proyectos y logramos aplicar un proceso que se seguía desarrollando y evolucionando. Desde ahí, quise ampliar mi conocimiento técnico, y surgió la oportunidad de un puesto como gerente de proyectos técnicos donde estoy ahora, en BI Worldwide, así que me vine aquí; quería volver al mundo PM, estar más cerca de los proyectos y afilar mis herramientas técnicas. Así llegué a donde estoy hoy, ha sido emocionante, ha pasado volando, pero me encanta.

Ben Aston:

Siempre tengo curiosidad, ¿esto es ahora tu… Cuéntame, ¿cuál es tu trabajo soñado? Parece que has pasado por trabajos interesantes: reportera deportiva, trabajando para Sesame Street, y ahora PM técnico en tecnología, pero ¿qué te gustaría ser cuando “seas mayor”?

Kelly Suter:

Buena pregunta. Creo que lo que más me gusta de lo que hago y de donde estoy, y de donde estuve hace poco, en Irish Titan, aquella otra empresa de desarrollo, es que me encanta llegar a un lugar donde está claro que el proceso no está realmente definido o apenas empieza a evolucionar. No quiere decir que el equipo no sea talentoso y saque grandes cosas ya, pero me gusta asumir retos directos, donde puede implementarse un proceso, y sentir el alivio del equipo de “Por fin tenemos algo sobre lo que apoyarnos”. Mi trabajo soñado sería ser esa persona “apagafuegos” para empresas nuevas, quizá startups, llegar y decir “Sabemos implementar este proceso, vamos a hacerlo aquí, y aquí también”. Me encantan los retos jugosos.

Ben Aston:

Genial. Cuéntame, ¿cuáles son los retos actuales que enfrentas? Relacionado con esa idea de ser “apagafuegos” y definir procesos, crear documentación, refinar los procesos… ¿Te enfrentas actualmente a algún reto particular?

Kelly Suter:

Actualmente, entre todos los retos habituales, el mayor es convencer, sin aburrir, al equipo de la importancia de la documentación. No quiero que parezca que vendo el tema de este pódcast, pero realmente es difícil cuando tienes un cliente y un equipo emocionados lograr total aceptación de “No hace falta frenar, ni perder el impulso, pero sí documentar”. Y luego, estandarizar esa documentación y cubrir nuestras bases; no tiene por qué ser tan tedioso, pero documentar lo suficiente para que si algún miembro se va o cambia de rol, no se pierda la lógica ni el proceso. He visto equipos reinventar la rueda constantemente, ya sea en su producto o en la documentación, sobre-ingeniando cosas que podrían estandarizarse o ser más eficientes.

Así que ahora mismo trabajo en documentar cosas cuyo último documento era de 2014, y ha funcionado para todos, pero no queremos que siga igual. Además, después de una auditoría, siempre viene bien tenerlo todo “zanjado”.

Ben Aston:

Genial, entonces en tu labor… estás definiendo procesos, creando documentación, refinando procesos. ¿Hay alguna herramienta que utilices y que te esté facilitando la vida ahora mismo? ¿Cómo gestionas eso?

Kelly Suter:

Sí, para documentación, no arreglo lo que no está roto, uso Google Suite. Si los clientes no tienen problemas de seguridad o privacidad con la información de la documentación que formalizas, Google Suite, Google Docs, espacio compartido, capacidad de establecer permisos para ver o comentar, o solo uso interno para el equipo.

Así no tienes que pensar en control de versiones, luego puedes exportar como PDF y tener un documento formalizable para firmar. En cuanto a escribir documentación, eso es lo que usamos. InVision es muy buena para validaciones creativas, comentarios al juntar la parte creativa. Ahí los diseñadores suben sus diseños o wireframes, vale para ambos, y los clientes o interesados pueden comentar, anotar los diseños finalizados en InVision, y exportar para documentación, porque lo visual ayuda mucho en la documentación. Si no tienes InVision, porque es de pago, Sketch. Sketch es una herramienta gratuita de Evernote para anotar diseños de forma bonita y simple. Subes los diseños, colocas números o letras para anotar, y trabajas así.

No lo complico demasiado, solo necesito importar mis diseños, anotarlos, ponerlos en documentación y luego escribir el texto. Eso es lo que me funciona para documentar.

Ben Aston:

Perfecto. Quiero profundizar más en tu evolución como PM digital. Ahora eres PM técnico, pero entiendo que usas varios sombreros: project manager, BA, analista de negocio, SCRUM master. ¿Cómo es diferente un PM técnico de un DPM? ¿Y cómo manejas esas diferentes funciones?

Kelly Suter:

Es muy buena pregunta. En mi caso, tengo suerte porque mi rol es único. En BIW hago tanto gestión de proyectos técnicos como tradicional. Hago gestión de eventos en vivo y gestión de contenido de cursos, que es un cuarto de mi trabajo. Los otros tres cuartos son de gestión de proyectos técnicos, y depende mucho del lugar. Hay gestión digital, técnica, ágil, todo precedido por “gestión de proyectos”, pero eres un PM. La mayor diferencia con mi trabajo anterior de DPM y mi rol actual de TPM es el nivel de profundidad técnica requerida en el trabajo digital, qué tan técnico es tu trabajo digital. Como DPM antes gestionaba todas las partes móviles: estrategia de contenido, arquitectura de la información, wireframes, diseño, y cuando se trata de desarrollo, simplemente decía "ok, sé que tienes que auditar estos datos, definir su exportación para inventario y avísame cuando termines".

Como PM técnica, estoy mucho más inmersa en la parte de desarrollo. Sigo gestionando entregables de creatividad, estrategia y QA, pero en desarrollo, quizá deba estar junto al lead dev durante QA, revisando código y lanzamientos, verificando que lo requerido se corresponda con el código antes de darlo por terminado. También escribo los requisitos técnicos. Estar más cerca de los requisitos implica más responsabilidad; cuanto más cerca estás de los requisitos, más tienes que participar en conversaciones posteriores.

Como DPM, gestionaba los requisitos, asignaba las tareas, y como TPM, los escribo. Estoy más “en las trincheras” en desarrollo.

Ben Aston:

Bien, entonces para los que no conocen qué son los requisitos funcionales o empresariales, ¿puedes explicar cómo es ese proceso?

Kelly Suter:

Al principio de cualquier proyecto, o al integrarte por primera vez en un equipo o empresa, hay que entender bien los roles y responsabilidades. Aunque estén definidos, pueden cambiar según el cliente. A veces trabajamos con integraciones personalizadas, por ejemplo, una base de datos de productos. El desarrollador puede profundizar en detalles que ni conozco. Así que no finjo saber, pero asumo hasta cierto punto y pido ayuda: "¿Me ayudas con esta parte de los requisitos?" Como propongo en mi artículo: preguntar “¿por qué?” varias veces, llegar a la raíz de lo que se quiere y dejar que el “dev” complete los requisitos técnicos donde yo no llego.

Hay que trazar límites y ser transparente. A veces me han preguntado "¿Por qué haces esto tú y no el analyst o el estratega?" y mi respuesta es: depende de en qué parte conviene invertir el presupuesto y ser eficiente. Todo es un equilibrio y debe comunicarse claramente.

Ben Aston:

Perfecto. Para quienes oyen términos como “diseño de requisitos empresariales” o “requisitos funcionales”, puede sonar confuso. Alguien dirá: “En la agencia hacemos diseño y luego lo damos a desarrollo”. Pero tú hablas de documentación, ¿no es lo opuesto a ser ágiles y flexibles?

¿Qué son estos documentos? ¿Por qué son importantes?

Kelly Suter:

Si hablamos de documentación de requisitos empresariales, que llamaré BRD, y de requisitos funcionales, FRD, el BRD es como un curso 101. Los puntos clave del negocio: traducir a español y mandarín, entregar 10 cursos, estar listo para abril, soportar base de datos de 6.000 usuarios. El BRD es una formalidad, un chequeo para que todos estén de acuerdo. Incluye advertencias del tipo “si esto se sale de alcance o se pasa de presupuesto, lo comunicaremos y priorizaremos lo que entra o va a una segunda fase”.

El FRD es otro punto de control, amplía cada punto con detalle: quién hace las traducciones, si es automático o manual, cómo se gestiona la introducción de los idiomas, etc. El BRD es el “estamos alineados”, sabiendo que el FRD evolucionará mucho. Si la traducción no entra finalmente por presupuesto, quedará documentado en el FRD y en lo demás te centras en definirlo por completo.

Uno lleva al otro y el FRD debería ser el plano de construcción.

Ben Aston:

Eso es. El BRD lo definimos al principio; marca el éxito desde el punto de vista del negocio. El FRD detalla cómo cada funcionalidad específica cumple con los requisitos empresariales (ejemplo: tener la web accesible en China implica localización en mandarín y detalles de implementación).

Pero, hablemos del tema ágil. Muchos desarrolladores dicen “muéstrame requisitos, sin ellos no puedo avanzar”, pero también a veces critican tener demasiada documentación. ¿Cómo logras el equilibrio entre un enfoque iterativo y definir requerimientos funcionales detallados?

Kelly Suter:

Buenísima pregunta. Para encontrar el equilibrio hay que tener claro de antemano, o incluso documentado, si se sigue un proceso ágil, definiendo lo que eso implica y lo que se necesita tanto del cliente como del equipo. Por ejemplo, ahora estamos construyendo un software que asigna puntos a aprendizajes. El cliente quiere el producto para enero y confía en nosotros. No hay tiempo de documentar todo pese a que me gustaría, así que el objetivo final está claro, pero sin definir todos los intermedios; semana a semana hacemos reuniones (stand-ups), asignamos partes del proyecto y cada dos semanas mostramos avances al cliente, aunque sean versiones sin pulir, para validar la funcionalidad. Hay APIs que determinan el funcionamiento de los puntos, y esa comunicación constante es vital.

Como PM, documento esas reuniones: qué mostramos, qué logramos, qué preguntas surgen. Así si el cliente espera algo diferente, puede expresarlo a tiempo y ajustamos el plan para la semana siguiente. El reto es revisar constantemente el rumbo y ajustar prioridades según sea necesario.

Ben Aston:

Exacto.

Kelly Suter:

Así, entre el producto final y el ahora, hacemos un seguimiento, calculamos lo que hay que dejar para después (certificados, por ejemplo) y qué sí hay que priorizar. Es cuestión de comunicación constante, documentación durante el proceso y confianza mutua.

Ben Aston:

Sí, en muchos proyectos si esperas a definirlo todo antes de empezar, nunca arrancas. Los requisitos funcionales ayudan a los desarrolladores a saber qué construir, al cliente le dan claridad sobre lo que recibirá, y a QA le permiten verificar lo que se prometió. El enfoque es hacer lo suficiente para mantener el proyecto avanzado.

Pero documentar tanto lleva mucho tiempo. ¿Cómo trabajas ese flujo? ¿Usas JIRA, algún sistema?

Kelly Suter:

Sí, cuando tengo un FRD finalizado —esto no lo hago en aislamiento, mantengo al equipo informado y hago preguntas durante el proceso—, y el documento está revisado por todos y aprobado por el cliente, entonces presento al desarrollo dos opciones: construir yo las tareas para cada ítem de los requisitos o dejar que el desarrollador los defina según prefiera. A menudo, después de revisar el FRD, les parece bien que yo cree las tareas: las organizo por tipo de página (registro, inicio, producto, etc.) y sub-tareas por cada línea. Luego, siempre intento que los propios desarrolladores estimen el tiempo; quien vaya a desarrollar debe estimar, no el mejor del equipo para que no se desfasen los tiempos. Así hay menor delta entre estimado y real. Uso JIRA (Atlassian) para la gestión, creo todas las tareas en backlog y los desarrolladores las estiman, las ordenan según su workflow y divido en sprints de semanas de 30-35 h, si es posible en single-thread. Para cada tarea ágil, añado una línea de cómo testear el requisito.

Ben Aston:

Perfecto. Quisiera tocar el tema de la estimación. Cuando un proyecto es más técnico, al principio el cliente quiere saber cuánto costará, pero aún no tenemos todo definido, ¿cómo equilibras la falta de definición de requisitos funcionales con la exigencia de una estimación global?

Kelly Suter:

Es una pregunta compleja. Como PM, casi nunca tengo autoridad para dar un estimado, sólo comentarios casuales tipo, “¿Podremos tenerlo para marzo?”. Cuando sí participo, lo primero es revisar qué hemos hecho antes, buscar proyectos similares, tamaño del cliente, base de usuarios, etc. Por ejemplo, un eCommerce en Magento 1 se hacía en 6-8 semanas, 2 desarrolladores; así teníamos un punto de referencia, no tanto en horas o dinero, pero sí de proporción. Lo explico al equipo comercial: si no hay integraciones ni personalizaciones, tenemos una idea de lo que puede costar, pero todo depende. Si tenemos un líder técnico, mejor, porque puede representar ese criterio. A veces, ese es el rol del PM técnico: tener a mano comparativas (si es eCommerce, LMS, etc.) y ser abiertos con el cliente sobre la estimación. Es complicado estimar con precisión en fases tempranas.

Ben Aston:

Sí, hablas de estimación análoga. Comparar con tres proyectos previos, dar un rango y explicar que la definición vendrá después, ayudando así al cliente a entender que ajustar requisitos es parte de la fase de descubrimiento. A medida que se definen, se puede estimar mejor.

Kelly Suter:

Sí, siempre hago dos ejercicios rápidos: desde el inicio pido al cliente priorizar entre alcance, tiempo, presupuesto, poniendo un orden de 1 a 3. Todos los quieren igual, pero deben elegir y eso clarifica. Puede cambiar luego, pero ayuda a encarar lo desconocido. El otro es “bueno, mejor, óptimo”: según el presupuesto, si surge una integración o algo espectacular pero complejo, pueden escoger si pagan más o eliminan otras funcionalidades. El cliente toma ese tipo de decisiones y siente que colabora.

Ben Aston:

Exacto, a veces el cliente nos fuerza a comprometernos con un presupuesto fijo en proyectos técnicos y no siempre es posible. Colaborar y hacerles ver que si amplían funcionalidades, aumentará el trabajo, así podemos ajustar estimaciones y enfoque según su prioridad.

Y finalmente, para quien nos escuche y quiera empezar a definir requisitos, ¿qué recomendarías como primer paso para introducir la idea de requisitos y mejorar la definición para el desarrollo?

Kelly Suter:

Siempre digo: si eres PM digital por primera vez, viviendo en esta era digital, conoces más de lo que crees. Ya tienes hábitos y experiencia con tecnología. Así que antes de lanzarte a buscar plantillas de documentación técnica y rellenarlas a ciegas (quizá lo hice antes…), primero pregúntate “¿Qué estamos haciendo para este cliente? ¿Una web de registro para un evento? ¿Qué hay que definir?” Repasa cada elemento de la página y piensa cómo funciona en móvil y escritorio. Explícalo como si fuera para tu abuela con móvil antiguo. Luego pregunta al dev, “¿Esto lo entiendo bien?” Lo agradecerá aunque suene obvio: mejor definir bien para que puedan desarrollar sin dudas.

Cuando empieces con requisitos, divídelo en elementos de lo que construyes y explícalo. Seguro tu primer documento será más conversacional e inconsistente entre páginas, pero está bien: irá mejorando. Esto es digital, puede ser nuevo para el cliente, y tú representas al experto. Camina el proceso con el cliente: sabes más de lo que crees porque vivimos en ello.

Ben Aston:

Muy útil. Creo que todo los requisitos giran en torno a hacer preguntas y resolver dudas. Si empiezas a definir requisitos, puedes pensar “¿será una pregunta tonta?”, pero nada se debe asumir. Piénsalo como si lo explicaras a tu madre o abuela.

Y recuerda que es una herramienta de comunicación: la documentación que ayuda a que todos estén alineados con lo que se va a hacer. Si tienes claridad, reduces el esfuerzo desperdiciado, el cliente no se defrauda, y minimizas rehacer cosas. Toma tiempo, sí, pero se recupera evitando malentendidos y reprocesos.

Kelly, muchas gracias por acompañarnos, ha sido genial contar contigo.

Kelly Suter:

Gracias, lo agradezco mucho.

Ben Aston:

Y como una de nuestras expertas en DPM, Kelly también participa en nuestro curso de Mastering Digital Project Management. Si no sabes de qué hablo, pero necesitas formación como PM, échale un vistazo. Es un intensivo de siete semanas, con lecciones en vídeo, tareas, debates grupales, webinars. Entra a dpmschool.com e inscríbete. Empezamos en febrero. Si quieres unirte a la conversación sobre requisitos, visita la sección de recursos de thedigitalprojectmanager.com para unirte a nuestro Slack, donde hay debates muy interesantes, o comenta en el post. Hasta la próxima y gracias por escuchar.