Diviser le temps entre le produit et les efforts d'ingénierie

Dans chaque entreprise que j'ai travaillé, nous avons eu une séparation entre le temps consacré aux initiatives de produits et aux travaux d'ingénierie. Les pourcentages ont toujours changé, parfois 70% de produit, 30% d'ingénierie, parfois autant qu'une division 50/50. L'impulsion est de s'assurer que l'ingénierie passe une partie de leur temps à construire de nouvelles fonctionnalités, mais nous garantit également que nous pouvons faire «notre propre» travail tel que l'adressage de la dette technique, la mise à niveau des systèmes et documenter notre code.

Le problème est que c'est une chose de dire cela au départ, et une autre pour en faire une réalité. Il y a des raisons pour lesquelles j'ai vu ce modèle échouer, non pas parce que les gens ne comprennent pas en théorie qu'il est précieux, mais parce que dans la pratique, il y a des pièges communs que vous devez réfléchir. Nous couvrirons certains de ces scénarios du point de vue d'un chef d'ingénierie afin que nous puissions aborder un bon chemin à suivre.

Les problèmes

Certains des pointeurs ci-dessous sont des réactions et une planification en fonction de ce qui peut mal tourner, alors parlons d'abord des défis que vous pouvez rencontrer si cela n'est pas correctement.

• Le produit peut avoir des conflits, soit avec le travail lui-même, soit le temps impliqué. Cela peut lutter contre la relation entre le produit et l'ingénierie. S'ils sont pris par surprise, vous pouvez potentiellement trouver les limites de votre travail de devenir plus restrictives.
• Vos ingénieurs pourraient ne pas comprendre ce que l'on attend d'eux . La parallélisation des efforts peut être difficile à faire, donc la construction d'un bon processus peut apporter une clarté.
• Le chemin de maintenance doit être clair : prévoyez-vous de faire une mise à niveau du système géant? Cela peut affecter d'autres équipes au fil du temps et si vous n'êtes pas clair sur la propriété éventuelle, cela pourrait revenir vous hanter. ?

Aussi agréable que cela ait une certaine liberté dans votre temps d'ingénierie, la communication, la planification et les attentes claires peuvent vous assurer d'éviter l'un des problèmes décrits ci-dessus.

Communication

Une fois que vous avez compris le problème que vous souhaitez résoudre, il est essentiel de rédiger une petite feuille que vous pouvez partager avec les parties prenantes sur la nature de l'œuvre, le temps qu'il va prendre et pourquoi c'est important.

S'il s'agit d'un grand projet, vous pouvez également étendre ces pièces dans les problèmes GitHub / GitLab / Jira, et ajouter une étiquette pour le type de travail qu'elle est. C'est génial car vous pouvez utiliser le système de gestion de projet que vous utilisez déjà pour élever la quantité de travail et les attentes chaque semaine. Il est bon de garder le dialogue ouvert avec vos partenaires de produit sur la portée et la nature du travail afin qu'ils ne soient pas surpris par les autres travaux. Cela variera en grande partie selon la culture de l'équipe et de l'organisation.

Cela peut également aider à clarifier vos ingénieurs. S'ils comprennent la nature du travail et ce que l'on attend d'eux, il leur est plus facile de s'attaquer aux petits problèmes qui se composent dans son ensemble.

