navigation

Quels indicateurs d’efficience d’un SI ? 11 février, 2010

Posté par dailymanager dans : communication,efficacite,objectif,reporting , ajouter un commentaire

Pour s’y retrouver dans une jungle de chiffres qui peuvent tous donner lieu à des interpretations contradictoires et des débats sans fin, tâchons de les catégoriser par grand domaine de valeur ajoutée d’un Système d’Informations

1- La première catégorie regroupe les tableaux de bord de la fonction système d’information, au sens de l’alignement avec les métiers. Il s’agit d’indicateurs portant sur l’avancement des grands projets, mais aussi la contribution de la DSI à l’innovation, à la gestion des risques, au management des processus, à la relation avec les fournisseurs. Bref, tout ce qui est relatif à un Plan d’Action Stratégique Systèmes d’Information.

2- Le second groupe cible les tableaux de bord de l’IT, au sens des exigences technique. Ils concernent les indicateurs opérationnels liés au fonctionnement et à la continuité du service. Il s’agit par exemple de la disponibilité des applications, les temps de réponse, le nombre d’incidents et leur répartition, les délais moyens de résolution, les mises en production refusées pour non-conformité.

3- En troisième lieu viennent les tableaux de la DSI, au sens de la fonction organisationnelle. On y retrouvera des indicateurs tels que ceux relatifs aux ressources humaines. Ils comprennent en outre les indicateurs liés à la formation et l’expertise des collaborateurs ainsi que la communication avec les utilisateurs à travers les récurrentes enquêtes de satisfaction.

4- Pour finir, nous avons les tableaux de bord de suivi des budgets, au sens du bilan financier. Ils vont du suivi de la facturation jusqu’au recouvrement des prestations, de la maîtrise et de la linéarité des budgets.

(librement inspiré de la méthode Gimsi, qui sépare Stratégie, Technologie, Hommes et Structure)

Selon chaque culture d’entreprise, de par la relation établie entre les métiers et la DSI, certains domaines sont plus surveillés que d’autres. Au cours de mes missions, j’ai pu observer un attachement classique aux exigences techniques (2) via une faible tolérance aux incidents de la part des métiers (justifiée ou non). J’ai également constaté que dans certains cas, la présence d’une justification de type stratégique (1) suffisait à masquer tous les autres indicateurs financiers (4). Enfin, la fonction organisationnelle (3) est souvent le parent pauvre des indicateurs. Des jeux de pondération qu’il convient de manier avec prudence et qui ne durent pas bien longtemps.

Mais celui que ne pilote que par les indicateurs, fussent-ils prospectifs, risque de rencontrer quelques déboires. La crise peut être considérée comme une opportunité par les DSIs pour accélérer leur repositionnement en mettant en valeur leur apport potentiel à la valeur ajoutée par le biais d’exemples précis et parlants. Réussir dans cette démarche est complexe, car cela implique  transparence et relation équilibrée dans une logique de collaboration entre métiers et DSI.  Ce que ne cherchent pas toujours les autres directions qui peuvent préférer privilégier un niveau de  domination à travers leur rôle de commanditaire reléguant de facto la fonction SI à un centre de coûts.

Jean-Pierre Corniou [ex-DSI de Renault] décrivait très bien ce phénomène à travers une formule lapidaire : « Individualiser les coûts [sur la DSI] mais collectiviser les gains [du côté des métiers] »

La recherche des bons indicateurs est donc une quête du Graal qui va suivre un nouveau chapitre du fait de la tension des exigences dans un contexte de crise. L’efficience du SI passe à nouveau à la loupe.

Le ROI déchu ? 7 février, 2010

Posté par dailymanager dans : objectif,projet , ajouter un commentaire

Le retour sur investissement (ROI) est un des indicateurs clefs permettant aux décideurs et investisseurs de savoir si un projet en vaut la chandelle.

Purement financier, il est calculé à partir de la moyenne pondérée du coût des capitaux propres et de l’endettement net relatif au projet, soit l’investissement, auquel s’ajoutent les gains attendus, soit la trésorerie nette dégagée annuellement. Le ROI vise à s’assurer de la rentabilité financière d’un projet.

