Discussion :

[GreatDeveloperOnizuka]

Bonjour,



Tu pointes la un problème de fond . En entreprise il y a aussi un "hyper administration" et "hyper normalisation". Chaque manager va tenter de mettre dans case tel truc et tel autre ... Quitte a avoir des process dégueulasses ... et qui ne servent au fond à rien ! Une chaine de traitement complexe ... en France on aime la complexité ! Chacun doit montrer qu'il est indispensable ! Alors qu'en réalité il ne l'ai pas.

Chez moi il y en a pas . Par contre ceux qui se sentent indispensables et veulent le montrer oui alors alors que personne n'est indispensable en réalité . Même si je me considère plus compétent que les employés actuels de ma boite pour la plupart, pour me remplacer, ils vont foutre 2 3 mecs qu'il faudra reformer et basta. Au final, ça sera juste une goute sur tout le fric qui est généré. Je pense que le PDG tant qu'il ramasse plus d'oseil qu'il en sort ça lui va en fait.

[Escapetiger]

Enfin il y a les projets dirigés par une femme. Elles adorent faire du micro-management alors qu'elles ne connaissent rien de l'informatique.(.../...)

En aparté via France Culture dont le premier épisode ci-après m'a servi de base pour rendre hommage à nos collègues féminines et IT pro sur developpez ici (Les femmes dans la tech) :

Épisode 1 : Femmes et numérique : un bug dans la matrice
Le sempiternel cliché des filières scientifiques désertées par les femmes semble perdurer voire s'accentuer dans certaines disciplines comme l'informatique...

Épisode 2 : Un siècle de femmes au travail
Si en un siècle, le nombre de femmes actives a doublé, cette irruption résulte d'un siècle d'histoire contrastée. Elle est le fruit d’une évolution des...

Épisode 3 : Femmes à l'écran, clichés au tournant
Les personnages féminins, au cinéma ou dans les séries, véhiculent des normes, des représentations. Dès lors, ils peuvent perpétuer ces normes, ou au contrainte...

Épisode 4 : L'économie du patriarcat
Le patriarcat est avant tout un système économique, qui repose sur l’exploitation des femmes dans le cadre de la famille. Comment l’analyse de cette exploitation...

Source: Les femmes dans l'économie – série de podcasts à écouter – France Culture

[yahiko]

Anecdote sympa.

Pas plus tard qu'aujourd'hui, le DSI, qui n'est pas informaticien, et qui vient d'être parachuté à ce poste il y a moins d'un an, me demande de rédiger un cahier des charges à base de users stories.

Bien sûr, il n'a même pas idée de la contradiction qu'il énonce.

Il veut un cahier des charges, parce que du milieu d'où il vient, l'industrie, ça va de soi avec tout nouveau projet.

Et des users stories, bah parce qu'il paraît que c'est comme ça qu'il faut faire dans l'informatique dixit un coach Agile.

Et on s'étonne pourquoi les "méthodes" Agile sont voués à l'échec...

Le problème de l'informatique en France, à 90%, c'est l'incompétence des managers.

[egann538]

Pas plus tard qu'aujourd'hui, le DSI, qui n'est pas informaticien, et qui vient d'être parachuté à ce poste il y a moins d'un an, me demande de rédiger un cahier des charges à base de users stories.

Admettons qu'il y a sans doute un problème de vocabulaire. Après ça ne me paraît pas délirant de vouloir réunir les User Stories dans un document qui sera ensuite décliné? Qu'il s'appelle cahier des charges ou backlog je ne pense pas que ce soit un grand problème. Mais bon je ne connais pas le contexte.

[Gunny]

Le problème de l'informatique en France, à 90%, c'est l'incompétence des managers.

Je suis venu dans ce thread pour dire ça, donc +1000. En France on a d'une part beaucoup trop de managers, et d'autre part ceux-ci manquent très souvent de compétences. Cela étant un corollaire du fait que le métier de développeur est mal valorisé et trop souvent vu comme un marche-pied vers des fonctions de management : levez la main si vous avez déjà entendu qu'on ne peut pas rester dev toute sa vie, ou que rester dev après 35 ans c'est pas normal. Le problème de l'incompétence en découle naturellement car un bon dev ne fait pas forcément un bon manager, problème amplifié par l'extrême conservatisme des boîtes françaises, pour qui il ne faut surtout pas dépenser d'argent pour former ses salariés.

[Pierre Louis Chevalier]

