J'ai eu l'opportunité de travailler sous la direction d'un chef de projet qui avait une approche intéressante des conflits de propriété de projet: " Quand il est temps de faire les choses, il vaut mieux avoir un capitaine moyen que deux excellents. "

Il semble que la propriété du projet soit vraiment importante pour votre collègue. Pourquoi ne pas le traiter comme un atout plutôt que comme un passif?

Faites reconnaître votre collègue comme le propriétaire du projet, avec toutes les responsabilités qui en découlent. Ayez une réunion avec votre responsable et votre collègue. Optez pour quelque chose comme " semble que le collègue X ici aime vraiment s'approprier. Donc, pour simplifier les choses et leur donner une bonne expérience de propriété [si nécessaire], laissez-les prendre celui-ci - je vais vous aider les suivre et s'en remettre à leurs décisions sur la plate-forme, les bibliothèques, les approches et autres. Le prochain projet est le mien, cependant. Deal? "

Aspects positifs de cette approche:

• Vous serez considéré comme un joueur d'équipe qui accepte l'enthousiasme des autres coéquipiers et leur donne une chance de faire leurs preuves, tout en éliminant un facteur de stress;
• Étant officiellement à l'arrière, vous serez dispensé de défauts de conception (vous pouvez suggérer des approches, mais la décision finale n'est pas la vôtre);
• Le fait que le responsable et le collègue acceptent votre propriété pour le prochain projet vous donne une base solide pour utiliser le ' poursuivons mon approche cette fois, d'accord? 'quand c'est à vous de définir des spécifications;
• La mise en œuvre d'une solution sous la vision de votre collègue vous proposer un point de vue différent sur la manière d’aborder les définitions de projet.

Lorsqu'il fait une suggestion ou une critique de votre pull request, expliquez une fois pourquoi vous n'allez pas la modifier pour qu'elle corresponde à sa suggestion. Cela doit être simple et clair. Par exemple:

"Cela n'améliorerait pas significativement le code."

"L'effort pour faire ce changement n'est pas justifié par sa valeur."

"La méthode actuelle est plus simple."

S'il refuse toujours d'accepter la demande d'extraction, remontez à la direction. Vous pouvez le faire par e-mail, par exemple: "La demande d'extraction X est ouverte depuis Y temps, attendant toujours l'approbation de Z. Z n'a pas donné de justification suffisante pour rejeter la demande d'extraction."

Forcer le être celui qui retarde et interfère, puisque c'est ce qu'il fait. Faites remarquer que son insistance sur les changements de conception constants ou son refus d'approuver en temps opportun les demandes d'extraction simplement parce qu'elles ne sont pas faites comme il le juge le mieux est de perdre votre temps.

Notez que vous allez simplement à la direction pour décider si votre code est acceptable tel quel et si la demande d'extraction doit être acceptée ou non. Soit votre code répond aux normes applicables, soit il ne le fait pas. Si c'est le cas, il devrait être accepté. Si ce n'est pas le cas, il a raison et vous avez tort.

Je ferais appel à un manager et lui dirais que les arguments constants nuisent à l'efficacité. C'est quelque chose qu'il doit régler.

Si c'était moi, j'essaierais de diviser le projet. Essayer de trouver une interface et donner à chacun sa part à gérer. Vous pouvez peut-être suggérer cela.

Souvent, contester l'une de ses suggestions ou en proposer une autre est une bataille difficile.

Parfois, c'est normal. C'est en fait utile, dans certains cas. Vous devriez aussi avoir ce niveau de confiance. Si vous prenez une décision, vous devriez être prêt à la sauvegarder, jusqu'au bout.

Cela semble être satisfait à chaque fois que je ne veux pas faire quelque chose exactement de la même manière qu'il le ferait, et c'est généralement un processus long et fastidieux.

Cela peut être un problème. Ce n'est peut-être pas le cas. Parfois, les développeurs ont du mal à se souvenir "il y a plus de x façons de skin un foo". Vous pouvez essayer de résoudre ce problème avec votre responsable.

Par exemple, supposons que je choisisse d'utiliser une bibliothèque pour accomplir une tâche. Je vais devoir le lui justifier, ce qui est bien en soi, mais il y a une résistance inhabituellement élevée même si je peux justifier son utilisation.

