Nous prototypons par code. Conférence FrontTalks

Bonnes vacances, amis! En préparation pour le début de la nouvelle année de travail, nous terminons une série de documents de la conférence FrontTalks 2018. Il s'agit d'une conférence d'Andrei Salomatin filipovskii_off - un développeur de Polychops. Andrey propose une approche équilibrée du prototypage: passer des artisans qui exécutent les commandes aux chercheurs - apprendre à travailler avec incertitude et, éventuellement, maintenir la raison même sans plan clair.

La rétroaction quantitative est un test AV, des résultats binaires, lorsque l'option A ou l'option gagne. C'est tout ce que nous pouvons obtenir des cycles quantitatifs. C'est comme si nous étions dans une pièce sombre et que rien n'est visible, mais nous avons un pointeur laser. De temps en temps, nous l'éclairons dans les coins, soulignons certains points et comprenons ce qu'ils contiennent.

Que souhaiterions-nous à la place? Un utilisateur qui décrira cette pièce sombre, qui la connaît bien mieux que nous.

- Bonjour à tous! Je voudrais parler du prototypage: pourquoi faire des prototypes, ce que nous en retirons et comment les fabriquer, à l'aide d'exemples.





Je vais commencer par une petite histoire. En 2012, j'ai rejoint cette startup, un merveilleux cerf. Nous avions quelque chose comme une plate-forme publicitaire, je suis venu en tant que développeur Java. Il est clair que de gros volumes de trafic, des tâches intéressantes, l'équipe est juste folle - tout est merveilleux. Nous travaillons depuis environ huit mois, la tête au clavier, nous faisons des fonctionnalités très sympas, nous retournons rapidement tout. Mais en 2013, le cerf remonte les sabots.

Qu'est-il arrivé? J'y ai réfléchi très longtemps, puis j'ai travaillé comme développeur front-end et back-end pour différentes entreprises, puis j'étais chef d'équipe, puis chef de produit. Il a travaillé à la fois dans des startups et dans des sociétés d'externalisation, dans de grandes entreprises. Principalement concentré sur les startups.



J'ai également réalisé certains de ces projets. J'ai eu la chance de travailler sur MoscowJS, Frontend Union Conf et RadioJS. Peut-être que nous avons croisé avec vous quelque part. Maintenant, je fais Code Podcast, un podcast en anglais sur les concepts communs en programmation, et Polychops, un projet pour les musiciens qui fonctionne dans un navigateur et vous aide à pratiquer l'instrument, à gagner du temps et à vous entraîner.

Qu'est-il arrivé à HeyMoose? L'entreprise avait des gens très intelligents qui travaillent maintenant en tant que développeurs seniors chez Microsoft ou sont devenus des STO. Nous avons fait ce que nous avons fait de mieux: nous avons résolu des problèmes techniques complexes rapidement et de manière intéressante. Mais quelque chose s'est mal passé.



Et quelque chose ne va pas avec beaucoup d'entreprises, en particulier les startups. Les startups s'épuisent le plus souvent pour deux raisons: soit elles ne comprennent pas le produit, quelque part elles manquent le produit, soit elles manquent d'argent. Très souvent, ils manquent d'argent parce qu'ils recherchent un produit et ne le trouvent pas assez longtemps.

Mais pourquoi le développement personnalisé dans les sociétés d'externalisation ne ferme-t-il pas? Ou pourquoi les grandes entreprises ne ferment-elles pas? Ils semblent plus lents. En règle générale, les équipes y sont au moins moins motivées. Quelle est la différence? Les mécanismes de travail sont les mêmes: dans le développement personnalisé, nous écrivons des savoirs traditionnels ou demandons des savoirs traditionnels aux clients, ils le peignent pour nous, nous le donnent, nous faisons des maquettes, du code et nous l'écrivons - le même processus. Ce qui est dans une startup, c'est que dans les grandes entreprises, il peut y avoir des pratiques de pointe. Tout de même. Alors pourquoi les startups s'épuisent-elles?

Imaginons d'abord une situation hypothétique: un chef de produit vient à nous et nous demande si nous pouvons ajouter un métronome qui fonctionnera dans le navigateur, émettre un son avec un intervalle périodique et une visualisation synchronisée, de sorte que différentes lumières scintillent au rythme du métronome individuel. Et pour que tout cela soit précis, peu importe ce qui se passe sur l'ordinateur, les autres processus, etc.