Il faut dire que d’un point de vue financier, l’indicateur est séduisant, reléguant ainsi la décision et son risque dans une formule de calcul. Mais si le ROI a séduit les directions générales et les DSI qui l’intègrent explicitement dans leurs contrats de prestation de services, en informatique, son calcul est plus discutable, tenant autant aux spécificités métiers des systèmes d’informations qu’à des difficultés de communication.
L’informatique reste un support au service des autres département, et dans cette dépendance, des coûts et des bénéfices cachés sont déjà difficile à percevoir, alors quant à chiffrer… Ces masques dépendent de chaque spécificité métier, par exemple, des coûts d’appréhension des utilisateurs, ou des bénéfices de satisfaction client et d’image… et de la qualité, l’évolutivité, cette notion difficile à chiffrer au delà du strict coût financier de maintenance d’un système.

Signe des temps, alors que l’indicateur a été mis en avant pour la promotion des nouvelles technologies et de l’e-commerce en particulier, le ROI est maintenant désaffecté par les Directions des Services Informatiques. Les experts y voient une difficulté de communication, car si l’on voit facilement l’investissement, le coté gain peine à être chiffrer quand il ne s’agit pas d’une prise de nouveau marché. Si le vrai retour sur investissement est à trouver coté utilisateurs, la DSI ne dispose pas toujours de toutes les données financières lui permettant de calculer le retour sur investissement, comme le coût du personnel et la valeur des amortissements.

Sans rentrer dans les cas particuliers, la typologie des projets influence beaucoup le mode de calcul, à tel point qu’il est rapidement impossible de comparer deux indicateurs ROI entre eux. Projets réglementaires, projets stratégiques, projets innovants… alors que de l’autre coté, projets techniques ou projets de processus se prêtent bien au jeu du calcul car on maîtrise l’ensemble des paramètres.

Autre facteur de limitation du ROI, son absence de pertinence en dehors du strict contexte d’une entreprise. La dépense correspond à ce que la DSI met en oeuvre, les écarts entre différentes cultures d’entreprise rendent la comparaison inutile : l’unité d’oeuvre n’est pas sécable du processus de gestion auquel elle est associée. En d’autres termes, on peut arrivre à la conclusion qu’une projet n’est pas viable alors que c’est la gestion de projet qui fait défaut qui coûte trop cher.

En avant vente ou en pré étude, si le calcul du ROI est déjà très discutable, il faut aussi reconnaître que son calcul à posteriori n’a guère plus de valeur. Le retour d’expérience constate souvent son incapacité à dissocier  l’ensemble des paramètres impactés par un nouveau produit informatique. En cas de progression des ventes après la mise en place d’une nouvelle application, il est difficile de mettre en avant le système d’information : la réussite sera attribuée aux vendeurs… et ce débat peut devenir très vite conflictuel au sein d’un comité de direction.

Force est de constater que le ROI ne permet pas de saisir réellement ce que le système d’information apporte aux métiers. Il reste un indicateur, mais au sens péjoratif du terme… si tant est qu’on considère par exemple un vrai KPI mesurable comme un indicateur « noble ».

Le ROI déchu ? dans objectif roi

Dorénavant, comme toute gouvernance et toute communication repose sur la présence d’indicateur fiables, le ROI est de plus en plus substitué par de multiples indicateurs qualitatifs, notamment sur des projets spécifiques où l’informatique s’inscrit dans un chantier plus vaste.

Pour prendre en compte les coûts et les bénéfices cachés, il convient en effet d’élargir la vision de l’indicateur purement financier à un aspect plus large, capable de prendre en compte la valeur ajoutée que le projet informatique va apporter à l’entreprise. Il faut pour cela travailler main dans la main avec les directions métiers : études de satisfaction, niveau de prestation de service, et surtout, maintenabilité et agilité du système. (*)

L’objectif est dans la majorité des cas, de rester agile malgré la croissance des systèmes. Une impulsion pour des usines de développement rapide d’applications, de gestion de projets et de métrologie.

D’où l’importance de normer, d’apprécier le coût de l’outillage informatique des processus métier, et de mesurer l’évolution de ce coût dans le temps. Mais force est de constater que nos dirigeants raisonnent beaucoup en terme de business unit et hiérarchie fonctionnelle, et ont encore du mal à entrer dans une logique orientée processus, plus transverse.

 

En savoir plus : http://fr.wikipedia.org/wiki/Retour_sur_investissement

http://solutionspme.lemondeinformatique.fr/articles/lire-le-retour-sur-investissement-est-plus-qu-un-simple-calcul-90.html

 