J'ai lu des articles intéressants en anglais qui expliquaient que en somme le management devrait être au service des développeurs et non le contraire, puisque au final c'est eux qui font le boulot, et mieux ils sont traités et aidé et mieux ils bossent.
Le management de développeurs en informatique n'a rien à voir avec le management de soldats à l'armée. Dans un sens le développeur en informatique n'est pas juste seulement un genre de scientifique appliqué à l'informatique mais c'est aussi souvent un créatif, voir un artiste, qui doit donc être motivé, protégé, chéri et choyé

Je suis moi même manager et ma façon de faire est pas loin de ça, j'essaye juste de faire en sorte que tout roule et que les développeurs soient formées et motivés, et qu'ils puissent s'épanouir dans le meilleur environnement de travail possible, par exemple tu ne met pas un développeur dans un open space à coté d'un commercial qui hurle au téléphone toute la journée, et tu évites d'aller le déranger toutes les 5 minute pendant qu'il code.
Il doit y avoir un dialogue et un équilibre sain qui s'instaure, une équipe de développeurs n'est pas la pour répondre dans la minute aux lubies de n'importe quel commanditaire incompétent qui demande la lune pour demain, c'est en étant à l'écoute des équipes de développement que l'on peu comprendre ce qu'il est raisonnablement possible de faire, comment et dans quel délais.

[Escapetiger]

Je suis venu dans ce thread pour dire ça, donc +1000. En France on a d'une part beaucoup trop de managers, et d'autre part ceux-ci manquent très souvent de compétences. (.../...)

Merci à nouveau * Gunny depuis «ton» Danemark,

« Les voyages forment la jeunesse » (cf. Montaigne ** )... et les moins jeunes !

* Les développeurs sont plus heureux en Europe du Nord

** « Faire des voyages me semble un exercice profitable. L’esprit y a une activité continuelle pour remarquer les choses inconnues et nouvelles, et je ne connais pas de meilleure école pour former la vie que de mettre sans cesse devant nos yeux la diversité de tant d’autres vies, opinions et usages »

[GreatDeveloperOnizuka]

Admettons qu'il y a sans doute un problème de vocabulaire. Après ça ne me paraît pas délirant de vouloir réunir les User Stories dans un document qui sera ensuite décliné? Qu'il s'appelle cahier des charges ou backlog je ne pense pas que ce soit un grand problème. Mais bon je ne connais pas le contexte.

Ce qui se rapproche du cahier des charges classique serait le Vision Doc : https://en.wikipedia.org/wiki/Vision_document

Je suis venu dans ce thread pour dire ça, donc +1000. En France on a d'une part beaucoup trop de managers, et d'autre part ceux-ci manquent très souvent de compétences. Cela étant un corollaire du fait que le métier de développeur est mal valorisé et trop souvent vu comme un marche-pied vers des fonctions de management : levez la main si vous avez déjà entendu qu'on ne peut pas rester dev toute sa vie, ou que rester dev après 35 ans c'est pas normal. Le problème de l'incompétence en découle naturellement car un bon dev ne fait pas forcément un bon manager, problème amplifié par l'extrême conservatisme des boîtes françaises, pour qui il ne faut surtout pas dépenser d'argent pour former ses salariés.

Je l'ai déjà dit plus haut, mais par rapport à mon expérience, tous les services informatiques gérés par des non informaticiens foirent quasi tout le temps, j'en ai jamais vu qui marchait. Est-ce qu'on va gérer une armée avec des non militaire (hors ministre de la défense)? Un service d'un hôpital par un non médecin? Une équipe de football est quasi tout le temps entrainé par un ancien footballeur. C'est pourtant con mais en informatique, c'est pas automatique loin de là .

J'ai lu des articles intéressants en anglais qui expliquaient que en somme le management devrait être au service des développeurs et non le contraire, puisque au final c'est eux qui font le boulot, et mieux ils sont traités et aidé et mieux ils bossent.
Le management de développeurs en informatique n'a rien à voir avec le management de soldats à l'armée. Dans un sens le développeur en informatique n'est pas juste seulement un genre de scientifique appliqué à l'informatique mais c'est aussi souvent un créatif, voir un artiste, qui doit donc être motivé, protégé, chéri et choyé

Je suis moi même manager et ma façon de faire est pas loin de ça, j'essaye juste de faire en sorte que tout roule et que les développeurs soient formées et motivés, et qu'ils puissent s'épanouir dans le meilleur environnement de travail possible, par exemple tu ne met pas un développeur dans un open space à coté d'un commercial qui hurle au téléphone toute la journée, et tu évites d'aller le déranger toutes les 5 minute pendant qu'il code.
Il doit y avoir un dialogue et un équilibre sain qui s'instaure, une équipe de développeurs n'est pas la pour répondre dans la minute aux lubies de n'importe quel commanditaire incompétent qui demande la lune pour demain, c'est en étant à l'écoute des équipes de développement que l'on peu comprendre ce qu'il est raisonnablement possible de faire, comment et dans quel délais.

