Contrôle de temps des développements

[deadalnix]

Envoyé par Luckyluke34

Dans le deuxième type de boîte (qui a dit SSII ? ^^) il n'est que logique de mesurer les temps passés le plus finement possible pour pouvoir identifier les problèmes et les corriger au moindre écart. Encore faut-il que 1/ les mesures soient fiables, 2/ analysées correctement, 3/ que les bonnes actions soient décidées derrière et 4/ qu'il y ait des retours pour éventuellement adapter ou modifier celles-ci. D'après ce que j'ai vu, ça tient plus souvent de la théorie que de la réalité et les décisionnaires sont tellement éloignés du terrain que les actions menées sont souvent contre-productives.

Et même la, tu as pas d'infos utiles. Comment tu mesures par exemple les écarts de productivité avec les gens que tu n'as embauché qui serais venu dans ta boite si les conditions y étaient meilleures ? Comment tu mesures l'adhésion des troupes aux objectifs de la boite, leur motivation ? La créativité des solutions trouvées, et ce que ça va te coûter/t'économiser par la suite ?

[I_believe_in_code]

Personnellement je ne travaillerais pas pour une société qui me demande de me justifier tous les quarts d'heures, ni même toutes les deux heures. C'est du flicage, et si on veut me fliquer on n'a qu'à le faire en se passant de ma propre complicité.

Question : "oui, mais non, gros Troll, t'as rien compris, ça sert pas à fliquer..."

Réponse : Mon expérience (qui est discutable) m'a appris que toute chose pouvant servir à fliquer les gens (que cela soit sa vocation première ou non) finit par ne servir qu'à cela.

[souviron34]

Envoyé par jabbounet

Il pourrait être interessant de mettre une balise [TROLL] [/TROLL] sur le forum qui apparaitrait dans un cadre spéciall avec des poils autour.

Cela permettrai au lecteur d'etre averti sur les intentions de la personne qui post.

Envoyé par el_slapper

C'est à l'appréciation des modérateurs. Je le fais parfois. J'ai été rappellé à l'ordre une fois.

J'aime la proposition de Jabbounet(les poils autour du texte assumé trollesque) : celà permettrait de rendre plus visuelle - et donc perceptible par un lecteur qui ne s'y attend pas - l'ironie.

ça existe déjà, si on regarde bien :

[]
..
[/]




Bon, les crochets sont de moi ..

[_skip]

Pour en revenir au sujet, j'ai été amené à faire cela mais ce n'était pas pour du flicage. Un problème qui arrive vite lorsqu'on développe un progiciel et qu'on offre des contrats de maintenance c'est de contrôler ce que ça nous coûte.
Style une personne téléphone pour un souci, on passe le développeur, on essaie des trucs... Tout ça paraît faire partie des petits à côtés quotidiens mais cela peut finir par chiffrer assez sec.