(*) Une stratégie se déclinant en objectifs et parfois en intéressement, pour favoriser le maintien des performances, les ingénieurs d’Orange bénéficient d’une une part variable indexée sur les résultats ainsi relevés. La supervision de la qualité de service repose un suivi de la performance informatique des systèmes, comme un temps de réponse en fonction de la criticité d’un bogue, combiné à des sondages réalisés auprès des clients finaux.

Super Manager 5 février, 2010

Posté par dailymanager dans : contexte,encadrement , ajouter un commentaire

Super Manager dans contexte 2107dansmonbureau

Bonnne année 2010 21 janvier, 2010

Posté par dailymanager dans : biblio , ajouter un commentaire

Un début d’année étant souvent synomyme de « bonnes résolutions », pour vous aider à construire les vôtres, je vous propose de parcourir ces excellents posts du néanmoins excellent F. John Reh :

http://management.about.com/cs/yourself/a/newyearsres1200.htm

http://management.about.com/cs/yourself/a/ToDoList1002.htm

Prenez ces liens comme deux points d’entrée sur un blog très riche et très instructif.

En savoir plus : http://management.about.com/

Nécessité opérationnelle 1 janvier, 2010

Posté par dailymanager dans : contexte,efficacite,encadrement,operations , ajouter un commentaire

En prenant les rennes de EADS, on rapporte que Louis Gallois se serait exclamé : « comment une telle organisation peut elle faire voler des avions ? » Il faut dire qu’en matière de pilotage, cette entreprise à deux têtes ressemble plus à un montage politique qu’un attelage opérationnel. Et c’est parce qu’il ne faut donc pas chercher à la tête la lien directe du succès de cette entreprise de haute technologie.

Sur le terrain peut opérer un facteur supplémentaire, souvent caché ou inconscient, qu’on nommera la nécessité opérationnelle. Il s’agit de ce surplus d’énergie et de motivation qu’un membre d’un équipe va soudain déployer pour mener à bien un projet pendant les phases à haut risque, et notamment juste avant qu’il rentre dans le mur.

Cette force n’est pas facile à appréhender d’un point de vue extérieur : quand il faut passer dans le concret, il n’y a que les personnes de terrain, qui, finalement, savent ce qu’il faut faire et comment le faire rapidement. Dans ce cadre, c’est sur le dernier maillon opérationnel qu’on transmet la mission opérationnelle et la charge qui en résulte.

Dès lors, pour ce dernier maillon, qui devient de plus en plus critique, il devient une nécessité que les choses se passent opérationnellement le mieux possible, menant à bien le projet sur les quelques mètres du danger. Sur ces derniers mètres, il y a le livrable et sa qualification, ultime étape du projet : auparavant on aurait pu cacher ou se tromper sur l’avancement, mais dans les derniers mètres, c’est du concret et du factuel. C’est la nécessité opérationnelle qui prend alors le contrôle des opérations. Déploiement d’heures supplémentaires, pilotage direct des équipes, centralisation et reformalisation des informations, ce maillon peut alors court-circuiter certains processus organisationnels s’accaparant alors, par nécessité, certains rôles qui n’étaient pas les siens, avec la charge et la rancoeur qui va avec. Paradoxalement  d’ailleurs dans le domaine professionnel, cette prise de pouvoir est acceptée par l’ensemble des autres acteurs, qui, il faut bien le dire, font ainsi aveu d’impuissance temporaire. Encore faut il s’en rendre compte, car cet aveu est temporaire : la reprise en main et  la négation de cette épisode suivra très rapidement.

Mais comment la nécessité opérationnelle est elle déclenchée ? La question de la motivation est la plus difficile à résoudre. Comment cette ressource critique peut il opérer dans les faits ? Pourquoi ce déploiement volontaire et spontané d’une telle énergie ? Contrairement aux principes de la pyramide de Maslow, ce n’est pas une raison bassement matérielle (pas de prime à miroiter) ou de besoin de sécurité (pas de menace de licenciement) ou de besoins sociaux (pas de promotion au mérite) mais peut être un simple besoin d’estime (légitimité par le respect) ou d’accomplissement personnel (conscience professionnelle). Les managers sont plutôt les premiers surpris et les premiers à freiner : même si,  finalement, ils ne renoncent pas aux objectifs qu’ils ont donnés. De plus, les autruches, qui, temporairement, ont plongé la tête dans le sable le temps que la crise passe, ne tarderont pas à ressortir leur bec. La motivation n’est donc pas un calcul comme un ROI : l’opérationnel impliqué ne se fait, en général, aucune illusion sur la reconnaissance de son travail. C’est pour lui une nécessité et non pas une opportunité. Et si on constate une relative usure, il faut bien reconnaître que à la prochaine crise, il replongera, presque par réflexe : parce qu’il faut bien que quelqu’un fasse ce qu’il faut faire !

Handicapés de l’amélioration 5 décembre, 2009

Posté par dailymanager dans : contexte,histoire , ajouter un commentaire

Les deux précédents articles que j’ai publié (Signaux d’alertes ; Partir en beauté) sont deux points de départs d’une constatation que je formule d’une manière volontairement radicale : l’entreprise est incapable d’amélioration continue dans sa conduite de son management. Apprendre, c’est admettre, reconnaître ses erreurs, les comprendre et en tenir compte. C’est le principe élémentaire de l’amélioration continue, principe dont les vertus ne sont plus à démontrer, tant les entreprises ont intégré les retours d’expérience dans leurs processus. Intégré ? Pas complétement, car cela s’applique essentiellement aux opérateurs des processus, mais jamais aux pilotes de ces processus.

Dans l’incapacité de détecter les signaux précurseurs d’un départ, puis dans l’incapacité de connaître les raisons d’une démission, le management n’est pas capable de reconnaître ses erreurs et d’en améliorer son fonctionnement. Il existera toujours des causes extérieures à un départ, une meilleure offre, une raison familiale, une envie de changement, ce sont les motifs exprimés en premier. On cachera les autres causes, plus polémiques et conflictuelles. Il faut bien reconnaître que celui ou celle qui part a déjà abandonné la partie. Nul n’ignore que les absents ont souvent tort, et que les sifflement d’oreilles ne tardent pas longtemps. Dans ce contexte, déclencher un conflit juste avant de s’absenter est le meilleur moyen d’avoir globalement tort.

Récemment, j’ai découvert la pratique de l’entretien de départ. Une sorte d’entretien d’embauche à l’envers. C’est à mon sens, un début de vertu de l’amélioration continue, mais l’exercice reste très périlleux. Règlement de compte à éviter, il faut l’aborder à la manière d’un retour d’expérience, et aborder les points positif pour crédibiliser la présence de points négatifs. Bref, un exercice de formalisation des plus difficiles et des plus stérile, que bien peu aborderont avec sérieux : après tout, vous partez parce que les choses ne se sont pas améliorées, à quoi bon faire mieux après votre départ .

L’incapacité de faire un REX (retour d’expérience) est un handicap qui ralentit l’amélioration des pratiques managériales. L’actualité récente a montré que certaines pratiques peuvent mener à des actes radicaux et irréversible, mais même là, la prise de conscience reste difficile, du moins en terme de communication. Si de tels actes désespérés avaient pour but de faire passer un message, comme l’interprête volontiers la presse, alors on peut se demander comment il y a pu avoir une telle sourde oreille.

Après avoir lu plusieurs comptes rendus de réunions entre direction et représentants du personnel, l’exercice mélangé de négation des problèmes et de communication positive est auto intoxicant. Même si la situation est flagrante et reconnue de tous comme problématique, plutôt que de nier qu’il peut y avoir des problèmes et des conséquences, la direction niera en avoir entendu parlé ou niera avoir eue l’alerte de manière formalisée. Cette négation est alors l’aveu institutionnel d’un handicap d’amélioration.

 

Signaux d’alertes

Posté par dailymanager dans : contexte,histoire , ajouter un commentaire

