Le travail est fait correctement : c'est jusque que la demande était stupide.Envoyé par I_believe_in_code
Mais, va savoir pourquoi, le demandeur ne se vire pas lui-même.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Le travail est fait correctement : c'est jusque que la demande était stupide.
Mais, va savoir pourquoi, le demandeur ne se vire pas lui-même.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
oh que non !!!
Entre commerciaux, administratifs, banquiers, traders, politiques, il y en a un paquet...
Principe de Peter...
La seule différence, c'est que il y a un vrai support "de la base"...
Il n'y a qu'à voir les enthousiasmes sur ce forum pour tel ou tel nouvel outil, nouvelle techno, nouvelle méthode, nouvelle méthodologie, etc etc..
Les "acteurs de base" sont persuadés que ce qu'ils viennent de voir est la Solution Miracle, et que tous les autres sont des pauvres idiots qui n'ont rien compris encore à l'excellence et à la supériorité de cette Solution Miracle, qui fera qu'on résoudra tous les problèmes, qu'on fera quelque chose de parfait, sans bugs, sans fuites, avec une IHM parfaite et un organigramme des plus compréhensibles et un code des plus maintenables..
Bref que tous les autres avant ne sont que des conservateurs stupides qui ne voient pas La Lumière
Bof....Il y a bien plus d'incompêtents dans les banques que dans l'informatique. Ce fut mon secteur d'activité pendant 6 ans, où j'étais "opérationnel".
Les gens passent un temps dingue à la machine à café, les commerciaux n'ont pas de clients: ce sont des clientéles captives, les produits vendus sont inconnus et mal évalués (d'ailleurs ont l'a récemment compris...), la plupart de gens qui travaillent dans la gestion d'actif ne connaissent pas les calculs financiers de base, ni la réglementation de base. Le nég qui te dit qu'il est trader et se trompe de sens sur change, le gérant qui confond poids et quantité fout tout le portefeuille à découvert et te répond qu'en tant que gérant il n'a pas à justifier ses opérations, l'analyste qui se bourre la gueule à une soirée client et fini par insuter des gens sur place, celui qui oublie de passer une opération et explique au client que c'est pour son bien aors qu'il est rentré bourré, à bavasser jusqu'à 18H00 et a loupé la clôture, celui qui achéte un fonds action basé sur la convexité, celui qui te fait perdre un client parce qu'il ne sait pas calculer une expo de change sur le fonds dont il est censé être gérant : tout le fonctionnement est basé sur le copinage, (quand c'est pas les franc macs).
Et comme la somme des gens y travaillant est une incompêtence faramineuse et propagée à l'ensemble du secteur, le marché est lisse, et le syndrôme de peter s'épanoui, d'autant que paradoxalemet, ils font ds heures, pourquoi je ne sais pas, mais il y a aussi un jeunisme sordide propre à ce milieu : Si tu es marié, tu dois faire passer ton travail avant ta famille, si tu ne l'es pas, i faut partager ta vie privée ave tes cllègues, il faut sortir du bureau tard et aller boire avec tes collègues, bref un corporatisme décati et nauséabond. Vu l'air du temps, je pourrai écrire un livre sur les pratiques de ce secteur...
Ayant pu comparer 2 secteurs dont un que j'ai fuis, parce qu'il me provoque des ulcères (vrais) et de vrais pb d'éthique, l'IT est loin d'être vérolée, c'est même encore assez candide : il y a encore des problèmes dus au choc possible entre ceux qui veulent que ça réussisse et ceux qui veulent que rien ne change. Et parfois du bon en sort;
c est vécu par tout le monde, c est certaint, mais l'essentiel c est d'essayer de nettoyer un peut ce bordel quand on a les moyens.
IT Comedy club
Y a du vécu mais j'ai bien rigoler lolll25 signes et expériences réelles qui montrent qu'un projet de développement logiciel est destiné à l'échec
Malgré tous nos efforts pour faire de chaque développement logiciel en entreprise un succès, certains projets restent maudits depuis leur commencement. Voici 25 signes et expériences réelles qui montrent qu'un projet de développement logiciel est destiné à l'échec.
- Le projet change de nom pour la troisième fois en autant de mois.
- Le chef de projet décide qu'il vaut mieux écrire une version séparée du logiciel pour les Etats-Unis plutôt que d'internationaliser une version unique.
- Les spécifications ont commencé quatre mois après le début du développement.
- Le nouveau directeur de R&D informe fièrement les dirigeants que le projet sera fini à 99% en avance sur le planning et leur assure que le logiciel peut-être livré directement aux clients sans avoir besoin de phases de tests.
- Vous êtes un développeur web. Vous ouvrez l'archive ZIP qui contient les fichiers HTML produits par votre client pour le site que vous intégrez à votre application web. Vous découvrez que les documents HTML du client sont simplement des fichiers Microsoft Word sauvegardés au format HTML.
- Le mémo dit que vous allez développer une application 64 bits sur une plateforme 16 bits.
- Le développeur ne comprend pas le document de spécifications et continue de coder malgré tout. Et l'équipe de validation ne sait pas comment réaliser ses tests mais "teste" malgré tout.
- Quand vous voyez le budget du projet, vous réalisez que plus de la moitié a été dépensée pour demander à un infographiste de créer une maquette de la page d'accueil du site, sans même s'assurer que le design était réalisable. Ou sans aucune considération pour les milliers de pages de contenus qui existeront en plus de cette page d'accueil.
- L'utilisateur ou le client demandent de nouvelles fonctionnalités au lieu de se focaliser sur la résolution de bugs et l'amélioration des performances.
- Vous trouvez une liste de 16 bonnes pratiques de développement et réalisez qu'aucune d'entre elles n'est suivie.
- Les rapports d'avancement sont vus comme une insubordination.
- Le nouveau dirigeant remplace toutes les personnes ayant une connaissance profonde de l'organisation par des externes de son ancienne société.
- C'est un gros projet et son nom est Projet Iceberg. Ou alors c'est la troisième fois que la société essaye de l'arrêter et le projet porte le nom de code Phoénix. Etrangement, vous ne croyez pas que celui ci renaîtra de ses cendres.
- Même les clients qui ont eu la version gratuite sont énervés.
- Le manager de votre projet critique (rapportant 80% des revenus de votre société) a appris la technologie choisie depuis moins de trois mois et il forme 4 nouveaux développeurs en même temps. Le manager a eu droit a une durée de trois mois pour réaliser le projet.
- Ils ont changé le chef de projet et relocalisé le projet entier dans une autre ville. (Vous vous considérez comme chanceux que les deux villes soient sur le même continent.)
- Le chef de projet décide d'appliquer la méthode Agile pour "gagner du temps".
- L'équipe de management décide de dépenser un million d'euros sur un projet en valant 20 000. Ensuite les managers décident en accord avec l'équipe achat de la société que le logiciel d'un million d'euros demande un matériel valant 2 millions d'euros. Pendant ce temps, une secrétaire achète un PC d'occasion et un CD-Rom contenant de nouveaux logiciels d'automatisation. Elle code le projet pendant sa pause déjeuner. (On pourrait en fait considérer celui-ci comme un succès).
- Le chef de projet vous informe que maintenir un historique complet de toutes les bases de données est une fonctionnalité obligatoire de l'application, mais il n'a pas eu le temps de (lire : ne sait pas) réaliser un modèle de données pour ça. Alors il a décidé de prendre de l'avance en commençant l'interface web et de s'en inquiéter plus tard. Et c'est le Le chef de projet !
- Le chef de projet dit : "soyez créatifs". Cela se produit après que l'équipe de management ait diminué l'effectif sur le projet de 20%. Et après que l'équipe informatique ait récupéré du matériel prévu pour le recyclage, indiquant que c'était votre environnement de développement.
- Quand vous êtes embauché comme l'architecte principal et qu'après 4 semaines dans le projet vous ne comprenez toujours pas ce qu'ils veulent que vous fassiez. Finalement vous découvrez qu'ils ne savent pas non plus.
- Quand les spécifications indiquent que la nouvelle application doit fonctionner exactement comme celle qui existe déjà.
- L'équipe dirigeante demande une date de livraison de l'application avant même que vous ayez reçu une seule information concernant les fonctionnalités demandées.
- Quand le tout nouveau chef de projet crée un planning sans consulter personne de l'équipe technique et alloue pour chaque élément 2 semaines dans le planning (y compris les éléments comme "architecturer la base de données" et "écrire le code").
- On vous donne de nouvelles fonctionnalités à développer le jour de la livraison. Souvent.
C'est une liste basée sur des témoignages de nombreux professionnels de l'informatique. Mais, au final, c'est peut être encore incomplet ? Avez-vous des anecdotes à partager avec nous ?
j'ai pas tout lu ... mais je voudrais vous raconter un expérience vécue (au début des années 90).
Domaine : finances
Objectif: pas clair, vague idée de ce qu'il fallait faire et , apparemment personne ne l'avait fait avant.
On a tatonné à gauche à droite, puis fait des protos ... pendant un an!
Le chef de projet a pété un cable mais la direction nous a soutenu (mais oui!)
Une fois que les idées ont été claires on a commencé à coder en Juillet, la version Beta était prête en septembre et le produit final livrable en janvier.
On a donc travaillé sans specs et au radar.
Non seulement ça s'est vendu comme des petits pains, mais , comme on n'était pas sûr de nous, chaque partie avait été testée à mort et le produit s'est révélé robuste (j'ai rencontré plus tard un client qui l'avait fait tourner 7 ans sans un problème).
Comme Monsieur Jourdain on avait fait de "l'agile" sans le savoir. Mais les point principaux du succès étaient:
- un petite équipe technique soudée travaillant "en commando" (des spécialistes très bien payés)
- une communication permanente et confiante avec la direction (oui il existe d'excellents managers et d'excellents commerciaux!)
- une grande rigueur dans le contrôle des résultats, dans la documentation de ce que l'on faisait (d'autres on pris le relai).
Donc oui le projet heureux existe!
(sans doute avec des modalités chaque fois différentes: le point critique est la relation entre donneurs d'ordres et équipe de réalisation. La programmation est une aventure humaine avant tout!).
Un petit mot supplémentaire car je suis revenu sur quelques pages en arrière...
A propos de "l'industrialisation": voilà un joli mot magique censé résoudre les problèmes de notre "industrie".
Pourquoi personne ne parle de "l'industrialisation de la stratégie miliaire"?
Voilà une comparaison qui va choquer et pourtant je dis tout le temps que le premier bouquin d'informatique a été écrit vers 1830! C'est "De la guerre" de Clausewitz (ne prenez pas les choses au premier degré: j'ai des raisons puissantes et graves pour détester la chose militaire: mais les aspects méthodologiques de Clausewitz sont fondamentaux).
Vécu pendant un stage en licence info, le logiciel n'est jamais entré en production, la nouvelle directrice commerciale n'en voulait pas- L'utilisateur ou le client demandent de nouvelles fonctionnalités au lieu de se focaliser sur la résolution de bugs et l'amélioration des performances.
On peut pas comparer le dév à l'architecture ou à l'automobile pour une raison simple :
Quand une maison tient debout, tu peux pas l'installer chez un autre utilisateur.
Si tu devais développer chaque fois le même logiciel pendant 20 ans, je peux t'assurer une chose, à la fin, tu approcherais du zéro bug.
Et si tu faisais construire un pont par l'équipe qui a construit ta maison... je te laisserai le traverser en premier.
Répondre avec citation
Partager