Discussion :

[WinNew]

Bonjour à tous,

Je souhaiterais votre point de vue sur la situation qui est la mienne (et celle de mes collègues). Nous sommes dans une petite boîte qui est encore en phase de développement.

J’ai beaucoup de mal à suivre les exigences du management. Au début, je me suis dit que j’avais des problèmes personnels. Mais, en discutant avec les autres, je réalise que le problème vient du management (il n’y a qu’à voir le nombre de développeurs qui viennent et qui partent).

Que pensez-vous de cette organisation :

• Tu es concentré sur le ticket A.
• On te dit que le ticket B est prioritaire. Tu interromps donc ton travail sur A pour te concentrer à B.
• Sur ce, un problème d’exploitation engendre un ticket C encore plus prioritaire que B. Tu interromps donc ton travail sur B pour te concentrer à C.
• Quand tu as terminé l’analyse de C, les priorités ont changé, et on te demande de travailler sur un ticket D.

J’ajoute qu’on vous demande de travailler sur des tickets sur lesquels vous ne connaissez rien. Et on ne vous donne aucune information.

Résultat : tu as clôturé C, mais A et B restent ouverts. Tu es pris par le rythme. Tu oublies complètement A et B... et quand tu te penches de nouveau dessus (si tu te penches dessus), tu as tout oublié et tu dois refaire tout un cheminement intellectuel pour te remettre dans le contexte.

Personnellement, j’ai beaucoup de mal à sauter sans cesse du coq à l’âne, en laissant en plan la moitié de ce que je commence.

-> Grosse fatigue.

Quels sont vos points de vue sur cette technique de management  « au ticket » ?

Merci,

WinNew

[jabbounet]

cela ressemble a un problème d'organisations.

des méthodes type kanban ou autre peuvent aider à traiter ce type de problématiques.

[Jean-Philippe André]

Salut,

