Discussion :

[sshpcl2]

ça m'étonne que personne n'est parlé de l'espèce parasitaire propre aux informaticiens ... j'ai nommé le commercial .

entendu dans un entretien d'embauche

le boulot lvl 3 unix

le client --> avez vous déjà travaillé sur blabla
la ressource --> heu ca je sais pas faire
le commercial --> moui mais vous savez dans nos métiers c'est 80 % de relationnel et 20 % de technique la technique ça s'apprend.

pour le commercial lire et assimiler un livre 500 page n'est qu'un détails qui tiens à quelques heures ..

voila et le grandiose le fabuleux ... special user

tout à l'heure ça marchais !!!

[Louis Griffont]

ça m'étonne que personne n'est parlé de l'espèce parasitaire propre aux informaticiens ... j'ai nommé le commercial .

entendu dans un entretien d'embauche

le boulot lvl 3 unix

le client --> avez vous déjà travaillé sur blabla
la ressource --> heu ca je sais pas faire
le commercial --> moui mais vous savez dans nos métiers c'est 80 % de relationnel et 20 % de technique la technique ça s'apprend.

pour le commercial lire et assimiler un livre 500 page n'est qu'un détails qui tiens à quelques heures ..

voila et le grandiose le fabuleux ... special user

tout à l'heure ça marchais !!!

J'ai eu un patron qui un jour, devant un client, qui voulait son projet en 30j alors que je tablais sur 70/80 , sort bah s'il faut embaucher 3/4 développeurs c'est pas un problème. Des "pisseurs de lignes", c'est pas ce qui manque !
C'est bô la considération !

[Barsy]

En parlant de commercial, c'est souvent :

l'ingénieur : il faut 50 jours pour le projet
le commercial : mais le client ne peut en acheter que 30
l'ingénieur : en supprimant le dernier module qui franchement ne sert pas à grand chose, je peux le faire en 30.
le commercial : parfait

(un peu plus tard...)

