Discussion :

[el_slapper]

(.../...) Perte de productivité ? Perte ponctuelle pour un gain temporel évident pour l'entreprise. Mieux vaut avoir un salarié qui s'est formé sur un petit projet pour le réutiliser par la suite qu'une sur-spécialisation.(.../...)

Dans mes bras. Je me rappelle d'un syndicaliste italien qui bossait dans un chantier naval menacé et qui disait "Nous, on connait notre boulot. Si le plan indique un tuyau droit, mais que sur place, on s'aperçoit qu'il faut un tuyau coudé, eh bien on coude le tuyau." C'est un bon résumé, à mon sens, du mot "professionnel". C'est l'antithèse du taylorisme appliqué massivement dans le tertiaire de nos jours.

En plus, le taylorisme est devenu has been dans l'industrie il y a plus de 50 ans. Mais il reste l'horizon indépassable des décideurs du tertiaire, qui rêvent de chaines de fabrication façon "temps modernes" pour toute activité humaine. Ça marche encore pour certaines choses(genre servir un hamburger), mais dans la majorité des activités, c'est dépassé. Il faut de l'intelligence, et l'intelligence ne s'industrialise pas. Les activités sont trop complexes pour entrer dans un petit manuel à suivre aveuglément.

C'est d'ailleurs paradoxal : notre job est d'industrialiser au maximum des process. Mais certaines parties de notre job ne sont pas industrialisables. Celles qui le sont(je pense en particulier au déploiement, ainsi qu'à certains tests de non-régression) doivent être industrialisées absolument. Mais la conception du code(ou, un code, ça ne se pisse pas, ça se conçoit, ça n'est pas juste une transcription de specs, c'est une vraie conception de bas niveau en soi).

[Tr0n33]

Dans mes bras

Avec plaisir !

Il faut de l'intelligence, et l'intelligence ne s'industrialise pas. Les activités sont trop complexes pour entrer dans un petit manuel à suivre aveuglément

C'est l'essentiel de mon stress et de mon énervement quotidien dans les grandes entreprises pour lesquelles j’œuvre. Il faut des processus et des normes, mais jamais au dépend de la fluidité du travail. Les méthodologies agiles n'ont pas été inventées pour rien. Sur ma mission actuelle, j'ai appris le Powershell très rapidement quelques heures tout au plus pour une capacité de réponses désormais rapides ce qui permet à mon chef de ne pas demander une ressource d'appui technique supplémentaire. Mais d'un autre côté je reçois la pression d'un commercial qui aurait aimé positionner deux ressources pour presser la vache à lait. On peut donc, d'un certain point de vue, comprendre le besoin dans ces deux articles d'éviter les digressions de formation sur un projet.

Mais il y a toujours des désavantages à ces situations d'apprentissage. Certaines entreprises ou équipes tablent justement sur ces formations "sur le tas" pour éviter de former réellement les individus. Bilan, dans des équipes de MCO ou de TMA, je croise souvent des petits jeunes qui ont peu d'expérience et qu'on met car il ne s'agit à priori que de la correction de bug. Or de mon point de vue, c'est là qu'il faut un véritable expert du domaine.

Les problématiques sont donc diverses et je trouve un peu fort de café, sur les deux articles, de prétendre d'un état de fait quand il manque terriblement d'hypothèses réalistes. Je dirais bêtement que tout dépend des tâches, de ce que l'on conçoit, de la gestion des individus, de l'environnement, des besoins etc. Le raisonnement sur les articles est donc un peu trop dans la logique d'Ockham. Quant à prétendre qu'on peut tout faire avec Java... Mon Dieu... Je crains que ce monsieur n'est jamais fait au final que de l'informatique de gestion (Quand on utilisera Java pour faire des modèles formels, on en reparlera ^^).

[el_slapper]

(.../...)Je crains que ce monsieur n'est jamais fait au final que de l'informatique de gestion (Quand on utilisera Java pour faire des modèles formels, on en reparlera ^^).

Et encore, ça dépend des niveaux de gestion. Quand je faisais des batchs massifs de traitement de millions d'enregs comptables pour une banque, on était 2 fois plus rapides en développement avec du COBOL(et je ne parle même pas de temps d'exécution) qu'avec Java. Évidemment, le poste utilisateur, lui, était en Java, le cobol étant juste inacceptable pour une interface. Voilà, on avait un marteau, et un tournevis, et suivant qu'on avait à faire à un clou ou à une vis, on sortait le marteau ou le tournevis.

Sinon, pour les corrections de bugs, je crois qu'on les colle aux débutants parce que ça gave les "experts". Le "ça lui permettra d'apprendre", c'est très secondaire. Le chef essaye surtout de ménager ses anciens, dont il sait qu'il en a besoin. Et donc "il apprendra comme ça", c'est un bon prétexte. Pas totalement faux, en plus. Mais ça n'est pas la vraie raison.

[Tr0n33]

Sinon, pour les corrections de bugs, je crois qu'on les colle aux débutants parce que ça gave les "experts". Le "ça lui permettra d'apprendre", c'est très secondaire. Le chef essaye surtout de ménager ses anciens, dont il sait qu'il en a besoin. Et donc "il apprendra comme ça", c'est un bon prétexte. Pas totalement faux, en plus. Mais ça n'est pas la vraie raison.

En fait c'est généralement parce que les individus ont une tendance - je dis bien tendance - à être ennuyé par des tâches routinières ou simples. Pour moi l'ennui est une source de créativité. Je préfère faire une tâche rébarbative et avoir deux jours hommes d'avance pour faire des évolutions d'API, des tests complémentaires, des rapports pour une meilleure maintenance, de l'ajour de documentation, d'optimisation. En fait je me rends compte que c'est cette façon de faire qui m'a donné le temps de me former en parallèle à d'autres langages, d'autres techniques etc (rarement le fait de la hiérarchie, ou des commerciaux).

Mais on digresse un peu là.