Discussion :

[SamSer]

Mais enfin que voudrais tu que fasse les gens incompétents sinon???
Il faut les intégrer quand même, c'est de la discrimination sinon !

Au mur et une balle dans la tête

Sinon, je ne connaissais pas ce Dilbert. Je vais de ce pas checker qui c'est ...

[guidav]

Parfois, même des professionels se font surprendre par la vraie difficulté de créer une appli complète, et pas seulement son code(qui lui-même n'est pas forcément trivial).

Alors que le maçon, on le voit poser ses briques.

On peut ajouter que même entre pros, on a beaucoup de mal à estimer le temps de travail des uns et des autres sur des technos différentes.
Pour prendre l'exemple d'un gars qui code un peu, mais dont ce n'est pas l'activité principale (moi), je n'ai pas vraiment d'idée du nombre de jours/homme qu'il faut pour développer un projet "fini". Concevoir / développer, ok, j'ai une petite idée, mais documenter, tester, mettre en intégration... tout ça, à moins d'être un "vrai" développeur, c'est très difficile d'en avoir une idée précise.

Je pense qu'on manque beaucoup en France de "bricoleurs", pas informaticiens de formation, qui savent faire leurs propres outils avec un peu de VBA, de C++ ou de PHP à partir de briques bien conçues.

[Cincinnatus]

L'ignorance des décideurs

Comme cité par d'autres avant moi. L'absence de connaissance dans le domaine informatique semble même être devenu une norme ou un prérequis pour accéder à des postes à hautes responsabilités. Tous les hauts postes dans les sociétés d'informatiques un peu conséquentes sont tous occupés par des personnes de formation commerciale.

Effectivement, de plus en plus de DSI sont d'origine HEC ou autres écoles de commerce. Tout simplement parce que l'informatique n'est qu'un centre de coût et n'est pas vue comme un facteur d'innovation pour la boîte.

Bien que simple développeur, j'avais lu il y a quelque temps le livre d'Yves Cazeau Performance du système d'information : Analyse de la valeur, organisation et management, Neuf scènes de la vie quotidienne d'un DSI. L'auteur y mettait bien en évidence ce problème et donnait des pistes pour rendre visible les gains dus à l'informatique.

[JCB001]

Ce qui m'a le plus surpris c'est le manque de procédure standardisée, chaque projet dans chaque entreprise est traité différemment, on est pas dans un process standard tel qu'enseigné en théorie.
Egalement surprenant c'est le mélange de compétents et d'incompétents dans une entreprise (les plus compétents étant souvent moins bien payé : syndrome de Peter ?, les incompétents et paresseux rarement virés, situation peut être typiquement française), une fois j'ai travaillé chez un gros client, projet de 20 personnes et aucune stratégie de test rééllle (5 ans plus tard appli toujours instable m'a ton dit ;-) )...

[Pelote2012]

Ayant commencé dans une SSII, ce qui m'a frappé c'est 2 ou 3 gars hyper balaise sur lesquels l'agence s'appuyé beaucoup dessus (pas de bol pour eux ils sont partis chez des concurrents pour être mieux payés).
Le reste pas très ordonnés, ne surtout rien dire sur la qualité du boulot des gars qui sont là depuis 20 ans (on se demande pourquoi il s sont toujours là)
Et dès qu'une personne quitte un projet, tous les malheurs sont de sa faute ...
J'ai aussi vu des gars partir et revenir (salaire + 50% = 30% par le concurrent + 20% car l'agence ne pouvait pas se passer de lui sur un gros projet , vive le turn over) comme quoi, il n'y a pas que les patrons qui se font avoir (d'un autre côté, il paieraient correctement ...)

