C’est l’histoire d’un projet, pas plus complexe que d’autres, pas plus simple non plus : une application qui s’interface avec une base de données et 2 systèmes tiers. Du classique du point de vue technique et architecture, du standard également du point de vue management : il faut tout faire pour hier et il y a beaucoup à faire…bref, « ca va être chaud! » comme disent souvent les développeurs mais personne ne le crie trop fort.

Alors on « staffe », on monte à 40 personnes, on spécialise les gens, on contractualise entre les équipes. Les équipes s’organisent en pools, répondant à certaines demandes puis redispatchant d’autres demandes à d’autres pools. Un flux de demandes s’organise, certains pools chauffent et deviennent le « goulot d’étranglement », un stock se crée en amont alors que les équipes en aval attendent…Dès lors et pour ces pools en surchauffe, l’important devient l’urgent, il faut choisir parmi l’urgent pour répondre à l’immédiat, switcher de tâches en permanence et au final, la chaine globale ralentit.
En complément, les reportings commencent à virer au rouge dans les premiers niveaux de management. Mais au fur et à mesure de l’escalade de ces mêmes reportings dans la hiérarchie, ces derniers virent au vert tant et si bien qu’en « haut » : tout va bien...

suite sur ce blog

http://blog.octo.com/cest-lhistoire-dun-projet/