Résultat, chez mon précédent employeur nous avions décidé que dorénavant les appels de support seraient mentionnés dans un document par tranche de 15 minutes arrondis au dessus avec le nom du client concerné (sauf si vraiment c'est la bricole qui prend 1min).
A cause des observations que nous avons faites alors, nous avons décidé de modifier le contrat de maintenance pour passer de support illimité à "juste" 1/2 journée gratuite par année. Car si on prenait toutes les questions qui auraient été répondues en lisant le manuel ou en demandant au collègue à qui on avait déjà expliqué en détail, on avait des gens qui nous coûtaient 3 à 5 fois le prix du contrat de maintenance. Dès que cette limitation du crédit temps a été introduite, les clients à problème ont soudainement cessé leur recours quasi-systématique au support et le contrat de maintenance est redevenu profitable.

Bref, maîtriser les coût est indispensable dans la majorité des cas. Après obliger le développeur à justifier toute sa journée, c'est peut être quelque peu contre productif car il risquerait de se mettre à faire des mauvaises économies (négliger un peu le test) qui nous retomberaient dessus ou alors s'il règlerait plus rapidement que prévu un souci, d'allonger ses pauses clopes ou de ventiler le temps gagné sur autre chose ce qui tuerait le concept. Sans compter que ça entraînerait des réfléxes défensifs, comme doubler ou tripler le temps réel lorsqu'ils évaluent la durée d'un projet, donc on s'en sort pas toujours gagnant.

Pour ce qui est du temps passé *sans produire*, un exemple bien connu d'un produit dont la boîte a coulé à cause du temps de support, c'est vistaDB en .net. Le produit coûtait quelque 300 dollars, le support gratuit pour les souscripteurs était illimité et fait aux US, ben ça leur a été fatal. Ce n'est pas une déduction que j'ai faite, c'était le propriétaire de la société qui le mentionnait clairement comme cause majeure de son échec sur son blog.

[deadalnix]

Et si en premier lieu, le support, ce n'était pas les gens du dev, et que ça ne remonte à eux que si le problème le nécessite vraiment ?

Même sans une petit boite, c'est justifié d'avoir une personne pour cela.

Cette personne peut en effet reporter combien de temps elle a passé avec chaque client pour le contrôle des coûts. Mais le travail de dev n'est pas du tout compatible avec des interruptions répétées. Le coût, rien qu'en motivation/productivité dépasse largement le temps d'appel au client, même arrondis au dessus.

[el_slapper]

Ca dépend. Certains considèrent que c'est un choix judicieux, histoire de motiver les développeurs à améliorer leur bidule.

[deadalnix]

Tu as du tu tromper d'article. Le liens que tu fournis explique un fonctionnement similaire à celui que je décris.

[_skip]

Envoyé par deadalnix

Et si en premier lieu, le support, ce n'était pas les gens du dev, et que ça ne remonte à eux que si le problème le nécessite vraiment ?

Même sans une petit boite, c'est justifié d'avoir une personne pour cela.

Cette personne peut en effet reporter combien de temps elle a passé avec chaque client pour le contrôle des coûts. Mais le travail de dev n'est pas du tout compatible avec des interruptions répétées. Le coût, rien qu'en motivation/productivité dépasse largement le temps d'appel au client, même arrondis au dessus.

Dans un monde idéal, effectivement il y aurait quelqu'un qui ne fait que du support, qui a les compétences techniques et le métier nécessaire qui filtre au moins le plus gros des demandes.

Sauf que dans certaines structures, il y a juste pas assez de support pour justifier un salaire à temps plein, donc c'est un collaborateur qui s'en charge selon le schéma suivant :

• La secrétaire ne connaît pas suffisamment le métier, ni le logiciel
• Le commercial est soit absent en prospection, soit rapidement dépassé et il ne connaît pas toujours le logiciel en profondeur.
• Le technicien s'y connaît en routeur et en système mais le métier c'est pas son fort.

Et il reste plus que le développeur, qui connaît le métier ET le logiciel, sait distinguer une anomalie d'un comportement normal dû à une configuration foireuse etc...

Mais bon à la décharge de tout ce petit monde, le support est très souvent un truc délicat. On peut certes investir dans une équipe qui fait que cela mais à partir de là les coûts augmentent autant pour le client que pour l'employeur avec les formations, les salaires etc... Au risque que le produit se retrouve niqué par rapport à la concurrence moins chère (car ce qu'un client demande très souvent c'est "combien?").
On peut aussi essayer de le sous-traiter là où c'est pas cher comme le font presque tous les *gros* (Asie, pays de l'est) mais avec les risques qui vont avec.

Ou alors on espère qu'il y en aura pas trop et on fait avec les gens qu on a sous la main. Il y a beaucoup de sociétés qui n'atteignent pas les tailles suffisantes pour avoir un support dédié.

Enfin pour revenir au sujet, même en dehors des cas de support, nous avons besoin de maîtriser ce que ça nous coûte pour savoir où on va. Et cela concerne également (voire particulièrement) les prestations non facturées, typiquement mon entreprise offre les évaluations gratuites au client, ça nous demande du boulot, on veut savoir combien... C'est naturel.

[el_slapper]

Envoyé par deadalnix

Tu as du tu tromper d'article. Le liens que tu fournis explique un fonctionnement similaire à celui que je décris.

