À propos des vaisseaux spatiaux et de l'espace. Comment créer une fonctionnalité en modifiant tout le produit en cours de route

Le 24 avril, un changement important s'est produit dans la plateforme Wrike: l'équipe a annoncé la sortie publique d'une nouvelle fonctionnalité - «Spaces», dans la version russe - «Spaces».
L'objectif de Spaces est d'améliorer le travail des équipes dans le gestionnaire de tâches et de simplifier la navigation dans le produit, en rendant les processus plus organiques et transparents. L'avons-nous fait? Continuez à lire et découvrez comment déployer des mises à jour sérieuses dans une grande entreprise et ne pas les gâcher, comment assurer l'interaction de 30 équipes Scrum et quelles leçons nous avons tirées du processus de développement de produits, dont la publication nous a coûté beaucoup de sang et un esprit d'équipe révolutionnaire.

Pourquoi les espaces ont-ils été inventés?

Lorsque Wrike a été créé, il était axé sur la résolution des problèmes d'efficacité de petites équipes de 15 à 20 personnes. Il est pratique pour ces équipes de travailler dans un seul endroit où il y a un «espace» pour tout le monde.

Au fil du temps, la taille des comptes a augmenté plusieurs fois. Maintenant, le produit est utilisé par des équipes distribuées dans des comptes avec des milliers de personnes, et à l'avenir, nous voyons Wrike comme un outil pratique pour le travail de nombreux services de l'entreprise: d'une part, travaillant dans des processus différents, d'autre part - toujours devant interagir les uns avec les autres.

Étant donné que dans le monde réel, des équipes existent dans différents bureaux, bureaux et pays, l'équipe de Wrike a pensé à créer un espace spécial pour elles afin qu'elles puissent simultanément travailler dans le cadre de leur processus et ne pas perdre le contact avec d'autres départements.

Les espaces permettent aux groupes de travail individuels d'organiser efficacement leur flux de travail: leur donner les outils et la structure de données dont ils ont besoin, l'accès à diverses formes de requêtes, afin qu'ils puissent organiser leur propre espace de travail et agir de manière plus ciblée. Les espaces vous permettent également de mieux contrôler la diffusion des informations au sein d'équipes multifonctionnelles et d'augmenter le niveau de sécurité des données.



L'idée de créer des espaces appartient à Sasha Plotvinov et Van Saveliev, chefs de produit Wrike. Tout d'abord, ils ont mené des recherches, dessiné un prototype de la solution pour les équipes du conseil d'administration, assemblé des maquettes et validé l'idée. Plus tard, il a été finalisé au Wrike Hackathon , où ils ont fait un pas de côté et assemblé un prototype d'espace personnel qui complétait le concept.

«Spaces» est d'abord une fonctionnalité pour les équipes. Cependant, il est basé sur le concept d'espace personnel vivant, dont tout le monde doit exclure les informations inutiles et les bruits étrangers.

Quels problèmes les espaces résolvent-ils?

Pour simplifier, Wrike se compose de projets et d'outils pour travailler avec eux. Par exemple, lorsque vous travaillez sur une version complète, vous créez un certain nombre de projets, surveillez leur progression via le diagramme de Gantt, contrôlez le chargement des équipes à l'aide de la charge de travail et, en fonction des résultats, créez un rapport pour les parties prenantes.

Tout semble simple, mais si vous avez des milliers de personnes travaillant sur un seul compte dans un grand nombre d'équipes avec des processus qui se chevauchent et utilisent de nombreux outils, deux problèmes apparaissent: il devient difficile de gérer les processus et l'interface utilisateur est surchargée d'éléments inutiles .


<sub>était


est devenu</sub>

De tels obstacles à un travail d'équipe efficace se posent pour un certain nombre de raisons: premièrement, dans la même arborescence de dossiers, il existe de nombreuses équipes; l'utilisateur voit constamment des informations non pertinentes et viole par inadvertance la structure de l'équipe «étrangère». Deuxièmement, seuls les administrateurs ont accès à la gestion des processus, et la structure du compte est souvent constituée par les administrateurs-directeurs généraux.

Dans le processus de développement d'Espaces, nous sommes arrivés à deux tâches clés:

• L'utilisateur ne doit voir que ce qui l'intéresse
• La délégation et l'auto-organisation devraient venir au lieu de la gestion verticale

Wrike fait partie de ces entreprises qui estiment que la gestion horizontale surpasse les organisations verticales et «turquoise» se montrent de la manière la plus efficace. L'approche mise en œuvre dans Spaces aidera l'équipe à atteindre un nouveau niveau de transparence et d'auto-organisation, où la gestion horizontale prévaudra.

«Si auparavant, l'administrateur de compte avait un haut degré de responsabilité dans les processus, il pourra désormais confier l'organisation du workflow de l'équipe à son supérieur immédiat, qui connaît souvent mieux les fonctionnalités de son équipe.»

- Ivan Savelyev, chef de produit Wrike

Quelles difficultés avons-nous rencontrées?

Bien entendu, des modifications importantes du produit entraînent de grands risques et un certain nombre de difficultés. En voici quelques uns:

