Aller au contenu

La France des pénuries


Bézoukhov

Messages recommandés

19 minutes ago, ttoinou said:

Déjà répondre à des messages et savoir bien écrire tu te met au dessus du lot

 

Pas forcément. En tant que BA, j'arrive à fonctionner aussi bien avec des devs talentueux mais "bordéliques" (je fais alors du management) que avec des devs très fiables mais besogneux. Les devs talentueux et très pros, ca peut fonctionner ou clasher suivant les personnalités et les organisations. Les tocards pas fiables, j'arrive le plus souvent à en tirer le meilleur parti (aka ne pas avoir de projet commun avec eux).

  • Haha 1
Lien vers le commentaire
il y a 2 minutes, Lameador a dit :

En tant que BA, j'arrive à fonctionner aussi bien avec des devs talentueux mais "bordéliques" (je fais alors du management) que avec des devs très fiables mais besogneux.

C'est une vraie qualité, pour un business analyst, ça.

Lien vers le commentaire
il y a 17 minutes, Lameador a dit :

Pas forcément. En tant que BA, j'arrive à fonctionner aussi bien avec des devs talentueux mais "bordéliques" (je fais alors du management)

Tu kiffes renvoyer les même messages jusqu'à qu'ils répondent ? Essayer de déchiffrer ce qu'ils disent parce que c'est toujours ambiguë et qu'ils ne se mettent jamais à ta place ? Pour moi quelqu'un qui arrive à nager dans des dizaines de milliers de lignes de code mais qui est pas capable d'aligner trois phrases qui font sens et répondre dans l'heure, y'a comme une contradiction

Lien vers le commentaire
il y a 35 minutes, Mathieu_D a dit :

Quand tu es bien organisé tu n'as pas besoin de bons, les vaguement passables font le job.

C'est à dire bien organisé ? Plus tu t'organises, plus il faut expliquer le process d'organisation. Si déjà la personne a la flemme de répondre à tes messages c'est mal parti pour apprendre des outils "complexes"

Lien vers le commentaire
37 minutes ago, ttoinou said:

Tu kiffes renvoyer les même messages jusqu'à qu'ils répondent ? Essayer de déchiffrer ce qu'ils disent parce que c'est toujours ambiguë et qu'ils ne se mettent jamais à ta place ?

Je kiffe être payé et avoir un cheval de course, même capricieux

Je gère aussi très bien les promenades en calèche avec Florette.

 

37 minutes ago, ttoinou said:

Pour moi quelqu'un qui arrive à nager dans des dizaines de milliers de lignes de code mais qui est pas capable d'aligner trois phrases qui font sens et répondre dans l'heure, y'a comme une contradiction

 

Répondre dans l'heure, c'est assez chiant. Et supporter des demandes d'utilisateurs lunatiques qui t'expliquent benoitement le contraire de ce qu'ils avaient demandé la veille, c'est le genre de truc qui peut faire perdre politesse et sens des conventions sociales à la plupart des devs qui prennent leur job à coeur.

 

 

P.S :  @PABerryersi ma video te fait rire, c'est que tu as peu fait de gestion de projets IT dans une grosse entreprise

  • Haha 1
Lien vers le commentaire
il y a 37 minutes, Lameador a dit :

Je kiffe être payé et avoir un cheval de course, même capricieux

 

Ah oui d'accord. C'est vrai que du coup t'es du bon côté de l'équation t'en profites de leur incompétence :D . Moi je les paye mes ingés et chaque euro qui sort de ma poche pour quelqu'un qui peut pas prendre 30 secondes pour lire mon message me brise les fesses.

 

C'est quoi la difficulté de répondre dans l'heure ?

Lien vers le commentaire
1 hour ago, Lameador said:

 

Sujet passionnant et controversé. A la louche, mon avis est que même avec une très bonne organisation je dirais qu'il faut au moins

 

- 15% de bons (ou mieux)

- 40% de corrects et dociles (ou mieux)

- 80% de médiocres (ou mieux)

- 95% de non-nuisibles (ou mieux)

 

Et que sans les 15% de bons, tu vas faire du surplace stérile pendant que la concurrence progressera.

Si le bon c'est l'architecte on peut passer sous les 15% :-)

 

 

54 minutes ago, ttoinou said:

C'est à dire bien organisé ? Plus tu t'organises, plus il faut expliquer le process d'organisation. Si déjà la personne a la flemme de répondre à tes messages c'est mal parti pour apprendre des outils "complexes"

"Bien organiser" ça revient peu ou prou à "bien décomposer les tâches".

Par exemple un junior qui part d'une page blanche fera certainement un truc inutilisable en prod', même s'il est bon. Si le chemin est bien tracé pour bien s'insérer dans l'existant ça se passera bien, même sans talent, même si l'apport incremental est moins important que si un virtuose avait fait le truc.

 

