Question:
Mon patron devrait-il apprécier le travail que personne n'a demandé?
Eric97
2019-01-29 22:50:43 UTC
view on stackexchange narkive permalink

Ma question
Mon patron devrait-il apprécier quelque chose que j'ai fait pour augmenter la productivité, mais qui ne fait pas nécessairement partie de mon travail ou de quelque chose qu'on m'a demandé de faire?

À propos de mon travail
Je travaille en tant que technicien de fabrication dans une grande entreprise et mon travail consiste à surveiller, configurer et travailler avec des machines CNC, comme dans une production de masse. C'est très monotone et répétitif, alors j'ai pensé à un moyen de rendre mon travail un peu plus facile.

En raison de mon intérêt général pour la programmation, j'ai commencé à apprendre C #, SQL et la programmation "approfondie" de nos machines cnc Siemens au cours de la dernière année.

J'ai écrit une application C # solide (à mon avis) et apporté quelques modifications à nos machines, ce qui augmente la productivité globale de mon département. L'application effectue tous les travaux répétitifs, facilite la configuration et la surveillance des machines et réduit les pièces rejetées en raison d'une erreur humaine.

Nous avons doublé notre production de pièces et réduit le temps de configuration, etc. En fait, un opérateur peut désormais travailler avec deux machines au lieu d'une seule.

Néanmoins, cela ne fait pas partie de mon travail ou de mon apprentissage. Personne ne m'a demandé de faire ça. Je l'ai fait pour rendre mon travail plus intéressant et parce que c'était amusant d'écrire le code de l'application, d'automatiser le processus et d'améliorer tout le concept.

Contrairement à mes collègues, mon patron n'apprécie pas vraiment le travail que j'ai fait en dehors de mon travail réel. Mais je serais heureux avec une sorte de petite appréciation. Ne vous méprenez pas, je ne veux pas d'augmentation ou quelque chose du genre. Un petit "bon travail" et une poignée de main suffiraient.