Je dirai pas que les dév sont des artistes, faut pas déconner, je les vois comme simplement des experts style avocat ou médecin. Comme on prend un avocat pour résoudre certains problèmes divers et variés, le dév est là pour résoudre des problèmes liés à la circulation des informations. Les informations étant hyper stratégiques dans une organisation, choyer ses dévs pour garder les bons est comme tu le dis très important. Je pense pas que les Gafam ou autre netflix rechignent à payer une blinde leurs bons dév, comme une équipe de foot ne rechignerait pas à payer pleins pot les bons joueurs .

Malheureusement pour nous, on va entrer de plus en plus avec la concurrence des dév low-cost formés via bootcamp ou autre formation rapide. Bref, je plains le junior en 2021 si celui-ci n'a pas go dans les bonnes technos et les bonnes missions tôt.

Perso je veux passer un peu plus dans le management car je commence à avoir du mal à bien gérer pour la veille techno et aussi que ça m'intéresse un peu moins. Mais je pense que je managerais largement mieux un un informaticien que certains commerciaux qui sont là juste pour la comédie en faisant fi de comprendre ce que l'informaticien a à dire .

[foetus]

Admettons qu'il y a sans doute un problème de vocabulaire. Après ça ne me paraît pas délirant de vouloir réunir les User Stories dans un document

Je ne connais pas Scrum , mais il me semble qu'il y a bien 1 cahier des charges ... mais très très léger. @DuyBinh dit qui s'appelle "Vision Doc".

En gros, "eXtrem Programing" (XP) est 1 méthode agile trop extrême parce que c'est l'équipe de développeurs avec 1 représentant du client, qui s'autogère.
Lorsque je passe des entretiens d'embauche, il y a des mots qui te font passer pour 1 charlot auprès du recruteur ... alors qu'il ne connaît rien à l'informatique. Comme XP ("il travaille à l'arrache") et architecte ("il ne veut pas devenir manager")

Et donc, Scrum c'est l'autre extrême, parce que basé sur la gestion de projet et d'1 équipe. Cela te donne 1 cadre et tout de suite cela fait sérieux/ vendeur :

• il y a 1 cahier des charges très léger, c'est sérieux. Mais léger pour éviter l'effet tunnel.
• il y a des réunions toutes les semaines, peut-être tous les jours. C'est sérieux. Alors qu'avec XP c'est pareil.
• il y a des "users stories" et 1 P.O. qui permet de définir/ suivre/ valider son besoin. C'est sérieux. Alors qu'avec XP c'est + ou - pareil.
• il y a des "sprints" qui permettent de savoir ce que font les développeurs.. C'est sérieux. Alors qu'avec XP c'est pareil.
• ...

d'ailleurs avec XP on parle + de "refactoring", "test first", concevoir avec des tests, "pair programming", ... que, avec Scrum, de post-its, "backlog", "Scrum Master" qui prépare les réunions et fait des jeux, KPI, ...

[GreatDeveloperOnizuka]

Je ne connais pas Scrum , mais il me semble qu'il y a bien 1 cahier des charges ... mais très très léger. @DuyBinh dit qui s'appelle "Vision Doc".

En gros, "eXtrem Programing" (XP) est 1 méthode agile trop extrême parce que c'est l'équipe de développeurs avec 1 représentant du client, qui s'autogère.
Lorsque je passe des entretiens d'embauche, il y a des mots qui te font passer pour 1 charlot auprès du recruteur ... alors qu'il ne connaît rien à l'informatique. Comme XP ("il travaille à l'arrache") et architecte ("il ne veut pas devenir manager")

Et donc, Scrum c'est l'autre extrême, parce que basé sur la gestion de projet et d'1 équipe. Cela te donne 1 cadre et tout de suite cela fait sérieux/ vendeur :

• il y a 1 cahier des charges très léger, c'est sérieux. Mais léger pour éviter l'effet tunnel.
• il y a des réunions toutes les semaines, peut-être tous les jours. C'est sérieux. Alors qu'avec XP c'est pareil.
• il y a des "users stories" et 1 P.O. qui permet de définir/ suivre/ valider son besoin. C'est sérieux. Alors qu'avec XP c'est + ou - pareil.
• il y a des "sprints" qui permettent de savoir ce que font les développeurs.. C'est sérieux. Alors qu'avec XP c'est pareil.
• ...

d'ailleurs avec XP on parle + de "refactoring", "test first", concevoir avec des tests, "pair programming", ... que, avec Scrum, de post-its, "backlog", "Scrum Master" qui prépare les réunions et fait des jeux, KPI, ...