j'ai eu des cas un peu similaires en Angleterre. Mon manager a mis un tableau en place sur Excel avec les éléments suivants :
- ID du problème
- origine (qui est destinateur du problème)
- sponsor (qui est destinataire de la solution)
- date de création (création du ticket)
- degré d'urgence (rouge / orange / vert / bleu si fini)
- dead line (date limite)
- chargé du problème (membre de l'équipe)
- date du dernier point (si réunions d'équipe ou bilan individuel)
- commentaire du dernier point (idem)
- statut (en cours, en attente, terminé)

Ca te permet potentiellement de garder un oeil sur ton historique, et d'autre part c'est très pratique en cas de reporting à faire sur ton activité ou celle de ton équipe

[garheb]

Ca m'a tout de suite fait pensé à ça pour ceux qui connaissent: http://imgur.com/t0XHtgJ

Pour ceux qui ne connaissent pas: Le personnage doit changer une ampoule, mais en en cherchant une il s'aperçoit qu'une étagère est mal fixée, il décide donc de la réparer, il va donc chercher un outil dans un tiroir, qui grince, il décide donc de le réparer... La chute: sa femme demande si il a changé l'ampoule et on le voit, sous la voiture "Tu vois pas que c'est ce que je suis en train de faire?!"

Concernant ton problème: pas possibilité de vous répartir les types de tickets, de manière à ne jamais avoir à abandonner un ticket pour un autre?

[GoldKnight]

Tu es vraiment obligé de sauter d'un ticket à l'autre ?

En fait je te demande cela car avec l'expérience j'ai appris à relativiser les demandes d'un management de plus en plus exigeant et de moins en moins cohérent.
Il n'y a rien de pire lorsqu'on est concentré sur une tâche qu'une interruption, c'est la règle d'or de la productivité. C'est pour cela que je ferme souvent mon mail par exemple.
Lorsque tu es sur un ticket A si on te demande d'en faire un autre B, note la demande mais met la de côté le temps d'obtenir un résultat pour A. Ça ne veut pas dire forcément dire terminer A mais terminer par exemple le programme en cours, noter soigneusement où tu en es, afin que lorsque tu reprends A tu puisse d'imprégner du sujet rapidement. Et ne saute pas comme un affamé sur une demande sous prétexte qu'ils disent que c'est urgent. On t'avais dit que B était urgent mais C est encore plus urgent alors quid de B ? Finalement c'était pas si urgent puisque tu es censé faire C. Donc autant rester concentré sur A le temps d'obtenir le résultat dont je t'ai parlé.

[WinNew]

Je crois surtout que le management est pris de panique.

Notre système d’information est hyper instable.

Une « action » entraine une cascade de requêtes HTTP (jusqu’à cinq). Quand il se produit une erreur sur un maillon de la chaîne, il résulte d’une cascade d’erreurs... Mais il n’y a aucun moyen simple d’identifier les requêtes d’une même action. Ils auraient pu passer un identifiant unique à toutes les requêtes d’une même action... mais non. Ils ne l’ont pas fait.

Le chef dit : « je veux être totalement indépendant du SGBD ». Résultat : ils n’utilisent pas le SQL (les jointures sont faites en PHP, via des boucles...). Et puis, au lieu de renvoyer les données, on instancie des objets qui contiennent les données... Ils n’utilisent pas les transactions. Une requête qui prend 10 ms en SQL prend 5 secondes en PHP... et il arrive que PHP épuise la mémoire qui lui est allouée. Et nous avons, évidemment, des données incohérentes.

Quand vous associez les requêtes HTTP en cascade et le NO SQL : vous avez des timeouts HTTP à cause d’accés à la base trop longs... Cela génère une avalanche de messages d’erreurs (sur tous les maillons de la chaîne HTTP). Et puis c’est pareil quand une requête plante, car PHP n’a pas assez de mémoire (car on fait les jointures en PHP).

Les LOGs sont envoyés à un syslog. Résultat : ils sont tronqués et il y a des LOGs qui passent à la trappe. C’est super : on ne sait pas ce qui s’est passé.

Le SI est hyper compliqué, et il est extrêmement difficile de diagnostiquer quoi que ce soi. En plus il est très instable...

Bref, les concepteurs ont conçu un élégant système « académique », hyper découplé, mais ils n’avaient pas les reins assez solides pour ça : on a demandé à des développeurs WEB de monter un système d’information industriel.

Et aujourd’hui, c’est la panique...

[phili_b]

oui mais ça n'empêche que ce dit GoldKnight est de bon conseil.

Surtout si c'est programmé avec les pieds et que les messages d'erreurs sont délayés dans les logs, ça veut dire qu'il faut un minimum de temps pour les analyser.

Fixes toi des tranches de temps incompressibles. Non si tu as commencé une tâche, quelque soit l'urgence tu ne passeras pas à l'autre avant 1/4 d'heure.

En support tu dois être multitâche et disponible, mais en fait c'est du temps partagé, pas du temps réel.

Pour toute tâche tu dois répondre relativement rapidement, mais ça ne veut pas dire l'analyser systématiquement tout de suite, ni encore moins la résoudre tout de suite.

D'ailleurs s'il faut répondre rapidement, il ne faut pas non plus habituer les gens a une réactivité instantanée sinon tu ne t'en sors pas.

Et il faut des vrais degré d'urgence et de délai. Comme ça c'est toi qu'organise. Tandis que si tout est urgent ça ne peut pas fonctionner. Je me souviens d'un tableau de reste à faire où tout était en priorité maxi. Le chef de projet l'a renvoyé en demandant de remplir le tableau avec des priorités équilibrées pas toutes à maxi.

[Carhiboux]

Salut,

Tu parles de ticket, donc j'imagine que vous avez un mantis/teamtrack/jira/autre pour gérer vos incidents.

La plupart des outils de gestion des incidents proposent de mettre une priorité sur les tickets.

C'est au demandeur (le client) ou à défaut au chef de projet de définir les priorités.

Ensuite et sauf incident super grave, ou que ta tache en cours doive durer super longtemps, changer sans cesse de tache est très improductif.

Bref, c'est un problème que tu dois faire remonter à ton management, idéalement, avec des solutions à proposer : par exemple, puisque vous êtes plusieurs et que le chef ne semble pas assumer son role de dispatcher, proposer qu'un membre de l'équipe s'en charge, afin de définir les priorités et de ne pas déranger tout le monde.

[Glutinus]

D'accord avec Carhiboux.

Tu as ton mot à dire sur la durée que vont prendre chaque action, mais tu dois régulièrement voir avec ton chef de projet pour les différentes priorités, dans un contexte de maintenance / suivi de production c'est nécessaire qu'il y ait un gestionnaire de priorités.

Avec de l'expérience tu apprendras à jongler entre les tâches avec le minimum de stress possible, mais le but (difficile) est de faire comprendre que tu peux pas gérer tous les tickets en même temps.

[Waldar]

En plus de ce qui a été dit au-dessus, je vous conseille deux choses :

1. Lorsqu'on vous attribue une nouvelle tâche, il faut systématiquement la refuser au lieu de l'accepter.

On va vous demander pourquoi, il faut expliquer que vous êtes déjà sur une priorité et vous demandez à votre manager de discuter avec le client qui vous a affecté la tâche en cours afin de démêler les tenants et aboutissants non pas de la nouvelle tâche, mais de ne pas finir la première.

Dans le meilleurs des cas ça vous donne du temps, soit pour finir la tâche, soit pour l'avancer assez significativement pour la finir.

Dans le pire des cas (c'est le même demandeur qui a déjà fait son choix), ça ne change rien par rapport à maintenant.



2. Clôturer la tâche en cours avec un motif "Reportée à la demande du client". Ça vous dédouane de tout mauvais procès d'intention qu'on pourra vous coller par la suite.


L'idée générale n'est pas de ne pas travailler, c'est de gagner du temps afin de laisser à qui de droit de peser le pour et le contre d'un changement de priorité et donc de mettre les managers devant leurs responsabilités.


Bon courage.