Discussion :

[SurferIX]

Est-ce que tu fais économiser 2 salaires ou est-ce les autres qui surcoutent 2 salaires ? Il ne faudrait pas confondre ;-)

J'ai fait économiser le travail de deux "petites mains" (n'y voyez rien d'irrespectueux) qui auraient dû rentrer des tarifs (= faire une conversion d'un tableau excel vers un programme totalement différent) sur toute une semaine. Le salaire de deux "petites mains" sur une semaine c'est tout de même plus cher que le travail d'une matinée pour moi.

C'est bien beau en théorie mais quand tu as un client qui ne comprends rien à ce qu'il veut, quand on lui présente le produit tel qu'il l'a spécifié et te dit que c'est pas du tout ça qu'il voulait, et ceci régulièrement, tu fais quoi ?

Je n'ai, en fait, jamais connu de client qui savait exactement ce qu'il voulait, comme il voulait, et (surtout) qui arrivait à imaginer ce que ça donnerait au final. La seule solution viable à ce genre de problème c'est l'activité que je déteste par dessus tout à savoir : faire un cahier des charges détaillé, page par page, écran par écran, avec "quand l'utilisateur clique ici ça donne ça". Ainsi, si le client est pas content, on ressort le cahier des charges, on lui montre, et toute modification supplémentaire est facturée / facturable. Là, il y repensera à deux fois sur la prochaine demande de modification, et c'est limite lui même qui vous apportera "son cahier" des charges détaillé

[nfluch]

J'ai effectivement parlé de qualité produit.
Cependant la qualité process dans ton cas aurait été : J'ai détecté une limitation, vous devriez corrigé votre besoin (cahier des charges, task tracker, spécification, etc).

Car tu as un introduit un changement non tracé (et donc non recetté), d'un point de vue purement qualité, tu as introduit une anomalie (ie. un écart à la spécification).
De plus, tu as passé du temps sur une activité non prévue.

et surtout que si son client décide de faire le chieur, il va lui dire qu'il ne veut pas de son évolution et lui demander de revenir à l'ancienne pour gratis
et de plus peut être un avertissement de la part de son employeur (j'ai déjà vu ça ya pas longtemps...)

[phili_b]

sauf si on est en régie longue ou en interne.

[_skip]

Vous n'allez quand même pas dire que ça n'a pas quelque chose de profondément dérangeant de ne pas pouvoir éliminer un problème parce que pour ça, 10 mètres cube de paperasse signés et contresignés seraient nécessaires en aval...

Je comprend que dans certaines boîtes avec des rapports naturellement tendus avec les clients ça doivent être ainsi mais perso j'aurai l'impression d'être un drone sans cervelle si je devais laisser des faiblesses dans un process en connaissance de cause juste parce que du point de vue de la spécification (document assez incomplet par nature) il n'y rien d'expressément précisé.

[MiaowZedong]

Vous n'allez quand même pas dire que ça n'a pas quelque chose de profondément dérangeant de ne pas pouvoir éliminer un problème parce que pour ça, 10 mètres cube de paperasse signés et contresignés seraient nécessaires en aval...

Je comprend que dans certaines boîtes avec des rapports naturellement tendus avec les clients ça doivent être ainsi mais perso j'aurai l'impression d'être un drone sans cervelle si je devais laisser des faiblesses dans un process en connaissance de cause juste parce que du point de vue de la spécification (document assez incomplet par nature) il n'y rien d'expressément précisé.

C'est le problème de l'entreprise...

Les actionaires veulent que les employés ne fassent que le travail pour lequel ils sont payés, mais ne peuvent pas contrôler directement donc ils imposent toute sortes de contrôles qui te font effectivement comported comme un drone. En même temps les entreprises qui laissent faire n'importe quoi finissent par couler, donc, en entreprise c'est le moins pire qui ai été trouvé.


Après pour le fun, j'ai fais la comparaison entre la valeur éstimée du nouyeau Linux (ce qu'on estime qu'il couterait à une entreprise de le developper) et la charge de travail réelle de ses developpeurs, il n'y a vraiment pas photo: les developpeurs du libre sont beaucoup plus productifs. En même temps, je suis sur qu'un maçon construit son mur plus vite et mieux qu'un mur qu'il construit au travail

[alex_vino]

En même temps, je suis sur qu'un maçon construit son mur plus vite et mieux qu'un mur qu'il construit au travail

Plus vite je ne pense pas car il va s'appliquer à bien fignoler tous les détails, mais mieux ça c'est une certitude.
Très joli exemple

[_skip]

En même temps les entreprises qui laissent faire n'importe quoi finissent par couler, donc, en entreprise c'est le moins pire qui ai été trouvé.

Si tu es cuisinier dans un restaurant et que tu vois que ton steack est brûlé, tu envoies quand même le plat en sachant ce que ça va donner ou est-ce que tu prends sur toi de faire quelque chose?

Bon ok c'est tiré par les cheveux comme comparaison, mais je pense que c'est quand même plus compliqué que ça. Les entreprises dont les développeurs laissent passer des choses douteuses, voire foireuses parce que la machinerie en aval est trop rigide à secouer, c'est plutôt celles-là je ne vois pas durer longtemps.
Enfin je dis ça je dis rien mais on voit de plus en plus dans les méthodologies dites agiles qu'une place importante est attribuée à la responsabilisation des acteurs du projet justement pour éviter d'en faire des drones. Et c'est censé grandement améliorer la qualité.

Après pour le fun, j'ai fais la comparaison entre la valeur éstimée du nouyeau Linux (ce qu'on estime qu'il couterait à une entreprise de le developper) et la charge de travail réelle de ses developpeurs, il n'y a vraiment pas photo: les developpeurs du libre sont beaucoup plus productifs. En même temps, je suis sur qu'un maçon construit son mur plus vite et mieux qu'un mur qu'il construit au travail

J'avoue que ton analyse sur la productivité des développeurs du libre et la conclusion que tu en tires m'échappent complètement .
Pour ce qui est de dire qu'un employé qui bosse pour lui fait du meilleur boulot qu'un employé qui bosse à son travail, je n'adhère pas du tout à cette généralisation. En quoi une personne qui travaille pour elle-même (càd en obéissant à ses seuls critères de qualité) devrait bosser mieux et plus vite que lorsqu'elle travaille pour son employeur (en sachant que le travail est vendu à un client et qu'ainsi, les critères qualité sont les règles de l'art)?

La vérité à mon sens c'est que la balance peut autant pencher d'un côté comme de l'autre. Autant tu peux avoir un gars qui en a rien à foutre tant que son travail n'est pas pour lui, autant tu peux en avoir un autre qui s'applique moins parce que justement ce qu'il fait c'est *juste pour lui* et qu'il n'est pas tenu de fournir les mêmes garanties de qualité.
Moi même quand je développe des petites choses pour mon usage perso, je fais en sorte que ça fasse ce que je demande mais je ne pousse pas les GUI et la gestion d'erreurs etc... au même stade que lorsqu'il s'agit d'un déliverable destiné à un client utilisateur.

Bref sans vouloir partir dans du HS, j'avoue que je ne suis pas aussi convaincu que toi par ces différentes affirmations.

[JPLAROCHE]

bonjour,
je suis à 15 mois de la quille, je suis en entreprise privé PME

j'ai aimé mon métier d'informaticien, mais aujourd'hui j'ai pété les plombs deux fois ma santé en a pris un sale coup et le stress au bout d'un moment on ne gère que difficilement. Un tunnel dont on ne vois pas le bout

70h voir 80h par semaine impossible de lâcher..... sinon plus de boulot,
ma femme est bien malade,hum pas des blagues bien sur certain diront que je n'avais qu'à .... mais a 60ans on ne trouve plus de travaille. je ne suis pas de ceux qui ce cache derrière les syndicats d'ailleurs on est leurs bêtes noires il y a les projets qui démarres ou qui sont en phase final, la maintenance hors travailles et la pression quand on vous rends responsable .... oui je suis très loin des 35h et sans oublier la compression de personnel tous le monde ce dit informaticien veulent vous apprendre votre travail car ils touchent à la maison leurs ordinateurs confonde leurs feuilles Excel(dont il ne se serve qu'à 15%) et une application ex: commercial ou stock .... gestion d'entreprise là je vis mes derniers instant car tous le monde a été mis dehors et un erp prend la place il fait papa maman et la bonne soeur ah j'oubliai il ne réfléchi pas et les responsabilités devront être prise quand a la bonne marche des choses elle est mise dans les main d'une personne qui n'ai pas informaticienne et ne connaît pas la gestion d'entreprise mais la direction ce frotte les mains un service de moins à payer économie ( de bout de chandelle pour moi)
je suis amer car j'ai travailler sans compter ni regardé la pendule j'ai cru a des valeurs et puis le vide aujourd'hui il est minuit 45 je dort mal il me faudra du temps pour me remettre heureusement après 40 d' Ibm 3.10 3.8 360 32 34 36 38 as400(depuis 1989 octobre ) et les pc
1985 mon premier pc a moi car j'y croyais (pascal l'assembleur le C le basic ... )
aujourd'hui une petite consolation Linux et de bon produit de développent mais je suis las et je sais pas si j'ai encore la moelle pour titiller le C++