Difficulté 1. Réduire les risques

L'adaptation d'un compte à une nouvelle façon d'organiser le travail est une tâche plutôt longue. À l'intérieur de Wrike, le problème a été découvert presque immédiatement: en tant qu'entreprise avec de nombreuses équipes et processus, nous tombons dans la catégorie de clients que nous considérons comme notre propre public et utilisons quotidiennement notre produit. Dans le compte d'équipe (plus de 800 personnes de tous les bureaux internationaux), nous avons lancé des versions et reçu immédiatement des commentaires de l'intérieur - cela a aidé à préparer une publication publique et à maximiser les risques à l'avance.
Pour ceux qui n'ont jamais utilisé Wrike, dans les étapes initiales, nous avons mené une série d'entretiens sur les solutions, lancé des tests à l'aide du service UserTesting et également mis en place un programme d'accès anticipé pour la fonctionnalité Spaces pour les clients intéressés.

Avant de lancer à l'ensemble du public, nous avons également effectué des tests A / B sur de nouveaux essais pour nous assurer que le nouveau paradigme de navigation est intuitif pour les nouveaux utilisateurs. Des tests, il est devenu clair que les nouveaux utilisateurs commencent à utiliser le produit avec succès. Nous avons également interviewé les groupes de test et de contrôle et avons constaté que parmi les répondants, les utilisateurs étaient beaucoup plus susceptibles de parler de la compréhensibilité de l'interface et de la facilité d'utilisation de Wrike.

Difficulté 2. Apporter la valeur de la solution au client

Wrike compte de nombreux clients qui utilisent déjà le service et mettent en place leurs processus de travail, il y avait donc un risque que la nouvelle fonctionnalité soit réticente.

Nous avons lancé la version bêta privée pour les clients clés et connecté notre département de services professionnels au processus.
Afin de transmettre le problème et, par la suite, sa solution aux clients, les responsables de la réussite client ainsi que les administrateurs de compte ont identifié les problèmes d'organisation des processus à un stade précoce et ont expliqué aux clients comment Spaces pouvait les résoudre. Ainsi, nous avons transmis la valeur maximale des espaces, qui dépassait la taille des coûts de la restructuration. Nous n'avons pas tout à coup «déployé la fonctionnalité», mais nous avons systématiquement préparé les clients à son apparition: les responsables de la réussite client ont organisé des webinaires, enseigné aux clients comment naviguer dans la nouvelle fonctionnalité, fait des newsletters par e-mail de formation, parlé des meilleures pratiques.

Plus tard, nous n'avons fait aucun appel: les clients ont commencé à venir eux-mêmes au programme de test précoce et à utiliser une nouvelle fonctionnalité.

Difficulté 3. Une amélioration nécessite de nombreux changements

L'amélioration de la plateforme affecte différents aspects du produit, et nous avons décidé d'entreprendre une modernisation afin de ne pas rester au même endroit. Nous avons eu de la chance avec une équipe de développement qui a délié les nœuds techniques les plus incroyables et trouvé des solutions optimales tout au long du travail sur le projet. De plus, tout le monde comprenait la nécessité de cette initiative, nous avons donc toujours eu un fort soutien du vice-président et chef de la direction.

Dès le début, l'équipe de développement a décidé de créer une architecture à connexion minimale, transformant l'ensemble de la solution en un ensemble de composants métier et de mini-applications distincts qui s'intègrent et interagissent uniquement entre Workspace (le produit final que voit Wrike).

Un référentiel distinct a été créé pour ces composants, y compris un sandbox. Il était possible non seulement de regarder chaque composant en action et de le montrer, par exemple, dans une revue de sprint, mais également de mener son développement et ses tests à part entière. L'assemblage, les tests unitaires et les autotests ont pris un ordre de grandeur moins de temps que lors du développement dans un espace de travail à part entière. Cela a permis aux développeurs d'itérer rapidement, d'afficher les résultats à la fin de chaque sprint et, si nécessaire, d'apporter rapidement des modifications à la fois à la fonctionnalité et à l'API. Après un certain temps, l'étape suivante a été franchie - la création d'une sorte de «terrain de jeu», sur lequel une interface très simplifiée du produit principal a été créée, y compris l'intégration de la plupart des composants. Cela nous a permis de concevoir et de déboguer leur interaction les uns avec les autres.

Comment les équipes ont-elles interagi entre elles?

Wrike compte environ 30 équipes Scrum travaillant sur leur partie du produit, dont chacune est actuellement affectée par des fonctionnalités, ou sera incluse dans le processus dans un proche avenir. Le problème de l'interaction inter-équipes lors du développement d'Espaces s'est parfois posé très fortement - après tout, chaque équipe dispose de ses propres OKR produits pour le trimestre.

La question de la communication était une priorité: où il était possible de tout discuter à l'avance, de convenir et de formaliser les accords, l'interaction s'est avérée meilleure qu'avec les équipes avec lesquelles il n'y a pas eu de discussions préliminaires. Dans ce dernier cas, l'équipe de développement a dû apporter des changements ou modifier la fonctionnalité de quelqu'un d'autre elle-même.