C'est une très bonne chose. Une bonne chose énorme . Lorsque je gère une équipe, chaque nouvelle bibliothèque nécessite une discussion ÉNORME. La personne qui préconise l'utilisation de la bibliothèque doit justifier son utilisation. Il doit y avoir une justification sérieuse. Si vous voulez forcer tous les membres de votre équipe - et tous ceux qui ont rejoint votre équipe - à utiliser cette nouvelle dépendance, cela en vaut la peine. Alors peut-être que c'est un mauvais exemple. Mais il faut s'attendre à un certain niveau de "lutte pour ce que vous voulez" pendant les phases de planification. Si vous effectuez ces niveaux d'appels pendant la phase de «codage», c'est mauvais pour vous. Celles-ci auraient dû être faites, discutées, décidées, etc. bien avant que la première ligne de code (pour la nouvelle fonctionnalité) ne soit écrite. Ajouter une dépendance au moment du codage, pour moi, est un rejet automatique d'une pull request, suivi d'une réunion. Ensuite, une tentative pour être sûr que la prochaine fois, nous disposerons les dépendances avant de commencer à écrire du code.

En général, je n'ai pas l'impression d'avoir ma propre autonomie pour la prise de décision, ce qui, à mon avis, devrait être accordé;

Vous n'avez pas et c'est OK. Il n'y a pas de moi dans l'équipe. Encore une fois, s'il s'agit de problèmes au niveau de la mise en œuvre, ils doivent être expliqués. S'il s'agit de problèmes au niveau de la planification, il est temps d'être prêt à défendre votre chemin.

au lieu de cela, je me sens comme son assistant.

Maintenant, ceci est un problème. Vous devrez peut-être définir de meilleures métriques pour une demande d'extraction réussie / échouée. Dans quelles conditions est un pass? Dans quelles conditions un échec? En cas d'échec, des éléments exploitables sont-ils donnés?

Une règle que j'utilise toujours est que si quelqu'un échoue à une pull request, il doit donner des éléments exploitables pour rendre la requête passable.

Fail: Les tests ne réussissent pas, corrige le code pour que les tests passent .
Échec: n'utilisez pas d'itérateurs comme x, utilisez de vrais noms de variables, dans ce cas appelez-le "pour l'entrée dans les entrées" et non "pour e dans les entrées"

Puis au moins en regardant le message d'échec vous avez un endroit pour démarrer une conversation.

Mon manager a dit qu'il était d'accord avec la médiation, mais cela me semble incroyablement mesquin.

Le travail du manager est de gérer; LAISSEZ-LES . Si votre responsable en a assez de traiter ces demandes, il les fera arrêter. Votre responsable peut très bien préférer ce niveau de surveillance.

Par exemple, supposons que je choisisse d'utiliser une bibliothèque pour accomplir une tâche. Je vais devoir le lui justifier, ce qui est bien en soi, mais il y a une résistance inhabituellement élevée même si je peux justifier son utilisation. En général, je n'ai pas l'impression de disposer de ma propre autonomie de décision , ce qui, à mon avis, devrait être accordé; au lieu de cela, je sens que je ne suis fondamentalement que son assistant.

Dans une équipe / entreprise, vous n'avez pas votre autonomie pour la prise de décision; du moins pas pour des décisions de haut niveau comme choisir une nouvelle technologie, une nouvelle bibliothèque, décider de l'architecture, ...

Lorsque vous travaillez sur un projet en équipe, vous devez être remplaçable . Vous pourriez être malade / heurté par un bus à tout moment, et un autre collègue devrait être en mesure d'intervenir et de continuer là où vous étiez.

Plus ce collègue est familier avec votre travail, mieux c'est, c'est pourquoi il est important que:

• vous utilisiez les mêmes bibliothèques tierces que n'importe qui d'autre dans l'entreprise,
• vous structurez votre projet de la même manière que tout autre projet dans le entreprise,
• ...

Bien sûr, il y a de la place pour l'exploration. Une nouvelle bibliothèque tierce, une nouvelle structure, etc ... peuvent améliorer le statu quo, mais elles sont perturbatrices et leurs avantages devraient donc largement compenser leurs coûts. Cela doit être une décision consciente de la part du département / division / entreprise . Ce n'est pas à vous de le faire, même si vous pouvez le défendre.

Nous devons approuver les pull requests de l'autre, par conséquent, si je fais quelque chose qu'il n'aime pas, il a la possibilité de le rejeter purement et simplement jusqu'à ce que je le modifie pour répondre à ses suggestions. Si je dois faire passer cette fonctionnalité, je dois soit rester sur ma position et passer beaucoup de temps à la justifier, soit simplement la changer pour ce qu'il suggère et poursuivre ma vie. un peu un rocher et un endroit dur

Si vous me le permettez, je pense qu'il y a un problème de méthode de travail ici.

La conception de haut niveau doit être discutée avant de commencer le travail; c'est juste une perte de temps de travailler pendant une semaine sur quelque chose, de le présenter pour approbation et de le faire rejeter avec la raison "Attendez, avez-vous envisagé l'interaction avec X? Cela ne fonctionnera jamais!".

