Muchos tuvieron que lidiar con una situación en la que el gerente requiere un equipo de unicornios con una piel de arcoíris, y la fecha límite era ayer. En dicho equipo, el trabajo puede convertirse en un conflicto eterno, todos están tratando de proteger sus intereses y todos se olvidan por completo de que inicialmente se unieron para crear un producto de calidad y comunicar los beneficios. Tal equipo difícilmente puede llamarse efectivo.
Sobre lo que es un equipo de producto efectivo, cómo construirlo y lo que hay que hacer para que todos los miembros del equipo estén involucrados al máximo en el proceso, hablamos con expertos en una mesa redonda que tuvo lugar en nuestra oficina. Junto con nosotros, Roman Abramov (director de producto de CarPrice y fundador de ProductStar) buscó respuestas a las preguntas, Mikhail Alexandrovsky (Fundador Dostavista), Anna Boyarkina (Jefe de Producto Miro), Ilya Krasinsky (CEO Rick.ai), Michael Yan (CEO ManyChat) . Detalles debajo del corte.
El 8 de agosto, tuvo lugar un panel de discusión en la oficina de ManyChat, en el que discutieron el tema de la construcción de un equipo de producto efectivo que sea relevante para muchas empresas. Los expertos invitados fueron
- Roman Abramov, Director de Producto de CarPrice y Fundador de ProductStar
- Mikhail Alexandrovsky, Fundador Dostavista
- Anna Boyarkina, Jefa de Producto Miro
- Ilya Krasinsky, CEO de Rick.ai
- Michael Yan, CEO de ManyChat.
La reunión fue moderada por Kira Matveeva, directora de producto del Grupo Lamoda. Durante la discusión, discutimos qué herramientas y procesos existen, cómo unir y dirigir un equipo, ayudar a los empleados a crecer y desarrollarse, mantener la motivación, impulsar habilidades y también respondimos preguntas de la audiencia.
Para aquellos que aprecian especialmente el efecto de la presencia personal,
sugerimos ver la grabación transmitida . Para todos los demás: una transcripción detallada de la discusión. Que tengas una buena lectura!
¿Qué es un equipo de producto, cuál es su diferencia con un equipo que no es de producto?
Roma
Un equipo de producto es un equipo que corta un producto, probablemente en línea. En mi opinión, puede incluir desarrolladores, evaluadores, comercializadores, diseñadores (especialmente). Estos no son solo productos. La tarea de los productos es liderar y organizar este equipo. Para que se sientan bien juntos, y que todo esto conduzca a un resultado.
Ilya
Agreguemos holivar de inmediato para que no sea aburrido: cuando todos están de acuerdo con todos. Siempre me bombardean cuando el equipo del producto "corta el producto". Por cierto, el equipo difiere de los empleados en que los miembros del equipo están unidos por un objetivo. Me encantan los equipos que son responsables del dinero, y luego resulta que el 60% del tiempo no es necesario cortar el producto. Por el contrario, es necesario desechar lo innecesario.
Michael
Sigamos con holivarit. No estoy de acuerdo con que el equipo se trate de dinero. Se trata de algunas métricas de productos. Los equipos de productos y productos no son diferentes en que los equipos que no son productos tienen objetivos en las métricas que no son productos. Nada mas.
Michael
Agreguemos algo más a esto. Por lo general, todos están de acuerdo con todo, pero aquí comenzaron con una disputa. Teníamos una gran pregunta: si los productos son responsables del dinero o de otras métricas. Recientemente leí algo bueno en
Product Star : "El objetivo del gerente de producto es aumentar los ingresos de la compañía". Me parece que esto combina diferentes puntos de vista, porque diferentes compañías en diferentes etapas pueden tener objetivos completamente diferentes. Y el equipo de producto va a la misión de la compañía a través de las tareas y objetivos que ahora enfrenta esta compañía. Al principio, es posible que tenga la tarea de alcanzar la rentabilidad. Luego, cuando llegas a la rentabilidad, continúas creciendo, entonces puedes pensar en muchas otras cosas.
Anya
Esta es una pregunta muy compleja, controvertida y extraña. Cada uno de nosotros agregó nuestros propios significados. Si lo piensa, el gerente de producto y el equipo de producto es un equipo que tiene un producto a su disposición y, a través de él, el equipo afecta las métricas, el negocio de la compañía y el logro de los objetivos. Estoy de acuerdo, pueden ser diferentes. Puede ser capitalización, puede ser dinero, puede ser algún otro indicador. En el caso general, esta no es solo una historia sobre el equipo que muestra algunas características (aunque esto es genial e interesante), sino sobre cómo el equipo resuelve el problema de lograr los objetivos de la empresa.
Estructura del equipo, roles y tipos de organización. ¿Quién puede estar en el equipo y cuáles son las áreas de responsabilidad?
Anya
Creo que es interesante saber ... En un momento, decidimos dividir el equipo en un equipo de un producto básico (básico) y un equipo de crecimiento. En algún lugar hace 3-4 años, cuando priorizamos las tareas, siempre había un conflicto de intereses: en qué invertimos, en el desarrollo de la funcionalidad del producto o en experimentos. ¿Haciendo valor o tratando de escalarlo? Una de las mejores soluciones que funciona en esta etapa (no digo que siempre sea así): se asignó un equipo separado para el crecimiento. Debe comprender que tenemos todo el negocio dividido en dos partes condicionales: parte del beneficio se genera a partir del autoservicio, cuando algunas personas vienen y compran un producto, y también hay un negocio de contacto humano con un departamento de ventas. El equipo de crecimiento trabaja en autoservicio y proporciona GoToMarket
(aprox. GoToMarket - entrada al mercado) para nuevos productos. El equipo emplea a 20-22 personas: gerentes de producto, diseñadores, desarrolladores. Hay 4 gerentes de producto.
Ilya
Es decir, estos son, de hecho, 4 equipos que tienen ciertas métricas, pueden resolver más rápido, y así sucesivamente. Y los equipos de infraestructura que los controlan para que no sanen nada.
Anya
¿Qué significan los equipos de infraestructura?
Ilya
Me encanta este esquema: necesitas hacer experimentos rápidos. Este es un tipo de equipo completamente diferente, los desarrolladores aceptan las reglas del juego que “no lo estamos haciendo en este momento, correcto, con patrones de diseño, base de datos y ORM. Estamos haciendo un trozo; han lanzado el frente, lo han desplegado lo antes posible, y así sucesivamente ”.
En este caso, surge el problema de que muchos equipos comienzan a crear una gran cantidad de código basura, su calidad disminuye, por lo que se fortalecen con los equipos de infraestructura que realizan revisiones de código, aseguran la calidad del código, etc. Las características se centran en las métricas del producto y los experimentos rápidos, los equipos de infraestructura: en la calidad del código, componentes complejos y largos, motor, refactorización, etc.
Anya
Sí, en términos generales. Siempre debe haber algún tipo de base que le permita hacer experimentos rápidos.
Michael
También tenemos algo similar. Hace algún tiempo, dividimos el desarrollo de productos en equipos básicos y de crecimiento. Cada equipo tiene escuadrones
(aprox. Escuadrón - comando) que se ocupan de algo por separado. Al igual que muchas empresas, comenzamos a compartir desarrollo y productos. Pero cuando comenzó el crecimiento, comenzamos a hacer cuadrados donde hay desarrolladores, productos, analistas y alguien más, si es necesario, por ejemplo, DevOps. Inicialmente, los desarrolladores obedecieron a la estación de servicio y nada más. Ahora también lo obedecen, los despide, los cría, y eso es todo. Pero al mismo tiempo, los desarrolladores también son miembros de los escuadrones. Esto funciona bien, el código se mantiene en buenas condiciones. Inicialmente, tenemos todos los desarrolladores de Signora. Esto también es malo cuando no hay movimiento, cuando alguien está enseñando, criando a alguien.
Ilya
¿Pero tiene algún tipo de asimetría, algunos equipos se centran en experimentos rápidos, otros están en la verificación y refactorización de códigos: la facturación, por ejemplo, es un tema eterno y doloroso que se aserra y refactoriza durante mucho tiempo?
Michael
Hay un equipo de infraestructura que no está en el equipo de crecimiento, se ocupa de las "partes íntimas del código".
Anya
¡Nosotros también tenemos uno!
Ilya
Agregaré Hay una cosa que no veo tan a menudo. ¿Qué es la funcionalidad cruzada? Cuando no corremos a otro departamento, porque tenemos diseñadores y desarrolladores en el mismo equipo. Y realmente me gusta agregar gerentes de ventas al equipo de productos para que permanezcan allí parte del tiempo. Hay clientes, y los gerentes de ventas se comunican con los clientes, entienden lo que necesitan. Y hay un equipo de producto que participa en el desarrollo del producto. Me gusta cerrar la brecha entre los gerentes de ventas y el equipo de producto. Quiero que las ventas entren en soporte y desarrollo y hablen sobre lo que está sucediendo, influenciado de alguna manera.
Michael
Tenemos un punto interesante. Originalmente éramos un equipo remoto e intentamos obtener el menor crecimiento posible. Cuando nos convertimos en más de 20 personas, nos reunimos en la primera oficina de Moscú. Luego conseguimos una oficina en San Francisco, contratamos a un tipo local genial de Atlassian que construyó grandes historias. También comenzó a contratar gente local. Y tuvimos un problema que el marketing comenzó a separarse del equipo de producto.
Ahora estamos comenzando a construir nuevos equipos. Comenzamos a enviar desarrolladores a la oficina de San Francisco. Ayudan a los vendedores con sus conocimientos y habilidades.
Y ahora estamos formando dos equipos de crecimiento que se fusionarán en una era
(aprox. Área de productos, una línea de productos que combina varios equipos de productos) y trabajarán junto con el marketing. Tendrán sus propias métricas y sus tareas. Un equipo estará en San Francisco, el otro en Moscú. Y para lograr sus objetivos y avanzar, deberán sincronizarse constantemente. No puedo decir que ya funciona, pero me parece que será genial.
Roma
De lo interesante, puedo decir tres cosas. Primero, nuestra tendencia es "menos, pero mejor". Había 100 de 600 personas en TI. Ahora hay menos de 50 personas, pero están mejorando cada vez más. Tres desarrolladores fuertes, incluso sin un producto, harán más de 10 malos con un producto. Como fragua de personal, tenemos una sucursal de Kirov.
La segunda tendencia y realidad es que tenemos mucho fuera de línea. El negocio no es solo ventas, sino también grandes minoristas, franquicias en todo el país, almacenes gigantes, miles de automóviles que giran por todo el país en tres días. Por todo esto, hacemos CRM, todos los enlaces que la gente necesita. A menudo esto es descuidado por personas con experiencia en línea, pero esto es importante y es una gran historia.
La tercera tendencia: transferimos toda la TI al trabajo remoto. Los resultados se han duplicado, la rotación es cero. Anteriormente, vino un joven, lo entrenamos, lo dominó y, tan pronto como levantó la mano, fue barrido, en Avito, Chipre. Ahora todos están contentos, están trabajando en casa, la esposa está cerca, la productividad es excelente, un buen motivador para el desarrollador, todos son buenos.
Cambiamos gradualmente como una prueba A / B. Tenemos el sistema empresarial OKR, lo hemos estado utilizando durante dos años, ayuda mucho a sincronizarse con el negocio. Al principio había un día desde casa, cualquiera. Luego hubo dos días desde casa, luego tres. Este trimestre se ingresó toda la semana desde casa. Si bien todo funciona bien, la gente está feliz, hay resultados. Creo que este es el futuro: ¿por qué sentarse en una oficina cargada y pagar el alquiler?
Solo hay un enchufe: estos son procesos. El principal problema era la discriminación contra los empleados remotos. “¿Por qué vamos a conectar a un tipo que está sentado fuera de la casa? Deja que se siente allí. Pero cuando todos entiendan que mañana y me sentaré desde casa, todos se conectarán. También trabajo de forma remota.
¿Cómo asegurarse de que todos los empleados remotos estén lo más involucrados posible?
Roma
Todo se decide por la práctica. Si le escribe a un empleado, pero él no está en línea, si Slack no tiene el estado "fue a almorzar", la próxima semana se sienta en la oficina. Una persona debe ser responsable, si trabaja de forma remota, debe estar disponible constantemente.
SkyEng habla mucho sobre su práctica en esta área. Uno de los principales proveedores dice que puede trabajar de pie y usar una tabla de planchar como soporte. Compré una silla cómoda, estoy sentado en la mesa de la cocina, hablando por Skype, todo está bien.
Ilya
La oficina debe estar allí para que puedan reunirse y discutir ideas. Pero lo bueno de lo remoto es que las personas están sentadas y haciendo lo suyo, nadie las distrae una vez más. Genial cuando el número de reuniones es mínimo. Lo más importante, en mi opinión, y lo que enseñamos a bordo como equipo:
- ¿Cómo se plantea la tarea? Este es un problema eterno. Utilizamos el marco de situación-problema-solución (ver los primeros 2 capítulos de la pirámide de Minto) y establecemos la tarea a partir del resultado, es decir, respondiendo a la pregunta de qué hacer y cuál debería ser el resultado.
- Cultura de las minas: primero, los miembros del equipo escriben el texto, luego llaman y discuten brevemente los bloqueadores y las preguntas o planifican acciones profundas.
- Cultura de entrega del resultado, incluido intermedio.
En general, los equipos distribuidos son sobre adultos que saben cómo administrar su tiempo y ayudarlos a hacerlo de manera efectiva.
¿El producto y el proyecto son una persona?
Anya
El producto debe decidir si necesita un proyecto o no. Si necesita avanzar, ¿a quién le importa?
Michael
Tuvimos una graduación de productos en la que vimos un crecimiento gradual. Por cierto,
Roma habló de esto
antes de la mesa redonda . Para nosotros, el producto de primer nivel es cuando puede eliminar un problema del trabajo atrasado y resolverlo. Cuando hay una especificación y descripción, solo necesita completarla. El segundo nivel es encontrar una solución cuando se conoce el "dolor" del usuario. Cualquier persona de nivel 2 debe poder y nivel 1. El tercer nivel, cuando hay una métrica específica en la entrada que necesita influir, y ya hay problemas y oportunidades para ello. El cuarto nivel está trabajando con la estrategia. En el componente actual, el producto, que se encuentra dentro del equipo multifuncional, desempeña las funciones del propio gerente del proyecto o (lo que es mejor) el propio equipo tiene una función distribuida del gerente del proyecto. Cuando un equipo es pequeño (por ejemplo, 6 personas) y trabajan juntos, y los sprints son cortos, no se necesita un gerente de proyecto. Para unidades más grandes, eria, que consta de varios equipos, hay un propietario del producto que también puede trabajar directamente con los gerentes de producto dentro de los equipos. Así que ahora no tenemos gerentes de proyecto en ManyChat.
Anya
A menudo en diferentes entrevistas me preguntan: "¿Tiene un producto dedicado a la gestión de proyectos"? Es genial cuando hay un equipo que se mueve solo. Pero aún así, esta es una habilidad importante, y debes entender cómo hacerlo. Si necesita llegar a un resultado, debe ser capaz de resolver problemas. Por lo tanto, creo que la habilidad debería serlo, porque sin ella es muy difícil avanzar, especialmente en situaciones con un alto nivel de incertidumbre. Puede ser posible hacer crecer un equipo que haga todo por sí mismo, pero debe ser capaz de hacerlo.
Michael
El producto debe ser responsable de garantizar que se logre el resultado. Pero cómo se hace esto no es importante. Si hay competencia dentro del equipo, esto es genial. De lo contrario, debe reponerse.
Michael
Históricamente teníamos un proyecto y productos diferentes, luego aumentó el número de equipos y nos dimos cuenta de que no necesitábamos un gerente de proyecto separado. Cuando todo está más o menos ajustado en equipos, no es necesario. Se necesita un proyecto cuando se forma un nuevo equipo, es necesario construirlo, los procesos deben ajustarse. Necesitamos una persona que sepa cómo hacer esto. Pero si continúa siendo necesario, entonces algo está mal en el equipo. Cada equipo decide cómo funciona. Inicialmente, los proyectos participaron en todo esto. Con el tiempo, quedaron varios proyectos, no se asignan a equipos específicos y hacen otras cosas.
Ilya
Muy cerca del patrón que "profesamos". Gracias a Maxim Dorofeev, una frase como "un hombre con manos de culo" apareció en la industria. Esta persona es muy fácil de identificar, a menudo trabaja los fines de semana y, si se va de vacaciones, todo se desmorona en el equipo. Él toca todo el tiempo para que vengan a las reuniones diarias. Hay una clase de chicos que se encierran todo en sí mismos y surgen problemas. Resulta un "pase de gerente" que constantemente transfiere tareas entre personas con una pérdida de significado en el camino.
Nuestros productos pueden actuar como proyectos en el equipo, pueden promocionar tickets en el sistema. Pero realmente nos encanta cuando los desarrolladores escriben tickets ellos mismos. Nuestro proyecto considera métricas, visualiza problemas en el equipo, monitorea cuántas tareas están en progreso, observa la velocidad de paso, estima dónde cuelgan las tareas, ya sean revisiones de código o no. Ayuda a hacer diagnósticos. El proyecto está fuera del equipo, en el sentido de que no cierra el proceso a sí mismo, pero ayuda, facilita y están en la etapa de lanzamiento con el equipo.
El gerente de proyecto es una "palabra de portada" en la que puedes meter cualquier cosa. En general, si un empleado quiere, puedo darle el puesto de la reina Victoria. ¿A quién le importa cómo se llama? A alguien le gusta el término "Scrum-master", a alguien le gusta más el "facilitador de procesos".
Michael
Entrenador ágil ...
Ilya
Los amo desde la distancia ... Los amo mucho, pero desde la distancia.
Novela:
Muchos chicos vienen a nuestros cursos que trabajan en el papel de un proyecto. Vienen con consideraciones de que saben mejor qué hacer que otros tipos, quieren aprender nuevas habilidades, por ejemplo, aprender a comunicarse con los usuarios, etc.
Pero estoy seguro de que la persona responsable del resultado no solo debe hacer promesas sin mirar atrás al equipo, sino comprender claramente que tiene "bajo el capó". Puede dibujar castillos en el aire, aunque quizás otro año tendrá que refactorizar. Solo entonces puede asegurar el resultado.
¿Cómo desarrollarse en un equipo de producto?
Roma
Cuando fui aquí, traté de agregar en mi mente qué preguntas surgen en los planes de desarrollo. Las preguntas más comunes:
Primera pregunta: ¿dónde encontrar al mentor? ¿Puedes convertirte en mi mentor?
La segunda pregunta: ¿qué curso elegir, qué leer?
Tercera pregunta: ¿cómo crecer si ya te has convertido en alguien?
Lo mejor es cuando tu mentor es tu líder. Yo mismo busqué asegurarme de que mi líder fuera un mentor. El mentor externo no conoce el contexto de los problemas que está resolviendo, y hay muchos inconvenientes en esto. Pero en cada empresa hay niveles de información, y el jefe puede saber aún más que usted. Puede aconsejar qué hacer sin entrar en detalles.
¿Cómo bombear? La profesión del producto es muy diversa y versátil. Pero en diferentes lugares de trabajo se necesitan diferentes habilidades y destrezas, se deben bombear desde diferentes lados. Hay productos B2B y B2C, y estas son historias completamente diferentes. Lo que los chicos están hablando de productos en masa, en B2B será un 80% inútil. Necesita estudiar todo y elegir dónde está interesado en excavar.
Tercero: qué aprender, dónde correr, si ya estoy bien. Veo que en esta sala hay muchos tipos geniales y experimentados, y muchos de ellos piensan que ya han escuchado todo esto, y no hay nada nuevo. Pero lo más importante es no pensar que sabes todo mejor que otros. Cuanto más expandes el campo del conocimiento, más tiene contacto con la realidad y más no sabes. Si parece que lo sabes todo, entonces te estás degradando.
Necesidad de ampliar las redes. , — , . : - , . , . , , — .
, . , , , , , , , -, . . , , , .
:
. , , . — . , , .
, , ( , ), , , -. , . , , . , , . : ( ), , , , , . - , - . , . , — , . — 90% .
— . , , . MVP, . «» ? custdev, . , , . — . , .
— 10 . , 30% . , . , , , . , , , . , .
, , 2 CEO, , , . , 0 1, , . .
, $15 000. - , 20-30 , , 50-60. « ». , 0 1 — . . , , .
:
, - -. Google: « 20% , ». , . « » , , .
, . , , , , — , «», . , , .
, , . , , . , : , . , . . , , — 10 , . , , . , . , , (: ). , , . , , — - , . , , « ». , , .
, . , OKRs. , , . , , , , . , - , .
:
— , , . , . -, - , . - , -… . . , . , , , . , . , . . . , . , — . -, . , , , .
:
, , . , - , . , .
. . , . , ( ).
:
: . — -. , . - , . - . , . , -, , . . -, , : « … … ». , . .
Por supuesto, cuando se enfrenta a una tarea práctica, elegirá la conferencia y el libro correctos. Es mejor cuando la necesidad de crecimiento proviene de una tarea específica.Y en conclusión
Pedimos a los expertos que compartieran enlaces útiles y los pusieran en un solo lugar. Toda la información se puede obtener de nuestro bot en Facebook o en el canal Telegram .