Sauf qu'XP ne permet pas le flicage comme pourrait l'être Scrum . Tu as le scrum master par exemple qui permet à des anciens chef de projet de se reconvertir . Il peut servir de flic pour le manager des fois (j'ai souvent vu ça). T'as aussi la planification en story points qui permet au manager de fliquer et d'avoir la fameuse estimation qu'on te demande tout le temps. Vu qu'on nous prend pour des ouvriers, ben faut nous fliquer tel des contremaitres. .

Sinon me semble pas qu'en XP, il n'y ait des sprint à la base. Le principe d'un dév itératif vient de RUP : https://fr.wikipedia.org/wiki/Proces...it%C3%A9rative

Après comme toujours on s'en "branle" plus ou moins de la méthodo (bien que je trouve qu'XP est la meilleure des méthodes dans la plupart des cas sincèrement). L'importance est de laisser faire le bon sens. Les managers qui viennent casser les couilles pour imposer des choix techniques alors qu'ils y comprennent rien. Est-ce que je remets les décisions de mon médecin en cause moi? Non. Est-ce que les directeurs d'hôpitaux vont venir faire chier les médecins sur comment ils gèrent leurs services?

Bref, tant qu'on prendra les dev pour de simples ouvriers, de bonnes méthodes seront détournées (Scrum sur le papier semble bonne et je pense qu'on pourrait bien l'adapter selon des situations). Bref, c'est dommage que les dév n'aient pas de couilles la plupart du temps, on devrait faire un lobbying style notaire, avocat, médecin tout ça. Avec un vrai ordre pour réussir à mettre la pression.

[jpouly]

Admettons qu'il y a sans doute un problème de vocabulaire. Après ça ne me paraît pas délirant de vouloir réunir les User Stories dans un document qui sera ensuite décliné? Qu'il s'appelle cahier des charges ou backlog je ne pense pas que ce soit un grand problème. Mais bon je ne connais pas le contexte.

Ce qu'il faut surtout, c'est formaliser le besoins et l'écrire. Voir le réécrire.

Sur un projet (en presta), le client nous avait fournis un cahier des charges écrit avec les p...

J'ai dis à mes collègues que je ne m’engageais pas là-dessus. Et j'ai réécrit le cahier des charges, malgré la réticence de ces derniers.

Bizarrement, une fois écrit, ils l'ont complété . Et on l'a présenté au client, qui avait bien compris qu'écrire ce genre de document, c'était pas son métier (par contre, son métier il le connaissait mieux que quiconque).

Comme quoi des fois, il faut brusquer un peu les choses, et surtout oublier ces méthodes à la c... pour faire du bon boulot.

Elles ne sont là que pour faire payer au client ses propres incohérences, tout en assumant pas les siennes.

[Madmac]

Citation Envoyé par Madmac
Enfin il y a les projets dirigés par une femme. Elles adorent faire du micro-management alors qu'elles ne connaissent rien de l'informatique.(.../...)

Wow...
J'espère que tu es juste un troll de génie avec un second degré du tonnerre parce que sinon tu as de sacrés problèmes psychologiques...

Malheureusement, je ne trolle pas! Dans les petites et moyennes entreprises, il y a rarement du personnel avec une formation en informatique. En général, j'ai affaire à des gens qui ont une formation en administration. Avec les hommes, je leur explique qu'ils doivent me d'écrire en détail ce que le site doit pouvoir faire avant de pouvoir commencer. Et que c'est la meilleure façon de procéder. Après tout on fait bien des plans avant de lancer dans la construction d'un édifice. En général, ils comprennent.

Mais les femmes acceptent mal de payer pour cette étape et s'attendent à ce que je produise du code dans l'heure qui suit. Si elles sont trop entêtées, je leur dis d'aller chercher ailleurs et je quitte. J'ai plus de 40 ans d'expérience en programmation. Et je sais ce que je vaux. Et je sais reconnaître les clients à emmerdes. Et j'ai eu à travailler avec des dirigeants incompétents qui tournent les programmeurs en bourriques. Et à cause de cela, et par dépit, j'ai développé une stratégie pour produire rapidement sans trop me faire chier. Ce que l'expérience m'a appris est la création d'un programme information et très proche de l'architecture. Et c'est pour cette raison que j'impose un cahier de charge détaillé et un prototype. Je n'aime pas qu'un projet s'étende en longueur, car j'ai tendance à m'ennuyer quand c’est le cas. Donc le client en a pour son argent avec moi. Alors cette raison, je ne suis pas excessivement flexible. je ne fais plus de full stack. Et généralement, je confie le dossier CSS à un graphiste que j'ai entraîné,

