- salut. Parlez-nous un peu de vous. Depuis combien de temps travaillez-vous chez Wrike et qu'avez-vous fait avant de rejoindre l'entreprise?
- salut. Je m'appelle Sasha Plotvinov. Je travaille avec Wrike depuis six ans. Auparavant, il a travaillé dans une autre organisation et y a d'abord été engagé dans l'optimisation des moteurs de recherche, puis a rejoint les chefs de projet. Puis, à un moment donné, j'ai voulu plonger dans l'UX. Il a travaillé dans deux autres endroits en tant que designer UX, et après cela, il a obtenu un emploi chez Wrike.
- Et dans quelle mesure votre expérience avec UX chevauchait-elle ce que vous faites maintenant?
- C'était une histoire complètement différente. Dans le passé, j'ai travaillé principalement sur de très petits projets clé en main, ou sur des choses sans rapport avec le produit lui-même. Par exemple, j'ai travaillé chez Business Lines. Évidemment, la base du produit est la livraison des marchandises. Nous venons de créer une interface pour le rendre pratique.
Wrike est une histoire complètement différente, c'est une entreprise avec un produit numérique au centre. De plus, chez Wrike, j'ai obtenu un emploi en tant que designer UX mobile, et pour moi, c'était un tout nouveau domaine. Avant cela, je ne m'occupais pas sérieusement des applications mobiles.
Je me souviens d'avoir trouvé un emploi en septembre. Et littéralement, je me suis retrouvé dans une situation amusante: l'application mobile a été partiellement développée et avait des vues de base, mais il n'y avait pas de conception et d'interface. Avant moi, en effet, la tâche était immédiatement fixée pour sortir l'application Android en décembre, malgré le fait que je ne connaissais pas le produit à l'époque.
- Il s'avère que tu es venu à Wrike, et dès le premier jour tu as dû apprendre une toute nouvelle affaire?
- Oui, c'est vrai. Tout a été aggravé par le fait que Wrike est un excellent service pour la gestion du travail. Personne ne savait comment l'intégrer dans une application mobile. Il n'y avait pas de réponse claire à la question de savoir ce qui devait être et ce qui ne devait pas l'être. Un compromis d'une certaine version allégée est-il possible avec seulement une partie de la fonctionnalité?
La réponse courte est maintenant «non». La plate-forme Wrike est conçue de telle manière que lorsque certains utilisateurs ont juste besoin d'aller dans la boîte de réception et de regarder les commentaires, d'autres peuvent avoir besoin d'aller dans la tâche et de modifier la description. Les troisièmes utilisateurs doivent changer le statut, et quatrièmement - pour remplir un formulaire de demande.
Par conséquent, afin de satisfaire la plupart des utilisateurs, il est nécessaire, d'une manière ou d'une autre, de mettre en œuvre la moitié de la fonctionnalité Wrike dans une application mobile. Mais quelle moitié est aussi la grande question. Et où est la marge de suffisance de ce qui devrait être dans l'application mobile Wrike?
- Vous avez dit que l'un des principaux défis consistait à déterminer les principaux composants de la version de bureau à intégrer dans une application mobile et comment établir des priorités. Et quels étaient les autres défis sérieux en plus de cela?
- L'un des principaux défis personnellement devant moi était que j'étais entouré de personnes avec une grande expertise et que j'avais besoin d'urgence de grandir à leur niveau. Mais, vous savez, il y a des moments dans votre vie où vous êtes prêt à tourner des montagnes. Vous sentez la force en vous, vous comprenez que vous avez pris de l'élan - laissez simplement vos mains partir. Il se trouve que lorsque j'ai fini de travailler dans l'entreprise précédente, je n'aimais pas vraiment ça. J'ai réalisé que je peux et que je veux faire plus de bien. Et quand je suis arrivé à Wrike, j'étais prêt à agir.
Une telle impulsion permet de surmonter les difficultés partout. Mais il a ensuite superposé le fonctionnement de Wrike. L'entreprise a déjà créé un environnement dans lequel je pourrais vraiment être efficace. Et pendant les deux à trois premières années, j'ai travaillé tranquillement pendant 12 à 14 heures par jour. Je n'avais pas l'impression de me fatiguer et personne ne m'a forcé à le faire. Je n'étais encouragé que par un désir intérieur d'en savoir plus et d'aller de l'avant. Pour comprendre pourquoi j'étais si motivé, il vaut la peine de s'attarder sur le fonctionnement de Wrike. Pour moi, j'ai en quelque sorte déduit une définition de pourquoi cela fonctionne ici en général.
"Et pourquoi?"
- Wrike est très différent des autres entreprises dans lesquelles j'ai travaillé. Voici l'environnement dans lequel les règles du jeu équitable sont formées. Il y a peu de politique et une grande transparence de ce qui se passe. Les gens qui peuvent faire du bon travail ont les mains libres. Ils peuvent changer de rôle horizontalement, changer de projet.
En principe, c'était la même chose avec moi - j'ai d'abord travaillé en tant que designer UX, puis je suis devenu chef de produit dans une équipe mobile. Il a ensuite réuni plusieurs équipes mobiles. Ensuite, je suis passé au produit principal, également en tant que produit. Il s'avère que vous voyez où les efforts déployés mènent au meilleur résultat - vous pouvez y aller.
Nous le devons aux «pères fondateurs» qui ont arrangé Wrike de telle manière que cela est devenu possible. Il n'y a aucune situation dans laquelle quelqu'un viendra et dira: «Nous devons le faire parce que je pense que oui», sans aucune explication. Avant de toujours mettre des arguments sur la table, expliquez la logique et tenez compte de votre position. C'est le principe de base sur lequel une entreprise existe. Dans un tel environnement, vous voulez vraiment faire quelque chose et vous commencez à traiter l'entreprise comme la vôtre.
- Question sur le rôle du designer UX. Vous êtes arrivé à ce poste il y a six ans, et bien d'autres sont venus après vous. Selon vous, dans quelle mesure le rôle du concepteur UX a-t-il changé et évolué?
- Elle a beaucoup changé. Avec la croissance de l'entreprise, les normes ont augmenté et les processus ont changé. Il y a six ans, nous avions un département UX de trois personnes. Il y avait frontend, backend et d'autres départements par fonction. Des gens unis selon leurs compétences, cuisinés en eux, le travail est transféré d'un département à l'autre.
Ensuite, nous sommes allés à la mêlée. Les concepteurs UX étaient divisés en équipes, les fonctions et le format du travail dans son ensemble ont changé. Au lieu de discuter d'une solution pour les trimestres, de la polir, d'écrire de longues spécifications couvrant tous les cas étroits, le travail s'est transformé en un tout autre. Maintenant, il était nécessaire de créer un prototype le plus rapidement possible, de fournir des avantages avec des histoires incrémentielles individuelles, c'est-à-dire d'être beaucoup plus flexibles. Et même lorsque vous devez travailler sur quelque chose de stratégique, il a une touche d'agilité. Vous n'imposez pas votre vision à l'équipe, vous dites que nous avons fait une revue de problème, trouvé un concept de solution, et nous allons dans cette direction. Mais si après deux sprints nous devons dire que nous pouvons mieux résoudre le problème d'une autre manière, tout est rejoué. C'est normal dans le nouveau monde. C'est l'un des aspects qui ont changé dans la profession UX.
Aujourd'hui, Wrike emploie une vingtaine de concepteurs de produits. Quand je me suis installé pour la première fois, tout le monde a travaillé comme bon lui semblait. Maintenant, en général, une image complètement différente. Il existe des directives, des composants et des processus clairs. Il y a une revue, une revue UX, qui n'était pas là avant non plus. Et tout cela, bien sûr, simplifie et accélère votre travail, mais vous oblige également à respecter le système. Et la technologie s'est développée assez rapidement depuis lors. À propos du même Sketch il y a six ans, personne ne le savait vraiment.
«Je sais que vous êtes devenu le tout premier chef de produit chez Wrike.» Pouvez-vous nous dire comment cela s'est produit et qu'est-ce qui a changé avec votre transition vers ce rôle?
- Il y a 6 ans, il y avait une telle histoire que, en principe, nous n'avions pas de chefs de produit. Il y avait des concepteurs UX, PDG et CTO.
L'entreprise se développe rapidement, les projets se multiplient. À un moment donné, un besoin a commencé à se faire sentir pour que quelqu'un puisse répondre à la question: «Et quand publierons-nous cette fonctionnalité?». La solution la plus évidente était de poser ces questions aux concepteurs UX. Pourquoi? Parce qu'ils ont contacté les utilisateurs, discuté des solutions avec les parties prenantes et planifié des itérations. Naturellement, on pourrait nous demander: «Les gars, découvrons combien cela coûtera. Sur cette base, la date limite pour le projet sera claire. "
Au fil du temps, le domaine de responsabilité des concepteurs UX s'est élargi. Nous étions trois, chacun dans son domaine était de plus en plus engagé dans la recherche sur la façon dont les clients utilisent le produit et travaillait davantage avec le marketing. Par exemple, dans le cadre d'une application mobile, je pourrais préparer des supports marketing pour la prochaine version. Cela ne ressemble pas à un devoir UX, non? Et c'était tout à fait normal lorsque l'entreprise ne comptait que 30 à 50 personnes. Maintenant, bien sûr, il y a un département marketing dans lequel les gars sont engagés séparément dans cela et savent comment le faire mieux.
À un certain moment, nous avons été exprimés: «Les gars, vous êtes maintenant des produits excédentaires. Comment aimez-vous cela? " Étant donné que j'avais un sous-produit séparé (applications mobiles), pour moi, c'était une histoire assez naturelle. J'ai pensé et réalisé que, en principe, une telle transition est inévitable pour moi.
Je suis devenu chef de produit non pas parce que je voulais en devenir un toute ma vie, mais plutôt parce que j'ai compris qu'un autre rôle est impossible avec une telle activité. C'est dans ce rôle qu'il est possible de bien comprendre, du début à la fin, le problème de l'utilisateur. Construisez des hypothèses, trouvez une solution et mettez-la en œuvre, voyez ce qui s'est passé et ce qui ne l'a pas été, analysez les résultats et effectuez la prochaine série d'améliorations. Ou plongez-vous dans une stratégie et déterminez le chemin optimal vers l'objectif souhaité à grande échelle - tout cela, bien sûr, est très intéressant.
- Autrement dit, la transition d'un concepteur UX à un chef de produit s'est faite en douceur et votre domaine de responsabilité a été plus ou moins désigné avant même?
- C'est vrai. Une part substantielle des responsabilités est apparue naturellement avant la transition. Mais, en même temps, il restait une partie à étudier. Vous ne pouvez pas soudainement apprendre accidentellement à déterminer la stratégie de l'endroit où vous devez vous déplacer. Ou découvrez accidentellement comment analyser correctement les résultats de votre travail. À partir du moment où il est devenu clair que vous avez un nouveau rôle, il s'est avéré qu'il était urgent de développer d'autres compétences afin de devenir un produit intelligent.
- Dites-moi, comment s'est passée la transition d'une application mobile à un produit web?
- À un moment donné en travaillant sur une application mobile, j'ai réalisé que je voyais comment vous pouvez résoudre les problèmes des utilisateurs, mais les solutions se situent en dehors du domaine des applications mobiles. Ils se trouvent dans le domaine principal des produits - le Web. Nous sommes allés au hackathon avec l'idée de la vue Board (l'un des types d'espace de travail dans Wrike, représentant les tâches du projet sous forme de cartes de statut). Nous avons présenté le projet, remporté le prix et, par conséquent, ce fut pour moi un tournant.
Je me souviens qu'il y avait une réunion où nous avons discuté de ce que nous allions faire avec les projets de hackathon. Je me suis porté volontaire pour développer ce projet sur le Web. Puis une personne est venue dans l'entreprise qui a commencé à s'occuper des applications mobiles, Dima Orlov (voir Entretien avec lui), et je suis allé sur le Web de façon continue. J'ai une nouvelle équipe. Nous avons développé la vue Board, un script pour créer et personnaliser des projets, ainsi que d'autres scripts et vues populaires. À un certain moment, la vue Board est devenue la deuxième représentation la plus populaire du projet dans le produit, après la liste par défaut, lorsque les tâches sont présentées sous la forme d'une liste. Il s'est avéré que le public marketing a aimé la présentation du travail sous forme de fiches par statut.
- Et qu'est-ce qui a changé avec le passage au rôle de chef de produit? Pouvez-vous décrire ce que ce rôle représente dans Wrike?
- Il s'agit d'un rôle relativement nouveau dans l'entreprise. Elle a un peu plus d'un an. Je vais raconter le fond en fonction de ma vision.
Mon équipe et moi avons travaillé sur un projet assez important, il s'appelle "Spaces". Il s'agit essentiellement d'une nouvelle façon d'organiser les données dans l'espace de travail, nécessaire pour adapter la solution à de grandes équipes. Nos gros clients ont de plus en plus d'équipes sur le compte. Et pour eux, respectivement, Wrike, qui a été posée il y a dix ans, est devenue à l'étroit.
Différentes équipes ont été impliquées dans les travaux de ce projet. Il y avait de nombreuses tâches de synchronisation des différents éléments, de résolution des problèmes inter-équipes, nous avons analysé les caractéristiques architecturales et discuté du projet avec les principales parties prenantes de l'entreprise. Au cours des travaux, il est devenu clair que de telles initiatives à grande échelle apparaîtront plus souvent. À ce moment, alors que notre organisation de produits était déjà assez grande et que le besoin se faisait sentir de fusionner les équipes de produits en groupes, le groupe central a été formé, qui comprenait trois équipes. Je suis devenu un leader en elle.
Pour moi, ce rôle était nouveau, incompréhensible et inhabituel au début. Il me semble que la gestion d'un produit est plus facile qu'avec les chefs de produit. J'ai commencé à travailler non pas directement avec l'équipe qui crée le produit, mais avec les produits qui travaillent avec les équipes qui créent le produit.
Le rôle de chef de produit est assez indépendant. Certains l'appellent même «mini-PDG» parce que le produit possède un morceau du produit, est responsable du cycle complet. Mais en même temps, quand il y a plus de 20 produits excédentaires dans un grand produit, l'option «chacun pour soi» fonctionne déjà de manière inefficace.
Et l'un des défis les plus sérieux était de savoir comment, d'une part, laisser la liberté d'action aux propriétaires de produits, et d'autre part, s'assurer que les vecteurs d'activité s'alignaient et que les équipes au total pouvaient faire plus de bien.
- Et combien participez-vous à la formation d'une vision globale de la direction? Ou est-ce purement «descendant» d'en haut? Qui, relativement parlant, est un architecte mondial?
"Je suis sûr que dans des produits aussi volumineux que Wrike, il ne peut pas y avoir un seul architecte qui peut tout mettre du début à la fin et dire:" Voici notre plan, allez-y, dites à vos équipes quoi faire. " Et, tout d'abord, cela est dû au fait que, souvent, la plupart des réponses apparaissent, juste au niveau de ces mêmes équipes.
C'est l'un des principaux défis pour nous - pour s'assurer que la vision et la stratégie de l'entreprise sont en harmonie avec la vision et la stratégie du produit, du groupe, de l'équipe. Il n'y a aucune instruction normale pour cela. Au fil du temps, nous avons appris à traiter la planification stratégique à tous les niveaux comme une partie distincte importante du travail, et c'est en principe l'une des activités les plus intéressantes pour moi.
Il existe des équipes qui travaillent «sur le terrain» et qui comprennent les besoins des clients, mais qui ne voient pas la situation dans son ensemble sur le marché. Il y a des PDG et des VP produits qui ont une vision et une stratégie d'entreprise et de produit de haut niveau. Et, il me semble, l’une des tâches clés du chef de file du groupe est d’aider ces deux mondes à se compléter et à se renforcer, dans la configuration la plus optimale.
- Avez-vous l'impression de vous être éloigné de l'endroit où le produit est directement créé? Après tout, plus vous êtes proche du point où une orientation stratégique est définie, plus vous êtes éloigné du «mouvement».
- C'est vrai, à un moment donné, j'ai commencé à manquer de travailler avec l'équipe. Et puis, j'avais juste besoin d'un produit dans l'une de mes équipes pour travailler sur un projet complexe avec un impact énorme sur l'utilisateur. Et j'ai réalisé que je pouvais travailler sur ce projet pendant un certain temps jusqu'à ce que je trouve un produit dans l'équipe. Je le fais en ce moment.
- Autrement dit, au moment où vous combinez le rôle d'un produit principal avec un produit?
- Oui, c'est vrai. Mais en toute honnêteté, je dirai que le rôle même d'un lead implique que vous pouvez couvrir un chef de produit dans votre unité, si nécessaire.
- Votre chemin vers Wrike est-il spécifique? Ou, en principe, peut-il être décrit avec certaines nuances comme typique?
- Dans Wrike, il y a beaucoup d'exemples où les gars ont changé radicalement de rôle. Par exemple, des développeurs front-end, ils sont passés à l'analyse ou d'un développeur iOS à l'apprentissage automatique. Dans ces cas, les gens faisaient vraiment un travail, puis un tout autre. Dans mon cas, toutes les transitions entre les rôles peuvent être décrites comme assez organiques.
Quant à la transition des spécialistes UX aux chefs de produit - je pense que maintenant environ un tiers de tous les produits de Wrike sont d'anciens concepteurs UX. Peut-être maintenant des statistiques un peu différentes, mais je dirai que sur les 6 designers UX qui étaient chez Wrike il y a quatre ans, quatre sont devenus des produits. Autrement dit, la conversion est assez élevée. Notre directeur UX sur ce sujet est toujours plaisantant et triste, et probablement fier en même temps. La réalité est que, dans notre entreprise, les concepteurs UX travaillent en étroite collaboration avec le produit, et avec les utilisateurs, et avec l'analyse, ce qui permet d'acquérir des compétences produit.
- Merci! Peut-être en conclusion, voulez-vous ajouter quelque chose? Peut-être quelques conseils pour les débutants?
- Oui, je vais peut-être ajouter une histoire. Il ne s'agit pas d'hypothèses, de métriques ou d'analyses; de nombreux bons articles ont déjà été écrits à ce sujet. Cette histoire raconte comment c'est d'être propriétaire d'un produit. Une illustration de la vie, sans aucune conclusion de mon côté.
Nous nous sommes réunis à la veille du dernier nouvel an pour une réunion d'épicerie. Ils se sont assis à la table - nous étions une vingtaine - et ont commencé à discuter des résultats de l'année. Nous avons regardé il y a un an, fait une telle rétrospective informelle. Nous ne nous sommes pas concentrés sur des versions spécifiques, des notes, mais plutôt sur des impressions et des sentiments partagés. Et chacun à son tour a dit à quel point il apprécie cette année.
, , , , , . , , . , : « , , ».
, , , , - associate - , , .
, , , , . : “ ?” . , , -. .
, , - . , — , , , — .