Cela signifie que avant de commencer le travail, vous devez vous mettre d’accord en équipe sur une direction générale. Et si quelque chose survient à mi-chemin et nécessite un changement radical, vous devez vous mettre d'accord en équipe sur la direction à prendre à partir de là.

Remarque: j'ai vu des gens plaider pour l'approbation de leur PR parce qu'ils avait beaucoup travaillé, malgré les objections sur sa qualité ou sa conception. Cela fait mal de voir vos efforts rejetés ... c'est pourquoi il est préférable de discuter des choses à l'avance.

Donc, en supposant que:

• vous avoir l'approbation de la direction pour les technologies, les bibliothèques tierces et la conception de projet,
• vous avez convenu au préalable de la direction générale de la pull request.

Ensuite, la discussion sur le La demande d'extraction elle-même doit être centrée sur:

• le polissage des cas de bord,
• le nettoyage de l'implémentation,
• la clarification des bits obscurs.

Une fois dans une lune bleue, vous pouvez recevoir un commentaire du type "Oh merde, nous avons oublié de tenir compte du cas X". Ça arrive. C'est une erreur d'équipe.

Bien entendu, cela ne résout pas comme par magie votre problème de propriété. Votre collègue peut encore être intraitable lors de la discussion initiale sur la direction générale de la pull request.

En général, que l'on soit propriétaire ou non n'a pas d'importance, vous voulez un consensus .

Votre premier objectif devrait donc être de comprendre pourquoi votre collègue est difficile:

• a-t-il une vision différente?
• est est-il idéaliste?
• est-il un maniaque du contrôle?
• ne fait-il pas confiance à vos compétences?
• ...

et essayez de résoudre le problème avec lui.

Vous devez vous aligner sur la vision de haut niveau du projet, gagner sa confiance en vos compétences, ...

Si tout le reste échoue, en dernier recours ¹ , vous voudrez peut-être impliquer votre responsable et lui faire répartir les responsabilités. Vous avez mentionné vous et il avait des compétences différentes, vous devriez donc être en mesure de répartir les responsabilités en 3 domaines: son domaine, votre domaine et un espace commun. Dans votre région, son opinion serait purement informative (et vice versa).

¹ Et enfin, la confrontation rend les gens aigris.

Y a-t-il une meilleure façon de gérer cela?

Je me demande s'il pense que chaque décision est binaire:

1. Droite / correcte (c'est-à-dire à ma manière)
2. Mauvais (c'est-à-dire à votre manière, pas à moi, je ne l'aurais pas fait comme ça)

Je pense qu'il est important de catégoriser les décisions dans au moins trois compartiments plutôt que deux:

1. Agréable (nous convenons tous les deux que c'est une bonne chose)
2. Désagréable ou inacceptable (il existe un préjudice objectif et identifiable associé à une proposition)
3. Assez bien ou acceptable (par exemple, je ne l'aurais pas fait comme vous le suggérez, mais ce que vous suggérez est assez bon, immédiatement adéquat et mieux que rien)

Une de mes expériences de révision de code est lorsque j'étais le gardien officiel (c'est-à-dire chef d'équipe ou propriétaire de produit), et je me souviens que mes commentaires sur la révision de code comportaient trois catégories:

1. C'est bien, prêt pour l'enregistrement
2. Ce n'est pas encore tout à fait prêt, vous devez changer cela (j'ai besoin u pour changer cela) avant l'enregistrement
3. Je vois ce que vous avez fait, ça marche; FYI je ne l'aurais pas fait de cette façon, je l'aurais fait de cette autre façon; vous pouvez modifier ceci (avant l'enregistrement, pour le faire comme je l'ai suggéré) si vous le souhaitez, mais ce n'est pas obligatoire.

Avoir cette troisième catégorie est en quelque sorte nécessaire si vous voulez une aide autonome.

Notez que s'il y a "dommage objectif et identifiable associé à une proposition", alors vous devez tous les deux être capables de voir et de convenir que le mal existe. S'il y a encore un désaccord, il s'agit peut-être d'un compromis, et peut-être que est un sujet que vous pourriez apporter au chef de produit (par exemple "patron, devrions-nous utiliser et dépendre d'un composant tiers , ou adopter davantage une politique Pas inventé ici? ").

Ou y a-t-il un autre développeur de logiciels à proximité? J'avais l'habitude de travailler avec une petite équipe de pairs expérimentés. Nous nous parlions en tête-à-tête pour discuter et décider de nos interfaces. Dans les rares cas où deux personnes ne pouvaient pas ou n'étaient pas d'accord sur quelque chose, nous invitions un autre (c'est-à-dire un troisième) développeur à la discussion (pour trouver un consensus ou une décision à la majorité). p>