Me llamo Dmitry Volkov. Durante mi trabajo como gerente de producto, he acumulado muchas historias sobre victorias y fracasos, cómo construir adecuadamente la comunicación entre el desarrollo y los negocios, y lo que nunca se debe hacer. Hoy contaré dos de esas historias.
Hice algunos fakaps incluso antes de mudarme a Yandex.Money. Hoy contaré cómo en una empresa siberiana perdimos un PM fuerte debido a malentendidos mutuos de lo que el negocio realmente necesita. La segunda historia será sobre lo importante que es explicarle al equipo que el producto necesita el mercado, y cómo la velocidad, la eficiencia y el trabajo bien coordinado de todos los participantes del proceso lo acompañan. Y un poco más sobre cómo funcionan esas cosas en Yandex.Money.
Nota del editor: este texto es el resultado de un informe de Dmitry Volkov en la reunión de Piemnaya el 28 de febrero de 2019. La opinión editorial sobre algunos temas puede no coincidir con la opinión del autorHace un par de años, cambié mi pequeña empresa para trabajar en una gran empresa siberiana, donde construí un servicio para transferencias de dinero en línea. En ese momento trabajé con cinco equipos, cada uno de ellos tenía su propio gerente de proyecto, y esto me ayudó mucho, porque entonces era bastante difícil para mí comunicarme con todos estos hermanos introvertidos. Uno de los equipos se reunió recientemente y se nombró allí PM con una formación muy sólida. Antes de eso, trabajó durante varios años como analista en un gran banco, y fue difícil encontrar a alguien más adecuado para un producto financiero.
Debo decir que este PM fue realmente un diamante facetado: fue firme en sus decisiones y juicios y nos satisfizo un poco más que completamente. En ese momento, nos parecía que vivíamos de acuerdo con Agile, por lo tanto, organizamos constantemente la planificación, el aseo, las retrospectivas y, en casi todas las reuniones, el primer ministro aplastó la autoridad, su juicio e intentó dominar al equipo y los productos.
Ella cuestionó todo: que esta característica se puede implementar en la arquitectura de nuestro producto, cuestionó la evaluación del equipo y dudó de la idoneidad de otros productos. A veces, tal desacuerdo llegó al sabotaje de la empresa. ¿Cómo se manifestó esto?
Una vez que realizamos las pruebas de pasillo, hablamos con un grupo de enfoque y de repente nos dimos cuenta de que la capacidad de agregar una fecha de liberación del pasaporte no es lo más obvio para los usuarios. Le pedimos al equipo que cortara un paquete con el calendario estándar en Android e implementara la función usando un tambor simple para seleccionar números, fechas y meses del año.
Pero PM encontró nuestra idea absurda. Ella no estuvo de acuerdo en que las tonterías que estamos ofreciendo ahora en general valen la pena. En ese momento, me di cuenta de que no podemos interactuar, no está claro qué estamos haciendo, por qué y cómo se tienen en cuenta los intereses de los clientes.
Sin embargo, el problema se descubrió con bastante rapidez. Todo estaba en la posición extremadamente simple, fácil y relajada de la empresa: "Dije que es necesario, que así sea". Y esto causó un conflicto interno en el proyecto en la decisión de hacer algún tipo de función que ofrecemos.
Las empresas tienen esa formulación históricamente. Entiendo que desde el punto de vista del producto, no es cierto, pero el crecimiento de una gran empresa por parte de 3.500 personas estuvo vinculado a planes, proyectos trimestrales e indicadores financieros. Por lo tanto, todo lo relacionado con el dinero provocó una reacción: "Tenemos que hacerlo". Y cada vez que nos hicieron la pregunta: "¿Por qué estamos implementando esta función?", Mi colega y yo respondimos por igual: "Solo porque es necesario, por el bien del dinero". Todo nuestro negocio era por el dinero. Envío de transferencias de dinero: se trata de dinero. Todo dependía del dinero: nuestros salarios, bonos y bollos en los puntos de café.
En algún momento, todos se pelearon con todos. Los probadores se pelearon con los desarrolladores, los probadores se pelearon con los administradores, los administradores se pelearon con nosotros porque algo no funcionaba para nosotros, nos topamos con ellos, pero no funcionó de nuevo, volvimos a toparnos. El caos total estaba sucediendo. No estaba claro qué hacer, y para resolver el conflicto, tuvimos que atraer a un equipo de recursos humanos y al director técnico de la empresa. Después de un tiempo, decidimos que el equipo debería disolverse.
Estaba muy avergonzado, pero la decisión fue tomada: disolvimos el equipo, distribuimos colegas a los equipos restantes. Se ofreció al proyecto cambiar a otro producto, que no estaba relacionado con transferencias de dinero, para no cruzarse más con tales tipos, como yo. Desafortunadamente, ella tomó esta situación muy cerca de su corazón y renunció ese día.
Entonces, debido a las comunicaciones mal construidas, y en general a causa de mis errores, perdimos un jugador bastante fuerte en nuestro equipo que podría aportar grandes beneficios a la empresa, pero no pudo, porque fue expulsado de nuestras filas. Desde entonces, no he olvidado que centrarse en los objetivos puede conducir al fakap más salvaje y arruinar al equipo. Y si tal situación se desarrolla nuevamente, entonces estaré más preparado para resolver tal conflicto.
Sobre comunicaciones y relaciones
Otro caso del que quiero hablar es también sobre la comunicación y las relaciones, pero sobre las relaciones superiores, más probablemente incluso sobre el amor.
Tan pronto como se forma una imagen clara en mi cabeza de lo que está sucediendo en el equipo, esto significa que estoy perdiendo de vista algo. Y para no hacer fakaps similares al anterior, solo tengo que comunicarme con todo el equipo, cada uno individualmente, y transmitir a todos los valores comerciales que perseguimos, transmitirlos con tanta minuciosidad como lo hacemos para nuestros clientes. .
Teníamos diez equipos de diferentes ciudades, y traté de participar en casi todas las actividades asociadas con ellos. Asistí a todas las reuniones y stand-ups y hablé sobre cómo la implementación de una característica particular afectó la rentabilidad de la compañía. Le dije a la gente sobre números, gráficos, sobre cambios en términos de crecimiento o disminución en el número de usuarios, mostré los resultados de los informes analíticos. También hablé sobre fakap: cómo la introducción de nuevas funciones no trajo el resultado esperado. Era importante reconocer abiertamente los errores de las empresas al establecer prioridades, lo que también era importante para que el equipo comenzara a confiar en mí y en el segundo gerente que estaba involucrado en este producto.
Cada equipo estuvo involucrado en el proceso de discutir las características del producto en función del impacto, el valor y la importancia para el cliente y la empresa. Al mismo tiempo, revisamos casi por completo el proceso de establecer el problema en la cartera de pedidos, y ahora cada característica se registró en la cartera de pedidos en función de cuatro preguntas: por qué, para quién, cómo y qué . Los impactos habituales descritos en el libro de Goiko Adzic .
Esto permitió involucrar a los participantes en todos los procesos en curso, y todos los equipos comenzaron a estar más atentos a lo que vieron y a nuestros requisitos.
Pero no solo estábamos cambiando. Se ha vuelto completamente incorrecto que los equipos permanezcan en silencio o se acerquen a nosotros y digan que nuestras ideas o nosotros mismos apestan, por lo que no haremos esto. Era necesario explicar por qué no deberíamos hacer alguna función o por qué queremos hacer otra cosa. Además, se invitó a los equipos no solo a escribir código, sino también a comenzar a usar este producto por su cuenta.
Por lo tanto, realizamos un experimento: cada desarrollador tenía que abandonar una oficina acogedora, ir al banco, atravesar todos los círculos del infierno y la tristeza, eventualmente hacer una transferencia de dinero, pero comprender cómo se sienten nuestros usuarios en cada etapa.
Debo decir que trabajamos con un público complejo. Luego fueron inmigrantes laborales, inmigrantes de Asia Central, que dejaron su huella en los escenarios de los usuarios. La participación directa del equipo en los procesos que atraviesa el usuario ayudó a comprender que no somos suficientes para mostrar las personalidades de los usuarios y crear un Mapa de viaje del cliente, e hicimos todo esto.
Y luego se sorprendieron cuando los equipos comenzaron a venir con muchas ideas y sugerencias nuevas. Querían hablar sobre cómo se sentían incómodos en algún momento o, por el contrario, qué tan bien se hicieron las notificaciones de que la transferencia de dinero se recibió con éxito, y así sucesivamente. Llevaron muchas ideas para nosotros y cada vez mejoraron nuestro producto ellos mismos.
Por lo tanto, si comprende que el gerente de producto con el que trabaja a diario proviene de personas silenciosas, de aquellos a quienes no les gusta hablar sobre el negocio que hace con él, entonces tome su mano y llévelo a un cuarto oscuro. Dígale allí como equipo cómo la difusión de información ayudará a cada uno de ustedes a participar plenamente en el proceso de desarrollo.
Dígale que es necesario ver no solo las características que desea, que es necesario refinar y heredar el código, corregir viejos fragmentos de muletas, porque a veces la corrección de tales tareas nos abre completamente sus flujos. Hable abiertamente con él y el equipo sobre lo que está sucediendo con su producto. Pídale que venga a cada standup de su equipo y que cada vez cuente lo que logró lograr el día anterior. Permítale mostrar los números de los informes analíticos, los resultados de los grupos focales, etc.
Esto definitivamente lo ayudará a ver el problema de manera más amplia, porque sus colegas probablemente estén listos para compartir sus opiniones con él, pero ahora no confían en él.
En general, a los desarrolladores no les gusta decir nada sobre sí mismos o sobre un producto, a excepción de varias palabras extrañas que todavía no entiendo muy bien y no he aprendido en todo este tiempo, sobre el código y mucho más. Cada desarrollador quiere hacer un producto de calidad y compartir su opinión, pero muchos temen no ser escuchados. Si usted y su producto son abiertos con el equipo (usted está con el producto), entonces la gente le dirá todo de buena fe, y esto también afectará el desarrollo de su proyecto.
Los equipos en Yandex.Money también funcionan así. Una estrecha conexión entre el proyecto y el producto nos permite desarrollarnos mucho más rápido que antes: limpiamos regularmente el trabajo atrasado, eliminando tareas obsoletas que pudiéramos tener, siendo groseros, a veces evaluando nuestras tareas en camisetas y puntos de historia para facilitar el tiempo y acelerar los procesos al planificación Nos comunicamos con nuestro equipo y hablamos sobre cómo se comporta el usuario en cada etapa de CJM, qué sucede en los informes con números y métricas.
En conclusión, puedo decir que si su producto no comparte lo que está sucediendo en el mercado o en su producto, entonces es hora de pedirle que lo haga. Tan pronto como le diga al equipo qué está haciendo exactamente y por qué, la participación de todos los participantes aumenta enormemente. Probado en la práctica.
Sorpresa para quienes lo lean: en esta publicación hay un código promocional para un buen bono de Yandex.Money. Recibirá al primero que encuentre y se active .
UPD 10:20 El primer código promocional fue entre líneas antes del kata. Se activó en 17 minutos.
Y si no tiene tiempo, no se desanime, habrá códigos promocionales en las próximas publicaciones también. Suscríbase a nuestro blog para adelantarse a todos la próxima vez.
Texto preparado por:
El autor es Dmitry Volkov.
Editores - Eugene Shklyar, Denis Vonsarovsky.