Après les utilisateurs ne sont pas sensés non plus écrire aux dev' directement. Ça se passe nettement mieux s'il y a une couche amoa ou un PO pour faire le filtre.

Mais sinon oui, je demande aussi de toujours au moins accuser réception d'un message.

Lien vers le commentaire
il y a 11 minutes, Mathieu_D a dit :

"Bien organiser" ça revient peu ou prou à "bien décomposer les tâches".

Ca d'accord, mais je te parle d'ingénieurs qui 1) listent pas certains messages 2) lisent certains messages mais oublient (manque d'effort) 3) ne comprennent pas qu'ils ont fait la simple connerie de pas lire ou pas relire (donc aucune capacité de se remettre en question et d'amélioration dans le futur). Je parle de soft skills qui sont plus simples à obtenir que programmer hein. Juste des flemmards

Lien vers le commentaire
il y a 35 minutes, Mathieu_D a dit :

Après les utilisateurs ne sont pas sensés non plus écrire aux dev' directement.

:lol: :icon_mdr: :icon_jump:

 

il y a 31 minutes, Sloonz a dit :

This.

 

il y a 26 minutes, ttoinou a dit :

Justement je parle d'un environnement remote et répondre à une discussion en ligne, quand tu le veux. C'est pas une interruption.

Si le délai pour répondre est inférieur à une demi-journée, c'est probablement une interruption.

  • Yea 1
Lien vers le commentaire

Mais non. Les développeurs sont pas toujours en train de faire du calcul lourd où il faut être deep focus, y'a toujours des petits trucs à faire, ca fait du bien de s'aérer l'esprit (si le développeur checke son smartphone et facebook ben il l'a fait lui même ses interruptions) et faut savoir prendre des notes quand on se plonge dans un problème pour pouvoir revenir dessus sur plusieurs jours de toute façon.

 

En plus en ne répondant pas aux messages, il y a un risque de travailler sur la mauvaise chose

  • Yea 1
Lien vers le commentaire

Là je suis avec un développeur freelance jordanien qui fait plein de fautes en anglais, je lui explique toutes ses fautes et il continue de faire les même encore et encore. Et la discussion est comme cela :

 

- pourrais tu vérifier mon travail ?

- Moi : oui, il y a problème 1, problème 2, problème 3, problème 4

- tu peux me donner les identifiants X ?

- ok les voici

- le boulot est fini, je fais quoi ?

- Moi : réponds à mes messages

- D'accord, à l'avenir je ferais de mon mieux pour répondre à tes questions

- Moi Tu n'as pas répondu à mes messages

- C'est vrai, j'ai pas été friendly

- Moi : j'parle pas de ca

- C'est quels messages ?

- Moi Relis

- Alors on continue le  travail ?

- Moi Non, réponds à mes messages

- Je ne les vois pas

 

 

Non mais lol, il suffit de remonter les messages. C'est juste de la grosse flemmardise de couillon, c'est tout, y'a aucune excuse. Tu scrolles, tu lis, tu te met à la place de l'autre et tu te demandes "est ce que mon interlocuteur a eu une réaction à ce message", tu relis, et quand c'est pas bon tu réponds. Point barre

Lien vers le commentaire
il y a une heure, ttoinou a dit :

Les développeurs sont pas toujours en train de faire du calcul lourd où il faut être deep focus

Ça peut arriver, et si c'est le cas tu ne peux pas leur reprocher de ne pas avoir répondu à tes messages. Évidemment, c'est plus souvent le cas des experts techniques que des juniors, parce que la nature des problèmes à résoudre est différente.

 

il y a 41 minutes, Mathieu_D a dit :

Les dba non plus ne sont pas franchement fans des demandes en direct des utilisateurs quand on y pense.

 

"Hé c'est lent là tu peux faire quelque chose ?"

:wub:

 

Hélas les utilisateurs ne sont plus assez naïfs pour croire aveuglément un "Tu sais que quand tu me téléphones / m'envoyes un message, tu ralentis d'autant la base de données, arrête ça tout de suite". :lol:

  • Haha 1
Lien vers le commentaire
il y a 21 minutes, Rincevent a dit :

Ça peut arriver, et si c'est le cas tu ne peux pas leur reprocher de ne pas avoir répondu à tes messages. Évidemment, c'est plus souvent le cas des experts techniques que des juniors, parce que la nature des problèmes à résoudre est différente.

On est d'accord. Je parle d'un problème récurrent, un truc vraiment basique. Si mon dev était en train de coder un truc de ouf j'pense j'ferais l'impasse sur le message dans les trois heures qui suivent.

 

Sinon c'est cool de parler aux utilisateurs, tu peux comprendre mieux leur besoin directement sans intermédiaire.

 

La religion de la division du travail à l'époque des économies du service c'est une fiction, j'sais pas pourquoi les libéraux y croient autant, ca doit être un reste des économies industrielles

  • Yea 1
Lien vers le commentaire
il y a 4 minutes, ttoinou a dit :

Sinon c'est cool de parler aux utilisateurs, tu peux comprendre mieux leur besoin directement sans intermédiaire.

Ça suppose que eux-mêmes le comprennent. ;)