Sauf que l'auteur, lui, trouve ce fonctionnement normal.

[Kearz]

Au choix:

1-Très répétitif
9h00 - 9h15: Allumer le PC. Démarrer tout les outils.
9h15 - 9h30: Travail sur la X destinait faire Y
9h30 - 9h45: Travail sur la X destinait faire Y
9h45 - 10h00: Travail sur la X destinait faire Y
10h00 - 10h15: Travail sur la X destinait faire Y
10h15 - 10h30: Pause
10h30 - 10h45: Travail sur la X destinait faire Y
10h45 - 11h15: Travail sur la X destinait faire Y

2-Précis
9h00 - 9h15: Allumer le PC. Démarrer tout les outils.
9h15 - 9h30: Travail sur la X destinait faire Y. Analyse du problème [...]
9h30 - 9h45: Travail sur la X destinait faire Y. Choix de l'algorithme, initialisation des variables.
9h45 - 10h00: Travail sur la X destinait faire Y. Erreur d'analyse, recommence.
10h00 - 10h15: Travail sur la X destinait faire Y. Mise en place dans brique A, B, C.
10h15 - 10h30: Pause. Toilette-Cafe
10h30 - 10h45: Travail sur la X destinait faire Y. Test A,B,C.
10h45 - 11h15: Travail sur la X destinait faire Y. Test D,E,F.


Avec la méthode 1, c'est une perte de temps autant tout regrouper.
Avec la méthode 2, et pourquoi pas coder directement dans la grille?

Franchement je comprends trop l'intérêt. A la journée ou demi journée c'est compréhensible. (Pour savoir où en est le projet, ce qui a été fait, etc.)

ça pourrait être utile pour les contrats de maintenances mais c'est pas précis non plus au final: tu passe 20 à régler le problème du client, t'en marque combien? 15 ou 30?
Pour la maintenant, c'est mieux d'avoir un compteur et de dire: tel client, je viens de passer XX minutes.

Bref,
Contrôle des temps = normal
Contrôle du temps tout les 15 minutes = flicage, outils de pression, stresse, pas bien, etc.

[Faereth]

Le contrôles des temps est important pour pouvoir évaluer le temps de développement de nouvelles fonctionnalités ou de corrections d'anomalies.

Dans ma boîte on a un logiciel qui nous permet d'affecter un temps à des tâches qui nous sont affectées, temps que nous devons saisir à chaque fin de journée (normalement) pour avoir une synthèse en fin de mois du temps réellement passé sur tel ou tel dev.

Au début je me disais, ouais pourquoi pas, cela peut être bien, et à la limite je comprends que ma boîte désire pouvoir mieux gérer ses coûts/temps de développement. Mais bon premier problème, ce logiciel découpe les journée en 1/8ème, 1/8ème qui équivaut à peu près à une heure... Bon déjà il faut commencer à feinter quand tu as des petits dev qui te prennent 5 minutes (genre corrections de mini-bug)... OK c'est pas grave, on nous répète que de toute façon cet outil c'est pour l'équipe pour que l'on puisse avoir une meilleur visibilité de qui fait quoi...

On prenait une marge de 30% non affecté dans le mois, pour pallier aux-bugs-ultra-urgent-que-tu-dois-traiter-tout-de-suite... Mais bon il y en avait pas toujours (et heureusement ^^) mais du coup tu te retrouvais à ne pas remplir tous ton mois. Quand je n'ai plus de tâches, je cherche à aider des collègues, faire de la veille, etc...

Mais un beau jour, un mois où tous mes temps n'étaient pas remplis, je reçois un mail de la DRH (dans ma boîte c'est une espèce de nébuleuse, tu ne sais pas qui ils sont mais eux savent ce que tu fais), me demandant ce que j'avais fais tel jour à telle heure et pourquoi cela n'était pas renseigné dans le logiciel. Et là j'ai commencé à me dire que le : "Cet un outil pour nous développeur, pour nous aider dans notre organisation" ressemblé à un gros flicage déguisé par la DRH.

