Discussion :

[el_slapper]

(.../....)c'est curieux , on a pourtant toujours affirmé que le bon côté du fordisme c'était les salaires très élevés qu'on donnait aux salariés de Ford pour qu'ils achétent eux-mêmes les véhicules qu'ils produisaient..bref "faire tourne la boutique"..

Tu as raison, mais je parlait de tout le reste. Le travail limité à sa plus simple expression, complétement aliénant. Charlot dans les temps moderne qui visse comme un robot.

c'est exact ; ce qui s'est passé en France c'est qu'on a bêtement voulu copier souvent sur les méthodes de management et les méthodes industrielles comme au Japon et aux USA.
Or copier des méthodes industrielles n'est pas toujours pertinent ça c'est comme vouloir appliquer les méthodes AGILE à un projet de développement logiciel alors que c'est pas forcément applicable ( je ne vais pas lancer un débat là-dessus ).
C'est quasiment imbécile de vouloir copier sur les Américains , la taille des entreprises en France n'est pas la même qu'aux USA et surtout le marché n'est pas du tout le même.
Aux USA c'est un marché de masse de 300 millions de consommateurs, en France c''est même pas 70 donc au final c'est plus improductif qu'autre chose..
Mais je vois une raison à l'industrialisation un peu poussée à l'extrême c'est parce qu'il y a la volonté et la nécessité de maitriser les coûts à tout prix...
autrement dit si tu veux industrialiser un projet informatique c'est dans une logique de maitrise de coûts.
Ce qui est dans la réalité difficile à faire puisqu'on ne peut pas industrialiser un projet informatique totalement.

J'ai mis en gras la partie importante. Nous ne sommes pas des producteurs. Un producteur de vis produit toujours la même vis. C'est plus difficile qu'il n'y parait, surtout pour être compétitif en gardant les normes de qualité exigées par le marché, mais c'est toujours la même vis. Nous, si on nous demande de produire la même vis, on copie-colle, ou mieux, on encapsule dans une API quelconque, on a pas besoin de refaire.

Dit autrement, si on fait appel à nous, c'est qu'il faut créer quelque chose, pas simplement le produire. Et les solutions éprouvées par le fabricant de vis ne nous sont d'aucun secours. C'est à ce titre que nous ressemblons beaucoup aux écrivains : on ne sait pas à l'avance quel sera le résultat. Alors qu'avant d'usiner une vis en atelier, je savais à quoi elle allait ressembler à la fin. Même en info de gestion, on créée. Donnes la même spec de garnissage d'un fichier plat de banales données comptables à 10 collègues, et tu auras 10 solutions différentes. C'est pour ça que l'industrialisation du codage donne des résultats catastrophiques.

Par contre, la plupart des autres éléments de notre métier sont industrialisables : le build, la livraison, les tests automatiques(mon métier en ce moment), peut-être même la gestion des environnements, et j'en oublie certainement. Mais la création du code, non. Ce qui rend les méthodes de diminution des couts ridicules.

pour moi il n'y a pas de doctrines industrielles il n'y a que les lois de l'Économie de marché...

Il y en a. Le grand public ne les connait pas. le SMED, ou changement rapide d'outil, est une doctrine qui pousse l'ingénieur à rendre ses outils flexibles. Ca m'a beaucoup servi pour concevoir certains codes dont je savait que les specs étaient vouées à changer. Le kanban vise à faciliter le suivi de production en limitant la paperasse. Il s'adapte facilement à la gestion de projet informatique, dans certains cas. Etc...

Le Lean aussi vient de l'industrie, et part du principe que celui qui a les mains sur le problème est le mieux à même de le résoudre. C'est une doctrine, opposée à celle du chef qui sait tout et du subordonné qui n'est qu'un âne.

pour prendre l'exemple de Mercedes, la seule doctrine ( comme une majorité d'entreprises anglo-saxonnes) ce qui importe surtout c'est de vendre des voitures à leur client et surtout que les clients soient satisfaits de leurs achats , on peut qualifier cela de pragmatisme allemand..et puis surtout les allemands sont partisans du "deutsche quälitat" donc il n'y pas de doctrines dans ce domaine..
les anglo-saxons ils font tout sauf avoir avoir une vision compliquée des choses : ils fabriquent des produits qui sont conformes aux attentes des consommateurs.