[_skip]

Un témoignage intéressant...
Il est si facile de dire qu'on ne doit pas hésiter à faire le choix entre le travail et la santé. Mais est-ce que ce choix on l'a toujours? Et durant toutes les étapes de sa vie? Pas sûr...

Les compressions de personnels informatique se ressentent quand même pas mal, surtout dans les boîtes non IT. J'ai une connaissance qui bosse en maintenance dans une grande structure, il y a certaines erreurs connues qui se produisent de temps en temps qu'il a officieusement ordre de dépanner sans chercher à fixer le problème (il pourrait). Ca paraît idiot alors pourquoi cela? Et bien ils sont 8 au service informatique, chaque intervention donne lieu à du papier signé avec temps de travail et tout ça. Ils savent très bien que si le management s'aperçoit qu'au niveau du nombre d'heures il y a une petite chance que le travail des 8 tiennent sur un planning hyper-serré à 6, il y en a 2 qui vont gicler. Du coup ils laissent des petites choses arriver pour que leur département continue d'exister sous sa forme actuelle.

Pour ce qui est du développement dans ces mêmes boîtes, tout est sous-traité à l'extérieur, ça crée plein de situations problématiques au niveau support car les compétences concernant le logiciel qui se trouve dans le produit fini livré au client ne sont pas sur place. Bref.

Il y a un chiffre qui traîne comme quoi un énorme pourcentage des chefs d'entreprise ne sont pas satisfaits de leur système informatique. Franchement ça s'explique pas seulement par l'incompétence générale des informaticiens, loin de là.

[coshibe]

Voilà vraiment un discussion très intéressante pour moi qui sort d'ecole.

Je suis actuellement fonctionnaire. Niveau horaires je travaille en belgique donc 38h par semaine, l’excédent pouvant être récupéré en journée de récup'.

Au niveau de la charge de travail : on ne me donne pas de délais, pas de pression, personne ne controle ce que je fais. Donc je me fais plaisir je soigne mes applications, j'ajoute des fonctionnalités qui me semblent bien. Certains diront que c'est inutile, mais ce que je code je vais en être responsable pendant un long tres long moment. Donc j'ai tout interet à bien l'ecrire la premiere fois. Et c'est un gros avantage par rapport à tous ceux qui travaillent en SSII et qui doivent se demander s'ils en font trop ou pas assez.

Par contre je regrette énormément de ne pas avoir un commercial, ou un responsable un peu plus sur mon dos. Car mine de rien le fait d'avoir des comptes à rendre ça motive beaucoup plus et ça donne l'impression que ce qu'on fait est important, alors que là, quand j'ai fini mon appli je la publie sans avoir de comptes à rendre, ce n'est pas très motivant.