Le féminisme a créé des monstres qui surestiment leurs compétences et leurs valeurs réelles. Et qui considère que les hommes doivent être dirigés. Et si tu en doutes, tu demanderas l'opinion de Bill Gates ...

Pour que tout le monde y trouve son compte et que les coûts restent raisonnables, le client doit connaître son rôle. Un chirurgien ne prend pas de directive du client sur les moyens qu'il doit prendre pour faire un pontage cardiaque. Eh bien moi non plus. Et c'est sans doute une des raisons pour laquelle je fais encore de la programmation. À moins de vouloir développer des problèmes d'hypertension ou des ulcères d'estomac, n'acceptez pas d'être dirigé pas des gens incompétents.

[Madmac]

Ce qui se rapproche du cahier des charges classique serait le Vision Doc : https://en.wikipedia.org/wiki/Vision_document
.

Cela ressemble passablement ce que je fais. En fait, il est plus détaillé et je vais commencé à explorer ce modèle.

[Gunny]

Je l'ai déjà dit plus haut, mais par rapport à mon expérience, tous les services informatiques gérés par des non informaticiens foirent quasi tout le temps, j'en ai jamais vu qui marchait. Est-ce qu'on va gérer une armée avec des non militaire (hors ministre de la défense)? Un service d'un hôpital par un non médecin? Une équipe de football est quasi tout le temps entrainé par un ancien footballeur. C'est pourtant con mais en informatique, c'est pas automatique loin de là

Ah oui mais tout à fait, je ne dis pas que le management ne doit rien connaître au dev, on ne peut pas gérer quelque chose qu'on ne connaît pas du tout. Ce que je dénonce c'est de pousser systématiquement les développeurs vers des positions de management. Par ailleurs cette connaissance peut s'acquérir autrement que par la case dev (formation par exemple). Après cela dépend aussi de la position de management : un tech lead se doit d'être un développeur sinon ça n'a pas de sens, alors qu'un chef de projet peut très bien être compétent sans jamais avoir travaillé comme dev.
On touche aussi à un autre point qui est lié à la surabondance des positions de management, c'est le micro-management. Ironiquement, c'est une des choses qu'Agile et Scrum empêchent si c'est implémenté correctement.

[walfrat]

Avec les hommes, je leur explique qu'ils doivent me d'écrire en détail ce que le site doit pouvoir faire avant de pouvoir commencer. Et que c'est la meilleure façon de procéder. Après tout on fait bien des plans avant de lancer dans la construction d'un édifice. En général, ils comprennent

Et bien t'as de la chance, parce que je pense que "en général" ils ne comprennent pas.

Comme tu dis tu avais de l'expérience a détecter les emmerdes, peut-être avais-tu plus d'expérience à détecter les emmerdeur que les emmerdeuses ?

J'ai déjà été micromanagé, et ce n'était pas une femme, et pourtant j'ai déjà aussi eu des femmes en manageurs/chefs de projet.

[Madmac]

Et bien t'as de la chance, parce que je pense que "en général" ils ne comprennent pas.

C'est pour une des raisons pour le prototype est nécessaire. Cela rend les choses beaucoup moins abstraites. Et cela permet d'identifier les fonctionnalités qui manquent au projet.

Comme tu dis tu avais de l'expérience a détecter les emmerdes, peut-être avais-tu plus d'expérience à détecter les emmerdeur que les emmerdeuses ? .

Le type qui a une fixation sur une nouvelle technologie et qui ne comprend pas que le truc n'est pas prêt pour la production. Ou plus couramment présentement, l'ex-vendeur de balayeuse qui , s'est recyclé en vendeur de logiciel. Il est incapable de vous donnez des directives claires et vous offre un salaire de misère, car il n'est q'un intermédiaire entre toi et le véritable client. Le type qui veut te payer avec des participations dans son entreprise.

J'ai déjà été micromanagé, et ce n'était pas une femme, et pourtant j'ai déjà aussi eu des femmes en manageurs/chefs de projet.

Je ne dis pas qui est impossible de trouver des femmes qui vont gérer efficacement un projet. Mais en général, elles consacrent beaucoup trop de temps sur l'apparence des formulaires en début de projet. Et forcément cela a un impact sur la facturation et conséquemment sur la relation d'affaire. Mais la grosse différence est que les femmes ont un problème d'égo que l'on rencontre pas chez les hommes.