Lien vers le commentaire

Mmmh d'expérience ce n'est pas pour rien qu'on a inventé les PO ou les MOA pour être entre la technique et le business...

 

(Mais oui c'est utile de faire un passage chez les utilisateurs finaux un coup de temps en temps. Là où je suis en ce moment ils envoient tout le monde en magasin faire un genre de stage.)

Lien vers le commentaire
il y a une heure, Mathieu_D a dit :

Mmmh d'expérience ce n'est pas pour rien qu'on a inventé les PO ou les MOA pour être entre la technique et le business...

On demande qu'est ce qu'un bon dev et je dis que les soft skills c'est important et pas compliqué à obtenir mais trop souvent négligé. Après mes problèmes peuvent aussi venir de cultures de travail différentes, jlis un bouquin dessus pour éclaircir

Lien vers le commentaire
8 hours ago, ttoinou said:

La religion de la division du travail à l'époque des économies du service c'est une fiction

Si tu sais me recruter dans le trimestre 30 personnes qui savent coder, savent opérer un service, savent architecturer, savent designer, savent rendre un service sécurisé, savent rendre un service ergonomique, savent prioriser les demandes utilisateurs, savent planifier, savent négocier, connaissent le droit, connaissent le métier cible (dont il faut souvent 5 ans à plein temps pour commencer à comprendre les enjeux), je les fais remplacer mes 70 personnes.

  • Yea 2
Lien vers le commentaire
9 hours ago, ttoinou said:

Là je suis avec un développeur freelance jordanien qui fait plein de fautes en anglais, je lui explique toutes ses fautes et il continue de faire les même encore et encore. Et la discussion est comme cela :

 

- pourrais tu vérifier mon travail ?

- Moi : oui, il y a problème 1, problème 2, problème 3, problème 4

- tu peux me donner les identifiants X ?

- ok les voici

- le boulot est fini, je fais quoi ?

- Moi : réponds à mes messages

 

Ben je ne vois pas de questions dans tes messages. 😛

 

 

 

 

Lien vers le commentaire
il y a 50 minutes, cedric.org a dit :

Si tu sais me recruter dans le trimestre 30 personnes qui savent coder, savent opérer un service, savent architecturer, savent designer, savent rendre un service sécurisé, savent rendre un service ergonomique, savent prioriser les demandes utilisateurs, savent planifier, savent négocier, connaissent le droit, connaissent le métier cible (dont il faut souvent 5 ans à plein temps pour commencer à comprendre les enjeux), je les fais remplacer mes 70 personnes.

Par religion je dis qu'on va trop loin dans beaucoup de cas, il faut savoir rester généraliste ET avoir une niche et des compétences clées.

 

Et sinon pour ton exemple je fais tout cela.

 

A l'exception de sécuriser un service (mais jsuis capable de comprendre des trucs basiques quand meme et voir quand ya une faille) et le droit (mais je  fais mes propres recherches avant de prendre un avocat)

Lien vers le commentaire

Mais du coup est-ce que tu dois répondre à la réponse pour prouver que tu l'as lue ? Et est-ce que l'autre est supposé répondre à ta réponse à sa réponse et ainsi de suite ? Parce que sinon comment peut-on être sûr que toutes les réponses ont été lues ? 🤔

Lien vers le commentaire
4 minutes ago, Lancelot said:

Mais du coup est-ce que tu dois répondre à la réponse pour prouver que tu l'as lue ? Et est-ce que l'autre est supposé répondre à ta réponse à sa réponse et ainsi de suite ? Parce que sinon comment peut-on être sûr que toutes les réponses ont été lues ? 🤔

Il suffira d'implémenter le protocole TCP à chaque message. Il n'existe pas plus efficace.

 

  • Yea 1
  • Haha 1
Lien vers le commentaire
3 hours ago, ttoinou said:

Ahah ouais yen avait des cachées mais ne pas réagir à un message est une preuve que tu l'as pas lu en communication async, remote, low context, écrit

Je ne suis pas à l'aise sur le fait qu'un message sur Slack ait une valeur de spec'.

Lien vers le commentaire

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
×
×
  • Créer...