Bref je me suis barré de là (en plus je n'avais plus de vie de famille), j'ai trouvé un boulot sympa dans une petit boîte sympa, je revie

[shenron666]

5 - L’interaction avec les personnes

À force de passer du temps devant son ordinateur à coder, on pense que la programmation est un travail solitaire. Pourtant, c’est étonnant le nombre d’interactions avec d’autres personnes en entreprise (réunion, conversation avec des bêta-testeurs, discussion avec des collègues, etc.).

ça me fait halluciner d'imaginer que le gars n'ai pas eu un projet à plusieurs à concrétiser pour obtenir son diplôme
et quand on réalise un projet à plusieurs, bah on reste pas dans son coin

4 - Le problème de l’écriture

Cela aide beaucoup d’être capable d’écrire clairement afin de passer un message. Dans une certaine mesure, la rédaction du code et l’écriture sont tout à fait semblables. Dans les deux cas, vous devez exprimer vos idées clairement et sans ambigüité, d’une manière structurée.

idem que le point précédent quand on doit rédiger une doc, ou une thèse, ou commenter son code pour un jury...
comment est-ce possible de ne découvrir cela qu'une fois en entreprise

3 - Un logiciel n’est jamais terminé

« Avant mon premier travail, je pensais que lorsque vous avez développé une fonctionnalité, vous en avez fini » écrit Warne « Cependant, en réalité, très souvent vous revenez dessus. Peut-être parce que ce n’était pas exactement ce que le client voulait, il faut fixer un bug ou ajouter quelque chose de nouveau ».

en fait, durant ses études, il n'a jamais développé de programme complexe
juste des fonctionnalités

Warne ajoute qu’il ne comprenait pas pourquoi les nouvelles fonctionnalités étaient presque toujours introduites dans un code existant. Ceci à cause du fait de toujours développer des programmes à partir de zéro à l’université, ce qui n’est presque jamais le cas en entreprise.

euh, une nouvelle fonctionnalité c'est... nouveau, en plus, donc forcément dans un code existant
et ça rejoint mon commentaire précédent...

2 - Quelques algorithmes intelligents

Pendant le cycle universitaire, sont enseignés des structures de données et algorithmes intelligents, dont on s’attend à trouver dans les systèmes en entreprise. Cependant, ce sont des structures de données et des algorithmes assez basiques qui sont utilisés dans le monde du travail, d’après Warne.

j'utilise les algorithmes les plus adaptés à la situation, pas forcément les plus basiques, et souvent je dois tester pour trouver le plus efficace voire "tuner", ajuster un algorithme pour un cas avec des particularités
il devrait peut être changer de boulot...

1 - La complexité de l’agrégation

Au vu des algorithmes et structures basiques utilisés dans les programmes, Warne pensait qu’il n’y aurait pas de nombreux défis à travailler sur le système. Ce qui était faux, car le système était extrêmement compliqué à cause du nombre important de fonctionnalités simples qui étaient regroupées ensemble. « La complexité d’un système provient de l'agrégation d'un grand nombre de pièces simples, pas de toutes les pièces complexes » conclut Warne.

ça dépend du programme
c'est vraiment un senior ? ou c'est juste un gars qui a des années d'expériences dans un seul job de dev ?
quand on a fait plusieurs boites et plusieurs domaines fonctionnels divers et variés, on ne peut pas avoir ce genre de réflexion, ou alors on a pas eu de boulot intéressant
ou du moins, c'est ce que je ressent quand je lis ça

au final, j'ai l'impression que le gars a eu des études basiques baclées incomplètes
et a décroché un boulot inintéressant
il ne tient qu'à lui de changer et rendre sa VDM plus intéressante

[laurdbayrone]

Amis développeurs, (cela ne vous rassurera pas), mais sachez que dans l'industrie métallurgique, cest exactement la même chose.

[ElJipi]

Amis développeurs, (cela ne vous rassurera pas), mais sachez que dans l'industrie métallurgique, cest exactement la même chose.

Cela ne me rassure pas du tout

[shenron666]

Amis développeurs, (cela ne vous rassurera pas), mais sachez que dans l'industrie métallurgique, cest exactement la même chose.

bah c'est la même chose partout... ou pas
ça dépend du point de vue de la personne, de son parcours, tant éducatif que professionnel, de l'environnement professionnel, de la persistance de l'existant, etc...

et aussi de la volonté de la personne à ne pas rentrer dans un moule qui ne lui convient pas

[deadalnix]

Amis développeurs, (cela ne vous rassurera pas), mais sachez que dans l'industrie métallurgique, cest exactement la même chose.

Dans la métallurgie, le PDG sait que l'acier existe.

[Squisqui]

Dans la métallurgie, le PDG sait que l'acier existe.

Preuve que la métallurgie possède les mêmes soucis.
Résumer l'acier à la métallurgie, c'est comme résumer le développement logiciel à pisser du code.
Les alliages sont magiques au même titre que le développement logiciel pour le monsieur en haut.
Je pense que les métallurgistes doivent faire la gueule lorsqu'on leur annonce qu'ils doivent produire un métal aux propriétés fantaisistes en un temps irraisonnable.

[deadalnix]

Bon, j'y connais rien en métalurgie, donc la métaphore va se stopper rapidement.

Cependant, je suis à peu près sur que le chef est capable de comprendre qu'un alliage est plus solide d'un autre, plus souple ou je ne sais quoi.

En d'autres termes, le PDG ne connais rien au détail, mais soyons sérieux, ce n'est pas son métier. Cependant, il ne crois pas que le métal sort d'une boita magique (le fait qu'il paye des fournisseurs pour cela doit grandement aider).

