Dans chacune de nos six équipes de développement, le backlog est prévu pour environ deux ans à venir, en tenant compte du refactoring presque inévitable, des correctifs, des fonctionnalités et des productologues de Wishlist. À l'intérieur, tout peut aller selon les priorités, et certains gros blocs deviennent plus importants, puis ils sont supprimés, puis quelque chose de nouveau y est ajouté. Mais il est toujours possible de savoir où creuser dans les mois à venir.
En plus d'un tas d'avantages, un tel système présente deux inconvénients évidents:
- C'est ennuyeux et l'ennui n'est pas ce qui nous motive à écrire du code.
- De nombreuses hypothèses s'accumulent qui, selon le processus habituel, se situent quelque part à la fin de l'arriéré, mais chacune d'elles peut donner un résultat rapide. Ou peut-être pas. Certains d'entre eux sont intéressants.
En mode normal, il est difficile d'analyser ces hypothèses, car vous avez besoin de l'interaction d'un scientifique du produit, d'un homme d'affaires (généralement un responsable de ligne) et de quelques autres personnes d'autres équipes de développement. Autrement dit, lorsque vous avez deux heures gratuites, vous ne pouvez toujours pas le faire. Et comme nous gagnons souvent de l'argent en piétinant le chemin de l'entreprise vers de nouvelles interfaces et de nouvelles fonctionnalités, les tests d'hypothèses sont la vie.
Tout d'abord, nous avons réservé du temps à l'intérieur du bureau et avons effectué le flux de travail global. Il s'est avéré que si vous vérifiez le plus rapidement possible, vous obtenez des solutions moyennes. Pour améliorer la qualité, vous devez sortir de la routine générale.
Par conséquent, nous avons déjà voyagé trois fois dans une ville étrangère et y avons travaillé.
Pourquoi est-ce nécessaire?
Si vous avez déjà lu des articles sur la façon dont nous accumulons
la dette technique et ce que nous en faisons, et sur ce que le
développeur doit savoir
sur les affaires , alors vous savez que de temps en temps nous avons des dizaines d'hypothèses sur ce que à faire. Environ la moitié proviennent de développeurs, en partie d'histoires d'autres départements et de l'expérience de transfert à soi-même, en partie d'un scientifique du produit, fondateur, ou tout simplement en raison de la phase de la lune.
Ensuite, nous déterminons la liste des personnes nécessaires pour résoudre la plupart de ces tâches. En règle générale, il s'agit d'une équipe de développement spécifique (directions de l'air, des chemins de fer, des visites, des trains, des aventures ou des analyses), un ingénieur en infrastructure, quelques personnes d'une entreprise (pour une image générale et une évaluation de la cohérence financière), un analyste pour le transfert aller-retour, des personnes d'autres équipes .
Le processus de base ressemblait à ceci: prendre un spécialiste du marketing, des développeurs, un concepteur, des analystes et un leader. Au bureau, une fois par semaine, nous organisons une discussion sur le sprint des hypothèses. Une journée est allouée lorsque le travail n'est effectué que sur des hypothèses. Si la solution d'un problème part dans six heures, elle est interrompue et quitte ce processus. La tâche consiste à lancer la bêta oblique dans six heures. Dix hypothèses par semaine sont testées pour toutes les équipes.
Cela fonctionne bien, mais les limitations que vous avez vues ci-dessus.
Le développement à part entière prend ce que le chef de projet est satisfait en fonction des résultats bêta.
Nous avons consulté le gourou de la gestion de projet, et plusieurs personnes différentes ont déclaré à la fois que des forces spéciales devraient être mises en place au sein de l'entreprise, c'est-à-dire celles qui sont spécifiquement impliquées dans le dévissage d'hypothèses rapides. Quelque part, cela s'appelle un groupe de développement, ailleurs. Le point est un hackathon permanent pour une équipe.
Cela semble logique, mais pas rapidement mis en œuvre: il faut réunir des experts dans six domaines différents de l'entreprise et priver les équipes principales des plus intéressantes, car tous les raisins secs du chignon sont cueillis par ces "forces spéciales".
Des "forces spéciales" sont nécessaires parce que si 100% du temps du développeur n'est pas alloué pour résoudre le problème, cela se révèle pire. A en juger par l'expérience. Mais nous ne pouvions pas faire ça.
Nous avons pris TRIZ et suggéré que nous devions nous concentrer une partie du temps sur les hypothèses, à temps partiel sur le travail principal «à long terme». Qu'est-ce qui nous empêche de faire cela, comme nous l'avons fait au bureau? Contexte, distractions et réglementations constantes, emploi constant des membres de l'équipe et longue rétroaction.
C'est ainsi que les gens ont créé des hackathons. Ils suppriment toutes les restrictions de bureau et donnent le temps de se concentrer. Seul un hackathon est une histoire volontaire gratuite, et il s'agit généralement d'une formation. Les développeurs passent leur samedi, car ils peuvent apprendre quelque chose de nouveau et pas mieux faire leur travail.
Par conséquent, nous avons décidé de mener une expérience et d'aller à Istanbul avec une équipe de 14 personnes.
Expérience d'Istanbul
Pourquoi Istanbul? Nous avions besoin d'une ville qui réponde aux besoins alimentaires:
- Obtenez un vol rapidement sans retards fréquents (l'autre côté de la planète ne convient pas, les îles aux conditions météorologiques imprévisibles ne conviennent pas).
- L'accès est relativement peu coûteux (l'Islande ne convient généralement pas).
- La ville est plus attrayante que Moscou à cette époque de l'année (tout le monde n'aime pas sortir du bureau pour voyager, Omsk ne convient pas, mais les habitants de cette ville me pardonneront).
- Il y a beaucoup de choses intéressantes pour lesquelles vous n'avez pas à voyager loin (la Norvège ne convient pas).
- L'équipe veut unanimement se rendre dans cette ville.
Nous avons dressé une liste des villes appropriées et discuté avec tout le monde. Il était important que tout soit vérifié en même temps, et ce n'était pas un devoir terrible.
Nous avons décidé que nous aurions une grande réunion à Istanbul en échange de deux jours de congé (payé), mais nous achetons nous-mêmes nos billets. Cette logique convenait à tout le monde, car c'est l'occasion d'accoupler ces deux jours de congé le week-end et de faire des mini-vacances en milieu d'année.
Et bien, au final, nous sommes toujours des passionnés de voyages.
Ils ont loué sur place une grande maison près du centre.
Qui l'a fait? L'un des développeurs a passé son temps personnel à organiser tout cela. Je ne sais pas si c'était parce qu'il voulait étudier le processus des voyages d'affaires (nous venons de le promouvoir), ou simplement parce qu'il voulait aider tout le monde.
Pendant une semaine, ils ont averti la
cuisine que nous avions besoin de collations sur la route, mais la charge de nourriture diminuerait dans les prochains jours.
Nous avons travaillé le vendredi matin, comme d'habitude, à 12h30 nous sommes allés à l'aéroport, vers 15 heures - départ, à 18 heures nous y étions.
Nous sommes arrivés à la maison, il y avait déjà du Wi-Fi déployé là-bas, j'avais des documents imprimés avec moi. Le tout avec des ordinateurs portables d'entreprise. Nous avons mangé, assis et discuté des principales choses. En fait, c'était un débat sur quoi et comment faire dans le produit. Autrement dit, nous avons décidé de ce qui devrait entrer dans l'arriéré. Je voulais discuter des hypothèses «rapides», du destin et des priorités des tâches à long terme.
Le lendemain, nous sommes arrivés à ce format: jeudi, une liste de problèmes problématiques est apparue (en plus de ceux qui étaient déjà connus), nous en avons donc parlé presque tout le vendredi. Deux côtés ont été trouvés: l'un était pour l'hypothèse, l'autre était contre. Ensuite, ils ont organisé un duel, que tout le monde a jugé. C'est, presque comme un essai d'hypothèses: le procureur tire pour ce que vous n'avez pas besoin de faire, et l'avocat tire pour le succès et la joie. Certes, ils n'ont pas pensé à changer le procureur et l'avocat, et c'est une procédure standard dans de tels débats.
L'horaire de travail était le suivant: nous choisissons le pire moment pour les promenades (à Istanbul c'est le milieu de la journée), nous y mettons la rencontre. Le matin et le soir sont libres, mais nous déjeunons ensemble, c'est l'occasion de communiquer. Pendant ce voyage, certaines personnes accomplissaient encore de petites tâches, c'est-à-dire qu'elles ne pouvaient pas complètement désactiver le processus habituel. En revanche, je ne dirais pas que cela a pris beaucoup de temps.
Un exemple d'hypothèse de rodage
Les bus n'ont pas de billet électronique légalement approuvé. Cela nous attriste énormément, car les passagers doivent soit imprimer le formulaire à la maison, soit imprimer sur une imprimante à la gare routière (ce qui devient parfois un problème, et parfois c'est banal moyennant des frais). Les chemins de fer russes acceptent depuis longtemps l'enregistrement électronique presque partout, les avions vous impriment à l'aéroport sans poser de questions dans les terminaux ou à la réception (et dans certains endroits, vous n'avez pas besoin d'imprimer). Et dans les bus à certains endroits encore les années 70 de l'URSS.
Dans la pratique, il existe des stations progressives qui affichent simplement le ticket depuis le téléphone. Ils ont toujours ces données dans la déclaration de leur part, et il vous suffit de regarder là-bas et le document de la personne. Mais il y a des stations conservatrices et celles qui sont juste «Baba Yaga contre». Et toutes les stations ont leurs propres formes de ces formes.
Du point de vue de la gare, un billet électronique est un développement. La sécurité de la station augmente, elle est plus pratique pour le contrôleur et le conducteur, les opérations sont accélérées, le papier est économisé, les jeunes ne posent pas de questions.
Quoi qu'il en soit, dans un bus, un ou deux passagers oublient les billets, et en tout cas ils sont restaurés à partir des données de la gare. Mais à certains endroits, ils trouvent très à redire. La pratique a montré que si un passager commence à scandaliser, il le laisse entrer. S'il part tranquillement (le plus souvent des retraités) - nous devons déjà comprendre la situation.
La première chose que nous avons faite a été d’attribuer des gares conservatrices et lors de l’achat de billets, nous faisons une notification séparée avec eux au passager qu’il est nécessaire d’imprimer un billet: ils ne seront pas autorisés sans lui.
Nous avons ensuite décidé de dresser une «liste blanche» de ces gares routières où l'enregistrement électronique fonctionne. Triple contrôle: rappel passager, appel de notre client secret, question directe à la direction de la gare.
Si la législation est en retard sur la réalité en ce qui concerne l'autorisation des billets électroniques, mais qu'il existe une solution de contournement par la récupération des billets selon la gare, alors pourquoi ne pas automatiser et fabriquer votre propre béquille rapide et pratique?
En général, nous avons trouvé de telles stations et marqué des balises sur le site.
La vérification est répétée de temps en temps.
Au cours du processus, il s'est avéré qu'il y a des gares qui ont elles-mêmes adopté un tel système, mais n'en ont pas vraiment parlé aux passagers. Les intégrateurs y vont aussi avec joie.
Ensuite, nous avons accordé de petites primes dans le système aux stations qui ont une telle note de sorte qu'il y a une incitation économique à le faire.
En conséquence, il s'est avéré que nous avons rapidement combiné (enfin, en fait pas nous, mais eux-mêmes, en particulier, avec notre outil) plusieurs stations et opérateurs qui effectuent déjà eux-mêmes l'enregistrement électronique.
Autrement dit, vous ne pouvez pas simplement vous asseoir et attendre que tout apparaisse sur le plan législatif, mais comprendre comment le faire par programme. Et c'est tout. Nous avions besoin d'un tas de développeur, manager, une personne en communication avec des partenaires et un designer.
Quel est le résultat?
Pertes de la première expérience:
- Moins de billets et d'hébergement.
Bénéfices:
- Presque comme des vacances au milieu de l'année.
- Pour les six prochains mois, ils ont décidé toutes les questions à la fois.
- Ils ont pu communiquer spécifiquement avec l'équipe. Pour une raison quelconque, le bureau ne fonctionne pas de cette façon.
- Des choses difficilement mesurables au niveau des sensations: les relations dans l'équipe ont changé.
- Nous avons regardé notre propre produit de l'extérieur: après tout, nous avons utilisé nos outils (et d'autres équipes) tout le temps, nous avons proposé plusieurs fonctionnalités «à la volée».
- Ils ont simplement fait un voyage, ce qui est logique pour une entreprise qui se déplace.
- Les camarades "supérieurs" ont enseigné aux "June" à penser rationnellement, non seulement dans le développement, mais aussi dans la planification de la journée. C'est très insignifiant, mais le transfert d'expérience se fait sentir.
- Ils ont pu amener les développeurs distants à communiquer, ce qui n'était généralement pas suffisant.
Nezhdanchiki:- Nous avons appris que les deux filles avaient des problèmes catastrophiques d'orientation avec la zone: elles étaient perdues, nous les avons retrouvées, jamais lâchées. Cela a presque perturbé la session de travail.
- Le développeur qui a pris en charge l'organisation a montré une manifestation de leadership situationnel. Pas tout à fait prévu, eychar et le leader ont été surpris.
- Nous avons découvert que notre collègue Misha prend des photos sympas. Il a pris l'appareil photo, a tout enlevé, puis a présenté des tirages papier. Pour mémoire.
Il est très difficile de synchroniser les déplacements, et cela n'est pas encore devenu un processus. Mais je pense que oui, car les avantages sont évidents. Maintenant, nous utilisons les deux approches: nous allouons le temps des équipes au bureau pour analyser les hypothèses et parfois partir. Les départs sont plus nécessaires pour déterminer la vision et les différentes tâches, et «ne pas déranger» au bureau pour casser les hypothèses en mode hackathon personnel.
Sept hypothèses ont été sélectionnées et testées dans la première itération, dont trois ont montré des résultats. Par exemple, en direction des bus.
À l'étape de la saisie des données, les passagers ont commencé à montrer une plaque portant l'inscription «Dernier achat de billet pour ce vol il y a N minutes». Sur la version mobile A / B a montré + N% aux ventes, sur le bureau il n'y a pas de résultats significatifs. Nous avons élargi le formulaire de recherche sur la version mobile des pages avec le calendrier - en conséquence, nous avons obtenu + NN% aux ventes. Nous recevons des données des clients afin de pouvoir les renvoyer. Sur les problèmes vides, ils ont commencé à collecter des e-mails d'utilisateurs pour envoyer des bus, s'ils apparaissent dans la direction, il y en a des centaines par semaine. En fonction des préférences de l'utilisateur, nous collectons des offres dans la newsletter. Les résultats. Résultat: 91–93%. Ventes de ceux qui ont ouvert la lettre: + NN, 3% (significatif). Mais! Les gens prennent le bus dans les mêmes directions, ce qui signifie que les prévisions sont les mêmes. Jusqu'à présent, il s'avère que les envois seront toujours les mêmes. Nous réfléchirons à la diversification.
À cette époque, il y avait des tâches typiques dans l'arriéré, par exemple, une telle routine:
- Exécutez deux intégrations avec les stations de bus.
- Mettez à jour trois intégrations actuelles.
- Intégrer les transporteurs de bus lituaniens.
- Créez des connecteurs pour votre compte 16 opérateurs.
En général, cela fonctionne, mais nous aimerions écouter votre expérience de travail «isolé» du bureau et de voyager quelque part si vous en aviez.