Ensuite pour ce qui est des gens qui disent travailler 50 à 70h par semaine. Je suis certain que ca existe et que c'est possible, 'ai vu ce que ca donne dans le domaine banquaire, notamment pour toute la partie front - office. Certains connaissent peut-être ceux qu'on appelle les "commandos" des programmeurs a qui on demande de coder pour la veille. Ces gars là triment comme des malades, mais en général au bout de quelques temps à galérer ils montent en grade et finissent avec des salaires >6k/mois donc ca en vaut la peine. Personnellement je préfère gagner mois mais vivre plus à coté. Alors certes je ne pourrais sans doute jamais me payer la même voiture qu'un trader. Mais j'arrive à reconnaitre ma femme dans la rue

Et pour ce qui est du probleme des SSII, c'est une vraie plaie. Lorsque j'ai travaillé dans le domaine banquaire, tout etait sous-traité.
1. On commande un nouveau programme à une SSII
2. la SSII recrute pour la faire
3. la SSII livre le produit et renvoie les jeunes embauchés.
4. un peu plus tard on a besoin de faire une modification, mais comme le code du produit est baclé(pour ne pas dire torché) du coup il faut rappeler la SSII mais comme celle ci a renvoyé ses employés, elle va devoir en embaucher de nouveau pour réétudier la chose, ou alors on va tout recommencer à zero en ajoutant les nouvelles fonctionnalités.
C'est du vecu, et cela peut se faire sur du court terme. Alors que ca aurait sans doute couté moins cher de créer un service informatique de développement compétent et surtout persistant. Quitte à les convertir en HelpDesk en periode calme.

Quant au travail effectif, pour ma part je pense être à 15h/semaine. Etant débutant je passe beaucoup de temps à me documenter (Exclusivement sur DVP bien sur). Je regrette de ne pas avoir un mentor/parrain/senior pour m'encadrer au début, je suis sur que je serai 2 fois plus rentable si c'était le cas.

En bref, avoir de la pression peut etre penible, mais un minimum de stress vous apporte enormement d'autosatisfaction lorsque vous aboutissez.

[MiaowZedong]

Et pour ce qui est du probleme des SSII, c'est une vraie plaie. Lorsque j'ai travaillé dans le domaine banquaire, tout etait sous-traité.
1. On commande un nouveau programme à une SSII
2. la SSII recrute pour la faire
3. la SSII livre le produit et renvoie les jeunes embauchés.
4. un peu plus tard on a besoin de faire une modification, mais comme le code du produit est baclé(pour ne pas dire torché) du coup il faut rappeler la SSII mais comme celle ci a renvoyé ses employés, elle va devoir en embaucher de nouveau pour réétudier la chose, ou alors on va tout recommencer à zero en ajoutant les nouvelles fonctionnalités.
C'est du vecu, et cela peut se faire sur du court terme. Alors que ca aurait sans doute couté moins cher de créer un service informatique de développement compétent et surtout persistant. Quitte à les convertir en HelpDesk en periode calme.

C'est la mode de la flexibilité. Il faut être flexible de nos jours, le problème c'est que (comme toutes les modes) la plupart des adeptes de la flexibilité ne comprennent pas pourquoi et imitent autrui. Du coup, ils sont flexibles même quand ça leur sert à rien et coute très cher, comme dans ton exemple.

Cela dit, dans ton exemple la conversion en HelpDesk ne marche pas: il faut un HelpDesk tout le temps, donc pas besoin de personnel supplémentaire (et surpayé) en période calme. Par contre, je doute fort qu'une grande banque se retrouve jamais à n'avoir aucun besoin en Dev, donc il serait logique d'avoir un service "maison", quitte à lui adjoindre des supplétifs (CDD, intérimaires, prestataires SSII) pour les grosses missions.

[Logan Mauzaize]

J'ai eu une dizaine d'anomalies là-dessus, donc ça a été recetté quand même!!! dont 8 étaient des demandes d'amélioration déguisées, en fait. Si ils avaient été assez stupides pour se limiter à leur plan de recette, on ne serait pas allé bien loin, ni sur ce sujet, ni sur d'autres.

C'est justement le travail du commerciale de blinder son contrat pour qu'il n'y ait pas trop d'ambiguité et celui du chef de projet de "négocier". La première activité de la gestion des anomalies est "le tri". Comme dans les urgences d'un hopital, il faut classifier/catégoriser/prioriser/pré-analyser les problèmes.

Le fait que ça soit moi qui soit en charge de bidouiller les fichiers en cas de plantage a du jouer, aussi.....

Au final, si j'avais proposé le truc, ils auraient refusé, car "trop cher". En fait, je leur ai fait gagner du temps et de l'argent, et dès qu'ils ont vu le truc ils se sont jetés dessus en en demandant plus. C'est mal, mais ça marche.

Si tu leur facture chaque intervention ca ne devrait pas trop les peiner de te "commander" la modification

Je considère que notre métier est de faire une appli qui marche. Si un bricolo nécéssaire n'est pas spécifié(du genre, la gestion d'erreurs), mais qu'il est nécéssaire au bon fonctionnement de l'appli, il faut le faire quand même. Je demande à mon dentiste de me coller un bridge, si il a des opérations en plus à faire pour que ça tienne, ça n'est pas à moi de les spécifier.

Ton boulot, tout comme celui de ton dentiste, est de respecter un contrat. Celui de ton dentiste c'est de te soigner sans te ruiner. Une "opération"/un geste qui ne lui coûte pas grand chose peut-être qu'il te le fera gratuit ; ou peut-être pas, mais dans ce cas TU DEVRAS PAYER ! Comme il s'agit de ta santé, tu l'accepteras sûrement sans rechigner.
Cependant c'est moins vrai pour une entreprise qui derrière doit capitaliser tout ce qu'elle dépense.

S'il doit te faire payer un geste ou qu'il existe un risque, tout médecin te fera signer un papier !

Le produit(dans notre cas le fichier final produit) est tel que demandé, ni plus, ni moins. Le process, c'est à nous de le faire pour qu'il soit efficace. Mais se limiter bêtement à la spec, c'est en général aller dans le mur - sauf méthodes de type aérospatial qui coutent 10 fois plus cher(hypothèse basse).

Tu le dis toi-même, tu te places dans un contexte et une situation dans laquelle la qualité n'est pas demandé/contrainte. Les méthodes qualité ne sont donc pas acceptables dans ton cas !

J'ai fait économiser le travail de deux "petites mains" (n'y voyez rien d'irrespectueux) qui auraient dû rentrer des tarifs (= faire une conversion d'un tableau excel vers un programme totalement différent) sur toute une semaine. Le salaire de deux "petites mains" sur une semaine c'est tout de même plus cher que le travail d'une matinée pour moi.

Sauf si l'entreprise pouvait te faire générer de l'argent durant cette même matinée

Je n'ai, en fait, jamais connu de client qui savait exactement ce qu'il voulait, comme il voulait, et (surtout) qui arrivait à imaginer ce que ça donnerait au final. La seule solution viable à ce genre de problème c'est l'activité que je déteste par dessus tout à savoir : faire un cahier des charges détaillé, page par page, écran par écran, avec "quand l'utilisateur clique ici ça donne ça". Ainsi, si le client est pas content, on ressort le cahier des charges, on lui montre, et toute modification supplémentaire est facturée / facturable. Là, il y repensera à deux fois sur la prochaine demande de modification, et c'est limite lui même qui vous apportera "son cahier" des charges détaillé

Ca me fait penser à une anecdote l'année dernière. Dans mon travail, je ne travaille pas avec le décideur (qui n'est pas le client non plus mais qui est très proche de lui : service commercial, support, etc.) mais avec une sorte d'AMOA qui rédige des spécifications détaillées (telles que tu les décrits) à partir d'un cahier des charges du décideur. Après une longue série d'échange (environ 1 an), ils arrivent à se mettre d'accord sur une spécification détaillée concernant un nouvel écran : captures d'écran, l'utilisateur appuie sur tel bouton, ca provoque telles et telles actions, ainsi de suite.
Nous réalisons donc l'écran et livrons l'application ; et là, le décideur refuse la livraison et signale que ce n'est pas du tout ce qu'il avait imaginé

Cependant, j'aime bien les outils tels que les présentations et Balsamiq. Commercialement parlant, j'aurais tendance à annexer ces documents, même s'ils n'ont aucune valeur mais juste pour limiter les excès de mauvaises foi.

et surtout que si son client décide de faire le chieur, il va lui dire qu'il ne veut pas de son évolution et lui demander de revenir à l'ancienne pour gratis
et de plus peut être un avertissement de la part de son employeur (j'ai déjà vu ça ya pas longtemps...)

Et en plus, il te demandera de finalement l'intégrer pour gratis (ou pas cher) car tu l'as déjà fait. Même si c'était pour la version d'il y a deux ans et que tout à changer depuis !

Vous n'allez quand même pas dire que ça n'a pas quelque chose de profondément dérangeant de ne pas pouvoir éliminer un problème parce que pour ça, 10 mètres cube de paperasse signés et contresignés seraient nécessaires en aval...

Tu ne vas quand même pas dire que ça n'a pas quelque chose de profondément dérangeant de pouvoir faire crasher un avion parce qu'un développeur a joué sa forte tête ?
La qualité est nécessaire pour un moins deux choses qui sont fondamentales dans notre société (ou même l'esprit humain au sens large) : la justification et la responsabilité.
Tu pourras également dire qu'il y a quelque chose de profondément dérangeant à ça mais c'est une réalité !

Je comprend que dans certaines boîtes avec des rapports naturellement tendus avec les clients ça doivent être ainsi mais perso j'aurai l'impression d'être un drone sans cervelle si je devais laisser des faiblesses dans un process en connaissance de cause juste parce que du point de vue de la spécification (document assez incomplet par nature) il n'y rien d'expressément précisé.

Hélàs c'est l'avenir de notre métier, même si c'est déjà beaucoup du présent. L'industrialisation, on pourrait dire le "taylorisme", de nos activités est bien ancrée dans les moeurs avec des choses comme CMMi. Les clients veulent et doivent (économiquement parlant) se centrer sur leurs coeurs de métiers et donc déléguer ("sous-traiter") les activitiés qui ne sont pas les leurs. Dans ce contexte, il faut au maximum industrialiser/rationnaliser ce que l'on fait (enfin surtout la manière dont le fait, puisqu'on parle de processus).

Cependant je reviens sur le

drone sans cervelle

. Ne pas résoudre un problème, n'indique pas qu'il ne faut pas le détecter, le remonter et trouver l'arrangement idéal pour tous les partis. La recherche de la cause de l'introduction de l'anomalie (et non la cause de l'anomalie), la recherche de solution pour éviter que cela se ne reproduise et leurs mises en place, nécessitent je pense beaucoup plus de cervelle que la simple détection/correction en "autiste" !

Pour en revenir à l'industrialisation, tu vas t'éloigner de l'ouvrir de production, que l'on délguera à des sud-méditerranéens (Maroc, Tunisie) ou des extreme-orientaux (Chine, Inde) pour te rapprocher de celui de contre-maître !

Si tu es cuisinier dans un restaurant et que tu vois que ton steack est brûlé, tu envoies quand même le plat en sachant ce que ça va donner ou est-ce que tu prends sur toi de faire quelque chose?

Il y a bien des restaurateurs qui envoient de la viande avariée !
L'équivalent du steak brûlé ce serait une application qui ne fonctionne vraiment pas, alors que notre problème tiens plus de la sauce trop salée. Résultat à Macdonald, ils envoient alors qu'au Phuket le cuisinier se fait virer !