Contrairement à ce que l'on tente de nous faire croire, hommes et femmes ne sont pas identiques. Ils ne mesurent pas la valeur des gens selon les mêmes critères. Pour une femme, l'apparence, le salaire et les avoir sont des critères importants. Pour un homme, le salaire et les avoir ne sont pas primordiaux. Ce qui fait qu'un homme va considérer une jolie administratrice sur le même pied d'égalité qu'une jolie serveuse. Et une femme moche va être traitée comme une femme moche, peut importe son salaire annuel. Il n'y a qu'à voir les questions que les hommes posent quand on annonce que l'on vient de se faire une nouvelle petite amie. Les questions sur les seins, les jambes, la hauteur (l'apparence en général) et l'age vont arriver bien avant les questions sur son salaire. Généralement quand un homme s'intéresse à son métier est surtout pour connaître ses intérêts. Dans le passé, j'ai eu quelques hommes qui m'ont fait des avances mais c'étaient très rare. Et en général, ils ne tentent pas de jouer aux "marieuses". Alors qu'avec des femmes, c'était un facteur qui se présentait trop souvent à mon goût. Chez les cadres féminins dans la trentaine ont peut presqu'entendre leur horloge biologique qui fait tic-toc...

Le problème est que les femmes se mesurent de la même façon qu'elles utilisent pour mesurer un homme. Ce qui fait qu'en pratique, que beaucoup de femmes qui font de bons salaires, mais qui sont physiquement des "6" sur une échelle de 10, ont beaucoup à accepter que l'on ne les traite pas comme des princesses. Et que leur "charme" n'ont aucun impact sur la facture. Je le répète: Le féminisme a engendré des monstres. Il y a beaucoup de femme qui sont dans des secteurs pour laquelle elles ont peu d'intérêt. Mais comme elles étaient sous-représentées dans ces secteurs, alors le système les a encouragés dans ces secteurs.

Là où cela devient vraiment dramatique est que la différence entre une personne très compétente et parmi les meilleurs se situe uniquement dans la passion ...

[kain_tn]

Le féminisme a créé des monstres qui surestiment leurs compétences et leurs valeurs réelles. Et qui considère que les hommes doivent être dirigés. Et si tu en doutes, tu demanderas l'opinion de Bill Gates ...

Je pense que le terme que tu recherches est "misandrie" et non "féminisme". Et pour ce qui est de Bill Gates, je l'entends déjà bien assez s'exprimer sur tous les sujets en ce moment: si lui et ses petits copains multimilliardaires de la tech pouvaient se taire 5 minutes, ça me ferait du bien

Pour que tout le monde y trouve son compte et que les coûts restent raisonnables, le client doit connaître son rôle. Un chirurgien ne prend pas de directive du client sur les moyens qu'il doit prendre pour faire un pontage cardiaque. Eh bien moi non plus. Et c'est sans doute une des raisons pour laquelle je fais encore de la programmation. À moins de vouloir développer des problèmes d'hypertension ou des ulcères d'estomac, n'acceptez pas d'être dirigé pas des gens incompétents.

Tout à fait d'accord. Et je ne pense pas que l'incompétence soit "genrée".

Mais la grosse différence est que les femmes ont un problème d'égo que l'on rencontre pas chez les hommes.

C'est amusant car mon expérience du monde du travail m'a montré que ce sont souvent les hommes qui ont des problèmes d'égo... Moins ils étaient compétents, moins ils acceptaient d'avoir tort. Les rares femmes que j'ai rencontrées en IT étaient en général plutôt compétentes, sinon très. Et bien souvent elles manquaient de confiance en elles alors qu'elles auraient pu se le permettre au vu du niveau de médiocrité ambiante...

Je vais donc émettre l'hypothèse que l'égo croit avec le niveau d'incompétence d'une personne - peut-être une réaction défensive face à la peur d'être démasqué(e) en tant qu'imposteur?

Et une femme moche va être traitée comme une femme moche, peut importe son salaire annuel. Il n'y a qu'à voir les questions que les hommes posent quand on annonce que l'on vient de se faire une nouvelle petite amie. Les questions sur les seins, les jambes, la hauteur (l'apparence en général) et l'age vont arriver bien avant les questions sur son salaire.

Wow wow wow! Encore un bon piège glissant sur lequel il est facile de nourrir des trolls! Je ne vais pas m'aventurer sur ce terrain là!

Chez les cadres féminins dans la trentaine ont peut presqu'entendre leur horloge biologique qui fait tic-toc...

Le problème est que les femmes se mesurent de la même façon qu'elles utilisent pour mesurer un homme. Ce qui fait qu'en pratique, que beaucoup de femmes qui font de bons salaires, mais qui sont physiquement des "6" sur une échelle de 10, ont beaucoup à accepter que l'on ne les traite pas comme des princesses. Et que leur "charme" n'ont aucun impact sur la facture. Je le répète: Le féminisme a engendré des monstres.