Qui est sûr à 100% que nous pouvons le faire en utilisant le navigateur et l'API du navigateur? Pas une seule personne. Qui est sûr à 80% que nous pouvons probablement le faire? 3-4 mains. Qui est sûr 50 à 50? La majorité. Qui est sûr que nous ne pouvons pas faire ça du tout? Honnêtement.

L'exemple suivant. Supposons que nous travaillons dans une autre entreprise sur une banque mobile. Nous pensons davantage au produit et pensons qu'il est nécessaire d'augmenter le nombre d'utilisateurs qui utilisent notre banque mobile. Nous avons mis au point une fonctionnalité: désormais, l'utilisateur peut partager un achat ou reconstituer un compte sur les réseaux sociaux. L'argent lui est venu, il est comme ça sur Facebook - regardez, l'argent m'est venu. Pensez-vous que cela aidera à attirer plus d'utilisateurs? Qui en est sûr à 100%? Pas un seul. Qui est sûr à 100% que cela ne nous aidera en aucune façon? Deux ou trois mains. Le reste se situe quelque part entre les deux.



Et le dernier exemple. Nous faisons un service cloud, ouvrons notre entreprise. Le service cloud collectera les journaux des projets, du frontend et du backend dans les petites et moyennes entreprises, les agrégera, l'apprentissage automatique, l'IA et tout ça. Nous le vendrons. Qui est sûr que c'est 100% de réussite ou 100% de perte? Quelques personnes.



Il n'y a qu'une seule bonne réponse à ces trois questions: «probablement». Nous sommes sûrs à 50-80% des réponses à certaines questions. Cela dépend beaucoup du contexte, de la mise en œuvre. Le même métronome avec la visualisation - j'ai travaillé dessus, vous ne pouvez pas le faire fonctionner dans tous les contextes: par exemple, avec un casque Bluetooth. Mais cela peut être fait pour deux ou trois cas généralisés. À ma connaissance, c'est «probablement» - et il y a une raison pour laquelle les startups ferment leurs portes, pour lesquelles HeyMoose a fait des siennes. Peut-être que nous ferons quelque chose de bien, ou peut-être que nous perdons juste du temps. Et nous n'avons aucun moyen de comprendre à quel point nous sommes confiants dans ce que nous faisons.

Un peu de théorie. Quelle est la différence entre le développement personnalisé et les startups? La différence est dans le contexte. Nous sommes dans ce contexte d'incertitude, nous avons une probabilité de succès et une probabilité d'échec. C'est comme si nous essayions d'utiliser les mêmes méthodes et pratiques lorsque nous courions au sol et lorsque nous courions dans l'espace sans gravité. Il semblerait que nous courions, mais rien ne se passe. Que faisons-nous mal?

Cette incertitude provient de trois domaines principaux. Cela vient du marché - parce que nous ne savons pas clairement quelles autres sociétés sont impliquées dans l'agrégation des journaux. Peut-être que ce marché a déjà été capturé par quelqu'un? Quelle démographie sur le marché, quels sont les prix? L'incertitude peut provenir d'un produit. Nous ne savons pas quel problème notre client a et comment le résoudre. Ceci est un exemple d'une banque mobile. Nous semblons avoir une compréhension, mais nous ne savons pas si les utilisateurs ont ce problème et comment le résoudre.

Et il y a des problèmes de mise en œuvre. Un exemple avec un métronome. Nous ne savons pas à 100% si cela est théoriquement possible ou non.

Ou un autre exemple. Nous n'avons aucun problème avec le marché ou le produit, si nous inventons un remède contre le cancer, qui n'est qu'une pilule - acceptée et saine. Mais il existe un grand nombre d'incertitudes sur la façon de mettre en œuvre cette pilule. Nous sommes dans le brouillard de la guerre, mais en même temps, nous nous comportons comme si le brouillard n'existait pas, car nous avons les mêmes principes qui fonctionnent dans le développement personnalisé. Nous les déplaçons simplement dans notre contexte d'incertitude.

Nous prétendons en quelque sorte que ce brouillard n'existe pas, il n'y a pas d'incertitude. Et nous essayons de prédire l'avenir. Quand j'ai commencé à travailler en tant que chef de produit, j'ai été frappé après le processus de développement par la quantité de divination que le chef de produit devrait produire. Lorsque vous relevez du directeur ou de quelqu'un d'autre, vous devez avoir l'air confiant, dire que nous ferons ceci ou cela, saisir le marché d'ici septembre, tout va faire mal. Tout cela - bien fait, j'ai tout réfléchi. Bien qu'en fait je comprenne que rien de tout cela n'existe, je devine juste sur les cartes et j'essaie d'avoir l'air confiant avec ça. Nous n'avons pas une culture du travail avec incertitude, avec probabilité. De plus, pour ressembler à des experts, nous devons constamment nous battre pour une réputation, être confiants, parler de ce que nous devons faire, au lieu de ce que nous devons vérifier ou de ce dont nous ne sommes pas sûrs.