Bon ok c'est tiré par les cheveux comme comparaison, mais je pense que c'est quand même plus compliqué que ça. Les entreprises dont les développeurs laissent passer des choses douteuses, voire foireuses parce que la machinerie en aval est trop rigide à secouer, c'est plutôt celles-là je ne vois pas durer longtemps.

C'est également ton travail de remonter ces problèmes et de trouver des solutions !

Enfin je dis ça je dis rien mais on voit de plus en plus dans les méthodologies dites agiles qu'une place importante est attribuée à la responsabilisation des acteurs du projet justement pour éviter d'en faire des drones. Et c'est censé grandement améliorer la qualité.

Dans les méthodes agiles, il n'y a rien de contraire à ce que j'ai dit. Bien au contraire, puisque dans le cas de SCRUM, c'est le "product backlog review" (si mes souvenirs sont bons) qui visent à "amender"/"valider"/"signer" le contenu de la prochaine livraison. En revanche, le processus a pleinement intégré (contrairement au modèle en V ou W) l'existence d'anomalie et d'évolution dans les entrées au fur et à mesure de la vie du projet.

J'avoue que ton analyse sur la productivité des développeurs du libre et la conclusion que tu en tires m'échappent complètement .
Pour ce qui est de dire qu'un employé qui bosse pour lui fait du meilleur boulot qu'un employé qui bosse à son travail, je n'adhère pas du tout à cette généralisation. En quoi une personne qui travaille pour elle-même (càd en obéissant à ses seuls critères de qualité) devrait bosser mieux et plus vite que lorsqu'elle travaille pour son employeur (en sachant que le travail est vendu à un client et qu'ainsi, les critères qualité sont les règles de l'art)?

On est toujours plus exigeant/impliqué/motivé quand c'est pour nous-même. C'est une grande mauvaise foi (et pourtant ma femme sait que j'en ai une grande !) que de dire le contraire.[/QUOTE]

[el_slapper]

Nemek : je ne cite pas tou, ça serait trop long. D'abord, je précise que je suis en régie(ce qui modifie un opil les relations). Surtout, j'ai deux chaises : je fais le projet, et je le maintiens une fois qu'il est en place. Et je fait face à des cons(pas tous, hein, juste cette équipe), qui ne comprennent que le fait accompli.

A chaque fois que j'ai fait remonter des choses, la réponse a été.....pas de réponse, en fait, comme si je parlais à la mer. Tu parles comme si tout le monde jouait le jeu. Ca n'est pas le vrai monde. Dans le vrai monde, tu as des jeux de pouvoir, des susceptibilités, des blocages, qui font que passer par la voie standard n'est pas toujours possible. Et dans ces cas-là, désolé, je triche. La méthode pour moi d'imposer cet outil méthodologique indispensable a été de le faire, et d'attendre les réactions. Y'en a pas d'autre!!!!! J'ai tout essayé, la persuasion, l'explication, l'appel aux urbanistes, etc..... Seul marche le fait accompli.

Surtout, la vraie méthode qualité, la bourrine, la panzerdivision aerospatiale, est bien trop couteuse pour fonctionner dans 99% des cas. Même avec les moyens dont dispose la banque qui est mon client, il n'est pas possible de jouer au con en disant "votre spec n'est pas claire, j'ai codé comme j'ai compris, si ça vous ne convient pas, c'est 6 mois de plus". Faire su zéle de méthodologie(hors cas exotico-spatiaux), c'est souvent un moyen de ne pas faire son boulot, tout en essayant de faire croire qu'on est professionel.

Les méthodes qualité ont été mises en place en production automobile, pas en conception automobile. Développer du logiciel, c'est de la conception. Appliquer aveuglément les méthodes qualité de la production automobile au développement logiciel est un aller-simple garanti vers l'enfer.

Ton exemple de "conception qui plait-résultat qui ne plait pas" c'est un grand classique. C'est toujours comme ça. C'est pour ça que la méthode qualité automobile(qui elle part déjà d'un produit parfaitement défini, et développe tout ce qui faut pour le produire de manière répétitive) n'est pas applicable à nos métiers. Spécialement en interfaces : la SFD, aussi détaillée soit-elle, ne permet pas au décideur de "sentir" l'interface telle qu'elle sera. Déjà, pour les batches, il y a souvent des trous(eh, le client décédé, pourquoi on peut encore taper sur son compte?), et c'est au programmeur de les combler.

[Logan Mauzaize]

Nemek : je ne cite pas tou, ça serait trop long. D'abord, je précise que je suis en régie(ce qui modifie un opil les relations). Surtout, j'ai deux chaises : je fais le projet, et je le maintiens une fois qu'il est en place. Et je fait face à des cons(pas tous, hein, juste cette équipe), qui ne comprennent que le fait accompli.

J'avoue pleinement ne pas avoir connu la régie et il y a de moins en moins de chance que ce soit le cas, vu que la plupart des clients de ma boîte externalise les régies qui étaient déjà qu'une mascarade (aussi appelé "Forfait in-situ").

A chaque fois que j'ai fait remonter des choses, la réponse a été.....pas de réponse, en fait, comme si je parlais à la mer. Tu parles comme si tout le monde jouait le jeu. Ca n'est pas le vrai monde. Dans le vrai monde, tu as des jeux de pouvoir, des susceptibilités, des blocages, qui font que passer par la voie standard n'est pas toujours possible. Et dans ces cas-là, désolé, je triche. La méthode pour moi d'imposer cet outil méthodologique indispensable a été de le faire, et d'attendre les réactions. Y'en a pas d'autre!!!!! J'ai tout essayé, la persuasion, l'explication, l'appel aux urbanistes, etc..... Seul marche le fait accompli.