[ManusDei]

Ce qui m'a le plus surpris lors des premiers pas en enterprise.

Le bordel ambiant.
Les tâches sont plus ou moins distribuées, mais y a toujours des moments où on va se retrouver à bosser sur autre chose, de non prévu (qui aurait dû être fait par quelqu'un d'autre qui n'a pas le temps, par exemple). On râle aussi pas mal sur l'administration, mais j'ai l'impression que c'est pareil en entreprise.

L'expertise
Ou plutôt le manque de, parfois. Pas le temps semble être le mot d'ordre, donc pas mal de choses sont bidouillées. Et ensuite faut savoir où ranger les bidouilles pour qu'elles soient retrouvables pour la fois suivante. Je suis dans une SSII, bien sûr on range la bidouille en interne, donc si une autre boîte prend le relais, ils recoderont les bidouilles.

La réinvention de la roue
J'ai à mon actif 3 stages de 6 mois, dans 3 entreprises différentes (dont celle qui m'a embauché). J'ai revu les projets de mes deux premiers stages, sous d'autres noms et d'autres formes dans les entreprises suivantes (codés en interne), et apparemment d'autres entreprises les ont refaits aussi.
Je commence presque à comprendre le pourquoi du libre, même si c'est probablement autant le bordel.

[ElJipi]

Pour résumer.

Ce qu'on apprend a l'école et que l'on imagine être (en mieux et plus Pro) en entreprise:
http://fr.wikipedia.org/wiki/Unified_Modeling_Language
http://fr.wikipedia.org/wiki/Cycle_en_V
http://fr.wikipedia.org/wiki/M%C3%A9thode_agile
http://fr.wikipedia.org/wiki/Unified_Process
etc.

Ce que l'on découvre réellement en entreprise:
http://www.risacher.com/la-rache/index.php?z=2

Quand on connait la méthode LaRache et que l'on découvre que c'est la méthode réellement utilisé dans la plupart des SSII. On a tout comprit

[deadalnix]

Quand on connait la méthode LaRache et que l'on découvre que c'est la méthode réellement utilisé dans la plupart des SSII. On a tout comprit

80% des projets informatiques sont des échecs (pa rentables car trop cher, ne répondant pas aux besoins, jamais fini, etc ...). Ça a peut-être un lien.

[jabbounet]

80% des projets informatiques sont des échecs (pa rentables car trop cher, ne répondant pas aux besoins, jamais fini, etc ...). Ça a peut-être un lien.

Ceci dit l'expression et la compréhension du besoin est en lui même un domaine sous-estimé..... En dix ans de boulot j'ai eu assez rarement de cahier des charges suffisamment clair pour commencer à travailler dans de bonnes conditions. Les rares fois ou c’était le cas cela venait de gens qui avait à la fois la connaissance métier (ou en tout cas le comprenait) et la connaissance technique associé (évite les besoin délirant et non réalisable ou trop couteux)....

Lors du déroulement du projet il faut aussi apprendre à être ni trop perfectionniste (explose les délais), ni trop peu (réduit la qualité donc augmente les retours et les cout de maintenance).
....

Bref tout un tas de chose compliqué à équilibrer dans un projet avec plein d'inconnues et des humains pour travailler dessus.