J'ai quand même l'impression que tu décris une sorte de niche sociétale, et peut-être même une différence culturelle ici. Tu parles de cadres féminins trentenaires avec un bon salaire au Canada: c'est plutôt spécifique.
Et la notion de "6" (peu importe le nombre, on dira par exemple "he/she's a perfect 10" dans les films/séries US) est quelque chose de très courant en Amérique du Nord, mais moins je pense de mon côté de l'Atlantique, même si le jugement sur les apparences (souvent physiques) est bien présent ici aussi.

Il y a beaucoup de femme qui sont dans des secteurs pour laquelle elles ont peu d'intérêt. Mais comme elles étaient sous-représentées dans ces secteurs, alors le système les a encouragés dans ces secteurs.

Là on touche à un vrai problème: la discrimination "positive"". Vouloir absolument que tous les cœurs de métier soient représentés par autant d'hommes que de femmes (également étendu aux histoires de minorités aux US), ce qui est une aberration mais qui sert à dévier un sujet bien plus important: les inégalités (salaires, congés, statuts, etc.) entre les hommes et les femmes pour des positions équivalentes, et un accès équitable à ces mêmes positions, quelque soit le genre ou le groupe ethnique de la personne.

Là où cela devient vraiment dramatique est que la différence entre une personne très compétente et parmi les meilleurs se situe uniquement dans la passion ...

Là, je te rejoins, d'où le message que j'ai adressé à l'auteur de ce fil de discussion: ne pas persévérer si ce n'est pas sa passion à la base.

[GreatDeveloperOnizuka]

C'est pour une des raisons pour le prototype est nécessaire. Cela rend les choses beaucoup moins abstraites. Et cela permet d'identifier les fonctionnalités qui manquent au projet.



Le type qui a une fixation sur une nouvelle technologie et qui ne comprend pas que le truc n'est pas prêt pour la production. Ou plus couramment présentement, l'ex-vendeur de balayeuse qui , s'est recyclé en vendeur de logiciel. Il est incapable de vous donnez des directives claires et vous offre un salaire de misère, car il n'est q'un intermédiaire entre toi et le véritable client. Le type qui veut te payer avec des participations dans son entreprise.



Je ne dis pas qui est impossible de trouver des femmes qui vont gérer efficacement un projet. Mais en général, elles consacrent beaucoup trop de temps sur l'apparence des formulaires en début de projet. Et forcément cela a un impact sur la facturation et conséquemment sur la relation d'affaire. Mais la grosse différence est que les femmes ont un problème d'égo que l'on rencontre pas chez les hommes.

Contrairement à ce que l'on tente de nous faire croire, hommes et femmes ne sont pas identiques. Ils ne mesurent pas la valeur des gens selon les mêmes critères. Pour une femme, l'apparence, le salaire et les avoir sont des critères importants. Pour un homme, le salaire et les avoir ne sont pas primordiaux. Ce qui fait qu'un homme va considérer une jolie administratrice sur le même pied d'égalité qu'une jolie serveuse. Et une femme moche va être traitée comme une femme moche, peut importe son salaire annuel. Il n'y a qu'à voir les questions que les hommes posent quand on annonce que l'on vient de se faire une nouvelle petite amie. Les questions sur les seins, les jambes, la hauteur (l'apparence en général) et l'age vont arriver bien avant les questions sur son salaire. Généralement quand un homme s'intéresse à son métier est surtout pour connaître ses intérêts. Dans le passé, j'ai eu quelques hommes qui m'ont fait des avances mais c'étaient très rare. Et en général, ils ne tentent pas de jouer aux "marieuses". Alors qu'avec des femmes, c'était un facteur qui se présentait trop souvent à mon goût. Chez les cadres féminins dans la trentaine ont peut presqu'entendre leur horloge biologique qui fait tic-toc...

Le problème est que les femmes se mesurent de la même façon qu'elles utilisent pour mesurer un homme. Ce qui fait qu'en pratique, que beaucoup de femmes qui font de bons salaires, mais qui sont physiquement des "6" sur une échelle de 10, ont beaucoup à accepter que l'on ne les traite pas comme des princesses. Et que leur "charme" n'ont aucun impact sur la facture. Je le répète: Le féminisme a engendré des monstres. Il y a beaucoup de femme qui sont dans des secteurs pour laquelle elles ont peu d'intérêt. Mais comme elles étaient sous-représentées dans ces secteurs, alors le système les a encouragés dans ces secteurs.

Là où cela devient vraiment dramatique est que la différence entre une personne très compétente et parmi les meilleurs se situe uniquement dans la passion ...

Heu tu serais pas un peu parano? Les femmes et les hommes sont pas identiques mais l'incompétence homme ou femme ça change quoi? Dans ma boite c'est rempli d'incompétents peu importe le sexe. D'ailleurs l'ancienne DG de ma boite était la personne la plus compétente je pense. Et pour le discours des femmes veulent ci veulent ça, tu veux coucher avec ta collègue ou quoi? Qu'est-ce que t'en as à foutre que les femmes préfèrent les Brad Pitt riches ou autre? T'es là pour bosser pas pour faire pote non?

[sergio_is_back]

Le problème de l'informatique en France, à 90%, c'est l'incompétence des managers.

Comment dire ça... Il n'y a pas toujours que les managers qui sont incompétents... C'est parfois la chaîne complète qui pêche, il m'est arrivé de reprendre le projet d'un client abandonné en rase campagne par une équipe de zozos, et je peux dire après avoir vu le code produit et le résultat qu'ils étaient tous à coté du sujet, du consultant au managers, et que les développeurs ne valaient pas tripette, la moindre fonction, procédure, soit boguée soit à refaire totalement car pas dans le sujet...

Perso, je pense que beaucoup d'équipes de développement ont trop confiance : non seulement dans la méthode, mais aussi dans leurs capacités de développement tout court.

Des bons développeurs, des équipes de dév bien gérées, j'en connais, c'est avant tout des personnes qui sont capables de mener un projet à son terme (ce qui arrive de moins en moins souvent, faut le dire !) même s'il y a un peu de dérive sur les délais de livraison estimés (souvent donné au client par le commercial pour faire plaisir). Cette capacité n'est que rarement en rapport avec les méthodes de développement utilisées, faut le dire aussi. Une bonne équipe doit être capable d'adapter son approche au client et surtout au projet, certaines phases peuvent parfois être squeezées au profits d'autres... On oublie toujours que le développement c'est pas que pisser que de la ligne de code (sinon vu le nombre de lignes que j'ai écrit en plus de 30 ans, je serai millionnaire) c'est aussi comprendre la finalité, le besoin du client...