Je réitère un point important : si tu ne travailles pas dans un environnement de qualité, tu ne peux pas faire de la qualité. C'est comme faire du SCRUM (ou méthodes agiles en général) sans implications des parties !
Cependant si tu travaillais dans un environnement de qualité, il y a des choses qui obligent les gens à répondre présent : les indicateurs et les revues.
Je ne connais que CMMi (même si de très loin) donc j'estimerai que c'est un standard pour la qualité des projets informatiques : toutes les phases de projet sont soumises à des indicateurs (des chiffres clés qui résument la situation). Ces derniers vont du simple j/h jusqu'au nombre de d'anomalie, en passant par le coût moyen par anomalie, le nombre de remarque sur la documentation en entrée, le nombre d'échange (téléphone, courrier, réunion) et leurs fréquences.
Lors de la mise en place des revues les indicateurs à surveiller ont été défini, et à chaque revue ces indicateurs sont analysés. Lorsque que quelqu'un ne joue pas le jeu, au moins un des indicateurs va passer au rouge et la personne en question rapidement identifiée. Vois ça comme des tests de non-régression ;-)

Ce que tu définis comme méthode de travail, me fait énormément penser au concept "Théorie du héros" de CMMi. Je t'invite à lire la littérature à ce ce sujet et à envoyer quelques passages aux messieurs concernés ^_^

Surtout, la vraie méthode qualité, la bourrine, la panzerdivision aerospatiale, est bien trop couteuse pour fonctionner dans 99% des cas. Même avec les moyens dont dispose la banque qui est mon client, il n'est pas possible de jouer au con en disant "votre spec n'est pas claire, j'ai codé comme j'ai compris, si ça vous ne convient pas, c'est 6 mois de plus". Faire su zéle de méthodologie(hors cas exotico-spatiaux), c'est souvent un moyen de ne pas faire son boulot, tout en essayant de faire croire qu'on est professionel.

Je ne suis pas sûr qu'un peu de qualité coûte un bras, ça reste comme une assurance : un petit coût pour en cas de problème que ça ne coûte pas les yeux de la tête. En revanche, elle nécessite de l'implication mais c'est en général le principe de "projet".

PS : je continuerai plus tard

[el_slapper]

(.../...)Ce que tu définis comme méthode de travail, me fait énormément penser au concept "Théorie du héros" de CMMi. Je t'invite à lire la littérature à ce ce sujet et à envoyer quelques passages aux messieurs concernés ^_^(.../...)

J'attends la suite de ta théorie, mais je précise que j'ai connu les normes EAQF en automobile, que ça marche très bien...en automobile.

Pour ce qui est de la théorie du héros, le problème, c'est que ça marche. Dans ce lien, l'auteur dit que la principale raison de succès des projets(y compris à la NASA) est la suivante :

“A few good people stepped in at key moments and did whatever was needed to get the job done.”

, que je traduirais par "quelques gens de qualité ont pris les choses en main à un moment clef, et on fait ce qu'il fallait pour que le travail soit fait.".

"stepped in" peut aussi se traduire par "sont intervenues", mais je pinaille.

Sur un grand nombre de projets, l'auteur a constaté que la qualité process n'avait qu'une influence faible sur le pourcentage de succès. Influence d'ailleurs négative - les processus "légers" ayant un taux de succès marginalement supérieur(et non pas massivement comme le prétendent les experts en agile). Par contre, la qualité intervenant - qualité de communication, qualité de la motivation, et qualité intrinsèque, dans cet ordre - est un facteur bien plus primordial.

CMMI, c'est un moyen de garantir que les gens font bien ce qu'on leur a demandé. Ca ne garantit en aucun cas que ce qu'on leur a demandé est exhaustif et sans erreurs. Une spec sans erreur, je ne connais pas. Ca n'existe pas - ou alors si, ça existe : c'est un code final complétement débuggué, prêt à être livré(lien que j'ai mis précédemment).

[taha1]

40 c'est peu je dirais ...

j'ai vu des chef de projets et des managers faire 7h-19h (donc si on fait le calcul, en comptant les pauses déjeuners ... ça fait plutôt 50h par semaine).
Après je dirai que c'est une question de priorité ... mais c'est vrai que ceux qui font des horaires de fou sont très bien payés aussi.
pour ma part je ne tiens pas le compte mais c'est sûr que je fais plus que le nombre d'heures mentionnées dans mon contrat.

[Robin56]

mais c'est vrai que ceux qui font des horaires de fou sont très bien payés aussi.

Pas forcément non.

[taha1]

je parle des CP qui bossent comme des fous (j'en connais pas mal) dans leur cas travailler plus = gagner plus mais ce n'est pas une généralité qui s'appliquent aux autres (les développeurs inclus)

[Robin56]

je parle des CP qui bossent comme des fous (j'en connais pas mal) dans leur cas travailler plus = gagner plus

Euh désolé d'être une nouvelle fois pas d'accord avec toi mais je dirais encore "Pas forcément non"

Les CP ont devant eux un planning avec un budget à tenir et une limite de ressource (avec un client sur le dos, la qualité, etc ...). Ils ont donc normalement plus de pression sur eux ce qui se traduit souvent par des volumes horaires importants. De là à trouver une corrélation entre leur volume horaire et leur salaire, c'est pas forcément proportionnel non.

[Logan Mauzaize]

bonjour,
je suis à 15 mois de la quille, je suis en entreprise privé PME

j'ai aimé mon métier d'informaticien, mais aujourd'hui j'ai pété les plombs deux fois ma santé en a pris un sale coup et le stress au bout d'un moment on ne gère que difficilement. Un tunnel dont on ne vois pas le bout

70h voir 80h par semaine impossible de lâcher..... sinon plus de boulot,
ma femme est bien malade,hum pas des blagues bien sur certain diront que je n'avais qu'à .... mais a 60ans on ne trouve plus de travaille. je ne suis pas de ceux qui ce cache derrière les syndicats d'ailleurs on est leurs bêtes noires il y a les projets qui démarres ou qui sont en phase final, la maintenance hors travailles et la pression quand on vous rends responsable .... oui je suis très loin des 35h et sans oublier la compression de personnel tous le monde ce dit informaticien veulent vous apprendre votre travail car ils touchent à la maison leurs ordinateurs confonde leurs feuilles Excel(dont il ne se serve qu'à 15%) et une application ex: commercial ou stock .... gestion d'entreprise là je vis mes derniers instant car tous le monde a été mis dehors et un erp prend la place il fait papa maman et la bonne soeur ah j'oubliai il ne réfléchi pas et les responsabilités devront être prise quand a la bonne marche des choses elle est mise dans les main d'une personne qui n'ai pas informaticienne et ne connaît pas la gestion d'entreprise mais la direction ce frotte les mains un service de moins à payer économie ( de bout de chandelle pour moi)
je suis amer car j'ai travailler sans compter ni regardé la pendule j'ai cru a des valeurs et puis le vide aujourd'hui il est minuit 45 je dort mal il me faudra du temps pour me remettre heureusement après 40 d' Ibm 3.10 3.8 360 32 34 36 38 as400(depuis 1989 octobre ) et les pc
1985 mon premier pc a moi car j'y croyais (pascal l'assembleur le C le basic ... )
aujourd'hui une petite consolation Linux et de bon produit de développent mais je suis las et je sais pas si j'ai encore la moelle pour titiller le C++