«Il y a eu des cas extraordinaires: une fois qu'il était nécessaire d'intégrer un composant assez grand et complexe développé par une équipe externe avant qu'il ne soit terminé par cette équipe (en conséquence, il est apparu dans notre fonctionnalité plus tôt que fondamentalement). Que faire - nous avons essayé de terminer le travail dans le cadre des délais et avons dû sortir. Et le temps que nous avons passé à tout mettre en ordre après la fin du composant, nous avons dû l'enduire d'une fine couche lorsque nous travaillions sur d'autres fonctionnalités - l'intégration selon le plan était bien révolue! »

- Alexey Kartavenko, chef d'équipe frontend

Le nombre de problèmes qui surviennent lorsque 30 équipes interagissent les unes avec les autres dans un environnement agile très intense ne doit pas être décourageant. Pour presque toutes les entreprises, organiser un processus de mêlée est déjà une réussite, et la mêlée de mêlées est un fantasme: ici, les producteurs de produits, les prospects et les développeurs ordinaires doivent apprendre à travailler ensemble.

Voici les conseils donnés par l'équipe Spaces à ceux qui se préparent à réaliser un gros projet:

1. Le plus souvent possible, discutez des options intermédiaires du projet avec différents participants au processus, recueillez constamment des commentaires et recherchez des éléments de réflexion supplémentaires.
2. Si ce que vous faites peut être utilisé en interne (nous avons eu beaucoup de chance avec cela chez Wrike), lancez un projet pilote. Roulez sur tout le monde, informez tout le monde, exécutez des formulaires de rétroaction!
3. Déterminez le niveau de préparation auquel vous pouvez activer les fonctionnalités pour les clients fidèles: parmi eux, il y a toujours ceux qui aiment suivre le temps et activer toutes sortes de fonctionnalités expérimentales. Leurs commentaires seront particulièrement précieux car ils sont votre public cible. tous les premiers mécanismes de test sont à votre disposition: expérimentations A / B, déploiements limités et contrôlés des versions alpha et bêta, accès Early Access à la demande, etc.
4. Équilibre entre la vitesse de développement et sa qualité, comme sur une planche de surf: n'ayez pas peur de laisser de la dette technique dans le sprint actuel, mais commencez immédiatement les tâches pour l'éliminer dès que la situation devient claire. N'oubliez pas de donner à ces tâches la plus haute priorité. Il n'est pas à courte vue de faire une couverture complète des tests unitaires et automatiques des fonctionnalités qui peuvent changer après les commentaires lors du prochain sprint. De plus, ce n'est pas seulement stupide, mais criminel pour l'ingénieur de laisser le code indésirable à la fin et de le laisser arriver à la sortie.
5. Essayez de vous préparer correctement pour chaque prochain sprint: effectuez des PBR (Product Backlog Refinement), assurez-vous d'effectuer des tâches dans le sprint en cours pour rechercher ce que vous prévoyez de faire dans le prochain, parlez au propriétaire du produit et au concepteur UX autant que vous le souhaitez: poursuivez les dans la cuisine et dans le fumoir, clarifiant les détails. Essayez de synchroniser le backend, le frontend et les tests de manière à ce que l'interaction se chevauche, de sorte que personne ne reste inactif, en attendant la disponibilité des collègues d'une autre spécialisation, de sorte que vous n'ayez pas à vous asseoir sur le mok et à les jeter, etc.
6. Plus près de la date de sortie, lorsque les passions chauffent et que la majeure partie du travail est transférée des développeurs aux ingénieurs QA, remplacez-les par votre épaule: testez votre code vous-même, exécutez la régression, aidez à l'analyse et essayez d'écrire des tests automatiques.
7. Lorsque vous interagissez avec d'autres équipes, commencez à l'avance des discussions régulières sur la manière exacte dont vous allez procéder. Notez tous les accords et plans, générez de la documentation, vous pouvez même rédiger des contrats - non pas parce que quelqu'un essaiera de vous tromper et ne fera pas trop, mais parce que tout le monde a sa propre mousse de jours et que vos problèmes ne sont qu'à cinq pour cent étrangers. La synchronisation Sprint est idéale, visez-la.
8. Lorsque vous utilisez quelque chose développé par d'autres équipes, méfiez-vous des déclarations selon lesquelles «presque tout est prêt, prenez et intégrez». Tout d'abord, vous devrez découvrir si vous ne voulez pas vous mettre dans le pétrin, en prenant aveuglément ce qu'ils donnent et en construisant vos plans (en particulier ceux du calendrier).
9. Et le plus important: pas une seule chose sérieuse dans un monde informatique complexe ne se fait d'un simple clic, donc, si le projet est en développement depuis longtemps et qu'ils commencent à «regarder de côté», prenez soin de vos nerfs et sachez: même si ce n'est pas aujourd'hui, mais demain ou après-demain, des fils qui glissent à l'infini s'entremêleront, le brouillard se dispersera et le succès vous attend - vous croyez en ce que vous faites, non?