Por qué los productos exitosos hacen estudios previos: un caso de estudio de BøthOfUs
Puede haber mejores formas de hacer las cosas que enviar una simple lista de cosas que necesitan mejorar.
*El proceso de desarrollo de productos de BothOfUs
Recientemente regresamos de realizar un taller de estudio previo con un equipo en Alemania. Mientras estuvimos allí, discutimos una gran cantidad de temas, desde el largo plazo y los valores de la empresa hasta uno de mis principales objetivos, los mayores problemas que enfrenta el equipo en este momento.
Nos encanta facilitar talleres, ofrece una gran oportunidad para explorar realmente un tema y obtener una comprensión real, que a menudo es difícil de lograr en las tareas diarias habituales de nuestro negocio. También ofrece la oportunidad de agregar valor real al producto y ayudar al equipo a ahorrar entre 10 000 y 50 000 €.
Esta vez estábamos realizando un taller de 8 horas repartidas en 2 días. Aunque no parece mucho tiempo, al final, creo que todas nuestras mentes se sentían completamente utilizadas. Nuestros objetivos, evaluar cómo automatizar el proceso actual rápidamente y cómo manejar esto de una manera que no cause problemas a los usuarios existentes menos expertos en tecnología.
Suena bastante directo. Sin embargo, como descubrimos, eso realmente depende de cuán impresionantemente organizado pueda ser un individuo. Nos sorprendió lo compleja que era la estructura existente, más manual. Tenemos mucha compasión por el equipo que se mantiene unido para tener éxito.
*sugerimos diferentes modelos de taller dependiendo de los objetivos del equipo
Cuando comenzamos un taller, siempre comenzamos tratando de obtener la visión completa de dónde se encuentra el producto, podría ser solo una idea inicial con un par de líneas y necesitamos descubrir juntos cuáles son los problemas a resolver para estos usuarios. O un proyecto maduro y lanzado en su enésima iteración que busca agregar una nueva función.
En el sprint de diseño de Google, este es el día 1. 8 horas completas para comprender el problema, así de importante es esto para el equipo de Google Ventures, este paso impulsará todo lo que saldrá del taller, por lo que lo tratamos con gran reverencia.
Es posible que muchos de los talleres que realizamos solo sean talleres de 4 a 8 horas, por lo que tenemos la diversión de obtener 8 horas de resultados en solo un par de horas. Aquí tratamos de entender quiénes son los principales usuarios, cuál es el problema a resolver, por qué este problema, qué tan válido es esto como problema, cuáles podrían ser las causas y los efectos del mismo. Estos problemas se expresan mejor desde diferentes perspectivas, por lo que siempre es valioso tener una variedad de experiencias y conocimientos aquí. Una vez logrado esto, podemos pasar a mi parte favorita, ¡soluciones!
La segunda parte de nuestro taller se centró en el día 2 del sprint de diseño de Google, donde consideramos soluciones para los problemas que hemos descrito. Una frase común que escuchamos sobre esta etapa es “si no puede encontrar 20 soluciones diferentes, no ha entendido el problema correctamente”. No necesitamos encontrar 20 soluciones cada uno, sin embargo, con varios expertos, deberíamos crear ideas lo suficientemente diversas aquí, que podamos discutir y llevar con nosotros para crear prototipos y probar. Creo que todos siempre disfrutan la etapa de solución porque después de sentarse y hablar sobre los problemas se siente productivo.
Al invertir tiempo para estar en sintonía e informarnos mutuamente sobre los diferentes problemas que enfrentan los diferentes departamentos, podemos innovar colectivamente para resolver problemas utilizando la experiencia de la que cada departamento ni siquiera puede ser consciente. Habiendo entendido varios lugares clave que potencialmente podrían automatizarse, exploramos cómo el flujo podría verse afectado por la automatización, qué soluciones necesitaban implementarse con mayor urgencia y cómo planificar la implementación. Por lo general, aquí traemos el triángulo de gestión de proyectos o traemos el principio de MoSCoW. Hacemos esto para recordarnos a nosotros mismos que todavía somos humanos. Algunas soluciones son más simples y agregan mucho valor, mientras que otras pueden agregar menos valor en relación con el costo de implementación. El enfoque clave a lo largo del taller es agregar VALOR.
En este momento, tenemos una buena comprensión de la solución prevista y cómo pretendemos implementarla para que podamos proceder a preparar la Especificación de requisitos de software (SRS) o el documento de alcance. Si disponemos de más tiempo, puede ser valioso comenzar a crear prototipos en esta etapa; sin embargo, no es imperativo, ya que también podemos comenzar esto durante los siguientes pasos.
El SRS actúa como guía para lo que hará el equipo que implementa la solución. Describe claramente los flujos, qué funciones deben incluirse en la solución y cómo debe hacerse. Nuestro objetivo es enviar esto dentro de una semana después de completar el taller para recibir comentarios y esta vez tuvimos algunos ajustes para incluir, esto nos da tiempo para repensar cualquier decisión que hayamos tomado que no tengamos clara y para asegurarnos de que toda la información sea precisa. comprendido.
Una vez que se confirma el SRS, discutimos los requisitos con mi propio equipo para preparar estimaciones para implementar las soluciones, esto le da al equipo pautas sobre qué esperar de cualquier equipo que intente implementar la solución, si las estimaciones son muy diferentes, podrían ser los requisitos. No se han entendido o puede faltar la calidad.
*qué entregables esperar para un SRS o prototipo
En algunas ocasiones, es posible que se nos pida que preparemos prototipos simples de estructura alámbrica junto con el SRS, por lo general, lo recomendaríamos, ya que tener un esquema visual acordado puede ahorrar mucho tiempo y costos; sin embargo, no siempre es necesario. En este taller reciente, no se necesitaron wireframes.
Se ha demostrado que este flujo completo ahorra a los equipos entre 10 000 y 50 000 € al ayudar a priorizar el valor agregado y al alinear a los equipos para implementar la solución de una manera más lineal.
Si tuviéramos que volver a realizar este taller, probablemente nos recordaríamos algunas cosas. En primer lugar, administre el tiempo con cuidado. Creo que presionamos a todos demasiado el día uno, lo que podría haber sido menos eficiente y nos dejó menos tiempo el día 2. Además, nos gustaría priorizar el alcance que se automatizará antes para poder dedicar más tiempo a decidir qué se podría implementar en una fecha posterior, particularmente porque esta iteración tenía un plazo más ajustado que otros proyectos.
Puedes leer más sobre nuestros talleres aquí: https://bothofus.se/SocialImpact/Spanish_B%C3%B8thOfUs_Workshop_V5.3.pdf
Si esto te parece interesante, ¡háznoslo saber! ¡Nos encantaría tener una charla! Reserve una llamada gratuita de 20 minutos — https://calendly.com/marina_bothofus/intro
Kay Nag — Co-Fundador
https://www.linkedin.com/in/kaynag/
Marina —Países hispanohablantes
https://www.linkedin.com/in/marinardz/
Joel Yeap — UK & países de habla inglesa
******Muchas gracias******