Résultat? Des collègues créent des tâches bidons pour saisir des temps dans cet outils alors que l'on travaille hein, mais quand tu passes du temps à former un nouveau et que tu n'es pas cencer le faire tu te fais taper sur les doigts... Alors tu commences à gonfler les temps de dev en prévision, etc...

Moi je continue à laisser des mois "à trou" et ne me justifie pas. Pour le moment je n'ai pas eu de mauvais retour, mais je pense que ca va venir, et de toute façon j'ai de quoi leur répondre.

Tous ca pour dire que bien géré je pense que la saisie des temps et une bonne chose, mais qu'il faut rester dans un aspect "humain", tu vas pas être efficace toute la journée, mais tant que le taf est fait...

[Nemek]

Là où je bosse, je suis en moyenne uniquement à 50% de mon activité prévue la semaine précédente....

Cependant j'ai toujours des tâches qui correspondent à mes activités réelles : formation, support fonctionnel, support Oracle, etc. Par contre la chose qui fait défauts ce sont les activités transverses, je dois les répartir sur les différents projets sur lesquels j'interviens.

[h2s84]

Tiens ça me rappelle cet article Manager une entreprise par les données, est-ce vraiment plus efficace ?

[souviron34]

Que je trouve (ainsi que la conclusion MIT/harvard) pas mal fausse...

Car, basé sur des chiffres, ni Renault, ni André Citroen, ni Marconi, ni Bell, ni Ford, ni Jobs, ni Gates, ni Péladeau, ni aucun des grands entrepeneurs industriels n'aurait fait quoi que ce soit..

Ils partaient tous perdants : petits, avec des concurrents gigantesques ayant l'oreille des gouvernants ou des autres grandes industries, avec peu - voir pas du tout - de moyens, pas de marchés.. Juste des idées, des passions, et 1 ou 2 copains même pas de la partie au max...

[okaparka]

Envoyé par tssi555

Bonjour,

....tenir à jour un fichier (excel) d'activités journalières 15 minutes par 15 minutes! de manière quotidienne...? .

Selon le théoreme de Shannon sur l'échantillonnage, faire un relevé de temps toutes les 15 minutes suppose que la tâche ait une durée prévue (ou contractuellement planifiée avec la hiérarchie) de 150 minutes (2 h 30) et que le dérapage autorisé est de 15 minutes... et aussi que le manager n'ait pas plus d'un quart d'heure de retard (disons 5 minutes) lorqu'il viendra faire la recette de la fourniture.

Dans ce contexte on peut admettre qu'un suivi au quart d'heure peut permettre de rectifier le tir pour éviter une livraison de la fourniture avec une demi heure de retard (ou une demi heure d'avance !).

hors de ce contexte , c'est une connerie comme cela a déja été dit.

[el_slapper]

Envoyé par souviron34

Que je trouve (ainsi que la conclusion MIT/harvard) pas mal fausse...

Car, basé sur des chiffres, ni Renault, ni André Citroen, ni Marconi, ni Bell, ni Ford, ni Jobs, ni Gates, ni Péladeau, ni aucun des grands entrepeneurs industriels n'aurait fait quoi que ce soit..

Ils partaient tous perdants : petits, avec des concurrents gigantesques ayant l'oreille des gouvernants ou des autres grandes industries, avec peu - voir pas du tout - de moyens, pas de marchés.. Juste des idées, des passions, et 1 ou 2 copains même pas de la partie au max...

Je pense que ce sont des choses différentes. L'intuition des dirigeants, ça joue sur la stratégie. Genre, je vais faire fortune grâce à un site web qui permet à une niche pauvre(les étudiants) de glander(Facebook).

Le DDD, c'est un avantage tactique : est-ce que mon avion doit passer la nuit à Vancouver ou à Seattle, suivant les conditions météo? Ca ne permet pas de passer outre une mauvaise stratégie, mais, à stratégie similaire, ça permet d'optimiser les rendements. Sur des marchés à faible marge, ça peut être déterminant. Jobs ou Gates ont créé de nouveaux marchés, le DDD aurait été au mieux d'in interêt marginal pour eux. Pour Air France ou pour Wizzair, par contre, ça peut vraiment faire la différence.