le commercial : finalement, je lui ai vendu 30 et comme il voulait le dernier module, je lui ai mis aussi... Et puis comme le client était un peu frileux, on est en mode forfait (forcément, le client est pas con, il sait qu'il y aura beaucoup de dépassement).

Dans la plupart des boîtes, les commerciaux reçoivent leur prime dès qu'ils vendent un projet, ils se fiche ensuite de savoir si le projet sera rentable ou non. Résultat, ils acceptent à peu près toutes les demandes du client en sachant que ça ne leur retombera jamais dessus.

Pour un client, j'ai eu à développer un logiciel pour calculer la rentabilité des projets. Dans cette entreprise, ils en avaient marre des méthodes de leur commerciaux qui vendaient exprès à perte pour obtenir plus de projets et toucher des primes. Avec mon logiciel, les commerciaux sont maintenant obligés de vendre des projets qui rapportent pour toucher leurs primes. Quand est-ce que ce mode de fonctionnement sera appliqué partout ?

[Louis Griffont]

Un commercial a coulé ma première boite comme ça !

Pour un client, j'ai eu à développer un logiciel pour calculer la rentabilité des projets. Dans cette entreprise, ils en avaient marre des méthodes de leur commerciaux qui vendaient exprès à perte pour obtenir plus de projets et toucher des primes. Avec mon logiciel, les commerciaux sont maintenant obligés de vendre des projets qui rapportent pour toucher leurs primes. Quand est-ce que ce mode de fonctionnement sera appliqué partout ?

Dans un monde parfait ? Donc... Jamais !

[biboo_]

Dans une vie antérieure:

Coup de fil à 03:00 du matin du contremaître, responsable du redémarrage éventuel de l'IBM 4331, sur lequel tournent les applications de suivi de fabrication:

"J'ai redémarré l'ordinateur suite à une coupure et j'ai un message en anglais..."

"Oui ? Lequel ?"

"eh... data base no... euh... avélable"

"Database not available ?... OK... J'arrive !"... Après un déplacement de 30 kms en pleine nuit, j'arrive devant la console et lis:

"Database Now Available !"

Arggggggggggggg !!!!!!

Comme quoi l'accent peut tout faire.

[GLDavid]

J'ai choisi tout simplement autres.
Pour moi, la phrase qui tue commence par "Ce serait bien que (tu changes/modifies/ajoutes/supprimes/...)..." et surtout, cette phrase est prononcé quelques heures avant la date de release ou de déliverable. Grrrr !
Pourquoi ? Parce qu'on travaille avec des gens qui ne savent pas que faire un bouton et écrire toute la procédure de traitement liée à ce bouton prend du temps et ajoutes de la complexité au code.

Maudits soient les biolo.....clients !

[Invité(e)]

Après avoir vu un développeur ajouter un bouton dans borland :

C'est facilement maintenant de programmer.

[Tassin73]

Dans une vie antérieure:

Coup de fil à 03:00 du matin du contremaître, responsable du redémarrage éventuel de l'IBM 4331, sur lequel tournent les applications de suivi de fabrication:

"J'ai redémarré l'ordinateur suite à une coupure et j'ai un message en anglais..."

"Oui ? Lequel ?"

"eh... data base no... euh... avélable"

"Database not available ?... OK... J'arrive !"... Après un déplacement de 30 kms en pleine nuit, j'arrive devant la console et lis:

"Database Now Available !"

Arggggggggggggg !!!!!!

Le métier d'informaticien ne se limite pas aux frontières de la science de l'information mais à tous les appareils électroniques et ça gave.


J'adore aussi ce type de situation => j'ai développé une nouvelle application et au moment des tests utilisateurs ils sortent plein choses manquantes, erronées, à modifier etc... En ayant vu la maquette quelques jours avant et que tout était parfait pour eux .
Bon bah c'est repartit pour quelques journée de développement supplémentaire .

[xtope]

J'adore aussi ce type de situation => j'ai développé une nouvelle application et au moment des tests utilisateurs ils sortent plein choses manquantes, erronées, à modifier etc... En ayant vu la maquette quelques jours avant et que tout était parfait pour eux .
Bon bah c'est repartit pour quelques journée de développement supplémentaire .

Oui mais ça c'est une situation courante que tu retrouveras quasi partout. Perso je ne les blâme pas dans ce genre de cas, il est vrai que souvent après coup on se rend compte que telle chose ou telle chose serait mieux si elle était faite autrement. Le tout est de leur faire bien comprendre l'impact de chaque modification.

[vg-matrix]

tout le monde, je viens de découvrir ce sujet et franchement le fait d'avoir un truc de ce genre pour se relaxer un peu des plaintes des utilisateurs est vraiment génial. Voilà une situation qui m'est arrivé au service pendant ces derniers jours après avoir déployé de nouvelles machines:

Utilisateur: Allo, "service informatique", pourquoi mon adresse ip (192.168.0.10) à changé?
Moi: C'est pour ne pas avoir à reconfigurer toutes les machines de l'entreprise et puis ça ne gène rien puisque vous ne vous en servez pas dans votre activité quotidienne.
Utilisateur: Non, je veux garder mon ancienne adresse qui était 192.168.0.100
Moi: Avez-vous un problème d'accès au réseau?
Utilisateur: Non, mais je veux mon ancienne adresse.
Moi: OK, je le direz à mon chef de service et on verra
Utilisateur: d'accord mais ne tardez pas
Moi:

Si l'adressage était dynamique, on aurait pas eu ce problème.

Vous savez, le métier d'informaticien est certes difficile mais passionnant !!!

[MaliciaR]

Maudits soient les biolo.....clients !

Tz tz tz tz, on va pas s'entendre là

[tulipebleu]

En parlant de commercial, c'est souvent :

l'ingénieur : il faut 50 jours pour le projet
le commercial : mais le client ne peut en acheter que 30
l'ingénieur : en supprimant le dernier module qui franchement ne sert pas à grand chose, je peux le faire en 30.
le commercial : parfait

(un peu plus tard...)

le commercial : finalement, je lui ai vendu 30 et comme il voulait le dernier module, je lui ai mis aussi... Et puis comme le client était un peu frileux, on est en mode forfait (forcément, le client est pas con, il sait qu'il y aura beaucoup de dépassement).

Moi c'est plutôt :
commercial : il faut faire ce nouveau projet en 30.
moi : Ok.
une semaine avant les 30 jours :
moi : on ne pourra pas finir, il nous faut encore 2 semaines.
commercial : après discutions avec le client, il accepte une ralonge de 2 semaines, mais il faudra ajouter 3 modules au projet.

[Louis Griffont]

Moi c'est plutôt :
commercial : il faut faire ce nouveau projet en 30.
moi : Ok.
une semaine avant les 30 jours :
moi : on ne pourra pas finir, il nous faut encore 2 semaines.
commercial : après discutions avec le client, il accepte une ralonge de 2 semaines, mais il faudra ajouter 3 modules au projet.

Dans ce cas, c'est toi qui t'es gauffré, pas le commercial. Ensuite, lui doit négocier et c'est pas toujours aisé !

[calibhaan]

J'ai mis autre...
le celebre:
- J'ai un problème avec Windows, il faudrait que tu m'aide...
- Ouais non mais en même temps moi je suis pas consultant windows, je suis développeur d'application...

[B.AF]

c'est le problème des devs : des personnalité souvent peu extraverties, et donc pas très réactives aux agressions du quotidien.
J'avoues même que je trouve que dans le dev en général, il y a une forme de puérilité et de déni, au sens où en 2009 beaucoup de dév pensent encore qu'ils seront augmentés pour leur technicité, chose qui ne sera jamais considéré, puisque les évaluateurs en ont rarement la capacité.

[Altess]

B.AF > Ou comment me casser le moral a 9:36 du matin

[Barsy]

Dans ce cas, c'est toi qui t'es gauffré, pas le commercial. Ensuite, lui doit négocier et c'est pas toujours aisé !

Son problème est souvent la conséquence du mien. Quand le commercial décide de vendre un projet en le "sous-chiffrant", on arrive à la fin du terme avec encore la moitié du projet à réaliser. Résultat, il faut négocier un délai avec le client.

Autre chose aussi qui est bien énervant c'est :

L'ingénieur : Il faut 30 jours pour faire le projet.
Le chef de projet : Mais le client veut être livré dans 10 jours. On va vous mettre à trois dessus comme ça vous respecterez les délais.

Je ne sais pas pourquoi, mais les managers ont toujours l'impression qu'en multipliant par X l'effectif, on divise par X le temps. Et si le client veut-être livré demain, on met 30 personnes ? C'est le problème de chiffrer les projets en jour/homme.

[Invité(e)]

Je ne sais pas pourquoi, mais les managers ont toujours l'impression qu'en multipliant par X l'effectif, on divise par X le temps. Et si le client veut-être livré demain, on met 30 personnes ? C'est le problème de chiffrer les projets en jour/homme.

Pour expliquer ce problème avec des mots simples, on peut utiliser cette métaphore :

Pour faire un bébé, il faut une femme et neuf mois.
Mais vous pouvez toujours demander à neuf femmes de faire un bébé en un mois...

[hegros]

Les estimations en même temps en moyenne c'est des marges d'erreur au minimum à partir de 50%... L'erreur c'est d'estimer qu'une seule fois et de ne pas renouveler son estimation ce qui traduit en fait un manque sérieux dans le suivi et le contrôle des tâches mais estimer tout le monde ne sait pas faire, suivre et contrôler d'autant plus...

[chaplin]

c'est le problème des devs : des personnalité souvent peu extraverties, et donc pas très réactives aux agressions du quotidien.

Ce ne sont ni plus ni moins des rapports de force. J'ai relevé que les femmes fuyaient la filière informatique, et ça c'est un mauvais signe pour toute la profession dev ou pas dev.