En général quand les couches de frustrations commencent à s’accumuler, l’employé n’est pas loin de donner sa démission. Il va à quelques reprises sonner l’alarme mais, si personne ne répond, il va de plus en plus se diriger vers la porte de sortie. Même si l’on est en période de crise, certains profils ne courent pas les rues. Quand on a de bons salariés, mieux vaut tout faire pour les retenir. Voici donc les 7 raisons principales qui font qu’un employé donnera sa démission :

  1. Job et conditions de travail ne sont pas celles qui étaient attendues : le recrutement a été mal effectué et le candidat va sûrement partir dans les 6 mois.
  2. Inadéquation entre le job et la personne : la personne ne se sent pas à l’aise dans son job. Elle a surestimé certaines de ses compétences.
  3. Trop de peu de feedback et de coaching : les employés sont livrés à eux-mêmes et ne parviennent pas à s’améliorer ou à s’aligner avec l’organisation. Ils ne peuvent bénéficier d’aucune aide concrète leur permettant de s’améliorer et d’apprendre. Le management ne prend pas le temps de justifier ses décisions. Il rejette ou ignore un travail sans en donner d’explication, se croyant tout puissant et laissant la personne dans un flou faisant diminuer son estime d’elle-même. Donner du feedback, c’est aider à comprendre et à s’améliorer.
  4. Trop peu de possibilités de croissance et d’avancement : pas de prise en compte de la croissance du salarié sur le long terme. Pas de visibilité lui permettant de définir des projets avec l’entreprise.
  5. Sentiment d’être dévalué et non reconnu : ils se sentent invisibles, leurs idées ne sont pas prises en compte. Ils n’ont pas l’autonomie et le respect qu’ils souhaitent. L’entreprise focalise sur les projets mais non sur les hommes. Les gens veulent se sentir importants et sentir que leur entreprise a besoin d’eux pour réussir. S’ils ne sont pas justement reconnus pour leur travail, ils vont avoir l’impression que ce qu’ils font n’a pas d’importance. Le salaire n’est pas en adéquation avec la charge de travail demandée.
  6. Stress créé par un manque d’équilibre entre vie professionnelle et vie privée : charge de travail, conflits internes, pas de travail d’équipe, travail demandé pendant le week-end ou à des heures tardives.
  7. Perte de confiance dans la hiérarchie : des managers peu intègres, impossibles à approcher, sans vision, qui ne communiquent pas. Des managers qui prennent des décisions de façon arbitraire ou qui micro-managent et se sentent tout puissants au point d’écraser leur équipe et de ne la considérer que pour l’exécution.

Manager, c’est avant tout manager des hommes. Ceux qui n’ont pas de sensibilité pour les autres devraient d’abstenir d’être à de tels postes. En tant que manager, il est important de connaître ses employés, de chercher à comprendre leurs différences et surtout ce qui les fait avancer (certains recherchent le salaire, d’autres la formation, d’autres la promotion). Avant d’avoir une équipe efficace, il faut apprendre à connaître ses hommes afin d’obtenir le meilleur d’eux-mêmes. Les besoins principaux à considérer sont les suivants :

Si certains avaient oublié certains de ces principes il serait temps de vite se les remettre en tête car crise ou pas crise, les salariés peuvent démissionner et on en voit tous les jours changer d’entreprise.

 Extrait de : http://blog.netpme.fr/2009/06/26/7-raisons-qui-font-demissionner-un-salarie/

Partir en beauté

Posté par dailymanager dans : contexte,histoire , ajouter un commentaire

Un article de Management, Avril 2008

Partir en beauté dans contexte managementavril08

L’article PDF complet en cliquant dessus !

En savoir plus : http://www.jequittemaboite.fr/index.php?id=146

1968 : Loi de Conway 23 novembre, 2009

Posté par dailymanager dans : amelioration,changement,histoire,risques , ajouter un commentaire

Loi de Conway est un adage du nom de programmeur informatique Melvin Conway, qui a introduit l’idée en 1968:

« Les organisations qui conçoivent les systèmes … sont contraintes de produire des modèles qui sont des copies de leur propre structure de communication »

La droit de Conway peut être illustrée et simplifiée comme suit : deux modules logiciels A et B ne peuvent pas correctement s’interface l’un avec l’autre, à moins que le concepteur de l’implémentation de A communique avec le concepteur et exécutant de B. Ainsi, la structure d’un système logiciel en tant que qu’intégration de composants va se montrer révélateur de la structure sociale de l’organisation qui l’a produit.

Exemples de loi de Conway
Considérer un grand système S que le gouvernement veut construire. Le gouvernement engage la société X pour construire le système S. La société X possède trois groupes d’ingénierie, E1, E2 et E3, qui participent au projet. La loi de  Conway donne à penser qu’il est probable que le système se composera de 3 principaux sous-systèmes (S1, S2, S3), chacun construit par l’un des groupes d’ingénierie. Plus important encore, les interfaces qui en résultent entre les sous-systèmes (S1-S2, S1-S3, etc) reflète la qualité et la nature de la communication interpersonnelle entre les groupes d’ingénierie respectives (E1-E2, E1-E3, etc.)