Nous, en particulier les développeurs, avons toujours tendance à penser à ce que nous savons, comprenons et pouvons contrôler. En tant que développeurs, nous aimons vraiment planifier des architectures, penser à l'avenir, ne pas vous répéter, modéliser la programmation et tout ça.

Les concepteurs en souffrent également. Ils aiment penser à l'avenir, faire des mises en page parfaites, etc. Nous sommes des experts, bien qu'en réalité nous devions peut-être devenir quelqu'un d'autre.

Comment gérons-nous l'incertitude? Quelles méthodes de lutte avons-nous? La première méthode est la plus importante - mettre toutes les cartes sur la table, admettre que nous ne sommes sûrs d'aucun problème. Nous pouvons être sûrs à 50%, mais pour tester l'hypothèse, nous avons besoin de deux jours. Alors pourquoi ne pas simplement aller tester l'hypothèse? Nous pouvons être sûrs à 90% que le produit décollera, mais nous avons besoin de huit mois pour mettre en œuvre ce produit et tester l'hypothèse. Allons-nous simplement vérifier? Ou peut-être réfléchirons-nous à la manière de réduire l'incertitude à 90 ou 100%?

C’est la première façon. Il faut accrocher un badge sur cette incertitude, pour dire quelle est sa taille ou sa taille, combien de travail il faut pour la résoudre, etc.

La deuxième voie sur laquelle l'humanité travaille depuis 500 ans est la méthode scientifique. Ce n'est pas parfait, il a ses propres bugs, mais c'est le meilleur mécanisme que nous ayons pour le moment. La méthode scientifique dit: pour résoudre l'incertitude, nous devinons d'abord, formulons une hypothèse basée sur nos conclusions, puis réfléchissons à une expérience qui confirmera ou réfutera cette hypothèse, puis exécutez une expérience, regardez les chiffres et comprenez si notre hypothèse est vraie.



En développement, en particulier dans le front-end, nous avons une opportunité unique de réaliser ces expériences à très grande vitesse. Cette méthode est appelée prototypage. Le prototype est un moyen de gérer l'incertitude. Ce n'est pas une invention de produit, pas la création de quelque chose d'idéal que les utilisateurs utiliseront. C'est l'occasion d'en savoir plus sur le monde qui nous entoure. Nous apprenons cela en créant des illusions. Le prototype est une illusion, pas un produit. C’est comme si nous construisions le décor sur la scène du théâtre ou sur la scène pour faire des films. Ce n'est qu'une illusion. L'objectif est de réduire l'incertitude.

Le prototypage fonctionne dans deux contextes: dans le contexte de l'implémentation, quand on ne sait pas théoriquement du point de vue de l'API, c'est possible ou non, et dans le contexte du produit quand on ne sait pas quel problème l'utilisateur a et comment le résoudre. Le prototypage ne fonctionne pas vraiment dans les études de marché - Excel existe pour cela.

Le fait est que lorsque nous travaillons sur un prototype, nous devons abandonner la façon de penser en tant qu'experts. Nous devons oublier ces modèles de programmation, nous devons oublier comment nous fabriquons des produits idéaux - parce que nous ne le faisons pas. Nous essayons d'accélérer la recherche, nous devenons des scientifiques.



Ainsi, au lieu de réfléchir aux architectures, nous devons trouver un moyen d'itérer très rapidement. Au lieu d'approcher et de penser à l'avenir, vous devez réfléchir à la façon de le faire maintenant, en peu de temps.

Au lieu de penser à votre réputation, à ce qui se passera si je dis que je suis sûr ou pas sûr ... Au lieu de cela, je dois abandonner ma réputation et devenir de nouveaux arrivants. Dunce. Comment fait-on cela? Quelles choses spécifiques pouvons-nous appliquer pour devenir des débutants?



Le premier point et le plus important est la rétroaction. Avant même de planifier notre prototype, de dessiner une mise en page ou autre chose, nous pensons à qui nous montrerons ces modèles ou prototypes, comment nous testerons le produit et ce que nous essayons d'obtenir de cette expérience. Plus cette boucle de rétroaction est courte, mieux c'est pour nous.