Est-ce que j'en demande trop?

Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (https://chat.stackexchange.com/rooms/89160/discussion-on-question-by-eric97-should-my-boss-value-work-nobody-asked-for).
Sept réponses:
#1
+24
Homerothompson
2019-01-29 23:03:02 UTC
view on stackexchange narkive permalink

Dois-je trop demander?

Non, vous ne le faites pas. Vous avez augmenté les performances de votre entreprise, ce qui devrait avoir un impact sur les chiffres, ce qui est tout ce dont la direction se soucie généralement.

Je vous recommande de préparer un petit rapport dans lequel vous expliquez ce que vous avez fait et quelle a été l'amélioration que vous avez obtenue. vous pouvez demander à votre patron si ce genre d'initiative est encouragé ou non. Sur cette base, vous pouvez déterminer si vous travaillez au bon endroit en fonction de vos attentes professionnelles.

Si j'étais votre patron, non seulement je vous féliciterais et essayerais de vous obtenir un bonus, mais j'essaierais aussi vendre à la haute direction les choses qui se passent dans mon équipe

Je pense que je vais essayer cela dans l'une de nos "évaluations de performances personnelles", car je pense que mon patron est généralement ouvert à des améliorations dans notre département / entreprise.Merci pour le conseil.
@Eric97 Assurez-vous que vous avez bien documenté vos améliorations afin que quelqu'un d'autre puisse facilement prendre le relais de vous.Non pas que je m'attends à ce que vous soyez licencié, mais pour montrer davantage que vous faites vraiment cela pour le bénéfice de l'entreprise et non pas pour créer votre propre «royaume» de travail.
Vous voudrez également documenter toutes les étapes nécessaires pour préparer cette production et mettre en évidence les risques et les atténuations potentielles.Assurez-vous que votre patron en est conscient et qu'il les approuve.Sinon, les points positifs pourraient rapidement devenir très négatifs un jour si quelque chose ne va pas (voir ma réponse ci-dessous).
#2
+11
ShinEmperor
2019-01-30 00:02:01 UTC
view on stackexchange narkive permalink

Premièrement, bon travail.

Je ne m'attends pas à ce que vous choisissiez ma réponse comme réponse, c'est juste une perspective différente.

Dans général, prendre des initiatives est une bonne chose. Cela montre que vous êtes intéressé par votre travail et le travail que l'équipe doit faire. Vous êtes prêt à faire une différence qui compte et vous êtes prêt à apporter des changements pour améliorer les choses dans l'ensemble.

Mais ... Il y a quelques inquiétudes à ce sujet ...

Tout d'abord, le logiciel. Il est conçu et construit par une seule personne. Ma première préoccupation est la suivante: est-il bien testé? Y a-t-il eu un vrai contrôle qualité? Est-ce efficace? Tient-il compte de toutes les possibilités. Sans connaître le logiciel lui-même et le contexte de sa mise en œuvre. Ma première pensée est ".. le logiciel est-il prêt?"

Deuxièmement, il y a quelques problèmes interpersonnels. L'un d'eux est que si le travail de deux hommes peut maintenant être fait par un seul, cela signifie que la direction peut réduire le personnel. Maintenant, vous pouvez ou non vous en soucier, c'est bien. Mais avoir la réputation de réduire les moyens de subsistance des gens peut être difficile. Je sais que c'est l'économie, mais quand même. Les collègues pourraient ne pas célébrer votre réussite si vous êtes allé de l'avant et mettez vos collègues au chômage. La direction vous aimera et cela pourrait être une bonne chose. Je ne dis pas que tout cela est le cas, mais je pourrais certainement voir que c'est le cas. Rappelez-vous toujours que l'efficacité et l'automatisation ne sont pas «gratuites», quelqu'un paie pour cela et c'est la manière du monde. Mais tout le monde ne s'en réjouira pas, et à juste titre.

Troisièmement, ils n'ont pas demandé pourquoi devraient-ils recevoir. Le travail bénévole est une chose délicate. Si un changement que vous apportez a un impact considérable et fait une énorme différence en termes de productivité et d'efficacité, alors le gestionnaire doit l'expliquer à quelqu'un. En surface, cela peut sembler une bonne chose. Parfois, les cadres supérieurs n'aiment pas les gens qui prennent de telles initiatives parce qu'il y a généralement un protocole en place pour faire quelque chose comme vous. Donc, tous les gestionnaires ne seront pas satisfaits de ce que vous avez fait et je sais pertinemment qu'il y a des gestionnaires qui voudraient que vous inversiez le processus. Parce que les organisations sont souvent accrochées au processus, pour de bonnes ou de mauvaises raisons.

Je ne dis pas que vous ne devriez pas vous attendre à un "merci". Je dis, nous devons toujours être prudents lorsque nous essayons de «faire le bien». Les meilleures intentions peuvent conduire à des incitations très étranges.

Alors gardez cela à l'esprit. Devriez-vous vous attendre à un merci? Cela dépend de combien vous avez rendu la vie de votre manager plus difficile ou plus facile. Fournir ce qui n'a pas été demandé n'est pas toujours une bonne chose.

Tout d'abord, merci pour tous les différents avis et commentaires.J'apprécie vraiment cela!1) Le logiciel a été écrit par moi-même et je l'améliore continuellement et j'ajoute de nouvelles idées.Je valide chaque saisie utilisateur et avec l'aide de mes collègues j'essaye de trouver le plus de bugs possible.Pour être honnête, l'application est un peu exagérée pour ce qu'elle est censée faire (cadre d'interface utilisateur, MVVM, async / await), mais en écrivant cette application, j'ai appris C #.2) À ce moment-là, notre ministère manquait un employé à chaque quart de travail, donc heureusement, personne n'a besoin d'être congédié ou autre chose.
Néanmoins, je ne suis pas à proximité d'un développeur de logiciels, c'est juste l'un de mes hobbies!Mais pour la tâche qu'il est censé faire et pour les problèmes de connexion de plusieurs machines différentes, le logiciel fonctionne très bien.
Je pense que c'est la meilleure réponse.Je pense que l'initiative d'OP est formidable et hautement louable, mais ce genre de choses comporte des risques importants.Je le sais par expérience ayant pris des initiatives similaires à plusieurs reprises avant moi (pas avec des processus de production, mais avec des systèmes purement logiciels) et ce que j'ai appris est le suivant: il est facile d'obtenir un prototype qui fonctionne 80 à 90% du temps,mais ces derniers 10 à 20% sont incroyablement difficiles à atteindre et provoquent la découverte de failles cruciales dans le prototype.En général, le résultat de mes expériences "hé regarde ce que j'ai construit" a échoué, parfois assez mal.
Mon conseil à OP: 1) continuez l'initiative!2) Parlez à votre patron ou à toute autre personne appropriée pour discuter du QA nécessaire pour vous assurer que votre solution est vraiment prête pour la production (y compris établir un processus de gestion des temps d'arrêt / pannes avec vos nouveaux composants)Il peut également y avoir des considérations de formation.En gros, je pense que vous voulez qu'ils sachent que vous avez introduit des risques et que ce que vous avez fait nécessite une assurance qualité supplémentaire.Parce que vous * voulez * qu'il obtienne ce contrôle qualité.Tous les logiciels prêts pour la production sont soumis à un contrôle qualité massif.Le vôtre doit aussi.Sinon, il échouera gravement un jour.
Et 3) à l'avenir, assurez-vous que vous créez un prototype dans un environnement à faible risque, pas en production, et assurez-vous que la direction est consciente et approuve tous les risques à la fois lors de la création d'un prototype et en particulier lors de sa mise en service.en production.
#3
+5
teego1967
2019-01-30 00:45:24 UTC
view on stackexchange narkive permalink

