Question:
Comment convaincre le patron de passer une période de préavis sur la documentation au lieu de nouveaux projets
G_H
2019-05-17 18:33:14 UTC
view on stackexchange narkive permalink

Récemment, j'ai signé avec un nouvel employeur et je purge actuellement la période de préavis chez mon ancien employeur. Il y a une période de préavis assez longue où je vis, compte tenu de mes paramètres (13 semaines, Belgique). Actuellement, nous mettons un client au courant d'un progiciel pour lequel j'ai effectué la plupart de l'analyse, de la conception et du développement. En fait, c'est un produit qui existe par mérite de généraliser les aspects communs de projets similaires et qui a pris sa forme actuelle au cours de nombreux projets et années. La plupart des connaissances, à la fois techniques et fonctionnelles, m'appartiennent. Le code lui-même est bien documenté, mais la façon dont tout s'articule, la connaissance du domaine, l'installation et les meilleures pratiques d'utilisation nécessitent beaucoup plus de documentation.

Je travaille avec un autre développeur sur cette mise à jour et il apprend assez bien. Mais avec moi faisant une partie du travail, lui expliquant les choses et devant décider quoi déléguer, je n'ai tout simplement pas le temps de tout expliquer. Même si je l'ai fait, je ne peux pas m'attendre à ce qu'il se souvienne de tout ou le saisisse immédiatement. Si je pouvais utiliser le reste de ma période de préavis pour créer des guides d'utilisation et de développement détaillés, cela lui laisserait du matériel de référence solide ainsi que tous les futurs développeurs et utilisateurs.

Au lieu de cela, ce projet doit être achevé dès que possible car il y a un client beaucoup plus gros pour le même produit qui attend de commencer une implémentation. Il est clair que mon patron attend de moi que je commence le plus rapidement possible, que je mette l'autre développeur au courant et qu'il apprenne et documente au fur et à mesure. Je sais pertinemment que cela mènera à un peu plus que des connaissances et des notes très inégales, manquant de perspicacité et manquant une grande partie des techniques que j'ai dû apprendre par expérience. Sans une documentation complète, ceux qui restent dans l'entreprise devront perdre énormément de temps à comprendre comment utiliser le logiciel, comment le développer et ne pourront pas éviter de nombreuses erreurs que je commet et dont j'apprends. Et enfin, j'ai passé des années de ma vie à construire cette architecture, à la régler et à l'améliorer; c'est mon idée et je n'aimerais pas la laisser "impuissante".

Comment convaincre mon patron que l'entreprise, mes collègues et les projets futurs sont mieux servis si je mets en place les ressources nécessaires pour une assistance continue plutôt que d'avoir à passer mes dernières semaines ici à réduire les heures facturables d'un client et à mettre en place des échafaudages sur lesquels personne ne saura vraiment s'appuyer?

