projet

De fr.discu.org
Aller à : navigation, rechercher

Un projet «ne marche pas» lorsqu'il semble s'enliser.

Si cela doit beaucoup à trop d'adversité tierce imprévue... mieux vaut parfois renoncer ou reporter, car à l'impossible nul n'est tenu.

Si les causes lui semblent propres, alors dans une forte proportion des cas l'ambition ou l'équipe sont trop étoffées.

Réduire l'ambition pose d'ordinaire surtout un problème d'ordre «politique», ici hors champ.

Pour le reste, en particulier en matière d'organisation d'un projet de développement de logiciel...

Héritage culturel et défis d'aujourd'hui

En matière d'organisation de projet notre héritage culturel est pétri d'enseignements issus des:

premiers grands projets contemporains
menés par les militaires ou assimilés (dès la première guerre mondiale puis durant le projet Manhattan et par la NASA dans les années 1960) dont les participants devaient, à cause du secret et faute de canaux de communication adéquats, être massifs et rassemblés. Rien ne devait filtrer à l'extérieur et il fallait s'assurer de tout impliqué car toute révélation quant aux travaux menés guidait potentiellement l'ennemi (dans le cas de la NASA durant la Guerre Froide il s'agissait en réalité surtout de développer des missiles ainsi que des techniques aux produits commercialisables),
conceptions productivistes
Taylorisme, Fordisme... procédant par ordonnancement et stricte définition des tâches (buts et modalités). C'est d'autant plus adéquat que l'on a parfaitement spécifier tout ce que l'on construit.

Aujourd'hui un participant confronté à une difficulté cherche seul réponse dans des gisements d'informations tels que les moteurs de recherche ou consulte ponctuellement un tiers grâce aux canaux facilitant contact rapide à distance (messagerie électronique, chat...).

Tout cela était inconnu des auteurs de principes gouvernant méthodes et modèles de processus aujourd'hui encore employés.

Le mode d'organisation devait tout à la culture des chefs, militaires et industriels, comme le révèlent l'outillage issu de ces efforts (PERT, CPM (sens 3), Gantt...) et l'organisation préconisée (chacun son rôle/sa mission/son poste/son périmètre/son titre/sa fonction/...).

Ils souhaitaient en particulier faciliter le remplacement inopiné de n'importe quel participant (un salarié coûte d'autant moins qu'il est facilement remplaçable et la disparition d'un soldat irremplaçable peut entraîner des dommages disproportionnés).

Les processus sont déterminants dans un contexte parfaitement maîtrisé (travail mécanisable, donc «un robot pourrait le faire») qui n'est pas celui du gros des projets de développement de logiciel, éminemment volatil et mal exploré donc privilégiant la capacité d'adaptation, auquel cet héritage n'est pas directement applicable.

L'agilité augmente semble-t-il la probabilité de succès et ses valeurs sont réciproques des préférences manifestées par militaires et industriels d'alors.