Mon patron devrait-il apprécier quelque chose que j'ai fait pour augmenter la productivité, mais qui ne fait pas nécessairement partie de mon travail ou quelque chose qu'on m'a demandé de faire?

La réponse à cela, pour de nombreux lieux de travail, c'est «non».

La direction fera souvent semblant d'encourager les «auto-entrepreneurs» et les personnes qui prennent des initiatives sans qu'on leur dise quoi faire, mais quand cela se produit, certains ont problèmes avec cela.

Pour une chose, de nombreux gestionnaires qui utilisent une approche "commande et contrôle" (les ateliers d'usinage sont certainement de cette façon dans mon expérience), n'aiment pas quand des choses se produisent qui ne sont pas planifiées - même s'ils sont bons.

En regardant cela de leur point de vue, ils sont sur la ligne si quelque chose ne va pas. Une application «voyou» écrite par un apprenti qui contrôle des machines coûteuses soulèvera certainement des inquiétudes. Que se passe-t-il lorsque vous partez et que tout le monde est devenu dépendant de votre candidature? Que se passe-t-il si les machines sont mises à jour et que votre application ne peut plus fonctionner avec elles? Qui appellent-ils dans 5 à 10 ans si l'application doit être mise à jour? Ces endroits attendent des SLA pour leurs machines, ils ne peuvent pas se permettre d'avoir une "ligne vers le bas" pour embaucher un consultant extérieur pour comprendre ce qu'un ancien employé a fait il y a des années (certes - cela se produit plus que vous ne le pensez - je a gagné sa vie en faisant ça une fois!).

Il me semble que votre responsable peut adopter une approche attentiste et formuler une réponse prudente. Il apprécie probablement ce que vous avez fait, mais n'est pas vraiment ravi à l'idée d'avoir une équipe de programmation C # naissante qui grandit spontanément dans sa boutique.

Votre meilleure approche est peut-être de démontrer de manière convaincante comment le l'entreprise peut prendre en charge cette application à l'avenir.

Pour clarifier, je ne suis plus apprenti.Je comprends votre point, mais pour moi, c'était un peu le risque ou le "pari" que je suis prêt à prendre, pour peut-être avoir des chances pour une future promotion.Je ne veux certainement pas rester les 40 prochaines années dans l'atelier d'usinage sur un modèle à 4 équipes et à la même chose encore et encore.L'important pour moi était que tout fonctionne de la même manière sans mes programmes.Donc, si quelque chose se brise et que je ne suis pas là pour le réparer, ils peuvent toujours faire fonctionner les machines comme ils le faisaient à l'époque.Sans les avantages évidemment.
@Eric97, oui, je suis de votre côté sur ce point.J'essaye juste d'expliquer leur point de vue (comme je l'imagine).Vous avez peut-être raison de dire qu’ils peuvent toujours «revenir» à l’ancienne façon de procéder, mais personne n’appréciera de le faire si cela signifie une baisse de productivité.D'une certaine manière, vous leur forcez la main et créez une dépendance.
#4
+4
bob
2019-01-30 02:38:26 UTC
view on stackexchange narkive permalink

Votre initiative est louable, alors continuez (avec des mises en garde)!

L'initiative est géniale! C'est un atout majeur pour toute entreprise. Mais il est important de reconnaître que l'initiative a tendance à introduire des risques (je parle d'expérience!). L’objectif est de pratiquer l’initiative de manière à sensibiliser votre chaîne de gestion aux risques à l’avance et à leur donner l’opportunité de valider et d’atténuer les risques, ou de les rejeter, auquel cas vous vous retirez. Vous ne voulez pas prendre de risques en leur nom à leur insu. Ce genre d'initiative, bien que bien intentionnée, peut vous causer des ennuis.

Pourquoi votre patron ne vous dit-il pas merci?

Il existe des possibilités raisonnables:

Votre solution n'a peut-être pas aidé votre patron

Votre solution n'augmente peut-être pas une mesure de performance clé pour votre patron. Ou peut-être que cela lui a causé plus de travail. Ou même simplement plus de stress.

Votre solution peut ne pas aider l'entreprise à long terme

Prototypes, que toute solution qui n'a pas été minutieusement testée est , introduisent un risque important. Finalement, ils devront être préparés à la production ou remplacés par quelque chose qui est ou simplement mis hors service. N'importe lequel de ces processus pourrait prendre beaucoup de temps et d'argent et entraîner des interruptions de production au pire moment possible. Il y a donc une chance, et assez élevée, que cette solution finisse par s'avérer être un passif net pour l'entreprise (même si la solution pouvait aider l'entreprise à long terme, cela pourrait coûter plus cher que ce que l'entreprise veut) investir pour préparer le prototype à la production, et le faire sans approbation pourrait leur forcer la main). Cela ne dit rien sur vos compétences (bien que la méconnaissance des outils augmente les risques), c'est juste un truisme que la mise en production d'un prototype va presque toujours causer des problèmes à un moment donné.

La communication est essentielle

Un des points clés à retenir est que l'initiative est bonne lorsqu'elle est associée à une bonne communication à l'avance. Vous devez informer votre supérieur de tous les risques potentiels liés à ce que vous voulez faire avant de le faire et lui permettre de signer, d'atténuer ou de rejeter ces risques (dans ce dernier cas, vous vous retirez et ne faites pas ce que vous vouliez). Il est également très important que votre patron comprenne l'état de votre logiciel avec une précision totale. S'il s'agit d'un prototype, le patron doit comprendre qu'il n'est pas prêt pour la production.

Que faire ensuite

Dans votre cas actuel, je vous recommande fortement de parler avec votre patron, d'expliquer ce que vous avez cherché à faire, d'expliquer ce que vous avez fait, de discuter des avantages quantitativement, de discuter de l'actuel des efforts pour le préparer à la production, ainsi qu'une évaluation complète et honnête de sa situation dans ce continuum. Demandez si votre patron souhaite continuer à l'utiliser, et si oui, quelles mesures supplémentaires d'AQ (le cas échéant) sont nécessaires, quelle documentation est nécessaire, quelles approbations juridiques le cas échéant et quels ajustements de processus sont également nécessaires être sur appel en cas de problème avec le programme à 3h du matin pendant une production?).

