Il y a quelques années, Vedomosti
a parlé d'un «messager russe protégé», qu'ils ont l'intention de mettre en œuvre dans les agences gouvernementales. Même raconter cette nouvelle en une phrase donne dans la tête le son de marteaux qui marchent lentement. Imaginez, quelque part derrière une haute clôture, avec des hérissons à l'entrée et deux sentinelles, certains des programmeurs en uniforme sont alarmés et lancés au combat au profit de la substitution des importations.
Les stéréotypes sont une chose terrible, je sais.
Le messager avec Beeline a été développé par Staply. Maintenant, ils ont quitté cette entreprise et transféré les développements vers un nouveau produit - «Mobile Enterprise». Il s'avère qu'il s'agit d'une petite équipe de télétravailleurs qui n'acceptent pas tellement le microcontrôle qu'ils vivent sans managers et même sans chefs d'équipe, travaillent quand ils veulent et où ils veulent.
Comment ils y parviennent, j'ai demandé au directeur technique de Staply Maxim Indykov (
maks_ohs ).
L'entreprise a été incluse dans le récent classement des meilleurs employeurs de My Circle IT avec une note moyenne de 4,81 pour les douze critères, parmi lesquels les employés de Staply sont les technologies modernes les mieux notées, un salaire adéquat, la croissance professionnelle, la reconnaissance des résultats de travail et la communication avec la haute direction.
Qu'est-ce que Staply
Maxim Indykov«Tout a commencé il y a environ six ans.» Je suis diplômé de l'ITMO, technologie de l'information. Il s'agit d'un méli-mélo de toutes les matières - jusqu'à l'élaboration du curriculum, l'histoire, la philosophie, les mathématiques, la physique, la programmation. Ensuite, nous avons réfléchi avec les gars aux choses intéressantes à faire. Nous avons eu plusieurs tentatives et le premier projet, qui avait un certain poids, s'appelait Cloudiverse.
Avec lui, les gars ont pris la deuxième place au hackathon Techrunch. La ligne de fond était la suivante: un fichier est pris, divisé en morceaux dans le navigateur, chaque morceau est crypté, et ces morceaux cryptés sont envoyés à différents nuages. Un morceau est dans Dropbox, un morceau est dans Google Drive et le morceau reste localement. Pour tout remonter, vous devez connaître la clé et savoir où se trouvent les pièces.
Cela a été fait dans le contexte du battage médiatique selon Snowden. Mais en fait, le projet était plus intéressant pour nous d'un point de vue technique - un travail inhabituellement important sur le client à l'époque. Mais le sujet de la sécurité s'est en quelque sorte estompé.
- Votre battage médiatique ou une sorte de conviction était-il votre motivation?- Hype n'est pas du tout - c'était juste un bon bonus. Motivé pour faire un projet intéressant. Et quand nous l'avons montré, tout le monde était intéressé. Cela semble être une idée simple, mais en même temps, elle est bien visualisée dans la tête des gens. Ici, le fichier est divisé et il ne reste qu'un jeu de caractères. Ne vous en faites pas du tout.
- Et comment êtes-vous entré dans TechCrunch?- Je viens d'envoyer une demande et tout. Pris une distribution gratuite de billets en ligne et réussi à s'inscrire. Nous essayons toujours de faire aussi simple que possible. Aucune recherche de solutions de contournement, aucun schéma délicat. Pourquoi TechCrunch? Je voulais faire de mon mieux. À cette époque, c'était un bon hackathon de battage médiatique.
Nous étions alors peu - trois personnes. Je (développeur), designer, organisateur. Il y avait encore une personne, il s'occupait des brevets.
Tout est allé assez vite. Après avoir commencé à développer un chat de service pour la correspondance, quelque chose comme Slack. Ils ont juste fait un bon messager pratique. Et juste à ce moment-là, il y avait une histoire avec la substitution des importations, quelque part dans la 14e année.
Nous avons testé le produit à Rosenergoatom et dans le gouvernement de la région de Moscou. La principale caractéristique était qu'il était installé sur des serveurs internes. Solution totalement en boîte. Il vous permet de communiquer en toute sécurité, car il n'y a tout simplement pas d'accès à Internet. Par conséquent, les grandes entreprises l'ont essayé.
Quelques nouvelles sont sorties sur ce sujet, ont-ils écrit dans Vedomosti. Nous avons nous-mêmes beaucoup écrit - sur "Habr", sur VC - et en quelque sorte c'était PR. Ils n'ont jamais acheté de publicité, ils ont juste fait des articles avec du bon matériel, des sujets intéressants. J'ai écrit sur la programmation, Dima - notre avocate - a écrit sur l'histoire juridique du projet. Ils ont partagé avec la communauté ce que nous savons.
À cette époque, nous n'avions pas de ressources importantes pour le développement et le soutien. Nous étions peu nombreux et nous avons commencé à nous développer, à chercher des gens, à constituer une équipe, à tout apprendre.
Quel type de produit fait Staply en ce moment?
Staply propose désormais trois produits: l'éditeur d'offres commerciales d'Octaplan, Emny est l'un des services de recherche d'emploi de VK. Et le produit principal est Mobile Enterprise. Les trois sont réalisés par une équipe d'une trentaine de personnes.
«Mobile Enterprise» est un service pour les petites et moyennes entreprises, qui comprend un ensemble d'outils: chat pour les employés, suivi des appels, analyse des appels, système de définition des tâches, système CRM, bloc-notes, analyse publicitaire et bien plus encore.
«Le cas d'utilisation est assez simple», explique Maxim. «Le propriétaire de l'entreprise met les chiffres dans une publicité - dans un journal, à la radio, à la télévision. Un canal séparé est attribué à chaque numéro; des appels sont effectués pour chacun. Un employé peut y analyser des applications et continue de travailler avec un client là-bas.
Il peut définir une tâche pour son équipe, par exemple, rappeler un client, signer un contrat, guider le client à travers l'entonnoir de vente, modifier ses statuts sur le tableau Kanban.
Pour ce client, les employés peuvent communiquer en groupe, dans des salles de chat, créer des discussions. Les salles de chat ont un mini-pad pour stocker des informations communes à toute l'équipe de notes. "
Comme le dit Maxim, la principale caractéristique du service est qu'il est simple, vous n'avez rien à configurer et tout est déjà prêt à l'emploi.
- Et le fait que tout le monde utilise Slack?- C'est une niche complètement différente. Bien que nous développions quelque chose de similaire, mais nous n'avons jamais rivalisé avec eux, nous ne nous sommes pas fixé un tel objectif.
- Pourquoi?- Slack est une chose pour ceux qui préfèrent toutes sortes d'intégrations, comme pour configurer quelque chose. Je ne parle pas seulement de la communauté informatique, je pense qu'elle est beaucoup utilisée où. Et «Mobile Enterprise» est un produit pour ceux qui n'aiment pas configurer quoi que ce soit, ne savent pas comment, ou ne veulent pas.
Premièrement, ce sont les petites et moyennes entreprises des régions. Les gens veulent que tout fonctionne immédiatement.
- Et avec quoi vous utilisez-vous, avec quoi communiquez-vous?- Dans ce que nous développons - dans la "Mobile Enterprise". Nous l'utilisons tous les jours pour comprendre par nous-mêmes où quels problèmes, où améliorer. Eh bien, Skype pour les appels de groupe fait partie intégrante. Serait-il plus simple ...
- J'ai lu que vous avez essayé de lancer le messager d'abord en Amérique, mais ce n'est pas le cas. Pourquoi?- Quand ce n'était que le début, nous avons essayé de travailler pour le monde entier. La localisation a pris beaucoup de pouvoir. Le produit est en constante évolution, vous devez prendre en charge deux types de textes, traduire. Sur ce marché, nous n'avions pas d'emploi à grande échelle. Ils ont avancé très simplement - avec des articles. Hacker News était probablement la principale source de trafic.
Les utilisateurs informatiques sont les premiers testeurs. Mais il n'y avait pas d'issue spécifiquement pour les affaires. Et cela n'a pas fonctionné, probablement parce que l'accent s'est fortement déplacé vers la Russie. Il est devenu clair qu'il est également intéressant ici, et il y a beaucoup à faire - pour donner aux personnes qui utilisent encore Excel ou même des blocs-notes un service simple.
Travail à distance sous responsabilité personnelle
- Comment se fait-il que vous ayez distribué à distance?- Tous ceux qui ont lancé cette entreprise vivaient à Saint-Pétersbourg. Les objectifs de faire un bureau n'ont jamais été. Mais toujours à distance aussi. Je voulais juste constituer une bonne équipe. Beaucoup de bonnes personnes en termes de programmation vivent à Ekaterinbourg, Novossibirsk, Kazan. Ils ont donc formé une équipe complètement éloignée.
Dans un premier temps, nous nous sommes fixé pour tâche d'éviter au maximum la microgestion et le contrôle. Le microcontrôle peut tuer l'environnement organique d'une entreprise. Quand tout le monde se réveille à neuf heures, s’assoit au bureau, distribue des tâches, commence à les faire, ils partent, ils ne peuvent pas partir quelque part à leur guise, reportent leur travail pour plus tard. Par conséquent, nous essayons d'éviter le contrôle, et jusqu'à présent, nous avons réussi.
- Il me semble que pour de nombreuses entreprises, cela ressemble à un cauchemar - travailler sans contrôle et sans bureau.- Nous n'avons même pas de managers et de chefs d'équipe. S'il n'y a pas de choses qui brûlent, alors une personne peut simplement le prendre, aller quelque part pour se détendre. Pas de problème si c'est prévisible. Une personne peut travailler de manière pratique.
Mais pour certains, c'est aussi difficile. Lorsqu'il y a un bureau, tout le monde organise pour vous tout votre emploi du temps et votre travail. Et ici, vous devez le faire vous-même. Ne vous recyclez pas, travaillez vous-même quand vous en avez besoin. C'est une grande responsabilité qui incombe à chaque personne. Personne n'organise ta vie pour toi.
- Comment gérez-vous?- Lorsqu'il n'y a pas de pression d'en haut, d'en bas et de côté, la responsabilité de leurs promesses, actions et paroles vient au premier plan. Maintenant, dans le cadre des systèmes de définition des tâches, toutes sortes d'indicateurs de performance clés, la responsabilité personnelle a été repoussée à l'arrière-plan.
Nous nous faisons tous confiance et savons que cette personne est ici - s'il a dit qu'il le ferait. S'il n'a pas le temps, alors il dira qu'il n'a pas le temps.
- Et s'il ne l'a pas fait?- Cela est considéré individuellement. Il n'y a pas de contrôle, mais il y a une modération du processus. Observation, prise de décision structurelle. Nous n'avons que trente personnes. Probablement, vous pouvez toujours faire face à une telle équipe.
Nous avons toujours essayé de ne pas grandir autant que possible. Il y avait des moments où il y avait plus de gens sur les projets, mais ensuite tout était flou.
- Quelles villes avez-vous distribuées?- Notre designer vit en Italie. Et puis - Peter, Moscou, Iekaterinbourg, Krasnoyarsk, Krasnodar, etc.
- Les fuseaux horaires n'interfèrent-ils pas?- Non. Nous n'avons pas besoin d'un emploi permanent de neuf à six. Il vous suffit de réaliser les choses que vous avez promises de faire, de trouver un terrain d'entente avec l'équipe et de convenir d'un moment convenable pour tout le monde.
Nous, les fondateurs, nous nous asseyons également à la maison, nous nous réunissons dans la ville. Et avec l'équipe - généralement lors de conférences. Supposons que nous nous asseyions à une conférence pendant une journée, écoutions, et que le lendemain, nous discutons déjà de choses de travail en coworking. À Moscou, probablement, «Table» est la meilleure option pour de tels rassemblements.
Il arrive qu'après avoir travaillé avec une personne pendant six mois, vous ne savez même pas à quoi elle ressemble. C'est toujours très drôle de se retrouver lors d'une conférence. Vous ressemblez à ceci: «Bonjour. C'est toi? Nous avons convenu de nous rencontrer à la fontaine! »
- Et comment vous divisez-vous en équipes?À peu près également - cinq à six personnes. Celui qui a commencé à développer le projet est un centre de connaissances - et autour de lui une équipe qui souhaite le développer en ce moment. Les projets au sein de l'entreprise sont ouverts, tout le monde peut voir ce qui se passe, aider ou aussi entrer en développement.
Les équipes sont fluides, mais tout le monde ne travaille que dans le domaine de son produit. Quand un développeur travaille sur trois projets à la fois, c'est très déprimant et épuisant. De tous côtés, ils veulent quelque chose de lui. J'ai vu dix personnes se raccrocher à des personnes d'autres entreprises et elles ont subi un terrible burn-out.
"Vous le dites, et il semble que vous ayez une totale liberté." Faites ce que vous voulez, quand vous voulez et comment vous voulez. Pas de managers, pas de pression. Mais quand j'ai lu votre page sur HeadHunter, j'ai eu une impression complètement différente. Délais, feuille de route, appels quotidiens.- La pression est produite par elle-même. Mais cela est différent du développement personnalisé. Là, le client fait des demandes, il faut faire à une telle date, et il paiera pour ce qui est fait. Ce n'est pas une forte motivation. Eh bien, il paiera l'entreprise, mais qu'est-ce qui intéresse le développeur?
Mais quand l'équipe sait qu'une annonce a été achetée à un partenaire pour les dates, elle sait que les équipes y travaillent aussi et nous attendent - motivation interne, la responsabilité apparaît. Vous ne travaillez pas déjà pour l'argent et les délais, mais vous êtes responsable de veiller à ce que les autres réussissent également.
Et il y a une pression interne qui organise les gens. L'équipe elle-même commence à proposer quoi faire, comment distribuer et comment suivre.
- Cela ne brouille-t-il pas les responsabilités? Au lieu d'écrire du code, un développeur commence à correspondre, à réfléchir aux problèmes d'organisation. Et à la fin, rien de bon ne sera fait.- De tels cas se produisent. Mais il y a un autre côté. Parfois, une personne a écrit sa partie et aide à organiser le travail à l'intérieur. C'est même cool - il est génial de comprendre ce qui est vraiment nécessaire là-bas. Après tout, avec les managers, c'est généralement: "Donnez-moi un statut, je vais y penser." Et ici, le programmeur est à l'intérieur du processus et sait où faire.
C'est la question du fait que nous n'avons vraiment pas de chefs d'équipe. Timlid apparaît lui-même en termes de compétences, et s'il reste la capacité de communiquer, de construire des relations, il devient automatiquement un leader.
- Pas de managers, pas de leads. Mais que faites-vous alors en tant que directeur technique?- La dernière fois, principalement par embauche. Les entretiens prennent beaucoup de temps, surtout si vous devez passer plusieurs tours.
Et généralement - juste une modération technique du développement, de l'observation. Je peux rapidement faire des prototypes, je sais que je peux les faire en une journée, donc je prototypes de fonctionnalités.
Pour le travail, nous utilisons le service Notion, nous y maintenons pleinement notre base de connaissances, et peignons les scènes. J'organise donc ces étapes, en discutant avec des partenaires. En général, j'essaie de ne pas garder la connaissance en moi. Lorsque vous apprenez quelque chose et le mettez rapidement dans la base de connaissances, tout devient beaucoup plus facile, surtout dans une équipe distante.
- Dans le schéma classique, lorsque le gestionnaire attend le statut et que le client de la version est un développeur, il peut se déplacer et le terminer, même s'il n'est pas satisfait de la qualité. Et dans vos conditions le perfectionnisme sans fin ne fleurit pas? Quand n'est-il toujours pas de haute qualité et qu'il n'est pas nécessaire de jeter de toute urgence?- Si le terme peut être reporté pour des raisons de qualité, il vaut mieux reporter. L'option avec un délai sans tests et contrôles conduira encore alors à l'effet inverse, à la fatigue, une grosse dette technique.
- Sur le même HeadHunter, vous avez écrit que si la date limite est fixée, vous n'avez pas besoin de la déplacer.- Eh bien, c'est un cas individuel à chaque fois. Vous pouvez déplacer le délai, l'essentiel est de tout signaler. Je peux réduire toutes nos tentatives d'organiser quelque chose à une seule chose - une personne devrait être prévisible.
Si une équipe peut prédire le comportement d'une personne, elle peut lui faire confiance. Si elle sait qu'une personne tient ses promesses et qu'il les tient vraiment - d'accord. Si une personne a un délai, et il écrit qu'il n'a pas le temps - peu importe pour quelles raisons - aussi bien. S'il écrit une heure avant la sortie, alors c'est mauvais, c'est une imprévisibilité absolue. Nous avons discuté d'une chose - en avons obtenu une autre. L'essentiel est la communication. Écrivez, informez, dites - vous pouvez toujours trouver quelque chose.
- Est-il vrai que tout le monde a des tâches pour vous?- Oui.
"La confusion ne commence-t-elle pas?"- Une fois par semaine, il y a un gros appel lorsque nous analysons et pensons que nous devrions faire le bien en une semaine. En conséquence, les tâches sont définies au sein de l'équipe. Nous discutons d'abord de la feuille de route pour le développement de produits. La discussion est plutôt globale, en général tout le monde y participe.
Par exemple, je dis: "Nous devons créer un module avec l'envoi de SMS." Et tout le monde entre en discussion - comment nous le ferons, quand, qui le fera. En conséquence, un plan élaboré dans la base de connaissances est formé, et nous essayons de le garder. Nous ne fixons pas de retenues et de délais. Nous avons plutôt un délai commun, que nous avons nous-mêmes choisi.
Autrement dit, nous sommes d'accord et essayons simplement de respecter notre propre plan.
- Tout le monde est-il responsable de tout?- Oui.
- Cela conduit souvent au fait que personne n'est responsable de rien."Bien sûr que ça pourrait l'être." Mais peu importe comment une personne fait tout, elle a sa propre spécialisation. Le développeur frontend est responsable du frontend. Ce qu'il a fait lui-même en est responsable.
Et la responsabilité collective (bien que je n'aime pas du tout ce mot) est plutôt de dire au bon moment: "Écoutez, mais vous ne le faites pas, vous faites trop de travail, c'est plus facile." La responsabilité est probablement d'aider l'autre à ne pas en faire trop.
Par conséquent, il est difficile de rechercher des personnes. Avec un tel travail à distance, une bonne communication est très importante pour que la personne soit ouverte. En effet, s'il existe une structure rigide, une hiérarchie où une personne peut se présenter comme une vis en tant que spécialiste, mais absolument sans compétences en communication, alors elle ne peut communiquer avec personne, obtenir des tâches et bien faire son travail.
Mais au travail à distance, il ne suffit pas d'être un bon spécialiste - il faut être capable de trouver des contacts, de communiquer.
Embauche créative de personnes intéressantes
"Où recrutez-vous ces personnes?"- Fondamentalement, «My Circle», légèrement plus petit que HeadHunter, est diffusé dans «Telegram» - en général, partout où il y a des programmeurs. À moins que nous n'utilisions LinkedIn.
Nous écrivons, comme nous l'appelons, des «emplois créatifs». Par exemple, ils y ont mis du texte chiffré, raconté quelques histoires. Ou des postes vacants, où il ne s'agit pas d'un texte ordinaire, mais d'un dialogue. Pourquoi écrire "nous avons besoin d'un développeur" alors que vous pouvez écrire quelque chose d'inhabituel!
C'est une façon d'essayer de trouver des personnes qui seront intéressantes avec nous.
Et il arrive que de bons spécialistes soient juste à côté. Une fois, j'ai trouvé un développeur Android pendant que nous skions sur Rosa Khutor.
- Des gens intéressants - c'est super. Mais devraient-ils passer par une filtration technique?- Nous avons essayé d'interviewer le plus rapidement possible, de filtrer très grossièrement, et déjà sur une période d'essai pour regarder comment une personne travaille. Soudain, quelqu'un ne sait tout simplement pas comment obtenir une entrevue? Cette approche n'a pas fonctionné.
Une personne est incluse dans le travail, et la compréhension est déjà floue - est-ce qu'elle l'obtient ou non. Vous ne le remarquerez pas rapidement. Par conséquent, nous testons maintenant des connaissances fondamentales. Nous ne tournons pas autour des cadres, mais demandons les bases, comment tout fonctionne, comment cela fonctionne. Le même protocole HTTP - c'est un pour tous. Ou comment les index fonctionnent dans les bases de données, comment les bases de données elles-mêmes sont organisées - pas seulement en effectuant des requêtes, mais en comprenant les processus en cours et en comprenant comment les en-têtes sont organisés.
Beaucoup de gens ne savent même pas comment les encodages courants sont organisés, pourquoi UTF-8, pourquoi «huit».
- Pensez-vous qu'il faut vraiment le savoir - pourquoi exactement le «huit»?- Je pense que c'est une compréhension fondamentale des bases, c'est vraiment important. Une personne peut être un bon spécialiste, mais elle rencontrera des problèmes qui nécessitent des connaissances de bas niveau.
Par exemple, pourquoi cette requête est-elle si lente. Une personne semblait bien écrire des requêtes SQL, mais vous devez fouiller, comprendre ce que vous pouvez changer dans la structure de la base de données, trouver pourquoi cet index particulier est si lent.
Une personne qui ne connaissait pas les fondements fondamentaux est immédiatement perdue. Cela devient très difficile pour lui. Bien sûr, ce n'est pas un tel filtre grossier qui n'a pas répondu - c'est tout à la fois. Il n'y a pas de liste de contrôle.
S'il ne sait pas une chose, mais sait dans d'autres domaines - d'accord.
- Donnez-vous une tâche de test?- Encore une fois, de différentes manières. Les tâches de test sont probablement une tentative de filtrer les personnes qui ne sont tout simplement pas intéressées. Si une personne se montre bien dans une interview, on peut dire qu'un test n'est pas nécessaire. Et parfois, il est impossible de l'évaluer lors d'une interview.
Très souvent, environ 70% de toutes les réponses avec le lancement d'un référentiel sur Github ne sont qu'une sorte de désabonnement, car il y a un vide à l'intérieur du référentiel, des projets auto-écrits d'il y a cinq ans et c'est tout. Par conséquent, un test est nécessaire pour voir comment une personne écrit du code, comment il le rédige, comment il le documente.Notre tâche de test, en particulier pour le backend, est assez générale - pour décrire une API Rest simple avec un appel à un service externe et la documenter. Pas de calculs complexes logiques - l'essentiel est de montrer comment vous pouvez créer du code.Puis un maximum de trois jours et donnez une réponse. Et pour la période d'essai, nous essayons de comprendre si tout va vraiment bien, si la personne nous a déjoué.- Et déjanté?"Oui, bien sûr." , . : « , , -, ». , : « ?» : «-, ». .
Ruby Go
— , ?— Ruby on Rails, - . , MySQL — .
Go. , . Go, , , Go .
, . Ruby- — Elixir, Go. .
— , Go?— . — , Go - . — Go . — , .
— , Go, « », .* *— , . . . , .
Go . ? , . , , .
Go .
— React . Vue, TypeScript.
«»
— , Staply Primavera. Staply «». ?— — «» . , . — , , . — , .
— , . . — , — , , . . , , .
— ?— . . — .
— , «» « »?— , . , .
— , «».— , . , , « », «», .
. — .
— , ?— . — , - . . — — , .
, . . , , , .
, . .
— — , — . 3000 — . .
. .
— ? , — .— . , , , . , — . , .
Il peut ne pas y avoir d'accélération en raison de conditions externes, il peut ne rien y avoir. Mais il doit y avoir un bon produit qui résout le vrai problème.