Un autre exemple: soit une équipe de deux personnes d’ingénieurs logiciels, A et B. Supposons que A conçoive et développe une classe de logiciels X. Plus tard, l’équipe découvre que la classe X a besoin de quelques nouvelles fonctionnalités. Si A ajoute les fonctionnalités, A est susceptible d’étendre simplement X pour inclure les nouvelles fonctionnalités. Si B ajoute les nouvelles fonctionnalités, B ne prendra pas de risque de régression sur X, et donc à la place va créer une nouvelle classe X2 dérivée de X, héritant de caractéristiques X, et portera les nouvelles fonctionnalités dans X2. Donc, dans cet exemple, le plan final est le reflet de l’organisation opérationnelle qui a mis en œuvre la fonctionnalité.

 

1968 : Loi de Conway dans amelioration climateorbiterbrowse

Mars Climate Orbiter s’est écrasé parce que l’équipe a utilisé des unités des États-Unis d’usage (par exemple, pouces, pieds et livres) tandis que d’autres unités de mesure ont été utilisées par une équipe sur des composants périphériques. Cette information était essentielle pour les manœuvres de placement de la sonde sur son orbite de Mars. «Les gens font parfois des erreurs», a déclaré le Dr Edward Weiler, administrateur associé de la NASA pour les sciences spatiales. «Le problème ici n’est pas l’erreur, il a été l’échec de l’ingénierie des systèmes de la NASA, ainsi que les contrôles dans nos processus afin de détecter l’erreur. C’est pourquoi nous avons perdu le vaisseau spatial.»

 

Il existe des preuves de la loi de Conway qui ont été publiées par une équipe de chercheurs de Harvard Business School. Leur étude révèle des différences significatives dans la modularité des architectures : les équipes distribuées ont tendance à développer plus de produits modulaires.

Cette loi peut être interprétée comme humoristique, dans la mesure où les organisations rigides qui ne sont pas disposés à se ré-organiser pour produire une conception optimale, peuvent finir par produire un sous-design standard qui ne fait que refléter l’organisation pré-existante. Mais l’essence de la loi de Conway s’applique aussi aux organisations flexibles qui sont prêts à ré-organiser pour produire une conception optimale.

Par exemple, considérons une entreprise flexible qui est chargé de concevoir une voiture, et l’entreprise ne dispose pas encore d’organisation d’une voiture de conception. La conception de la nouvelle organisation sera vraisemblablement composée de groupes qui correspondent aux principales composantes d’une voiture: moteur, le corps, la transmission, intérieur, électriques, etc.
L’essence du droit de Conway s’applique même à cette réorganisation: les composants et les interfaces de la voiture qui en résultent reflètent les groupes d’ingénierie et de leurs interfaces.

Et, fait significatif, tout manquement aux relations interpersonnelles entre les groupes d’ingénierie, se manifestera d’une lacune de la conception qui en résultent.

En savoir plus : http://en.wikipedia.org/wiki/Conway%27s_Law

1979 : Loi de Hofstadter

Posté par dailymanager dans : efficacite,encadrement,histoire,operations , ajouter un commentaire

La loi de Hofstadter (ou Loi de glissement de planning) est une loi empirique concernant la difficulté de la planification dans le domaine de la recherche et du développement. Elle est typiquement constatée dans la gestion de développements logiciels.

La loi de Hofstadter déclare que :

« Ça prend toujours plus de temps qu’on croit, même en prenant en compte la loi de Hofstadter. »

Cette loi a été énoncée par l’universitaire américain Douglas Hofstadter dans son oeuvre-phare, Gödel, Escher, Bach, les brins d’une guirlande éternelle (Gödel, Escher, Bach: An Eternal Golden Braid[1]) (1979, Prix Pulitzer en 1980). Derrière une formulation facétieuse, la loi de Hofstadter rend compte d’une difficulté universelle : il est pratiquement impossible de prévoir le temps qui sera nécessaire à l’accomplissement d’une tâche complexe. Cette impossibilité est mise en exergue par le caractère auto-référentiel de la phrase qui se cite elle-même : de ce fait, elle introduit l’imprédicativité ou « raisonnement en boucle ».

Dans les développements informatiques les méthodes agiles prétendent prendre en compte la difficulté évoquée par la loi de Hofstadter.

En savoir plus : http://en.wikipedia.org/wiki/Hofstadter%27s_law

12345...14

sitehgeo4 |
"L'arbre qui tombe peut fai... |
Dra. Monica Guia |
Unblog.fr | Créer un blog | Annuaire | Signaler un abus | citoyen
| Petite écologie d'un insect...
| SonyaT