Au mur et une balle dans la tête :ccool:Citation:
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 !
Sinon, je ne connaissais pas ce Dilbert. Je vais de ce pas checker qui c'est ...
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.Citation:
Envoyé par el_slapper
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.
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.Citation:
Envoyé par Carhiboux
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.
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 ;-) )...
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 :P
ça me fait halluciner d'imaginer que le gars n'ai pas eu un projet à plusieurs à concrétiser pour obtenir son diplômeCitation:
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.).
et quand on réalise un projet à plusieurs, bah on reste pas dans son coin :?
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...Citation:
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.
comment est-ce possible de ne découvrir cela qu'une fois en entreprise
en fait, durant ses études, il n'a jamais développé de programme complexeCitation:
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 ».
juste des fonctionnalités :aie:
euh, une nouvelle fonctionnalité c'est... nouveau, en plus, donc forcément dans un code existantCitation:
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.
et ça rejoint mon commentaire précédent...
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ésCitation:
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.
il devrait peut être changer de boulot...
ça dépend du programmeCitation:
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.
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 :ccool:
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 :(Citation:
Envoyé par laurdbayrone
bah c'est la même chose partout... ou pasCitation:
Envoyé par laurdbayrone
ç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
Dans la métallurgie, le PDG sait que l'acier existe.Citation:
Envoyé par laurdbayrone
Preuve que la métallurgie possède les mêmes soucis.Citation:
Envoyé par deadalnix
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.
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).
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.
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 :aie:
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.Citation:
Envoyé par ElJipi
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)....Citation:
Envoyé par deadalnix
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é.
Pas du tout.Citation:
Envoyé par deadalnix
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 ! :ccool: "
3. Réaction de l'ingénieur : 8O :furax: :mur:
Évidemment, ceci est une caricature... (tout le monde sait bien qu'il faut au minimum 4 mois pour développer un warp drive engine... :roll: :aie:)
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... :aie: )
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à... :roll:
Outre l'excellente réponse de pcaboche, j'aimerais pointer le fait que le mot "echec" a pas mal de définitions différentes.Citation:
Envoyé par deadalnix
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.
On remarque ici que tout le monde à un comportement rationnel. Le blâme reviens donc à ceux qui fixent les règles du jeu.Citation:
Envoyé par pcaboche
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.
Excellente remarque.Citation:
Envoyé par deadalnix
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... :?
Juste une question : est-ce que vous vous trouvez dans ce j'appelle "le cycle en 2 temps" ? (voir citation ci-dessous)Citation:
Envoyé par deadalnix
Citation:
Envoyé par pcaboche