Sobre naves espaciales y espacio. Cómo hacer una función cambiando todo el producto en el camino

El 24 de abril, se produjo un cambio importante en la plataforma Wrike: el equipo anunció el lanzamiento público de una nueva característica: "Espacios", en la versión rusa: "Espacios".
El objetivo de Spaces es mejorar el trabajo de los equipos en el administrador de tareas y simplificar la navegación en el producto, haciendo que los procesos sean más orgánicos y transparentes. Lo hicimos? Siga leyendo y aprenda cómo implementar actualizaciones serias en una gran empresa y no arruinarlo, cómo garantizar la interacción de 30 equipos scrum y qué lecciones aprendimos del proceso de desarrollo del producto, cuyo lanzamiento luego nos costó mucha sangre y un espíritu de equipo innovador.

¿Por qué se inventaron los espacios?

Cuando se creó Wrike, se centró en resolver los problemas de la efectividad de pequeños equipos de 15-20 personas. Es conveniente que dichos equipos trabajen en un lugar donde haya un "espacio" para todos.

Con el tiempo, el tamaño de las cuentas ha aumentado varias veces. Ahora el producto es utilizado por equipos distribuidos en cuentas con miles de personas, y en el futuro vemos a Wrike como una herramienta conveniente para el trabajo de muchos departamentos de la compañía: por un lado, trabajando en diferentes procesos, por otro, aún teniendo que interactuar entre ellos.

Dado que en el mundo real existen equipos en diferentes oficinas, oficinas, países, el equipo de Wrike pensó en crear un espacio especial para ellos para que pudieran trabajar simultáneamente como parte de su proceso y no perder contacto con otros departamentos.

Los espacios permiten a los grupos de trabajo individuales organizar de manera eficiente su flujo de trabajo: darles las herramientas y la estructura de datos que necesitan, acceder a diversas formas de consultas, para que puedan organizar su propio espacio de trabajo y actuar más centrados. Los espacios también le permiten controlar mejor la distribución de información en equipos multifuncionales y aumentar el nivel de seguridad de los datos.



La idea de crear espacios pertenece a Sasha Plotvinov y Van Saveliev, gerentes de producto de Wrike. Primero, realizaron una investigación, elaboraron un prototipo de la solución para los equipos en el tablero, reunieron maquetas y validaron la idea. Más tarde, se finalizó en el Wrike Hackathon , donde dieron un paso al costado y ensamblaron un prototipo de Personal Space que complementaba el concepto.

"Espacios" es, en primer lugar, una característica para los equipos. Sin embargo, se basa en el concepto de vivir el espacio personal, que todos necesitan para excluir información innecesaria y ruidos extraños.

¿Qué problemas resuelven los espacios?

Para simplificar, Wrike consiste en proyectos y herramientas para trabajar con ellos. Por ejemplo, cuando se trabaja en una versión completa, se crean varios proyectos, se supervisa su progreso a través del diagrama de Gantt, se controla la carga de los equipos con Workload y, en función de los resultados, se crea un informe para las partes interesadas.

Todo parece ser simple, pero si tiene miles de personas trabajando en una cuenta en una gran cantidad de equipos con procesos superpuestos y utilizando muchas herramientas, aparecen dos problemas: se vuelve difícil administrar los procesos y la interfaz de usuario está sobrecargada con elementos innecesarios .


<sub>fue


se ha convertido</sub>

Tales obstáculos para el trabajo en equipo efectivo surgen por varias razones: en primer lugar, en el mismo árbol de carpetas hay muchos equipos; el usuario ve constantemente información irrelevante y, sin darse cuenta, viola la estructura del equipo "alienígena". En segundo lugar, solo los administradores tienen acceso a la gestión de procesos, y la estructura de la cuenta a menudo está formada por el administrador jefe administrador.

En el proceso de desarrollo de espacios, llegamos a dos tareas clave:

• El usuario debe ver solo lo que es relevante para él.
• La delegación y la autoorganización deben llegar al lugar de la gestión vertical.

Wrike es una de esas compañías que cree que la gestión horizontal supera a las organizaciones verticales y "turquesas" que se muestran de la manera más eficiente. El enfoque implementado en Spaces ayudará al equipo a alcanzar un nuevo nivel de transparencia y autoorganización, donde prevalecerá la gestión horizontal.

"Si antes el administrador de la cuenta tenía un alto grado de responsabilidad por los procesos, ahora podrá confiar la organización del flujo de trabajo del equipo a su supervisor inmediato, que a menudo conoce mejor las características de su equipo".

- Ivan Savelyev, gerente de productos de Wrike

¿Qué dificultades encontramos?

Por supuesto, los cambios significativos en el producto conllevan grandes riesgos y una serie de dificultades. Aquí hay algunos de ellos:

Dificultad 1. Reducir riesgos

Adaptar una cuenta a una nueva forma de organizar el trabajo es una tarea que requiere mucho tiempo. Dentro de Wrike, el problema se descubrió casi de inmediato: como una empresa con muchos equipos y procesos, caemos en la categoría de clientes a quienes consideramos nuestra propia audiencia y usamos nuestro producto a diario. Dentro de la cuenta del equipo (más de 800 personas de todas las oficinas internacionales), lanzamos lanzamientos e inmediatamente recibimos comentarios del interior; esto ayudó a prepararse para un lanzamiento público y maximizar los riesgos de antemano.
Para aquellos que nunca han usado Wrike, en las etapas iniciales llevamos a cabo una serie de entrevistas de soluciones, lanzamos pruebas usando el servicio UserTesting y también hicimos un programa de acceso temprano para la funcionalidad de Espacios para clientes interesados.

Antes de lanzar a toda la audiencia, también realizamos pruebas A / B en nuevas pruebas para asegurarnos de que el nuevo paradigma de navegación sea intuitivo para los nuevos usuarios. De las pruebas quedó claro que los nuevos usuarios están comenzando a usar el producto con éxito. También entrevistamos a los grupos de prueba y control y descubrimos que entre los encuestados, los usuarios tenían muchas más probabilidades de hablar sobre la comprensibilidad de la interfaz y la facilidad de uso de Wrike.

Dificultad 2. Aportar el valor de la solución al cliente.

Wrike tiene muchos clientes que ya utilizan el servicio y configuran sus procesos de trabajo, por lo que existe el riesgo de que la nueva funcionalidad sea reacia.

Lanzamos beta privada para clientes clave y conectamos nuestro departamento de Servicios Profesionales al proceso.
Para transmitir el problema y, posteriormente, su solución a los clientes, los gerentes de Customer Success junto con los administradores de cuentas identificaron los problemas de organizar los procesos en una etapa temprana y les dijeron a los clientes cómo Spaces podría resolverlos. Por lo tanto, transmitimos el valor máximo de Espacios, que superaba el tamaño de los costos de la reestructuración. No solo "desplegamos la función" de repente, sino que preparamos sistemáticamente a los clientes para su aparición: los gerentes de Customer Success realizaron seminarios web, enseñaron a los clientes cómo navegar por la nueva funcionalidad, capacitaron boletines informativos por correo electrónico, hablaron sobre las mejores prácticas.

Más tarde, no hicimos ninguna llamada en absoluto: los clientes comenzaron a acudir ellos mismos al programa de prueba inicial y usaron una nueva función.

Dificultad 3. Una mejora requiere muchos cambios

La mejora de la plataforma afecta varios aspectos del producto, y decidimos emprender la modernización para no estar en un solo lugar. Tuvimos la suerte de contar con un equipo de desarrollo que desató los nodos técnicos más increíbles y encontró soluciones óptimas durante todo el trabajo en el proyecto. Además, todos entendieron la necesidad de esta iniciativa, por lo que siempre tuvimos un fuerte apoyo del VP y CEO.

Desde el principio, el equipo de desarrollo decidió crear una arquitectura mínimamente conectada, convirtiendo la solución completa en un conjunto de componentes comerciales y mini aplicaciones separadas que se integran e interactúan solo entre Workspace (el producto final que ve el usuario de Wrike).

Se creó un repositorio separado para estos componentes, incluido un entorno limitado. Fue posible no solo mirar cada componente en acción y mostrarlo, por ejemplo, en una revisión de sprint, sino también llevar a cabo su desarrollo y pruebas completas. El ensamblaje, las pruebas unitarias y las pruebas automáticas tomaron un orden de magnitud menos tiempo que cuando se desarrollaron en un espacio de trabajo completo. Esto permitió a los desarrolladores iterar rápidamente, mostrando los resultados al final de cada sprint y, si es necesario, realizar rápidamente cambios tanto en la funcionalidad como en la API. Después de un tiempo, se dio el siguiente paso: la creación de una especie de "patio de recreo", en el que se creó una interfaz muy simplificada del producto principal, incluida la integración de la mayoría de los componentes. Esto nos permitió diseñar y depurar su interacción entre ellos.

¿Cómo interactuaron los equipos entre sí?

Wrike tiene cerca de 30 equipos de scrum trabajando en su parte del producto, cada uno de los cuales se ve afectado actualmente por las características, o se incluirá en el proceso en un futuro próximo. El problema de la interacción entre equipos durante el desarrollo de espacios a veces surgió de manera muy aguda: después de todo, cada equipo tiene sus propios OKR de productos para el trimestre.

