⛴️ 🧖🏼 👩🏿‍✈️ Démarrage au sein de l'entreprise 😭 🐒 🌊

Bonjour, je m'appelle Andrey Vanin et je développe et lance des produits de courtage et de fintech. Aujourd'hui, il y a exactement un an que je travaille chez BCS, où au sein d'une équipe de huit personnes, nous développons le projet fintarget.ru.

Vous trouverez ci-dessous une (pas) grande histoire sur la façon de mettre en œuvre une startup dans une grande entreprise, de la mettre sur le marché et en même temps de ne pas épuiser les tonnes de mémos et d'approbations.

Intro

Oubliez tous les manifestes Agile et créez un environnement de travail confortable si vous voulez obtenir des résultats. Dans la gestion de projets sans espoir, ce ne sont pas la présence du bureau PlayStation et les rituels de mêlée obligatoires qui viennent au premier plan, mais les ambitions et la motivation personnelle de l'équipe.

Si votre développeur veut être le meilleur, il ne jouera pas au air hockey et il se fiche qu'il y ait des toilettes au bureau (il y a un spoiler). Si votre projet veut atteindre le respect, il apprendra à marcher sur sa tête et à résoudre tout problème, que ce soit un autre travail inconcevable de remplacement d'une chaise cassée ou la nécessité de coordonner un processus qui n'est pas là.

Si le fournisseur frontal a une hypothèque en cours - offrez-lui le choix - soit PS4, soit plus un bonus du même montant. Votre tâche n'est pas d'être un nounou dans le projet, mais d'assurer le résultat de manière à ce que l'équipe et le client soient satisfaits. Même si ce n'est pas possible.

À vos marques

J'ai rejoint l'entreprise début avril 2019. Deux développeurs étaient assis dans le bureau, un client et un demi chef de projet qui n'avaient jamais été impliqués auparavant dans des projets de développement. Nous avons dû développer rapidement un système à partir de zéro, ce qu'ils ont essayé de faire trois ou quatre fois auparavant, mais en cinq ans, personne n'a été en mesure de mettre sur le marché un produit sain et convivial.

Sur mon bureau, il y avait une impression d'une présentation de cinq diapositives - comment tout ira bien, à quoi il ressemblera, l'architecture théorique, combien d'argent il devrait apporter et combien d'argent cela prendra. Et pas un mot sur le produit, pas une seule mention d'unités apparentées, pas un seul processus et comprendre comment tout cela devrait décoller.

Mais la date limite a été annoncée - à libérer en septembre. Et nous nous sommes assis pour travailler.

Double pivot

La première version du produit impliquait la création d'une infrastructure interne sans sa propre solution frontale. On a supposé que le produit serait présenté sur l'étagère de l'application mobile, et mes deux développeurs ne prendront en charge que le backend et la logistique des flux d'informations. Cette approche a garanti l'échec du projet dès juin, car dans la direction commerciale parallèle, l'équipe d'application a commencé à subir des changements importants et son carnet de commandes jusqu'à la fin de l'année était très brumeux. Et nous avons décidé de créer un produit MVP sur le site Web actuel de l'entreprise. Ce fut le premier virage.

La solution la plus simple dans cette situation est d'externaliser le concepteur UX et le concepteur de mise en page, de dessiner des mises en page au crayon, d'obtenir la conception et de la donner au développement. Mais seules les startups indépendantes le peuvent. Nous sommes une startup au sein d'une grande entreprise, où le designer ne peut pas payer en espèces, et tout le travail de façade doit être fait en coordination avec le marketing et les avocats. C'était plus difficile, mais cela n'a pas empêché le développement du noyau, nous nous sommes donc lancés dans le marketing.

Presque immédiatement, le problème de la stratification de l'image globale s'est posé - le marketing ne savait pas ce que nous faisions techniquement et les développeurs ne comprenaient pas à quoi tout cela aurait dû ressembler. Avant les vacances de mai, nous avons d'abord ouvert la confluence et nous nous sommes assis pour décrire les écrans.

Jusqu'à la mi-mai, une compréhension détaillée du fonctionnement du produit n'existait que dans ma tête et sur une cinquantaine de pages décrivant les algorithmes et les écrans. C'était un gros risque (l'astuce a été faite par des professionnels! Ne répétez pas - c'est dangereux!), Mais en même temps chaque membre de l'équipe savait quoi faire et était chargé de travail deux mois à l'avance.