Quel chevauchement existe-t-il entre la manière dont ce produit est (ou est susceptible d'être) mis en œuvre chez chaque client?
@PlayerOne Beaucoup.C'est en quelque sorte l'essence même.Les chevauchements fréquents et les points communs entre les projets m'ont conduit à développer une solution commune avec de nombreux modèles pour les modèles de données, les mappages de données et la configuration.Ceci est ensuite extensible et modifiable selon les besoins pour un client / projet spécifique.Ainsi, regarder les implémentations existantes peut certainement vous permettre de "cultiver la cargaison" votre chemin, mais vous manquerez de comprendre pourquoi les choses sont faites de cette façon et n'apprendra pas grand-chose à personne sur l'extension du logiciel.
@JoeStrazzere Oui, j'ai exprimé ces préoccupations et déclaré que je crois que la documentation est très importante, et ne pas sous-estimer la complexité de l'orchestration de toutes les parties mobiles de ce logiciel.Mais le refus était qu'une documentation approfondie prendrait trop de temps et que l'autre développeur devrait documenter au fur et à mesure.Aussi, je sais certainement que je laisserai derrière moi mon travail (et les opportunités d'améliorations que j'aurais aimé voir) avec lesquels je suis en paix.J'ai hâte de faire de nouvelles choses et de supprimer un héritage.Mais j'aimerais bien le faire et que mon expérience profite aux autres.
@G_H si vous pensez que la documentation est si importante, pourquoi ne l'a-t-elle pas déjà fait?
@BittermanAndy Il existe de la documentation pour différentes parties, mais il y a beaucoup de lacunes, certaines d'entre elles sont devenues obsolètes avec le temps et beaucoup sont laconiques et techniques, pas tellement fonctionnelles ou perspicaces.Et à part ça, la même vieille histoire ... Avancer sur des projets a toujours eu la priorité sur la documentation et le refactoring, et même maintenant sur le projet actuel, il m'a été suggéré que prendre des raccourcis serait bien si cela signifie que nous pouvons commencer plus vitesur le suivant.
Assez lié [question sur le fait de ne pas être d'accord avec ce qui vous a été attribué pendant votre période de préavis.] (Https://workplace.stackexchange.com/questions/33892/my-employer-wants-me-to-write-a-guide-pour-faire-mon-travail)
Dix réponses:
sf02
2019-05-17 18:43:31 UTC
view on stackexchange narkive permalink

Comment puis-je convaincre mon patron que l'entreprise, mes collègues et les projets futurs sont mieux servis par moi en mettant en place les ressources nécessaires à son soutien continu plutôt que d'avoir à passer mes dernières semaines ici à réduire les heures facturables d'un client et mettre en place des échafaudages sur lesquels personne ne saura vraiment s'appuyer?

Vous ne le faites pas. S'il y a des conséquences négatives si votre patron attribue de nouveaux projets plutôt que de vous faire documenter, il devra s'en occuper, pas vous. Il est de la responsabilité de votre patron d'assurer une transition en douceur de vos tâches vers les autres employés, s'il ne planifie pas correctement, ce n'est pas quelque chose dont vous vous souciez. Oui, cela peut rendre les choses plus difficiles pour vos collègues à l'avenir, mais c'est quelque chose qu'ils devront aborder avec le patron en raison de ses décisions.

Il n'y a aucun mal à exprimer vos préoccupations à votre patron , mais en fin de compte, il prendra la décision qu'il jugera la meilleure pour l'entreprise. Qu'il prenne la bonne décision ou non n'est pas votre préoccupation.

+1.Votre patron a estimé que vous avez clairement géré si longtemps sans pile de documentation, donc cela ne peut pas être d'une importance critique.S'il a tort, c'est à vous de ne pas l'avoir fait au fur et à mesure.
Je vois ce que vous voulez dire, et la responsabilité incombe certainement en grande partie à la direction.Mais il peut exister des idées fausses sur la complexité de l'apprentissage du travail avec ce produit et sur la manière dont l'écriture des connaissances du domaine aiderait dans les projets.Peut-être que mon patron pense que les gens vont très bien comprendre et se méprend sur la valeur ajoutée de moi en condensant des années d'expérience et d'expérimentation.Je souhaite donc que cela soit clair.De plus, je me soucie vraiment de ce que j'ai fait et j'en suis fier.Le laisser sans conseils ferait beaucoup de mal.
@G_H Il n'y a aucun mal à exprimer vos inquiétudes à votre patron, mais en fin de compte, il prendra la décision qu'il jugera la meilleure pour l'entreprise.Qu'il prenne la bonne décision ou non n'est pas votre préoccupation.
@G_H, semble que vous avez peut-être tenu ce projet de près jusqu'à ce point.Bien que vos préoccupations soient valables, toutes ces raisons s'appliquaient bien avant que vous ne donniez votre avis, les avez-vous déjà soulevées?
MechMK1
2019-05-17 18:54:32 UTC
view on stackexchange narkive permalink

Les problèmes causés par votre départ de l'entreprise ne sont pas votre problème.

Clairement et simplement. C'est quelque chose que les managers aiment à revendiquer lorsque les employés quittent l'entreprise, et d'ailleurs, les managers qui font de telles déclarations sont aussi ceux qui doivent les prononcer le plus. Cela étant dit, supposons que votre manager est simplement mal avisé et ne veut pas être malveillant.

Vous pouvez lui expliquer que votre temps est mieux consacré à la documentation qu'à un nouveau projet. Si vous travaillez sur la documentation, vous laisserez derrière vous un produit utilisable avec des développeurs compétents, qui comprennent exactement ce qu'il fait et comment il fonctionne.

Si vous travaillez sur votre nouveau projet, vous devrez soit précipiter le développement (résultant en un mauvais travail) ou vous abandonnerez à mi-projet (résultant en beaucoup de temps perdu à acquérir des connaissances qui sont effectivement perdues pour l'entreprise).

En fin de compte, peu importe la décision de votre patron , c'est leur problème, pas le vôtre. S'il fait un mauvais choix, ce n'est pas de votre faute.


Que se passe-t-il si votre patron ne coopère pas?

Dans un monde parfait, votre manager serait raisonnable et comprendrait que laisser votre lieu de travail intact est le meilleur plan d'action. Nous savons tous que nous ne vivons pas dans un monde parfait, et dans certaines entreprises, la politique semble être de réduire le plus possible le travail de départ des employés - après tout, ils partent de toute façon, alors peu importe si leur moral est faible.

Afin de vous préparer à ce scénario, voici quelques informations courantes que vous pourriez entendre lorsque vous discuterez avec votre responsable de la façon dont vous devriez passer vos dernières semaines dans l'entreprise:

Si vous nous quittez maintenant, l'entreprise fera faillite!

Ce n'est pas votre problème. Vous êtes (ou étiez) un employé, pas un actionnaire ou un propriétaire. En tant qu'employé, votre tâche n'est pas de maintenir l'entreprise à flot ou de réussir, et en tant que tel, vous ne devez pas non plus prendre la responsabilité de ne pas le faire.

Il y a une date limite et vous devez remplissez-le.

Non. Ce délai n'est tout simplement pas votre problème. Votre responsable essaie de vous tirer le maximum de travail pendant que vous êtes encore ici.

Bien qu'il puisse être souhaitable de garder votre réputation d'employé aussi bonne que possible, dans certains cas, les exigences de la direction sont justes trop déraisonnable pour se rencontrer. Dans de tels cas, il vaut mieux ne pas vous stresser, manquer la date limite et laisser le désordre derrière vous. Oui, votre ancien patron vous reprochera tout (même les choses avec lesquelles vous n’avez rien à voir), mais dans de tels cas, tous les autres anciens employés sauront probablement que ce patron est similaire.

Je pensais mieux à vous que vous nous laisseriez en suspens.

Juste une insulte personnelle. Suivant.

Que devons-nous dire au client? Ils vous attendaient sur le projet!

Ce n'est pas encore votre problème. Si le client «s'attendait» à ce que vous soyez sur le projet, alors c'est sa faute d'avoir des attentes qui n'ont pas été clairement formulées lors des discussions de vente. Si vous avez été personnellement vendu au projet après avoir annoncé votre démission, la personne qui vous a vendu a commis une erreur. Ne laissez pas "J'ai fait une erreur, maintenant vous devez la réparer!" prendre le meilleur de vous.

Je ne vois pas vraiment comment cela s'applique.Il n'y a rien dans la question initiale qui suggère que le patron blâme le PO pour quoi que ce soit, ou que la culpabilité les fait trébucher ou leur dit qu'ils ne peuvent pas partir.Tout cela semble être une diatribe sans rapport avec ce qui est demandé.
La question est toujours "Comment convaincre mon patron?", Et je pense qu'il n'est pas nécessaire d'essayer.Si son patron prend la mauvaise décision en lui assignant la mauvaise tâche, alors c'est la faute du patron.
Ce peu, je ne peux pas discuter avec.
@MechMK1 Votre dernier commentaire est le point de BittermanAndy.La question est "Comment convaincre mon patron?"La première moitié de votre réponse n'est pas liée à la question.Vous jetez des hypothèses et y répondez ... tenez-vous-en à répondre à la question comme vous l'avez fait dans la seconde moitié.
@JeffC Je suis d'accord d'où vous venez.Cependant, je crois toujours que cette préface ajoute de la valeur à la question et à la situation en cause, car ce sont des déclarations qui se posent souvent dans de telles situations.Si vous pensez le contraire, veuillez suggérer une modification de ma réponse.Je ne connais pas assez la culture de ce sous-site pour savoir à quel point les réponses sont censées être concises.
@MechMK1 Si c'était moi, je déplacerais la moitié inférieure vers le haut ... mettre la réponse directe en premier.Dans la moitié inférieure, mettez quelque chose comme ... "Voici quelques commentaires que vous pourriez entendre et comment les traiter:" et ensuite les lister.De cette façon, il y a plus de contexte dans cette partie de votre réponse.
@JeffC J'ai restructuré la réponse pour être, espérons-le, plus cohérente.
@MechMK1 me semble bien.Pour être clair, je ne pense pas que votre réponse initiale était incohérente, j'ai simplement pensé qu'elle pourrait être améliorée pour être plus claire.Je pense que les arguments que vous avez soulevés étaient valables, c'était juste moins pertinent ... du moins l'OMI.
Merci @JeffC.Je suis toujours ouvert aux commentaires.
TessellatingHeckler
2019-05-18 00:36:41 UTC
view on stackexchange narkive permalink

Il est clair que mon patron s'attend à ce que je commence le plus rapidement possible, que je mette l'autre développeur au courant et qu'il apprenne et documente au fur et à mesure.

On dirait que votre patron s'attend à ce que vous passiez une partie de votre période de préavis à créer de la documentation, donc votre patron n'est pas contre la documentation par principe. Le nouveau développeur pourrait-il être celui qui demandera à votre patron de se concentrer davantage sur la documentation? Votre patron a peu de raisons de considérer votre désir pour l'avenir du projet parce que vous partez, mais il a beaucoup de raisons de considérer les besoins du développeur qui y travaillera.

Même si je l'ai fait, je ne peux pas m'attendre à ce qu'il se souvienne de tout ou le saisisse immédiatement. Si je pouvais utiliser le reste de ma période de préavis pour créer des guides d'utilisation et de développement détaillés, cela lui laisserait du matériel de référence solide ainsi que tous les futurs développeurs et utilisateurs.

Si vous ne le faites pas avoir le temps de faire une bonne documentation, pourriez-vous enregistrer une vidéo de vous en train de parcourir le projet, en parlant de la conception? De préférence, vous et le nouveau développeur en discutez, ou simplement vous parlez avec un tableau blanc.

Ce serait mieux que rien, beaucoup plus rapide que d'écrire une documentation claire de qualité de production avec des liens fonctionnels et des diagrammes bien rangés, etc. Il ne faudrait pas que quiconque se souvienne de ce que vous dites après une audience, car il peut être rejoué et mis en pause. Vous n’avez pas besoin que quiconque prenne des notes au fur et à mesure, vous pouvez donc couvrir plus de sujets en moins de temps, etc.

Procurez-vous un smartphone ou une webcam, réservez une salle de réunion pendant 30 minutes et enregistrez. Faites de même le lendemain, pour les questions et les confusions qui ont surgi depuis la veille. Si vous pouviez faire quelques sessions en 13 semaines, cela pourrait être un équilibre utile entre aucune documentation et une documentation idéale.

Yakk
2019-05-18 01:34:31 UTC
view on stackexchange narkive permalink

C'est fondamentalement l'appel de votre patron quant à l'effort que vous consacrez à la documentation à ce stade.

Sur le plan professionnel, il est bon de ne pas vouloir que votre projet brûle après votre départ.

Cependant, vous avez demandé quelque chose pour convaincre votre patron. Je pourrais essayer quelque chose comme ceci:

En règle générale, un développeur professionnel atténue continuellement les événements "touchés par un bus" - les développeurs disparaissent (y compris eux-mêmes). C'est l'une des raisons pour lesquelles j'ai mis à jour et conservé la documentation écrite sur ce projet. L'étendue de cette documentation, le travail qui y est consacré, tenait compte du fait que le risque que je sois "heurté par un bus" ou que je disparaisse d'une autre manière en un mois était faible.

Le gain d'un L'unité de documentation était Chance (je disparais) fois Coût (Manque de documentation). Le premier terme étant faible, je me suis concentré sur la documentation la moins chère et la plus rentable.

Maintenant, les chances que je sois bientôt parti sont de 100%.

Cela signifie la matrice des gains de la documentation a changé.

Investir beaucoup plus dans la transition pourrait faire une énorme différence à ce stade. Et vous n'aurez pas une autre chance à cette information.

Je peux et me concentrerai sur la livraison de ce prochain projet, comme demandé. Cela générera probablement des revenus à court terme. Mais il y aura une opportunité de réduction des coûts à long terme perdue.

Je comprends l'un ou l'autre choix, mais je voulais que le choix soit clair. Les revenus à court terme sont importants; c'est ainsi que nous restons en affaires. Mais en échange, vous acceptez des problèmes croissants de maintenance du produit et / ou vous constaterez que d'autres modifications sont beaucoup plus coûteuses à l'avenir.

Je livrerai avec enthousiasme et professionnalisme en fonction de votre choix.

Acceptez maintenant vraiment et honnêtement que le Boss peut vouloir choisir les bénéfices à court terme plutôt que la douleur à long terme. C'est une décision commerciale valable. Les entreprises qui choisissent régulièrement le plus long terme sur le court terme font cette chose appelée «faire faillite», et les projets qui le font sont annulés.

Même si le patron fait le mauvais choix, vous avez expliqué la situation comme vous Comprenez-le, et ce ne sera pas de toute façon votre responsabilité formelle dans un mois.

Vous vous souciez de votre projet, et c'est à la fois admirable et acceptable. Mais ce n'est plus votre projet, si jamais ça l'a vraiment été.

Player One
2019-05-17 19:45:42 UTC
view on stackexchange narkive permalink

Utilisez une partie de votre temps pour implémenter le produit chez votre nouveau client pour documenter la manière dont il doit être implémenté et les choix que vous avez faits lors de sa mise en œuvre.

Cela profitera:

  • Votre nouveau client - car il trouvera désormais plus facile d'intégrer votre remplaçant
  • Votre ancien client et collègue - car ils peuvent également l'utiliser comme transfert pour l'implémentation des anciens clients ( puisque vous dites dans les commentaires qu'il y a beaucoup de chevauchements)
  • Votre (bientôt) ancien employeur - car leurs deux clients apprécieront tous les deux vos efforts
  • Vous - grâce aux références et à la réputation que vous obtiendrez en étant professionnel au cours de vos dernières semaines.

Ne vous inquiétez de rien d'autre - votre responsabilité n'est pas du succès futur de votre ancienne entreprise, c'est pour rester professionnel en partant.

Il y a un œil attentif sur la façon dont le temps est passé.Pour chaque aspect de la mise en œuvre, il y a des problèmes Jira et des estimations de temps.Cela pourrait très bien fonctionner si je pouvais intégrer le temps nécessaire à la documentation dans les estimations et indiquer clairement que cela fera avancer à la fois le nouveau projet et le transfert des connaissances.Je vais essayer ça!
cdkMoose
2019-05-17 21:49:45 UTC
view on stackexchange narkive permalink

Ce n'est pas à vous de convaincre votre responsable de la gestion de son équipe / service. Il n'y a rien de mal à faire part de vos préoccupations une fois, mais restez-en là.

C'est à votre responsable et à votre employeur de déterminer la meilleure utilisation de votre temps restant. S'ils estiment que la génération de revenus ou les délais des clients sont plus importants que cette documentation, acceptez-les et faites de votre mieux avec les tâches qui vous attendent. Tout comme vous devriez le faire même si vous n'avez pas donné d'avis.

bremen_matt
2019-05-17 23:18:02 UTC
view on stackexchange narkive permalink

Si vous voulez vraiment convaincre votre patron, le meilleur moyen est indirectement. Discutez peut-être de ce problème avec la personne censée vous remplacer et demandez-lui de parler au patron. Vraisemblablement, votre remplaçant reconnaîtra qu'il y a beaucoup à apprendre et implorera le patron de la documentation.

Si cette personne ne semble pas non plus s'en soucier, alors vous avez fait tout ce que vous pouvez faire ...

dmoore1181
2019-05-18 00:36:33 UTC
view on stackexchange narkive permalink

Comme les autres réponses l'ont souligné, ce n'est pas quelque chose dont vous devriez vous inquiéter. Tant que vous avez parlé à votre direction et lui avez dit quelles sont vos opinions, ce sont eux qui sont en charge et ceux qui devront répondre à leurs supérieurs quand / s'ils prennent la mauvaise décision.

J'ai été dans une situation très similaire. La dernière entreprise pour laquelle j'ai travaillé était le développeur senior qui était là depuis 6 ans, mes collègues y étaient depuis moins d'un an et ne se concentraient pas sur la principale ligne d'application commerciale, donc je ne savais pas trop comment le les affaires réelles ont fonctionné. Lorsque j'ai remis mon avis, j'ai également envoyé une lettre avec une stratégie de sortie comprenant plusieurs heures de formation sur tous les grands domaines de l'entreprise pour les développeurs restants (seulement 2). Au lieu de cela, mon directeur de patrons voulait que je termine un projet qui, bien qu'important, aurait pu être achevé à tout moment au cours des prochains mois. J'ai procédé à la réalisation de ce projet et leur ai donné mon numéro de téléphone avec un taux horaire au cas où ils auraient besoin d'aide après les heures.

En fin de compte, tout a fonctionné, ils ont rencontré des pierres d'achoppement et l'équipe de direction sait pourquoi. Il est toujours difficile de quitter un projet auquel vous avez consacré des années de votre vie, mais si vous êtes capable de le laisser avec une bonne équipe de développeurs, ils finiront par le comprendre.

Petro Korienev
2019-05-18 01:36:55 UTC
view on stackexchange narkive permalink

Répondre à votre question exacte ("Comment convaincre mon patron ...") est assez simple.

Montrez ceci à partir d'une perspective financière. Calculez les efforts supplémentaires pour que les autres développeurs interviennent et les pertes potentielles d'argent, et laissez le patron décider de ce montant d'argent. Calculez la valeur que vous apportez pour atténuer ces pertes. Calculez la valeur que vous apportez en travaillant sur un nouveau projet et apportez ces deux valeurs à votre patron. Convainquez avec les chiffres - les mots sont ambigus, les chiffres ne le sont pas.

Conseil: probablement, après le calcul, vous découvrirez que vous travaillez sur un nouveau projet apporte plus de valeur à l'entreprise et vous n'aurez pas besoin de convaincre votre patron

Indice 2: Vous pourriez avoir de fausses hypothèses sur les pertes - probablement, votre client sera facturé pour tous les efforts supplémentaires que le nouveau développeur doit déployer pour que les choses fonctionnent et l'entreprise ne perd pas quoi que ce soit

Indice 3: Votre citation «c'est mon idée» révèle votre attitude personnelle face à un problème, vous pourriez donc être mal orienté dans l'évaluation et la prise de décision dès le début - vous prenez cela personnellement

Indice 4: comme d'autres réponses l'ont dit, ce n'est pas votre responsabilité. Le transfert des connaissances et la contingence commerciale sont à la discrétion de votre patron.

Bonne chance dans votre nouvelle entreprise!

mathreadler
2019-05-18 21:07:18 UTC
view on stackexchange narkive permalink

Votre temps de travail est payé par votre entreprise, il est donc raisonnable et probablement même légiféré de décider de ce que vous faites pendant cette période.

Si vous avez de la chance, ils réaliseront à quel point c'était stupide vous laisser partir sans documentation et vous demander ensuite de revenir.

Habituellement, au cours de la première action, vous réalisez plusieurs améliorations architecturales qui peuvent être apportées par la suite, mais uniquement avec retravailler ou même repartir de zéro. S'ils ne veulent pas que vous reveniez, si vous avez économisé de l'argent, vous pouvez réécrire votre cerveau enfant par vous-même. (Je suppose ici que c'est un logiciel). Peut-être que vous pouvez le faire en vous employant vous-même.

Que cela puisse arriver est un risque que chaque employeur prendra en vous retirant du contrat.

Je ne lâche pas prise, j'ai pris la décision de partir.Si quelque chose j'aimerais éviter que cela ne revienne me hanter.De plus, je pense que quitter une entreprise et ensuite créer votre propre projet basé sur l'architecture établie dans cette entreprise pourrait être illégal ou en violation du contrat (dont certains aspects continuent d'être en vigueur après le départ).
@G_H Eh bien .. d'accord.Alors je suppose que vous auriez dû y réfléchir avant de signer ou de partir.Si vous réécrivez tout tant que les brevets logiciels ne sont pas en vigueur dans votre législation et que l'entreprise ne les a pas brevetés, pour autant que je sache, ils ne peuvent rien faire.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...