El tema de la comunicación era una prioridad: donde era posible discutir todo por adelantado, acordar y formalizar los acuerdos, la interacción resultó ser mejor que con aquellos equipos con los que no hubo discusiones preliminares. En el último caso, el equipo de desarrollo tuvo que hacer cambios o modificar el funcionamiento de otra persona.

“Hubo casos extraordinarios: una vez que era necesario integrar un componente bastante grande y complejo desarrollado por un equipo externo antes de que este equipo lo terminara (como resultado, apareció en nuestra funcionalidad antes que básicamente). Qué hacer: tratamos de terminar el trabajo como parte de los plazos y tuvimos que salir. Y el tiempo que pasamos poniendo todo en orden después de que el componente estuvo terminado, tuvimos que untarlo con una capa delgada cuando trabajamos en otras características: ¡la integración según el plan había terminado hace mucho tiempo! ”

- Alexey Kartavenko, Frontend Teamlead

El número de problemas que surgen cuando 30 equipos interactúan entre sí en un entorno ágil muy intenso no debería ser desalentador. Para casi cualquier empresa, organizar un proceso de scrum ya es un logro, y el scrum de scrums es una fantasía: aquí los propietarios de productos, los leads y los desarrolladores comunes deben aprender a trabajar entre ellos.

Estos son los consejos dados por el equipo de Spaces a quienes se preparan para hacer un gran proyecto:

1. Con la mayor frecuencia posible, discuta las opciones intermedias del proyecto con diferentes participantes en el proceso, recopile constantemente comentarios y busque alimento adicional para pensar.
2. Si lo que haces se puede usar internamente (tuvimos mucha suerte con esto en Wrike), comienza un proyecto piloto. Rodar sobre todos, informar a todos, ejecutar formularios de comentarios!
3. Determine el nivel de preparación en el que puede habilitar la funcionalidad para clientes leales: entre ellos siempre hay aquellos a quienes les gusta mantenerse al día y activar todo tipo de características experimentales. Sus comentarios serán especialmente valiosos porque son su público objetivo. todos los mecanismos de prueba temprana están a su disposición: experimentos A / B, implementaciones limitadas y controladas de versiones alfa y beta, acceso anticipado a pedido, etc.
4. Equilibre entre la velocidad de desarrollo y su calidad, como en una tabla de surf: no tenga miedo de dejar deudas técnicas en el sprint actual, pero comience inmediatamente las tareas para eliminarlo tan pronto como la situación se aclare. Recuerde dar a estas tareas la máxima prioridad. No es miope hacer una cobertura completa de las pruebas unitarias y automáticas de funcionalidad que pueden cambiar después de la retroalimentación en el próximo sprint. Además, no solo es estúpido, sino criminal que el ingeniero deje el código basura al final y lo deje llegar al lanzamiento.
5. Trate de prepararse adecuadamente para cada próximo sprint: realice PBR (Refinamiento de la cartera de productos), asegúrese de realizar tareas para investigar lo que planea hacer en el próximo sprint, hable con el Propietario del producto y el diseñador de UX tanto como le parezca: perseguir ellos en la cocina y en la sala de fumadores, aclarando los detalles. Intente sincronizar el back-end, la interfaz y las pruebas de tal manera que la interacción se "lapee", de modo que nadie esté inactivo, esperando la disponibilidad de colegas de otra especialización, para que no tenga que sentarse en el mok y luego tirarlos, etc.
6. Más cerca de la fecha de lanzamiento, cuando las pasiones se están calentando y la mayor parte del trabajo se transfiere de los desarrolladores a los ingenieros de control de calidad, sustitúyalos por su hombro: pruebe su código usted mismo, ejecute la regresión, ayude con el análisis e intente escribir pruebas automáticas.
7. Al interactuar con otros equipos, comience regularmente discusiones por adelantado sobre cómo exactamente hará esto. Escriba todos los acuerdos y planes, genere documentación, incluso puede redactar contratos, no porque alguien intente engañarlo y no hacer demasiado, sino porque todos tienen su propia espuma de días y sus problemas son solo un cinco por ciento ajenos. La sincronización de Sprint es ideal; apúntala.
8. Cuando use algo desarrollado por otros equipos, tenga cuidado con las afirmaciones de que "casi todo está listo, tome e integre". Primero, tendrás que averiguar si no quieres meterte en un lío, tomando a ciegas lo que te dan y construyendo tus planes (especialmente los de calendario).
9. Y lo más importante: ni una sola cosa seria en un mundo complejo de TI se hace con el clic de un dedo, por lo tanto, si el proyecto está en desarrollo durante mucho tiempo y comienzan a "mirar de reojo", cuide sus nervios y sepa: incluso si no es hoy, pero mañana o pasado mañana, los hilos que se deslizan sin cesar se entrecruzarán, la niebla se dispersará y el éxito te espera; crees en lo que estás haciendo, ¿verdad?