J'ai parlé avec les fondateurs de la startup ElectroNeek: Sergey (PDG), Dmitry (CIO) et Mikhail (CTO). À la fin de l'interview - une vidéo où le robot est assemblé en direct.
- Dmitry, veuillez envoyer une photo pour le KDPV, où vous êtes tous ensemble.
- Croyez-le ou non, nous ne nous sommes pas encore autant rencontrés depuis deux ans)
ElectroNeek développe un écosystème de produits logiciels qui peuvent être utilisés pour créer des robots qui répètent toutes les actions des employés de bureau sur un ordinateur avec toutes les applications qui y sont installées. Ainsi, il est possible de robotiser totalement ou partiellement les processus de l'entreprise. ElectroNeek se spécialise dans le travail avec des intégrateurs système et des équipes informatiques créant des centres de compétences RPA, c'est-à-dire que leurs produits sont destinés à ceux qui développent des robots en grand nombre, et ne résolvent pas plusieurs problèmes spécifiques d'automatisation locale.
RPA (Robotic Process Automation) est une technologie qui permet d'automatiser les tâches répétitives quotidiennes. RPA vous permet d'émuler littéralement les actions d'un utilisateur régulier sur un ordinateur. Vous avez passé votre souris sur le bouton et cliqué, puis entré le texte avec le clavier et appuyé sur "Entrée". C'est exactement ce qu'est la RPA. À mesure que la demande augmentait, les fournisseurs de RPA ont commencé à faire évoluer leurs solutions pour fournir des mécanismes d'automatisation plus flexibles. Il y a des intégrations avec les langages de programmation, avec des technologies comme l'OCR, ils réfléchissent sérieusement à l'introduction de l'apprentissage automatique. Les robots peuvent désormais être lancés simultanément, selon un planning, à distance, etc. Exemples de cas: un , deux , trois , quatre, cinq .
- Qu'est-ce qu'un robot?
Mikhail: La robotisation est une émulation d'une personne. Une personne peut être émulée sous différentes formes. Vous pouvez physiquement. Le robot marche comme un humain. Le robot clique sur le moniteur comme un humain. Taper comme un humain. Il n'y a jamais d'émulation humaine complète. Mais l'aspect de l'émulation humaine est la robotisation.
- Mikhail, Yandex vous a chassé, mais vous avez quand même décidé de travailler chez ElectroNeek, quelle est votre motivation à travailler dans une startup, et pas dans un emploi chaleureux garanti?
Mikhail: Lorsque vous travaillez dans une startup, vous êtes vous-même le forgeron de votre propre bonheur, mais dans l'entreprise, vous êtes limité.
- Michael, comment as-tu été attrapé?
Mikhail: À ce moment-là, j'avais déjà quitté Akronis depuis un an, j'ai arrêté de voir mon vecteur de développement, je voulais étudier différentes technologies, faire des projets pour animaux de compagnie. Je voulais faire quelque chose par moi-même et je cherchais une équipe. Pendant ce temps, Dimitri et Sergei cherchaient un CTO et ont lancé un cri à leurs connaissances. Je connaissais Dmitry de l’université, même si nous ne communiquions pas beaucoup, alors nous nous sommes réunis. J'étais prêt pour cette proposition.
J'avais besoin de comprendre si je croyais au projet ou non. Nous avons rencontré Sergei dans un café, il m'a décrit très superficiellement ce qu'est Electroneek, et après la réunion, j'ai étudié de manière indépendante le sujet de la RPA plus en détail, j'ai examiné les concurrents.
Nous avons téléphoné à nouveau, déjà trois d'entre nous. Sergey et moi étions assis l'un à côté de l'autre, et Dmitry était en Amérique à ce moment-là. Nous avons parlé du produit, comment ils le voient, où ils prévoient de se développer, pour qui il est, comment nous allons nous démarquer et pourquoi il y a «un autre constructeur de robots» sur le marché.
J'ai vu qu'il y avait une demande, du moins en Russie. Dmitry a parlé du marché mondial, en particulier des États-Unis. Auparavant, il travaillait chez Ernst & Young et y dirigeait RPA pour les entreprises du Fortune 500, il connaissait donc bien la demande.
Sergey et Dmitry ont décidé de se différencier de leurs concurrents avec une UX simple et pratique, pour rendre la robotisation plus accessible aux entreprises de toutes tailles. J'avais besoin de savoir si mes co-fondateurs potentiels comprennent ce que sera l'interface, quelle est exactement sa fraîcheur. J'ai entendu la réponse honnête "Nous ne savons pas." Pour le moment, les gars ne savaient pas ce qui devrait être exactement, mais ils prévoyaient d'essayer de le découvrir.
Une telle honnêteté et une telle ouverture étaient importantes pour moi. J'ai aimé qu'ils soient honnêtes sur la situation. Ceci est important pour les relations futures. Tout dire tel qu'il est, et si une personne est adéquate, elle comprendra. Quand vous êtes honnête, si un montant sort quelque part, vous pouvez immédiatement regarder comment résoudre le problème, peu importe qui a gâché.
- À quoi ressemblait Electroneek avant de rejoindre le projet?
Michael:Avant moi, il y avait un prototype fonctionnel qui pouvait être montré. C'était un projet sur GitHub pour montrer ce qu'ils sont sur le point de faire.
Quand je suis arrivé, ils m'ont montré un prototype, parlé des concurrents, des tâches à résoudre et demandé de bien faire . Pas sur le genou, mais pendant longtemps, pour qu'il puisse se développer. Mais il n'y avait pas le temps de s'asseoir longtemps pour se développer, il fallait aller plus vite au combat. Il fallait courir vers les clients, il fallait attirer de l'argent. Par conséquent, dès les premiers jours, j'ai commencé à écrire du code. Je connaissais déjà Electron à cette époque. (Electron est un framework qui vous permet d'écrire des applications de bureau en utilisant la pile de technologies Web.)
- Qu'est-ce qui différencie le développement d'un produit RPA des autres?
Sergey:Quelle est la différence entre le développement d'une plateforme RPA et un produit «en soi»? La plateforme RPA, en particulier ElectroNeek, est un outil de développement. Un moyen de créer quelque chose en interagissant avec quelque chose de tiers. Ce n'est pas un produit distinct comme le CRM, qui en lui-même et parfois seulement via l'API interagit avec autre chose.
Un utilisateur basé sur ElectroNeek crée une solution logicielle (robot) qui va interagir avec d'autres produits en constante évolution: navigateurs, ordinateurs de bureau. Vous ne contrôlez pas l'environnement avec lequel le résultat du développement interagira. Cela impose d'énormes exigences en matière de qualité, d'UX et de développement de solutions produits.
- Pourquoi un autre produit RPA sur le marché?
Sergey:les gens viennent souvent nous voir et nous disent: "Pourquoi développez-vous alors que vous pouvez aller sur un site Web, télécharger un module de clic RPA prêt à l'emploi et le créer?" Oui, il peut ouvrir un ordinateur portable, se familiariser avec Internet Explorer, ouvrir Google. Mais dès que vous allez plus loin (dès que XPath ou des sélecteurs apparaissent), différentes variantes de sites, d'écosystèmes gouvernementaux ou SaaS, vous serez confronté au fait que ce n'est pas prêt et ne fonctionne pas. Et puis, si vous développez votre propre plate-forme, vous devez vous adapter aux changements, et si tout est déjà câblé, vous ne pouvez pas vous adapter de manière flexible aux changements. Nous l'avons eu sur le pilote.
- Comment avez-vous choisi la pile technologique?
Michael:Le projet impliquait qu'il y aurait à la fois un bureau et un composant WebPart, une façade classique, une façade classique et une application de bureau. Et au début, le projet n'impliquait pas une grande équipe. J'ai compris que les premiers mois je serais seul, nous n'avions pas prévu de nous développer à un rythme grandiose.
J'avais besoin de fournir une sorte de multi-station pour que 1 à 3 personnes puissent tout faire. C'est pourquoi nous avons choisi Electron. Il vous permet d'écrire une application de bureau, un backend et un frontend dans le même langage (nous l'avons TypeScript).
À l'avenir, vous pouvez vous spécialiser, mais au début, c'est très pratique lorsque tout le monde peut tout faire.
En règle générale, il y a un problème de basculement du contexte du backend vers le frontend. Par exemple, sauvegarde en python, façade en JavaScript, combinaison populaire. Et même si une personne combine cela en elle-même, il lui sera coûteux et difficile de passer d'une langue à une autre. Et lorsque vous résolvez un problème, vous changez souvent, ce n'est pas pratique. Nous nous sommes débarrassés de cela, rien ne change lors du changement: une langue, une approche, même tout se ressemble.
Ensuite, j'ai cherché des bibliothèques capables de fermer immédiatement certaines de mes tâches et je n'ai pas essayé de tout écrire moi-même.
Au début, vous n'avez pas besoin d'essayer de faire du vélo. Préparez-vous si cela répond à vos besoins. Peut-être que vous devez alors vraiment retirer cette pièce et la remplacer par la vôtre. Mais en même temps, vous aurez immédiatement une pièce de travail.
J'ai pris une bibliothèque prête à l'emploi pour la visualisation. Notre produit principal est un environnement de développement, et il existe une visualisation d'organigramme. Naturellement, je ne l'ai pas écrit moi-même, mais j'ai pris la bibliothèque open source joinjs. Il vous permet de travailler au niveau svg. Dessinez des interfaces à l'aide d'images vectorielles.
Nous y sommes assis depuis longtemps. Parfois, nous pensons que nous allons nous débarrasser d'elle, cela peut être fait à tout moment, mais jusqu'à présent, elle effectue toutes les tâches et tient la charge.
Il est important de tout écrire de manière modulaire afin que vous puissiez jeter un morceau et ne pas vous confondre dans votre propre web de code. L'approche modulaire vous permet de vous débarrasser rapidement des bibliothèques.
Notre programme n'est pas seulement un éditeur d'organigrammes, il résout un problème spécifique - il automatise le bureau. Vous l'utilisez pour gérer les applications de bureau.
Une partie importante de notre programme est une bibliothèque de bas niveau pour interagir avec les applications, comment appuyer sur un bouton, compter une image, créer une capture d'écran.
J'ai pris la bibliothèque standard C # UIAvtomation, qui était également utilisée par nos concurrents à l'époque. Nous l'avons récemment remplacé par un plus moderne.
Cette bibliothèque avait un wrapper, une API assez étroite que nous avons utilisée. Ensuite, nous avons pu jeter cette bibliothèque, en attacher une nouvelle et la coller avec un adaptateur à cette API. Cela se produit rapidement et sans douleur, et cela devrait être fait.
- Comment les fonctionnalités ont-elles été implémentées?
Mikhail: J'ai parlé avec les co-fondateurs, ils avaient de l'expérience dans l'intégration de la solution d'un concurrent, ils comprenaient quelles fonctionnalités étaient nécessaires. Ils m'ont donné une liste des fonctionnalités qu'ils ont beaucoup utilisées. J'ai commencé à les fabriquer un par un.
Littéralement un mois ou deux plus tard, nous avons commencé à faire un projet pilote pour la poste russe.
Nous avons résolu le problème de l'automatisation du déchargement pour eux. Ils avaient une application RH de bureau pour la gestion des CV. Il n'y avait pas d'interface et vous deviez sortir tous les CV. Il n'y avait pas d'API, pas de base de données et ils ne pouvaient pas les extraire.
Nous venons de cliquer sur cette application, de récupérer les données à partir de là et de les mettre sur le disque.
La solution principale n'a pas été difficile, j'ai écrit l'algorithme en quelques heures, mais le diable est dans les détails. Beaucoup de nuances: documents de types différents, certains types de champs peuvent ne pas exister, etc. J'ai passé un peu plus de temps à finir.
Pour chaque fonctionnalité, je me suis demandé de quelle solution j'avais besoin maintenant pour qu'à l'avenir je puisse résoudre des problèmes de ce genre. Si une fonctionnalité passait ce filtre, je l'ai ajoutée. Au début, les fonctionnalités sont ajoutées sans trop de discussion. La base de code est petite, ajoutée, essayée, supprimée, c'est facile.
Lorsque l'application est déjà volumineuse, chaque fonctionnalité nécessite une discussion. Qu'est-ce que la fonctionnalité affectera, si elle casse quelque chose et si nous avons un autre moyen. Au début, il est facile de scier des traits, ils ne cassent rien, car il n'y a toujours rien à casser.
- Quelle a été l'ampleur du travail pour la poste russe?
Mikhail: L' application contenait tous les employés de la poste russe dans tout le pays. Il est impossible de le crier avec vos mains.
Ce que faisait notre robot. Il a entré une recherche avec des filtres vides. Le résultat est une liste de tous les employés avec défilement sur plusieurs écrans. Vous devez cliquer sur chaque élément de la liste sur la feuille, une fenêtre s'ouvre, il y a une partie des données et plusieurs boutons qui ouvrent d'autres fenêtres. Toutes les fenêtres devaient être ouvertes, toutes les données devaient être assemblées, les fenêtres devaient être refermées et passer à l'élément suivant de la liste. Et avec de telles itérations pour tout voler. Voici un résumé approximatif du processus.
Le pilote était mutuellement libre et nous ne l'avons pas mis en état de production. Pour nous-mêmes, nous avons fait une preuve de concept: sur la plate-forme, vous pouvez résoudre tels ou tels problèmes, vous pouvez aller avec cela pour collecter des fonds, vous pouvez vendre aux clients et terminer en déplacement. C'est ce que nous avons commencé à faire.
- Comment avez-vous attiré les investissements?
Michael:Nous avions besoin d'un prototype fonctionnel qui impressionnerait les investisseurs. L'interface de la solution pour Russian Post n'était pas jolie, elle a été faite par moi, et je ne suis pas designer. J'ai fait pour moi, le mode IDE WebStorm Dark.
Les premières étapes du prototype
ElectroNeek en 2021
Les investisseurs savent utiliser l'imagination. Vous pouvez leur montrer un prototype tordu et leur dire comment cela va changer et ils comprendront. Le prototype peut même être bogué et bogué, mais l'essentiel est de montrer un grain de sens pour que l'investisseur puisse en saisir l'essence. Les clients doivent montrer un beau produit prêt à l'emploi. Les personnes adéquates comprennent la différence entre un MVP et un produit final. Et il vaut mieux ne pas travailler avec des insuffisants. Vous prenez des investisseurs depuis longtemps, il est agréable de travailler avec des personnes adéquates.
- Comment ont été les manifestations aux investisseurs?
Michael:Disons que j'ai écrit une nouvelle fonctionnalité, et demain matin, elle doit être démontrée aux investisseurs. Je comprends qu'il ne peut pas être montré sous cette forme. Peut-être que quelque chose se branche, peut-être qu'il n'y a pas de bon exemple pour montrer la fonctionnalité. Je suis assis là à finir la nuit, à trouver des exemples, à attraper des insectes pour que ça ait l'air bien le matin. Le matin je viens sans dormir pour la démonstration. Je montre le produit aux investisseurs. Presque sans sommeil, mais avec succès.
Au début, il n'y a pas moyen de s'en passer. Il n'y a pas de processus de développement normal lorsqu'il existe un environnement de développement à part entière, un environnement de test, un classement, une production. Il n'y a qu'un seul environnement, c'est pour vous à la fois le standing et la production. Vous êtes le seul et votre tâche est de le faire plus rapidement. Et vous travaillez comme chirurgien qui vient de se préparer pour l'opération et a "ouvert" le code, et ils lui disent: "Eh bien, cousons-le plus vite et allons-y."
Je devais tout faire et suivre le rythme. Tant que l'application est petite, elle tient bien dans la tête, un bon développeur est capable de tout faire lui-même et de ne rien manquer. Lorsque l'application se développe, il n'est plus possible de se passer du QE.
Sergei: Nous avions des ressources limitées, nous n'avons reçu que 150 000 dollars, dont 70 000 en espèces, c'était tout ce qu'il fallait pour finir le prototype en un produit normal et montrer les premières ventes en Russie et aux USA. Ensuite, ils ont recueilli 0,5 million de dollars. Nous avons montré des ventes rapides. Les investisseurs ont cru en nous.
Michael:Dès que l'argent est apparu, ils ont commencé à agrandir l'équipe afin de fabriquer un bon produit le plus rapidement possible. Que signifie «bien»? Vous n'avez pas besoin d'un produit parfait dès le début, même s'il peut être fabriqué. C'est une erreur. Beaucoup de gens savent comment le faire parfaitement, mais cela prend beaucoup de temps. Si rapide et bon, alors trop cher. Tout est impossible à la fois. En conséquence, cela doit être assez bien fait ici . Assez bon pour vendre.
Vous pouvez créer un produit avec des bogues, s'ils ne sont pas critiques, ne tirez pas dans la jambe et vous pouvez ajouter des fonctionnalités plus rapidement. Les gens achètent un produit avec un bogue, ils voient un bogue, un rapport à ce sujet, nous le corrigeons juste là. Les gens voient les commentaires. Il n'y a pas de problème.
- Comment embauchez-vous des développeurs?
Michael:Je me concentre plus sur la capacité que sur l'expérience. L'expérience est importante, mais le développement est quelque chose où vous devez constamment apprendre quelque chose. Lorsque vous devez faire glisser une nouvelle bibliothèque dans le projet, la probabilité que vous la sachiez ne sera pas très élevée. Les connaissances de base sont importantes. Nous avions besoin de connaissances de TypeScript, il a fallu beaucoup de temps pour se recycler dans un autre langage. Le cadre est souhaitable de savoir. Nous utilisons Angular.
Il est important pour nous qu'une personne puisse résoudre rapidement un problème complexe sans erreurs, ou avec des erreurs faciles à corriger, qui apparaîtront pendant la course. Une personne devrait être capable de réfléchir à beaucoup de choses. S'il est capable de réfléchir à beaucoup de choses, de comprendre quel genre de cas d'angle il y a en général, alors c'est cool.
Il arrive souvent que les gens écrivent un programme, mais ils n'ont tout simplement pas pensé à certains cas. Et qui va-t-il penser d'eux? Le QA peut ne pas y penser non plus. Et puis ils tirent. Dans le même temps, les données initiales sont suffisantes pour prédire ces cas de coin. Pour moi, c'est la différence entre un développeur prometteur et un développeur peu prometteur: combien de cas de coin au départ il est capable d'anticiper.
- Combien de personnes y a-t-il maintenant?
Mikhail: Six personnes - développement de base, qui créent directement la plate-forme. Quatre personnes qui sont surrendre la plate-forme des solutions réutilisables. Ils utilisent la plate-forme, ainsi que des outils supplémentaires dans les langages de script, et réalisent des projets spécifiques. Je parle juste des développeurs maintenant. Il existe également un département QA, une équipe produit distincte.
- Comment êtes-vous passé du codage aux responsabilités de gestion en tant que CTO?
Mikhail: Après avoir reçu l'investissement, j'ai activement écrit du code pendant plusieurs mois. Bien que nous ayons embauché QA, je n'en étais pas particulièrement sûr. J'ai écrit la revue de code moi-même.
Puis j'ai vu sur le tableau kanban que j'étais un cou étroit. Et je comprends qu'il est temps de lâcher prise, d'accepter que les problèmes me passent à côté de la production.
J'ai passé en revue les choses les plus critiques. A commencé à s'appuyer sur l'assurance qualité. C'était un processus graduel d'abandon du contrôle. Lorsque vous passez tout par vous-même, vous êtes sûr du résultat. Vous voyez tout, vous pouvez attraper tous les problèmes vous-même. Mais ce n'est pas une histoire évolutive. Elle est bonne au début, alors vous devez vous débarrasser d'elle en cachette. J'ai donc progressivement lâché prise, examiné uniquement les endroits critiques, puis arrêté complètement d'écrire et de réviser. Maintenant, tout le monde le fait sans moi.
- Maintenant que vous avez accepté la baisse de qualité, quelle est la prochaine étape?
Mikhail: Ecoutez, je n'ai plus la possibilité de revoir le code, nous avons déjà traversé ça. Que puis-je faire d'autre? Vous pouvez maintenant ajuster les choses du processus.
Disons que les développeurs fusionnent des fonctionnalités de qualité pas très élevée dans la branche principale. Quelque chose ne va probablement pas avec l'examen. On verra. Vous regardez ce que les gens examinent. Aha, pour attirer l'attention des gars là-dessus. Vous allez aux instructions. Processus de débogage. À la recherche de points faibles. Vous n'essayez pas de travailler, vous créez des processus.
C'est là que les développeurs examinent, mais les fonctionnalités ne sont toujours pas très fusionnées. Ajoutons un test de fonctionnalité avant de le fusionner. Ajoutée. Que s'est-il passé? Maintenant QA n'a pas le temps de les tester. D'accord, toutes les fonctionnalités ne doivent probablement pas être testées de cette manière, mais uniquement les plus dangereuses qui affectent l'ensemble du projet. Vous équilibrez
Il n'y a pas de modèle pour différentes entreprises, mais l'approche générale est la même: tester votre système et résoudre les goulots d'étranglement de manière procédurale. Alors c'est déjà une histoire évolutive.
Ma tâche est de trouver le goulot d'étranglement où se trouve le problème du processus, de parler aux gens et de mettre en œuvre une solution fonctionnelle.
Idéalement, si je m'écarte, alors tout fonctionne. C’est impossible au départ. Écartez-vous, tout est cassé. Et maintenant, il devrait être que je suis parti pendant un mois et que rien ne s'est cassé.
- Comment comprendre quand embaucher une personne spéciale?
Mikhail: Y en a - t-il assez pour ce cou étroit d'homme? Si une personne est occupée à au moins 70% par cette tâche, vous pouvez embaucher. Si vous avez besoin d'une personne 5% du temps, vous pouvez probablement vous en occuper vous-même.
- Que faites-vous maintenant?
Mikhail: Je suis toujours en charge des processus. Et je vais m'occuper d'eux pendant longtemps.
Je parle de fonctionnalités, comme Sergey. C'est là que notre produit se développe. Il le passe à travers son propre prisme, moi à travers le mien.
Nous sommes des développeurs écrivant un outil de développement. Je ne suis pas en mesure de suivre toutes les fonctionnalités que nous faisons, mais j'analyse les fonctionnalités importantes, complexes, critiques ou intéressantes et je donne des commentaires à l'équipe produit, qui optimisera la fonctionnalité en fonction de cela. Je ne suis pas dans le métier de décrire, mais d'écouter ce qu'ils vont faire et de faire des commentaires. Sergey fait de même en termes de fonctionnalités. C'est quelque chose que nous ne lâcherons certainement pas. Il est important de comprendre où le produit se déplace, où nous le développons.
- Comment étudies tu?
Michael:Premièrement, j'énonce clairement le problème. L'expérience de vie permet déjà de beaucoup décider. J'en sais déjà beaucoup plus que lorsque j'ai été diplômé de l'université, mais il y a encore des problèmes que je ne comprends pas comment résoudre.
Premièrement, je découvre quel est le problème. Disons que je n'ai pas une sorte d'outil. Je cherche sur Google, je regarde YouTube ou un cours, je découvre ce que font les professionnels dans un domaine particulier.
Par exemple, comment tester des applications volumineuses lorsqu'il y a beaucoup de tests manuels? On n'a pas le temps, que faire?
Si vous n'êtes pas un QA cool dans le passé, vous comprenez indirectement ce qui est quoi, mais vous ne connaissez peut-être pas certaines nuances. J'ouvre YouTube, j'écoute une conférence d'assurance qualité d'une heure avec de nombreuses années d'expérience, je comprends que ce que j'ai entendu peut être appliqué, j'essaye, j'analyse. Si ça va, je le laisse.
Il est impossible de tout savoir. La tâche de tout gestionnaire est d'apprendre tout ce qui est possible, de déléguer et de manière à conserver la fonction de contrôle.
Définissez le cadre dans lequel les gens travaillent et contrôlez le résultat dans ce cadre. Ils prennent leurs propres décisions.
S'il y a un problème sur le marché, la décision peut être prise sans moi. Le contrôle qualité dit que la tâche est critique et peut décider de revenir en arrière. Je n'ai pas besoin de me réveiller pour ça. L'essentiel est que les gens comprennent le cadre.
- Des conseils pour vous-même dans votre jeunesse?
Michael:Au début, il m'a semblé qu'au début je devais beaucoup apprendre. Quelque chose que je ne sais pas encore. Je ne peux pas écrire un site Web, je ne peux pas écrire un backend. Je voulais d'abord suivre un cours ou terminer une université. Pas vraiment. Prenez-le et essayez-le. Google est un excellent outil, tout y est. Résolvez les problèmes ponctuellement. Vous ne savez pas comment à le faire spécifiquement, et d' apprendre à faire ce en particulier . Vous ne savez pas comment configurer nginx, alors étudiez-le spécifiquement.
Vous ne pouvez pas tout apprendre. Suivre un cours de programmation de plusieurs semaines prend trop de temps. Mieux vaut commencer la programmation. Ces problèmes qui se poseront pour vous et les résoudront. C'est plus rapide de cette façon. Et encore plus plongé dans le problème que la lecture d'un livre. Si vous lisez 600 pages d'une couverture à l'autre, les connaissances seront superficielles. La connaissance est plus profonde sur l'expérience.
J'ai "découvert Google" dans le sens où je peux, avec mes connaissances, faire des choses complexes, google, et trouver des solutions ponctuelles pour les plugs. C'est ainsi que je me suis développé dans le futur.
Je lis des livres de manière sélective. Lorsque je résolvais un problème, j'ai trouvé un fragment qui décrit la solution. Les articles sont les mêmes. Vous ne pouvez pas non plus regarder les conférences dans leur intégralité. Les conférences durent 4 heures. Trouvez le code temporel, regardez simplement la partie intéressante, cela peut suffire.
- Parlez-nous des contrôles de l'organisation des services (SOC)?
Sergey: Si vous souhaitez créer une application SaaS sur le marché américain, en particulier quelque chose qui fonctionnera dans des entreprises de plus de 200 à 500 personnes, la question du SOC (Security Organization Control) se posera immédiatement. Alors que vous ne l'avez pas, tout le monde le lui demande. C'est une histoire qui passe au peigne fin les politiques de l'organisation, la répartition par niveau de droits et d'accès, comment concevoir le code, les auditeurs viennent vérifier.
Tant que vous ne l'avez pas, tous les clients normaux le demandent et ne signent pas le contrat. Dès qu'il apparaît, et que vous dites "nous l'avons, si vous voulez envoyer un rapport", les clients répondent que ce n'est pas nécessaire, "nous ne voulons pas lire le rapport".
Cela prend quatre mois, est mis en ordre et est en cours de vérification. Un ensemble d'activités qui affecte l'ensemble de la pile technologique. Michael peut dire, il a complètement conduit ce processus.
Mikhail: Nous sommes une organisation qui fournit des services aux clients. Le SOC concerne les outils dont nous disposons pour garantir la sécurité, la disponibilité et la continuité du service et la sécurité des données. Toutes ces choses qui intéressent les gros clients et peu d'intérêt pour les petites organisations.
Si notre client est une grande organisation, le manque de SOC peut être un problème pour eux. Leurs règlements ne permettent pas de travailler avec vous. Par conséquent, à un certain moment, cela a fait surface pour nous.
Soit vous avez cette certification, SOC (cela coûte encore cher pour une startup en herbe), soit l'entreprise vous envoie un questionnaire de plusieurs pages sur votre sécurité. Vous le lisez et vous n'en comprenez pas la moitié.
Vous pouvez le remplir pendant longtemps, car dès le départ, il n'est pas toujours clair sur quoi porte le discours. De plus, pendant que vous remplissez, vous comprenez que nous ne l'avons pas. Et ce n'est pas le cas. Et ce n'est pas là non plus. Et il ne sert à rien d'envoyer ce questionnaire. Et il ne semble pas si difficile de faire en sorte que ces choses se produisent. Mais cela doit être fait.
À un moment donné, nous avons réalisé que de tels clients viennent chez nous, nous remplissons leurs questionnaires pendant longtemps, mais à la suite de la transaction, il n'y en a pas. Nous avons décidé de régler ce problème.
Cette certification est un processus de contrôle continu. Non pas que vous l'ayez fait une fois et c'est tout. Vous devez mettre en place une sorte de "cases à cocher" sur une base régulière. Vos données sont toujours cryptées lors de la transmission. Vous avez des données qui sont toujours cryptées sur les serveurs, au cas où elles disparaîtraient quelque part sur le disque dur, personne ne retirera rien de là. Il existe de nombreux exemples de ce type et des exemples plus sophistiqués.
Lorsque vous commencez à rechercher comment faire cela sur Google, vous trouvez une feuille A4 de 60 feuilles, ce qu'il faut faire et comment le faire. Et chaque point doit être démonté, car vous ne le comprenez pas. Cela ressemble à un travail très long.
D'accord, c'est la voie que nous allons suivre pendant longtemps. Ou peut-être pouvons-nous trouver une entreprise qui nous facilitera la vie? Notre compagnie. À l'époque, nous étions déjà chez Y Combinator. Nous avons posé cette question aux gars de là-bas, nous avons été incités par des anciens de YC qui vont automatiser cette histoire. Le service n'est pas gratuit, mais nous avons acheté un service auprès d'eux. Il s'agit d'une sorte de panneau d'administration dans lequel vous intégrez tous vos services. JetSuit, Bitbucket, Gitlab, Jira, AWS, Azure, qui a quoi. Le programme lui-même étudie où vous avez quels paramètres, et dit quoi et où vous manquez. Vous le corrigez par point et tous les éléments de cette feuille sont automatiquement fermés.
Après cela, un auditeur est invité, qui confirme que tout est vraiment là et met un "test". C'est ainsi que nous avons simplifié notre vie.
Pour les grandes entreprises, c'est une formalité, sans laquelle elles ne pourraient pas aller plus loin et coopérer avec nous. Eh bien, en plus, une réelle augmentation de la sécurité des clients.
- Parlez-nous de Y Combinator à travers les yeux d'un développeur?
Mikhail: Je n'ai pas vraiment compris à quoi servait YC. Il était clair que c'était du prestige. Et l'objectif spécifique était difficile à comprendre pour moi. J'ai lu comment cela peut être là. Il était difficile pour moi d'imaginer quel genre d'expérience utile on pourrait y parvenir. J'étais assez sceptique quant au fait que j'allais m'améliorer en tant que professionnel. Mais j'ai compris que c'était une étape utile pour l'entreprise dans son ensemble.
Si nous parlons du résultat. Nous avons eu plus d'avantages commerciaux. Ils ont également aidé avec des ressources techniques et continuent d'aider. Nous avons créé une infrastructure plus correcte dans le cloud.
Le principal avantage de cette histoire est que si vous êtes prêt à utiliser les produits fournis par YC, prêt à approfondir leur compréhension, alors ce sera un gros plus.
Nous avons terminé YC en mars 2020, clôturé la ronde avec 2,5 millions de dollars. Une croissance significative de l'équipe de développement et des tâches a commencé.
- Comment êtes-vous arrivé à l'équipe produit actuelle?
Mikhail: Nos produits sont assez complexes, il faut être développeur pour comprendre un produit pour les développeurs. Vous devez comprendre du point de vue du développeur quelles fonctionnalités mettre en œuvre, comment nos clients les utilisent. D'un autre côté, cela vaut la peine d'être un bon homme d'affaires, un chercheur de marché. Combinez toutes ces compétences. Il y a quelques difficultés avec cela.
Sergey:Au cours des 4 à 5 derniers mois, de mars à août, nous avons d'abord embauché un chef de produit qui avait de l'expérience en RPA. Nous avons travaillé avec lui pendant plusieurs mois et n'avons obtenu aucun résultat. Nous n'avons pas embauché un chef de produit de la série «Nous vous embaucherons et l'or coulera immédiatement», nous voulions arriver à une compréhension claire des fonctionnalités que nous faisons, elles sont nécessaires pour capturer le marché futur, pour résoudre problèmes spécifiques aux clients, pour la vente incitative. Nous avons pris le produit pour des métriques assez mesurables et en avons discuté. Malheureusement, les deux produits roulaient. C'est aussi notre faute. Nous avons embauché des gens qui ont proposé de faire le long métrage, «parce que c'est beau». Combien d'argent apportera-t-elle? Eh bien, c'est difficile à compter ... Qui va-t-elle aider? Comment cela peut-il vous aider à gagner des trades actuels, ou du moins à ne pas les perdre? Nous n’avons pas réussi à construire une telle histoire.
Qu'est-ce que nous avons fini avec. Un programme super confortable pour nous, il anime beaucoup notre entreprise.
Nous avons un chef de produit UX, un chef de produit technologique, nous avons un chef de l'ingénierie, nous avons un CTO et nous avons un PDG en tant que représentant commercial. Nous avons formé un bureau d'épicerie où le produit est «découpé» en différentes parties. UX, analyse de nouvelles fonctionnalités, ingénierie. Mikhail et moi jouons le rôle de facilitateurs dans le cas de la priorisation. Je suis également responsable des fonctionnalités de vente. Dmitry examine comment les fonctionnalités du produit sont ou peuvent être traduites en opportunités et outils marketing tels que notre bibliothèque mondiale de robots créés par des clients et des partenaires.
Nous avons des sessions spontanées pour discuter de problèmes graves. Nous avons également un appel hebdomadaire d'une heure et demie où nous planifions le prochain sprint, qui a déjà été priorisé au sein de l'entreprise. Les nouvelles fonctionnalités arrivent sur trois pistes: bugs - nous corrigeons quelque chose qui ne fonctionne pas, ralentit la vente ou interfère avec les clients actuels; UX - nous corrigeons l'actuel, car nous savons que le produit peut toujours être amélioré; nous ajoutons quelque chose de nouveau au produit, ce qui nous permettra d'être plus efficaces à l'avenir. Nous travaillons dans un tel cadre. Nous aimerions en venir à une personne impliquée dans l'ensemble du produit, mais jusqu'à présent, il nous semble que c'est difficile.
Je voudrais conseiller aux futurs entrepreneurs, en particulier aux techniciens, de ne pas essayer d'envisager une seule option (que le PDG doit trouver un propriétaire de produit), mais qu'il existe un format d'interaction distribué qui donne un résultat.
- Est-il possible avec l'aide de votre robot de cultiver dans des jeux informatiques, des clics sur YouTube?
Dmitry: À notre base, un client a fabriqué un robot qui allume la bouilloire.
Sergey: Le robot peut appuyer sur n'importe quel bouton. Nous donnons un outil de développement. Ce sur quoi les clients s'appuient repose sur la responsabilité des personnes. Vous pouvez construire tout ce que vous voulez.
Sergey:Nous avions une histoire. Le client a acheté le service, puis a écrit: «J'ai spécifiquement choisi la fille la moins développée dans la direction informatique de notre entreprise, Olya. Et ainsi "Olya" a pu créer un robot avec l'aide d'ElectroNeek. Si "Olya" peut le faire, alors n'importe qui dans mon entreprise le peut. J'achète un produit chez vous! " C'est un indicateur élevé de facilité d'utilisation. Bien que la plupart des développeurs juniors ou intermédiaires nous utilisent. Ils reçoivent un produit, dans n'importe quelle pile (web, desktop, y a-t-il une API ou pas), créent une application (un robot?), C'est la liberté que donne notre produit.
Dmitriy:Lorsqu'un produit parvient aux investisseurs à un stade précoce, l'histoire avec Olya s'y répète, il y a Oli parmi les investisseurs. Il y a eu des situations où des partenaires des principaux fonds américains se sont lancés dans le produit (Gary Ten d'Initialized, ancien partenaire de YC et investisseur dans Coinbase et Instacart). Le partenaire a commencé à assembler le robot avec ses mains.
Bonus: collectionner un robot en direct
Lire la suite
- Lancez HN: ElectroNeek (YC W20) - Trouvez et automatisez automatiquement le travail de routine
- Comment quatre Russes ont créé une usine «d'employés numériques» et en ont gagné 1 million de dollars
- electroNeek RPA - les robots logiciels aident les gens
- À propos de la robotisation des affaires avec Farida Roslovets et le directeur de la société RPA electroNeek