Un exemple de la vie personnelle. Productive Mobile est la société pour laquelle j'ai récemment travaillé, une startup, ils ont mis au point une plate-forme qui vous permet de créer une application mobile à partir d'un site Web de manière très simple. Nous l'avons vendu à de grandes entreprises car elles ont des produits comme SharePoint ou SAP qui ne peuvent pas être utilisés sur un téléphone mobile, zoom pincé, c'est tout. Nous leur avons proposé une option: vous pouvez créer une application mobile basée sur un site réel, disons, en une semaine. Le problème est que nous avions une équipe de développement très solide et un cycle de vente très long. Lorsque vous vendez un produit d'une entreprise de la taille de Daimler ou BMW, le cycle de vente est d'un minimum de 8 mois. Pendant cette période, une équipe de développeurs talentueux peut déposer beaucoup.

Qu'avons-nous fait et qu'est-ce qui nous a aidés? Nous avons créé une mini-équipe d'utilisateurs au sein de notre entreprise qui a utilisé le produit. Et le nombre de fonctionnalités que nous avons commencé à faire et à publier a diminué. Mais en même temps, la qualité des fonctionnalités a augmenté n fois. Et quand nous sommes arrivés chez notre utilisateur et avons dit que nous avions telle ou telle plate-forme, essayons, pour une raison quelconque, les situations d'urgence ont cessé quand nous étions comme ça: nous n'y avons pas pensé, c'est quelque chose de nouveau. Nous avons commencé à créer des fonctionnalités qui ont commencé à produire des résultats. Cela est dû au fait que nous avons simplement réduit la boucle de rétroaction.

Un exemple avec un métronome, le projet Polychops sur lequel je travaille actuellement. Tout d'abord, nous avons créé une vidéo en peu de temps, que nous avons publiée quelque part sur Internet. Dans ce document, nous avons demandé comment aimez-vous ce concept, qu'en pensez-vous. Selon les critiques, nous avons non seulement apprécié son intérêt. Nous avons encore des pistes avec lesquelles nous pourrions parler, à qui nous pourrions inviter à des appels, des entretiens, leur donner un essai d'un prototype, etc.

Nous essayons d'obtenir des commentaires très tôt. Et pas n'importe quelle rétroaction, mais qualitative, pas quantitative.



Quelle est la différence? La rétroaction quantitative est un test AV, des résultats binaires, lorsque l'option A ou l'option gagne. C'est tout ce que nous pouvons obtenir des cycles quantitatifs. C'est comme si nous étions dans une pièce sombre et que rien n'est visible, mais nous avons un pointeur laser. De temps en temps, nous l'éclairons dans les coins, soulignons certains points et comprenons ce qu'ils contiennent.

Que souhaiterions-nous à la place? Un utilisateur qui décrira cette pièce sombre, qui la connaît bien mieux que nous. Nous avons besoin d'entretiens de haute qualité, d'appels, de quelque chose d'autre pour recevoir des informations des utilisateurs sous une forme élargie.



Booking.com est un exemple d'entreprise qui s'appuie fortement sur les commentaires quantitatifs. À mon avis, il y a quelque chose à travailler sur leur site.

L'un des prototypes du projet sur lequel je travaille est une fonctionnalité avec laquelle une personne peut s'enregistrer et reproduire en même temps comment elle a joué sous le métronome - bonne ou mauvaise. Nous avons inventé cette fonctionnalité parce que nous avons demandé des commentaires de qualité aux personnes qui ont testé le prototype. L'une des personnes a écrit que tout était super, j'aime la partie avec le métronome, mais ce serait cool d'exporter cette piste avec le métronome en tant que piste audio. Nous sommes comme ça - c'est illogique, pourquoi? Il dit: "J'insère ceci dans mon programme pour travailler avec la musique, puis je m'écris moi-même, et ensuite je peux entendre si j'entre dans le rythme ou pas." Nous sommes comme ça - c'est génial.

Mais au lieu de simplement exporter, nous avons décidé de tester l'hypothèse. Nous avons parlé aux gens, leur avons demandé s’ils s’écoutaient quand ils jouaient avec le métronome. Beaucoup ont dit que oui, nous avons souvent un programme - un métronome, un autre programme - un enregistreur vocal au téléphone ou ailleurs, nous enregistrons et nous écoutons. Nous sommes comme ça - nous sommes des programmeurs, nous pouvons combiner cela dans une seule application. En conséquence, nous avons obtenu cette fonctionnalité. Nous ne l'aurions jamais deviné si nous venions de faire des tests AV.



