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 :
De ton point de vu cela te semble ridicule mais son point de vu est compréhensible. Il a compris que si tu réduis les tâches par personne, c'est pas pour en donner d'autre. Un autre va faire le calcule suivant : 4 jours homme par semaine de gagné alors ça fait 16 jours par mois et par tête = Suppression de poste. Si tu supprimes des postes alors il faudra pas de responsable, donc lui il saute.Envoyé par Ymer Leahcim
Regarder autrement
Cet article semble n'être vu que sous l'angle technique.
Certains point sont une conséquence justement d'un relâchement dans la qualité des livrables avant développement.
La méthode scrum ne doit pas être un justificatif, ni un palliatif aux mauvaises analyses.
Le développeur ne devrait travailler qu'avec des livrables et pas faire ce qui lui plaît.
oh mais je l'avais compris.
là où j'ai pas compris, c'est la peur de la personne "chef" et sa non-volonté à vouloir améliorer l'entreprise où elle bosse et la vie de ses saalriés subordonnés en leur faisant faire autrechose de qualitatif.
Depuis j'ai compris que lorsqu'on se rend compte d'une solution comme ça (réduisant les tâches itératives d'un groupe de personnes), il ne faut surtout pas en parler au chef, mais au supérieur hierarchique du chef (1 degrés de subordination plus haut).
Heu je suis pas sure. Bypasser un chef peut être mal perçu selon les cas.
En faite, c'est un situation complexe. Cela dépend de plusieurs paramètres qui sont en dehors du domaine technique. J'ai découvers ce cas dans le secteur bancaire ou je suis actuellement.
- Arriver à un certain âge, des utilisateurs n'aiment pas le changement, même si ça va dans le bon sens. Changement = bouleversement.
- Si tu proposes quelque chose qui fait gagner du temps en améliorant le process, tu créés du vide, et il faut le remplir. Vide = payer à rien faire et on connait les risques.
- L'orgeil du chef et le risque de voir de l'arrogance sur une personne qui arrive avec des idées.
Il faut être diplomate heu non, fourbe
Moi également.
Peut être que toi aussi tu aurais été viré.Bon juste pour rire
je double-rire !Peut être que toi aussi tu aurais été viré.Bon juste pour rire
car en fait c'est ce qu'il s'est passé pour moi dernièrement : je me suis rendue inutile en format tout le monde aux tâches informatiques de base, en résolvant tous les bugs applicatif, proposant dans mon agence (une SSII) de vendre plutôt des CMS au lieu d'avoir des sites sur mesure....
et au fil du temps, mon ex-patron avait moin de choses lourdes et concrêtes à me faire faire.
un site conçu intégralement c'est 100% d'ingenierie
un CMS c'est 90% de tâches bureatiques et 10% de tâches d'admin-ingénierie
En gros, j'ai été le maçon qui a éveillé et conseillé son patron à la vente de maison préfabriquées. c'était il y a 4ans.
aujourd'hui quand je vois la conception des sites internet, c'est 9/10 qui sont des CMS et 95% ont un template acheté à 30$ légèrement modifié par un stagiaire webdesigner....
Beh désolé
Kouskefil
Je suis d'accord avec le fait que Cohen défonce les portes déjà grandement ouvertes, mais dans un domaine où l'autre de la vie, il y a toujours un débutant pour qui des conseils peuvent être donnés !
Mais tu as fais ton ton boulot et dans le bon sens. Il y a des endroits ou des personnes freinent des 4 fers pour maintenir une certaine dépendance envers eux. Donc quand un jeune coq arrive avec de bonne idées pour améliorer la productivité ça vole dans les plumes.
Effectivement...et la grande question, c'est combien de ces sites sont-ils vraiment vivants et bien référencés. Depuis que je bosse dans le web, j'ai vu je ne sais combien de fois arriver un client avec un plaquette (pour les pires) et me dire "je veux ça sur mon site web". J'ai passé un temps fou à expliquer que ce ne sont pas les mêmes médias et surtout qu'un site doit être vivant sinon il tombe aux oubliettes. Et là j'ai eu plus que souvent la réponse "mais je n'ai personne pour alimenter le site", sans parler du "mais qu'est-ce qu'on va mettre dedans?"
Donc un site fait "à la va comme je te pousse" sans réflexion, ça ne sert à rien. Autant le faire en HTML statique (je grossis le trait volontairement). En fait ces sites ne sont pas réfléchis et les gens ne veulent pas y consacrer de temps ni d'argent.
Cet article est un assez bon résumé de ce que j'ai pu rencontrer comme difficultés en trente années de carrière.
Parler de péchés à des informaticiens est évidemment une habile provocation. Le cerveau des informaticien est tout particulièrement rôdé à pourfendre les croyances par l'épreuve des faits. Cela est assez peu compatible avec une quelconque piété.
Cependant les avanies de la relation client/développeur ne sont qu'une des variations du thème de la conflagration des univers mentaux.
Un récent exemple m'a montré que bien des biais apparaissent quand des médecins élaborent un texte réglementaire avec des sportifs.
Il n'est pourtant pas inutile de s'atteler à en démontrer les mécanismes.
Identification ronflante de problèmes déjà connus depuis longtemps et que tous les méthodes de développement essaie de résoudre... Si on parle toujours et toujours de ces problèmes de développement, c'est peut-être parce qu'aucune méthodologie de développement, Agile ou autre, apporte un véritable solution pleinement satisfaisante à ces problèmes! Il faudrait peut-être arrêter de parler de problèmes et de s'attaquer à de véritables solutions innovatrices. Pour ma part, Agile a fait des efforts mais n'en déplaisent à ses admirateurs n'est pas LA solution.
<troll> "... l'auteur, Harlan Coben, ...". Lololol</troll>
Agile permet de simplifier les choses et de faire communiquer les différents intervenants...à condition de se poser les bonnes questions.
D'expérience quand un sujet a du mal à arriver à terme, je finis par poser la question "C'est quoi le besoin" et là, assez régulièrement, j'ai pu constater une différence assez notable entre la réponse donnée à cet instant et ce qui a été écrit dans les spèc. On en revient souvent à ce" problème d'expression, voire d'identification, du besoin.
Oui mais là, tu n'abordes qu'une partie du sujet.
Il y a aussi le cas où le besoin évolue, tout simplement.
Lorsque l'on met le client en situation de marché, avec la concurrence mondiale qui ne s'arrête jamais, il faut s'avoir s'adapter.
Sur un projet court, ça n'a pas de raison d'arriver
mais dès que le projet s'étale dans le temps...
Forcement
Ecrit comme ça, oui.
Mais dans les faits, beaucoup ont du mal à le comprendre et/ou à l'accepter.
Il y a quelque temps, quand j'ai quitté le monde des sociétés de services pour passer côté client, j'ai eu à mon arrivée une discussion de ce type :
"
* Ce que tu me demandes ne correspond pas au SFD
* oui, mais le SFD a été écrit il y a 4 mois...
* je m'en fous, le SFD c'est le SFD !!
"
Je te laisse deviner lequel des interlocuteurs j'étais et ce qu'il est advenu du presta lorsqu'il est arrivé le moment de renouveler sa mission...
Disons que dans un projet où tout va bien, il est facile de faire des concessions et donc d'assouplir les règles et par conséquent d'accepter des modifications des SFD. Par contre quand le projet va mal et que tout le monde se braque et se cache derrière son contrat, le moindre changement peut poser problème...
Personnellement, quand je pose la question du "C'est quoi le besoin", c'est pour forcer l'interlocuteur à reformuler et ainsi à confirmer son besoin. Ensuite si son besoin correspond bien à ce qui était écrit, pas de souci on continue. Si ça diffère, on se pose et on réfléchit aux impacts de ce changement et à comment le prendre en compte. Agile n'est qu'une boite à outil permettant de gérer cette situation en donnant des règles simples et partagées pour la prise de décision.
Les erreurs
La gestion des erreurs dans la développement d'une application est a notée pas facile
Répondre avec citation
Partager