Ensuite pour ce qui est de la condition ouvrière, les allemands privilégient l'apprentissage, la méthode et la progressivité des choses.
(.../...)

Oui, mais tout ça, c'est de la doctrine. De la doctrine qui a fait ses preuves, qui me plait beaucoup, mais de la doctrine quand même. De la doctrine qui dit qu'on doit faire de la qualité parce qu'on ne peut pas rivaliser sur les prix. De la doctrine qui dit qu'un ouvrier qualifié rapporte plus, même si son salaire est supérieur. Ce n'est pas toujours vrai, mais les Allemands appliquent ça de manière systématique, doctrinaire, et ça marche.

Après, ça s'intègre dans un environnement plus vaste, dont tu parles très bien(et je t'ai mis +1 pour ça). Mais quand tu rentres dans le détail de l'organisation, tu vois l'influence des choix doctrinaires sur l'efficacité du travail. Et, dans les grands comptes Français, au niveau informatique, on est clairement à la ramasse à ce sujet. Surtout quand les doctrines sont mal assimilées(agile, j'ai dit agile? Comme c'est agile...).

Moi, j'ai l'agilité personnelle comme doctrine. Je pars du principe que si je pédale dans la semoule, c'est que je m'y prends mal, et que je dois changer de méthode. C'est parfois faux - dans certains cas, il est bon d'insister. Mais c'est la doctrine que j'applique, et elle m'a permis de corriger le tir dans bien des situations douteuses. L'agilité au niveau de l'équipe? Bof. Il y aura toujours une tête de lard pour ne pas jouer le jeu, et envoyer tout le monde dans le décor.

[Glutinus]

[*]Ecrire en plus de faire du code, car cela requiert les mêmes compétences : ce n'est pas parce qu'on a les compétences pour écrire qu'on a quelque chose à dire. Si je parlais de mon boulot, je pense que mon employeur, qui ne met pas son code en open-source, ne serait pas content. Et si c'est pour ouvrir un blog sur les chats, autant ne pas le faire.[*]Your job is not to write code --> il est vrai que le boulot doit être avant tout d'améliorer le logiciel dans le sens du client, comme elle le dit, mais le reste n'est que lapalissades

Je pense avoir déjà vu par ici, des membres de developpez qui se sont fait recruter grâce à leur blog. Mais le ROI peut être inintéressant. Par exemple, je bosse sur un produit à licence. J'ai trouvé une solution simple à une problématique qui à mon avis peut apparaître régulièrement. Est-ce que pour autant je vais la publier ? Je préfère la vendre

Après faut voir la différence entre le "codeur" en France (ou autre pays similaire) et celui dans un contexte plus... anglo-saxon ?
A part la mission sur laquelle je suis, où je fais vraiment de la technique, j'ai passé beaucoup plus de mission à faire du mail, de la politique - et j'essayais de faire comprendre que s'il recherche quelqu'un bon en rhétorique, il devrait plutôt aller puiser chez science-po - de la documentation pour tout et rien dire...

[yahiko]

Il faudrait aussi rappeler que le développement pur ne se réalise plus en France pour une part croissante. L'Inde est plus compétitive à ce niveau.

[Laurent 1973]

Nous ne sommes pas des producteurs. Un producteur de vis produit toujours la même vis. C'est plus difficile qu'il n'y parait, surtout pour être compétitif en gardant les normes de qualité exigées par le marché, mais c'est toujours la même vis. Nous, si on nous demande de produire la même vis, on copie-colle, ou mieux, on encapsule dans une API quelconque, on a pas besoin de refaire.

Je suis d'accord, le développement informatique n'est pas une chaîne de production.

Si je voulait faire le parallélisme avec l'industrie automobile, je le ferais comme ceci:

• Le développement informatique ~= Le bureau étude d'ingénieur R&D qui conçoit des plan de voitures
• La chaîne de production de voiture ~= La gravure du CD et sa mise en boite.

C'est étrange, de vouloir cantonner des ingénieurs informatiques à un rôle d'ouvrier en production.

J'aimerais bien savoir comment, chez Renaud ou Mercedes, leurs ingénieurs R&D travaillent.
Est-ce que l'on leur découpe aussi leur travail de façon si atomique que pour nous?

[el_slapper]

Je suis d'accord, le développement informatique n'est pas une chaîne de production.

Si je voulait faire le parallélisme avec l'industrie automobile, je le ferais comme ceci:

• Le développement informatique ~= Le bureau étude d'ingénieur R&D qui conçoit des plan de voitures
• La chaîne de production de voiture ~= La gravure du CD et sa mise en boite.

C'est étrange, de vouloir cantonner des ingénieurs informatiques à un rôle d'ouvrier en production.

Tout à fait d'accord; un peu de théorie à ce sujet, qui a beaucoup inspiré ma réponse précédente.

J'aimerais bien savoir comment, chez Renaud ou Mercedes, leurs ingénieurs R&D travaillent.
Est-ce que l'on leur découpe aussi leur travail de façon si atomique que pour nous?

Non. Ils ont leurs spécialités, mais il y a en gros 3 niveaux : la R&D, la qualité, et les méthodes. Les méthodes sont des gens qui sont aussi en contact avec la production, et ils ont un impact profond sur la conception, parce-qu'il ne suffit pas de faire une pièce qui remplisse sa fonction, encore faut-il que la production soit compétitive. Il y a en général des ilots par spécialités, et le débutant se trouve en charge de la glace de custode. Plus des gens qui font la liaison entre les pièces. En fait, ça fait 5 spécialités en les comptant et en comptant la production.

[yahiko]

L'analogie avec l'univers automobile a ses limites. Tous les logiciels n'ont pas vocation a avoir les même contraintes qu'une automobile (tant en terme de fiabilité, certifications, complexités, etc).

Le développement informatique a justement trop souffert des cycles en V pour ne pas y replonger...

[Invité]

Faire un blog ? J'en ai fais un et ça m'a aidé à revoir mes idées et à me remettre en question afin de m'améliorer.

Les diagrammes (UML ou autre) sont très importants si on travaille en équipe. (Mais cela n'est compréhensible que par des développeurs malheureusement, pour un client ça ne sert à rien, je préfère largement exposer mes idées sur un blog avec du texte et des images toutes faîtes, le client comprend beaucoup mieux dès lors pourquoi ça ne fonctionne pas, et dans le pire des cas, pourquoi ce n'est pas possible.)

Car bon, des clients qui veulent faire du n'importe quoi avec de vieilles machines, j'en ai déjà eu mais des tonnes, à tel point que depuis que j'ai eu certaines mauvaise surprise, je n'installe plus rien sur leur machine (sauf anti-virus et outils de réparation) et je fais tout sur la mienne.

J'en ai eu un qui ne savait plus afficher une page avec IE, ni reformatter son PC, il téléchargeait des films sans anti-virus.
J'aurai bien été content de lui passer un lien vers un blog plutôt que de répéter 100* la même chose à tout mes clients.
Un autre qui utilisait encore windows xp. (Qui n'est plus maintenu)


Pour ce dernier j'ai du lui expliqué que il y avait eu un virus dans le PC et que ce n'était pas moi qui n'avait pas vérifier que ce que j'avais installé sur sa machine était compatible avec sa machine, j'ai même du faire une sauvegarde et un checkdsk avec un outil externe. (pas le cd d'installation de windows, ça vaut rien ça et en plus ça ne marchait pas!)
Ca m'a prit plusieurs jours pour pouvoir reprogrammé sur la machine. :/
Bon, le client à quand même ragé contre moi par après (je ne sais pas ce qu'il a cru mais ce qu'il me disait était fort incohérent et louche, de plus il semblait très satisfait quand il voyait mes compétences.), même en essayant de lui faire comprendre que ça n'était pas de ma faute. :/

Un autre client j'ai du faire une copie de son disque dur externe, pour le reformaté car le système de fichier était trop ancien et n'affichait pas son dossier.


Maintenant il y a toujours des clients plus honnête que d'autres, mais si la communication ne passe pas bien, ce n'est même pas la peine de développer pour ce client là.

PS : ha oui il y avait aussi eu un autre client qui voulait que je lui modifie un programme avec une version de visual studio qui n'existe plus. :/

J'ai du lui expliqué que ce n'était pas possible et qu'il faudrait que je recrée tout le programme.

[Mat.M]

J'ai mis en gras la partie importante. Nous ne sommes pas des producteurs. Un producteur de vis produit toujours la même vis. C'est plus difficile qu'il n'y parait, surtout pour être compétitif en gardant les normes de qualité exigées par le marché, mais c'est toujours la même vis. Nous, si on nous demande de produire la même vis, on copie-colle, ou mieux, on encapsule dans une API quelconque, on a pas besoin de refaire.

c'est un autre débat...on s'est éloigné du sujet principal faire du code ou écrire un blog...
maintenant si tu produis toujours la même vis soit la concurrence arrive soit tu est leader sur ton marché et tu n'auras plus de croissance de ton chiffre d'affaire car les gens n'ont plus besoin d'acheter des vis, les besoins sont satisfaits.
Ton CA il va rester plat sur une courbe en fonction du temps.
Là où je veux en venir c'est que la société de consommation et l'Economie de marché converge vers un système fini parce que le progrès technique s'essoufle totalement.
Donc ne subistera plus que les économies de "rente" , l'alimentaire, le transport,le logement...

Nous, si on nous demande de produire la même vis, on copie-colle, ou mieux, on encapsule dans une API quelconque, on a pas besoin de refaire.

c'est l'intérêt de la programmation orientée objet , cela évite de refaire des copier-coller à tout bout de champs..

Oui, mais tout ça, c'est de la doctrine. De la doctrine qui a fait ses preuves, qui me plait beaucoup, mais de la doctrine quand même. De la doctrine qui dit qu'on doit faire de la qualité parce qu'on ne peut pas rivaliser sur les prix. De la doctrine qui dit qu'un ouvrier qualifié rapporte plus, même si son salaire est supérieur. Ce n'est pas toujours vrai, mais les Allemands appliquent ça de manière systématique, doctrinaire, et ça marche.

on ne peut pas appeler cela de la doctrine ou alors c'est un usage inapproprié du terme "doctrine"...

Le terme doctrine c'"est synonyme d'idéologie philosophique ou politique.

la seule vérité de l'Economie c'est de gagner de l'argent en vendant des produits que les consommateurs veulent acheter..c'est ça le pragmatisme des choses.

C'est quelque chose qu'on n'a vraisemblablement pas compris en France...

si tu souhaites créer une entreprise ce qui va surtout te préoccuper c'est ton chiffre d'affaire, pas d'accord ?
Donc pour faire du CA il faut avoir une stratégie commerciale..

Tiens regarde la page Wikipedia sur la doctrine /théorie économique
doctrine /théorie économique , y'a même pas d'équivalent en anglais de cette page

Après, ça s'intègre dans un environnement plus vaste, dont tu parles très bien(et je t'ai mis +1 pour ça). Mais quand tu rentres dans le détail de l'organisation, tu vois l'influence des choix doctrinaires sur l'efficacité du travail. Et, dans les grands comptes Français, au niveau informatique, on est clairement à la ramasse à ce sujet. Surtout quand les doctrines sont mal assimilées(agile, j'ai dit agile? Comme c'est agile...).

ehhh non l'organisation du travail c'est pas du tout de la philosophie comme Descartes ou Platon !
Ou alors j'ai mal compris tes propos.
La finalité de l'organisation du travail, la rationalisation des processus économiques qui selon les cas d'entreprises a ses des défaults c'est....de faire gagner de l'argent à l'entreprise tout bêtement et simplement.
Là oui ça rejoint la conception tayloriste des choses.
Si tu montes une usine tu peux pas faire de l'artisanal comme la boulangerie du coin c'est pas possible ou alors tu coules purement et simplement , on est arrivé dans l'Economie de marché.
On peut me traiter de capitaliste (et pourtant je suis au chômage) mais face à la mondialisation et l'Economie de marché on ne peut plus rien faire il faut s'y adapter coûte que coûte..

L'analogie avec l'univers automobile a ses limites. Tous les logiciels n'ont pas vocation a avoir les même contraintes qu'une automobile (tant en terme de fiabilité, certifications, complexités, etc).

Le développement informatique a justement trop souffert des cycles en V pour ne pas y replonger...

c'est parfaitement exact ; on ne mène pas à terme un projet logiciel comme on fabrique des égagères pour Ikea en Asie du Sud Est à des millions d'exemplaires..

[Saverok]

Les diagrammes (UML ou autre) sont très importants si on travaille en équipe. (Mais cela n'est compréhensible que par des développeurs malheureusement, pour un client ça ne sert à rien, je préfère largement exposer mes idées sur un blog avec du texte et des images toutes faîtes, le client comprend beaucoup mieux dès lors pourquoi ça ne fonctionne pas, et dans le pire des cas, pourquoi ce n'est pas possible.)

L'UML regroupe pas mal de diagrammes différents (il n'y a pas que les diagrammes de classes) dont beaucoup sont très compréhensibles par des gens du métiers (use case, état transition, activité, etc)
Pas besoin d'avoir un haut niveau d'étude en dev pour comprendre (il n'y a qu'à suivre les flèches)
D'expérience, ça aide beaucoup.
A vrai dire, je n'ai jamais eu un client qui s'en ait plain et qui a réclamé du texte, bien au contraire
Un schéma est nettement plus clair et compréhensible et permet d'économiser beaucoup de lignes de textes inutiles.

A cela, si tu ajoutes du BPM, qui est justement une représentation orientée métier, on s'en sort très bien

Bref, tout ça pour dire que je partage pas du tout ta remarque.
L'UML sert autant pour le développeur car il prend du recule et a une vision d'ensemble, qu'à l'équipe car cela permet de se coordonner et de partager la même vision d'ensemble du projet, qu'au client car se sont des outils de représentation facilement compréhensible par la plupart des gens même métier, qu'au concepteur car il peut anticiper certains problèmes, qu'au DSI et admin réseaux qui comprennent mieux les interactions entre les appli et systèmes et peuvent donc mettre en place les protocoles pour les flux, la sécu, etc.

[el_slapper]

c'est un autre débat...on s'est éloigné du sujet principal faire du code ou écrire un blog...
maintenant si tu produis toujours la même vis soit la concurrence arrive soit tu est leader sur ton marché et tu n'auras plus de croissance de ton chiffre d'affaire car les gens n'ont plus besoin d'acheter des vis, les besoins sont satisfaits.
Ton CA il va rester plat sur une courbe en fonction du temps.
Là où je veux en venir c'est que la société de consommation et l'Economie de marché converge vers un système fini parce que le progrès technique s'essoufle totalement.
Donc ne subistera plus que les économies de "rente" , l'alimentaire, le transport,le logement...

En fait, on veut dire la même chose, mais pas pareil. Le fabriquant de vis va avoir une équipe de R&D pour inventer de nouvelles vis...mais continuer à produire aussi les anciennes, car la demande existe encore. Ce sur quoi je pense qu'on est d'accord(et je reformule et tu me dis si c'est bien le cas), c'est que la R&D ne s'accommode pas des méthodes de la production industrielle.

c'est l'intérêt de la programmation orientée objet , cela évite de refaire des copier-coller à tout bout de champs..

Oh le gros appeau à troll(je n'ai pas dit le troll, juste un appeau, je vais essayer d'éviter de troller moi-même).
Pour rappel, en procédural, on peut parfaitement faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Call MaProcedure(MonParametre, MaReponse)

En fonctionnel :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaReponse = MaFonction(MonParametre)

En objet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaReponse = MonObjet.MaPropriete(MonParametre)

C'est juste une manière différente d'encapsuler. Ce ne sont jamais que des routines, et c'est là tout l'intérêt : une fois qu'on a fait une routine, on a plus de problèmes de conception.

on ne peut pas appeler cela de la doctrine ou alors c'est un usage inapproprié du terme "doctrine"...

Le terme doctrine c'"est synonyme d'idéologie philosophique ou politique.

la seule vérité de l'Economie c'est de gagner de l'argent en vendant des produits que les consommateurs veulent acheter..c'est ça le pragmatisme des choses.

C'est quelque chose qu'on n'a vraisemblablement pas compris en France...

si tu souhaites créer une entreprise ce qui va surtout te préoccuper c'est ton chiffre d'affaire, pas d'accord ?
Donc pour faire du CA il faut avoir une stratégie commerciale..

Tiens regarde la page Wikipedia sur la doctrine /théorie économique
doctrine /théorie économique , y'a même pas d'équivalent en anglais de cette page

D'apris wikipedia "Doctrine" : Dans le domaine militaire, politique, diplomatique, et du management, on appelle par extension doctrine les principes de base sur lesquels s'appuient une stratégie et des plans d'actions.

Je ne parle pas de doctrine économique, je parle de doctrine de management, qui est à un niveau beaucoup plus bas. Le Fordisme(ou le kanban, ou le SMED, ou que sais-je) est une doctrine manageriale, et son application se fait à l'échelle de l'entreprise, voire de l'équipe, pas à celle du pays, contrairement à une doctrine économique. Tu as tort en te focalisant sur le CA : l'important, c'est le rapport entre le CA et les couts engagés pour le dégager. Et c'est la que le management est essentiel. Si le management est bon, on produira autant, voire plus de richesse vendable, pour un cout moindre. Après, au niveau supérieur, on a bien le besoin d'arriver à vendre toute cette richesse produite. Mais je ne parle pas de cela. L'informatique n'a que peu à voir avec cela. C'est à plus bas niveau

Et j'ai constaté un problème énorme à ce niveau chez les grands comptes Français. Notamment celui-là : "Le développeur informatique est un rouage remplaçable, contrairement à son manager". C'est crétin, faux, mais c'est la doctrine, et ça explique en grande partie le fonctionnement des SSII(qui découle directement du fonctionnement imbécile de leurs clients), mais aussi les méthodes de recrutement des-dits grands comptes.

ehhh non l'organisation du travail c'est pas du tout de la philosophie comme Descartes ou Platon !
Ou alors j'ai mal compris tes propos.
La finalité de l'organisation du travail, la rationalisation des processus économiques qui selon les cas d'entreprises a ses des défaults c'est....de faire gagner de l'argent à l'entreprise tout bêtement et simplement.
Là oui ça rejoint la conception tayloriste des choses.
Si tu montes une usine tu peux pas faire de l'artisanal comme la boulangerie du coin c'est pas possible ou alors tu coules purement et simplement , on est arrivé dans l'Économie de marché.
On peut me traiter de capitaliste (et pourtant je suis au chômage) mais face à la mondialisation et l'Économie de marché on ne peut plus rien faire il faut s'y adapter coûte que coûte..(.../...)

L'organisation du travail, interne à l'entreprise, repose sur des présupposé philosophiques. Le chef est essentiel, l'acteur est sacrifiable. C'est un présupposé philosophique qui vient directement du Fordisme, mais aussi des organisations militaires. Qui résulte en une perte sèche et massive de savoir-faire à chaque fois qu'un prestataire s'en va. Ça n'a rien à voir avec le capitalisme(qui décrit l'environnement extérieur de l'entreprise, et son mode de direction, par rapport à une économie planifiée, par exemple). D'ailleurs, les échos que j'ai des entreprises d'état sont étrangement proches de ce que j'ai pu vivre dans le privé. Ce n'est pas une question de paradigme économique(parceque l'ed nat, comme entreprise capitalistique soumise à un marché concurrentiel, on repassera), c'est une question d'organisation interne du travail, qui découle directement des présupposés philosophiques sous-tendus.

Tu ne peux pas organiser ton usine de vis comme une petite boulangerie, mais tu peux partir des mêmes présupposés. Je fais confiance à l'ouvrier, ou je le micro-manage? Je donne un fouet et carte blanche au sous-chef? Je mets la pression pour les résultats, ou je fais confiance aux gens? On découpe le travail en micro-parties, ou on laisse à l'ouvrier un pan plus grand du travail sous autonomie? On ne répond pas à ce genre de questions en partant sur une page blanche, mais en s'appuyant sur la culture dans laquelle on baigne. En Corée du Nord, la réponse ne sera généralement pas la même qu'aux Bahamas, parce que la culture philosophique est différente.

(oups, j'ai beaucoup écrit. Quasiment une petite entrée de blog!)

[Mat.M]

Tu as tort en te focalisant sur le CA

j'ai certainement tort de vouloir me focaliser sur le CA mais faut pas s'en prendre à moi c'est l'Economie de marché et la mondialisation qui veut ça !
Or en France j'ai l'impression qu'on n'a pas encore compris cela..
si tu gères une entreprise qui ne fais pas un CA minimal tu risques au mieux de vivoter au pire de couler par le simple jeu de la concurrence et des charges de l'entreprise,du coût du travail qui augmentent ( et de l'inflation aussi..)

ceci dit le service informatique c'est un domaine économique qui n'est pas tout à fait lié aux contraintes de l'Economie de marché contrairement à l'édition logiciel par exemple..

Si le management est bon, on produira autant
l'important, c'est le rapport entre le CA et les couts engagés pour le dégager. Et c'est la que le management est essentiel.

pas du tout d'accord ; l'augmentation de la production c'est tributaire des modéles d'organisation, de la rationalisation de la production c'est l'essor de la technologie qui a permis cela , les ERP, les sysèmes embarqués...
un manager c'est un type qui ne servira plus à rien parce qu'on automatise de plus en plus sauf pour certains domaines comme la recherche et développement...

mais le management pur c'est totalement dépassé parce qu'un bon manager ça ne suffit plus du tout.

Si tu veux manager un projet il y a les coûts de développement et les risques financiers que cela peut présenter...donc que tu embauches un manager qui a fait Polytechnique ou l'ENA avec 15ans d'expériences en management bref l'homme providentiel comme on aime en France ce type-là il ne servira strictement à rien si le projet ne rapporte pas d'argent..

donc les mentalités françaises sont totalement à côté de la plaque pour moi..

L'organisation du travail, interne à l'entreprise, repose sur des présupposé philosophiques.

mais non pas du tout , il n'y a pas de présupposé philosophiques...c'est totalement fini ce temps-là..
la seule philosophie c'est de rationnaliser les coûts d'une entreprise si tu ne le fais pas tu vas te faire bouffer par la concurrence en tant que manager d'entreprise; c'est totalement comptable et mathématique c'est de la métholodogie industrielle.
On a crée les ERP c'est justement pour rationnaliser les coûts et le systéme d'information d'une entreprise, Karl Marx n'a rien à voir avec un ERP et ses modules fonctionnels

[el_slapper]

j'ai certainement tort de vouloir me focaliser sur le CA mais faut pas s'en prendre à moi c'est l'Economie de marché et la mondialisation qui veut ça !
Or en France j'ai l'impression qu'on n'a pas encore compris cela..
si tu gères une entreprise qui ne fais pas un CA minimal tu risques au mieux de vivoter au pire de couler par le simple jeu de la concurrence et des charges de l'entreprise,du coût du travail qui augmentent ( et de l'inflation aussi..)

L'important, c'est le BENEFICE. Donc le CA et les couts. Donc, oui, le CA est important, mais si tu te contentes de faire monter ton CA sans regarder les couts, tu vas dans le décor.(je n'ai sans doute pas été clair sur mes interventions précédentes).

pas du tout d'accord ; l'augmentation de la production c'est tributaire des modèles d'organisation, de la rationalisation de la production c'est l'essor de la technologie qui a permis cela , les ERP, les systèmes embarqués...
un manager c'est un type qui ne servira plus à rien parce qu'on automatise de plus en plus sauf pour certains domaines comme la recherche et développement...

Si ce que tu veux dire, c'est que quand la tehcnologie fait passer l'usine sidérurgique de 20 000 à 2 000 personnes, on a moins besoin de chefs, on est d'accord. Mais le travail des 2 000 qui restent est plus compliqué, et il faut plus de managers par tête.

Si tu veux manager un projet il y a les coûts de développement et les risques financiers que cela peut présenter...donc que tu embauches un manager qui a fait Polytechnique ou l'ENA avec 15ans d'expériences en management bref l'homme providentiel comme on aime en France ce type-là il ne servira strictement à rien si le projet ne rapporte pas d'argent..

Je suis d'accord avec ça. Mais je ne comprends pas comment du fais le lien entre :

donc les mentalités françaises sont totalement à côté de la plaque pour moi..

et

mais non pas du tout , il n'y a pas de présupposé philosophiques...c'est totalement fini ce temps-là..

Justement, si les mentalités Françaises sont à coté de la plaque, c'est parce-que les présupposés philosophiques(voire idéologiques) sont erronés. Là ou Google présuppose que le développeur est une ressource rare à cultiver, Le Crédit Général de Paris présuppose que le développeur est du bétail renouvelable. Dans les deux cas, un bon management sera utile pour tirer le maximum des gens, sauf que le Crédit Général de Paris part avec un sacré handicap... parce que ses présupposés philosophiques ne sont pas adaptés à son activité(en tous cas coté informatique.)

Si des gens intelligents sont à coté de la plaque, c'est qu'ils partent de mauvaises bases.

la seule philosophie c'est de rationaliser les coûts d'une entreprise si tu ne le fais pas tu vas te faire bouffer par la concurrence en tant que manager d'entreprise; c'est totalement comptable et mathématique c'est de la méthodologie industrielle.
On a crée les ERP c'est justement pour rationaliser les coûts et le système d'information d'une entreprise, Karl Marx n'a rien à voir avec un ERP et ses modules fonctionnels

J'ai beau bosser pour un ERP(dans le médical), ils sont tout sauf la panacée, et certains de nos modules sont ouvertement ignorés par les clients qui préfèrent parfois des logiciels dédiés. Là aussi, on a des préjugés idéologiques forts, qui s'affrontent : l'intégration contre la spécialisation. Chaque solution a ses avantages et ses inconvénients, mais le choix est plus souvent idéologique que pragmatique. Veut-on le meilleur pour chacun, ou le meilleur pour tous? La réponse n'a généralement rien de rationnel. Chacun y va de sa petite expérience, et tente d'influencer le grand chef.

L'efficacité est une vertu, mais les capitalistes, comme les autres, ne sont que des humains, et ne font pas toujours le choix rationnel. Petit exemple de gens qui essayaient de faire mieux, mais n'avaient pas les bonnes écoles de pensée. Et complètement dans le cadre du capitalisme.

[Mat.M]

salut el_slapper ok d'accord avec toi mais pour ce qui est de l'ERP on dévie du sujet principal...
c'est évident qu'un ERP ça ne fait pas tout.
C'est un débat à ouvrir dans le forum concerné

[pascalCH]

Mais bien sur !! enfin la solution définitive aux bugs !

• Un bug est forcément d'origine humaine, le développeur étant un homme, il en est donc à l'origine
• l'écrasante majorité des bugs provient du code puisque pour corriger un bug, on fini toujours par modifier le code
• il est évident que plus il y a de code, plus il y a de bugs
• La seule ligne de code qui marche est celle que personne n'écrit
• Un bon programme ne contient que des commentaires
• mais les commentaires polluent les sources

donc oui !

• laissons les développeurs écrire sur les blogs, au moins il ne pollueront plus les sources et n'écrirons plus de bugs !

ps : bon, du coup, on n'a plus besoin d'eux, donc, on s'en sépare; mais du coup, qu va écrire les logiciels ? ben peut-être qu'on n'en a pas besoin non plus, après tout, avant, il y avait des papiers, des crayons, des règles à calculer et on se débrouillait très bien !!

ps 2 : en fait, ça colle pas, pour écrire un blog, il faut un blog, donc un logiciel !!

[SurferIX]

A en juger par les citations de cette Laura Klein, je lui décernerais volontiers la palme de l'enfonçage de portes ouvertes...

On pourrait dire la même chose du livre "Les hommes viennent de Mars, les femmes de Vénus", et pourtant ce livre a servi à pas mal de monde.
Je ne partage donc pas ton point de vue... car je pense que ça fait toujours du bien de rafraîchir les mémoires.

[yahiko]

car je pense que ça fait toujours du bien de rafraîchir les mémoires.

Si tu avais oublié, c'est assez inquiétant

[domi65]

Elle rappelle ensuite que les clients ne sont pas tous équipés des derniers MacBook Air avec un écran haute résolution.

On s'en fout de la résolution, dans le cadre du développement web. Ce qui importe, c'est la définition.

[domi65]

@ yaniko

A en juger par les citations de cette Laura Klein, je lui décernerais volontiers la palme de l'enfonçage de portes ouvertes

Tu me l'as soufflé !

J'ajouterai qu'elle est quand-même douée pour le charabia :

Si vous vous attendez que le code écrit va améliorer l'engagement des utilisateurs, alors vous devez avoir un moyen de savoir si vous avez réussi ou non

sémantique, non, comme code ?

[JCott]

L'idée d'être un «lean startup» est basé sur le fait que vous devez être capable de s'adapter à différents environnements et de réagir en fonction des besoins des clients. Tel est le principe derrière le phénomène de démarrage maigre et la plupart des entreprises ont besoin de l'embrasser (ainsi que les principes de service à la clientèle) pour réussir.

http://helprace.com/knowledgebase-software