Mis principales errores en un año en el área de Producto
Espero que mis errores te brinden algún aprendizaje ó por lo menos reconforte los corazones ansiosos de los que recientemente iniciaron en el área.
Traducido del artículo de Daniele Dauster “Meus principais erros em 1 ano na área de Produtos”
Parece que fue ayer cuando estaba pasando por la fase de transición de carrera, puedo recordar con exactitud la rutina de estudios que tenía en esa época, los millones de currículums que he enviado, las mentorías que realicé, las devoluciones negativas en los procesos de selección, la sensación de desánimo y las ganas de desistir.
Recuerdo todavía, la primera vez que hablé con Bernard De Luna, en una mentoría colectiva, en ese día, yo estaba trabajando y en el horario que comenzaba estaba saliendo de una agencia hacia mis clases de inglés, no tuve dudas, prendí mi notebook dentro del Uber e inicie una batería de preguntas a pesar del ruido del tránsito que tenía de fondo.
Pues, querido lector, no fue fácil llegar aquí, fue necesario mucho esfuerzo direccionado de forma correcta para mi objetivo, pero también, no voy a eludirlo, confieso que las cosas no mejoraron después que ingresé en el área y por ese motivo escribí este artículo.
Espero que mis errores te brinden algún aprendizaje ó que por lo menos conforten los corazones ansiosos de los que iniciaron recientemente en el área.
1- Historias de usuario
Sí, yo erré. Y sé que debes estar pensando: ¿cómo así? Es tan fácil, existen millones de consejos sobre eso, inclusive, creo que es una de las primeras cosas que estudias cuando estás en la fase de transición, pero en la práctica la teoría es otra. Surgen varias dudas, como el tamaño, los criterios de aceptación y además, la maduración del equipo también impacta demasiado en esa construcción.
Mis errores: Bueno, en el proceso de quebrar las historias de usuario, algunas quedaron enormes, otras las separé por front y back. Como consecuencia, los desarrolladores pasaron mucho tiempo para entregar 1 historia de usuario, trabando el continuous delivery (entrega contínua).
Aprendizajes: Hoy quiebro las historias de usuario de acuerdo con la propuesta de valor y con lo racional de la entrega incremental, además, utilizo BDD — Behavior Driven Development (desarrollo orientado al comportamiento) trayendo los escenarios de tests, lo que ayuda mucho a que los desarrolladores entiendan el comportamiento esperado de la funcionalidad.
2- Discovery
Discovery, el terror de las personas de negocio y ¡la verdad se ha dicho!, el terror también de las personas de producto. Apuesto que crees que los problemas fueron las técnicas aplicadas, inclusive, ya escribí un artículo sobre discovery, respondiendo varias preguntas sobre ese asunto, pero no fue eso, preste atención, la cereza del postre es lo que te voy a decir ahora querido lector.
Mis errores: No involucrar lo suficientemente a los stakeholders en el discovery y no comunicar la evolución del proceso. Y ¿sabes el problema que eso acarrea? Puntas sueltas, riesgos no mapeados anteriormente. El propósito del discovery es justamente mitigar los riesgos, entonces imagina, prototipo listo y ahí llegas al refinamiento y “descubres” que todavía necesitas definir varias cosas para seguir com el delivery o que vas a necesitar realizar cambios porque no tuviste en consideración el impacto de aquella iniciativa para determinada área.
Aprendizajes: Involucrar los stakeholders durante todo el proceso, no necesitas marcar trescientas reuniones, puedes realizar alineamientos asíncronos, es algo inclusive a lo que he apostado bastante. Además de eso, documento todo en un único repositorio, links, investigación, evidencias y agrego el status para que cualquier parte interesada tenga acceso siempre que lo necesite (con eso evito más reuniones innecesarias). De esta forma, consigo mapear lo máximo posible de riesgos e impactos en determinadas áreas, mantengo los stakeholders actualizados, con expectativas alineadas y además mantengo una documentación que sirve de histórico, en caso necesite consultar posteriormente el motivo de aquella iniciativa.
3- Estimación
Hace algunos meses atrás Diego Eis publicó un artículo genial, sobre la responsabilidad de las personas de producto en la gestión de expectativa de los stakeholders sobre las estimaciones, mi cabeza se fritó y me identifique en varias partes.
Mis errores: Depositar toda la responsabilidad de la estimación en los desarrolladores y ser apenas la portadora de esa información. Y me gustaría dejar claro aquí que estoy mencionando esto como un error mío, en hipótesis alguna estoy criticando las estimaciones de los desarrolladores. Eso porque, para que algo suba a producción, como decimos, no tiene apenas el tiempo de desarrollo, existe también el tiempo del proceso, aprobaciones, existen además, imprevistos que surgen en el medio del camino. Entonces si un stakeholder cuestiona el tiempo de entrega de una iniciativa y le respondes llevando en consideración sólamente el tiempo de desarrollo informado por los desarrolladores, cometerás el mismo error que yo.
Aprendizajes: No importa la maturidad de tu equipo, ten a mano herramientas para ayudarlos con las estimaciones. Alinea con tu equipo los plazos internos y considera plazos mayores contemplando los puntos descritos arriba. Entender la capacidad de tu equipo es muy importante también, ya que, con esa comprensión y partiendo las historias en tamaños similares, consigues transmitir rápidamente una previsión de una iniciativa.
EN CONCLUSIÓN…
1 año actuando en el área de producto, miro hacia esos errores y me pregunto ¿cómo pude cometerlos? pero lo comparto sin miedo, porque fue gracias a ellos que me torné la profesional que soy hoy. Podría, inclusive, hacer un post de celebración sólo contando las victorias que tuve en ese período, pero querido, yo crecí mucho más con mis errores que con mis aciertos. Es eso, querido lector, espero que hayas aprendido algo com este artículo, por mi lado, sigo ansiosa por vivir nuevas experiencias, cobrándome menos en relación a la perfección, pero igual de exigente pues me rehuso a cometer los mismos errores nuevamente.
Danielle Dauster
‘Productera’ del Nordeste de Brasil, apasionada por el universo tech, por los libros y amante de un buen café. @produteiraderecife
