Discussion :

[Ska_Dg]

Bonjour à tous! Tout d'abord, je dois avouer que c'est mon tout premier post mais je fréquente régulièrement le forum et je dois dire qu'il est excellent, gros bravo à tous ceux qui le font vivre.
Mon problème est le suivant :
Je suis actuellement programmeur, depuis maintenant un peu plus d'un an, dans une entreprise toulousaine qui compte un peu plus de 3000 employés.
Je participe donc à la création, la mise à jour et la correction d'applications nécessaires à cette même entreprise. Seulement régulièrement, je met prend un tire car l'utilisateur à rencontrer 1 ou 2 bugs dans l'appli.
Une petite explication sur le fonctionnement du service de développement :
-1 directeur info
-1 chef de projet
-4 programmeur
Le directeur info, présente le travail à effectuer au chef de projet, qui prend quelques notes sur une feuille. Le chef de projet, une fois de retour dans son bureau, arrange ses quelques notes de manière à créer des phrases et ensuite nous fait un topo rapido, à partir de ces notes qu'il nous laisse en tant que cahier des charges.
Le programmeur (moi en l'occurence), fait ce qu'il à faire et fini par ses tests.
Le programme est alors contrôlé par le chef de projet puis validé.
Seulement il arrive que de temps en temps divers bug apparaissent à l'utilisation. Et c'est à ce moment que le directeur info vient me mettre un tire, me menaçant, aujourdhui même de prendre les sanctions qui s'avèrent nécessaire.

C'est pour cela que j'aurai aimé avoir votre avis de professionnel, qu'en pensez-vous? comment cela se déroule-t-il ailleurs (car c'est mon premier job en tant que programmeur)? Peut-être ne suis-je tout simplement pas fait pour cet emploi ? Ou 'est-ce leur organisation qui en serait en partie la cause?

Merci à tous par avance.

[orafrance]

le travail est validé par le CP c'est donc lui qui est responsable en cas de non conformité de l'appli par rapport à la demande. Ca c'est pour le cas où le cahier des charges ne serait pas respecté.
Si ce sont des bugs techniques qui mettent en défaut la qualité de ton code, alors tu es en effet responsable de ces bugs. Pour éviter de faire monter la mayonnaise et montrer ton professionnalisme tu peux fixer des objectifs à valider par le DSI (par exemple : pas plus de 2 bugs fonctionnels et 1 bugs techniques par demande du CP) et demander des moyens supplémentaires si tu penses que c'est ce qui fait défaut : plus de temps pour les tests unitaires, environnement de recette pour valider le dév, etc...

