Personnellement je trouve cela absurde de le licencier certes il ne foutait rien mais il faisait son boulot quelques part et donc on ne peu pas lui reprocher sa ...
Version imprimable
Personnellement je trouve cela absurde de le licencier certes il ne foutait rien mais il faisait son boulot quelques part et donc on ne peu pas lui reprocher sa ...
Ben, moi quand j'ai rien à foutre au boulot je vais mendier du travail sur d'autres projets.Citation:
Envoyé par Xecain
Je le fais à la cool, c'est à dire que je prend le temps de venir sur dvp, de glander sur le net, mais j'essaye quand même d'avoir des activités professionnelles dans ma journée... c'est quand même pour ça qu'on est payés, et derrière je peux argumenter pour des augmentations.
Bonjour,
Normalement, s'il avait programmél'ordinateur pour faire son boulot, il devait demander à son chef un travail à la hauteur de ses compétences et montrer son travail à son chef .
Je pense que ce n'est pas le faite d'avoir programmé un robot c'est le faite de ne rien faire qui lui a valu son poste
Que pensez-vous ?
Salutations
Même sur Mainframe on peut effectivement automatiser :Citation:
Envoyé par zecreator
- la génération de jeux de données élaborés,
- les lancements de jobs,
- la récupération des résultats,
- la transformation des résultats en données exploitables + facilement.
En clair, vous pouvez effectivement, une fois automatisés, gagner jusqu'à au moins 60% de votre temps. Par contre, jamais 100% je pense.
Exemples (vécus) parmi d'autres sur Mainframe:
- visualisation simplifiée sur micro d'un fichier de suivi mainframe (téléchargement + macro Excel vba)
--- manuellement sur mainframe aurait nécessité 4 écrans tso par résultat unitaire, là une seule feuille de calcul Excel,
- récupération des données d'exploitation des chaines de traitement de la veille par un progiciel et envoi sur une feuille de calcul Excel. Et là une macro déclenchée dans Outlook permettait d'envoyer les résultats formatés aux décideurs.
--- en résumé, un bouton d'une feuille excel à cliquer le matin en arrivant, et tout s'enchaînait. Gain de temps - 1/2h à 3/4 d'heure !
Autre exemple de programmation pure celui là sur un portage de progiciel de micro vers SAP :
- une macro excel permettait de générer du code selon certaines définitions fonctionnelles à porter. Ensuite, ce code était lancé automatiquement. Le fichier résultat était envoyé à l'équipe réceptrice qui s'occupait de porter le logiciel sur SAP.
En résumé, peu de travail à faire côté ancien logiciel ...
Je pense que si c'est une vraie news, le gars était surtout un testeur. Ce n'est pas le département de l'assurance qualité qui est sensé développer, ou alors pour ses propres besoins. Ce qui pourrait expliquer l'automatisation des tâches.
Lorsqu'un professionnel de l'informatique automatise son travail, qui devrait en bénéficier ? Lui ou son entreprise ?
La question soulève des préoccupations éthiques au sein de la communauté des développeurs
En 2016, une confession anonyme apparaissait sur les réseaux sociaux par le biais d'un développeur faisant usage du pseudonyme FiletOfFish1066 (appelons le FOF) qui prétendait qu'après avoir passé six ans à travailler pour une entreprise technologique réputée dans la région de la baie de San Francisco, il a été remercié dans des circonstances que chacun pourrait qualifier sur le ton qui lui plaît.
Voici un rappel de ce qu'il a affirmé, bien que son histoire n'a pas été prouvée (fable ? Farce ? Histoire vraie ? À chacun de le déterminer) :
Après avoir obtenu un diplôme en sciences informatiques sept ans auparavant, FOF a été engagé dans la section Assurance Qualité d’une entreprise technologique. Pendant les huit premiers mois, il a choisi d’automatiser toutes ses tâches de programmation. Une fois cet ouvrage terminé, il s’est vu avoir beaucoup de temps libre qu’il a employé à faire ce qu’il voulait.
Il explique que « depuis six ans jusqu’à maintenant, je n’ai rien fait au boulot. Je ne plaisante pas. Pendant 40 heures par semaine que je suis allé au boulot, j’ai joué à League of Legends, parcouru les forums, et fait tout ce qui me plaisait. Durant les six années écoulées, je n’ai probablement fait que 50 heures de vrai travail, donc en gros je n’ai rien foutu. Et personne ne s’en soucie vraiment. Les tests ont tous été concluants. Je n’avais pas d’amis au bureau donc personne ne me parlait en dehors de mon boss et, à quelques occasions, des développeurs pour les logiciels que je testais ».
Et combien était-il payé à ne « rien faire » ? L’entreprise lui versait en moyenne 95 000 dollars par an. Ce scénario aurait pu encore continuer si le service informatique ne s’était pas rendu compte de la supercherie qui a été la raison de son licenciement.
FOF a employé un ton marquant son découragement suite à son licenciement dans la mesure où il affirme avoir oublié comment coder, ayant relégué ce travail à un ordinateur pendant six ans et ne disposant donc plus de compétences en développement qu’il pourrait mettre en avant pour obtenir un nouvel emploi. Fort heureusement pour lui, il a fait des économies qui s’élèvent à 200 000 dollars étant donné qu’il vit encore chez ses parents, donc pas d’argent à dépenser sur le loyer.
« Après six ans, je ne sais littéralement plus comment écrire un bon programme. J’ai pratiquement tout oublié. J'ai joué à League of Legends et je n’ai rien fait d'autre. Je suis physiquement en forme, ce qui est un plus, depuis que j’allais en salle de gym tous les jours pendant le travail. Mais je ne sais plus rien sur la programmation ou toute autre chose. J’ai 28 ans, je suis sans emploi (bien qu'ils me donnent trois mois de salaire), et je n’ai pas de compétences. J'ai environ 200 000 dollars dans mon compte bancaire et je vis toujours avec mes parents. Je vis frugalement, donc je ne vais pas mourir de faim ou quelque chose comme ça, et je peux certainement subvenir à mes besoins », a-t-il continué.
Il a également exprimé un vif désir de surmonter ces dépendances et de reprendre sa vie ensemble : « Le moment est venu pour moi de surmonter mon addiction à la bière et à League of Legends… Je vais essayer par la pratique Cracking the Coding Interview ainsi que me plonger dans la lecture de bouquins parlant de structures de données et d’algorithmes. Je vais également postuler à certains emplois. Après y avoir pensé un moment, je crois qu’une fois que je vais étudier tout ce que j’ai oublié, ma motivation va revenir. J’ai toujours aimé le développement logiciel, j’étais juste paresseux ».
Automatiser ses tâches est-il éthique ?
L'histoire est rapidement devenue virale dans les forums technologiques du Web, incitant finalement son protagoniste à supprimer non seulement le message, mais l'intégralité de son compte.
Environ un an plus tard, un internaute répondant au pseudonyme Etherable a posté une requête sur un forum de développeurs pour demander : « Est-ce contraire à l'éthique pour moi de ne pas dire à mon employeur que j'ai automatisé mon travail ? » Ledit développeur a indiqué avoir accepté un travail de programmation qui s'était avéré être une « saisie de données glorifiée » et, il y a six mois, avoir écrit des scripts qui mettaient tout le travail sur pilote automatique. Après cela, « ce qui prenait auparavant un mois au dernier gars, prend maintenant peut-être 10 minutes ». Le travail était à temps plein, avec des avantages sociaux, et permettait à Etherable de travailler à domicile. Le programme a produit des résultats presque parfaits; pour autant que la direction le sache, son employé a simplement fait un travail irréprochable.
Les réactions ont été partagées entre ceux qui estimaient qu'Etherable trichait, ou du moins trompait l'employeur, et ceux qui pensaient que le codeur avait simplement trouvé un moyen intelligent d'effectuer le travail à accomplir. Etherable n'a jamais répondu à la discussion qui a suivi. Peut-être effrayé par l'attention (il faut dire que les médias du monde entier ont repris l'histoire), l'utilisateur a disparu, laissant cette seule contribution à une conversation de plus en plus cruciale sur qui peut automatiser le travail et à quelles conditions.
À un moment où le spectre de l'automatisation de masse hante les travailleurs, des développeurs démontrent comment la menace peut devenir une aubaine lorsqu'elle est prise entre leurs mains, avec ou sans la connaissance de leurs employeurs. Étant donné que FiletOFish1066 et Etherable ont posté de manière anonyme et ont rapidement disparu, aucun des deux n'a pu être joint pour commenter. Mais leurs histoires montrent que l'automatisation du lieu de travail peut prendre de nombreuses formes et être dirigée par des personnes autres que des cadres.
L'automatisation des tâches côté développeurs n'a rien de nouveau
Bien sûr, les développeurs écrivent du code qui automatise leur travail depuis des décennies. La programmation implique généralement l'utilisation d'outils qui ajoutent de l'automatisation à différents niveaux, du formatage du code à la fusion de différentes bases de code. La plupart ne poussent pas à l'extrême l'automatisation complète ou presque complète de leur travail.
Certains développeurs qui font appel à l'automatisation des tâches se sont attaqués par exemple à la gestion des stocks, à la rédaction de rapports, au rendu graphique, à l'administration de bases de données et à la saisie de données en tous genres. Un développeur a indiqué qu'il a également automatisé toute la charge de travail de sa femme.
« Quand j'ai commencé, mon travail me prenait littéralement huit heures par jour », a expliqué un développeur qui a parlé sous couvert de l'anonymat. Il a travaillé pour une grande chaîne d'hôtels d'entreprise qui commençait à informatiser son flux de travail dans les années 90. Il a rapidement reconnu qu'il passait beaucoup de temps à répéter les mêmes tâches, alors il a commencé à apprendre à coder après les heures de travail. « En l'espace d'environ trois mois, j'ai développé un morceau de code dans Lotus [qui était alors un tableur PC populaire] qui non seulement automatise les tâches répétitives individuelles, mais qui automatise efficacement l'ensemble du travail », a-t-il indiqué. Il n'a pas dit exactement à ses patrons ce qu'il avait fait et la qualité de sa vie professionnelle s'est considérablement améliorée.
« C'était bizarre d'avoir du temps libre pendant la journée », a-t-il reconnu. « J'ai passé ce temps à apprendre les autres systèmes de l'hôtel ». Il s'est ensuite rendu utile, aidant la direction à résoudre les goulots d'étranglement de ces systèmes. L'auto-automatisation avait effacé le labeur subalterne, réduit son stress et lui avait permis de poursuivre ses intérêts réels. « En effet, j'ai fait de mon poste quelque chose que j'aime, qui est le dépannage », a-t-il déclaré. Deux semaines avant son départ, il a remis à son patron une disquette chargée du programme et de la documentation sur son fonctionnement. Son patron était contrarié qu'il démissionne jusqu'à ce qu'il lui remette la disquette, lui montre le fonctionnement du programme et lui dise d'appeler en cas de problème. Aucun appel n'est jamais venu.
Un autre individu avait pour tâche de compiler des rapports pour une compagnie d'assurance de Pennsylvanie en 2000 lorsqu'il s'est rendu compte que son travail pouvait être effectué par un programme informatique. « J'étais un débutant à l'époque, avec seulement un an d'expérience en informatique », a-t-il reconnu, lorsqu'il a commencé à écrire du code qui pourrait remplacer son travail. « Il m'a fallu environ un an pour l'automatiser. J'ai toujours pensé que mes patrons seraient impressionnés et trouveraient plus de travail pour moi. Ils étaient impressionnés, mais ils n'avaient pas non plus d'autre travail pour lui ». Il passait ses journées à jouer aux échecs en ligne. « Je n'étais vraiment complètement inactif que pendant environ 6 à 9 mois », a-t-il indiqué, après quoi il a reçu une promotion.
Dans la plupart des domaines, les travailleurs ont rarement une entrée formelle pour savoir si leur travail est automatisé ou comment et quand l'automatisation pourrait être mise en œuvre. Les personnes ayant eu recours à l'automatisation offrent un aperçu de ce à quoi cela ressemble lorsque l'automatisation n'est pas orchestrée par une décision d'entreprise descendante, mais par les mêmes travailleurs qui en récoltent les bénéfices. Certains embrassent le temps libre supplémentaire, tandis que d'autres utilisent les heures libres pour acquérir de nouvelles compétences et relever de nouveaux défis programmatiques.
La crainte de se faire renvoyer ou voler son code
« Ce que j'aime bien dans ces histoires, c'est qu'elles montrent que l'automatisation a encore le potentiel de réduire la quantité de travail ennuyeux que nous devons faire », a noté Jamie Woodcock, sociologue du travail à l'Oxford Internet Institute. « Ce qui était la promesse de l'automatisation, c'est-à-dire que nous n'aurions pas à travailler 60 heures par semaine et que nous pourrions faire des choses plus intéressantes comme rester à la maison avec nos enfants ».
Pourtant, de nombreux professionnels qui ont fait usage de l'automatisation ont peur d'indiquer qu'ils ont eu recours à un code. Même si un programme exécute impeccablement son travail, beaucoup pensent que l'automatisation pour son propre bénéfice est une erreur. Que le travail humain est intrinsèquement vertueux et que les employés doivent toujours maximiser la productivité de leurs employeurs. D'ailleurs, la plupart des contrats de travail stipulent que la propriété intellectuelle développée sur le temps de l'entreprise appartient à l'employeur. Ainsi, tout hacking d'efficacité ou gain d'automatisation qu'un employé pourrait réaliser est susceptible d'être absorbé par l'employeur, les avantages étant redirigés en amont.
Un développeur a indiqué qu'il a préféré garder pour lui le fait qu'il avait entièrement automatisé son travail au sein de son entreprise parce qu'il craignait qu'elle revendique la propriété intellectuelle comme la sienne et refuse de le dédommager. Un autre a déclaré qu'il avait une fois automatisé par inadvertance un département entier en redondance. Il gagne désormais «*plusieurs semaines*» par an grâce aux scripts d'automatisation. Il a précisé que lui et ses collègues gardent un contrôle strict sur leurs techniques d'automatisation, pour garder le contrôle sur la façon dont elles sont utilisées : « Nous gardons généralement ces outils pour nous ».
Un autre développeur s'est donné beaucoup de mal pour dissimuler les contours de son travail entièrement automatisé de 50 000 $ par an à son patron. La direction pouvait se connecter sur l'écran de son ordinateur via le réseau, il a donc lancé une boucle de vidéo préenregistrée pour masquer le fait qu'il ne travaillait pas réellement. Il a pourtant écrit : « Je n'ai pas l'impression de faire la bonne chose ».
« Je ne comprends pas pourquoi les gens penseraient que c'est contraire à l'éthique », a déclaré Woodcock. « Vous utilisez de toute façon divers outils et formes d'automatisation ; quiconque travaille avec un ordinateur automatise le travail ». Il estime que si l'un de ces développeurs s'était assis devant l'ordinateur, saisissant manuellement les données jour après jour, il ne serait jamais réprimandé. Mais en démontrant qu'ils sont capables de niveaux d'efficacité plus élevés, certains peuvent, de manière perverse, avoir l'impression de se soustraire à un devoir envers les entreprises qui les emploient. C'est peut-être pourquoi l'automatisation du travail peut ressembler à de la triche et être traitée comme telle par la politique de l'entreprise. Sur Amazon Mechanical Turk, le marché de l'entreprise technologique pour le microtravail, l'automatisation est explicitement contraire à ses conditions de service - pourtant les travailleurs comme ceux de la plateforme, qui travaillent pour des centimes par tâche, pourraient surtout bénéficier de l'automatisation.
Certains développeurs disent qu'ils ont été licenciés pour avoir automatisé leur travail. En 2011, un développeur a écrit*: « Ils ont pris ce que j'avais développé, m'ont remplacé par un idiot à qui ils ont montré comment le faire fonctionner, et m'ont rapidement renvoyé pour "insubordination". J'avais pris un actif commercial qui leur donnait 30 000 $ de profit par an et je l'ai transformé en un programme qui rapportait un million de dollars par an pour l'entreprise, et ils m'ont viré pour économiser environ 30 000 $ par an sur mon salaire. Créateurs d'emplois mon cul ».
En tant que telles, les préoccupations des auto-automatistes rémunérés sont moins probablement ancrées dans des questions éthiques et plus dans le fait de ne pas vouloir être licenciés ou exploités par un employeur qui, comme le note Woodcock, « attend non seulement tout notre temps, mais tout ce que nous créons ». Les auto-automatistes méfiants, spécule-t-il, « ne font pas confiance à nos lieux de travail ».
Et vous ?
:fleche: Lorsqu'un professionnel de l'informatique automatise son travail, qui devrait en bénéficier ? Lui ou son entreprise ? Pourquoi ?
:fleche: Avez-vous déjà automatisé une partie de votre travail ?
:fleche: Si oui, en avez-vous parlé à votre hiérarchie ? Pourquoi ? En avez-vous profité pour faire autre chose ? Quoi par exemple ?
:fleche: Sinon, envisagez-vous de le faire ? Qu'est-ce qui vous en empêche ?
:fleche: La situation soulève-t-elle, selon vous, un problème d'éthique ? Dans quelle mesure ?
:fleche: Un professionnel qui automatise son travail devrait-il être payé moins, pareil ou plus ? Pourquoi ?
:fleche: Des risques de se voir « confisquer » son code et se voir coller un motif quelconque, pioché dans les caractères chinois en petits caractères sur son contrat de travail, pour se faire renvoyer ?
Voir aussi :
:fleche: Quelles sont les habitudes de programmation qui peuvent faire de vous un bon développeur ? Expliquez les avantages que vous en avez tirés
:fleche: Comment avez-vous appris à développer ? Êtes-vous passé par le parcours classique d'une formation diplômante en informatique ou autrement ?
La question est épineuse mais en France, je dirais que ça dépend du contrat.
Dans nos contrat de développeur, c'est écrit que tout ce que l'on crée est la propriété de l'entreprise pour laquelle on travaille.
Si ce n'est pas écrit dessus, je ne dirais rien si je suis bien payé et éventuellement je négocierais une forte augmentation.
Si la propriété n'est pas spécifiée dans le contrat et que je développais quand même l'outil pour automatiser, je le protégerais (mot de passe + 2FA par exemple) afin qu'ils ne puissent pas l'utiliser si je me faisais virer.
En France quant tu est salarié, c'est la propriété de l'entreprise donc en fait le bail c'est d'automatiser un maximum de chose de ton travail sans le dire a l'entreprise qui croit que tu fait ca en manuel.
Tout simplement parce que si ton entreprise sait que tu a automatisé ton travail, il te donnera encore plus de travail à faire vu que l'automatisation elle ne considérera ca plus comme du travail mais un outil de l'entreprise.
Et donc il vaut mieux ne rien dire et faire semblant de travailler alors qu'on a automatisé son travail.
Donc si j'ai bien compris une entreprise qui invente un procédé qui permet d'automatiser des tâches pour supprimer des emplois dans d'autres entreprises, c'est le progrès et c'est éthique. Par contre que dans l'entreprise un gars fait la même chose pour lui, c'est non éthique. Donc au final une personne morale (l'entreprise) est toujours éthique même si elle ruine les gens alors qu'un individu seul est toujours critiquable. Pendant combien de temps on va encore laisser les entreprises avoir plus de droits que les individus? (je rappelle que le délit de "blasphème" existe contre les entreprises mais pas contre les dieux, donc on voit où on place l'entreprise...)
Jusqu'ici j'étais tout à fait d'accord *
Citation:
Envoyé par xbrossard
Par contre sur ce dernier point pas du tout :
Voir par exemple ici : https://www.publicsenat.fr/article/p...e-droit-185366Citation:
Envoyé par xbrossard
La république laïque a quand même du bon : en droit français, le blasphème n'existe pas ;)
*Tout à fait d'accord au barbarisme "au final" près : "le final" (masculin donc), c'est la dernière partie d'une œuvre musicale, sans rapport avec le sujet qui nous intéresse. Voir la définition du CNRTL ICI (2e onglet LE final)
Oui, tout dépend du contrat, réel ou moral, d'ailleurs.Citation:
Envoyé par smarties
Si celui-ci relève d'un accord commercial (appel à un prestataire par exemple), cela relève du contrat commercial et de ce qui y est indiqué. S'il n'y a pas de clauses spécifiques de cessation de propriété, la propriété du code produit appartient à son auteur, c'est à dire le prestataire.
L'entreprise demandeuse a tout intérêt à faire inclure une clause de cessation de propriété, mais généralement ça se négocie, et si le prestataire sait y faire, ça peut se négocier cher.
Attention, même en présence de clause le spécifiant, généralement est exclue de la cessation de propriété, tout ce qui relève d'un caractère artistique. C'est à dire, généralement pour une entreprise, tout ce qui est logo, charte graphique, etc ...
Mais là, ensuite, ça se règle aux tribunaux, au cas par cas.
Si le contrat relève du contrat de travail, toute production appartient de facto à l'entreprise. Cela concerne évidemment, les salariés, mais aussi stagiaires, intérimaires, freelance, mais aussi les salariés d'ESN qui travaillent directement pour un client final, en régie ou non. En effet, si le contrat entre l'ESN et le client final relève du contrat commercial, l'ordre de mission du salarié de l'ESN pour ce client final est assimilable, en quelque sorte à un contrat de travail.
Idem pour un freelance, le client n’achète pas une prestation, mais du temps de disponibilité, une "ressource" pour faire un travail interne à l'entreprise.
Écrit ou pas écrit. En France, ça n'a pas forcément besoin d'être écrit, c'est la règle de base.Citation:
Envoyé par smarties
Et ça va très loin.
Çà concerne, tout ce qui est créé dans le cadre du travail demandé au salarié, que le travail soit fait à la maison, ou sur sur site.
Mais ça concerne aussi, tout autre type de production, même personnelle, réalisé avec les outils mis à disposition par l'employeur au salarié dans le cadre de sont travail pour celui-ci, et que ceci soit fait au travail ou la maison, durant les heures de travail ou en dehors.
Donc attention notamment aux stagiaires, qui utiliseraient les outils du travail pour réaliser leur projets scolaires ou personnels ou leur rapport de stage. L'entreprise peut, en théorie, en revendiquer la propriété.
En pratique, les tribunaux ne donnent généralement raison à l'entreprise que s'il y a un risque d'atteinte à ses intérêts.
En France, tu n'as pas le droit.Citation:
Envoyé par smarties
S'il n'est pas forcément interdit de mettre un mot de passe à ta création, tu dois obligatoirement fournir celui-ci à l'entreprise pour qu'elle puisse y accéder en ton absence. C'est à dire, si tu viens à être licencié, mais aussi simplement quand tu pars en congé, ou en arrêt maladie, par exemple. Et ne pas le fournir, volontairement ou non, peut justement être un motif de licenciement pour faute grave voire lourde, suivant le préjudice que subit l'entreprise.
et si c'est un une ami qui a crée l’outil ça se passe comment :cfou:
Dans ce cas, autant créer un programme dégueulasse avec pleins de trucs inutiles dans le code et le faire planter après un certain temps comme pour le bug de l'an 2000. Si l'entreprise ne fait pas appel à quelqu'un de spécialisé, elle ne pourra pas le maintenir.Citation:
Envoyé par sevyc64
Si la personne part, elle peut fournir une documentation et indiquer que le programme est corrigé de temps en temps car il n'est pas encore au point.
Après c'est probablement très borderline au niveau de la loi
Toujours pareil, si l'entreprise peut identifier et prouver l'intentionnalité de la chose, ce qui est généralement pas très compliqué pour un expert, surtout quand il s'agit de petites "bombes à retardement" laissées ou créées volontairement, elle peut évidemment se retourner vers l'auteur, même plusieurs années après.Citation:
Envoyé par smarties
Après c'est une histoire de justice et de tribunal.
La question n'est pas épineuse parce qu'elle est tranchée par la loi!Citation:
Envoyé par smarties
Pas besoin d'être inscrit dans un contrat. Tout ce qui est créé par un collaborateur pendant ses heures de travail appartient à... son employeur!
Cela va même au-delà: Si tu utilises des connaissances spécifiques apprises au service de ton employeur (genre liste de clients, secrets de fabrication, ...) pour développer une activité économique après avoir quitté ton employeur, tu peux être condamné par un tribunal.
Je trouve que vous manquez de recul :
un employeur ne vous paie pas à ne rien faire.
si vous êtes salarié et que vous avez réussi à automatiser une très grande partie de votre travail, la première chose à faire est que cela ne doit surtout pas se savoir.
d'autre part, vous devez présenter la chose comme une amélioration progressive, donc brider les performances et les débrider petit à petit en fonction de la reconnaissance reçue en échange.
cela s'appelle la progressivité pour durer et tout salarié expérimenté le sait : on ne présente jamais une progression fulgurante au risque de se prendre le mur.
et oui, l'année suivante quand les objectifs seront fixés et qu'on demandera d'améliorer encore vos résultats, vous en serez incapables....
un job, c'est un parfois (ou très souvent) un marathon et l'objectif est bien de durer, pas d'exploser en plein vol par pure vanité et/ou par manque de vision stratégique pour se maintenir.
de cette manière vous servez à la fois les objectifs de l’entreprise et les vôtres, faut-il encore y penser.
Je ne vois pas ce que la propriété intellectuelle vient faire la dedans.
Bien sur que tout appartient à l'entreprise.
Rien n’empêche une entreprise de posséder une ferrari et des poubelles.
vous confondez bénéfice de l'automatisation avec propriété et qualité.
quel micmac...
Encore une fois, tout ce qui compte en tant que prestataire ou salarié, c'est de faire son travail.
Et ce quel que soit le procédé utilisé, dans les limites de la loi et du règlement de l'entreprise.
MAIS comme tout employeur le pense, il ne vous paie pas à rien faire et donc attend un résultat.
donc tout faire pour que cela ne se sache pas, est une stratégie.
dévoiler des perf en amélioration constantes, est également une stratégie, que même votre PDG utilise.
Mettez vous à sa place : dire aux actionnaires qu'il a augmenté les bénéfices de 100%.
le CA (conseil d'administration) et les actionnaires le félicitent et lui demande de faire 120% l'année suivante.
à part des marchés bien particuliers avec des circonstances elles aussi particulières, c'est peu probable que le pauvre PDG qui pensait bien faire, puisse atteindre cet objectif
2 ans après, c'est la déception à tous niveaux et notre gentil PDG prend la porte.
Méditez bien et ne mélangez pas tout.
créer un programme qui fonctionne mais qui n'est pas optimal n'est pas contraire à la loi
sinon, toutes les autos devraient être parfaites.
tous les logiciels devraient être parfaits, il n'y aurait donc aucun logiciel de vendu.
Encore une fois, méditez bien et ne mélangez pas tout.
C'est toi qui devrait méditer!Citation:
Envoyé par urumaru
L'élément essentiel dans une relation de travail, c'est... la confiance!
Si un responsable hiérarchique découvre un collaborateur appliquant la stratégie que tu proposes (qui se résume en fait à "en faire le moins possible, tout en faisant croire que tu te tues au travail"), ce sera la porte pour le collaborateur en question.
Qui plus est, c'est justement avec les agissements que tu proposes que les relations de travail entre employeur et employé deviennent horribles et que l'employeur en vient à imposer des règles débiles à tout le personnel à cause de quelques individus qui profitent du système.
Mon petit doigt me dit que lorsque tu te casses un ongle, tu obtiens un arrêt de travail de 6 mois et que tu trouves cela normal... J'ai raison, non?
Ce n'est pas "borderline", c'est condamnable et cela relève même du pénal: Il y a tromperie, malversation, intention de nuire, tentative d'extorsion et autre joyeuseté!Citation:
Envoyé par smarties
Ah on verse dans l'attaque personnelle...intéressant...
Je n'ai pas à me justifier.
Sachez cependant que ma confiance se borne à ce que tous mes collaborateurs atteignent leurs objectifs personnels et que toutes les équipes atteignent les objectifs collectifs.
Et du haut de ma petite expérience, je peux vous assurer que ça fonctionne suffisamment bien pour que je puisse dire qu'aucun de mes collaborateurs n'a démissionné pendant que je les dirigeais.
Enfin, en ce qui concerne le petit doigt... regardez-vous dans un miroir avant de critiquer les autres : je gère mon service et je m'implique au niveau support puisque la satisfaction du client est une donnée particulièrement importante pour moi, ce qui me permet de dire à ma direction générale si les SI fonctionnent correctement ou non et pour quelles raisons et si cela a pu impacter les perfs de l'entreprise.
Bon je suppose qu'avant que vous n'atteignez ce niveau de respectabilité attribué par vos subordonnés, il vous faudra un peu de temps.
J'aimerais bien savoir si tout ce que vous développez est parfait, si un autre ne va pas vous critiquer pour n'avoir pas écrit comme lui une fonction... bref la perfection... du moment que les programmes font ce pour quoi ils ont du être développés, dans le respect du cahier des charges (qui soit dit en passant intègre des critères de performance) ça me convient très bien.
Et je ne suis pas un ignorant, je sais très bien que parfois le produit livré est bridé, et alors ? Cf objectifs à atteindre.
J'aime bien ce que tu dis là. Comme je disgresse, je mets cette anecdote en mode "replié"Citation:
Envoyé par urumaru
En vérité, le besoin de ce DSI n'était pas "de ne pas inquiéter le client", mais de prouver qu'on avait toujours des choses à faire. Sauf que j'avais une dizaine d'anomalies par client, et que j'avais quatre clients ! C'était déjà compliqué de gérer les commerciaux des clients qui voulaient faire passer des anomalies cosmétiques (une couleur, un accent qui manque...) alors qu'un autre client a sa prod en carafe !
Je rejoins urumaru sur un aspect : cela dépend de la personne pour qui on travaille. Oui, je sais, je suis suisse, mais pour moi il faut du contexte.
Si ton employeur (ou client, si tu es en ESN) a juste besoin de personnes qui bossent, alors automatiser ne sert à rien. J'ai bossé pendant 18 mois sur du suivi de production, on m'a fait venir en tant qu'expert technique et j'ai passé mes journées à regarder le moniteur que ça ne plante pas. On aurait très bien pu trouver quelque chose, genre si la chaine plante, on reçoit un mail, couplée avec une alerte sonore assez forte.
Chez ce même client, on relançait à la main des chaines, et ça faisait le passe-plat. Avec un collègue, on avait proposé une chaine qui lançait les traitements de rattrapage les uns après les autres (c'était en bout de chaine, la nuit ; si ça plante, c'était pas grave, il fallait tout reprendre de toute manière). Ohlala, on avait dit un gros mot ! Optimiser !
En vérité, j'ai compris après, ce client c'était juste des internes qui se tiraient à boulets rouges. Ils avaient juste besoin d'une force de frapper pour disséquer les mails et balancer la faute au voisin quand quelque chose n'allait pas. Les équipes ne voulaient pas des buteurs : ils voulaient juste des joueurs qui faisaient des passes décisives et taclaient les meilleurs attaquants en face, quitte à se prendre un carton rouge.
Cela, je l'ai compris bien cinq ans plus tard, dans une équipe au même format chez un autre client. L'équipe qui nous alimentait en amont faisait de la merde, mais comme on était leur reporting, alors forcément les erreurs étaient de notre côté, il fallait qu'on répare. Leur manager avait recruté un de ses anciens potes ; le mec, en réunion, disait qu'il était tellement impliqué qu'il se levait à 3h du mat pour lancer des chaines de traitement. A deux reprises, on a dit qu'il y avait aussi des ordonnanceurs dans notre outil, mais pendant les comités c'était pas ce que voulait entendre les DSI. Finalement, le besoin de ce client c'était pas avoir des tâches automatisées, mais une douzaine de personnes qui travaillent manuellement de leurs mains... et utilisent leurs jambes pour faire des croche-pattes dans l'escalier.