Vous constaterez peut-être que cela a moins de sens dans une perspective d'orientation pour que chaque ingénieur divise le temps entre les projets de produits et d'ingénierie. Ils peuvent plutôt préférer diviser le travail entre eux: trois personnes sur le travail de produit pendant quelques semaines, une personne sur les travaux d'ingénierie. Il y a aussi des moments où tout le monde doit être impliqué afin qu'ils aient des connaissances institutionnelles égales (les migrations peuvent être comme ceci, selon ce qu'elle est). Votre kilométrage peut varier en fonction de la taille de l'équipe, de la quantité de travail de produit et du type de projet.

La communication aide ici aussi - si vous ne savez pas quel est le bon chemin, cela peut aider à avoir un petit brainstoral en tant que groupe sur la façon dont vous souhaitez faire cela. Assurez-vous simplement que vous alignez également tout le monde sur les raisons pour lesquelles le projet est important comme vous le faites.

Types de projets

Il existe de nombreux types de projets que vous pouvez créer dans votre équipe d'ingénierie, et chacun a des approches légèrement différentes de ce que j'ai vu, alors passons en revue chacun d'eux.

Dette technologique

Attorons d'abord la dette technique, car c'est l'un des travaux les plus courants qui peuvent déverrouiller votre équipe. Pour chaque fonctionnalité que vous écrivez, si l'effort d'ingénierie est ralenti, vous ne perdez pas seulement du temps en termes de développement de produits, vous perdez également de l'argent en termes de temps d'ingénierie en salaire.

Un peu de dette technique est naturelle, en particulier dans les petites entreprises où il est plus judicieux de se déplacer rapidement, mais il y a des points où la dette technologique devient paralysante pour le développement et les versions, et rend une base de code instable. Parfois, cela doit être fait immédiatement pour s'assurer que tous vos ingénieurs peuvent fonctionner efficacement, et parfois c'est progressif.

Dans de nombreux cas, les éléments de la dette technique sont des choses dont vous avez besoin dont vous avez besoin par une approche inférieure: les développeurs les plus proches du travail avec le système sauront mieux que la dette technique quotidienne existe que les directeurs d'ingénierie (EMS). Le défi en tant qu'EM est de remarquer des schémas plus grands, comme lorsque de nombreuses personnes se plaignent de la même chose, plutôt qu'un Dev qui peut avoir une opinion forte. Demander autour de vous avant de commencer ce type de projet peut aider - sonder les gens sur combien de temps ils pensent qu'ils perdent au cours d'une semaine donnée par rapport à la perspective d'une alternative.

Parfois, la dette technique est une grande quantité de refacteur. J'ai vu cela aller mieux lorsque les gens sont à l'avance sur le type de demandes de traction (PR) nécessaires. Avez-vous besoin de mettre à jour le CSS en un million de places? Ou convertir les composants de l'ancienne classe en crochets? Vous ne voulez probablement pas un énorme RP pour tout cela, mais cela n'a pas de sens de rompre ce travail par composant non plus. Travaillez ensemble en équipe sur le montant de chaque RP et ce qui est attendu de l'examen afin de ne pas créer de «trou d'examen» pendant que le travail est terminé.

Projets innovants

Beaucoup d'entreprises réaliseront des projets de hack Week / Innovation Week où les développeurs peuvent travailler sur une fonctionnalité liée au produit de l'entreprise sans attacher. C'est le moment idéal pour l'exploration, et j'ai vu des fonctionnalités puissantes ajoutées à des applications bien connues de cette façon. Il est également incroyablement énergisant pour l'équipe de voir leur propre idée se concrétiser.

Le problème de faire ce genre de projets dans le temps d'ingénierie divisé est que vous pouvez parfois faire en sorte que l'équipe du produit se sente un peu méprisé. Pourquoi? Eh bien, pensez aux choses de leur point de vue. Leur travail consiste à mettre en place ces fonctionnalités, à planifier soigneusement les parties prenantes, à mettre en place des feuilles de route (souvent en fonction des métriques et de la recherche de l'entreprise) et de monter dans le calendrier d'ingénierie, travaillant généralement avec un chef de projet. Si vous passez la moitié de votre temps à travailler sur des fonctionnalités imprévues, vous pouvez potentiellement bifurquer un plan existant pour un projet, aller à l'encontre de certaines des recherches connues dont ils ont, ou simplement ralentir le processus pour obtenir une fonctionnalité de base de marque dont ils ont besoin.

La façon dont j'ai vu cela se déroule bien, c'est quand l'EM communique à l'avance avec le produit. Considérez cela comme un partenariat: si le produit dit qu'une fonctionnalité particulière n'a pas de sens, il a probablement une bonne raison de le penser. Si vous pouvez tous les deux vous entendre, il y a probablement un chemin à suivre où vous êtes tous les deux d'accord.

C'est bien de répondre à leurs peurs aussi. Craisent-ils qu'il n'y ait pas assez de temps pour le travail de produit? Demandez à votre équipe directement combien de semaines à la mi-temps, ils pensent que cela pourrait prendre (avec les attentes que les choses pourraient changer une fois qu'ils ont creusé). Expliquez clairement à tous que vous ne vous attendez pas à ce que cela soit fait à un rythme de couche de rupture.

En fin de compte, la communication est essentielle. Idéalement, ce sont de petits projets qui ne feront rien dérailler qui peuvent être faits en parallèle avec le travail régulier. Ma suggestion est de l'essayer avec quelque chose de très petit en premier pour voir quelles bosses sur la route pourraient y avoir, et également établir une confiance avec un produit que vous réaliserez toujours votre travail et non «Go Rogue».

Le dernier morceau de cela est de déterminer qui est responsable des mesures, des résultats et quand les choses ne se passent pas bien. Une partie de la raison pour laquelle le produit décide de la direction est parce qu'ils sont sur le crochet lorsqu'il échoue. Assurez-vous que vous êtes clair qu'en tant que leader de l'ingénierie, vous assumez la responsabilité des résultats, à la fois le bien et le mal de maintenir une bonne relation.

Travail lent et en cours

C'est probablement la coupe la plus claire de tous les types de projets et obtiendra probablement le moins de recul de quiconque. Des exemples de ce type de travail sont la documentation interne, l'outillage (si vous n'avez pas d'équipe d'outils dédiés) ou de petits morceaux de maintenance.

La communication nécessaire ici est un peu différente des autres projets, car ce ne sera pas nécessairement un projet contraint que vous expédiez, mais plutôt un processus itératif. Prenez la documentation à titre d'exemple: je suggère de créer du temps pour la documentation interne dans n'importe quel processus de fonctionnalité.

Par exemple, disons que vous avez créé une nouvelle fonctionnalité qui permet aux équipes de collaborer. Tout le monde dans toute l'entreprise ne sait pas que vous avez créé un microservice pour cette fonctionnalité que toute équipe peut utiliser et quels paramètres sont attendus, ou comment ajouter des fonctionnalités sur la route. Les documents internes peuvent faire la différence entre le service utilisé, ainsi que votre équipe invitée à s'associer à quelqu'un chaque fois que quelqu'un a besoin de l'utiliser. Ou pire: ils essaient de pirater et de le comprendre seuls, créant un gâchis de quelque chose qui aurait pu être travaillé plus rapidement et plus efficacement.

Contrairement aux projets d'innovation, le travail lent et en cours n'est généralement pas quelque chose que les gens ont vraiment envie de faire, donc la définition d'un processus et des attentes fonctionne tout de suite. La documentation interne est une partie parfois cachée mais très importante d'une équipe qui fonctionne bien. Il aide à intégrer, à faire en sorte que tout le monde sur la même longueur d'onde sur l'architecture du système, et peut même aider les développeurs à solidifier ce qu'ils ont construit et à réfléchir à la façon dont ils le résolvent.

Migrations

Les migrations sont traitées un peu différemment de certains autres types de projets car il affecte probablement tout le monde. Il n'y a pas une seule bonne façon de le faire, et dépendra également largement du type de migration - le cadre vers le cadre, la rupture d'un monolithe et la migration vers un processus de construction ou un serveur différent peuvent avoir des approches différentes. En raison du fait que chacun d'eux est probablement un article de son propre article, passons par des options de haut niveau qui s'appliquent à leur organisation.

• Ma première suggestion est de faire autant de recherches que possible à l'avance sur le type de migration que vous faites. Il n'y a aucun moyen de tout savoir, mais vous ne voulez pas vous faire partie à travers un processus pour découvrir quelque chose de critique. Il s'agit également d'informations utiles à partager avec les parties prenantes.
• Y a-t-il des débats internes sur la direction de votre entreprise? Timebox une unité de temps pour résoudre le problème et assurez-vous d'avoir un décideur clair à la fin . Beaucoup de problèmes technologiques n'ont pas une «vraie» solution, donc le fait d'avoir un propriétaire prendre la décision et tout le monde en désaccord et s'engager peut aider. Mais vous voulez également donner un moment aux gens pour que leur voix entende ce qui leur donne une pause, même si elles sont en désaccord - elles pourraient penser à quelque chose que vous n'êtes pas.
• Documentez un plan de migration, à la fois à un niveau élevé, puis travaillez sur l'impact sur chaque équipe. C'est aussi le moment idéal pour expliquer au produit pourquoi ce travail est important: votre base de code devient-elle ancienne et ne peut plus bien jouer avec d'autres bibliothèques et outils? Un nouveau processus de construction est-il sorti qui pourrait faire gagner du temps à vos ingénieurs dans un processus de version? Aidez-les à comprendre pourquoi le travail est essentiel.
• Soyez clair sur la maintenance et la propriété. Si une équipe migre un processus de construction qui provoque des problèmes pour une autre, qui répare les choses pour débloquer cette équipe? Vous devriez décider cela avant que cela ne se produise.
• Certains chemins de migration vous permettent de faire les choses lentement au fil du temps, ou d'équipe par équipe, ou de faire beaucoup de travail à l'avance. Cependant, il y a généralement un moment où cela va être critique et toutes les mains sur le pont sont nécessaires. Contrairement à certains des autres travaux qui peuvent être parallélisés, vous devrez peut-être travailler quelque chose avec un produit où tous les autres fonctionnalités sont bloquées pendant un peu pendant que vous mettez en place le nouveau système. Si vous travaillez en étroite collaboration avec eux, vous constaterez peut-être qu'il y a des moments dans la saison où vous avez naturellement plus d'accalaises de client, et cela pourrait vous donner la salle de respiration dont vous avez besoin pour le faire. Je suggérerais que s'ils sont prêts à vous laisser passer du temps d'ingénierie à 100% pour un petit moment, vous retournez la pareille; Et une fois que la plate-forme est stable, consacrez 100% du temps de l'équipe au travail de produit.

Célébrer!

Cette dernière étape peut sembler facultative, mais c'est un gros problème à mon avis. Votre équipe vient de retirer quelque chose d'incroyable: ils ont parallélisé des efforts, ils étaient de bons partenaires pour les produits, ils ont fait quelque chose pour l'organisation d'ingénierie en général. Il est crucial de célébrer le travail comme vous le feriez pour un lancement.

L'équipe doit savoir que vous appréciez ce travail, car il est souvent ingrat, mais très percutant . Il peut également renforcer la confiance pour savoir que si quelque chose de poilue se présente à l'avenir, cela aide également leur cheminement de carrière. Célébrer avec votre équipe ce que vous avez accompli coûte très peu et a de grands impacts culturels.

Acheter le livre

Ceci n'est qu'un échantillon du type de contenu de mon dernier livre qui sortira bientôt…

Rejoignez la liste!

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!