A un problème donné, en informatique, il y a 50 façons de le résoudre (vu le nombre de langages, de frameworks, de technos), mais certaines façons seront plus ou moins bonnes ou quasi inapplicables dans certains contextes... Il faut toujours avoir ceci en tête quand on se positionne sur un projet...

Et puis, il faut le dire aussi : certains, managers comme développeurs, n'ont surtout pas envie de sortir de leur "zone de confort", on reste dans ce que l'on connais même si ça convient pas pile poil, on s'arrangera pour que ça plaise au client après coup !

[GreatDeveloperOnizuka]

Comment dire ça... Il n'y a pas toujours que les managers qui sont incompétents... C'est parfois la chaîne complète qui pêche, il m'est arrivé de reprendre le projet d'un client abandonné en rase campagne par une équipe de zozos, et je peux dire après avoir vu le code produit et le résultat qu'ils étaient tous à coté du sujet, du consultant au managers, et que les développeurs ne valaient pas tripette, la moindre fonction, procédure, soit boguée soit à refaire totalement car pas dans le sujet...

Perso, je pense que beaucoup d'équipes de développement ont trop confiance : non seulement dans la méthode, mais aussi dans leurs capacités de développement tout court.

Des bons développeurs, des équipes de dév bien gérées, j'en connais, c'est avant tout des personnes qui sont capables de mener un projet à son terme (ce qui arrive de moins en moins souvent, faut le dire !) même s'il y a un peu de dérive sur les délais de livraison estimés (souvent donné au client par le commercial pour faire plaisir). Cette capacité n'est que rarement en rapport avec les méthodes de développement utilisées, faut le dire aussi. Une bonne équipe doit être capable d'adapter son approche au client et surtout au projet, certaines phases peuvent parfois être squeezées au profits d'autres... On oublie toujours que le développement c'est pas que pisser que de la ligne de code (sinon vu le nombre de lignes que j'ai écrit en plus de 30 ans, je serai millionnaire) c'est aussi comprendre la finalité, le besoin du client...

A un problème donné, en informatique, il y a 50 façons de le résoudre (vu le nombre de langages, de frameworks, de technos), mais certaines façons seront plus ou moins bonnes ou quasi inapplicables dans certains contextes... Il faut toujours avoir ceci en tête quand on se positionne sur un projet...

Et puis, il faut le dire aussi : certains, managers comme développeurs, n'ont surtout pas envie de sortir de leur "zone de confort", on reste dans ce que l'on connais même si ça convient pas pile poil, on s'arrangera pour que ça plaise au client après coup !

C'est ça, bcp de personnes anti changement: utilisateurs comme développeurs. Car changer demande des efforts et bcp de personnes ont la flemme si l'ancien système marchait même si full bug.