Le projet a fumé, coordonnant la prochaine version de l'architecture et l'interaction des systèmes, le chef d'équipe est entré à l'intérieur et a commencé à choisir le code, et le troisième développeur (embauché avec moi le même jour) comprenait les mécanismes d'intégration depuis près d'un mois. Et c'était la partie la plus difficile. L'entreprise possède deux douzaines de systèmes, dont six dont nous avions besoin pour intégrer.
À un moment donné, il est devenu clair que le chef d'équipe nommé ne cadrait pas avec le rythme de l'équipe et devait être remplacé. Le deuxième développeur a pris sa place, et pour le poste vacant, nous avons pris un programmeur avec une formation de candidat en sciences physiques. Pour l'avenir, je dirai que cela nous a sauvés.

Cependant, presque immédiatement, il est devenu évident que nous ne pourrions pas non plus nous intégrer dans le circuit Web interne, et le client a convenu de la seule solution d'économie à ce moment-là - nous créons notre propre front de produits Web avec notre équipe de marque et d'assistance. À l'intérieur du département, nous avons annoncé à la hâte un concours pour le nom du produit et finalement choisi l'option qui a été exprimée par le tout premier, car il y avait un bon domaine dans ma tirelire personnelle, et il n'y avait rien de mieux pour que chacun vote et soit créatif. La marque fintarget.ru est donc apparue. Et c'était le deuxième tour clé.

À propos de l'équipe

Des millions de livres sur la gestion du développement vous donnent des modèles de travail d'équipe standard et des processus standard, oubliant que chaque équipe est unique et nécessite une approche individuelle.

De nombreux facteurs peuvent influencer le travail et la communication au sein d'une équipe: l'âge, l'état civil et même les préférences musicales. Néanmoins, presque jamais les produits n'y prêtent attention et, en règle générale, se concentrent sur des facteurs secondaires - l'emplacement et la taille de la table, les stores sur les fenêtres, les écouteurs avec ventilation et d'autres petites choses qui ne sont "pas gênantes".

Les stars se sont réunies et nous avons réussi à trouver une chaîne de relations dans laquelle chacun avait toujours quelque chose à dire à part le travail. Et lorsque vous avez établi la communication - vous pouvez calmement gérer la répartition des rôles.

Au stade du débogage des processus d'équipe, nous avons formé un schéma hybride tel qu'il ne correspond à aucun des modèles existants.

Tout d'abord , nous avons abandonné l'analyste. Absolument. Le rôle de l'analyste est réparti entre le chef d'équipe et le propriétaire du produit, et le détail des processus est modernisé et fixé lors des tests du service. C'est l'amélioration continue du produit dont les partisans d'Edge adorent parler.

Deuxièmement, nous avons effacé la frontière entre les pouvoirs du chef de produit en la personne du client et du propriétaire du produit. Deux employés jouent deux rôles en ligne, sans délimiter l'autorité et sans avoir peur de la responsabilité dans la prise de décision. Il était particulièrement intéressant de regarder les développeurs qui ont vu comment le propriétaire et le gestionnaire se disputaient la CJM ou la mise en page. Soit dit en passant, cela a grandement influencé la participation de l'équipe.

Troisièmement , au stade du développement du noyau, nous avons complètement abandonné les sprints avec un arriéré dur et utilisé une approche itérative basée sur le raffinement et l'ajout de fonctionnalités pendant le développement. Rappelez-vous comment les images jpeg ont été chargées dans le navigateur au début du siècle? C'est à peu près de la même manière que nous avons développé le cœur de produit.

Quatrième, nous avons (forcément) strictement délimité les fonctionnalités des développeurs. Un développeur de microservices distinct a été attribué à chaque secteur, qui n'était responsable que de son segment. Nous avons cinq segments de ce type dans le projet: intégration avec les systèmes internes, intégration avec les systèmes d'échange, algorithmes des produits du noyau, OpenAPI et front.

Et cinquièmement , toutes les ressources du chef de projet de notre département étaient uniquement destinées à gérer des équipes externes chargées de finaliser les systèmes avec lesquels nous devions nous intégrer, et de mettre en œuvre toutes les procédures de coordination et d'intégration d'une startup dans l'infrastructure de l'entreprise.

Pendant trois mois, ce héros du projet a passé plus de cent et demi services différents, décrit et documenté une douzaine de nouveaux processus, et c'est lui qui a réfuté en pratique la théorie populaire de l'impossibilité de créer des startups au sein de grandes entreprises.

Cette approche nous a permis de planifier le pool de tâches, de fixer toutes les exigences pour MVP, et dans son ensemble, quand il est devenu clair que le mécanisme fonctionnait, moi, en tant qu'oouner, je suis parti en vacances presque calmement. C'était en juillet, et comme il est écrit dans un célèbre roman de gestion de projet, lorsque tous les processus sont définis, les tâches et les délais sont connus, il suffit de regarder.

Le premier août, nous avons fait assembler le noyau du système, presque tout le travail préparatoire a été fait, la version bêta d'OpenAPI a été assemblée, le front a été dessiné et composé et il restait encore une semaine pour peaufiner les algorithmes et attendre que le front-end fonctionne, qui était «juste» pour tout collecter tout Ceci est un MVP qui fonctionne.

Arbres d'événements

Il est possible de collecter l'infrastructure de projet de démarrage dans une boucle de test fermée autant que vous le souhaitez, mais le projet ne décollera jamais sans intégration avec les systèmes clés de l'entreprise. C'est le principal problème de travail des startups au sein des entreprises: plus de 80% des projets meurent sans trouver l'occasion de s'intégrer et de se conformer à toutes les exigences et réglementations de l'entreprise.

Il existe plusieurs de ces systèmes dans le domaine du courtage: systèmes de négociation et de comptabilité, bus d'intégration, CRM, un catalogue de services et une douzaine d'autres systèmes et mécanismes qui sont très strictement réglementés et contrôlés par les services de sécurité de l'information.
L'intégration sans exagération a été le test le plus sérieux pour le projet et l'équipe, et nous avons dû tuer un total d'environ trois hommes-mois de travail dessus.

Un rôle clé dans ce processus a été joué par la règle «tout d'abord briser toutes les règles». Nous avons initié plusieurs scénarios d'intégration parallèle à la fois - du plus officiel (via le passeport du projet, la coordination de l'architecture, la création d'un circuit de test et le transfert de toutes les instructions pour la politique de publication et le support) au plus officieux - nous développons dans le circuit de combat, fermé de l'extérieur et testons le système par nous-mêmes comptes de courtage.

Les détails de cette histoire méritent un article séparé, mais la clé qui a été obtenue consiste en plusieurs points:

. « – – crm– – – – », , ,
- « - », « » .
L'approche de test «préprod» a considérablement accru l'implication des développeurs, a permis de tester l'UX dans la pratique avant de lancer le produit dans le monde extérieur et, surtout pour le projet, de déboguer le bon fonctionnement des algorithmes du système sur les données réelles du marché et des clients.

Et surtout - ne considérez jamais le temps perdu sur des processus parallèles lors de l'intégration. Comme dans les budgets publicitaires, vous ne savez toujours pas quelle moitié du budget vous avez dépensé en vain. Construisez simplement un arbre d'options et démarrez les processus: certaines branches disparaîtront d'elles-mêmes comme désespérées, certaines fusionneront en une seule et lorsque l'une d'entre elles vous mènera au résultat, ce ne sera que votre chemin de champion. Parce que dans un autre projet, le même scénario peut ne pas fonctionner.

Quel est le résultat

Le MVP de travail du projet a été assemblé fin août, en parallèle, une version de l'émulateur d'accréditation du programme à la NAUFOR a été mise en place et cent cinquante pages de pièces justificatives pour l'enregistrement du logiciel ont été écrites. Les premières transactions réelles sur le système aux cris joyeux de l'équipe ont eu lieu le 31 août. Les modifications légales apportées aux documents de l'entreprise et aux réglementations des clients sont entrées en vigueur le 1er septembre et avant que le système ne soit accrédité, nous avons eu le temps de déboguer et de lécher les interfaces.

Dans MVP, nous n'avions ni comptes en devises, ni contrats à terme, ni même notre propre compte de courtage, mais la tâche clé était terminée - l'infrastructure a été mise en œuvre, le préprod est devenu une prod, le service aux clients a été mis en œuvre.

Le 17 septembre, le logiciel Fintarget a été ajouté au registre des programmes de suivi automatique accrédités et le lendemain, nous avons vu les premiers clients se connecter au système. Il y avait encore beaucoup de travail pour étendre les fonctionnalités et amener le MVP à l'état de produit à part entière et autosuffisant, mais c'est une histoire complètement différente et moins intéressante: versions, sprints, backlogs et analyses client sans fin.