Autrement pour ce qui m'as surpris, pas grand chose si ce n'est que parfois les gens ne travaillent pas tous dans la même direction (faire que les projets marchent et créent de l'activité) et se tirent dans les pattes parfois au point de planter une activité.

[pcaboche]

80% des projets informatiques sont des échecs (pa rentables car trop cher, ne répondant pas aux besoins, jamais fini, etc ...). Ça a peut-être un lien.

Pas du tout.

Ici, il y a confusion entre la cause et la conséquence (et vous allez vite comprendre pourquoi la méthode La Rache est si répandue...).


Recette pour un projet (informatique ou autre) qui échoue :

Ingrédients:

- un commercial payé a la com'

- un système de mesure des performances du commercial complètement biaisé (ex: basé uniquement sur la valeur des contrats qu'il décroche)

Notez que l'ingénieur n'apparait pas du tout dans la liste des ingrédients. C'est normal....

Étapes:

1. Laisser le commercial discuter avec le client (il est important que le commercial soit motivé uniquement par sa com' et que la réussite ou l'echec du projet n'ait aucune incidence sur celle-ci. Si ça plante, on dira que c'est la faute de l'ingénieur)

2. Attendre que le commercial revienne, tout fier de lui, en disant: "hé les mecs, j'ai décroché le contrat du siècle ! Le client avait l'air super emballé par l'idée ! Maintenant que j'ai fait le plus dur (convaincre le client) tout ce qu'il vous reste à faire, c'est développer un "warp drive engine" en 3 mois. Je ne sais pas ce que c'est, mais rien que le nom ça a l'air super cool ! "

3. Réaction de l'ingénieur :

Évidemment, ceci est une caricature... (tout le monde sait bien qu'il faut au minimum 4 mois pour développer un warp drive engine... )



L'idée de base, c'est que même avec les meilleurs ingénieurs du monde, si on a des projets irréalistes ou à produire dans des délais fantaisistes ou avec des ressources insuffisantes, on court inévitablement à la catastrophe. Dans ce cas, dépités, il arrive que même les meilleurs ingénieurs se tournent vers la "méthodologie" La Rache (vu que le projet est condamné d'avance, autant se tourner vers une méthodologie qui demandera moins d'efforts et qui est plus facile à mettre en place... )


Le pire, c'est que certaines personnes jugées "importantes" dans la hierarchie d'une société sont en fait incroyablement remplaçables. Par exemple, en ce moment, j'ai un "chef de projet"/commercial en France, si on demain on me le remplaçait par un perroquet dénué d'intelligence, qui ne comprend rien à ce qu'on lui dit, et ne ferait que répéter "bon, quand est-ce que tu peux nous livrer ?", je ne suis pas sur de pouvoir faire la différence (surtout que je ne communique avec lui que par e-mail ou par téléphone).

Bref si on me le remplaçait par un perroquet, ça ressemblerait un peu à ça:
http://dilbert.com/strips/comic/1995-04-23/
ou plus généralement à ça:
http://search.dilbert.com/search?w=turing+test

Bref, je sens que je vais être content de le quitter celui-là...

[el_slapper]

80% des projets informatiques sont des échecs (pa rentables car trop cher, ne répondant pas aux besoins, jamais fini, etc ...). Ça a peut-être un lien.

Outre l'excellente réponse de pcaboche, j'aimerais pointer le fait que le mot "echec" a pas mal de définitions différentes.

Si on compte tous les projets qui n'ont pas donné dans le temps prévu l'ensemble des fonctionnalités prévues, effectivement, on ne doit pas être loin de 80%. Mais on a aussi des projets qui livrent dans les délais un ensemble incomplet mais utilisable, des projets qui livrent en retard la totalité des composants, etc.....

Et si pcaboche a raison de taper sur les commerciaux, nous les techniciens ne sommes pas forcément parfaits non plus. Nous avons tendance à nous faire plaisir, et ça donne des monstres à 500 milliards que des gens sensés abandonnent dès que possible.

[deadalnix]

Pas du tout.

Ici, il y a confusion entre la cause et la conséquence (et vous allez vite comprendre pourquoi la méthode La Rache est si répandue...).

Recette pour un projet (informatique ou autre) qui échoue :

Ingrédients:

- un commercial payé a la com'

- un système de mesure des performances du commercial complètement biaisé (ex: basé uniquement sur la valeur des contrats qu'il décroche)

Notez que l'ingénieur n'apparait pas du tout dans la liste des ingrédients. C'est normal....

Étapes:

1. Laisser le commercial discuter avec le client (il est important que le commercial soit motivé uniquement par sa com' et que la réussite ou l'echec du projet n'ait aucune incidence sur celle-ci. Si ça plante, on dira que c'est la faute de l'ingénieur)

2. Attendre que le commercial revienne, tout fier de lui, en disant: "hé les mecs, j'ai décroché le contrat du siècle ! Le client avait l'air super emballé par l'idée ! Maintenant que j'ai fait le plus dur (convaincre le client) tout ce qu'il vous reste à faire, c'est développer un "warp drive engine" en 3 mois. Je ne sais pas ce que c'est, mais rien que le nom ça a l'air super cool ! "

3. Réaction de l'ingénieur :

Évidemment, ceci est une caricature... (tout le monde sait bien qu'il faut au minimum 4 mois pour développer un warp drive engine... )



L'idée de base, c'est que même avec les meilleurs ingénieurs du monde, si on a des projets irréalistes ou à produire dans des délais fantaisistes ou avec des ressources insuffisantes, on court inévitablement à la catastrophe. Dans ce cas, dépités, il arrive que même les meilleurs ingénieurs se tournent vers la "méthodologie" La Rache (vu que le projet est condamné d'avance, autant se tourner vers une méthodologie qui demandera moins d'efforts et qui est plus facile à mettre en place... )

On remarque ici que tout le monde à un comportement rationnel. Le blâme reviens donc à ceux qui fixent les règles du jeu.

S'il est clair que ce schema est répandu, tu as aussi celui du projet qui échoue car on a toujours fait selon LaRache. J'ai pu constater le phénomène récemment. C'est plus pernicieux : au début ça marche, et on dev vite. Puis, le soft se révèle avoir quelques défaut pratiquement incorrigibles, dont l'origine elle même est relativement inconnue. Bien sur, il s'est écoulé quelques années dans le process. C'est l'effet soufflet au fromage : ça gonfle bien au début, mais ça se dégonfle aussi vite.

[pcaboche]

On remarque ici que tout le monde à un comportement rationnel. Le blâme reviens donc à ceux qui fixent les règles du jeu.

Excellente remarque.

Généralement, ceux qui fixent ces règles absurdes, ce sont les dirigeants, donc des commerciaux (ou anciens commerciaux). Donc finalement, c'est toujours le même problème...

S'il est clair que ce schema est répandu, tu as aussi celui du projet qui échoue car on a toujours fait selon LaRache. J'ai pu constater le phénomène récemment. C'est plus pernicieux : au début ça marche, et on dev vite. Puis, le soft se révèle avoir quelques défaut pratiquement incorrigibles, dont l'origine elle même est relativement inconnue. Bien sur, il s'est écoulé quelques années dans le process. C'est l'effet soufflet au fromage : ça gonfle bien au début, mais ça se dégonfle aussi vite.

Juste une question : est-ce que vous vous trouvez dans ce j'appelle "le cycle en 2 temps" ? (voir citation ci-dessous)

Ce qui m'a toujours amusé dans l'acronyme "RAD", c'est que cela ne veut pas dire "Développement d'Applications Rapides (comme on pourrait le penser de prime abord), mais "Développement Rapide d'Applications". Et dans les faits, c'est surtout: "Développement Rapide d'Applications (souvent très lentes et pas forcément faciles à maintenir)".

Et dans certains cas, ça se traduit par l'émergence d'un nouveau cycle de développement, que j'appelle "le cycle en 2 temps", malheureusement de plus en plus en vogue:

1er temps:
- l'entreprise exprime un besoin, elle fait un appel d'offres
- un consultant arrive et propose sa solution
- le consultant fait du RAD et respecte les délais
- le client est content, le consultant touche son gros chèque
- on met la solution en prod

2ème temps:
- au bout d'un certain temps d'exploitation, les problèmes de volumétrie/charge apparaissent
- on fait appel à un "spécialiste" pour corriger les défauts de "cette grosse m**** d'application" (dixit les utilisateurs)
- au bout d'un moment (3 ou 4 entreprises où on retrouve le même genre de problème), le "spécialiste" en a ras le c*l de devoir essuyer les m***** de ces consultants à la c*n

J'ai volontairement mis le terme "spécialiste" entre guillemets. En fait, ce qui en fait "spécialiste", c'est qu'il sait se retrousser les manches plutôt que d'utiliser des outils pour gamins censés lui mâcher le travail...

Il existe une variante, qui est le cycle en 3 temps. C'est la même chose que le cycle en 2 temps, mais avec une extension:

3ème temps:
- on sous-traite les évolutions du système dans un pays du tiers-monde où les gens s'en fichent parce qu'ils sont payés au lance-pierre pour travailler sur des applications où tout le monde a jeté l'éponge depuis longtemps
- on demande au dernier spécialiste en place de faire un "transfert de connaissances"
- si ce n'est pas déjà fait dans le 2ème temps (des raisons personnelles qui l'ont contraint à rester), le spécialiste se casse en disant à tout le monde d' "aller se faire ***** avec un ***** pendant qu'un ****** vous ***** le *****... " (utilisez votre générateur d'insultes préféré pour remplir les blancs)