Ca résume bien une chose : passer 30 ans tu dois être manager sinon tu vaux plus rien alors justement passer 30 ans tu as une vraie valeur ajoutée !
Sinon c'est moche à dire mais fait pas plus, pas moins que ce pourquoi tu es payé, au pire on te vire et tu profites du système français (si tu es en France :/) ultra-protecteur qui fera le relai en attendant la retraite ... Pour les détracteurs et la foule de gens qui vont s'indigner, il faut admettre que ce n'est pas à un seul citoyen de supporter les méfaits d'une entreprise/organisation mais bien à l'état d'agir. Cependant l'état agit rarement, il reste donc la passivité de la protection sociale pour combler ce manque !
Je ne conseillerai que trop aux gens de mettre de l'argent côté (complémentaire retraite, épargne) pour ne pas à avoir à choisir entre santé et travail à tout moment de la vie et encore moins lorsque la santé au plus bas comme à l'approche de la retraite !

Les compressions de personnels informatique se ressentent quand même pas mal, surtout dans les boîtes non IT. J'ai une connaissance qui bosse en maintenance dans une grande structure, il y a certaines erreurs connues qui se produisent de temps en temps qu'il a officieusement ordre de dépanner sans chercher à fixer le problème (il pourrait). Ca paraît idiot alors pourquoi cela? Et bien ils sont 8 au service informatique, chaque intervention donne lieu à du papier signé avec temps de travail et tout ça. Ils savent très bien que si le management s'aperçoit qu'au niveau du nombre d'heures il y a une petite chance que le travail des 8 tiennent sur un planning hyper-serré à 6, il y en a 2 qui vont gicler. Du coup ils laissent des petites choses arriver pour que leur département continue d'exister sous sa forme actuelle.

Entièrement d'accord et ca se retrouve partout. Quasi tous les services pour lesquels j'ai travaillé en sous-traitance demandent des avances/acomptes sur projet afin de liquider le budget et ne pas le voir se faire réduire comme peau-chagrin chaque année !

Pour ce qui est du développement dans ces mêmes boîtes, tout est sous-traité à l'extérieur, ça crée plein de situations problématiques au niveau support car les compétences concernant le logiciel qui se trouve dans le produit fini livré au client ne sont pas sur place. Bref.

Il y a un chiffre qui traîne comme quoi un énorme pourcentage des chefs d'entreprise ne sont pas satisfaits de leur système informatique. Franchement ça s'explique pas seulement par l'incompétence générale des informaticiens, loin de là.

L'externalisation en soi n'est pas forcément un problème, en tout cas pour la production. En revanche pour le support, ça peut être problématique surtout quand il faut en revenir à la base. Exemple (extrêment capilotracté) un PC a besoin de courant pour fonctionner !
Cependant je pense qu'il y a un gros problème dans l'accompagnement. Est-ce que le problème vient des décideurs, des utilisateurs ou de l'offre ? Au moins d'un peu partout, mais il est vrai que généralement ce sont les décideurs qui (prochent de leurs sous) ont dû mal à capitaliser ce que leurs coûtent leurs systèmes d'information. Exemple très cons mais très concrets (que je tire de ma propre société, une SSII qui plus est !), si la secrétaire perd 2h par jour dans un logiciel/process mal foutu alors qu'un petit logiciel pas cher ferait l'économie de ce travail journalier qui joue également sur son moral et sa motivation.

Et c'est un gros avantage par rapport à tous ceux qui travaillent en SSII et qui doivent se demander s'ils en font trop ou pas assez.

Tu fais toujours pas assez de choses en trop de temps
Sérieusement ton manager est là justement pour te cadrer, s'il est diplomate et pas trop con, il te le dit gentillement sans que ça l'air d'un blâme.

Par contre je regrette énormément de ne pas avoir un commercial, ou un responsable un peu plus sur mon dos. Car mine de rien le fait d'avoir des comptes à rendre ça motive beaucoup plus et ça donne l'impression que ce qu'on fait est important, alors que là, quand j'ai fini mon appli je la publie sans avoir de comptes à rendre, ce n'est pas très motivant.

Je dirai que ca permet d'avoir un oeil externe qui contrôle/cadre/dirige les choses !

Ensuite pour ce qui est des gens qui disent travailler 50 à 70h par semaine. Je suis certain que ca existe et que c'est possible, 'ai vu ce que ca donne dans le domaine banquaire, notamment pour toute la partie front - office. Certains connaissent peut-être ceux qu'on appelle les "commandos" des programmeurs a qui on demande de coder pour la veille. Ces gars là triment comme des malades, mais en général au bout de quelques temps à galérer ils montent en grade et finissent avec des salaires >6k/mois donc ca en vaut la peine. Personnellement je préfère gagner mois mais vivre plus à coté. Alors certes je ne pourrais sans doute jamais me payer la même voiture qu'un trader. Mais j'arrive à reconnaitre ma femme dans la rue

