Ca doit être assez emmerdant quand même, bien des années plus tard, quand le gars est mort. :p
1 - "Hey Bob, c'est quoi mon mot de passe déjà ?"
2 - "Au secours, je crois que quelqu'un a volé mon mot de passe et hacké notre système !"
3 - "On m'a donné un programme gratuit et quand je l'ai installé, mon système a crashé."
4 - "On va passer à l'outsource IT, tu pourrais former tes remplaçants ?"
5 - "Finalement, on a pas pris le programme que tu as testé"
6 - "Mon fils à besoin d'un job alors je le place au service IT"
7 - "Je suis d'accord pour qu'on passe à Windows 7, mais alors on n'achète aucun nouveau hardware."
8 - "L'AMF (Autorité des marchés financiers), veut tous nos e-mails des 5 dernières années "
9 - "Assurez-vous que personne ne gaspille du temps (donc de notre argent) sur Facebook !"
10 - "Coupe de budget sur le help desk, vous êtes dispo les week ends ?"
Autre (précisez svp)
Ca doit être assez emmerdant quand même, bien des années plus tard, quand le gars est mort. :p
Eventuellement.. Mais en général le gars qui lui a succédé (même numéro de poste) sait et/ou a les archives...
Mais disons que c'était par rapport au commentaire de Tchize... JE ne vois pas très bien qu'est-ce que ça aurait de ridicule de mettre en raison "voir untel"....
ça peut être temporaire, ça peut être (par exemple dans une assurance) tant qu'une enquête n'est pas terminée, ça peut être que c'est le responsable du compte et qu'il a de très mauvais rapports avec le client, ça peut être pleins de choses...
En tous cas, ça laisse la trace de savoir qui a demandé, et donc de pouvoir aller demander des comptes au besoin, ce qu'une indication 'supprimé" ne donnera ps, à moins justement d'aller faire un historique et voir qui a fait ça , et ce gars-là est parti ailleurs, le retracer, l'appeler, et lui demander pourquoi....
En tous cas, je ne vois strictement rien de choquant (et même au contraire) à avoir cette information...
ça me rappelle, un batch d'éditions de courriers clients, j'avais vu un commentaire sur un remplissage en dur(sous certaines conditions) : numéro de téléphone de Mr machin au 01/01/1984. On était fin des années 2000... Là, c'était un numéro qui apparaissait sur un courrier client, pas un simple commentaire. Assez limite quand même.
Et sinon, expliquer au chef/client/moa ppurquoi on ne peut pas supprmier le client ? Ça peut être pas mal non plus et on peut arriver à des évolutions qui conduiront à un truc propre, maintenable et flexible non ? (je suis toujours sur le soft delete)
Ou alors si la personne concernée ne veut pas en parler, tu lui dit "d'accord, ça prendra 5 jours, et ça sera facturé 3000€..."
Je sais pas pourquoi, mais dès que le mot "euro" entre dans une conversation, de suite, on écoute les gens![]()
Justement, c'est ce que je fais, et alors il reconsidère la discutions![]()
Un cas que j'ai rencontré :
On est dans une phase de test avant livraison de l'application. Je profite des tests pour regarder les différentes erreurs lancées, mais catchés, et je fais des corrections si elles sont nécessaires.
Moi : "Tiens chef, j'ai corrigé un paquet d'erreurs qui étaient lancée dans l'application, ça devrait être plus propre maintenant. J'ai corrigé celle-là, celle-là, et celle-ci."
Chef : "Ah non mais celle-ci on était au courant, il faut pas la corriger sinon ça fera tout planter !"
Moi : "???"
Chef : "Oui, c'est un vieux truc, on s'en sert plus maintenant"
Moi : "Mais dans ce cas pourquoi pas avoir supprimé le code au lieu de laisser une exception ?"
Chef : "heu.. ???"
Je connaissait le principe "ne jamais modifier une code qui fonctionne", mais je ne connaissait pas son pendant "ne jamais corriger un code qui fait des erreurs"![]()
Hé, oui, c'est de la que viennent des expressions comme "compatibilité bug-pour-bug".
Quand trop de monde utilise (ou même contourne) un bug, il devient une feature.
(même si les "compatibility shims" de Windows commencent à mitiger un peu cela)
Là je vous en fait part, puisque j'en ai eu un fou rire immédiat (aux larmes)
"Nous sommes en retard, soit mais nous n'avions pas correctement perçue la diffuculté du projet au démarrage, en outre, nous avons du réaliser un travail préparatoire de 2 ans, nécessaire aux développement de l'application, et aujourd'hui, il s'avère que le framework résultant n'est pas optimal et que nous avons encore des charges de développement technique. Nous savons que la version béta (ndlr : et encore, béta c'est un GRAND mot pour décrire l'inframerde que c'est) a des problèmes de stabilité et de performance. Cependant nous allons lancer un projet visant à développer mieux et plus vite en conservant notre framework technique"
Quand mon avis fut demandé, j'ai répondu que je faisais face au premier cas réel de terrorisme informatique.
J'allais dire "ils ont mis deux ans à sortir un bouse, mais proposent de perdre du temps à tout réécrire en conservant la partie bouseuse, en espérant que ça améliore le tout"....
En fait c'est juste l'histoire d'une boite où les gens ne bossent pas, où le resp du dev se bat contre le resp de la moa, qui s'entourent de gamins qui sortent de l'école, pas de gestion de projet, pas d'expérience, et donc ça fini en grand n'importe quoi. Pas grand chose à voir avec le dev en fait, faudrait juste que leur patron développe un sens de la sanction plus important.
Ce n'est pas toujours facile d'avoir un même Resp. Dev et Resp. MOA. C'est même souvent une Fausse Bonne Idée car on perd une partie de la vision (Métier ou Technique).
Par contre il faut un chef de projet avec du recul pour arbitrer sinon au lieu d'avoir un triumvirat qui va avoir tendance à s'équilibrer plus ou moins on a une situation de choc frontal.
Enfin, le coup du "Au bout de deux ans on lance un projet qui va certainement durer 2ans pour sauver la grosse bouse au lieu de reprendre le projet du départ avec de vrais pros", je connais.
C'est un cas classique de déni d'échec. Le manager qui a pris les décisions considère comme une faiblesse de reconnaître l'énormité de son erreur et part dans une fuite en avant. Souvent ça finit par la fin du manager (viré à coup de pompe dans le c... ou golden-parachuté selon la taille de la boîte) ou par la mort de la boîte. ... quand c'est pas les deux simultanément (Je me golden-parachute avant que le bateau coule ...)
Sinon connaissez vous le syndrôme du nostalgique ?
En gros vous avez une problématique et à chaque fois votre manager dit "On a fait un truc comme ça il y a 5ans, je vais vous passer les archives !" et vous vous retrouvez obligé de devoir reprendre une vieille bouse obsolète par essence (en fait un concept de vieille bouse car il faut pas se leurrer, rien n'est utilisable quand ca vient des archives) et cela coûte 3 fois le prix à la boîte.
La première et la seule fois ou j'ai entendu parler de MOA, c'est en France, pays ou par tradition, on a tendance à metre 4 ou 5 responsables de projet au dessus des développeur. Le seul type au dessus ca doit être le responsable de projet. La vision métier, t'as deux possibilité: soit elle viens du client, on est donc dans le classique discussion du responsable avec le client pour connaitre ses besoins, soit elle est coté fournisseur, et dans ce cas là on l'intègre à l'équipe comme n'importe quel dev. Pareil pour l'architecte, il rentre dans l'équipe, il est pas au dessus
Je suis allé faire un formation en gestion de projet agile en France, j'étais éffaré par le nombre de gens qu'il fallait là bas pour faire tourner un projet. Heureusement, mon formateur canadien avait le même avis et n'a pas arrêté de rappelé à l'architecte présent à la formation qu'aux états-unis, les arhcitecte software commencent à mendier dans les rues![]()
Oui c'est vrai la dernière fois que j'ai fait le blind test du fabuleux comité projet, j'ai demandé combien avait déjà développé au moins une application, 1 a levé le doigt, et combien avaient des compétences de dev, et le même a levé le doigt.
Comme nous étions 12 dans la salle à lui expliquer quoi faire, j'ai du quand même expliquer que si il y avait des problèmes, c'était simplement du fait que
- Inclure des non professionnels dans les échanges ne permet pas d'aller vite
- Faire décider par des non professionnels ne permet pas de prendre les bonnes décisions
- La finalité étant du développement, si c'est le poste où les ressources sont manquantes et en situation de juniorité n'était pas une bonne idée.
![]()
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager