Voir un langage de programmation nouveau et jusqu'ici peu connu dans un petit projet de démarrage ou d'animal de compagnie avec des amis est monnaie courante. Vous allez demander pourquoi ils l'ont pris, ils vous diront que vous venez de l'apprendre par curiosité, que vous avez aimé et que vous avez décidé d'expérimenter, parce que vous en avez assez de l'éternel Java / .Net / JS au travail.
Mais si une entreprise parle d'elle-même dans des expressions telles que «commerce international», «bureaux dans le monde», «culte de la productivité», «le résultat est important pour nous, pas le processus», «nous avons besoin d'yeux brûlants et du désir de se développer» - généralement, ils n'ont pas en attente de surprises. Certains mettent même des listes d'arrêt sur les nouvelles technologies jusqu'à ce qu'elles prennent du poids dans l'industrie. Aux questions sur les inconvénients des outils, dites évasivement: "l'essentiel, ce sont les gens, pas les langues".
Wrike, avec environ 400 développeurs, a une approche différente. Ils n'ont pas fermé les yeux sur les lacunes de JavaScript et n'ont même pas choisi un compromis, tel que Flow ou TypeScript - mais sont allés de manière complètement radicale. Ils ont réécrit le front dans une langue que mille personnes à peine connaissaient alors, et, semble-t-il, ont encore une confiance absolue en eux.
Wrike a pris une troisième place honorable parmi les moyennes entreprises dans le classement des meilleurs employeurs de My Circle IT avec une note moyenne de 4,82. Les principales qualités les plus appréciées de l'entreprise sont: le paquet social, les conditions de travail confortables, les relations avec les collègues, un salaire adéquat et la croissance professionnelle.
- Wrike a été fondée par Andrey Filev en 2007 à Saint-Pétersbourg. Puis il a commencé à développer des affaires en Amérique, dans la Silicon Valley. C'était alors une entreprise complètement différente, et maintenant nous avons beaucoup grandi.
Au début, Andrey avait une entreprise d'externalisation. Ils ont commencé à chercher des logiciels qui lui permettraient de travailler plus efficacement - pour gérer le temps et les ressources. Il n'y avait pas d'outil vraiment cool à l'époque, et l'idée est venue de créer le vôtre. Puis Wrike est né.
Nous avons commencé avec des choses simples, mais progressivement le produit a commencé à croître. C'était il y a 12 ans, et nous pouvons dire que nous avons participé à la formation d'un marché pour de tels systèmes de gestion du travail. Wrike est désormais utilisé par plus de 18 000 entreprises dans le monde.
- Cette société d'externalisation existe-t-elle toujours?Oui, ça s'appelle Murano Software. Mais elle n'a rien à voir avec nous. Wrike est une entreprise à produit unique à part entière, qui était une expérience dans le cadre d'une entreprise d'externalisation, mais qui a explosé et s'est séparée très rapidement.
"L'utilisent-ils toujours là-bas?"Oui encore.
Qu'est-ce que Wrike
Wrike est une plate-forme de gestion de projet et de collaboration au sens très large: d'une liste de tâches personnelle à un système adapté aux grandes entreprises.
À l'intérieur, vous pouvez créer des projets avec de nombreuses tâches et sous-tâches, configurer des rapports pour la collecte de données, afficher des diagrammes de Gantt, suivre les tâches dans le calendrier et les modifier simultanément avec d'autres participants. Les modules complémentaires Wrike vous aident à gérer votre charge de travail en temps réel ou à exécuter des campagnes marketing multicanaux complexes. Il existe une API pour l'intégration dans d'autres outils. Il existe des extensions, par exemple, pour Adobe Creative Cloud. Il vous permet de visualiser et de commenter les fichiers sans quitter le système.
Wrike ne cherche pas à se concentrer sur une fonction, une industrie ou une profession particulière. Il se positionne comme un outil universel pour tout - jusqu'au remplacement du système de messagerie, du messager, de la base de connaissances, du traqueur de bogues et bien plus encore.
- La défocalisation sur tout le monde et pour tout n'aggrave pas les parties individuelles?- Nous n'entrons pas délibérément dans des niches à profil étroit. Par exemple, nous ne voulons pas faire exclusivement des systèmes de suivi des bogues pour des développeurs comme Jira. Nous ne voulons pas créer de logiciels uniquement pour les programmeurs ou uniquement pour les concepteurs. Nous voulons créer un produit universel. Dans le même temps, nous comprenons qu'il existe des cas hautement spécialisés que nous ne couvrons pas.
Mais ce n'est pas notre objectif: plaire à tout le monde ou occuper pleinement le créneau informatique. Bien que nous, en développant Wrike, nous l'utilisions comme un système pour les tâches et un traqueur de bogues.
- Autrement dit, vous pouvez prendre le traqueur de bogues plus rapidement, le messager est plus rapide, mais ce seront cinq outils différents et il sera difficile de synchroniser entre eux.
- Mais alors vous devez rivaliser avec tout le monde. Atlassian d'une part. Slack en tant que messager - de l'autre.- Oui, maintenant seuls les paresseux ne développent pas de systèmes de gestion de projets et de produits.
- Mais en fait, il n'y a pas tellement d'entreprises qui seraient en concurrence avec nous sur tous les plans.
- Atlassian n'est-il pas comme ça?- Il est plus concentré sur le marché informatique. Par exemple, pour les designers, Jira est trop compliqué.
C'est très difficile à personnaliser. Il y a même une profession - Jira Setup Manager. Nous essayons de nous assurer que vous allez sur le site, prenez un compte gratuit et c'est tout - dès le premier jour, vous pouvez l'utiliser sans problème.
- Mais vous dites que vous travaillez également en étroite collaboration avec les clients et les directeurs directs qui établissent les processus.Oui, nous avons une équipe de responsables de la réussite et du déploiement client, ainsi qu'un système complet de visites, guides, livres électroniques et toutes sortes de documentation. Il existe des gestionnaires qui vous aideront à configurer Wrike pour des processus prêts à l'emploi. Parfois, ils travaillent avec de gros clients individuels. Parfois immédiatement avec beaucoup (par exemple, l'enregistrement de webinaires). Même si une personne a enregistré un essai et n'a pas compris le produit, elle aura la possibilité de discuter en direct avec l'un des coureurs et de comprendre comment cela fonctionne.
- En général, l'
introduction d'un produit dans une entreprise comptant des milliers d'utilisateurs est une autre tâche.
- Il est arrivé que c'était très difficile avec l'un des gros clients?Habituellement, plus l'entreprise est grande, plus elle a de processus de travail - plus il est difficile de travailler. Bien entendu, nous ne sous-traitons pas. Il n'y a rien de tel qu'une sorte de sacs d'argent vienne et dit: "voici beaucoup d'argent pour vous, faites-moi une telle chose." Nos chefs de produits déterminent eux-mêmes les voies de développement des produits. Mais il y a des clients avec des demandes intéressantes.
Airbnb, par exemple, utilise la plateforme dans des cas très inhabituels. Chaque appartement et chaque personne qui le loue est un projet distinct à Wrike.
Ou le constructeur automobile Coil [nom changé]. Les clients leur commandent des pièces de rechange. Donner à ces gens des comptes Wrike n'est qu'une idée. Vous ne serez pas chaque propriétaire de Coil à faire votre compte. Mais l'entreprise voulait vraiment une opportunité pratique de travailler avec les clients.
Bien sûr, nous n'avons pas dit que pour le moment nous ferions une telle fonctionnalité pour eux. Mais les managers ont réalisé qu'elle améliorerait le produit dans son ensemble. C'est ainsi que les «formulaires de demande externes» sont apparus pour les personnes qui n'ont pas de compte Wrike.
- Il s'est avéré que vous avez fait pour Coil [nom changé], mais est-ce que cela convenait à tout le monde?"Pas vraiment." Nous avons simultanément analysé le marché et émis l'hypothèse - cette tâche résidait dans une feuille de route potentielle. S'il y avait une demande qui ne nous convenait pas du tout, nous ne le ferions pas.
La structure interne de Wrike
Nous travaillons sur Scrum. L'entreprise est divisée en équipes par fonctionnalités - environ 10 personnes chacune. Ils sont de composition différente, mais chacun a un backend, frontend, scrum-master, QA, QA automation, UX-designer, product obouner, product analyst (les analystes viennent parfois en plusieurs équipes). Une telle composition est entièrement fonctionnelle et peut faire une caractéristique de et vers.
Il existe des équipes internes qui créent des cadres, des composants, des kits de conception et sont engagées dans la transition d'une version d'un langage de programmation à une autre.
Certaines équipes sont communes à l'ensemble de l'entreprise. Par exemple, ce sont SysOps, qui sont engagés dans l'infrastructure de serveur, et DevOps - ils sont engagés dans le déploiement et la livraison de produits. Nous publions une à trois fois par jour.
Nous utilisons également partiellement la structure bien connue de Spotify avec les guildes. Par exemple, le frontend, où le front-end se compose de toutes les équipes. Il existe des leads front-end qui traitent de la gestion et de l'architecture. Et il y a des chefs de guilde.
Nous n'avons pas encore atteint le point de les isoler des équipes. Mais en général, c'est logique et organique. Désormais, les personnes possédant des compétences techniques élevées en architecture font partie des équipes d'infrastructure.
Wrike n'est pas vraiment une structure bureaucratique. Mais cela ne signifie pas que le chaos se produit dans notre pays. Si une personne fait ce qu'elle aime et le fait bien, elle aura des opportunités de croissance, quelle que soit la position qu'elle occupe.
- Et dans quel bureau ce qui se fait?- À Saint-Pétersbourg et à Voronezh, bureaux d'ingénierie. Nous avons 400 personnes à Saint-Pétersbourg et 40 à Voronej. Il y a des bureaux à San Jose, San Diego. Un bureau à Prague ouvrira cette année. Bureau récemment agrandi à Dublin. En janvier de cette année, un bureau a été ouvert à Melbourne, en Australie.
- Dans les bureaux américains, nous avons un service commercial, marketing, managers (CSM). Dublin a également CSM et des ventes. Il y a aussi une équipe d'analystes. À Saint-Pétersbourg - le bureau le plus grand et rassembleur. Nous avons ici des responsables du service client, des chefs de produit, des analystes, des designers, du développement et du back office.
- Est-ce que tout le monde travaille dans des bureaux ou êtes-vous ouvert à un endroit éloigné?- Les commandes Scrum à distance sont très difficiles. Nous voulons que les gens soient proches et en contact les uns avec les autres. Dans les départements qui peuvent impliquer un travail à distance (par exemple, le support client), nous ne limitons pas beaucoup les gars.
- Udalenka en développement - un point discutable. Maintenant, on en parle beaucoup, sur Twitter en anglais, nous discutons constamment de ce sujet. Il y a des avantages et des inconvénients. À notre avis, il y a plus de «contre». En tant que chef d'équipe, il serait difficile pour moi d'assurer la productivité et un esprit commun, de grandir et de coacher les collaborateurs distants.
Nous avons un horaire assez flexible, les gens ne s'assoient pas strictement au bureau de dix à six heures. S'il y a un stand-up, soyez gentil - venez, et quand il passera et combien de temps cela prendra, les équipes choisiront par elles-mêmes. Si quelque chose se passe, également sans problème - la personne écrit qu'elle travaille à domicile.
- Lorsque le produit est international, les développeurs sont souvent tenus d'avoir une bonne connaissance de l'anglais pour parler avec les clients.- Nous n'avons pas de clients, nous ne sommes pas des sous-traitants. L'entreprise est internationale, et une partie des communications se fait en effet en anglais, mais cela ne s'applique pas à tout le monde. Pour les développeurs en Russie, nous n'avons pas d'exigence particulière de connaître l'anglais.
Une fois par mois, il y a des réunions où nous parlons de tous les changements dans l'entreprise et la performance financière. La communication avec le support se fait en anglais. Les billets avec des bugs clients sont également, bien sûr, en anglais. Pour ceux qui veulent resserrer ou apprendre une langue, il y a une telle opportunité - nous avons des cours continus avec des enseignants, pour les employés, ils sont gratuits.
Mais mon avis est que si un développeur n'a pas commencé à développer hier, il connaît l'anglais au moins au niveau de la lecture de la documentation. Sans langue, vous ne pouvez même rien google.
Bien sûr, les développeurs peuvent ne pas avoir un véritable accent britannique et il n'y a pas d'Oxford derrière eux, mais ils peuvent généralement parler et lire quelque chose.
Pourquoi Dart est meilleur que JavaScript et TypeScript
- Maintenant, tout cela est un grand système complexe. Mais il est né du développement interne il y a très longtemps et a beaucoup changé depuis lors. Pour cette raison, il n'y a pas eu de mauvais calculs architecturaux qui interfèrent maintenant avec la vie?- Bien sûr, le projet est grand. Nous avons sur le backend soit un an et demi, soit deux millions de lignes de code Java. L'avant est également comparable. Mais je ne connais pas une seule personne qui puisse concevoir le système cinq ans à l'avance, et il se développera sans reconstruction.
Il arrive que quelque chose tombe. Parfois, nous nous rendons compte qu'il y a deux ans, c'était stupide. Mais cela est naturel du point de vue de l'ingénieur. Sinon, comment?
- Par conséquent, il existe des équipes internes qui réécrivent périodiquement les anciennes pièces.
- Oui, je dis parfois que nous devons nous asseoir et refactoriser, sinon ça va tirer pour que tout soit tiré. Nous nous asseyons et refactorisons. L'architecture interfère - nous faisons de l'architecture.
- Quelle est votre pile?- Sur le backend Java. Base de données SQL. À l'avant, une chose intéressante. Il était une fois, nous avions JavaScript, mais nous avons réalisé qu'il ne se modifiait pas du tout et avons choisi Dart.
- Qu'as-tu choisi ??- Dart. Oui, c'est une réaction normale. Une langue dactylographiée de Google, qui a maintenant près de sept ans. Nous sommes probablement les évangélistes les plus importants de cette pile en Russie.
- Les plus importants ou les seuls?- Au fait, maintenant, il se développe activement. Google a lancé Flutter - c'est un tel framework mobile écrit uniquement sur Dart. Il y a une
communauté russe de fléchettes que nous avons créée et que nous soutenons. Il y a déjà environ un millier et demi de personnes. Bien sûr, selon les normes de JavaScript, ce n'est pas très impressionnant, mais aussi beaucoup.
En décembre dernier, nous avons organisé
la conférence DartUp - il y avait une immense salle et beaucoup de gens sont venus. Et beaucoup utilisent Dart en production. La langue se développe progressivement et c'est très cool.
"Nous sommes donc à cheval maintenant." Dire «dans le monde» est probablement prétentieux, mais, en fait, il l'est. DartUp est la plus grande conférence Dart au monde. Encore plus que Google.
- Il y avait environ trois cents personnes à la conférence. Il y a deux ans, il semblait que nous étions seuls dans le domaine des guerriers.
- Tout cela est intéressant, mais comment travailler sur un projet d'une telle envergure, si vous n'embauchez pas de personnes, il n'y a pas de bibliothèques ou de frameworks.- C'est une erreur. Récemment, nous avons embauché dans l'équipe un homme pour qui Dart était généralement le premier langage de programmation.
- A Dart, tout est là. Il s'agit d'un langage de la catégorie C # et Java - tout ce dont vous avez besoin y est intégré. Et ce n'est généralement pas vrai que tout y est vide et que la culbute roule. Il y en a encore plus que dans certaines langues de vingt ans. Bibliothèques, outils, support de framework - Angular est là aussi.
Bien sûr, il n'y a pas d'infrastructure comme sur JS. Mais le problème est que lorsque les gens écrivent des millions de bibliothèques, ils obtiennent des millions de mauvaises bibliothèques. Et peut-être seulement une centaine normale.
Et si les bibliothèques sont écrites par Google, qui utilise Dart dans AdWords et AdSense, la qualité moyenne est beaucoup plus élevée.
La beauté du langage est qu'il est simple et en C. Autrement dit, nous embauchons des développeurs en C ++, C #, Java, JavaScript - n'importe qui. Nous n'avons pas besoin de connaître Dart. Naturellement, il n'y a pas de développeur de fléchettes dans la rue.
Mon équipe a un développeur avec l'expérience de C Sharp, qui sait Au front, il n'a même jamais écrit. Et en cinq jours, il a lavé un long métrage. Parce que la langue est comme si vous y avez écrit toute votre vie.
Dans le bon sens, les ingénieurs de développement écrivent la logique métier, quelle que soit la langue.
"Mais les gens ne commencent pas à écrire dans leur ancienne langue?" Les mêmes surnoms JS sont passés d'un langage dynamique à un langage statique.- Par conséquent, notre processus de sélection n'est pas le plus simple. Mais juste et honnête.
- D'accord, pourquoi la langue est-elle bonne?Je dirais que c'est l'un des plus fortement typés qui compile en JS. Lorsque nous nous sommes assis sur le front il y a quatre ans et que nous étions environ 8 - vous pouvez au moins vous couvrir de toutes sortes de linters, de règles, de tout dans le monde - mais il manquera encore quelque chose. Nous avions besoin d'un typage statique, aussi strict que possible.
Sur Dart, si vous écrivez quelque chose de mal, vous le comprendrez immédiatement. Il a une détection d'erreur antérieure, ce qui permet même sans tester le code de comprendre s'il fonctionne ou non.
Il n'y a pas de chaos dans la bibliothèque intégrée lorsque l'un est mis à jour et que l'autre tombe. Parce que le SDK est fourni avec la langue, ce qui garantit que tout fonctionne après la mise à niveau. Vous n'avez pas besoin de connecter un million de bibliothèques pour obtenir des flux et des flux - tout est déjà là.
Maintenant, dans le monde, il existe deux langues qui vous permettent d'écrire pour toutes les plates-formes - pour mobile, pour backend, pour ordinateur de bureau, pour le web. C'est JS et Dart. JS par contre sait combien. Et Dart a un énorme avantage en tapant.
Par conséquent, il n'y a qu'une seule langue typée en dur qui vous permet d'écrire pour toutes les plateformes avec un réglage normal. Beaucoup citent Kotlin comme exemple, mais pour le web ce n’est pas très.
- Maintenant, vous ne regrettez pas que, par exemple, TypeScript n'ait pas été choisi?- Pas maintenant, mais en principe nous ne regrettons pas. Je vous conseille de voir le rapport de Victor Logov de JetBrains à la conférence HolyJS [
L'orateur a probablement confondu le nom, et c'était un rapport d'Anton Lobov ].
Ils prennent en charge TypeScript dans leurs produits, et cela place simplement TS sur les étagères, raisonnablement. Et après cela, il n'y a aucun désir de le prendre. On a le sentiment que des fonctionnalités y apparaissent selon le principe «Ajoutons ça? Allez.
- Pour que je crois, dites-moi ce qui est mauvais à Dart? Il se peut que tout ne soit pas parfait.Facilement. Il y a des problèmes, mais pas avec la langue, mais avec Google. Ils utilisent beaucoup d'outils à l'intérieur, qui ne fouillent pas. Nous avons maintenant un canal direct avec Google, nous faisons partie d'un certain nombre d'organisations internes, et ils distribuent lentement ces outils.
Mais ceci n'est pertinent que pour nous, pour une très grande base de code. Les petits projets n'ont aucun problème.
- Après l'expérience avec Dart, vous ne vouliez pas remplacer Java par Go?- Pourquoi? Nous avons sélectionné Dart en fonction de certains paramètres. C'était une décision équilibrée.
- Un de nos conférenciers dit qu'il y a des entreprises qui réécrivent tout avec les nouvelles technologies et il y a des entreprises qui font de l'argent. La réécriture ne doit pas être une fin en soi. Il existe des tâches commerciales et des outils devraient les mettre en œuvre.
- Nous expérimentons différentes technologies. Si à un moment donné, nous comprenons que Go fonctionne mieux, nous essaierons.
À l'avant, nous nous dirigeons vers des applications indépendantes. Il y a un monorepositaire sur le backend. Il y a de nombreux avantages à cela, mais il y a aussi certains inconvénients - vous pouvez en parler longtemps. Nous envisageons une architecture de microservices basée sur ce qui sera utile dans notre environnement.
L'architecture de microservice fonctionne bien là où il y a peu de connexions. Si vous avez beaucoup de connexions, les microservices se transforment en douleur. Il n'y a pas de solution miracle. Pour ce faire, nous avons toute une équipe qui explore ce qui est le mieux utilisé dans notre environnement.
Embaucher des ingénieurs, pas des experts linguistiques
- De quoi avez-vous besoin pour vous rejoindre?- Nous prenons des gens intéressés par ce qu'ils font. Ceci est un cliché - sur les yeux brûlants. Mais c'est important. Même si vous êtes un bon développeur, mais peu vous importe quoi couper, ne serait-ce que pour travailler de dix à six et recevoir de l'argent - avec une forte probabilité, cela ne nous conviendra pas.
- Nous prenons des gens qui veulent apprendre, se développer. Si vous pensez que tout a déjà été accompli et que maintenant le roi du monde n'est pas non plus notre option.
- Étant donné que nous avons un assez bon canal de rétroaction du développeur aux entreprises et vice versa, l'approche «ici, travail» n'est pas très appropriée. Nous essayons d'embaucher des gens qui sont prêts à offrir leur vision, ils ont des opinions et des questions.
Cela fait avancer le projet beaucoup plus rapidement que si vous embauchez trois super-seniors qui disent "mon temps de travail est écoulé et généralement vous ne me payez pas assez". Ils feront moins que la personne qui coupe le projet en une journée au hackathon, le met en production.
- Nous recherchons des personnes qui se soucient, qui sont intéressées à aller de l'avant.
- Alors je suis venu vers toi, j'ai dit que je suis tellement déterminé, j'ai beaucoup d'opinion, mes yeux sont en feu. Je les ai toujours fourrés avec quelque chose pour briller, dis-je, prends-moi. Alors prends-le?- Les entretiens ne sont pas si simples. Nous créons des conditions proches des processus de travail et observons comment une personne se montre. Si vous êtes développeur, vous écrirez du code. Si eychar - vous allez interviewer.
- Le développeur va-t-il écrire le code lors de l'entretien?— , , .
, , . , , , , .
: « React-», — . React, ?
, . . , JS. : « Jira Wrike. ?»
, — Go, . , . , , .
— , , « », ?— . , . . , , . — . . , .
, , . , , ? . , … — , « ».
— . ?— .
Wrike , , . , . , , , .
— ?— . Gantt-. Canvas, . , , Google — , Dart . , .
— , - , ?— . . , -. Wrike, . , - , .
— ? , 400 . ?— . — . , . Cultural fit, , .
— . , ?— -5 . — . , . , , ? , .
— , , ?— , - . , , , .
— , , . . . . , , — .
— , ?- Non. . - .
— , ?— . , . , , , . .
— . Wrike — safe place. Google , — . , .
, , — .
— , ?- Critiquer n'est pas tout à fait le bon mot. Assurez-vous d'avoir besoin de commentaires. Nous ne sommes pas ici pour rechercher les coupables - nous sommes ici pour faire le travail efficacement.