La proportion de gens qui sont récompensés pour leurs mérites (salaire, prime, position, poste) est à mon avis extrêment minime, voir inexistante dans certaines boîtes.
C'est un simple constat économique que tout personne (manager ou non, ayant fait une école commerciale ou non) fait rapidement, pourquoi dépenser plus pour quelqu'un qui fait son travail et/ou plus à même récompense/rémunération ?

Et pour ce qui est du probleme des SSII, c'est une vraie plaie. Lorsque j'ai travaillé dans le domaine banquaire, tout etait sous-traité.
1. On commande un nouveau programme à une SSII
2. la SSII recrute pour la faire
3. la SSII livre le produit et renvoie les jeunes embauchés.
4. un peu plus tard on a besoin de faire une modification, mais comme le code du produit est baclé(pour ne pas dire torché) du coup il faut rappeler la SSII mais comme celle ci a renvoyé ses employés, elle va devoir en embaucher de nouveau pour réétudier la chose, ou alors on va tout recommencer à zero en ajoutant les nouvelles fonctionnalités.

Pour limiter ce genre de problèmes car contractuellement les SSII ne sont pas tenus de maintenir leurs ressources, c'est le principe du forfait, beaucoup de société sont passés au bundle.
Sinon externaliser ne veut pas nécessairement dire forfaitiser, si tu restes en AT c'est le client qui reste maître des ressources.

Quant au travail effectif, pour ma part je pense être à 15h/semaine. Etant débutant je passe beaucoup de temps à me documenter (Exclusivement sur DVP bien sur). Je regrette de ne pas avoir un mentor/parrain/senior pour m'encadrer au début, je suis sur que je serai 2 fois plus rentable si c'était le cas.

Oui mais ce dernier coutera deux plus cher :p

En bref, avoir de la pression peut etre penible, mais un minimum de stress vous apporte enormement d'autosatisfaction lorsque vous aboutissez.

T'es pas énormément autosatisfait quand tu arrives à un résultat tout seul comme un grand ?

Ton exemple de "conception qui plait-résultat qui ne plait pas" c'est un grand classique. C'est toujours comme ça. C'est pour ça que la méthode qualité automobile(qui elle part déjà d'un produit parfaitement défini, et développe tout ce qui faut pour le produire de manière répétitive) n'est pas applicable à nos métiers. Spécialement en interfaces : la SFD, aussi détaillée soit-elle, ne permet pas au décideur de "sentir" l'interface telle qu'elle sera. Déjà, pour les batches, il y a souvent des trous(eh, le client décédé, pourquoi on peut encore taper sur son compte?), et c'est au programmeur de les combler.

J'invite fortement dans ce cas à utiliser des outils de Wireframing et de présentation. Par ailleurs, ça me semble beaucoup plus parlant que n'importe quel spécification, tout comme quelques diagrammes UML. Cependant tout ces outils graphiques ne peuvent faire valider/utiliser contractuellement, donc les dossiers "traitements textes" restent indispensables.

J'attends la suite de ta théorie, mais je précise que j'ai connu les normes EAQF en automobile, que ça marche très bien...en automobile.

"La théorie du héros" décrit un projet qui serait dirigé par une (voir quelques) tête(s). Et que le jour où l'équipe (de l'ensemble du projet, du client au développeur) est décapitée, le projet peut être considéré comme mort. Et comme tout finit par changer/mourrir, le projet ne peut pas vivre "éternellement" (comprendre longtemps). Pour des projets one-shot, cela reste entièrement viable. Et encore, je pense qu'il est possible de capitaliser sur un projet one-short car la personne a appris, tester, détecter des limitations, etc que ce soit sur le produit lui-même mais également des produits avec lesquels il interagit etc.

Rien n'empêche, je te l'accorde de générer/tracer/conserver tout cela. Cependant il y a une grande constation que beaucoup de personnes a faite est que si le code n'est pas toujours bien fait ; la documentation, les tests, etc sont toujours sous-estimés/baclés/absents/incomplets/etc

Pour ce qui est de la théorie du héros, le problème, c'est que ça marche. Dans ce lien, l'auteur dit que la principale raison de succès des projets(y compris à la NASA) est la suivante : , que je traduirais par "quelques gens de qualité ont pris les choses en main à un moment clef, et on fait ce qu'il fallait pour que le travail soit fait.".

"stepped in" peut aussi se traduire par "sont intervenues", mais je pinaille.

Cela rejoint l'idée des méthodes agiles, limiter le nombre d'intervenant et faire en sortes qu'ils soient très proches pour qu'il y ait une grande réactivité de toutes parts. Que ce soit quand le client change d'avis ou quand le développeur trouve un problème.

Sur un grand nombre de projets, l'auteur a constaté que la qualité process n'avait qu'une influence faible sur le pourcentage de succès. Influence d'ailleurs négative - les processus "légers" ayant un taux de succès marginalement supérieur(et non pas massivement comme le prétendent les experts en agile). Par contre, la qualité intervenant - qualité de communication, qualité de la motivation, et qualité intrinsèque, dans cet ordre - est un facteur bien plus primordial.

Tu admets donc qu'en l'absence de ces qualité, il te faut bien un système garantissant au mieux l'obtention de ces qualité, au pire de les combler ?

CMMI, c'est un moyen de garantir que les gens font bien ce qu'on leur a demandé. Ca ne garantit en aucun cas que ce qu'on leur a demandé est exhaustif et sans erreurs. Une spec sans erreur, je ne connais pas. Ca n'existe pas - ou alors si, ça existe : c'est un code final complétement débuggué, prêt à être livré(lien que j'ai mis précédemment).

Je suis bien d'accord, il s'agit bien de structurer le process et non décrire les activités de chacun ! Cependant l'assurance qualité vise à garantir la détection des erreurs au plus tôt, limiter leur introduction et améliorer leurs réparations.