La partie la plus importante du prototype est l'interface. Dans un sens global. Si nous avons une sorte de service avec une sorte d'API, alors notre interface est une API, alors ce avec quoi l'utilisateur interagit. Si nous travaillons sur un métronome, notre interface est la partie visuelle et le son. Si nous travaillons uniquement sur une application mobile, notre interface est une interface visuelle. Dans le prototype, l'interface est la seule partie importante. Tout ce que nous pouvons simuler, remplacez-le par une peluche.

Un autre exemple de Productive Mobile. À un moment donné, nous avons décidé de réécrire l'API interne dans cet éditeur de glisser-déposer des applications mobiles. L'API permet à JS de relancer certaines parties complexes de votre application mobile. En tant que chef de produit, je pouvais simplement écrire une spécification et la donner aux développeurs. Je suis sûr que dans un maximum d'un mois, tout serait prêt, testé et merveilleux. Mais nous avons décidé d'essayer une voie différente. Nous venons de documenter l'API que nous avions en tête, sur papier, et avons donné ce papier aux personnes qui créaient des applications mobiles. Ils ont demandé: si vous aviez une telle API, comment construiriez-vous vos applications en théorie?

Ils ont pris un autre papier, ils ont tout vérifié. Sans implémentation. L'API n'a pas fonctionné à ce stade. Nous avons donc effectué 5 à 10 itérations avant de réaliser la forme de l'API. Nous avons économisé énormément de temps pour la mise en œuvre. Après avoir compris le formulaire, nous avons documenté la spécification, l'avons mise en œuvre. Tout est devenu merveilleux.



Un autre exemple du métronome. La toute première idée pour Polychops est un métronome pour travailler avec des polyrythmies. Nous avons réalisé le premier prototype en environ 20 minutes, a écrit sur Flash. Voici à quoi il ressemblait. Il y avait même un son. Nous sommes juste allés le montrer à d'autres musiciens, nous avons demandé - comment aimez-vous cela? C'est la seule chose importante.



Puis on a fait un vrai métronome dans le navigateur, ça a marché, animation, bla bla, tout est beau.


Mais cela a pris environ un mois et demi, et le prototype précédent a pris 20 minutes.

Concentrez-vous sur l'interface.



Pour gagner du temps, utilisez un système de conception. Un exemple rapide de Polychops.



À gauche se trouve le prototype initial, où nous avons juste tous les boutons, pensé à toutes les interactions nous-mêmes. Après un certain temps, nous avons décidé que nous avions besoin d'un menu, d'une navigation, de listes déroulantes, d'autre chose. Nous pourrions nous asseoir et réfléchir avec les concepteurs à chaque liste déroulante, à chaque bouton, mais c'est une énorme quantité de temps, que nous n'avons en principe pas besoin de passer. Par conséquent, nous avons pris le système de conception fini, pris la conception matérielle, ils ont tout parfaitement documenté. Vissé, tout va bien.



Voler. Ne volez pas aux concurrents. Il est inutile de voler aux concurrents. Si quelque chose fonctionne pour les concurrents, vous n'avez pas besoin de le vérifier, il vous suffit de le copier. Volez des produits qui sont parallèles aux vôtres, qui ne sont pas exactement votre produit, mais quelque chose de similaire.



Un autre exemple de Polychops. L'interface d'enregistrement est pratiquement léchée des programmes sonores existants tels que Logic. Naturellement, nous l'avons grandement simplifié, mais les gens savent déjà comment utiliser Logic, ce qui signifie qu'ils peuvent comprendre comment utiliser Polychops.

. , . .



: , . , , .



, , . , , . , , , , , . .



— . , , . , .



, , — . . , React . React, React. , , , Redux Apollo, . . .



— . , , — . , - , . , , , , , . -, . . -, , — , . , , , , , .



, , . . , . — , , .

, . , . . , . . . — , . , .

? « ?» — , . ?



. , . . 10% , , 10%, , — .

. , 90% , . , , 10%. — , . .

, . Productive Mobile , . , , - , .

. React, — React Native. , , — React, React Native. - : «, React Native, , ». .

? . , , 10 React Native , React Native-. , - , , . , , , «write once — use anywhere». Android iOS . . , , , . — , - , - . — .

, , … ?

Polychops - , . , , , , , . - , , . . .

, . , , , . , , , , , , , , , .

, , , - . Je vous remercie