Cela vaut pour le «courage», qui n'est qu'une valeur secondaire chez les militaires comme industriels pour lesquels il doit rester inféodé à l'obéissance. Le cinéma entretient la fiction d'un courageux soldat autonome riche d'initiative, en réalité on gagne les guerres contemporaines par la puissance de l'outil de production sous-jacent (cette interdépendance éclairant peut-être la communauté de certaines des vues des industriels et des militaires, de grandes réalisations des premiers découlant de commandes des autres) et par la prédicibilité (donc l'obéissance) plutôt que grâce à des coups d'éclats, certes romantiques mais désordonnés (donc difficiles à exploiter voire s'affaiblissant mutuellement) et locaux.

L'un des défis d'un projet relève de son caractère pluridisciplinaire. Le productivisme (comme, dans une moindre mesure, l'organisation militaire) les résout par l'analytique, en isolant chaque traitement autonome. L'ouvrier vissant le boulon peut tout ignorer hors de sa mission (ce que fait son prédécesseur sur la chaîne de montage, la raison pour laquelle il visse ou celle pour laquelle il doit le faire comme imposé plutôt qu'autrement). Cela ne rend aucune communication nécessaire en régime de fonctionnement normal, où tout est connu. Rien de tout cela n'est transposable à un projet de développement logiciel où l'on connaît mal le problème (objet, moyens, solution...), qui de surcroît évolue vite, donc où les participants doivent communiquer efficacement afin d'éclairer du mal-connu.

Dans un contexte mal maîtrisé procédures et méthodes offrent au mieux un utile pense-bête (checklist, bonnes pratiques...) pendant les travaux (rarement) ou avant/après eux (plus souvent), et par ailleurs laisse de façon illusoire espérer pouvoir "remplacer n'importe qui n'importe quand". Là encore l'évolution des outils révèle clairement cette prise de conscience quant aux ambitions et modalités (comparer Merise à ITIL).

Par ailleurs on sait communiquer à distance de façon confidentielle et sans latence, donc mobiliser ponctuellement un tiers, et le souci de confidentialité implique rarement d'interdire de le faire afin d'éclairer un élément précis, surtout somme toute générique. Autrement dit ce n'est pas parce que durant une guerre et avant l'ère de l'Internet aucune information ne devait sortir d'un centre de recherche qu'il faut croire nécessaire de constituer une équipe projet complètement autonome et isolée.

Effectif d'un projet

Dans une équipe trop étoffée l'utilité apparente (résultat tangibles fournis) de certains participants semble faible, cela déçoit («on n'avance pas»), puis un cercle vicieux nourrissant la démotivation s'instaure.

Cette apparent inutilité doit d'ordinaire beaucoup à des difficultés de communication. Certaines informations nécessaires ne sont pas bien prises en compte car ne sont pas disponibles ou comprises, et cela cause des erreurs condamnant à mal faire ou à refaire. Ou bien elles le sont au prix d'un effort voire gâchis démesuré (« on passe son temps en rédaction et lecture, ainsi qu'en réunions dont chacun n'obtient que peu d'informations pour lui utiles »).

Tout cela érode rendement donc motivation.

Dans un projet sain chacun en sait toujours assez pour agir adéquatement et efficacement, toutefois tenter d'informer tout le monde de tout et s'assurer que chacun comprend serait vain.

Projet efficace

Un développement progresse bien et vite si des participants de cultures diverses se comprennent vite et bien.

C'est un défi majeur et aucune méthode ou procédure n'y suffit, à moins d'être exhaustive et bien appliquée par tous.

Bien appliquer une méthode rigoureuse est difficile donc ne pas espérer que tous les participants y atteindront on qu'une intermédiation assurée par quelques-uns y suffira. Pour profiter de Merise il faut devenir Merisien, ce qui exige de nombreux jours de travail dont la rentabilité n'est pas d'emblée apparente.

Cela explique la disparition de ces méthodes ambitieuses (car guidant l'analyse), surtout au sein d'équipes recelant des non-informaticiens, au profit de pense-bêtes bricolés (ITIL en tête) et de simples conventions de notation (en particulier UML), de champ plus restreint car ne contraignant pas à changer de modèle mental, plus faciles à assimiler et forgeant une langue (donc un début de culture) commune.

Chaque membre d'une équipe projet saine:

en sait suffisamment
sait répondre à toute question pertinente ou bien nommer et rapidement contacter un participant qui saura le faire (directement, sans consulter un troisième personne). Corollaire: chacun connaît bien l'ensemble d'un domaine («macro»).
est un humain
latences et distorsions induites par les moyens de communication interdisent d'organiser selon l'analytique, faute de pouvoir détailler des tranches de savoirs chacune bien circonscrite par tout participant tout en les laissant échanger les informations utiles. Corollaire: une équipe ne peut être considérée, en un changement d'échelle, comme un membre d'une plus grosse équipe.

Les corollaires limitent l'effectif d'un projet autonome (interagissant peu avec tout autre) à moins d'une dizaine de membres, 3 à 6 semblant idéal. Zinoviev l'a bien illustré.

Voir aussi à l'arrache.