Mais ma solution fonctionne!

Pour l'instant, oui. Peut-être que ce sera pour toujours. Mais à moins que vous ne l'ayez déjà entièrement prêt pour la production, ce qui semble être un peu compliqué à moins que ce ne soit très simple ET à moins que toutes les mises à jour requises du processus de production aient également été effectuées (QA, procédural, juridique, documentation, personnel, etc.) alors la probabilité est (et je parle d'expérience à ce sujet) qu'elle échouera à un moment donné, et au fur et à mesure que la production sera prête, elle échouera de plus en plus de manière assez laide. C'est un piège malheureux pour les programmeurs que la mise en place d'une solution à 80% est rapide et facile, et il semble donc que la création d'une solution prête pour la production sera également rapide et facile. Et même qu'une solution à 90% pourrait être prête pour la production sans trop de risques. Ce n'est tout simplement pas vrai. J'ai une poignée d'échecs sous ma ceinture pour soutenir ce que je dis. Apprenez de mes erreurs et attendez-vous à ce que celle-ci échoue. Faites tout ce que vous pouvez maintenant pour éviter ou atténuer cet échec. Au minimum, votre patron doit savoir et comprendre parfaitement ce qui s’est passé et tous les risques encourus. C'est la clé. Ce sera inconfortable, mais c'est mieux que d'attendre après un échec majeur pour vous expliquer à votre patron.

Conclusion

Je n'arrêterais pas de prendre des initiatives et je ne demanderais pas non plus pour un "merci". Au lieu de cela, je ferais tout mon possible pour éviter que cela ne devienne une responsabilité pour l'entreprise et je m'assurerais la prochaine fois que je communiquerai avec mon patron dès le départ.

Je ne pourrais pas être plus d'accord.Malheureusement, OP est actuellement en mode de contrôle des dégâts, mais pour l'avenir, c'est une bonne leçon.
@JoeStrazzere J'ai édité ceci pour souligner plus fortement votre point.
#5
+3
Dan
2019-01-29 23:06:35 UTC
view on stackexchange narkive permalink

Pensez-y en termes de logiciel que vous pourriez utiliser. Beaucoup d'efforts et d'heures supplémentaires ont été consacrés à la livraison du produit final. Plus encore, après la sortie, les gens peuvent parfois faire des heures supplémentaires pour livrer le produit. Pourtant, personne ne remercie l'équipe de développement lorsque cela se produit. Les gens pourraient être plus indignés ou même passer à un produit concurrent en cas de problème. Ils pourraient s'en moquer si quelqu'un y passait 50 ou 1000 heures. Ils s'en moquent si vous perdez votre conjoint et que vous devez maintenant traverser une dure bataille de divorce et que votre enfant grandira sans savoir qui est papa.

Cela dit, je ne pense pas que votre patron va s'en soucier maintenant ou même dans le futur. Je pense aussi que si quelque chose ne va pas, vous pourriez avoir des ennuis en tant que «dernier gars à avoir joué avec ça». Même si votre programme n'a jamais touché ces parties.

#6
+1
Ben Barden
2019-01-29 23:04:52 UTC
view on stackexchange narkive permalink

Votre tâche en valait la peine, comme vous pouvez le constater d'après l'appréciation de vos collègues. Il y a certainement des patrons qui apprécieraient et apprécient de telles choses. Votre patron ne semble pas être l'un d'entre eux, cependant, et ce n'est pas injuste. Après tout, on ne vous a jamais demandé de le faire et, apparemment, vous n'en avez même pas discuté avec lui pendant que vous y parveniez.

Maintenant, si votre question portait sur "comment puis-je obtenir la reconnaissance pour ce?" il y a certaines choses que vous pouvez faire, mais vous n'êtes pas dans une position où il est raisonnable de exiger quoi que ce soit.

#7
+1
Old_Lamplighter
2019-01-29 23:16:33 UTC
view on stackexchange narkive permalink

L'auto-promotion n'est pas une mauvaise chose. C'est ainsi que vous progressez.

Parlez-en simplement à votre patron.

Hé! Patron! J'ai trouvé un moyen de faire XYZ en moins de temps! Puis-je vous montrer?

Puis une démonstration s'il le demande.

Soit il l'appréciera, soit il ne l'appréciera pas, mais vous avez obtenu l'information Là. Cela peut ou non vous aider dans ce travail, mais vous avez une attitude saine qui, sinon chez votre employeur actuel, vous aidera à faire progresser votre carrière au cours de votre vie.

Continuez comme ça!

Merci pour le conseil!Je vais combiner cela avec la réponse @Homerothompson.Je ne veux pas me promouvoir moi-même d'une manière mauvaise et arrogante.
@Eric97 La manière de se promouvoir dans le bon sens est de suivre la règle de la CAR, qui signifie Challenge, Action, Résultat.Mettez les choses de cette façon, et vous n'aurez jamais l'air mal."J'ai vu que c'était lent, j'ai écrit du code, maintenant c'est plus rapide".Pas moyen de rendre ça mauvais


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...