Attention aussi de bien identifié le type de bug : est-ce une erreur qui est passée à travers les tests unitaires, une erreur fonctionnelle ou une évolution (là c'est plus toi le responsable par exemple )

[LooserBoy]

Les conseils d'orafrance sont, comme à l'habitude, de bons conseils... (il va choper le melon... tsss)

Ce n'est pas très correct de la part du DSI de venir "souffler dans les bronches", directement, du "grouillot" programmeur sans tenter de savoir quelle étape du dev/tests/deploiement a raté. (On est pas "chez mémé"! Le respect au travail, ca existe!)

* Reflechis à voix haute... alors... un DSI... un CP... un Dev... *

Et si le CP s'était "couvert" vis-à-vis du DSI et donc que tout te retombe dessus et rien sur lui? (parano? moi? mais non... juste échaudé...)
Quel est le type de relations avec le CP?

[Ska_Dg]

Merci de vos réponses ca permet de voir un peu plus clair.
En fait, les bugs ressortant sont en non conformité avec "la demande" ( je préfère appeler comme cela les pseudos cahier des charges que je reçois : feuille de brouillon, écrite au crayon à papier) et sont passés outre les divers tests effectués par ma part et celle de ma CP.
Pour te répondre LooserBoy, en ce qui concerne la relation avec ma CP, bah c'est pas compliqué, c'est grand sourir par devant et même compliment (Car elle m'a complimenté pour ce prog justement) et par derrière c'est daillage en règle. Je l'ai su par un collègue ayant une plus grande ancienneté dans la boîte et qui a eu l'opportunité d'entendre quelques conversations entre DI et CP.

Le problème est que je ne peux quitter mon employeur, car je suis soumis à une clause de dédiformation.

PS: JE fais un petit edit de mon message, car je viens de relire vos messages. En ce qui concerne la recette du programme, chez nous cela se passe ainsi : CP fait quelques tests et valide puis c'est la mise en place.
Voilà, pas terrible l'environnement de recette? ....

[LooserBoy]

Tu peux proposer, afin que de pareils situations ne se reproduisent, de mettre en place un environnement de recette un peu plus formalisé (cahier de recette, environnement proche production,...).

De même, tu peux aussi proposer que l'echange de "cahiers des charges" se fassent un peu plus formellement. Un bon petit mail avec toutes les contraintes demandées accompagnées éventuellement d'une explication orale, ca clarifiera un peu les choses.

[el_slapper]

Dans une vraie boîte, il y a de vrais testeurs. Soit ce sont des spécialistes à plein temps, soit ce sont des utilisateurs détachés, dans le pire des cas un programmeur inutilisé.

Mais ce qu'il faut, c'est un cahier de tests. Complet. Qui décrit chaque test, son pourquoi, et son résultat attendu. Sans ça, c'est la fête du slip. Chacun prétend avoir raison - et tout le monde a tort.

Conseil Numéro 1 : demande des specs par écrit. Par mail, par exemple; ça ne vaut pas un bon vieux cahier des charges, mais au moins, tu as une référence écrite(et une petite boîte n'a pas forcément les moyens de tout faire)

Conseil Numéro 2 : Fais un cahier de tests(je sais, c'est abominablement emm'nuyant - mais il faut désormais couvrir ton derrièrre). Ou tu décris rapidement la tronche de ton test(j'ouvre l'appli, je selectionne le client dupont, je lui fais souscrire un contrat), et le résultat attendu(client ouvert, bouton actif, etc...). N'oublie pas les cas non passants(le client Dupont habite en IdF, impossible de l'affecter à l'agence de Bordeaux, ou son RIB n'est pas renseigné, etc...). Et quand tu as fini, tu transmets l'ensemble pour validation.

Avantage 1 : si tes tests ne sont pas complets, c'est au CP de le voir. Et c'est sa faute si il manque des cas
Avantage 2 : tu vas t'apercevoir, en les rédigeant, un tas de points que tu avais négligés - et donc avoir une meilleure couverture
Avantage 3 : pour la prochaine évolution, tu rajoutes juste le nouveau cas, tu retestes tout, et tu as assuré la non-regression.

[orafrance]

Merci de vos réponses ca permet de voir un peu plus clair.
En fait, les bugs ressortant sont en non conformité avec "la demande" ( je préfère appeler comme cela les pseudos cahier des charges que je reçois : feuille de brouillon, écrite au crayon à papier) et sont passés outre les divers tests effectués par ma part et celle de ma CP.
Pour te répondre LooserBoy, en ce qui concerne la relation avec ma CP, bah c'est pas compliqué, c'est grand sourir par devant et même compliment (Car elle m'a complimenté pour ce prog justement) et par derrière c'est daillage en règle. Je l'ai su par un collègue ayant une plus grande ancienneté dans la boîte et qui a eu l'opportunité d'entendre quelques conversations entre DI et CP.

Bah là il n'y a qu'une seule solution. Tu sollicites un entretien avec le DSI et tu lui explique pseudo-cahiers des charges et validation de la CP à l'appui. Après t'as juste à dire que ton travail est conforme à la demande de ta hiérarchie (la CP) et que si cette demande n'est pas conforme aux souhaits des utilisateurs alors il convient de mettre en place des processus qualités : MOE, MOA, spécification générale et technique, bon de livraison, etc... c'est le B.A.BA de la gestion de projet... si le DSI peut passer à coté (et encore mais ça tu vas pas lui dire ) la CP aurait du mettre en place ce type de process.

Avec ça, si ça calme pas le DSI et si la CP ne se prend pas un Skud alors tu peux craindre effectivement que les choses se dégradent

Tu peux aussi te tourner vers le DRH si tu ne te sens pas à voir directement le DSI

Le problème est que je ne peux quitter mon employeur, car je suis soumis à une clause de dédiformation.

Bah on n'en est pas encore à envisager une démission il me semble

[Ska_Dg]

Merci pour toutes vos réponses. Je vais tenter de faire changer cela.
Au moins je suis rassuré sur le fait, que l'organisation telle quelle est chez mon employeur actuel n'est pas générale et qu'une fois ma période de dédit formation terminée je pourrais trouver quelque chose de beaucoup plus fiable.

[LooserBoy]

Merci pour toutes vos réponses. Je vais tenter de faire changer cela.
Au moins je suis rassuré sur le fait, que l'organisation telle quelle est chez mon employeur actuel n'est pas générale et qu'une fois ma période de dédit formation terminée je pourrais trouver quelque chose de beaucoup plus fiable.

Ou de pire... (sans vouloir faire peur, ca existe... )

[_vince_]

Merci pour toutes vos réponses. Je vais tenter de faire changer cela.
Au moins je suis rassuré sur le fait, que l'organisation telle quelle est chez mon employeur actuel n'est pas générale et qu'une fois ma période de dédit formation terminée je pourrais trouver quelque chose de beaucoup plus fiable.

J'arrive un peu tard mais j'aimerais ajouter ma petite contribution.

Il y a un autre carton rouge concernant le management et ses methodes. Tes chefs semblent oublier que les bugs sont inevitables dans un logiciel. Un logiciel sans bug, ca n'existe pas ou alors c'est un logiciel qui n'est pas utilise. Et tout logiciel necessite son outil de suivi de bugs (e.g. trac, bugzilla). Et un rapport de bug doit decrire les faits, et ne doit pas etre ressenti comme un "tir" sur le developpeur.

Un chef qui se plaint des bugs mais qui ne met rien en place pour les eviter et ameliorer la qualite du logiciel... ce n'est pas un bon chef. Sans parler des specs ecrites sur un brouillon. Meme si le logiciel est utilise en interne, un peu de formalisme ne ferait pas de mal. Et ceci montre bien que la validation logicielle est un metier a part entiere avec ses methodes.