Page 1

L'art de la gestion de projet

Par Scott Berkun
...............................................
Editeur: O'Reilly
Date de publication: Avril 2005
ISBN: 0-596-00786-8
Pages: 392

Table des matières | Index

«L'art de la gestion de projet» couvre tout - à partir de méthodes pratiques pour faire en sorte travail devient
bien fait et à temps, à l'état d'esprit qui peut vous un grand chef motiver votre équipe pour faire
faire de leur mieux. La lecture de cette lecture était comme le modèle pour la façon dont les meilleurs projets sont gérés au
Microsoft ... Je souhaite que nous mettons toujours ces leçons en pratique! "--Joe Belfiore, directeur général, E-
Division maison, Microsoft Corporation

"Berkun a écrit un rythme rapide, guide gratuit jargon et plein d'esprit à ce qu'il se réfère à bon escient pour que la
«Art» de la gestion de projet. Il est une excellente introduction à la discipline. Assaisonné et nouvelle
les gestionnaires bénéficieront des perspectives de Berkun ".
--Joe Mirza, Directeur, CNET Networks (Cnet.com)

"La plupart des livres avec de la gestion de projet 'les mots dans le titre sont tomes sèches. Si cela est ce que vous êtes
attendant d'entendre le livre de Berkun, vous serez agréablement surpris. Bien sûr, il est sur ​le projet
gestion. Mais il est aussi sur la créativité, la situation de résolution de problèmes, et le leadership. Si vous êtes un
membre de l'équipe, chef de projet, ou même une partie prenante non technique, Scott propose des dizaines de
des outils pratiques et des techniques que vous pouvez utiliser, et les questions que vous pouvez demander, pour assurer vos projets
réussir ».
--Bill Bliss, vice-président principal du produit et de l'expérience client, expedia.com

Dans l'art de la gestion de projet, vous allez apprendre à partir d'un gestionnaire vétéran de logiciels et web
développement à planifier, gérer et diriger des projets. Ce compte personnel de dures leçons apprises
plus d'une décennie de travail dans l'industrie distille des concepts et des défis complexes en pratique
pépites de conseils utiles. Inspirer, drôle, honnête et convaincante, ce livre est que vous et votre
équipe ont besoin d'avoir à portée de bras. Il vous sera bien utile avec votre travail actuel, et sur ​l'avenir
les projets à venir.

Les sujets traités comprennent:

Comment faire bouger les choses

Prendre de bonnes décisions

Spécifications et exigences

Idées et quoi faire avec eux

Comment ne pas ennuyer les gens

Leadership et la confiance

La vérité au sujet de faire des dates

Que faire quand les choses tournent mal

Page 2
 L'art de la gestion de projet
Par Scott Berkun
...............................................
Editeur: O'Reilly
Date de publication: Avril 2005
ISBN: 0-596-00786-8
Pages: 392

Table des matières | Index

Droit d'auteur
Préface
Qui devrait lire ce livre
Hypothèses je ai fait de vous en écrivant ce livre
Comment utiliser ce livre
Chapitre un. Une brève histoire de la gestion de projet (et pourquoi vous devriez soins)
Section 1.1. Utiliser l'historique
Section 1.2. développement Web, cuisines, et les salles d'urgence
Section 1.3. Le rôle de la gestion de projet
Section 1.4. Programme et de la gestion de projet à Microsoft
Section 1.5. L'acte d'équilibrage de la gestion de projet
Section 1.6. Pression et la distraction
Section 1.7. Le bon type d'implication
Section 1.8. Résumé
Partie I: Plans
Chapitre deux. La vérité sur les horaires
Section 2.1. Horaires ont trois objectifs
Section 2.2. Balles et des méthodologies d'argent
Section 2.3. Qu'est-ce que les horaires ressembler
Section 2.4. Pourquoi horaires échouent
Section 2.5. Ce qui doit arriver pour les horaires de travail
Section 2.6. Résumé
Chapitre trois. Comment comprendre ce qu'il faut faire
Section 3.1. la planification du logiciel démystifié
Section 3.2. Plans qui approchent: les trois points de vue
Section 3.3. Le point de vue interdisciplinaire magique
Section 3.4. Poser les bonnes questions
Section 3.5. Catalogue de mauvaises manières communes de décider ce qu'il faut faire
Section 3.6. Le processus de planification
Section 3.7. la recherche de la clientèle et de ses abus
Section 3.8. Rassembler tous les éléments: exigences
Chapitre Quatre. Rédaction de la bonne vision
Section 4.1. La valeur des choses d'écriture vers le bas
Section 4.2. Combien de vision avez-vous besoin?
Section 4.3. Les cinq qualités de bonnes visions
Section 4.4. Les points clés à couvrir
Section 4.5. Sur bien écrire
Section 4.6. Rédaction, révision et la révision
Section 4.7. Un catalogue des énoncés de vision boiteux (qui devrait être évité)
Section 4.8. Des exemples de visions et objectifs
Section 4.9. Visions devraient être visuel
Section 4.10. Le chèque vision de la santé mentale: le culte quotidien
Section 4.11. Résumé

Page 3

Chapitre Cinq. Où les idées viennent de

Section 5.1. L'écart des exigences à des solutions
Section 5.2. Il ya de mauvaises idées
Section 5.3. Penser dans et hors de boîtes est OK
Section 5.4. Les bonnes questions attirent de bonnes idées
Section 5.5. Les mauvaises idées mènent aux bonnes idées
Section 5.6. Perspective et l'improvisation
Section 5.7. L'expérience client commence la conception
Section 5.8. Une conception est une série de conversations
Section 5.9. Résumé
Chapitre Six. Que faire avec les idées une fois que vous les avez
Section 6.1. Idées deviennent hors de contrôle
Section 6.2. Gestion des idées exige une main ferme
Section 6.3. Les points de contrôle pour les phases de conception
Section 6.4. Comment consolider les idées
Section 6.5. Prototypes sont vos amis
Section 6.6. Questions pour itérations
 Section 6.7. La liste des questions ouvertes
Section 6.8. Résumé
Partie II: Compétences
Chapitre Sept. Ecrire de bons spécifications
Section 7.1. Quelles sont les spécifications peuvent et ne peuvent pas faire
Section 7.2. Décider quoi spécifier
Section 7.3. Spécification ne conçoit
Section 7.4. Qui, quand, et comment
Section 7.5. Quand les spécifications complète?
Section 7.6. Avis et commentaires
Section 7.7. Résumé
Le chapitre huit. Comment prendre les bonnes décisions
Section 8.1. Dimensionnement jusqu'à une décision (ce qui est en jeu)
Section 8.2. Trouver et pesant les options
Section 8.3. L'information est une lampe de poche
Section 8.4. Le courage de décider
Section 8.5. Prêter attention et regarde en arrière
Section 8.6. Résumé
Chapitre Neuf. Communication et relations
Section 9.1. Gestion par la conversation
Section 9.2. Un modèle de base de la communication
Section 9.3. Problèmes de communication commune
Section 9.4. Projets dépendent relations
Section 9.5. La meilleure attitude de travail
Section 9.6. Résumé
Chapitre Dix. Comment ne pas ennuyer les gens: le processus, le courriel et réunions
Section 10.1. Un résumé de pourquoi les gens se fâchent
Section 10.2. Les effets de bon processus
Section 10.3. E-mail non-gênant
Section 10.4. Comment faire pour exécuter la réunion non-gênant
Section 10.5. Résumé
Chapitre Onze. Que faire quand les choses tournent mal
Section 11.1. Appliquer l'indicatif
Section 11.2. Situations communes à attendre
Section 11.3. Prendre la responsabilité
Section 11.4. Limiter les dégâts
Section 11.5. La résolution des conflits et la négociation
Section 11.6. Rôles et une autorité claire
Section 11.7. Une trousse émotionnelle: la pression, les sentiments sur les sentiments et le complexe du héros

Page 4

Section 11.8. Résumé

Partie III: Gestion
Chapitre Douze. Pourquoi le leadership est basé sur la confiance
Section 12.1. Bâtiment et de la confiance de perdre
Section 12.2. Faire confiance clair (créer des lumières vertes)
Section 12.3. Les différents types de pouvoir
Section 12.4. Faire confiance aux autres
Section 12.5. La confiance est l'assurance contre l'adversité
Section 12.6. Modèles, questions et conflits
Section 12.7. erreurs de fiducie et de faire
Section 12.8. La confiance en vous-même (auto-suffisance)
Section 12.9. Résumé
Chapitre treize. Comment faire bouger les choses
Section 13.1. Priorités faire bouger les choses
Section 13.2. Les choses arrivent quand vous dites pas
Section 13.3. Keeping it real
Section 13.4. Connaître le chemin critique
Section 13.5. Soyez implacable
Section 13.6. Soyez avertis
Section 13.7. Résumé
Chapitre quatorze. Stratégie-jeu Moyen-
Section 14.1. Vol en avant du plan
Section 14.2. Agir en toute sécurité
Section 14.3. Le pipeline de codage
Section 14.4. Frapper des cibles mobiles
L'article 14.5. Résumé
Chapitre Quinze. La stratégie de fin de jeu
Section 15.1. Big délais sont juste quelques petits délais
Section 15.2. Éléments de mesure
Section 15.3. Eléments de contrôle
Section 15.4. La fin de la fin du jeu
 Section
Section 15.5.
15.6. Party
Résumétime
Chapitre seize. Pouvoir et la politique
L'article 16.1. Le jour où je suis devenu politique
Section 16.2. Les sources d'énergie
Section 16.3. L'abus de pouvoir
Section 16.4. Comment résoudre les problèmes politiques
Section 16.5. Connaître les règles du jeu
Section 16.6. Résumé
Remarques
Chapitre un
Chapitre deux
Chapitre Trois
Chapitre Quatre
Chapitre Cinq
Chapitre Six
Chapitre Sept
Chapitre Huit
Chapitre Neuf
Chapitre Dix
Chapitre Onze
Chapitre Douze
Chapitre treize
Chapitre quatorze
Chapitre quinze

Page 5

Seize Chapitre
Bibliographie annotée
Philosophie et stratégie
Psychologie
Histoire
La gestion et la politique
Science, l'ingénierie et l'architecture
processus de logiciel et de la méthodologie
Remerciements

Crédits photos
Colophon
A propos de l'auteur
Colophon
Index
Page 6

L'art de la gestion de projet

par Scott Berkun

Copyright © 2005 O'Reilly Media, Inc.

Tous droits réservés.

Imprimé aux Etats-Unis d'Amérique.

Publié par O'Reilly Media, Inc.,

1005 Gravenstein autoroute Nord

Sebastopol, CA 95472.

Livres O'Reilly peuvent être achetés pour l'éducation, les affaires, ou l'utilisation de promotion des ventes. Éditions en ligne
sont également disponibles pour la plupart des titres (safari.oreilly.com). Pour plus d'informations, contactez notre
département corporate / des ventes institutionnelles: (800) 998-9938 ou corporate@oreilly.com.

Éditeur: Mike Hendrickson

Directrice de la production: Marlowe Shaeffer
MENDEDESIGN,
Cover Designer:
www.mendedesign.com
Décorateur d'intérieur: Marcia Friedman
Directeur artistique: Michele Wetherbee
Histoire Impression: Avril 2005:
Première édition.

Le logo O'Reilly est une marque déposée de O'Reilly Media, Inc. Un grand nombre des designationsused par
les fabricants et les vendeurs pour distinguer leurs produits sont des marques déposées. Où ceux
apparaissent dans ce livre, et O'Reilly Media, Inc. était au courant d'une revendication de la marque, la
désignations ont été imprimés est en majuscule initiale.

Bien que toutes les précautions ont été prises dans la préparation de ce livre, l'éditeur et l'auteur
assumer aucune responsabilité pour les erreurs ou omissions, ou pour les dommages résultant de l'utilisation de la
renseignements contenus aux présentes.

ISBN: 0-596-00786-8

[C] [7/05]

Page 7
 Préface

Mon mot préféré dans la langue anglaise est de savoir comment. Comment cela marche-t-il? Comment était-ce fait?
Comment ont-ils fait cela? Chaque fois que je vois quelque chose d'intéressant arrive, je suis rempli de questions qui
impliquer cette petite mais puissante petit mot. Et la plupart des réponses, je trouve le centre sur la façon dont les gens
appliquer leur propre intelligence et la sagesse, plutôt que de leur connaissance des technologies spécifiques ou
théories.

Au cours des années de construire des choses et en comparant mes expériences à celles des autres gestionnaires,
les programmeurs et les concepteurs, je ont développé des croyances et des conclusions sur la façon de gérer des projets
bien. Ce livre est une sommation de ces idées. Il comprend des approches pour diriger des équipes, travailler
avec des idées, organiser des projets, la gestion des horaires, portant sur ​la politique, et de faire les choses
arriver, même dans le visage de grands défis et des situations injustes.

Malgré le large titre de ce livre, la plupart de mon expérience de travail vient du secteur de la technologie, et
en particulier, Microsoft Corporation. J'y ai travaillé de 1994 à 2003, la direction d'équipes de personnes sur
des projets tels que Internet Explorer, Microsoft Windows et MSN. Depuis quelques années, je travaillais dans
Excellence technique du groupe de Microsoft. Tandis que là, je suis responsable de l'enseignement et de conseil
avec des équipes à travers la société, et a souvent été demandé de faire la leçon à des conférences publiques, des sociétés,
et les universités. La plupart des conseils, des leçons et des histoires dans ce livre proviennent de ces expériences.

Bien que je viens d'un milieu logiciels et web développement, je l'ai écrit ce livre largement
et inclusive, appelant les références et les techniques de l'extérieur de l'ingénierie et de la gestion
domaines. Il est très utile ici pour les gens dans le monde des affaires en général. Je suis convaincu que le
défis de l'organisation, de premier plan, la conception, et de la prestation de travail ont beaucoup en commun, quel que soit
du domaine. Les processus impliqués dans la fabrication de fours grille-pain, gratte-ciel, les automobiles, les sites Web,
et produits logiciels partagent plusieurs des mêmes défis, et ce livre est principalement sur
surmonter ces défis.

Contrairement à d'autres livres sur la façon de mener des projets et des équipes, ce livre ne attribue pas à une grande

Page 8

la théorie ou la philosophie présomption innovante. Au lieu de cela, je l'ai placé mon pari sur l'aspect pratique et
diversité. Je pense que les projets aboutissent à de bonnes choses quand la bonne combinaison de personnes, de compétences,
les attitudes et les tactiques est appliqué, quelle que soit leur origine ou leur (manque de) pedigree. La structure de ce
livre est la plus sensée que je trouvais: se concentrer sur les défis et les situations fondamentales, et de fournir
des conseils sur la façon de les traiter ainsi. Je suis parie fortement sur ​choisir les bons sujets et de donner bonne
conseils sur eux, sur toutes les autres considérations. Je vous souhaite que je l'ai fait le bon choix.
Page 9

Qui devrait lire ce livre

Votre meilleur pari à voir si ce livre est pour vous implique retournement retourner à la table des matières, la cueillette
un sujet qui vous intéresse, et l'écrémage par ce que je dois dire à ce sujet. Je fais généralement pas
la confiance préface beaucoup, et je vous recommande de ne pas non plus; ils ont rarement le même style ou voix
le reste du livre. Mais ici, va de toute façon.

Le livre sera le plus précieux pour les personnes qui se correspondent dans l'un ou plusieurs des éléments suivants
catégories:

Expérimenté chefs d'équipe et les gestionnaires. Ce livre est bien adapté pour tous ceux qui jouent un
rôle de leadership, officiellement ou officieusement, sur tout type de projet. Les exemples sont des logiciels
développement, mais de nombreux concepts appliquent facilement à d'autres types de travail. Vous pourriez être le fonctionnaire
chef d'équipe, ou tout simplement une des personnes les plus expérimentés de l'équipe. Bien que certains de la
thèmes du livre peuvent être très familier pour vous, l'approche directe et pratique du livre
faut de la volonté de vous aider à clarifier et à affiner vos opinions. Même si vous n'êtes pas d'accord avec les points que je fais,
vous aurez une base claire pour travailler contre dans le raffinage et l'amélioration de votre propre point de
vue.

Nouveaux chefs d'équipe et les gestionnaires. Si vous regardez les sujets énumérés dans la table des matières,
vous trouverez un aperçu solide de leaders de tout et gestionnaires sur des projets réellement faire. Chaque
chapitre fournit une couverture des défaillances et des erreurs communes même des gens expérimentés
faire, avec des explications sur pourquoi cela arrive et quelle tactique peut être utilisée pour éviter ou récupérer
d'eux. Le livre vous fournit une vision plus large et la compréhension de la nouvelle
responsabilités que vous avez prises et sur ​les moyens les plus intelligents d'aller sur leur gestion. Car
la plupart des chapitres prennent de grands sujets, ils comprennent souvent des références annotées aux sources les plus profondes.
 Programmeurs et testeurs individuels, ou d'autres contributeurs aux projets. Ce livre
améliorer votre compréhension de ce que vous contribuez à, et quelles approches et des idées
vous pouvez utiliser pour être efficace et heureux de le faire. Si vous êtes déjà demandé pourquoi les projets
changer de direction si souvent ou semblent être mal géré, ce livre vous aidera à comprendre
les causes et les remèdes. Si rien d'autre, la lecture de ce livre vous aidera à cadrer votre
contributions individuelles dans un contexte plus large, et augmenter les chances que votre travail fera une
différence (et que vous allez rester sain d'esprit tout en le faisant). Si vous êtes intéressé par la suite
gérer ou diriger des équipes vous-même, ce livre vous aidera à explorer ce qui va vraiment être comme
et si vous êtes fait pour elle.

Les étudiants de la gestion de l'entreprise, la conception des produits, ou en génie logiciel. Je utilise l
étudiants de mot dans le sens le plus large: si vous avez un intérêt personnel dans ces sujets ou sont
formellement les étudier, ce livre devrait être d'un grand intérêt pour vous. Contrairement à une grande partie de la
la couverture du manuel de ces sujets, ce livre est fortement situation et narrative concentré. La
expériences et des histoires sont réelles, et ils sont à la base des leçons et tactiques: pas le
inverse. Je évite délibérément de dessin des lignes entre les différents sujets académiques
parce que, dans mon expérience, ces lignes ni projets d'aide ni contribuer à la compréhension
la réalité (l'univers ne se divise pas de la même manière les universités ont tendance à être). Au lieu de cela, ce livre
combine la théorie de l'entreprise, la psychologie, la tactique de gestion, les processus de conception, et des logiciels
l'ingénierie de quelque manière nécessaire d'offrir des conseils sur les sujets décrits.

Page 10

Hypothèses je ai fait de vous en écrivant ce livre

Vous n'êtes pas stupide. Je suppose que si je l'ai choisi le bon chapitres et écris-les bien, vous
ne sera pas besoin de moi pour passer du temps lentement construire des cadres élaborés d'information. Au lieu,
Je vais faire le point et de passer du temps là-bas. Je suppose que vous êtes quelque chose d'un peerperhaps avec
plus, moins, ou experiencewho différente a chuté de quelques conseils.

Vous êtes curieux et pragmatique. Je dessine sur des exemples et des références dans de nombreuses disciplines,
et je suppose que vous trouverez la valeur en tirant les leçons de l'extérieur du web et des logiciels
développement. Ce ne sera pas obtenir de la manière, mais les pointeurs pour les esprits curieux fera surface, parfois
juste en bas de page. Je suppose que vous voulez apprendre, êtes ouvert à des idées différentes, et reconnaîtra
la valeur du bien considéré opinionseven si vous n'êtes pas d'accord avec eux.

Vous ne l'aimez pas le jargon ou de grandes théories. Je ne pense pas que le jargon et les grandes théories aider dans l'apprentissage
et l'application de nouvelles informations. Je les évite, sauf si elles fournissent un chemin à utiles
informations ou fournir une structure qui sera utile plus tard.

Vous ne vous-même, les logiciels, la gestion ou prenez pas trop au sérieux. Développement de logiciels
et la gestion de projet peut être ennuyeux à lire. Bien que ce livre ne sera pas un défouler comique
ou la satire (même si un livre de Mark Twain ou David Sedaris qui explique génie logiciel
a le potentiel), je ne vais pas hésiter à faire des blagues à mes frais (ou quelqu'un d'autre frais), ou
utiliser des exemples qui font un point par des moyens comiques.
Page 11

Comment utiliser ce livre

Je l'ai écrit ce livre avec considération pour les gens qui aiment sauter autour et lire les chapitres
individuellement. Cependant, il ya un certain avantage à le lire directement à travers; certains des plus tard
concepts se fondent sur ​les précédents, et le livre ne suivent plus ou moins l'ordre chronologique de la plus
projets. Bien sûr, vous ne savez jamais ce sauf si vous lisez ce droit à travers, donc si vous choisissez de
sauter autour, vous aurez à me faire confiance sur ce coup.

Le premier chapitre est la plus large dans le livre et a un ton plus profond que le reste. Si vous êtes curieux
pourquoi vous devriez vous intéresser à propos de la gestion de projet, ou ce que les autres personnes importantes ont dit
à ce sujet, alors vous devriez certainement donner un coup de feu. Si vous essayez et déteste, je recommande vraiment
donnant un autre chapitre un essai avant d'abandonner le navire.

Toutes les références et URL citées dans le livre, ainsi que des notes et des commentaires supplémentaires, sont
en ligne à www.scottberkun.com/books/artofpm/. Le site a un forum de discussion et d'autres
ressources pour ceux d'entre vous qui sont intéressés à aller au-delà des sujets dans ce livre.

Et maintenant, parce que vous étiez intelligent et assez pour lire l'intégralité de cette introduction patient, je suppose
vous êtes à la vitesse sur les autres mécanismes de la lecture de livres (numéros de page, les notes, et tout ce qui)
et juste de sortir de votre chemin.

Des cris de joie,

Scott Berkun

Redmond, WA
Page 12

Chapitre un. Une brève histoire du projet

la gestion (et pourquoi vous devriez soins)

Dans de nombreuses organisations, la personne conduisant un projet n'a pas le chef de projet de titre de travail.
C'est bon. Les programmeurs, les gestionnaires, les chefs d'équipe, des testeurs, et les concepteurs de gérer tous les projets en
leur travail quotidien, qu'ils soient de travailler seul ou en équipe. Pour le moment, ceux-ci
distinctions sont pas importants. Mon intention dans ce livre est de capturer ce qui fait des projets réussis
et comment les gens qui mènent des projets réussis font. Ces idées et stratégies ne nécessitent pas de base
hiérarchies spécifiques, titres d'emploi, ou de méthodes. Donc, si vous travaillez sur un projet et avoir au moins une
responsabilité de son résultat, ce qui suit va appliquer à vous. Et si votre carte de visite arriver
à-dire chef de projet sur ​elle, tant mieux.

Ce livre est conçu pour être utile dans trois façons: comme une collection d'essais thématiques axés individuels,
comme un seul récit étendu, et comme une référence pour des situations courantes. Chaque chapitre prend une
tâche différente de haut niveau, fournit un cadre de base, et propose des stratégies et des tactiques pour
complété avec succès la tâche. Cependant, dans ce chapitre d'ouverture, je dois prendre un autre
approche: il ya trois sujets plus larges qui feront le reste du livre plus facile à suivre, et je
leur présenter maintenant.

La première est une histoire courte de projets et pourquoi nous devrions apprendre de ce que les autres ont fait. La
deuxième est quelques informations sur les différentes saveurs de la gestion de projet, y compris des notes
à partir de mon expérience de travail chez Microsoft. Et le troisième est un regard sur les défis sous-jacents
impliqués dans la gestion de projet et la façon dont ils peuvent être surmontés. Bien que ces points seront utiles
plus tard, ils ne sont pas nécessaires pour comprendre les chapitres suivants. Donc, si vous trouvez l'approche de
ce premier chapitre trop large pour votre goût, se sentir libre de se déplacer sur le chapitre 2 et le noyau de ce livre.

Page 13

1.1. Utiliser l'historique

Gestion de projet, comme une idée, remonte très loin. Si vous pensez à toutes les choses qui
ont été construits dans l'histoire de la civilisation, nous avons des milliers d'années d'expérience du projet pour
apprendre. Une ligne pointillée peut être tirée des développeurs de logiciels d'aujourd'hui à travers le temps à
les constructeurs des pyramides égyptiennes ou les architectes des aqueducs romains. Pour leur respective
 époques, les gestionnaires
les fois. Pourtant, de projet
aujourd'hui, quandont joué desdes
la plupart rôles similaires,
gens en appliquant
essaient d'améliorer la la technologie
façon dont leurpour les problèmes
développement webpertinents de
et des logiciels
les projets sont gérés, il est rare qu'ils prêtent attention aux leçons tirées du passé. Le calendrier
nous utilisons comme le champ de la connaissance utile est beaucoup plus proche de nos jours que ce qu'elle devrait être.

L'histoire des projets d'ingénierie révèle que la plupart des projets ont de fortes similitudes. Ils ont
exigences, des dessins, et des contraintes. Ils dépendent de la communication, la prise de décision, et
combinaisons de pensée créative et logique. Les projets impliquent habituellement un calendrier, un budget et un
client. Plus important encore, la tâche centrale des projets est de combiner les œuvres de différentes personnes
en un tout cohérent singulière qui sera utile pour les personnes ou les clients. Si un projet est construit
sur HTML, C ++, ou du ciment et de l'acier, il ya un ensemble de base indéniable de concepts que la plupart
projets partagent.

Curieux de meilleures façons de diriger les efforts de développement Web et logiciel, je l'ai pris un sérieux
intérêt à ce noyau. Je étudié d'autres domaines et industries pour voir comment ils ont résolu la centrale
défis à leurs projets, afin que je puisse appliquer des solutions comparables dans mon propre travail. Je me demandais comment
des projets comme le télescope spatial Hubble et le Boeing 777 ont été conçus et construits. Pourrait
Je réutilise quelque chose de leurs spécifications complexes et les processus de planification? Ou lorsque le Chrysler
Bâtiment a été construit à New York et le Parthénon à Athènes, ne les chefs de projet de planifier et
estimer leur construction de la même manière mes programmeurs ont fait? Quels ont été les intéressant
différences, et ce qui peut être acquise par l'examen de ces différences?

Comment sur ​les éditeurs de journaux, qui organisent et planifient la production quotidienne de l'information? Ils étaient
faisant multimédias (images et mots) bien avant les premiers rêves de publication sur le Web. Qu'en est-il de
la production du long métrage? Le lancement d'Apollo 13? En examinant ces questions, je suis capable de regarder
comment je suis allé à propos de la direction d'équipes de projet d'une nouvelle façon.

Toutefois, ces enquêtes ne fournissent pas toujours des réponses évidentes. Je ne peux pas promettre que vous allez expédier
tôt ou mieux planifier précisément parce que les conseils de ce livre a été influencé par ces sources.
Mais je sais que quand je suis rentré dans le monde du logiciel après avoir regardé ailleurs, mes propres processus
et des outils ont semblé différent pour moi. Je trouve des façons de les changer que je ne l'avais pas pensé. Sur
Dans l'ensemble, je me rendis compte que la plupart des approches utiles et comparaisons que je trouvais étaient jamais
mentionné lors de mes études en sciences informatiques à l'université. Ils ne furent jamais discutées à tech-secteur
conférences ou écrit dans des revues spécialisées.

Les principaux enseignements de mes enquêtes sur le passé sont les trois points suivants:

1. Gestion de projet et développement de logiciels ne sont pas arts sacrés. Toute moderne
Travaux de construction est une nouvelle entrée dans la longue histoire de faire les choses. Les technologies et
compétences peuvent changer, mais la plupart des défis fondamentaux que faire du génie civil restent difficiles. Tous
les choses, si les langages de programmation ou des méthodologies de développement, sont uniques dans certains
façons mais dérivé dans d'autres. Mais si nous voulons réutiliser autant de connaissances que nous pouvons à partir de la
passé, nous devons nous assurer que nous sommes ouverts à examiner à la fois unique et l'aspectsthe
derivativein comparant avec ce qui a précédé.

2. La simple vue de ce que vous faites, plus la puissance et de se concentrer que vous aurez dans
faire. Si nous pouvons maintenir périodiquement une simple vue de notre travail, nous pouvons trouver utile
comparaisons à d'autres façons de faire les choses qui existent partout autour de nous. Il n'y aura plus
des exemples et des leçons de l'histoire et des industries modernes qui peuvent être tirés de la comparaison,
avec, et contrasté contre. Ceci est similaire au concept défini par le mot japonais

Page 14

shôshin, ce qui signifie l'esprit du débutant, (1) ou l'esprit ouvert, une partie essentielle de nombreux arts martiaux
disciplines. Rester curieux et ouvert est ce qui rend la croissance possible, et il exige de la pratique de
maintenir cet état ​d'esprit. Pour continuer à apprendre, nous devons éviter la tentation de glisser dans étroite,
vues sûrs de ce que nous faisons.

3. Simple ne veut pas dire facile. Les meilleurs athlètes, les écrivains, les programmeurs et les gestionnaires ont tendance à
être ceux qui voient toujours ce qu'ils font aussi simple dans la nature, mais en même temps difficile.
Rappelez-vous que simple est pas la même chose aussi facile. Par exemple, il est une chose simple à exécuter un
marathon. Vous commencez à courir et ne vous arrêtez pas jusqu'à ce que vous avez atteint 26.2 miles. Quel pourrait être
plus simple? Le fait qu'il est difficile de ne nie pas sa simplicité. Direction et gestion
Il est également difficile, mais leurs choses naturegetting fait d'une manière spécifique vers un goalis spécifique
simple.

Je veux parler de ces concepts dans de nombreux chapitres. Donc, si je fais des références qui sont hors de la
limites stéréotypées de développement de logiciels, je l'espère, vous comprendrez mes raisons pour le faire.
Et quand je suggère que la prise de décision ou de planification sont des fonctions de gestion simples, je vais
supposons que vous saurez que ce ne suggère en rien ces choses sont faciles à faire.

1.1.1. Apprentissage de l'échec

«Les êtres humains, qui sont presque unique [] parmi les animaux en ayant la capacité d'apprendre
à partir de l'expérience des autres, sont également remarquables pour leur répugnance apparente à
le faire. "

Douglas Adams
 Une simple
souffrir question quipar
volontairement se des
poseerreurs
dans l'étude
et des de l'histoiresides
déceptions projets
elles est la suivante:
pourraient pourquoi
être évités? serait-on
Si l'histoire de deux
génie antique et moderne est (largement) dans le domaine public, et nous avons payé pour faire intelligent
les choses, peu importe où l'inspiration vient, pourquoi si peu de récompenser les gens pour les organisations
récolte les leçons du passé? Comme les projets sont achevés ou sont annulés (et beaucoup
projets de développement finissent de cette façon (2)) tous les jours, peu est fait à apprendre de ce qui est arrivé. Ce
semble que les gestionnaires de la plupart des organisations récompensent rarement les gens pour la recherche de ce genre de
connaissances. Peut-être qu'il est peur de ce qu'ils vont trouver (et la peur d'être tenus responsables pour elle). Ou
Peut-être juste un manque d'intérêt de la part de quelqu'un d'examiner les expériences douloureuses ou frustrant quand
temps pourrait être consacré à passer à la prochaine chose nouvelle à la place.

Dans le livre de Henry Petroski Pour ingénieur est humain: Le rôle de l'échec dans la conception réussie (Vintage
Livres, 1992), il explique comment de nombreuses percées en génie ont eu lieu à la suite de l'échec.
En partie, cela se produit parce que les échecs nous obligent à faire attention. Ils nous demandent de réexaminer
hypothèses que nous avions oublié étaient là (il est difficile de faire semblant de tout le OK lorsque le prototype a
brûler dans les flammes). Comme Karl Popper (3) ont suggéré, il ya seulement deux sortes de théories: ceux qui sont
mal et ceux qui sont incomplètes. Sans échec, nous oublions, dans l'arrogance, que notre
compréhension des choses est jamais aussi complet que nous pensons qu'il est.

L'astuce est alors d'apprendre autant que possible de les échecs des autres. Nous devrions utiliser leur
expériences pour tirer parti contre l'avenir. Bien que les détails superficiels de l'échec peuvent différer
considérablement d'un projet à, les causes profondes ou de l'équipe des actions qui les ont déclenchés pourraient être
entièrement transférable (et évitable). Même sur nos propres projets, nous devons éviter l'habitude de
fuir et se cacher des défaillances. Au lieu de cela, nous devrions les voir comme des occasions d'apprendre
quelque chose. Quels facteurs ont contribué à ce qui se passe? Quels sont ceux qui pourraient être faciles à minimiser ou
éliminer? Selon Petroski, connaissance réelle de l'échec réel est la plus puissante source de
progrès que nous avons, pourvu que nous ayons le courage d'examiner soigneusement ce qui est arrivé.

Peut-être cela est la raison pour laquelle The Boeing Company, une des plus grandes entreprises de conception de l'avion et de l'ingénierie
dans le monde, tient un livre noir des enseignements qu'il a tirés des échecs de conception et d'ingénierie. (4)
Boeing a gardé ce document depuis que la compagnie a été formée, et il l'utilise pour aider moderne
les concepteurs apprennent des tentatives passées. Toute organisation qui parvient à faire cela non seulement augmente sa
les chances de réussite des projets, mais contribue également à créer un environnement qui peut discuter et confronter
échec ouvertement, au lieu de nier et de se cacher de lui. Il semble que les développeurs de logiciels ont besoin de garder
livres noirs de leur propre.

Page 16
15

1.2. développement Web, cuisines, et les salles d'urgence

Un problème avec l'histoire est qu'il est pas toujours identifier. Il peut être difficile d'appliquer les leçons travers
décennies et de maintenir l'empathie pour les choses qui semblent si différent de la façon dont le travail est fait aujourd'hui. Une
alternative est de faire des comparaisons avec les types de projets intéressants modernes. Bien que cela ne
avoir les gravitas de l'histoire de l'ingénierie, il ne permet de vivre des expériences à la première personne et observations.
Souvent, voir les choses de première main est la seule façon de donner aux gens suffisamment d'informations pour faire des
les liens entre les diverses idées.

A titre d'exemple, je connais un développeur web qui croit que son travail ne ressemble à rien d'autre dans le
l'histoire de l'univers. Il estime que, parce que le développement web l'oblige à faire complexe
decisionsdesigning d'ingénierie et de coordination comme il va, de vérifier les modifications dans une affaire d'heures
ou même quelques minutes, et puis tous les publier au projet de worldhis et la gestion des tâches est la différence
jamais rien vu avant. Il est fier de débiter CSS, XHTML, Flash, Java, et d'autres technologies
il a maîtrisé, affirmant qu'ils auraient déconcerté les plus grands esprits il ya 50 ans. Je suis sûr
que, dans votre expérience, vous avez rencontré des gens comme lui. Ou peut-être vous avez travaillé dans des situations
où il semblait improbable que quelqu'un d'autre dans l'univers jamais rien géré aussi complexe que
ce que tu faisais.

Je l'ai suggéré à ce développeur ami qu'il errer dans le dos de son établissement préféré de déjeuner
sur une journée bien remplie. Pour une variété de raisons, il est intéressant de mettre les pieds dans les cuisines (voir Anthony
Excellent livre de Bourdain, Kitchen Confidential , Ecco, 2001), mais mon point spécifique était d'environ
la productivité. La première fois que quelqu'un voit la gestion rapide de la tâche et de la coordination qui se produisent dans un
cuisine professionnelle bien remplie, il est susceptible de reconsidérer la difficulté de son propre emploi est. Les cuisiniers sont souvent
jonglant avec des poêles à frire avec des ordres différents à différents stades de réalisation, et de brouillage entre
plusieurs ensembles de brûleurs dans les coins opposés de la cuisine, tandis que les serveurs courent dans et hors, délivrant
nouvelles de nouveaux ajustements et les problèmes des clients.

Tout cela se passe dans de petites pièces exiguës, bien plus de 90 degrés, avec des lumières fluorescentes vives
flagrante ci-dessus. Et malgré le nombre de commandes de sortir toutes les quelques secondes, nouveaux venus dans tout aussi
rapide. Parfois, les commandes sont renvoyés, ou, un peu comme les projets de logiciels, nécessitent la coutume, et dernière,
modifications minute (tableau 1 est intolérant au lactose; le tableau 2 a besoin de la sauce sur le côté, etc.). Grand,
cuisines sont occupés incroyable à regarder. Comme chaotique qu'ils puissent paraître au premier abord, de grandes cuisines courent avec un
niveau d'intensité et de précision qui souffle équipes plus loin développement.

Chefs cuisiniers de travail et de ligne sont les gestionnaires de projets culinaires, ou comme Bourdain se réfère à eux, le trafic aérien
contrôleurs (une autre profession pour la introspective à considérer). Même si le personnel de cuisine travaille sur
une plus petite échelle et moins célèbre que manager d'une équipe de développement de logiciels, il n'y a pas
la comparaison de l'intensité de tous les jours. Si vous doutez de moi, la prochaine fois que vous êtes à ce occupé déjeuner endroit, demandez à votre
 serveur si vous pouvez regarder à l'intérieur de la cuisine. Il pourrait ne pas vous laisser, mais si il le fait, vous ne serez pas
désappointé. (Certains restaurants et bars branchés ont cuisines ouvertes. Si vous en trouvez un, assis le plus près
à la cuisine que vous le pouvez. Puis suivre une personne pendant quelques minutes. Regardez comment les commandes sont passées,
suivis, construit et livré. Si vous allez sur une journée bien remplie, vous allez penser différemment la façon dont
bogues logiciels sont ouverts, suivis et fixes.)

Une autre leçon de terrain intéressant dans la gestion de projet vient de salles d'urgence de l'hôpital. Je l'ai
visionnée sur la chaîne Discovery Channel et PBS comment de petites équipes de médecins experts, des infirmières, et
spécialistes travaillent ensemble comme une équipe de projet pour traiter diverses et parfois bizarres médicale
situations qui viennent à travers les portes de l'hôpital. Il est pas surprenant que ce soit la profession que
inventé le processus de triage, un terme couramment utilisé sur des projets de logiciels à prioriser les problèmes et
défauts (abordés dans le chapitre 15 ).

Le milieu médical, en particulier les situations de traumatisme, offre une comparaison fascinante pour d'équipe
les résultats de travail, de stress élevé la prise de décision, et de projets communautaires qui touchent de nombreuses personnes chaque jour
(Voir Figure 1-1 pour une comparaison approximative de cela et d'autres milieux de travail). Comme Atul Gawande
a écrit dans son excellent livre, Complications: Notes d'un chirurgien sur une science imparfaite (Picador USA,
2003):

Page 17

Nous attendons pour la médecine d'être un champ ordonné des connaissances et de la procédure. Mais il est pas. C'est un
science imparfaite, une entreprise de connaissances en constante évolution, informations incertaines,
individus faillibles, et dans le même temps vit sur la ligne. Il est la science dans ce que nous faisons, oui,
mais aussi l'habitude, de l'intuition, et parfois simplement vieux devinettes. L'écart entre ce que nous savons
et nous visons persiste. Et cette lacune complique tout ce que nous faisons.

Figure 1-1. Dans l'abstrait, de nombreuses disciplines ont des processus similaires. Ils
tout consacrer du temps à la planification, l'exécution et le raffinage. (Cependant, vous
ne devrait jamais aller à une cuisine pour un traitement médical ou de manger en cas d'urgence
chambre.)

Ce point, et beaucoup d'autres dans le livre éclairant de Gawande, est vrai pour le développement logiciel.
Fred Brooks, dans le livre classique sur le génie logiciel, The Mythical Man-Month , fait similaire
les comparaisons entre les équipes de chirurgiens et des équipes de programmeurs. Même si des vies sont rarement au
jeu lorsque l'on travaille sur des sites Web ou des bases de données, il ya de nombreuses similitudes valides dans les défis
ces différentes équipes de personnes doivent faire face.
Page 18

1.3. Le rôle de la gestion de projet

Gestion de projet peut être une profession, un emploi, un rôle ou une activité. Certaines entreprises ont des projets
les gestionnaires dont le travail est de superviser les projets de 200 personnes entières. D'autres utilisent le titre de niveau ligne
jeunes cadres, chacun responsable d'une petite zone d'un grand projet. Selon la façon dont un
organisation est structurée, ce que sa culture est, et quels sont les objectifs du projet sont, projet
la gestion peut être un rôle informel ("il est fait par la personne qui, chaque fois que nécessaire") ou fortement
défini ("Vincent, Claude, et Raphaël sont les gestionnaires de projet à temps plein»).

Dans ce livre, je vais principalement utilise l'expression chef de projet , ou PM , de se référer à quiconque est impliqué dans
la direction du projet et de l'activité de gestion. Par l'activité de gestion de projet , je veux dire le leader
équipe de trouver ce projet est (planification, l'ordonnancement et la collecte des besoins),
paître le projet à travers la conception et le travail de développement (communication, prise de décision,
et la mi-jeu de stratégie), et la conduite du projet jusqu'à son achèvement (leadership, crise
la gestion et la stratégie de fin de jeu).

Si ce genre de travail est structuré de manière moins formelle dans votre monde, tout simplement traduire chef de projet ou PM pour
signifie «personne faisant des tâches de gestion de projet, même si elle est pas sa tâche principale» ou «personne
la réflexion sur le projet dans son ensemble. "Je l'ai rencontré beaucoup de façons différentes pour ces activités soient
distribué entre les équipes, et les conseils de ce livre est largement indifférent à leur égard. Ce livre est moins
sur les titres et les formalisations emploi et davantage sur la façon de faire les choses et de faire bouger les choses.
Mais pour garder mon écriture aussi simple que possible, je vais appuyer sur l'expression chef de projet , ou PM .

Parfois, l'absence d'un chef de projet dédié fonctionne très bien. Les programmeurs et leurs patrons
maintenir les horaires et les plans d'ingénierie (le cas échéant), et une personne de l'analyste d'affaires ou de marketing ne
le travail de planification ou d'exigences. Tout ce qui pourrait être considéré comme la gestion de projet tout simplement
est distribué dans l'équipe. Peut-être que les gens de l'équipe ont été embauchés pour leur intérêt
au-delà de l'écriture de code. Ils pourraient ne pas l'esprit planification précoce, la conception de l'interface utilisateur, ou une entreprise
stratégie. Il peut y avoir des optimisations significatives en travaillant de cette manière. Tant que tout le monde est prêt à
payer la taxe de la responsabilité de garder les choses ensemble, et la distribution de la charge qu'un
chef de projet dédié porterait pour l'équipe, il ya un employé de moins que l'équipe a besoin.
Efficacité et simplicité sont de bonnes choses.

Mais d'autres fois, l'absence d'un chef de projet crée un dysfonctionnement. Sans une personne dont
la tâche principale est de guider l'effort global, les préjugés et les intérêts peuvent faire dérailler les directions individuelles
de l'équipe. Factions antagonistes forts peuvent se développer autour de rôles commerciaux et d'ingénierie,
ralentissant les progrès et tout le monde impliqué frustrant. Considérez que, dans les salles d'urgence, l'un
médecin prend l'initiative de décider du cours de l'action pour un patient. Cela accélère beaucoup de décisions
et donne la clarté des rôles que tout le monde sur l'équipe de traumatologie est appelé à jouer. Sans que
sorte d'autorité claire pour les questions de type gestion de projet, les équipes de développement peut avoir des ennuis.
Si il n'y a pas de propriétaire claires pour mener le triage de bug, ou pas est dédiée au suivi de l'horaire et
la signalisation des problèmes, ces tâches pourraient traîne dangereusement derrière individuelle, la programmation centrée
activités.

Bien que je pense que beaucoup des meilleurs programmeurs de comprendre assez sur la gestion de projet pour le faire
eux-mêmes, ils reconnaissent aussi la valeur unique d'un bien, personne dédiée à jouer le rôle de
gestionnaire.

Page 19

1.4. Programme et de la gestion de projet à Microsoft

Microsoft a eu un problème à la fin des années 1980 en ce qui concerne la façon de coordonner les efforts d'ingénierie avec le
 marketing et des affaires côté de chaque division (diront certains, cela est encore un problème pour Microsoft
et beaucoup d'autres entreprises). Un homme sage nommé Jabe Blumenthal a réalisé qu'il pourrait y avoir un
travail spécial où un individu serait impliqué dans ces deux fonctions, jouer un rôle à la fois
leadership et la coordination. Il serait impliqué dans le projet dès le premier jour de la planification, tout le chemin
à travers le dernier jour de l'essai. Il devait être quelqu'un qui était au moins assez technique pour travailler
avec et gagner le respect des programmeurs, mais aussi quelqu'un qui avait des talents et intérêts pour
une participation plus large dans la façon dont les produits ont été faites.

Pour ce rôle, au travail, il aurait à profiter de passer ses jours effectuant des tâches aussi variées que l'écriture
spécifications, l'examen des plans de marketing, générant des calendriers de projet, la direction d'équipes, qui font
la planification stratégique, la course bug / défaut triage, cultiver moral de l'équipe, et de faire autre chose que
qui devait être fait que personne ne faisait (bien). Ce nouveau rôle chez Microsoft a été appelé programme
gestionnaire . Pas tout le monde dans l'équipe ferait rapport directement à lui, mais le gestionnaire de programme serait
accorder des pouvoirs importants à mener et conduire le projet. (En théorie de la gestion, cela est
à peu près l'idée d'une organisation matricielle, (5) où il ya deux lignes de structure de reporting pour
individus: l'un basé sur la fonction et l'autre sur la base de projet. Ainsi, un programmeur individuel ou
testeur pourrait avoir de rapports relationshipsa primaire un pour son rôle fonctionnel et un secondaire deux,
mais solide, un pour le projet, elle travaille sur.)

Jabe joué ce rôle sur un produit appelé Multiplan (qui deviendra plus tard Microsoft Excel), et il a travaillé.
Le processus d'ingénierie et de développement amélioré avec la qualité de la coordination avec le
l'équipe des affaires, et à travers les couloirs de Microsoft il y avait beaucoup de joie. Après de nombreuses
mémos et des réunions, la plupart des équipes au sein de la société a adopté le rôle lentement. Dites ce que vous voulez,
bon ou mauvais, sur les produits qui en résultent, mais l'idée fait sens. En définissant un rôle pour un line-
niveau généraliste qui était pas un coursier ou un laquais, mais un leader et un chauffeur, la dynamique de la façon dont
les équipes de développement travaillé chez Microsoft a changé à jamais. Ce rôle de gestionnaire de programme était ce que je
fait à travers la plupart de ma carrière chez Microsoft, et je travaillais sur les équipes de produits qui comprenait Internet
Explorer, MSN et Windows. Finalement, je même des équipes de personnes qui ont joué ce rôle réussi.

À ce jour, je ne connais pas beaucoup d'entreprises qui ont fait autant dans la redéfinition et la formalisation d'un
forme spécialisée de la gestion de projet. Il était rare dans mes nombreuses interactions avec d'autres web et
entreprises de développement de logiciels de rencontrer quelqu'un qui a joué le même genre de rôle (soit ils
étaient des ingénieurs ou des types d'affaires, ou en de rares occasions, les concepteurs). Beaucoup d'entreprises utilisent équipe
structures d'organisation du travail, mais peu définir les rôles qui traversent ingénierie et des affaires
hiérarchies délibérément. Aujourd'hui, il ya plus de 5000 gestionnaires de programme chez Microsoft (sur
plus de 50 000 employés au total), et même si la puissance de l'idée a été diluée (et dans
certains cas, mal utilisé), l'esprit de base de celui-ci peuvent encore être trouvés dans de nombreuses équipes et des groupes au sein de la
compagnie.

Mais indépendamment de ce qu'il a dit sur ma carte de visite, ou ce que Microsoft lore vous choisissez de croire ou de
ignorent, mes fonctions quotidiennes comme un gestionnaire de programme étaient des fonctions de gestion de projet. Dans le
termes simples, cela signifie que je suis chargé de faire la projectand celui qui était
contribuant à ITAS réussie que possible. Tous les chapitres de ce livre refléter les tâches essentielles
impliqué dans ce faisant, de la planification précoce ( chapitres 3 et 4 ), à l'écriture Spec ( chapitre 7 ), à
la prise de décision ( chapitre 8 ), à la gestion de la mise en œuvre et la libération ( chapitres 14 et 15 ).

Sous ces compétences, certaines attitudes et traits de personnalité entrent en jeu. Sans prise de conscience de
eux, quiconque attaque ou la gestion d'un projet est un sérieux désavantage.

Page 20

1.5. L'acte d'équilibrage de la gestion de projet

Il est difficile de trouver de bons gestionnaires de projets parce qu'ils ont besoin de maintenir un équilibre des attitudes. Tom
Peters, dans son essai "Poursuivant le gestionnaire de projet parfait», (6) appelle ces attitudes contradictoires
paradoxes ou dilemmes. Ce nom est approprié parce que des situations différentes exigent différents
comportement. Cela signifie que le gestionnaire de projet doit non seulement être au courant de ces traits, mais aussi à
développer des instincts de ceux qui sont appropriés à quels moments. Cela contribue à l'idée de
la gestion de projet comme un art: il faut l'intuition, le jugement et l'expérience nécessaires pour utiliser ces forces
de manière efficace. La liste suivante des traits est plus ou moins dérivé de l'essai Peters:

Ego / non-ego . En raison de la quantité de chefs de projet de la responsabilité ont, ils tirent souvent
une grande satisfaction personnelle de leur travail. Il est compréhensible qu'ils auraient une haute
investissement émotionnel dans ce qu'ils font, et pour beaucoup, cette connexion émotionnelle est ce que
leur permet de maintenir l'intensité nécessaire pour être efficace. Mais dans le même temps, le projet
les gestionnaires doivent éviter de placer leurs propres intérêts avant ceux du projet. Ils doivent être prêts à
déléguer des tâches importantes ou de plaisir et de partager des accolades et des récompenses avec toute l'équipe. Comme
autant que l'ego peut être un carburant, un bon gestionnaire de projet doit reconnaître quand son ego devient en
le chemin.
 Autocrate / délégant . Dans certaines situations, les choses les plus importantes sont une ligne claire de
autorité et un temps de réponse rapide. Un gestionnaire de projet doit être suffisamment confiant et volontaire
de prendre le contrôle et de forcer certaines actions sur une équipe. Cependant, l'objectif général devrait être de
éviter la nécessité de ces situations extrêmes. Un projet bien géré devrait créer un
environnement où le travail peut être déléguée et a collaboré sur efficacement.

Tolérer l'ambiguïté / poursuivre la perfection . Les premières phases de tout projet sont très ouverte et
expériences fluides où l'inconnu l'emporte largement connu. Comme nous le verrons dans les chapitres
5 et 6 , l'ambiguïté contrôlé est essentiel pour de bonnes idées à la surface, et un gestionnaire de projet
Il doit être respecté, sinon le gérer. Mais à d'autres moments, en particulier dans les phases ultérieures d'un
projet, la discipline et la précision sont primordiales. Il appelle à la sagesse de discerner quand la quête
la perfection est intéressant, par rapport quand une solution médiocre ou rapide et sale est suffisante.
(Voir la section « Recherche et de pesée des options "dans le chapitre 8 ).

Oral / écrit . Malgré la façon dont la plupart des organisations de développement de logiciels d'email sont centrées, orale
compétences sont extrêmement importants pour la gestion de projet. Il y aura toujours des réunions,
négociations, des discussions de couloir, et des séances de remue-méninges, et le gestionnaire de projet doit
être efficace à la fois la compréhension et la communication des idées face à face. Plus la
organisation ou le projet est, les compétences écrites les plus importantes (et la volonté d'utiliser
eux) deviennent. En dépit de ses préférences personnelles, un gestionnaire de projet doit reconnaître quand
communication écrite ou orale sera plus efficace.

Reconnaître la complexité / simplicité champion . Beaucoup de gens sont victimes de la complexité.

Quand ils sont confrontés à un défi organisationnel ou d'ingénierie complexes, ils se perdent dans les détails
et oublier la grande image. D'autres restent dans le déni de complexité et prennent de mauvaises décisions
parce qu'ils ne comprennent pas pleinement les subtilités de ce qui est impliqué. L'équilibre est ici
de reconnaître quelle vue du projet est le plus utile pour le problème ou la décision à portée de main, et
pour passer confortablement entre elles ou de les garder à l'esprit à la fois dans le même temps (sans votre
tête exploser). Les gestionnaires de projet doivent être persuasif à obtenir l'équipe à lutter pour
simplicité et de clarté dans le travail qu'ils font, sans minimiser les difficultés liées à
la bonne écriture, le code fiable.

Impatient / patients . La plupart du temps, le chef de projet est la personne qui pousse à l'action,
forcer les autres à conserver un emploi maigre et concentré. Mais dans certaines situations, l'impatience travaille contre
le projet. Certaines activités politiques, trans-organisationnelles, ou bureaucratiques sont inévitables
le temps coule: quelqu'un doit être dans la chambre, ou être sur la conférence téléphonique, et ils doivent être
patient. Alors, savoir quand pour forcer un problème, et quand faire marche arrière et de laisser les choses se passent, est un

Page 21

les gestionnaires de projet de sens doivent développer.

Courage / la peur . Un des grands misnomères de la culture américaine est que le brave sont des gens
qui se sentent aucune crainte. Ceci est un mensonge. Le brave sont ceux qui se sentent la peur, mais choisir de prendre des mesures
de toute façon. Un chef de projet doit avoir un sain respect pour toutes les choses qui peuvent mal se passer,
et les voir comme tout à fait possible. Mais un chef de projet doit correspondre à cet égard avec le
courage nécessaire pour prendre sur les grands défis.

Croyant / sceptique . Il ya rien de plus puissant pour le moral de l'équipe d'un leader respecté
qui croit en ce qu'elle fait. Il est important pour un chef de projet d'avoir confiance dans
le travail accompli, et de voir la vraie valeur dans les objectifs qui seront atteints. En même temps,
il ya un besoin de scepticisme (pas de cynisme) de la façon dont les choses se passent et la manière dont les
ils sont effectués. Quelqu'un doit sonder et à la question, ce qui expose les hypothèses et la mise
questions difficiles à la lumière. L'équilibre est de demander quelque sorte vigoureusement questions et défi
les hypothèses des autres, sans secouer la croyance de l'équipe en ce qu'ils font.

Comme Peters souligne dans son essai, il est très rare de trouver des gens capables de toutes ces compétences, beaucoup moins
avec la capacité de les équilibrer correctement. Beaucoup des erreurs que tout PM fera implique
mécomptes à équilibrer un ou plusieurs de ces forces contradictoires. Cependant, toute personne peut obtenir mieux
à reconnaître, comprendre, et ensuite améliorer sa propre capacité à garder ces forces en équilibre.
Ainsi, alors que je ne vais pas mettre l'accent sur cette liste de paradoxes fortement à nouveau (bien qu'il arrive quelques fois
par la suite), il est une référence valable. En regardant cette liste des forces contradictoires, mais nécessaires, peut vous aider
de prendre du recul, de reconsidérer ce que vous faites et pourquoi, et de prendre de meilleures décisions.
Page 22

1.6. Pression et la distraction

Une crainte de ceux de nouveau à la gestion de projet est que le succès exige un changement. De nouveaux projets sont
créé avec l'intention de changer l'état du monde en modifiant, bâtiment, ou de détruire
quelque chose. Le maintien de la quounless d'état qui est le but explicite, pour certains reasonis étranges pas un
succès. Le monde est en train de changer tout le temps et si un site Web ou un autre projet ne sont pas aussi
bonne aujourd'hui qu'elle l'était l'an dernier, cela signifie généralement qu'il est tombé derrière parce que les objectifs étaient
erronée ou l'exécution du projet qui a échoué en quelque sorte.

Il est difficile d'ignorer la pression sous-jacente que cela implique pour les gestionnaires de projet, mais il est livré avec le
territoire. Ne restez pas là; fais le mieux. Il ya toujours une nouvelle façon de penser, un nouveau sujet de
apprendre et d'appliquer, ou d'un nouveau procédé qui rend le travail plus amusant et plus efficace. Peut-être cela est un
responsabilité plus proche de la direction que de la gestion, mais la distinction entre les deux est
subtile. Peu importe combien vous essayez de les séparer, bien gérer nécessite des compétences de leadership, et
conduisant ainsi exige des compétences de gestion. Toute personne impliquée dans la gestion de projet sera responsable
pour un peu des deux, peu importe ce que dit sa description de tâches.

Mais revenons à la question de la pression, je l'ai vu de nombreux gestionnaires qui répugnent à la direction
moments (par exemple, un moment où l'équipe / projet a besoin de quelqu'un pour prendre des mesures décisives) et
retirer à suivre les efforts des autres au lieu de faciliter ou même y participer. Je tombe
quelqu'un ne est de garder score et regarder dans les coulisses, il serait peut-être mieux adapté pour le
département de comptabilité. Quand quelqu'un dans un rôle de leadership répond constamment à la pression des
sortir de la mêlée, il est se cache pas leadinghe. PMs inefficaces ou pression négative ont tendance à estomper
dans la périphérie du projet, où ils ajoutent peu de valeur.

1.6.1. Processus compliqué avec les objectifs

Quelques GP dans cette situation ont recours à la quantification des choses qui ne doivent pas être quantifiés. Incertain de
quoi faire d'autre, ou de peur de faire ce que la plupart doit être fait, ils occupent leur temps avec secondaire
les choses. Et comme l'écart entre le PM et le projet se développe, la quantité d'attention inutiles
versée aux graphiques, des tableaux, des listes de vérification et des rapports augmente. Il est possible qu'à un moment donné le PMS
commencer à croire que les données et le processus sont le projet. Ils se concentrent sur ​la moins importante
choses qui sont faciles à travailler avec (feuilles de calcul ou des rapports), plutôt que sur les choses importantes que
sont difficiles à travailler avec (l'effort de programmation ou le calendrier). Ils peuvent développer la croyance
que si elles suivent simplement une certaine procédure à la perfection et vérifier les bonnes choses au large de la liste de contrôle,
le projet est garanti pour réussir (ou plus cyniquement, toute défaillance qui pourrait arriver ne sera pas
être techniquement leur faute).

Pour minimiser la possibilité de confusion, de bons gestionnaires de projets résistent définition des limites strictes
autour de types de travail qu'ils sont prêts ou non disposés à le faire. Ils évitent les lignes jaunes vives entre
les tâches de gestion de projet et le projet lui-même. L'adhésion à des listes de contrôle implique qu'il ya une
processus définitif qui garantit un résultat particulier, qui est jamais le cas. En réalité, il ya
toujours juste trois choses: un but, une pile de travail, et un tas de gens. Des rôles bien définis (voir
Chapitre 9 ) pourrait aider ces personnes d'organiser autour de l'œuvre, mais la formation de rôles est pas
l'objectif. Une liste de contrôle pourrait aider ces personnes font le travail d'une manière qui répond à l'objectif, mais le
liste de contrôle est pas le but non plus. Confondre les processus avec les objectifs est l'un des grands péchés
gestion. Je devrais le savoir: je suis engagé moi-même.

Il ya des années, à travailler sur le projet Internet Explorer 4.0, je suis le PM pour plusieurs grandes zones de la
 interface
développéutilisateur. Je sentais
que si une pression importante: il des
étaitlistes
le plus
de grand cession
je nejemanque
jamais jamais.
eu. En réponse, je les choses
la conviction je pouvais tout écrire dans contrôle, Alors que
ne doivent être suivis attentivement sur un projet, je l'avais pris trop loin. Je l'avais construit une feuille de calcul élaboré pour
Les données montrent plusieurs vues, et les grands tableaux blancs dans mon bureau étaient couverts de tableaux et de listes
(Et les tableaux blancs supplémentaires étaient sur le chemin).

Page 23

Mon patron me laissait courir avec elle parce que les choses se passent bien. Autrement dit, jusqu'à ce qu'il m'a vu passer plus
temps avec mes listes de contrôle et des processus que je faisais avec mon teamA grand drapeau rouge (signe d'avertissement). Il
est venu dans mon bureau un jour, et de voir le comique grande matrice de listes de vérification et des tables je serais
écrite sur chaque surface plane dans mon bureau, m'a fait asseoir et a fermé la porte. Il a dit, "Scott, ce
truc est agréable, mais votre projet est votre équipe. Gérer l'équipe, pas les listes de contrôle. Si les listes de contrôle
vous aider à gérer l'équipe, grande. Mais la façon dont vous allez bientôt vous utiliserez votre équipe pour aider
vous gérez vos listes de contrôle ".

Ainsi, au lieu de se concentrer sur les processus et les méthodes, les gestionnaires de projet devraient être concentrés sur leur
équipes. Systèmes de planification ou de suivi simples devraient certainement être utilisés, mais ils doivent correspondre à la
la complexité du projet et de la culture de l'équipe. Plus précisément, la planification et le suivi devrait
soutenir l'équipe à atteindre projet goalsnot les inhiber. Je suis convaincu que tant que le PM est
attention et a gagné la confiance de l'équipe, des tâches, des processus, des rapports, des listes de contrôle manquants,
ou d'autres machines de gestion de projet nécessaire deviendra clair avant que les problèmes qu'ils pourraient
Résolvez devenir sérieux.

Comme nous le verrons dans le chapitre 10 , juste parce qu'un livre ou un dirigeant dit de faire quelque chose, ou parce que
une technique a été employée le mois dernier ou l'an dernier, ne signifie pas qu'il applique aujourd'hui. Chaque équipe et
projet est différent, et il ya souvent de bonnes raisons de douter anciens jugements. La raison d'être
conservatrice avec des méthodes et des processus est que ceux qui sont inutiles ont tendance à faire boule de neige, traînant
équipes descendent dans la fosse de goudron de projets difficiles, comme décrit dans Fred Brooks ' Le mythique Homme-
Mois . Lorsque les processus sont nécessaires pour gérer les processus, il est difficile de savoir où le travail réel
est fait. Il est souvent le chef d'équipe ou chef de projet qui a la plus grande capacité à diriger le
équipe claire de la bureaucratie, ou plus cyniquement, d'envoyer l'équipe à plein régime dans les cercles sans fin de
procédures et de la pensée du comité-driven.

Page 24

1.7. Le bon type d'implication

 Tous managersfrom Fortune 500 cadres aux entraîneurs de sports teamsare vulnérables à la participation
eux-mêmes. Je pense à un certain niveau, ils savent qu'ils sont en tête de potentiel, et compulsif
la participation est une pratique (si négatif) façon d'essayer de compenser. Cette partie
explique la source inépuisable de micromanagers; le mouvement le plus facile pour un gestionnaire faible est d'abuser d'elle
pouvoir sur ses subordonnés (et dans des cas extrêmes, simultanément blâmer les subordonnés pour
être assez incompétent pour besoin d'autant d'attention). Les gestionnaires des insécurités ont souches à partir
le fait que, en termes de révolution industrielle, les gestionnaires ne sont pas dans la ligne de production. Ils ne le font pas
rendre les choses avec leurs mains, et ils ne sont pas le même genre d'actifs que ceux qui le font.

Les gestionnaires ne sont pas embauchés pour contribuer une quantité linéaire de travail à l'atelier de l'usine ou du logiciel, comme un
devrait travailleur ou programmeur pour le faire. Au lieu de cela, les dirigeants et les gestionnaires sont embauchés pour amplifier le
valeur de tout le monde autour d'eux. Les méthodes pour ajouter ce genre de valeur sont différents de
travaillant sur la ligne. Mais parce que de nombreux gestionnaires sont d'anciens programmeurs et ont été promus à des
la gestion de la ligne, les chances sont bonnes que ils ont plus confiance et les compétences à l'écriture de code
qu'ils ne diriger et de gérer les gens qui écrivent le code.

Comme un entraîneur pour une équipe de base-ball, la présence d'un gestionnaire est censé contribuer à quelque chose
de nature différente de l'ajout d'un autre contributeur individuel. Parfois, cela se fait par décantation
arguments ou le blindage à l'équipe de la politique. D'autres fois, il est fournissant des plans de haut niveau de bien-être, ou
trouver des solutions de contournement intelligentes pour des situations inattendues. Parce que ces contributions sont plus difficiles à
mesure, de nombreux GP luttent avec l'ambiguïté de leur rôle. En tant que gestionnaires, ils sont des cibles faciles pour
blâmer et avoir quelques endroits où se cacher. Il faut une combinaison de conviction, la confiance, et la sensibilisation
pour être efficace et heureux comme un leader d'une équipe.

1.7.1. Profitez de votre point de vue

La meilleure façon de trouver les points de l'effet de levier est de faire usage de la différence en psychologie gagné
d'être sur la ligne. Un PM, dans le cadre de ses fonctions, de passer naturellement plus de temps à travailler avec
différentes personnes de l'équipe que d'autres ne, gagnant ainsi plus de sources d'information et un
perspective plus large du projet. Le PM va comprendre le point de vue de l'entreprise du projet ainsi que
le point de vue technique, et il va aider l'équipe à traduire entre eux lorsque nécessaire. Ce large
point de vue, il est possible de livrer des pépites d'information critiques sur les bonnes personnes au
bon moment. Bien que ce pouvoir peut avoir des effets généraux, ce qui suit est une histoire simple qui aide
illustrer ce point d'une manière globale.

Comme une habitude, je l'ai toujours arpenté les couloirs et laissé tomber dans le programmeur qui avaient ouvert leurs portes.
Je habituellement juste faire le petit entretien, essaie de les amener à rire de quelque chose, et leur demander de montrer
moi ce qu'ils ont travaillé sur. Si ils ont offert, je regarde une démonstration de tout ce qu'ils me montrent.
Faire cela tous les jours, même pour quelques minutes, m'a souvent donné une bonne idée de l'état réel de
le projet (dans le chapitre 9 , nous allons discuter de cette pratique de la gestion en marchant autour).

Par exemple, un matin, au cours du projet IE 5.0, je suis passé par le bureau de Fred. Il se disputait avec
Steve, un autre programmeur, comment ils allaient obtenir la nouvelle liste Voir commande au travail
problème imprévu properlyan de compatibilité avait été découvert ce matin. Ni l'un d'entre eux
voulu faire le travail. Et à partir de ce que je pouvais entendre, il faudrait une demi-journée ou plus à corriger. Je fourré
mon nez et a confirmé ce dont ils parlaient. Ils hochaient la tête, comme pour dire,
"Ouais, pourquoi devriez-vous soucier?" Je leur ai alors dit d'aller parler à Bill dans le couloir. Ils ont à nouveau demandé
pourquoi, pensant que cela était une question d'architecture très spécifique que je ne pouvais pas comprendre facilement. J'ai souris
et dit: «Parce que je vient de quitter son bureau, et il a le contrôle de la nouvelle arborescence de travail parfaitement sur son
machine. Il est tombé sur le problème la nuit dernière et fixé comme partie d'un autre élément de travail ".

Maintenant, bien sûr, dans cette petite histoire que je ne pas sauver le monde ou de prévenir une catastrophe majeure. Si je ne l'avais pas fait
cet égard pour eux, seulement quelques heures ou une demi-journée aurait été gaspillé (bien que, comme nous allons

Page 25

discuter plus tard dans le chapitre 8 , les horaires glissent généralement un peu à la fois). Mais cela ne le point. Bien
les gestionnaires de projet font leur affaire de connaître toutes sortes de choses utiles à propos de l'état de la
teamand l'état du mondeet ensuite appliquer ces connaissances pour aider les gens à obtenir des choses fait. Il est tout
des petits morceaux de transfert d'informations en temps opportun, comme celui de cette histoire, qui font les équipes médiocres
bon et très bonnes équipes. Pas de projets ou de suivi des bogues système remplace complètement le besoin de
les gens à parler les uns aux autres à propos de ce qui se passe parce que les réseaux sociaux sont toujours plus forts (et
parfois plus rapide) que les technologiques. Les grands défis comme la vision du projet, disposent de listes, et
horaires viennent toujours à beaucoup de petits défis qui sont positivement influencés par la facilité
bonne connaissance et une circulation de l'information grâce à une équipe. Les gestionnaires de projet jouent un rôle essentiel dans
décisions qui découlent saine et active.

Mais si elle est peu ou grandes choses, les actions et les décisions des gestionnaires font devraient avoir clairement
avantages pour l'ensemble de l'équipe. Il pourrait prendre une semaine ou un mois pour devenir visible, mais un bon projet
gestionnaire va créer un impact positif sur la qualité du travail produit, et souvent la qualité de
la vie vécue par toutes les personnes impliquées. Les gens vont se sentir différemment au sujet de leur travail, dira ouvertement
qu'ils ont une meilleure compréhension de ce qu'ils font et pourquoi, et se sentent mieux sur ce qui est
vient ensuite qu'avant. Ce genre de changement se produit une seule réunion, la décision, ou
discussion à un moment, mais au cours d'un projet, cette ambiance et de l'énergie peuvent changer et d'améliorer
de façon spectaculaire.

1.7.2. Les gestionnaires de projet de créer une valeur unique

 En conséquence, les bons gestionnaires et les dirigeants gagnent souvent un type particulier de respect de la part des programmeurs,
testeurs, designers, marketing, et les gens de documentation qui entrent en contact avec eux. Le PM
devrait être capable de réaliser des exploits de la pensée, de la stratégie et de leadership qui ont un impact positif sur l'équipe
dans quelques autres façons possible. Souvent, cela implique de trouver des raccourcis et des optimisations intelligentes dans le quotidien
workflow, ou de donner un coup de pouce de l'enthousiasme ou l'encouragement de la bonne manière et au bon moment.
Ils ne doivent pas être surhumain, ou même particulièrement lumineux, pour ce faire (comme je l'ai aucun doute
découvert). Ils ont juste à comprendre l'avantage de leur point de vue et choisissent de faire
utilisation des TI.

Il ya un simple fait incontestable: les gestionnaires de projet ou chefs passent plus de temps avec chaque
personne de l'équipe que quiconque. Ils sont en plus de réunions, chuter de plus de bureaux, et de parler à
plus de contributeurs individuels que toute autre personne. Ils peuvent faire ou d'influencer des décisions plus
que quiconque dans l'organisation. Si le gestionnaire de projet est heureux, triste, motivés, ou déprimé,
certains qui va déteindre sur tous ceux qu'elle rencontre tous les jours. Qu'est-ce que les GP apporter à la
projet, bonne ou mauvaise, sera contagieuse pour le reste de l'équipe.

Donc, si le gestionnaire de projet est axé sur, engagé à, excité, et capable de réussir,
les chances augmentent que tout le monde se comporte de la même façon. Gestionnaires de toute nature sont similaires
des positions de pouvoir potentiel, et il ya peu de points de levier de autant de valeur dans la plupart travail
environnements. Cela signifie que si elle est à tout possible de cultiver les attitudes et les idées que je l'ai
décrit jusqu'ici, il n'y a pas plus grande place pour faire ces investissements que dans les dirigeants et les gestionnaires.
Cela ne veut pas dire que d'un gestionnaire de projet doit être une figure de héros charismatique qui, avec à peine un haussement d'épaules,
peut conduire les armées de programmeurs dans la bataille (voir la section « Le complexe du héros »dans le chapitre 11 ).
Au lieu de cela, il a juste besoin d'être véritablement intéressé à aider les rapports de ses coéquipiers et d'être
réussi à lui plus souvent.

En fin de compte, l'idée de base Je crois en est que, tant que personne ne se blesse (sauf peut-être
concurrents), et vous les personnes impliquées dans le droit chemin, nothing else matters, mais le fait que la bonne
Stuff est faite. Il n'a pas d'importance combien d'idées venus de vous ou de quelqu'un d'autre, tant que le
résultat est positif. La gestion de projet est sur l'utilisation de tous les moyens nécessaires pour augmenter la
probabilité et la vitesse des résultats positifs. Un mantra quotidien utile, je l'ai utilisé est «Faire de bonnes choses
se produisent. "Les gens me voir dans le couloir ou travailler avec un programmeur à un tableau blanc et
demander, "Hey Scott, what'cha faire?" Et je sourire et de dire, "Faire de bonnes choses arriver." Il est devenu un
partie dominante de la façon dont je me suis approché chaque jour, et quand je réussi les autres, cette attitude
étendu sur et à travers l'équipe à travers eux. Comme ce livre passe à chapitres thématiques axés, je
espérons que vous vous sentirez cette attitude, et les idées de base de ce chapitre d'ouverture, venez à travers.

Page 26

1.8. Résumé

Chaque chapitre de ce livre se termine par un bref résumé des points clés pour vous aider à examiner plus tard:

La gestion de projet est partout et il a été autour depuis longtemps.

Si vous gardez l'esprit d'un débutant, vous aurez plus d'occasions d'apprendre.

Gestion de projet peut être une tâche, un rôle ou une activité (les conseils de ce livre applique bien pas
importe comment vous définissez).

La gestion du programme est fortement défini le rôle de gestion de projet de Microsoft. Il est dérivé
de l'idée d'une organisation matricielle.

Leadership et de la gestion nécessite une compréhension et intuition, plusieurs commune

paradoxes. Ceux-ci comprennent l'ego / non-ego, l'autocratie / délégation, et le courage / la peur.

Attention aux prétention et sur-implication dans votre activité de gestion. Le processus

devraient soutenir l'équipe, pas l'inverse.

Si vous êtes un gestionnaire dédié, chercher des moyens de tirer profit de votre point de vue unique de la
équipe et projet.
Page 27

Partie I: Plans

Chapitre 2 : La vérité sur les horaires

Chapitre 3 : Comment comprendre ce qu'il faut faire

Chapitre 4 : Rédaction de la bonne vision

Chapitre 5 : Où viennent les idées

Chapitre 6 : Que faire avec les idées une fois que vous les avez
Page 28

Chapitre deux. La vérité sur les horaires

Certaines personnes ont tendance à être en retard . Il pourrait être à seulement quelques minutes à l'occasion, ou juste une couple de fois
une semaine, mais les gens sont souvent en retard sur leurs horaires quotidiens. (Cependant, parce que le déni est un autre
êtres humains grande de compétences semblent avoir, je comprendrai si vous refusez d'admettre que cette allégation applique
à vous.) Les élèves du secondaire sont en retard en classe, les adultes sont en retard aux réunions au travail, et les amis
arriver 10 minutes de retard au bar pour les boissons. Il semble que, inconsciemment, nous croyons souvent que d'être
l'heure est pas de cibler un moment précis, mais à la place est d'être dans une fourchette de
moments, et pour certaines personnes, cette gamme est plus large que pour les autres. Un exemple intéressant est le
de nombreuses hôtesses qui nous accueillent dans les restaurants. Ils nous disent une table sera bientôt prêt, (1) mais souvent
on nous fait attendre longtemps. Ce sont ces expériences des horaires retardés, étant mis en attente sur
le téléphone, ou en attente dans le bureau du médecin, qui ont causé nous devenons cyniques à propos
scheduleswe ont tellement d'expérience avec la vie ne marche pas selon eux.

Il est pas une surprise alors que tant de projets arrivent en retard. Comme les êtres humains, la plupart d'entre nous arrivent à la
tâche de projets de planification avec un bilan discutable pour livrer ou de recevoir des choses sur
temps. Nous avons tendance à estimer sur la base des hypothèses faibles, prédire les résultats pour les travaux sur la base de la meilleure
possible ensemble de circonstances, andgiven notre avant experiencessimultaneously éviter de mettre trop
confiance dans tout calendrier que nous voyons ou créons. Pourquoi nous faisons cela, ses répercussions sur les calendriers des projets, et
ce qui peut être fait pour éviter ces problèmes est le sujet de ce chapitre.

Mais avant que nous puissions comprendre comment faire de meilleurs horaires, nous devons d'abord comprendre ce que
horaires des problèmes à résoudre. Si ils sont si peu fiables, pourquoi embêter avec eux à tous? Horaires servent
plusieurs purposesonly différents dont certains sont axés sur la mesure de l'utilisation du temps.

Page 29
 2.1. Horaires ont trois objectifs

Tous les horaires, que ce soit pour la planification d'une partie de week-end ou pour mettre à jour un site intranet, servent de trois
principaux objectifs. La première, et la plus connue, est de prendre des engagements sur le moment où les choses
sera fait. Le calendrier prévoit une forme de contrat entre chaque personne sur une équipe ou dans un
organisation, confirmant ce que chaque personne va livrer cours de la prochaine semaine, le mois ou l'année.
Généralement, quand les gens pensent à propos des calendriers de projet, il est ce premier but qui ils pensent
sur. Les horaires sont souvent axés à l'extérieur, en dehors de l'équipe de projet plutôt que dans, parce
ils sont utilisés pour aider à conclure une affaire ou de se conformer avec le scénario d'un client. Souvent, le client est
payer explicitement la chronologie ainsi que pour le service fourni (pensez UPS ou FedEx). Afin de
permettent aux clients ou partenaires de faire des plans basés sur un projet donné, un temps doit être convenu
pour quand les choses spécifiques qui se passera.

Le deuxième objectif d'un programme est d'encourager tous ceux qui ont contribué à un projet pour voir
ses efforts en tant que partie d'un tout, et investir dans la fabrication de ses pièces fonctionnent avec les autres. Jusqu'à il ya un
projet de calendrier proposant des dates et heures précises pour quand les choses doivent être prêts, il est peu probable
que les connexions et les dépendances entre les personnes ou les équipes seront examinées. Au lieu de cela, tout le monde
travailler sur sa propre tâche, et ont tendance à ne pas penser à la façon dont son travail aura un impact sur les autres.

Il est seulement quand les détails sont écrites, avec les noms des personnes à côté d'eux, que les vrais calculs
peuvent être faites et des hypothèses examinées. Cela est vrai même pour les petites équipes ou pour les personnes travaillant
seul. Il ya un pouvoir psychologique dans un calendrier qui extériorise et amplifie l'engagement
qui est faite. Au lieu des dates et des engagements existants qu'à l'intérieur de l'esprit de quelqu'un, ils
sont dépréciées et exister dans l'univers tout sur leur propre. Il est pas aussi facile d'oublier ou d'ignorer
quelque chose quand il est affiché sur un tableau blanc dans le couloir, vous ou l'équipe de rappeler ce que
qui doit être fait. Et spécifiques à PMs: avec un projet de calendrier en place, des questions sur la façon réaliste
certaines choses sont peuvent être soulevées, et les comparaisons peuvent être faites entre ce que le projet est en cours de
demandé à voir avec ce qui semble être possible dans un laps de temps donné.

Ce changement psychologique ou la pression est ce qu'on appelle une fonction de forçage. Une fonction de forçage est rien
quelorsque mettre en placenaturally force un changement de perspective, l'attitude ou le comportement. Ainsi, les horaires
sont fonctions de forçage important pour les projets. Si elle est utilisée correctement par un PM, horaires forcer tout le monde
dont le travail apparaît sur eux de réfléchir attentivement à travers le travail qu'ils doivent faire et comment il se glisse dans
ce que font les autres. Cette prise de conscience de la relation entre les parties est un peu indépendant de
le calendrier lui-même. Cette fonction de forçage est une étape cruciale vers la réalisation du potentiel du projet.
Même si les bulletins de annexe, est doublé, est réduite de moitié, ou passe par une variété d'autres tortueux
permutations, les engagements et les connexions tout le monde a fait un avec l'autre sera
entretenu. Donc, ce deuxième but d'un calendrier peut être atteint et peut être entièrement vaut le
l'effort de créer un calendrier, même si le calendrier lui-même se révèle être gravement inexacte. Pour
par exemple, si le projet vient très tard, l'existence d'un calendrier sera essentiel pour aider le
projet portée achèvement du tout.

Le troisième but des horaires est de donner à l'équipe un outil pour suivre les progrès et de briser le travail en
gérables. Briser les choses en tailles de un ou deux jours aide réellement les gens à
comprendre ce que le travail est que ce qu'ils doivent faire. Imaginez si, lors de la construction d'une maison, le constructeur
a donné un élément de ligne: "Maison:. 120 jours" Avec une telle faible granularité, il est difficile pour quiconque, y compris
le constructeur lui-même, de comprendre que les choses doivent être fait en premier, ou qui sont des éléments de travail de la
le plus cher ou de temps. Mais si le constructeur peut fournir une ventilation semaine par semaine de
activités, tout le monde a une meilleure compréhension de ce que les tâches seront effectuées lors, et chaque équipe
membre a une plus grande occasion de poser les bonnes questions et de clarifier les hypothèses. De la PM de
point de vue, un bon horaire donne une vision plus claire du projet, débusque défis et
oublis, et augmente les chances que les bonnes choses vont arriver.

La plus grande et plus complexe du projet, les horaires plus importantes sont. Dans les grands projets,
il n'y a plus de dépendances entre les gens, et les décisions et les horaires ont plus de chances de
impactant autres. Lorsque vous avez une poignée de personnes qui travaillent sur une petite équipe, les chances de personnes
des difficultés à reconnaître dans le travail de l'autre sont beaucoup plus élevés. bordereaux de programme en petites équipes ne sont pas

Page 30

bonnes nouvelles, mais, dans un tel cas, un bordereau demi-journée représente une demi-journée supplémentaire d'énergie pour trois
personnes seulement, donc la récupération est possible. Quelqu'un peut rester tard dans la nuit, ou, si nécessaire, l'équipe peut
viennent tous ensemble et d'accord pour aider à faire le temps. Sur un projet plus vaste, avec des dizaines ou
des centaines de personnes et des composants, un feuillet d'une journée peut rapidement en cascade et de créer des problèmes dans tous les
sortes de façons imprévues, ce qui est souvent au-delà du point de récupération d'une équipe. De toute façon, une grande équipe ou
petite, horaires donnent aux gestionnaires et compteurs de haricots l'occasion de poser des questions, faire des
ajustements, et aider l'équipe par surfaçage et de répondre aux questions qu'ils se posent.

Avec ces trois objectifs à l'esprit, il est facile de voir que les horaires parfaits ne résolvent pas tous les
problèmes que les projets ont. Un calendrier ne peut pas remédier à de mauvaises pratiques de conception ou d'ingénierie, et ne peut
il protéger un projet de la faiblesse du leadership, objectifs imprécis, et la mauvaise communication. Donc, pour autant
le temps qu'il faut pour créer des horaires, ils sont encore que des listes de mots et de chiffres. Il est à
quelqu'un pour les utiliser comme un outil pour la gestion et la conduite du projet. Dans cet esprit, il est temps de
faire ressortir le grand vocabulaire et explorer methodologiesthe logiciel machinerie lourde de projet
gestion.
Page 31

2.2. Balles et des méthodologies d'argent

Il existe de nombreux systèmes différents sur la façon de planifier et de gérer le développement de logiciels. Ces
systèmes sont souvent appelés méthodologies, ce qui signifie un ensemble de pratiques visant à la réalisation d'un
certain type de résultat. Méthodes de logiciels communs incluent le modèle de cascade, le modèle spirale, rapide
Le développement d'applications, Extreme Programming, et de développement axée sur Feature. Tous ces
méthodes tentent de résoudre organisation et de gestion de projet à des problèmes similaires. Ils ont chacun
forces et faiblesses, et il faut des connaissances et de l'expérience de décider qui on est bon pour
ce genre de projet.

Mais mon objectif dans ce chapitre, et dans ce livre, est de ne pas débattre et comparer les différentes méthodologies ou
systèmes pour faire les choses. Au lieu de cela, je crois qu'il ya des concepts et des tactiques qui les sous-tendent tous et
qui doivent être maîtrisées afin de réussir avec toute méthodologie. Dans tous les cas, les méthodes
doivent être ajustés et adaptés pour répondre aux spécificités d'une équipe et d'un projet, et cela est possible seulement
si vous avez une base de connaissances qui est plus profond que les méthodes elles-mêmes. Donc, si vous
peut comprendre et pratiquer les idées sous-jacentes décrites dans ce chapitre et dans le reste de la
livre, vos chances d'être efficace augmentera, indépendant de la méthodologie que vous utilisez. Je vais
expliquer les aspects de certaines méthodes que nécessaire pour clarifier certains points, mais vous aurez à chercher ailleurs si
vous êtes méthodologie shopping. (2)

Bien que les méthodes et les processus de développement de logiciels sont très importants, ils ne sont pas et
d'eux-mêmes balles en argent, ou libérateurs de bons résultats. La pire chose est de suivre aveuglément
un ensemble de règles ou de procédures qui sont clairement ne fonctionnent pas, tout simplement parce qu'ils apparaissent dans certains
livre célèbre ou sont promus par un gourou très respecté. Plus souvent qu'autrement, je l'ai trouvé que
obsédé sur le processus est un signe d'avertissement du leadership du mal: elle peut être une tentative de décharger le
défis et responsabilités naturelles que les gestionnaires sont confrontés dans un système de procédures et
bureaucraties qui obscurcissent la nécessité d'une réelle pensée et d'action. Peut-être encore plus dévastateur à un
l'équipe est que la méthode de fixation peut être un signal de ce qui est vraiment important pour l'organisation. Comme
Tom DeMarco écrit dans le livre PeopleWare :
 L'obsession de méthodologies dans le milieu de travail est un autre exemple de la high-tech
illusion. Il découle de la conviction que ce qui importe vraiment est la technologie .... Quelle que soit la
avantage technologique peut être, il peut venir seulement au prix d'une aggravation significative de la
La sociologie de l'équipe.

En mettant l'accent sur la méthode et la procédure, à la place des procédures de construction pour soutenir et amplifier le
valeur des personnes, des projets démarrer le processus de planification en limitant les contributions des individus.
Ils peuvent donner un ton de règles et règle suivante, plutôt que de penser et de la règle d'ajustement ou de la règle
amélioration. Alors, soyez très prudent de la façon dont vous appliquez peu importe la méthode que vous utilisez: il ne devrait pas être
quelque chose infligé à l'équipe. Au lieu de cela, il devrait être quelque chose qui soutient, encourage et
assiste l'équipe en faisant du bon travail sur le projet. (3)

Alors, rappelez-vous que l'utilisation d'une méthode ou d'une autre est jamais la seule raison pour un projet
faire ou manquant ses dates. Au lieu de cela, il ya des facteurs que les calendriers des projets d'impact tous, et projet
les gestionnaires doivent les comprendre avant tout travail d'ordonnancement est jamais fait. Mais avant de parler
à ce sujet, nous avons besoin pour couvrir les composants d'un calendrier.

Page 32

2.3. Qu'est-ce que les horaires ressembler

Il ya une règle de base pour tous les horaires: la règle des tiers. Il est extrêmement rugueuse
estimation et back-of-the-enveloppe genre de chose, mais il est la façon la plus simple d'aborder et de
comprendre les horaires. Si vous êtes expérimenté avec la programmation, se préparer à aller à cringeI'm
simplifier l'ensemble du processus. Je fais cela pour fournir le pied plus simple possible de parler
ce qui tend à aller mal, pourquoi cela se produit, et ce qui peut être fait à ce sujet.

Voici comment le modèle ultrasimplified pour la planification fonctionne: pour tout projet, briser le temps disponible
en trois partsone pour la conception, l'un pour la mise en œuvre, et un pour les tests. En fonction de la
méthodologies que vous utilisez, ces phases seront appelés des choses différentes, ou ils peuvent se chevaucher les uns avec les
d'autres à certains égards, mais toutes les méthodes ont le temps consacré à ces trois activités. Sur tout
jour donné, vous êtes soit de déterminer ce qui doit être fait (conception), le faire réellement
(La mise en œuvre du code de production), ou de vérifier, analyser, et d'affiner ce qui a été fait (les tests).

2.3.1. L'application de la règle des tiers

Comme la règle générale va, pour chaque jour vous vous attendez à écrire du code de production, une journée aurait dû être
consacré à la planification et la conception du travail, et un jour doit être prévu de tester et d'affiner ce travail
(Voir Figure 2-1 ). Il est la chose la plus simple du monde, et il est un moyen facile d'examiner toute existante
planifier ou à démarrer une nouvelle à partir de zéro. Si la quantité totale de temps est divisé en pas plus ou moins le
trois types de travaux, il devrait y avoir des raisons bien compris pourquoi le projet exige une inégale
répartition de l'effort. Les déséquilibres dans la règle de thirdssay, 20% plus de temps consacré à des tests de
implementationare bien tant qu'ils sont délibérées.

Figure 2-1. Le calendrier du projet plain vanilla règle de tiers.

Envisager un projet de développement web hypothétique: si vous êtes donné six semaines pour le lancer, la première
 étape devrait être de diviser cette époque à peu près en trois tiers, et, en utilisant ces divisions, faire des calculs
quand le travail peut être achevé. Si cela ne donne pas assez de temps pour faire le travail prévu au
un niveau élevé, alors quelque chose est fondamentalement faux. Soit le calendrier doit changer, ou de la
quantité de travail devrait être achevé doit être réduit (ou des attentes de nécessité de la qualité
être abaissée). Recadrage à partir du moment de la conception ou de test ne fera qu'augmenter les chances que le temps
passé l'écriture de code sera en fait erronée ou se traduira dans le code qui est plus difficile à gérer et
maintenir. La règle des tiers est utile en ce qu'il oblige la nature à somme nulle de projets à la surface.
Ajout de nouvelles fonctionnalités nécessite plus que juste un programmeur leur mise en œuvre; il y a
conception inévitable et les coûts des essais que quelqu'un doit payer. Lorsque les horaires glissent, il est parce que
il y avait des coûts cachés ou ignorés qui ne sont jamais comptabilisés.

Page 33

2.3.1.1 Le morcellement du développement (le projet anti-projet)

Pour être complet, il est utile d'examiner le cas le plus simple possible: il n'y a pas de projet. Tout le travail est
fait sur une basisrequests fragmentaires venir, ils sont évalués par rapport à d'autres travaux, et puis ils
sont mis dans le prochain emplacement disponible sur le calendrier. Certaines équipes de développement, les développeurs de sites web,
ou IT programmation départements fonctionnent à peu près de cette façon. Ces organisations font rarement
investissements ou les engagements dans les grands incréments. Les méthodes agiles (discutés prochainement) sont souvent
recommandé à ces équipes comme le système le plus naturel pour l'organisation du travail, car ceux-ci
méthodes soulignent la flexibilité, la simplicité, et les attentes de changement. Si vous travaillez sur plusieurs petits
affectations (pas de projets) à la fois, vous aurez à extrapoler à partir des exemples de projets-centric
Je l'utilise dans ce livre.

Toutefois, la règle des tiers applique toujours à ces situations. Même si chaque programmeur travaille
seul sur de petites tâches, il est probablement dépenser environ un tiers de son temps total de déterminer ce
qui doit être fait, un tiers de son temps à le faire, et un tiers en vous assurant qu'il fonctionne correctement. Il
pourrait aller et venir entre ces usages du temps, mais comme une façon grossière de comprendre tout genre
de travail, la règle des tiers applique bien à toute échelle.

2.3.2. Diviser pour régner (grandes horaires = beaucoup de petites annexes)

Si vous examinez la plupart des méthodologies de développement de logiciel, vous pouvez voir les contours de l'Etat de
tiers. Les objectifs et les approches spécifiques utilisées pour concevoir ou mettre en œuvre les choses peuvent être très différentes,
mais au plus haut niveau, les résultats souhaités sont similaires.

Là où ça devient complexe est sur des projets plus importants ou plus, où les horaires sont divisés en plus petits
pièces, avec chaque pièce ayant sa propre conception, mise en œuvre, et de temps à tester. Extrême
Programmation (connu sous XP) appelle ces pièces itérations; le modèle de la spirale les appelle phases; et
certaines organisations appellent les jalons. Alors que XP implique que ces morceaux de temps sont seulement quelques-uns
semaines, et le modèle de la spirale implique qu'ils sont des mois, l'idée fondamentale est la même: créer
calendriers détaillés pour des périodes limitées de temps seulement.

La volatilité plus de changement et de projet qui est prévu, la plus courte à chaque étape devrait être. Ce
abaisse la quantité de risque global dans le calendrier parce que le plan directeur a été divisé en
gérables. Ces pauses entre les morceaux de l'horaire offrent des possibilités naturelles à
faire des ajustements et améliorer les chances que la prochaine étape sera directe avec plus de précision son
travail. (Nous verrons comment faire cela dans le chapitre 14 .)

2.3.2.1 Les méthodes agiles et traditionnelles

XP et d'autres méthodes agiles supposent l'avenir est toujours volatile, ils misent sur les processus qui
incorporer facilement des changements de direction. Projets qui ont des coûts de production très élevés (par exemple, la construction d'un
gratte-ciel, une console de jeu vidéo, ou un système d'exploitation embarqué) vont dans l'autre sens et d'investir
fortement dans les activités de planification et de conception. Il peut être fait, mais tout le monde doit engager à la
les décisions prises lors de la planification, et le coût prohibitif des changements tend à être la seule façon que
qui se passe.

La plupart des projets de développement de logiciels sont quelque part au milieu. Ils ont un peu de planification initiale,
mais pour aider à gérer la volatilité future des besoins et des demandes des clients, le travail est divisé en
phases qui ont affecté du temps pour la conception, la mise en œuvre, et l'assurance de la qualité. Si une nouvelle émission
se pose, il peut être considéré pour la phase actuelle ou mis dans le seau de travail soit correctement
étudiée et comprise au cours de la prochaine phase.

Pour la plupart des projets, que le temps de la planification initiale est utilisée pour capturer suffisamment d'informations des clients
et les gens d'affaires pour définir combien de phases sont nécessaires et ce que l'accent devrait être pour chacun
(Voir Figure 2-2 ). Selon le plan plus vaste, chaque phase peut consacrer plus de temps à concevoir ou à
test. Une phase pourrait être divisé en deux phases plus petites (approche d'un style plus agile
développement), ou deux phases pourraient être combinés ensemble (approche plus monolithique
le développement). Mais dans tous les cas, le temps devrait être réparti entre les phases de profiter de ce que
a changé. Cela comprend la réponse aux problèmes qui ont surgi au cours de la phase précédente, qui

Page 34
 ne pourrait pas être pleinement prises en compte au cours de cette phase.

Figure 2-2. Un grand projet doit être une séquence de petits projets.

Voilà autant que je vais aller dans la méthodologie de planification de haut niveau. Les chapitres 14 et 15 volonté
couvrent comment gérer un projet à travers l'ensemble de la programmation, mais ils vont se concentrer sur la gestion et
le leadership perspectivesnot sur les détails de la façon dont vous avez appliqué une méthodologie particulière. Si vous
pourrait suivre les derniers paragraphes (même si vous ne pas complètement d'accord avec les points soulevés dans
eux), puis les conseils donnés dans les chapitres 14 et 15 doivent être pertinentes et utiles, quel que soit le
vous avez organisé ou planifié votre projet.

Quoi qu'il en soit, je présente mes excuses à tous les anciens combattants de développement qui passaient sur ou est tombé malade pendant cette section.
Maintenant qu'il est fini, je vous promets que ce point de vue léger et simple de la programmation est presque tout ce que vous
besoin afin de comprendre les concepts dans le reste du chapitre.

Page 35

2.4. Pourquoi horaires échouent

les calendriers de projet sont les boucs émissaires faciles pour tout ce qui peut aller mal. Si quelqu'un
Fudges une estimation, manque une exigence, ou se fait frapper par un autobus, il est le calendrier (et la personne
responsable de lui) qui attire le blâme. Si l'alimentation de la nation était de sortir pendant 10 jours, ou
meilleurs programmeurs de l'équipe étaient d'attraper la peste, toujours quelqu'un disait: «Vois, je dis
vous le calendrier serait glisser »et remuer son doigt dans le visage du maître d'horaire. Il est totalement injuste,
mais il arrive tout le temps. Autant que les gens détestent les horaires, ils détiennent toujours leur place à un
norme irréalisable. Même les meilleurs planificateurs dans le monde, avec les plus intelligents et les meilleurs esprits
 outils à leur disposition, tentent toujours de prédire les futuresomething nos espèces ne rarement
bien.

Mais si une équipe commence un projet pleinement conscient des raisons probables horaires tombent en morceaux et prend un certain
des mesures pour minimiser ces risques, le calendrier peut devenir un outil plus utile et précis dans le
processus de développement.

2.4.1. Tir aveugle de très, très loin

Si un programme est créé lors de la planification initiale, des centaines de décisions qui peuvent influer sur le calendrier
ont pas encore été fait. Il y aura des problèmes et des défis, dont personne ne peut prévoir, et il n'y a pas
manière un plan spéculative précoce peut éventuellement rendre compte. Jusqu'à exigences sont comprises et
conception de haut niveau est bien en cours, un gestionnaire de projet est trop aveugle et a trop peu d'informations pour
faire des prédictions réalistes. Pourtant, la plupart du temps, un calendrier approximatif coupe est créé avec confectionnés
des chiffres et des spéculations sauvages, et cet homme de paille est remis à l'équipe sous le couvert d'un
plan de projet crédible. Souvent, les gens sont victimes de la précision par rapport à la précision piège: un
calendrier avec des dates et heures précises (précision) impressionnante prospectifs ne constituent pas nécessairement près de
la réalité reflétant (précision). La précision est facile, mais la précision est très difficile.

Cependant, il est vrai que tous les projets et les horaires doivent commencer quelque part. Un tir dans la boîte noire
être utilisé pour dynamiser une équipe et de mettre certaines limites en place. Il peut entamer un processus de
enquête pour étoffer les horaires et d'élever et de répondre à des questions importantes. Mais si un non vérifiée
et la spéculation de balayage non examinée est utilisé comme base pour un autre schedulewithout
risques refinementgreat attendent. Il existe des preuves solides qu'il est difficile pour quiconque d'estimer la
quantité de temps nécessaire au début d'un projet.

Barry Boehm, dans son essai sur 1989 en génie logiciel, (4) trouvé échelle des erreurs de planification dans
rapport à la façon au début de l'estimation de l'échéancier du projet est fait (comme le montre la Figure 2-3 ). Si le total
estimations de calendrier sont faites tôt, ils peuvent être hors d'autant que 400%, dans les deux sens (je
soupçonnent les erreurs sont biaisés contre nous, qui tend à prendre plus de temps que ce que nous attendons, bien que son
les données ne montre pas cela). Lors de la conception, que plus de décisions deviennent claires, la variance se rétrécit, mais il est
encore grande. Il est seulement quand le projet est la mise en œuvre que la gamme de calendrier estimation
devient raisonnable, mais même alors, il ya encore un swing de 20% des décisions d'ordonnancement comment précises
sont susceptibles d'être.

Figure 2-3. La gamme des erreurs d'estimation lors de projets (adapté de

Logiciel de Boehm Engineering Economics).

Page 36

Cela signifie que les gestionnaires de projet doivent comprendre que le calendrier estimation pousse dans la précision
au fil du temps. Horaires exigent que l'attention est accordée à leur mesure des progrès réalisés, et que
des ajustements sont apportés que le projet avance.

2.4.2. Un calendrier est une probabilité

Quand je suis fraîchement sorti du collège et de travailler sur mes premiers quelques grands projets (Windows et Internet
Explorer), les horaires de haut niveau serait rendu à mon équipe par quelqu'un beaucoup plus
important que I. Être trop subalterne pour avoir beaucoup implication dans le processus, le calendrier serait
présenté un jour, et il était de mon devoir de demander que le calendrier de maître pour le petit nombre de
 programmeurs et testeurs qui je travaillais.
Alors que nous avons fait de négocier sur les différences entre ce calendrier de maître et le calendrier généré par
mon équipe sur la base des éléments de travail, (5) que le calendrier de haut niveau a toujours semblé apparaître de nulle part.
Il descendait d'en haut, soigneusement formaté, décomposé en de belles colonnes de dates et
numéros. Il était comme un artefact volé à l'avenir.

Peu importe la façon sarcastique ou cynique nous étions, pour la plupart, nous avons suivi ces horaires fidèlement.
Malgré le mystère de leurs origines, nous avions de bonnes raisons de faire confiance à nos chefs d'équipe, et nous étions occupés
assez avec notre propre travail de ne pas trop se soucier de la leur. (En fait, ils sont souvent fournis de base
explications pour ces listes initiales de haut en bas, mais nous étions trop occupés et trop confiant à payer
beaucoup d'attention.)

Plus tard, quand la programmation est devenue quelque chose que je étais responsable, je me suis rendu la vérité tacite
sur les horaires. Ils ne sont pas des dons de l'avenir. Il n'y a pas de formule magique ou de la science pour
la création d'horaires parfaits. Malgré mes perceptions de jeunesse, la programmation est pas une tâche isolée: il
représente toujours et englobe de nombreux aspects différents de ce que le projet est maintenant et sera
plus tard. Les horaires sont tout simplement une sorte de prédiction. Peu importe comment précisément ils sont rédigés ou comment
convaincre qu'ils apparaissent, ils sont juste une sommation de beaucoup de petites estimations, chacune inévitablement
sujettes à différents types d'oublis et problèmes imprévisibles. Bonnes horaires viennent seulement d'un
leader ou une équipe qui poursuit et réalise un bon jugement dans de nombreux aspects différents de relâche
développement de logiciels. Vous ne pouvez pas être un expert dans une partie étroite de la décision de choses et toujours
attendre à bien planifier.

Donc, si tout le monde dans l'équipe peut convenir que le calendrier est un ensemble de probabilités, alors le problème
est pas dans le calendrier itselfit est dans la façon dont le programme est utilisé. Si jamais un calendrier est montré dans une équipe
de réunion, ou envoyé autour de courriel, une question valable est la suivante: comment probable est le calendrier défini? Sinon
probabilité est proposé (par exemple, ce que les cinq risques les plus probables sont une spéculation et sur la probabilité de
leur occurrence), et celui qui fait le calendrier ne peut pas offrir des explications quant aux hypothèses
elle est prise, il faut toujours supposer que le calendrier est possible, mais improbable. (6) Il
devrait être ouvert à l'équipe de faire des suggestions quant à ce que des considérations ou des informations peuvent être
ajouté ou modifié dans le programme pour le rendre plus probable.

Page 37

Ainsi, le secret ici est que le calendrier n'a pas à être parfait (qui est un soulagement, bien sûr, parce
il n'y a pas des horaires parfaits). Horaires doivent être assez bon pour l'équipe et les dirigeants à
croire, fournir une base pour le suivi et faire des ajustements, et ont une probabilité de succès
qui satisfait le client, l'entreprise ou le sponsor global du projet.

2.4.3. Estimation est difficile

Au cours du processus de conception (couverte en chapitres 5 et 6 ), une partie du travail pour les concepteurs,
programmeurs et testeurs est de briser la conception en petits morceaux de travail qui peuvent être construits.
Ces morceaux, souvent appelés les éléments de travail ou une structure de répartition du travail (WBS 7 ), devenue la ligne
articles dans le schéma directeur pour le projet. Les éléments de travail sont (croisons les doigts) intelligemment
distribués (8) à travers l'équipe de programmation, et en les récoltant jusqu'à, un calendrier est créé. Chaque
de ces éléments de travail doit avoir une quantité de temps qui lui est attribué par le programmeur, et sur la
base de ces estimations, le calendrier est construit.

Par la définition la plus simple, de bonnes estimations de travail ont une forte probabilité d'être précis, et le mauvais
estimations de travail ont une faible probabilité. Je ne vous attendez pas à gagner des récompenses pour ces définitions, mais
elles ne impliquent au moins une chose utile: il est le jugement des chefs d'équipe qui définit la barre pour une
compte tenu de projet. Elle exige un processus actif de la révision des estimations et poussant, leader, et
poussant les autres à les obtenir au niveau qu'ils doivent être. Je pense qu'il est intelligent de faire participer ouvertement à la
équipe de test / QA dans le processus d'estimation, les laissant participer aux discussions de conception et de demander
questions ou offrir des commentaires. Au minimum, cela va les aider dans leurs propres estimations pour
travaux d'essai, qui peut ne pas correspondre aux estimations de travail de programmation. Souvent, AQ a le meilleur
aperçu oublis de conception et de cas de défaillance potentiels que les autres vont négliger.

2.4.3.1 Le monde est basé sur l'estimation

Une chose qui rend difficile la planification est que peu de gens apprécient estimer les choses complexes qui
ils seront tenus pour responsables. Il est toujours amusant de se vanter et faire des paris sur nos compétences ("Cette
Site livre / film / web pue: Je pourrais faire un soooo beaucoup mieux "), mais quand nous sommes pressés à l'étape
et deliversigning nos noms sur un contrat détaillant notre responsibilitythings changement. Nous savons
qu'il est tout à fait possible que tout ce que nous nous engageons à faire aujourd'hui pourrait être impossible ou
indésirable à faire le moment venu. Il pourrait se révéler plus difficile que nous le pensions.
Les programmeurs sont comme tout le monde et ont de bonnes raisons d'avoir une estimation de l'anxiété. Par
disant que quelque chose peut être fait dans un certain laps de temps, ils risquent d'être très mal.

Dans mon expérience, même les programmeurs qui comprennent le processus d'estimation et croient en elle, ne le font pas
tiens à le faire. Une partie est l'inadéquation de l'imagination («Comment ce travail, compte tenu de la très limité
informations dont je dispose? ") avec une précision temporelle (" Dites-moi exactement combien d'heures cela va prendre pour
faire ») Mais la sympathie ici devrait être limitée:.. tout le monde qui travaille dans l'ingénierie et de la construction
a le même genre de défi, que ce soit pour la construction de gratte-ciel, le remodelage de la cuisine, ou
lancement de vaisseau à atterrir sur d'autres planètes. De la lecture sur la façon dont ces gens estiment choses,
 il ne semble pas que leurs défis ou techniques sont fondamentalement différents de ce que le Web
les développeurs et les ingénieurs logiciels sont confrontés. La principale différence est dans combien de temps ils sont donnés
pour générer des estimations et comment ils sont disciplinés dans l'utilisation de ce temps ( chapitres 5 et 6 sera
discuter de cela en détail).

2.4.4. De bonnes estimations proviennent de bons dessins

Pour le crédit de programmeurs partout, la chose la plus importante que je l'ai appris sur le bien
estimations est qu'ils ne viennent que de dessins et exigences crédibles. Bon génie
Les estimations ne sont possibles que si vous avez deux choses: une bonne information et de bons ingénieurs. Si le
specs sont de la merde, et un programmeur est invité à évoquer un nombre basé sur une incompréhensible
tableau blanc gribouillage, tout le monde devrait savoir exactement ce qu'ils obtiennent: un gribouillage floue d'un
estimation. Cela signifie que de bonnes estimations sont l'affaire de tous, et il devrait être le travail du
les gestionnaires et les concepteurs dans particularto TeamProject entières font ce qu'ils peuvent pour soutenir ingénieurs

Page 38

faire des estimations crédibles. Si l'estimation se sent comme une corvée et un projet de comptabilité, ou si l'équipe
les dirigeants ne sont pas investis dans le processus, ne vous attendez pas des estimations fiables ou probables.

Si les dirigeants reconnaissent estimations faibles dans le calendrier et sont à l'aise avec plus de calendrier
risque, il n'y a rien de mal avec les estimations faibles. Sur les petits projets, plus rapides, des estimations approximatives peut
être tout ce que le projet a besoin. Les exigences peuvent être changent souvent, et la nature de l'entreprise
ou l'organisation pourrait exiger moins de structure et plus de flexibilité. Il n'y a rien de mal avec faible
estimations de qualité, à condition que personne ne les confondre avec ceux de haute qualité.

Une technique utile ai trouvé était que chaque fois qu'un programmeur rechigné à donner une estimation, je demanderais,
"Quelles sont les questions que je peux répondre à cette question vous rendrait plus confiants au sujet de donner une estimation?" Par
obtenir de lui pour être précis, je lui ai donné l'occasion de confronter la peur ou la frustration qu'il pourrait
sens, ce qui m'a permis d'aider à résoudre son problème. Bien sûr, je dois aider à trouver des réponses à ses
questions et débattre éventuellement les questions que je sentais qu'il était son travail pour enquêter, mais au moins nous seraient
parler de l'obtention de meilleures estimations.

Voici quelques moyens supplémentaires pour assurer de bonnes estimations:

Établir des intervalles de confiance de référence pour les estimations . Une confiance conjecture = 40% dans
exactitude. Une bonne estimation = 70%. Une analyse détaillée et approfondie = 90%. Chefs d'équipe
se mettre d'accord sur la façon précise qu'ils veulent estimations soient, ainsi que la quantité de temps
les programmeurs auront pour leur faire et comment les risques d'estimations manqués seront
géré. Ne pas se focaliser sur les chiffres: il suffit de les utiliser pour aider à rendre la qualité des estimations
béton. Une estimation de 90% devrait être sur le nez 9 fois sur 10. Si vous décidez de demander à votre
équipe pour améliorer la qualité des estimations, vous devez faire correspondre cette demande plus de temps pour eux
faire cela.

Programmeurs de plomb doivent mettre la barre pour les estimations de qualité par poser les bonnes questions
et en prenant sage approches que l'équipe peut émuler . Faites tout ce qui est nécessaire pour tuer
la motivation de commentaires sarcastiques ou rétropédalage (par exemple, «Ne me touche pas à cette", "Il est juste un
deviner ", etc.). Découvrez les besoins légitimes qu'ils ont pour délivrer de bonnes estimations, et à l'arrière
vers le haut avec le temps nécessaire pour répondre aux objectifs estimation de qualité.

Les programmeurs doivent faire confiance . Si votre chirurgien du cerveau vous dit l'opération vous avez besoin
prend cinq heures voulez-vous la pression lui de le faire dans les trois? J'en doute. Parfois, la pression a
à appliquer pour garder les gens honestbut seulement comme une mesure d'équilibrage (la nécessité canonique pour
ceci est un programmeur qui donne des estimations élevées pour des choses qu'elle ne aime pas, et faibles pour les
les choses qu'elle fait). À l'occasion, obtenir plusieurs estimations (à partir de deux développeurs différents)
peut être une façon de faire un test de cohérence.

Les estimations dépendent de la compréhension du programmeur des objectifs du projet . Estimations

sont basés sur l'interprétation d'un programmeur non seulement des spécifications de conception (si elles existent),
mais aussi les buts et les objectifs du projet. Dans Gerald Weinberg est The Psychology of Computer
Programmation (Dorset House, 1971), il enregistre comment le manque de clarté à propos de niveau supérieur
objectifs a une influence directe sur les hypothèses de bas niveau programmeurs font. Aussi clair que
le problème technologique pourrait être, l'approche du programmeur pour le résoudre pourrait changer
considérablement selon les intentions de haut niveau de l'ensemble du projet.

Les estimations doivent être fondées sur la performance précédente . Il est une bonne habitude pour les programmeurs
de suivre leurs estimations sur les projets. Il devrait faire partie de leurs discussions avec leur manager,
qui devrait être intéressé par la compréhension qui, de leur équipe est meilleure à estimer ce que.
Extreme Programming utilise le terme de vitesse de se référer à un programmeur (ou de l'équipe de) probable
performance, basée sur la performance précédente. (9)

Spécification ou la qualité de la conception devrait être de quelque point l'ingénierie doit

faire de bonnes estimations . Ceci est une négociation entre la direction et les programmeurs projet.
Plus la qualité des estimations désirées, plus la qualité des spécifications devraient être.
Nous parlerons plus de bonnes spécifications dans le chapitre 7 .

Il existe des techniques connues pour la réalisation de meilleures estimations . Le plus connu
technique est PERT, (10) qui tente de minimiser les risques en faisant la moyenne haute, moyenne et faible
estime pour le travail. Ce qui est bon pour deux raisons. Premièrement, il oblige tout le monde à réaliser des estimations
sont des prédictions, et qu'il ya un éventail de résultats possibles. Deuxièmement, il donne projet
Page 39

aux gestionnaires la possibilité d'étrangler façon agressive ou prudente les horaires sont (plus de poids
peut être appliquée à l'égard des estimations basses ou élevées).

2.4.5. Les oublis communs

Bien que de bonnes estimations vont un long chemin vers l'amélioration des horaires, un grand nombre des facteurs qui ont un impact
calendrier coupait postes individuels. Le piège cela crée est que, malgré la façon parfaite et
merveilleux toutes les estimations pour les éléments de travail sont, les risques réels d'horaire sont les choses ne sont pas rédigés
vers le bas. Tandis qu'il est vrai que les chances de contracter la peste sont minces dans la plupart des régions du monde, la
la probabilité d'un ingénieur importante attraper la grippe ou de partir en vacances est assez élevé. Il y a un
ensemble commun de ces oublis de calendrier que tous les gestionnaires de projet ont besoin de se familiariser avec. La
problème est qu'il est souvent seulement après que vous avez été brûlé par un contrôle que vous êtes prêt à regarder
pour elle à l'avenir. Voilà pourquoi la gestion de projet et la gestion de calendrier, en particulier,
exige de l'expérience pour devenir compétent. Il ya trop de façons différentes à l'échec, et aucun moyen de
pratiquer à leur recherche, sans être responsable de leurs conséquences.

Voici ma liste des animaux de compagnie de questions qui me ont aidé à détecter les problèmes d'horaire potentiels dès le début.
La plupart de ces venaient de poser des questions sur ce qui a mal après un projet a été achevée,
et essayer de trouver une question que quelqu'un aurait pu demander dès le début qui aurait évité le
problème. (Ce qui manquait? Ce qui n'a pas représenté? Quelle aurait fait une différence ou
me aurait permis de prendre des mesures correctives?)

Jours de maladie et de vacances pour tous les cotisants étaient inclus dans une certaine forme dans le calendrier?

Avez personnes ont accès à l'horaire, et étaient-ils invités à rendre compte des progrès réguliers (en
une manière non gênant)?

Était quelqu'un en regardant le calendrier global sur une base quotidienne ou hebdomadaire? Cette personne ne possède
assez d'autorité pour poser les bonnes questions et faire des ajustements?

L'équipe a fait sentir appropriation et l'engagement à l'horaire? Si non, pourquoi? L'équipe at-
contribuer à la définition de l'horaire et le travail à faire, ou at-il été transmis à
leur?

Ont-chefs d'équipe ajouter plus de demandes de fonctionnalités que ce qu'ils ont aidé à éliminer? Avez-chefs d'équipe jamais
dire pas de nouveaux travaux et de fournir une philosophie raisonnable de l'équipe pour savoir comment répondre à
nouvelles (tardives) demandes?

Ont été membres de l'équipe encouragés à et soutenus dans disant pas à de nouvelles demandes de travail qui
ne correspondait pas aux objectifs et la vision?

Qu'est-ce que les probabilités ont été utilisés pour faire des estimations? 90%? 70%? 50%? Était-ce exprimée en
le schéma directeur de haut niveau? Le client / VP / client était au courant de cela? Était ici
débat d'une autre proposition qui a pris plus de temps mais il est venu avec une probabilité plus élevée?

Y at-il des moments périodiques dans le calendrier lorsque des ajustements de calendrier et des renégociations
pourrait avoir lieu par les dirigeants et la gestion?

Le calendrier ne suppose moins d'heures de travail de plus de saisons de vacances? (Aux États-Unis, Thanksgiving
Noël est souvent un moment de faible productivité.) Y at perturbations météorologiques hautement probable
les événements ont pesé dans le calendrier (par exemple, les blizzards, les tornades à Chicago dans le Kansas, le soleil
à Seattle)?

Étaient les spécifications ou la conception des plans assez bon pour l'ingénierie de faire du bon travail
estimations?

Ingénierie a été formé ou expérimenté dans la prise de bonnes estimations de travail?

2.4.6. L'effet boule de neige

Page 40

La chose la plus déprimante de la liste précédente est que même si vous obtenez plus de ce droit, en raison de
comment interdépendants chaque contribution est d'un calendrier, il est toujours facile pour les horaires de glisser. Chaque
la décision de l'équipe permet, à partir des choix de conception les estimations, est à la base de bon nombre des décisions
qui suivent. Un oubli tôt dans le processus que l'on découvre plus tard aura un amplifiée
impact sur le projet. Ce comportement de compoundage des horaires est facile de sous-estimer parce que le
cause à effet ne sont pas souvent visibles dans le même temps (vous pouvez voir la manière de l'effet après que la cause
eu lieu). Dans les pires cas, lorsque plusieurs oublis majeurs se produisent, les chances d'un calendrier tenant
ensemble sont minces à aucun (voir Figure 2-4 ).
 Figure 2-4. L'effet boule de neige.

Et bien sûr, cela devient encore plus difficile. La façon dont fonctionne est la probabilité que la probabilité d'une série de
événements indépendants se produise est la multiplication de la probabilité de chaque épreuve individuelle (aussi
connu sous le nom probabilité composée). Donc, si la probabilité de vous finir ce chapitre est de 9 sur 10
(10/09), et la probabilité de finition vous est la suivante 10/09, la probabilité totale de finition vous
deux chapitres ne sont pas 9/10: il est de 81/100. Cela signifie que si votre équipe est de 90% probable fait son
Dates chaque semaine, au fil du temps les chances d'un glissement qui se déroulent continuellement augmenter. Probabilité froid et
sans cœur, et il nous aide à nous rappeler que l'entropie est partout et ne sont pas l'ami de projets ou
leurs gestionnaires.

Page 41

2.5. Ce qui doit arriver pour les horaires de travail

Maintenant que nous comprenons pourquoi les horaires sont si difficiles à maintenir, je peux vous donner des conseils sur la façon de
minimiser les risques et maximiser les avantages de toute l'échéancier du projet. Ces approches et
comportements recoupent les rôles ou les milieux traditionnels, qui, je crois, reflète la véritable nature de
ordonnancement. Parce que le calendrier représente la totalité du projet, la seule façon d'utiliser
horaires est effectivement de comprendre quelque chose au sujet de toutes les choses qui doivent arriver pour
réussite du projet. Il est une tâche interdisciplinaire, pas seulement un génie ou de gestion
activité.

longueur de Milestone doit correspondre à la volatilité du projet . Le plus de changements que l'on attend, la
les étapes plus courtes devraient être. Petits jalons fixés l'équipe en place à la mi-jeu plus facile
ajustements. Cela donne des intervalles de gestion plus court entre deux examens, et il réduit le
risques de faire des changements. L'équipe peut être préparée à attendre à des changements sont à l'étape des croisements,
afin qu'ils attendre à des changements au lieu de lui résister.

Soyez optimiste dans la vision et sceptique dans le calendrier . Un défi psychologique majeur
pour la planification est de faire usage de scepticisme correcte, sans dégonfler la passion et
la motivation de l'équipe. Contrairement à la création d'un document de vision, où l'esprit et l'optimisme
à propos de l'avenir doit régner, un calendrier doit venir du point de vue opposé. La
chiffres qui sont ramenés à estimer combien de temps les choses devraient prendre nécessiter une brutale et
 le respect sincère de la loi de Murphy ("Qu'est-ce qui peut aller mal ira mal"). Horaires ne devrait pas
refléter ce qui pourrait arriver ou pourraient se produire dans des conditions optimales. Au lieu de cela, un bon horaire
déclare ce qui happendespite plusieurs choses importantes ne vont pas comme prévu. Il est
important d'avoir l'équipe de test / QA impliqués dans la planification, car ils prêtent une naturellement
œil sceptique et critique des travaux de génie.

Pariez sur le design . Le processus de conception est la meilleure assurance contre l'ignorance et inattendu
défis. Les pratiques de conception de meilleurs sont le seul moyen d'améliorer le trajet de l'équipe par le biais
la mise en œuvre et d'autres phases. compétences de conception ne sont pas les mêmes que les compétences de mise en œuvre, et
le codeur le plus fort ou le plus rapide ne sera pas nécessairement le meilleur penseur ou un problème de conception solveur.
Bon processus de conception est pas enseignée dans de nombreux programmes de sciences informatiques, en dépit de combien il était essentiel
est à la réflexion sur l'approche et les projets d'ingénierie. Voir les chapitres 5 et 6 pour en savoir plus sur
ce sujet.

points de contrôle des régimes de discussions add / cut . Horaires devraient inclure de courtes périodes de révision
où les dirigeants peuvent examiner les progrès actuels et compte de nouvelles informations ou d'un client
rétroaction. Cela devrait être intégré dans le schéma directeur et être une partie explicite de tout projet
contrat. Dans ces commentaires, les articles et les caractéristiques de travail existants peuvent être coupés, ou de nouveaux ajoutés, comme
dictée par l'analyse de la direction de la situation actuelle. Points naturels pour ces avis sont en
entre les phases, ou sur une base limitée, à la fin de chaque phase de conception ou d'exécution, mais
elles peuvent avoir lieu à tout moment, il ya de sérieuses préoccupations ou des divergences évidentes entre le plan
et la réalité. Les objectifs de ces discussions devraient être de revenir au projet de santé mentale, actualisez la
planifier, revoir les priorités des éléments, et commencer la prochaine partie du calendrier avec une clarté et la croyance en
ce qui vient ensuite (voir les chapitres 14 et 15 ).

Informer l'équipe sur la planification de la philosophie . Peu importe l'approche de calendrier ou de la technique est
utilisé, il devrait être de notoriété publique à l'équipe. Si chaque programmeur et testeur a une base
compréhension de la façon dont les horaires de travail et la gestion de projet particulier de la stratégie utilise
pour le projet actuel, ils seront en mesure de poser les bonnes questions et être plus susceptibles de comprendre
et croire en ce qui est prévu.

Évaluer l'expérience de l'équipe avec l'espace de problème . L'une des variables magiques
ordonnancement est la façon dont l'équipe est connu avec le genre de problèmes, il est invité à résoudre.
Si l'équipe est la construction d'un site Web orientée base de données, et cinq des six programmeurs ont fait
ce genre de travail plusieurs fois avant, il est juste de supposer qu'ils vont être mieux à la conception et

Page 42

estimer le travail d'une équipe qui n'a jamais fait avant. Cela devrait tenir compte fortement sur la façon dont
un calendrier agressif ou conservateur peut être.

Mesurer la confiance et l'expérience de l'équipe à travailler ensemble . Alors même que

estimations proviennent de programmeurs individuels, les programmeurs travaillent ensemble comme une unité
pour construire une chose complète. Même une équipe de programmeurs de superstar vétérans ne sera pas aussi
efficace que prévu si elles ne sont pas travaillé les uns avec les autres avant (ou face à des défis difficiles
ensemble). Il devrait être un drapeau rouge si jamais une équipe nouvellement formée est demandé de travailler sur un grand, risqué
projet ou est demandé de commettre un calendrier agressif.

Prendre des risques au début . Si vous savez que Sally a la composante la plus complexe, face à ceux qui
défis à l'avant dans le calendrier. Plus le risque est élevé, plus vous aurez envie de votre côté
à faire face. Si vous ne traitent pas des risques que plus tard dans le calendrier, vous aurez moins
degrés de liberté pour y répondre. La même chose vaut pour politique, organisationnel, ou
les risques liés aux ressources. Nous allons parler de la gestion de l'élément de travail, au pipeline de développement, en
Chapitre 14 .
Page 43

2.6. Résumé

Horaires remplissent trois fonctions: permettant des engagements à faire, en encourageant chacun
pour voir son travail comme une contribution à un ensemble, et permettant le suivi des progrès. Même quand
horaires glisser, ils ont encore de la valeur.

Big horaires devraient être divisés en petits horaires à minimiser les risques et d'augmenter la
fréquence des ajustements.

Toutes les estimations sont des probabilités. Parce que les horaires sont une collection des estimations, ils sont aussi
probabilités. Cela fonctionne contre la précision de calendrier en raison des probabilités accumulent (80% x
80% = 64%).

Le plus tôt que les estimations sont faites, le moins précis qu'ils sont. Cependant, des estimations approximatives sont
la seule façon de fournir un point de départ pour de meilleurs.

Horaires doivent être faites avec scepticisme, pas à l'optimisme. Investir dans la conception de faire la lumière sur
hypothèses et génèrent la confiance fiable.
Page 44

Chapitre trois. Comment comprendre ce qu'il faut faire

Peu de gens sont d'accord sur la façon de planifier des projets . Souvent, la plupart du temps passé lors de la planification est
amener les gens à mettre d'accord sur la façon dont la planification doit être fait. Je pense que les gens obsédés par la planification
car il est le point de contact pour de nombreux rôles différents dans toute organisation. Lorsque des décisions importantes
sont en jeu qui va affecter les gens pendant des mois ou des années, tout le monde a la motivation pour vous impliquer.
Il ya de l'excitation et une nouvelle énergie, mais aussi la crainte que si des mesures ne sont pas prises, les possibilités seront
perdu. Cette combinaison rend trop facile pour les gens à supposer que leur propre vision du monde est
le plus utile. Ou pire, qu'il est la seule vision du monde à considérer et à l'aide dans le
planification de projet processus.

"La partie la plus difficile de construire un seul système logiciel est de décider ce qu'il faut construire. Non
autre partie du travail conceptuel est aussi difficile à établir les modalités techniques
exigences, y compris les interfaces aux personnes, aux machines et à d'autres logiciels
systèmes. Aucune autre partie du travail de sorte paralyse les résultats si mal fait. Aucun autre
une partie est plus difficile à corriger plus tard. Par conséquent, la fonction la plus importante que la
logiciel constructeur effectue pour le client est l'extraction et le raffinement de itératif
les exigences en matière de produits. "

Fred Brooks

Il est donc pas surprenant que les livres liés à la planification dans le coin de mon bureau en désaccord fortement
avec l'un l'autre. Certains mettent l'accent sur la stratégie de l'entreprise, d'autres sur les processus d'ingénierie et de planification
(La mise au point traditionnelle de la planification du projet), et quelques-uns sur la compréhension et la conception pour les clients.
Mais le plus pénible que leurs désaccords est que ces livres ne parviennent pas à reconnaître que d'autres
approches existent encore. Cela est étrange, car aucun de ces perspectivesbusiness, la technologie,
customercan jamais exister sans les autres. Plus encore, je suis convaincu que le succès dans la planification du projet
se produit à l'intersection de ces différents points de vue. Tout gestionnaire qui peut voir ceux
intersections a un grand avantage sur ceux qui ne peuvent pas.

Page 45

Donc, ce chapitre est d'environ aborder le processus de planification et d'obtenir une vue de la planification qui a
les cotes les plus élevées de menant à la réussite. Je dois d'abord préciser un certain vocabulaire et des concepts
différentes stratégies de planification utilisent (il est un peu aride, mais nous aurons besoin pour les chapitres amusants qui suivent).
Lorsque cela est hors de la voie, je vais définir et d'intégrer ces trois points de vue différents, explorer la
Questions de bons processus de planification répondent, et de discuter de la façon d'aborder le travail quotidien à faire
la planification arriver. Les chapitres suivants aller plus en détail sur les livrables spécifiques, tels que
documents de vision ( chapitre 4 ) et les spécifications ( Chapitre 7 ).
Page 46

3.1. la planification du logiciel démystifié

Un petit projet d'un homme pour un site Web interne ne nécessite pas le même processus de planification comme un
300 personnes, dont 10 millions $ pour le projet d'un système d'exploitation à tolérance de pannes. En général, plus les gens
et la complexité que vous avez affaire, la structure de planification plus vous avez besoin. Cependant, même simple,
projets d'un homme bénéficient de plans. Ils offrent la possibilité de revoir les décisions, exposent
hypothèses, et de clarifier les accords entre les personnes et les organisations. Plans agissent comme un forçage
fonction contre toutes sortes de bêtise parce qu'ils exigent que les questions importantes soient résolus tout
il est temps d'envisager d'autres options. Comme Abraham Lincoln a dit: «Si je devais six heures pour abattre un
arbre, je voudrais passer quatre heures à aiguiser la hache, "que je prends pour signifier que la préparation à puce
minimise travail.

La planification du projet consiste à répondre à deux questions. Répondant à la première question, «Que devons-nous
à faire? "est généralement appelé la collecte des besoins. Répondant à la deuxième question," Comment allons-nous faire
il? "est appelé la conception ou la spécification (voir Figure 3-1 ). Une exigence est une description soigneusement écrit
d'un critère que le travail devrait satisfaire. (Par exemple, une exigence pour la cuisson d'un repas
pourrait être de faire de la nourriture bon marché qui est savoureux et nutritifs.) Bon exigences sont faciles à
comprendre et difficile à mal interpréter. Il peut y avoir différentes façons de concevoir quelque chose pour remplir une
exigence, mais il devrait être facile de reconnaître si l'exigence a été satisfaite lors de la recherche
 àlesune pièce finie de travail. Un cahier des charges est tout simplement un plan pour la construction de quelque chose qui va satisfaire
exigences.

Figure 3-1. Une vue incroyablement simple mais pratique de la planification. Si vous ne le faites pas
savez ce que vous devez faire, il est trop tôt pour savoir comment le faire.

Ces trois activitiesrequirements collecte, la conception / spécification, et implementingare profonde

sujets et digne de leurs propres livres (voir la bibliographie annotée ). Je vais couvrir les deux premiers
du point de vue du niveau de projet dans les prochains chapitres, et la mise en œuvre fera l'objet plus tard
dans le livre ( chapitres 14 et 15 ).

3.1.1. Différents types de projets

Plusieurs critères changent la nature de la façon dont les exigences et les travaux de conception sont effectuées. Je vais utiliser trois
exemples de projets simples et diversifiés pour illustrer ces critères: (1)

Solo-surhomme . Dans le projet le plus simple, une seule personne est impliquée. De l'écriture du code pour
la commercialisation de la planification d'entreprise à faire son propre repas, il fait tout lui-même et est son
propre source de financement.

Petite équipe de contrat . Un cabinet de 5 ou 10 programmeurs et 1 gestionnaire est engagé par un client pour
construire un site web ou une application logicielle. Ils rédigent un contrat qui définit leurs engagements
à l'autre. Lorsque le contrat se termine, la relation prend fin, à moins qu'un nouveau contrat / projet est

Page 47

commencé.

Big équipe du personnel . Une équipe de 100 personnes employées par une société commence à travailler sur une nouvelle version
de quelque chose. Il pourrait être un produit vendu au public (aka shrink-wrap) ou quelque chose utilisé
interne (internalware).

Ces trois types de projets diffèrent par la taille de l'équipe, la structure organisationnelle et les relations d'autorité,
et les différences entre eux établissent des distinctions importantes pour la façon dont ils doivent être gérés.
Ainsi, alors que votre projet pourrait ne pas correspondre exactement à ces exemples, ils seront des points de référence utiles
dans les sections suivantes.

3.1.2. Comment la planification de l'impact des organisations

Avec les trois types de projets à l'esprit, nous pouvons examiner les critères de base pour la planification du projet. À n'importe
fois dans un projet, il ya des questions de base que tout le monde devrait connaître la réponse. Tu pourrais
pas toujours les réponses, mais vous et votre équipe devez savoir ce qu'ils sont. La plupart planification
frustrations surviennent quand il ya un désaccord ou de l'ignorance au sujet de ces questions.

Qui a autorité exigences? Quelqu'un doit définir les exigences et les amener
approuvé par les parties nécessaires (client ou VP). Dans le cas solo-surhomme, cela est facile:
Superman aura toute l'autorité qu'il veut. Sur une équipe de contrat, il y aura un client qui
veut fort contrôle sur les exigences et éventuellement la conception. Enfin, une grande équipe de personnel
peut disposer de commissions ou d'autres divisions de la société qui auront besoin d'être servi par le
fonctionne (et dont l'approbation d'une certaine façon est nécessaire). Il peut y avoir des personnes différentes avec haute
exigences de niveau autorité («Ce sera un camion de sport") et les exigences de faible niveau autorité
("Il obtiendra 20 mpg et ont 4 roues motrices").

Qui a le pouvoir de conception? similaires à des exigences, quelqu'un doit définir la conception du
travail lui-même. Le design est différent des exigences parce qu'il ya toujours un grand nombre
différentes conceptions possibles pour répondre à un ensemble d'exigences. Designs, aiment également des exigences, sont
souvent négocié entre deux ou plusieurs parties. Une personne ou une équipe pourrait être responsable de
la conduite du processus de conception et de développement d'idées (designer), et une autre équipe fournit
conseils et des commentaires sur les travaux de la première partie (VP). Notez que parce que le design compétence est
distribué dans l'univers indépendante du pouvoir politique, les gens accordées autorité de conception
pourrait ne pas être des gens avec beaucoup de talent de conception.

Qui a autorité technique? autorité technique est définie par qui obtient de choisir
approches d'ingénierie sont utilisés, y compris les langages de programmation, outils de développement, et
 architecture technique. Beaucoup de ces décisions peuvent avoir un impact exigences, conception, et le budget.
La différence entre les décisions techniques et décisions de conception est subtile: comment quelque chose
se comporte et regarde souvent a beaucoup à voir avec la façon dont il est construit. Dans certaines organisations,
autorité technique remplace les exigences et l'autorité de conception. Dans d'autres, il est inféodé
à eux. Dans le meilleur des organisations, il ya une relation de collaboration entre tous les
différents types d'autorité.

Qui a autorité budgétaire? La possibilité d'ajouter ou de supprimer des ressources à un projet peut être
indépendant des autres formes d'autorité. Par exemple, dans la situation de l'équipe de contrat, le
l'équipe pourrait avoir le pouvoir de définir les exigences et la conception, mais ils pourraient avoir besoin pour
retourner au client chaque fois qu'ils veulent plus d'argent ou de temps.

Combien de fois des exigences et des conceptions seront examinées, et comment seront-être des ajustements
a décidé? La réponse dépend en grande partie sur les questions précédentes. Les parties impliquées dans plus de
exigences, conception, et les budgets, le plus d'efforts devront être dépensés les maintenir synchronisés
au cours du projet. Comme une règle du pouce: le moins d'autorité que vous avez, le plus diligent vous avez besoin
à environ examiner et confirmer les décisions, ainsi que ouvrant la voie à des ajustements.

Bien que je l'ai identifié différents types d'autorité, il est possible pour une personne de posséder plusieurs ou
tous. Cependant, la plupart du temps, l'autorité est répartie entre les chefs d'équipe. Le plus
la complexité de la répartition des pouvoirs est, l'effort de planification plus vous aurez besoin pour être efficace. Dans
Chapitre 16 , je vais couvrir comment faire face à des situations où vous avez besoin de plus d'autorité que vous avez. Pour

Page 48

maintenant, il suffit de reconnaître que la planification implique ces différents types de pouvoir.

3.1.3. Livrables de planification commune

Pour communiquer les exigences, quelqu'un doit les écrire. Il ya beaucoup de façons de le faire,
et je ne suis pas préconiser une méthode particulière. Qu'est-ce qui importe le plus est que la bonne information a
été capturé, les bonnes personnes peuvent facilement discuter et de bons engagements sont pris pour ce que
travail doit être fait. Si la façon dont vous documenter les exigences fait tout cela pour vous, une grande. Si ça
n'a pas, puis chercher une nouvelle méthode avec ces critères à l'esprit.

À titre de référence, je vais parler de quelques-unes des façons courantes pour documenter les exigences et
des informations de planification. Si rien d'autre, sachant le jargon commun contribue à traduire entre le
diverses méthodes utilisées par différents organismes. Vous trouverez quelques équipes documentent les exigences
informelle: "Oh, exigences ... juste aller parler à Fred." D'autres ont des modèles et des avis élaborés
procédures qui brisent ces documents dans incroyablement petites (et éventuellement se chevauchent) pièces appartenant
par des personnes différentes.

exigences de document de marketing (MRD) . Ceci est l'entreprise ou de l'équipe de marketing de

analyse du monde. Le but est d'expliquer quelles sont les possibilités d'affaires existe et comment un
projet peut exploiter ces opportunités. Dans certaines organisations, ceci est un document de référence pour
aider les décideurs dans leur réflexion. Dans d'autres organisations, il est au cœur de la définition du projet
et tout ce qui suit découle fortement de lui. MRD aident à définir le «quoi» d'un
projet.

Vision / document de portée . Un document de vision encapsule tous disponibles penser à ce que d'un
projet pourrait être dans une composition unique. Si un MRD existe, un document de vision doit hériter
et reportez-vous fortement à lui. Un document de vision définit les objectifs d'un projet, pourquoi ils font sens,
et quelles sont les caractéristiques de haut niveau, les exigences ou les dates pour un projet seront (voir chapitre 4 ).
documents de Vision définissent le «quoi» directement d'un projet.

Spécifications . Ces capture ce que le résultat du travail final devrait être pour une partie de la
projet. Bonnes spécifications naissent à partir d'un ensemble d'exigences. Ils sont ensuite développées
par le travail de conception itératif (voir les chapitres 5 et 6 ), ce qui peut impliquer la modification / amélioration
les exigences. Specs sont complets quand ils fournissent un plan réalisable que le génie peut
utiliser pour satisfaire aux exigences (la quantité de détails qu'ils doivent avoir est entièrement négociable avec
ingénierie). Les spécifications devraient hériter lourdement dans l'esprit des documents de vision.
Spécifications définissent le «comment» d'un projet dans une perspective de conception et d'ingénierie.

structure de répartition du travail (SRT) . Alors une spécification détaille le travail à faire, un WBS
définit comment une équipe d'ingénieurs se prendre pour le faire. Quel travail sera fait en premier? Qui le fera
fais le? Quels sont tous les morceaux individuels de travail et comment pouvons-nous les suivre? Un WBS peut être
très simple (un tableur) ou très complexes (cartes et outils), selon les besoins de la
projet. Les chapitres 7 et 13 porteront sur ​les activités WBS-Type. WBS définit le «comment» d'un
projet du point de vue de l'équipe.
Page 49

3.2. Plans qui approchent: les trois points de vue

Vous avez peut-être remarqué que chacun des livrables mentionnés précédemment représente l'un des deux
perspectives sur le projet: commerce ou d'ingénieur. Sur de nombreux projets, ces deux points de vue en concurrence
avec l'un l'autre. Ceci est une erreur de planification fondamentale. La planification doit rarement être un binaire, ou
soit / ou, de l'expérience. Au lieu de cela, il devrait être l'intégration et de la synthèse de ce que chacun peut
contribuer.

Pour ce faire, un gestionnaire de projet doit reconnaître que chaque perspective contribue
quelque chose d'unique qui ne peut pas être remplacé par plus d'autre chose (par exemple, aucun montant de la commercialisation
stratégie permettra d'améliorer la maîtrise de l'ingénierie, et vice-versa). Pour de bons résultats, tout le monde impliqué
dans la planification de projet doit avoir une compréhension de base de chaque perspective.

La couverture suivante de la planification est la force industrielle. Si vous voyez des questions
ou des situations qui ne sont pas applicables en raison de la taille de votre équipe ou de votre portée
projet, sentez-vous libre de parcourir ou de les ignorer. Je ne pense pas que tout ce que je couvrirai
ici applique à un seul projet. Cependant, je suis en train de fournir de la valeur pour vous
non seulement pour ce projet, mais également la suivante et celle d'après. Là
sont nombreux angles et des questions ici qui se révélera utile pour vous dans le long
terme, même si certaines d'entre elles ne vaut pas pour ce que vous travaillez aujourd'hui.

3.2.1. Le point de vue commercial

Le point de vue de l'entreprise se concentre sur des choses qui ont un impact de la comptabilisation de profits et pertes (P & L) d'un
organisation. Ceci inclut les ventes, les bénéfices, les dépenses, la concurrence, et les coûts. Tout le monde devrait
comprendre leur P & L: il est ce qui paie leurs salaires ou leurs contrats. Lorsque les équipes techniques sont
pas au courant de la façon dont leur entreprise fonctionne, de nombreuses décisions prises par la direction apparaissent illogiques ou
stupide. Ainsi, il est dans l'intérêt de celui qui est responsable de la planification des activités pour aider les autres
comprendre leur raisonnement. Dans le secteur de la technologie, les gens avec des titres d'emploi comme analyste d'affaires,
marketing, développement des affaires, responsable produit, ou un cadre supérieur représentent l'entreprise
perspective.

Certains projets ont de multiples perspectives d'affaires. Si vous travaillez pour une entreprise contractée pour construire une
serveur de base de données, vous avez les intérêts de votre entreprise d'affaires à considérer, ainsi que l'entreprise
intérêts du client que vous servez (espérons qu'ils sont en ligne avec l'autre). L'intersection de
ces perspectives peuvent se compliquer; Je vais garder les choses simples ici et d'assumer des projets sont des
la variété grand-personnel. Cependant, il devrait être facile d'extrapoler les questions suivantes à plus
des situations complexes.

Un bon moyen de point de vue commercial que l'équipe a des réponses aux questions suivantes:

Que besoins non satisfaits ou désirs ne nos clients?

Quelles sont les fonctionnalités ou services pourrait nous fournir qui sera répondre à ces désirs et les besoins?

Sur quelle base les clients vont acheter ce produit ou service? Ce qui va les motiver à faire
ainsi?

Quel sera le coût (personnes / ressources)? Sur quelle période?

Quel potentiel de revenus (ou des coûts d'exploitation réduits organisationnelles) at-il? Au cours de ce
période de temps?

Page 50

Que ferons-nous pas construire afin que nous puissions construire ce?

Sera-t-il contribuer à notre stratégie d'entreprise à long terme ou protéger d'autres génératrices de revenus
actifs? (Même les organismes sans but lucratif ou des organisations informatiques disposent d'une stratégie d'affaires: il ya toujours des factures à
payer, revenus d'obtenir, ou génératrices de revenus pour soutenir les groupes.)
 Comment cela nous aidera-Match, déborder, ou de battre les concurrents?

Quels sont les fenêtres de temps de marché que nous devrions cibler pour ce projet?

Les responsables de la perspective de l'entreprise de prendre des vues audacieuses de l'importance de ces questions.
Ils croient que les réponses représentent la ligne de fond de l'organisation et devrait fortement
influencer les décisions du projet.

Cependant, le point de vue de l'entreprise ne signifie pas que tous les projets doivent être esclaves de revenus. Au lieu de cela, il
évalue les projets en fonction de leurs contributions à la stratégie de l'entreprise. Par exemple, une stratégie
projet pourrait être essentiel à l'organisation, mais jamais générer de revenus.

3.2.1.1 Marketing est pas un mot sale

La critique la plus injuste des gens d'affaires est qu'ils ne sont que "marketing", un peu d'un négatif
étiqueter dans le secteur de la technologie. Je pense que le marketing obtient une mauvaise réputation. En termes de MBA, il ya quatre P s que
définir le marketing: produit, prix, placement, et la promotion. Définition du produit et le prix est un
processus créatif. L'objectif est de développer une ideasold de produit pour un profitthat correspond aux besoins de la
clientèle ciblée. La recherche, l'analyse, et le travail créatif sont nécessaires pour réussir.
Placement, le troisième P , considère comment les clients vont obtenir le produit (par le biais d'un site Web? le
supermarché? le coffre de la voiture de Fred?).

Enfin, le marketing est souvent stéréotypée promotionwhat à meanis comment passer le mot positif
sur le produit à des gens influents et les clients potentiels. Étonnamment, la promotion est un petit
une partie de son temps à une entreprise ou un produit analyste gestionnaire (peut-être 10-20%). Ainsi, les plans de marketing définissent
beaucoup plus que ce que les annonces vont ressembler ou ce que des offres promotionnelles seront réalisés. Aussi, notez que
les quatre P du marketing s appliquer à presque rien. Il ya toujours un produit (site web RH), un prix
(Gratuit), un placement (intranet), et une promotion (e-mail) pour cela.

Mais lorsque le point de vue commercial est traité seul, il montre seulement un tiers de ce qui est nécessaire. La
la qualité d'un produit influe sur les ventes, mais la qualité ne vient pas de la commercialisation. Qualité (2) vient
de conception et l'ingénierie quelque chose qui répond aux besoins réels des clients avec succès. UN
plan d'affaires proposé qui se concentre sur les possibilités technologiques (plutôt que des conjectures) sera
font les bonnes affaires.

Un chef de projet, qui utilise un seul point de vue et ne parvient pas, pourrait ne jamais comprendre ce qui est vraiment
qui a mal tourné. Sa tendance sera de travailler plus dur dans le même point de vue à la place de l'élargissement
la vue.

3.2.2. Le point de vue de la technologie

Alors que je faisais mes études d'informatique à l'Université Carnegie Mellon, il était courant de parler
professeurs et étudiants sur les nouveaux produits. Nous avions toujours se concentrer sur ce composantes de ces nouveaux
produits logiciels utilisés et comment ils comparés à ce qui aurait pu. Valeur était implicitement
définie comme la qualité de l'ingénierie: comment fiable et performant, ils étaient ou combien de la dernière
la technologie ils ont profité de. Généralement, nous pensions que tout aspiré. Extrêmement rares
produits empilés jusqu'à nos critiques. Nous nous demandions pourquoi le marché a été emballé de bout en bout avec
la médiocrité et de la déception. Nous serions même inventer des théories de la conspiration de geek pour expliquer le mal
décisions, que nous pensions ont été faites contre la pureté de l'ingénierie et donc fait peu ou pas de sens
à nous. Souvent, nous serions concentrons blâme sur les services de marketing de ces entreprises (3) (non pas que de nombreux
nous compris ce que les commerçants ont fait). Même dans mes premières années dans l'industrie, les mêmes types de
conversations ont eu lieu, encore et encore. Alors seulement il y avait un examen plus approfondi parce que nous étions
en concurrence avec un grand nombre des produits ou des sites Web dont nous avons parlé.

Page 51

Quand nous avons regardé le monde, nous avons vu des technologies et de leurs mérites d'ingénierie seulement. Nous ne
compris pourquoi les produits mal conçus parfois vendus très bien ou pourquoi bien conçu
produits parfois pas réussi à vendre du tout. Nous avons également remarqué que la qualité de l'ingénierie n'a pas toujours
en corrélation avec le bonheur de la clientèle. Pour ces mystères, nous avons eu deux réponses. D'abord, il avait quelque chose
à voir avec les pouvoirs magiques de gens du marketing mauvais. Deuxièmement, nous avons besoin des clients intelligents. Mais
nous ne pensons pas beaucoup à nos conclusions. Au lieu de cela, nous sommes retournés à l'écriture de code ou de trouver un autre
produits de déchirer en lambeaux. Je pouvais voir mon point de vue pour ce qu'elle était seulement après que je l'avais écouté certains
marketing intelligent et certains concepteurs de produits talentueux.

Le point de vue de la technologie met la plus grande valeur sur la façon dont les choses devraient être construits. Il est d'une construction et
matériaux mentalité. Il ya une esthétique, mais il est du point de vue de la technologie, pas de la
le point de vue du client. Il ya un biais vers le bâtiment de choses, au lieu de comprendre comment,
Une fois créés, ces choses vont aider l'entreprise ou le client. Dans l'ingénierie stéréotypée
voir, une base de données qui satisfait l'esthétique de l'ingénieur est suffisante, même si aucun client ne peut comprendre
comment faire quelque chose avec elle, ou il ne parvient pas à atteindre ses projections de ventes.

Aussi critique que ce dernier paragraphe peut sembler, de nombreuses questions importantes proviennent de la technologie
afficher uniquement:

Qu'est-ce qu'il (le projet) doit faire?

 Comment ça va fonctionner? Comment seront chacune des composantes en elle travailler?

Comment allons-nous construire? Comment allons-nous assurer qu'il fonctionne comme il est censé?

Comment fiable, efficace, extensible et performante sont les systèmes ou celles que nous sommes en cours
capable de construire? Y at-il un écart entre cela et ce que le projet exige?

Quelles sont les technologies ou architectures sont facilement disponibles pour nous? Serons-nous parier sur tout nouveau
technologies qui seront bientôt disponibles, mais ne sont pas encore disponibles?

Quels sont les processus et les approches techniques sont appropriées pour cette équipe et ce projet?

Quelles sont les connaissances et l'expertise applicable ne nos gens ont? Que vont-ils pas travailler sur
pour travailler sur ce projet?

Comment allons-nous combler les lacunes en matière d'expertise? (Train / location / savoir / ignorer et espère que les écarts vont magiquement
un moyen.)

Combien de temps faut-il pour construire, à quel niveau de qualité?

3.2.3. La perspective du client

Ceci est le plus important des trois points de vue. Parce que le projet est mis au service de la
client (et peut-être servir de l'entreprise, mais seulement par servir le client), il en résulte que
la plus grande énergie devrait être consacré à la compréhension de qui les clients sont. Ceci comprend
étudier ce que les clients font toute la journée, comment ils le font actuellement, et quels changements ou
améliorations seraient utiles pour les aider à faire ce qu'ils font. Sans cette information,
ingénierie et des affaires tirent dans l'obscurité.

Mais, malheureusement, la perspective du client est le plus faible dans de nombreuses organisations. Il reçoit généralement le
la dotation en personnel moins et l'appui budgétaire. Il ya moins de gens dans la plupart des organisations qui ont été
formés dans la compréhension et la conception pour les clients que leur entreprise et de la technologie
homologues. Et même lorsque les experts des clients sont embauchés (tels que les concepteurs d'interface utilisateur ou
ingénieurs d'utilisabilité), ils sont souvent limités à des rôles limités dans le processus décisionnel projet
et sont accordé quelques exigences ou peu d'autorité de conception.

En tout cas, le point de vue du client est construit à partir de deux sources différentes: les demandes et de la recherche.
Les demandes sont tout ce que le client demande explicitement ou se plaint. Ce type d'information
est précieux parce que le client a la plus grande motivation pour identifier ces problèmes ("Oui, mon

Page 52

explose ordinateur chaque fois que je frappé la barre d'espace "), mais il est également problématique, car, dans la plupart des cas,
les clients ne sont pas les concepteurs. Elles brouillent souvent la distinction entre les problèmes qui doivent être
résolu et les moyens spécifiques de les résoudre. Ils peuvent demander explicitement pour une fonctionnalité, tels que l'impression
aperçu, sans décrire le véritable problème (les gens jettent trop de papier). Si le projet
l'équipe peut commencer par comprendre le problème, il peut y avoir plusieurs façons de résoudre ce qui sont moins cher
ou mieux que les demandes de fonctionnalités. Même les concepteurs qualifiés ont souvent du mal à concevoir pour
eux-mêmes. (4)

Il ya deux sortes d'experts qui comprennent les clients et la conception pour eux: les ingénieurs d'utilisabilité
et les concepteurs de produits. Utilisabilité ingénieurs sont des experts dans la compréhension comment les gens travaillent, et ils
fournissent des métriques et des recherches pour aider les équipes de projet prendre de bonnes décisions dès le premier jour de projet
la planification. Les concepteurs de produits, ou les concepteurs d'interaction, sont des gens formés à la façon de prendre ces données
et le convertir en bons dessins pour des sites Web ou des produits. Si votre organisation est assez chanceux
d'employer ces bons gens, les impliquer dès le début. Demandez-leur d'être les défenseurs de ce point de vue. Si
vous travaillez sans eux, vous êtes à un désavantage à vos concurrents. Envisager l'embauche
quelqu'un de consulter et d'informer sur l'endroit où ces efforts seraient le plus de valeur.

Sans l'aide d'experts, le gestionnaire de projet doit se débrouiller par ses propres moyens. Cela est possible, mais parce
il est souvent la perspective moins intéressant pour les gens ayant des antécédents de l'ingénierie et moins
compris par la haute direction, il obtient généralement moins de soutien que les autres points de vue.
Suffisamment de ressources et de l'ancienneté doivent être investis dans la perspective du client pour équilibrer le
technologiques et commerciaux les. Sinon, surprise: la perspective du client ne sera pas crédible et
ne sera pas entendu.

Les questions importantes de la vue de la clientèle comprennent:

Que font les gens font réellement? (Non ce que nous pensons qu'ils font ou ce qu'ils disent qu'ils font.)

Quels problèmes ont-ils essayer de faire ces choses? Où vont-ils se coincer, confus, ou
frustré?

Que doivent-ils ou veulent faire, mais ne sont pas en mesure de le faire du tout?

Où sont les opportunités spécifiques pour rendre les choses plus facile, plus sûre, plus rapide ou plus fiable pour
leur?

Que les idées de conception pour savoir comment améliorer la façon dont la chose doit workin termes de ce que les gens
 dohave fait le plus de potentiel pour améliorer l'expérience client?
Comment ces idées peuvent être explorées? Qu'est-ce prototypes, croquis, ou des alternatives doivent être
étudiés pour nous aider à comprendre le potentiel pour le projet?

Quelles sont les idées et les concepts de base devrait l'utilisation de projet pour exprimer des informations pour les utilisateurs?

Page 53

3.3. Le point de vue interdisciplinaire magique

Ces trois points de vue se chevauchent toujours l'autre. Chaque compte d'affaires possède technique
et les implications du client (qui est le même pour tous les autres permutations). Donc, pour le meilleur
perspective de planification exige disposant chacune de vue sur un pied d'égalité et de voir où le
les similitudes et les différences. Certaines décisions devront être réalisés qui favorisent une perspective plus
l'autre, mais cela ne devrait pas être fait par accident. Il devrait appuyer une stratégie intelligente dérivé
d'obtenir autant de valeur à partir de chaque point de vue que possible.

En investissant du temps à explorer toutes les trois points de vue, il est possible de voir des opportunités pour une croissance intelligente
décisions stratégiques. Il pourrait être possible de répondre à certaines des questions ou des objectifs premiers de chacun des
trois perspectives en définissant un projet ciblé à trois où les perspectives se chevauchent. Cela sont
les zones qui ont la plus grande valeur potentielle à l'organisation parce qu'un effort peut
traiter simultanément les objectifs d'affaires, de la technologie, et de la clientèle.

Presque aussi importante que sa valeur stratégique de planification, l'aide d'un diagramme de Venn (comme celui de la figure 3-
2 ) peut désamorcer les préjugés en perspective d'ingénieurs ou de marketing. Il permet aux équipes de voir les points de chevauchement
voir, plutôt que ceux que concurrentes. Discussions de planification de projets tôt et souvent au cours de cette
diagramme ou quelque chose comme ça (par exemple, un schéma qui inclut une liste d'objectifs potentiels de chaque
point de vue) peut être utilisé pour encadrer les suggestions faites par les personnes qui ont un parti pris en faveur de vue
le projet. Quand les idées sont suggérées, elles peuvent être mappées contre ce schéma pour voir comment ils
contribuer à tous les trois perspectives. Le PM joue un rôle clé dans la réalisation de ce projet, de manière proactive par
en utilisant sa nature généraliste d'unifier les trois vues en une seule.

Figure 3-2. Les trois points de vue.

Une façon d'y parvenir est de mettre en place dès le début qu'il y aura toujours une grande technologique
idées qui ne bénéficient pas de l'entreprise ou du client, ainsi que de grandes idées pour aider les clients qui
ne sont pas viables pour l'entreprise ou possible avec la technologie actuelle. Cela donne à chacun le pouvoir de
identifier des idées unidimensionnels et appeler les uns des autres sur eux. Il génère également le respect de l'autre côté
perspectives car tout le monde est obligé de se rendre compte qu'ils doivent collaborer avec des gens qui
 connaissances qu'ils ne possèdent pas dans l'ordre doivent être couronnée de succès.

Mais si aucun effort est fait pour concilier les points de vue divergents ensemble, les conflits sont rarement abordées
de front. Au lieu de cela, des réunions de planification de projets deviennent des champs de bataille pour attaquer et de défendre
opinions fondées sur ces lignes de perspective (et non pas sur les véritables mérites des idées elles-mêmes).
Souvent, quand je l'ai consulté avec les équipes de projet, le problème, on m'a demandé d'aider à eu rien à
voir avec leur capacité à planifier un projet. Au lieu de cela, il y avait un pas résolu, ou même tacite, de conflit
de l'opinion sur les raisons d'un departmentengineering ou de marketing, pour exampleis plus importantes que
L'autre. Leurs points de vue singuliers non seulement l'origine du problème, mais aussi rendu impossible la

Page 54

voir la cause du problème.

Il ya des années, je suis impliqué dans l'une de ces guerres stupides moi-même. Je suis le gestionnaire de programme pour web
des fonctions de recherche sur Internet Explorer 4.0. Deux personnes de développement des affaires ont été assignés à nous,
et ils ont été négocient des accords avec les principaux moteurs de recherche de l'époque (Excite, Yahoo !, Lycos,
AltaVista, etc.). Nous avons discuté avec ces experts d'affaires sur les décisions de conception, de débattre en permanence
sur ce qui était le mieux pour le client par rapport à ce qui était le mieux pour l'entreprise. Nous avons chacun croyaient que
nous avons tenu l'autorité (je parle pour le personnel de conception / ingénierie, et ils nous ont donné de l'entreprise
arguments). Nous avons discuté sur les mêmes points pendant des semaines, toujours débattre des décisions spécifiques et
ne reculant pour évaluer nos philosophies cachés sur ce qui a fait de bons produits. Choses
est devenu tellement mauvais que nous avons apporté à notre gestionnaire de groupe pour nous aider à atteindre un compromis.

Je suis convaincu d'une vision plus large du monde aurait aidé toutes les personnes impliquées. Nous étions tous si
investi dans nos egos et les croyances que nous étions prêts à dépenser des tonnes de temps disputent des points minuscules,
au lieu de travailler à comprendre tous les points de vue sur ce que nous avons construit. Une meilleure vision
le document aurait pu aider, mais cela était impossible parce que les défis commerciaux de la
Internet était si nouveau pour l'industrie (circa 1997). Cependant, si nous avions été partageons les uns les autres de
connaissances, au lieu de résister, on aurait pu avoir une chance de trouver une solution mutuellement bénéfique
compromis.

Apporter une vue interdisciplinaire à un projet vous permet de faire des choix qui recoupent les très
les frontières qui limitent vos concurrents. Il vous donne aussi des arguments solides pour toute décision que vous
choisir de faire. Au lieu de seulement affirmant que un design spécifique sera plus facile à construire, vous pouvez aussi
dire pourquoi le marketing va trouver plus de possibilités de vendre que le design (à condition, bien sûr, que vous êtes
pas seulement faire jusqu'à ces revendications). Parfois, cela vous obligera à faire des sacrifices. Quand tu es
à la recherche des meilleures solutions, ils ne correspondent pas toujours à ce que vous êtes bon à faire, ou qui
idées que vous préfèrent personnellement. Mais si vous êtes en mesure de faire ces sacrifices, vous gagnez la condamnation et
la sincérité nécessaire pour amener les autres à faire de même. Vous pouvez ensuite appeler d'autres sur favorisant idées pour animaux de compagnie sur
ce qui est mieux pour le projet. Les gens vont passer derrière les décisions qu'ils ne pas complètement d'accord avec si elles
voir que l'esprit ouvert, travaillant dans l'intérêt du projet, est à l'œuvre ces décisions.

3.3.1. L'équilibre du pouvoir

Si vous travaillez dans une grande entreprise, vous devriez envisager un certain facteur politique pour équilibrer la vue
d'un projet. Je l'appelle le facteur de rapport de puissance. Comment le pouvoir sur le projet est réparti entre les gens
qui représentent ces trois points de vue? Par exemple, si les ingénieurs sont plus nombreux que les analystes d'affaires de 3: 1, le
vue de l'ingénierie aura tendance à dominer les décisions. Le rapport de puissance est simplement le rapport entre le nombre
des personnes sujettes à une vue donnée. Pour avoir une perspective équilibrée, le ratio devrait être de 1: 1: 1
(Ingénierie de Business to Customer). Le rapport de puissance naturelle est le nombre brut de personnes qui ont
expertise dans chaque vue. Le plus hors de l'équilibre, le rapport est, plus le changement sera vers une
compte tenu de la perspective.

Mais les chiffres bruts de gens ne définit pas combien ils ont de pouvoir. L'armée de Napoléon avait des milliers
de soldats, mais il y avait un seul Napoléon. Il peut y avoir 10 programmeurs et de commercialisation 1
(10: 1: 0), mais le distributeur peut avoir autant de pouvoir sur le projet, compte tenu de son rôle ou de l'ancienneté, comme
les autres combinés. Cela signifie un gestionnaire peut compenser pour tout rapport naturel en accordant
pouvoir à ceux qui devraient avoir plus d'influence sur le projet. Et parce que la nature d'un projet
les changements au fil du temps, différents points de vue devraient avoir plus de pouvoir à des moments différents. Voyez comment
vous pouvez déléguer les décisions (voir Chapitre 12 ) pour trouver le juste équilibre pour le projet à la droite
temps.

Page 55
 3.4. Poser les bonnes questions

La façon la plus simple pour encadrer le travail de planification est d'affiner une série de questions que les besoins de travail de planification
répondre. Ils doivent être retirés des trois points de vue avec l'intention de les combiner
dans un plan unique. Dans un premier temps, ils peuvent être explorées de façon indépendante. Définition du projet précoce peut être ouvert
terminé. Les gens peuvent fonctionner avec des idées pour animaux de compagnie ou des intuitions pendant un certain temps, ils ont juste besoin d'être encadrée.
Tout le savoir
devrait mondeque tout cela va ensemble dans MRD ou documents de vision, ce qui nécessitera de nombreux
discussions qui combinent affaires, l'ingénierie, et la pensée de la clientèle dans un plan unique.

Les questions (souvent appelés les questions de planification de projet) doivent être retirés des trois listes
discuté plus tôt, sur la base de leur pertinence pour le projet sur lequel vous travaillez. Si il est un nouveau projet (non
v2), alors vous aurez besoin des questions de base pour définir les principes fondamentaux. Si il est une petite mise à niveau à un
système existant, il peut y avoir moins d'affaires et clients de questions à examiner. Mais peu importe ce que
le projet est, faire l'exercice de courir à travers les questions. Il va forcer sur des hypothèses et
des idées qui ne sont pas reconnus et donner à chacun un point de départ pour en discuter.

Cette liste de questions de planification du projet devrait être libre de la plupart des frontières en perspective. Au lieu de cela, vous aurez
avoir un point de vue holistique du projet, qui peut être divisé, au besoin, dans l'ingénierie,
affaires ou clients considérations. Par exemple, la liste ci-dessous montre les versions plus complexes
de questions énumérés plus haut:

Quelles sont les trois ou quatre groupements utiles que nous pouvons utiliser pour discuter des différents types de
clients que nous avons? (Par exemple, pour un traitement de texte, il pourrait être étudiants, professionnels,
et les utilisateurs à domicile. Pour une base de données informatique, il pourrait être la vente, les réceptionnistes et les cadres.) Comment faire
leurs besoins et leurs comportements diffèrent?

Quelles informations démographiques peuvent nous aider à comprendre qui sont ces clients? (Age,
revenus, type de société, la profession, l'éducation, d'autres produits appartenant ou des sites Web utilisés, etc.)

Quelles activités est chaque groupe d'utilisateurs en utilisant notre produit? Comment cela correspond à ce que
ils ont acheté le produit pour? Comment cela correspond à la façon dont nous avons commercialisé le produit?
Quels problèmes ont-ils en utilisant le produit pour satisfaire leurs besoins?

Qui sont nos nouveaux clients potentiels, et quelles sont les caractéristiques, scénarios, ou des types de produits seraient
nous devons fournir pour les clients faire? (Quels sont les profils démographiques de ces nouveaux
clients?)

Avons-nous la technologie et l'expertise pour créer quelque chose qui répond à ces besoins et
problèmes? (Pour chaque besoin identifié, de réponses oui, peut-être, et ne peuvent souvent être suffisante, au
moins un premier passage).

Peut-on construire la technologie et d'obtenir l'expertise nécessaire pour créer quelque chose qui répond à ces
les besoins et les problèmes? (Oui, peut-être, pas.)

Y at-il des possibilités importantes dans un nouveau produit ou gamme de produits? Ou sont les besoins liés
directement au produit ou ligne de produits actuelle?

Y at-il des modèles économiques viables pour l'utilisation de notre expertise et la technologie pour résoudre ces
des problèmes ou des besoins identifiés? (Est-ce que les bénéfices l'emportent sur les coûts sur un calendrier prévisible?)

Quels sont les délais de marché pour la prochaine version ou lancement de produit? Quels fenêtres
occasion faire le plus de sens pour cibler?

Quels sont les concurrents dans ce marché faire? Que pensons-nous de leurs stratégies sont, et
comment pourrions-nous rivaliser avec eux?

Page 56

3.4.1. Répondre aux bonnes questions

Il peut prendre des heures ou des semaines pour répondre à ces questions, en fonction de la profondeur et de la qualité de la
réponses nécessaires, qui est définie par le gestionnaire de projet ou chef de groupe. En règle générale, la
plus stratégique du projet devrait être, plus important de la qualité de ce type de définition
et la recherche de planification est. Pour les projets tactiques qui sont axés sur des questions mineures ou des besoins à court terme,
moins de profondeur est nécessaire. Vous pourriez avoir besoin de considérer seulement une poignée de questions, et vous pouvez baser votre
réponses en grande partie sur la façon dont vous leur répondit pour le dernier projet. Mais pour les projets importants, ce
information sera inestimable dans des ajustements ou des modifications midproject, non seulement dans la planification
phase.

Certaines de ces questions sont mieux répondu par types d'analystes d'affaires, d'autres sont mieux traitées par
programmeurs ou ingénieurs d'utilisabilité plomb. Souvent, les meilleures réponses proviennent de discussions entre
ces experts et le partage de notes, des sources et des opinions. Il peut être coûteux et
consommer pour faire ce travail, mais qui est la nature de la planification. L'achat d'une maison ou une voiture, se déplaçant à une
nouveau pays, ou en écrivant un livre exige des efforts de planification importants pour rendre le processus de travail sur
 bien.
projet.Si(Je
vous
vaisleparler
faites plus
correctement,
à ce sujet il permet une prise
dans le chapitre 14 de
.) décision plus rapide et plus nette dans tout le reste de la

3.4.2. Que faire si il n'y a pas de temps?

Dans le pire des cas, même si aucune recherche existe et pas de temps est alloué pour faire enquête appropriée,
poser ces questions de toute façon. Il suffit de soulever les bonnes questions invite deux possibilités positives. Premier,
des suppositions intelligentes à la bonne question sont mieux que rien. Une question bien posée est axé
l'énergie sur les bonnes questions. Même si vous avez seulement le temps pour deviner, la spéculation sur les bonnes questions est
plus précieux que la spéculation sur les mauvaises questions. Deuxièmement, l'absence de recherches dans le noyau
questions peuvent soulever un drapeau rouge pour les dirigeants et la gestion. La santé à long terme d'une organisation
est tributaire de sa capacité à faire de bons plans, et même si les investissements (embauche d'une personne ou
fournir un financement) pourrait venir trop tard pour aider ce projet, il peut certainement aider à la suivante.

Page 57

3.5. Catalogue de mauvaises manières communes de décider ce qu'il faut faire

Il ya toujours plus de mauvaises façons de faire quelque chose que les bonnes manières, et la planification des projets est pas
exception. Comme un outil supplémentaire vers trier le bon du mauvais, le tableau 3-1 montre quelques-uns des
les approches moche, je l'ai vu utilisé. Je propose ceux-ci dans l'espoir que cela vous aidera à reconnaître quand
ce qui se passe, et pourquoi ces approches sont problématiques.

Tableau 3-1. Mauvaises manières communes de décider ce qu'il faut faire

Mauvaise façon Exemple Pourquoi il arrive Le problème

Souvent, il n'y a pas la
Le monde peut avoir
désir ou de ressources pour
Nous ferons changé depuis v2.0. Sans
"Version 3.0 sera comme 2.0, revenir en arrière et faire de nouvelles
ce que nous avons fait examiner la façon dont ont fait 2,0
mais en mieux! " la recherche dans le
dernière fois. contre ses objectifs, le plan
affaires, la technologie,
peut être un désastre.
et les problèmes des clients.
Nous ferons Articles qui ont été coupés sont
Caractéristiques sont soldés
ce que nous sans doute bien
"La fonction coupe pour la version non essentiel. Mise au point d'un
oublié de compris et partiellement
2.0 sera le cœur de 3.0! " libération sur eux peut ne pas être
Finish Last complet, ce qui pour
la meilleure utilisation des ressources.
temps. endroits facile à démarrer.
Il est le plus simple
Nous ferons
stratégie commerciale. Ce Il ya peut-être stupide
ce que notre «Notre objectif est de faire correspondre le produit
 concurrent fonctionnalité de X pour la fonction ".insécurité,
convainc leetparanoïaque, raisonne
paresseux. Non faire un concurrent
quelque chose. est
faire.
l'analyse est nécessaire.
Les tendances sont les tendances
Les révolutions sont rares.
parce qu'ils sont faciles
Le progrès technologique est
Nous allons construire et amusant à suivre.
"Version 5.0 sera Java surestimé dans le court
tout ce qui est Les gens se passionnent
sur la base, d'un dispositif mobile prêt, terme, sous-estimé dans le
chaud et la tendance, et il peut
et RSS 4.0 conforme. " long terme. Client
trendy. prêter l'excitation facile pour
problèmes devrait l'emporter
ennuyeux ou mal définie
manies branchés.
projets.
Par distraire tout le monde Est-ce que le monde a besoin d'un
"Project X sera le meilleur à la construction, plutôt meilleur piège à souris? Gens
Si nous le construisons
/ moteur de recherche web que la raison de venir si ce qui est construit est
ils vont
éditeur / Widget / souricière bâtiment, les gens peuvent utile pour eux, non pas parce que
venir.
déjà." parfois éviter réel une équipe a décidé de construire
la planification. quelque chose.

Page 58

3.6. Le processus de planification

Dans tout le temps alloué pour la définition du projet, créer un processus simple pour répondre à la
des questions de planification. Si possible, chaque perspective (affaires, la technologie, et le client) doit avoir
une personne avec une expertise dans ce domaine conduire les recherches d'informations, la génération d'idées et
propositions et l'examen de ses pensées avec leurs pairs d'autres perspectives. L'astuce est de garder cette
assez petit pour être productif, mais assez grand pour être en perspective large et globale. UN
groupe de 10 personnes sera beaucoup moins efficace à l'examen des questions et le développement de la chimie d'équipe
d'un groupe de 5 (voir chapitre 9 ).

Par expérience, je préfère traiter avec les egos meurtris de ceux qui ne sont pas des principaux contributeurs à
la planification que d'inclure trop de gens souffrent et un an ou plus sur un mal planifiée et fortement
projet compromise. Les personnes d'âge mûr qui vous ne comprennent pas se comprendre vos raisons si vous
prendre le temps de les expliquer, et l'immature aura une opportunité de croissance, ou de motivation
de trouver un emploi mieux adapté à leur ego.

Si vous utilisez livrables de planification comme ceux que je brièvement décrits précédemment dans ce chapitre, l'objectif
du groupe de planification devrait être de créer et de publier ces documents pour l'équipe. La planification
phase (voir Figure 3-3 ) ne se termine que lorsque ces documents (ou plus important encore, les décisions qu'ils
contenir) sont terminés.

Figure 3-3. La rétroaction entre les niveaux de planification.

Un projet de version de chaque document de planification devrait être préparée assez tôt pour intégrer les commentaires
de l'équipe avant une version finale est due. Comme le montre la Figure 3-3 , il peut même être une simple
boucle de rétroaction entre les livrables. Lorsque le projet d'un MRD est créé, quelqu'un peut être en mesure de
commencer à travailler sur le document de vision, ce qui soulève de nouvelles questions pour le MRD qui améliorent avant qu'il ne soit
 finalisé. Ce schéma
pour la finition se répète àdetravers
de documents tout le travail
planification, de planification.
un certain chevauchementDonc, même
dans si il ya
le temps estdes
en délais
bonne durs
santé et améliore la qualité du processus.
Comme le montre la Figure 3-4 , quand un projet est à la mi-match (mise en œuvre), il devient plus difficile, si
impossible, pour ce genre de commentaires de propager sauvegarder la structure de planification. (Sinon,
Figure 3-4 peut être pensé pour représenter une équipe qui a contracté une influence sur les spécifications et le travail
missions seulement.)

Figure 3-4. Comme le temps passe, il devrait devenir plus difficile (mais pas
impossible) pour que les changements se propagent sauvegarder la structure de planification.

Page 59

3.6.1. Le travail quotidien

En ce qui concerne le travail quotidien de la planification est concerné, il n'y a pas de solution magique pour le faire de ceux-ci
sortes de tâches collaboratives. Les gens sont les gens, et il est impossible de sauter au-delà du temps qu'il faut pour
amener les individus qui sont d'abord des différents esprits de se réunir, d'apprendre les uns des autres, et
faire les arguments ou les compromis nécessaires pour faire avancer les choses. Il y aura des réunions et
discussions, et probablement la création de listes de distribution de courriels ou des sites Web, mais pas de recette secrète de
ces choses font une grande différence. Être aussi simple et directe que possible. Le leader donne le ton en
de commencer les conversations, poser les questions importantes, et de faire que les bonnes personnes sont en
la pièce au bon moment. Cependant, il ya trois choses à garder à l'esprit:

La partie la plus importante du processus sont les rôles que les gens sont censés jouer .
Qui a autorité exigences? Concevoir? Si beaucoup de gens sont impliqués, comment les décisions seront-
fabriqué? Comment les liens seront rompus? Avec ces sortes de problèmes de relations définies dès le début, de nombreux
problèmes peuvent être évités ou, plus probablement, manipulés avec sang-froid et la rapidité. (Voir
Chapitre 10 pour plus sur les relations et définir les rôles.)

Tout le monde devrait savoir quels sont les points intermédiaires sont . Quels sont les jalons
entre le premier jour de l'effort de planification et le jour où la définition du projet est censé
être complet? Le calendrier de deliverablessuch que des rapports, des présentations, des réunions d'examen, ou
vision documentsshould être répertorié au début et à la propriété défini pour chacun d'eux. Quand exactement
ne commencent fin et la conception ou la mise en œuvre de «planification»? Il devrait être bon, publiée
réponses.

Il devrait y avoir des réunions fréquentes où chaque point de vue est discutée . Rapports de
de nouvelles informations ou de pensées devraient être présentés, et de nouvelles questions ou les conclusions devraient être
soulevée. Les experts venus d'ailleurs dans l'organisation ou l'équipe doit être tiré dans ces
réunions quand ils ont une expertise qui peut aider, ou si leurs opinions seraient de valeur pour le
groupe.

Le chef de projet est souvent responsable de la consolidation de chaque réunion et de discussion en bas
points clés et de tirer des conclusions sûr conclus sont écrites dans la pierre dans un endroit le groupe peut facilement
référence. Questions ou questions soulevées devraient être affectés de manière appropriée, puis discutés lors de la
prochaine réunion.
Page 60

3.7. la recherche de la clientèle et de ses abus

Il existe de nombreuses façons d'abuser des informations sur les clients. Simplement en faisant valoir que
clients sont importants ne signifie pas grand-chose. Il ne prend pas le travail de dire «Nous nous soucions de clients» ou
"La satisfaction du client est important", car il est rare que quelqu'un se demander comment ces croyances correspondent aux
comportement organisationnel. Même si dans la dernière décennie beaucoup de progrès ont été réalisés dans le raffinage
méthodes pour la recherche et la compréhension des clients, la plus grande partie n'a pas pénétré jusqu'à
organisations Management- ou d'ingénierie-centric. Il est encore rare pour les équipes de projet ont une
expert dans la recherche de clients, conception de l'interface, la convivialité ou la disposition des décideurs.

De loin, l'erreur la plus répandue Je l'ai vu dans la recherche de la clientèle est trop compter sur un seul
méthode de recherche comme source pour la prise de décision. Le problème fondamental de toute recherche,
scientifique ou autre, est qu'une étude évalue donné un seul point de vue sur une question (nous allons
reparlerons dans le chapitre 8 ). Chaque méthode pour examiner quelque chose est bon de mesurer certaine
attributs et horrible à mesurer d'autres (voir le tableau 3-2 ). Tout comme vous ne seriez jamais utiliser un
tachymètre pour mesurer votre poids ou votre compte bancaire pour mesurer votre pression artérielle (si
elles peuvent être liées), il ya certaines choses que les enquêtes et les groupes de discussion sont bonnes et d'autres
qu'ils ne sont pas.

Tableau 3-2. Les méthodes de recherche de client commun

Méthode Quel est-il? Avantages Moins

Un groupe de clients potentiels
Concentrer sont réunis pour voir
groupe prototypes et donner des avis en
une discussion animée.
Une série de questions sont donnés
Enquête
à des clients potentiels.
Experts ou membres de l'équipe vont à expérience client.
Site
les lieux de travail des clients et
visites
observez-les faire leur travail.
Clients sélectionnés utilisent un design
dans un environnement contrôlé.
Ergonomie Les mesures sont prises pour combien
étude de nombreux scénarios qu'ils peuvent
complète, dans combien de temps,
et combien d'erreurs.
Le marché du produit est
examiné pour voir combien de
Marché il ya des clients, ce que le
recherche produits concurrents coûtent, et
ce que les projections de recettes
sont.
unLes groupes de discussion ont tendance à les gens de polarisation vers l'être utiles. Ils ne veulent pas d'insulter leurs hôtes, et
ils seront souvent plus positive et généreuse en considérant les idées qu'ils ne le feraient autrement.
Des discussions sont difficiles à
On peut obtenir beaucoup d'opinions à
analyser et facile à
une fois. Permet étendue
mal interpréter. Mal formés
suggestions et ouverte
facilitateurs créent trompeuse
dialogue. un
données.
Fiabilité de l'information est
À faible coût moyen d'obtenir b enquêtes Authoring
faible.
des informations de grande
sans biaiser les réponses est
nombre de personnes. Bien
difficile. Facile de
pour les très grandes tendances.
mal interpréter les données.
Observez le vrai Les données sont le plus précieux
à ceux qui ont fait la visite:
Souvent, cela est le plus il est difficile de transférer à
mémorable et puissant autres ou à utiliser
expérience pour l'équipe. quantitativement.
Quantifie combien il est facile Valeur directe peu pour
d'utiliser quoi que ce soit. Fournitaffaires ou technologique
preuve de spécifique des questions. Peut être gaspillée
problèmes. Le plus précieux effort si elle est faite en retard ou si
lorsqu'elle est effectuée tôt, avantéquipe d'ingénierie ne
projet commence. regarder souvent.
Ne pas expliquer pourquoi
Seul moyen de capturer la produits sont couronnées de succès,
Vue d'affaires d'un et il se concentre sur les tendances
marché ou de l'industrie. et les dépenses, plutôt que
les gens et leurs comportements.

Page 61

Méthode Quel est-il? Avantages Moins

b Considérez comment diligent vous étiez à répondre à des questions dans le dernier sondage que vous avez pris. Si vous ne
participer à des sondages, posez-vous sur les types de personnes susceptibles de passer beaucoup de temps en prenant des enquêtes.

Les experts de la recherche de la clientèle font deux choses: ils choisissent la méthode basée sur les questions que le
équipe de projet doit répondre, et ils font usage de plusieurs méthodes pour contrer les limitations
et les préjugés des approches individuelles. Tableau 3-2 décrit certaines des principales méthodes de recherche et
leurs compromis de haut niveau.

Comme un gestionnaire de programme chez Microsoft, sur les meilleures équipes de projet je travaillais, je eu accès à un grand nombre de
ces sources d'information. Je dois souvent demander des réponses à des questions spécifiques qui allaient
au-delà de ce que m'a fourni, mais il y ont été consacrés experts dans l'organisation qui serait
 généralement
(Typiquement le faire
avec pour de
moins moi. Sur les
succès autres
parce queéquipes avec
je devais moins de
beaucoup soutien,
d'autres je dois
choses alleraussi
à faire fairebien,
faire et
surjemon propre
ne suis pas aussi compétent
à obtenir des résultats comme un expert à plein temps serait).

Même sans ressources ou de budget, de quelques heures de travail vers répondre à ces questions de planification
peut parfois donner des résultats utiles. Axé sur l'énergie dépensés recherches sur le Web à puce et de la bibliothèque
enquêtes (réels bibliothécaires sont souvent des outils plus puissants que les sites Web) peuvent révéler des sources qui sont
infiniment plus utile que rien. Au fil du temps, les compétences et l'expérience en faisant ce genre de
la recherche va croître, et cela peut prendre moins de temps à l'avenir. Plus important encore, après avoir fait une partie de
ce genre de travail sur votre propre vous mettra dans une position plus éclairée d'embaucher quelqu'un pour le faire pour
vous devriez le budget ou les effectifs enfin vous être offert.

Avec toute source de données, le scepticisme et sain examen aident à affiner et améliorer sa valeur.
Les hypothèses doivent être remises en question, et des biais connus de différents types de recherche devraient être appelés
en même temps, la recherche est présenté dans une discussion. Cela ne signifie pas que ces données
devrait être jeté tout simplement parce qu'il n'y a pas assez de lui ou parce qu'il ya des questions valables
à ce sujet. Au lieu de cela, l'équipe doit essayer de regarder au-delà des défauts de trouver les pièces précieuses qui peuvent être
utilisés pour influencer les discussions et de donner une meilleure perspective sur ce qu'est la réalité du client de
expérience est comme. Aucune forme de données est parfait: il ya toujours des préjugés, des mises en garde, les marges d'erreur, et
des détails cachés. Le gestionnaire de projet doit être capable de voir au-delà des préjugés et de faire un usage intelligent de
ce qui est disponible pour prendre de meilleures décisions.

Page 62

3.8. Rassembler tous les éléments: exigences

Planification crée de grandes quantités d'informations intéressantes (posant beaucoup de questions tend à faire
que cela se produise). Le défi est de savoir comment simplifier l'information et de la convertir en une forme
utile pour définir un plan d'action. À un niveau élevé, un document de vision est l'endroit où tout le
perspectives, la recherche, et la stratégie sont synthétisés ensemble. Nous parlerons plus que spéciale
document dans le chapitre suivant. Mais à un milieu à faible niveau, l'outil le plus simple est l'utilisation de
exigences. documents de Vision contiennent souvent des informations des exigences, mais selon que
spécifications ou d'autres documents, plus ciblées seront écrits, des exigences détaillées pourraient être
figurant ailleurs.

Beaucoup de projets utilisent les exigences que la façon de définir la direction d'un projet. Une exigence par
définition est tout ce que l'équipe (et client) accepte sera satisfaite lorsque le projet est terminé. Dans
le sens le plus simple, commander une pizza au pepperoni est un acte de la définition des besoins. Tu racontes
le pizzaiolo précisément ce que vous voulez. Il peut vous poser des questions pour clarifier l'exigence ("Avez-
vous voulez un soda avec ça? "), ou il peut négocier les détails de l'obligation (« Nous sommes sur
pepperoni, acceptez-vous de salami à la place? "). Dans le cas plus complexe de développement de logiciels,
bonnes exigences sont difficiles à obtenir. Il existe de nombreuses façons d'interpréter les idées abstraites
("Faire courir vite» ou «faire planter moins souvent»), et le processus d'exigences suscitant peut être
difficile.

Il existe des méthodes établies pour le développement et les exigences de documentation, et je recommande
vous familiariser avec eux (voir les excellents Exigences Explorer: Qualité Avant Conception ,
par Donald Gause et Gerald Weinberg, Dorset House, 1989). Selon quelle autorité vous
 ont sur le
obtenir deprocessus de gestion
bons résultats. des exigences,
Les détails il ya différentes
de ces méthodes façons
et comment les de s'y prendre
appliquer sont pour
hors faire
de la en sortedeque
portée la vous aurez
présente
livre. Cependant, je peux vous offrir une méthode simple qui je pense est facile à utiliser et généralement très
efficace: la méthode des énoncés de problèmes.

déclarations de ce problème sont des descriptions d'une ou deux phrases de questions de l'utilisateur final ou clients spécifiques.
Ils doivent être issus de toute la recherche qui a été effectuée ou de client spécifique
demandes. Ils doivent être rédigés dans un format qui identifie un problème ou un besoin de la clientèle
point de vue (par opposition à la perspective d'ingénieur ou de commerce). Cela permettra d'assurer que le point
de vue de l'impact sur le client est maintenu et pas involontairement déformée par d'autres
perspectives. énoncés de problèmes permettent également d'éviter certaines des exigences erreurs communes que
équipes (nous les couvrons brièvement dans le chapitre 5 ).

A titre d'exemple, voici ce que la liste des énoncés de problèmes pour un site web intranet pourrait ressembler:

Il est difficile de trouver des articles couramment nécessaires sur la page d'accueil.

Pages avec des informations de service sont très lent à charger et les utilisateurs à attendre.

La page de requête de base de données se bloque lorsque l'on travaille avec de grandes tables, et les utilisateurs ont à recommencer
avec leur travail.

Le site ne fournit pas un accès automatisé aux services de ressources humaines, qui prennent beaucoup de temps à faire
manuellement.

Résultats de la recherche sont difficiles à numériser avec la configuration actuelle.

La page d'enregistrement ne prévient pas sur les champs nécessaires, et il est trop facile de faire des erreurs.

La page d'état ne comprend pas d'informations sur e-mail, et les utilisateurs ne peut pas savoir pourquoi leur
email ne fonctionne pas.

Il n'y a pas moyen de sauver des préférences ou des options pour la page d'accueil est affichée.

Page 63

Notez que ce ne sont pas des rapports de bogues. Ces questions ont peut-être jamais été identifiés comme des choses du Web
le site avait besoin de faire. déclarations de problème devrait être plus large et différent en perspective de
bogues parce que l'idée est de capturer ce qui manque du point de vue du client, au lieu de seulement
ce qui est rompu à partir d'un point de vue technique.

Chacune de ces déclarations d'une phrase peut être suivie par des pièces justificatives ou des exemples (par exemple,
captures d'écran du site Web ou d'un produit qui fournit le contexte de la question, ou des références à la
étude de convivialité ou d'autres recherches qui a fait surface le problème) pour aider à raconter l'histoire et expliquer pourquoi
et comment le problème se produit (ou pourquoi l'omission d'un type de fonctionnalité est importante). Mais ça
Les pièces justificatives doivent pas mélanger avec l'énoncé du problème lui-même, ou avec des plans d'ingénierie ou
objectifs d'affaires. Pour la santé mentale, ces énoncés de problèmes de client devraient rester purement propos
clients et leurs besoins.

3.8.1. Problèmes deviennent scénarios

Parce que les énoncés de problèmes représentent l'état actuel du monde, un projet besoin de quelque chose
d'autre pour exprimer comment le monde sera quand le travail est terminé. A cet effet, le problème
déclarations doivent être convertis dans ce qu'on appelle des déclarations ou des scénarios longs. Il y a
de nombreuses façons différentes de faire ça; utilisent-cas sont une méthode populaire (voir Alistair Cockburn l'écriture
Cas d'utilisation efficaces , Addison Wesley, 2000), mais il ya beaucoup d'autres.

Chaque scénario est une brève description de quelque chose d'un client sera en mesure de le faire à la suite de la
projet, ou les tâches qu'ils auront plus à faire parce que le projet automatise les tâches pour
leur. L'idée est de décrire ces choses auprès du client ou du point de vue de l'utilisateur et d'éviter toute
description de la façon dont ces avantages seront achievedthat vient plus tard. Pour l'instant, ce qui est important est que
l'équipe est en mesure d'articuler et de discuter les scénarios qui ont le plus de valeur. Considérations pour
la valeur de l'entreprise de résoudre chaque scénario ou de leur faisabilité technologique devrait être reflété dans
la façon dont les scénarios sont priorisés.

Les déclarations de longs eux-mêmes devraient devenir la façon de représenter le plus facilement ce qui a été
appris sur les clients et ce que le projet sera axé sur la fourniture pour eux. Basé sur
liste précédente des problèmes des clients, voici ce que certains états de longs pourraient ressembler.

Caractéristiques possibles de Project X :

Communément articles utilisés seront faciles à repérer sur la page d'accueil.

Résultats de la recherche sera facile pour la plupart des utilisateurs de lire rapidement.

Le site offrira un accès facile et automatisé aux services de RH.

La page d'enregistrement, il sera facile d'entrer des informations sans erreurs.

Pages d'information du Service seront au moins aussi vite que la page d'accueil elle-même.
 L'interface de requête de base de données sera aussi fiable que d'autres parties du système.

Les utilisateurs seront en mesure d'en apprendre davantage sur les questions de statut du serveur de messagerie d'une manière simple et pratique.

Les utilisateurs auront un moyen pratique pour que le système se souviennent de leurs préférences.

déclarations de fonctions ne devraient jamais décrire une solution ou conception spécifique, mais devraient plutôt expliquer
l'impact de la solution sur le client. (Cela est plus facile à dire qu'à faire. La plupart des ingénieurs et créatifs
les gens aiment résoudre des problèmes. Si vous décrivez un problème, ils voudront sauter à droite dans le résoudre
au lieu de passer du temps à essayer d'élaborer ou affiner le problème. Il est commun d'exiger une
interdiction temporaire sur les propositions de solution au cours des discussions de la liste de problèmes et de scénarios. Il suffit de demander
aux gens d'écrire leurs idées au cours de la réunion, puis de discuter plus tard. Faire des exceptions
pour des idées que d'éliminer complètement les problèmes dans les listes ou les identifier comme trivial.)

En reportant profonde discussion sur les alternatives de conception, l'équipe peut se concentrer sur la clarification de la réelle
objectifs du projet. Ces déclarations de longs peuvent être commandés à peu près par ordre d'importance, aidant à

Page 64

définir la forme de ce que le projet sera. Si cela est bien géré, quand vient le temps d'explorer
et de définir des conceptions, il sera beaucoup plus rapide car tout le monde va travailler vers les mêmes résultats
(Au lieu de se laisser distraire par les technologies ou leurs idées préférées pour des solutions). Parce que tant est
à cheval sur ces courtes descriptions, ils doivent être écrits avec soin et en tenant compte de la façon dont
de temps ils vont être utilisés par l'équipe de projet. Il faut souvent plusieurs passes et des avis Pour ne pas se tromper,
mais une fois terminée, ils vont rarement besoin d'être redéfini au cours d'un projet.

3.8.2. Intégrer les exigences commerciales et technologiques

Avec une liste de caractéristiques potentielles qui a grandi sur la recherche de l'utilisateur, des fonctionnalités supplémentaires pour satisfaire entreprise
ou de considérations technologiques peuvent être ajoutés. Mais une question primaire doit être répondu: quelle est la
but de ces demandes supplémentaires si elles ne contribuent pas à aider les clients? Avant
ajoutant de nouvelles fonctionnalités, la liste existante devrait être revue pour voir ceux qui représentent déjà ces
considérations commerciales et technologiques. Cela oblige toute discussion à être centré sur l'impact de la clientèle
et bénéficier, sans interdire considérations technologiques ou commerciales spécifiques.

Il est tout à fait possible que les besoins de l'entreprise d'exploiter certaines opportunités de marché sont
représenté par une ou plusieurs caractéristiques déjà sur la liste. les exigences technologiques devraient également être
attachés à des prestations que ces efforts d'ingénierie créeront pour les clients. Toute entreprise ou
les exigences technologiques qui ne se connectent avec avantages pour le client (à court ou à long terme) devrait être
scruté. Ces caractéristiques noncustomer centrée devraient être soigneusement définis pour vous assurer qu'ils font
pas d'impact négatif de l'expérience du client.

Et même si la commercialisation exige un ajout qui n'a aucun lien avec l'amélioration de l'expérience client,
tout le monde saura que ce soit le cas et réagir en conséquence. Parfois, il est nécessaire d'ajouter un
fonction pour aider à vendre un produit, malgré sa valeur utilisateur final douteuse, ou pour satisfaire une clientèle exigeante ou
exécutif. Mais en organisant d'abord le processus de planification autour de la recherche de clients, problème
déclarations, et les caractéristiques résultant, tout le monde aura à faire des arguments dans ce contexte.
cloches d'avertissement devraient éteint si la majorité des fonctionnalités dans un communiqué avoir aucun lien direct à la
client. Si elles peuvent être révisées par leur relation à une liste centrée sur le client, aléatoire ou auto-
demandes de desserte à se démarquer à tout le monde dans la salle et de la demande additionnelle et débat
discussion. Cela donne le gestionnaire de projet de chaque occasion pour définir un champ de jeu de niveau
caractéristiques qui a le meilleur intérêt de la clientèle et de l'organisation à l'esprit.

3.8.3. Résumé

Différents projets exigent différentes approches de la planification.

Comment la planification qui est fait est souvent déterminé par l'autorité qui a quoi. Exigences, conception,
et le budget sont les trois types de chargé de projet que de la planification de l'impact.

Il ya quelques livrables communes pour les projets de planification: les conditions de commercialisation
documents (MRDS), les documents de vision / objectifs, les spécifications et les structures de répartition du travail
(WBSs).

Le moyen le plus puissant pour planifier un projet implique l'utilisation de trois perspectives égales: affaires,
la technologie, et le client. La perspective du client est souvent le plus mal compris et
usurpée.

Poser des questions oblige bonne pensée et dirige la planification de l'énergie de manière efficace.

Le processus de définition des besoins est difficile, mais il ya de bonnes références pour savoir comment faire
bien.

Des déclarations et des scénarios problème sont une façon simple de définir et communiquer les exigences.
Ils sont facilement convertis en des idées de design sans perdre la clarté sur ce qui est important et
ce qui n'est pas.
Page 66
65

Chapitre Quatre. Rédaction de la bonne vision

Un défi dans des équipes de premier plan est garder les gens concentrés sur les mêmes objectifs pour de longues périodes de
temps. Tous les dirigeants craignent que les décisions qu'ils font ne seront pas conservés. Il est possible que les raisons
les gens avaient pour écouter eux aujourd'hui seront oubliés ou ignorés demain. Peut-être pire,
les gestionnaires eux-mêmes peuvent oublier la direction dans laquelle ils sont censés être à la tête du projet. Donc,
le défi de la gestion de projet est non seulement de faire démarrer les choses dans la bonne direction, mais aussi
pour garder la tête de cette façon.

Chapitre 3 inclus un bref aperçu des documents de planification, comme MRD, la vision, et la spécification.
Ce chapitre se concentrera sur le document de vision, la plus importante de toutes les matières de la planification.
Je vais vous expliquer pourquoi les documents de vision en valent la peine d'écrire, quelles sont les qualités bons ont, et
comment obtenir continuellement de la valeur de leur part au cours d'un projet. Lorsqu'ils sont utilisés correctement,
ils concluent la phase de planification initiale d'un projet (voir Figure 4-1 ).

Figure 4-1. Un document de vision finalisé signifie la fin de la planification

la phase, tout comme les spécifications finales signifient la fin de la phase de conception.

Page 67
 Mais on note avant que je commence. Il ya de nombreuses façons de diviser le motif que MRDS, visions,
et les spécifications couvrent. Certaines organisations ne pas utiliser MRD ou des documents de justification de l'entreprise au
tous, et à la place rouler cette information dans le document de vision elle-même. Je l'ai vu d'autres équipes se divisent
ce que je appelle le document de vision en quatre ou cinq petits documents et de leur donner des noms de fantaisie. UN
quelques fois que je suis sur de très petits projets où l'information de type vision a été effondré vers le bas dans
la spécification elle-même. Donc, ne vous inquiétez pas combien de documents vous devriez avoir ou ce qu'ils sont
appelé: Je ne pense pas que ce soit particulièrement important. L'avis qui suit devrait appliquer bien à tout
processus de planification que vous choisissez d'utiliser.

Page 68

4.1. La valeur des choses d'écriture vers le bas

Daniel Boorstin, auteur de la grande fonctionne Les Créateurs et Les découvreurs , a dit une fois que la
mot écrit était le plus grand homme jamais inventé la technologie. Sans elle, nous serions dépendants de notre
souvenirs notoirement peu fiables (1) à faire des choses complexes comme faire de la dynamite (hmmm, combien
nitroglycérine va de pair avec la façon dont beaucoup de charbon?) ou des réacteurs nucléaires (l'uranium va où?). Spécifique
à la poursuite des travaux du projet, les choses par écrit, il est possible de définir les travaux d'ingénierie ou
capturer les objectifs globaux pour des équipes entières qu'une seule fois, et de réutiliser cette connaissance à plusieurs reprises.
Documenter les détails de décisions décharge le fardeau de la précision et de recueillement de notre
esprits vers le bas sur le papier, et tout ce que nous devons faire pour les récupérer est de regarder ce que nous avons écrit. Cette liberté
d'esprit nous permet d'aller à pleine vitesse à la tâche à accomplir, confiants que nous pouvons revenir à ce que nous
écrit si nécessaire (par exemple, lorsque nous perdre le focus, avoir des désaccords, ou se confondre). Il en résulte que le
plus complexe et impliqué tout effort est grand, plus il est probable que écrire certains des détails
à ce sujet permettra d'améliorer les chances de succès.

Le plus grand groupe de personnes travaillant ensemble est, le plus complexe et implique le travail sera. UN
équipe de trois personnes pourrait être en mesure de parler suffisamment dans le couloir de coordonner la façon dont leurs efforts
intégrer et maintenir en vie les objectifs finaux clairement à l'esprit. Cependant, une équipe de 20, 100, ou 1000
les gens ne sont pas ce luxe. Au lieu de cela, quelqu'un doit définir le plan de niveau supérieur pour l'ensemble de la
travail avant une grande partie commence, et elle a besoin de documenter d'une façon que tout le monde peut facilement utiliser
comme référence.
 Les choses par écrit sert aussi à communiquer les intentions d'une équipe dans un grand
organisation. Si le groupe A peut représenter leurs idées de base et les décisions de haut niveau dans un court document,
puis des groupes B et C peuvent comprendre les intentions de groupe A et soulever des questions ou de fournir de la rétroaction
rapidement. Le plus complexe et impliqué un projet est plus important que court document
devient, parce que les projets complexes ont des chances plus élevées pour les malentendus et des erreurs coûteuses.
Et, comme un bonus, de nouvelles personnes à l'équipe (senior et grands junior) peut lire une version distillée de la
idées fondamentales du projet et se mettre au diapason beaucoup plus rapidement que si elles ont dû apprendre ces idées fondamentales
sur une base ad hoc.

Page 69

4.2. Combien de vision avez-vous besoin?

Je l'ai vu documents de vision qui étaient 50 pages, soigneusement formatés avec recherche, des diagrammes,
et la réflexion stratégique. Je l'ai aussi vu des visions qui étaient un couple de pages d'articles à puces, avec une
quelques phrases décrivant chacun. Selon le projet, différentes quantités de structure et
la planification sont nécessaires. Ne faites pas l'erreur de penser que les documents de planification sont fixés, rigide
les choses: ils sont seulement des documents. Quelle est la profondeur ou de fantaisie dont ils ont besoin pour être dépend de la nature de la
projet et la culture de l'équipe. Toutefois, les bons documents de vision ont tendance à couvrir les mêmes types
de questions, mais le matériau varie en profondeur et de rigueur.

Pour vous aider à comprendre combien la structure et de l'investissement de votre document de vision doit, tenir compte de la
questions suivantes:

Combien de personnes différents seront touchés par le projet? Combien de différentes organisations
sont-ils? Comment allez-vous fixer des attentes de haut en bas, et à travers chaque organisation correctement?

Combien de questions valide ne l'équipe elle-même ont de l'avenir? Combien les personnes
ont besoin de savoir ce qu'ils vont faire et pourquoi ils vont faire ce?

Qu'est-ce que la profondeur de la rétroaction sur la direction du projet voulez-vous des autres?

Combien d'expliquer des décisions voulez-vous d'avoir à faire à personne? (Une bonne vision devrait
debout sur sa propre à représenter le projet à de nombreuses personnes.)

Combien de profondeur de la connaissance et de la pensée doit un chef de projet de fournir à l'organisation

dans le cadre de la prise de décisions au niveau du projet? (Une vision fournit la preuve de cela.)

Au cours du projet, combien profondeur de la pensée stratégique, l'équipe devrait avoir

accès à?

Qu'est-ce que la recherche ne dirigeants ou cadres supérieurs attendent de vous dans le cadre de la planification du projet?
Comment allez-vous livrer ce pour eux?

Il y aura un besoin de rappeler à l'équipe plus tard quels sont les objectifs? Sont les personnes susceptibles de faire valoir
plus tard, sur les questions spécifiques qui ont été convenus récemment?

Les plus détaillées et plus fort vos réponses à ces questions sont, plus la valeur d'une vision
 le document
beaucoup aura.eux
d'entre Si quelques-unes de ces
appliquent, et leur questions
lecture faitessevotre
posent,
tauxaller avec quelque chose
de désabonnement de léger et
de l'estomac, informel.
vous Si
aurez besoin des trucs plus lourd.

Il est juste de dire que ces questions sont plus précisément des questions de leadership et de la façon dont un chef de file
a l'intention de faire face aux défis de leadership, plutôt que des choses purement environ visions. Toutefois,
document de vision est le seul moyen que je connaisse pour attaquer simultanément plusieurs d'entre eux. Je suis également convaincu
que même si l'on travaille seul (solo-surhomme), écrire un document de vision informelle (par exemple, une liste
des buts) pour la semaine, le mois et l'année va un long chemin vers la conclusion de ces périodes de temps
avec quelque chose à être fiers. Une fois que les choses sont écrites, il est plus facile de tenir les gens responsables
pour eux, même si vous êtes seulement rendre des comptes à vous-même.

4.2.1. objectifs de l'équipe et des objectifs individuels

Pour parler en détail de visions, je dois définir certains termes. Visions, buts de l'équipe, et les objectifs sont souvent
utilisé dans des moyens de chevauchement. Voici une clarification de la manière dont je vais les utiliser:

Vision . Définit les objectifs de haut niveau pour l'ensemble du projet. Ceci peut également inclure une vision

Page 70

déclaration ou uber-but. (objectifs de haut niveau définis par une vision sont parfois appelés objectifs
pour les aider à distinguer des objectifs de niveau inférieur.)

objectifs de l'équipe . Le sous-ensemble de la vision d'une équipe en particulier est responsable, qui est défini dans
plus grande profondeur que la vision. (Par exemple, l'équipe A peut être responsable de la base de données
système et de ses objectifs, et l'équipe B pourraient être responsables pour le système de moteur de recherche et son
buts, mais ils partagent la même vision du projet.)

Les objectifs individuels . Le sous-ensemble des objectifs de l'équipe que l'individu est responsable.

Sur de petits projets, il ya peu de distinction entre l'équipe et les objectifs individuels (voir Figure 4-2 ). UN
projet pourrait même être assez qu'il n'y a pas besoin de ces distinctions petite. Mais le plus grand
projets avec 50 personnes ou plus, cette couche supplémentaire pourrait être nécessaire. Travailler sur de grandes équipes (environ
définie comme plus de 50 personnes) pour une grande partie de ma carrière, je suis habitué à voir ces trois couches: une
fixé pour l'ensemble du projet (vision), un jeu pour chaque élément ou zone du projet (équipe), et un pour
les objectifs personnels pour chaque employé qui travaille sur le projet (individuel). Les deux premiers sont des publics
record pour toute l'équipe; le dernier est entre le salarié et son manager.

Figure 4-2. Trois niveaux d'objectifs.

A titre d'exemple, prenons projeter Hydra, un site web intranet:

Vision Hydra. Le site web Hydra fera sources d'intranet les plus fréquemment utilisés (recherche,
comptabilité, stocks, RH, Voyage) facilement accessible depuis un site de web, avec un simple, Easy-
Interface d'utilisation.

Une équipe sera chargée de faire la recherche et de la comptabilité facilement accessible et simple à
utiliser. L'équipe B sera responsable de l'inventaire, RH, et Voyage.

Fred (équipe A) va concevoir et mettre en œuvre toutes les fonctionnalités requises pour la recherche. Mike (équipe B) sera
conduire l'effort global de conception et d'écrire toutes les spécifications de l'interface utilisateur pour Hydra. Bob (équipe
B) va concevoir et mettre en œuvre toutes les fonctionnalités requises pour les RH et Voyage.

L'idée est qu'il existe une forte héritage de haut en bas: les objectifs de l'équipe héritent de objectifs du projet,
et les objectifs individuels dérivent principalement de buts de l'équipe de la zone (la principale exception étant individuelle
besoins de formation ou la croissance qui ne peuvent être satisfaits dans le projet). À condition que ces trois niveaux
sont bien conçu, tout le monde devrait apparaître chaque jour, motivés pour faire un travail qui a du sens locale
à eux et contribue directement à l'ensemble du projet. Le temps qu'il faut pour mettre en place une structure comme celle-
est bien la peine. Il crée la synergie naturelle des objectifs communs pour l'ensemble de l'équipe et marques
gestion d'un projet beaucoup plus facile (voir Figure 4-2 ).

Différents documents doivent correspondre à ces trois niveaux de définition (ou très peu, différents
 discussions).
menant Pour l'ensemble
à la création de lade
du document vision dudeprojet,
vision le chef de
haut niveau. file
Elle du gestionnaire
devrait de groupe
alors attendre zone ououd'un
uber-projet devrait être
composant
dirigeants d'hériter et interprètent ces directives de haut niveau en objectifs pour leurs propres zones, éventuellement
soulevant des thèmes ou des objectifs spécifiques d'elle. Enfin, les contributeurs de niveau ligne devraient discuter avec leur

Page 71

les gestionnaires et les chefs d'équipe quels sont leurs objectifs et les responsabilités individuelles sont, dérivées de celles
objectifs de l'équipe.

Page 72

4.3. Les cinq qualités de bonnes visions

 Parce que tout découle de la vision de haut niveau, leader du classement général de l'équipe devrait investir davantage
l'énergie en elle que tout autre matériau de planification précoce. Les cinq caractéristiques les plus importantes sont:
simplifiant, intentionnelle (but-driven), consolidée, inspiré, et mémorable.

4.3.1. Simplifier

La chose la plus importante à rechercher est un effet de simplification sur le projet. Une bonne vision
fournir des réponses aux questions fondamentales des individus ont, et leur donner un outil pour faire
décisions dans leur propre travail. Alors que la vision sera probablement avoir des idées qui soulèvent de nouvelles questions, ces
devrait être moins nombreux que ceux qui ne doivent être posées. Dans les premières phases d'un
projet, les gens devraient se référer à la vision de toutes les discussions de Timein, e-mails, et
meetingsactively l'utiliser comme un outil pour aider à prendre des décisions et, espérons-le, des progrès. Le projet
Manager doit être à l'affût pour cela et être prêt à modifier et réviser la vision d'inclure
des questions imprévues qui rendront plus utile à l'équipe. La vision ne devrait jamais être comme un
relique, peluche derrière une vitrine. Il devrait être plus comme un livre de règles pour un bon
jeu de société, apporter de la clarté pour tous les participants, faisant des limites claires, et rapidement le règlement
litiges ou malentendus. Il doit être porté sur l'utilisation et ont griffonné des notes dans le
marges. Son effet devrait être de mettre fin à la ronde préliminaire rapidement et amener les gens dans le cœur
de l'action avec la confiance que le projet ne peut réussir.

4.3.2. Intentionnelle (but-driven)

Le document de vision est la première source d'objectifs d'un projet. Il donne le ton à ce que les bons objectifs ressemblent,
combien de buts il devrait être dans un plan, et comment beaucoup de raffinement les objectifs peuvent avoir besoin avant
ils sont complets. Un objectif bien écrit définit une intention claire pour les gens de l'équipe. Assez
information est fournie dans le but lui-même, ou en soutenant des informations sur l'objectif, que les gens vont
savoir quand il a été achevé. Ils devraient également être en mesure de séparer facilement des activités qui sont
susceptibles de contribuer à l'objectif de ceux qui ne seront pas. Ecrire de bons objectifs est difficile et très
subjective; il faut de nombreuses révisions pour obtenir un objectif fort, bien écrit. Les objectifs moins de haut niveau,
le plus puissant du document de vision devient. Comme une règle empirique, une vision de projet
document doit avoir quelque part entre trois et cinq objectifs de haut niveau (voir la prochaine
catalogue de bonnes énoncés de vision pour des exemples).

Un acronyme populaire d'affaires pour l'écriture de bons objectifs est SMART, qui signifie spécifique,
Mesurable, orienté vers l'Action, Réaliste et en temps opportun. L'idée est que si un but a chacun de ces cinq
attributs, il est susceptible d'être assez bien pour être utile (toutefois, un jugement subjectif reste défini
quant à la façon spécifique ou un but réaliste devrait être). Une autre technique qui peut vous aider avec des objectifs est
jouer l'avocat du diable: demander comment un projet peut encore échouer si son objectif peut être satisfait que par écrit. Alors
considérer si il ya une façon de formuler avec plus de soin l'objectif, ou si un autre peu de supplémentaire
information doit être fournie pour soutenir l'objectif.

4.3.3. Consolidé

Pour le document de vision à aucun pouvoir, il faut renforcer les idées de nombreux autres endroits. Ce
devrait absorber la pensée clé de la recherche, l'analyse, la planification stratégique, ou d'autres efforts, et d'être
la meilleure représentation de ces idées. Toute vision d'une équipe est un échec si elle exige la compréhension
le lecteur de faire encore la moitié du travail de l'auteur.

Pour cette raison, il est préférable de séparer les objectifs et les directives de l'ensemble de l'appui

Page 73

arguments et de la recherche derrière le plan. Il devrait y avoir un endroit pour trouver facilement tous ceux
pensées supplémentaires et des matériaux (une simple page web ou un site), et il devrait encourager la
diligente (ou les sceptiques) aller plus loin que le document de vision elle-même. Consolidation ne veut pas dire
improviser ensemble un assortiment aléatoire de referencesit signifie qu'il devrait y avoir cohérence
entre eux. Ils doivent utiliser le même modèle et de la mise en forme, ou au moins être facilement imprimable que
un volume: pas pour le bien de processus, mais parce que cela rend plus facile à lire, ce qui oblige
quelqu'un (de préférence la tête lui-même grand manitou) à considérer exactement combien de références ou sources
sont importants pour les gens de se familiariser avec. Ce nombre ne devrait pas être nulle, mais il ne doit pas être
15 ou 20 documents, essais, ou des rapports.

4.3.4. Inspiré

Inspiration ne vient jamais de choses superficielles (et en passant, même les gens superficiels exigent
l'inspiration authentique). Pour communiquer avec les gens, il doit y avoir un problème évident dans le monde qui a besoin
à résoudre, dont l'équipe a un intérêt ou la capacité à résoudre. Même si un chef d'équipe charismatique
peut aider, elle ne change pas la qualité des idées écrites dans la vision. En donnant au lecteur une
compréhension claire des possibilités qui existent, et de fournir un plan solide pour l'exploiter,
les gens qui ont toute capacité d'être inspiré, seront. Bien avec les programmeurs et les ingénieurs
il ya une tendance à inspirer des défis technologiques, il est facile de tirer les
défis du problème du monde réel que le projet doit résoudre. Assurez-vous que tout le monde
comprend que le projet est financé à résoudre le problème du monde réel et pas seulement le
technologique.
 4.3.5. Mémorable

Être mémorable implique deux choses: premièrement, que les idées avaient un sens ou dans certains étaient intéressants
façon; et, deuxièmement, qu'ils résonnent avec les lecteurs et resteront avec eux au cours des semaines et
mois d'un projet. Ils pourraient ne pas se rappeler plus de quelques points, mais cela suffit pour eux
à se sentir confiants quant à ce qu'ils font tous les jours. (Notez que si la vision est trop complexe pour
quiconque de comprendre, il est impossible de parvenir à cet effet. Les gens se souviennent rarement des choses qu'ils
ne comprends pas.)

Être mémorable est mieux servi par être direct et honnête. Si vous pouvez frapper au cœur des décisions
et les communiquer welleven si les gens ne pas complètement d'accord avec ceux decisionsthey restera
avec des personnes de plus que ceux d'une vision pleine d'idées qu'ils croient pleinement mais ont été enterrés dans faible
et l'écriture boueux. Donc, nous efforcer de faire de la vision claire et confiante. Donner à l'équipe des concepts forts
et façons de penser le travail. Évitez les idées flashy attrayants qui pourraient inspirer les gens dans le
à court terme, ou de capturer une mode ou une tendance volage, mais à court de vapeur, après quelques semaines, lorsque la valeur
l'idée a été dépensé.

Page 74

4.4. Les points clés à couvrir

Au cœur d'une vision devrait être des réponses à de nombreuses questions suivantes. Il est commun pour ces
Les sujets qui seront les grands titres dans un document de vision ou listés à la fin dans le cadre d'une section Q & A.
(Bien que, lorsque ces questions ne sont pas abordées dans le document de base et sont fabriqués dans un
annexe, attendre à voir ingénieurs FLIP pour les dernières pages, ce qui implique quelque chose de négatif au sujet de la
la force de l'écriture qui l'a précédée.)

Répondre à beaucoup de ces questions exige la participation de marketing, de recherche de la clientèle,

la conception du produit, ou d'autres experts qui sont disponibles pour youand cela ne devrait pas être une réflexion après coup.
Certaines des questions suivantes sont volontairement similaires aux questions posées dans le chapitre précédent
sur la planification. La différence est que ces questions sont inclinés lourdement vers les priorités et
décisions, plutôt que le contexte et la compréhension. Lors de la planification, il y avait de la place pour l'exploration,
mais la vision est obligé de prendre un stand et être décisif.

Quelle est la seule phrase qui définit cette version spécifique de ce projet spécifique? (Ceci est souvent
appelé l'énoncé de vision, ou pour les cyniques sur l'équipe, la déclaration sans vision. Exemples
pour cette sont offerts sous peu.)

Comment ce projet contribue aux objectifs de l'organisation? Pourquoi ce projet est plus
pertinents que d'autres qui pourraient également contribuer aux objectifs de l'organisation?

Quels scénarios / fonctionnalités pour les clients sont essentiels pour ce projet? (Priorité 1.)

Quels scénarios / fonctionnalités pour les clients sont souhaitées mais pas indispensable? (Priorité 2)

Qui sont les clients? Quels sont les problèmes à résoudre ne ce projet pour eux? Quelles sont les preuves ou
la recherche (par opposition aux opinions et spéculations) soutient ces revendications? Comment les clients
faire leur travail sans ce projet?

Qui sont les acteurs de ce projet dans l'organisation (les personnes ayant le pouvoir sur la
projet, mais qui ne sont pas nécessairement les clients)? Quel rôle auront-ils dans le projet? (Nous
les parties prenantes de couverture dans le chapitre 16 .)
 Pourquoi ces clients vont acheter ou vous abonner à ce service? (Versions de Obfuscated "parce qu'il est
cool »ou« parce qu'ils ont pas le choix »ne sont pas des réponses acceptables. Toutefois, des résumés des
Ce que les utilisateurs cibles paient actuellement, et comment le nouveau projet correspond à leur mode de vie,
budgets, ou des habitudes quotidiennes, seraient. Bien sûr, dans une situation d'IT, la réponse peut être "parce
ils ont pas le choix. ")

Qui sont les concurrents et comment ce projet comparer à eux? (Les versions antérieures de même
les projets doivent être inclus dans la concurrence, ou éventuellement des alternatives non technologiques tels que
crayon et du papier. La conception simple du Palm Pilot est attribuée à papier car le primaire
concurrent, pas d'autres appareils électroniques.)

Quelles solutions pour les clients ont été demandés ou suggérés, mais ne sera certainement pas une partie
de ce projet?

Comment est-ce pas une technologie à la recherche d'un problème?

Quel est le projet ne va pas à accomplir? (Ne pas être pédant: la liste des choses les gens pourraient
deviner ou supposer ferait partie du projet, mais ne sera pas. Inclure politique, des affaires, et
perspectives des clients si elles ne sont pas déjà couverts.)

Quels sont les moyens probables pour ce projet particulier à l'échec, et comment vont-ils être évités ou
minimisé? (Dans les premières versions, il peut y avoir seulement des évaluations de risque, mais sans plans pour
gestion / les éviter.)

Page 75

Qu'est-ce que d'autres entreprises ou des groupes est ce projet comptent sur pour réussir? Quel autre
entreprises ou groupes comptent sur ce projet afin de réussir?

À un niveau élevé, comment le travail se divise sein de l'équipe? Qui sont les responsables pour chaque
sous-domaine majeur du projet, et de quelle autorité ont-ils?

Quelles hypothèses sont faits que le projet dépend? Qu'est-ce que le fait dépendances
projet ont sur d'autres projets, des entreprises ou des organisations?

Pour toute question ou point qui est considérée comme critique, il devrait y avoir solide comme le roc pensée derrière elle.
Le gestionnaire de projet doit chercher les membres les plus intelligents et les plus sceptiques de l'équipe, et
les enrôler pour percer des trous dans la logique et arguments à l'appui derrière états clés. Car
Ces points seront la pierre angulaire de tout ce qui suit, ils devraient être irréfutable. Ce
processus de rétroaction est souvent mieux fait de manière informelle, en tête-à-tête ou en très petits groupes, avec le projet
gestionnaire intégration de la rétroaction et d'envisager de nouvelles perspectives après chaque discussion.
Page 76

4.5. Sur bien écrire

Même pour ceux d'entre nous qui, naturellement, bien communiquer, des visions et des documents de leadership apporter
avec eux le potentiel de grande prétention. Soudain, il ya une occasion de montrer à l'ensemble du
organisation comment Grand notre pensée isthe tentation ego est difficile de résister. Mais l'écriture prétentieuse
va contre son propre but; au lieu de communiquer des idées, il les obscurcit.

4.5.1. Il est difficile d'être simple

L'erreur la plus commune dans les visions d'écriture est assimilant complexité de la pensée de la complexité des
présentation. Contrairement à ce que beaucoup de gens pensent, il prend beaucoup plus de travail pour exprimer
idées sophistiquées d'une manière simple que le contraire (l'écriture du code et des essais d'écriture partager
relation). Dix pages de résumés, avertissements, des graphiques, des diagrammes et peuvent facilement masquer la
idées centrales d'une vision. Leur inclusion ne pourrait prouver les insécurités et le manque de concision sur
la part de l'auteur (lu aucun journal académique ou philosophique pour des exemples abondants de cette).
Malheureusement, ce comportement est facile à copier. Il a tendance à commencer par le haut des organisations et saigner bas,
causant des niveaux quasi-mortel de ballonnement de communication et les frais généraux. Dans certaines entreprises, il est difficile d'être
que les documents sont en anglais.

Pour cette raison, le document de vision établit plus que la direction du projet. Ce
établit le ton et la qualité de la communication les gens devraient attendre de l'autre tout en travaillant
sur le projet. Il est une chance pour les chefs d'équipe de démontrer pour tout le monde comment couper à la
chasser et à bien communiquer. Au contraire, si la vision est pléthorique, jargonneux, pompeux,
hautement spéculative, contradictoire, voire délirant, il ne devrait pas être une surprise que la résultante
projet aura les mêmes caractéristiques.

Bons documents de vision jamais se détourner de leurs idées de base. Ils évitent préfaces, avertissements, et
introductions, et ils ne font aucune tentative de cacher la clé (et peut-être controversé) des décisions
qui va définir le projet. Pour cette raison, ils sont souvent courts et faciles à lire. Beaucoup mauvaise vision
les documents que je ai lu étaient de grands volumes qui ont été intimidants pas à cause de l'éclat même de
pensaient qu'ils ont exprimé, mais en raison de leur taille physique. L'intimidation a travaillé: personne ne lire la
document.

4.5.2. Bien écrire exige un auteur primaire

Beaucoup des pires documents de vision que je ai vu ont été générés par les comités. Petits comités peuvent
agir parfois de bons conseils de sondage, mais ils ne devraient jamais jouer le rôle de l'auteur principal
ou l'autorité de prise de décision. Sauf chimie exceptionnelle et une vision partagée (généralement
anathème, compte tenu de la politique de comités), les perspectives de concis, écriture claire, passionnés sont
lamentable. Par conséquent, le gestionnaire de projet ou chef de file besoin de l'Autorité à l'auteur de la vision et entraînement
une seule voix en elle, avec la compréhension complète qu'il est son travail de ne pas écrire un reflet de sa propre
la personnalité, mais plutôt à encapsuler les meilleures idées et de penser disponibles dans l'organisation. La
un auteur doit être un collaborateur fort qui est en mesure d'intégrer les meilleures idées et les opinions des
d'autres en un seul document.

Une référence canonique pour l'auteur principal est la Déclaration d'Indépendance américaine. En 1776, la
Congrès continental a formé un comité de rédiger ce document. Le comité a rencontré à plusieurs reprises,
mais reconnaissant l'importance de la clarté dans le document, demandé Thomas Jefferson pour rédiger un projet de
la déclaration. Tout comme je suggère pour une équipe de projet, Jefferson a écrit de nombreux projets et
engagé dans des discussions avec le Congrès au cours de plusieurs révisions. Le groupe a livré un
document final au Congrès plusieurs semaines plus tard. Ce rôle n'a pas besoin d'être très visible; Jefferson
ne pas faire une tournée de dédicaces ou mentions de produits pour son travail sur la Déclaration. Il était
tout simplement accordé le pouvoir de faire usage de ses compétences dans le meilleur service pour son équipe.

Page 77

4.5.3. Volume est pas la qualité

 Il faut comprendre que la pensée claire ne nécessite pas beaucoup de pages. Le plus efficace
documents de leadership dans le monde ne sont pas très long. La Constitution des États-Unis, y compris le projet de loi de
L'homme, est une simple 7000 mots (environ 6 pages). Les 10 commandements sont 300 mots. La Magna
Carta est 5000. Bon, penseurs clairs sont capables de distiller des idées jusqu'à leur noyau et des éléments centraux,
et ils les expriment d'une manière qui est plus puissant que deux fois plus de pages. Volume devrait
ne pas confondre avec la qualité. Malheureusement, parce que le volume est plus facile à produire que la qualité, nous
donnent parfois à la tentation de «Si nous ne pouvons pas être bon, nous pourrions aussi bien être long et peut-être
Personne ne remarquera "(une autre habitude d'auteur comité de plomb). Bien que dans cet esprit, il est juste
de se demander pourquoi je ne suis pas en mesure de faire ce livre plus court. Mea culpa .

Tous ces points impliquent que la propriété de la rédaction et la révision d'une vision devrait être affecté
attentivement. Les chances sont bonnes que le meilleur communicateur dans l'organisation est pas la personne avec le
plus le titre du poste principal. La probabilité la plus élevée pour la création d'une bonne vision requiert le chef de projet
à connaître ses propres forces et faiblesses, ainsi que celles du peuple sur son personnel.

Page 78

4.6. Rédaction, révision et la révision

Chaque organisation a différentes considérations à faire dans la façon dont ils envisagent des projets. Je ne peux pas offrir un
plan simple, en cinq étapes pour savoir comment obtenir du jour 1, sans vision, le jour 20 (ou 5 ou 50) avec un
achevé et entièrement parrainé vision. Selon la façon dont beaucoup d'autorité-vous faire ou ne pas avoir, il
peut prendre beaucoup de temps pour obtenir toutes les approbations nécessaires et d'avoir tout le nécessaire
conversations d'ouvrir la voie pour le projet.

Mais ce qui est important est que le processus de définition de la vision commence avant l'actif
projet pour votre équipe est complète, et il doit être terminé avant que l'équipe devrait se déplacer à
pleine vitesse sur le prochain. Parfois, une personne peut être retiré d'un projet dans ses dernières phases
et peut consacrer la moitié de son temps à la reconnaissance sur les questions clés énumérées plus tôt. Le chef de projet peut
puis ramasser l'élan de ce travail et de se diriger vers un projet plus vite qu'il le pourrait si
il travaillait seul.
 Souvent, la partie la plus exigeante de ce processus, à la mi-taille ou de grandes organisations, travaille avec
la haute direction et d'autres équipes pour coordonner ce qui doit être fait (voir chapitre 16 ). Etes-
il prévu de la chef de la direction ou des cadres pour l'ensemble de l'entreprise que l'impact de cette prochain projet? Etes-
il ingénieurs ou d'autres leaders d'opinion qui ont besoin d'être consulté? Qui sont les leaders dans le
organisation (l'équipe locale et l'ensemble de l'entreprise) qui ont l'expertise, ou de l'influence politique,
que nous devons être conscients et établir des relations avec? Sont des idées fondamentales il que nous sommes censés
à tenir, ou au moins envisager de délivrer sur? Faites d'autres projets dans l'entreprise ont besoin de nous pour livrer
quelque chose pour eux afin qu'ils puissent réussir dans leurs efforts?

Dans de bonnes situations, les cadres supérieurs apportent des réponses claires à certaines de ces questions et
reconnaître l'incertitude qu'ils créent pour le projet quand ils partent de bonnes questions
sans réponse. Dans de mauvaises situations, un lourd fardeau est placé sur le chef de projet de créer sa propre
réponses et apprennent seulement par essais et erreurs ce sont les limites réelles. (Sinon, si vous êtes dans un
petite boutique et ont seulement vous-même ou vos pairs à répondre à, tous ces cadres supérieurs
les questions et les charges sont naturellement, et pour le meilleur ou le pire, la vôtre.)

En tout cas, la nature du travail est le même. Étant donné un échéancier prévu entre l'achèvement de
le projet actuel et le moment où le nouveau projet doit être à pleine vapeur,
des points intermédiaires doivent être fixés pour les brouillons, passe en revue avec les dirigeants qui représentent l'ensemble
équipe et complets premières ébauches d'une vision pour le projet. Attendez-vous à ce que à chaque point de contrôle, le temps
seront dépensés révision et l'amélioration du projet (par opposition à supposer que chaque rencontre se terminera
avec le hochement de tête de chambre dans l'accord). Commencez petit, et augmenter progressivement le soutien au processus
et les idées centrales au fil du temps, ce qui les rend mieux après chaque opportunité pour la rétroaction. Le calendrier
pour ce processus devrait être rendue publique (voir Figure 4-3 ), et les gens dans le petit groupe ne devrait pas
être caché dans les bureaux spéciaux ou dans d'autres bâtiments. Ils doivent être visibles et accessibles au
équipe (même si il faut prendre soin de ne pas les distraire du projet en cours). Encourageant
questions et la visibilité est toujours utile transitions en douceur dans un nouveau travail.

Figure 4-3. Un horaire de base pour l'examen et la révision d'une vision

document.

Page 79

Une partie de ce processus doit inclure une présentation des idées clés, et le projet de la vision, à l'ensemble du
équipe (aka réunion tout-mains) assez tôt qu'il est pas un prétexte complète, mais son horaire tardif
assez qu'il ya quelque chose de substantiel à dire. Bien que cela est effrayant pour les nouveaux dirigeants, si une réunion
est tenue au moment où les idées fondamentales sont solides, mais certaines questions demeurent, l'occasion est
créé pour tout le monde sur le projet pour voir la vision comme quelque chose de vivant et accessible. Ils ne vont pas
rejeter si elle est quelque chose qu'ils peuvent encore influencer et de question. Si la vision a grandi à travers
de nombreuses conversations et des possibilités de rétroaction, le déploiement de l'équipe se sentent naturel
toutes les personnes impliquées.

Lorsque la vision est terminée, la phase de planification est terminée (voir Figure 4-3 ). L'équipe devrait avoir
les informations nécessaires pour faire du bon travail de conception qui répond aux objectifs. Si un processus d'examen comme le
celui montré dans la figure 4-2 a été utilisé, l'équipe devrait avoir une longueur d'avance sur la conception, car
ils ont été mis au courant de la direction générale dès le début.
Page 80

4.7. Un catalogue des énoncés de vision boiteux (qui devrait être

évité)

Je l'ai lu des dizaines de documents de vision dans ma carrière, et il ya certains modèles les mauvais
partager. Visions boiteux ont pas l'intégrité; ils ne proposent pas un plan, et ils ne se prononcent pas.
Au lieu de cela, ils spéculent, et d'éviter la possibilité de se tromper. Si la vision ne prend pas clair
position sur ce qui devrait arriver, les dirigeants de l'équipe ne sera jamais pleinement investir émotionnellement derrière l'effort,
la mise en place du projet à l'échec. Dans le film Fight Club , Tyler Durden dit, "Tirer plumes jusqu'à
vos fesses ne fait pas de vous un poulet. "La rédaction d'un document avec le mot vision dans le titre ne fait pas
dire que vous avez une vision. Vous pouvez avoir toutes les bonnes rencontres et d'utiliser les modèles de documents droite
et de manquer encore le point de ce que les documents de vision devraient faire ensemble. Dans le même sens que la présence
le titre du poste chef de projet ne fait pas par magie tout ce que vous faites un acte de leadership, appelant
quelque chose d'un document de vision ne signifie pas que cela aura les effets que je l'ai décrit précédemment.

Tableau 4-1 montre certaines des choses communes que je l'ai vu dans impressionnant à la recherche de documents de vision qui
les disqualifier d'avoir valeur de direction du projet.

Tableau 4-1. Énoncés de vision boiteux communes

Lame énoncé de vision Exemple Pourquoi il arrive / échoue

L'évier de cuisine L'évier de cuisine L'évier de cuisine
Le charabia Le charabia Le charabia
Le mauviette-o-matic Le mauviette-o-matic Le mauviette-o-matic
Qu'est-ce que le vice-président veut Qu'est-ce que le vice-président veutQu'est-ce que le vice-président veut
Page 81

4.8. Des exemples de visions et objectifs

Dans cette section, je donne quelques exemples de bonnes déclarations de vision et les objectifs du projet tiré de mon
propre expérience. Bien que je l'ai changé les détails, il est facile d'imaginer ce que travailler sur ces
projets seraient comme, ainsi que ce que les objectifs sous les visions peuvent contenir.

Voici des exemples de bonnes déclarations de vision:

SuperEdit 3.0, l'outil d'édition pour les réviseurs expérimentés, fera le top cinq plus
scénarios clients fréquents faciles à utiliser, plus fiables, plus rapides et à exploiter que SuperEdit
2.0.

Superwidgets.com sera le site de widgets achats Premier ministre sur l'Internet pour l'achat
agents de sociétés de taille moyenne. Il fera tout le processus de l'achat pour le widget
moyennes entreprises simples, faciles et sécuritaires.

Le Helpdesk Services automatisés site (HASS) Version 5.5 abordera le top 10 clients
plaintes à travers l'université, sans aucun impact négatif sur la performance moyenne,
la fiabilité ou le temps de réponse à travers le système.

Comme un exemple de bonnes buts du projet, voici ce que l'équipe de personnes qui a développé le Palm Pilot
organiseur portable utilisé pour définir leur projet: (2)

1. Taille. Tenir dans une poche de chemise. Être assez léger pour ne pas sembler laborieuse.

2. Coût. Moins d'un agenda papier de luxe (300 $ USD).

3. Simplicité. Il devrait être aussi simple que de papier. Active instantanément et utilise de simples conventions.

4. Synchroniser avec le PC. Utilisez le PC comme un point d'interaction commune pour le client.

Les objectifs du projet bons comme ceux-ci sont clairs et simples, et décrire le monde tel qu'il sera lorsque le
le travail est terminé. Rappelez-vous que la simplicité est différent de difficulté. Il était un important
défi technologique et design pour créer un produit qui satisfait à ces objectifs. Le précédent
des exemples de bonnes déclarations de vision pourraient représenter d'énormes défis pour ces projets. Selon
sur la façon dont "premier", "facile à utiliser", et "top plaintes" sont définies, ces projets pourraient avoir grand
défis qui les attendent.

4.8.1. Soutenir déclarations et objectifs vision

Les allégations formulées dans un énoncé de vision, ou dans les objectifs du projet, devraient être pris en charge ou clarifiés
quelque part dans le document. Donc, ce que signifient ces déclarations par les besoins des clients , plus facile à
effectuer , la fiabilité , et top plaintes des clients doivent être définis avec suffisamment informé que
décisions peuvent être prises. Si ces choses sont suffisamment importants pour être dans la vision, ils sont importants
assez pour enrôler l'aide d'experts en eux étoffer à la même précision et de détails que technologique
buts. Si des allégations telles que "facile à utiliser" sont faites, mais personne n'a aucune expertise à propos de la facilité d'utilisation, la
l'équipe n'a pas mis en place pour atteindre cet objectif. En produisant la vision, les dirigeants devraient évaluer ce
des ressources sont nécessaires pour réussir et comment les lacunes en matière de ressources et de compétences seront remplis (les choix sont
train, location, changement vision, ou croiser les doigts).

Page 82
 4.9. Visions devraient être visuel

"Un doigt pointe vers la lune. Ne confondez pas le doigt pour la lune."

Parabole zen

Visions gagné leur nom pour une raison: ils sont censés faire appel à notre capacité à imaginer et à
visualiser un type spécifique de résultat. En regardant une image, nous absorbons de nombreux niveaux de toutes les informations
immédiatement. Pour de nombreux concepts et des idées complexes, les images offrent un accès plus rapide et une plus grande clarté à
plus de personnes en moins de temps que les mots. Je ai eu des dizaines de conversations dans mon bureau avec
des programmeurs ou des architectes qui luttent pour clarifier des points d'un argument, pour finir quand
l'un de nous va enfin sur le tableau blanc, rapidement esquisse l'idée, et demande: «Voulez-vous dire comme
ce? "Puis nous avons l'habitude tous rire de combien de temps nous avons perdu à essayer d'expliquer des modèles d'objets ou
dessins avec nos paroles ou nos mains, quand un marqueur et tableau blanc auraient été beaucoup plus rapide.
Je pense que la culture américaine souligne les aptitudes verbales et mathématiques plus de dessin et de compétences artistiques,
et les réflexes de la plupart des professionnels ont été formés pour aller dans cette direction. Je suis convaincu que,
à notre détriment, nous oublions le pouvoir des images pour exprimer des idées.

Les meilleurs documents de vision, je l'ai vu inclus des images visuelles. Ils fournissent des dessins bruts, mock-
ups, ou des prototypes de ce que le résultat final pourrait ressembler si la vision est suivie. Ceux-ci ont été offerts
que des suggestions et des coupes grossières, de donner aux gens juste assez d'une idée pour aider les buts dans la vision
cristalliser dans l'esprit des lecteurs. Il est fait clairement ces maquettes sont loin d'une version finale de
ce qui sera construit. Très loin. Au lieu de cela, ils sont présentés comme une seule première tentative pour répondre aux idées
dans la vision. Ce genre de spéculation permet aux gens de parler de l'œuvre elle-même, plutôt que de seulement
les abstractions du travail fourni par la vision.

Des maquettes et des prototypes résonnent souvent plus avec les ingénieurs et les programmeurs les plus hard-core
que tout schéma de modèle d'objet ou de l'échantillon de code. Contrairement à ces formes familières et abstraites
expression, le prototype visuel montre quelque chose qui ne existe pas encore, mais peut. Gratte-ciel
les architectes et les designers automobiles font beaucoup de maquettes et de prototypes physiques pour les aider à
comprendre les idées avec lesquelles ils travaillent et pour obtenir des commentaires sur les idées des autres.
Les cinéastes utilisent storyboards pour le même but. Bons documents de vision ne doivent pas hésiter à
en utilisant des techniques similaires. Montrant un croquis de la dernière chose permet à chaque personne de mettre sa propre
travailler dans un contexte plus large. Les membres de l'équipe ne sont pas seulement en train de construire une composante plus. Ils maintenant
avoir une idée de ce que leur composante rendra possible quand il sera terminé.

4.9.1. Visualisation des choses non-visuels

Juste parce qu'un projet n'a pas une interface utilisateur ou interagir avec les clients ne signifie pas qu'il ne peut pas
visualiser. Comment changer le monde lorsque le projet est terminé? Peut-être la vision est d'environ
l'élimination d'un problème ou de frustration pour les gens (serveurs lente, le blocage des bases de données, etc.).
Cela peut être visualisé en montrant avant et après vues (ou simulations) de la même web siteor une
prototype qui a comparé la séquence des étapes les clients auront à faire avant et afterexpressing
comment les choses beaucoup plus simples seront quand la nouvelle architecture ou base de données est mis en œuvre.

Il ya souvent plusieurs façons à exprimer visuellement idées, quel que soit abstrait ou technique qu'ils
peut sembler. Si le projet permettra aux clients de passer moins de temps à leur bureau, montrer un vide
chaise par un bureau. Si le projet fera la base de données plus rapide, montrer deux démos, un avant et un
après. Si le taux d'une API de système embarqué d'échec va diminuer de 10%, montrer le cas de test qui est
étant utilisé pour mesurer ce, avant et après le projet. Donner une image visuelle de l'équipe, peu importe
comment terne ou ennuyeux, il est, pour encadrer autour de leur travail individuel.

Si ce résultat final ne peut pas être visualizedeven comme un simple croquis, une maquette ou un chartthen je dirais que
la vision est pas claire. Si vous ne pouvez pas trouver aucune représentation visuelle de l'impact du projet sur la
univers, avoir peur que ça dirigée vers quelque chose que le monde n'a pas besoin, ou qu'il ne va pas bien

Page 83

assez défini pour vous d'être couronnée de succès.

Cette compétence d'imaginer l'avenir et la visualisation des idées, en particulier lorsque les clients sont impliqués, est
le domaine de designers. Parfois, ils sont appelés interaction, produit, ou même des designers industriels.
Ce sont des professionnels qui ont été formés sur la façon de transformer des idées en images et abstraite
pensées dans les détails de ce que les clients vont voir. Alors que certains ingénieurs ou chefs de projet
pourraient avoir ces talents, peu ont les cultivée en compétences. Si la facilité d'utilisation et le client
satisfaction sont les objectifs, puis les services de designers devraient être acquises au début d'un projet, et
contribuant cet aspect à la vision ne serait que l'un des apports naturels qu'ils feraient
au projet. Si apporté une autorité suffisamment tôt et accordé à être vraiment impliqués, ils ont non seulement
fabriquent des produits semblent bonnes, mais aussi contribuera de manière significative à rendre le produit lui-même bon.
Page 84

4,10. Le chèque vision de la santé mentale: le culte quotidien

Un des exemplaires originaux de la Constitution des États-Unis se trouve dans une voûte, derrière les vitres épaisses de plexiglas, dans un
musée à Washington DC Bien qu'il soit sûr et sécuritaire, je suis certain que peu de gens lisent dans ce
le format. Quand les idées ne sont pas accessibles ou gardé à la lumière, ils disparaissent (sauf si elles sont importantes
assez pour obtenir leurs propres expositions dans les musées). Même sur des projets à court terme, il est facile de perdre la trace de
comment les décisions quotidienne se réinsérer dans l'ensemble plus vaste, et le manque de visibilité des idées de base
favorise ce genre d'entropie. Les gens pourraient être très occupé et se sentir bien sur les modules et
pièces qu'ils construisent, mais sans les points fréquentes et communes de référence, il est difficile de savoir
si tout est toujours en cours dans la bonne direction. La vision, ou les idées de base et les objectifs qui font partie
de celui-ci, doit être gardé en vie dans les couloirs et les bureaux des personnes qui font le travail.

Pour garder la vision visible, quelques objectifs de base devraient être en place sur les affiches dans les régions à fort trafic de la
couloir. Ils devraient être discutés ouvertement dans les réunions hebdomadaires ou mensuels, lire à haute voix à l'ensemble
chambre avant la réunion commence. ponts de diapositives ou d'autres matériaux utilisés à l'intérieur de l'équipe devraient avoir
ces quelques points de base sur la première diapositive ou la première page. La plupart des personnes de l'équipe, la plupart du temps,
devrait être en mesure de nommer la plupart des objectifs du projet, certainement au moins ceux qu'ils sont
contribuant directement ou sont tenus responsables pour.

Mais cette visibilité ne garde pas nécessairement la vision vivante. Le fait que les gens peuvent rappeler ou ont
mémorisé cela ne signifie pas qu'ils continuent à l'utiliser et de les évaluer afin de les aider dans leur travail.
Garder la vision vivante nécessite une action de la part des chefs d'équipe. Ils doivent continuellement
réappliquer le même raisonnement qui a conduit à sa création.

Posez les questions suivantes à chaque réunion de l'état ou de leadership à travers le parcours d'un projet:
 1. Est-ce que la vision reflète exactement nos objectifs et nos intentions pour ce projet?
2. Est la vision aide prospects et les contributeurs individuels à prendre des décisions et de rejeter les demandes
qui sont hors de portée?

3. Y at-il des changements à la vision que nous devrions considérer que ferait # 1 et # 2 vrai?

Si les dirigeants d'une organisation peuvent rendre le document de vision une chose vivante, elles permettent
tout le monde à faire de même. La vision et les objectifs restent en bonne santé et peuvent être une source continuelle de
la motivation et la clarté pour l'ensemble de l'équipe.

Cela ne veut pas dire que la vision devrait être modifiée fréquemment. Au contraire, des changements majeurs doivent être
rare après le projet se déplace à pleine vitesse. Mais comme avec un amendement constitutionnel, la possibilité
devrait exister que certaines situations peuvent justifier le changement. Et ce potentiel permet de garder tout le monde
forte et des idées centrales de la vision dans l'esprit de tout le monde.

Page 85

4.11. Résumé

documents de Vision distillent autres documents de planification dans un plan unique et de haut niveau.

Les choses par écrit sert l'auteur et l'équipe. Il fournit une base de discussion et un
point de référence qui ne repose pas sur nos mémoires faillibles.

La quantité de détails dans votre document de vision varie selon la nature de l'équipe et de la
projet.

buts de l'équipe devraient provenir objectifs définis dans la vision. Les objectifs individuels devraient découler de
les objectifs de l'équipe.

Bonnes visions sont simples, le but entraînée, consolidée, inspiré, et mémorable.

Volume ne pas égale qualité. Il faut plus d'efforts pour être concis que non.

Gardez la vision vie en posant des questions sur l'utilité de la vision à des décisions quotidiennes sur la
projet.
Page 86

Chapitre Cinq. Où les idées viennent de

La vérité moins-que-étonnant sur ​les origines des idées est qu'ils proviennent de personnes. Aucune idée
dans l'histoire de l'humanité ait jamais provenir d'un tas de grosses pierres, un monticule de terre chaude, ou d'un
faisceau de pointus, bâtons pointus. Avoir des idées proviennent de l'auto-assistance des livres, des séminaires de créativité, ou ne
des séances de remue-méninges. Alors que les idées pourraient être présentées ou consommés par ces choses, il est le
les gens qui les créent que sont la source. Il en découle que sur les projets, il est individualsand pas
processus, méthodologies, ou committeeswho viennent avec des idées et des façons de les appliquer
vers le travail qui doit être fait.

Donc, il n'y a rien de magique idées. Nous sommes tous capables de venir avec eux (même si certains
nous sont beaucoup mieux que d'autres). Ne jamais oublier qu'il est la nature fondamentale de l'homme
et d'autres créatures d'utiliser leurs pouvoirs créateurs et cognitives pour résoudre les problèmes qu'ils rencontrent dans
le monde. Malgré le peu d'éducation ou l'expérience que nous pourrions avoir dans nos vies modernes pour savoir comment
appliquer effectivement ces compétences, ils sont toujours là. Notre espèce est toujours là surtout parce que nous trouvons
des moyens pour faire face à des défis, et d'inventer des outils et des stratégies pour nous aider à les surmonter. (Bien qu'il
est juste de se demander si notre capacité à inventer des choses, telle qu'appliquée actuellement au 21e siècle, les causes
plus de problèmes que nos inventions résoudre.)

En ce qui concerne les projets, la capacité de trouver de bonnes idées est important dès le premier jour à la dernière. Bien
idées sont nécessaires pour prendre des décisions de la planification, développer des conceptions, écrire du code de qualité, et de livrer
travail qui répond aux besoins du client. La portée de ces idées peut être différent (par exemple, un certain impact de la
ensemble du projet et d'autres impacts seule ligne de code), mais le processus de découverte et de choisir
entre eux est très similaire. Dans ce chapitre et le suivant, je vais vous expliquer ce processus. Dans ce
chapitre, l'accent sera mis sur la façon de venir avec des idées et de faire la pensée créative. Chapitre 6 sera
définir comment gérer le processus créatif et de travailler avec des idées une fois que vous les avez.

Pour la plupart, je serai en utilisant la phase de conception du travail (voir chapitre 2 ) pour illustrer le processus de
travailler avec des idées. Ceci est à peu près la période de temps après un plan de haut niveau a été créé (par exemple,
vision) mais avant la mise en œuvre a commencé. Si vous ne pas organiser votre projet de cette façon, que ce
Page 87

bien: ce chapitre sera toujours utile pour vous. Le conseil ici est facilement appliqué à tout type de de problèmes
la résolution ou la situation idée génératrice.

Page 88

5.1. L'écart des exigences à des solutions

Pour des raisons que je ne peux pas expliquer entièrement, beaucoup de gens ont de la difficulté à planifier le travail créatif. En plus de la
livres que je ai lu sur le développement de logiciels et la gestion de projet, il ya une pénurie de
la couverture sur la façon d'obtenir à partir d'une liste d'exigences pour ce qui devrait être mis en œuvre, à une bonne
conception. Horaires ont souvent une date pour quand les exigences sont censés être fini, et
une autre date pour que les spécifications sont censés être terminé, mais peu d'instruction est prévue pour
 ce qui se passe entre ces deux dates (voir Figure 5-1 ).

Figure 5-1. Le design est souvent considérée comme un processus mystérieux entre le début
la planification et les spécifications terminés.

Maintenant, cela peut être très bien si le travail en question est très progressive, direct et simple. La
l'ambiguïté de ce temps est atténué par la simplicité de l'œuvre créatrice qui doit être fait. Mais
Sinon, un manque de définition pour savoir comment s'y prendre pour concevoir quelque chose met en place l'équipe à l'échec. (1) Si
les problèmes sont complexes, l'équipe aura besoin de temps pour évaluer différentes approches et apprendre
les meilleurs d'entre eux avant qu'ils ne commettent pleinement à leur construction.

Comme un voyageur à une bifurcation de la route, savoir où vous voulez aller («la maison, s'il vous plaît") ne vous dit pas
rien sur la meilleure façon d'y arriver ("tous les trois des routes, au moins de l'endroit où je me tiens, regardez
même "). Les voyageurs avertis chercher des façons de minimiser les chances d'aller dans une voie sans issue.
Peut-être ils marchent à une courte distance en bas de chaque route, ou trouver un autre point de vue (une colline, un
montagne, un satellite en orbite géocentrique espion contrôlé à distance) qui leur donne plus d'informations.
Plus ils ont besoin d'aller sur leur voyage, plus l'investissement de temps pour l'exploration
a probablement besoin d'être.

Il ya deux façons simples de combler l'écart. Exigences de haute qualité sont une option, et la conception
l'exploration est l'autre. Parce qu'ils sont très lié à l'autre, il est pas rare que ceux-ci
deux activités se chevauchent dans le temps.

5.1.1. Les exigences de qualité et éviter les erreurs

Dans le chapitre 3 , je fourni une explication de base des exigences et de leurs rôles dans le processus de planification.
Environ, les exigences de qualité définies communiquer efficacement les besoins du client et / ou la
objectifs du projet, avec une clarté suffisante pour être une action pour celui qui fera le travail. Un bien
exigence peut pas définir la façon de résoudre un problème, mais plutôt, il peut identifier clairement un problème
assez que quelqu'un avec l'expertise peut travailler en toute confiance pour le résoudre. La plupart des logiciels
et les équipes de projet que je ai rencontrés ont au moins un processus d'exigences informelle, peut-être
simple que des échanges de courriels avec des listes à puces de besoins d'une phrase.

Exigences sont essentielles. Ils agissent comme le point de départ pour générer des idées et des solutions potentielles.
Si l'état des besoins "Il y aura une grange et il doit être vert», puis tous ceux qui font la conception pour

Page 89

le projet sera de penser à différents types de granges verts. Ceci est utile de deux manières. Tout d'abord, il
élimine de nombreuses idées de considération possible (toute personne présentant des croquis de vaisseaux spatiaux bleu peut
être corrigé facilement). Deuxièmement, il permet aux concepteurs de poser des questions à explorer davantage le
exigences. Un concepteur peut poser des questions de bas niveau, comme «Est-vert lime acceptable ou unique
verts foncés? »ou« Combien de pieds carrés ne la grange besoin d'être? ", ou des questions de haut niveau, tels
comme «Qu'est-ce que la grange il être utilisé? Avez-vous envisagé un loft? Il est probablement moins cher et peut être
mieux à vos besoins. "Selon la personne qui a des exigences et de l'autorité de conception (voir chapitre 3 ),
différentes personnes auront le pouvoir de décider comment les questions sont répondues. Mais tout le monde devrait
être encouragés à poser des questions et sonder les besoins, ce qui améliore leur qualité.

Donc, plus l'attention portée aux exigences écrits avec soin, plus les chances sont que les concepteurs
va trouver des solutions pour y répondre. Si aucune exigence sont écrits, alors celui qui fait la conception est
travaillant à son propre risque (par exemple, si vous concevez sans exigences, il est dans votre intérêt de rédiger
certains). A titre indicatif pour mieux répondre aux exigences, voici une courte liste des erreurs courantes à éviter
exigences d'écriture (voir Exploration Exigences: Qualité Avant de design , et par Donald Gause
Gerald Weinberg, Dorset House, 1989, pour plus).

Fournir un plan pour les besoins de la négociation et l'itération . Parce que les exigences permettent
concepteurs de poser des questions, les chances sont bonnes que certaines des questions sera assez bon
pour forcer à repenser les exigences. Celui qui a l'autorité des exigences devrait être
la planification de cette et soit entamer des discussions avec les concepteurs assez tôt pour les intégrer,
ou prendre des dispositions pour des modifications aux exigences plus tard, après quelques idées ont été
proposée. Le plus ciblées sont les exigences sur les problèmes spécifiques à résoudre, plutôt
que des moyens spécifiques pour les résoudre, moins il y aura besoin de les modifier.

Traquez hypothèses erronées . Souvent, les exigences supposent que le client ou l'utilisateur
doit ou veut quelque chose qu'il n'a pas vraiment besoin ou envie. Les listes de besoins possibles
peut commencer dans un courriel ou informelles listes, et tout le monde peut prendre quelqu'un d'autre a passé au crible
et intensément leur revue. Si vous êtes le PM, ne faites pas cette hypothèse. Demander religieusement
 la clarification des questions telles que «Pourquoi avons-nous besoin de cela?", "Quel problème cela va résoudre?", ou
"Dont l'exigence est-ce?" pour pousser les hypothèses dans la lumière. Rappelez-vous qu'il est
toujours possible que quelqu'un innocemment mal compris quelque chose ou transmis erronée
informations sans le savoir.

Traquez les informations manquantes . Les erreurs les plus flagrantes dans les exigences impliquent des erreurs de
omission. Cela peut être partielle ou complète. Partielle signifie qu'un aspect d'une exigence est
manquantes (par exemple, le format de champ de date est pas spécifié, même si un champ de date est), ou qu'un ensemble
exigence a été négligé (le site Web doit être en grec et en charge Netscape
2.0). L'information manquante peut signifier deux choses totalement différentes: d'abord, le client ne se soucie pas
sur cet aspect du problème; ou la deuxième, le client ne soit soins, mais n'a pas pensé
cet aspect ou oublié de mettre le bas. Comme hypothèses erronées, il est le travail de la PM au drapeau
bits d'information manquante et confirment que ce soit le résultat de la première ou de la deuxième question.

Définir les priorités relatives à chaque exigence . Autant que nous aimerions obtenir tout sur
notre listes de courses, il est essentiel que les exigences impliquent au moins l'importance de chaque exigence
est, par rapport aux autres. En le faisant de façon relative, il est beaucoup plus facile pour les négociations à prendre
placer entre ceux qui ont l'autorité des exigences et celles de l'autorité de l'ingénierie (pour
plus sur la priorité, voir le chapitre 12 ).

Affiner ou éliminer langue involontairement ambiguë . Des mots tels que rapide , grande , petite ,
belle , jolie , et utilisable exigent des mesures relatives à être compris. Il est très bien pour eux d'être laissés
ambiguë, à condition que tout le monde impliqué dans l'exigence (client, patron, programmeur,
etc.) est à l'aise avec la négociation des réponses plus tard. Sinon, il est dans l'intérêt de
tous les participants à rédiger leurs exigences ambiguës ne sont destinés. Limite
cas ("Notre page d'accueil doivent être au moins aussi rapide à charger dans FireFox comme www.addison-
wesley.com ; de préférence, il devrait être aussi rapide que www.oreilly.com ") sont souvent le moyen le plus simple de
résoudre les ambiguïtés. Comme dans cet exemple, les exigences absolues (doivent avoir) et désirée
exigences (Nice, mais peut vivre sans) peuvent être indiqués facilement.

En utilisant l'un des énoncés de problèmes de chapitres 3 et 4 , voici une façon d'écrire une qualité
exigence:

Il ya certainement de la place pour plus de détails, mais de nombreux pièges d'exigences ont été évités en seulement

Page 90

quelques phrases. Notez que l'exigence est spécifique concernant l'intention, mais il ne précise pas
refonte de la page elle-même. Le plus en détail l'exigence va, plus il ya des risques pour
l'obligation de (inutilement) limitant la conception. Cela peut ou peut ne pas être souhaitable,
en fonction de ce qui a l'autorité et de la compétence.

5.1.2. l'exploration de conception

Maintenant que nous sommes d'accord (non pas que vous avez un choix) sur l'importance des besoins, nous pouvons discuter
la façon d'explorer des idées fondées sur eux.

Une fois que les exigences sont en place, les concepteurs peuvent explorer le territoire encadrée par les exigences.
Il ya un grand espace, appelé l'espace de problème, des façons possibles de résoudre un problème donné.
En fonction des exigences, cet espace peut être très grand; par exemple, il ya un infini
nombre de façons de concevoir une maison, un repas, un système de comptabilité, un site web, ou quoi que ce soit que
vous êtes payé pour faire. Donc, jusqu'à ce que vous avez un certain sens de ce que les possibilités sont (parce que vous avez
exploré ce territoire particulier avant), il est imprudent de se engager à quoi que ce soit découvert dès le début. La
premières idées que vous trouvez sont peu susceptibles d'être très bon: vous êtes encore à apprendre à votre façon de contourner le problème
l'espace et développer un sens pour les possibilités.

Figure 5-2 illustre l'espace de problème comme provenant d'exigences. En tant que concepteur commence
explorer des idées pour satisfaire les exigences, l'espace de problème commence à se développer. Le problème
l'espace se développe parce que chaque question au début ou croquis expose plus de décisions et d'opportunités que
pourrait être vu avant. Par exemple, les exigences pourraient stipuler "Le site Web doit fournir à temps plein
recherche en texte de toutes les pages, "mais il ne sera probablement pas dire quel moteur de recherche devrait être utilisé, comment il
sera configuré, ou comment son interface utilisateur sera intégré dans le reste du site Web. Au lieu,
quelqu'un doit explorer ce que les différentes possibilités sont, et il y aura beaucoup. (Cependant, le
espace de problème finalement se rétrécit. Nous en parlerons dans le prochain chapitre.)

Figure 5-2. idées de conception développent à partir des définitions de problèmes.

Selon la nature de ces exigences, il peut y avoir différents types de limites sur la
 espace de problème. Si il ya seulement une semaine de temps de chercher des solutions de rechange, et la conception finale doit
ne coûte que 10 $ à construire, l'espace de problème est très limitée. Un concepteur sera limitée à une étroite
un ensemble de solutions de rechange. En fait, il est tout à fait possible de créer des conditions qui sont impossibles à satisfaire
(Par exemple, faire une machine à mouvement perpétuel ou de résoudre des problèmes NP complets en temps polynomiale). Temps,
budgétaires, de l'expertise et de conception spécifique critères ont tous un impact de la forme ou la taille de l'espace de problème. Ce
est en partie pourquoi la définition des besoins a un tel impact sur le processus de conception.

Cela explique aussi pourquoi il doit y avoir une boucle de rétroaction entre la conception et les exigences. Si certains
exigences se révéler impossible à satisfaire, compte tenu des contraintes d'un espace de problème, il
doit être un moyen de les régler. Alternativement, si un concepteur trouve une idée fantastique qui satisfait aux
les objectifs du projet, mais nécessite un réglage exigence, il est dans l'intérêt de la
client / client / entreprise à envisager d'apporter ce changement.

Pas étonnant que le travail innovant se produit souvent quand une personne a deux exigences et
responsable de la conception (c.-à quelqu'un dans une start-up, un laboratoire R & D, ou un groupe qui lui a donné
beaucoup de puissance). Il peut régler les modifications de conception et de toutes les exigences de sa propre.

Page 91

5.1.3. Peur de l'écart et de l'idée de progrès

Peut-être beaucoup de gens sauter sur le processus de conception, car ils ont peur de l'exploration, en particulier
quand les autres regardent les faire. Lorsque nous explorons notre propre travail (par exemple, en essayant d'optimiser une
algorithme ou de réviser un document), il n'y a personne pour assister au processus. Nous sommes libres d'essayer
idées embarrassantes ou étranges parce que le seul jugement nous sommes confrontés est la nôtre. Mais avec le design comme un
l'activité prévue pour une équipe, tous ceux qui font la conception aura ses explorations visible à beaucoup d'autres
gens. Tous les croquis ou des prototypes qu'elle fait devront être montré à d'autres personnes et discuté ouvertement.
Si les gens ne font pas confiance aux autres de leur donner des critiques constructives, il est pas surprenant que ce processus
les intimide. (2)

Et contrairement à la correction de bugs ou de produire des documents, des travaux de conception la plupart des gens ne savent pas comment
mesurer les progrès accomplis. Au lieu de regarder un certain nombre grossir ou rétrécir, lors de la conception d'un gestionnaire
doivent compter sur sa connaissance du processus de conception (qui peut être limitée) ou son jugement subjectif
des progrès créative (dont il ne peut pas avoir ou un trust). Cette situation est aggravée par la crainte que trop
beaucoup structure restreindre gens créatifs de faire leur travail créatif, mais pas assez de structure
pourrait envoyer le droit de projet pour une falaise. (Comme un bouchon final pour le chapitre 6 , je promets que je vais vous expliquer comment
relever ce défi dans le prochain chapitre.)

Dans l'ensemble, je pense que workwhether créatrice liée à la construction de ponts, la conception vaisseau spatial, ou
sitessuffers ingénierie web à partir de nombreux stéréotypes. Les gestionnaires et les dirigeants ont besoin d'être le premier
les gens à obtenir passé ces étiquettes. Spécifique à trouver des idées, deux des pires stéréotypes et
perceptions erronées sont représentés par les phrases suivantes mauvais: "il n'y a pas de mauvaises idées" et "pensent
hors de la boîte. "En examinant ces phrases et les idées erronées derrière eux, je vais donner quelques
façons simples de réfléchir à la créativité et donnent des conseils sur la façon de trouver de bonnes idées.
Page 92

5.2. Il ya de mauvaises idées

Je ne sais pas d'où l'expression «il n'y a pas de mauvaises idées" est venu, mais je suis certain que ce qui ne va pas. Je l'ai
vu l'expression utilisée dans les deux publicités télévisées et dans les réunions de brainstorming (et tout à fait
éventuellement dans des publicités télévisées sur les réunions de remue-méninges). Cette petite phrase est généralement mignon
utilisé dans une tentative pour aider à prévenir les gens de filtrer les idées trop tôt dans la processa créative
noble objectif, pour être sûr. Mais lorsqu'il est appliqué à presque toute autre situation impliquant la résolution de problèmes ou
la pensée créative, la phrase "il n'y a pas de mauvaises idées" ne pouvaient pas être plus frustrant faux. J'ai
des preuves irréfutables qu'il existe un nombre infini de terrible, horrible, inutile, comiquement
idées stupides, et embarrassante mauvais. Si vous prêtez attention au monde autour de vous, il est assez clair
que les gens sont à venir avec de nouvelles tout le temps.

Même avec un ensemble haut de gamme d'exigences, la plupart des conceptions possibles qui existent ou qui pourraient être
créé ne va pas résoudre les problèmes ou de satisfaire les objectifs (voir Figure 5-3 ). En fait, l'espace de la bonne
des solutions pour un problème est beaucoup plus petit que l'espace de nonsolutions. Logique de base le confirme: si
Je vous demande d'escalader le mont Everest, il ya probablement une poignée de différentes routes qui mènent en toute sécurité
le haut. Mais si je vous demande de ne pas escalader le mont Everest, vous avez un nombre infini de façons de réussir
(Par exemple, la cueillette de votre nez, la lecture de Dickens, de l'escalade d'autres montagnes, escalade autres montagnes tout
la cueillette de votre nez et de la lecture de Dickens, etc.). Il ya toujours plus de façons de ne pas faire quelque chose que
il ya de le faire (un fait sûr de générer beaucoup de joie parmi les cyniques et les fainéants partout).

Figure 5-3. La plupart des conceptions possibles ne sera pas conduire au succès (et la
ceux qui ne sont pas tous tassent, que ce schéma pourrait impliquer).

Cependant, le problème est qu'il est difficile de savoir dès le début que les idées vont conduire à de véritables solutions.
Contrairement à l'ascension du mont Everest, la plupart des projets couvrent un territoire qui ne sont pas bien tracée. Tu pourrais
être à l'aide de pointe (lire comme peu fiables) technologies, en essayant de résoudre une nouvelle ou complexe ensemble de
problèmes, ou de travailler avec des gens qui ne disposent pas de l'expertise nécessaire. Il y a 1000 raisons
pourquoi votre projet actuel peut être différent de projets réalisés dans le passé, et que des moyens de différence
cette nouvelle pensée (concevoir) est nécessaire pour réussir.

5.2.1. Bon ou mauvais par rapport à quoi?

Bien sûr, cela devient encore plus difficile, car il est pas toujours facile de savoir si l'idée en face
vous est bon ou mauvais. Les idées sont impossibles à évaluer dans l'abstrait. Ils sont bons ou mauvais que dans
comment ils résoudre un problème particulier ou obtenir un effet désiré (par exemple, faire rire quelqu'un,
rendre les choses explosent, etc.). Comme je l'ai dit précédemment, si le problème est complexe, il est rare que vous trouverez

Page 93

une solution complète, ce qui signifie qu'une bonne solution est bonne que par rapport à ses alternatives. Si vous
ont une seule idée sur la table, il n'y a pas de base de comparaison et aucun moyen de bien l'évaluer.
Donc, si jamais vous vous trouvez sans alternatives pour évaluer les uns contre les autres, ou un problème clair
à résoudre, il est très difficile de juger de la valeur d'une idée. (3)

Une autre façon de penser à ce sujet est que, bien que la découverte de E = MC2 était certainement un beau morceau de
travaux par M. Einstein, il est pas d'une grande utilité à un ami du mal à équilibrer son chéquier, ou
quelqu'un qui est actuellement perdu dans le désert du Sahara (4) (pour ne pas mentionner quelqu'un perdu dans le désert
et en essayant d'équilibrer son chéquier). Est E = mc2 une bonne idée? Peut-être qu'elle est, si vous élargissez votre
exigences et espace de problème à inclure l'idée générale d'améliorer votre connaissance de la
 univers. Peut-être qu'il est pas si la seule chose que vous vous souciez de votre ami est dans le Sahara. Idées regardent
bon ou mauvais que contre une sorte de fond, et peu importe comment intelligent ou malin une idée
semble dans l'abstrait, quand il vient à des projets qui doivent réellement construire quelque chose pour résoudre certains
genre de problème, l'absence de distinction abstraite de la pragmatique conduit toujours à des difficultés.

Il est commun pour les gens intelligents à égarer des vrais problèmes à la main en raison de la
qualités abstraites de leurs idées. Les idées peuvent être élégant, intelligent, ou créatif dans la façon dont ils se rapportent à d'autres
idées que nous sommes familiers avec, même quand ils ne résolvent pas les problèmes du monde réel. Parfois, une idée
peut rendre quelqu'un se sent bien car il valide une allégation qu'il a fait, ou travaille à son politique
avantage. Par exemple, un programmeur pourrait plaider en faveur idée A au lieu de B idée parce que A est plus
elegantgiven le modèle d'objet, il est bien designedeven idée A est moins satisfaisante compte tenu de la
les exigences du client. Il est possible ses besoins personnels sont en contradiction avec le projet
exigences, mais il n'a pas remarqué la différence. Donc, assurez-vous toujours de démêler ce votre vrai
motivations sont pour la poursuite ou la défense, une idée.

Page 94

5.3. Penser dans et hors de boîtes est OK

Le deuxième plus notoire et trompeuse phrase concernant les idées, «penser en dehors de la boîte», a
ses origines dans un type de casse-tête casse-tête classique. Le casse-tête, montré dans la figure 5-4 , demande le puzzle
victime, je veux dire des participants, pour relier les neuf points en utilisant seulement quatre lineswithout droite soulevant le
stylo le papier. Il se trouve que cela est impossible, sauf si la victime utilise l'espace au-delà du
limites des points et pense (roulement de tambour s'il vous plaît) à l'extérieur de la boîte. Le point est censé être
qu'en supposant à tort que les contraintes et les limites font partie d'un problème, nous limitons notre
de penser et de nous empêcher de trouver des solutions. Il est un charmant, presque sucré, le point, et je vais
vous donner un moment à savourer avant que je déchire en lambeaux.

Puzzles et casse-tête de côté, ça ne l'élimination des boîtes qui est le plus difficultit est de savoir qui
boîtes à utiliser et quand les utiliser. Les contraintes sont toujours présents: nous avons besoin d'air pour respirer et
de nourriture pour vivre. Les lois de la physique lier des objets ensemble. Parfois, les contraintes sont utiles dans la résolution
problèmes; Par exemple, dites ce que vous allez sur la gravité, mais je suis reconnaissant que je peux supposer quand je
mettre un rocher pointu sur le sol, il ne va pas à voler et me frapper au visage.

Figure 5-4. Le «penser en dehors de la boîte" puzzle, avec une solution.

 Ainsi, l'engin réel de la résolution de problèmes et la pensée créatrice est de savoir quelles contraintes d'utiliser ou
ignorer et quand le faire. Je l'ai vu des gens super-créatifs arrivent à ma porte avec des idées fantastiques
depuis trois semaines la dernière date possible, je les aurais utilisé. Je suis aussi allé au remue-méninges
réunions pour Tiny, projectsalready sous-financé derrière les gens de schedulewhere offert leur «plus grand,
la plus radicale, out-of-the-box, des idées "qui ne Furieux de toute l'équipe, car pas un seul
des bonnes idées venu n'importe où près le plan final du projet.

Quelqu'un doit diriger une équipe en décidant quelles contraintes / conditions peuvent être ignorés, plié,
tordus, ou manipulés, et qui doivent être suivies pour la ligne et la lettre. Être créatif souvent
implique de travailler au sein d'une contrainte, avec des ressources ou de temps, et de trouver la ruse ou intelligent
les moyens de faire mieux que l'on croyait possible (voir le film Apollo 13 ). Big, idées étonnantes radicales sont
rarement nécessaires pour réussir. Le plus souvent, il est une poignée de, solide, une bonne base correctlythat ideasapplied
sont nécessaires.

Mon point fondamental est le suivant: faire ce que vous voulez avec la boîte. Pensez dans la zone, hors de la boîte,
sur la boîte, sous la boîte, déchirer et faire un feu hors de la boîte, que ce soit, aussi longtemps que vous
gérer pour résoudre les problèmes identifiés comme les objectifs du projet. Faire les cases pertinente dans
faveur de la compréhension des problèmes, cultiver meilleure énergie créative des gens, et visant tous les
la puissance de l'équipe dans la même direction. Comme l'a dit Thomas Edison, «L'enfer, il n'y a pas de règles ici. Nous sommes
essayer d'accomplir quelque chose. "Assurez-vous que toutes les règles que vous créez servent le processus et les personnes en
, pas l'inverse.

Page 95

Il est également essentiel d'examiner les questions suivantes: comment obtenez-vous les gens à réfléchir sur le même
problèmes? Comment apportez-vous de bonnes idées vers vous? Vous voulez deviner où vous pourriez commencer? Est
ce paragraphe vous ennuyer encore? Eh bien, surprise. Les choses commencent souvent par poser les bonnes questions.
(Vraiment? Oui. Etes-vous sûr? Positive. Pouvons-nous passer à autre chose alors? Bien sûr.)
Page 96

5.4. Les bonnes questions attirent de bonnes idées

«Les ordinateurs sont inutiles. Ils ne peuvent vous donner des réponses."

Pablo Picasso

Pour esquiver un tas de besoins des collèges indésirables, je étudié la théorie de la logique et de la philosophie dans le cadre de
mon diplôme de premier cycle. Outre les nombreuses choses que je appris et oublié, une chose que je appris et
souvenu était de savoir comment poser les bonnes questions. Je devais bons instincts pour la logique, mais comme la seule
de premier cycle en cours de théorie de la logique de niveau universitaire, je était habituellement (OK, toujours) derrière le reste du
le groupe. Je me suis vite appris que si je ne demandais pas soigneusement formulées questions à des pairs ou des professeurs, je ferais
recevoir des volumes d'informations complexes qui ne m'a pas aidé du tout. En fait, je l'ai trouvé que beaucoup
ingénieurs, médecins et autres experts intelligents ont tendance à être très heureux de partager ce qu'ils savent,
indépendamment du fait qu'il est ce que je demande à propos. Les gens se perdent dans leurs propres connaissances.

Demanda prudemment les questions sont un moyen de mener des conversations difficiles dans des directions utiles. Comme
par exemple, je eu cette expérience récurrents avec des professeurs logiques qui m'a obligé à prêter attention à
comment je posais des questions. Il serait commencer par me demander quelque chose comme, "Pouvez-vous expliquer ce une partie
du théorème d'incomplétude de Gödel? "Le professeur répondait:« Certainement. Vous voyez, toutes les preuves
les systèmes peuvent être réduites à un ensemble essentiel des caractéristiques définies par le noyau primitif récursif
fonctions. "Je dirais," Euh, OK. C'est bien. Mais pouvez-vous expliquer cette seule ligne ici? "Et je ferais remarquer à ce
petite ligne dans la preuve, encerclé à l'encre rouge épais et avec un point d'interrogation géant à côté de lui. Le prof
hochait la tête et dire: «Oh, ce que, bien sûr. <Pause>. Eh bien, l'histoire de la logique des systèmes de preuve
découle de la noble tentative d'exprimer les aspects de l'existence à travers un système vérifiable .... "Je
disons, "Oh, mon dieu. Non, cela ici <pointant à nouveau>. Qu'est-ce que cela signifie? Comment est-il lié à la ligne
ci-dessus? »Il avait répondre avec," Certainement, certainement. Vous voyez, théorie de la preuve se rapporte à la théorie de la logique
parce que du lemme d'intangibilité entre les séries de valeur nonordinal mais infinie .... "Enfin, je donnerais
et la tête pour le pub le plus proche.

Je appris que sans les bonnes questions, je ne reçois jamais de bonnes réponses. Parfois, il était difficile d'obtenir
bonnes réponses même quand poser les bonnes questions. Mais je ne parviens à passer ces classes, et je tard
constaté que chez Microsoft, et dans le secteur de la technologie, ces compétences d'interrogation-demandant étaient d'une grande valeur. La
des problèmes de communication, je rencontrés dans la salle de classe étaient semblables à des problèmes Je visage avec les ingénieurs,
avocats, cadres, spécialistes du marketing, les concepteurs et les clients. Souvent, les gens insistent pour vous dire des choses
qui n'a rien à voir avec ce que vous devez savoir. Mais mon expérience de classe logique côté, bonne
questions, demandé fermement, aident conversations déplacer dans des directions utiles.

Il ya trois sortes de questions à prendre en compte spécifique à résolution créative de problèmes: en se concentrant
des questions (bonnes), des questions créatives (aussi bien), et des questions rhétoriques (le mal).

5.4.1. Mise au point des questions

Une bonne question concentrant attire l'attention d'une personne ou d'un groupe à l'absence de quelque chose
importante, utile, ou même au centre du travail se fait. Ces types de questions restreindre la
champ d'application de la discussion d'une certaine façon et d'amplifier l'attention accordée à certains aspects d'une situation. Il est
l'équivalent de "Ne vous embêtez pas avec cela pour le moment, regardez ici." En supposant que le bénéficiaire de la
question prête attention, une question mûrement réfléchie et dirigée peut être plus utile que tout
nombre de réponses à des questions de moindre importance. "Y at-il un moyen d'utiliser la base de code existante pour construire une
système qui répond à cette exigence de la performance? », ou« Comment les utilisateurs de savoir quand aller à cette
dépister? ", ou" Est-il possible de mélanger le beurre d'arachide avec du chocolat? "En quelques mots, les bonnes questions
identifier un élément essentiel du problème (ou solution) sans passer par l'ensemble de la secondaire et
 Informationsetanalyses non essentiels debonne
créer un espaceou
pour
un une
bonréponse à naître. Les gens intelligents saventà pleine
instinctivement quand ils entendent une question, problème, et pourront profiter de l'attaquer
la vitesse une fois qu'il a été reconnu. Les bonnes questions agissent comme des aimants, attirant intelligente et créative
les gens à leur égard, et de mettre l'ensemble de leurs idées potentiellement bonnes pour la balade.

Page 97

Les gestionnaires de projets et de grands penseurs créatifs sont maîtres de questions. Ils sentent quand les choses sont
descendre la piste, de reconnaître les éléments essentiels manquants dans une discussion ou un plan, et injecter
leur retour avec une question bien choisie et formulée. Sur des équipes solides, même si le projet
gestionnaire demande la mauvaise question, le fait qu'il a interrompre la discussion au bon moment sera
provoquer quelqu'un d'autre pour répondre avec la bonne. "Eh bien, Scott, en fait, nous rejeté cette
exigence. Ainsi, une meilleure question est 'nous sommes sûr que cette nouvelle conception est conforme la liste mise à jour
exigences? »et après une brève discussion, toute l'équipe est maintenant ré-alimentée et recentré
autour d'une vue améliorée du travail à faire. Les bonnes questions sont des catalyseurs: ils se recombinent le
la connaissance et de l'énergie d'un discussionenhancing, le raffinage, et la cristallisation tout au casting qui onceand
l'énergie de nouveau vers un relief plus fructueux.

Je l'ai trouvé que, après la construction de la confiance avec une équipe, la question la plus puissante dans l'ensemble de projet
la gestion, la pensée créative et la résolution de problèmes est:

Quels sont les problèmes que vous essayez de résoudre?

Pourvu que vous avez suffisamment de crédibilité que cette question ne soit pas considéré comme gênant gestionnaire-parler, il peut
être utilisé dans presque toute discussion, à tout moment, tôt ou tard dans un projet, pour aider à rendre certains de deux
les choses. Tout d'abord, que l'équipe peut identifier ce qu'ils sont vraiment essayer de comprendre; et, deuxièmement,
que tout le monde dans la salle au moment a la même réponse (il n'y a rien de pire que de cinq à puce
personnes qui travaillent ensemble, mais sans le savoir, à essayer de résoudre des problèmes différents). Cela fonctionne par magie
bien pour quelque chose de haut niveau stratégie discussions aux décisions de la syntaxe du code niveau de détail faible,
test cas minuties, ou les problèmes de production de conception. Il a une telle phrase puissant et utile que je l'ai fait
en une affiche et accroché au-dessus de mon bureau. Je l'ai trouvé que chaque fois que je me sens comme la pensée de conception
et la génération d'idées sont confus, ou les gens disent des choses contradictoires, je ne suis pas aloneothers sont
tout aussi confus. Ainsi, en jetant la question principale vers le bas, je fais en sorte tout le monde obtient réinitialisé et
rechargée autour de quoi que ce soit que nous sommes censés faire.

5.4.2. Des questions Creative

Un tout autre type de question, une question de créativité, fonctionne dans la direction opposée à partir
concentrant questions. Des questions Creative pointer dans des directions qui ne sont pas considérés, mais devraient être
exploré. "Combien de façons différentes que nous pouvons présenter cette information à des clients sur la maison
la page? »ou« Que peut la base de données du moteur de recherche est-il utilisé? "discussions de conception prospèrent habituellement
sur des échanges de ce genre de questions entre coéquipiers, avec beaucoup de réflexion, croquis, et
explorer des réponses entre les deux. Les bonnes questions créatives augmentent généralement le nombre de
alternatives et élargir le champ de la discussion (mais pas nécessairement la portée de la
problème). Comme nous le verrons plus loin dans ce chapitre, la création d'un vaste bassin d'idées est souvent le seul moyen de
arriver à de bonnes idées. Poser les bonnes questions créatives met en place une personne créative pour aller dans la bonne
direction, ou, comme cela est souvent le cas, dans une mauvaise direction qui aide les gens finissent par comprendre ce que
celui de droite est.

5.4.3. Les questions rhétoriques

Mais attention, avec le jumeau maléfique de la question créative: la question rhétorique. Les questions rhétoriques sont
le genre de sincérité, demanda sans aucune intention d'une réponse littérale. Comme un parent gronder un enfant
("Que pensiez-vous quand vous avez mangé une boîte entière de Fruit Loops?» Ou «Comment pourriez-vous Sally
couvrent l'écran de télévision avec le beurre d'arachide? "), questions rhétoriques ont tendance à finir discussions. Ils
impliquerait la culpabilité et le jugement négatif. Ils supposent que le demandeur de la question en sait plus que le
destinataire, et ils placent injustement le bénéficiaire dans une position compromettante du pouvoir. Les gens qui ont
autorité, mais ne savent pas comment bien l'utiliser, posent souvent des questions rhétoriques (par exemple, un patron frustré ou
enseignant). En posant des questions de cette manière, ils obtiennent rarement la réponse qu'ils étaient après. Si elle est utilisée
attentivement, questions rhétoriques peuvent être drôles ou peuvent secouer les gens qui ont besoin d'être secoué ("Come
les gars, est-ce vraiment le meilleur que vous pouvez faire? "). Mais ils doivent être utilisés avec parcimonie, même pour cette
objectif.

Les deux focalisation et des questions créatives aider à attirer les matières premières nécessaires à la bonne pensée. Ce
prend une main attentive de savoir quand utiliser quel genre de question et quand à contribuer simplement
les discussions et les idées de bénévolat. Bien sûr, si l'équipe est de produire du bon travail et naturellement séjours

Page 98

concentré tout en étant créatif, il pourrait ne pas être nécessaire de chercher consciemment questions. Après tout,
il est de la qualité des idées qui est important à la fin, pas les questions ou les processus spécifiques qui
conduit à eux.
Page 99

5.5. Les mauvaises idées mènent aux bonnes idées

Je l'ai vu une conception quelque chose de créateur quand je étais un junior à l'université. Je ne savais pas vraiment ce que
les concepteurs ont fait, et je pensais que ce quepour le plus partthey fait les choses semblent jolies: jeans à la mode,
sacs à main de marque, etc. Quoi qu'il en soit, ce jeune homme a été la conception d'un nouveau type de stéréo portable. Il
assis à son bureau dans le studio de premier cycle du département de conception, qui était un grand espace ouvert avec
beaucoup de tables, des croquis, des prototypes et des plans dans tous les sens. (5) Il a été esquissant
des idées différentes, chacun une conception alternative pour la stéréo. Je lui ai demandé ce qu'il faisait, ou
plus précisément, comment ce qu'il faisait bon dans "la conception," quoi que cela signifiait pour lui.

Il réfléchit un instant, sourit, et me dit: «Je ne sais pas vraiment ce que les bonnes idées regardent
comme jusqu'à ce que je l'ai vu les mauvais. "Je hocha poliment la tête, mais lui écartée complètement. Je attribuions mon
incapacité à comprendre ce qu'il disait à ma perception de lui comme d'un impair, de type créatif personne,
et non pas à ma propre ignorance.

Il était seulement après que je l'avais passé quelques années la conception de logiciels que je comprenais ce qu'il était
disant. Je l'avais appris par l'expérience que les bonnes idées ont souvent besoin les restes de beaucoup de mauvaises idées.
Sans faire des erreurs et des oublis dans de nombreuses tentatives différentes, il est souvent impossible de trouver le
 chemin d'idées qui mène au succès (voir chapitre 1 ). Peut-être qu'il est seulement quand une idée ne fonctionne pas et
nous sommes confrontés à l'échec que nous sommes obligés de revoir nos hypothèses. Et alors seulement, lorsque nous
recul avec plus d'informations, nous pouvons voir le chemin qui était pas visible pour nous avant.

Donc, les meilleures idées et conceptions nécessitent élan. Ils ne sont pas arrivés à la suite d'un sort magique ou
force de volonté ("être brillant, maintenant! Je veux dire maintenant. Que diriez-vous maintenant ...!"). Chaque dessin, croquis, ou
prototype, peu importe le ridicule ou pathétique, enseigne le concepteur (ou ingénieur ou scientifique) un
petit quelque chose de plus sur le problème, et augmente les chances que la prochaine tentative sera mieux
que la dernière. Chaque grand esprit qui a poursuivi la résolution de problèmes complexes dans le monde a
fait entouré par de grandes piles de papier froissé. Certains ont menti à ce sujet, d'autres ont
embrassé. Si rien d'autre, cette notion que les mauvaises idées mènent à bons nous libère de commencer à concevoir
cependant, nous choisissons. Nous devrions nous attendre pleinement à se salir les mains et de faire beaucoup d'erreurs au début
parce que le plus tôt nous les faisons, le plus tôt nous allons passer à de meilleures idées.

5.5.1. Bons dessins proviennent de nombreuses bonnes idées

Résolution d'un problème unique est pas le but d'un projet; les choses sont beaucoup plus difficiles que cela. La plupart des logiciels
projets impliquent la résolution de dizaines de problèmes, de préférence d'une manière que les clients peuvent utiliser facilement
et que peut être construit par l'équipe d'ingénierie dans un laps de temps limité. Le nombre de
points d'intégration entre les pièces et les composants impliqués dans la conception et l'ingénierie d'un
automobile, un site web ou un logiciel exige que les concepteurs passent par de nombreux
révisions avec la pleine confiance que cela peut prendre des dizaines de tentatives et des ajustements pour obtenir tout
droit. Révision et raffinement sont le nom du jeu, et une partie du processus.

Toutes les activités créatives de l'ingénierie aux arts partagent cette vérité fondamentale, que certains sont bien connus
penseurs et les créateurs ont déclaré:

"Les deux outils les plus importants d'un architecte a sont la gomme dans la salle de dessin
et le marteau sur le site de construction ".

Frank Lloyd Wright

"Plus grand outil de Le physicien est sa poubelle."

Albert Einstein

"Il ya des jours où je fais cinq d'entre eux, mais il faut compter celle de 20 dessins,
un seul sera couronnée de succès. "

Page 100

Vincent Van Gogh

"Il n'y a pas une telle chose comme un échec. Seulement abandonner trop tôt."

Jonas Salk

«Il ya une façon de le faire betterfind il."

Thomas Edison

"Fail. Échouer à nouveau. Fail Better."

Samuel Beckett

«Si vous voulez réussir, doubler votre taux d'échec."

Tom Watson, IBM

«Je vous écris 99 pages de merde pour chaque page de chef-d'œuvre."

Ernest Hemingway

Bien que l'objectif ne serait pas de faire chaque projet de logiciel dans un chef-d'œuvre, tout projet
exigeant la conception et la résolution de problèmes doit être donné suffisamment de temps pour explorer une gamme de solution de rechange
idées. Ils ont également besoin de temps pour intégrer les concepts et les composants. Le cynique et la
pas cher pourrait choisir de fournir moins de ressources pour ces activités, mais le coût sera toujours payée
dans la plus faible probabilité de résoudre effectivement les problèmes des clients.

Mais même si vous achetez tout cela, et vous travaillez dans une organisation qui fournit le temps pour la conception, les choses
sont encore difficiles. Recherche et la création des idées utiles exigent des compétences différentes que la plupart d'entre nous apprennent à
l'école ou sont généralement enseigné dans le lieu de travail. En fait, je me suis, malgré des années d'étude et de travail dans
conception, a dû retourner à l'école pour obtenir une nouvelle leçon sur l'endroit où viennent les idées.
Page 101

5.6. Perspective et l'improvisation

Sur un défi de Ayca Yuksel et Vanessa Longacre, deux anciens collègues de travail chez Microsoft, les trois
nous inscrits dans une classe de comédie d'improvisation dans un collège communautaire. Après que le premier jour, je
appris que ma terreur à la proposition d'être drôle sur commande était dénuée de tout fondement. JE
ont découvert que la plupart des gens, si ils apprennent à prêter attention (qui la classe nous ont appris à faire),
peuvent trouver de l'humour dans de nombreuses situations ordinaires. Il est tout à apprendre à voir les choses qui vont souvent
connexions inaperçus, et faisant entre eux.

Lorsque je suis rentré au travail et le monde de projets, dessins et modèles, je me rendis compte que la même chose était
vrai au sujet de la résolution de problèmes. Bonnes solutionneurs de problèmes remarquent choses que les autres ne le font pas. Ils voient plus
détail, faire plusieurs associations, et avoir plus de profondeur de la perception de tirer à trouver des connexions
entre les choses. Dans une interview à Wired Magazine, Steve Jobs avait ce grand morceau de créativité
commentaire:

Pour concevoir quelque chose de vraiment bien vous avez pour l'obtenir. Vous devez grok vraiment ce qu'il est tout au sujet.
Il faut un engagement passionné pour bien comprendre somethingchew it up, et pas seulement
avaler rapidement il. La plupart des gens ne prennent pas le temps de le faire. La créativité est simple connexion
les choses. Lorsque vous demandez à une personne créative comment ils ont fait quelque chose, ils peuvent se sentir un peu coupable
parce qu'ils ne le font vraiment, ils ont juste vu quelque chose. Il semblait évident pour eux après
quelque temps. Cela est parce qu'ils ont pu se connecter expériences qu'ils ont eu et synthétiser nouvelle
les choses. Et la raison pour laquelle ils ont été en mesure de le faire était qu'ils ont eu plus d'expériences ou
avoir pensé plus sur leurs expériences que les autres ont. Malheureusement, cela est trop
une denrée rare. Beaucoup de gens dans notre industrie ont pas eu des expériences très diverses. Ils
ne pas avoir suffisamment de points pour se connecter, et ils se retrouvent avec des solutions très linéaires, sans un large
perspective sur le problème. La compréhension par le plus large, de l'expérience humaine, la
de meilleures conceptions que nous aurons. (6)

Le seul reproche que je fais de cette citation est qu'elle implique quelque chose de spécial au sujet des personnes créatives qui
ne peut pas être obtenu par des personnes "noncreative". Je ne crois pas que les gens sont nés dans l'un des deux exclusive
des tas de génies créatifs et abrutis sans imagination. Si la classe d'improvisation je prenais était une indication,
la plupart des gens peuvent apprendre à devenir plus attentif et développer leur sens de la sensibilisation à la
monde, eux-mêmes, et les connexions entre les choses, satisfaisant les critères emplois.

Tout le monde dans la classe (voir www.jetcityimprov.com ) inventé des façons d'être intéressant et drôle,
malgré la façon dont presque aucun des adultes studentsall, tous issus de différents milieux et professions
(Et quelques-uns d'autres pays) - eu de la comédie ou l'improvisation expérience avant. Je pense
Improv et d'autres bons exercices créatifs attirent sur notre capacité universelle de faire usage de ce que les autres
nous montrer, et nous aider à voir plus clairement et profondément en accordant plus d'attention. Je crois fermement qu'une
compétent, mais pas exceptionnel, développeur de logiciel pourrait améliorer plus en étudiant la
la construction de gratte-ciel, des ponts, ou même la composition musicale, que la lecture exclusivement au sein
son domaine.

Intensifier l'extérieur d'un domaine spécifique (même pour seulement quelques heures nécessaires pour lire un livre ou regarder un
film) et puis regarde en arrière est souvent la seule façon de vraiment comprendre pour ce qu'elle est. Maîtrise de
quelque chose doit être comme debout sur un pic dans une plage de montagne: il vous permet de prendre la fierté dans ce
vous avez accompli, mais il rend également vous vous rendez compte combien d'autres montagnes, il ya des
aussi bonnes vues.

Je trouve que la classe d'improvisation m'a aidé à sortir de mon travail et de mes relations et de grandir dans des égards, je
 ne pouvait pas tout l'intérieur de ces choses. Aider ce long ont été les quatre règles que nous avons utilisés au cours en classe
jeux pour nous aider à rester conscient et garder les idées qui coule. Je trouvais plus tard qu'il a transférées facilement
dans les discussions de la conception et de petits groupes meetingssituations de remue-méninges où l'objectif était de
chercher de nouvelles idées et de créer une grande liste de concepts et pensées pour être examiné plus tard.

Je reconnais que, à l'sceptique et sarcastique (comme l'auteur), des listes de règles à suivre peuvent sembler
comme le fascisme heureux (la tyrannie avec un sourire). Cependant, la plupart du temps, je l'ai essayé avec themeven difficile,

Page 102

calme, cynique, sarcastique teamsthey've pédante, trop intellectuel, et à faible sociale-énergie a aidé.
Ils systématiquement conduit à de meilleures discussions, même si ces discussions ont commencé avec l'équipe de rejeter
ces règles et à venir avec leur propre.

5.6.1. Règles d'improvisation pour la génération d'idées

Pour ce faire le jeu d'improvisation pour le brainstorming (avertissement: il est pas bon pour la pensée profonde de la conception),
vous avez besoin de quelques choses: un petit groupe de personnes (2-8), une chambre confortable, un beau morceau de dédié
temps, au moins une définition de problème pertinent pour le projet, et quelqu'un à un tableau blanc pour écrire
de courtes descriptions bas de chaque idée personnes suggèrent. Si les gens doivent le tableau blanc pour expliquer des idées,
c'est bon. Mais puisque l'objectif est le volume, détail ne devrait pas être le focus.

Pour commencer, quelqu'un agit en tant que facilitateur et reste par le tableau blanc. Il devrait y avoir un problème
déclaration qui définit ce que le groupe génère des idées pour. Cela peut provenir le problème
des déclarations ou des exigences, ou il peut être quelque chose que vous venez avec votre propre. Une fois la
problème est convenu, les gens commencent à offrir des idées, qui l'animateur écrit vers le bas.

Le jeu commence quand quelqu'un suggère une idée et une discussion en découle. Il ya quatre règles à
suivre pour que la discussion:

1. Oui, et ... . Lorsque quelqu'un d'autre propose une pensée, la réponse est seulement permis «Oui, et
<Insérer quelque chose ici>. "Votre première tentative doit être de continuer sa ligne de pensée.
Généralement, vous prenez son idée ou un point et le déplacer vers l'avant ou de rediriger il, comme «Nous pourrions utiliser
un champ de recherche ici ... »,« Oui, et il serait assez intelligent pour mettre l'utilisateur au bon endroit
quand on tape quelque chose dans. "Ou," Oui, et il pourrait faire usage du nouveau moteur de recherche, nous sommes
bâtiment et retourner des résultats plus rapides. "L'intention est de faire avancer les choses de façon positive et à
développer une habitude d'écouter les autres afin de les aider avec leurs idées, au lieu de simplement
attendre à-dire votre propre.

2. Pas de demi-Assing . Il est inacceptable d'offrir une idée de votre propre, suivie par "Désolé, je sais qu'il est
boiteux »ou« Je ne suis pas bon à être créatif. "Half-Assing signifie ne pas être engagé à ce que
vous dites. Ce que vous dites n'a pas à être brillant pour vous de se tenir derrière. Il est OK pour
votre idée soit mauvaise: ça pourrait déclencher quelqu'un d'autre à dire quelque chose de mieux. Si vous faites confiance
la personne à côté de vous pour dire "Oui, et ...", elle pourrait être en mesure de faire quelque chose d'intéressant avec
votre idée "moche" que ni elle ni vous aurait pensé autrement.

3. Aucune question de blocage . Questions posées idées, et les gens en leur demandant, sur la défensive. Si
vous dites: «Pourquoi diable voulez-vous faire?", vous êtes encadrant un nouveau contexte autour de ce que la
autre personne dit ce jugement qui est pas improvisationalit. Il suppose qu'il n'y a rien de bon
raison pour cela jusqu'à preuve du contraire, ce qui est la bonne atmosphère pour la pensée libre et gratuit
(Bien que ce soit la bonne atmosphère plus tard dans les plus profondes discussions de conception). Au lieu de cela, tester votre
propre intellect: comment pouvez-vous diriger leur idée initiale en quelque chose d'utile? Faites ce que
hypothèses ou sauts de la foi dont vous avez besoin afin de donner un sens de la déclaration de quelqu'un d'autre.
Rouler avec elle et de continuer. Bref, des questions de clarification pourrait être OK à l'occasion, mais ne pas
faire le focus. Il est préférable de passer à la prochaine idée de restreindre dans sur ceux des particuliers.
Si la génération d'idées brutes est le but, le volume des idées par heure est plus important que le
la qualité de chaque idée. Ne rien dire peut souvent être mieux pour l'objectif global de la génération d'idées
que de faire un point de la façon dont une idée est stupide.

4. Faire l'autre gars semblent bonnes . Personne ne devrait conserver le score ou de garder trace de qui a dit quoi.
Les récompenses doivent aller vers les gens qui aident les amplifier, expriment, ou de dessiner sur les meilleures idées des autres
dans le groupe. Parce que les chances sont que tout ce que obtient conçu sera construit par tous dans le
chambre, il n'y a pas de sens de donner des étoiles d'or ou de classer les idées en fonction de leur origine. Si
le processus de conception commence comme un processus communautaire saine, où les meilleures idées augmentent indépendamment
de leurs origines, le reste du projet sera probablement le même esprit.

Le résultat de ce genre d'exercice devrait être une liste d'idées brutes et fragmentaires que quelqu'un va trier
par la suite. Quand il le fait, il va choisir celles assez intéressant de poursuivre ou de discuter en
plus de détails. Parce que ces discussions de suivi sont moins à propos de la génération d'idées brutes, l'improvisation

Page 103

règles ne comptent pas comme muchalthough l'esprit d'entre eux devrait continuer.
 5.6.2. Plus approches pour générer des idées

Si vous n'êtes pas prêt pour les jeux d'improvisation, ou si vous voulez un moyen plus simple de
de générer des idées, voici quelques suggestions traditionnels:

Procurez-vous un livre sur la pensée créative . Il ya beaucoup de bons à choisir. Deux de mes
favoris sont Thinkertoys , par Michael Michalko, et six chapeaux de la réflexion , par Edward de Bono.
Beaucoup d'autres livres populaires sont très bien aussi, mais je ont obtenu le plus de kilométrage de celles-ci
deux.

Faites attention à quand vous vous sentez le plus créatif . Figure ce que font les environnements
plus facile pour vous d'être créatif. Es-tu seul? Êtes-vous avec des personnes (qui) les gens? Est la musique sur
ou désactiver? Quelle musique? Tout le monde est différent, et vous ne vous connecter avec votre propre créativité jusqu'à
vous passez un certain temps à trouver ce que vous inspirent les environnements. Il pourrait impliquer d'être dans un
café génial, méditant sur un banc de parc dans les bois, ou en regardant le soleil se coucher lentement
sur l'horizon derrière le pont de Brooklyn.

Reconnaître que la persistance contribue à la créativité . Les personnes qui apparaissent créative ne le font pas
nécessairement venir avec des idées plus facile que vous le faites. Mais ils peuvent passer plus de temps
l'exercice de ces parties de leur cerveau et de les garder souples. La créativité est une compétence comme tout
d'autre part, et bien que nous ne commençons pas tous avec les mêmes dons, tout le monde peut apprendre à mieux rien si
ils investissent suffisamment d'énergie en elle.

Achetez le jeu de cartes de remue-méninges, ThinkPak, créé par Michael Michalko . C'est un
jeu de cartes à jouer qui sont conçus pour aider les individus ou les groupes viennent avec de nouvelles idées pour
tout type de défi. Il ya d'autres ensembles comme celui-ci que vous pouvez trouver, mais je les ai eu plus
succès avec celui-ci que d'autres. (ThinkPak est disponible au www.amazon.com .)

Page 104

5.7. L'expérience client commence la conception

"Visionnaires technologiques peuvent ne reconnaîtra jamais la distinction entre ce qui est faisable
et ce qui est souhaitable .

Edward Mendelson

Si la meilleure architecture dans le monde est écrit avec les meilleurs modèles d'objets, les meilleurs algorithmes, et
base de code plus rapide encore plus fiable jamais, il peut encore être tout à fait inutile si les clients pour lesquels
que le travail a été fait ne peut pas comprendre comment faire ce qu'ils doivent faire avec elle. Ce serait une perte de
ces algorithmes et ces heures-homme d'effort d'ingénierie parce que personne ne sera jamais l'expérience de la
la qualité du travail accompli.

La seule assurance contre est de commencer l'effort de conception et d'ingénierie de la downfrom top
 ce que le client verra sur l'écran, vers le bas pour les composants de haut niveau, puis vers le bas à la
des éléments de travail. Dès concepts bruts ont été rédigées pour ce que l'utilisateur l'expérience, la
ingénieurs et technologues devraient répondre avec la façon dont ce qu'ils ont pensé à des crises
contre ces concepts. Les dessins peuvent être construits? Quels compromis pourrait être nécessaire? Quoi
contraintes doivent être pris en considération? Le travail se poursuit, avec des discussions des allers-retours
entre les couches de la conception, et différents experts de l'équipe, faire en sorte que les choses
progrès, l'intégrité de l'expérience de l'utilisateur est maintenue, sans violer ce qui est possible (et
probable) des ingénieurs. La pensée de conception sera déplace dans deux directions: de l'désiré
expérience client vers le bas à la technologie, et de la technologie pratique au client
l'expérience (voir Figure 5-5 ).

Figure 5-5. Le meilleur processus de conception intègre la conception centrée sur le client
avec des considérations pratiques pour la technologie disponible. Si l'on est
conçu dans l'isolement, l'autre sera toujours compromise.

Les séances de remue-méninges doivent expliquer comment et par où commencer le travail de conception. Beaucoup de début
idées générées dans brainstorming décrivent sans doute d'une certaine façon de concevoir le système pour résoudre un
problème. Chacun de ces idées comporte au moins une matière de representationin visuelles de la manière dont le logiciel
ou le site Web serait en fait se tourner vers quelqu'un qui essaie de itthat utiliser peut être esquissée et discutés
sans écrire une seule ligne de code. (Si le projet est un système embarqué ou un kernelsystems OS
qui ont aucune attention utilisateur interfacethen tangible devrait être accordée à ce que les conditions ne sont jamais
acceptable).

Venir avec ces représentations, croquis, dessins de jeunesse, ou dans certains cas des prototypes, est le
première étape pour comprendre l'idée. Si elle ne peut pas être établi et ne peut être esquissée, il ne peut certainement pas être
construite. UML et des diagrammes Visio ne sont pas la même chose que d'une esquisse. Les diagrammes sont des abstractions.
Ils ne montrent pas ce que l'utilisateur verra, et, par conséquent, ils peuvent se cacher toutes sortes de problèmes et

Page 105

détails qui doivent être pensés.

Voici l'un des problèmes de l'échantillon I qui figurent dans le chapitre 3 : "Il est difficile de trouver des objets couramment utilisés sur
. la page d'accueil "Supposons que, après une séance de remue-méninges, trois idées décents ont été trouvés:

1. Dynamiquement la priorité à la page basée sur ce que les gens utilisent.

2. Débarrassez-vous des personnes de substance ne jamais cliquer sur.

3. Organiser la page d'accueil en groupes qui font sens pour les clients.

Avant tout ingénieur pense à la façon de construire ces choses, quelqu'un doit prendre en compte les idées »
mérites du point de vue de l'expérience client. Il pourrait arriver que aussi merveilleux que ces idées
paru dans l'abstrait, personne dans le bâtiment peut venir avec un bon design (7) qui incorpore
eux d'une manière qui le rend plus facile pour les clients de faire le travail qu'ils doivent faire. Pour cette raison,
il est dans l'intérêt de l'équipe de commencer avec l'expérience client: il est la meilleure façon d'éliminer
travaux inutiles, de clarifier ce que la conception sera construit et pourquoi, et de réduire les chances d'avoir à faire
de grands changements plus tard. La gestion de ce processus ne soit pas facile, mais faire mal est mieux que de ne pas le faire à
tous.
Page 106

5.8. Une conception est une série de conversations

Avec quelques croquis d'interfaces d'utilisateurs potentiels, le travail de conception réelle peut commencer. Un informelle
walkthrough des croquis avec des ingénieurs, des testeurs, et les commerçants peuvent commencer les conversations réelles
qui conduisent au progrès. Un ingénieur peut donner une recommandation off-the-brassard à un concepteur de la
travailler implicite ou suggérer des modifications à la conception qui pourraient le rendre plus facile à construire. Beaucoup bonne
questions seront posées dans les deux directions. L'ingénieur peut également être en mesure de faire le concepteur
au courant des options qui sont techniquement possible, mais dont elle n'a pas connaissance ("Oh, avec le nouveau flux
condensateur que nous construisons, vous pouvez éliminer cet écran "). Le début de cette discussion peut commencer, le
plus vite la conversation devient forte, et plus les idées qui peuvent être soulevées, considérés, et
revu.

Il est important que tout le monde voit le processus pour ce qu'elle est: une série de tentatives, de discussions,
questions, et introspections qui se répètent jusqu'à ce que des propositions satisfaisantes soient prises (éventuellement
documenté dans les spécifications). Si quelqu'un ne veut pas participer à ce genre de fluide de travail, ils
devrait libérer une partie de leur autorité dans le processus de prise de décision à ceux qui le font. Design est
pas le même que l'ingénierie, et bien qu'ayant ingénieurs impliqués dans la conception tend à améliorer la
dessins, il est préférable d'enlever des personnes de cœur du processus que d'essayer de changer le
processus pour satisfaire un individu.

Si les objectifs du projet sont clairs, et les problèmes à résoudre sont identifiés, la conception
conversations qui en découlent seront de bonne humeur. Les désaccords vont se produire, mais si tout le monde essaie
pour résoudre le même problème, les conflits vont seulement jusqu'ici. Et étant donné les points que je l'ai faite plus tôt dans
ce chapitre sur la valeur de point de vue, ces problèmes peut amener les gens à élargir leur
perspectives. Comme les règles de l'improvisation suggèrent, l'idée d'une personne peut être un point de départ pour de lancement
quelqu'un avec un fond ou une opinion différente de suggérer quelque chose de tout à fait inattendu et
nettement mieux que ce qui a été proposé à l'origine.

«Je préfère travailler avec de bonnes personnes, parce que si je viens avec une idée, ils viennent
avec une meilleure idée, alors je viens avec un meilleur encore, et ainsi de suite: il est un saute-mouton
processus, et le travail devient beaucoup mieux que ce serait si je ne l'ai fait exactement
ce que je veux."

Terry Gilliam, réalisateur

Le genre de collaboration Gilliam décrit est possible seulement quand une équipe a confiance les uns les autres. Il est souvent
les gestionnaires et les dirigeants qui ont la responsabilité de créer des environnements de confiance et qui ont besoin
être ouvert aux bonnes idées, indépendamment de leur origine. Nous parlerons plus à ce sujet dans le chapitre 12 .
Page 107

5.9. Résumé

Beaucoup d'équipes ne parviennent pas correctement le temps entre les exigences et les spécifications.

Les exigences de qualité et des explorations de conception sont le meilleur usage de ce temps.

Les idées sont bonnes ou mauvaises que par rapport à des objectifs ou d'autres idées.

Les contraintes sont utiles pour trouver des idées, mais penser à l'extérieur de la boîte est pas nécessairement le
répondre. Parfois, la meilleure solution est de trouver une façon intelligente de travailler dans les contraintes.

Questions, des perspectives et des jeux d'improvisation sont des outils pour trouver de nouvelles idées.

Le meilleur endroit pour commencer avec des idées de conception est l'expérience du client.

Idées se développent dans des conceptions à travers des conversations entre différentes personnes ayant différents types
d'expertise.

Page 108
 Chapitre Six. Que faire avec des idées, une fois

vous les avez

Aussi difficile que cela est de trouver de bonnes idées , il est encore plus difficile de les gérer. Alors que le projet est
fredonner, document de vision en place et une forte dynamique créative aller de l'avant, il est
un autre niveau de réflexion qui doit se produire: comment les conceptions et les idées se traduire par des décisions?
Même si de bonnes conceptions et d'idées sont à l'étude, et les gens sont heureux de ce qu'ils sont
travailler, le défi de la convergence vers les spécifications reste. Si un changement de dynamique
vers des décisions de conception définitifs ne se fait pas au bon moment et ne sont pas gérées dans la bonne
Ainsi, la catastrophe attend. Pour de nombreuses raisons, l'échec du projet commence ici.

Si l'équipe a encore du mal à prendre de grandes décisions sur la journée programmeurs doivent spécifications (ou
les décisions qu'ils contiennent), le ton a été donné pour le reste du projet: les choses seront en retard, ils
seront foireux, et les gens ne seront pas en mesure de faire de leur mieux. Plus troublant est que, même si
les choses sont terminées à temps, si la qualité des idées reflète dans les dessins est pauvre, l'actualité peut
pas important. Selon les objectifs du projet, la qualité des idées peut compter autant que, ou
plus, être à l'heure.

Pour ces raisons, le temps entre l'achèvement de la planification précoce et la rédaction de

spécifications, dans toute étape, est toujours difficile. Équipes naturellement tendue lorsque la première grande
délai (IE, spécifications) est visible à l'horizon. Même si les gens ne sont pas en parler, de nombreux
reconnaissent que toutes les idées étant toujours discutés peuvent survivre. Il n'y aura pas assez de temps,
argent, ou aux gens de construire toutes les différentes choses qui sont envisagées. Les gens commencent à penser
des moyens pour couvrir leurs engagements ou coins coupés. Pire encore, certaines des idées et des conceptions peut
être en conflit les uns avec les autres. Une voiture peut avoir un seul moteur, une maison un seul toit, et si trois
différentes alternatives pour ces choses sont encore proposées, il est clair que la plupart d'entre eux ne viendra pas à
être.

Page 109

6.1. Idées deviennent hors de contrôle

Une observation frustrant en ces temps est qu'il ya beaucoup de bonnes idées rebondissant autour,
ils ne semblent pas se poser n'importe où. Peut-être la pire expérience de ma careerat ce stade dans un
projectwas pendant la fabrication d'Internet Explorer 4.0. (Si vous n'êtes pas intéressé par une autre guerre
histoire, vous pouvez passer à la section suivante.)

Je me souviens assis dans mon bureau à regarder mon tableau blanc. Un autre PM et je l'avais fait un schéma de
l'équipe de projet plus vaste et toutes les fonctionnalités que nous travaillions. Chaque fois que nous avons pensé qu'il était
complète, nous aimerions rappeler une nouvelle exigence qui avait été ajouté ou modifié. Quand nous avons fini, il
 a pris toute tableau blanc. Soudain, il était hors de la réunion, et je suis seul dans mon bureau avec
le schéma mal.

Je devais tonnes de travail à faire, mais je me suis assis et fixa toute façon. Je ne pouvais pas imaginer comment cela est arrivé. La
taille de chaque problème que nous essayions de résoudre était si grande et chevauché tant avec l'autre
problèmes que je ne pouvais pas le garder dans ma tête en même temps. Je ai adoré mon équipe et mon travail, mais
Cela ne m'a pas protéger de mon sentiment croissant de désespoir. Je ne pouvais pas voir comment nous pourrions terminer ce que nous
avait commencé. Bien qu'il a été un gâchis prometteuse, avec beaucoup de choses intelligentes en elle, il a été un gâchis
néanmoins. Un ami de l'équipe passa la tête dans mon bureau, a vu l'expression sur mon visage et
le schéma je regardais, et comprit immédiatement. Il a dit, "Hey, sentir l'amour!", Qui
est devenu notre cri de ralliement sarcastique pour le reste du projet.

Dans les premiers mois de l'IE 4.0 projet, nous avons eu une tempête parfaite de développement de logiciels. Nous étions
essayant simultanément de passer de petits rejets et des équipes (A la 2.0 et 3.0) pour un produit majeur
libération. Nous avons eu la pression de la concurrence de Microsoft avec Netscape, dont la presse l'industrie
faite pour être une bataille winner-take-all. Et puis il y avait la politique interne d'un transformateur
instant stratégique. Il aurait été difficile pour quiconque de maintenir le navire stable. Et comme la plupart
projets, il est quand l'élan se déplace de la planification à l'ingénierie qui egos et des opinions se heurtent.
Les gens sont confrontés à leurs premières décisions difficiles et se sentent les pressions de leurs engagements. Comme incertitudes
et les pressions deviennent de plus en plus évident, une chose ne change pas: les délais. La prochaine date siège
impatience à l'horizon, se rapprochant chaque jour. (1)

La solution, qui est l'objet de ce chapitre, est de gérer avec soin le domaine de conceptions possibles.
Quelqu'un a pour planifier et orienter chaque étape de l'exploration à la spécification. À moins d'une
conception expérimenté ou un champion d'ingénierie autour de mener cet effort (qui, comme mentionné dans le
chapitre précédent, est la meilleure façon), le fardeau tombe sur le chef de projet le plus proche. En ramassant
où Chapitre 5 quitté, nous allons nous concentrer en tournant le coin de la génération d'idées et la tête vers le
rédaction des spécifications (un sujet pratique couverte dans le chapitre suivant).

Page 110

6.2. Gestion des idées exige une main ferme

L'erreur la plus commune est de traiter le processus de conception comme si elle était une grande lumière switchyou pouvez juste
allumer et éteindre quand vous le souhaitez. Ce fantasme, comme il va, fonctionne comme ceci: vous vous présentez un jour,
sais qu'il est tard et qu'il ya trop d'idées et de conceptions (et pas assez de décisions),
et vous dites à l'équipe, "OK, nous en avons terminé avec les idées. Choisissez un design et nous allons commencer à coder! Woo-Hoo!"
Même à l'occasion de la large qu'il y est une conception qui est prêt pour primetime (qui il n'y aura pas), ce
type de comportement imprévisible va désorienter et à confondre toute l'équipe. Jusqu'à ce moment,
tout le monde travaillait sur des conceptions qui exigeaient le temps de cuire. Sans une date qui leur est donné, ils
peuvent avoir pensé qu'ils avaient droit jusqu'à 23h59 dans la nuit avant de spécifications étaient dus à faire
leurs grandes décisions.

Au lieu de cela, une bonne gestion idée est décisif, mais prévisible. Il ne devrait jamais être une surprise que la
nature du travail est en train de changer (sauf si il ya une crise) ou que l'accent de l'énergie est en train de changer
parce que le projet est dans une phase différente. Il devrait y avoir des rappels simples et naturels sur la
équipe que la portée et l'importance des changements. Comme un gradateur de lumière pour lightsthe genre avec un bouton qui
donne le contrôle mesurée sur changesthere devrait être un changement graduel d'orientation. Il est le projet
Le travail de gestionnaire pour gérer interrupteur qui gradateur et assurez-vous qu'il est contrôlé d'une main ferme.
Il peut y avoir un moment où quelqu'un a à dire, "Look. Le temps est écoulé. Est-ce A ou B?", Mais que
moment, devrait être prévu des jours ou des semaines avant qu'il ne vient à propos. Le rythme pourrait avoir besoin de
accélérer ou de décélérer, mais cela doit être fait avec élégance.

Pour illustrer cela, la figure 6-1 montre commodément une vision idéalisée de la phase de création d'un projet,
avec un point singulier dans le temps lorsque les problèmes et les objectifs ont été définis (document de vision et / ou
exigences), et un seul point dans le temps lorsque les spécifications seront terminées. Entre ces deux
les points sont beaucoup de remue-méninges, croquis, conception, prototypage, et toutes sortes d'autres plaisirs
 activités décrites dansetle
dechapitre
plus en 5plus
. Pour la première demialternatifs.
ou du temps disponible,
le secondtout le monde
venir avec des idées l'espace de modèles Pour semestre, la se concentre sur
accent se déplace à réduire le champ par le raffinage et l'amélioration des meilleurs dessins. Finalement, un
point est atteint lorsque suffisamment de décisions de conception ont été apportées à toutes les documenter dans un
spécification.

Figure 6-1. L'espace de problème doit réduire au tournant.

Ceci est une bonne histoire, et d'une amende diagramme, et je suis fier qu'ils apparaissent dans ce livre. Cependant, comme l'est
le sort de nombreux diagrammes fines, à celle illustrée ici représente quelque chose qui n'a jamais tout à fait
qui se passe. Ne existent pas ces lignes droites et des angles parfaits. Gestion des idées, comme beaucoup de projet
la gestion, est toujours un processus floue et subjective (voir les huit paradoxes de projet
la gestion dans le chapitre 1 ), et il ya plusieurs raisons importantes pour lesquelles ce schéma est inexacte.

Page 111

Tout d'abord, l'espace de problème tend à se déplacer d'avant en arrière. Il est jamais une ligne jaune vif qui est fixé dans
endroit. Parce que la compréhension des problèmes à solveand les moyens de résoudre Themis pas statique, la
l'espace des alternatives possibles est toujours en croissance et le rétrécissement. Exigences seront ajustés. La
tendances pourraient être pour l'espace pour croître de plus de rétrécir, rétrécir ou plus de croissance, mais il est tout jamais
de l'un ou l'autre. Il est plus d'une ligne courbe floue que droit.

Les raisons courantes pour cette comprennent:

De nouvelles informations deviennent disponibles . Le monde ne vous arrêtez pas parce que vous avez un projet
en cours. Les entreprises pourraient se retirer des affaires. Une technologie peut échouer. Les budgets peuvent changer. UN
étude de la convivialité ou une entrevue à la clientèle pourraient révéler une nouvelle compréhension du problème («les gens
imprimer des documents plus souvent que nous le pensions "ou" les utilisateurs peuvent même pas faire leurs tâches de base avec le
la conception de la page d'accueil, nous prototype ").

Le plan d'un ingénieur devient clair, en changeant les estimations approximatives de la quantité de travail
pourrait être possible . Pensée précoce donne toujours moyen de mieux, en pensant plus tard. Cela a parfois
fonctionne en faveur du projet, et parfois cela fonctionne contre le projet. Par exemple, un
programmeur pourrait trouver une nouvelle stratégie de mise en œuvre: «si nous construisons cette nouvelle façon, je ne fais pas
a à voir cinq de ces autres éléments de travail, et il est plus de temps pour d'autres travaux, ou nous pouvons
finir tôt (youpi) »ou« parce que nous ne pouvons pas construire comment je pensais d'abord, nous avons à faire cinq
éléments de travail supplémentaires, ce qui signifie moins de temps pour d'autres travaux, ou nous pouvons terminer fin (boo). "

Les conflits se trouvent entre deux solutions pour les deux problèmes différents que, lorsque
intégrée, le travail contre l'autre . Cela peut se produire pour la facilité d'utilisation, une entreprise ou
des raisons techniques. Joe pourrait avoir un design fantastique pour le moteur de la voiture, et Sally pourrait
avoir un grand dessein pour une transmission, mais une fois réunies, ils se rendent compte que les aspects de
chacune de leurs conceptions conflit les uns avec les autres; par exemple, la transmission ne correspond pas à la
moteur.

6.2.1. Changements provoquent des réactions en chaîne

Une autre raison de l'espace de problème se déplace est que le design décisions sont interdépendants: un seul changement possible
impact sur de nombreuses décisions différentes. Compte tenu de cette interdépendance, il est impossible de prédire totalement ce que le
impacts seront. Je l'ai vu cela se produire de nombreuses fois.

Sur le projet IE 5.0, un de nos objectifs était d'améliorer la capacité des gens à organiser leur liste des
sites Web préférés. Nous avons examiné quatre modèles différents et fait interface utilisateur simple (UI)
prototypes pour chacun. Avec ces prototypes, nous avons fait des estimations d'ingénierie rugueuses et a obtenu de base
informations convivialité à utiliser dans les comparant. Avec caractéristiques dues bientôt, nous avons choisi de mettre l'accent sur la conception B.
Mais alors, jours plus tard, nous avons appris qu'en raison d'un changement d'horaire sur un autre projet, un
composante de conception B dépendait ne serait pas disponible pour nous. Donc, nous avons dû revenir en arrière et de réévaluer
notre choix.

Quand nous avons fait, nous avons découvert que tous les autres modèles également tenus le même composant (d'oh!).
Puis, quand nous avons coupé la fonctionnalité (par exemple, supprimé l'obligation) que cette problématique
 composante
fournir cette aurait fourni, nous
fonctionnalité à euxavons appris
à travers quecode.
notre d'autres
Ce programmeurs
composant étaitont étéimportant
plus comptentde
surlanous pour
projet que nous avions initialement réalisé. Nous avons dû s'asseoir comme une équipe et de déterminer si nous pouvions nous permettre de
concevons et construisons cette fonctionnalité nous-mêmes, ou si nous pouvions vivre avec les conséquences de ne pas avoir
la fonctionnalité du tout.

Il est important de noter que cette histoire ne représente pas un échec. Sans prendre la décision d'aller
avec un design B, nous ne l'aurions jamais débusqué toutes les dépendances et les considérations de conception
impliquer. Je crois que les équipes intelligentes débusquer les exigences et les dépendances au début, mais si la
projet est complexe, vous pouvez ne jamais les avoir toutes. Je ne crois pas que le temps passé modélisation
systèmes complexes d'attraper tous la dépendance et de l'interdépendance est habituellement en valeur les coûts (si le
le rythme est rapide, et le projet est complexe, ces modèles seront coûteux à entretenir), mais il pourrait
être. Cela dépend des besoins du projet. Nous avons choisi de miser sur le travail d'équipe du processus de conception
à les débusquer pour nous, et il l'a fait.

Page 112

Quoi qu'il en soit, le processus de va-et-vient, je suis allé à travers, où les chemins ouverts et fermés, les hypothèses
ont été révélées fausses, et de nouvelles questions ont été soulevées, est précisément ce que les choses conception est tout au sujet.
Ceci est souvent appelé itération, ce qui signifie que les détails doivent évoluer au fil du temps (parce que le
problème est suffisamment complexe que les décisions ne seront pas droit sans plusieurs évolutions).

Spécifique à la conception, l'itération implique, une expérience en une seule étape-retour en deux étapes-avant. Le plus
difficile et complexe le travail, le plus serré que le rapport tend à être (par exemple, 1,5 pas en avant pour chaque 1
reculer). Mais jusqu'à ce que vous prenez ce pas en avant et prendre une décision («Courons avec un design B!"),
vous ne verrez pas tous les problèmes et questions. La prise de décisions lors de la conception, même si elles se révèlent
de se tromper, est le seul moyen de forcer les questions et les problèmes à la surface. Si vous prévoyez correctement, vous
sera mauvais à plusieurs reprises au cours du processus de conception, mais à travers ce faisant, vous sera considérablement
améliorer vos chances de succès. La plupart ingénierie, conception, et les efforts scientifiques ont similaire
modèles, comme la citation suivante exprime:

"Il ya encore d'énormes quantités d'essai et d'erreur .... Vous revenez en arrière et en avant de
observation de la théorie. Vous ne savez pas quoi chercher, sans une théorie, et vous
ne peut pas vérifier la théorie sans regarder le fait .... Je crois que le mouvement
avant et en arrière se produit des milliers, voire des millions de fois au cours d'une seule
enquête. "

Joshua Lederberg, lauréat du Prix Nobel 1958

6.2.2. Le travail créatif a élan

Le deuxième problème avec la figure 6-1 est que la dynamique créative d'un projet est toujours plus fort
que les dirigeants et les gestionnaires inexpérimentés attendent. L'effort nécessaire pour affiner une piscine d'idées
en un seul (bon) design devient beaucoup plus difficile, et exige des compétences différentes, que ce qu'ils
prévu. Figure 6-1 implique correctement que le temps de fermer un espace de problème devrait être aussi
longtemps que le temps qu'il a fallu pour pousser dehors. Mais le plus innovant ou créatif du projet est, le plus difficile
il consiste à estimer le temps de l'espace de problème aura besoin. Ceci est dû à l'œuvre créatrice de
élan.

La cause de cette dynamique est que le taux de nouvelles questions et de problèmes d'être découvert est plus rapide
que le taux que les vieilles questions sont fermées. Toute personne impliquée dans le travail peut sentir cette tendance.
Même lorsque la date cible pour les spécifications est semaines, beaucoup croient que le calendrier est
aller à glisser (et pire encore, qu'il n'y a rien qu'ils peuvent faire à ce sujet parce que les gestionnaires ne voient pas
il passe). Ceci est souvent le premier point majeur de glisser sur des projets. Il arrive peu à peu et est
constamment sous-estimé jusqu'à ce qu'il soit trop grand pour corriger facilement. (Je vais couvrir les actions correctives générales
pour les horaires dans les chapitres 14 et 15 ).

Donc, dans le schéma de la figure 6-2 (sensiblement plus laid que celui représenté sur la figure 6-1 , mais, hélas,
plus réaliste), l'équipe travaille dur, mais il est encore très clairement que la date pour l'écriture
spécifications est improbable. Le taux de fermeture est bon et est une tendance dans la bonne direction, mais son
trajectoire ne correspond pas à la date limite de spécification.

Figure 6-2. L'espace du problème augmente et diminue lors de la conception, par rapport
à l'élan inattendu de travail créatif.
Page 113

Cela est souvent la première fois qu'un chef de projet a la possibilité de céder à la panique. Jusqu'à ce point,
tout était abstraite: des mots, des objectifs, des listes et des ponts de diapositives. Mais quand les dessins ne sont pas ensemble
encore, et la date pour les spécifications métiers, les gens ont peur. Certains cherchent des moyens d'éviter le vrai
la situation en blâmant les autres, forçant mauvaises décisions, ou de nier l'existence du problème du tout. Chapitre
7 expliquera une technique pour faire face aux spécifications fin; chapitre 11 va discuter de ce qu'il faut faire
quand les choses vont mal. Mais dans ce chapitre, je vais me concentrer sur une meilleure façon de gérer les idées et éviter
ces problèmes en premier lieu.

Page 114

6.3. Les points de contrôle pour les phases de conception

La meilleure façon de gérer des idées est de commencer tout travail de conception majeur avec des points de contrôle claires pour la façon dont le
temps doit être utilisé. Au lieu d'avoir seulement deux points de contrôle, les exigences (ou la définition du problème),
et l'écriture des spécifications, des points intermédiaires doivent être définis avant le travail créatif va à pleine
vitesse. Il est le travail du gestionnaire de projet pour faire en sorte que ces points dans le temps sont créés (et que
 tout le monde
définir comprend
les spécificités leur
pour utilité),
quand cesmais il pourrait
points être préférable
dans le temps si lesetconcepteurs
se produisent ou ingénieurs
quels devraient être les critères pour atteindre
eux. (2) Il existe de nombreuses façons de le faire, et la meilleure façon varieront d'un projet
projet et une équipe à équipe. Mais, comme une règle de base, voici les points clés dans le temps (illustrés
dans la figure 6-3 ).

Figure 6-3. Les points de contrôle pour la conception.

Vision et la preuve de concept . Si le document de vision est livré avec une preuve de concept
prototype, la conception et le travail créateur a une longueur d'avance. Il y aura déjà des idées de design
et les concepts d'ingénierie d'enquêter et de construire hors des (ou de rejeter, mais avec améliorées
compréhension du problème). Il est pas une bonne vision si elle ne possède pas au moins un épreuvage rugueuse
de concept de prototype de conception.

groupements Idea / listes . Après la première vague de nouvelles idées et approches possibles sont élevés,
quelqu'un a d'organiser et de les consolider. Il devrait y avoir un moment où cette
qui se passe afin que l'équipe peut attendre et planifier.

Trois solutions de rechange . Après la mi-course, l'objectif est de réduire la conception possible
directions en trois à cinq alternatives. Plus le projet est complexe, plus les solutions de rechange
il devrait y avoir. Combien chaque variante diffère des autres dépend de la
posture agressive / conservatrice du projet, la confiance des concepteurs, et la
problèmes que le projet tente de résoudre.

Deux alternatives . Enquêter, la recherche, le prototype, et à la question jusqu'à ce qu'il est possible de
confiance éliminer jusqu'à deux alternatives. Il devrait y avoir deux orientations claires qui définissent
le plus grand point de décision restant (s).

Une conception . Enquêter, la recherche, le prototype, et à la question jusqu'à ce qu'il est possible de faire une finale
choix de la direction.

Spécification . Documenter la conception unique choisi. Utilisez le temps restant pour enquêter,

Page 115

comprendre, et se prononcer sur les questions de conception de niveau inférieur.

Ces points de contrôle doivent être définis par l'équipe dans le même temps le document de vision est
complétée. Si les horaires sont à court, à l'échelle le nombre et la taille des points de contrôle à la baisse ou sauter
certains des points intermédiaires. Et si il n'y a pas assez de ressources pour investir dans des points de contrôle pour tous
le travail, la priorité dans les plus importants défis de conception.

Il est important de réaliser que ces points de contrôle ne sont pas exclusivement utilisés pour contrôler le processus. Ils
aussi servir à guider l'équipe, diviser le travail en morceaux maniables, et de donner le gestionnaire de projet
une façon de comprendre l'état du projet. Lorsque des changements se produisent, les points de contrôle donnent à chacun
un cadre de référence pour discuter de ce qui se passe et pourquoi. Par exemple, après avoir atteint trois
alternatives, de nouvelles informations ou des idées qui pourraient se développer élargit temporairement le domaine de la
conceptions alternatives à quatre ou cinq. Cela pourrait signifier la conception est encore en vie, et une nouvelle réflexion est
étant utilisé pour améliorer la conception. Mais il pourrait également signifier que les directions inutiles sont en cours
exploré. Les points de contrôle obligent l'équipe de comprendre que l'on est, et reconnaissent lorsque le
espace de conception est de plus en plus grande que ce qu'elle devrait être. Les postes de contrôle créent des opportunités naturelles pour
les gestionnaires de projet et leurs équipes pour discuter de la façon agressive ou prudente ils doivent être dans leur
prochaines décisions pour garder le projet sur les rails.

NOTE

Ces points de contrôle peuvent être utilisés au niveau du projet ou pour tout problème de conception individuelle
à partir d'une fonction à un algorithme. Il est une tactique pour paître travail; il applique à toute échelle de
le projet.

D'après mon expérience, ce sont les premiers points de contrôle qui sont plus difficiles à obtenir à droite et le plus facile pour
 ingénieurs d'ignorer.
processus créatif. LesSigens
les premières étapes
vont voir la peuvent
valeur êtredans
et acheter bien le
gérées, une fondation
processus. est formé
Alors, prenez pour
soin de le reste
gérer les de la
quelques premiers points de contrôle. Avec des équipes particulièrement résistants, ce qui simplifie le processus en seulement trois
checkpointsproblems définies, les trois alternatives, et l'écriture specificationsmight être un réaliste
compromet la première fois (voir le chapitre 10 pour en savoir plus sur la création de processus d'équipe et l'adoption).

Page 116

6.4. Comment consolider les idées

Dans tout processus créatif, une fois que vous avez assez d'idées que quelqu'un doit se pencher sur les possibilités et
les diviser en tas utiles. Cela permet de comprendre la conception différente viable
les directions et de commencer à voir leurs différences. (En règle générale, 4 ou 5 tas de choses sont plus faciles au travail
avec de 30, 50, ou 150 choses individuelles. Cela est vrai pour les idées, les spécifications, les enfants hyperactifs,
petits animaux, des bonbons, des écrivains ennuyeux qui font listes stupides sans raison, etc.) Il est très bien si
quelques idées sont représentés dans les prototypes et les autres dans gribouillis, notes, ou des pensées inexplorées.
L'objectif est de ne pas éliminer ou d'affiner les idées individuelles, il est de mettre un peu la forme et la structure autour de
le centre commercial.

Il existe de nombreuses techniques (3) pour ce faire, mais la plus simple que je connais est un schéma d'affinité
(Aka KJ diagrammes, après l'anthropologue Kawkita Jiro). Cette approche nécessite quatre choses:
idées, un mur, Post-it, et l'équipe (même si la bonne bière et savoureux aide alimentaire). Dans une affinité
diagramme, chaque idée est représentée comme une note, décrit en quelques mots et placé sur le mur.
Ces idées peuvent être le résultat de séances de remue-méninges ou une liste affinée par une ou plusieurs personnes sur
l'équipe. Il peut y avoir n'importe où de 20 à 100 ou plus d'idées. L'ampleur du problème que vous êtes
essayer de résoudre, et comment les gens créatifs ont été, peut faire pour les sautes sauvages de la taille d'idées
d'un projet à.

Avec un schéma d'affinité, vous verrez une vue plus large de toutes les idées. Elle devrait ressembler à quelque chose comme
Figure 6-4 . Quelques idées sont semblables, et que vous souhaitez pour les positionner ensemble de sorte qu'ils sont plus faciles
pour identifier. Travailler permet visuellement gens à se concentrer sur les relations et non sur la quantité
informations qu'ils peuvent garder dans leur tête. Diagrammes d'affinité ont également l'avantage de faire
discussions avec les autres sur les idées naturelles. Un petit groupe de personnes peut se tenir ensemble sur le mur
et faire des commentaires sur les relations qu'ils peuvent, en changeant les positions de la Post-it comme
ils viennent à de nouvelles conclusions. Diagrammes d'affinité utilisent des Post-it, car ils peuvent être déplacés
autour d'une paroi et organisés en différents agencements facilement.

Figure 6-4. Beaucoup d'idées (yay), mais ils sont difficiles à gérer (boo).
 Le but du diagramme d'affinité est de parvenir à quelque chose comme ce qui est montré dans la figure 6-5 . Le même
liste brute d'idées sont maintenant regroupées en cinq seaux qui représentent la plupart des idées disponibles. Le chemin
pour ce faire est facile. Quelqu'un va vers le mur et commence à se déplacer autour d'idées. Le designer en chef, le
chef de projet, ou une petite équipe devraient être le premier à prendre un coup de couteau à l'organisation des idées. Après
quelqu'un a pris une première coupe, il devient plus facile pour les autres de se déplacer autour d'idées entre les groupes,
changer les noms des groupes, ou reconnaissent que certaines idées sont des copies de l'autre et
peut être enlevé. Comme les gens de l'équipe arrêtent et apporter des modifications, le schéma va changer dans
forme de diverses façons intéressantes. (Un conseil: envisager de prendre régulièrement des photos numériques si vous voulez
préserver les différents groupes de personnes viennent avec.) Finalement, le diagramme d'affinité installe
et les groupements émergent qui peut être utilisé dans les étapes suivantes.

Page 117

Figure 6-5. Regroupement des idées est une bonne idée.

Au cas où je suis trop abstrait décrivant comment des diagrammes d'affinité travail, voici un exemple qui
explique Figure 6-5 d'une autre manière. Disons que l'un des objectifs du projet était de faire de la recherche
les résultats sur le site Web intranet facile à utiliser. Nous avons rencontré, remue-méninges, eu quelques bières, et est venu
avec une longue liste d'idées. Le lendemain matin, les gens avaient un peu plus à ajouter, nous les avons donc inclus. Nous
examiné cette liste, éliminé les doublons, ri lorsque nous avons traversé hors idées ne pouvait expliquer, et
eu cette liste de base des idées pour travailler avec:

Supprimer les options avancées qui ne l'utilise jamais.

Améliorer la présentation de la page de résultats de recherche.

Utilisez le moteur de recherche HyperX supérieure.

Réduire le nombre de résultats présentés.

Permettre aux utilisateurs de définir des préférences pour la page devrait ressembler.

Ouvrez les résultats dans une nouvelle fenêtre.

Corriger les bugs de performance dans notre moteur de recherche.

Faire le travail du moteur de requête correctement (soutenir des recherches booléennes).

Après avoir examiné la liste et en utilisant des Post-it ou une autre méthode pour regrouper les idées, nous avons passé une
une demi-heure de les organiser. Nous les déplacions, essayé différents arrangements, et enfin arrivés
à une liste que nous pensions être le plus utile:

Simplifier

Personnaliser

Autoriser les utilisateurs à définir des préférences pour savoir comment la page doit ressembler
Ouvrez les résultats dans une nouvelle fenêtre

architecture Remodel

Faire le travail du moteur de requête correctement (soutenir des recherches booléennes)

Corriger les bugs de performance dans notre moteur de recherche
Utilisez le moteur de recherche HyperX supérieure

Les groupements ici sont très simples, et parce qu'il ya seulement un total de huit idées, il fonctionne très bien.
Cependant, si il y avait 40 ou 50 idées, une liste ne serait pas travailler ainsi. Listes promouvoir linéaire et
pensée hiérarchique, et ils deviennent difficiles à gérer quand ils deviennent trop grands. Plus tard dans
le développement, les listes sont un excellent moyen de faire avancer le processus, mais tout en restant dans les premiers stades,
diagrammes affinité sont plus puissants. Ils aident les gens voient les idées comme des choses fluides et tangible qui peut
être déplacés facilement et réorganisé. Cette fluidité aide les gens à remettre en question leurs hypothèses,
voir de nouvelles perspectives, et de suivre les pensées des autres. Pour les équipes de nouvelles à la pensée créative
 (En particulier en tant que groupe), un diagramme d'affinité est un excellent moyen d'aller. Utilisez des listes pour vos propres besoins comme
un gestionnaire de projet après, mais donner à l'équipe une affinité. Je suis convaincu qu'il aide à trouver plus

Page 118

bonnes idées et rassemble les gens dans le processus.

6.4.1. Affiner et prioriser

Ne vous inquiétez pas de trouver "le meilleur" bonne groupingpretty est assez bon. Il ya plusieurs façons de
groupe encore un petit nombre d'idées, et beaucoup d'entre eux sera bon. But pour quatre ou cinq groupes qui
couvrir motif différent ou impliquer des directions différentes. Certaines idées pourraient pas tout à fait dans l'un quelconque
groupe, mais le travail eux du mieux que vous pouvez de toute façon.

Rappelez-vous que vous pouvez revenir à vos idées et de se regrouper plus tard si vous avez besoin. Lorsque vous trouvez
quelque chose qui se sent bien, passer. Vous ne livrons pas les diagrammes d'affinité ou des listes d'idées à la
client, il ne faut pas overthink il.

Un dernier exercice à considérer est de prendre une passe informelle à prioriser les idées (je couvrirai formelle
priorités dans le chapitre 12 ). Quelles idées sont les plus prometteuses? Reportez-vous à la vision du projet
et les problèmes à résoudre pour vous assurer que tout le monde comprenne les critères réels, car il est facile à
tomber en amour avec des idées pour des raisons qui ont rien à voir avec les objectifs du projet. Une personne
devrait conduire ce processus, que ce soit le chef de projet ou le concepteur en chef. Le plus vous informel
garder cette discussion, le moins de temps cela va prendre. Il est pas nécessaire d'établir des critères complexes
liste de contrôle et la procédure d'évaluation. Tout ce que vous avez besoin est une idée approximative de ce qui concepts semblent plus forte
avant de vous déplacer au prototypage. Devrait prévoir du temps devenus plus courts, ce guide sera rude
rendre plus facile à démêler où utiliser votre temps restant.

Page 119

6.5. Prototypes sont vos amis

Dans le chapitre 5 , je l'ai expliqué pourquoi le design est une exploration. Vous devez explorer l'espace de problème
 comprendre quelles sont les alternatives. Une bonne conception dépend de la connaissance des solutions de rechange parce
plus l'information que vous avez sur les problèmes et les solutions, il est le plus facile de faire bonne
décisions. Prototypes sont la prochaine étape naturelle dans le processus de conception. Ils prennent tout ce qui est
été appris et l'appliquer au problème sans prendre sur les risques de mise en œuvre complète.
Prototypes remplissent la maxime du charpentier, "mesure deux fois, couper une fois", en améliorant la conception
penser avant que l'équipe engage un plan. Et comme je l'expliquerai prochaine, les prototypes ne doivent pas être
élaborer ou coûteux, ou d'exiger beaucoup de temps. Si vous êtes sceptique quant à la valeur de prototypage,
passer à la section " Prototypes soutenir les programmeurs. "

6.5.1. Où les prototypes commencent?

Avec quatre ou cinq groupes en main, vous avez ouvert la voie à bon prototypage. Alors que les gens avec
compétences créatives fortes pourraient avoir vu les indications pour des alternatives jours avant, des groupements de
idées rendent plus facile pour l'équipe pour voir combien il ya des solutions de rechange. Avec 20 ou 30 idées, il
ya des centaines de différentes façons dont ils pourraient être combinés, sans compter le nombre de façons différentes là-bas
sont à interpréter chaque idée individuelle.

Un designer expérimenté aura un bon instinct pour savoir comment commencer. Elle sera tri confortable
à travers les idées et décider ce qu'il faut premier prototype disponibles (pour ne pas mentionner comment s'y prendre
je le fais). Mais si vous êtes concevoir sans un, il existe plusieurs façons simples de choisir quoi
prototype:

Choisissez l'idée la plus prometteuse de chaque groupe et essayer de les combiner en une seule conception.

Avez-petits prototypes pour chaque groupe pour voir où ils vont. Tous les problèmes pourraient être nécessaires
résolu simplement en remodelant l'architecture ou en ajoutant personnalisation? Voir dans quelle mesure chacun
direction prend la conception.

Le jugement de Designer: permet au concepteur d'utiliser son expérience et de l'intuition pour décider quoi
utiliser dans un premier coup de poignard.

Faites une liste des plus difficiles ou les plus importants des questions de conception, et de faire un prototype (s)
aidera à y répondre.

En règle générale, le plus sophistiqué, le prototype est le plus sophistiqués les questions qu'il
peut répondre. Un croquis sur le dos d'une serviette est très bien pour les types très tôt et très rugueux de
questions, mais si vous voulez savoir quelque chose de spécifique et d'être confiant dans la réponse, vous aurez besoin
quelque chose de beaucoup plus impliqué.

Avec les premiers prototypes en cours, il devrait devenir clair que les idées supplémentaires pourraient être ajoutés
sans provoquer des conflits ou des problèmes, et lesquels ne sont plus adaptées. Comme un puzzle, certains
les choses vont glisser ensemble et faire plus de sens que d'autres, mais il faut essais et erreurs pour trouver
dehors. Parce qu'il ya tellement de détails et perspectives (client, affaires, technologie), il est
impossible de prédire quels chemins vont travailler et ceux qui ne sera pas. Et voilà précisément ce que
prototypes et son itération sont pour: faire des erreurs, l'apprentissage, la révision, et aller de l'avant.

6.5.2. Prototypage pour des projets avec des interfaces utilisateur

Prototypes doivent être effectués de haut en bas. Commencez par ce que les utilisateurs verront et l'ordre dans

Page 120

où ils vont le voir. Impliquez votre convivialité et experts de conception le plus tôt possible pour obtenir une certaine
dessins et des hypothèses raisonnables. Il n'y a pas beaucoup de sens en jours de dépenses de la planification des bases de données
et des schémas XML que quelques écrans ont été réalisés: voilà comme la construction de la charpente d'une maison
avant d'avoir vu le plan d'étage. Si vous le faites, vous êtes assuré de jeter la qualité de la production
travail, quelque chose de l'effort de prototypage vise à éviter. (Pour les arguments sur les questions de
Avant de concevoir la programmation, voir Alan Cooper Les détenus exécutent le droit d'asile , Sams,
2004.)

Au lieu de cela, attendre jusqu'à ce que il ya des croquis ou des maquettes de l'interface utilisateur qui sont prometteurs (meilleure
déterminée par des études d'utilisabilité ou en marchant à travers les décisions utilisateurs auront à faire sur
chaque écran pour faire leur travail). Les ingénieurs devraient ensuite explorer comment il pourrait réellement se construit. Si
des discussions similaires ont commencé plus tôt dans le projet, ce devrait être un prolongement naturel et facile de
leur.

En ce qui concerne la façon de construire des prototypes, il n'y a aucun secret magique. Il faut une certaine expérience pour apprendre ce qui
les choses peuvent être truquées ou passés sous silence et ceux qui nécessitent plus de réflexion et de l'investissement. (4) Le
règle générale est de faire le moins de travail nécessaire pour obtenir l'information dont vous avez besoin. Quelconque
toolFlash, HTML, VB, ou même papercan être utilisés pour des prototypes. Il est beaucoup plus sur la compétence
du concepteur et / ou prototyper que la technique ou un outil.

6.5.3. Prototypage pour des projets sans interfaces utilisateur

Même sur des projets avec aucune interface utilisateur ou des interfaces Web, il est toujours judicieux de prototype. (5) Au lieu
de problèmes de conception d'interface utilisateur, choisissez les défis techniques les plus difficiles ou complexes et prototype
 leur. Confirmez que les algorithmes de base sont solides, satisfaire des cas de test de base, ou de répondre à un sous-ensemble de la
critère de performance. Le but de prototypage est le même, peu importe quel genre de projet, il est: le travail
à comprendre si l'approche approximative (s) que vous envisagez peut être construit dans le temps imparti
et effectivement résoudre les problèmes posés. Il est une chance de faire face aux risques avant le début de la mise en œuvre
et d'en apprendre davantage sur ce qui doit être fait avant de s'y engager.

6.5.4. Prototypes soutien programmeurs

Dans la situation où il ya un concepteur ou gestionnaire de projet qui peut conduire l'effort de prototypage,
les programmeurs et les ingénieurs se plaignent souvent qu'ils ont rien à faire. (6) Ils pourraient aussi dire
que le processus est une perte de temps (une affirmation souvent faite de tout ce qui ne concerne pas l'écriture
Code). Au contraire, je pense que les programmeurs bénéficient davantage de prototypage que quiconque sur la
équipe. Prototypage, il est bien fait, améliore considérablement la probabilité que les dessins qu'ils
sont priés de construire ont été bien pris en compte et sont de haute qualité. Il est pas garanti, bien sûr,
mais les chances ne augmentent. Peut-être ce qui est plus important pour le chef de projet, tout en prototypage
se déroule, est pour les programmeurs d'avoir le temps de plomb pour enquêter sur le développement et la
approches d'ingénierie dont ils auront besoin à utiliser. La qualité de leur code de production devrait augmenter si elles
investir leur temps de conception à bon escient.

Voici une courte liste de questions programmeurs devraient être responsables de répondre à ce moment:

À un niveau élevé, comment allons-nous construire ce qui est montré dans le prototype (s) de conception? Y at-il existante
Code ou de la technologie qui peut / doit être utilisé?

Conception raisonnable Y at-il modifie le concepteur doit être conscient de cela réduira
les coûts d'ingénierie?

Quels sont les cinq ou six principaux composants nécessaires, et comment vont-ils se rapportent les uns aux autres? À
le plus haut niveau, comment cher ces composants va être de construire?
(Haut / moyen / bas / inconnue est suffisant. Pour la réponse inconnue , il est le travail du programmeur
à commencer à enquêter.)

Où sont les plus grands risques techniques? Quels composants sont les plus difficiles ou les plus complexes à
construire?

Page 121

Quelles sont les interfaces entre les composants, sont les plus complexes ou les plus susceptibles d'échouer? (UN
Testeur QA personne dédiée ou, le cas échéant, pourrait répondre à cette meilleure.)

Tout comme il n'y a aucun moyen pour un concepteur de répondre avec confiance aux questions complexes de conception sans
prototype de conception, il n'y a aucun moyen pour un ingénieur de répondre en toute confiance l'ingénierie complexe
questions sans prototype d'ingénierie (en dépit de ce qu'il pourrait dire). Si jamais multiples
les efforts de prototypage sont nécessaires, ils doivent être effectués en synchronisation avec l'autre. Il est préférable pour le plomb
concepteur et l'ingénieur en chef de passer du temps à parler les uns aux autres, poser des questions, et d'aider
l'autre pour prendre les bonnes décisions. Les deux efforts de prototypage devraient être sur une voie qui pourrait
finalement se rejoignent conceptuel: les bureaux d'études idées doivent correspondre.

6.5.5. Alternatives augmentent la probabilité de succès

Spécifique aux interfaces utilisateur et des conceptions de Web, la plupart des prototypes Je ai contribué ou fait moi-même,
eu beaucoup de frères et sœurs. Avec la grande piscine d'idées qui sont apparues dès le début de la création
processus, il y avait de nombreuses alternatives qui semblaient tout aussi raisonnable que les autres. La seule façon de
comprennent ceux qui étaient mieux était d'essayer certains d'entre eux. Les concepteurs ou ingénieurs qui sont
connu à la réalisation de prototypes ont la capacité de changer l'interface utilisateur, mise en page, ou autre
détails à l'un d'un certain nombre de configurations (CSS et HTML sont de grands exemples, où
il ya des couches qui peuvent être modifiés indépendamment l'un de l'autre). Un prototype flexible peut faire
les discussions et les décisions se produisent beaucoup plus rapidement parce que les gens ne doivent pas imaginer et visualiser comme
beaucoup dans leurs esprits.

Je l'ai appris par expérience que peu importe combien il semble que les gens d'accord, si elles ne sont pas tous
regarder la même image, ils peuvent ne pas être en convenant à tous. Chaque personne peut avoir quelque chose de très
différente dans l'œil de son esprit, et quand elle a dit oui aux autres, elle a effectivement accepté de très
choses différentes. Plus tard, les chances sont bonnes il est le concepteur ou le gestionnaire de projet qui sera blâmé
pour ce genre de confusion. Prototypes sont un moyen fiable pour l'empêcher parce que ce sont des choses réelles
qui peut être montré et renvoyé à plus tard. "Vous voyez ça? Vous avez accepté cela, et tout le monde dans la salle
vu que vous acceptez cette conception exacte. "Vous devriez appeler spécifiquement les aspects de prototypes ou de conception
captures d'écran que vous utilisez de cette façon.
Page 122

6.6. Questions pour itérations

Avec la première coupe à un prototype, des tonnes de nouvelles idées et questions viendront. Cela inclura
suggestions de changements, des améliorations et de nouvelles idées à essayer. Si il est un des premiers prototypes, sa prochaine
itération pourrait se concentrer sur l'exploration de grandes idées ou des changements de largeur. Si il est un prototype fin, itérations
devrait être utilisé pour réduire l'espace de conception et aider à prendre des décisions. Étant donné que chaque itération est
ensemble, il ya une opportunité pour un nouveau débat sur les progrès de la conception. La meilleure
cadre pour ces discussions est un ensemble de questions qui aident à évaluer la conception et que l'accent
la discussion de façon productive.

Voici quelques questions pour les premières itérations de prototypes:

Quelles sont les exigences de cette satisfait-il? Peut-on vérifier cela? (Facilité d'utilisation, cas d'utilisation, etc.)

Ce qui est bon et mauvais à propos de cette conception par rapport au problème qu'il est censé résoudre? (Avantages
et les inconvénients de chacune de convivialité, des affaires, de la technologie, les considérations.)

Quelles données avons-nous besoin pour évaluer cette conception? (Peut-être une étude d'utilisabilité, un examen informel
par un programmeur pour la santé mentale de l'ingénierie, le marketing, l'opinion d'un expert, etc.)

Qu'avons-nous appris de cette conception que nous devrions garder à la prochaine tentative? Éliminer?

Que pourrions-nous essayer dans la prochaine itération de faire ce mieux?

Y at-il d'autres idées des groupements d'idées ou d'autres prototypes que nous devrions inclure?

Voici quelques questions pour les itérations de prototypes fin:

Quelle décision ne nous aider à faire cela?

Quelle question ouverte cela nous aidera-fermons?

Cette conception a confirmé l'existence d'un problème que nous devons examiner? Formé il résolu un
problème que nous devions résoudre?

Que pourrions-nous essayer dans la prochaine itération de nous rapprocher de la rédaction des spécifications?

Et avec cela, le concepteur dispose de suffisamment d'informations pour prendre une autre version du prototype,
intégrant peut-être deux alternatives différentes ensemble ou bifurquer la conception en deux nouvelles
alternatives. Il ne devrait pas y avoir de restrictions sur ce qui est autorisé ou non autorisé, tant que
tout ce qui est fait par la suite fait le travail de conception d'un pas de plus vers l'achèvement.
Page 123

6.7. La liste des questions ouvertes

Comme le domaine des solutions de rechange se rétrécit, il ya une nouvelle responsabilité pour le chef de projet: le
liste non questions. Une question ouverte est quelque chose qui doit être décidé ou compris mais n'a pas
encore arrivé. Il est essentiellement une liste de questions, et il devrait englober tout ce qui doit être
fait, en priorité par son impact potentiel sur l'ingénierie. La forme de cette liste ne soit pas aussi important que le
qualité des questions énumérées et la diligence de la personne qui conduit à les résoudre. Je l'ai utilisé une
désigné tache sur un tableau blanc ou feuilles de calcul Excel pour cela, et je ne peux pas dire que l'outil que je choisi
fait beaucoup de différence de toute façon. Je ne pense pas que ces listes doivent être contrôlé ou géré comme
code source (qui est, à moins que la politique ou la culture de votre organisation font qu'il vaut la peine); la
l'outil simple, plus il est meilleur.

Cette liste peut commencer avec une liste très approximative de questions sans réponse ("Allons-nous utiliser des données schéma A ou B?"
ou "Nous avons besoin de la conception finale de l'interface utilisateur de Sally"), mais il devrait croître et d'améliorer en détail que moins de jours
rester devant les spécifications sont écrites. Chaque élément doit avoir un nom à côté de la personne
qui est le moteur de la question de la résolution. Il devrait être le travail du PM pour vous assurer que tout le monde est au courant de
questions qu'ils ont été affectés, harceler de façon appropriée, et de les suivre à la résolution.

Les programmeurs devraient avoir le fardeau de questions d'ingénierie et de recherche, mais si il y en a

questions que le PM peut prendre, il le devrait. Typiquement, les éléments qui pourraient bloquer l'ingénierie, mais ne sont pas
specificsuch d'ingénierie comme une approbation de commercialisation, les considérations d'utilisabilité, l'image de marque, et visuelle
designshould être suivis par le gestionnaire de projet, car ils auront un impact sur la spécification plus que
la mise en œuvre (nous allons couvrir la différence entre les deux dans le chapitre 7 ).

Le gestionnaire de projet sage divise la liste des questions ouvertes en deux priorités: des choses qui doivent être
résolues avant que les spécifications et les choses qui pourraient attendre plus tard. Il est le moyen le plus naturel pour
établir des priorités et se concentrer sur les questions qui ont le potentiel pour bloquer engineeringand éventuellement l'ensemble
projet. Tout sur la liste après la spécification devrait être clarifiée avec les ingénieurs parce qu'ils sont les
seuls qui peuvent vérifier que la décision ou de l'information peuvent attendre. (Comment et pourquoi les choses doivent attendre
qu'après spécifications seront couverts dans le chapitre suivant).

Donc, toutes les incertitudes qui doit être adressée doit être répertorié. Personne d'autre que le chef de projet
peut-être besoin de voir cette liste, certainement pas dès le début. Mais au fil des jours, il peut servir comme un outil pour unifier le
équipe à des réunions ou des discussions de couloir. L'objectif est de ne pas rendre les gens se sentent mal, il est de leur rappeler
de ce qui reste et les aider à voir quels sont les problèmes d'autres membres de l'équipe doivent résoudre. Car
Le travail de chef de projet affecte tout le monde, faisant de la liste visible permet aux gens de collaborer sur
résoudre les problèmes. "Oh, qui est sur ma liste, aussi. Si vous le prendre, ou devrais-je?" Ceci est une raison
Je l'ai gardé ma liste de questions sur un tableau blanc dans mon bureau ou dans le couloir. (Un site Web peut travailler
très bien, mais dans mon expérience, personne ne regarde jamais cette liste, mais la personne qui l'a créé. Non virtuelle
et des lieux informels fonctionnent beaucoup mieux.)

Je trouve que chaque fois que les gens sont venus à mon bureau et a demandé comment les choses allaient, je parle de ce
liste et dire: «Voilà exactement comment les choses se passent. Lorsque cette liste est vide, je serai en mesure de terminer ceux
CARACTERISTIQUES TECHNIQUES ». Bien que ce soit pas un indicateur de performance ou quelque chose rigoureusement mesurables dans le temps,
l'état de la liste des questions d'un chef de projet, et la portée des questions qu'il comprend, révèlent une grande
traiter de la façon dont les choses vont bien. Si la liste est longue, mais contient des questions très spécifiques et étroites,
les choses sont en bonne forme. Si la liste est courte mais demande fondamentaux effrayantes comme: «Quel problème sommes-nous
essayer de résoudre? "ou" Quel langage de programmation utilisons-nous? ", vous savez le projet a une longue
marche à suivre.

Page 124

6.8. Résumé
 Les idées ont leur propre dynamique. Il faudra plus de temps à régner dans le travail créatif que vous attendez.
Les changements seront en cascade à travers un projet.

Créer des points de contrôle pour le travail créatif pour suivre et gérer. Points de contrôle communs incluent
proof-of-concept, groupements d'idées, trois alternatives, deux alternatives, une conception.

Utiliser des diagrammes d'affinité pour consolider idées.

Prototypes permettre au projet d'affronter les problèmes plus rapidement et d'apprendre de ses erreurs sans
risque significatif.

Utilisez itérations, ou le raffinement périodique d'un prototype, à poser des questions, d'évaluer les progrès,
et décider des prochaines étapes.

Créer une liste non questions pour suivre les questions qui doivent être résolues avant que les spécifications peuvent
être achevé.

Page 125

Partie II: Compétences

Chapitre 7 : Rédaction de spécifications

Chapitre 8 : Comment prendre les bonnes décisions

Chapitre 9 : Communication et relations

Chapitre 10 : Comment ne pas ennuyer les gens: le processus, le courriel et réunions

Chapitre 11 : Que faire quand les choses tournent mal

Page 126

Chapitre Sept. Ecrire de bons spécifications

Je ai eu un argument avec un programmeur qui a cru que nous ne devons écrire spécifications. JE
entra dans son bureau avec ce grand gabarit je avais dit d'utiliser par notre patron, et il a juste ri au
(et malheureusement, à moi aussi). Son opinion était que si ce que je voulais faire était si compliqué
 que je devaispour
la nécessité 50 pages pour expliquer
l'ensemble aux programmeurs,
de ce processus ça ne valait
et de la paperasserie comme pasun
la signal
construction
que la de toute façon. Iletalavucoordination sur
communication
l'équipe était défaillant, et que nous étions pas confiance pour décider des choses pour nous-mêmes. Nous ne devrions pas avoir besoin
tellement frais généraux et de la bureaucratie, at-il dit, laissant entendre que la planification élaborée n'a jamais été nécessaire.

Ayant eu cet argument devant, je souri. Je lui ai demandé si il avait fait la même demande au sujet de la
les plans d'ingénierie pour la construction d'appartements salut-lieu ou il a vécu dans l'autoroute viaduc de trois étages
il a conduit à se rendre au travail. Mais apparemment, il avait entendu cette question auparavant, et il sourit droit
arrière. Il a dit que pendant qu'il était heureux de ces choses ont été prévues dans les moindres détails, il ne pense pas
travailler avec le logiciel était tout à fait la même chose que de travailler avec les lois de la physique et de la construction
matériaux. Nous nous sommes rapidement mis d'accord sur deux points. Tout d'abord, que, par rapport à l'ingénierie traditionnelle, logiciels
est plus souple, plus facile à changer, et a rarement la vie des gens en jeu. Mais, nous avons reconnu que
parce que nous face à des défis d'ingénierie complexes, eu une équipe de personnes en fonction de notre
les décisions et les budgets et les délais eu à répondre, il nous fallait plus de nos souvenirs de couloir
conversations à assurer que les bonnes choses se sont produites.

Nous avons également convenu que ce que nous avions besoin pour notre projet a été quelque chose d'adapté à la nature du travail que nous
ont été faites et le genre de personnes que nous étions. Une sorte de documentation écrite serait utile si elle
résoudre des problèmes réels pour notre équipe, accéléré le processus de faire avancer les choses, et l'amélioration de la
probabilité d'un résultat de qualité (et il devait être mise à jour au fil du temps sans bouleverser
quiconque). Si nous pouvions faire quelque chose qui atteint ces choses, il a dit qu'il serait heureux de l'utiliser,
indépendamment de ce que nous appelions ou quelle forme il est venu. Et avec cela, nous avons révisé le processus de spec
bas en quelque chose, nous avons convenu serait travailler pour notre petite équipe. Je suis retourné à mon patron, rabâché
notre conversation, et a travaillé sur un compromis. Le grand, droit fiscal taille spec modèle alla.

Page 127

La principale leçon de cette histoire est que comme toute autre chose les gens font, il n'y a pas une seule bonne façon
rédiger des spécifications ou pour documenter des travaux. Spécifications, comme la plupart des choses que les équipes sont invités à le faire,
doit correspondre aux besoins du projet en cours et les personnes qui auront à créer et à les lire.
Et de la même manière que les sites Web ou logiciels doivent passer par un processus de conception pour trouver
les meilleures approches, les spécifications ont besoin d'une pensée et d'itération à faire correctement.

Mais beaucoup de gens expérimentés que je connais sont tombés dans le piège de croire il ya une seule façon de
faire spécifications (ou quel que soit ils les appellent), qui tend à être quelque manière qu'ils l'ont fait la dernière fois.
Parfois, cette chaîne de répétition va tout le chemin du retour vers les premiers projets qu'ils ont travaillé sur. Ils
supposons que parce que ces projets ne sont pas complets catastrophes, la façon dont ils écrit spécifications
contribué positivement vers ce résultat: une allégation selon laquelle sans aucune enquête peut ou non
être vrai (ie, le projet aurait pu réussir, en dépit d'un processus de spécification dysfonctionnelle). Pire encore, si
bonnes questions sur comment et pourquoi les spécifications sont écrits ont jamais été demandé, personne sur l'équipe
comprend vraiment comment bon ou mauvais le processus d'écriture de spec est vraiment, ou combien il ou ne
ne pas contribuer à la performance de l'équipe. (Ceci est tout à fait similaire à la façon dont l'absence de bonne
questions sur l'écriture de code de qualité empêche la possibilité de comprendre comment bon ou mauvais le
Code est vraiment.)

Mon objectif dans ce chapitre est d'expliquer l'ensemble des idées suivantes. Tout d'abord, que les spécifications devraient faire
trois choses pour un projet: veiller à ce que la bonne chose se construit, fournit un jalon de calendrier qui
conclut une phase de planification d'un projet, et de permettre une révision profonde et commentaires des différents
personnes sur le parcours du projet prendra. Ces trois choses sont très importantes, et il est
peu probable qu'un processus autre que des spécifications écrites fournir tous en même temps. Pour cela
seule raison, je suis un fan de spécifications. Deuxièmement, la plupart des plaintes des gens ont sur les spécifications sont facilement
remédié, à condition que leurs auteurs à comprendre les pièges courants de la rédaction de spécifications et reconnaissent la
Fiche d'avantages spécifiques devraient être utilisés pour fournir.
Page 128

7.1. Quelles sont les spécifications peuvent et ne peuvent pas faire

Spécifications, comme des documents de vision, sont une forme de communication. Lorsqu'il est utilisé de manière efficace, ils
communiquer des informations importantes d'une manière simple et facile à consommer. Lorsqu'elles sont mal utilisées, elles sont
difficile à lire, fastidieux de créer, et frustrant pour tout le monde qui vient en contact avec eux.
Souvent, les équipes qui écrivent spécifications moche semblent avoir besoin de plus d'entre eux (comme dans «Si les loups viennent dans les paquets,
spécifications viennent dans fléaux "). La plupart du temps, les spécifications faibles ou défaillants proviennent d'un
malentendu sur ce cahier des charges sont capables de faire et ce qu'ils ne peuvent peut-être réaliser.

Voici une liste des choses importantes spécifications peuvent faire pour un projet:

Décrire efficacement les fonctionnalités de ce qui va être construit

Aider les concepteurs à clarifier les décisions en les forçant à être précis

Permettre à l'examen, le questionnement et la discussion des plans détaillés avant la mise en œuvre complète
commence

Communiquer les informations d'une à plusieurs

Créer un point de référence pour les plans spécifiques équipe-large (et si élaboré lors de la conception
la phase, l'utiliser comme une documentation vivante de ce qui se passe (1) )

Fournir un calendrier étape naturelle à concentrer l'équipe

Créer une assurance contre l'auteur (s) d'être frappé par un bus (2)

Accélérer, améliorer et augmenter la fréquence des discussions saines

Donner aux dirigeants une occasion de donner une rétroaction et de mettre la barre de la qualité

Ajouter la santé mentale et la confiance de l'équipe (et auteur)

Choses spécifications ne peuvent pas ou ne devraient pas faire:

Éliminer toutes les discussions entre les membres de l'équipe

Prouvez à l'équipe comment futé est l'auteur

Démontrer l'importance d'une fonction est (ou pourquoi il ne devrait pas être coupé)

Convertir les gens à un point de vue philosophique

Soyez une aire de jeux pour Visio UML ou les compétences de l'auteur

Les dirigeants de l'équipe devraient dresser une liste comme celle-ci pour l'équipe à utiliser. Tout le monde qui le fera
avoir à lire ou d'écrire les spécifications devraient être invités à revoir la liste et faire des commentaires à ce sujet avant toute
specs sont écrits. Peut-être qu'il ya quelque chose énumérés que l'équipe n'a pas besoin de spécifications pour ou
quelque chose ne figure pas qui devrait être ajouté. Cela peut être une discussionhalf rapide une heure max. Même un
courte discussion à ce sujet établit des attentes pour ce que les spécifications contribueront, et donne à l'équipe une chance
à fournir des suggestions pour de meilleures façons de s'y prendre. Si il est un modèle d'équipe à l'échelle pour
spécifications, il doit être écrit avec ces critères à l'esprit.

Page 129
 7.2. Décider quoi spécifier

Chaque méthodologie je l'ai vu pour le développement de logiciel ou de gestion de projet définit les spécifications
différemment. Je ne suis jamais inquiet trop à ce sujet. Il ya quatre types de base de l'information qui
finissent dans les spécifications, et la meilleure façon de les aborder est en supposant qu'ils finissent dans quatre
documents différents. Mais comment ces choses se répartissent est pas particulièrement important (bien que certains
les gens ne se religieux à ce sujet). Ce qui importe est que la bonne information est défini par le droit
les gens, et qu'il est produit d'une façon qui est utile pour les gens qui ont besoin de le consommer. Donc, sur
petites équipes, ces différents types de spécifications sont souvent combinés. Sur les grandes équipes, ils peuvent
besoin d'être séparé (mais reliés entre eux) et même rédigé par des personnes différentes.

Exigences . Pour documenter les nombreuses choses attendues d'un projet, une des exigences
spécification décrit toutes les demandes et les obligations que le travail doit vivre jusqu'à. Ce
consolide toutes les autres exigences de travail et fournit un point de référence pour le projet. À
mieux, cela est une liste de conditions de victoire, décrivant ce que le résultat final sera sans
expliquant trop sur la façon dont il sera atteint. Dans tous les cas, les exigences devraient être définies
avant que le processus de conception commence (bien qu'ils puissent être améliorés et mis à jour plus tard), et ils
doit être dérivé à partir du document de vision. Ils devraient être inclus avec option
spécifications pour la clarté et pour aider à l'examen (que ce plan va satisfaire les exigences?).

Caractéristique . Une spécification de fonction décrit le comportement et la fonctionnalité pour un particulier

scénario ou un ensemble de scénarios de la perspective du client. Une spécification de caractéristique est la
sortie principale du processus de conception. Il décrit la fonctionnalité du logiciel par l'intermédiaire du
interface utilisateur (si il y en a un), et il explique en détail comment les choses devraient fonctionner de la plus non-
point de vue technique. Il devrait décrire comment l'expérience du client ont changé
lorsque le travail est terminé, et il devrait contenir une simple énumération des travaux de l'ingénieur-défini
éléments nécessaires pour l'accomplir. Ceci est différent de la liste des exigences en ce qu 'il définit un spécifique
conception qui satisfait aux exigences, y compris l'interface utilisateur ou d'une autre conception non triviale
éléments.

Spécifications techniques . Une spécification technique détaille l'approche d'ingénierie nécessaires à l'exécution
la spécification de fonction. Il doit être seulement suffisante pour décrire la plus complexe ou détaillé
composants réutilisés que d'autres programmeurs peuvent réutiliser, et en apporter la preuve
pour les éléments de travail nécessaires à une spécification de fonction. Parfois, la profondeur ou de nature technique
d'une spécification de fonctionnalité élimine la nécessité d'une spécification technique.

Listes des éléments de travail . Ce sont à peu près équivalent à la structure de répartition du travail, WBS. Un travail-
la liste de l'article est la description de chaque mission de programmation nécessaires pour remplir la fonction
spécification. Il doit être ventilé à un niveau de détail qui sépare les éléments de différente
niveaux d'importance, avec des estimations qui sont mesurés en jours (une frontière sur le travail à l'article
la taille devrait être défini, peut-être un jour ou une demi-journée, mais il est à la hauteur des programmeurs pour le définir).
La création de la liste des éléments de travail est tout à fait du domaine du programmeur, et il est à la
programmeur en chef, et peut-être le chef de projet, d'examiner et de désinfecter ces listes.
(Techniquement, les listes des éléments de travail ne sont pas les spécifications: ils sont le plan pour savoir comment Engineering
remplir les spécifications. Cependant, ils sont si importants et liés aux spécifications que je ne pouvais pas trouver un
meilleur endroit pour les introduire.)

Les critères de test et les critères de sortie d'étape . Comme la spécification de fonction se réunit, le test
critères devraient être créés. Ceci doit inclure des cas de test des priorités pour la nouvelle fonctionnalité,
avec des objectifs pour la façon dont le code doit effectuer sur ces cas pour répondre à la qualité
objectifs pour l'étape (aka critères de sortie, voir chapitre 15 ).

Permettez-moi de vous donner un exemple de la façon dont ces différents types d'informations de spécification peuvent être
combinée. Chaque fois que je travaillais sur une grande équipe avec de nombreux rôles spécialisés, il était courant pour écrire
à la fois fonctionnalité et les spécifications techniques. Nous aimerions tirons listes des besoins de la vision, l'examen
eux avec l'équipe et le client, puis les placer au début de la spécification de fonction.

Page 130

Listes des éléments de travail ont été générés par le programmeur (souvent dans un tableur d'équipe simple à l'échelle), et
copié ou liés dans la fonction spec. Nous finirions avec une spécification primaire qui inclus
la plupart des types d'informations de spécification vient d'être décrit.

La meilleure façon de penser à ces quatre types de spécifications est dans l'ordre chronologique approximatif:
exigences, articles option, techniques, et le travail. Comme beaucoup d'autres tâches du projet, chacun de ces quatre
types d'information fournit les bases pour la prochaine. Le plus grand de l'équipe et plus complexe
le projet, plus formalisé la division entre ces types de spécifications doit probablement
être.

7.2.1. Qui est responsable des spécifications?

Sur une grande équipe, PMS ou les concepteurs devraient être responsables de la fonction spec; les programmeurs
être responsable de la spécification technique. Ils doivent être écris ces choses, afin que quelqu'un lecture
les deux documents seront croire que les auteurs savent réellement les uns des autres et ont bavardé fréquemment. Souvent,
spécifications techniques sont beaucoup plus courtes (et moins généreux pour le lecteur) parce que leur public est
 plus petits, et les programmeurs ont tendance à ne pas être intéressé par écrit des choses qui ne compile pas. Toutefois,
la spécification technique d'appui les dessins de la fonction spec devrait correspondre.

Les analystes d'affaires, les clients ou les gestionnaires de projet écrivent souvent les documents d'exigences. Ça dépend de
qui a des exigences autorité et la nature de l'équipe du projet est (petite équipe de contrat, grand
équipe du personnel). Listes des éléments de travail sont la responsabilité de celui qui est la gestion de l'équipe de programmation.
Dans les grandes organisations, cela est généralement le programmeur en chef.

Sur de petites équipes, comme d'habitude, il est une affaire moins structuré. Il ne peut pas être des politiques strictes pour celui qui ne
ce qui, ou même quels documents doivent être écrits. Le gestionnaire de projet ou chef programmeur peut
aboutir à l'écriture d'un document unique qui est un ragoût inégale de ces quatre types d'informations, de sauter
entre eux pour répondre aux besoins immédiats de son équipe. Cela peut être très bien, pourvu que les gens obtiennent ce
ils ont besoin quand ils en ont besoin.

Page 131

7.3. Spécification ne conçoit

Les deux chapitres précédents ont défini un processus de conception de la façon de travailler avec les idées et les développer
dans les plans. L'importance d'un processus de conception définie est de séparer l'acte de la conception et
planification des travaux à partir de l'acte d'écrire une spécification pour elle. La création d'une spécification devrait,
autant que possible, être axé sur l'expression d'un régime existant ou un ensemble de décisions dans le meilleur possible
Ainsi, plutôt que de concevoir simultanément ce plan. L'moins il y a séparation entre ces deux
les choses, plus il est difficile d'atteindre l'un d'entre eux. Exécution d'une de ces procédés en soi est
assez difficile, et plus on essaie de faire les deux en même temps, plus les chances sont de faire
soit la tâche correctement.

Spec auteurs doivent être conscients des mentalités différentes de la conception et la spécification. Quand ils sont assis
pour écrire la spécification, ils doivent, pour le moment, arrêter l'exploration et la création et la concentrer sur
exprimer et expliquer. Ou, au moins, ils doivent planifier de revenir et fortement réviser la
document pour tenir compte de la voix d'un explicateur plutôt que d'un créateur. Chaque fois que la rédaction des spécifications
(Ou autre), il est important de se rappeler que la façon dont nous avons pensé que quelque chose est pas
toujours la meilleure façon de l'expliquer à quelqu'un d'autre.

7.3.1. Décrivant la conception finale contre la façon de construire

Alors qu'il est possible de combiner fonctionnalité et les spécifications techniques en un seul document, la plupart des
le temps dont ils ont besoin pour être sections séparées. Une des pires spécifications que je ai lu est tombé dans le
piège de faire ces deux choses à la fois. L'auteur, aussi intelligent et capable, comme il était, essayé de
décrire la conception tout en expliquant en même temps comment il serait construit. Dès que je l'ouvris
document, il était évident combien de temps il a dû passer sur elle. (3) Il avait fait grande et
méticuleusement fabriqués diagrammes montrant les relations entre les objets et composants, tandis que
les diagrammes simultanément en termes de comment ils allaient être utilisés par les clients. Le résultat était
 une belle et très raffiné catastrophe. La spécification était impressionnant, mais après cinq minutes de lecture
la chose et se débattant dans la frustration de donner un sens, je devais à l'envie de l'étrangler (et
Apparemment, son équipe a eu une réaction similaire). Il avait essayé à plusieurs reprises de marcher les gens à travers elle,
qui, malheureusement, n'a servi qu'à augmenter leur négative (et violents) latente réponses.

Dans une tentative pour aider, je parlais à l'écrivain de spec et a essayé de donner quelques conseils. Il a admis que
il avait perdu le focus et que la spécification elle-même était pas si important, mais il croyait encore son approche était
bien. Il a affirmé que parce qu'il savait que les programmeurs auraient besoin d'une référence à la fois pour le
le comportement et les détails de plus haut niveau des relations d'objet prévu, il était logique de combiner
tous ensemble. Mon opinion est que, même si une personne a besoin des deux types d'informations, il n'y a pas
raison de supposer qu'elle a besoin d'eux en même temps ou sur la même page. Souvent, il est plus facile d'écrire
et de lire à un seul niveau de la pensée, et de traiter avec l'histoire d'un niveau à un moment, que de
les combiner. Bonnes spécifications décrivent souvent la conception en couches: d'abord, ce que le
les expériences des clients décrits dans la langue du client; deuxième, un aperçu de haut niveau de base
objets et l'architecture; et la troisième, la couverture des questions de conception d'ingénierie complexes et détaillées.

7.3.2. Bonnes specs simplifient

La chose la plus difficile pour les personnes techniquement esprit à faire est de choisir efficacement qui détaille quitter
sur et à quel moment le faire. Ayant de nombreuses classes logiques et mathématiques terriblement complexes survécu, je
appris que les meilleurs enseignants savaient quand sauter non essentiel, bien que toujours important, les choses
et comment revenir à eux quand l'étudiant (ou le lecteur) était prêt pour eux. Lorsque spécifications sont
bien écrits, ils utilisent le même type de compétence. Les éléments essentiels viennent à travers. Les gens gagnent
la compréhension de l'œuvre et peut procéder à la clarté. Les modèles mentaux qu'ils avaient pour la façon dont les choses
seront construits sont plus raffinée après avoir lu la spécification et la qualité des questions, ils peuvent

Page 132

demander au PM ou d'autres sur l'équipe est améliorée. Recherchez cet effet. On n'a jamais tout le monde, mais
efforcer d'atteindre les importants contributeurs au projet.

Bien sûr, la complexité est inévitable pour un modèle d'objet complexe ou interface très détaillée.
Certaines choses pourraient prendre une explication et le temps de comprendre, mais soyez sûr que ce soit vraiment le
cas. Plus souvent, la complexité est une échappatoire qui cache écriture pauvres ou de la pensée médiocre. L'ensemble
Point à la rédaction du cahier des charges est de décrire les choses d'une manière qui minimise la quantité de travail
d'autres personnes auront à faire pour comprendre. Dans le pire des cas, il faudrait que quelqu'un
plus de temps pour comprendre la spécification que ce serait pour elle de concevoir la chose elle-même. Mais comme
la plupart des questions de l'écriture, ces critères sont très subjective. Tri le bon niveau de clarté
et la complexité appropriée est une question de jugement, et il est préférable de laisser place aux chefs d'équipe de décider.

Mais au nom d'essayer de décrire les choses bien, voici quelques conseils et choses à éviter en écriture
spécifications:

Emprunter de bonnes explications pour des choses d'autres caractéristiques (même si elles sont rédigés par des
d'autres personnes) . Utilisez hypertexte de manière appropriée et de saisir des aperçus utiles à partir du Web si
neededwhich devrait être encouragée par les dirigeants de l'équipe. Vous ne disposez pas d'inventer ou de décrire
tout.

Évitez le jargon et le langage obscur . Ne l'utilisez pas, sauf si vous êtes certain qu'il aide le lecteur,
ce qu'il fait rarement. Ou, mettre moins utilement, réduire l'obscurcissement probable de intentionnelle
question conceptuelle à travers la concision atténuée de macro-concepts dans désambiguïsé
transformations de connaissances et l'abrogation générale des assemblages linguales redondants.

Accrochez-vous à de vieilles spécifications . Ils font de bonnes références lorsque vous êtes coincé sur la meilleure façon
présenter un concept ou au schéma quelque chose. Quand vous voyez une bonne spécification quelqu'un d'autre
écrit, tenir à cela, aussi.

Avoir des lecteurs spécifiques à l'esprit lorsque vous écrivez . Même sur une équipe de 10 personnes, il y aura
probablement 4 ou 5 qui dépendra plus lourdement sur la spécification. Ajouter au mélange d'une personne intelligente vous
savoir, qui ne figure pas sur l'équipe et ne sont pas familiers avec la technologie particulière que vous utilisez. Comment
décririez-vous un concept difficile à lui?

Ne pas tomber en amour avec Visio ou organigrammes . Maintenir des relations platoniques avec tous les outils.
Habituellement, les schémas ne sont intéressantes que pour la personne qui les a faites, et ils sont souvent pas aussi
efficace pour aider le projet que leur créateur pense. Parfois, un bon paragraphe ou un
, croquis dessinés à la main bâclée est mieux qu'un 500-élément diagramme UML. (Juste parce qu'un
diagramme est la seule façon pour l'auteur de comprendre quelque chose ne garantit pas que ce soit le meilleur
façon de l'expliquer à quelqu'un d'autre.) Outils et diagrammes peuvent être de grandes choses, simplement de maintenir
l'objectivité à leur sujet.

Est-ce une référence ou une spécification? Spécifications ne doivent généralement être API complète
références ou décrivent chaque instance unique ou comportement possible. Il est tout à fait raisonnable
se concentrer sur l'explication des 10 ou 15 cas courants ou les plus importants et ont une distincte
document qui énumère de manière exhaustive le reste (avec moins de détails).

Avant de creuser, utilisez pseudo ou même l'anglais pour décrire des algorithmes complexes au
un niveau élevé . Comme mentionné précédemment, examiner comment une approche multidimensionnelle à l'explication pourrait être
le meilleur moyen de learneven pour des gens intelligents. Au minimum, de bons résumés et aperçus
aller un long chemin.
 Et voici un tour supplémentaire que je l'ai toujours trouvé utile: chaque fois que quelqu'un est confondu par
quelque chose dans un projet de votre spec (quelque chose que vous découvrirez que si vous parvenez à la corrompre pour
lire en premier lieu), prendre cinq minutes pour lui expliquer. Une fois, elle l'obtient, lui demander si il ya une
meilleure façon vous pourriez l'avez expliqué dans la spécification. Parfois, vous aurez de bons conseils et parfois
vous ne serez pas, mais votre compréhension sera toujours d'améliorer tout simplement parce que vous êtes vous forçant à
élargissez votre perspective. Chaque fois que vous demandez une autre personne, vous penser à l'particulier
le concept d'une manière légèrement différente, améliorer les chances de trouver une meilleure approche. Comme le spec
auteur, rappelez-vous que la bonne rétroaction vient plus facilement si vous le demandez que si vous attendez pour elle.

Page 133

7.3.3. Garantir le droit chose va se passer

Spécifications définissent un ensemble d'intentions. Ils font cette affirmation: «Si les choses se passent comme nous le prévoyons, lorsque nous
terminer ce travail, nous aurons ce qui est décrit dans ce document, "ce qui signifie que tous (ou raisonnablement
grand pourcentage) du comportement et la fonctionnalité communiquée dans une spécification de fonction doit
se manifester dans le code de travail finale quand tout est fait. Alors qu'il est tout à fait possible que le jour
après la spec est terminée, le monde peut changer, le jour où il est écrit dans l'intention demeure. Quand
le monde change, la spécification doivent être mis à jour pour refléter ce nouveau monde et nouvelle
intentionswhatever ils sont.

Au niveau de l'ingénierie, l'objectif d'un cahier des charges est alors de communiquer ces intentions à
tout le monde qui a besoin de faire usage d'entre eux. Pour les testeurs et assurance de la qualité, cela signifie avoir
suffisamment de précision pour le comportement attendu d'un projet d'écrire des projets de cas et les estimations test.
Marketing, la documentation et d'autres spécialistes sur le projet auront d'autres questions qu'ils
besoin de répondre à ce que le résultat final ne sera comme avant qu'ils puissent faire leur travail. Technique
soutien ou de compte les gestionnaires auront besoin de comprendre comment les choses fonctionnent afin qu'ils puissent soutenir, ou un plan
à soutenir, le travail.

Une des meilleures questions à poser gens après qu'ils ont lu une spécification est: "Avez-vous ce que vous
besoin de faire votre meilleur travail? "En mettant l'accent sur les lecteurs, leur intérêt dans cela va changer. Ils
va poser de meilleures questions et de mettre la spécification à utiliser, dans leur esprit, vers le vrai travail qui sera
suivre.

Page 134
 7.4. Qui, quand, et comment

Tout comme documents de vision, il est très important que les spécifications ont un auteur. Tout le monde qui est
va faire le travail devrait être de contribuer en faisant des commentaires et de l'ajout de contenu, mais on
personne a besoin de filtrer, façonner, et faire toutes ensemble. La raison en est simple: si vous
veulent la spécification de lire comme il a été écrit par un clair-pensée individuelle, vous ne pouvez pas avoir
différentes personnes possédant différentes parties du document. Tant que l'on comprend que l'auteur
il est son travail d'intégrer de bonnes contributions et suggestions de toute personne qui leur offre, des choses
devrait fonctionner très bien.

En supposant qu'il est un auteur primaire, les candidats probables pour le travail sont le chef de projet,
concepteur, ou programmeur en chef. Parce spécifications représentent la prise de décision inter-fonctionnelle, ils
devrait être écrit par la personne qui est le plus responsable des décisions à ce niveau. La fonction
spécification et la spécification technique sont obligés de correspondre et de renouer avec l'élément de travail
énumère l'équipe de programmation compilé. Si l'ingénierie et le design ont travaillé ensemble
tout au long du processus de conception, ce qui rend ces choses correspondent est simple. En prime,
travailler ensemble dès le début change la perspective sur le processus de spécification: il sera considéré comme un heureux
collaboration pour planifier le travail, plutôt que le début d'un processus de débat et de frustration.

Pour cette raison et d'autres, le travail de spécification devrait commencer au cours de la phase de conception. Comme
prototypes sont en cours et des idées explorées, petites décisions commencent à tomber sur le travail, et
rough-projets de documents de spécification peuvent commencer (et devraient être marqués comme les premières versions). Ils peuvent être
maintenu privé pendant un certain temps jusqu'à ce qu'il y est assez descriptif pour être de valeur à plus d'une personne. Dans
les conversations entre la gestion de projet, la conception, le marketing et la programmation, une lente mais
compréhension constante grandit sur ce que le bon design est, et la spécification devrait traîner ceux
discussions. Comme le processus de conception frappe le point dans le temps où il n'y a que deux grands
alternatives, la spécification devraient avoir une forte dynamique derrière elle. Avec seulement deux alternatives
sur la table, les spécifications peuvent minimalement inclure tous les éléments communs et les travaux de génie
requis dans les deux variantes (par exemple, un moteur de recherche qui est nécessaire pour les deux modèles), ainsi qu'un
fiche de haut niveau des grandes décisions restantes et leurs implications potentielles.

7.4.1. Ecrire pour un contre l'écriture pour beaucoup

Pour les gestionnaires de projet, les spécifications peuvent être un endroit idéal pour mettre des informations d'utilisation seulement
leur. Il ya souvent beaucoup de questions ou de problèmes de personnes différentes que la seule spec
document devient, à la surface, l'endroit le plus facile de suivre ces questions. Malheureusement, pour quiconque
mais le gestionnaire de projet, ce niveau de détail devient bruit. La lecture d'un cahier des charges ne devrait pas se sentir
comme lire le journal de travail de l'auteur (bien que, comme de nombreux scientifiques et ingénieurs, en gardant une
agenda de travail séparé peut vous aider à découvrir de bonnes idées). Le plus grand de l'équipe, et plus
rôles spécialisés, il ya, le pire ce problème peut être.

Cependant, l'une des fonctions importantes de la spécification est d'aider le Premier ministre directement. Parce qu'elle doit
organiser et diriger l'effort, le document sera probablement modifié et lu le plus souvent par elle que
par quelqu'un d'autre. La boîte de dialogue de journal comme que les surfaces dans la spécification a une fonction importante;
il peut y avoir dans le suivi de la valeur des bits spécifiques et détaillées des informations sur un projet. L'astuce consiste à
faire d'une manière qui ne masque pas le récit de base et les décisions de la spécification tente de décrire.

Ainsi, lors de la création d'une spécification, il faut prendre soin de séparer les services qui détaille seulement le PM
et ceux qui sont de valeur pour le reste de l'équipe. La façon la plus simple de le faire est de séparer
explications du comportement ou de la fonctionnalité de la spécification de problèmes ou des questions sur le courant
descriptions. Il pourrait y avoir une liste unique des questions en suspens à la fin de la spécification, qui est la
solution la plus simple.

Page 135

7.5. Quand les spécifications complète?

Pour tout programme de développement qui a une phase de planification, la rédaction et la révision des spécifications
est sa conclusion naturelle. En théorie, l'équipe devrait connaître la plupart des détails de ce qui sera construit
et comment il sera fait lorsque les spécifications sont complètes. Le projet est prêt à aller à pleine vitesse, et
l'équilibre du travail passe de planificateurs et aux concepteurs de programmeurs et testeurs.

7.5.1. Comment est-elle suffisante?

 Décider quand une spécification est complète est une question de jugement. Il ya toujours des problèmes persistants et
questions ou des dépendances sur d'autres entreprises et des projets qui ne sont pas complètement triées
eux-mêmes encore sorti. Le timbre "spec complète" d'approbation peut signifier des niveaux très différents de
exhaustivité et la qualité en fonction du projet et de l'équipe. Il n'y a pas de bonne ou mauvaise:
parfois le risque de spécifications les plus faibles est compensé par le calendrier pression ou d'autres
considérations. Tout comme tout autre aspect de haut niveau d'un projet (qualité du code, de la stabilité,
performance), seul le jugement des chefs d'équipe peut décider le bon niveau de l'investissement. Et de
Bien sûr, plus la stratégie itérative de l'ingénierie générale est, le plus de flexibilité Il y aura probablement
être dans la façon dont les spécifications sont écrites.

Mais comme une règle universelle, plus la spécification est élevé, plus la probabilité sera d'un
résultats en temps voulu. La question est alors combien probabilité avez-vous besoin? Vaut-il le temps
faut pour faire une spécification 5% de mieux? Ou bien les programmeurs ou PM ont compris ceux
détails dans le cours naturel de faire le travail? Il n'y a pas de réponse facile. Vous cherchez à tout donné
spécification, je dois utiliser mon propre jugement. Je pense qu'il faut de l'expérience du projet, plus que
programmation ou de l'écriture, de faire cet appel.

Toutefois, le point important est que peu importe quel niveau de complétude est attendue avant la
spécifications sont considérées comme terminées, le seul moyen d'y parvenir est par le processus d'examen. Car
il est très subjective et comparative, la seule façon d'obtenir des caractéristiques d'une certaine qualité est d'avoir l'équipe
dirigeants (et les consommateurs) de spec examen et améliorer les informations sur eux. (Je vais vous décrire ce processus dans le
section suivante.)

7.5.2. Comment gérer les questions ouvertes

Peu importe la façon dont une équipe gère le processus de conception, il y aura toujours des questions non résolues
pendant l'écriture spec. Si ces questions ne sont pas gérés correctement, attend en cas de catastrophe. Beaucoup de mi-projet
catastrophes sont les descendants des questions de spec malveillante ou négligés. Il est essentiel que le PM prendre
initiative dans la collecte et l'examen de ces questions, de pousser l'équipe à les reconnaître dès le début.
Ceci est un défi difficile pour le SPM moins expérimentés, car ils seront donc consommés par d'autres spec-
écrit tâches qu'ils ne seront pas donner bon moment pour ouvrir-question de gestion. Souvent, il faut être
mordu par un problème tard dans un projet visant à reconnaître la valeur de début de suivi des problèmes.

Une gestion efficace des questions ouvertes est purement propos diligence. Quelqu'un doit à la fois enquêter
les problèmes potentiels et de prendre le temps de les écrire. Il n'y a pas de magie ici. Une fois qu'ils sont
écrit, ils peuvent être hiérarchisées, affectés, et résolus; mais si personne ne prend le temps,
la prévention des problèmes majeurs sera une question de chance, pas d'habileté.

En supposant que vous ne le suivi des problèmes d'une certaine façon, même si elle est juste une liste sur votre tableau de bureau, voici
quelques questions de base pour aider à prioriser et de les affiner:

Quand cette question doivent être résolus? Qui est la meilleure personne pour prendre les décisions
nécessaire pour le résoudre?

Page 136

La question peut être isolé d'une certaine façon, peut-être à un composant ou un scénario spécifique? Ou faut-il
impact sur la totalité de l'élément ou un projet?

Quelles sont les résolutions possibles pour le problème qui sont encore à l'étude? (Pour
exemple, nous allons utiliser ASP ou PHP, mais pas JSP.) Comment chaque impact alternative, le
spécification?

Peut-on réduire ce problème? Comment ça incidence vraiment le client dans notre scénario de l'utilisateur prioritaire 1?

La question peut être divisée en plus petites questions qui peuvent (doivent) être déléguées à d'autres personnes?

Qui ou ce qui bloque la résolution de cette question, et sont les efforts déployés pour résoudre le
bloquer? (Cette résolution peut être technique ou politique.)

Si il ya beaucoup de grandes questions et il est difficile de les diviser, quelque chose a mal tourné, et la
processus de conception et / ou la direction de l'équipe a échoué. Le moyen de sortir du problème est au-delà de la portée de
la gestion en plein question. (Voir Chapitre 11 ).

7.5.2.1 Combler le fossé spec

Si vous gérez bien des questions ouvertes, il est possible de combler les écarts de calendrier en faisant estimations sur la façon
ces problèmes seront résolus. L'idée de base, souvent cyniquement appelée «shot-Gunning," est
illustré dans la Figure 7-1 . Si cela est fait correctement, une spécification peut être examiné et apprécié
Spec-complète sur le temps, même si il ya encore des problèmes de conception non résolus. Shot-Gunning fait
introduire risques: vous estimer à quel point l'équipe permettra de résoudre les questions en suspens, au lieu de
attente pour l'équipe de réellement les résoudre toutes. Cependant, il est pas nécessairement un déménagement à haut risque. Ce
Tout dépend de comment bien compris les enjeux et comment bien les hypothèses sont qui ont
été faite à leur sujet. Envisager, si vous voulez, deux équipes. L'équipe A a une longue mais bien comprise
la liste des questions. L'équipe B a un petit mais mal compris la liste des questions. Quelle équipe pensez-vous
 très probablement rencontrer ses dates? Je serais prêt à parier sur l'A-Team (jeu A-team thème de la musique). Si rien d'autre,
scepticisme dicte que la liste des petits problèmes de l'équipe B implique qu'ils ont pas trouvé la totalité de leur
spec encore des questions. L'équipe A a passé plus de temps à comprendre leurs questions ouvertes et est mieux
préparé pour tous les défis que le projet tient pour eux.

Figure 7-1. Combler l'écart de conception / spécification.

Il est important de noter que la fermeture de l'écart ne signifie pas abandonner le travail de conception nécessaire pour
finaliser ces décisions. Cela signifie que le PM tente de prendre du recul pendant un moment et soigneusement faire
jugement appelle à un souci de maintenir éventuellement le calendrier.

Pour aider à combler l'écart, examiner les questions suivantes pour chaque question ouverte:

Y at-il des éléments de travail qui devront être fait indépendamment de quelle alternative est choisie? Dans l'affirmative,

Page 137

ils doivent être estimés et ajoutés à la spécification. Si nécessaire, ces éléments de travail peuvent être démarrés
avant la spécification est finalisé.

Peuvent le PM ou le concepteur résoudre ce problème? La fermeture de cette question se traduira par de nouveaux travaux
articles? (Par exemple, il peut être possible de travailler en parallèle avec le programmateur à partir de la
compris des éléments de travail, tandis que le PM entraîne la question ouverte à la résolution.)

Quelles sont les alternatives possibles pour résoudre ce problème qui sont toujours en considération?

Parmi les alternatives probables, ce qui est le plus cher? Considérons l'estimation des éléments de travail
sur la base de cette approche, et de faire la spécification et élément de travail liste dans un pire cas de conception
plan.

Est-ce un élément central ou noyau? Quand le programmeur besoin pour mettre en œuvre ce? Pouvoir
cet être conçu par la suite pendant la phase de mise en oeuvre? Est-ce quelque chose que nous savons quelques autres
composants sont dépendants?

Ce problème peut être contenue, rétréci, divisée, ou coupé? Dans le cas contraire, il bosse à la partie supérieure de la priorité
liste.

Combler le fossé ne peut pas toujours être fait avec succès. Il est possible que vous ferez une poussée solide et
progresser les choses avant, mais toujours trouver que vous êtes trop loin. Même ainsi, le pousser à fermer n'a jamais fait mal.
Équipes inexpérimentées ont souvent besoin de ce genre de pression pour les forcer à faire face à toutes leurs questions
(Techniques et autres), et les gestionnaires pourraient ne pas bien comprendre la complexité de ce qui reste
jusqu'à ce que cela arrive. Un bon argument peut être fait pour combler l'écart de manière proactive, au lieu d'attendre
jusqu'à ce que le calendrier est à risque.

7.5.3. La signification de frapper spec complète

Il devrait y avoir une date sur le calendrier du projet pour frapper spec complète, et il est peut-être le plus
date importante pour les GP en tant que contributeurs individuels au projet. Souvent, l'écriture de la
spécification est leur primaire, ou peut-être seulement, livrable littérale significative au projet. Une fois
spécifications ont été achevés, l'accent de la PM se déplacera vers le guidage et la tête du projet,
y compris en aidant la transition de l'équipe en plein développement.

Après spécification complète, il devrait y avoir un changement de la psychologie et de l'attitude de l'équipe de projet. La
sentiment devrait être que pour l'étape actuelle, les préliminaires sont terminés et que beaucoup de
des décisions difficiles ont déjà été faites. L'équipe a connu des grands défis à
déterminer les bonnes conceptions et de tri à travers les nombreuses possibilités de réaliser la vision de
trouver un plan cohérent. Il est à l'heure pour vous assurer que tout le monde impliqué dans l'effort à ce jour
a une partie de cette perspective et a reconnu son travail.

NOTE
 Face à face est la meilleure façon de dire aux gens que vous appréciez leur travail. Ne comptez pas sur une
e-mail à toute l'équipe pour signifier beaucoup à tout le monde. Aller de porte-à-porte ou les appeler au
téléphone. Une courte conversation a un poids plus émotionnelle que tout e-mail.

Bien que les événements de moral et entretiens de dynamisme sont difficiles à bien faire, il devrait y avoir un certain genre d'équipe à l'échelle
reconnaissance pour le travail accompli à ce jour. Il est souvent des choses simples qui fonctionnent le mieux: un après-midi,
un long déjeuner au soleil, ou une semaine de bières ou des collations gratuites dans la salle de café. Une sorte de positif
briser la routine (par exemple, sortir du lieu de travail) est la meilleure façon d'aider les équipes de transition et
recharger en préparation pour les différentes pressions auxquelles ils seront confrontés dans les semaines ou mois à venir.

Page 138

7.6. Avis et commentaires

Les plus grandes personnes d'erreur font avec des spécifications est en attente jusqu'à ce qu'un processus d'examen formel prend
placer pour obtenir des commentaires sur son contenu. Avis devraient être utilisés pour confirmer et d'affiner, de ne pas faire une
premier passage et une décision finale dans le même temps. Ceci est une autre raison pour laquelle un processus de conception est si
Important: cela signifie que les décisions de conception ont eu de nombreuses itérations, et les auteurs ont eu beaucoup
de chances d'intégrer de bonnes suggestions. Les chefs d'équipe doivent y arriver en étant
disponible pour commentaires informelles antérieures et en faisant les projets de spécifications disponibles sur l'intranet. Mais
cela ne veut pas dire que l'examen des spec réunions devraient être une partie de plaisir; tout le monde devrait marcher dans la
processus d'examen avec une idée très claire de ce qui est attendu d'elle.

Il ya différentes façons de réviser les spécifications, mais la plupart d'entre eux impliquent une réunion où le
le document est lu ou discuté à la satisfaction de quelqu'un. Comment formel ou informel de cette réunion est
dépend fortement de la culture de l'équipe, l'attitude des chefs d'équipe, et la nature de la
projet. Mais cependant, il est fait, l'objectif est de répondre aux deux mêmes questions: "Est-ce cahier des charges
suffisamment détaillé pour nous guider à travers le développement? »et« Est-ce que le résultat satisfaire aux exigences
et les objectifs de cette partie du projet? »Il ya certainement beaucoup plus précise des questions à poser, mais
ils dérivent tous de ces deux les clés. Le processus d'examen doit viser à y répondre
en toute confiance.

7.6.1. Comment examiner une spécification

L'examen d'une spécification devrait être un processus d'équipe. Alors que le centre de l'attention est le document
et les gens qui l'ont écrit, l'objectif devrait être de confirmer que tout le monde qui doit faire le travail
d'accord avec ce qui est dans le document. Le moyen le plus simple et le plus rapide de le faire est par tous obtenir
ensemble dans une pièce afin qu'ils connaître toutes les réponses à toutes les questions qui sont posées. J'ai vu
avis de spec faites par courriel ou par conférence téléphonique, et je ne peux pas dire que je suis heureux avec les résultats. Dès que
comme une question litigieuse est venu, je souhaitais étions dans la même chambre avec l'équipe afin que je puisse utiliser
tableaux blancs ou des gestes de la main pour expliquer les choses en temps réel. Le plus complexe de la spécification, la plus
vous voulez que les gens dans la salle. (Si vous êtes obligé de travailler pratiquement, et de croire tout le monde doit être en
sur l'examen, le faire en petits groupes de trois à cinq. Pour les tâches complexes comme la révision des spécifications,
des conférences téléphoniques et des conférences vidéo avec les grands groupes deviennent rapidement tragi-comédies.)

Un bloc d'une ou deux heures de temps doit être réservé à une salle de conférence de taille moyenne plusieurs jours
l'avance. Si la spécification est prêt pour l'examen (tel que déterminé par l'auteur, avec les conseils de critères
défini par les chefs d'équipe), il devrait sortir dans le cadre de la réunion inviter. Autant que je me souvienne,
Je suis capable de faire cela seulement une poignée de fois. Le plus souvent, je ai réservé la réunion une semaine ou deux dans
avancent et tout le monde informés qu'ils recevraient le document par courrier électronique 24 heures avant l'examen de la spec
rencontrer. Certaines personnes haïssaient, mais je l'ai appris est le moyen le plus efficace de fournir une
mis à jour le document et amener les gens à lire. Avec l'alerte précoce, les gens peuvent planifier temps dans cette
Période de 24 heures à lire la chose.

De la même façon, je pense qu'il est juste d'exiger que les participants à l'examen de la spec doit lire
avant qu'ils apparaissent. Par la sélection naturelle, les gens qui ont vraiment besoin de le lire trouveront le temps de le faire
parce que ce sera l'une des choses les plus importantes qu'ils font. Peu importe ce qu'ils disent, si
ils peuvent honnêtement pas trouver le temps de parcourir au moins le document pour des problèmes flagrants, le travail est pas
une priorité pour eux et ils ne font pas dans la salle.

Chaque fois que je eu le pouvoir de le faire, je fait spécifications de lecture avant la réunion une règle pour l'ensemble
équipe. Cela garantit deux choses. Tout d'abord, il réduit le nombre de personnes qui se présentent aux seules personnes
qui ont vraiment besoin d'y assister. Les chances d'une salle comble remplis de nitpickers sans importance vont chemin vers le bas.
Deuxièmement, la réunion d'examen sera beaucoup plus rapide car tout le monde commence à une profondeur similaire
compréhension. Les gens qui ne lisent pas le cahier des charges aura tendance à se démarquer sur la base du
questions qu'ils posent. Si leurs questions sont valables, ils devraient être considérés, mais si elles sont bien
couverte dans la spécification, il est juste de leur demander de lire cet article et le suivi avec l'auteur de spec après
Page 139

la réunion.

7.6.2. Qui devrait être là et comment fonctionne-t-il?

Il devrait y avoir au moins une personne de chaque rôle majeur dans la salle (programmation, tests, etc.),
ainsi que tous les autres grands rôles contributifs (affaires, conception, documentation). Avis doivent être ouverts
à toute l'équipe: si les testeurs ou les programmeurs se sont intéressés à la spécification, et a pris le temps de lire
, ils devraient être invités à assister, même si elles ne fonctionnent pas sur la fonction spécifique. Les chefs d'équipe
devrait être invite en option, et il est à eux de décider si ils ont besoin pour participer à la
rencontrer. Si ils font bien leur travail, ils peuvent savoir assez de détails pour assister seulement à la
la plupart des contentieux avis de spec. D'autre part, si elle est une équipe inexpérimentée, ils peuvent avoir besoin de
assister à chaque réunion.

La réunion proprement dite devrait être dirigé par le Premier ministre (ou spec auteur). Le processus est simple: réponse
des questions. Si il n'y a pas de questions (par exemple, Fantasyland), et les bonnes personnes sont dans la salle et sont
heureux avec la spécification, l'examen se termine. Quelques GP aiment faire soluces du prototype final,
ce qui est bien. D'autres préfèrent marcher à travers le document section par section. Personnellement, je pense que ce
est une perte de temps (si je l'ai écrit un bon Spec, et tout le monde l'a lu, pourquoi passer par l'ensemble
chose?), mais certaines équipes comme elle, afin de l'utiliser tout ce qui fonctionne. La seule chose importante est que les gens sont
engagés dans une saine discussion, poser les bonnes questions, et de travailler ensemble pour arranger les choses.

Pour toute question soulevée, il est à la hauteur des gens dans la salle pour discuter de la réponse à la question
la satisfaction de demandeur ou d'ajouter un nouvel élément à la liste des questions ouvertes dans la spécification. Lorsque les questions se terminent,
PM examine la liste des questions ouvertes (un tableau blanc dans la salle de conférence fonctionne bien pour l'inscription de nouvelles
articles) et décide si il ya quelque chose digne de tenir une autre discussion de révision. Si rien
atteint cette barre, la spécification est réputé en revue, en attendant l'enquête et la résolution de ces nouveaux
questions ouvertes.

Après l'examen de la spec est terminée, le PM devrait avoir un calendrier pour répondre à de nouvelles questions ou
questions soulevées lors de la réunion. Immédiatement après la réunion, tout le monde qui a été invité à assister à
devraient recevoir un e-mail avec un court résumé des questions ouvertes, une date de la prochaine révision (si l'on
était prévu), et un calendrier pour quand les questions en suspens doivent être résolues. Ceci est particulièrement
Important Si le blocs de question ouverte une autre personne de l'équipe de faire son travail. En fait, le blocage
questions devraient être appelés lors de la revue de spécifications et d'une attention particulière.

7.6.3. La liste des questions

Il ya des questions qui doivent être posées dans chaque réexamen spec sur la base des choses communes
Les gens ont vu vont mal au fil des ans. Même si poser des questions difficiles ne trouve pas spécifique
questions, ils font forcer l'équipe à penser plus critique sur ce qu'ils font. Rappelez-vous, cette
est pas un examen final: il est OK pour tout le monde de savoir ce que les questions seront avant qu'ils apparaissent. Il est
dans votre intérêt de vous assurer tout le monde se promène dans l'examen préparé.

Parce que la conception et la rédaction de spécifications sont des processus optimistes, il est à la hauteur des personnes à l'examen pour être
sceptiques et sonde pour des choses qui auraient pu être négligés. (Veillez à ne pas être méchant. Etre
critique ne nécessite pas de sortir de votre façon d'être cruel ou de rendre les gens se sentent mal. Si une équipe est
terriblement sous préparé pour avis de spec, la responsabilité est souvent autant sur les dirigeants de l'équipe que
les individus). Même si l'équipe connaît les bonnes questions, quelqu'un doit pousser et de faire creuser
assurer que les vraies réponses sortent.

Voici ma liste, mais je vous encourage à réviser ces questions et d'ajouter votre propre:

Est-ce que la liste du programmateur d'éléments de travail correspond à la spécification? Comment chaque composante majeure
les spécifications se rapportent à chaque élément de travail? Lorsque, dans la conception est le plus probable que nous trouverons
vis à vis des éléments de travail?

Comment est cette conception les plus susceptibles de se briser? Quels sont les composants ou les interfaces les plus faibles? Pourquoi

Page 140

ne peuvent-ils être améliorés?

Quel est l'aspect le plus fort de cette conception? Quelle est la plus faible? Que sommes-nous plus et les moins
confiant sur? Sont notre force et la confiance centrés autour de la plus importante
composants?

Avons-nous le bon niveau de qualité? Sera-ce aussi fiable, performant, et utilisable comme notre
exigences de la vision du projet? Les estimations de test sont-elles réalistes?

Pourquoi pas une conception plus simple mieux? Avons-nous vraiment besoin de cette grande complexité ou la fonctionnalité?
Quelle preuve avons-nous quel argument ou sonore peut être fait de ne pas faire cette simple?
 Qu'est-ce que les dépendances
autres spécifications ne possède
qui pourraient échouercette
d'uneconception? Y endommage
manière qui at-il des technologies,
ou interditles
ce entreprises, les projets, ou
travail? Avons-nous
des plans d'urgence?

Quels éléments de la conception sont plus susceptibles de changer? Pourquoi?

Avez-test, la documentation, le marketing, et tous les autres rôles spécialisés affectés à ce projet ont
toutes les informations dont ils ont besoin pour faire leur meilleur travail? Quelles sont leurs principales préoccupations, et comment allez-
ils être traités? Ou y at-il des raisons que nous ne pouvons les ignorer son?

Quels sont les PM de, programmeur, et les principales préoccupations de testeur avec cette spécification? Avec ça
en vedette?

Y at-il des occasions de partager ou emprunter le code avec d'autres fonctions en cours de construction pour ce projet?

Avons-nous atteint nos exigences d'accessibilité et de localisation pour l'interface utilisateur?

Quels sont les risques pour la sécurité de cette conception? Pourquoi faut-il pas de sens pour les éliminer? Etes-
ils documentés dans la spécification, y compris les remèdes potentiels (à savoir, les modèles de menaces)?

Avons-nous des preuves crédibles indiquant que les utilisateurs spécifiés peuvent utiliser cette conception d'interface utilisateur pour
succès font ce qu'ils doivent faire?

Page 141

7.7. Résumé

Specs devraient faire trois choses: veiller à ce que le bon produit est construite, fournir un calendrier
jalon qui conclut une phase de planification d'un projet, et de permettre une révision profonde et évaluations
d'individus différents au cours du projet.

Caractéristiques résoudre seuls certains problèmes. Les chefs d'équipe doivent être clairs sur quels problèmes ils sont
essayer de résoudre avec des spécifications, et les problèmes doivent être résolus par d'autres moyens.

Bonnes specs simplifient. Ils sont essentiellement une forme de communication.

Spécification est très différente de la conception.

Il devrait y avoir une autorité claire pour qui écrit et a le contrôle sur la spécification.

Combler le fossé est une approche à la gestion des questions ouvertes et d'accélérer la fin de la
processus de spécification.

Un processus d'examen est la façon la plus simple de définir et de contrôler la qualité spec.
Page 142

Le chapitre huit. Comment prendre les bonnes décisions

Dans le processus d'écriture de ce livre , je interviewé plus d'une douzaine de gestionnaires de projet. Un des
les questions que je leur ai demandé était de savoir comment prendre de bonnes décisions. Leurs réponses inclus des choses comme
pesée des options, la définition des critères, et la recherche de différents moyens de résoudre la situation en main.
Mais quand je leur ai demandé combien de décisions ils ont fait un jour, et combien de fois ils ont utilisé les
techniques qu'ils nommés, ils ont souvent réalisé que quelque chose clochait. Beaucoup admis (après avoir regardé
sur leurs épaules pour vous assurer que personne d'autre ne entendre) qu'il était impossible de toujours suivre
tout processus formalisé pour prendre des décisions, étant donné le peu de temps qu'ils avaient et le nombre de
les choses dont ils avaient besoin de se faire.
 Au lieu de de
projection cela, ils ont concédé
la question que, contre
immédiate souvent,
lesils travaillent
grands sur du
objectifs l'intuition, hypothèse
projet. Si raisonnable,
ils le peuvent, ils vontet un rapide
réappliquer logique utilisée pour des décisions antérieures ou de faire usage de l'expérience de projets antérieurs. Mais comme
raisonnable que cette réponse sonnait chaque fois que je l'ai entendu, le gestionnaire de projet et je l'ai trouvé
quelque chose de décevant à ce sujet. Je pense que nous voulons tous croire que toutes les décisions sont prises avec soin
et la considération, même si nous savons qu'il ne peut absolument pas être ainsi. Il est temps limité et limité
la puissance du cerveau, et non pas tous les décisions peuvent être prises aussi bien.

Spécifique à la gestion de projet, je pense que les échecs dans le processus décisionnel se produisent le plus souvent pas
parce que le décideur était faible d'esprit ou inexpérimentés, mais tout simplement parce qu'il a investi son
l'énergie mal dans l'ensemble des différentes décisions qu'il avait à faire. Il ya une prise de décision de méta
processus de décision qui les décisions d'investir temps et énergie dans. Il faut l'expérience et de la
volonté d'examiner des erreurs et apprendre d'eux pour obtenir mieux à ce niveau plus élevé de décision-
décision. (Différents types de formation peut être fait pour développer ces compétences, (1) mais je ne l'avez jamais vu ou
entendu parler d'eux en tant que composants de base de toute science informatique ou programme de gestion de projet.)

Il est la capacité de prendre des décisions efficaces qui explique comment certaines personnes peuvent gérer cinq fois
beaucoup de travail (ou des personnes) que les autres: ils se divisent instinctivement travail en morceaux significatifs, trouver le
les décisions et les actions qui ont le plus d'influence, et qui investissent leur énergie dans ces décisions

Page 143

aussi bon que possible. Pour les décisions qu'ils doivent investir moins de temps dans, des erreurs ou des problèmes causés
par eux devrait être plus facile de se remettre de que les erreurs qu'ils auraient faites dans importante
décisions.

Il est curieux alors que lorsque "les compétences de décision" sont enseignées dans les universités, les étudiants sont en général
apprendre les méthodes de la théorie de l'utilité ou de l'analyse d'arbre de décision: processus où les choix sont affectés
les valeurs et les calculs numériques sont faites contre eux (analyse coût-bénéfice est un autre
méthode couramment enseigné). De nombreux programmes de MBA d'études (2) et une certaine gestion de projet
certifications comprennent ce genre de formation. Mais peu de couverture est offerte pour les décisions de niveau supérieur ou
d'autres considérations pratiques de prise de décision en dehors de la salle de classe. Des méthodes telles que la décision
analyse de l'arbre exiger la quantification de tous les éléments, ce qui fonctionne bien pour exclusivement financièrement
décisions fondées, mais est un tronçon de la conception, de la stratégie ou les décisions organisationnelles. Comme souvent
cas, de nombreux facteurs et points de vue différents doivent être considérés pour prendre des décisions de bons projets,
et aucune méthode formelle Je les ai vus tous les intègre véritablement.

Il est donc pas surprenant que des gestionnaires de projet, je interrogés, très peu ont eu une formation formelle
dans la prise de décision, et de ceux qui ont, peu pensaient qu'ils utilisaient souvent. Cette observation anecdotique
correspond à ce que Gary Klein a écrit dans son livre, Sources of Power: Comment les gens prennent des décisions (MIT
Press, 1999): «... être sceptique des cours sur les méthodes formelles de prise de décision qu'ils enseignent.
Méthodes gens utilisent rarement. "Klein continue à expliquer les nombreuses façons que compagnie aérienne qualifiés
les pilotes, les pompiers et les infirmières de traumatologie à prendre des décisions, et combien il est rare que les méthodes officialisé
dans les manuels sont utilisés pour faire avancer les choses. Cela ne signifie pas que ces méthodes sont mauvais, juste que
les manuels fournissent rarement des preuves au sujet de qui utilise les méthodes ou comment elles sont réussies,
par rapport à d'autres techniques.

Tout comme les gestionnaires de projet, Klein observé que ces professionnels qualifiés ont rarement assez
informations ou de temps pour faire ces méthodes fonctionnent décision. Au lieu de cela, ils ont quatre choses:
l'expérience, l'intuition, de la formation, et de l'autre. Ils font de bonnes décisions en maximisant les
ressources. Dans certains cas, comme avec les pilotes de chasse ou les étudiants en médecine, la formation est conçu avec
cela à l'esprit. Au lieu de mémoriser des procédures ou des théories idéalisées cours de la formation, l'accent est
placé sur le développement de l'expérience grâce à des simulations de problèmes et défis communs.

Dans ce chapitre, ma couverture de la prise de décision se concentre sur trois aspects: comprendre ce qui est en
jeu, de trouver et de pesée des options (si nécessaire), et en utilisant correctement les informations.
Page 144

8.1. Dimensionnement jusqu'à une décision (ce qui est en jeu)

Tout ce que vous faites chaque jour est une sorte de decisionwhat temps de se réveiller, de quoi manger pour le petit déjeuner,
et à qui en parler d'abord au travail. Nous ne pensons pas souvent de ces décisions que parce que les conséquences
sommes si petits, mais nous sommes toujours à faire des choix. Nous avons tous nos propres jugements naturels pour qui
décisions dans nos vies exigent plus de considération, et le même genre de logique vaut pour projeter
les décisions de gestion. Certains choix, comme l'embauche / licenciement des employés ou la définition des objectifs, auront
ramifications qui durent des mois ou des années. Parce que ces décisions auront une plus longue et plus profonde
l'impact, il est logique de passer plus de temps compte tenu des choix et de la pensée à travers leur
différents compromis. Logiquement, les décisions plus petits ou moins importants méritent moins d'énergie.

Ainsi, la première partie de la prise de décision est de déterminer l'importance de la décision à portée de main. Beaucoup de
le temps, nous faisons cela de façon instinctive; nous répondons à la question et d'utiliser notre jugement personnel. Suis-je
confiant que je peux prendre une bonne décision sur place, ou dois-je besoin de plus de temps pour cela? Il souvent
ne prend que quelques instants pour régler cette question. Toutefois, cela est précisément là où beaucoup d'entre nous heurtons à
ennuis. Ces instincts pourraient être guidés par les facteurs bonnes ou mauvaises. Sans prendre le temps, au
moins maintenant et puis, de le décomposer et évaluer les morceaux qui conduisent à cet arrêt, nous ne faisons pas
vraiment savoir ce que les préjugés et les hypothèses susceptibles d'être conduit notre pensée (par exemple, désirant une promotion
ou de protéger une caractéristique des animaux de compagnie).

Avec cela à l'esprit, voici les questions fondamentales à utiliser dans le dimensionnement jusqu'à une décision. Cette liste peut être utilisé dans
le moment pour aider à la taille jusqu'à une décision spécifique, ou comme un moyen de réévaluer vos critères de haut niveau pour
jaugeant décisions.

Quel problème est au cœur de la décision? Les décisions se posent souvent en réponse à la nouvelle
informations, et la façon initiale, la question est soulevée se concentre sur les aspects aigus et étroites de
le problème. Donc, la première chose est de demander à des questions de sondage et de descendre à la véritable décision
qui doit être fait. Par exemple, le problème peut être défini d'abord comme «Nous ne disposons pas
le temps de corriger tous les bugs connus 50 que nous avons trouvés, "mais la vraie question est probablement« Nous avons pas de critères
pour savoir comment trier les bugs. "Redéfinir le problème, et la décision, en une forme plus utile va
un long chemin vers l'amélioration de la qualité des décisions. Être patient et calme en réponse à une
apparemment question urgente contribue en général à rendre cela possible. Posez des questions comme: Quelle est la
cause de ce problème? Est-il isolé ou sera l'impact sur d'autres domaines? Dont le problème est-il? Laquelle
buts dans la vision qu'il ne mettent pas en danger? Avons-nous fait déjà cette décision dans la spécification ou
vision, et si oui, nous avons de bonnes raisons de reconsidérer maintenant?

Combien de temps cette décision aura un impact sur ​le projet? Quelle est la profondeur de l'impact sera? Un gros
décision, comme le sens de la vision ou la technologie à utiliser, aura un impact sur l'ensemble de
projet. Une petite décision, comme ce moment pour avoir une réunion ou ce que l'ordre du jour devrait être,
aura un impact sur un petit nombre de personnes d'une manière limitée. Si il est une décision à long terme, et de la
impact est profond, la patience et la rigueur sont nécessaires. Si il est une décision à court terme avec une faible
l'impact, aller pour la vitesse et la clarté, basé sur une idée claire des décisions stratégiques prises dans le
vision. Généralement, il est préférable de prendre de grandes décisions dès le début ou dans une phase donnée d'un projet, de sorte
ils peuvent être réalisés avec la pensée du patient et l'examen, au lieu de quand le temps est compté.
(Ceci est similaire à quelques-unes des considérations exposées dans le chapitre 2 ).

Si vous vous trompez, ce qui est de l'impact / coût? Quelles autres décisions seront touchés comme un
résultat? Si l'impact est faible ou négligeable, alors il n'y a pas grand chose à perdre. Toutefois, cela ne
dire que vous devriez commencer retournement des pièces de monnaie. Pour les aspects des projets tels que la facilité d'utilisation ou la fiabilité,
qualité provient de nombreuses petites décisions étant alignés les uns avec les autres. L'expression «mort par
milliers " (3) vient de cette situation, où il est pas une grosse erreur qui vous fait; il est le
de nombreux minuscules. Donc, vous devez au moins demander si le choix est vraiment isolé. Dans le cas contraire,
il est préférable d'essayer de faire plusieurs choix à la fois. Par exemple, soit suivre la même conception de l'interface utilisateur
des lignes directrices sur toutes les pages, refactorisons tout le code qui utilise la même API, ou coupés ces caractéristiques
complètement. Obtenez autant de kilométrage que possible sur chaque décision que vous prenez.

Page 145

Qu'est-ce que la fenêtre d'opportunité? Si le bâtiment est en feu, peu importe la complexité
choisir votre itinéraire de fuite pourrait être, il ya seulement un certain laps de temps que votre décision
aura de l'importance. Si vous attendez trop longtemps pour prendre la décision, il sera fait pour vous; routes vont fermer
et toutes les options vont disparaître éventuellement. La façon dont fonctionne l'univers est que les grandes décisions ne sont pas
nécessairement venir avec de plus grandes quantités de temps pour les faire. Parfois, vous avez à faire
décisions stratégiques difficiles rapidement en raison de la fenêtre d'opportunité limitée que vous avez. Et
parfois, la vitesse de prise de décision est plus important que la qualité de la décision
lui-même. (4)
 Avons-nous fait ce genre de décision avant? Ceci est le test de l'arrogance. Si je vous mets dans un
salle d'urgence avec un patient se tortillant sur la table d'opération et vous a demandé d'effectuer
chirurgie de pontage cardiaque, quelle confiance seriez-vous? Il n'y a pas de honte à admettre l'ignorance:
il faut généralement courage de le faire. Si vous travaillez sur quoi que ce soit difficile ou tranchant,
il y aura des moments où vous avez aucune idée de comment faire quelque chose. Ne pas cacher cette (sauf si vous êtes
vitesse sur la qualité de la décision en question le choix), ou laisser quelqu'un d'autre le cacher. Au lieu,
identifier ce que vous pensez que l'équipe, ou vous-même, est inexpérimenté avec ce genre de choix et la puissance
besoin d'aide extérieure, ou plus de temps pour réfléchir à cette question. Si un dirigeant ou gestionnaire admet
à l'ignorance, elle rend OK pour tout le monde dans la salle pour faire la même chose. Soudainement,
faire pour l'ensemble de l'équipe décision permettra d'améliorer de façon spectaculaire parce que les gens sont enfin
honnête.

Qui a le point de vue d'expert? Est-ce vraiment ma décision? Tout simplement parce que quelqu'un demande
vous de décider quelque chose ne signifie pas que vous êtes la meilleure personne pour faire l'appel. Tu es mieux
à certains types de décisions que d'autres, donc ne comptez pas sur vos propres limites de prise de décision.
Les gestionnaires de projet sont souvent considérés comme des experts locaux: le marketing voit le PM que la technique
expert, et de l'ingénierie voit le PM comme un expert en affaires. Mais en réalité, le PM peut être plus proche
Vers une prise-de-tout (et maître de rien). Ne jamais avoir peur de prendre le téléphone et appeler le
les gens qui en savent plus que vous sur la question à portée de main. Au moins leur demander leur consultation
et de les amener dans la discussion. Envisager de déléguer le choix qui leur est entièrement; demander
si ils pensent qu'il est de leur appel à faire, ou la vôtre. Si la relation est bonne, il pourrait être préférable
à prendre la décision en collaboration, bien que cela nécessite souvent le plus de temps à la fois pour
parties.

Dont l'approbation avons-nous besoin? Dont les évaluations voulons-nous / besoin avant de décider?
Plus l'organisation, les coûts plus généraux, il ya environ décisions. Une apparence
décision banale peut devenir complexe lorsque la politique et les désirs des parties prenantes et partenaires
organisations entrent en jeu (voir chapitre 16 ). Un bon test de votre autorité est combien de fois
triviales décisions exigent l'approbation ou la formation de comités. Les procédés plus bas
sont autour de décisions, plus vous devez travailler grâce à l'influence plutôt que de décret. Il y a
coûts politiques à des décisions qui ont rien à voir avec la technologie, les affaires, ou le client
considérations, et l'impact d'une décision qui les comprend.

Page 146

8.2. Trouver et pesant les options

Dans les sources du pouvoir: comment les gens prennent des décisions , Klein identifie deux façons de base les gens font
décisions: l'évaluation du singulier et de l'évaluation comparative (voir Tableau 8-1 ). Dans l'évaluation du singulier,
la première option est examiné et vérifié contre certains types de critères (ce que je veux porter ce vert
shirt maintenant?). Si elle répond aux critères, il est choisi et le décideur se déplace à plus
choses importantes. Si elle ne répond pas aux critères, une autre idée ou le choix est considéré, et de la
processus se répète (que diriez-vous cette chemise jaune?). Un bon exemple de cela pourrait être de trouver un endroit où aller
à la salle de bains quand vous avez vraiment y aller, ou d'essayer de trouver quelque chose à manger quand vous êtes
affamé. La première toilettes ou de restaurant vous trouvez est suffisante, et il n'y a pas
besoin d'explorer des alternatives.

Tableau 8-1. Les deux façons de base gens prennent des décisions

Décision
Comment ça marche Exemple
approche
 Singulier La première alternative raisonnable est trouvé Vous avez sérieusement besoin d'aller à la
évaluation accepté. salle de bains.
Comparatif Plusieurs alternatives sont évaluées Vous êtes décider sur lequel tropicale
évaluation l'autre avant de décider. île d'acheter ..

À l'autre extrémité du spectre, la prise de décision, l'évaluation comparative requiert la recherche

alternatives avant de décider. Considérant ce que la ville de déplacer votre famille est un bon exemple d'un
décision d'évaluation comparative commune.

Évaluation singulier fait sens pour les situations où la différence entre une excellente solution et un
solution décente est pas important. Klein décrit ces situations comme étant dans la zone de l'indifférence
parce que le décideur est indifférent aux principaux aspects du résultat tant que la base
critère est rempli. Être capable de reconnaître quand toutes les alternatives sont dans la zone de l'indifférence
(Voir Figure 8-1 ) peut sauver un projet beaucoup de temps, ce qui vous permet de mettre fin à des débats et des discussions
dès le début et à concentrer l'énergie sur les décisions complexes dignes de plus de réflexion. Bonne décision
décideurs ne perdez pas de temps d'optimiser les choses qui ne nécessitent pas d'être optimisé. Comme Tyler Durden dit,
"Ce qui ne devrait pas d'importance vraiment pas d'importance."

L'évaluation comparative est le mieux pour les situations complexes qui impliquent de nombreuses variables, ont
conséquences qui sont difficiles à saisir rapidement, ou exigent un résultat de haute qualité. De nouvelles situations ou
problèmes qui sont de nature stratégique sont les premiers candidats pour l'évaluation comparative. Le plus
qui est en jeu dans une décision, et tout le monde l'est moins familier avec la nature des options, le
plus approprié à une évaluation comparative est. Avec des équipes, l'évaluation comparative est le meilleur
cadre à utiliser si vous avez à convaincre les autres ou si vous voulez leur participation à la prise de décision
processus. Les forces de l'évaluation comparative vous pour présenter des arguments relatifs et développent plus profond
justifications pour l'action, qui est utile pour la discussion et de la communication groupe.

Figure 8-1. La zone d'indifférence contient les aspects d'un problème que vous
ne se soucient pas; évaluation unique implique que vous avez une zone plus large de
l'indifférence de l'évaluation comparative.

Page 147

La plupart du temps, il ya toutes les raisons de faire des comparaisons rapides. Il ya beaucoup de façons différentes de faire
évaluation comparative, et certains sont moins élaborés que d'autres. Par exemple, il ne faut pas plus
que quelques minutes pour énumérer quelques alternatives pour une décision sur un tableau blanc et de faire un peu
des jugements rapides sur leur valeur relative. Et même lorsque l'on travaille seul, je l'ai trouvé que faire un
courte liste des comparaisons est un excellent moyen de vérifier ma propre santé mentale. Si je ne peux pas venir avec plus de
un choix, alors je ne comprends pas clairement le problème assez bien: il ya toujours des alternatives.

8.2.1. Les émotions et la clarté

Peu de gens en parlent, mais il ya toujours des problèmes émotionnels et psychologiques impliqués dans
la prise de décision. Richard Restak, auteur de The Secret Life of the Brain (Joseph Henry Press, 2001),
a écrit, "Il n'y a pas une telle chose comme un moment non-émotionnel." Nous avons toujours des craintes, les désirs, et
motivations personnelles pour les choses, que nous les admettre ou ont même pas conscience d'eux. Même
motivations altruistes, comme vouloir le meilleur résultat pour le projet ou pour les personnes concernées,
ont une composante émotionnelle pour eux.

Cela signifie que même la personne de l'entreprise comme la plus logique dans la salle a des sentiments au sujet de ce qu'il est
fait, qu'il en soit conscient d'entre eux ou non. Parfois, nos émotions peuvent être utiles dans la fabrication
décisions, mais d'autres fois ils nous ralentissent, ou nous préjugés contre les choses que nous devons examiner. Et
au-delà des sentiments personnels, l'acte de prise de décision lui-même implique la pression et le stress, et il peut
créer des émotions et des sentiments en nous qui ont rien à voir directement avec la question à la main. Par
externaliser le processus de prise de décision à travers l'écriture ou de parler, nous rendons possible pour partager
 le fardeau affectif et à penser clairement sur les choix que nous avons. Même si nous avons la
la responsabilité de la prise de décision, l'ouverture du processus à d'autres nous donne une vue plus claire de
le meilleur plan d'action.

8.2.2. Le moyen facile à la comparaison

L'évaluation comparative peut avoir lieu que si vous avez précisé le problème ou la question à trancher.
Vous aurez également besoin d'un sens de ce que les aspects de l'issue sont souhaitables (navire plus tôt, à améliorer
qualité, font de la VP heureux, etc.). Il devrait y avoir tout intérêt à emprunter les mots et le phrasé
du document de vision, des spécifications ou des exigences listes. Ces documents reflètent de haut niveau
Les décisions qui ont déjà été faites, et vous devriez réutiliser autant de leur valeur que possible
(Ce qui est précisément ce que ces documents sont pour). Parfois, une conversation avec le client,
client, ou l'auteur de ces documents est tout aussi bon que (ou mieux) que les documents
eux-mêmes.

Si vous êtes familier avec les détails de la question, ou pouvez obtenir dans une chambre avec quelqu'un qui est, il faut
à seulement quelques minutes à venir avec une bonne liste de choix possibles. Avec une liste rapide, vous allez commencer à
se sentir mieux à propos de ce que vos solutions de rechange sont, et vous aurez une base pour amener d'autres personnes dans
la discussion. Parfois, il sera évident que l'on choix est considérablement mieux que les autres,
et aucune analyse supplémentaire est nécessaire. Mais souvent, vous trouverez le contraire: ce qui semblait être un no-

Page 148

brainer est plus compliqué que vous pensiez en premier. En écrivant les choix, vous obtenez une chance de
reconnaissent que d'autres questions se cachaient de vous.

La façon la plus simple de le faire est avec une liste de bonnes vieilles avantages et les inconvénients (voir Figure 8-2 ). Je ne suis pas sûr que quand
dans la vie, nous apprenons, mais presque tout le monde, je l'ai toujours enseigné ou géré a été quelque peu familier avec
rendant ce type de liste. Ce qui est étrange est qu'il est rare de voir des gens utilisent ces listes
réunions ou des discussions, peut-être parce qu'ils ont peur que par écrire leur pensée
les processus, les autres vont penser qu'ils ne sont pas assez intelligents pour garder dans leurs têtes.

Figure 8-2. La liste des avantages et des inconvénients.

Apparemment, la liste avantages / inconvénients remonte au moins au 15ème siècle, quand il a été utilisé comme un outil pour
aider à régler les débats publics. Ensuite, des siècles plus tard, Benjamin Franklin a appliqué la technique pour son propre
la prise de décision, donc il est crédité de populariser aux États-Unis (5)

Aussi simple que ce genre de liste est, voici quelques considérations importantes pour utiliser efficacement:

Toujours inclure une option "ne rien faire" . Non chaque décision ou un problème exige une action.
Parfois, la meilleure façon de faire est de ne rien faire, laisser tout ce qui arrive arrive, et investir
énergie ailleurs. Les coûts irrécupérables sont rarement la peine d'essayer de récupérer. Toujours vous donner cette
l'option, même si seulement de forcer l'équipe à comprendre exactement ce qui est en jeu dans la décision.
En fonction de vos politiques locales, ayant "ne rien faire" sur la liste peut donner plus de valeur par rapport à
toute autre décision que vous faites, car il rappelle aux gens qu'il n'y a aucune loi universelle qui
dit que vous devez faire quelque chose au sujet d'un problème.

Comment savez-vous ce que vous pensez que vous savez? Cela devrait être une question tout le monde est
demandé confortable. Il permet aux gens de vérifier des hypothèses et à remettre en question prétend que, tout en
pratique, ne sont pas fondées sur tout type de données, la connaissance de première main, ou la recherche. Il est OK pour
faire de grandes affirmations non prouvées "Je suis 100% positifs cette fonction sera fiable" aussi longtemps que
tout le monde sait que la seule chose derrière cela est l'avis de la personne qui en fait (et peut alors
juger sur ce mérite). Le cas échéant, de rechercher les données et la recherche pour aider à répondre importante
des questions ou des revendications.

Posez des questions difficiles . Couper à la chasse à propos de l'impact des décisions. Soyez direct et honnête.
Poussez fort pour se rendre à la base de ce les options ressemblent. (Voir la section « keeping it real »dans
 Chapitre 13 ). Le plus vite vous rendre à cœur de la question et une véritable compréhension de la
choix, le plus tôt vous pouvez passer à la prochaine décision. Soyez critique et sceptique. Demander
à chacun de mettre des sentiments et des préférences personnelles de côté: ne permet pas de bonnes idées de se cacher derrière
la crainte de blesser les sentiments de quelqu'un. Voir la liste à d'autres sur l'équipe, et d'ajouter dans leur
questions ou des observations pertinentes. Mettez des questions ou des hypothèses possibles dans les avantages ou
inconvénients colonne pour une idée donnée; une question sans réponse peut encore aider à clarifier ce qu'est un choix donné

Page 149

signifie vraiment.

Avoir une opinion dissidente . Pour les décisions importantes, il est essentiel d'inclure impopulaire, mais
des choix raisonnables. Veillez à inclure les opinions ou les choix ne vous plaisent pas personnellement, mais pour
qui bons arguments peuvent être faites. Cela vous empêche honnête et donne toute personne qui voit la
avantages / inconvénients énumèrent une chance de vous convaincre à prendre une meilleure décision que celle que vous pourriez
sont arrivés à vous-même. Ne pas avoir peur de se demander «Quel choix me ferait regarde
le pire, mais pourrait encore aider le projet? »ou« Y at-il de bons choix qui pourraient nécessiter
que je vous avoue que je me trompe sur quelque chose? "

Considérez choix hybrides . Parfois, il est possible de prendre un attribut d'un choix et d'ajouter
à un autre. Comme la conception d'exploration, il ya toujours des combinaisons intéressantes dans la prise
décision. Cependant, il faut savoir que cela ne exploser le nombre de choix, ce qui peut ralentir
les choses et de créer plus de complexité que vous avez besoin. Surveillez la zone d'indifférence et
ne perdez pas de temps en elle.

Inclure tous les points de vue pertinents . Considérez si cette décision impacts plus que la
la technologie du projet. Y at-il des préoccupations d'affaires qui seront touchés? Ergonomie?
Localisation? Si ces choses sont les objectifs du projet et sont touchés par la décision, ajoutez-les dans
le mélange. Même si elle est une décision purement technologique, il ya différentes perspectives en jeu:
les performances, la fiabilité, l'extensibilité, et le coût.

Commencez sur papier ou un tableau blanc . Lorsque vous êtes le premier à venir avec des idées / options, vous voulez
le processus pour être léger et rapide. Il devrait être facile de traverser les choses, faire des hybrides, ou
écrire des choses à tir rapide (un peu comme au début du processus de conception). Ne pas commencer par faire un
tableur Excel de fantaisie, avec 15 colonnes multicolores activés pour des tableaux croisés dynamiques; vous allez manquer le
Point. Pour certaines décisions qui sont résolus rapidement, la liste tableau est tout ce que vous aurez jamais besoin. Si
il se trouve que vous avez besoin pour afficher la liste avantages / inconvénients à une réunion importante, vous soucier de faire
une feuille de calcul élaborée ou glisser le pont plus tard.

Affiner jusqu'à stabilisation . Si vous continuez à travailler à la liste, il finira par s'installer dans une écurie
définir. Les mêmes questions de base ou des opinions continueront à venir, et vous ne serez pas entendre majeure
nouveau commentaire des gens intelligents avec qui vous travaillez. Lorsque la totalité de la logique et raisonnable
idées ont été contrôlés sur, et en montrant la liste des personnes vient seulement avec le même ensemble de
choix que vous avez déjà entendu, il est probablement temps d'avancer et de décider.

NOTE

Un exercice simple pour le lecteur est à ajouter à la liste affichée dans la figure 8-1 . Étant donné le peu de
détail de la situation est fourni, il ya au moins une douzaine d'autres options raisonnables
pourrait être ajouté. Un joli prix sera remis à toute personne qui les nomme tous.

8.2.3. Discuter et évaluer

Les décisions efficaces peuvent être effectués seulement quand il ya une liste de choix et une certaine compréhension de la façon dont
comparer les choix de l'autre. Avec une liste en place, une personne peut marcher à travers les choix et
développer une opinion sur les options qui ont le plus grand potentiel. Il est souvent seulement par
discussion qui a de fortes opinions peuvent être développés, et la liste des choix agit comme une discussion naturelle
facilitateur (nous allons discuter de la facilitation dans le chapitre 9 ). Je cherche toujours à mettre ces matrices de décision sur une
tableau blanc, donc lorsque les gens marchent dans mon bureau et poser des questions sur l'état d'un problème, je peux pointer
leur exactement où je suis et leur montrer pourquoi je suis penché dans une direction particulière. Même si je ne le fais pas
encore une conclusion, il est facile pour eux de comprendre pourquoi (peut-être me acheter plus de temps à faire
la décision). Plus encore, je peux leur demander de l'examiner avec moi, écoutez ma logique, et me proposer leur
avis. Au lieu d'essayer d'expliquer tout cela à la volée, la liste avantages / inconvénients tous les documents de la
considérations et ajoute de la crédibilité à quelque opinion que je l'ai développé.

Sur équipes qui communiquent bien, il est naturel de discuter des décisions critiques en tant que groupe. Chaque personne dans
la discussion tente d'enchaîner des hypothèses tirées de la liste avantages / inconvénients, et fait un

Page 150

argument en faveur d'une décision particulière. Vous entendrez chaque personne exprimer son opinion en termes d'une histoire "Si
nous faisons cela, alors X va arriver en premier, mais nous serons en mesure de faire Y "et puis quelqu'un d'autre sera carillon,
affiner l'histoire ou interroger l'une des hypothèses. L'histoire se raffinées, ainsi que les avantages et
les inconvénients de choix se ajustée afin de capturer la pensée plus claire que le groupe est arrivé à. Au fil du temps
(Qui pourrait être minutes ou jours), toutes les personnes concernées, en particulier le décideur, a une pleine
 la compréhension de ce que signifie la décision et quels compromis sont impliqués. Lorsque les avantages et les inconvénients
Liste stabilise, et peu de nouvelles informations sont ajoutées, il est temps d'essayer d'éliminer choix.

8.2.4. Sherlock Holmes, le rasoir d'Occam, et la réflexion

Le personnage de Sherlock Holmes a dit une fois, "Si vous éliminez l'impossible, ce qui reste,
cependant improbable, doit être la vérité "Et il va de pair avec la prise de décision:. si vous éliminez la
pires choix, ce qui reste, cependant mauvaises, doivent être votre meilleur choix. Ceci est certes un
cynique pour aller au sujet de décider les choses, mais pour prendre des décisions difficiles, la logique éliminatoire peut être la seule
façon de tourner le coin de la pression que vous ressentez et prendre de l'élan vers la prise d'une décision finale.

Si vous avez créé une liste de choix possibles et la nécessité de réduire le champ, chercher des choix qui ne sont pas
répondre à la barre minimum pour le projet. Vous pourriez avoir les a inclus plus tôt parce qu'ils ajoutés
à la discussion et a fourni une occasion de trouver des choix hybrides, ou parce que les exigences
étaient en cours de réexamen, mais maintenant il est temps de les couper lâche. Passez en revue vos documents et
listes des besoins, vérifier avec votre client ou de l'avocat de la clientèle, et de rayer de choix qui vient
ne sera pas assez bon. Si vous êtes chanceux, vous serez en mesure d'éclaircir le champ de plus de moitié et de réduire
la liste à deux ou trois choix qui sont vraiment utile d'examiner.

Un autre outil pour aider à réduire les possibilités est un principe connu sous le rasoir d'Occam. Guillaume de
Occam était un philosophe médiéval au 12ème siècle qui est crédité de l'aide de la notion de
la simplicité pour prendre des décisions. Il croit que les gens ajoutent souvent la complexité des situations, même si
il ne permet pas de les résoudre. Il a suggéré que la meilleure façon de comprendre les choses était de trouver la
simple explication et l'utilisation que d'abord parce que, la plupart du temps, il était la bonne explication (c.-à-
en langage moderne, keep it simple, stupid). (6)

Rasoir d'Occam se réfère au processus d'essayer de couper tous les détails inutiles qui nuisent à la
chemin et retour à la question centrale au cœur du problème. Cela implique également que la solution avec
les plus grandes chances d'être le meilleur est celui qui a la logique simple. Il pourrait y avoir une prometteuse
choix dans la liste qui requiert l'ingénierie complexes et risqués ou de nouvelles dépendances sur fiables
des personnes ou des technologies. Application rasoir d'Occam, le manque de simplicité et de clarté pourrait être un critère
pour prendre une option sur le fonctionnement et la coller avec le choix simple et fiable.

Mais pour appliquer le rasoir d'Occam efficace, vous devez prendre le temps de réfléchir. Lorsque vous passez des heures
pilonnant les mêmes questions, on finit par perdre de vue. Lorsque tous les choix commencent
la même recherche, il est temps de sortir. Partez pour une promenade, prendre un café avec un ami, ou de faire quoi que ce soit
pour effacer votre esprit et penser à autre chose. Vous devez être en mesure de regarder les choix avec une
esprit clair et frais, afin de prendre une décision efficace, et vous ne pouvez pas le faire si vous continuez à
regarder toute la journée.

La réflexion est très sous-estimée comme un outil de prise de décision. Pour tenir compte des moyens de prendre du recul et de permettre à tous
des informations que vous avez travaillé avec sombrer dans. Souvent, la compréhension réelle se produit uniquement lorsque
nous détendre et permettons à nos cerveaux pour traiter toutes les informations que nous avons jeté à elle. Je trouve que faire
quelque chose de physique comme faire une course ou une marche est la meilleure façon de permettre à mon esprit à se détendre. Autre
fois, faire quelque chose de purement pour le plaisir fait le tour, comme participer à un combat de Nerf, regarder un
bon film, ou jouer avec mon chien. Il est également difficile de battre le sommeil d'une bonne nuit (peut-être précédé
par un défouler collaboration entre les feuilles) pour compensation de l'esprit. Mais tout le monde est différent, et
vous devez comprendre par vous-même la meilleure façon de donner à votre esprit le temps de digérer tout ce que vous avez
été de penser à.

Quand vous faites revenir à votre liste de comparaison, rappelons brièvement visu les questions fondamentales sont.
Puis, pensant d'Occam, regarder les alternatives et vous vous demandez quel choix offre la
façon la plus simple de résoudre le problème à la main. Le choix le plus simple peut pas promettre le meilleur possible
résultat, mais en raison de sa simplicité, il pourrait avoir les plus grandes chances de résoudre avec succès le
problème à un niveau satisfaisant.

Page 152
151

8.3. L'information est une lampe de poche

La plupart des gens instruits dans le monde occidental ont appris à faire confiance à numéros. Nous estimons qu'il est plus facile de travailler
avec les chiffres et faire des comparaisons avec eux qu'avec des sentiments abstraits ou des idées. Décision et
théorie de l'utilité, brièvement mentionné plus tôt, dépend de cette notion en affirmant que nous faisons de mieux
décisions si nous pouvons convertir nos désirs et les probabilités de choix en nombres et de faire
calculs basés sur eux. Malgré ma critique antérieure de ces théories, parfois forcer
nous de mettre les valeurs numériques sur des choses peut nous aider à définir nos véritables opinions et prendre des décisions
sur eux.

Mais les décisions de côté, nous aiment souvent à voir des preuves pour les réclamations sous forme numérique. Il y a un
différence de l'utilité et de la crédibilité dans quelqu'un dire "Notre moteur de recherche est 12% plus lent sur 3-
requêtes de mots »que« le système est lent. "Les données numériques donne une sorte de précision qui humaine
la langue ne peut pas. Plus encore, des données numériques est souvent exigé par les personnes pour appuyer les revendications qu'ils
faire. La déclaration "Le système est lent" pose la question "Comment le savez-vous?" Le manque de
 une sorte d'étude ou de recherche dans la réponse rend la demande difficile de faire confiance, ou dépendantes
uniquement sur l'opinion et le jugement de la personne le dire. Parfois, un morceau spécifique de
information répond à une question importante et résout une décision beaucoup plus rapidement que possible
autrement.

8.3.1. Les données ne prend pas de décisions

Le premier malentendu à propos de l'information est que cela rend rarement une décision pour vous. Un bon morceau de
informations fonctionne comme une lampe de poche. Il aide à éclairer un espace et permet à quelqu'un qui est à la recherche
soigneusement pour voir les détails et les limites qui étaient invisibles auparavant. Si il n'y a pas actuellement de données ou
la recherche sur les revendications importantes, de prendre le temps d'obtenir des données peut accélérer la prise de décision
processus. Le brouillard commence à se lever et les choses deviennent claires. Mais les rendements diminuent avec le temps. Après le
premier feu a été allumé et les détails de base ont été révélés, pas de quantité d'informations peut
changer la nature de ce qui a été vu. Si vous êtes coincé au milieu de l'océan Pacifique,
connaissant la température actuelle de l'eau ou de la sous-espèce de poissons à proximité ne seront pas facteur beaucoup dans l'une des
les décisions que vous êtes susceptible de faire (mais connaissant les courants d'eau, les routes commerciales, et les constellations
pourrait). Pour la plupart des décisions difficiles, le problème ne vient pas d'un manque de recherche ou de données. Des décisions difficiles existent
dans cet univers, peu importe la quantité d'informations que vous avez. Je pense que le phénomène de l'analyse
paralysie, où les gens analysent et discutent obsessionnelle, est symptomatique de la croyance désespérée
si seulement il y avait suffisamment de données, la décision elle-même résoudre. Malheureusement, ce ne sont pas tellement. Information
aide, mais seulement jusqu'à un certain point.

8.3.2. Il est facile de mal interpréter des données

Le deuxième terme impropre à propos de données est que tout cela est également créé. Il se trouve que lorsque l'on travaille avec
numéros, il est très facile de mal interpréter l'information. Comme l'a écrit Darrell Huff dans mentir avec
Statistiques (WW Norton, 1993), "Le langage secret des statistiques, si attrayant dans un esprit fait-
la culture, est utilisé pour le sensationnalisme, gonfler, confondre, et simplifier. "Huff catégorise le nombre
moyens simples les mêmes données peuvent être manipulées pour présenter des arguments opposés, et il offre des conseils
qui devrait être la formation standard pour les décideurs partout dans le monde. La plupart des tours impliquent la
omission de détails importants ou la sélection exclusive de l'information qui prend en charge une réclamation désiré.

Par exemple, disons une boisson populaire de sport a une annonce que les revendications "Utilisé par 5 sur 6
superstars. "Il semble impressionnant, mais qui superstars utilisent le produit? Qu'est-ce exactement
sépare une étoile d'une superstar? Celui qui ils sont, comment ils ont été choisis pour l'enquête? Comment faire
ils utilisent le drinkto laver leurs voitures? Etaient-ils payés en premier, ou étaient-ils rejetés de l'enquête si
ils ne utilisent déjà la boisson? Qui sait. La publicité ne serait certainement pas dire. Si vous regardez

Page 153

attentivement toutes sortes de données, de la recherche médicale à l'analyse d'affaires aux tendances technologiques,
vous trouverez toutes sortes d'hypothèses et réserves surprenantes niché dans les petits caractères, ou non
tout mentionné. De nombreuses enquêtes et rapports de recherche sont financées principalement par des gens qui ont beaucoup
à gagner à des résultats particuliers. Pire encore, dans de nombreux cas, il est des magazines et des articles de journaux écrits par
personnes autres que celles qui font de la recherche qui sont notre point de contact pour l'information, et leur
objectifs et sens de l'attention des universitaires ne sont souvent pas aussi élevé que nous aimerions qu'ils soient.

8.3.3. Recherche comme munitions

La dernière chose à surveiller est de munitions se faisant passer pour la recherche. Il ya un monde de
différence entre essayer de comprendre quelque chose et essayer de soutenir une théorie de compagnie spécifique. Quoi
qui se passe trop souvent est quelqu'un (appelons-le sauter) a une idée, mais pas de données, et cherche des données
qui correspond sa théorie. Dès Passer trouve, il retourne à qui il essaie de convaincre et
dit: «Voir! Cela prouve que je suis à droite." Ne pas avoir de raison de douter des données, les rendements de la personne et
Passer obtient son chemin. Mais malheureusement, la preuve à l'appui de Skip prouve presque rien. Un tas de recherche
disant Pepsi est meilleur que Coca-Cola ne signifie pas qu'il n'y a pas une autre pile de part de recherche qui
prouve exactement le contraire. Recherche, pour être d'utilisation honnête, doit chercher des preuves pour la demande en
question et des preuves pour contester la demande (ce qui est une explication très simple et partielle de ce qui est
On appelle ce procédé scientifique). Les bons chercheurs et de scientifiques le font. Bien
annonceurs, les commerçants et les gens d'essayer de vendre des choses (y compris les idées) faire généralement pas.

La meilleure défense contre la manipulation des données et une mauvaise interprétation est la communication directe entre
gens. Parlez à la personne qui a écrit le rapport au lieu de simplement lire. Évitez les deuxième, troisième, et
informations quatrième main chaque fois que possible. Parler à l'expert révèle directement souvent des détails et
nuances qui sont utiles, mais étaient inappropriés pour inclusion dans un rapport ou une présentation. Au lieu de
dépendant exclusivement de ce petit transmis des email, appeler le programmeur ou de commercialisation sur le téléphone
et obtenir son avis sur la décision que vous faites face. Il ya toujours plus de valeur dans les personnes que dans
information. La personne qui a écrit le rapport a appris 1000 choses qu'elle ne pouvait pas y inclure Mais ne serait-
Or l'amour à partager avec quelqu'un d'assez curieux de demander.

Outre l'utilisation de personnes comme des sources, une culture du questionnement est la meilleure façon de comprendre et de
minimiser les risques d'informations. Comme nous avons couvert plus tôt en matière de conception et de prise de décision,
questions conduisent à des solutions de rechange, et ils aident tout le monde à examiner ce qui pourrait être manquant ou
supposé dans l'information présentée. Le questionnement conduit également à la volonté de données provenant de différentes
sources, éventuellement provenant de personnes ou organisations avec différents agendas ou des préjugés, permettant la
 décideur et le groupe d'obtenir une image claire du monde qu'ils essaient de prendre des décisions
dans.

8.3.4. La précision est pas la précision

Comme une dernière note à propos de l'information et des données, beaucoup d'entre nous oublient la distinction entre la précision et
exactitude. La précision est une mesure spécifique comment est; la précision est de savoir comment un proche de la réalité
mesure est. Simplement parce que nous sommes offert un nombre précis (par exemple, une estimation de travail de 5.273
jours) ne signifie pas qu'il a toute plus grande probabilité d'être précis qu'un nombre plus floue (4 ou 5
journées). Nous avons tendance à confondre la précision et l'exactitude parce que nous supposons si quelqu'un a pris le temps
de comprendre un tel nombre spécifique, l'analyse devrait améliorer les chances que son estimation
est bon. Le piège est que la précision de faux est libre. Si je prends une conjecture sauvage-cul (aka WAG) à la prochaine
Le chiffre d'affaires de l'année (5,5 millions $), et un autre pour les dépenses de l'année prochaine (2,35 M $), je peux
les combiner pour produire une projection de bénéfice convaincante-sondage: $ 3,150,000. Précise? Oui.
Précise? Qui sait. Sans demander "Comment savez-vous cela?" ou "Comment a été ces données produit?",
il est impossible d'être sûr si ces décimales représentent exactitude ou juste une précision. Prenez l'habitude
de briser les mauvaises habitudes des autres utilisations de trompeuse de précision.

Page 154

8.4. Le courage de décider

"Tout le monde sait le chemin, quelques-uns réellement marcher il."

Bodhidharma

Il ya une grande différence entre connaître le bon choix et faire le bon choix. Une grande partie de la
temps, un certain nombre de gens peuvent comprendre ce que la bonne décision est, mais très peu seront prêts à
se lever et eux-mêmes et leur réputation derrière elle mettre. Vous trouverez toujours plus de personnes
prêts à critiquer et vous ridiculiser pour vos décisions, que les gens sont prêts à prendre sur le
la responsabilité et la pression de prendre la décision eux-mêmes. Toujours garder cela à l'esprit. Décision
décision est un acte courageux. Les meilleures décisions pour les projets sont souvent impopulaires, va bouleverser ou
décevoir certaines personnes importantes dans l'équipe, et fera de vous une cible facile pour faute si les choses
se tromper.

Ces charges sont monnaie courante pour quiconque tente d'exercer une activité de leadership. La prise de décision est
l'une des la plupart des dirigeants des choses centrales et les gestionnaires font, et meilleur est le chef de file, plus
courage qui est nécessaire dans les types de décisions qu'elle fait (voir la section " Ayez confiance en vous
(Autonomie) "dans le chapitre 12 ).

8.4.1. Certaines décisions ont aucun choix gagnants

Une des décisions les plus laids que je ai jamais fait en tant que gestionnaire de projet comprenait la barre de l'explorateur
composant d'Internet Explorer 4.0. La barre de l'explorateur était une nouvelle partie de l'interface utilisateur qui
ajouté une bande verticale sur la partie gauche du navigateur pour aider les utilisateurs à naviguer dans la recherche
résultats, leur liste de favoris, et un historique des sites visités qu'ils avaient. Avec quelques semaines avant notre premier
bêta (test de aka) de libération, nous avons développé des préoccupations au sujet de la conception. Nous avions su à propos de la
problème pour un certain temps, mais avec la pression croissante du public de ce qu'on a appelé le «navigateur
guerres, "nous avons commencé à craindre que ce problème pourrait nous faire du mal dans la presse si nous avons expédié avec elle.

La question était la suivante: il était possible, dans des cas particuliers, pour afficher la barre de l'explorateur dans la même fenêtre que
l'explorateur de système de fichiers, ce qui permet à un utilisateur de créer un navigateur Web qui divise l'écran en
trois bandes verticales laides, laissant un petit espace pour effectivement affichage des pages Web. Après avoir vu la presse
et l'industrie scruter IE 3.0, nous craignions utilisateurs bêta ou journalistes pourraient découvrir cette condition,
faire une capture d'écran de celui-ci, et de libérer dans le cadre de leurs examens. Avis sur le produit ont été grièvement
important, surtout pour les versions bêta. Il y avait un consensus sur l'équipe et de la haute pression
la gestion que nous avons dû prendre des mesures et faire quelque chose.

Je fait une liste des avantages et des inconvénients rapidement, discuté avec mes programmeurs et autres gestionnaires de projet,
et identifié trois choix viables. Ils étaient tous mauvais. Régler le problème correctement requise cinq jours
de travailler, que nous ne disposons pas. Nous aurions à couper un autre élément majeur pour faire ce travail dans le temps, et
il serait dévastateur pour la qualité de la presse de le faire. Il y avait une solution hacky, exigeant
deux jours de travail, qui ont éliminé certains des cas qui ont causé cette condition, mais il a été un travail qui
devrait être jeté plus tard (le travail a été assez bon pour une version bêta, mais pas bon
assez pour une version finale). Le dernier choix était de ne rien faire et de parier que personne ne découvrirait
ce problème. Je désespérément cherché d'autres alternatives, mais ne trouve pas tout. Toute idée de gens sont venus
 me
fin, conduit vers le bas à ces troisblanc
choix.etJedeme souviens assissur
dans
ce mon
que jebureau un soir jusqu'à très
juste à regarder mon tableau tourner en rond dois faire.

Chaque chef de projet peut raconter des histoires de choix difficiles qu'ils avaient à faire. Si vous avez la responsabilité,
ils viennent avec le territoire. Ils peuvent impliquer des décisions du budget, l'embauche, le licenciement, offres commerciales,
la technologie, les litiges, la négociation, la conception, la stratégie d'entreprise, you name it. Lorsqu'ils sont confrontés à un dur
décision, il n'y a pas une seule bonne réponse. En fait, il est tout à fait possible que les choses peuvent arriver
faire aucun des choix disponibles (ou la totalité d'entre eux) mener au succès. La prise de décision, peu importe comment
bien documenté ou examinée, est un autre acte de prédiction. À un certain niveau, toute décision difficile vient
dans la fin de l'arrêt du gestionnaire de projet et courageand la courageto de l'équipe suivent.

Page 155

Dans cette situation particulière sur IE4, je choisi de ne rien faire. Après une nuit blanche, je décidai je préfère
gérer les questions de la presse si et quand elles se sont produites (qui consommerait mon temps, pas le
programmeurs ') au lieu d'investir dans l'assurance contre quelque chose qui n'a pas encore eu lieu. JE
étais pas heureux à ce sujet, mais je sentais qu'il était le meilleur choix pour le projet. L'équipe avait accepté dès le début
qu'elle était ma décision de faire, alors nous avons déménagé sur. (7)

8.4.2. Les bonnes décisions peuvent avoir de mauvais résultats

Notre recul sur les événements passés a été injuste pour beaucoup de bons décideurs. Tout simplement parce que
choses ne fonctionnent pas d'une manière particulière ne signifie pas qu'ils ne font pas un bon choix avec le
informations qu'ils avaient à leur disposition. Il est impossible de couvrir toutes les éventualités et envisager
toutes les possibilités lorsqu'ils traitent avec des décisions complexes ou difficiles (bien que certaines personnes vont essayer).
Le plus de temps que vous passez en essayant de couvrir toutes les éventualités (une habitude commune de micromanagers),
moins de temps vous aurez à dépenser sur les résultats probables. Il ya peu de sens dans se soucier
être frappé par la foudre, si vous avez une maladie cardiaque, manger mal, et envisager tapant très vite
comme une forme d'exercice.

Tout simplement parce que le cadre d'un projet échoue ne signifie pas nécessairement une mauvaise décision a été prise. Il est
commun pour les choses se passent au-delà du contrôle du gestionnaire de projet, l'équipe, ou le
organisation. Beaucoup de choses sont impossibles à prévoir, ou même si prédit, impossible d'être comptabilisés
pour. Il est injuste de tenir les décideurs responsables pour des choses qu'ils ne pouvaient certainement pas connus ou
rien fait. Pourtant, dans de nombreuses organisations, ce est exactement ce qui se passe. Si une équipe perd un
Fermer jeu, l'opinion publique tend à ne pas créditer le travail acharné et les efforts héroïques des joueurs qui ont obtenu
l'équipe perdante même si loin. Blame doit être manié avec précaution autour de la prise de décision.
Décideurs courageux auront tendance à échouer visiblement plus souvent que ceux qui font toujours sûr
et des choix prudents. Si vous voulez décideurs courageux, il doit y avoir une sorte de
un soutien pour eux de faire de gros paris et de les aider à récupérer quand ils échouent.

Les gestionnaires de projet sont certainement responsables du sort du projet. Je ne suis pas qu'ils suggérant
devrait être tapoté sur le dos pour imploser une équipe. Il est juste que des précautions doivent être prises pour ne pas reprocher à un
PM pour prendre une bonne décision qui est avéré avoir un mauvais résultat. Si sa logique et de la pensée
processus était valable avant la décision a été prise, alors, même avec le recul, sa logique et de la pensée
processus sont toujours aussi saine après la décision a été prise. L'état du monde à l'heure actuelle une
décision se produit ne change pas plus tard tout simplement parce que nous savons plus maintenant que nous avons fait ensuite. Si
il y avait quelque chose que le PM et l'équipe ne savait pas ou ne pouvait pas voir, en dépit de leur diligence dans
essayer de connaître et de voir les choses, ils ne devraient pas être grillées pour elle. Au lieu de cela, l'équipe devrait être
penser à comment ils pourraient collectivement ont été en mesure de capturer les données et les connaissances qui
ils ont manqué et d'appliquer ce que les prochaines décisions qu'ils ont à faire.

Page 156
 8.5. Prêter attention et regarde en arrière

Pour améliorer les compétences décisionnelles, deux choses doivent se produire. D'abord, vous devez prendre des décisions
que vous défi et vous forcer à travailler dur. Si vous ne faites jamais les décisions que vous trouvez difficile,
et si vous êtes trompe rarement, il est temps de demander à votre patron pour une plus grande responsabilité. Deuxièmement, vous devez
prêter attention aux résultats de vos décisions et d'évaluer, avec l'aide d'autres personnes impliquées, si vous
aurait pu faire les choses différemment pour améliorer la qualité du résultat. avantages d'expérience seulement
ceux qui prennent le temps d'apprendre de lui.

Dans la formation et dans de vraies missions, les pilotes de chasse se réunissent en séances d'information pour examiner ce qui a eu lieu.
Ces séances sont animées par des cadres supérieurs et expérimenté. Le thème central est que la seule façon de
développer et apprendre quelque chose d'aussi complexe que d'être un pilote de chasse est d'examiner les missions,
en corrélation avec tout le monde impliqué ce qui est arrivé et pourquoi, et de voir si il y avait des moyens à
améliorer le résultat. Ces discussions incluent souvent l'analyse de la stratégie et de la tactique et une
l'échange d'idées et d'opinions d'autres moyens pour faire face à la même situation.

La communauté médicale fait quelque chose de similaire dans ce qu'on appelle les M & M ou de la morbidité et de la mortalité
sessions (en plaisantant dénommé D & D, de la mort et des beignes), si ceux-ci sont généralement effectuées seulement
pour les cas mortels, ou lorsque quelque chose de particulièrement nouveau ou complexe a été fait.

Dans les deux cas, il appartient aux dirigeants de la session pour éviter de faire la session d'un procès ou à
embarrasser les gens pour leurs erreurs. L'objectif doit être de les faire se sentir suffisamment à l'aise avec
ce qui est arrivé qu'ils sont prêts à dépenser du temps à examiner et réévaluer ce qui se passait, donc
ils apprennent quelque chose d'elle, et donnent d'autres dans l'organisation une chance de bénéficier des coûts
de tout ce qui a eu lieu.

Voici ma liste approximative de questions pour l'examen des décisions. Quand je suis appelé pour aider les équipes à évaluer
travaux antérieurs, tel est le cadre décisionnel je commence avec. Cela fonctionne mieux en tant que groupe
activité (parce que vous allez bénéficier de points de vue différents), mais il fonctionne aussi pour l'examen de votre
propre pensée.

La décision n'a résoudre la question centrale? Cela devrait faire partie du processus de prise de décision
lui-même. Même si vous faites le bon appel, la différence est souvent la façon dont l'équipe exécute le
décision. Deux heures, une journée, deux jours après une décision a été prise, les besoins décideur
être de l'enregistrement et que la décision a coincé et est effectuée correctement.
Ces premières heures ou des jours sont lorsque des problèmes imprévus sont les plus susceptibles de se produire, ce qui peut
forcer un réexamen de la décision. Cela est naturel et doit être prévu.

Y avait-il mieux la logique ou de l'information qui aurait pu être utilisé pour filtrer les options
plus rapide? Où était le temps passé à faire la décision? Y avait-il des connaissances ou des conseils vous
aurait pu avoir qui aurait accéléré le processus de recherche ou d'explorer des solutions de rechange?
Quels sont les outils de recherche ont été utilisées? Quelqu'un at-il aller à la bibliothèque? La librairie? Rechercher sur le Web?
Appeler un consultant ou expert? Pourquoi ne sont pas ceux-ci proviennent utilisés?

Ont la vision, de spécifications ou d'exigences aident à la prise de décision? Bonne

les décisions et les priorités au niveau du projet devraient contribuer aux décisions de niveau inférieur le plus souvent
pas. Voilà exactement ce qu'ils sont là pour ça. Cette décision ne révèle une faiblesse ou de surveillance dans
la vision? A été la vision / spec / obligation mise à jour après la décision a été prise pour capturer
et d'éliminer la surveillance?

La décision at-il aidé l'avancement du projet? Parfois, une mauvaise décision encore se déplace
avancer le projet. Une décision catalyse personnes. En rendant une décision rapide pour aller à l'est, et
changer le point de vue, il pourrait devenir clair que le bon sens est en fait
nord. Mais jusqu'à ce que l'équipe a commencé à déplacer vers l'est, ils auraient pu ne jamais compris cela. Dans
en regardant en arrière, expliquer pourquoi la décision initiale a été un succès: était-ce parce que vous avez fait le droit
appeler, ou parce que vous avez fait la décision au bon moment?

Page 157

Ont été les principales personnes impliquées dans le processus et derrière la décision? Il y avait
toute personne dont le soutien ou l'expertise était nécessaire qui n'a pas été impliqué? Avez-vous essayé
en contact avec eux et de ne pas, ou avez-vous même pas essayé? Y avait-il un moyen de les apporter plus
efficacement que vous avez fait? (Vous devez obtenir leurs opinions sur ce si vous voulez un honnête
point de vue.)

La décision n'a prévenir ou causer d'autres problèmes? La question immédiate aurait pu

résolus, mais ont d'autres problèmes causés? Le moral n'a tomber? Était une entreprise partenaire ou une équipe
brûlé par la décision? Quels sont les effets secondaires négatifs de la décision n'a pu et auraient-ils pu
pu être évitée? Ont-ils été prévus, ou étaient-ils une surprise?

Avec le recul, étaient les choses que vous étiez inquiet au sujet tout en rendant la décision de la
bonnes choses? pression et la paranoïa peuvent fausser son sens pour lequel les questions sont dignes de
attention. Avec le recul, vous devriez être capable de voir les choses qui ont été déformées en importance,
par vous ou par d'autres, et vous vous demandez comment cela est arrivé. Dont l'opinion ou de l'influence contribué à
la distorsion? Qui a tenté de minimiser, mais a été ignorée?

Avez-vous eu l'autorité suffisante pour faire le bon appel? Peut-être que vous aviez une idée vous
 voulu courir avec, mais vous abandonné pour des raisons politiques. Ou peut-être que vous avez passé plus de temps
la lutte pour le contrôle de questions, où vous vous sentiez aurait dû être sous votre autorité de la
commençant. Considérez la façon dont le pouvoir a joué un rôle dans la décision et comment les changements dans la
distribution de l'énergie pourrait avoir changé la façon dont les choses allaient.

Comment ce qui a été appris dans cette décision être appliqué ailleurs dans le
projet? Ne pas limiter les leçons apprises aux spécificités de la décision. Regardez la prochaine vague de
décisions à venir au projet (à côté de la date ou de la tâche importante), et appliquer les leçons à eux.
Utilisez la nouvelle perspective et regarder vers l'avenir, plutôt que seulement le passé. Rappelez-vous le
Proverbe birman: "Un homme craint le tigre qui le mordit dernière, à la place du tigre qui lui mordre
Suivant."

Page 158

8.6. Résumé

Il est une compétence importante dans la méta-prise de décision ou des décisions sur les décisions à
investir du temps dans.

Taille des décisions avant de passer trop de temps sur eux.

Recherchez la zone d'indifférence et de possibilités pour une utilisation efficace de l'évaluation singulier.

Utilisez l'évaluation comparative des décisions dignes de plus d'investissements.

Toutes les décisions ont des composantes émotionnelles à eux que nous l'admettions ou non.

Avantages et inconvénients des listes sont la méthode la plus souple pour l'évaluation comparative. Ils le rendent facile
d'impliquer les autres et obtenir des perspectives supplémentaires sur les décisions.

Les informations et données ne prennent pas de décisions pour vous.

Vous améliorez à la prise de décision en examinant les décisions passées et les explorer pour les leçons
et opportunités pour une meilleure tactique.
Page 159

Chapitre Neuf. Communication et

relations

L'une des premières histoires d'ingénierie dans l'histoire occidentale est l'histoire de la Tour de Babel,
de la Genèse, et à sa base est une leçon sur la communication. Comme le raconte, l'humanité était
heureusement unis dans le désert. Ils ont vite compris comment faire des briques et du mortier. Les choses étaient
va si bien que, sans raison particulière, ils ont décidé de construire une tour très haut dans le ciel. Choses
est allé le long brillamment jusqu'à ce que les travailleurs soudainement perdu la capacité d'utiliser la même langue (pouvez-vous
dire «intervention divine»?), à quel point tout est littéralement tombée en dehors. Les gens fois-unis
ont été dispersés à travers le monde (plus de l'intervention divine), et différentes langues et sociétés
ont été formés. Il est suggéré dans l'histoire que si elles avaient été en mesure de continuer à bien communiquer
uns avec les autres, rien aurait été impossible (ce qui est peut-être, que l'histoire suggère également,
ce qui a motivé l'intervention divine).

Cette histoire biblique est assez courte en longueur: à peine une page complète. Cependant, à travers les siècles, il est
capturé l'attention de nombreux artistes et écrivains qui ont utilisé l'histoire pour explorer contemporaine
 problèmes. Les images saisissantes de la tour peinte par Bruegel (1) et d'autres ont donné l'histoire de plus en plus
pertinence pour les tâches d'ingénierie et de gestion de projet de leur époque. Les interprétations de la
histoire ont changé d'âge en âge, comme l'ont fait les représentations de ce que la tour ressemblait réellement, mais
les thèmes généraux sont les mêmes. Certains croient que l'histoire est un avertissement à propos de l'orgueil et de l'humanité
un rappel que certaines choses doivent être inaccessible pour nous. D'autres le voient comme une histoire de gens qui luttent
pour obtenir tout ce qu'ils peuvent en repoussant les limites de ce qui est possible. Mais pour moi, et pour la
souci de ce chapitre, la leçon centrale de l'histoire de Babel est simple: si vous ne pouvez pas communiquer, vous
ne peut pas réussir.

Pour une grande partie de l'histoire de la civilisation, la lenteur de la communication a causé des problèmes. Même à la fin
que la guerre de Sécession (1861-1865), il y avait pas de radio, télégraphes, ou sémaphore (drapeau)
systèmes d'usage courant. Généraux messages envoyés par un cheval de coordonner l'information de bataille avec
les commandants de différents camps (qui, selon la distance, a pris des heures ou des jours, en supposant que le

Page 160

messager ne pas se perdre). En conséquence, les décisions ont souvent été prises jours à l'avance avec des pas efficaces
façon de retirer ou de modifier les affectations d'attaque. De nombreuses catastrophes et les malentendus de première ligne
le résultat de ces limitations. (Imaginez un commandant de champ de bataille qui vient de sonner la charge,
envoyer toutes ses troupes pour attaquer, quand un messager épuisé trébuche dans sa tente. La
messager, luttant pour reprendre son souffle, dit, "Dispatch de la commande ...." Cher commandant: Le
renforts vous étiez en fonction ont été envoyés ailleurs. Pardon. Bonne chance. »Pas étonnant
messagers étaient souvent abattus.)

Ces jours-ci, la communication est toujours aussi importante que dans les époques précédentes. Mais deux choses ont changé.
Tout d'abord, la vitesse est plus le principal problème (comment pouvez-vous obtenir plus vite que la messagerie instantanée?).
Au lieu de cela, le problème est devenu la qualité et l'efficacité de la communication. Deuxièmement, pour le travail
qui est aussi complexe et interdépendant que le développement de logiciels, la communication ne suffit pas: il
doivent être des relations efficaces et saines entre les personnes qui travaillent ensemble. Ainsi
de nombreuses décisions sont partagées, et beaucoup de travail est fait en collaboration, que sans bonne
relations, aucune quantité de matière de communication supplémentaires. Contrairement à la structure de commandement militaire
une armée, la plupart des équipes de logiciels se fondent sur l'interaction peer-to-peer et d'autres, moins hiérarchique entraînée
relations. Bien qu'il existe souvent des leaders clairement définis, qui donnent parfois des ordres, des projets
sont fortement tributaires de la capacité de l'équipe à faire usage de la connaissance de l'autre, de partager des idées,
et de travailler en synchronicité (plutôt que de compter sur des lignes strictes de l'autorité, la discipline rigoureuse,
et l'obligation de suivre les ordres sans poser de questions).

Parce que les gestionnaires de projet passent beaucoup de temps à communiquer avec des individus et des groupes, ils
entraînent inévitablement une plus grande responsabilité pour la communication efficace que d'autres personnes de l'équipe.
Les bons gestionnaires de projet fournissent un flux continu d'une bonne communication et des relations saines,
amplifier l'efficacité de tous ceux qu'ils entrent en contact avec. Si elle est la santé de la sociale
réseau d'une équipe qui l'empêche de devenir un autre tour de Babel, alors il est le projet
gestionnaire qui a le rôle le plus naturel dans la construction et le maintien de ce réseau.

Faire cela ne nécessite pas, une personnalité jeu-show-hôte extraverti; ni qu'il ne demande un
sens inné de l'humour ou de pouvoirs magiques (bien que ceux-ci peuvent aider). Au lieu de cela, on commence par
en admettant que la communication et les relations sont essentiels au succès, et qu'il n'y a de la place pour
amélioration pour vous-même et votre équipe. Si vous admettez qu'il est important, alors vous aurez envie de comprendre
où la plupart des problèmes de communication se produisent et apprennent à traiter avec eux.
Page 161

9.1. Gestion par la conversation

Cela peut paraître étrange, mais il m'a fallu beaucoup de temps pour comprendre la valeur de parler aux gens dans
le lieu de travail. Je bavarde et plaisanter autour, mais je rarement confondu socialisation au travail avec le réel
faire des travaux. Mon éducation et des expériences au collège m'a amené à croire que je devais résoudre des problèmes
sur mon propre au travail. Dans ma première année chez Microsoft, je cherche rarement l'opinion des autres ou Trouver
quelqu'un qui avait plus de connaissances que je l'ai fait et le réutiliser. Au lieu de cela, je moudre sur mon propre et
travailler dur au lieu de puce. Dans le même temps, je l'ai regardé deux de mes premiers gestionnaires, Ken Dye et
Joe Belfiore, présentent le comportement curieux de passer beaucoup de temps à parler à d'autres personnes. Je voudrais
les voir, assis dans divers autres bureaux des gens, bavarder. Aussi occupé comme je l'étais, je ne pouvais pas aider
mais se demandent comment ils pouvaient se permettre de passer autant de temps "socialisation". Étant nouveau, je ne leur demande
à ce sujet. Au lieu de cela, je viens étiqueté eux "extravertis", qui à l'époque, compte tenu de mes antécédents, étais
genre mineur de l'insulte. Leur comportement m'a ennuyé (devraient-ils pas travailler au moins aussi dur que je
suis?), et je ne vois pas l'utilité de ce qu'ils faisaient. Comme je me trompais.

Comme mes responsabilités ont augmenté, je lentement compris ce que Ken et Joe avaient fait. Par essais
et l'erreur je appris que malmenant, l'intimidation, la dictée, ou exiger des choses était pas un moyen efficace
tactique quand je devais choses de gens qui ne sont pas obligés de me écouter. Je remarquai similaire
résultats dans des programmeurs ou des testeurs noncommunicative, et qu'ils étaient inefficaces lors de l'obtention
travail qui a impliqué d'autres personnes techniques. (Ceci est important si vous regardez la figure 9-1 . Le
implication est que tout le monde peut bénéficier de meilleures compétences en communication et relations, peu importe
comment isolé leur travail est censé être.)

Figure 9-1. Il ya des preuves que les programmeurs ne sont pas aussi solitaire que nous
penser.

Je trouve que le plus de fois que je exigés ou supposés choses de personnes ("Vous avez besoin de coder ce
Ainsi, OK? "), plus la probabilité est que je reçois le meilleur travail de leur part. Même si ils l'ont fait
ce que je demandais, quelque chose sur mon approche a tué une partie de leur motivation ou minimisé la
probabilité qu'ils avaient ajoutent de la valeur au-delà de ce que je lui avais demandé pour. Cependant, je trouve que quand je causais
avec eux ("Hey, je pense que nous devons faire X, et je pense que vous êtes la bonne personne pour le faire. Que faites-vous
penser? "), au lieu de aboyer des ordres, je recevais ce que je devais plus tôt que quand je l'habitude ces autres
tactiques. Et, comme un bonus, les chances ont augmenté d'entre eux suggérant de bonnes améliorations sur mes idées. JE
appris que les dialogues sont mieux que des monologues.

9.1.1. Relations améliorer la communication

Page 162

Malgré la façon dont il est évident que vous devez avoir une relation positive avec quelqu'un dans le but de
avoir une bonne conversation avec lui, les gens sont rarement récompensés pour leurs compétences pour le faire. Ceux
discussions informelles et des conversations Ken et Joe ont investi du temps dans ne sont pas un moyen de tuer le temps. Ceux
conversations étaient investissements dans les personnes et l'information, donnant Ken et Joe connaissances et
aperçu de ce qui se passait que quelques autres dans l'organisation avait. Mais spécifique à mon point:
quand ils avaient besoin de demander des conseils, une opinion ou une tâche, ils pourraient parler à presque tout le monde sur le
équipe, à tout moment, et de commencer à partir d'un endroit sain et positif, plutôt que de partir de zéro. Leur
relation avec l'équipe accéléré leur capacité à communiquer avec tout le monde.

Cela a rendu plus facile à couper à la chasse sans être impoli, ou même de faire des demandes exceptionnelles de
les personnes qui seraient normalement rejetés. En matière d'opinion, ils avaient construit assez de confiance pour obtenir
opinions honnêtes de la droite des personnes de manière décontractée, et, si l'envie, ils pourraient intégrer
ces suggestions et des idées dans leur propre pensée bien à l'avance de grandes discussions. En bref,
à travers ceux conversation et de relations informelles, Ken et Joe étaient en avance sur le reste de la
 équipe.
à traversIls savaient
leur plus sur ce
investissement quiles
dans se relations.
passait bien
Ilsetavaient
ce quiouvert
n'a paslaété,
voieet àilstoutes
ont eusortes
plus de
d'influence sur
soutien supplémentaire
et les avantages, simplement en parlant et en écoutant les gens.

Dans le classique de Tom Peters et Nancy Austin, Une passion pour l'excellence (Warner Business Books, 1985),
ce genre de comportement est appelé en marchant autour de la gestion (MBWA). Il est décrit comme une centrale
la qualité dans les gestionnaires de succès qu'ils ont observés (un chapitre entier dans leur livre est dédié à elle).
Mais il est pas facile de bien faire. Ils recommandent de choisir explicitement un petit nombre de personnes, à différents
les niveaux et les rôles dans l'équipe, et le temps de l'investissement dans la construction de ce type de relation informelle avec
eux. (2) Plus important encore, il est nécessaire de comprendre comment la communication saine et
les relations de travail et un engagement à développer ces compétences. Même si vous ne choisissez pas une MBWA
approche pour établir des relations, de la communication de base et des compétences interpersonnelles sera toujours essentiel de
tout ce que tu fais.

Page 163

9.2. Un modèle de base de la communication

Malgré la façon dont nous communiquons souvent avec les gens, nous intervenons rarement en arrière et de disséquer ce qui est fait
passe. Parce que la plupart d'entre nous ont jamais été enseigné ou formés pour comprendre ce qui se passe
quand les gens communiquent, il est pas surprenant que nous nous heurtons à des problèmes fréquemment. Très peu de gens
dans le lieu de travail ont une réelle compétence dans le diagnostic de la communication ou des problèmes relationnels, ou
avoir l'autorité nécessaire pour faire le tri. Cependant, il est facile à apprendre un cadre simple pour
ce que les objectifs de la communication arefrom une gestion de projet perspectiveand l'appliquer à tous les jours
situations. Avec cette connaissance, vous pouvez briser où les choses sont défaillants et à devenir plus
capable de résoudre les problèmes parce que vous aurez une meilleure compréhension de ce qui ne fonctionne pas.

"Les bons centres de communication très développés autour de la conscience individuelle et

différenciation. Un bon communicateur est conscient de deux processus internes
eux-mêmes, et dans d'autres processus externes ".

John Bradshaw

Dans le cadre plus simple que je connais, il ya cinq états de base (décrits peu de temps) que tout acte de
La communication peut être en. (3) Chacun est de plus en plus importante et plus difficile à réaliser que la
état précédent. La communication est couronnée de succès que si elle atteint le troisième état (compréhension), sinon
le quatrième (accord) ou cinquième (action). Pour aider à illustrer chaque état, je vais utiliser un exemple de la
le film 2001: A Space Odyssey : Dave, un astronaute, est dans un petit engin spatial et veut revenir
à l'intérieur du vaisseau mère. Hal, à l'intérieur du vaisseau-mère, est la seule entité capable d'ouvrir les portes
de le laisser entrer.
 1. Transmis . Lorsque vous envoyez un e-mail ou laissez un message vocal, vous transmettez un morceau de
informations à quelqu'un. Cela ne signifie pas qu'elle a lu ou entendu, cela signifie juste que le message
a laissé vos mains avec l'intention d'arriver dans la sienne. Avec le courrier électronique et le Web, il est très facile de
transmettre des informations, mais il n'y a aucune garantie que quelqu'un va jamais lire. Exemple:
Dave dit, «Hal, ouvrir les portes de la soute de la gousse, s'il vous plaît." (Dave entend que le silence en réponse.)

2. Reçu . Quand quelqu'un vérifie son email ou des signes pour une enveloppe FedEx, le message a
été reçu. Toutefois, la réception ne signifie pas que le message a été ouvert ou que le bénéficiaire
a l'intention de le lire ou de passer du temps à essayer de comprendre. Tandis que les recettes de lecture
pour le courrier électronique ne vous dire qu'il a été ouvert, rien d'autre est confirmée. Exemple: Hal répond, "Bonjour
Dave. "(La transmission est reçu.)

3. Compris . Digérer et interpréter correctement les informations d'un message est un grand saut dans
effort de recevoir simplement un message. Activité cognitive réelle doit avoir lieu afin de
comprendre quelque chose ("Qu'est-ce que cela signifie?"), tandis que la réception il ne nécessite pas que
même activité ("Hé, je suis certaine email!"). Selon le problème impliqués, la compréhension d'un
un message pourrait impliquer l'apprentissage d'un nouveau concept, à la recherche des références, ou l'examen d'une
pièce complexe de code. Souvent, pour comprendre quelque chose, le destinataire doit poser des questions à
clarifier les choses ambiguës sur le message d'origine. Poser des questions nécessite un plein sur deux
communication bidirectionnelle, ce qui est plus complexe pour les deux parties. (Cela complique simple de cinq
cadre de scène, la création d'un arbre de communications simultanées imbriqués, comme chaque question,
et chaque réponse, commence sa propre séquence de transmission, de réception, de compréhension, etc.)

4. Convenu . Comprendre quelque chose ne signifie pas une personne est d'accord avec elle. Je pourrais pleinement
comprendre tous les aspects de la demande d'un exécutif, un jour avant la version finale, de faire un
Linux port de notre seule Mac programme de montage vidéo, mais cela n'a aucune incidence sur la façon dont je fou
pense que l'idée est. Parvenir à un accord entre deux personnes intelligentes et opiniâtres peut être un
complexe et activité de temps, surtout si les objections ne sont pas clairement énoncés. Malgré
combien il est difficile, l'accord est la base pour la prise de décisions qui influent sur ​une équipe. (4) Exemple:
"Désolé Dave, mais je crains que je ne peux pas faire cela." (Hal comprend ce que Dave veut, mais il ne le fait pas
d'accord et ne donne aucune explication.)

5.

Page 164

5. Converti en action utile . Malgré la quantité d'énergie qu'il peut prendre pour comprendre quelque chose
correctement et peut-être atteindre un niveau d'accord à ce sujet, beaucoup plus d'énergie est nécessaire pour
demander à quelqu'un de faire quelque chose à ce sujet. Même si le message explicitement appelé pour que le récepteur
prendre des mesures, il n'y a souvent pas de stricte obligation de sa part de le faire. Peut-être qu'elle suppose qu'il est OK
pour répondre à la demande de la semaine prochaine ou le mois prochain (lorsque vous devez le faire dans les 10 prochaines minutes).
Et peut-être, le pire de tout, il est tout à fait possible qu'une action est prise, mais il est la mauvaise action,
ou il est une action que l'expéditeur du message ne suis pas d'accord avec.

Les bons communicateurs transmettent des informations à l'intention de celui-ci étant entendu. Au lieu de simplement
l'envoi d'un e-mail et de voir ce qui se passe, ils réfléchissent à la manière profonde dans ce cinq étapes
modèle ils doivent aller pour être efficace, et ils confectionnent la communication de faire ce
possible. Ils utilisent un langage et des exemples qui fera sens pour le destinataire du message,
au lieu de simplement en utilisant ce qui est commode pour eux. Plus encore, dans le message qu'ils clarifient ce que le
les points susceptibles d'argumentation sont et d'identifier quelles mesures ils veulent le destinataire à prendre en réponse.

Donc, chaque fois que vous recevez ou envoyez un e-mail, ou arrêtez-vous au bureau de quelqu'un pour lui demander quelque chose,
il ya une progression naturelle de la prise de communication endroit. Utilisez ce cadre pour vous aider
diagnostiquer pourquoi ce que vous voulez qu'il se passe ne se passe pas. Une bonne communication se produit lorsque
il ya une séquence naturelle et équitable des échanges entre deux personnes de passer à travers chacun de ces
stades. Même quand les choses ne vont pas bien, en étant conscient d'un cadre comme celui-ci permet d'identifier où
la communication est tomber en panne.
Page 165

9.3. Problèmes de communication commune

Il ya une poignée de raisons pour lesquelles la communication est rompue. Chaque gestionnaire de projet doit être
familiers avec ces raisons à les identifier dans les autres et leur propre comportement et à prendre
la responsabilité de travailler pour les résoudre quand ils se produisent. Dans de nombreuses équipes, ces comportements
exister parce que le gestionnaire du groupe soit présente les même ou les tolère dans d'autres. Jusqu'à
quelqu'un avec une certaine autorité dans les étapes, identifie le problème comme un problème de communication, et prend
au moins la responsabilité partielle pour aider à régler ce problème, ces mauvaises habitudes de communication se poursuivront.

Cette courte liste couvre un grand nombre de problèmes de communication communs, décrit brièvement pourquoi ils
produire, et offre quelques conseils simples pour éviter ou récupérer d'eux.

Assomption . Lorsque vous entrez dans le bureau de quelqu'un et lui demander pourquoi il n'a pas envoyé que
e-mail important encore, vous êtes en supposant que: a) il savait qu'il devait l'envoyer; b) il savait
quand il était censé l'envoyer; c) il a compris ce qui était censé être en elle; et d) il
était censé pour vous informer de toute façon quand il l'a fait. Avant de crier à cette personne (appelons-le
Sam), ou le blâmer, une bonne communication consiste à éclairer ces hypothèses. "Sam, fait
vous envoyer ce courriel encore? "Sam répond:« Qu'est-ce courriel? »« Sam, rappelez-vous, hier nous avons parlé dans
la salle et vous confirme que vous pourriez faire cela? "" Oh oui, je l'ai envoyé il ya quelques minutes. "Bonne
communicateurs précisent habituellement hypothèses au cours des discussions à des points clés, comme lorsque
des engagements sont pris, et confirment à nouveau avant la date limite.

Le manque de clarté . Il n'y a aucune loi dans l'univers affirmant que d'autres vont comprendre ce que
vous dites tout simplement parce que vous comprenez vous-même. Peu importe la façon éloquente que vous soyez,
si l'autre personne ne vous comprend pas, alors vous n'êtes pas assez éloquent de la situation
à portée de main (comme l'a dit Red Auerbach, "Il est pas ce que vous dites, il est ce qu'ils entendent"). Le naturel
remède est de prendre du recul, de ralentir, et de briser les idées en morceaux plus petits et les plus petits jusqu'à
un point de clarté est atteint, puis construire lentement d'elle. Trouver une histoire ou analogie pour donner un
cadre rugueuse que les gens peuvent suivre, et ajouter des détails à jusqu'à ce que vous ne devez pas l'analogie
plus.

Ne pas écouter . Dans le film Fight Club , le personnage principal, Jack, dit en référence à l'un des
les nombreux groupes de soutien, il est récemment rejoint, «Ils écoutent vraiment à moi, au lieu de simplement
en attendant leur prochaine chance de parler. "Nous sommes compulsivement mauvais auditeurs, et nous avons tendance à préférer
le son de nos voix à celle des autres. Pire encore, même si les gens nous parlent, nous sommes
souvent simplement calculer notre prochain responsecontinuing pour défendre notre ligne originale de
argumentinstead de vraiment écouter leur point. (La forme extrême de ce problème est tout simplement
ne font pas attention, comme dans la lecture de votre e-mail pendant que quelqu'un parle de vous. Malgré
créances douteuses de compétence multitâche, il envoie toujours un message négatif à la personne
Qui parle de vous: «Vous n'êtes pas digne de contact avec les yeux.») Le remède est de toujours accepter la
possibilité qu'ils savent quelque chose d'important que vous ne le faites pas. Votre but est de ne pas les forcer
dans une position, mais au lieu d'atteindre le meilleur résultat possible pour le projet.

Dictée . Le jumeau maléfique de ne pas écouter dicte. Au lieu de donner même le prétexte de
écouter, les gens qui dictent tout simplement donner des ordres. Des objections ou des questions à l'ordre sont
rejeté ou a répondu à la déception ou de la dérision, comme si elle devait être entièrement évidente
pourquoi l'ordre est ce qu'il est et pourquoi il est donné sans explication («Que faites-vous,
stupide? "). Ce ne est pas un acte de communication parce qu'il est une violation complète de la
cadre couvert précédemment: pas de tentative de parvenir à une compréhension, beaucoup moins
accord. Donner des ordres a sa place, mais il devrait être l'exception. Au lieu de cela, s'efforcer de faire
décisions dans un environnement où les gens ont le droit de poser les bonnes questions et de proposer des
défis à votre logique.

Problème inadéquation . Communication peut masquer de nombreux autres problèmes. Il est seulement quand nous
communiquer avec quelqu'un qu'ils ont une chance à la surface de leurs sentiments au sujet de l'autre
problèmes. Ce qui revient en réponse à une demande peut être une expression des sentiments qui ont
Page 166

rien à voir avec la demande spécifique ("Hey, pouvez-vous lire cette spécification?", "Non! Jamais! Mort
d'abord! "). Il pourrait y avoir un problème non résolu d'une autre décision qu'il n'a pas exprimé son
sentiments sur le moment. Si aucune des parties ne reconnaît qu'il ya différentes questions examinées
sous le couvert d'une seule question, la discussion sera frustrant et difficile à résoudre.
Quelqu'un doit les séparer: "Attendez, quoi parlons-nous vraiment ici Comment coder cette
fonction, ou pourquoi vous ne l'avez pas obtenir cette promotion vous vouliez? "

Personnel / attaques ad hominem . Les situations sont souvent faites personnelle quand on quarts de parti
la discussion loin de la question et vers un individu. Ceci est appelé ad hominem
(Contre la personne). Par exemple, Fred pourrait dire qu'il n'a pas le temps, à laquelle répond Sam,
"Voilà le problème avec vous. Comment se fait-vous jamais eu le temps d'examiner les plans de test?" C'est
injuste de Fred parce qu'il doit défendre non seulement son opinion, mais aussi son comportement personnel.
Les attaques personnelles sont des coups bas, et il ya de nombreuses formes différentes d'entre eux. (5) Souvent, le
personne de prendre la photo pas cher se sent vulnérable et voit l'attaque comme la seule façon de gagner la
argument. Il est à une personne plus mature (ou peut-être Fred lui-même) d'intervenir et séparée
les problèmes.

La dérision, le ridicule, et le blâme . Quand une personne a une idée nouvelle, elle fait elle-même
vulnérables à qui elle choisit de partager avec. Elle exige un sentiment de confiance pour être
venir et honnête. Si elle est constamment ridiculisé ou humilié dans le processus de
communiquer des informations importantes, mais désagréable, elle cesser de le faire. La première réponse
à un problème ne doit pas être "Comment pouvez-vous laisser cela se produire?" ou "Vous savez cela est tout à votre
faute, pas vous? "

Il ya d'autres problèmes qui se posent dans la communication, mais cette liste de base couvre de nombreuses possible
situations. Parfois, les situations de surface dans les conversations entre les seules deux personnes dans un bureau, et
parfois il ya plusieurs personnes impliquées. Les plus de gens impliqués, plus il peut être à
isoler quel est le problème et prendre des mesures pour y remédier. Parfois, des discussions de groupe sont la mauvaise
place pour résoudre les problèmes de communication parce qu'il ya trop de gens impliqués et les conflits à
résoudre tout problème de manière efficace. La communication de groupe est une question que je vais aborder brièvement dans le chapitre 10 ,
mais pour la plupart de ce chapitre, je vais me concentrer sur les situations plus simples.

Une tactique simple pour faire la liste précédente action est de partager avec les gens de votre équipe, et
leur demander d'identifier quand quelqu'un se comporte d'une manière problématique. L'équipe va maintenant avoir un
langue pour les problèmes qu'ils voient, ce qui rend plus facile d'identifier et de minimiser ces comportements.
Spécifique aux chefs d'équipe, l'engagement doit être fait pour réexaminer leur propre comportement et de payer
plus d'attention à ce qu'ils font et disent. Les chances sont élevées que ils vont identifier rapidement les habitudes
qui doivent être travaillé sur. (Changement de toute nature est difficile. Le changement organisationnel nécessite ceux
le pouvoir de prendre des mesures. Voir Chapitre 16 ).

Toutefois, peu importe combien vous lisez ou étudiez à propos de la psychologie et de la communication humaine, il
sera toujours subjective. Il n'y a pas de formule mathématique que vous pouvez utiliser, ou d'un dispositif de détection Vous pouvez
acheter, vous aider à reconnaître quand vous êtes sur le point de provoquer un problème de communication. De même
à faire prendre conscience aux autres de problèmes de communication, ils sont à l'origine. Il est sensible et compliqué,
et certaines personnes ont des années d'expérience avec les mauvaises habitudes de communication qu'ils sont disposés à
abandonner simplement parce que vous suggérez que ce qu'ils devraient. Ceci est l'une des nombreuses raisons pour lesquelles les projets
la gestion est un rôle difficile: vous avez à investir dans les relations avec les gens, quel que soit le
bien qu'ils investissent en vous.

Page 167

9.4. Projets dépendent relations

Les gestionnaires de projet sont seulement aussi bon que leurs relations avec les personnes de l'équipe. Peu importe
brillant ou informé le PM est, sa valeur est déterminée par la façon dont il peut demander ceux
traits au projet par d'autres personnes. Par exemple, parce que les programmeurs et testeurs font plus
 du travail réel, toute valeur du PM ajoute doit être à travers ces personnes. Cela ne signifie pas
les microgestion ou de devenir un expert dans ces compétences; il est de voir le rôle que PM
amplifier la valeur de ces autres travailleurs de toute manière possible.

Le défi réside dans la façon de le faire. Chaque fois que je vous ai donné une conférence ou enseigné un cours sur le projet
gestion et convaincu un groupe de ce point, quelqu'un soulève toujours la main et demande:
«Alors, comment puis-je amplifie leur valeur? Je comprends qu'il est quelque chose que je dois faire, mais comment dois-je aller
à le faire sans gêner la merde hors d'eux? "Ceci est une bonne question. Peu de gens viennent à
travailler vouloir être amplifié ou d'avoir une personne qu'ils pourraient ne pas aimer impliqués dans leur quotidien
affaires. La réponse est dans la compréhension des relations. Il n'y a pas de one-size-fits-all façon d'ajouter
valeur. Cela dépend de la personne à qui vous faites affaire avec et quelles attentes ont été fixés pour la
rôles que personne va jouer.

9.4.1. Définir les rôles

"La cause de la quasi-totalité des difficultés relationnelles est enracinée dans contradictoires ou ambigus
attentes autour des rôles et des objectifs. "

Stephen Covey, auteur de Les 7 habitudes des gens très efficaces

Dans la liste précédente des problèmes de communication, l'un des problèmes les plus importants concerne les
hypothèses et la façon de les clarifier. Les leaders, ou des rôles de gestionnaire PM sont les plus ambiguë et
les plus sujettes à des hypothèses formulées par d'autres. Tout programmeur ou testeur porteront toujours le premier
l'expérience qu'ils ont eue avec un PM (bon ou mauvais) que leur modèle quand on travaille avec tous les GP à venir. La
première fois que vous marchez dans la porte, la nouvelle équipe vous voit comme une projection de la totalité de leur précédente
expériences avec les GP. Ils assumeront des choses différentes que vous sur ce que vous pouvez faire et
la valeur que vous pouvez ajouter à l'équipe. Peu importe comment bien défini vous pensez que les descriptions d'emploi
sont où vous travaillez, il ya toujours beaucoup de place pour de mauvaises hypothèses.

Le remède le plus facile est de clarifier les rôles avec une personne importante que vous savez que vous allez travailler avec:
programmeurs, testeurs, spécialistes du marketing, les clients, ou même des cadres. Asseyez-vous avec une personne que vous travaillez
avec et de faire trois listes sur le tableau blanc. La première liste est des choses que vous êtes principalement responsable
pour. La deuxième liste est des choses que chacun de vous partager la responsabilité. Et la troisième liste est des choses qui
d'autres ont exclusivement la responsabilité. Comme vous travaillez ensemble pour faire les listes et de discuter qui
articles appartiennent où, vous allez rapidement vous reconnaître ce que vous avez des attentes de l'autre (voir Figure
2.9 ). La définition du rôle débusque toutes les hypothèses et les gens de bagages ont sur ​ce projet
les gestionnaires, les directeurs généraux, les développeurs, testeurs, ou toute autre personne est censé faire.

Figure 9-2. Rôle discussions définition aident chaque relation (ce qui est juste
une listes de exampleyour peuvent être différents de ceux-ci).

Page 168

Au minimum, vous aurez à identifier les endroits où vous n'êtes pas d'accord, et, même si vous ne les résoudre toutes,
vous serez conscient des problèmes potentiels et pouvez travailler avec plus de sensibilité sur ces tâches. La plupart
temps, des discussions utiles conduira à une meilleure compréhension des rôles et une idée plus claire de la façon dont
charge les deux parties comptent les uns sur les autres pour réussir. Mais peut-être le plus important est que cette
la discussion est un cadre, les deux parties peuvent utiliser pour discuter des problèmes de relation dans le futur. La glace
a été brisé, et il est maintenant plus facile de parler de rôles, la collaboration et la responsabilité. Si
y ait un problème plus tard, il sera facile de revenir aux listes et indiquer où quelque chose
ne fonctionne pas sur aussi bien qu'il devrait avoir.

La crainte d'avoir ces discussions est largement une question de contrôle. Dès que vous mettez en place sur le
tableau blanc quelque chose que vous aimez faire, et de l'offrir comme fourrage pour examen et débat, vous êtes vulnérable
pour l'avoir prise loin de vous (ou si la peur va). Mais en ce qui concerne la PM, la plupart des
le temps les choses de plus grand intérêt (haut niveau de prise de décision, le travail interdisciplinaire, la stratégie)
 sont les dernières choses techniquement plus programmeurs ou testeurs ciblés veulent être impliqués. En fait,
dans la plupart des cas, il ya une grande ignorance parmi les gens techniques sur ce que le PM est fait tous les jours,
et sans une sorte de discussion de rôle, ils ont aucun moyen de jamais découvrir ce que le PM fait
(Et parce que les bons chefs font souvent beaucoup de travail pour protéger les programmeurs et les testeurs de la politique,
la bureaucratie, et la stupidité de la direction générale, le reste de l'équipe ne pourrait jamais avoir un
occasion de comprendre combien le PM aide).

Dans le pire des cas, où il ya d'énormes lacunes dans les rôles perçus ("Je ne me soucie pas de ce que votre PM dernière a fait,
Je ne vais pas faire votre lessive "), il est temps de parler à votre patron et éventuellement le gestionnaire de la personne
vous avez parlé avec. Il ya rien d'alarmant: le cadre que vous avez utilisé est la meilleure façon de mettre la
la discussion à d'autres et de travailler vers une résolution. Sur les grandes équipes, je suis parfois commencé ce
discussion avec le manager de l'équipe de programmation premier, a obtenu son buy-in, et a ensuite travaillé mon
chemin vers le bas pour les programmeurs de niveau ligne. Cela a un sens si vous pensez que leur soutien est nécessaire jusqu'à
avant, ou si vous avez une meilleure compréhension commune des rôles avec lui que vous faites avec une partie de la
programmeurs de niveau ligne.

Page 169

9.5. La meilleure attitude de travail

Une hypothèse tacite du lieu de travail est que les gens travaillent dur et essayer de faire de leur
meilleur travail. Mais parce qu'il n'y a aucun moyen de mesurer la façon dont les gens travaillent fort, (6) ou ce que leur meilleur travail
ressemble réellement, les gestionnaires consacrent rarement le temps d'en parler. Ceci est une erreur. Un gestionnaire devrait
aider chaque membre de l'équipe de cultiver un désir de réussite. La relation entre le travailleur et
gestionnaire doit impliquer le gestionnaire d'aider le travailleur à être aussi efficace que possible.

Il devrait être tout à fait naturel et acceptable pour un PM de demander un testeur, développeur, commerçant, ou
concepteur de la question suivante: "Que puis-je faire pour vous aider à faire votre meilleur travail?" Pas de préface est
nécessaires, ni les mises en garde au sujet de ce que vous pourriez ne pas être disposés à le faire. Tout en demandant à ce simple
question, trois choses positives se produisent:

1. Vous établissez la possibilité que la personne à qui vous parlez est capable de faire son meilleur travail
sur le projet en cours et que peut-être il ya quelque chose pour l'empêcher de le faire.

2. Vous la mettez dans un cadre d'évaluation de sa propre performance et identifier les choses qu'elle peut
Faites cela pourrait faire une différence.

3. Vous permettre d'avoir une discussion sur ce que chacun de vous peut faire pour améliorer la qualité
du travail accompli. En encadrant la discussion autour de "mieux", vous esquiver la possibilité que
elle se sent critiqué ou que son travail actuel est pas assez bon.

Cette approche n'a rien à voir avec être un gentil garçon ou d'essayer de rendre les gens comme vous. Obtenir le
meilleure performance possible hors de l'équipe est une responsabilité directe de la PM. Comprendre comment
faire un concepteur ou un programmeur plus efficaces ne sont pas tout simplement faire cette personne une faveur, il est
améliorer la qualité et la rapidité du travail effectué sur le projet. Bien sûr, pour qu'un projet réussisse,
il pourrait ne pas exiger le meilleur travail de tout le monde, mais alors quoi. Si leur poursuite d'un niveau plus élevé ne fait pas
blesser le projectand il améliore nettement leur propre moral et un investissement personnel dans le teamthen
ça vaut le coût de poser quelques questions simples.

Parfois, quand vous demandez aux gens comment obtenir leur meilleur travail, la réponse pourrait être «Laissez-moi
seul, »ou« Arrêtez de me poser des questions idiotes », ou d'autres réponses moins-que-utile. Même si elles ne le font pas
semblent réceptifs, ils vont penser à votre question, qu'ils l'admettent ou non. J'ai eu
programmeurs haussent de ma question initiale ("Non, Scott, il n'y a rien que vous pouvez faire»), et puis venir
de nouveau à moi une semaine plus tard et de faire une excellente suggestion qui a fini par aider l'ensemble du développement
 équipe. De plus, ils me remerciaient pour les respecter assez pour leur demander leur avis.
L'attitude sous-jacente implicite par tout cela est que quand un programmeur est à la traîne, le travail de la PM
est de ne pas attribuer le blâme et lui crier de travailler plus vite. Au lieu de cela, il est de l'aider à comprendre le
problème, et de contribuer temps et d'énergie pour aider à le résoudre. Poser des questions sur son meilleur travail est un outil facile
façon d'établir une relation de soutien avec lui. Cette attitude applique à toute personne ou
organisme qui contribue au projet. Même si il ya d'autres demandes sur le temps de la PM,
il est souvent préférable de prioriser aider contributeurs directs au projet avant de politique secondaire ou
questions bureaucratiques. L'ancien aura toujours un impact direct sur le calendrier du projet, mais le
ne peut plus tard.

9.5.1. Comment faire pour obtenir le meilleur travail de personnes

Les grands leaders forcent rarement les gens à faire quelque chose. Au lieu de cela, ils utilisent tous les autres moyens en leur pouvoir
pour convaincre les gens de faire des choses. Tout le monde a ses forces et faiblesses en matière de
motiver les autres, et il en résulte que de meilleurs leaders ont tendance à avoir un plus large éventail d'outils à utiliser et
plus de commande sur eux.

Page 170

Quelque chose que je l'ai vu dans les gestionnaires et les dirigeants les plus faibles est la sur-dépendance sur une approche ou
méthode pour essayer d'obtenir le meilleur travail de personnes. Si cela une méthode ne fonctionne pas, ils abandonnent,
affirmant qu'il n'y a rien qui peut être fait. Malheureusement, pas beaucoup quand arrive le chef d'équipe
prétend qu'il n'y a pas d'alternatives. Au lieu de cela, lorsqu'on est coincé, il ya probablement un autre angle à prendre ce
pourrait fonctionner. Il est possible que vous êtes capable d'essayer une autre tactique, mais aussi envisager que quelqu'un
monde dans l'équipe est peut-être en mesure d'aider en prêtant un talent à la situation que vous ne disposez pas.

Suivez les conseils . Écoute de suggestions est une chose, mais faire quelque chose à ce sujet est une autre.
Quand ils demandent plus de temps pour certaines tâches, que cela se produise. Si elles donnent à penser qu'il existe
trop de réunions, qu'ils suggèrent des façons de les raccourcir. Les prendre au sérieux. Investir réel
l'énergie en donnant suite à ce dont ils ont besoin. Même si elle ne pas marché à la fin, si vous
prendre au sérieux le défi de remplir leurs demandes, ils remarquent. L'effet de la qualité
de leur travail sera semblable à avoir réussi. Mais, il doit être authentique. Les gens peuvent repérer
effort de gestion jeton de miles (ils ont des durées de vie d'expérience observant).

/ Confection exigences difficiles . La façon la plus évidente et stéréotypée pour une personne en
autorité pour obtenir du travail sur les gens est de demander: «40 push-ups, maintenant" Le plus intelligent,
indépendante, ou qualifiés les personnes avec qui vous travaillez sont, le moins probable cette approche ne fonctionnera. Si
la vision est bonne, le travail est intéressant, et les gens obtenir le long, il ya peu de nécessité d'exiger
rien. Motivation devrait venir naturellement. Lorsque vous avez besoin de faire du feu, de trouver des moyens astucieux pour
fais le. Placer des paris amicaux: «Si nous faisons cette date, je vais me teins les cheveux en bleu» ou «Quelle que soit l'équipe de
programmeurs corrige tous les bugs seront d'abord obtenir un barbecue après-midi sur mon bateau. " (7) demandes ont
leur place, mais ne soyez pas moyen, en toute honnêteté. «Regardez, ce qui doit être fait. Il est trop tard pour débattre
cela, et je suis désolé si je ne francs avant. S'il vous plaît, juste tenir cela pour moi. D'ACCORD?"

Inspirante . Il est très difficile de faire semblant d'inspiration. Soit vous croyez en ce que vous faites, ou vous
pas. Si vous ne croyez, alors vous devez trouver un moyen de l'exprimer d'une manière positive afin
que d'autres personnes peuvent se nourrir de lui. «Regardez. Je adore ce projet. Nous sommes payés pour apprendre de nouvelles
technologies et de comprendre comment les appliquer. Voilà rare et spécial, et ça me fait de venir
ici chaque jour. "Il n'a pas à être complexe ou même éloquent. Si elle est honnête, il fonctionne.
La nature humaine va et vient émotion positive, et quand vous apportez quelque chose de réel, vous
inviter les autres à suivre. Plus de méthodes directes comprennent les personnes demandant ce qu'ils aiment sur l'écriture
code, et les aider à établir des liens entre ces sentiments et le travail qu'ils ont en
devant eux.

barrages de compensation . Chaque grande course de retour dans le football américain avait un héros méconnu qui
ouvert la voie pour lui. Ce héros méconnu est appelé le bloqueur (aka le centre-arrière). Il court dans
avant de la marche arrière et frappe sur le premier mec qui essaie de plaquer le running back
(Généralement quelqu'un de beaucoup plus grand que ce qu'il est). Si vous regardez attentivement toute bobine de point culminant où
quelqu'un court pour 70 verges, vous verrez un autre gars à plat sur le sol, enterré sous
diverses grandes personnes, qui était responsable de faire le jeu possible. Les bons chefs font écoutes
possible. Ils cherchent et éliminent les problèmes qui ralentissent l'équipe vers le bas. Demandez aux gens: "Etes-
vous avez bloqué par quelque chose? "Si ils disent qu'ils sont en attente d'une décision, ou d'essayer de traquer
information, il est de votre devoir de déterminer si il n'y a aucune façon, vous pouvez accélérer ce processus. Ils
devrait savoir que vous êtes disponible pour aider si jamais ils se sentent bloqués.

Rappelez-leur de vos rôles respectifs . La façon la plus fréquente pour permettre le meilleur travail est de
rappeler aux gens de leurs rôles dans l'équipe. Quand un programmeur se plaint qu'elle devient
trop de demandes de nouvelle fonctionnalité, la réponse devrait être qu'il est probablement pas son travail au champ
demandes: elle devrait diriger les gens vers vous (PM). Elle est libre de se comporter si elle estime qu'il est
appropriée, mais si elle est en retard dans le calendrier, elle doit utiliser le PM pour exécuter des interférences.
Parfois, les gens, en particulier les programmeurs, sont tellement concentrés sur le travail lui-même qu'ils perdent
vue les testeurs, les concepteurs et les gestionnaires autour d'eux qui sont souvent mieux adaptés à conduire
certains types de tâches que ce qu'ils sont.

Rappelez-leur les objectifs du projet . Comme le Premier ministre ou un leader, vous avez plus de recul sur la
projet que tout individu. Il est facile pour les gens de se perdre dans la complexité de leur étroite
domaines de responsabilité et perdent la trace de ce que les questions sont vraiment importantes. Une courte conversation
avec vous, où que vous actualisez leur compréhension de ce qu'ils sont vraiment accomplir et pourquoi,
 peut restaurer leur attention, la motivation, et l'efficacité. Comme les feux d'atterrissage qui identifient un
piste de l'aéroport dans la nuit, le rendant facile pour les pilotes de repérer leur chemin vers la sécurité, les bons chefs éclairent le
façon.

Page 171

Enseignement . Si vous avez une compétence ou un truc que les gens avec qui vous travaillez peuvent faire usage de, pourquoi ne pas offrir
à leur enseigner? En leur donnant une nouvelle compétence ou une astuce pour l'aide d'un ancien double la valeur de
que la connaissance. Par l'enseignement, vous rendez possible pour les gens de faire travailler plus vite et
d'améliorer les chances de les faire du bon travail, ainsi que, éventuellement améliorer la qualité de
ce qui est leur meilleur travail. Noel Tichy, auteur de Le moteur Leadership (Harper, 2002), a cette
à dire sur l'importance de l'enseignement: «Vous parlez à un Navy SEAL [après qu'il a appris
quelque chose] et l'une des premières choses qu'il fait est enseigner son copain, car il va lui sauver la vie.
Si je apprends quelque chose ... puis-je lancer arrière et enseigne aux gens? Alors que je peux faire que sur une plus grande échelle?
Voilà l'astuce. "

Demandé . Il semble évident, mais il est rarement fait. Il suffit de leur demander leur meilleur travail. Vous ne le faites pas
besoin d'expliquer pourquoi, ni même nécessairement offrir quelque chose en retour. Il suffit de dire, "Hey, je serais ravi de voir
votre meilleur travail ici. Ce travail est important et si vous avez plus à donner, je voudrais que vous lui donnez
maintenant. "

9.5.2. La motivation à aider les autres à faire de leur mieux

Dès le début de mon temps avec l'équipe de Windows, je me souviens de sentir comme je passais tout mon temps à aider
d'autres personnes à faire leur travail. Je suis relativement nouveau gestionnaire (comme dans ayant des rapports directs), et après
courir aider les gens à éteindre les incendies et de donner des conseils, je voulais juste être seul. J'ai essayé
aller à mon bureau et de fermer la porte, mais les gens ont continué à venir par. Ma messagerie vocale lumière ne serait pas
arrête de clignoter, et je ne veux même pas regarder l'email qui avait accumulé pendant que je courais
autour du bâtiment. Je me souviens de se demander pourquoi je passais beaucoup de temps dans les bureaux d'autres personnes, et
il m'a fallu un certain temps pour arriver à une réponse que je croyais. Mais je trouvai un, et elle est ici.

Ces conversations ne sont pas des choses éthérées ou anecdotiques. Dans chacun de ces conversations, je étais
faire quelque chose directement lié aux objectifs du projet. Cela va au-delà de l'abstrait
importance de bonnes relations. Chaque fois que je répondu à une question à ma porte, négocié avec
une autre organisation, ou plaidé pour des ressources pour mon équipe, je faisais autant que tout développeur ou
Tester pour faire avancer le projet. Je leur ai permettant d'écrire du code, trouver des bogues, et à faire de 1000 l'autre
les choses rapide ou plus facile que ce qu'ils auraient autrement.

Mon point est que si vous examinez attentivement les conversations que vous avez avec les gens, et de tenir compte de leurs
impact sur le projet, vous trouverez généralement toutes les conversations contribue à l'une des suivantes
choses:

Améliore la qualité de ce qui est fait

Augmente les chances qu'il sera terminé à temps

Contribue à rendre le produit / site web / logiciels plus utile pour les personnes

Augmente les chances du produit / site web / logiciels vont générer des profits ou de la circulation

Protège les gens contre le travail inutile, la politique stupides, ou de la bureaucratie

Fait ce qui se construit plus facile à entretenir

Augmente le moral ou le bonheur du peuple de l'équipe

Aide à l'équipe de travailler plus intelligemment et plus rapidement, et d'appliquer (et apprendre) de nouvelles compétences

Élimine ou clarifie le comportement qui est préjudiciable au projet ou à l'équipe

Donc, même si vous vous lassez de compensation des barrages routiers, de répondre aux questions, ou le contrôle avec différents
personnes pour différentes raisons, rappelez-vous que l'effort que vous mettez dans ces choses ne soit pas gaspillé ou de
faible importance. Tant que vous pouvez connecter ces discussions, entretiens de dynamisme, des exercices d'incendie, des arguments et
discussions retour à des tendances positives dans le projet (ou la prévention des négatifs), ils sont
indispensable pour faire avancer le projet. Vous êtes travail à faire que personne d'autre dans l'organisation peut
éventuellement faire aussi efficacement que vous le pouvez. Toutefois, si vous trouvez que vous ne pouvez pas attacher ces conversations Retour

Page 172

à des choses importantes, arrêter de les avoir. Prioriser votre temps et vos relations, afin que votre
énergie va vers les choses qui ont le plus grand impact positif.
Page 173

9.6. Résumé

Projets ne se produisent que par la communication. Dans les temps modernes, la vitesse est pas la communication
goulot d'étranglement, la qualité est.

Relations améliorer et d'accélérer la communication.

Il existe plusieurs cadres de la façon dont les gens communiquent les uns avec les autres. PM devrait être
familier avec eux afin qu'ils puissent diagnostiquer et résoudre les pannes de communication.

Il ya plusieurs problèmes de communication commun. Ils comprennent: les hypothèses, le manque de

clarté, ne pas écouter, la dictée, des attaques personnelles, et le blâme.

La définition des rôles est la meilleure façon d'améliorer les relations.

Demandez aux gens ce dont ils ont besoin afin de faire de leur mieux. Moyens pour ce faire comprennent: l'écoute,
compensation des barrages routiers, l'enseignement, et en leur rappelant de buts.
 Relations et la communication
activités individuelles ne sont
qui ont lieu pas les
au cours travaux
d'un projet.de faible priorité. Ils sont essentiels à l'ensemble de la

Page 174

Chapitre Dix. Comment ne pas ennuyer les gens:

processus, le courriel et réunions

Bureaucratie (n): Un système administratif dans lequel le besoin ou l'envie de suivre rigide ou
procédures complexes entrave une action efficace.
 Plus votre équipe, plus les chances sont que vos activités de gestion de projet va ennuyer
quelqu'un. Chaque fois que vous suivre le travail de quelqu'un d'autre, ou de prendre des décisions qui ont un impact d'autres, vous voulez
potentiellement gêner quelqu'un; il est livré avec le territoire. Si vous êtes intelligent, vous aurez l'air des façons d'être
efficace sans gêner les personnes avec qui vous travaillez. Ils seront plus heureux, le projet sera mieux fonctionner,
et vous aurez moins de regards réprobateurs de gens dans le couloir.

Les trois activités avec les plus grandes chances de gens ennuyeux sont email, réunions, et de l'équipe
processus (par exemple, de construire ou de procédures de SPEC). Ce chapitre se déroulera à travers les erreurs les plus courantes et
approches de base pour effectuer ces tâches avec un facteur de risque de gêne minime (aka MARF).

Page 175

10.1. Un résumé de pourquoi les gens se fâchent

Parce que je ne pouvais pas trouver une histoire publiée de gêne, je me fie à mes propres observations
résumant pourquoi les gens se fâchent. Je dois une bonne quantité d'expérience dans ce domaine: je suis
plusieurs fois agacé, ont vu d'autres personnes dans un état de gêne, et ont été connus
à l'occasion, ennuyer les autres. Bien qu'il existe certainement d'autres causes de nuisance au-delà de ceux
dans la liste suivante, ce sont les plus communs et les plus importants que je connais.

Pour le plein effet dans la compréhension de ces exemples, ils sont décrits à la première personne (il peut
aider à penser d'une personne spécifique que vous avez une expérience de travail avec qui vous respectez, lors de la lecture
à travers ces).

Supposons que je suis un idiot . Si je l'ai été embauché pour faire X, dont je suis capable de faire, à tout moment
quelqu'un me traite comme si je ne peux pas faire Xor besoin d'une procédure en 20 étapes, sous forme de livret de règles, modèle,
évaluation quotidienne, comité ou autre processus pour me permettre de faire XI sera juste agacé.
Une partie de mon travail devrait être d'aider à définir mon travail d'une manière qui satisfait quelles que soient les objectifs
décrets de gestion. Mais jusqu'à ce que je ne l'incompétence et de prouver, je devrait être traitée comme
compétente. Je devrais être libre de définir, dans la raison, la meilleure façon de faire mon travail.

Ne pas me faire confiance . Si, sur une base quotidienne, je suis attendu à l'arrivée, une double vérification, triple vérification, et
rapport sur les décisions qui sont bien dans la gamme de mes responsabilités, je serai ennuyé. Si je
doit confirmer tout, quelle autorité dois-je vraiment? Pourquoi tout besoin d'être
documenté et enregistré, si je fais un bon travail? Même si je ne suis pas digne de confiance d'abord pour certains
raison, il devrait être le travail de gestion pour fournir une voie juste pour moi de gagner la confiance et aider
moi des progrès sur cette voie.

Perdre mon temps . Si la façon dont les fonctions de l'équipe me force à répéter des tâches fastidieuses (nombre)
fois, ou vont bien sortir de ma façon de se protéger contre les imprévus et paranoïas de gestion
qui sont comiquement peu probable et insignifiant, je serai ennuyé. Cela comprend volte-face sur
décisions importantes ou étant gravement incohérent dans la messagerie ou le comportement sans faire de
tenter de l'expliquer (ou au moins des excuses pour lui), même lorsqu'on lui a demandé.

Gérer moi sans respect . Si je suis jamais envoyé sur une chasse aux oies sauvages, étant donné les affectations
qui ont aucun fondement dans la réalité, ou mis en place à l'échec et prendre le blâme pour les choses au-delà de mon champ d'application de
la responsabilité, je serai ennuyé. Quelqu'un devrait être à la recherche pour moi et en vous assurant de mon
efforts aligner avec le projet de me guider vers le succès. Par conséquent, mes demandes de
assistance devrait être pris au sérieux et ne pas être trop retardée ou ignorée.

Fais-moi écouter ou de lire des choses stupides . Chaque fois que je suis obligé d'écouter quelqu'un d'autre
ou lu quelque chose une autre personne a écrit qui n'a aucune incidence significative sur le nous de travail
font, je serai ennuyé. Nous avons un bar de triage pour la qualité de bug: pourquoi ne pas l'un pour la stupidité?
Juste parce que quelqu'un convoque une réunion, écrit un papier, ou envoie un e-mail ne signifie pas qu'il est
valeur de mon temps. Les choses plus secondaires ou tertiaires, je me pose (ou forcé) à faire, moins
productive et je suis heureux.

La plupart de ces raisons pour expliquer pourquoi gêne beaucoup de gens détestent l'idée de processus de travail.
Ils craignent que toute tentative de systématiser leur travail ne peut résulter que de la bureaucratie ou d'autres formes
de la souffrance. Je pense que la crainte est infondée. processus de conception des gens, comme tout le reste, et si
le concepteur est intelligent et a les bons objectifs à l'esprit, les processus peuvent bénéficier tout le monde. Processus
peut aider les gens au lieu de restreindre et de les ennuyer.
Page 176

10.2. Les effets de bon processus

Je définis un processus que tout ensemble d'actions reproductible une équipe décide de se produire sur une base régulière pour
assurez-vous que quelque chose est fait d'une certaine manière. Processus vont par beaucoup de noms: règles, directives,
formes, des procédures ou des restrictions. (Par exemple, comment le code est vérifié dans, testé et construit est un
exemple courant d'un processus d'ingénierie. D'autres incluent l'écriture et commentaires spec, recherche de bugs,
la gestion des calendriers et des horaires, etc.) Un bon processus améliore les chances de l'être du projet
complété et a des avantages qui l'emportent sur ses coûts. Cependant, parce que le temps est rarement passé
se demander pourquoi certains procédés existent, ou quels problèmes ils (doivent) résoudre, de nombreuses équipes vivent avec
beaucoup de processus, sans les avantages qu'ils peuvent fournir.

Parfois, le problème est de savoir qui est au pouvoir. Quel idiot avec suffisamment d'autorité peut venir avec le
les plus abrutissantes système idiot pour faire quelque chose et essayer de forcer l'équipe à suivre.
Puis, quand l'équipe gère non seulement de survivre, mais ce processus fait expédier quelque chose, le
personne au pouvoir peut même pointer vers le processus en tant que contributeur à la réussite (aveugles au fait que
l'équipe a réussi en dépit du processus stupide). Si elles ont assez de puissance, ils peuvent étouffer
des mutineries ou les appels à la santé mentale et continuer à torturer l'équipe en ajoutant encore plus de procédures.

D'autres fois, le problème est la philosophie: "X a travaillé avant, donc faisons-X." Dans cette situation, un
chef d'équipe qui a fait quelque chose d'une certaine manière dans le passé insiste sur infligeant cette méthode ou
processus à chaque nouvelle équipe qu'il dirige (cette mauvaise habitude de gestion est mentionné dans le chapitre 8 ). C'est
mauvaise parce que le succès préalable avec X est pertinente que si la situation actuelle est similaire à des situations passées.
Le véritable test d'acceptation pour un processus devrait insister sur les besoins de la présente plus observations
sur le passé.

Mais la plupart du temps, le problème est la complexité de la création de processus. Un processus tente de
organiser la façon dont les gens travaillent et comment ils interagissent, deux choses importantes critique mais très organiques.
Les gens travaillent différemment. Ils ont des préférences différentes et tolérances pour les contrôles formels. Si le
personne qui crée le processus ne fait pas attention, le processus peut facilement devenir un goulot d'étranglement, le ralentissement de personnes
vers le bas et leur constriction (sens de) la liberté et l'émancipation.

L'astuce dans la création de bons processus est de comprendre deux choses en combinaison: ce qui rend
les projets et les équipes qui réussissent en général, et ce qui rend le projet actuel et équipe différente
d'autres (voir la Figure 10-1 ). Il ne suffit pas de savoir comment passes de test doit être effectué en général;
vous devez tenir compte de la culture, la personnalité et les habitudes de l'équipe de test actuel vous travaillez
avec. Parfois, la culture ou le projet exige une approche différente (par exemple, les processus de test pour
systèmes par rapport aux processus de test pour le site Web de punk rock le groupe de Steve) antiblocage de freinage intégré.
Au lieu de réguler par le haut, il est souvent préférable de laisser l'équipe d'auto-réguler. Au lieu de réutiliser le
modèle standard, permettent de les modifier et de créer leur propre. Tout comme n'importe quel genre de négociation (voir
Chapitre 11 ), quand il vient à traiter, vous devez être clair sur les intérêts que vous vous souciez et non
les positions spécifiques.

Figure 10-1. Bon processus nécessite d'avoir un sens pour les projets en général,
ainsi que les attributs uniques du projet actuel.

Page 177
 Pour vous aider à la fois à trouver et à reconnaître les bons processus, voici une liste des attributs et les effets qu'ils vont
avoir sur le projet. Ceci peut être utilisé comme une liste de contrôle lorsque vous vous asseyez pour créer ou affiner un processus.

Ils accélèrent le progrès . Comme paradoxal que cela semble, de bonnes procédures rendent les gens
plus efficace, pas moins efficace. Par exemple, les séparateurs de voies blanches sur les routes américaines
restreindre où vous pouvez aller dans votre voiture pendant que vous conduisez. Mais parce qu'ils fournissent la même
restriction pour tout le monde, ils fournissent un ensemble de base de règles qui permettent aux conducteurs individuels d'aller très
rapide (et de se déplacer ceux qui conduisent très lent). Les gens peuvent avoir confiance que les autres pilotes
suivre ces règles. Bon processus fournit un système que les gens peuvent compter et les décisions de base
sur. Dans certains cas, le processus définit les rôles que les gens vont jouer, ce qui le rend facile pour
Steve pour obtenir ce dont il a besoin à partir de Molly (par exemple, trouver quelqu'un pour faire une revue de code). Un canonique
exemple est automatisé des outils et des processus qui permettent aux gens de construire des projets avec quelques constructions
frappes, à condition qu'ils respectent les conventions de codage nécessaires définies par le système de construction.

Ils empêchent les problèmes . La motivation la plus courante pour mettre en place un processus est de
éviter une sorte de stupidité de passe (à nouveau). Le défi est de le faire sans
faisant simultanément des progrès plus difficile, ou d'encourager de nouveaux types de stupidité. Ce
il faut comprendre les causes du problème et quels sont les facteurs les plus importants pour
progrès. Demandant simplement à la question «Qu'est-ce que la moins intrusive, moins ennuyeux, et le moins
moyen coûteux de faire en sorte que X, Y et Z ne se reproduise jamais? "contribue de manière significative. Ou,
dans l'autre sens, quand on regarde à tout processus existant, demander «Quel est le problème le fait
empêcher de se produire? Comment grave ou probable est le problème? "Si un processus ne l'empêche pas
problèmes ou accélérer les progrès, envisager de se débarrasser de celui-ci (voir la section suivante " Une formule
de bons procédés »).

Ils font d'importantes actions visibles et mesurables . Processus d'ouverture des bogues ou
Fiche d'édition, il est facile de suivre combien de fois ces choses sont faites. Vous pouvez également facilement
le suivi de leur état, quels étaient les résultats, et quelles sont les tendances de l'équipe sont à l'échelle. Pour importante
des choses comme des bugs, spécifications, tests, un bon processus, il sera facile de savoir ce que l'état de
le projet est, et de comparer l'état actuel du monde contre où le projet était et
doit être. Ceci est important pour la mi-jeu et des stratégies de fin de jeu (voir les chapitres 14 et
15 ).

Ils comprennent un processus de modification ou d'éliminer le processus . Parce que les projets et
les équipes changent tout le temps, un processus qui est utile ou nécessaire un mois, peut ne pas être
utile ou nécessaire le mois prochain. Le processus lui-même doit avoir un mécanisme intégré pour
décider quand il est plus utile ou quand il doit être mis à jour pour le rendre de nouveau utile.
Ne présumez jamais qu'un processus sera durer éternellement, et éviter de définir des emplois autour de processus pour
cette raison. Quelqu'un qui identifie son travail comme «Le gars qui dirige passe de test 5" aura tendance à
défendre passe de test 5 avec sa vie et craindre des changements. C'est mauvais. Au lieu de cela, les gens
responsable des effets et les résultats des processus ont sur le projet.

Les personnes touchées par eux sont en faveur d'entre eux . Des gens comme les processus utiles. Un bien
processus sera considéré comme souhaitable de ceux qui en ont besoin. Si vous proposez un nouveau processus qui
impacts testeurs ou des programmeurs, et votre processus est précieux pour le projet, il ne devrait pas être trop
difficile de les amener à essayer. Ou, plus au point, les gens devraient être directement impliqués dans
venir avec le nouveau procédé en premier lieu. Bien sûr, certains convaincante peut être nécessaire
(Le changement se produit rarement sans persuasion). Mais si le problème que vous essayez de résoudre est réel,
et les gains de productivité sont réels, l'équipe devrait avoir toutes les raisons d'être positive

Page 178

motivé. Alternativement, si les gens qui le processus proposé impact peut énumérer
des dizaines de raisons pour lesquelles le processus est une mauvaise idée, ils sont probablement raison. (Mais si le problème est
réelle, ne pas abandonner. Demandez-leur pour une contre-proposition.)

10.2.1. Une formule de bons procédés

Une façon de penser au sujet du processus est la valeur de ses effets positifs par rapport aux coûts de mise en
placer et exécuter. Il ya une formule pour ce qui peut aider. Vous ne devez pas venir avec réelle
numéros de cette formule comme étant utiles. Je vous l'offre surtout comme un exercice pour vous aider à réfléchir sur le
compromis nécessaires pour ajouter des processus d'ingénierie. Si vous ne l'aimez exercices ou des formules, passez à
la section suivante: vous ne manquerez pas une miette.

Tout d'abord, prendre en considération les coûts du processus: le temps de concevoir le processus (DT), le temps pour l'équipe de
apprendre (LT), le temps réel pour faire le travail avec le processus, multiplié par combien de fois il est fait (AT * N).
Le coût total pour tout processus sont DT + LT + (AT * N).

Ensuite, considérer les avantages du processus: les coûts d'échecs les évite de processus (FC), multiplié
par la probabilité que ces défaillances se produisent (FP) sans que le processus, dans une unité de temps donnée,
 multiplié par le nombre de ces unités de temps sont dans le projet (T). Le total des prestations = (FC * FP) * T.
Le résultat est à peu près ceci: processus value = ((FC * FP) * T) - (DT + LT + (AT * N)).

Je reconnais pleinement qu'il ya toutes sortes de simplifications grossières dans cette formule, mais l'esprit de celui-ci est
assez près pour le rendre intéressant. Si le résultat est un nombre élevé, il n'y a plus de valeur que si elle est un
faible nombre. Un chiffre négatif signifie que les avantages du processus ont été compensés par la
coûts.

Cette formule implique, d'abord, qu'il est très facile de créer un processus qui élimine efficacement une
problème. Cependant, le prix de le faire peut coûter plus d'une vie de vivre avec les menaces de
ce problème particulier (par exemple, l'achat d'un système de sécurité 5000 $ pour la jarre à biscuits). Si vous incluez
la conception et le temps d'apprentissage, et de reconnaître qu'il ya une probabilité de seulement œuvres échec, coût-bénéfice
contre le changement de processus.

Cependant, vous devez tenir compte de la durée de vie des avantages: ils seront souvent couvrir plus d'un seul
projet. Mieux les procédures d'enregistrement ou de construire ont des cotes élevées d'être utile pour ce qui vient ensuite.
Plus important peut-être, est que la probabilité de défaillance se produisant au cours des prochaines
projets peuvent augmenter jusqu'à 100%. La valeur de T dans la formule est important: même si la probabilité d'une
échec (FP) est faible, plus l'intervalle de temps, plus les chances de l'échec produisent et
traiter empêchant ayant une valeur. (Cette situation expose l'un des principaux défis d'être un chef de file:
décider quand à payer les coûts tangibles à court terme pour les retours moins tangibles à long terme. Ce
défi revient partout: l'embauche, de l'équipement, les installations, la formation, etc. Vous récoltez ce que vous
semer. Les placements à long terme sont le seul moyen d'obtenir des améliorations à long terme.)

Et comme une dernière note à propos de cette formule: la valeur AT (heure réelle d'utiliser la procédure) est plus
important que cela puisse paraître. Un bon processus devrait rendre les choses prendre moins de temps: AT devrait avoir un
valeur négative par rapport à la façon dont le travail a été fait sans la procédure, si elle est vraiment un gain de temps. Ce
modifie la relation entre les coûts / avantages car il est structuré dans l'équation. Par exemple, si AT = 5
heures, mais auparavant la tâche a pris 7, la valeur nette est de 2 heures. Cela signifie que la tâche prend maintenant
deux heures de moins à faire, et la valeur globale du processus est beaucoup plus élevé.

10.2.2. Comment créer et déployer des processus

Lorsque vous identifiez un problème que vous pensez peut être résolu avec un processus, suivez la même rugueuse
Je vais décrire la procédure de chapitre 11 . (Même si vous n'êtes pas dans une crise, la procédure de base de
exécute un plan à court terme est similaire.) Définir clairement le problème que vous essayez de résoudre et de la
petit groupe de personnes les plus aptes à aider à le résoudre. Travailler comme alternatives génératrices de petits groupes
propositions et ensuite choisir la plus prometteuse.

Page 179

Ensuite, identifier une partie à faible risque isolé de projet pour piloter ce nouveau processus sur. Si possible, choisissez
les individus qui sont intéressés et réceptifs au changement de processus et de les impliquer dans le
création du processus. D'accord sur ce que les effets du changement de processus devrait avoir désiré, et si
, mis en place les mesures possibles pour eux. Ensuite, les personnes impliquées ont faire le changement. Définir une
date dans le futur afin d'évaluer l'efficacité du processus de changement a été.

Lorsque ce jour d'évaluation arrive, rencontrer de nouveau le petit groupe et les personnes impliquées dans le
pilote. Discutez de ce qui est arrivé. Si le pilote a été un désastre, répétez le processus et de faire un second petit
pilote. Sinon, réviser le processus sur la base de ce que vous avez appris, et l'étendre à un plus grand groupe
(Peut-être toute l'équipe). Il devrait être clair pour tout le monde vous demande d'utiliser le processus quels problèmes
vous essayez de résoudre et pourquoi vous êtes convaincu que la solution proposée aidera réellement (la
des preuves et des témoignages que vous avez des personnes impliquées dans le projet pilote devrait permettre une tonne).

10.2.3. Gestion de processus ci-dessous

"Ne jamais sous-estimer le pouvoir des gens stupides dans les grands groupes."

Todd Blanchard

Parfois, les personnes ayant plus de pouvoir que vous infligent les processus de votre équipe que vous n'êtes pas d'accord
avec. Vous pourriez être tout simplement en infériorité numérique ou sans le pouvoir de réviser le processus. Il arrive à
le meilleur de nous. Je sais que de trois moyens pour faire face à cette situation. Ils ne fonctionnent pas toujours, mais ils sont
vaut le coup.

Protégez votre équipe du processus . Parfois, vous pouvez absorber le processus pour votre équipe.
Si une forme ou une paperasse qui doit être fait de faire quelque chose, faites-le vous-même. Ce
pourrait vous faire sentir comme leur secrétaire, mais si il est seulement une question de vous brûler quelques minutes
chaque jour ou chaque semaine afin que votre équipe ne doivent pas, le commerce pourrait être entièrement en vaut la peine. Dans
certains cas, vous marquer beaucoup de points de confiance avec votre équipe pour les protéger contre la stupide
les choses. Cartes de temps, rapports de dépenses, obligatoires (mais ridicules) réunions de type RH, de l'équipement
réquisitions, et d'autres forum ennuyeux sont des exemples courants de processus facilement blindés.

Pariez contre le processus . Rallier votre équipe autour d'une contreproposition au processus. Découvrir
ce que les choses le processus tente d'empêcher ou d'assurer et de garantir aux pouvoirs en place
 que
une votre équipeSivavotre
évaluation. répondre à ces
équipe objectifspas
ne parvient sans le processus.
après ce moment, Définir
vous un certain
serez laps pour
d'accord de temps pourlefaire
adopter processus. Mais si elles
réussissez, vous allez prendre la proposition sur la table. Si rien d'autre, ce concentre le processus
discussion sur les bonnes questions (quel est le problème que nous essayons de résoudre?), de sorte que même si vous échouez, il sera
être un processus amélioré. (Dans de rares cas, la recherche sur d'autres similaires et réussie
organisations qui ne font pas ce que le processus est, ou le faire d'une manière différente et moins stupide,
peut marquer des points et d'éviter la nécessité pour le pari.)

Ignorer le processus . Je dois une tendance à ignorer lointain, ambiguë, bureaucratique,

organisationnelles choses que je ne comprends pas. Ma théorie est que en l'ignorant, je force un des
deux choses se produisent. Soit la personne responsable de la chose me contacter et me demander
pourquoi je ne le fais pas, me donner une chance d'avoir un dialogue avec lui au sujet de pourquoi je devrais le faire du tout;
ou, si personne ne me demande pourquoi je ne le faisais pas, alors il ne peut absolument pas être si important pour tout le monde (ou
au moins mon faire ou ne pas faire, il n'a pas d'importance). Je vais aller sur mon entreprise, réussir
sans la chose en question, et avoir une bonne justification si quelqu'un me demander un jour
pourquoi je ne fais pas cette chose ("Oh. Eh bien, nous avons fait X très bien sans elle. Peut-être que vous pouvez convaincre
moi comment Y aurait aidé? "). Cela fonctionne souvent mieux dans une nouvelle organisation parce que vous avez
l'excuse de l'ignorance ajouté l'organisation. Soyez averti, cependant: votre paysage politique
peut être dangereux d'ignorer la bureaucratie.

Page 180

10.3. E-mail non-gênant

Comme correctives un sujet comme il semble, email du système est toujours les gens les plus ennuyeux sur des projets beaucoup
avec. Simplement en raison du volume de courriels que nous recevons, il est facile de sentir la pression à lire et à
répondre aux nouveaux messages aussi rapidement que possible, sacrifiant souvent de bonnes compétences en lecture et écriture.
La plupart d'entre nous, la plupart du temps, il suffit de ne pas lire ni écrire email très bien. Ce qui est ironique est que la vitesse
et la commodité d'email sont gaspillées lorsque nous ne pouvons pas comprendre ce que l'enfer l'autre personne
essaie de dire, ou nous ne pouvons pas lui faire comprendre ce que nous essayons de leur dire.

Et peut-être la plus grande importance à la gestion de projet: e-mail est un des principaux moyens de
communication pour les dirigeants et les gestionnaires. Dans les deux créer un nouveau message et répondre au courrier envoyé par
d'autres, un influences leader et contrôle la circulation de l'information à travers un projet. Si un dirigeant a
les pensées claires et pose des questions solides, elle encourage les autres à faire de même. Une réponse à un
grande discussion avec des dizaines de personnes peut envoyer une vague de clarté à travers l'organisation. Mais le
chef mal la capacité de l'équipe à bien communiquer si elle exprime des pensées et des marques floues
points obscurs ou obfusqués.

Un défi majeur est que peu de gens admettent qu'ils envoient mauvaise email. (Leur incapacité à reconnaître
mauvaise email fait partie des raisons pour lesquelles ils sont mauvais à l'écrire) Par exemple, prendre le test suivant:. utilisant votre
propre jugement subjectif, quel est le pourcentage de courriels que vous recevez de personnes au sein de votre propre
l'organisation est de haute qualité? Qualité moyenne? Totalement inutile? Maintenant demandez-vous quel est le pourcentage de
l'e-mail que vous envoyez inscrit dans chacune de ces catégories. Comme une expérience, je une fois demandé à un petit groupe
des MP, testeurs et programmeurs de cette question très. Par un facteur de près de 2 à 1, tout le monde selon
que d'autres personnes ont écrit électronique crappier qu'eux. Parce qu'ils ont tous travaillé ensemble, ce
données anecdotiques implicite que tout le monde pense que le problème est email généré par d'autres, pas
eux-mêmes. Je ne ai pas de données dures pour soutenir cette revendication, mais il sonne vrai. D'une certaine façon, quand il ya
une panne de communication, sur la moyenne des gens ont tendance à blâmer l'autre gars (des preuves abondantes, voir
toute l'histoire de la politique internationale dans la civilisation occidentale).

10.3.1. Le bon morceau de courriel

Une habitude je appris à Microsoft était la récompense pour le bon morceau de courriel. Beaucoup de débats importants
a eu lieu le courriel, et il était courant que ces discussions incluent les personnes à de multiples niveaux
hiérarchie; PMs ligne, les cadres intermédiaires et les vice-présidents pourraient tous être l'échange du courrier avant et en arrière,
le traitement de l'autre la plupart du temps comme des égaux. Je me suis souvent retrouvé au milieu de ces débats, habituellement
parce que quelque chose je étais responsable est soudainement devenu très important pour la division.

Chaque si souvent dans ces discussions par courriel, je ferais un point très fort en réponse à quelque chose
quelqu'un d'autre a dit. Je voudrais mot soigneusement, réviser à plusieurs reprises pour obtenir la droite juste: simple, robuste,
et claire. Puis je l'envoyer. Parfois, mes arguments seraient obtenir déchirée; parfois, je serais
ignorées. Mais à l'occasion, je serais frappé un home run. Lorsque je l'ai fait, je reçois souvent un courriel privé à quelques minutes
plus tard, d'un vice-président ou «autre personne beaucoup plus important que je» qui dit que deux mots: "Bon
e-mail. "La discussion pourrait encore rage sur, mais je voudrais savoir que je marque quelques points dans l'argument.
Plus important est ceci: quelqu'un a pris le temps de me faire savoir que mes points étaient bons, et que
 Je les exprimais d'une manière louable. (1)
Gestionnaires intelligents bonne valeur email. Gestionnaires lu tant de choses mal écrites email tous les jours, et si
ils ne prennent pas le temps de récompenser ceux qui communiquent bien, ils sont peu susceptibles de voir plus de gens
fais le. Petits courriels indésirables prennent environ 15 secondes pour envoyer, et que mon histoire indique, peuvent signifier plus
à d'autres dans votre organisation que vous le pensez.

Mais louant les autres est plus facile que de prendre la responsabilité de vos propres habitudes de mauvaises email. Comme je l'ai
mentionné précédemment, je suis convaincu que la plupart des gens pensent, écrivent-ils mieux que d'autres email
pensent qu'ils font (et le plus expérimenté que vous êtes, plus il est peut-être d'obtenir une rétroaction honnête au sujet de
votre email étiquette). Parce que les dirigeants et les gestionnaires envoient plus email que d'autres, il est essentiel de

Page 181

trier ce mauvaises habitudes que vous avez et investir de l'énergie dans les freiner. Voici quelques projets
des conseils de gestion de style sur ce bon email ressemble et ce que certains des mauvaises habitudes communes
sont.

Soyez concis, être simple, et être direct . Pascal, le mathématicien pour qui la langue est
nommé, une fois écrit "Si je devais plus de temps, je voudrais écrire une lettre courte." Langue, comme le code, peut être
optimisé, bien que les objectifs sont différents. Au lieu de l'optimisation de l'efficacité logique, vous
Vous voulez optimiser l'efficacité de la communication. Contrairement code, un grammaticalement et logiquement
bon message en trois mots est inutile si le destinataire ne peut pas comprendre ce que l'enfer que cela signifie. (2)
Songez à qui est en train de lire l'e-mail et comment vous expliquer ou demander tout ce que vous devez
dire si vous parliez avec lui face à face. Quels sont les détails qui serait nécessaire? Omis? Quoi
concepts peuvent vous supposez qu'il sait? Que pouvez-vous utiliser des métaphores? Pour e-mail important, étape
loin de lui pendant quelques minutes, puis le relire, avec ces questions en tête, avant de vous
envoie-le. Ou pour un courrier important, ou par courrier aller à un grand nombre de personnes, avoir l'un des
personnes de votre équipe écrémé-dessus et vous donner des commentaires.

Offrez une action et une date limite . Le meilleur type de courrier électronique a une intention ou demande spécifique
qui est clairement indiqué, et, le cas échéant, est liée à un délai raisonnable. Il devrait être facile pour
personnes lisant l'email à comprendre pourquoi ils reçoivent, comment ils sont touchés par
l'action, et ce qu'ils doivent faire (avant la date limite). En supposant que vous appliquez la date limite
("Demandes doivent être faites au plus tard le vendredi moi"), vous définissez vous-même pour les gens à être attentifs à
actions futures vous communiquer par e-mail, qui vous met dans une position de pouvoir.

Prioriser . Est-il vraiment nécessaire d'envoyer cet e-mail? Les plus de courriels que vous envoyez, plus le travail
d'autres devront faire pour prioriser vos demandes. Combien de choses que vous avez mentionnées
sont importants? Si vous avez 10 questions à discuter, de les découper en deux groupes et de se concentrer sur la
groupe le plus important. Considérez si certaines choses peuvent être mieux gérés sur le téléphone, dans le prochain
réunion de l'équipe, ou en faisant du porte-à-porte va. Si vous ne donne pas la priorité, attendre les destinataires à
la priorité pour youin une manière qui sert leurs intérêts, pas le vôtre.

Ne présumez pas que les gens lisent rien (surtout si il est important pour vous) . Il est arrogant de
supposons que parce que vous l'avez envoyé, quelqu'un l'a lu. Les gens obtiennent des tonnes de courriels tous les jours,
une grande partie des gens tout aussi important que vous êtes. Le plus important, la question est à vous,
plus l'énergie que vous avez à dépenser pour vous assurer que les gens voient réellement et font activement
quelque chose à ce sujet. Le plus confiance que vous avez construit avec les personnes de votre équipe, plus
vous pouvez faire des hypothèses sur la façon dont les gens vont réagir à des choses que vous envoyez.

Évitez de donner un play-by-play . Il est rare que quelqu'un a besoin de connaître la séquence des événements qui
conduit à quelque chose. Évitez d'écrire des e-mails qui se concentrent sur les actions contribuant par
différents acteurs: «Quand Sally conçu la première fois de notre processus de construction, elle était intéressée à ...» ou
entraînée récit prose comme "La réunion a commencé très bien, avec Bob et Steve parle à travers
leurs diapositives avec une grande passion et conviction. Autrement dit, jusqu'à ce que .... "Au lieu de cela, se concentrer sur l'impact: ce
passé, comment cela change le monde, et ce que nous allons faire à ce sujet. Si vous êtes
obligés d'inclure les détails d'arrière-plan, les énumérer ci-dessous les points critiques. La même chose vaut pour
références de glisser ponts, des sites Web, des documents, etc. permettent à quiconque de survoler la première
deux lignes et de savoir immédiatement si elle est assez important pour eux de lire plus loin.

Séquestrer FYIs . Je suis allé sur les équipes qui ont persisté dans l'expédition de tonnes de semi-intéressant, mais-
non directement pertinentes-à rien email. Certaines personnes appellent ces FYIs, ou pour votre information
e-mails. La curiosité et la sensibilisation de l'industrie sont des habitudes fines, mais ne les laissez pas dominer
des forums de communication utilisés pour les travaux plus tangible. Mettre en place un alias de courriel ou groupe de discussion
pour les «tendances de l'industrie» ou «montre tech», où votre équipe peut poster les choses cool qu'ils trouvent. Si
votre client de messagerie prend en charge, demander à chacun de définir ces types d'e-mails à faible priorité ou ajouter
"FYI:" à l'avant de la ligne d'objet. Faire ce genre de choses facile pour les gens à filtrer.

Le téléphone est votre ami . Si jamais vous ne comprenez pas quelque chose dans un e-mail important
vous avez reçu, de ne pas répondre à une question complexe en cinq parties. Voyez si vous pouvez atteindre le
expéditeur de l'email sur le téléphone. La communication interactive est toujours préférable à résoudre
confusion et de conflit que le courrier électronique. A 30 secondes de conversation téléphonique équivaut souvent à une longue
série d'échanges de courriels chronophages. Si vous obtenez l'expéditeur sur le téléphone et résoudre
le problème, vous pouvez ensuite partager votre compréhension précisé dans un courriel envoyé à tout le monde: des cotes
sont bonnes que si vous étiez confus, donc en avait d'autres. Téléphones (ou une promenade dans le couloir)
sont les grands expediters du groupe communication par courrier électronique. (3)

Page 182
 10.3.2. Un exemple de mauvaise email

Email Awful est facile à reconnaître. Email Awful est souvent très long, mal écrit, a beaucoup
pièces jointes, et est difficile à parcourir. Il peut être repéré de très loin, et il est généralement soit
ignorés ou contesté de manière appropriée: "Fred: Je trouvais cet e-mail très déroutant Si les autres sont d'accord, peut.
soit vous réviser ou convoquez une réunion? Si pas, je vous appellerai. Merci. »Pour cette raison, terrible email est pas
le type le plus dangereux.

Les e-mails vraiment dangereuses sont celles qui ressemblent communication bien écrit, mais sont, en fait,
mûrs avec des distractions, des pensées à moitié cuit, et les ambiguïtés. Ce qui suit sont des exemples de deux
même e-mail: une mauvaise et une bonne. Voici le mauvais.

De: Jack Colono

Pour: équipe de développement Striker

Objet: Résumé des discussions de contrôle récents

Au cours des quatre dernières semaines, beaucoup d'entre nous se sont demandé si le processus de refonte de notre code
les procédures d'enregistrement seraient enfin complète. Je sais que cela a pris beaucoup de temps et qu'il n'y a
beaucoup de débats été dans les couloirs et les réunions à propos de la bonne façon de s'y prendre pour décider sur,
beaucoup moins déterminer, la conception réelle de la nouvelle procédure ainsi. Choisir les membres
du comité n'a pas été facile pour moi, et comme beaucoup d'entre vous le savez, a pris plus de temps que
attendu. Excuses pour cela, mais ces choses arrivent.

Donc, d'abord, je voudrais vous donner quelques-uns des faits saillants de notre nouvelle proposition, au cas où vous avez manqué une
des discussions hebdomadaires que nous avons eu, ou ne sommes pas venus en discuter avec moi à ce sujet au cours de la dernière
deux semaines:

1) Check-ins sont très importants. Ils déterminent ce que nous sommes vraiment construire.

2) Tout le monde a des opinions. Nous avons tous entendu Randy et Bob chaque décrivent en détail pourquoi ils
pense que le système actuel est si mauvais.

3) Il n'y a pas de réponses faciles. La plupart des changements que nous avons discuté ont toutes des inconvénients. Ainsi,
quand nous ne parvenons enfin à une conclusion, il y aura quelques aspérités sur la transition et
éventuellement sur une base continue.

Avec celle de la route, je voudrais maintenant vous faire savoir que plus tard cette semaine, je vais envoyer sur
la proposition révisée. S'il vous plaît être à l'affût de la prochaine pièce d'email de moi. CA devrait etre
à venir.

Merci,

Jack

10.3.3. Un exemple de bonne email

Contrairement au mauvais exemple, cet e-mail ne raconte pas des histoires ou d'essayer de justifier quoi que ce soit: tout est action.
Il est court, clair, et au point. Au lieu de parler des propositions, il offre en fait l'un. Tandis qu'il
a la saveur d'un ultimatum, il sert aux fins de créer la vitesse de libération de la proposition,
aidant à pousser la porte.

De: Jack Colono

Pour: équipe de développement Striker

Objet: Nouveau processus de check-in

Page 183

La proposition finale pour le nouveau processus check-in est terminé et est en place sur le site web:
http: // intman / proc / checkin / .

Parce que cela a été une question controversée, je l'ai discuté cette proposition en tête-à-tête avec beaucoup
de l'équipe et les commentaires de tout le monde incorporé. Si cela vous ne pas inclure et vous avez
de fortes opinions, s'il vous plaît me les communiquer dès que possible.

Mais attention: ceci est le deuxième avis public au sujet de ces changements à venir. L'opportunité
pour faire des changements est actuellement faible et qu'il se réduit de jour en jour. S'il vous plaît agir maintenant ou
préparer à tenir votre paix.

Vendredi à 17h00 . est la date limite pour me contacter avec des commentaires sur la proposition ci-dessus. JE
examinera et répondre à des questions ou des commentaires soulevés avant puis (en collaboration
avec des gens appropriés). Sinon, cette question est fermée et entrera en vigueur la semaine prochaine.

Merci,
 Jack
Aussi clair que la différence entre ces deux courriels devraient être, ne lisez pas trop dans ces
des exemples. Ils ne sont pas destinés à être des modèles pour les choses à faire toujours ou jamais. Chaque courriel que vous envoyez
pourraient avoir un but différent, et il pourrait être judicieux pour contredire ces exemples. Aussi longtemps que
vous écrivez pensivement et avec des motifs clairs, faire tout ce qui est nécessaire pour faire le travail.
Mais toujours à l'affût de façons de réduire à la chasse et utiliser le courriel pour faire bouger les choses.

Page 184

10.4. Comment faire pour exécuter la réunion non-gênant

Voici ma confession de réunion: je ne l'aime réunions régulières. Je suis convaincu que

sauf si il ya une force de maintien de leur maigre et bien rangé, ils finiront par se glissent dans lente, gonflé,
frustrantes, les déchets dysfonctionnelles de temps. Cependant, si il n'y a que la force en place, les réunions peuvent être
, des expériences centrage énergisants pour tout le monde dans la salle. Le défi est que celui qui organise
et dirige la réunion a besoin de savoir ce qu'il fait.

Pour commencer, de comprendre comment cher réunions sont. Si une réunion dure une heure, et 10 personnes sont
là, cette réunion coûte 10 heures-personnes. Au lieu de corriger les bugs ou de fermeture issuestwo garanti
formes de toute progressthe équipe est enfermé dans une salle de conférence attendre que quelque chose se produise
que vaut la dépense de leur temps. Peut-être ce qui se passe, peut-être qu'il ne fait pas. Donc je pense
les programmeurs et les autres sont justifiées se plaindre de réunions; par rapport à la valeur de temps dans
devant un ordinateur, de temps en réunions habituellement ne marque pas bien.

Toutefois, si la réunion exige la participation parce que les idées ou les décisions importantes sont sur la table,
révèle des informations qui changent le comportement post-réunion de tout le monde, ou transmet inspiration ou
la compréhension de ce qui se passe à travers le projet, alors la valeur de la réunion est beaucoup plus élevé.
Au lieu d'une corvée, il devient un moyen de consommer ou d'échanger des informations difficiles à obtenir par le biais
d'autres moyens.

10.4.1. L'art de la facilitation

Il ya des années, je me souviens d'être dans une grande discussion sur la façon dont nous allions à l'architecte une importante
partie de Windows. Je suis arrivé tôt et regardé tout le monde marche dans la chambre et prendre leurs sièges,
 béatement confiants dans leurs propres opinions. Je les regardais se penchent sur leurs chaises et parcourent
leurs arguments dans leurs esprits avant la réunion même commencé. Et, bien sûr, faire valoir est exactement
ce que nous avons fait. Pendant 10 minutes, la discussion est déplacée plusieurs fois dans les grosses vagues. Contradictoire
diagrammes ont été violemment esquissées dans les tableaux blancs, les mains fouetté en désaccord, et
déclarations sarcastiques et questions rhétoriques abondaient. Enfin, mon manager du groupe, Hadi Partovi,
se lever. Il marchait tranquillement sur le tableau blanc à l'avant de la salle.

Sans dire un mot, il a commencé à écrire une liste de questions. Au moment où il était sur le troisième, le
pièce était silencieuse. Tout le monde avait cessé de se disputer et a été regarder ce qu'il faisait. Quand il
fini, il lui a demandé si il avait les bonnes questions sur la planche. Tout le monde hocha la tête. Il nous a ensuite conduit à travers
les une à la fois. Il y avait encore des arguments, mais quand structuré, ils étaient nettement moins
continue. Hadi n'a pas offert sa propre opinion (bien que je savais qu'il avait un). Au lieu de cela, il a utilisé son
l'énergie pour aider le reste d'entre nous de naviguer à travers les questions que nous avions convenu. Ceci est l'art de
facilitation.

Faciliter (v): Le fait de rendre les choses faciles ou plus facile.

Bonnes rencontres se produisent seulement quand quelqu'un dans la salle comprend comment faciliter. Certaines personnes
faire instinctivement, et d'autres peuvent même pas reconnaître quand il est fait. Comme d'autres interpersonnelle
compétences, les gens ont différents niveaux de prise de conscience sur les nombreuses façons interaction se produit et comment
influencer.

Faciliter peut être un rôle semi-formel, tenue par une personne désignée qui dirige le spectacle (souvent le
PM), ou par celui qui a ouvert la séance. Certaines équipes ont de fortes cultures assez de facilitation
(Ce qui signifie que beaucoup de gens ont la compétence) qu'ils peuvent passer qui joue ce rôle naturellement dans
le cours de la conversation. Mais la plupart du temps, la plupart des projets, des réunions sont désespérément dans le besoin
de la facilitation talent.

Page 185

10.4.2. pointeurs de facilitation

La facilitation est une de ces compétences que certaines équipes prennent pour acquis. Jusqu'à ce que vous travaillez avec un groupe
des personnes qui ne communiquent pas efficacement ou se rendent compte qu'ils ne sont pas communiquer efficacement,
il est facile de négliger la valeur de ce que les gens avec cette compétence peuvent faire. Il ya pas mal de livres (4)
et des cours sur la façon de faciliter, mais votre meilleur pari pour la compréhension des compétences nécessaires est de regarder
quelqu'un qui le fait bien, et puis essayez d'appliquer certaines de ce que vous avez observé à la prochaine réunion
vous organisez. Cependant, il ya quelques conseils dignes de mention. Il m'a fallu beaucoup de temps pour comprendre
ceux-ci, et ils vont un long chemin en vous aidant à développer toutes les compétences de facilitation naturelles vous
avoir.

Créer un poste d'accueil . Si vous êtes l'organisateur de la réunion, vous êtes de facto
facilitateur. Commencez la réunion en présentant des gens, de clarifier l'ordre du jour, et le début de la
discussion. Si vous vous comportez comme un hôte à partir du moment les gens marchent dans la porte, ils seront
se comporter comme des invités et vous traiter avec respect. Soigneusement choisir où vous asseoir dans la salle:
assis à la tête ou au centre d'une table vous donne généralement le plus de sens de l'autorité, et
assis dans le coin vous donne le moins.

Écouter et réfléchir . La fonction de base de l'animateur est d'aider d'autres gens communiquent. Si
quelqu'un dit quelque chose à mi-cuit (mais pas complètement sans valeur), l'aider à le développer en
une idée complète. Si Mike a du mal à faire un point à Molly, et vous avez une façon claire pour aider
exprimer le point, le faire. Essayez le truc de réflexion de répéter ce que les gens disent: "Alors Mike, ce que je
pensez que vous dites est <insert meilleure façon pour Mike d'exprimer son point ici>. Es-tu d'accord?"
Cette affine son point et démontre à tout le monde comment faire la discussion collaborative.
Cependant, veillez à séparer votre désir de champion vos propres opinions: il est difficile d'être un
bon animateur ou un bon auditeur, si vous êtes pris dans votre propre agenda personnel. Certains
organisations embauchent des animateurs professionnels qui aident avec des réunions et des installations annexes litigieuses.
Savoir qui sont les bons facilitateurs dans votre équipe sont et de les appeler si vous préférez pour représenter une
point de vue particulier et ne pense pas que vous puissiez réussir faciliter en même temps.

Diriger la conversation . Avec l'ordre du jour tant que votre guide, sauter dans de pousser la discussion retour
sur la bonne voie lorsque cela est nécessaire. Soyez flexible et laisser les gens ont leur mot à dire, mais si la conversation est
vers le sud quand l'ordre du jour exige que vous allez à l'ouest, quelque chose doit être fait. Poliment
interrompre, pointez sur l'ordre du jour sur le mur, et demander qu'ils tableau de la discussion à la main jusqu'à ce
les questions à l'ordre du jour ont été couverts (ou offrir pour régler l'ordre du jour, si ce nouveau numéro est
digne). Faites attention à qui parle trop et qui ne parle pas assez, et
gérer le plancher en conséquence («Bob, Attendez un instant ... Steve avez-vous des idées sur
ce?").

Fin à la conversation . Avoir un seuil dans votre esprit pour quand une question doit être prise
déconnecté et résolu ailleurs. Il suffit souvent d'identifier un problème, et un propriétaire pour le
problème, et de demander que le propriétaire de partir à son compte et revenir demain ou le jour suivant
avec une solution proposée. Ceci est une excellente façon de terminer secondaires débats qui ont eu cours
réunions: "Whoa, détiennent les gars Sam et Bobyou deux vont et comprendre cela, alors ok.?
revenir et nous savons ce que vous avez décidé. "Ne laissez jamais deux personnes dominent le sol,
lorsque cinq ou six autres personnes sont ennuyés de leur esprit pendant toute l'heure.
 Faire l'histoire
facilitateur, cela .vous
Prenez
aideleàtemps
suivredelorsque
documenter la discussion
vous êtes (sidu
dans l'ordre possible,
jour et comme ça arrive).cela
de communiquer Comme
à la un
groupe. Pour cette raison, je suis complètement entiché de tableaux blancs. Ils sont le plus facile et
plus de manière flexible pour capturer ce que les gens disent, faire des listes de tâches, ou identifier les points de
(DIS) accord. Mais comment vous faites n'a pas d'importance. Ce qui est important est que lorsque la réunion
est terminée, les prochaines étapes et les points importants sont enregistrés et envoyés par courrier électronique à ceux qui
assisté à la réunion. Certains disent que d'être le scribe est une position de pouvoir parce que vous peut
influencent la façon dont les choses sont enregistrés et quels aspects sont soulignés. Même si cela ne le
cas, l'envoi de notes ne fournit une fonction de forçage pour les autres afin de clarifier tout ce que vous avez
déformé.

Même si vous n'êtes pas d'accord avec ces pointeurs, je l'espère qu'ils ont aidé à reconnaître qu'il ya un
rôle de leadership à jouer dans les réunions. Si personne ne joue activement ce rôle, les réunions auront tendance à
être des affaires frustrantes et / ou ennuyeux. Le refrain est générale "Réunions sucent et devraient être évitées,"

Page 186

mais le vrai problème est de savoir comment les réunions sont exécutés, pas l'idée de réunions elles-mêmes.

10.4.3. Trois types de réunions

Le plus grand piège pour les organisateurs de réunions est d'oublier la polyvalence l'idée d'une réunion est. Pas tout
réunions doit être exécuté de la même manière ou devraient avoir la même structure. La raison pour laquelle beaucoup
réunions sont ennuyeuses pour 90% des personnes il est parce que les objectifs sont en conflit avec la
de rencontrer la structure et de la taille. Vous ne pouvez pas avoir des discussions très interactives avec plus de sept ou
huit personnes, peu importe qui est de faciliter. Comme une règle très simple et approximative, il ya trois sortes de
réunions, avec des contraintes et des applications. Toujours tenir compte de ce genre de rencontre sera le mieux
servir le problème qui doit être résolu.

Discussion hautement interactif . Tout le monde à la réunion devrait participer. L'objectif est
la profondeur et l'intimité. L'accent est mis sur l'exploration ou résolution de problèmes spécifiques ou la recherche de solution de rechange
idées. Taille: petite à moyenne (2-8). Exemples: design discussion, remue-méninges, crise
la gestion, et le triage.

Rapports ou une discussion modérée . Une personne a un contenu à couvrir, et elle a besoin de personnes
pour répondre à ou comprendre que le contenu. Le but est d'obtenir des commentaires de haut niveau ou partager
connaissances. Cela peut être très interactif, mais il se produit uniquement pour un sous-ensemble du groupe. Plusieurs
différentes personnes peuvent prendre la parole lors de la réunion, en changeant les rôles pour qui est conduite
et qui est de répondre. Taille: taille moyenne à grande (5-15). Exemples: examen spec, architecture
examen, révision à la gestion, et la petite présentation.

Statut et l'examen du projet . L'objectif est de résumer l'état d'une équipe ou d'un ensemble de
projet. Donne aux dirigeants une chance de faire des corrections de cours et de présenter de nouvelles directives de
la gestion de l'ensemble du groupe à la fois. Lorsque ces réunions comprennent l'activité de collecte
état, ou de force tout le monde à écouter la déclaration de l'état, ils sont souvent le plus ennuyeux
expériences dans l'univers connu. Taille: taille moyenne à grande (10-100). Exemples: examen de l'état,
examen du projet, présentation importante, et réunion de tout-mains.

Les réunions les plus mauvaises se produisent quand il ya une inadéquation des objectifs et comment ils sont organisés. Si
il ya plus de 10 personnes dans la salle, il est très difficile d'avoir une très interactif ou profonde
discussion. Il n'y a pas assez de temps pour tout le monde de participer, et ce qui va arriver est qu'un petit
groupe de personnalités dominantes va utiliser la plupart du temps disponibles (à moins que quelqu'un facilite
la réunion pour éviter cela; Cependant, un petit groupe de personnalités dominantes est pas toujours une mauvaise
chose). La plupart des comités prennent ce formulaire et l'ont attendu médiocre aux résultats de merde.

10.4.4. Le mal des réunions périodiques

La deuxième réunion plus mal est celui qui revient (hebdomadaire, quotidienne, mensuelle), puis vit pour
semaines malgré elle pas plus nécessaire (quelques bâtiments à Microsoft étaient impossible de réserve
réunions en réunions périodiques parce abandonnés bouchés la programmation de salle de conférence
système). La récidive est grande en ce qu'il établit un rythme de travail et oblige les gens à être dans la même
chambre ensemble en même temps. Toutes sortes de petits problèmes peuvent être résolus rapidement et avec désinvolture quand
les gens sont physiquement ensemble et peuvent dépendre de se voir en personne une fois ou plus par semaine.
"Oh. Hey, Sam, je l'ai eu l'intention de vous demander ... est cette API va changer? Je voyais votre check-in et
Je pensais que cela pourrait avoir un impact moi, mais je ne savais pas. "Courrier électronique et les appels téléphoniques ne garantissent pas
réponses, mais lorsque la personne est assise à côté de vous, vous pouvez généralement obtenir ce dont vous avez besoin.

Le problème est que cela devient trop facile pour les réunions périodiques de vivre longtemps après la valeur de la
réunion a disparu. Quand certaines personnes arrêtent de venir, ou d'autres utilisent le temps de vérifier le courrier sur
leurs ordinateurs portables, quelque chose est faux; la réunion ne garantit pas plus le temps. La peur
(gestionnaires et autres organisateurs de la réunion) ont souvent est que par l'annulation de la réunion, ils sont
perdre un de leurs rares occasions pour diriger l'équipe en tant que groupe. Mais au contraire, torturant
équipes avec des réunions inutiles est de savoir comment les gestionnaires perdent de la crédibilité du leadership qu'ils essaient de
protéger.
Page 187

Voici une bonne règle: opt-in réunions. Gardez la réunion récurrente sur le calendrier et demander à chacun de
vérifier son email pour un ordre du jour cinq minutes avant la réunion est censée commencer. Si il existe un solide
ordre du jour, l'organisateur envoie-le, et le groupe se réunit. Si il n'y a pas d'ordre du jour, vous envoyez des e-mail
dire, et la réunion est annulée (pour cette semaine). Cela donne à l'équipe un intervalle de temps réservé si
nécessaire, mais ne force pas les gens à assister à des réunions de faux. La récurrence devrait être annulée
entièrement si aucune réunion se produit pendant plus de trois ou quatre semaines.

10.4.5. Pointeurs Réunion

Cette dernière section est une liste de tactiques souvent négligé pour la course et participer à succès
réunions. Il n'y a rien sexy ou intéressant à ce sujet: il ya juste certaines choses que vous avez à traiter
lorsqu'ils travaillent avec de petits groupes de personnes. Toute personne qui a dirigé de nombreuses réunions sera l'avoir
propre liste noire des astuces ou des conseils: si rien d'autre, je espère que cette liste vous aide à réfléchir à ce que les choses
ont travaillé pour vous dans le passé.

Sont les bonnes personnes dans la salle? Certaines personnes viennent si vous les invitez. Certaines personnes
ne viendra pas à moins que vous frappez les inconscients et les faire glisser (et / ou les soudoyer avec
bonbons). Faire beaucoup de GP de travail est d'obtenir les bonnes personnes dans la salle, au bon moment, afin
ne pas avoir peur de courir dans le couloir ou d'une barge dans d'autres réunions, si la personne qui est
censé être dans votre réunion n'a pas encore arrivé. Pire encore: si vous essayez de démarrer une
réunion et ne peut pas obtenir les bonnes personnes, arrêtent la réunion. Ne perdez pas une heure de temps à faire
trucs que vous aurez juste à le faire à nouveau demain ou le lendemain quand vous faites finalement obtenir un quorum.
Enfin, si vous avez les bonnes personnes, mais voir des gens dans la salle qui n'a pas besoin d'être là,
dites-leur. Soyez diplomate, offre de les envoyer des notes ou des résumés, mais les faire sortir de la
manger, surtout si ils vont obtenir de la manière.

Assis ou debout . Une astuce pour garder réunions courte est que tout le monde se lever (par exemple, répondre à
le couloir ou à l'extérieur). La théorie est que cela oblige les gens à se rendre au point et ne soulever
questions vraiment digne de discussion de groupe. La réunion doit durer pour seulement 5 ou 10 minutes,
tops. Le SCRUM (5) processus préconise une réunion permanente quotidienne à des fins d'état, où
seulement trois questions sont posées: Qu'avez-vous fait depuis la dernière réunion? Ce qui bloque
tu? Que ferez-vous par la réunion de demain? Avec ce genre d'engagement inconditionnel de se pencher
réunions, même l'ingénieur crankiest doivent être prêts à participer. Réunions assises traditionnelles
sont réservés aux petits groupes traitant de questions spécifiques. Il vaut la peine d'essayer au moins cela comme une
expérience: si rien d'autre, il inspire les gens à considérer que d'une réunion prévue pour une
heure n'a pas besoin de consommer l'heure pleine.

Préparer . Réunions échouent souvent à cause du manque de préparation. Toujours considérer combien
temps de préparation vous aurez besoin pour une réunion à servir ses objectifs. Parfois, ce sera
minime: une liste de questions ou de problèmes ouverts, ou un e-mail que vous envoyez avec l'ordre du jour le jour
avant. D'autres fois, il est complexe: une plate-forme de diapositives, une démo, documents agrafés. Chaque fois que vous avez
une réunion pas aussi bien que vous le souhaitez, demandez-vous ce qui aurait pu être fait différemment.
La plupart du temps, la réponse sera impliquer une certaine forme de préparation de négligence. Une astuce consiste à
tenir compte lorsque vous envoyez une réunion, invite, et ajouter du temps à votre propre calendrier avant
la réunion pour la quantité appropriée de préparation.

Les ordinateurs portables et gadgets . Je ai un fort préjugé contre l'utilisation de gadgets et les ordinateurs portables au cours
réunions. Si les gens dans la salle ne pense pas que ce qui se passe est suffisamment importante pour justifier
toute leur attention, ils ne devraient pas être dans la chambre (sauf si elle est un statut ou d'un projet-Review
réunion de type, où il ya un faible rapport signal sur bruit). temps de visage est précieux et doit être
utilisé pour les choses les gens se sentent naturellement sont importants et la valeur de leur temps, alors que les courriels et
la messagerie vocale sont conçus pour attendre. Si vous avez une opinion à ce sujet, parler à d'autres dans l'équipe
et voir si vous pouvez mettre d'accord sur une politique d'utilisation de portable appropriée dans les réunions.

Être à l'heure . Ceci est un comportement entraîné l'ancienneté. Si les vice-présidents et les cadres supérieurs ont tendance à arriver
la fin, tout le monde va. Si ils ont tendance à arriver à l'heure, tout le monde va. Vous pouvez essayer de démarrer
sur le temps de faire un point, mais si les gens importants ne sont pas là, vous ne finissent par répéter
vous une fois qu'ils ne montrent jusqu'à: il est une cause perdue. Toutefois, si elle est pairs ou des rapports que vous attendez
, essayez tactiques de gêne comiques. Mon truc favori est d'appeler le bureau de chaque personne qui est
fin. Si il est toujours là, se moquer de lui légèrement sur le téléphone en face de tout le monde: "Salut Sam.

Page 188

Nous serions honorés de votre présence dans la salle de conférence 5. "Si il n'y est pas, lui laisser une voix
courrier. Mettez-le sur haut-parleur et ont chacun dans la chambre dire, à l'unisson, «Nous vous aimons
Sam! »Ou chanter Joyeux anniversaire. Faites ceci à chaque réunion pour celui qui est en retard ou est la dernière à arriver.
Vous commencerez réunions avec quelque chose funand une motivation supplémentaire pour arriver à l'heure.

Terminez avec des étapes claires et les propriétaires . Lorsqu'une réunion se termine, tout ce qui compte est ce qui se passe
Suivant. Vous pouvez avoir le plus laid, plus méchant le plus brutal réunion, jamais dans l'histoire de l'humanité,
mais si vous quittez la pièce avec la liste de droite de cinq choses qui doivent être faites, et les noms
de cinq personnes qui ont accepté d'obtenir ces choses, vous avez réussi. Ne jamais laisser les gens
sortir d'une pièce sans un plan clair pour la prochaine étape est. Une partie de votre préparation doit être
basé sur la façon dont vous pensez que vous pouvez obtenir ce résultat et les bonnes personnes qui sont pour chaque
entrée.
Page 189

10.5. Résumé

Les gestionnaires de projet sont sujettes à d'autres ennuyeux. Certains d'entre elle est évitable.

Les gens se fâchent pour de nombreuses raisons. Souvent, il est quand ils sentent que leur temps est gaspillé, quand
ils sont traités comme des idiots, ou quand ils sont attendus pour supporter l'ennui et prolongée
mauvais traitements.

Bons procédés ont de nombreux effets positifs, y compris l'accélération des progrès et la prévention
problèmes. Mais, ils sont difficiles à bien concevoir.

E-mail non-gênant est concis et réalisables, et il permet rapidement aux lecteurs de déterminer si
ils sont touchés assez pour avoir besoin de lire plus de la ligne d'objet ou de la première phrase.

Réunions fonctionnent bien quand on leur facilite.

Réunions frustrantes se produisent lorsque les objectifs ne correspondent pas au type de réunion.
Page 190

Chapitre Onze. Que faire quand les choses vont

faux

Peu importe ce que vous faites , comment vous travaillez dur, ou avec qui vous travaillez, les choses vont encore aller mal. La
meilleure équipe du monde, avec les meilleurs dirigeants, les travailleurs, le moral et les ressources, sera toujours trouver
eux-mêmes dans des situations difficiles et inattendues. La seule façon d'éviter complètement difficile
situations est de ne rien faire d'importance ou de mettre constamment vous dans les situations, et sur
projets, où vous êtes à l'abri de toutes les formes de choses risktwo qui contribuent rarement à succès pour
projets ou chefs de projet.

"Tous les projets réussis sont tout simplement une longue série de malheurs qui doit être surmonté.
Loin de là étant inhabituelle pour faire face à l'adversité, il est normal, et notre entreprise est de
 surmonter. Le véritable test est pas quand nous réussissons quand il n'y a pas d'adversaire,
mais quand il est et nous triompher ".

William A. Cohen

Pour ces raisons, les bons chefs doivent être prêts à faire face à des situations difficiles. Il faut une certaine
sorte de sagesse pour réaliser que lorsque les mauvaises choses arrivent, ils se produisent. Rien ne peut être fait pour
les changer après le fait. Au lieu de cela, comment l'équipe répond à l'adversité peut être un facteur plus important dans
la réussite du projet que la capacité de l'équipe pour éviter l'adversité en premier lieu. Les deux sont importants, mais
la résilience et la capacité de récupération sont les attributs qui font traitant avec le possible inattendu.
Sans eux, une équipe parfaite et plan parfait peuvent spirale hors de contrôle avec juste un coup de pouce
mauvaise direction.

Ce chapitre fournira trois choses: un guide rugueux ou trousse de premiers soins pour savoir quoi faire quand les choses vont
mauvaises pensées sur la façon dont les personnes et les équipes répondent à des situations difficiles, et la couverture de la tactique
et les approches de la gestion dans les moments difficiles.

Page 192
191

11.1. Appliquer l'indicatif

"Vous pouvez blâmer les gens qui frappent les choses plus dans l'obscurité, ou vous pouvez commencer à la lumière
bougies. Vous êtes seulement à la faute si vous connaissez le problème et choisissez de faire
rien. "

Paul Hawken

Cette section est un simple amorce sur la façon de gérer les situations difficiles. Plus tard, je vais couvrir une partie de la
situations courantes et offrent des conseils spécifiques, mais ce guide général devraient vous aider à travailler à travers
quoi que ce soit qui vous a conduit à retourner à ce chapitre.

1. Calmez-vous . Rien ne rend une situation pire que de baser vos actions sur la peur, la colère, ou
frustration. Si quelque chose de mauvais arrive à vous, vous aurez ces émotions que vous soyez
conscients ou pas. Ils seront également influencer votre pensée et de comportement si vous êtes au courant
de celui-ci ou non. (Règle de base: moins vous êtes conscient de vos sentiments, plus vous vulnérables
sont à eux, vous influencer) Ne pas flancher ou réagir de façon excessive. être patient, continuer à respirer, et de payer
attention.

2. Évaluer le problème dans le cadre du projet . Juste parce que quelqu'un d'autre pense le ciel
est tombé ne signifie pas qu'il a. Est-ce vraiment un problème du tout? Dont le problème est-il? Comment
une grande partie du projet (ou ses objectifs) est à risque ou peut avoir besoin de changer à cause de cette situation:
5%? 20%? 90%? Mettre les choses en perspective. Quelqu'un va mourir à cause de cette erreur (vous n'êtes pas
un chirurgien du cerveau, êtes-vous?)? Seront des villes soient portées? Fléaux livré à des innocents? Aidez-moi
tous cadrer le problème à l'échelle émotionnelle et intellectuelle droite. Demandez des tonnes de questions
et amener les gens à penser plutôt que de réagir. Travailler pour éliminer des hypothèses. Sois sûr de
avoir une compréhension concrète du problème et de son impact réel. Ensuite, la priorité: urgence
(Maintenant!), Grande préoccupation (aujourd'hui), préoccupation mineure (ce ou la semaine prochaine), bidon (jamais). Savoir combien de temps
votre fusible est de répondre et de prioriser ce nouveau numéro contre tous les travaux existants. Si elle est un faux
problème, assurez-vous que celui qui criait au loup apprend quelques nouvelles questions à poser avant de soulever le rouge
drapeau à nouveau.

3. Calmez-vous à nouveau . Maintenant que vous savez quelque chose sur le problème, vous pourriez vraiment obtenir
bouleversé ("Comment ces idiots pourraient laisser <insérer chose incroyablement stupide ici> arrive !?"). Trouve un moyen
pour exprimer des émotions en toute sécurité: crier au ciel, séance d'entraînement à la salle de gym, ou de parler à un ami. Mais faire
les exprimer. (1) Savoir ce qui fonctionne pour vous, et de l'utiliser. Puis revenir au problème. Considérer
que non seulement vous avez besoin d'être calme pour prendre de bonnes décisions, mais vous avez besoin de votre équipe d'être
calme. Faites attention à qui est inquiet ou bouleverser et l'aider à se calmer. Humour, candeur,
nourriture et la boisson sont de bons endroits pour commencer. Si vous êtes un leader, être calme et vous-même recueilli
va un long chemin vers calmer autres. Et prenant la responsabilité de la situation (voir le
section ultérieure " Prendre la responsabilité "), indépendamment de la faute duquel il était, tend à accélérer une
le rétablissement d'un problème de l'équipe.

4. Obtenez les bonnes personnes dans la salle . Tout problème majeur ne sera pas un impact sur ​vous seul. Identifier qui
le reste est le plus responsable, bien informé et utile étant donné la situation, et les amener dans un
chambre (ou conférence téléphonique) tout de suite. Les sortir d'autres réunions et tâches: si elle est
urgence, agir d'urgence, et d'interrompre ou de préempter tout ce qui se dresse sur votre chemin. Asseyez-vous les
, fermez la porte, et courir à travers ce que vous avez appris à l'étape 2. Gardez ce groupe aussi petit que
possible; la plus controversée ou la complexité du problème, plus le groupe devrait être. (2) En outre,
considèrent que (souvent), vous peut-être pas partie de ce groupe: amener les gens dans la salle,
communiquer le problème, puis déléguer. Offrez votre soutien, mais de sortir de leur chemin
(Seriouslyleave la chambre si vous n'êtes pas besoin). Identifier clairement qui est en charge de la conduite de cette
question de la résolution (voir « Rôles et une autorité claire », plus loin dans le chapitre), que ce soit vous ou est
quelqu'un d'autre.
 5. Explorer des alternatives . Après avoir répondu à toutes les questions et de clarifier la situation, comprendre

Page 193
5.
quelles sont vos options (voir chapitre 8 ). Parfois, cela peut prendre un peu de recherche: déléguer
dehors. Assurez-vous qu'il est marqué comme urgent si nécessaire; ne présumez jamais que les gens savent comment
est quelque chose d'urgent. Soyez aussi précis que possible dans vos attentes pour quand les réponses sont
nécessaire.

6. Faire le plan le plus simple . Peser les options, choisissez le meilleur choix, et de faire un plan simple (ou
à nouveau, le cas échéant, délégué). Le meilleur choix disponible est le meilleur choix disponible, aucun
importe combien il suce (une crise est pas le moment pour l'idéalisme). Le plus urgent de la question, le
plus simple et plus clair de votre plan devrait être. Plus le trou que vous êtes, la plus directe
et en gras votre chemin hors de lui devrait être. Casser le plan en autant d'étapes aussi souvent que nécessaire
pour vous assurer que personne ne se confond. Identifier les deux listes de personnes: ceux dont l'approbation vous
nécessité pour le régime, et ceux qui doivent être informés du plan avant qu'il soit exécuté. Aller à
le premier groupe, présenter le plan, considèrent leur rétroaction, et d'obtenir leur soutien. Alors
communiquer cette information au second groupe.

7. Exécuter . Make it happen (voir chapitre 13 ). Assurez-vous que celui qui fait le travail a été impliqué
dans le processus et a une compréhension intime et quasi-obsessionnelle de pourquoi il le fait.
Il n'y a pas de place pour hypothèse ou d'ambiguïté. Avoir des points de contrôle spécifiques (horaire, quotidienne,
hebdomadaire) pour vous assurer que le plan a l'effet désiré et à vous et à d'autres au pouvoir pour forcer
considérer tout effort supplémentaire qui doit être consacré à cette question. Si de nouveaux problèmes ne se posent,
recommencer à l'étape 1.

8. Compte rendu . Après l'incendie a été éteint, les bonnes personnes dans la salle et de générer une liste de
leçons apprises. (Ce groupe peut être différent du droit des gens à l'étape 4 parce que vous voulez
pour inclure les personnes touchées par, mais ne sont pas impliqués dans le processus de décision) poser la question.:
que pouvons-nous faire la prochaine fois pour éviter cela? Le plus gros de la question, les réponses plus vous aurez à
cette question. Prioriser la liste. Envisager qui devrait être responsable de veiller à chacune des
les premiers éléments qui se passe.

Page 194

11.2. Situations communes à attendre

Il ya certaines mauvaises situations qui se produisent inévitablement sur des projets. Une grande partie du contenu de ce livre est
de minimiser les chances de ces situations se produit, ainsi que de minimiser la sévérité de
 eux devraient-ils se produire. Mais l'univers est un endroit difficile pour les projets, car il ya plus de moyens pour
les choses tournent mal que pour eux d'aller à droite. Les plus de projets sur lesquels vous travaillez, plus il est probable
vous aurez l'expérience de toutes les choses énumérées ici et d'avoir la chance d'apprendre de première main comment faire face à
leur.

Ma première situation vraiment difficile a eu lieu en 1996, lorsque je travaillais sur le contrôle parental
fonctionnalités de IE 3.0, mon premier grand domaine de responsabilité. Nous avons travaillé à soutenir le W3C
standard pour les systèmes de contrôle parental, essaie d'être le premier navigateur Web pour faire quelque chose de significatif
pour rendre le Web "en toute sécurité." Je pensais que le projet allait bien, jusqu'à ce que nous avons eu notre première réunion d'examen.
Ce fut un désastre complet. Parmi les 10 personnes là-bas, 9 d'entre eux semblaient tellement déçu par mon
réponses à leurs questions qu'ils essentiellement cessé d'écouter pour moi. Ils ont tous connu
les développeurs et les architectes, et leurs questions étaient beaucoup mieux que mes réponses. Tout
semblaient mal: les gens criaient et mon équipe était démoralisé. Dix minutes après la réunion, je
savait ce fut un désastre. Vingt minutes, je voulais, je pourrais disparaître. Lorsque l'heure était terminée, je
pouvait à peine se lever sur le sol.

Les gens de chez Microsoft appellent parfois ce genre de chose procès par le feu. L'idée est que le travail est dur et
il n'y a pas de gants. Les questions sont difficiles et les attentes sont élevées. Je dois une vive
mémoire de ce jour-là parce qu'elle était la première fois que je bien compris combien la pensée a été nécessaire
à faire un bon travail. Je l'avais entendu des histoires d'expériences similaires, mais jusqu'à ce qu'il est arrivé à moi, je ne
entièrement compris. Mais ensuite, les choses étaient claires: il était de mon devoir de faire les choses fonctionnent bien
suffit qu'une réunion comme celle-là ne se reproduise jamais.

De mon expérience, la formation d'autres gestionnaires, je l'ai appris qu'il est difficile pour les gens de se rapportent entièrement
à un problème qu'ils ne se sont pas connu (une autre raison simulations devraient être utilisés dans
entraînement). Malgré la façon dont il devrait être facile de raconter l'histoire de quelqu'un d'autre sur les horaires de glisser ou de
l'évolution des besoins, en quelque sorte plupart d'entre nous parviennent à croire que nous sommes à l'abri. Ou plus précisément,
que les problèmes que nous avions (ou que vous rencontrez) étaient uniques en quelque sorte qui les rendait inévitable
et contrairement à quoi que ce soit quelqu'un d'autre a jamais connu.

Donc, dans un acte d'optimisme pure, je vais vous offrir, cher lecteur, une liste des situations difficiles communs. Si
rien d'autre, en écumant cette liste devrait vous aider à reconsidérer les expériences que vous avez eues, ainsi que
ceux qui vous sont actuellement.

11.2.1. Comment savoir que vous êtes dans une situation difficile

En ce qui concerne les projets, je considère comme une situation difficile si elle remplit une des conditions suivantes
critères:

1. Il existe un fossé entre la réalité et aiguë du plan actuel. ("Nous sommes censés libérer de web
en une heure, mais Fred dit la base de données clients est corrompu, le pouvoir est sorti, et
l'équipe de programmation est ivre. ")

2. Il existe une confusion sur ce que l'écart est, ce qui le cause, dont le travail consiste à résoudre, ou
éventuellement si elle existe. ("Qu'est-ce que iceberg? Je ne vois pas un iceberg.")

3. On ne sait pas comment les ressources devraient être appliquées pour résoudre l'écart. Il peut y avoir des craintes que la prise
action ou ne rien faire peuvent faire empirer les choses. ("Ne restez pas là, faire quelque chose! Attendez,
non ... ne faire juste pas quelque chose, rester là! ")

Page 195

Le commentaire sarcastique à propos de cette liste est que pour certains projets maléfiques, ces traits pourraient applicable à partir du jour
une. C'est suffisant. Statu quo dans une organisation est un exercice d'incendie dans un autre. Alors qu'il est de la gestion
travail pour minimiser chaoshopefully au point qu'il est seulement des problèmes spécifiques à des moments spécifiques et non
un trait général des travaux environmentwe savons tous que, parfois, la gestion est pas capable de faire
leur travail (insérer deuxième commentaire sarcastique ici). Cela dit, les conseils donnés dans ce chapitre applique également
ainsi, peu importe combien de fois vous avez à appliquer. Mais si vous vous trouvez souvent de lire ce chapitre, il
pourrait être temps de chercher un nouveau directeur ou une nouvelle place pour travailler.

11.2.2. La liste des situations difficiles

The Rough Guide au début de ce chapitre peut être appliqué dans toutes les situations suivantes,
bien que les domaines et les compétences requises peuvent différer. Pour référence, je ai inclus une partie de la possible
réponses à considérer (fourrage pour l'étape 5, "Explorez alternatives», dans le guide sommaire) pour chacun de ces
situations:

De surveillance ou de la réalisation . La plupart de ce qui va mal sur des projets sont oublis ou
une sous-estimation. Quelques jours ou quelques semaines de décision prise il ya n'a pas fonctionné et maintenant quelque chose
ne fonctionne pas. Le problème est que le calendrier et / ou exigences demeurent: à leur rencontre,
quelque chose de nouveau à faire. (Daily construit aider forcer ces réalisations à se produire plus tôt
plutôt que plus tard) Réponses possibles:. modifier les exigences, modifier l'annexe
réimplémenter (couper la prochaine priorité minimale option), ou, si nécessaire, d'explorer nouveau design
alternatives. Si vous avez fait l'exploration de la conception (voir les chapitres 5 et 6 ), il peut y avoir une bonne
repli autre conception qui a déjà bien compris.
 Vous ou votre équipe est forcé de faire quelque chose de stupide . Cela peut se produire pour diverses raisons,
la plus évidente étant le résultat d'une décision de la direction ou un client qui refuse de
reconnaître un aspect du problème. (Bien que parfois un manque de demandes de ressources que
sciemment de mauvaises décisions doivent être prises.) Ceci est frustrant parce que vous savez mieux, mais
vous ne disposez pas d'assez de puissance pour faire quelque chose à ce sujet. Réponses possibles: Sachez que vous êtes dans
un piège de gestion. Si vous ne parvenez en quelque sorte à réussir malgré la décision stupide, vous aurez
être mis dans la même situation à l'avenir. Si vous échouez, vous pouvez être blâmé pour ne jamais
croyant. Donc, si cela est un problème chronique, vous avez besoin d'investir davantage dans la gestion (voir
Chapitre 16 ). Prioriser vos objections, avoir des recommandations spécifiques, et d'utiliser votre politique
et les compétences de négociation (voir " la résolution des conflits et la négociation ", plus loin dans ce chapitre) à travailler
vers un compromis. Vous ne serez pas gagner, mais jusqu'à ce que vous pouvez trouver une meilleure gestion, vous pouvez
protéger, vous et votre équipe. Essayez d'isoler la stupidité d'une fonction ou une étape où il
fera le moins de dommages (voir la prochaine section " Damage Control ").

A défaut de calendrier ou une ressource pénurie . Chaque fois que la probabilité de faire la prochaine date
tombe en dessous de 75% ou plus, les dates ne sont plus probable. Il est possible, mais peu probable.
Réponses possibles: voir chapitres 2 et 14 . Il est tout au sujet des critères de sortie et ses priorités implicites.
Soit vous coupez caractéristiques, ajouter du temps à l'horaire, ou d'ignorer toute logique connue, rédiger votre dernière
testament, et essayer de faire de la date de toute façon. Ne pas essayer d'examiner si le risque de calendrier
peut être isolé et déplacé hors du chemin critique, ou si elle peut être échangé dans un jalon avenir pour
chose jugée moins importante. La loi de Brook (3) implique que l'ajout de personnes dans le visage de
glisser horaires peut avoir moins de valeur que prévu.

La qualité est faible . Vous ne saurez pas si la qualité est faible si vous ne savez pas ce que la qualité est. Si vous êtes
quotidiennement en utilisant construit ou avoir certains paramètres fréquemment suivis (de comptage de bug, etc.), vous saurez début
sur. Il existe plusieurs types de mauvaise qualité: Code fragile, manquement à des exigences, pauvres
performance, ou d'instabilité. Il ya aussi de nombreuses causes de mauvaise qualité: Ingénierie (core
pratiques de développement), le processus (Visites et outils), ou le calendrier / planification. Possible
réponses: raffermir la compréhension de l'équipe de ce de bonne qualité est et fixer des objectifs quotidiens pour elle
(Voir chapitre 15 ). Sacrifier quelque chose (fonctions, temps) pour donner plus de qualité. Souvent, le meilleur
déménagement est de ralentir le rythme des progrès jusqu'à ce que la barre de la qualité a été atteint et tout le monde
comprend comment répondre, puis accélérer le rythme des progrès à nouveau.

Changement de direction . Gestion ou le marché lui-même peut exiger que le cours du projet
doit changer. Cela ne veut pas nécessairement mauvais pour le projet (il pourrait même être une forme de

Page 196

progrès), il est peu probable d'être juste beaucoup de plaisir. Les compressions budgétaires ou de nouveaux objectifs de haut niveau peuvent être
impliquer. Réponses possibles: le changement peuvent être séquestrés à certains composants? Séparé
ce que les spécifications ou des parties de spécifications sont encore viables, et de les garder dans le pipeline de développement
(Voir chapitre 14 ), puis hiérarchiser ce qui doit être changé. Assurez-vous de ne pas être
dicté: étant dit "Do X" est pas le même comme étant dit «Nous avons pour générer plus de 10%
. recettes "L'ancien est une directive;. celui-ci est un problème à résoudre Battez-vous pour savoir ce que le
problèmes, et se mêlent en proposant des solutions agréables au goût (voir « Résolution des conflits et
la négociation , "plus tard dans ce chapitre).

Équipe ou les questions de personnel . Une ou plusieurs personnes sont mécontents de quelque chose, et il est
un impact négatif sur l'équipe. Cela pourrait être personnelle («Je ne peux pas supporter de travailler avec Fred") ou il
pourrait être systémique («Je déteste la façon dont nous faisons des revues de code"). Réponses possibles: commencer par parler de un
sur-un pour les personnes impliquées. Demandez-leur ce qui se passe et ce qui peut être fait (par vous ou par
eux) pour améliorer les choses. Rincez le problème et laisser les gens se défouler. Rechercher les causes, pas
seulement des symptômes (voir " la résolution des conflits et la négociation ", plus loin dans ce chapitre).

Le désaccord et de conflit . Les gens ouvertement en désaccord sur ce qui devrait être fait (qui peut
être en bonne santé), mais les désaccords sont maintenant empêchent les progrès d'avoir lieu. Plus de temps
est passé à débattre et revoir constamment ce qu'il faut faire, au lieu de le faire. Dans l'extrême
cas, les différentes factions sont secrètement travaillent dans des directions différentes. Réponses possibles: voir la
section « La résolution des conflits et la négociation ", plus loin dans ce chapitre.

Le manque de foi . L'équipe vient de ne croit pas dans la direction de projet. Ils font le travail,
obtenir le long, et pas en désaccord activement, mais ils pensent que le navire se dirige tout droit pour le
iceberg. Alternatives possibles: voir si ils ont raison. Si ils ne sont pas, utiliser l'influence (voir chapitre 16 )
pour aider à construire un soutien derrière la direction. Commencez petit: qui a le plus de foi? Comment peux-tu
cultiver sa croyance et de l'envoyer au reste de l'équipe? Essayez de fixer des objectifs plus petits pour le
équipe et donner une impulsion. Aller de porte-à-porte et demander la confiance des gens: «Regardez, je vous connais
ne crois pas à cela, mais je le fais. Est-il possible que je peux vous convaincre de passer derrière cela? Dans le cas contraire, est
il possible pour vous de me faire confiance de toute façon, au moins pour la semaine prochaine? "

Menaces de mutinerie . Ceci est la violence, forme aiguë de manque de foi. Un moment où est atteint
le seuil de frustration de l'équipe a été dépassé et ils répondent mal à chaque nouvelle
problème qui surgit, peu importe combien il est petit. Plus encore, les gens se plaignent plus sur méta-
problèmes (par exemple, «Pourquoi ne la gestion / test / commercialisation continuer à faire cela?") que réelle
problèmes. Si on ne fait rien, les anciens combattants peuvent soutenir les plaintes, et une petite ou symbolique
des actes de subversion va commencer à prendre endroit (par exemple, certains bogues peuvent soudainement devenir difficile à
réparer). Quelqu'un doit répondre à ce front et la désamorcer. Reconnaître publiquement la question,
faire une liste de toutes les plaintes, et visiblement répondre à au moins certains des éléments de la liste.

Une grande partie de ce que peut faire ce genre de situations difficiles est pas la situation elle-même, mais le contexte dans
laquelle elle se produit. Le plus tard dans le calendrier un problème qui se passe, et de l'affaiblissement du moral de la
équipe (ou PM), plus il est difficile à traiter. Vers la fin, il ya moins de mouvements disponibles à
 résoudre le problème, et les enjeux à faire des mouvements sont beaucoup plus élevés. Parfois, ce fait rend
facile de se retrouver débats en pointant à la chronologie. Au cours de la fin du jeu, de nombreux types de questions deviennent
prohibitif pour changer, et il devient plus facile d'argumenter pour vivre avec le problème maintenant
et la fixation dans la prochaine version (ou étape). Mais notez que défaillant sur un problème ne
résoudre: il signifie simplement que vous avez un chemin facile pour avoir refusé de traiter le problème, qui peut être le
bonne chose ou une mauvaise chose pour le projet.

Il est également important de réaliser que les situations difficiles ont souvent des débuts et les terminaux floues. Non
Témoin lumineux rouge se éteint sur votre bureau vous dire que le moral est bas ou qu'une surveillance a juste
été faite. Vous devez regarder pour elle, et même si vous le faites, il ne sera pas toujours clair à 100% ce qui se passe
sur. Et puis si il ya un problème et que vous décidez de prendre des mesures, vous pouvez seulement être en mesure d'atténuer
et minimiser son impact; il pourrait ne pas être entièrement solvable. Cela signifie que vous avez à gérer mineure
les questions et les symptômes causés par le problème pendant des semaines ou même des mois. (Par example,
la gestion de deux programmeurs ou testeurs qui ne reçoivent pas juste le long de bien. Vous pouvez aider les choses plaquées sur,
mais vous ne pouvez pas résoudre leur conflit complètement.) Donc, une partie de ce qu'il faut faire quand les choses vont mal est-à-
consacrer du temps pour maintenir les problèmes chroniques et insolubles à un niveau tolérable. Le plus
problèmes que vous la gestion de cette façon, plus le temps vous aurez besoin de consacrer à l'entretien et
limiter les dégâts.

Page 197

11.2.3. Assurez-pratique et la formation difficile

Une bonne formation pour les gestionnaires de projet doit inclure des exercices et des jeux qui simulent mettre en GP
ces situations. Je l'ai appris que enseigner aux gens le cas idéal pourrait être la meilleure façon d'apprendre de base
théories, mais l'amélioration de la gestion de projet compétences et de faire comprendre les théories sont atteints
seulement par l'enseignement cas de défaillance et de défi. Les cours les plus réussies que je enseignent l'accent sur les situations
et des exercices de défi, plutôt que des formules et des concepts. Penser à nouveau cyniquement, le défi
de la gestion de projets ne navigue pas dans les eaux calmes et ouvertes avec un ciel clair. Au lieu de cela, le défi est en
sachant comment jongler, hiérarchiser et de répondre à toutes les choses inattendus et difficiles que vous êtes
confronté à. (Bien que peut-être la compétence ultime pour PMS est de changer les mers agitées dans le calme
eau avant les ensembles de l'équipe à la voile.)

Donc, si vous travaillez avec ou gérer d'autres gestionnaires de projet, et que vous ne disposez pas d'opportunités pour le bon
la formation, il est essentiel d'utiliser ces situations difficiles comme des occasions d'apprentissage quand ils se produisent. Comme
stressant et frustrant car ils sont, l'expérience d'aller à travers eux est d'or pur pour la prochaine
projectif vous prenez le temps par la suite pour les examiner. Stewart Brand a dit une fois, "à la hâte, erreurs
cascade. Avec délibération, erreurs instruire. " (4) Même dans la pire catastrophe, PMS ont encore le contrôle
sur la façon dont ils réagissent. Et à moins que la situation est littéralement fatale pour l'équipe, il ya toujours la
possibilité d'apprendre de quelque chose après qu'il est arrivé.

En ce qui concerne d'autres situations difficiles: il ya de nombreuses façons de briser le possible

problèmes que vous pourriez rencontrer. Si vous êtes à la recherche pour les grandes listes d'apprendre, la meilleure source unique
Je ai vu est le chapitre 3 de développement rapide par Steve McConnell (Microsoft Press, 1996). Le second
meilleure source est le catalogue de les anti-( http://c2.com/cgi/wiki?AntiPatternsCatalog ), qui est
en fait une lecture plus intéressante et colorée, mais il est plus difficile à appliquer et ne sont pas toujours bien
écrite (qui n'a rien de surprenant, car il est un système de wiki).
Page 198

11.3. Prendre la responsabilité

Assumer la responsabilité de quelque chose ne rend pas votre faute: cela signifie que vous allez faire face à la
conséquences et être responsable pour résoudre la situation. Beaucoup de gens craignent de prendre la responsabilité
parce qu'ils ne veulent pas être tenus pour responsables et mettre à risque de ridicule ou de réprimande. Un bien
gestionnaire doit avoir la disposition contraire: dans les affaires impliquant son équipe ou son projet, il
devrait rechercher la responsabilité et l'utiliser pour aider l'équipe et le projet réussir. Si soulager une
ingénieur ou d'un testeur de la peur du blâme me obtenir une meilleure solution, ou la même solution plus rapide, je serais
prendre volontiers le commerce. Si mon propre gestionnaire est tout bon, en prenant la responsabilité d'un problème pourrait
gagner me louange. En prêtant responsabilité réelle du problème, je fais instantanément le problème moins
dangereux pour le projet (voir la section tard " Rôles et une autorité claire ").

Cette idée de prendre la responsabilité peut s'étendre non seulement à blâmer ou de l'échec, mais à toutes les relations avec
les autres gens. Comme l'a écrit Larry Constantine dans Beyond Chaos: The Edge Expert en gestion des logiciels
Développement (Addison Wesley, 2001):

Au lieu de demander pourquoi une personne est si difficile, je trouve qu'il est plus utile de me demander pourquoi je
suis ayant difficilement avec cette personne. Il est, bien sûr, généralement beaucoup plus faciles à repérer la paille dans un
l'oeil de collègue que de voir les macaronis dans votre propre, mais chaque rencontre frustrante avec un
personne difficile est une occasion d'apprendre plus sur vous-même. Sur le long terme, vous pouvez
vous trouverez rencontrer moins en moins de gens qui sont difficiles pour vous de gérer.

Ceci est particulièrement utile dans des situations difficiles où d'autres personnes pourraient être plus sensibles ou sujettes
à la perte de leurs tempéraments. Si vous pouvez compter sur votre propre maturité et la sagesse pour surmonter les autres
Les craintes ou irrationalités des gens, vous devenez capable de mener un projet à la réussite en dépit de la
comportement frustrant ou contre d'autres.

Prendre ses responsabilités, même pour les échecs ou des situations difficiles, est toujours une occasion de croissance. Par
donner de votre propre peau, vous vous donnez un certain type de pouvoir parce que vous placez
vous dans le milieu de quelle que soit la situation. De détourner le blâme ou esquiver la responsabilité pourrait
vous aider à éviter le problème à court terme de nettoyer les dégâts, ou de répondre à des cadres supérieurs sur une
question difficile, mais il élimine également toute possibilité d'apprendre quelque chose ou à croître et à
démontrer vos capacités. Vous devez être prêt à vous brûler si vous voulez développer la compétence des
éteindre les incendies.

Au niveau pratique, utiliser votre volonté de prendre la responsabilité de responsabiliser les autres pendant les crises. Ajouter
la phrase suivante à votre Playbook pour travailler avec les autres: "Je ne suis pas sûr de savoir comment cela est arrivé, je
ne se soucient pas maintenant. Nous pouvons tri plus tard, et quand nous le faisons, je vais aider à prendre la responsabilité pour ce qui est
arrivé. Mais parce qu'elle ne se produise, nous devons faire X, Y et Z, et nous devons le faire maintenant. Peux tu
aidez-moi à comprendre comment faire X, Y et Z? "

Alternativement, dans certaines situations, la chose la plus puissante que vous pouvez faire est de donner votre responsabilité
un moyen. (Dans le chapitre 12 , je vais couvrir l'importance de la confiance et de la façon dont la délégation est une forme majeure de celui-ci
que les gestionnaires peuvent utiliser à l'avantage du projet.) Dans les moments difficiles, reconfirmer votre confiance dans
les capacités de quelqu'un pourrait avoir un effet plus positif que tout intellectuel ou technique
contribution que vous pourriez faire:. "Sally, regarde, je te fais confiance, je sais que cette question est difficile, mais tu es la.
expert. Cependant, vous pensez que nous devrions traiter avec elle est l'opinion que je me mettrai derrière. Mais voici mon
rétroaction. Repensse y bien. Si vous n'êtes toujours pas, nous irons à votre façon. "

Page 199

11.4. Limiter les dégâts

 Si suffisamment de problèmes se produisent en même temps, ou si quelque chose de vraiment dévastateur arrive, la première
déménagement doit être de limiter les dégâts. Cela signifie que dès le premier instant avant, votre priorité est
pour renvoyer le projet à un état acceptable. Imaginez être le pilote d'un 747 qui vient de perdre tous
puissance du moteur. Jusqu'à ce que vous avez restauré la puissance, pas grand chose d'autre questions. Toute votre énergie est concentrée sur
résoudre le problème que l'un des problèmes les autres dépendent de la. Vous êtes en mode dommages-contrôle.

Qu'est-ce que les pilotes et les capitaines sont formés pour le faire dans les situations de dommages-commande est de diagnostiquer le problème,
et essayer d'isoler la fois les symptômes et les causes. Pilotes et astronautes avions ont généralement une
procédure spécifique pour ce faire à chaque situation majeure qui pourrait se produire (souvent ces procédures
sont conservés dans un livre, car il ya beaucoup d'entre eux). L'idée est que quand la merde a vraiment touché le
ventilateur, il n'y aura pas de temps pour inventer une procedureand peut-être même pas assez de temps pour suivre un. Ainsi,
lorsque les pilotes ne se trouvent dans une situation d'urgence, ils commencent la séquence de diagnostic et de
travailler systématiquement le problème jusqu'à ce qu'ils trouvent une résolution (ou, si elles échouent, accident).

En tant que chef de projet, vous finirez par vous retrouver dans une situation d'avarie. Il n'y aura pas
le temps d'explorer des solutions de rechange ou envisager des options. Il y aura quelque chose de très important qui est très
cassé, et il ne sera pas clair comment il peut éventuellement être résolu. Pour gérer cette situation, suivez ce
la liste:

Convoquer une réunion tout-mains . La nouvelle se répand rapidement à travers une équipe quand quelque chose de très
important est évidemment très mal. Plus vous attendez pour y faire face, plus la dissension et la peur
l'équipe devra quand vous faites. Prenez le taureau par les cornes et de convoquer une réunion, ou envoyer haute
priorité email à l'équipe. Expliquez brièvement la situation et que vous travaillez dessus. Si
possible, expliquez ce que vous faites au cours des prochaines 24 heures (voir « Appliquer le rough guide , "
plus tôt dans le chapitre), et de définir le prochain point dans le temps lorsque vous aurez une mise à jour. Ne pas
cacher de gros problèmes: votre équipe va sentir que quelque chose est faux, peu importe à quel point vous
sont à leur cacher.

Si les gens sont en désaccord, trouver le point d'accord . Nous verrons cela plus en
section suivante. Mais si vous êtes dans une salle pleine de gens qui semblent ne pas d'accord sur ce qui est
passe ou ce qui doit être fait, prendre le contrôle et réinitialiser la discussion. Le ramener à la dernière
point d'accord: "Avons-nous tous d'accord que nos objectifs sont A, B, et C, et dans cet ordre?" Une fois
vous avez un point d'accord, mais il est simple, avancer les travaux sur les problèmes que vous êtes
face. Prenez les questions une à la fois et ne pas laisser la discussion se déplacer devant eux jusqu'à ce
ils ont été résolus ou assignés à quelqu'un en dehors de la réunion qui va les conduire.

Quel est le plus récent bon état ​connu pour le projet et l'équipe? Si le dommage
vous contrôlez est technique, revenir en arrière dans le quotidien construit (que vous devriez garder un
archive de) pour trouver la dernière bonne construction. Mettez sur la table pour remettre le projet à cet état.
Cela pourrait être plus rapide que la poursuite du projet de l'Etat qu'il est dans. Les programmeurs peuvent
réappliquer manuellement changements qui sont perdus, et vous pouvez appliquer des contrôles plus élevés pour éliminer le
cause du problème. Ceci est un changement radical, mais il assure la stabilité et la confiance à la
détriment du temps de calendrier.

Le problème peut être isolé? Pensez à un bateau qui est actuellement sur ​le feu. Le feu peut être
contenue? Les parties les plus critiques du navire peuvent être protégés contre le feu? Penser à
comment vous pouvez séquestrer le problème et l'empêcher de heurter les parties les plus critiques
votre projet. Cela peut nécessiter de sacrifier engagements moins importants ou ressources commerciales
d'une partie de l'équipe à l'autre. Il pourrait nécessiter l'aide à court terme d'autres
des gens d'autres régions pour aider à isoler et contenir le problème, mais parce qu'il assurera une
état stable pour le projet, ça vaut le compromis.

Les ressources peuvent être appliquées pour aider avec les dommages? Dans certains cas, vous pouvez passer votre
moyen (en termes d'argent ou de personnel) sur un problème. Envisager une véritable catastrophe comme un

Page 200

tremblement de terre ou une tornade: vous pouvez dépenser de l'argent pour déménager le projet ou pour acheter de nouveaux
équipement immédiatement pour aider à maintenir le projet en vie alors que des solutions à long terme sont trouvés. Si
vous découvrez une grande lacune dans la couverture d'assurance de la qualité, vous pouvez parfois pour externaliser
personnel supplémentaire pour couvrir des cas de test actuellement sans pilote ou de construire des processus. Jeter de l'argent ou
d'autres ressources à des choses peut parfois fonctionner si votre but est bon et il est le bon type de
cible.
Page 201

11.5. La résolution des conflits et la négociation

"Ce qui devrait nous inquiéter est pas le nombre de personnes qui nous opposent, mais comment bon
Leurs raisons sont pour le faire ».

Alain de Botton

Règlement des différends est gestionnaires de quelque chose doit le faire tout le temps. Le fait que la négociation apparaît
seulement dans ce chapitre ne signifie pas que d'avoir à résoudre les désaccords signifie quelque chose est allé
faux. Au contraire, une équipe dynamique et en santé devrait avoir suffisamment d'idées et opinions que
désaccords se produisent régulièrement. Tant que les gens sont en train de débattre des mérites de différentes idées et
traiter mutuellement avec respect, les désaccords fournissent des points de vue alternatifs et conduisent effectivement
progresser. Les choses importantes sont alors comment les gens traitent les uns les autres quand ils sont en désaccord, comment
ces désaccords sont résolus et si les désaccords et les débats sont convertis en positif
action.

Cela dit, en temps de crise, la capacité à résoudre les désaccords et de négocier est extrêmement important.
Vous devez être en mesure de trouver des compromis appropriés et de travailler dans des situations difficiles mutuellement
des résultats bénéfiques. De loin, la meilleure ressource pour apprendre la bonne attitude et les compétences pour ce faire est
le petit livre Getting to Yes par Roger Fisher (Penguin Books, 1991). (5) je ne trouve pas ce livre jusqu'à
plus tard dans ma carrière, et en le lisant, je trouve une meilleure compréhension de ce qui avait bien passé, et
ce qui a mal tourné, dans toutes mes expériences de négociation précédents. Je ai également réalisé que la négociation a pris
placer dans de nombreuses formes différentes. Parfois, je aidait deux personnes de l'équipe de résoudre un problème.
D'autres fois, je faisais partie des deux personnes en désaccord, mais sans le bénéfice d'un tiers
intéressé à aider à résoudre le conflit, je suis obligé d'agir en tant que négociateur. Dans tous ces cas, je trouvai
une approche de base qui a fonctionné pour moi, que je vous ai présenté ici:

Trouver le point d'unification . Deux personnes, peu importe combien ils sont en désaccord, d'accord sur
certaines choses: la terre est ronde, le ciel est bleu, le projet doit être à l'heure. Trouvez le
points importants de l'unification et de l'accord et de les utiliser pour commencer toute discussion que vous avez.
Vous voulez commencer toute négociation avec un élan positif. Régler les questions litigieuses
l'intérieur d'un cadre de l'intérêt mutuel et la perspective commune. Faites un diagramme de Venn des choses
 que l'intérêt des
intersections, partieschose
quelque A et choses
manque:quipourquoi
intéressent la partie avoir
seraient-ils B, et noter les intersections.
une base Si il
d'accord si elles ontn'ypas
a pas
intérêts communs?

Reconnaître les conflits de personnalité et ensuite les ignorer . Il est très facile de tomber dans le piège de
permettant les traits de personnalité de quelqu'un pour vous distraire de l'objectif de la négociation, surtout si
vous êtes l'un des deux partis. Au lieu d'essayer de trouver des situations qui profitent à tout le monde, il est
facile à glisser dans la négociation de voir comme une compétition: vous voulez gagner, ou pire, faire le
"Adversaire" perdre. Ceci est une distraction complète de vos objectifs réels. Si vous trouvez que vous ne voulez pas
la personne avec laquelle vous négociez, ou les personnes dont les conflits que vous essayez de résoudre, trouver un
façon de séparer ces sentiments de la tâche à accomplir (ou déléguer votre rôle à quelqu'un d'autre).
Concentrez-vous sur la façon dont le projet est desservi par la résolution du problème, et de faire que votre motivation.

Recherchez intérêt mutuel . Si vous disposez de toutes les façons possibles de résoudre toute situation, vous
trouvera toujours des choix qui profitent aux deux côtés. Vous pouvez les trouver qu'en formulant les questions
discussion autour des intérêts et des positions pas contradictoire. Une position est un ensemble de spécifique
demandes («Je vais manger seulement un gâteau au chocolat"). Un intérêt est un objectif de niveau supérieur ("Je veux un savoureux
et un dessert satisfaisant "). Loisirs peut être satisfait de différentes façons, mais les positions ont
quelques solutions. Souvent, les gens qui sont en conflit ne sont pas conscients des intérêts des uns et des autres, et de leur
énergie est dépensée luttant contre des positions différentes. Pourtant, les intérêts sont beaucoup plus faciles à comprendre et à
travailler avec que des positions. les gens de la Force de parler des intérêts et de parvenir à un accord (ou au moins
comprendre) à ce niveau, avant d'entrer dans des discussions sur les moyens propres à satisfaire
les intérêts de tout le monde. Liste des intérêts des deux parties et de les relier de nouveau au point de
unification: certains intérêts soient mieux dans la zone unifiée que d'autres. Faire comprendre à

Page 202

tout le monde impliqué lesquels ceux-ci sont.

Soyez forte mais souple . Si vous avez une position difficile que vous avez besoin pour maintenir, chercher d'autres,
positions moins importantes que vous êtes flexible sur. Si vous ne pouvez pas glisser vos dates, pouvez-vous changer
vos fonctions? Si vous ne pouvez pas donner plus de temps, pouvez-vous donner plus d'argent? Sachez ce que vous les points
sont flexibles sur et peut travailler avec, et ceux qui sont fixés. Le mieux que vous comprenez la
personne avec qui vous négociez, mieux vous sera d'offrir des choses qui sont de valeur
eux, mais vous coûtent peu. Il est sûr de dire que si vous êtes flexible sur rien, vous faites probablement pas
comprendre vos intérêts (peut-être parce que la direction vous a informé que de leur
la position, pas de leurs intérêts).

Connaître les solutions de rechange . Ne jamais entrer dans la négociation sans comprendre ce qu'il vous en coûtera
au pied de la table, et ce que ça va leur coûter à marcher loin de la table. Arriver à
Oui appelle ce votre BATNABest alternative à un accord négocié. L'idée est que cela devrait
aider à déterminer quels sont les intérêts et les positions que vous demandez. Le mieux votre BATNA est relative à
vos homologues », plus la puissance de négociation, vous avez probablement. Par exemple, disons
vous êtes bloqués dans le désert avec une douzaine de personnes, et vous avez le seul gallon d'eau douce.
Fred propose 5 $ pour elle. Vous pourriez dire non et probablement trouver une meilleure offre de l'un des autres,
mais seulement Fred peut négocier avec vous. Fred a quelques solutions de rechange raisonnables, alors que vous avez
plusieurs. Fred pourrait être le meilleur négociateur dans le monde, mais cela n'a aucune importance si vous êtes au courant de
la supériorité de vos options, par rapport à la sienne. (6)

Utilisez la persuasion et argumentation . Dans la plupart des cas, les intérêts et les désirs des deux parties sont
sur la base des opinions subjectives sur la valeur relative des choses. Cela signifie que si vous pouvez
développer une véritable compréhension des sentiments d'une partie, vous pouvez éventuellement les persuader que l'on
aspect de la situation est plus (ou moins) souhaitable que ce qu'ils pensaient. Être persuasif est une compétence:
il allie charisme, des capacités de communication, de la logique, et les choses qui peuvent être psychologyall
appris avec l'expérience et d'efforts. Essayez de faire preuve de tact quand persuader les autres, et de concentrer votre
efforts sur les points les plus importants au progrès.

L'acte de négociation est vraiment juste une forme particulière de la discussion. Obtenez les bonnes personnes dans la salle
(Voir « Appliquer le rough guide , "plus tôt dans ce chapitre), établir un programme qui comprend la discussion des
enjeux et les intérêts, et travaillent ensuite de trouver des alternatives possibles qui les résolvent. Si les personnes en
conflit sont dans la même organisation, vous pouvez compter lourdement sur les objectifs du projet pour encadrer ce
devraient être les intérêts de plus haut niveau pour toutes les personnes impliquées (le point d'unification). Les propositions et les
contrepropositions sont faites jusqu'à ce qu'une résolution soit atteint.

Si les personnes en conflit sont deux organisations différentes, les choses deviennent plus complexes: il peut
être moins confiance et les relations les plus faibles entre les personnes impliquées. Le premier objectif doit être de
répliquer quelque chose de semblable aux objectifs du projet: pourquoi sommes-nous en affaires ensemble? Quels sont les mutuelles
raisons bénéfiques pour nous de travailler ou de ressources échange? En règle générale, cela devrait être fait
lorsque cette relation commence (contrats sont une forme simple de ce type d'accord). Il clarifie
les intérêts de chacun et qui procure une base de référence devrait se référer à des conflits ou des désaccords surgissent plus tard
sur (ainsi que de minimiser les chances de ces désaccords formant en premier lieu). Mais au lieu
d'un accord de préemption, il peut être fait après le fait. Il sera plus difficile de le faire parce que la confiance
et la bonne volonté ne sera pas élevé, mais il est le seul chemin vers la recherche d'une solution.
Page 203

11.6. Rôles et une autorité claire

Il ya deux leçons que je appris de jouer les sports de compétition. Tout d'abord, une réelle confiance est gagné seulement quand
défis surface et sont surmontés. Il est seulement quand il ya un différend ou d'un argument, où quelqu'un
est contrarié ou peur et la vérité sort, que les relations ont la possibilité de grandir. Deuxième,
bonnes équipes fonctionnent de manière efficace parce que chaque individu comprend son propre rôle ainsi que le rôle
de toute autre personne dans l'équipe. Les choses vont bien quand chaque individu peut dépendre de la
contributions des autres, au point qu'il peut confortablement se concentrer sur ses propres tâches. Un guitariste
dans un groupe de rock ne peut pas faire un grand solo si le bassiste et le batteur ne fournissent pas un rythme fiable
la structure pour lui de travailler dans. Il est le même que les attaquants et meneurs dans le basket-ball, ou
quarterbacks et joueurs de ligne offensive dans le football américain. Et, bien sûr, il est certainement vrai pour
programmeurs, testeurs, et d'autres sur les équipes techniques.

La capacité à compter les uns sur les autres dans l'activité de l'équipe devient plus important que le stress et la pression
augmenter. Les choses sont susceptibles de tomber en panne, et les gens ont la première occasion à l'échec, avoir peur, ou
blâmer les autres quand les choses vont mal. Travail complexe est souvent fortement interdépendants, ce qui signifie que
Fred sait qu'il va échouer à remplir sa passe de test si Sara ne reçoit pas son code de travail à temps. Il
a de bonnes raisons de s'inquiéter: il n'a pas travaillé avec elle assez pour construire une réelle confiance dans sa capacité à
livrer dans des situations difficiles.

Ainsi, lorsque la pression est sur, il est fréquent de voir des équipes inexpérimentés ou immatures luttent avec
leurs rôles. Les individus en question la capacité des autres sur l'équipe et de faire ce qu'ils peuvent pour
se protéger contre la possibilité de défaillances causées par d'autres (souvent gaspiller de l'énergie dans le
processus). Même des gens expérimentés peuvent le faire si elles travaillent sur des équipes composées de personnes qui
ont pas construit beaucoup de confiance en l'autre.

Cela signifie que beaucoup de ce que le Premier ministre doit faire pendant les périodes difficiles est de renforcer la structure de rôle
l'équipe. Rappeler à tous ce que d'autres comptent sur eux pour faire et ce qu'ils devraient être
attendant les autres à faire pour eux. En tant que leader, il est à vous de déterminer qui est de plus secoué ou
nerveux, et de leur rappeler comment êtes-vous confiant dans l'équipe. Soyez conscient de qui se sent ignoré ou
vulnérables, et de travailler à changer leur perception. La tenue d'une équipe ensemble est pas fait quelque chose
avec de grands discours ou de grands gestes. Au lieu de cela, allez simplement aux gens et assurez-vous qu'ils se sentent connectés
à ce qui se passe et ce qu'ils ont besoin de croire qu'ils peuvent contribuer à ce succès.

Dans certains cas, les gens ont besoin de soutien et de défense de jouer leurs rôles. Le GP devrait sauvegarder personnes
qui sont honnêtement essayer de faire leur travail, mais reçoivent questionnement injuste ou improductif de
autres. Souvent, cela se passe autour de sous-équipes ou divisions rôle, comme entre la programmation et
essai ou l'ingénierie et de la commercialisation. Donc, quand vous entendez un commentaire injuste, comme "Mon dieu,
Bob doit être un idiot si il n'a pas encore terminé ce passage de test, "vous devriez dire, le cas échéant," Steve,
Bob est derrière maintenant, parce que l'équipe de développement était derrière toute la semaine dernière. Peut-être que vous pouvez l'aider à sortir comme
l'équipe de test vous a aidé les gars à l'arrière puis, hmmm? "Soyez la conscience de l'équipe et de garder
des gens honnêtes, si nécessaire.

Si il ya une réelle incompétence quelque part (par exemple, Bob est en fait un idiot), il est à l'heure d'engager
les individus et les gestionnaires directement, et assurer que le problème est identifié à ceux qui sont dans le
meilleure position pour faire quelque chose à ce sujet. (Base de la rétroaction sur le rôle de la personne est censé être
jouer et quelles parties de celui-ci ne se produisent pas. Il ne peut être l'incompétence autant qu'une
manque de communication au sujet des rôles ou des engagements). Mais la plupart du temps, les problèmes d'une équipe
en situation de stress sont la communication, erreurs honnêtes, manque de confiance, et le rôle des échecs, qui ne sont pas pures de
la bêtise ou de l'inaptitude.

11.6.1. Tout le monde devrait savoir qui est le décideur

Dans les moments difficiles, il doit y avoir une ligne claire de l'autorité de prise de décision. Si l'équipe est dans l'impasse
et une décision difficile doit être faite dans les cinq prochaines minutes, avec le sort du projet articulé sur le

Page 204

résultat, qui devrait le faire? Dans les organisations militaires, la chaîne de commandement existe pour vous assurer que le
réponse à cette question est toujours clair. Parce que les décisions seront prises sous beaucoup de stress et
de courts délais, ils ont besoin d'une structure de gestion qui est incontestable et peut être invoquée pour
 exécuter efficacement,
recevoir est indépendamment
axé sur la confiance de la façon
dans la chaîne dont une situation
de commandement. deles
Pour confusion pourrait
projets, la être.
règle de Une
base grande
devrait partie
être aussides soldats de formation
suivante: plus la pression et plus les enjeux, moins il devrait y avoir aucun doute sur qui a
autorité.

Sur les projets, la chaîne de commandement pour les décisions difficiles devrait dépendre managementmost
spécifiquement, la gestion de projet. Si le défi à relever consiste commercial, technique, et
les questions relatives aux exigences, pas un expert (marketing, ingénierie) va avoir le meilleur ensemble
perspective. Cependant, le Premier ministre, étant donné l'ampleur de son implication dans le projet, a le plus fort
compréhension des différentes considérations et les impacts possibles de ces décisions de compromis. Si
plusieurs personnes font des tâches PM, il faut simplement être un processus clair pour qui décide quoi et qui
obtient d'être impliqués. Les discussions de rôles décrits dans le chapitre 9 devraient inclure la couverture de décision
faisant autorité, et ils peuvent être utilisés pour clarifier d'autres questions d'autorité.

Mais rappelez-vous que le décideur, quel qu'il soit, a toujours le droit de déléguer ou de
collaborer. Ce qui est essentiel est alors pas que Bob ou Michelle ou M. VP prend toutes les décisions difficiles,
mais que tout le monde dans l'organisation sait qui aller quand certains types de décisions doivent être
fait, bien avant qu'une crise se produise. Cela permettra d'accroître la vitesse de la prise de décision sur une équipe, qui
peut arrêter les menaces mineures de devenir des catastrophes majeures.

Page 205

11.7. Une trousse émotionnelle: la pression, sentiments au sujet de

sentiments, et le complexe du héros

Cette dernière partie de ce chapitre portera sur des sujets liés à l'émotion pertinente lorsque l'on travaille sur des équipes
où quelque chose a très mal. Mon but ici est de ne pas vous donner une complète
traité de psychologie sur la gestion du stress, mais au lieu de vous donner un aperçu rapide des questions vous
devront faire face et les considérations clés que vous devez penser quand vous les rencontrez.

11.7.1. Pression

La meilleure définition que je trouvais le mot pression est la suivante:

 Pression (v): A, influence ou de force contraignante convaincante.

Le mot clé ici est contrainte . Pour être sous pression signifie qu'il existe des contraintes qui ne peuvent être
déménagé et doivent être traitées. Cela pourrait être le temps, les ressources, la première difficulté de la situation, ou
Tout ce qui précède. L'existence de ces contraintes signifie qu'il ya moins de choix disponibles et
encore moins de temps pour résoudre quel que soit le problème.

Mais quand les gens utilisent le mot pression , comme dans «Je suis sous pression", ils signifient il ya une certaine
menace perçue de ne pas dépasser la contrainte. Une situation de pression, telle qu'une politique
débat ou de prendre un tir à la dernière seconde gagnant, signifie que quelque chose d'important est en jeu que
peut facilement être perdu (ou au moins est censé être). Il ya souvent d'autres personnes impliquées qui le fera
souffrir si elles ne parviennent pas à réussir, amplifiant le sentiment de pression sur eux.

Qu'est-ce qui est le plus important de réaliser environ la pression est les différentes façons dont les gens répondent. Chaque
individu a des sensibilités différentes et se sentira plus ou moins de pression dans des situations différentes. Ils
auront également différentes manières de traiter ou de faire face. Pour certains, le meilleur relâchement de pression ou
le stress est l'activité physique, pour d'autres il est de l'humour. Mais, malheureusement, beaucoup de gens ne sont pas encore compris comment
pour faire face à ces choses.

Lors de situations difficiles, une tâche supplémentaire pour les dirigeants est de vous assurer qu'il ya un soutien pour
différents types de soulagement du stress. Si les témoins de l'équipe les dirigeants se moquant de leur propre stress
réponses («Quand je rentre chez moi, je suis preneuse un six-pack et de prendre le plus long bain dans l'histoire»), il
permet aux autres de suivre leur exemple. Si le programmeur en chef invite les autres programmeurs à la gym (ou le
Paintball Arena) après le travail de se défouler, d'autres auront la chance de voir si cela les aide
avec leur stress. Même ceux qui ne participent pas auront l'occasion d'examiner ce qu'est le stress
ils sont sous et où le meilleur endroit pourrait être pour le libérer. Au contraire, si les leaders sont
répressif et nier leur stress, prétendant qu'ils ne se sentent pas ou ne nécessitent pas une forme de libération (typique
comportement macho stupide), ils rendent la vie plus difficile pour tout le monde. Ne laissez jamais votre équipe pense que le
besoin de libérer le stress est un signe de faiblesse.

Attention à la menace déguisée, "Oh. Eh bien, si vous vous sentez tellement stressé que vous avez besoin de secours, peut-être
vous ne devriez pas être dans cette équipe. "Et éviter le ridicule dédaigneux," Oh, le yoga? Je suppose que ce OK si vous
besoin de beaucoup d'aide. "Ceux-ci viennent des gestionnaires qui ne savent pas ce qui est bon pour eux. Le stress
le relief est souvent pas cher ou gratuit, et il a aucun inconvénient. Même si elle n'a pas aider à soulager le stress, soutien
les gens dans la poursuite (ou ce qui en fait à leur disposition gratuitement) fournit des points de bonus de moral. Je l'ai
gestionnaires intelligents vu apporter massothérapeutes durant les moments difficiles, et faire du porte-à-porte, offrant
chaque personne un massage de 10 minutes. Il a fait des merveilles: même ceux qui ne participent pas parlé
pendant des jours.

11.7.1.1 pression naturelle et artificielle

Page 206

Pression est une force que la direction a un certain contrôle. Les actions de gestion du changement de la
la nature de la pression de plusieurs manières différentes, et la gestion d'une équipe à travers les périodes de stress exige
leur compréhension. Il ya quatre types de pression: naturelles, artificielles, positifs et négatifs
(Voir Figure 11-1 ).

Figure 11-1. Les quatre types de pression.

Je pense que la pression naturelle que les gens ressentent ont quand un engagement personnel important qu'ils
ont fait est à risque ("Oh, attendez. Je dis à Sam je dois la démo de travail par 14 heures"). Si ils croient en
l'engagement, et sont émotionnellement investi dans la qualité de leur travail, ils le feront, le tout sur leur
propre, d'accroître leur concentration et leur niveau d'énergie en réponse à la pression. Je l'appelle la pression naturelle parce
il vient directement du travail et la relation de la personne au travail. Dans ce cas, toutes
les dirigeants doivent faire est de guider et protéger cette énergie, et de soutenir les personnes de l'équipe dans leur
poursuite pour atteindre leurs objectifs. Ce genre de pression est généralement positif, car la motivation personnelle
et les besoins de l'équipe sont alignés. Cependant, il peut devenir négatif si les gens se sentent culpabilité ou de honte à propos
ne pas respecter leurs engagements, en particulier si d'autres sont à l'origine des problèmes qui ont mené à ceux
échecs.

Pression artificielle est une tactique dirigeants effectuent d'essayer et d'amplifier le sens de la pression de l'équipe. Ce
 peut être à la fois positive et négative. La forme positive est entraînée récompense, où les gens sont récompensés
pour travailler plus dur et augmenter leur performance par des moments difficiles (par exemple, soulève, promotions,
bonus). Ou, le travail supplémentaire pourrait être volontaire, où le chef demande (mais ne demande pas)
que l'équipe travailler plus fort (peut-être avec des incitations comme la passation en charges dîner pour ceux qui restent en retard, ou
laisser plus de gens travaillent à domicile). Parfois, la pression artificielle peut prendre la forme d'une fougueuse
réunion de l'équipe, où l'esprit positif derrière le projet est ravivée (peut-être générer une certaine
pression naturelle pour certains de l'équipe), et une nouvelle vague d'énergie est cultivé.

Formes négatives de pression artificielle comprennent gronder, culpabilisation, ou de menacer de façons d'obtenir
les gens à travailler plus fort. Parfois, cela implique de blâmer les dirigeants de l'équipe pour certaines défaillances, et
leur demandant de travailler plus fort pour régler les problèmes qu'ils peuvent avoir causés. Ceci est la stéréotypée
forer mentalité sergent: l'équipe a besoin d'être constamment discipliné et hurlé à pour effectuer à sa
meilleur (ou ainsi va la théorie).

La plupart du temps, il est une combinaison de forces naturelles, artificielles, positifs et négatifs qui
les gestionnaires utilisent pour conserver une équipe de bons résultats. Autant que je préfère utiliser les forces positives, parfois
il est seulement l'utilisation prudente des forces négatives qui peuvent amener une équipe autour de vous et il a porté à nouveau. Sur
Dans l'ensemble, il est un équilibre délicat et il n'y a aucune formule pour cela. Il est seulement à travers l'expérience avec
la gestion des équipes, et en observant la nature humaine, que vous devenez meilleur à l'application de ces sortes de forces.
Vous verrez que la plupart des gestionnaires expérimentés ont développé des théories sur l'application de
pression. Mais trop souvent, les théories ne sont pas tirées des expériences assez différentes pour justifier la
personnes de confiance ont en eux.

Les formulations de la pression de côté, il est clair que l'équipe a des limites sur combien de pression il peut
manipuler. Figure 11-2 montre un schéma adapté du Volume 1 de Gerald Weinberg de logiciels de qualité
Gestion (Dorset House, 1996). Il montre une courbe de performance pour les équipes travaillant sous
pression. Pour un temps, la plupart des gens et des équipes montrent une amélioration des performances lorsque la pression augmente. Mais

Page 207

au fil du temps, cette relation diminue et aplatit ensuite complètement. Quand une équipe est à son
niveau de performance maximale (aka redlining poussés à plein régime), aucune quantité de pression supplémentaire obtiendra
l'équipe à travailler plus fort, mieux, ou plus rapide. Si l'application d'une pression continue, éventuellement, le
équipe (ou individuel) seront recalés et les choses vont devenir bien pire.

Figure 11-2. Il existe une limite à la valeur de pression en augmentant

la performance.

Donc, toutefois vous décidez d'utiliser la pression à gérer une équipe, être au courant des seuils que vous êtes
travaille. Si l'équipe ne répond pas, il se pourrait que vous devez appliquer un autre type de
la pression, mais il peut aussi dire que l'équipe est redlining, et aucun montant de l'activité de gestion
va lui faire exécuter mieux. Il faut de l'expérience pour reconnaître la différence entre les deux. Dans
Bref, les membres d'une équipe de redlining auront leurs têtes vers le bas dans le couloir et ne seront pas sourire
beaucoup. Ils semblent nerveux et fatigué dans le même temps. Ils se flétrissent lorsqu'on lui a demandé de prendre le
une autre tâche ou faire un changement mineur à quelque chose de déjà terminée. Il est beaucoup plus coûteux à
récupérer de l'épuisement de ralentir le projet vers le bas, de sorte qu'il est préférable de faire ce dernier. Relâchez un peu
la pression en donnant aux gens un après-midi, jouer à un jeu impromptue de touch-football dans le
parking, ou d'ajuster la charge de travail ou le calendrier à quelque chose de sain d'esprit.

11.7.2. Sentiments sur les sentiments

Avant de vous sautez passé cette section, en supposant qu'il est des choses copain-copain qui ne vous concerne pas, laissez-moi
vous poser une question. Avez-vous déjà demandé pourquoi les gens se comportent différemment sous le stress? Si vous
ne se soucient pas, ou ne voient pas la pertinence de la gestion de projet, se sentir libre de se déplacer sur. Mais je plains
toute personne qui travaille pour vous. (Voir, culpabilisation a sa place.)

OK, qui était injuste, mais cela a fonctionné. Pour vous récompenser, laissez-moi vous dire une pépite précieuse à propos de l'homme
comportement. Virgina Satir, auteur de plusieurs livres sur la psychologie et le comportement humain, a un simple,
modèle pour aider à expliquer pourquoi les gens peuvent être si imprévisible. Autrement dit, parfois, quand nous nous sentons
d'une certaine façon (par exemple, perturber ou nuire), nous avons rapidement un second sentiment sur ce premier sentiment, et il est
ce second sentiment que nous avons tendance à agir. Par exemple, disons que je vous dis que vous drôle d'odeur.
Ce fait vous sentir triste. Mais peut-être vous vous sentez en colère à propos du fait que je fait vous vous sentez triste. Ainsi,
au lieu d'exprimer vos sentiments de tristesse, tout ce que vous êtes en mesure de faire est d'exprimer le sentiment secondaire
 de la colèrede( base
sentiment Figure 11-3
avait demontre un exemple
la tristesse simple
et ensuite de cela).
se sentir triste,Plus
maistard,
dansvous pourriezilobtenir
le moment, est toutautour de de
au sujet réaliser la
vos sentiments
réponse à d'autres sentiments.

Figure 11-3. Le modèle Satir explique que les sentiments que nous agissons sur ne sont pas
nécessairement les sentiments de base que nous avons.

Page 208

Dans le volume 1 de la qualité des logiciels de gestion , Weinberg poursuit en expliquant que le modèle de Satir a
d'autres conséquences utiles. Souvent, ce qui provoque ce second sentiment est une croyance ou d'une habitude que nous avons été
enseigné, ce qui est une constante pour le comportement émotionnel sain. Un sentiment de colère de se sentir triste est pas
un comportement universel pour les êtres humains: il a appris. En fait, selon Weinberg, nos réponses à
beaucoup d'émotions sont tout simplement ce que nous avons été exposés à notre propre développement émotionnel.

Le plus drôle sur le développement de l'enfance est que nous recevons tous croyance main-me-down et émotionnel
systèmes. La plupart des comportements que nous suivons sont en grande partie tirées de nos parents, qui ont appris
leurs comportements de leurs parents, et ainsi de suite. Jusqu'à ce que quelqu'un arrête et examine la valeur de leur
les comportements et les réactions émotionnelles, indépendante de l'endroit où ils les ont tirés de, il est difficile de
croître dans maturityor émotionnelle même de savoir comment émotionnellement mature et saine que nous sommes. Et le pire,
nous passons potentiellement un comportement destructeur ou confus à d'autres (par exemple, nos étudiants, collègues,
les amis et les enfants).

Certaines des règles que nous avons apprises pourraient être de bons, et d'autres pourraient être mauvais. Mais simplement parce que nous
répondre historiquement d'une certaine manière à quelque chose ne signifie pas que ces réponses sont en bonne santé pour nous
ou utile pour réaliser des progrès se produise.

La leçon ici pour PMS est que, parfois, les émotions que vous recevez de personnes que vous travaillez
avec la volonté de ne pas être liés directement aux actions que vous avez prises. Vous pouvez signaler un bogue dans quelqu'un est
code et il va se fâcher à vous, même si vous étiez poli et fait remarquer quelque chose d'important.

Plus spécifique à ce chapitre, le comportement humain devient plus erratique en situation de stress. Il y a plus
les pressions et les sentiments impliqués, et leur interaction est plus difficile à comprendre. Donc, en tant que gestionnaire,
qui travaille souvent avec d'autres, beaucoup de patience est nécessaire pour régler les parties de ce que vous êtes
recevoir sont dues à ce que vous avez dit, et quelles parties sont dues à d'autres sentiments des gens sont
ayant pour le moment.

Qu'est-ce que vous voulez empêcher de se produire est une cascade de ces sentiments nondirectly liés.
Imaginez si, dans la figure 11-3 , quelqu'un d'autre a répondu à une expression du sentiment B avec une déclaration
reflétant le sentiment C, obscurcissant encore la cause réelle de l'ensemble de la situation (sentiment A). Il est tout à fait
possible de se retrouver avec une réunion de cinq personnes, toutes disputes et crier, mais personne ne se trouve dans la même
contexte émotionnel: ils sont tous exprimer et répondre à des sentiments différents sur le sujet réelle
de discussion (par exemple, penser à votre dernière réunion de famille).

Autres écrivains notables sur l'émotion humaine, tels que Leo F. Buscaglia ou John Bradshaw, (7) vont à
souligner que la santé et matures émotionnellement plus une personne est élevé, plus il est conscient de son
propres émotions et celles des autres, en lui donnant un plus large éventail de choix sur la manière de répondre à la
les émotions des autres. Cela implique que chef de file dans une situation de crise a de meilleures chances de succès si elle
peut voir schémas émotionnels et faire usage de différents moyens de les gérer.

11.7.3. Le complexe du héros

Il est un type spécial de personne quand il vient à gérer la pression: la personne qui a un
complexe du héros. Ceci est tout individu qui crée des situations dangereuses compulsivement tout simplement pour qu'il puisse
les résoudre. Il peut donc compter sur le frisson et les défis de situations extrêmement difficiles qu'il
ne fera pas beaucoup pour éviter la difficulté de démarrer en premier lieu. Dans la forme mineure, il est

Page 209
 simplement quelqu'un qui aime travailler dans des situations à risque et leur survivre. Dans la forme majeure, un
personne avec un complexe du héros pourrait mettre le projet en péril, ou même essayer de le saboter.

Quand les choses tournent mal sur un projet, les personnes ayant des tendances héros complexe vont prospérer. Alors que certains
personnes flétrir ou répugnent à entrer dans le feu, ces gens sauter à droite, comme si le projet est
enfin intéressant de les obtenir. Avoir des gens de l'équipe avec des formes mineures de la complexe du héros
est grande parce qu'ils cherchent les incendies et les mettre, mais ils vont rarement causer des incendies de leur propre.
Ce sont les cas à part entière de complexe du héros que vous devez faire attention pour parce que leur comportement peut
délibérément provoquer le projet de devenir instable. Ou plus communément, ils vont se battre jusqu'à la mort
contre les actions qui feront de situations à haut risque impossible.

Le complexe du héros se développe le plus souvent chez les personnes qui ont commencé leur carrière dans des start-ups ou très
petites entreprises (volatils). Efforts héroïques et surhumains sont souvent nécessaires juste pour joindre les deux bouts
parce que ces organisations ont rarement assez de ressources pour leurs ambitions. (8) Si les choses
bien marcher, les survivants regardent leurs efforts héroïques comme une grande partie de la raison pour laquelle ils ont réussi. Dans
ce contexte d'origine, ils ont raison. Cependant, il ya des mauvaises habitudes qui se cachent derrière cette logique: juste
parce héroïsme étaient nécessaires dans la situation A ne signifie pas l'héroïsme sont nécessaires, voire bénéfiques, dans
situations B, C et D.

Le complexe du héros a plusieurs croyances de motivation, qui sont expliquées ou réfutée dans la liste suivante:

La planification est inutile: je l'ai prouvé . Parce que le héros a une expérience réussite
sans caractéristiques ou les horaires, il croit que ces choses ne sont jamais nécessaire. Cette croyance échoue
parce que de la façon dont différents projets peuvent être. A 5 personne, le projet de 1 mois a fondamentalement
des contraintes et des risques qu'un de 200 personnes, l'effort de 12 mois. Il peut exiger différents
approches de la gestion, la planification et l'ingénierie. Une partie de cette (imparfait) est la croyance
notion que le héros a connu tout ce qu'il ya à l'expérience sur les logiciels
développement. Cette arrogance l'aveugle des problèmes spécifiques qui exigent un dans chaque projet
équilibre unique de la gestion, le traitement et la structuration de l'équipe à résoudre. Toujours et jamais
les réponses ne sont pas valables à la question de savoir quand un processus est nécessaire: il dépend toujours de la
les détails du projet.

Je travaille pour moi seul . La force de motivation le plus égoïste pour le comportement de héros est simplement que le
héros aime être le héros. Elle l'aime tellement qu'elle ne se soucie pas ce qui sera mis en danger, ou
détruit, dans le processus de sa jouant le rôle. Les symptômes de cette concurrence destructrice sont
avec des pairs ou d'une indifférence au travail des autres (ou même les objectifs du projet). Elle peut
ne pas réaliser que son désir d'être le héros a des implications possibles (parce que ceux
inconvénients sont largement pour d'autres personnes, pas pour elle). Dans certains cas, elle peut même pas
comprendre pourquoi ses efforts héroïques ne sont pas toujours reçus dans la façon dont elle devrait. ("N'a
Je sauve les animaux mignons, flous de se brûler quand je suis tombé sur le bâtiment pour sauver
eux? »« Oui, mais vous avez également mis le feu. ")

Le pseudo-héros . Je l'ai vu qu'une poignée de fois. L'idée est qu'en faisant

gestion pense que quelque chose est bien pire qu'elle ne l'est, puis, comme par magie, ce qui rend beaucoup
moins pire que ce qu'il semblait, un individu peut cultiver la perception d'être très bon à
tout ce qu'il fait (notre héros!). La gestion plus ignorant ou indifférent est, le plus facile
cela est à faire. Il a tendance à travailler seulement quelques fois avant de pairs ou d'autres attrapent. Ce n'est pas
exactement le complexe du héros parce que la personne en question ne fait pas envie de faire héroïque
les choses: il veut juste être perçu comme étant héroïque.

Les héros ont leurs rois insensés . La plupart des situations qui créent des opportunités héroïques
échecs de gestion. Si le projet est semaines de retard, les exigences oublis majeurs sont faits,
ou de mauvais choix de stratégie énorme force et à la fin des modifications de conception, que la direction est responsable.
Parfois, vous verrez des relations de codépendance entre la gestion et de l'ingénierie,
où la gestion dépend de l'héroïsme d'ingénierie pour couvrir (cacher) leurs erreurs. Ainsi,
au lieu d'admettre leurs propres erreurs, ils dépendent récompensant le brillant, mais peut-
évitable, le travail héroïque de l'équipe d'ingénierie. Pendant ce temps, l'ingénierie aime le frisson de
ces problèmes et ne veut pas vraiment la gestion apprendre à mieux la planification ou de la gestion
risque, malgré la façon dont souvent ils se plaignent de la gestion. Une culture de la codépendance est entière
créé, qui dépend des héros et des récompenses à la fois la création de risques et de leur résolution.

Le complexe d'échec . Ceci est différent du complexe du héros, mais est liée assez pour le faire
sur cette liste. Certaines personnes ne se sentent pas à l'aise à moins qu'il ya des choses à se plaindre.

Page 210

Lorsqu'on leur a présenté un défi, ils se sentent excuses de trouver plus de confort et pour ne pas
convaincre les gens de leur validité, au lieu d'investir cette énergie à relever le défi
et en essayant de réussir. Ils préfèrent blâmer plutôt que de gagner. Ces gens viennent en grappes
de mauvaises équipes (ou familles) où le blâme et le déni étaient plus important que toute autre chose.
Ils ont besoin de quelqu'un pour démontrer que pour eux il ya un moyen plus sain d'aller sur la vie.

La meilleure façon de minimiser les risques de la culture du héros est d'avoir une équipe de gestion active. Si
quelqu'un croit que la différence est importante, il est facile de dire si une semaine de travail de 80 heures est
le résultat d'une réponse à la crise véritablement héroïque ou une chaîne d'incompétence auto-infligée. En tant que PM, vous pouvez
ne pas avoir assez d'influence pour faire l'équipe au courant de ses habitudes entraînée héros, mais la seule façon de
savoir est d'essayer (voir chapitre 16 ).

Il est seulement par quelqu'un d'appeler l'attention sur ce comportement qu'il n'y a aucune possibilité de lui changer.
Minimalement, pousser fort pour une politique de révision autour des actes héroïques. Chaque fois qu'un héros ne sa chose,
il devrait y avoir un débat public sur ce qui aurait pu être fait pour l'éviter en premier lieu. Crédit
peut être donné au héros, mais les récompenses devraient également être distribuées pour ceux qui trouvent un moyen de prévenir
 ce genre de situation ne se reproduise à l'avenir.

Page 211

11.8. Résumé

Peu importe ce que vous faites, les choses iront mal.

Si vous pouvez rester calme et briser problèmes en morceaux, vous pouvez gérer de nombreux difficile
situations. (Rappelez-vous le guide approximatif.)

Il ya certaines situations communes à attendre, qui comprennent les oublis, étant forcés de le faire
des choses stupides, les pénuries de ressources, de faible qualité, les changements de direction, les questions de personnel, et les menaces
de mutinerie.

Les moments difficiles sont les possibilités d'apprentissage. Assurez-vous que vous et votre équipe de prendre le temps de
examiner ce qui est arrivé et comment il aurait pu être évité.

Assumer la responsabilité de situations, peu importe qui les fait, est toujours utile d'accélérer
résoudre le problème.

Dans des situations extrêmes, passer en mode dommages-contrôle. Faites tout ce qu'il faut pour obtenir le projet
un état connu et stable.

La négociation est utile non seulement dans une situation de crise, mais aussi dans la gestion. Les bons négociateurs
travailler à partir des intérêts du peuple, et non pas leurs positions.

Avoir des lignes claires de l'autorité en tout temps. Les gens devraient savoir qui a le pouvoir de prise de décision
avant qu'une crise se produit.

Les gens réagissent à la pression de différentes façons. Soyez attentif et ouvert dans la façon dont vous aidez l'équipe
 traiter avec les différents types de pression.

Page 212

Partie III: Gestion

Chapitre 12 : Pourquoi le leadership est basé sur la confiance

Chapitre 13 : Comment faire bouger les choses

Chapitre 14 : stratégie-jeu Moyen-

Chapitre 15 : la stratégie de fin de jeu

Chapitre 16 : Pouvoir et la Politique

Page 213

Chapitre Douze. Pourquoi le leadership est basé

sur la confiance

Dans ma vie , je l'ai eu plus d'une douzaine de gestionnaires. Il est sûr de dire que beaucoup d'entre eux étaient
oubliable, et certains ont été terribles. Mais quelques-uns que je voulais ou admiré pour émuler pris le temps de
gagner ma confiance. Ils voulaient que je fais mon meilleur travail, et ils savaient que cela était possible seulement si je
pourrait compter sur eux sur une base quotidienne. Cela ne signifie pas qu'ils feraient tout ce que je demandé ou donné à mon
avis de défaut. Mais cela ne signifie pas que leur comportement était prévisible. Plus souvent qu'autrement, ils
étaient à l'avant avec moi au sujet de leurs engagements, les motivations et les attentes. Je savais où je
se tenaient, ce que mes et leurs rôles étaient, et combien le soutien était disponible d'eux pour ce que je
nécessaire pour le faire.

En tant que leader ou contribue de manière significative à une équipe, tout dépend de ce que les gens peuvent hypothèses
vous faire. Quand vous dites «je vais obtenir ce fait demain» ou «Je vais parler à Sally et l'emmener à
d'accord avec cela, "les autres personnes dans la salle vont faire des calculs silencieux, peut-être inconsciemment,
à propos de la probabilité que ce que vous dites se révélera être vrai. Au fil du temps, si vous servez votre équipe
ainsi, ces cotes devraient être très élevé. Ils vont vous prendre au mot et de placer leur confiance en vous.

Bien que les films et émissions de télévision dépeignent souvent le leadership comme un haut-drame activitywith héros
courir dans des bâtiments en feu ou après avoir courageusement combattu seul contre des hordes de leadership enemiesreal quels
de choses très simples et pratiques. Faites ce que vous dites et dites ce que vous voulez dire. Avouez quand vous êtes
faux. Demandez les opinions et les idées des autres dans les décisions qui les touchent. Si vous pouvez faire ces
les choses le plus souvent, vous gagnerez la confiance du peuple avec qui vous travaillez. Quand il arrive un moment
où vous devez leur demander de faire quelque chose de désagréable ou qu'ils ne sont pas d'accord avec, leur confiance en
vous ferez votre leadership possible.

Cela implique que pour être un bon leader, vous ne devez pas être le meilleur programmeur, planificateur,
architecte, communicateur, conteur blague, concepteur, ou toute autre chose. Tout ce qui est requis est que vous faites
confiance une chose importante à cultiver, et de sortir de votre façon de partager avec les gens autour de vous.
Page 214

Par conséquent, pour être un bon leader, vous devez apprendre comment trouver, construire, gagner, et d'accorder la confiance à othersas
ainsi que d'apprendre à cultiver la confiance en vous-même.

Page 215

12.1. Bâtiment et de la confiance de perdre

Trust (n): ferme confiance dans l'intégrité, la capacité, ou le caractère d'une personne.

"La confiance est au cœur de toutes les relations significatives. Sans confiance il n'y a pas
donner, pas de liaison prise de risque, pas ".
 Terry Mizrahi, directeur de Ecco (Centre de formation des organismes communautaires)
Comme une expérience informelle, je demandai à un échantillonnage aléatoire de connaissances qui ils ont confiance dans leur
lieux de travail actuelles, et pourquoi. Toutes les réponses étaient à peu près la même chose: la confiance se gagne par
les gens qui font bien leur travail, se sont engagés à les objectifs du projet, traiter les gens équitablement, et
un comportement cohérent dans les moments difficiles. Pas une seule personne a mentionné qu'ils aimaient ces
personnes ou voudraient les inviter à dîner. Il semble que la confiance (dans un contexte de travail) est
quelque chose qui coupe sous d'autres traits de personnalité. Nous pouvons faire confiance à des gens que nous ne aiment ou ne pas
vouloir passer du temps avec.

Contrairement à d'autres attributs sur les gens, la confiance a peu à voir avec une préférence personnelle. Nous ne choisissons pas
à qui faire confiance sur la base de choses superficielles. Au lieu de cela, il ya un ensemble plus profond de calculs que nous faisons
sur qui nous pouvons compter. Si je vous demandais qui vous ferait confiance pour sauver votre vie dans une dangereuse
situation, vous choisiriez gens très différemment que si je vous demandais qui vous voudriez aller à la
les films avec. Il n'y a aucune obligation pour la chimie personnelle et de fiabilité pour être connecté à chaque
autre en aucune façon.

Mais pour examiner la confiance dans le cadre de projets, nous devons briser le concept en pratique
morceaux. Une simple unité de confiance est un engagement. Un engagement, ou la promesse, est le type le plus simple de
accord entre deux personnes au sujet de quelque chose qu'ils conviennent à la fois à faire.

12.1.1. La confiance se construit à travers l'engagement

Lorsque vous faites un nouvel ami, et il vous dit qu'il va vous rencontrer quelque part, vous le prenez sur la foi que
il sera où il dit, quand il dit. Mais si deux ou trois fois de suite, il vous se lève, et vous
finir par regarder un film ou debout dans un club seul, votre confiance en lui va diminuer. En effet, il est
rompu ses engagements envers vous. Si cela continue, votre perception de lui va changer. Vous ne serez
plus le voir comme fiable, et vous interroger sur votre confiance en lui en matière d'importance.

Selon Humphrey Gérer le processus de logiciel (Addison Wesley, 1989), l'un des centre
éléments des projets bien gérée est la capacité de la chef de file de commettre à son travail, et de travailler pour répondre
ses engagements. Humphrey croit cela est si important qu'il défini précisément les éléments de
engagements efficaces. Sa liste, avec quelques modifications, suit.

12.1.1.1 Les éléments d'engagement efficace

1. La personne qui fait l'engagement fait si volontiers.

2. L'engagement ne se fait pas à la légère; qui est, le travail à réaliser, les ressources et la
calendrier sont soigneusement examinées.

3. Il ya un accord entre les parties sur ce qui doit être fait, par qui, et quand.

4. L'engagement est ouvertement et publiquement déclaré.

5.

Page 2164.

5. La personne responsable essaie de respecter l'engagement, même si l'aide est nécessaire.

6. Avant la date engagé, si quelque chose change que les impacts ou l'autre partie par rapport à la
engagement, un préavis est donné et un nouvel engagement est négocié.

Il ya deux choses ici un intérêt particulier. Tout d'abord, les engagements fonctionnent de deux manières. Les deux
personnes impliquées sont mutuellement engagés les uns aux autres. Si Cornelius engage à Rupert qu'il sera
marcher le chien de Rupert pendant qu'il est hors de la ville, les deux parties sont tenues de respecter les intérêts de l'autre.
Cornelius devrait jamais avoir à parcourir les 25 pâtés de maisons de l'appartement de Rupert, avec l'intention de marcher
Rover dans Central Park, seulement pour trouver Rupert allongée sur le canapé à regarder la télévision ("Oh, désolé. Je
destiné à vous appeler yesterdaymy voyage a été annulé. "). La confiance de chaque parti est accordée à l'autre dans un
échange de la confiance, et l'attente est que la fiducie sera respectednot violé ou oublié.
Permettre à quelqu'un de perdre son temps ou de l'argent est une violation de la confiance.

Deuxièmement, nous prenons des engagements tout le temps. Dans toutes les conversations que nous avons en ce qui nous demandons ou sommes
demandé de faire quelque chose, et convenir d'un calendrier pour cela, nous allons prendre un engagement. Ceci comprend
des énoncés simples tels que "Hey, je vais vous appeler après le déjeuner» ou «Je vais lire que le projet de demain." Deux
les gens peuvent avoir des idées différentes sur la gravité de l'engagement est, mais il est rarement le moindre doute
que certains type d'engagement a été fait. Le moins nous prenons au sérieux nos engagements envers
d'autres, plus grandes sont les chances de leur confiance en nous vont diminuer. Il existe différents niveaux d'engagement
(Par exemple, si vous oubliez d'appeler votre femme un après-midi, elle ne sera pas assumer cela signifie que vous voulez un
divorce), mais ils ont tous se connecter ensemble et contribuer à nos perceptions de la confiance des autres.

12.1.2. La confiance est perdue par un comportement incohérent

Pour en revenir à des projets, des personnes se fracturent la confiance quand ils se comportent de façon aléatoire ou imprévisible. Quand
quelqu'un prend constamment des mesures sans tenir compte de ses engagements, elle crée des vagues de préoccupation
 et l'inquiétude qui perturbent l'équipe. L'énergie est prise loin des gens qui ont à travailler (ou composer)
avec elle. Au lieu d'appliquer leur énergie vers l'achèvement des travaux, ils ont maintenant à dépenser de l'énergie
calculer si elle va effectivement faire ce qu'elle dit qu'elle va. Des plans d'urgence doivent être
conçu, et les niveaux de stress et de douter de hausse («Si Marla ne reçoit pas ce code vérifié dans à la fin de
aujourd'hui, nous arrosé. "). Le plus négligents quelqu'un est de la responsabilité qu'elle a, plus le
vagues seront.

Une histoire intéressante (quoique douloureux) à propos de la confiance échoué implique l'un de mes anciens gestionnaires. Je étais un
gestionnaire de programme de travail avec cinq programmeurs et testeurs, et nous nous entendions bien. Jake, le
chef d'équipe, était mon manager et avait autorité sur moi et plusieurs autres GP. Le problème était
L'habitude de Jake de changer son esprit. Par exemple, lui et moi serait de discuter les grandes décisions que je faisais
qui avaient besoin de son soutien. Nous aimerions parvenir à un accord rapide sur la meilleure approche. Mais dès
que nous sommes entrés dans une réunion où de fortes personnalités ou des personnes ayant une ancienneté égale ou supérieure à Jake
en désaccord avec lui, Jake, de façon dramatique, céderait (il l'a fait environ un tiers de la
temps, mais je ne savais pas laquelle troisième). Il avait couru dans l'autre sens et d'accord avec la décision qui a été
populaire.

Je me souviens debout au tableau blanc pendant les réunions, à mi-chemin en expliquant mon plan A,
quand il serait d'accord à la suggestion de quelqu'un pour aller avec le plan B. Je arrête et regarde fixement, étonné que
Il pouvait le faire sans se sentir une chose. Avait-il vraiment oublié? Était-il autant d'un brun-
noser? Était-il pas au courant de ce qu'il faisait pour moi? Ou était-ce comportement de girouette-like
(Ci-après le vent de la salle) vraiment au-delà de son contrôle? Je ne dispose pas des compétences, puis de faire le tri,
et je ne suis pas assez savvy pour parler à d'autres le comportement que je vécu, donc je souffrais. Ma
séances d'entraînement à la salle de gym ont jamais été aussi bon.

Finalement, je essayé de discuter avec lui ce comportement. Je également documenté les décisions que nous avions fait comme
dès que nous en avons fait (e-mail est bon pour cela), et je les ai utilisé plus tard comme référence. Je suis même allé
jusqu'à lui Prep juste avant les réunions. Mais tout cela ne fait pour des améliorations mineures (au lieu
de soutenir le plan B, il venait de rester en dehors de la discussion, mais pas aidé au plan A). Je me suis vite trouvé
moi de travailler autour de lui. Je sors de ma façon d'avoir des choses décidées aux réunions sans lui
présente. Par comparaison, il avait moins de travail et plus efficace. Cela a créé d'autres problèmes sur notre
équipe (et ma relation avec Jake), mais je suis capable de gérer mes domaines et faire avancer les choses.

Le plus triste est que Jake était intelligent, et le plaisir de travailler avec. Mais parce que je ne pouvais pas lui, il confiance

Page 217

n'a pas d'importance. Il aurait été plus utile en tant que directeur si il était moins intelligent, mais deux fois plus
digne de confiance. Nous aurions certainement fait de meilleurs produits, et je aurions dépensé moins d'énergie
lui et plus d'énergie en aidant l'équipe de gestion.
Page 218

12.2. Faire confiance clair (créer des lumières vertes)

Les bons gestionnaires Je ai eu fait confiance explicite. On m'a dit, à plat, que je devais le pouvoir de
prendre des décisions pour mes domaines de responsabilité, pourvu que je devais le soutien de mon équipe. Ils (mon
gestionnaires) permettrait d'identifier les choses spécifiques qu'ils étaient préoccupés et me demander de vérifier avec
eux sur ces points. Ils me demandent ce que je devais d'eux, et nous aimerions négocier pour voir si elles
pourrait-elle fournir pour moi. Sinon, ils me adressées à se concentrer sur faire bouger les choses, au lieu de
demander l'approbation de quelqu'un d'autre. Transmettre la confiance, le sens réel de la délégation, est une chose puissante.
Certains sports ont jargon spécifiques autour de ce genre de délégation de authorityfor exemple, obtenir la
«Feu vert» en basket-ball.

Ans avant je jouais au basket au lycée, je jouais sur l'entraîneur Rob Elkins ' (1) à l'équipe Samuel
Champ Y, dans Douglaston, New York. Il m'a pris à part une journée pendant la pratique, ce qui signifie généralement
il était temps pour une réprimande. Je avais été gaffes lors de la pratique, baisser le short des autres joueurs
de sorte qu'ils ne pouvaient pas revenir sur la défense. Quand je me suis assis, je baissais la tête basse, juste au cas où. Mais
il ne dit rien. Nous nous sommes assis pendant un long moment et a regardé le reste de l'équipe de mêlée sur le terrain.
Enfin, at-il dit, "Scott, vous avez le feu vert." Je l'ai regardé. "Lumière verte?" J'ai demandé. "Oui, il
répondit en souriant, mais ne me regarde pas. "OK, Coach," je l'ai dit, et courut sur le sol. Bien que
peu de gens entendent ces paroles, en quelque sorte tous les joueurs savent ce qu'ils signifient. Alors que les joueurs sont
normalement obligé de tirer la balle uniquement en conformité avec ce jeu l'entraîneur appelle, le vert
lumière signifiait exemption. Je pourrais tirer la balle à chaque fois que je pensais appropriée; Je pourrais remplacera
tout jeu et de l'autorité de l'exercice quand je pensais nécessaire.

Une grande quantité de confiance est conférée en racontant un joueur quelque chose comme ça, ce qui est précisément pourquoi
la plupart des joueurs vont toute leur carrière et de ne jamais l'entendre. (Je continuais à jouer au basket au lycée
et sur la division III équipes collégiales, mais je ne l'ai entendu encore et ne l'avais pas entendu parler avant.) Les entraîneurs
sont généralement terrifié à renoncer à toute autorité. Tout comme les gestionnaires, ils estiment que leur pouvoir est
ténue. Debout sur la touche (ou assis seul dans un coin bureau) est un lieu d'être vulnérables.
Beaucoup de gestionnaires et les entraîneurs ont peur de ce qui va se passer si elles accordent à leurs équipes des libertés supplémentaires.
Ils oublient qu'ils peuvent toujours ajuster les niveaux de confiance: avais-je abusé de l'entraîneur de la confiance mise en Elkins
moi, rien ne l'empêchait de prendre un peu de ce retour (changer le feu vert au jaune). Plus
importante, peut-être, est que le niveau des gestionnaires de fiducie ont peur de donner est souvent le montant précis
que leur équipe nécessite de suivre effectivement le leadership de leur directeur.

Il est sûr de dire que je jouais plus difficile pour l'entraîneur Elkins que pour tout autre entraîneur que je devais. Je sentais instinctivement
que je devais maintenant une barre supérieure à la hauteur de (bien que dans un jeu que je pris sept coups de saut en une seule
trimestre, et les a tous manqué, dont je suis sûr était une sorte de record du club pour les deux tentatives et
accidents). Je ai aussi travaillé avec plus d'intensité pour les gestionnaires qui transmettaient des quantités similaires de confiance dans
moi que pour ceux qui ne l'a pas. Ce ne fut pas parce que je les aimais bien (même si cela a aidé). C'était
parce que je suis accordé l'espace pour prospérer. Il est le transfert de confiance qui crée la véritable émancipation
car elle donne aux gens la place pour travailler plus près de leur performance de pointe.

Si le potentiel maximum pour le succès est votre objectif, vous devez chercher des moyens de donner aux gens les feux verts.
Il est le travail du gestionnaire de créer des opportunités pour son équipe, ainsi que pour aider son équipe ont la
la force et la préparation à prendre sur ces opportunités.
Page 219

12.3. Les différents types de pouvoir

Il existe deux modèles de pouvoir que je vais utiliser dans ce livre. La forme avancée viendra plus tard, en
Chapitre 16 . Pour l'instant, je vais rester à la simple, mais puissant, forme de pouvoir fonctionnel.

Puissance fonctionnelle est disponible en deux saveurs: acquis et gagné. Pouvoir accordé vient par
titres de la hiérarchie ou l'emploi (parfois appelés ex "de bureau" pouvoir d'office ou). Par exemple, l'entraîneur d'une
l'équipe de basket-ball a le pouvoir de décider quels joueurs seront dans le jeu et ceux qui rester sur
Le banc. Ou le patron d'un petit bureau de vente pourrait avoir le pouvoir d'embaucher et de congédier tous ceux qu'il
choisit. Mais ce pouvoir n'a rien à voir avec la façon dont beaucoup de respect les gens ont pour le
personne manier, ou même comment compétences et de connaissances des gens beaucoup sentir le gestionnaire a. En revanche,
puissance gagné est quelque chose qui doit être cultivée à travers la performance et de l'action. Puissance gagné,
ou l'autorité gagné, est quand les gens choisissent d'écouter, pas à cause de quelqu'un autorisation accordée,
mais parce qu'ils pensent qu'il est intelligent ou utiles.

12.3.1. Ne comptez pas sur le pouvoir accordé

"Je me méfie de tous les systemizers et de les éviter: la volonté d'un système est un manque d'intégrité."

Nietzsche

L'utilisation du pouvoir accordé comme une force principale dans le leadership limite relations. Elle exclut la
possibilité d'échanger des idées, et il met l'accent sur l'utilisation de la force, plutôt que smarts. Pendant que
il ya des situations où l'utilisation du pouvoir autocratique est nécessaire, de bons leaders gardent cette épée dans son
Fourreau autant que possible. Dès que vous dessinez, personne ne vous écoute anymorethey're
l'écoute de l'épée. Pire, tout le monde autour de vous tireront leurs propres épées pour répondre à la vôtre.
Au lieu de vous expliquer pourquoi vous avez tort, ils vont utiliser leur propre pouvoir accordé à contester
votre pouvoir. Il en résulte une concurrence des forces qui n'a rien à voir avec l'intelligence ou d'un
la recherche de la meilleure solution. Pouvoir accordé (comme le «côté obscur de la force") est intérim parce qu'il est
plus facile: vous ne devez pas travailler aussi dur pour obtenir ce que vous voulez.

Une fois que je fait face à une situation qui m'a mis au carrefour de pouvoir accordé et a gagné. Ce fut pendant
Internet Explorer 2.0, quand je devais ma première mission majeure de la gestion du programme. Le premier jour, je
a été introduit pour les deux programmeurs qui je travaillerais avec le projet de loi et Jay. Jay était sympathique, mais
Le projet de loi était calme et intimidant. Il était également très élevé dans l'organisme (un niveau 13 dans le
Microsoft jargon de l'époque, ce qui signifiait qu'il était à peu près aussi haute en tant que programmeur pourrait être). JE
rappelez-vous assis dans son bureau, regardant à travers son bureau. Je l'avais parlé pendant 10 minutes et
avait-il dit à peu près rien. Il vient de se pencha en arrière sur sa chaise et me regarda.

Je essayé d'aller au tableau blanc pour voir si cela pouvait aider le projet de loi se parler. Aucun effet. Il parla seulement
de dire des choses sarcastiques ou ambiguë déconcertants, comme "Oh, est-ce vrai?" et "Wow ... intéressant
on pourrait penser que. "Il était juste en train de jouer avec moi, comme un chat avec une souris à moitié morte. Vous voyez, je suis
juste une arrogante 23 ans; Je ne savais pas ce que je faisais, malgré ma conviction est que je
pouvait faire semblant. Le projet de loi, d'autre part, était un vétéran qui était passé par cette routine
des dizaines de fois avant. En fait, je suis sûr qu'il y avait seulement deux pensées qui traversent son esprit:
"Comment diable ai-je coincé avec le nouveau mec?" et "Est-il la première ou la deuxième personne la plus stupide
Je ai jamais rencontré? "La rencontre a pris fin avec moi dans un babillage" directement à partir de la vidéo de formation des ressources humaines "
sorte de passage à quel point il allait être de travailler ensemble. (Je suis sûr que cela a confirmé pour lui
que je suis, en fait, digne de la première place.)

À l'époque, un ami (un autre PM) m'a donné ce conseil: faire la loi. Je dois dire que le projet de loi
parce que je suis le Premier ministre, et il était le programmeur, il devrait faire ce que je disais au sujet de haut niveau
décisions. Cette adapter la mythologie Microsoft des MP ("Get sur mon chemin et je vais te tuer») que je l'avais entendu
à propos, et je rallié le courage d'aller essayer de vivre à la hauteur. Mais avant que je tirai mon épée et
chargée de la colline, je bavardais avec mon manager. Entre bonne humeur rires, il a dit ne pas faire

Page 220

quoi que ce soit si téméraire. Il m'a rappelé que le projet de loi était intelligent et bien informé sur ses domaines, et je
devrait trouver un moyen de faire usage de cela. Il a également ajouté que le travail avec le projet de loi serait, comme il le dit,
"bon pour moi." Faire confiance à mon manager, en dépit de son rire, je mets mon épée loin et approché
le problème du point de vue d'obtenir autant de valeur sur le projet de loi que possible.

12.3.2. Travailler pour développer la puissance gagné

 Au cours des semaines qui ont suivi, je gagnais lentement la confiance de Bill. Il était douloureux au début. Dans le processus de
obtenir de lui de me secourir, je devais lui prouver ce que je suis capable de faire et construire à partir de la petite
les choses à la grande. Je trouve que lorsque je l'ai reconnu qu'il en savait plus que moi sur quelque chose,
bon conseil venait de lui plus facilement. Quand je pris des engagements et de suivi à travers, il
est devenu plus généreux. Je devais prendre de bonnes décisions, et de défendre mes points de vue avec une bonne
arguments, mais finalement nous avons développé une relation de travail solide. Bill m'a accordé le pouvoir de
prendre des décisions qui lui impactés de manière significative. Il a juste besoin de moi d'abord démontrer que je suis
digne de sa confiance.

Avais-je exercé tout le pouvoir que je devais au cours de ces premiers jours accordé, je l'aurais perdu
chance de pouvoir gagné. Le projet de loi aurait pu céder à moi sur ce premier jour, mais parce qu'il serait
répondre qu'à mon pouvoir, il serait difficile de se déplacer passé et à plus de collaboration
façons de travailler ensemble. Et si je comptais toujours sur l'utilisation de la puissance (qui est ce qui tend à se produire
lorsque vous commencez à utiliser la puissance), il serait devenu moins efficace au fil du temps. Chaque fois qu'un gestionnaire
ou chef dit "Parce que je le dis," ils sont palabres et éteindre le potentiel de
de meilleures opinions. Tous les gens intelligents ou passionnés autour d'eux ne seront pas contribuent leur meilleur travail
et ne sera pas heureux au sujet de leurs rôles limités.

D'un point de vue organisationnel, le comportement autocratique pousse penseurs fortes loin. Ce
encourage simultanément à l'aise avec ceux qu'on leur dise ce qu'il faut faire pour rester. Tyrans
créer des environnements que seuls les serviteurs pouvaient tolérer, et vice versa. Pire, tyrans créer d'autres
tyrans sous eux. Ces modes de comportement (voir conférer un pouvoir ou rien) Obtenez transmis
à travers les organisations, éventuellement en les empoisonnant.

12.3.3. Persuasion est plus forte que la dictée

Dans la gestion d'autres, je appris que je suis plus efficace à faire de bonnes choses si je convaincu
les gens à faire quelque chose avant de les faire faire. Quel idiot peut utiliser la puissance et de la demande tyrannique
des types spécifiques de behaviorit prend aucune compétence. Mais pour convaincre une personne intelligente (ou groupe de personnes)
que quelque chose qu'ils ne veulent pas d'abord à faire est juste, bon, ou même peut-être dans leur intérêt, est
beaucoup plus puissant. Quand ils sont heures dans le travail, et commencent à se demander pourquoi ils le font
, ils ne peuvent pas vous blâmer. Ils pourront compter sur leur propre intelligence, influencés par votre
arguments, pour expliquer pourquoi ils passent leur temps à faire ce qu'ils font.

Finalement, les gens écouté moi à cause de leur confiance dans ma capacité à avoir de bonnes raisons pour
mes opinions. Ils demanderaient moins de questions et de prendre sur la confiance que je pensais dans ma demande
eux avant que je avais fait il. Ils avaient moins de craintes au sujet de mon profitant d'entre eux parce qu'ils avaient
tant d'expériences où les intérêts du projet et l'équipe motivée mon comportement. La
Plus les gens vous font confiance, plus il devient facile de les persuader. Comme avec le projet de loi, au fil du temps, je passais moins
et moins d'énergie à convaincre les gens de thingseven bien que ce soit où je ai commencé mes relations avec
themand de plus en plus de temps faire les choses.

1 2 3 4. Soyez autocratique si nécessaire

Pouvoir accordé a sa place. Quand les choses deviennent hors de contrôle, pouvoir accordé peut être le plus rapide
façon d'atteindre le but. Si une réunion se désagrège, les grands engagements sont brisées, ou autre
problèmes fondamentaux se produisent, utilisez l'épée. Si vous êtes convaincu que l'utilisation de l'énergie directe
est la seule possibilité réelle d'un résultat positif, peu importe les conséquences, par tous les moyens
faire usage de celui-ci. Soyez clair, être direct, et d'utiliser le pouvoir exécutif que vous avez à faire avancer le projet

Page 221

vers l'avant.

Cependant, je suis convaincu que plus il est utilisé, plus il couvre pour l'organisation fondamentale
des problèmes qui doivent être abordés. Si la seule façon de le faire à travers la semaine est de crier votre chemin
grâce à des réunions ou des ordres d'écorce dans des cabines, cela signifie que la vision du projet, la structure de l'organisation, et
calendrier besoin d'être revisité. Ils sont la colonne vertébrale du projet et vous mis en place pour mener sans
nécessitant tellement utilisation de l'énergie. Si ils sont sérieux hors de l'alignement, l'autocratie ne peut qu'aider
gérer les symptômes, ne résoudra pas les problèmes de fond.
Page 222

12.4. Faire confiance aux autres

Le plus profond et plus large d'une hiérarchie d'une organisation devient, plus commun, il est de compter sur
pouvoir accordé. Il ya une plus grande peur parmi les leaders sur la façon de maintenir les masses qui travaillent ensemble
(Ou peut-être, la façon de les empêcher de commencer une révolution), et il est la croyance qu'il n'y a pas
le temps d'engager tout le monde dans l'organisation dans un genre de discussion et de communication qui exige
utilisant autorité gagné. Même sur les petites équipes, je sais que certains dirigeants qui ne croient pas qu'ils ont le
l'énergie ou de temps pour engager l'ensemble de leurs principaux contributeurs dans ce genre de style de leadership. La solution de
ce problème est un autre genre de confiance, appelé délégation: faire confiance aux autres pour prendre des décisions.

Autorité et de confiance accumulent souvent autour de différentes tâches ou domaines de connaissances. Joe peut avoir
le plus d'autorité quand il vient aux objets de C, et Sally pourrait être la meilleure personne pour base de données
travail. , Les coéquipiers de communication sains confiance assez pour savoir quand quelqu'un d'autre a
plus de compétence ou une meilleure perspective, puis solliciter les conseils de cette personne sans crainte de
embarras ou ridicule. Ceci est une crainte réelle, car les disciplines d'ingénierie ont des cultures mûres de
comportement passif-agressif autour de demander de l'aide (c.-à-rtfm). Même en informatique
départements de l'université, l'autonomie est considérée comme une compétence de base, et les étudiants demandant pairs pour
aide est souvent considéré comme un signe de faiblesse.

Du point de vue du projet, l'autorité de Sally sur la conception de base de données est seulement aussi bon que son application à
le projet. Si elle est assis seul dans son bureau, et personne ne fait appel à son autorité pour aider à résoudre des problèmes,
alors l'autorité de Sally est gaspillé, ou, au mieux, limitée aux tâches Sally fait de son propre chef. Une clé
la responsabilité d'un chef de projet ou le gestionnaire est de modéliser la délégation et le partage des connaissances pour
toute l'équipe. Si elles le font bien, le reste de l'équipe aura un temps beaucoup plus facile suit le long.

12.4.1. Délégation de pouvoirs

Traditionnellement, la délégation est utilisé pour décrire l'acte de remise de tâches ou responsabilités spécifiques. JE
pense une forme plus puissante de la délégation est lorsque des décisions, ou la capacité d'influencer les décisions, sont
distribué. Cela peut se produire à des réunions ou des discussions de groupe. Quand le chef ou le gestionnaire est demandé
"Alors, comment allons-nous résoudre ce problème?", Il a la chance de remettre ce pouvoir vers
quelqu'un d'autre. "Eh bien, Sally, tu es notre meilleur concepteur de base de données. Que pensez-vous que nous devrions faire
ici? "Tant que cela ne se fait injustement (par exemple, au milieu d'une réunion d'examen de VP tendue, au cours d'une
à défaut démo, lorsque Sally n'a aucune idée qu'elle va être attendu pour répondre aux questions), ce jeux
 un ton de collaboration. Les gens peuvent être libre de reconnaître l'expertise de l'autre, et ils donneront
autorité appropriée. Bien sûr, pour le chef de projet, rien ne se risqua. Si les suggestions de Sally
ne sont pas bonnes, la discussion se poursuit. Mais sans cette première question, la discussion ne peut jamais
arriver à tous.

Bien sûr, la délégation étend également aux transferts explicites de l'autorité. En déclarant publiquement que l'œuvre
région ou fonctionnalité va être géré par une personne, un gestionnaire transfère son autorité à celle
personne. Il est important que les délégations sont faites avec suffisamment de visibilité que tout le monde qui a besoin de
voir le transfert voit réellement. Chaque fois que je tendis hors la responsabilité à quelqu'un qui a travaillé pour
moi, je me suis assuré de contacter chaque programmeur ou testeur qui seraient touchés afin qu'ils
savoir que tout le pouvoir et l'autorité que je devais pour ce travail serait transféré à quelqu'un d'autre.
Bien sûr, parfois, les gens ne veulent pas voir les choses déléguées, et il est le travail du chef de file de l'utiliser
le pouvoir de l'imposer.

John, un gestionnaire de projet sur mon équipe, était prêt à prendre plus de responsabilités. Donc, quand le temps
venu de réorganiser la répartition du travail de mon équipe, je suis parvenu à lui donner un domaine que je l'avais été
responsable de par le passé. Après les discussions appropriées avec John et Steve (le programmeur
sur la zone), je remis la responsabilité de John. Une semaine plus tard, Steve est venu dans mon bureau pour demander
PM pour aider à la région. En écoutant, je essayé de comprendre pourquoi il me parlait et non
John. Je l'ai interrompu: "Steve, pourquoi tu me parle à ce sujet?" "Eh bien Scott, vous avez utilisé de posséder
cela, non? "" Oui Steve, mais John possède maintenant. Avez-vous parlé avec lui? »Il haussa les épaules." Steve, allez

Page 223

parler à John, "je l'ai dit." Il est intelligent. Il est bon. Faites-lui confiance. "Steve revint quelques jours plus tard, et nous
eu une version plus courte de la même conversation. Mais après cela, je jamais entendu parler de Steve nouveau (au
du moins pas à ce sujet).

John savait probablement jamais à ce sujet et n'a jamais eu besoin. Steve préférait travailler avec moi pour
une raison, et il voulait continuer notre relation malgré le changement de propriétaire. Mais à
délégué, je devais me sortir des discussions. Je pourrais sans doute ai répondu Steve
me poser des questions, et je pourrais l'ai apprécié, mais je trahirais ma propre décision de déléguer.
Jusqu'à ce que je devais une raison de vous impliquer dans cette zone du projet, je devais faire confiance à John et Steve à faire
leurs emplois, qui comprenait à l'aide de la confiance de Steve en moi, de le convaincre de faire confiance à John.

Beaucoup de gestionnaires ont du mal à déléguer. Ils ont augmenté en raison de l'ancienneté de leur capacité à obtenir du travail
fait sur leur propre, et de leader exige un équilibre différent de compétences que d'être un individu
contributeur (voir la section « L'acte d'équilibrage de la gestion de projet »dans le chapitre 1 ). Ces
les gestionnaires sont généralement freinés par la crainte qu'ils ne disposent pas suffisamment de contrôle. Bien sûr, ceci est un
piège parce que si cette peur motive leurs décisions, ils ne pourront jamais apprendre à faire confiance à personne.

Parfois, la solution est un compromis. Le gestionnaire a juste pour discuter, avec le membre de son
l'équipe au moment de la délégation, quelles considérations le délégué est tenu de faire. ("John,
Je suis inquiet pour Steve. Il a été en retard sur chaque estimation. Donc, porter une attention particulière à ce que, OK? ") En
l'établissement d'attentes autour de missions, les dirigeants transférer une partie de l'expérience et des conseils, et
probablement augmenter les chances de succès.
Page 224

12.5. La confiance est l'assurance contre l'adversité

Comme nous avons discuté dans le dernier chapitre, tous les projets devront les choses vont mal. Les concurrents ont l'habitude
de ne pas faire ce que vous leur prévoyez (qui est leur travail), les technologies vont et viennent, et important
les gens changent leurs esprits. En tant que chef de projet, il est garanti que les choses vont se produire qui étaient
pas prévu ou pris en compte. Dans les moments difficiles ou incertains, vous voulez que votre équipe ou vos pairs à être
pouvoir compter sur vous et la confiance en l'autre.

Si la confiance a été cultivée et développée au fil du temps, et les gens ont de l'expérience avec la prise de décisions
l'autre (au lieu de en dépit de l'autre), le projet aura très résistant à des problèmes. Quand
les gens croient en l'équipe, ils peuvent invoquer des formes de la confiance et de patience qui ne sont pas disponibles
par d'autres moyens. Comme des soldats dans une tranchée, chaque personne peut compter sur quelqu'un d'autre pour regarder leur
retour, les libérant de donner plus d'énergie à la tâche devant eux.

Quand une équipe a confiance les uns les autres, il achète aussi le temps de gestionnaire de projet pour se concentrer sur la résolution du
problèmes à la main, au lieu d'essayer de calmer les couloirs des employés paniqués ou frustré.
Parfois, le leader pourrait avoir besoin de demander ce type de soutien explicitement. Il doit démontrer
le respect qu'il veut de l'équipe en reconnaissant le problème et demander, mais ne demandant pas,
leur soutien. (Crier «Soutenez-moi maintenant!" Ne fonctionne pas.) Dans l'ensemble, il est des liens entre
les personnes qui les reçoivent dans les moments difficiles: pas leurs salaires, et non les technologies sur lesquelles ils travaillent, et
certainement pas combien de puissance d'un individu a ou n'a pas.

Ainsi, le chef sage, comme le capitaine d'un navire, sait que les tempêtes et les dangers invisibles se cachent à travers la mer,
et il obtient lui-même et son équipage prêts du mieux qu'il le peut contre ce qu'il ne peut pas se préparer. Si
l'incertitude est garanti, meilleur investissement du gestionnaire de projet est susceptible d'avoir eu une forte
réseau de confiance entre lui et tous ceux qui ont contribué à l'effort. Sur les grandes équipes, plus
temps devrait être consacré la confiance sur les relations qui sont les plus critiques pour le projet ou plus
susceptibles d'échouer en situation de stress. Alors que les spécifications, les documents de vision, et d'autres outils ne les aidons les gens lient
ensemble, il est la confiance dans les gens derrière ces choses que porte le pouvoir réel.

Page 225

12.6. Modèles, questions et conflits

 Le ruledo or aux autres ce que vous voudriez qu'ils fassent pour youapplies aux gestionnaires. Pas de décret
des dirigeants est déjà suivi ainsi que ceux qu'ils se suivent. Les êtres humains sont sociale
créatures, et nous apprennent comportement tout au long de notre vie, essentiellement des modèles des autres. Nous
souvent apprennent mieux en voyant quelqu'un que nous respectons ou admirer faire quelque chose, et puis essayer, consciemment ou
inconsciemment, d'imiter ce comportement. Comme une question de confiance, il est à chefs de projets
démontrer le comportement qu'ils demandent ou le désir chez les personnes avec qui ils travaillent. Michael Jordan,
Parmi ses autres qualités, développé une réputation pour une éthique de travail intense. Même si il était le
les mieux payés et les plus bien connu joueur de basket-ball de la NBA, il y avait quelques-uns qui ont travaillé aussi dur
comme il le faisait. Cela a éliminé toute possibilité de peu de joueurs demandant de s'asseoir sur la pratique, ou à dépenser
moins de temps dans le gymnase. Le chef a établi un modèle que d'autres devraient suivre.

éthique de travail de côté, la règle d'or pour les dirigeants est qu'ils font confiance à leur propre jugement suffit de suivre
les mêmes règles que tout le monde (voir « Ayez confiance en vous (l'autonomie) ", plus loin dans ce chapitre). Faire
cela signifie permettre à d'autres, les pairs ou subordonnés, de remettre en question le jugement du chef de file ou
comportement. Si quelqu'un a été accordé le pouvoir, il doit y avoir une sorte de boucle de rétroaction pour
contester (à savoir, qui est autorisé à dire que le roi est nu?). Les bons leaders font confiance à leur
les coéquipiers de suffisamment occasion de toon, peut-être dans privateask de la rétroaction sur leur comportement et
la performance. Bien sûr, il n'y a pas d'obligation pour le leader de prendre des mesures sur les évaluations ou même
de commenter, mais il est difficile d'imaginer le succès survient si il ya pas de chemin sain et sécuritaire pour
ce genre d'information pour atteindre le gestionnaire de projet.

12.6.1. Les dirigeants définissent leur processus de rétroaction

Je l'ai trouvé que les gens sont généralement très réticents à donner une rétroaction aux figures d'autorité. Comme un
gestionnaire, je pris l'habitude de demander aux gens qui m'a rapporté, lors des réunions hebdomadaires en tête-à-un,
si elles avaient tout ce qu'ils voulaient que je pense, en ce qui concerne mon travail, mon comportement, ou de mon
la performance. Il était rare qu'ils disaient quelque chose, même si je savais que ce ne fut pas parce que je suis un
parfait gestionnaire (il n'y a pas parfaits gestionnaires). Je trouve la seule solution était la confiance et le temps. JE
devait être persistant dans la création de la confiance dont ils auraient besoin pour se sentir à l'aise de critiquer mon
behaviorwithout les inquiéter pour moi être sur la défensive ou réprimander pour leur
commentaires.

Mais une fois que je l'avais mis en place une boucle de rétroaction avec eux, je appris que leur point de vue était beaucoup
plus utile vers moi devenir un meilleur gestionnaire que les commentaires que je recevais de mon propre patron.
Je ne doute pas eu ce genre de relation avec tout le monde, mais la plupart des gens, tôt ou tard,
répondu à ma question avec quelque chose d'utile. Une suggestion pour l'exécution d'une réunion différente, une
question sur une décision que je l'avais fait, ou de tout autre commentaire garanti que la discussion qui a suivi
nous a aidés à la fois à se sentir mieux à propos de ce que la chose était.

Chaque fois que je suis dans une discussion, et fait ou reçu des suggestions, je tente d'exposer la différence
entre critiquer une idée et critiquer la personne qui est venu avec l'idée. Juste parce que
Une personne est d'accord ou en désaccord avec quelque chose de la personne B dit ne signifie pas la personne la personne A est de juger
B. Je voulais l'équipe de sentir qu'ils respectés et assez confiance les uns les autres de dire ce qu'ils
pensé et ouvertement en désaccord sans excuses, mais aussi sans malice ou sarcastiques inutiles
commentaire. Un sens de l'humour aide considérablement à rendre cela possible, et il commence souvent par
le leader manifestent lorsque le sarcasme ou la moquerie sont appropriées, peut-être par lui-même en utilisant comme
la cible des blagues. Mais mon point principal est que le chef doit démontrer le comportement
lui-même, freiner les gens qui vont trop loin, et tendre la main à ceux qui luttent pour y participer.

Cela étend tout le chemin à des conflits et des désaccords. Tout ce que l'autorité accordée et gagné
ne contribue pas à n'importe qui si elle se trouve juste tranquillement sur son cul pendant que de mauvaises choses se produisent. Il ya peu
de meilleures utilisations d'influence et de pouvoir que d'interrompre arguments stupides et à prendre la parole loin

Page 226

des gens qui en abusent. Lorsque des divergences d'opinion se glissent dans des attaques ad hominem, ou l'utilisation de
faux arguments pour justifier des décisions, quelqu'un a d'interrompre et de relever la barre. En ne tolérant
ce comportement, en particulier dans un contexte de groupe, tout le monde reçoit le même message au même moment:
ne pas essayer ce genre de flic-out à nouveau parce que nous ne l'acceptons pas ici.

Bien sûr, il suit à travers la règle d'or que le vrai leader doit se préparer pour la
possibilité (ou peut-être inévitable) que les autres vont contester ses propres arguments fallacieux, si elle
devrait essayer de les utiliser. Les meilleurs leaders sont ceux qui prennent plaisir à l'équipe d'être si
commis à ses normes intellectuelles qu'il n'a pas peur de remettre en question le comportement de même le chef.
Page 227

12.7. erreurs de fiducie et de faire

Il est facile de faire confiance aux gens quand ils réussissent; la gestion des erreurs de la population est beaucoup plus compliqué.
Ceci est où les gestionnaires gagnent leur salaire.

Je sais de ma propre expérience, que chaque fois que quelqu'un est présenté à la porte de mon bureau avec un
problème qu'il a causé, je vais essayer (mais pas toujours réussir) de maintenir trois pensées:

1. Je suis content qu'il vient me parler. Je préfère qu'il vienne à moi au lieu de le cacher ou de tenter de résoudre
sur son propre et de le rendre pire. Je devrais lui faire savoir tout de suite.

2. Comment puis-je aider à résoudre ce que ce problème est? Est-il même être fixé? Quelles sont les options? Comment
impliquer devrais-je être? Je devrais lui donner autant de conseils dont il a besoin, mais, si possible, demandez-lui
réaliser ce qui doit être fait. Cependant, je dois veiller à ce qu'il est pas en dessus de sa tête.
Le renvoyer dans le feu avec une certitude de 99% de décès est pas exactement une bonne gestion
pratique.

3. Je dois vous assurer que si il ya une leçon à tirer ici, il va apprendre. (2) Les erreurs sont où réel
l'apprentissage qui se passe parce que le fabricant de erreur a un investissement personnel et émotionnel dans ce
passé, et il aura une motivation extraordinaire à ne pas répéter (surtout si il estime que
l'équipe a confiance en lui).

Si vous demandez à des sages maîtres de toute discipline pour leurs grandes leçons, ils vont raconter des histoires sur la façon dont
ils vissés quelque chose, probablement une chose importante, et enfin appris une meilleure façon d'aller
de faire quoi que ce fût. Il en résulte que, pour devenir grand, vous devez non seulement de faire des erreurs
maintenant et puis, mais vous avez besoin de quelqu'un pour vous donner l'occasion de le faire. Les gestionnaires gagnent leur salaire
quand ils gérer les problèmes, car non seulement ils doivent aider à la récupération, mais parce qu'ils
ont aussi pour diriger le processus de conversion de l'erreur dans une leçon pour l'équipe à apprendre.

Une bonne gestion et le leadership sont de donner aux gens autant responsabilité et l'autorité que
leurs capacités et le niveau d'expérience permettent, mais de toute façon ne laissant jamais sentir qu'ils travaillent
 seul, ou qu'ils ont votre soutien que lorsque les choses vont bien. Il est logique que le
le potentiel de faire des erreurs est le même potentiel exact nécessaire de contribuer et de réussir. Ce
signifie qu'il est injuste de cerner les gens à la paroi pour les erreurs de jugement ou des problèmes qui en découlent
les décisions qu'ils ont fait.

Au lieu de cela, l'environnement idéal pour créer en est une où les gens sont à l'aise d'être ambitieux, mais
va admettre et à prendre la responsabilité de leurs erreurs. Ils doivent se sentir assez confiance à vouloir
apprendre autant que possible de sorte qu'il ne se reproduise pas. Si l'équipe partage collectivement cette culture,
il devient auto-correction. Quand il ya un système sain pour reconnaître, répondre à, et
apprendre de ses erreurs, au fil du temps moins d'entre eux ont tendance à se produire (ou quand ils le font, ils sont traités
avec rapidement), et les gens sont plus confiants de prendre toutes sortes de mesures dans la majorité des nonmistake
leur temps.

12.7.1. Ne jamais réprimander en temps réel

La pire chose dans le monde, en particulier en période de crise, est un gestionnaire ou un chef de réprimander
quelqu'un alors que la question est encore en suspens. Il ne résout rien, et il minimise fortement probable
que le problème va se résoudre rapidement, car la personne qui sait le plus sur la question
(L'accusé) est fait pour se sentir coupable et défensive. Imaginez que quelqu'un qui a travaillé avec vous couru
dans votre cris de bureau, "Mon bureau est en feu! Mon bureau est en feu!", et tout ce que vous pourriez offrir était,
"Gee, qui était stupide. Pourquoi avez-vous fait cela? Je suis donc très déçu en vous." Les gens font le rough
équivalent de cela tout le temps, et il est difficile de ne pas demander d'où cela vient. Je suppose que certains

Page 228

les gens croient, probablement en raison de l'osmose de mauvais gestionnaires ou les parents, que la façon de commencer à fixer
questions est en pointant les doigts et la distribution de blâme. Bien sûr, les gens se sentent mauvais et
établir qui devrait se sentir le pire ne fait rien pour améliorer la situation (savoir qui a commencé
le feu ne permet pas souvent mis dehors). Au lieu de cela, il est le temps après le problème a été résolu, lorsque
têtes sont fraîches et la pression est éteint, qu'il ya toutes les chances de revenir et de comprendre
ce qui est arrivé et pourquoi, et quelles sont les leçons qui en découlent pour l'individu, le leader, et la
équipe.
Page 229

12.8. La confiance en vous-même (auto-suffisance)

"Pour toi-même être vrai, et il doit suivre, comme la nuit le jour, tu ne peux
alors faux de tout homme ".

Shakespeare, Hamlet

Le dernier point à propos de la relation entre le leadership et la confiance est pour vous d'apprendre à faire confiance à
vous-même. Ceci est un sujet philosophique profonde bien au-delà de la portée de ce livre. Cependant, je dois
assez de confiance à la fois de nous que nous pouvons couvrir un terrain important dans cette courte section.

Si vous regardez les programmes d'études du secondaire et du collégial aux États-Unis, il ya une classe que vous
ne trouvera pas: comment comprendre qui vous êtes. Cela est très étrange. Pour une nation qui met primaire
importance sur l'individualité et de la liberté, les États-Unis ne fait pas beaucoup pour enseigner ses citoyens à propos de
la découverte de soi, beaucoup moins l'autosuffisance. La découverte de soi est le processus d'apprentissage qui vous êtes
comme un individu, indépendamment de vos amis, votre famille, l'employeur, ou d'une nation. L'autonomie est la
capacité d'appliquer votre individualité au monde, basé sur un cadre de émotionnel, physique, et
un soutien financier pour vous-même. Il ne signifie pas que vous avez à vivre nu dans les bois, vivant hors du
terres. Mais cela ne signifie pas que vous pouvez regarder à l'intérieur vous-même et trouver la force de faire des choix vous
croient, même si les autres ne sont pas d'accord avec ces choix.

"Croyez rien, peu importe où vous le lire, ou qui l'a dit, pas même si je dois
dit, à moins qu'il est d'accord avec votre raison et votre bon sens. "

Bouddha

Leadership, dans le sens traditionnel, exige que les individus ont un certain sens de l'autonomie. Tu
peut prendre un risque ou faire un choix difficile que si vous avez une boussole intérieure vous guider vers ce que
vous pensez est juste. Sans autonomie, l'ensemble de vos décisions seront basées largement sur les opinions des
d'autres, ou de votre désir de leur plaire, sans aucune force de centrage pour guider ces influences. Tom
Peters, John P. Kotter, et d'autres auteurs appellent cette force centrage d'un système de valeurs. Ils suggèrent que
un ensemble de valeurs peut agir comme votre coeur, ou le noyau d'une organisation, vous guidant à travers difficile
situations. Cette approche peut fonctionner, mais je suggère quelque chose de plus profond et plus personnel.

Autosuffisance commence par faire confiance possible de votre propre opinionsit pour vous de croire que quelque chose est vrai,
même si les autres ne le font pas. Opinion différente devrait nier que la vôtre si vous le jugez et, dans la pensée
à travers elle sur vos propres, changer votre esprit. Sinon, il n'y a aucune raison de donner votre opinion sur
un sujet (vous pourrait encore céder sur une décision, donnant votre autorité à la leur, mais cela ne
vous besoin de perdre votre propre opinion). Vos croyances devraient être auto-suffisante. Si vous deviez changer
votre esprit seulement parce que d'autres personnes pensent différemment que vous, vous seriez en train de commettre un acte contre
se faire confiance. Trahir la confiance en vous-même peut être tout aussi dangereux que de trahir la confiance dans votre
équipe.

Pour les courageux, l'autonomie va plus loin. Non seulement avez-vous confiance à votre propre avis, vous faites confiance à votre
assez de coeur pour permettre à vos opinions changent, et même d'admettre vos erreurs. Sans changement
et la lutte occasionnelle, on ne peut pas apprendre ou grandir. Mais si vous faites confiance à vous-même, vous reconnaissez que
vous êtes toujours vous, même quand vous échouez ou se développer dans de nouvelles idées. Emerson a écrit: «Une cohérence imbécile
est le spectre des petits esprits. "Il voulait dire que gardant les mêmes idées juste pour le plaisir de garder
ces mêmes idées avaient aucun sens. Une personne sage doit apprendre plus tout le temps, qui sera
exiger de lui de développer de nouvelles idées et des opinions, même si elles contredisent celles qu'il avait dans le passé. Si
vous menez une vie intellectuelle et émotionnelle actif, vos idées vont grandir avec vous.

Cela signifie qu'une personne autonome peut être confiant en elle-même, tout en trouvant des façons de permettre aux autres de
influencer elle et aider à définir sa vision de l'avenir, ce qui permet toutes sortes de changements positifs. Tu es
libre de faire des erreurs, les admettre, et de changer votre esprit, sans violer votre propre identité.

Donc, si vous pouvez apprendre à vous faire confiance dans ces moyens, vous, en tant que sous-produit de votre rôle de leadership,
aider les autres à apprendre à se faire confiance. Aucun acte de délégation dans les mondes de projets ou humaine

Page 230

la psychologie est plus puissant que d'aider les gens croient en leur propre capacité à devenir plus auto-
dépendante.
 Je recommande l'essai «Self-Reliance» par Ralph Waldo Emerson. Il est disponible dans la plupart des éditions de
ses œuvres, ou il peut être consultée en ligne à http://www.emersoncentral.com/selfreliance.htm .
Le meilleur livre général sur la découverte de soi est à couper du bois, transporter l'eau par Rick Fields (Jeremy P.
Tarcher, 1984). Pour la philosophiquement aventureux, essayez la lecture d'Albert Camus Le Mythe de Sisyphe
(Vintage, 1991).

"Il est seulement comme un homme met hors tout soutien étranger, et est le seul, que je le vois être
fort et de l'emporter ... Celui qui sait que le pouvoir est inné, qu'il est faible en raison
il a regardé [que] pour le bien de lui et ailleurs, et ainsi de percevoir, de lancers
lui-même, sans hésiter sur sa pensée, instantanément droits lui-même, se trouve dans l'érection
la position, ordonne à ses membres, des miracles; tout comme un homme qui se tient sur ses pieds est
plus fort qu'un homme qui se tient sur sa tête ".

Ralph Waldo Emerson, à partir de "Self-Reliance»

Page 231

12.9. Résumé

La confiance se construit à travers des engagements efficaces.

La confiance est perdue par un comportement incohérent sur des questions d'importance.

Utilisez l'octroi d'autorité et de confiance pour permettre aux gens de faire un excellent travail.

Pouvoir accordé provient de la hiérarchie organisationnelle. Puissance gagné ne vient que de

Les réponses à vos actions des gens. Puissance gagné est plus utile que le pouvoir accordé, bien que
les deux sont nécessaires.

Utiliser la délégation de construire la confiance de votre équipe et de veiller à votre équipe contre l'adversité.
 Répondre aux problèmes d'une manière qui permettra de maintenir la confiance des gens. Soutenez-les pendant les crises de sorte
qu'ils apportent questions à vous au lieu de les cacher.

Ayez confiance en vous est le cœur du leadership. La découverte de soi est la façon d'apprendre qui vous êtes et à
développer l'autonomie saine.

Page 232

Chapitre treize. Comment rendre les choses

arriver
 Un mythe de la gestion de projet est que certaines personnes ont une capacité innée à faire le bien, et
d'autres ne le font pas. Chaque fois que ce mythe est venu dans la conversation avec d'autres gestionnaires de projet, je toujours
a demandé une explication de ce abilityhow de le reconnaître, classer, et, si possible, développer
dans d'autres. Après discussion et le débat, la seule chose que nous avons l'habitude identifiedafter l'examen des nombreux
les autres sujets et compétences visées dans le présent bookis la capacité de faire bouger les choses. Certains
les gens sont capables d'appliquer leurs compétences et leurs talents dans toutes les combinaisons nécessaires pour faire avancer les projets
avant, et d'autres ne peuvent pas, même si elles ont les mêmes ou supérieures compétences individuelles. La capacité à
faire bouger les choses est une combinaison de savoir comment être un catalyseur ou un pilote dans une variété de
des situations différentes, et avoir le courage de le faire.

Cette aptitude à conduire est si important pour certains qu'il est utilisé comme un test décisif dans l'embauche de gestionnaires de projet.
Même si les MP ne peut pas définir précisément ce que la capacité est sans faire au moins quelques références à
d'autres compétences, ils ne se sentent qu'ils peuvent sentir ou mesurer dans d'autres. Par exemple, un intervieweur
a besoin de se poser la question suivante au sujet du candidat: «Si les choses ne vont pas bien sur
une partie importante du projet, je me sentirais confiants envoyer cette personne dans cette salle, en
cette discussion ou de débat, et croient qu'il allait aider à trouver un moyen de faire mieux, quel que soit le problème
était? "Si, après une série d'entretiens, la réponse est non, le candidat est renvoyé à la maison. (1) La croyance est
que si il est pas suffisamment souple ou souple pour adapter ses compétences et connaissances pour les situations à portée de main,
et trouver des moyens de faire avancer les choses, alors il ne sera pas survivre, et encore moins prospérer, sur un projet typique.
Ce chapitre traite de cette capacité et les compétences et tactiques impliqués.

Page 233

13.1. Priorités faire bouger les choses

Un grand pourcentage de mon temps en tant que PM a été passé à faire des listes ordonnées. Une liste ordonnée est juste un
colonne de choses, mis en ordre d'importance. Je suis convaincu que, malgré toutes les connaissances et
compétences que je devait avoir et d'utiliser, au total, tout ce que je voulais vraiment faire était listes ordonnées. Je collectionnais
choses qui devaient être donerequirements, fonctionnalités, les bugs, whateverand les mettre dans un ordre de
importance pour le projet. Je passais des heures et des jours de raffinage et de la révision de ces listes, l'intégration des nouvelles
idées et d'informations, de débattre et d'en discuter avec les autres, toujours faire en sorte qu'ils étaient
solide comme le roc. Puis, une fois que nous avons eu cette liste en place, je serais conduire et diriger l'équipe aussi dur que possible pour
suivez les choses dans l'ordre défini. Parfois, ces listes impliqués comment mon propre temps devrait être consacré
un jour donné; d'autres fois, les listes impliqués ce totalité des équipes de personnes ferait sur plusieurs semaines ou
mois. Mais le processus et l'effet sont les mêmes.

Je ai investi beaucoup de temps dans ces listes parce que je savais que d'avoir des priorités claires était l'épine dorsale
du progrès. Faire bouger les choses dépend avoir une idée claire de ce qui les choses sont plus
importants que d'autres et en appliquant ce sens à toutes les interactions qui se déroule sur le
équipe. Ces priorités doivent être reflétées dans chaque e-mail que vous envoyez, question que vous posez, et réunion
tu tiens. Chaque programmeur et testeur devraient investir de l'énergie dans les choses qui vont très probablement apporter
sur le succès. Quelqu'un doit être consacré à la fois à comprendre ce que sont ces choses et la conduite
l'équipe à les atteindre.

Que ralentit les progrès et les déchets le plus de temps sur des projets est la confusion à propos de ce que les objectifs sont ou
dont les choses devraient venir avant que d'autres choses. Beaucoup de malentendus et faux pas se produisent
parce que la personne A supposer priorité (le rendre plus rapide), et la personne B suppose une autre (faire
plus stable). Cela est vrai pour les programmeurs, testeurs, spécialistes du marketing et des équipes entières de personnes. Si ceux-ci
les conflits peuvent être évités, plus de temps peut être dépensé réellement progresser vers les objectifs du projet.

Cela ne veut pas dire ces débats sur les priorités ne devrait pas happenthey devrait. Mais ils devraient arriver
début dans le cadre de tout processus de planification que vous utilisez. Si les mêmes arguments gardent resurfaçage
au cours du développement, il signifie que les gens ne sont pas effectivement convaincu de la décision, ou ils ont
oublié la logique et le besoin d'être rappelé pourquoi ces décisions ont été prises. Divertir débats,
mais commencer par se demander si quelque chose a changé depuis les plans ont été faits pour justifier de réexaminer la
priorités. Si rien n'a changé (comportement des concurrents, la nouvelle mission du groupe, plus / moins de ressources,
nouveaux problèmes majeurs), bâton à la décision.

Si il est une liste ordonnée posté sur le mur de clarifier pour tout le monde que les choses ont été
accepté d'être plus important que d'autres choses qui, ces arguments finissent rapidement ou même jamais
Démarrer. Les listes ordonnées offrent à tous un cadre commun de la logique d'hériter de leurs décisions
de. Si les objectifs sont clairs et compris, il est moins nécessaire pour l'interprétation et moins de chances
pour les efforts gaspillés.

Donc, si jamais les choses sur l'équipe allaient pas bien et les gens avaient du mal à se concentrer sur le
choses importantes, je savais qu'il était de ma faute: soit je ne l'avais pas commandé les choses correctement, avaient pas efficacement
communiqué ces priorités, ou avait omis de signer et de remettre de l'ordre que nous avions. Dans
un tel cas, qui travaillent avec des priorités et listes ordonnées voulait tout dire.
 13.1.1. Listes ordonnées communes

En travaillant toujours avec un ordre de série de priorités, des ajustements et des changements sont faciles à faire. Si, par
miracle, plus de temps ou de ressources se trouvent dans le calendrier, il est clair que la prochaine plus
point important est de travailler sur. De la même façon, si le calendrier doit être coupé, tout le monde sait
ce que le prochain point important est moins et peut cesser de travailler sur elle. Ceci est extrêmement important
car il garantit que, peu importe ce qui arrive, vous avez fait le travail le plus important
possible et peut faire des ajustements rapides sans trop d'effort ou le moral négatif. En outre, toute
erreurs de priorités que vous faites seront relative: si l'article 10 de travail se révèle avoir été plus

Page 234

important que l'élément de travail 9, grosse affaire. Parce que toute la liste était en ordre, vous aurez pas fait une
horrible erreur. Et d'ailleurs, en ayant ces priorités claires et garder l'équipe concentrée sur
eux, vous pouvez très bien avoir acheté le temps nécessaire pour obtenir un objet de travail 10 fait après tout.

Pour la plupart des projets, les trois listes ordonnées les plus importants et les plus formels sont utilisés pour établir des priorités
les objectifs du projet, les caractéristiques et les éléments de travail (voir Figure 13-1 ). Les objectifs du projet sont généralement partie de la
document de vision (voir chapitre 4 ) ou sont dérivées. Les listes des caractéristiques et éléments de travail sont la
sortie du processus de conception (voir les chapitres 5 , 6 et 7 ). Parce que chacune de ces listes hérite priorités
à partir de la liste précédente, en accélérant un niveau pour atteindre un point de clarté puis réappliquer ceux
priorités redescendre au niveau en question, les différends peuvent commencer à être résolu. Bien que ce
ne peut pas toujours résoudre des débats, il fera en sorte que chaque décision a été prise dans le contexte de
ce qui est vraiment important.

Figure 13-1. Les trois plus importantes listes ordonnées, présentés dans l'ordre.

Autres choses importantes qui pourraient avoir besoin de listes ordonnées comprennent bogues, suggestions des clients, des employés
les primes et les budgets de l'équipe. Ils peuvent tous être gérés d'une manière similaire: mettre les choses dans l'ordre le plus
susceptibles de rendre le projet ou l'organisation réussie. Peu importe la complexité des outils que vous utilisez sont
(Par exemple, pour le suivi de bug), ne jamais oublier que tout ce que vous faites est ordonnant les choses. Si les outils ou de processus
vous utilisez ne vous aident pas à mettre les choses en ordre et effectuer cet ordre, à trouver un outil ou un processus différent.
Bug triage, par exemple, où les gens obtiennent dans une pièce et décident quand un bogue devrait être fixé (si
tous), est vraiment juste un processus de groupe pour faire une liste ordonnée de bugs. Les bogues peuvent être classés par
groupe plutôt que sur une base individuelle bug par bug, mais le but et l'effet sont les mêmes.

Si vous utilisez les trois listes ordonnées plus courantes, assurez-vous qu'ils sont toujours mappés à l'autre.
Chaque élément de travail d'ingénierie devrait cartographier une caractéristique, et chaque fonction doit correspondre à un objectif. Si un
nouvel élément de travail est ajouté, il doit être comparé avec des caractéristiques et des objectifs. Ceci est une fonction de forçage
empêcher caractéristiques aléatoires. Si un vice-président ou le programmeur veut glisser quelque chose de supplémentaire dans, elle devrait être
contraints de justifier contre ce projet cherche à atteindre: «Voilà une grande fonctionnalité, patron, mais
dont le but sera, il nous aider à satisfaire? Soit nous devrions ajuster les objectifs et faire face aux conséquences,
ou que nous ne devrions pas investir d'énergie ici. "Si vous enseignez l'équipe qu'il est une règle de garder ces trois
les niveaux de prise de décision dans la synchro, vous allez vous concentrer l'équipe et les empêcher de perdre du temps.

13.1.2. Priorité 1 contre tout le reste

Typiquement, ces listes ordonnées ont une ligne importante en les divisant en deux morceaux. La partie supérieure est
Priorité 1: les choses que nous devons faire et ne pouvons pas réussir sans éventuellement. La deuxième partie est tout
autre. Priorités 2 et 3 existent, mais sont compris tout à fait différentes sortes de choses de priorité
1. Il est très difficile de promouvoir la priorité 2 articles en priorité 1.

Cette ligne de priorité 1 doit être prise très au sérieux. Vous devez battre dur pour rendre cette liste que les petites et
serrée que possible (cela vaut pour toutes les listes de but dans le document de vision ainsi). Un article dans la priorité
1 liste signifie «Nous mourrons sans cela." Cela ne signifie pas que les choses sont bien d'avoir ou que nous

Page 235
 voulez vraiment avoir: il donne le plus serré, plus maigres façon de répondre aux objectifs du projet. Par exemple, si nous
ont été la construction d'une automobile, la seule priorité 1 les choses seraient le moteur, les pneus, la transmission,
freins, du volant et des pédales,. Priorité 2 articles seraient les portes, le pare-brise, l'air conditionné,
et la radio parce que vous pouvez contourner sans ces choses. La fonctionnalité de base de l'automobile
existe sans eux; vous pouvez expédier et encore appeler une voiture.

Mettre en place cette ligne était toujours très difficile; il y avait beaucoup d'argumenter et débattre à propos
et dans lesquelles les clients pouvaient vivre sans ou dont les choses ont été plus importants que d'autres. Ce
était bien. Nous voulions tout le débat et arguant avoir lieu au début, mais ensuite passer. Comme
douloureux que cela serait, quand nous avons terminé, nous aurions une liste qui avait survécu aux opinions et
perspectives de l'équipe. Nous pourrions alors aller de l'avant et d'exécuter, ayant réfutations et soutenir
arguments pour la liste que nous avions fait. Après avoir aiguisé à travers débats et de discussions, nous étions
prêts à 90% des questions communes ou des défis les gens peuvent avoir plus tard (par exemple, pourquoi nous étions
freins de construction mais pas la climatisation) et pourrait rapidement Dispatch eux: Nous avions entendu les arguments
avant, et nous savions pourquoi ils ne tiennent pas.

Le défi de la hiérarchisation est toujours plus émotionnelle / psychologique que intellectuelle, malgré ce que
les gens disent. Tout comme un régime pour perdre du poids ou la budgétisation à économiser de l'argent, éliminant choses que vous voulez
(Mais ne pas besoin) nécessite d'être discipliné, commis, et axée sur les objectifs importants. Dire
"La stabilité est importante" est une chose, mais pile rang contre d'autres choses importantes est entièrement
différent. Beaucoup de gestionnaires de poulet de ce processus. Ils couvrent, retard, et nient la dure
choix, et le résultat est qu'ils ont mis leurs projets à l'échec. Aucun des choix difficiles signifie aucun progrès.
Dans l'abstrait, le mot important de ne signifie rien. Donc, listes ordonnées et la déclaration d'un haut
priorité 1 forces de bar dirigeants et toute l'équipe de prendre des décisions difficiles et penser clairement.

La clarté est la façon dont vous faites les choses se passent sur des projets. Tout le monde se présente au travail chaque jour avec un
fort sentiment de ce qu'il fait, pourquoi il le fait, et comment il se rapporte à ce que les autres font.
Lorsque l'équipe pose des questions sur la raison pour laquelle une chose est plus important qu'un autre, il est clair
et des raisons logiques pour elle. Même quand les choses changent et les priorités sont ajustés, tout est dans le
même système fondamental de listes ordonnées et des appellations prioritaires.

13.1.3. Les priorités sont la puissance

Avez-vous déjà été dans un argument difficile que vous pensiez ne finirait jamais? Peut-être la moitié de la
ingénieurs croient fermement A, et l'autre moitié croient fermement pour B. Mais alors, le chef d'équipe intelligente
promenades dans, pose quelques questions, divise la discussion d'une nouvelle manière, et obtient rapidement tout le monde
accepter. Il est arrivé à moi plusieurs fois. Quand je étais plus jeune, je attribuions ce jusqu'à la brillance:
en quelque sorte que le gestionnaire ou le plomb programmeur était tout simplement plus intelligents que le reste des gens dans le
chambre, et a vu des choses que nous ne. Mais comme je l'ai payé plus d'attention, et même parfois leur a demandé
ensuite comment ils ont fait, je me rendis compte qu'il était d'avoir des priorités solide comme le roc. Ils avaient commandé une
énumérer dans leurs têtes et ont été en mesure d'obtenir d'autres personnes pour encadrer la discussion autour d'elle. Bien
les priorités sont l'énergie. Ils éliminent variables secondaires à partir de la discussion, ce qui permet de
concentrer et de résoudre les problèmes.

Si vous avez des priorités en place, vous pouvez toujours poser des questions à toute discussion que recadrer le
argumentation autour d'une considération primordiale plus utile. Cela permet d'actualiser le sens de ce que tout le monde
le succès est, divisant visiblement l'univers en deux piles: choses qui sont importantes et les choses qui sont
agréable, mais pas importante. Voici quelques exemples de questions:

Quel problème essayons-nous de résoudre?

Si il ya plusieurs problèmes, dont l'un est le plus important?

Comment ce problème se rapportent ou impact de nos objectifs?

Quelle est la façon la plus simple de résoudre ce qui nous permettra d'atteindre nos objectifs?

Si rien d'autre, vous pourrez réinitialiser la conversation se concentrer sur les objectifs du projet, dont tout le monde
peut d'accord avec. Si un débat a continué pendant des heures, de trouver un terrain d'entente est votre meilleur
occasion de faire avancer la discussion vers une conclusion positive.

Page 236

13.1.4. Être une machine de priorisation

Chaque fois que je parlais avec des programmeurs ou des testeurs et entendu parler de leurs problèmes ou les défis, je
rendu compte que ma valeur primaire était pour les aider à se concentrer. Mon but était d'éliminer secondaire ou
choses tertiaires de leurs plaques et de les aider à voir un ordre clair du travail. Il y a des moyens à 1000
mettre en œuvre une page Web système de conception ou de base de données particulière aux spécifications, mais seulement une poignée d'entre eux
vraiment clouer les objectifs. Sachant cela, je encouragé les programmeurs me chercher si jamais ils sont confrontés
une décision où ils ne sont pas sûr de l'investissement de temps pour faire autre.

Mais au lieu de les microgestion («Faites ceci. Pas le faire. Non, faire de cette façon. Avez-vous terminé encore? Comment
Et maintenant? "), je viens de faire comprendre que je suis là pour les aider à établir des priorités quand ils
eu besoin. Parce qu'ils ne disposent pas du point de vue de l'échelle du projet que je faisais, ma valeur était en aidant
eux de voir, même si juste pour un moment, comment ce qu'ils faisaient ajustement dans l'ensemble du projet. Quand
 Ils avaient
la clarté depassé
niveautoute la journée
supérieur, du débogage
le réconfort d'un module
et la confiance ouce
dans l'exécution de testsIl unitaires,
qu'ils faisaient. a souventils étaient
pris souvent
seulement 30 soulagé d'obtenir des
deuxième conversation pour nous assurer que nous étions encore tous sur la même page.

Chaque fois que de nouvelles informations est venu à ce projet, il était de mon devoir de l'interpréter (seul ou à travers
discussion avec d'autres), et en former une liste prioritaire des choses que nous avions à se soucier et les choses
nous ne l'avons pas. Souvent, je dois réviser la liste précédente, en l'ajustant pour répondre à la nouvelle information. UN
VP pourrait changer son esprit. Une étude d'utilisabilité pourrait trouver de nouvelles questions. Un concurrent peut faire une
changement inattendu. Ces priorisations vivaient, la respiration, les choses et les modifications à notre
direction ou objectifs se reflètent directement et immédiatement en eux.

Parce que je soutenais les priorités, je permis à l'équipe de rester concentré sur les choses importantes et
fait faire des progrès sur eux. Parfois, je pouvais réutiliser priorités définies par mes supérieurs (vision
documents, déclarations de mission de groupe); d'autres fois, je devais inventer mon propre à partir de zéro dans
réponse à l'ambiguïté ou de situations imprévues. Mais plus que tout, je suis un ordre de priorité
machine. Si jamais il ya une statue en l'honneur de bons gestionnaires de projets, je soupçonne l'inscription
diraient "Apportez-moi vos, vos droiture confus, vos masses sarcastiques et amers randomisés
de programmeurs nostalgie de clarté ».

Page 237

13.2. Les choses arrivent quand vous dites pas

Un effet secondaire d'avoir des priorités est combien de fois vous avez à dire non. Il est un des plus petits mots
la langue anglaise, mais beaucoup de gens ont du mal à le dire. Le problème est que si vous ne pouvez pas dire
Non, vous ne pouvez pas avoir des priorités. L'univers est une grande place, mais votre liste de priorité 1 doit être très
petite. Par conséquent, la plupart de ce que les gens dans le monde (ou de votre équipe) pourraient penser sont de grandes idées
finira par ne correspondant pas aux objectifs du projet. Cela ne signifie pas que leurs idées sont mauvaises; cela signifie juste
leurs idées ne seront pas contribuer à ce projet particulier. Ainsi, une loi fondamentale de l'univers PM est
ceci:. Si vous ne pouvez pas dire non, vous ne pouvez pas gérer un projet (2)

Dire NON commence au sommet d'une organisation. Les personnes les plus hauts sur un projet détermineront
si les gens peuvent réellement dire non aux demandes. Peu importe ce que disent les priorités, si le plomb
développeur ou gestionnaire dit continuellement oui à des choses qui ne jive avec les priorités, d'autres le feront
suivre. Les programmeurs vont travailler sur les fonctionnalités de compagnie. PMS ajouter des exigences (cachés). Même si celles-ci
les choix individuels sont bonnes, parce que l'équipe ne suit plus les mêmes règles, ni de travail
vers les mêmes priorités, les conflits se produiront. Parfois, il sera désaccords entre
programmeurs, mais les plans définitifs le plus souvent, le résultat sera disjoint. Stabilité, les performances et
convivialité seront tous souffrir. Sans la mise au point des priorités, il est difficile d'obtenir une équipe pour coordonner sur
faire la même chose. Les meilleurs dirigeants et les gestionnaires de l'équipe savent qu'ils ont à montrer la voie
à dire non aux choses qui sont hors de portée, plaçant la barre pour toute l'équipe.

Quand vous faites dire non, et le faire coller, l'acquis du projet élan. Éliminant les tâches de
Les plaques des gens leur donne plus d'énergie et la motivation à se concentrer et travailler dur sur ce qu'ils doivent
faire. Le nombre de réunions et discussions aléatoires va baisser et l'efficacité va monter. Élan
va construire autour de dire non: d'autres vont commencer à le faire dans leurs propres sphères d'influence. En fait, je l'ai
 membres
ne pas jivedeavec
l'équipe a demandé
nos priorités, denon.
dire faireOu
cela.
leurJedire
dirais,
que"Si jamais
je l'ai vousetvous
dit non, sentez
ils ont qu'on
besoin de vous
parlerdemande
à moi. Etde faire quelque chose que
ne perdez pas votre temps à discuter avec eux si ils les complainpoint mon chemin. "Je ne voulais pas qu'ils
gaspiller leurs priorités en matière de temps à débattre avec les gens parce qu'il était mon expertise, pas le leur. Même si
ils ne sont jamais confrontés à ces situations, je réussis à exprimer la gravité des priorités étaient et comment
veut, je devais travailler pour les défendre.

13.2.1. Maîtriser les nombreuses façons de dire non

Parfois, vous aurez besoin de dire non en réponse directe à une demande de fonctionnalité. D'autres fois, vous aurez besoin
à vous-même intervenir dans une conversation ou une réunion, identifier le conflit avec les priorités que vous avez
entendu, et dire effectivement pas à tout ce qui a été discuté. Pour vous préparer à cela, vous
besoin de connaître toutes les différentes saveurs que le mot ne vient en:

Non, cela ne correspond pas à nos priorités . Si il est trop tôt dans le projet, vous devriez faire l'argument
pourquoi les priorités actuelles sont bonnes, mais entendre les gens sur la raison pour laquelle d'autres priorités pourraient faire
plus de sens. Ils pourraient avoir de bonnes idées ou besoin de clarté sur les objectifs. Mais ne pas forcer la
discussion soit par rapport aux priorités du projet, et non la valeur abstraite d'une fonction ou d'un bogue
fixer demande. Si elle est en retard dans le projet, vous pouvez leur dire qu'ils ont manqué le bateau. Même si le
priorités sucent, ils ne vont pas changer sur la base d'une idée de fonctionnalité. Le plus tard vous êtes,
le plus grave échec de la stratégie doit être pour justifier des ajustements de but.

Non, seulement si nous avons le temps . Si vous gardez vos priorités maigre, il y aura toujours beaucoup de très
bonnes idées qui ne font pas la coupe. Exprimez-ce que la décision relative: l'idée en question
pourrait être bon, mais pas assez bon par rapport à l'autre le travail et les priorités du projet. Si le
article est sur la liste de priorité 2, faire valoir qu'il est possible ce sera fait, mais que personne ne devrait parier
la ferme en supposant que cela se produira.

Non, seulement si vous faites <insérer chose impossible ici> arriver . Parfois, vous pouvez

Page 238

rediriger une demande de retour sur la personne qui l'a fait. Vous si votre VP demande d'ajouter le support pour une
nouvelle fonctionnalité, lui dire que vous pouvez le faire que si il coupe l'un de ses autres demandes prioritaires en cours 1.
Cela déplace le point de discorde loin de vous, et vers une tangible, bien que probablement
inatteignable, la situation. Cela peut également être fait pour les questions politiques ou d'approbation: «Si vous pouvez
Sally convaincre que cela est une bonne idée, je vais y réfléchir. "Cependant, cela peut se retourner. (si il
ne convainc Sally? Ou pire, rend compte que vous êtes l'envoyant sur une chasse aux oies sauvages?)

Non communiqué suivant . En supposant que vous travaillez sur un projet de site web ou un logiciel qui aura
Plus de mises à jour, offrent à reconsidérer la demande pour la prochaine version. Ceci devrait probablement se produire
de toute façon pour tous prioritaires 2 articles. Ceci est souvent appelé report ou en barque.

Non jamais. Déjà. Vraiment . Certaines demandes sont si fondamentalement hors de la ligne avec le long terme
objectifs que le marteau doit descendre. Couper le cordon maintenant et vous épargner le temps de
répondre à nouveau plus tard la même demande. Parfois, il vaut la peine d'expliquer pourquoi (de sorte que
ils seront mieux informés la prochaine fois). Exemple: "Non, Fred Le moteur de recherche du site Web ne sera jamais.
soutenir la langue espéranto. Jamais. Déjà."
Page 239

13.3. Keeping it real

Certaines équipes ont un meilleur sens de la réalité que d'autres. Vous pouvez trouver de nombreuses histoires des équipes de projet
livré leurs mois ou des années pour ce produit fin, ou sont venus en millions de dollars sur le budget (voir
Robert Glass ' Software Runaways , Prentice Hall, 1997). Peu à peu, les équipes croient au mensonge ou minuscules
déformations de la vérité sur ce qui se passe, et de glisser dans dangereuse et improductive
endroits. En règle générale, plus une équipe obtient de la réalité, plus il est difficile de faire de bonnes choses.
Les chefs d'équipe doivent jouer le rôle de garder leur équipe honnête (dans le sens que l'équipe peut perdre
contact avec la réalité, et non pas qu'ils mentent délibérément), rappelant aux gens quand ils font jusqu'à
réponses, en ignorant les situations problématiques, ou en se concentrant sur les mauvaises priorités.

Je me souviens d'une réunion je étais il ya quelques années avec une petite équipe de produit. Ils construisaient quelque chose
qu'ils voulaient mon équipe à utiliser, et la présentation axée sur les nouvelles fonctionnalités et
technologies leur produit aurait. Assis près de l'arrière de la salle, je me sentais de plus en plus
à l'aise avec la présentation. Aucune des questions difficiles a été abordée ou même
mentionné. Puis je me rendis compte que le vrai problème: en ne traitant pas les questions importantes, ils étaient
perdre du temps à tout le monde.

Je regardais autour de la salle et a réalisé une partie du problème: je suis le seul de ma plomb
organisation de la fréquentation. Normalement, je l'aurais prévu un autre PM ou programmeur en chef de demander
Déjà questions difficiles. Mais avec les visages dans la salle, je ne sais pas si quelqu'un d'autre était
vagues de prise de confortables si nécessaire. A mille questions viennent à l'esprit, et je me suis vite
levé la main, déclenchant une série de questions simples, un après l'autre. "Quel est votre programme?
Quand pouvez-vous obtenir le code de travail pour nous? Qui sont vos autres clients, et comment allez-vous la priorité
leurs demandes contre la nôtre? Pourquoi est-il dans notre intérêt de nous rendre dépendant de vous et votre
équipe? "Leurs mâchoires chuté. Ils étaient tout à fait au dépourvu.

Il était clair qu'ils avaient pas tenu compte de ces questions avant. Pire encore, ils ne vous attendez pas à avoir à
y répondre pour les clients potentiels. Je poliment expliqué qu'ils ne sont pas prêts pour cette réunion. JE
excusés si mes attentes étaient pas clairement au moment de la réunion a été organisée (je pensais qu'ils
ont été). Je leur ai dit que sans ces réponses, cette réunion était une perte de temps de tout le monde,
y compris la leur. Je suggère que nous reportions le reste de la réunion jusqu'à ce qu'ils aient des réponses pour ces
questions simples. Ils ont convenu d'un air penaud, et fin de la réunion.

Dans le jargon PM, ce que je faisais dans cette histoire était appeler conneries. Ceci est en référence au jeu de cartes
Bullshit, où vous gagnez si vous débarrasser de toutes les cartes dans votre main. Dans chaque tour de jeu, un
Lecteur Etats qui cartes qu'il joue comme il les place face cachée dans un tas. Il est pas obligé de
dire la vérité. Donc, si à tout moment un autre joueur pense que le premier joueur est couché, elle peut «appeler conneries"
et forcer le premier joueur à montrer ses cartes. Si l'accusateur est droite, le premier joueur prend la totalité de la
cartes de la pile (un revers majeur). Toutefois, si l'accusateur est faux, elle prend la pile.

Appel conneries fait bouger les choses. Si les gens attendent de vous pourrez leur poser des questions difficiles, et non
hésitent à les pousser dur jusqu'à ce que vous obtenez des réponses, ils prépareront pour eux avant qu'ils rencontrent
tu. Ils ne vont pas perdre de temps à vous ou votre équipe. Rappelez-vous que toutes sortes de tromperie, y compris
auto-tromperie, le travail contre les projets. Le plus tôt la vérité vient à la lumière, le plus tôt vous pouvez faire
quelque chose à ce sujet. Parce que la plupart des gens préfèrent éviter les conflits et de faire semblant de choses sont OK (même
lorsqu'il existe une preuve qu'ils ne sont pas), quelqu'un doit pousser à faire connaître la vérité. Le plus vous pouvez
garder la vérité à l'air libre, plus votre équipe peut rester au ras du sol, se déplaçant à grande
vitesse.

Le défi avec d'autres interrogateurs est qu'il peut fonctionner contre la culture d'un individu ou
organisation. Certaines cultures voient interrogatoire comme une insulte ou un manque de confiance. Ils peuvent voir les tentatives de
garder les choses honnêtes comme des attaques personnelles, au lieu d'enquêtes comme de véritables dans la vérité. Tu pourrais avoir besoin de
d'aborder ces situations plus formelle que je l'ai fait dans l'histoire. Faites une liste de questions que vous
attendre que les gens répondent, et fournissent à eux avant les réunions. Ou, créer une liste de questions qui
quiconque dans l'organisation est libre de demander à quelqu'un à tout moment (y compris les vice-présidents et Premiers ministres), et l'afficher sur
le mur dans une salle de conférence. Si vous le faites la connaissance du public dès le premier jour que conneries sera
Page 240

appelé à tout moment, vous pouvez faire une partie de la culture sans insulter personne. Cependant, les dirigeants
ont encore la charge de conneries fait appel de temps à autre, démontrant pour l'équipe qui
coupe rapidement à la vérité peut être fait.

Page 241

13.4. Connaître le chemin critique

Dans la terminologie de la gestion de projet, le chemin critique est la séquence la plus courte de travail qui peut
terminer le projet. Dans l'analyse du chemin critique, un diagramme ou organigramme est faite de tous les éléments de travail,
indiquant les articles qui dépend que d'autres. Si cela est fait correctement, ce diagramme montre où
les goulots d'étranglement seront. Par exemple, si des fonctions A, B, et C ne peut pas être achevé avant D est fait, alors
 D est sur le chemin critique pour cette partie du projet. Ceci est important parce que, si D est retardé ou fait
mal, il aura un impact sérieux la réalisation d'éléments de travail A, B, et C. Il est donc important pour un
chef de projet pour être en mesure de planifier et prioriser le chemin critique. Parfois, relativement
composante peu importante sur son propre peut être la dépendance critique qui empêche véritable priorité 1 travaux
d'être achevé. Sans faire une analyse du chemin critique, vous pourriez ne jamais reconnaître ce jusqu'à ce qu'il soit
trop tard. (3)

Du point de vue de niveau supérieur, il y a un chemin critique à toutes les situations. Ils ne doivent pas être
schématisé ou mesurée au même niveau de détail, mais les processus de pensée dans l'évaluation de nombreux
PM situations sont similaires: regarder le problème comme une série de liens, et de voir où les goulots d'étranglement ou
points critiques sont. Quelles décisions ou actions dépendent que d'autres décisions ou les actions?
Ensuite, envisager si suffisamment d'attention est accordée à eux, ou si la vraie question est pas de celui actuellement
en cours de discussion. Vous accélérez considérablement une équipe en mettant son attention directement sur la
éléments, les facteurs et les décisions qui sont au cœur de progresser.

Toujours avoir un sens pour le chemin critique de:

Le travail d'ingénierie du projet (tel que décrit brièvement plus tôt)

De haut niveau de décision le processus du projet (qui ralentit l'équipe vers le bas?)

Les processus de l'équipe pour le code du bâtiment ou le triage des bogues (y at-il inutile de formes, réunions, ou
les approbations?)

Le processus d'étaiement contenu sur le Web ou intranet production

Toute réunion, une situation ou processus qui les impacts du projet objectifs

Faire bouger les choses efficacement nécessite un fort sentiment de chemins critiques. Chaque fois que vous entrez dans un
manger, lire un email, ou vous impliquer dans une décision, vous devez réfléchir à ce que les chemins critiques
sont. Est-ce vraiment la question centrale? Seront cette discussion ou de la ligne de la pensée résoudre? Concentrez votre énergie
(Ou de la salle de l'énergie) sur le traitement de ces considérations premier et évaluer ce qui doit être
faire pour assurer ces chemins critiques sont plus courtes, ou disposer des ressources suffisantes, pour éviter les retards. Si
vous pouvez clouer le chemin critique, les questions moins critiques seront plus facilement tomber en place.

Pour certaines organisations, le moyen le plus rapide pour améliorer la (non-ingénierie) chemin critique est de
distribuer autorité à l'ensemble de l'équipe. Au lieu d'exiger un consensus, que les individus prennent des décisions
et d'utiliser leur propre jugement quant à quand le consensus est nécessaire. Faites la même chose pour les approbations,
documentation, les formulaires ou autre possible surcharge bureaucratique (voir chapitre 10 ). Souvent, la meilleure façon
d'améliorer les chemins critiques dans les organisations est de supprimer les processus et décaler vers le bas et l'autorité
dans une équipe, au lieu de créer de nouveaux procédés ou des hiérarchies.

Page 242

13.5. Soyez implacable

«Le monde répond à l'action, et rien d'autre."

Scott Adams

Beaucoup de gens intelligents peuvent reconnaître quand il ya un problème, mais peu sont prêts à dépenser de l'énergie
nécessaire de trouver une solution, puis le courage de le faire. Il ya toujours des moyens plus faciles:
renoncer, accepter une solution partielle, remettre à plus tard jusqu'à ce qu'il disparaisse (doigts croisés), ou blâmer les autres.
La façon la plus difficile est de prendre le problème de front et résister à céder à des conclusions qui ne permettent pas
pour la satisfaction des objectifs. Les gestionnaires de projet réussi ne donnent tout simplement pas facilement. Si quelque chose
est importante pour le projet, ils agiront aggressivelyusing tout moyen necessaryto trouver une réponse ou
résoudre le problème. Cela pourrait signifier la réorganisation d'une équipe dysfonctionnelle, de prendre une chambre difficile
les gens se mettent d'accord sur les objectifs, trouver des réponses à des questions, ou régler les différends entre les personnes.

Parfois, cela signifie demander aux gens de faire des choses qui ne leur plaisent pas faire, ou de soulever des questions qu'ils
ne veulent pas répondre. Sans quelqu'un forçant ces choses se produire, le plus simple sur tendra
d'être choisi pour vous. Beaucoup de projets sont constitués de personnes avec des rôles spécialisés qui sont peu susceptibles de prendre
responsabilité pour les choses qui sont au-delà de leur portée limitée (ou qui tombent entre les mailles de leur
rôle et quelqu'un d'autre). Peut-être plus problématique est que la plupart d'entre nous éviter les conflits. Il est souvent le
PM qui doit interroger les gens, contester les hypothèses, et cherchent la vérité, quel que soit le
il pourrait faire mal à l'aise les autres (bien que l'objectif est de le faire d'une manière qui les rend aussi
 confortable que possible). PMs devons être prêts à faire ces choses lorsque cela est nécessaire.
Plusieurs fois, les situations qui semblent d'abord crumble intenable ou intraitable sous le
effort psychologique d'un chef de projet tenace. Une histoire classique de cette attitude est l' Apollo
13 mission. Dans son livre Le non est pas une option (Berkeley Publishing, 2001), Gene Kranz décrit
l'effort qui est entré dans la fixation du système de support de vie sur le vaisseau spatial endommagé. Il était l'un des
plus difficile génie défie l'équipe fait face, et il y avait des doutes graves parmi ceux avec le
plus d'expertise que même une solution partielle a été possible. Kranz a pris la position que non seulement
ils trouvent une façon, ils le feraient dans le temps limité imparti. Il a refusé d'accepter un moyen facile
dehors, et il a poussé son équipe à explorer des alternatives, résoudre leurs différends et de se concentrer leur
énergie. Tous les trois versions de l'histoire, le film Apollo 13 , le livre de Kranz, et perdu Lune (Pocket,
1995) par Jim Lovell (le capitaine de mission) et Jeffrey Kluger, fournissent de récits fascinants de l'un des
la gestion la plus grande du projet et des histoires de résolution de problèmes dans l'histoire.

GP efficaces tiennent tout simplement plus de solutions de rechange avant d'abandonner à d'autres personnes le font. Ils
interroger les hypothèses qui ont été laissés incontestée par d'autres, parce qu'ils sont venus à partir d'un vice-président
les gens avaient peur ou une source d'expertise de qualité supérieure qui ne se sentait la nécessité de contester. La
question: «Comment savez-vous ce que vous savez?" est la façon la plus simple de clarifier ce qui est assumé et
ce qui est réel, mais beaucoup de gens ont peur, ou oublient, pour lui demander. Être implacables croyantes
99% du temps, il existe une solution à ce problème (y compris, dans certains cas, modifier la définition
du problème), et que si elle ne peut pas être trouvé avec les informations à portée de main, puis plus profonde et plus
questions de sondage doivent être posées, peu importe qui doit être contestée. Le succès du projet
doit venir en premier.

Dans mes années dans la division Windows chez Microsoft, je travaillais pour Hillel Cooperman, peut-être le plus
gestionnaire passionnée et dévouée je ai jamais eu. Je me souviens d'une fois à venir dans son bureau avec un
dilemme. Mon équipe a été bloqué sur un problème complexe impliquant à la fois l'ingénierie et politique
problèmes. Nous avions besoin d'une autre organisation de faire un travail important pour nous, qu'ils ne voulaient pas
faire. Je l'avais réfléchi avec des opinions toutes les personnes impliquées, je avait sollicité d'autres personnes de haut niveau,
mais je suis toujours coincé. Il ne semble pas être une solution raisonnable, mais cela a été quelque chose de critique pour
le projet, et je savais que céder serait inacceptable. Après avoir expliqué ma situation, la
la conversation a quelque chose comme ceci: "Que ne vous ai pas essayé encore?" Je fis l'erreur de
répondre, «Je l'ai tout essayé." Il a juste ri de moi. "Tout? Comment pourriez-vous avoir éventuellement
tout essayé? Si vous avez tout essayé, vous auriez trouvé un choix que vous sentez à l'aise,
qui, apparemment, vous ne l'avez pas encore. "Nous avons trouvé ça drôle parce que nous savions tous les deux exactement où la

Page 243

la conversation allait.

Il a ensuite demandé si je voulais quelques suggestions. Bien sûr, je dis oui. Nous repompée pendant quelques minutes, le dos
et-vient, et est venu avec une nouvelle liste de choses à considérer. «Qui ne vous ai pas appelé sur le téléphone?
Email est pas bon pour ce genre de chose. Et de tous les gens de l'autre qui sont en désaccord avec sidethose
youwho est plus réceptifs à vous? Comment les avez-vous dur vendu sur ce que vous voulez? Dois-je obtenir
impliqués et le travail d'en haut? Cela aiderait? Qu'en est-il de notre VP? Comment avez-vous dur
poussé l'ingénierie pour trouver une solution de contournement? Un peu? Beaucoup? Aussi dur que possible? Avez-vous proposer d'acheter
les boissons? Dîner? Avez-vous leur parlez en tête-à-un, ou dans un groupe? Continuez, continuez, continuez
aller. Vous trouverez un moyen. Je vous fais confiance, et je sais que vous allez résoudre ce problème. Continue."

Il a fait deux choses pour moi: il m'a rappelé que non seulement ai-je eu des alternatives, mais aussi qu'il était
toujours mon pouvoir de prendre la décision. Fatigué comme je l'étais, je quittai son bureau, il y avait convaincu plus
chemins à explorer et qu'il était de mon devoir de le faire. Mon propriété de la question, qu'il avait reconfirmé,
aidé à me motiver à être implacable. La solution a été menaçant à l'intérieur l'un d'eux, et je viens d'avoir à
Trouve ça. Comme les dizaines d'autres questions que je gérais en même temps, je finalement trouvé un
solution (il y avait une solution d'ingénierie), mais seulement parce que je chassais pour elle: il a été ne va pas
de venir me trouver.

Parmi les autres leçons, je appris de Hillel que la diligence gagne les batailles. Si vous faites clairement que vous
sont morts grave et se battra jusqu'à la fin sur un sujet particulier, vous forcez plus de possibilités à
survenir. Les gens vont remettre en question leurs hypothèses, si vous tenez à la vôtre assez longtemps. Vous poussez les gens
à considérer les choses qu'ils ne sont pas considérés, et souvent ce est où la réponse se trouve. Même dans
des désaccords ou des négociations, si vous savez que vous avez raison, et continuer à pousser dur, les gens vont souvent
céder. Parfois, ils vont lui donner juste pour vous amener à les laisser seuls. Être arrogant, à condition que vous êtes
pas offensive, peut être une technique efficace à lui tout seul.

Être implacable est fondamentale pour faire bouger les choses. Il ya tellement de façons différentes pour
projets à glisser dans l'échec que si il ya au moins une force émotionnelle derrière le
projectpushing vers l'avant, cherchant des alternatives, croire, il ya toujours un moyen de sortir de chaque
problème et projet de trapthe est peu probable de réussir. Les bons chefs sont que la force. Ils sont obligés de
continuer à avancer, toujours à l'affût de quelque chose qui peut être amélioré dans un rapide ou
de façon plus intelligente. Ils cherchent le chaos et la convertissent en clarté. Aussi sceptique que les gestionnaires de projet doivent
être, ils sont à la fois optimiste que tous les problèmes peuvent être résolus si suffisamment d'intensité et
accent sont appliquées. Pour des raisons qu'eux-mêmes ne peuvent pas expliquer entièrement, PMS détiennent toujours une torche jusqu'à
contre l'ambiguïté et le doute, et de refuser de quitter jusqu'à ce que toutes les alternatives possibles ont été explorées.
Ils croient que la bonne pensée gagne, et qu'il faut travailler pour trouver de bonnes pensées.
Page 244

13.6. Soyez avertis

Mais étant implacable ne signifie pas que vous devez frapper à toutes les portes, chasser les gens dans le couloir,
ou de rester au travail jusqu'à ce que vous vous évanouissez à votre bureau. Quantité considérable d'effort peut être noble et bon, mais
toujours chercher des moyens de travailler intelligemment plutôt que de simplement difficile. Soyez implacable dans l'esprit, mais intelligent et
savvy en action. Juste parce que vous refusez de renoncer ne signifie pas que vous avez à souffrir
activités stupides, stupides, ou frustrantes (bien que parfois ils sont inévitables). Cherchez à puce
des moyens de contourner un problème ou des moyens plus rapides pour les résoudre. Faire un usage efficace des gens autour de vous
au lieu de supposer que vous avez à faire tout vous-même. Mais le plus important, être perspicace
ce qui se passe autour de vous, avec des individus et des équipes.

Une erreur fondamentale de nombreux GP font est d'oublier de déterminer qui ils travaillent avec et ajuster
leur approche en conséquence. Navy Seals et Rangers de l'armée sont formés pour effectuer des missions sur de nombreux
différents types de terrain: déserts, des marais, des jungles, toundra. Sans cette formation, leur efficacité
serait limité: ils avaient du mal à survivre sur un terrain inconnu parce que leurs compétences ne seraient pas travailler
(Imaginez un soldat en tenue de camouflage vert et olive, essayant de se cacher sur un terrain couvert de neige). La première
leçon qu'ils apprennent est de savoir comment évaluer leur environnement et considérer ce que les tactiques et les stratégies de
leurs compétences va travailler pour où ils sont. La même chose est vraie pour le SPM. Au lieu de géographique
environnements, PMS doivent prêter attention à l'autre sociale, politique et organisationnelle
ils sont dans des environnements, et utilisent les bonnes approches pour où ils sont.

Étant avertis et sensible à l'environnement est le plus important dans les situations suivantes:

Motiver et inspirer

L'organisation des équipes et de la planification à l'action

Régler des conflits ou lever les impasses

Négocier avec d'autres organisations ou des cultures

Faire arguments pour les ressources

Persuader quelque chose à quelqu'un

Gestion des rapports (personnel)

Voici indicatif du avertis PM à l'évaluation d'un environnement. Ces questions concernent un

personne que vous pourriez travailler avec ou à l'équipe ou d'un groupe plus large:

Quels sont les styles de communication sont utilisés? directe ou indirecte? Les gens sont ouvertement
communicative, ou sont-ils réservés? Y at-il communément admis façons de faire de certains
genres de points? Les gens sont généralement efficaces dans l'utilisation du courriel? Réunions? Sont les décisions prises
portes ouvertement ou derrière fermé? Adaptez vos approches pour ceux qui seront efficaces avec
qui vous parlez.

Comment large ou étroite est le sens de l'humour du groupe? Quels sont les thèmes interdit de rire
ou à remettre en question? Comment sujets délicats / difficiles / ou décisions litigieuses sont traitées par d'autres?

Arguments sont gagnées fondées sur des données? argument logique à travers le débat? L'adhésion à la
les objectifs du projet? Qui crie le plus fort? Qui a le plus brune nez? Pensez à faire des arguments
qui utilisent le style, le format ou la tonalité la plus acceptable pour votre auditoire, que ce soit un testeur solitaire
dans le couloir ou une salle pleine de cadres.
 Qui est ou
efficace à faired'eux?
<insertFaites
choseattention
que vous essayez de faire ici>,
Qui et ce les
questars?
je peux
émuler apprendre à ce qui fonctionne. sont Qui reçoit le

Page 245

plus de respect? Comment sont-ils en plein essor? Qui ne parvient pas ici? Pourquoi sont-ils échouent?

En termes de comportement réel, quelles valeurs sont les plus importants à cette personne ou d'un groupe?
Intelligence? Courage? Vitesse? Clarté? Patience? L'obéissance? Quels sont les comportements moins valorisés
ou sont déplorer? Les programmeurs et les gestionnaires peuvent avoir des valeurs très différentes. Savoir ce que le
d'autres valeurs de type avant vous essayez de le convaincre de quelque chose.

Qu'est-ce que la culture organisationnelle? Chaque université, société, ou une équipe a un autre
un ensemble de valeurs intégrées dans la culture. Si vous ne pensez pas que votre organisation a un, vous avez été
il trop long et ne peut plus voir (ou peut-être vous jamais vu du tout). Certaines organisations
la loyauté et le respect de la valeur au-dessus de l'intelligence et de l'individualité. D'autres se concentrent sur l'éthique de travail et
engagement.

Selon les réponses à ces questions, un PM devrait faire des ajustements à la façon dont elle l'a fait
travail. Chaque fois que vous entrez dans le bureau d'une autre personne, ou d'une autre réunion, il devrait toujours être
certains ajustements apportés. Comme un marin, d'évaluer l'environnement et ensuite juger de la meilleure route à
obtenir les objectifs du projet. Évitez de prendre la route difficile si il ya une façon plus intelligente pour arriver là où vous avez besoin
aller.

13.6.1. Les tactiques de guérilla

Être avertis signifie que vous cherchez, et disposés à prendre, la route intelligente. La liste suivante
contient tactiques que je l'ai utilisé avec succès ou ont été utilisés avec succès sur moi. Bien que votre
kilométrage peut varier avec eux, je suis sûr que cette liste va vous amener à réfléchir à d'autres façons avertis à
accomplir ce qui doit être fait pour atteindre vos objectifs. Certains d'entre eux présentent des risques, que je vais noter, et
doit être appliqué avec soin. Même si vous choisissez de ne jamais utiliser ces soi-même, en étant conscient d'entre eux,
vous serez avertis de ce qui se passe autour de vous.

Savoir qui a le pouvoir . Ne perdez pas de temps à discuter avec des gens qui ont aucun contrôle ou
influence sur la question. Pour être efficace, vous devez savoir qui prend les décisions ou les influences d'un
problème ou une situation particulière. Découvrez qui il est (il est pas toujours la personne la plus haut dans le
chambre, et l'identité de la personne peuvent changer d'une question à), obtenir du temps avec lui de un
à-tête, et faire de votre cas. Ou, au moins savoir ce qu'elle oppose vraiment. Si vous ne pouvez pas arriver à
la personne la plus influente (Sally, le vice-président), trouver la personne qui a le plus d'influence sur
elle (meilleur employé de Sally). Accédez au point de la chaîne, vous pouvez rejoindre le plus élevé. Attention: ne pas
les gens de fin de cycle. Allez au point de l'autorité, mais d'inviter le point de vue opposé, si nécessaire, ou
lui révéler ce que vous faites. «Regardez, nous sommes en désaccord, mais nous pouvons être d'accord qu'il est Sally
décision. Je vais aller lui parler à ce sujet demain. Je vous aime d'être là. "(Voir
Chapitre 16 ).

Allez à la source . Ne pas dillydally avec des interprétations d'occasion des gens de ce que quelqu'un
dit, et ne dépendent pas de déclarations ou d'e-mails écrits pour des informations complexes. Trouver le réel
personne et lui parler directement. Vous ne pouvez pas obtenir de nouvelles questions répondues par des rapports de lecture ou
e-mails, et souvent les gens vont vous dire des choses importantes qui étaient inappropriés pour écrite
communication. Aller à la source est toujours plus fiable et plus précieux que les solutions de rechange,
et il vaut la peine de l'effort requis. Par exemple, si deux programmeurs se disputent sur ce qu'est un
troisième programmeur dit, obtenir que la troisième programmeur dans la salle ou au téléphone. Toujours couper à
la chasse et de pousser les autres à faire de même.

Basculer entre les modes de communication . Si la communication ne fonctionne pas, changer de mode. Au lieu de
e-mail, de les appeler sur le téléphone. Au lieu d'un appel téléphonique, déposer par leur bureau. Tout le monde est plus
à l'aise dans certains médiums que d'autres. (En général, face à face, en face d'un tableau blanc,
l'emporte sur tout. Obtenez personnes dans une chambre avec un tableau blanc si le thread de messagerie sur une question
devient hors de contrôle.) Ne laissez pas les limites d'une technologie particulière vous arrêter. Parfois,
le changement de mode vous permet de vous une réponse différente, même si votre demande est le même, parce que
les gens sont plus réceptifs à un mode à un autre. Pour tout ce qui en conséquence, il vaut la peine
d'argent et de temps pour monter dans un avion, en voiture ou à leur bureau, si elle améliore la communication
dynamique entre vous et un collègue de travail importante.

Amener les gens seuls . Lorsque vous parlez à quelqu'un en privé, sa disposition à vous est différent

Page 246

que lorsque vous lui parlez dans un grand groupe. Lors d'une réunion, les gens importants ont pour élaborer ce
ils disent être approprié pour toutes les oreilles dans la chambre. Parfois, vous entendrez radicalement
choses différentes en fonction de qui est à portée de voix. Si vous voulez un avis franc et honnête, ou un
en profondeur de conversation intense, vous avez besoin d'amener les gens seuls. Aussi, pensez à des gens d'influence:
si Jim confiance l'avis de Beth, et vous voulez convaincre Jim, si vous pouvez convaincre Beth abord, apportez
son long. Ne pas embuscade personne, mais ne pas hésiter à les choses de la queue pour faire des progrès
arriver.

Hunt gens vers le bas . Si quelque chose est urgent et que vous ne recevez pas le temps de réponse vous
 besoin, tailler de temps sur votre calendrier de jalonner le bureau ou une armoire de la personne. Je l'ai fait
plusieurs fois. Si il ne répondait pas à mes appels téléphoniques ou des courriels, il avait bientôt revenir d'un
rencontrer et me trouver assis devant sa porte. Il avait généralement être pris au dépourvu alors que je devais une
négocier avantage. Ne pas avoir peur d'aller après que les gens si vous besoin de quelque chose d'eux.
Retrouvez-les dans la salle de café. Cherchez-les dans le café à l'heure du déjeuner. Demandez ce que leur secrétaire
réunions, ils sont dans et attendent à l'extérieur. Soyez poli, mais Hunt et obtenez ce que vous avez besoin. (Toutefois,
s'il vous plaît ne pas traverser dans leurs vies personnelles. Si vous chassez ainsi d'informations, vous ne devriez pas
même jamais besoin de traverser cette ligne particulière.)

Hide . Si vous êtes en retard sur le travail et besoin des blocs de temps de se rattraper, devenir invisible.
À l'occasion, je l'ai jalonné une salle de conférence (dans un bâtiment voisin) et dit que le
personnes qui pourraient vraiment besoin de moi où je me trouvais. Je rattrape sur l'email, spécifications, employé
évaluations, ou quelque chose d'important qui a été ne se fait pas, sans être interrompu. Pour
petites orgs, travaillant à domicile ou un café peuvent avoir le même effet (de marques sans fil
ce facile de nos jours). Je me suis toujours encouragé mes rapports à le faire chaque fois qu'ils estiment qu'il
nécessaire. Temps ininterrompu peut être difficile pour les GP à trouver, donc si vous ne pouvez pas le trouver, il faut
fais-le.

Recevez des conseils . Ne pas voler en solo sans carte, sauf si vous avez à. Dans une situation donnée, envisager
qui pense impliqués plus fortement de vous, ou qui peuvent avoir des conseils utiles pour la façon dont vous pouvez obtenir
De quoi as-tu besoin. Faire usage de toute expertise ou expérience que vous avez accès à travers les autres.
Tirez-les de côté et leur demander pour elle. Cela peut être sur une personne, une décision, un plan, rien.
"Hé Bob, je voudrais votre avis sur ce budget. Avez-vous quelques minutes?" Ou, «Jane, je suis
essayer de travailler avec Sam sur cette question. Tous les conseils sur la meilleure façon de le convaincre de couper cette
fonction «Pour beaucoup de gens, demandant simplement leur avis sera score Vous points de crédibilité: il est un
acte de respect pour lui demander l'opinion de quelqu'un.

Appel en faveurs, Beg, et pot de vin . Faire usage de la crédibilité ou de la générosité que vous avez développé une
réputation. Si vous avez besoin d'un ingénieur pour faire un travail supplémentaire pour vous, soit parce que vous avez raté
quelque chose ou une exigence tard venus, demandez-lui de vous faire une faveur. Aller à l'extérieur des limites
de la relation de travail rigoureuse, et de demander. Offre d'achat de son dîner (20 $ est souvent bien utile
quelle que soit la faveur est), ou lui dire que vous lui devez un (et ne tenez-vous à ce sujet). La
pire chose qui puisse arriver est qu'elle va dire non. Les plus de faveurs que vous avez fait pour les autres, les
plus de jetons vous aurez à miser sur. Aussi, envisager de travailler à trois voies métiers (par exemple, dans le jeu
Colons de Cattan) si vous savez quelque chose, elle veut que vous pouvez obtenir auprès de quelqu'un d'autre.
Il est contraire à l'éthique pas à offrir aux gens des choses qui vont les convaincre d'aider avec le travail qui doit
être fini.

Jouer les gens hors de l'autre . Cela ne doit pas être evilif vous êtes très prudent. Si Sam donne
vous une estimation de travail de 10 jours, qui vous pensez est faux, aller demander Bob. Si Bob dit
quelque chose de moins de 10 jours, revenir à Sam, avec Bob. Une conversation immédiatement s'ensuivre
sur ce que l'estimation de travail doit être vraiment. Si vous faites cela une fois, aucun ingénieur ne sera jamais donner
vous Bogus estimations nouveau (vous avez appelé des conneries). Toutefois, en fonction de la personnalité de Sam,
cela peut vous coûter des points de relation avec lui, donc le faire avec autant de tact que possible, et seulement quand
nécessaire. Les bons programmeurs de plomb devraient appeler bluffs estimation de leur propre chef, mais si elles
ne pas, il est à vous.

La pile du pont . Ne jamais entrer dans une réunion importante sans connaître les opinions de la
personnes importantes dans la chambre. Arrivez toujours avec un sens pour celui qui est susceptible de soutenir votre
opinion et qui est susceptible d'être contre elle, et avoir une stratégie développée pour naviguer à travers
tout (voir chapitre 16 ). Si quelque chose d'important est en jeu, de faire quelques mouvements d'influencer ceux
contre vous, ou pour rallier leur soutien, avant la réunion. Ne pas mentir, manipuler ou induire en erreur, mais
ne préparer sérieusement et de comprendre les arguments et contre-arguments qui va monter.

Page 247

Acheter les gens et les choses café savoureux . Cela semble stupide, mais je l'ai constaté que les gens que je l'ai
discuté avec des journées entières sont en quelque sorte plus réceptifs sur une bonne tasse de café au niveau local
café. Changer la dynamique de la relation: peu importe combien vous aimez ou ne plaît pas
la personne, faire l'invitation et d'investir les 20 secondes d'effort dont il a besoin. Même si, dit-il
"Non, pourquoi ne pouvons-nous parler ici?", Vous avez rien perdu. Déménagement de la conversation à un autre
emplacement, peut-être un moins formelle, peut l'aider à ouvrir à des solutions de rechange, il ne serait pas considérer
avant. Pensez biologiquement: les humains sont en meilleure humeur après qu'ils ont mangé un bon repas ou lorsque
ils sont dans un environnement plus agréable. PMs je ai vu qui gardent des beignets ou des biscuits (ainsi
que le rhum et whisky) dans leur bureau. Est-ce un acte de bonne volonté? Oui ... mais il ya psychologique
avantages à faire sûr que les gens avec lesquels vous travaillez sont bien nourris et que vous associez à
bonnes choses.
Page 248

13.7. Résumé

Tout peut être représenté dans une liste ordonnée. La plupart des travaux de la gestion de projet est
prioriser les choses correctement et de diriger l'équipe dans leur mise en oeuvre.

Les trois listes ordonnées les plus fondamentaux sont les suivants: les objectifs du projet (vision), la liste des fonctions, et la liste des travaux
articles. Ils doivent toujours être en phase avec l'autre. Chaque élément de travail contribue à une fonction,
et chaque caractéristique contribue à un but.

Il ya une ligne jaune vif entre la priorité 1 travail et tout le reste.

Les choses arrivent quand vous dites non. Si vous ne pouvez pas dire non, vous avez effectivement pas de priorités.

Le PM doit garder l'équipe honnête et les garder près de la réalité.

Connaître le chemin critique dans les processus d'ingénierie et de l'équipe permet d'efficacité.

Vous devez être à la fois implacable et de bon sens pour faire bouger les choses.
Page 249

Chapitre quatorze. Stratégie-jeu Moyen-

Le titre de ce chapitre, «stratégie-jeu Moyen," se réfère à la partie d'échecs. jeux d'échecs sont
divisé en trois parties: ouverture, milieu de jeu, et de fin de jeu. Le jeu de milieu est lorsque le
la stratégie générale de joueur devient évidente et est appliqué à travers déplace le joueur fait. Les plus
se déplace dans un jeu sont faites pendant le jeu du milieu. Fin de jeu est la conclusion du jeu, où
les ressources sont minces et tous les chefs d'accusation de déplacement simples. Ce chapitre se concentre sur la mi-match projet, et de la
chapitre suivant couvre projet de fin de jeu.

"Chance favorise le prêt."

Louis Pasteur

Mi-jeu sur les projets est le milieu de la planification globale. Vous saurez que vous êtes à la mi-match lorsque
certaines choses fonctionnent, mais certaines choses ne sont pas, certaines questions ont été découverts et résolus,
mais vous savez que d'autres ont même pas encore été trouvé. Mi-jeu est difficile, car beaucoup de choses sont
passe dans le même temps, et il est difficile de maintenir la clarté sur ce qui va bien et ce qui l'est pas.
Le terme brouillard de guerre utilisée par Clausewitz (1) en référence à la façon dont la guerre peut sembler chaotique pendant que vous
sont en itapplies bien à la mi-match. Il ya un brouillard inévitable de l'activité de développement qui l'entoure
l'équipe, et il est facile pour les novices de se perdre. Il est de la responsabilité des dirigeants de l'équipe de
amener l'équipe à travers l'incertitude de la mi-match et à en fin de jeu, où les choses deviennent
effacer à nouveau.

Dans le plus simple vue possible, mi-jeu et de fin de jeu sont tous sur la maintenance de haut niveau: (2)
 1. Si les choses vont bien à la fin de la première journée, alors le but pour le jour suivant est de le garder
va bien.

2. Si un jour le projet ne va pas bien, il est de votre devoir de comprendre quels sont les enjeux et

Page 250
2.
puis prendre des mesures pour rendre le projet bien courir à nouveau. Cela peut prendre des heures, jours ou semaines.

3. Répétez jusqu'à ce que le projet est terminé.

Le défi évident, même dans ce point de vue simple, est qu'il ya un nombre infini de choses qui
peut arriver à faire un projet pas bien fonctionner. Pire encore, il ya une quantité limitée de temps pour comprendre
quel est le problème et encore moins de temps pour le résoudre. Sans parler de l'effort nécessaire pour maintenir la bonne santé
parties du projet de courir en difficulté.

Pour ces raisons et d'autres, de l'énergie et de stress au cours de la mi-match et la fin du jeu sont très
élevé. L'équipe se déplace à une vitesse croissante et les marges d'erreur deviennent plus petits chaque jour. Et
alors que les approches de fin de jeu, quelqu'un doit trouver la bonne façon non seulement d'appliquer les freins, mais
également à ralentir le mouvement vers le bas progressivement afin que les choses finissent bien.

Dans ce chapitre et le suivant, je vais utiliser les mêmes hypothèses compris sur la méthodologie que je
réalisés dans le chapitre 2 (ce conseil applique bien, indépendant de la méthodologie que vous utilisez). Ça pourrait être
d'une valeur écrémé rapide de la section " des balles d'argent et de méthodes »dans le chapitre 2 avant de creuser dans
Ici.

Bien que ce chapitre applique principalement à la mi-match et la prochaine applique surtout à la fin du jeu, il est
beaucoup de chevauchement dans comment et quand ces techniques peuvent être appliquées (par exemple, la fin du jeu d'une phase peut
être considérés comme faisant partie de la mi-jeu de l'ensemble du projet). Alors, soyez prévenu que je vais parfois déplacer
et-vient entre ces deux sujets différents.

NOTE

La couverture de la mi-jeu et de la gestion de fin de jeu dans ce chapitre et le suivant est

force industrielle. Si vous voyez des questions ou des situations qui ne sont pas applicables en raison de la taille
de votre équipe ou de la portée de votre projet, vous pouvez parcourir ou les ignorer. Je ne pense pas que
tout ce que je couvrirai ici est valable pour un seul projet. Cependant, je suis en train de fournir de la valeur
de vous non seulement pour votre projet en cours, mais aussi la suivante et celle d'après. Là
sont nombreux angles et des questions ici qui se révélera utile pour vous dans le long terme, même si
certaines d'entre elles ne vaut pas pour ce que vous travaillez aujourd'hui.

Page 251

14.1. Vol en avant du plan

 Pilotage de grands objets dangereux exige plus que d'une main ferme. La plus grande chose que vous êtes la
direction, et plus les gens qui y participent, plus l'inertie dont il dispose. Comme la gestion de projet,
novices au pilotage grandes machines (voitures, avions, porte-avions, etc.) sous-estiment le temps
prend pour des changements à la tête d'être reflétées dans le comportement de la chose, ils sont de direction. Comme
montré dans la figure 14-1 , la trajectoire de gros véhicules, ou des projets, les changements de manière significative selon
sur combien dynamique ou d'autres forces sont impliquées. La plupart des gens, surtout les novices, ne parviennent pas
pour définir leurs attentes correctement pour les résultats de leurs actions. Souvent, cela est parce qu'ils ne le font pas
comprendre toutes les forces qui contribuent à la dynamique de la chose qu'ils fonctionnent. Aimer
quelqu'un à apprendre à conduire qui dérape dans la neige pour la première fois, il ya un trop grand nombre
forces inexpliquées interagir pour elle de rester en contrôle.

Quand les gens qui sont censés être en contrôle de perdre le contrôle, leur réponse commune est à la panique.
Ils pourraient ne pas l'admettre (personnes en mode panique admettent rarement qu'ils sont pris de panique), mais il est vrai. La
première réponse est généralement de prendre une action audacieuse correctives en réponse directe au problème. Mais depuis
ils ne comprennent pas vraiment toutes les forces, cette action corrective sera généralement beaucoup trop fort
(Voir Figure 14-2 ). Au moment où ils se rendent compte de ce qu'ils ont fait, une autre action corrective est nécessaire,
où ils exercent immédiatement. Mais depuis qu'ils sont encore en utilisant la même logique qui les a mis dans ce
la situation amusante, en premier lieu, plus de problèmes découlent.

Figure 14-1. La même action peut avoir des résultats différents en fonction de
combien inertie projet, il est.

Figure 14-2. À la consternation de ceux qui sont censés être en contrôle,

actions correctives sur des forces inconnues ont imprévisible (et souvent
affolantes résultats).

Page 252

Le fait est que quand un avion, l'automobile, ou le projet devient instable, il est difficile de dangereusement
controleven pour quelqu'un avec des compétences et de l'expérience d'experts. (Les petits projets sont certainement plus agile
et réactif, mais ils ont leurs élans, aussi.) L'instabilité rend le résultat de la plupart des actions
imprévisible, car il ya trop de variables changeantes trop rapidement. Bon projet
la gestion, puis, est en grande partie au sujet de rester une ou deux étapes à venir du projet, investir
quelle que soit l'énergie est nécessaire pour éviter d'entrer dans ces situations, en premier lieu.

Les pilotes de chasse ont une expression de ce qui arrive quand un pilote ne parvient pas à rester en tête: voler derrière la
avion. Cela signifie que le pilote n'a pas réussi à rester (au moins) une longueur d'avance sur ce qui se passe à son
 la machine, et il est maintenant une victime de l'interaction des forces sur son avion. Comme voler haut
avions de performance, les projets nécessitent la gestion de nombreuses forces interactives différentes. Ils
sont les deux systèmes non linéaires, ce qui signifie que la modification d'un élément (vitesse, l'angle, le calendrier, les objectifs)
peut avoir plus d'un effet, ou peut affecter le système avec plus de force que prévu, en raison
il est amplifié à travers de nombreux facteurs différents ou des personnes. L'avertissement est la suivante: même avec une écurie, mais
projet à haute vitesse, la nature complexe de la fois la base de code et l'équipe signifie toute gestion
action peut avoir des conséquences inattendues. Parfois, ces conséquences ne seront pas visibles pour
jours, voire des semaines. Lorsque ces effets à long terme font surface, il est trop facile de supposer
quelque chose de plus récent a causé le problème, ce qui rend difficile de résoudre de manière efficace.

14.1.1. Vérifiez votre santé mentale

Pour les gestionnaires de projet, la manière la plus efficace de voler en face du plan est d'avoir un bon sens quotidien
vérifier. Les programmeurs utilisent le terme de vérifier la santé mentale afin d'assurer que certaines choses importantes sont vraies dans
leur code (dans la terminologie C, pensez assert () ). Ceci est une très bonne idée parce que les hypothèses sont
des choses très dangereuses. Dans le code, lorsque l'un de ces contrôles de validité échoue, tout le monde peut aller au-delà du
recherche désespérée pour les harengs rouges (problèmes qui ne existent pas), et posent la question plus fondamentale
pourquoi une condition folle a été introduit dans le système.

Si vous voulez "voler en avant de l'avion," vous avez constamment veiller à ce que les conditions vous êtes
attendre sont toujours vrai. Et puis si vous en trouvez un qui est faux, vous savez immédiatement où votre
l'attention doit être.

Le défi est qu'il ya beaucoup d'autres vérifications de bonne santé possibles. Entre les objectifs, les horaires,
technologies, le moral, la concurrence, le budget et la politique, il est impossible de tout vérifier toutes les
le temps (bien que cela ne l'empêche pas certains gestionnaires paranoïaques d'essayer). Il est une erreur fatale de
faire glisser une équipe à travers la torture quotidienne de confirmer des dizaines de hypothèses aléatoires. Les plus pokes
vous faites à une équipe pour confirmer choses qui devraient généralement être vrai, moins vous leur faites confiance, et de la
plus vous perdre leur temps. Vous voulez connaître l'état de projet sans perturber l'état de
le projet.

Il ya trois façons de le faire: questions tactiques, des questions stratégiques, et les progrès transparente
mesures pour l'équipe. Nous aborderons des mesures dans le prochain chapitre. Pour l'instant, concentrons-nous sur tactique et
des questions stratégiques pour la santé mentale vérification.

Le processus est simple: garder une courte liste de questions qui vous aideront à mettre en avant de l'avion, et
faire un rituel de leur demander. Posez des questions tactiques une fois par jour; poser des questions stratégiques une fois
semaine. Vous pouvez le faire seul, ou choisir les membres spécifiques de l'équipe d'être impliqués dans ce processus avec
tu. Vous devriez également encourager les personnes de l'équipe, en particulier ceux qui sont expérimentés ou
chevronné, à faire de haut niveau semblable vérification de la validité tout sur leurs propres et de corréler leurs résultats

Page 253

avec le vôtre.

Mon approche de cette était la suivante: je verrouille une réunion hebdomadaire d'une demi-heure avec moi-même (si je ne le fais pas
protéger mon temps, qui le fera?) dans mon calendrier. Je ferme ma porte, mis sur quelques airs et courir
grâce à ma liste de question. Souvent, il n'a fallu que quelques minutes. Je serais alors en mesure de redéfinir les priorités de ma journée, ou
mon équipe, en conséquence. Sur certaines équipes, je l'ai poussé à faire ce genre de questionnement partie de la
culture d'équipe, et je l'ai fait de plus petites versions de ce type de questionnement et de répondre pendant équipe
réunions.

14.1.2. Questions tactiques (quotidiens) pour rester en tête

Quels sont nos objectifs et nos engagements? Sont-elles toujours exactes? Il ya tellement de travail
qui doit être fait sur un jour donné qu'il est inévitable que vous et d'autres vont perdre de vue le
buts. Il suffit de les regarder chaque jour réinitialise votre attention et de priorités. Plus important pour
l'équipe, si les objectifs officiels ne correspondent pas aux objectifs réels (disons, en raison de la fantaisie d'un VP) ou l'équipe
objectifs (faire des choses que nous pensons est cool), puis les objectifs ne sont pas exactes. Si les objectifs ne sont pas
précis, l'équipe est en conflit. Quand une équipe est en conflit, les symptômes de surface. Ne pas attendre
pour des symptômes si vous voyez conflits évidents qui finira par leur causer. Restez à l'avant,
en particulier sur les questions qui touchent directement les objectifs.

Est ce que nous faisons aujourd'hui contribuant à nos objectifs? Regardez les éléments de travail de votre
programmeurs travaillent sur aujourd'hui, demain, et cette semaine. Est-il clair comment ils sont
contribuer aux objectifs ou exigences épanouissante? Si non, le navire commence à dériver. Travail
avec le programmateur (s) approprié pour actualiser la compréhension de tous les objectifs et la
la valeur de travail vers les objectifs. Puis ajustez une des trois choses: les objectifs, le travail, ou les deux.
Cela est parfois appelé l'alignement de travail; comme les roues de votre voiture, vous devez périodiquement
Assurez-vous que les choses fonctionnent dans la même direction.

Sont les éléments de travail non seulement en cours d'achèvement, mais en cours d'achèvement d'une manière qui
satisfait les exigences et les scénarios? Il ya mille façons de remplir une unité de travail
qui ne satisfont pas entièrement l'esprit et l'intention de la conception. Toute bonne conception ou spécification sera
ont défini les choses de telle sorte que les éléments de travail seront satisfaire les scénarios réels des clients. Cependant, le
subtilités de la facilité d'utilisation, les exigences opérationnelles, l'intégration des composants, et la conception visuelle sont
souvent perdu sur les programmeurs avec 15 autres éléments de travail à faire. Si un concepteur d'interface dédiée (ou
autre expert) est autour, elle devrait examiner activement check-ins et l'accumulation quotidienne de faire
 Bien sûr, les éléments de travail satisfont holistique, pas seulement un objet de ligne, les exigences.

14.1.3. (Hebdomadaires et mensuels) / des questions stratégiques pour rester en tête

Ces questions sont souvent l'objet de réunions de direction. Si il ya un état hebdomadaire ou mensuelle
discussion, ce sont ces sortes de questions qui méritent une attention de leadership. Mais même pour un individu PM
travailler sur une petite surface, ces questions se posent.

Quelle est notre probabilité actuelle de frapper la prochaine date / Milestone / livrable au
niveau approprié de qualité? Les choses ont changé depuis les estimations de travail ont été effectuées. Comment faire
les gens se sentent sur le travail maintenant qu'ils sont en elle? Demandez-vous, et les personnes clés de votre équipe,
quelle est la probabilité de rencontrer avec succès la prochaine date. 100%? 90%? 50%? Haut?
Medium? Faible? Soyez honnête, et de demander aux autres de faire de même. Soyez sensible à l'équipe: ne pas faire
cette culpabilité ou un défi entraînés, comme si vous essayez de prouver que leurs estimations sont mauvaises ou que
ils ont besoin pour travailler plus dur. Au lieu de cela, le rendre clair que vous avez besoin de réponses honnêtes que de la
moment actuel. (Pourquoi ils ont une faible confiance en soi ou qui est à blâmer pour cela ne change pas le
fait qu'ils ont des doutes tangibles. Vous voulez être au courant et comprendre le tangible
doutes.)

Quels ajustements sont nécessaires pour améliorer cette probabilité? Il doit être extrêmement rare
pour obtenir la confiance de 100% dans la prochaine date de quelqu'un qui est honnête et sain d'esprit. Le suivi
la question de probabilité devrait toujours être comment vous pouvez faire la probabilité plus élevée. Moins

Page 254

des réunions et des interruptions? Des décisions plus rapides? Couper caractéristiques? De meilleures décisions? Clarifier les objectifs?
Meilleures revues de code? Quoi? Demandez aux gens qui sont les plus impliqués dans le travail de première ligne quotidienne.
Faites-lui une question hautement prioritaire pour vous-même et l'équipe de demander activement cette question et d'investir dans
les réponses.

Comment pouvons-nous faire des ajustements avec soin et dans l'isolement? pensent toujours chirurgicalement premier.
Quelle est la plus petite quantité d'action nécessaire pour résoudre le problème et avec succès
améliorer notre probabilité? Un appel? Un courriel? Prendre une décision importante visible? Tir
quelqu'un? Ne pas avoir peur de prendre grosse action si cela est le plus petit montant qui va faire le travail. Si
pas les options chirurgicales sont disponibles, alors penser de façon holistique. Est-ce que les objectifs doivent ajuster? La
check-in processus? Quel processus du système ou de l'attitude peut être ajustée pour résoudre le symptôme et
la cause? (Voir la section suivante, " Agir en toute sécurité . ")

Quels sont les risques plus grands ou les plus probables pour aujourd'hui / semaine prochaine / le mois prochain? Quoi
sont nos éventualités si elles viennent vrai? Tout simplement en identifiant trois ou plus dangereux ou
les risques probables, vous prenez un grand pas vers les prévenir; vous avez tourné votre radar sur,
et vous serez sensible à tout signe d'alerte qui pourraient indiquer ces problèmes se produisent.
Même si vous ne prenez 5 ou 10 minutes par semaine à la liste des risques possibles, et votre possible
réactions à ces risques, vous serez vous-même la mise en avant de l'avion. Ce type de projet
l'assurance est souvent pas cher: quelques minutes une semaine achète beaucoup de protection.

Comment le monde pourrait avoir changé à mon insu? Est-ce mon VP ou encore intervenants
à bord? Ont ses objectifs changé? Sont des acteurs clés de mon équipe inquiètent quelque chose que je
ne sais pas ce que sera l'impact du projet si elles sont à droite? Ce qui a fait notre concurrent
que nous pourrions avoir besoin de répondre? Sont nos partenaires ou des dépendances encore sur la bonne voie? Qu'est-ce que
qui ne va pas aujourd'hui que je ne vais pas découvrir jusqu'à demain? A quelques appels téléphoniques à court ou
errances couloir répondent généralement à cette question. Veillez à ne pas faire de la microgestion, agir sur
la paranoïa, la peur ou la race dans d'autres. Faites-en une chose commune et décontracté à faire ce genre de
enquêtes. Plus encore, encourager et récompenser les gens qui reçoivent de manière proactive ce genre d'information
(À propos de leur propre chef ou les responsabilités des autres) pour vous.

Toutefois, peu importe comment expérimenté, prêt, ou vous êtes intelligent, il y aura toujours jours
vous vous retrouvez volant derrière votre projet. Apprenez à voir la différence entre avoir une tonne de travail à
faire et d'être derrière le plan: ils ne sont pas la même chose. Les chances sont bonnes que vous aurez souvent l'impression, il est
plus de travail à faire que vous avez le temps pour. Toutefois, si vous avez construit listes ordonnées de prioriser le travail (voir
Chapitre 13 ), vous savez, il ya toujours des choses en attente de votre temps. Mais quand vous êtes derrière,
vous vous sentirez congelés, déprimé, voire apathiques. Vous croyez que, peu importe la façon dont la fin de votre séjour à
le bureau, vous ne pouvez jamais remettre le projet sous contrôle.

Trois importants dernières choses:

1. Lorsque vous êtes derrière, savoir que vous êtes derrière . Rappelez-vous que les horaires sont les probabilités. Comment
êtes-vous sûr que ce qui doit être achevé va se faire cette semaine? 80%? 50%? Si les chances sont
50-50 (ou pire) que vous allez faire, vous êtes derrière; votre marge d'erreur est petite, et vous
faire des erreurs si vous ne l'avez pas déjà.

2. Lorsque vous voyez les autres derrière le plan, offrir votre soutien pour les . Ne pas nier le
problème: dites-leur que vous voyez et ce que vous allez essayer de vous aider. Éviter de laisser quelqu'un dans votre sphère de
influence fléau ou de panique. Restez calme, aider les autres à rester calme, et de travailler ensemble pour revenir dans
avant de l'avion.

3. Ne pas hésiter à se faire aider par des pairs ou des superviseurs . Cela peut être le seul moyen de récupérer
et de revenir à l'avant. Utilisez leur aide à prioriser votre temps et celui de l'équipe, la cueillette
 une partie de votre travail, ou tout simplement pour vous écouter défouler. Prendre la main de quelqu'un si elle est
qui vous est offert. Demandez une main si elle est pas offert.

Pour plus de couverture de la façon de faire face aux situations de crise, reportez-vous à Chapitre 11 .

Page 255

14.2. Agir en toute sécurité

Au cours de la mi-match, la plupart des actions sont plus petits, les versions plus strictes de l'activité de PM fait lors de la planification ou de
conception. Si une exigence n'a pas été respectée et doit être incorporé, le processus de définition et
documenter, il est juste une version double du temps de ce qui a été fait au cours du processus des exigences
(Comprendre les besoins, examiner les compromis, définir et prioriser). Ou si quelque chose a été négligé dans le
spec, le processus de règlement, il est une répétition du processus de spécification double ou triple-temps. Peu
de nouvelles compétences sont employées pendant la mi-match. Il est généralement juste une version plus légère et plus rapide d'une compétence qui
a été utilisée plus tôt. Le problème est que le travail à la vitesse engendre un risque. Agir en sécurité pendant
mi-jeu signifie simplement que l'intégrité du projet est pas involontairement perturbé à la suite
de l'action.

L'action sécuritaire est difficile parce que les munitions est en direct à la mi-match. Les choses sont déjà en mouvement et
beaucoup de décisions ont déjà été prises, qui peuvent entrer en conflit avec toute nouvelle action. Par exemple, si
à mi-chemin à travers la construction de votre maison, vous décidez de modifier le plan d'une norme A-
cadre à un dôme géodésique, vous devrez jeter beaucoup de matériaux et de l'effort, et peut-être
nécessitera de nouvelles activités à faire davantage sous pression. Il faut de l'expérience pour apprendre comment changer une
exigence, la coupe d'une fonction, ou la modification d'une conception va affecter à la fois la base de code et l'équipe.

Le but de toute PM doit être de prendre des mesures de sécurité. Elle a besoin de se déplacer et de se comporter d'une manière qui
maintenir simultanément le projet sur la bonne voie pour atteindre des objectifs qui pourraient changer, tout en causant le moins de
dommages au projet que possible. Quelques dégâts est inévitable et devrait être prévu. Mais plus
Les actions de PM sont efficaces, l'impact moins négatif, il y aura.

Comme la figure 14-3 montre, plus le long d'un projet est, plus il est difficile de prendre des mesures de sécurité. C'est
parce que la probabilité qu'une action aura des conséquences coûteuses monte au fil du temps: la
les chances sont plus élevés que les travaux déjà réalisés devront être modifiés ou jetés. Ceux
les dépenses peuvent être entièrement garantis, mais de prendre des mesures en toute sécurité signifie qu'il ya une certaine connaissance
au sujet des coûts avant que des décisions soient prises.

Figure 14-3. Faire des ajustements sûrs est plus difficile si l'ajustement est
grande, et / ou qu'il est fait en fin de projet.

Lors de l'examen des ajustements (changements fonctionnalité / but / exigence) au cours de la mi-match, les cinq
questions à considérer sont:

1. Quel problème essayons-nous de résoudre? Avons-nous besoin de résoudre ce problème pour réussir? Faire
nous avons besoin de résoudre ce problème au cours de cette étape? Pouvons-nous vivre juste avec le problème?

2. Est-ce un symptôme ou problème une cause? Est-il acceptable de résoudre seulement le symptôme?

3. Comprenons-nous l'état du code ou de l'équipe assez bien pour prédire comment une action sera
impact sur eux?

4.

Page 2563.

4. Sont les coûts de l'ajustement (y compris le temps de comprendre l'état du code / de l'équipe,
 envisager des alternatives, et d'obtenir un soutien politique pour la décision) vaut le bénéfice de la
changer? Trouver et résoudre les causes pourrait coûter plus que simplement vivre avec le
symptômes, beaucoup moins les fixer.

5. Les risques de nouveaux problèmes potentiels valent le bénéfice du changement?

La décision de prendre des mesures repose sur les mêmes stratégies de prise de décision abordés dans
Chapitre 8 . Toute conception, de spécification, de la communication, ou l'action politique nécessaire fait usage de la
tactiques discutés dans les chapitres 6 , 7 , 9 , et 16 , respectivement. L'attitude et l'approche sont les mêmes,
sauf que le calendrier et la marge d'erreur sont beaucoup plus petits. Le manque de temps pour examiner les options
signifie deux choses. Tout d'abord, compter sur les connaissances apprises au cours de tout effort de prototypage ou de la conception dès le début.
Certains des ajustements que vous envisagez aurait dû faire surface à l'époque, et d'utiliser l'équipe de
connaissances pour aider à l'analyse actuelle. Deuxièmement, être conservateur. Le moins vous en savez, plus les risques
vous ne pouvez pas voir. Le plus tard, vous êtes dans le calendrier, plus la barre devrait être de prendre des mesures.

14.2.1. Engagements de rupture

Une partie intégrante de l'action sécuritaire envisage les engagements des chefs d'équipe ont apportée à la
équipe. Comme nous avons discuté dans le chapitre 12 , les dirigeants de fiducie gagnent de l'équipe est défini par la façon dont le
dirigeants gèrent leurs engagements. Le document de vision, les exigences et le calendrier sont
toutes les formes d'engagement entre la direction, les chefs d'équipe, les programmeurs, et le client. Quelconque
action que vous prenez à la mi-jeu peut invalider les engagements antérieurs que vous avez apportées.

Pour maintenir la confiance avec votre équipe que des changements se produisent, vous devez payer rapport à précédente
engagements. Comme l'a déclaré Humphrey, «Si quelque chose change que les impacts ou l'autre partie par rapport à la
engagement, un préavis est donné et un nouvel engagement est négocié. "Les changements sont autorisés,
mais ils doivent suivre un processus de négociation similaire à celle qui a conduit à la première série de
engagements (vision, exigences, calendrier). Vous ne devez pas rédiger des documents ou ont grand
réunions, mais vous avez besoin d'informer les gens que les engagements sont en train de changer, et de les impliquer dans le
processus de décider comment ces changements vont se produire.

Si vous demandez à votre équipe de jeter deux semaines de travail, assurez-vous que vous avez inclus ceux
coûts lors du calcul de la décision. Fournissez-leur raisonnement pour expliquer pourquoi le nouveau changement est le
droite, et leur dire quels facteurs ont contribué à cette opinion. Si possible, amener les gens sur le
équipe dans la discussion avant que les décisions finales sont prises.

Ne pas avoir peur de faire des changements. Le changement est bon, et il est inévitable. Mais il ya beaucoup de différents
sortes de changements, et de nombreuses façons différentes pour un leader de gérer une équipe à travers elle. Si tu étais
vers l'ouest, et veulent maintenant le projet vers le nord, vous aurez besoin d'appliquer les mêmes types de
compétences (même si deux fois plus rapide et la moitié formelle) nécessaires pour obtenir l'équipe vers le nord, comme vous le faisiez
pour les obtenir vers l'ouest. Retour sur les chapitres 3 , 4 , 11 et 12 pour des conseils sur conduisant à travers
changer.

Page 257

14.3. Le pipeline de codage

Le point de vue pragmatique du travail à mi-jeu se concentre sur l'écriture de code programmeurs. La seule façon de le
projet va de l'avant est à chaque ligne de code écrite qui porte le projet de plus près à l'achèvement
(Caractéristiques animaux, optimisations inutiles, etc., ne se déplacent pas avancer le projet). Toute la planification
et l'effort de conception qui a lieu avant les programmeurs d'écrire du code, qu'il soit effectué par eux ou par
d'autres, est fait pour créer une séquence de travail efficace pour eux de faire tout le temps est compté. Ce
est appelé le pipeline de codage.

Il est le travail de la PM pour vous assurer que le pipeline de codage se déroule sans heurts. Tandis que les programmeurs pourraient
propriétaire de la gestion de la filière et de décider qui travaille sur quoi, (3) il est toujours le PM de
la responsabilité de faire en sorte que l'équipe de programmation a autant de soutien que nécessaire de faire
 ça fonctionne. Cela peut impliquer des tâches de Gopher, l'organisation de réunions, lancinante diverses personnes pour finaliser
décisions, ou, dans certains cas, de résoudre les problèmes de conception restants (4) (voir Figure 14-4 ). Le PM
peut avoir à travailler quelques jours devant le programmeur, la finalisation des dessins et alimenter le pipeline.
Si un PM est responsable pour le travail de plusieurs développeurs, elle devra établir des priorités soigneusement son temps
pour assurer qu'elle peut jongler avec les demandes concurrentes de multiples pipelines (une autre raison pour laquelle le plomb
programmeur devrait faire partie ou plus de ce travail).

Figure 14-4. Les derniers détails d'un spec / la conception peuvent être vérifiées ou finalisés
en parallèle par le PM ou le concepteur. Cela contribue à la valeur de la
codage pipeline.

Dans la gestion de projet Web: Delivering réussissent Sites Web commerciaux (Morgan Kaufmann,
2001), auteur Ashley Friedlein appelle ce processus informer l'équipe, et les détails pour le prochain morceau
du travail qu'ils ont à faire est appelé un bref. Comme l'écrit Friedlein, "Pour maximiser l'efficacité et la rapidité de
développement, vos mémoires doivent être créés afin qu'ils soient toujours en avance de l'endroit où le travail est à
le moment. Dès qu'un morceau de travail est terminé, vous avez la mémoire pour la prochaine section de travail
prêt ". Ces mémoires sont dérivés des spécifications (si elle est encore pertinente), mais comprennent quelque chose de nouveau ou
changé que le programmeur pourrait avoir besoin de savoir. Sans informer activement les programmeurs cours
mi-jeu, il peut y avoir un certain nombre de choses qui bloquent un élément de travail et de ralentir le pipeline:
les problèmes d'utilisation, le travail de conception visuelle, les éléments de travail effectuées par d'autres programmeurs, les questions de marketing,
des problèmes techniques ou des dépendances externes. Parce que les MP ont souvent l'ensemble le plus diversifié de compétences,
ils sont les meilleures personnes pour exécuter le point pour le pipeline de codage, de fanions ou résoudre les problèmes, et
lisser les choses avant le programmeur commence sur eux. (Cela inclut la recherche de frustrés
programmeurs qui sont bloqués, mais soit ne sera pas admettre ou ne sont pas encore rendu compte.)

Quatre questions définissent comment le faire bien:

Page 258

Quel travail éléments sont activement codés? Y at-il des problèmes de blocage programmeurs
de terminer leurs éléments de travail actuellement actifs? Si oui, les éliminer (les problèmes de blocage,
pas les éléments de travail). Ceci est un état d'alerte maximale pour un projet. Si un programmeur est bloqué
écrit activement code, le projet est au point mort. Rien est plus important que de résoudre un problème
que les blocs d'un programmeur. Il suffit de leur demander: «Comment puis-je vous aider à résoudre ce problème?" Ils vous permettent de
savoir si vous pouvez aider. Si le problème de blocage est une dépendance (par exemple, Fred doit terminer élément de travail 6
avant que Bob peut commencer sur le point de travail 7), tenir compte des autres travaux un programmeur peut faire jusqu'à
ce bloc est retiré.

Est-ce que le programmeur connaît et comprend tout le nécessaire pour mettre en œuvre la
actuelle élément de travail de spécification? Il ya toujours des questions qui se posent et les lacunes seulement à
le moment de la mise en œuvre. Certains programmeurs sont plus proactifs que d'autres au sujet de
la résolution de ces lacunes d'une manière mature. Le PM ou le concepteur doit être disponible et
impliquer assez pour aider à identifier et combler ces lacunes. Parfois, ils peuvent être anticipatedfor
par exemple, ont été toutes les questions soulevées lors de l'examen de spécification pour cet item de travail résolus?

Quelle est la prochaine série d'articles qui seront codées? Ceci est où la gestion des biens de pipeline
commence: rester une longueur d'avance de programmeurs (voir Figure 14-4 ). Si le travail actuellement actif
les articles sont en bonne forme, l'accent se déplace vers les éléments suivants jusqu'à la canalisation. Les prochains articles
doit tendre vers la prochaine pièce la plus importante de travail pour le projet. Toujours essayer de faire la
la plupart des travaux critiques en premier, même si elle est la plus difficile. Pour chaque élément dans le pipeline, pensez à ce
questions ouvertes qu'ils ont cela pourrait ralentir ou bloquer le programmateur lorsque l'élément arrive sur son
plaque. Trouver et de les résoudre.

Était le dernier élément de travail qui a été achevé, vraiment terminé? Il est la sortie du
codage pipeline qui importe. Quelqu'un doit se pencher sur l'effet de check-ins sur la construction
et assurez-vous qu'il fait ce qu'il est censé faire à partir de la perspective du client. A fait le
l'achèvement de ce dernier élément de travail vraiment ajouter la fonctionnalité et le comportement nécessaire? Est-ce que la
équipe de test d'accord? Ont tous les tests unitaires passent? Quelqu'un at-il au moins ouverte bogues de suivre ce qui est
manquant? Daily construit (décrit dans le chapitre suivant) sont un moyen facile de suivre ce parce que vous
peut toujours expérimenter l'état actuel de la projectand trouver des lacunes dans ce qui était completedto
ce qui est nécessaire. Le plus grand l'élément de travail, plus cela est important.

Certains programmeurs prennent plus de responsabilités pour leurs pipelines de codage que d'autres. Beaucoup
 programmeurs seront plus agressivement chercher certains types de questions (techniques) et ont tendance à ignorer
ou du retard sur les autres (affaires, politique). Une partie de votre relation avec chaque programmeur est de savoir
le degré de participation vous devez prendre dans la gestion de leur pipeline. Il n'a pas d'importance tant
qui le fait, aussi longtemps que cela est fait, et quelqu'un est activement vérifier et protéger la qualité de
ces éléments de travail. (Ceci est une discussion de rôle, comme décrit dans le chapitre 9 ).

14.3.1. Pipelining agressif et conservateur

Souvent, le pipeline de codage ne doit être deux ou trois points d'avance sur l'équipe de programmation (si
chaque article nécessite deux jours, trois éléments ont besoin de plus d'une semaine de travail). Il peut être un informelle
discussion entre les GP et les programmeurs se mettre d'accord sur la séquence logique suivante. (Ou, si un maître
chemin critique ou diagramme de Gantt existe, et il est effectivement pas des semaines sur la date, le pipeline peut être dérivé
d'elle.) Cela donne juste assez d'un tampon de sorte que si un problème de blocage ne peut être résolu dans le temps, la
programmeur et PM ont suffisamment de temps pour trouver un autre élément de travail approprié pour mettre dans le pipeline
tout en bloquant cette question se résoudre.

Une équipe avec une posture agressive peut miser plus fortement sur le pipelining la priorité aux questions. Au lieu de
réalisation d'une structure de répartition du travail élaborée (WBS) de tous les éléments de travail, les paris de l'équipe lourdement sur
changements qui se produisent et sur la capacité de la PM ou programmeur en chef pour gérer le pipeline. La
les risques sont plus élevés ici: si le pipeline est sauvegardé ou ne peut pas rester en tête de l'équipe, de mauvaises décisions
va se fait et le temps sera gaspillé. Pour plus sur la construction de bonne WBSs et leur application à
le calendrier du projet, voir Contrôle total du projet par Stephen Devaux (Wiley, 1999), ou de tout bon
référence de la gestion de projet traditionnelle.

Pour les équipes avec une posture plus conservatrice, la gestion du pipeline est un raffinement de la douce
originale liste des éléments de travail qui a été créé lors de la planification. Le pipeline peut être tracée pour semaines

Page 259

ou mois de travail, en utilisant le plan original comme source pour le pipeline pour chaque programmeur. Là
pourrait être de petits ajustements, mais l'attente est que le plan original restera viable grâce à
moins, le jalon. Lorsque la prochaine étape commence, une nouvelle liste des éléments de travail est généré dans le cadre de
planification et le processus se répète. Donc, selon la façon dont la courte étape est, ou comment une écurie
projet est, la planification initiale du pipeline peut être fait pour travailler.

Cependant, le point fondamental concernant les gazoducs est pas comment vous le faites. Chaque méthode offre une
manière alternative. Ce qui importe est que le pipeline est géré efficacement, que les éléments de travail droite
sont fait dans le droit chemin, et que peu de temps est perdu à trouver ce que pour mettre en œuvre prochaine.

14.3.2. Le pipeline de codage devient le pipeline de correction de bug

Plus tard, dans un projet, après que tous les éléments de travail ont été accomplies, le pipeline de codage continue. Quoi
changements est que, au lieu d'éléments de travail, le pipeline est rempli de bugs / défauts à fixer. Dans le chapitre
15 , nous parlerons de cela quand nous couvrons triagethe processus décisionnel sur la façon dont les bugs devraient être
manipulés.

14.3.3. Le suivi des progrès

Le tableau de bord simple pour suivre les progrès à mi-jeu est la liste des éléments de travail: jusqu'à ce que chaque prévu
élément de travail est terminé (au niveau approprié de la qualité), mi-jeu est fini (voir Figure 14-5 ).
Toutes les stratégies mi-jeu impliquent la compréhension de l'état du projet, garder l'équipe sur
la bonne voie, et remettre les choses en place pour une fin de jeu réussie. Le score d'éléments de travail complétés
sont les données les plus essentiels pour la fabrication de ces déterminations.

Figure 14-5. Mi-jeu est pas fini jusqu'à ce que tous les éléments de travail sont prévues
complète. Seulement alors ne commence fin de jeu. Tout ce qui n'a pas d'incidence
le taux d'achèvement des éléments de travail ne doit jamais primer sur
les choses qui le font.

Je recommande d'utiliser une vue très simple du projet, tel que celui montré dans la figure 14-5 , et
 rendant
complèteaussi visibleSi
par zone). à l'équipe
il ya un que possible
site Web (sur les
d'équipe, ungrands
résuméprojets, montrer
des progrès le pourcentage
élément de travail des éléments
devrait être de travail
affichée bien en vue, et mis à jour quotidiennement. Placer un grand tableau dans le couloir principal pour le
équipe, et placer un tableau semblable il ainsi. Chaque réunion d'état hebdomadaire ou grande réunion de l'équipe
devrait commencer par un examen rapide de l'état de grand-équipe. Parce que les éléments de travail devraient être achevés en
un à trois jours, un tableau comme Figure 14-5 fera état ​de progrès sur une base quasi quotidienne. Les gens devraient
être encouragés à y aller régulièrement, et de découvrir ce qui a été vérifié dans récemment et ce qui est
venant bientôt.

Les données secondaires sur le statut, comme jours par élément de travail restants, les jours de travail restant par
programmeur, etc., devrait bien sûr être suivis. Mais ne permettent pas que les données obscurcir la vue simple.
Au cours de la mi-jeu, il est beaucoup plus important de fournir des moyens pour l'équipe pour obtenir un sens holistique
de la façon dont le projet est en cours. Les personnes ont souvent un sens de leurs zones locales et toutes les zones

Page 260

ils entrent en contact avec dans leur travail quotidien.

Il ya certainement plus à savoir sur le suivi des progrès de manière efficace. Je vais couvrir cette question en profondeur dans le prochain
chapitre, où les punaises et les tendances deviennent d'une importance cruciale.
Page 261

14.4. Frapper des cibles mobiles

"Pas de bataille fut jamais gagné selon le plan, mais aucune bataille n'a jamais été gagnée sans un."

Dwight D. Eisenhower

Un des arguments les plus forts pour les courts cycles de développement de XP et d'autres méthodes est que
directions changent tout le temps. En utilisant les cycles de développement courts, le projet peut répondre aux majeure
direction change sans jeter l'équilibre entre le travail, et tout effort de planification ou de conception peut
se concentrer sur le court terme tangible. Cela rend tout grand sens pour moi, tout comme l'attitude sous-jacente
de viser victoires cohérentes à court terme. Mais il est une vérité supplémentaire: plans à long terme, même si
ils sont rugueux, aura tendance à faire des changements à court et à moyen terme plus facile.

La raison en est que, au moment où un changement dans les objectifs, les exigences, ou de la conception produit, le
plan original est rarement jeté dans son intégralité. Au lieu de cela, les changements (aka deltas) sont faites par rapport
une certaine idée de base de ce que le projet allait être jusqu'à ce que la nouvelle modification a été apportée. Le plus
précise que le plan original était, même si elle était un plan rugueux, plus un point de référence, il peut
être et plus vite ces ajustements peuvent être faits. Ce que cela signifie est que la meilleure assurance
contre la volatilité des choses changement est d'avoir un plan réalisable dès le départ que vous pouvez régler
comme vous allez.

"Eh bien, à mon avis, une bataille ne fonctionne jamais comme prévu. Le plan est seulement une
base commune pour des changements. Il est très important que tout le monde doit connaître le plan,
de sorte que vous pouvez changer facilement ... la bataille moderne est très fluide, et vous avez à faire
vos décisions très fastand surtout pas selon le plan. Mais au moins, tout le monde
sait où vous voulez en venir, et [alors] où vous allez, plus ou moins ".

Major-général Dan Laner, commandant des Forces de défense israéliennes

L'astuce dans l'utilisation de plans où l'on prévoit des objectifs à se déplacer est de ne jamais permettre à de longues périodes de temps à
passer sans mise à jour du plan. Si vous pouvez trouver les bons intervalles, des cibles mobiles ne se déplacent pas vraiment
bien tout à la fois: ils suivent tout simplement dans une certaine direction à une certaine vitesse à un certain moment. Si
vous avez plusieurs étapes ou phases de votre projet (voir chapitre 2 ), ce sont vos naturelle
intervalles pour faire des ajustements (et si nouveau temps de conception est prévue dans chacune de ces phases, vous
peut revoir les choses dans le premier jalon qui doivent être changé). Même au sein d'une à trois ou six
semaine étape, vous pouvez trouver un ou deux milieux de réévaluer la trajectoire du projet par rapport à
des objectifs ou des exigences qui pourraient avoir changé. Pour cette raison, la longueur des étapes devrait
correspondent à la volatilité: la plus volatile de la direction, plus la longueur d'étape.

Figure 14-6 montre un exemple simple de faire des ajustements pour aligner avec les objectifs en mouvement. Le projet
commence à un, et est censé se terminer à B. Si deux semaines après le projet (peut-être la réalisation d'un
courte étape) chefs d'équipe conviennent que les objectifs pour B ont changé, le projet doit être décalée
de continuer à aligner B. Deux semaines encore, plus des ajustements sont faits, et un nouveau cours
correction a lieu. Certains travaux pourraient être jetés, mais moins de travail sera perdu à régler
direction plus tôt que dans l'ajustement direction tard. Si ces mouvements coïncident avec la fin / début
des étapes, l'équipe a le temps de faire un peu de travail de conception pour compenser les modifications, ajouter des travaux
articles de modifier les travaux antérieurs, et faire les ajustements dans la foulée.

Figure 14-6. Objectifs, exigences et contraintes vont changer, mais si le

vitesse et la direction sont comprises, et les étapes intermédiaires sont prises pour
suivi des changements, le changement peut être géré.

Page 262
 Même sans pauses d'étapes appropriées, le pipeline de codage peut aider à rendre ces mi-parcours
ajustements contrôlables pour l'équipe de développement. Parce que ces changements de cap se produisent dans le
pipeline en face de l'équipe de programmation, il ya un tampon pour que les changements se produisent. Le plus de plomb
temps dans le pipeline (voir Figure 14-7 ), plus il ya de tampon. En supposant, bien entendu, qu'il existe
quelqu'un (PM ou programmeur en chef) avec le temps de gérer le pipeline, l'équipe n'a pas à
venir à un décrochage complet pour faire des changements de direction. Il faut juste être assez (de la droite)
travailler dans le pipeline.

Figure 14-7. Chaque plan a une zone de couverture pour combien il variance
peut supporter. La plus large ou plus perspicace (prédictif d'une éventuelle
changer) le plan est, plus l'angle de la couverture.

Toutefois, cela ne suppose que les changements ne sont pas radicalement loin du plan initial: une donnée
effort de planification ne fournit que tant d'habileté pour le mouvement (voir Figure 14-7 ). Si la nouvelle
exigences ou objectifs croisent un certain point, de nouveaux travaux de conception majeur et d'exploration devront
à faire qui va au-delà de combien de temps plomb les supports du pipeline de codage (ou, dans certains cas,
combien de temps la conception est prévue pour la prochaine étape). Par exemple, si le plan initial était de
faire un four grille-pain, il pourrait être possible d'ajuster le projet au cours de la mi-jeu pour le rendre dans une
de taille moyenne ovenbut pas un accélérateur de particules ou un pétrolier.

Dans la figure 14-7 , un modèle rugueuse montre combien la variance a un projet; représente la région la
espace de changements que l'effort de planification a permis à une équipe de se remettre de sans grande nouvelle
travail. Un schéma similaire pourrait être établi au niveau micro pour chaque poste de travail. En fonction de la
L'approche de programmeur, son plan aura différents niveaux de couverture pour les besoins / conception
des modifications à ce projet de travail.

Il ya une chose à propos de maladroit Figure 14-7 à noter. Il représente un progrès chronologique

Page 263

verticalement, ce qui implique que la zone de couverture fournit plus de possibilités pour se déplacer dans le temps,
ce qui est faux. Une façon plus précise à penser de la zone de couverture est qu'il change le
projet fait, la croissance et le rétrécissement en fonction de ce que l'état du projet est. En général, l'espace
de la couverture se rétrécit au fil du temps que les éléments de travail sont terminées. Mais chaque mouvement fait les changements
plan efficace, et avec elle, la couverture de mouvement possible avenir.

14.4.1. Faire face à la gestion de mystère

Le bon fonctionnement des projets dans des entreprises saines, la plupart des changements de haut niveau sont chronométrés avec
jalons du projet (parce que, encore une fois, la longueur des étapes correspond à peu près à la volatilité des
le projet ou l'organisation). Gestion a la patience et de maturité pour attendre une phase est hors
avant de forcer l'équipe à réinitialiser et réajuster. Mais même dans ces organisations, il peut y avoir
directives de gestion qui forcent le changement à se produire à mi-parcours, sans beaucoup de temps de montée jusqu'à
préparer pour eux.

La plupart du temps, il ya plus de grondements de la gestion, le client, ou des raisons de concurrence à faire
corrections de cours que les décisions réelles à changer de cap. Parfois, il est dans votre propre pouvoir de
faire l'appel à changer les directions, et d'autres fois, vous avez simplement à attendre que quelqu'un d'autre de décider.
Dans les deux cas, une partie de votre pensée doit inclure un plan approximatif pour ce que vous feriez si l'menacé
changement devient réel. Avant de grandes décisions viennent de la gestion, ou les concurrents prennent le virage à droite,
une écriture sur le mur se trouve généralement dans les jours ou semaines advanceif vous cherchez pour elle. Tu
dépendent de vos relations et les compétences politiques pour obtenir l'information dont vous avez besoin pour prévenir
votre projet d'être pris au dépourvu. Il ne peut pas toujours être évitée, mais parfois il peut.

En utilisant les informations que vous avez, prendre régulièrement votre meilleure estimation à ce que le changement de direction pourrait
être (Soutien à une certaine technologie? Une nouvelle fonctionnalité? Un nouvel objectif?), et esquisser ce
les ajustements que vous aurez besoin pour y arriver. Cela peut être par exemple très roughfor, ayant une brève conversation
avec un programmeur en chef sur ce qui pourrait être impliqué. "Fred, qu'aurions-nous faire pour soutenir
 l'API 2.0 mettre
un certain enceplus
sens de quedecette
ceuxroute
que va
nous utilisons devrait
ressembler déjà? "Votre butvotre
vous et est pas un nouveau
équipe devez leplan de bataille,
prendre. Examineril est
deayant
nouveau
votre liste de priorités pour les éléments de travail (voir chapitre 13 ) et de voir si vous avez déjà fait une réflexion
sur le nouveau travail que vous pourriez avoir à prendre.

14.4.1.1 Explorer l'impact du changement

Si la probabilité de ce changement devient élevée, vous pouvez ajuster le travail dans le pipeline de codage
mieux vous préparer à ces changements. Dans la stratégie d'échecs, il ya au moins deux façons différentes à
planifier un déménagement:

1. Conservateur . Rechercher des mouvements qui vous donnent le plus grand nombre de mouvements futurs et que
laisser vos options ouvertes.

2. Agressif . Faites le plein engagement à une ligne de la stratégie que vous voyez clairement et forcer le jeu
sur votre adversaire.

Sur des projets (ou échecs), quand vous êtes confiant et sentez plus fort que l'adversaire (c.-à-mystère
la gestion ou la compétition), agressif est le chemin à parcourir. Quand les choses sont incertaines ou vous
sont surpassés, conservateur tend à être meilleur. Raconter votre équipe à penser conservatrice peut ralentir
les légèrement, mais tel est le prix de l'assurance que vous achetez. Parfois, être agressif
forces d'autres de prendre des décisions, et si vous êtes indifférent au résultat, mais besoin d'une décision rapide,
décisions agressifs peuvent travailler en votre faveur, même si vous êtes dans une position politique faible.

Mais remarquez que, compte tenu des ajustements ne signifie pas toujours le temps de développement supplémentaire ou réduire
la qualité du code. Il pourrait y avoir un autre algorithme qui est tout aussi fiable mais plus souple dans un
de façon importante. Il suffit de demander le programmeur ou l'équipe:. "Regardez les gars, je crains que notre
client / VP va nous forcer à soutenir un schéma de base de données différente. Jetez un oeil à ce que vous êtes
faire, et si il ya des moyens faciles et intelligents pour se préparer à ce changement que vous faites votre travail,

Page 264

faire en sorte. Mais ne faites pas de changements majeurs, et la qualité des sacrifices, pour cette raison. Compris? "

Parfois, cela est impossible: il pourrait prendre des heures de l'enquête de répondre à cette question. Mais là
y a des cas où il sera simple. Par exemple, un programmeur peut avoir déjà
considéré que la direction ou avoir une opinion raisonnable fondée sur sa compréhension du code. À
préparer votre équipe de cette manière, il pourrait coûter rien de plus qu'une conversation de cinq minutes. Plus
importante, peut-être: mieux vous comprendre les coûts possibles du changement, le mieux votre
arguments seront pour opposer son veto à des changements (ou le cas échéant, pour les soutenir).

14.4.1.2 La portée potentielle du changement

A noter également que plus un projet arrive à la série originale (ou le dernier actif) des objectifs, plus il sera
être de réaliser des ajustements ou des changements de direction. Dans la figure 14-8 , le projet est officiellement
orientent vers B, mais il ya de fortes rumeurs d'un changement de direction (présentée comme un "?" dans la figure).
Le PM prend la meilleure estimation de ce que le changement sera et ajuste en conséquence. Il fait un
Plan léger avec ses programmeurs à comment ils pourraient réagir.

Figure 14-8. Si vous connaissez un changement est à venir, mais ne savez pas quand vous
peut encore suivre à votre meilleure estimation de ce que le changement sera.

Alors que le projet progresse, le changement de mystère continue d'être une rumeur. L'angle du changement
les changements que le projet se poursuit le long de B, devenant plus nette et plus risqué. Avec chaque ligne de code
écrite, le soutien de moins en moins peut être donnée à une éventuelle autre direction. Étant donné que les pouces de projets
plus proche de l'achèvement en B, la distance de la modification de mystère (appelé la portée du changement dans la figure
14-8 ) obtiendra plus, par rapport à la distance restant à B. Le plus de l'équipe attend de faire
 changements alors que le projet est en mouvement, plus les coûts ont tendance à être.
Si le changement se produit, et vos efforts de prévision n'a pas payé, vous avez pas le choix: l'équipe
doit être réinitialisé. Si le changement est venu sans ressources supplémentaires temps, revenir à votre priorisation
listes et trouvez les articles que vous pouvez couper de vous acheter au moment où vous pensez que vous avez besoin (voir chapitre 11 ).

14.4.2. Gestion des modifications (changement de contrôle)

Certaines équipes de projet de contrôle et de suivre activement toute modification de conception qui exige un nouvel élément de travail ou
l'élimination d'un produit existant (cela commence après spécifications ont été formellement examiné). La crainte est
que si des changements de conception sont faites sans un processus impliqués, grands, les mauvaises décisions, les mauvais va se passer
sans les bonnes personnes sachant à ce sujet. Selon la culture et les objectifs de votre équipe, vous
pourrait ou ne pourrait pas besoin de faire cela. Comme Friedlein souligne, "La façon dont vous gérer le changement par le biais
le projet dépendra de ... la taille et la nature du projet. Généralement, le plus grand et plus

Page 265

le projet est complexe, et le plus rigide les spécifications, le plus étroitement que vous aurez à gérer
changer. "Si votre équipe ne vous embêtez pas avec un processus de spécification, il ne sera probablement pas la peine d'avoir un changement
a rien de processus eitherthere pour marquer deltas contre.

Cependant, même sur une équipe avec quelques processus formels, plus un projet est à l'achèvement, plus
sensible, il sera aux changements. Sans un processus en place pour communiquer, suivre et gérer
changements, il est difficile et frustrant de fermer la porte sur un projet. L'équipe est plus mature, la
plus tôt, il aura tendance à vouloir contrôler le changement. Il est pas nécessairement un processus de fin de jeu: il est juste que
que la fin du jeu approche, les risques à la hausse, de même que le désir de contrôler leur encontre.

La façon la plus simple de gérer le changement est une version super-maigre d'un processus de spécification. NASA
et Microsoft à la fois appeler cela un DCR, ou une demande de modification de conception. Autres noms communs pour elle sont ECR
(Demande de changement d'ingénierie), ECO (Engineering Change ordre), ou, plus simplement, CR (choisir
demande).

Le procédé le plus simple pour cela est la suivante:

1. Quelqu'un (PM) écrit un résumé de la changeincluding sa relation avec les objectifs du projet ou
requirementsthe besoin pour le changement, et une explication de la conception du changement soit
fabriqué. (Les points de bonus sont donnés pour identifier les risques possibles pour l'impact de la DCR sur le
projet.) Cela devrait être rarement plus d'une page ou deux. Un bug (ou toute autre méthode est utilisée pour
questions de suivi) devraient être créés pour suivre le DCR, et ce document doivent être attachés à
ce.

2. Le programmeur, testeur, et tous ceux affectés de manière significative par le changement doit contribuer à
le résumé DCR et acceptez que ce changement est nécessaire et conçu de manière appropriée.
Programmer fournit des estimations dev, et le testeur fournit des estimations de test (ou plan d'rude épreuve).

3. Le DCR est proposé à un petit groupe de chefs d'équipe (voir la section " équipe de guerre "dans le chapitre
15 ), ou le gestionnaire de groupe, qui donne une décision go / no-go sur le changement. Si le changement va
à travers, elle est traitée comme un élément de travail supplémentaire pour le projet, et le DCR est diffusé à la
équipe (et le poste de travail est assigné au programmeur approprié). Horaires et toute
la documentation du projet devrait être mis à jour pour refléter ce changement. Si elle est rejetée, le DCR rampe
dans le coin le plus proche de la salle, sanglotant de façon incontrôlable, jusqu'à ce qu'il disparaisse du projet
univers.

La dernière étape peut être ignorée si les équipes sont de petite taille et de l'autorité est fortement distribué. L'important
des gens se rencontrent, discutent des options, et de décider sur le changement. Mais si le changement va forcer le projet
à glisser, l'impact d'autres programmeurs, ou exiger des ressources supplémentaires, les chefs d'équipe doivent être
impliquer.

DCRs sont toujours plus chers que leurs estimations de programmation et de test. Ils ont inattendu
effets secondaires collatéraux sur le reste de l'équipe d'ingénierie, et ils provoquent le PM pour donner moins
attention à la conduite et d'autres activités déjà importantes. Parce que le travail de conception pour DCR est
fait en deux temps, la probabilité d'erreurs et de mauvais choix de conception est élevé. Il est commun pour un
DCR pour provoquer la nécessité d'autres DCR. Mon attitude générale envers eux est la suivante: il est préférable d'utiliser
courts cycles de dev avec les processus de conception solides et permettent quelques DCRs, que de planifier un calendrier qui
attend de nombreux changements DCR. Il devrait y avoir toutes les raisons pour les gens de l'équipe à vouloir
résoudre leurs problèmes de conception précoce et éviter le processus DCR.
Page 266

14.5. Résumé

Mi-jeu et de fin de jeu correspondent au milieu et à la fin du projet.

Si un jour le projet ne va pas bien, il est de votre devoir de comprendre ce qui ne va pas et de résoudre
ce. Répétez ce tout au long de la mi-match.

Les projets sont des systèmes non-linéaires complexes et ont une inertie importante. Si vous attendez pour voir aiguë
problèmes avant d'agir, vous sera trop tard et peuvent faire empirer les choses.

Lorsque votre projet est hors de contrôle, vous prenez l'avion derrière le plan, ce qui est un mauvais endroit pour être.
Sanity vérification est la meilleure façon de rester en avant de l'avion. Il ya à la fois tactique et
contrôles de validité stratégiques.

Considérez comment prendre des mesures pour corriger la situation de la manière la plus sûre possible. Plus la
l'action, et de l'autre le long du projet est, les plus dangereux sont les actions.

Le pipeline de codage est de savoir comment les éléments de travail sont gérés en cours d'exécution. Il y a
façons agressives et conservateurs pour gérer le pipeline.

Planification basée Milestone et le pipeline de codage offrent des possibilités de faire route sûre
corrections projets.

Changement de contrôle (DCR) est de savoir comment vous étrangler le taux de variation moyen et de bas niveau sur un
projet.

Page 267

Chapitre Quinze. La stratégie de fin de jeu

 Continuant à partir de la couverture de dernier chapitre de la stratégie à mi-jeu, ce chapitre mettra l'accent sur
dates frapper et délais, ainsi que les outils à utiliser pour la conduite des projets à terminer à temps.

Il est facile d'oublier, mais tous les projets ont plus d'une date limite. Il ya toujours des dates intermédiaires et
échéanciers qui mènent à l'étape ou les dates de fin de projet. Cela signifie que si votre équipe fait
un effort extraordinaire pour relever avec succès une date limite, et un autre délai attend à l'horizon,
il ya des risques cachés dans l'équipe poussant trop dur pour répondre à la première. Si un effort considérable est
nécessaire pour répondre à cette première date, et l'équipe commence sur le prochain épuisé, stressé, et
frustré, la probabilité d'atteindre avec succès les baisses limites suivantes. Vince Lombardi
a dit une fois que la fatigue fait de nous tous des lâches. Quand nous sommes épuisés, aucune quantité de caféine peut
nous faire les mêmes personnes que nous sommes dans de meilleures circonstances.

"Comment vous jouez une note est tout aussi important que ce que la note est."

Henry Kaiser

Quand une équipe est poussé très fort, il va prendre des jours ou des semaines pour se remettre au même niveau de
performances prédit dans les estimations de travail de l'équipe (voir Figure 15-1 ). Pire encore, le plus souvent
l'équipe est poussé de cette façon, moins sensible il beburnout est le point où la récupération est pas
plus possible dans un délai utile.

Figure 15-1. Vous payez un prix pour écraser de frapper une date dans la probabilité de
frapper la suivante. Un gros effort de frapper Milestone 1 forcera Milestone 2 à
commencer dans le trou.

Page 268

Au niveau du projet, il est préférable de penser à la productivité de l'équipe en tant que somme nulle (1) ressource: si vous avez besoin
des efforts extraordinaires pour répondre à une date, réalisent vous volez ces efforts depuis le début des parties de la
phase suivante. (Cependant, si l'équipe a des rôles spécialisés, il est possible de minimiser ce par compensation
responsabilités. Le moment crucial pour les concepteurs, planificateurs, PMS, testeurs et programmeurs souvent
se produit à différents moments du projet. Si le travail est réparti correctement, toute l'équipe est jamais
également croqué, avec différents rôles transportant plus de la charge à des moments différents.)

Pire encore, il ya un taux d'intérêt à payer: le ratio de temps de récupération à croquer effort est pas 1: 1. Cela prend
plus de temps pour récupérer que d'en donner l'effort supplémentaire intense (par exemple, il peut prendre seulement 20 secondes
pour le sprint pour attraper le train, mais cela peut prendre une minute ou plus pour reprendre votre souffle nouveau).
Parfois, le prix est de sacrifier des vies personnelles ou familiales de personnes, ce qui est pas dans le long terme
intérêt de l'individu, une équipe ou l'organisation (voir Figure 15-1 ).

Cela signifie que la bonne gestion devrait éviter ces grandes poussées. Il est impossible d'éviter certains
pointes sur un projet d'envergure, mais il est dans l'intérêt des gestionnaires pour les contrôler attentivement, travaux
 préventivement pour les minimiser, et de comprendre les véritables coûts quand ils surface (autrement dit, ne pas blâmer
l'équipe de deux semaines dans la prochaine étape pour être lent et grincheux). Le plus du projet,
plus l'énergie l'équipe perd de ces pointes et la fin du jeu vrai plus difficile d'un
projet multi-étape devient.

Page 269

15.1. Big délais sont juste quelques petits délais

Pour discuter des aspects importants de la stratégie à moyen et à la fin du jeu, nous avons besoin de définir plusieurs intérimaire
dates qui se produisent sur des projets. Les trois dates provisoires les plus élémentaires, dans un calendrier plain vanilla,
correspondent aux croisements entre la règle approximative de tiers décrits dans le chapitre 2 (voir Figure 15-
2 ). Chaque point de croisement représente un changement d'orientation pour l'équipe, et il devrait avoir sa propre sortie
critères.

Figure 15-2. Dans les étapes, il ya des dates clés qui devraient être
suivi, ciblée, et compte tenu des critères de sortie.

Les critères de sortie sont votre liste de choses que l'étape était censé accomplir. Ils décrivent
quel état le projet doit être pour compléter une étape. Les critères précédents de sortie sont définis, la
plus les chances sont que le jalon sera terminé à temps.

Les trois points de croisement clés de toute étape sont:

Conception complète / spec complète . L'équipe est prête à écrire du code de production. Tous
spécifications, des prototypes ou des mémoires de conception nécessaires pour commencer la mise en œuvre sont finis. (Note
que ce ne demande pas pour tous les specs pour être terminé, seulement celles jugées nécessaires pour commencer
 mise en oeuvre. Ce pourrait être de 20% ou 90% d'entre eux.) Le travail de conception peut continuer (voir le
section « Le pipeline de codage "dans le chapitre 14 ), et des itérations et des révisions peuvent se produire, mais une
pourcentage ou le noyau de celui-ci acceptable a été achevée.

Terminer la fonction . L'équipe est prête à mettre l'accent sur ​le raffinement et l'assurance qualité. Ce
signifie que toutes les fonctionnalités fournies par les éléments de travail individuels a été achevée, et
le comportement et la conception nécessaires pour répondre aux exigences a été mis en œuvre. Il peut y avoir
les lacunes ou les problèmes de qualité, mais un leadership a mesuré ou les suivis (bogues font
exister), base des travaux de construction peut être considérée comme complète. Tous les tests ou les métriques de qualité définis
dans le cadre de la spécification devrait avoir des mesures en place. En ce jour, toutes les questions restantes
devrait être suivi que des bugs, et la base de données bug devient le primaire (sinon le seul) moyen de
suivre les progrès restant.

Test ou d'un jalon complète . Le jalon est terminé. Qualité et de raffinement ont atteint
les niveaux appropriés. La prochaine étape commence, et / ou les navires du projet. Ceci est parfois
appelé étape complète, car elle est la dernière phase de l'étape. Si elle est la seule ou la dernière
étape, le projet est terminé.

Au-delà de la qualité des spécifications, des estimations de travail, et l'équipe elle-même, la règle la plus simple de
pouce pour les dates frappant est que les meilleures sont vos critères de sortie, les meilleures sont vos chances. (2) Jusqu'à la

Page 270

les critères sont remplis, l'équipe est prévu de continuer à travailler. Toute date importante dans votre calendrier doit
avoir un certain ensemble de critères de sortie définis pour elle.

15.1.1. Définir les critères de sortie

Les critères de sortie ne doivent pas être complexe (bien qu'ils puissent être). Cependant, ils ne doivent inclure
ces articles:

La liste des éléments de travail pour être complété

Une définition de la qualité de ces choses doivent être complété à (peut-être dérivé de l'essai
cas, plans de test, (3) et les spécifications)

La liste des choses que les gens pourraient penser besoin d'être fait, mais ne pas réellement besoin d'être
terminé

Choses que les gens ne devraient jamais, jamais penser doivent être faites (vérification de cohérence)

Il ya plusieurs façons à la fois de définir des critères de sortie et de communiquer et de les suivre avec une équipe.
Les détails de la façon dont ils sont faits ne sont pas si important (les proposer à l'équipe, prendre des commentaires, puis
finaliser et communiquer largement). Ce qui importe est que ils ont terminé au début, rester simples, et
utilisée publiquement pour suivre les progrès et orienter les décisions. Les critères de sortie doivent carte Retour à la vision et
objectifs, et ils devraient être la façon la plus utile d'appliquer la vision et des objectifs pour les questions et
défis à relever dans les parties médianes et de fin de jalons.

Les critères de sortie communs incluent:

Listes spécifications / dessins / travail-point est achevé . Ceci est utile seulement pour la conception
achèvement. Quoi outils ou de processus utilisé pour faire le travail de conception devrait avoir correspondant
les critères de sortie de conclure design. Peut-être qu'il est de 90% de toutes les spécifications en revue, ou il est un
prototype avec un certain ensemble de fonctionnalités de travail.

Éléments de travail réelles accomplies . Cela devrait être la liste des éléments de travail défini au début
de l'étape ou phase du projet. Lorsque les éléments de travail sont terminées à la spécification,
la phase / étape est terminée.

nombre de bugs à certains niveaux . Comme nous le verrons plus tard, il ya beaucoup de façons différentes pour suivre
et mesurer bugs / défauts. Généralement, les critères de sortie impliquant bogues spécifient la quantité autorisée
de bogues actifs d'un certain type.

Passer les cas de test spécifiées . Il peut y avoir un ensemble de conditions d'essai qui sont utilisés pour déterminer
lorsque l'étape est terminée. Si les cas de test sont utilisés comme critères, ils chasseront les décisions
pour lesquels bugs / défauts doivent être fixés avant le jalon peut finir. Il peut être suffisant d'utiliser
les critères de sortie à seuil définies par les cas de tests, tels que "80% des cas de test pour la priorité 1
scénarios doivent être adoptées. "

Performances ou la fiabilité métriques . Si l'équipe est la mesure de la performance de certains

composants (par exemple, une base de données ou d'un moteur de recherche), il pourrait y avoir des critères de sortie basés sur ceux
numéros. Si le critère de sortie est une amélioration de la vitesse de 10% par rapport à la version précédente, le
jalon est pas fini jusqu'à ce que cette augmentation de 10% a été atteint.

Temps ou d'argent . Le temps est le critère le plus simple de sortie dans le monde entier. Quand une certaine quantité de
temps est révolu, l'étape est terminée. Fin de l'histoire. Mois de faire de belles étapes parce que
il n'y a jamais eu de doute sur le moment où ils commencent, quand ils finissent, ou combien de temps est en eux.
(Les gens utilisent des semaines et des mois pour suivre le reste de leur vie, alors pourquoi ne pas projet de base
horaires sur eux ainsi?) Demi caractéristiques partiellement réalisés sont coupés et pris en compte dans la prochaine
jalon (si il y en a un). L'argent peut également être un critère de sortie: lorsque le budget est dépensé, et
 l'alimentation est coupée, vous vous arrêtez.

Sans critères de sortie, l'équipe doit dépendre de leurs opinions subjectives de ce "assez bon"

Page 271

des moyens pour un projet, qui est une énorme perte de temps. Tout le monde va avoir des opinions différentes
sur ce qui est assez bon. Même si une personne est donné le pouvoir de prendre cette décision, il sera
toujours controversée moins que quelque chose est écrit. Sans critères, les équipes sont obligées d'avoir
débats difficiles fin à un projet lorsque le stress et les risques sont élevés. Evitez de placer votre équipe dans un
situation où l'énergie doit être gaspillé à la fin de jalons argumenter sur les critères de sortie. Au lieu,
plan afin que vous pouvez utiliser toute l'énergie de l'équipe à la fin de jalons pour réellement répondre à la
critères.

Rappelez-vous que l'objectif est non seulement de frapper un jour, mais de frapper un jour avec le projet dans un état spécifique.
Le plus tôt l'équipe sait ce que l'Etat est, plus les chances sont que cela se produira. S'ils
savent dès le début quels sont les critères, toutes les décisions qu'ils font tout au long de l'étape reflétera
ce critère. Même si les critères changent en cours de route, l'équipe sera de réglage dans la même
les directions, la mise en place collectivement le projet pour une fin de jeu plus facile.

Une liste d'exemple de critères de sortie pour une étape sur un petit projet de Web pourrait être le suivant:

Éléments de travail complets 1-10 selon leurs spécifications

Rencontrez 80% des objectifs d'utilisabilité pour les zones prioritaires 1

Passer tous les tests prioritaires 1 automatisés et manuels

Passez 80% de tous les tests de priorité 2 automatisé

Triage tous les bogues actifs

Fixer tout de priorité 1 et 2 bugs

Obtenez signoff de l'équipe de marketing et d'affaires

15.1.2. Pourquoi les dates de frapper est comme les avions d'atterrissage

Avec des étapes intermédiaires, l'objectif est non seulement de frapper une certaine date, il est de mettre l'équipe en place pour la
étape suivante (ou libération). Frapper une date est plus qu'une question de la chronologie: en fonction de la façon dont
douceur vous frappez la date, la stabilité de code et la prochaine étape (si il existe) sont à risque.

Pensez à l'atterrissage d'un avion. Un bon atterrissage met l'avion dans une position qui le rend facile à prendre
repartir; par exemple, si les ailes sont encore attachés, le train d'atterrissage est opérationnel, et l'équipage
est encore en vie. Tout ce qui est nécessaire est plus de carburant, un plan de vol, et un sandwich pour le pilote. La fin de
jalons doivent être considérés de la même manière. Plus l'angle que vous prenez pour terminer un
jalon, plus les chances que le projet ne sera pas dans un bon état quand il complète le
jalon.

15.1.2.1 angle de descente

Les horaires les plus élémentaires pour les projets d'ingénierie peuvent être convertis en un tableau simple, comme celui
représenté sur la figure 15-3 . Ce tableau suppose que le taux de progression est constante, et que le projet
sera achevé exactement sur le calendrier en continuant à ce rythme constant. Ceci, bien sûr, est
monde imaginaire. Ce tableau ne sera jamais la carte de la réalité parce que le progrès et l'efficacité équipe ne sont jamais
constante (pour de nombreuses raisons décrites plus haut dans ce livre).

Figure 15-3. Ce calendrier est le plus marquant de base dans le monde, avec
hypothèses Fantasyland inclus.

Page 272
 Au lieu de cela, la plupart des projets se retrouvent dans la situation décrite dans la figure 15-4 . À un certain point sur ​le chemin de
la date cible, l'équipe réalise le travail ne va pas aussi vite que prévu. Ce pourrait être parce que la nouvelle
le travail a été introduite (voir la section « Gestion des changements (de commande de changement) "dans le chapitre 14 ) ou
parce que l'équipe n'a pas respecté ses estimations. Indépendamment de la façon dont il est arrivé, l'équipe fait face à une
choix: comment pouvons-nous faire jusqu'à la distance à la date de fin? Il n'y a que trois options:

1. Glissez le calendrier . Déplacez la date de fin de manière à refléter la nouvelle compréhension du taux de
descente.

2. Changer l'angle . D'une certaine manière vous convaincre que vous pouvez obtenir à l'équipe de faire plus de travail
plus vite pour rattraper l'écart dans le temps (par exemple, préparer crash). Vous pouvez essayer cela,
mais il y aura un prix à payer. Il y aura un plus grand risque d'erreurs, et l'équipe aura
lent et fatigué à partir du prochain cycle de travail.

3. Respecter la date avec ce que vous avez . Identifier les caractéristiques ou les éléments de travail qui ont le plus
travail ou risque restant. Soit couper ces caractéristiques, les reporter à la prochaine étape (si il
est un), ou laisser tomber la qualité et de les expédier comme ils sont (gulp).

Figure 15-4. Annexe réalité souvent en désaccord avec le plan. Comment

gérer cela dépend entièrement des critères de sortie.

La façon dont ce choix est fait devrait dépendre entièrement sur les critères de sortie. Ceci est exactement la situation
qui bénéficie le plus d'avoir une pensée claire sur ce que signifie pour une étape à la fin. Au lieu de
inventer critères maintenant, sous la contrainte d'un atterrissage difficile, tout ce que vous devez faire est de regarder en arrière et
ajuster les critères que vous avez faites il ya quelques semaines. La prise de décision dans des situations difficiles de fin de jeu
devient plus facile si il ya des critères de référence que l'équipe est déjà familier.

15.1.2.2 Pourquoi changer l'angle ne peut pas travailler

En utilisant l'analogie de l'avion à nouveau, changer l'angle pour adapter l'espace restant rend l'approche
instable. Projets, un peu comme les avions, ne contrôlent pas très bien lorsque leur vitesse de descente est élevé.
Il ya trop de choses qui doivent être faites simultanément pour que la vitesse se stabilise. Si vous

Page 273

étaient dans un avion approchant de la piste et a réalisé votre approche était éteint, vous souhaitez écartez et
faire une nouvelle approche (le déplacement de la piste, à la différence des dates de calendrier, est pas possible). Dans difficile
météo, les avions commerciaux redémarrent souvent leur approche. Toutefois, les projets peuvent rarement se permettre de
faire. Ils sont comme les avions qui sont à court de carburant: il ya suffisamment de ressources pour une seule
approche. Avec un seul coup, les pilotes sains font des approches très prudent et bien planifiés. Sain d'esprit
les gestionnaires de projet devraient emboîter le pas. Si votre date ou ensemble de fonctionnalités est immobile (comme une piste), vous
doit commencer à planifier pour l'atterrissage plus tôt.

15.1.3. Pourquoi il ya pire

Il ya un principe psychologique de base derrière la façon dont la plupart des gens vont sur la priorité de leur travail. Tous
choses étant égales, les gens auront tendance à éviter de faire des choses qu'ils ne veulent pas faire. (4) Cela signifie que
que le calendrier progresse, les éléments de travail restants ou corrections de bugs seront les tâches indésirables, tristes
de l'étape. Et même si le travail restant est ridiculement amusant à faire, si les équipes sont récompensés pour
les numéros de bogues qu'ils fixent en un jour ou une semaine, il ya une pression naturelle pour sélectionner les bugs de la
difficulté appropriée pour atteindre le quota.

A la fin des étapes, les gens ont tendance à être fatigués, frustrés, et qui conduisent à stressedconditions
une moins bonne performance. Bogues difficiles qui se situent entre régions ont tendance à circuler autour d'un développement
l'équipe à la fin de l'horaire (aka bug patate chaude). Un programmeur regarde un de ces bugs, réalise
il est une question difficile, et de sentir la pression de ses autres travaux, attribue le bogue à une autre personne qui
 pourrait en prendre
simplement la responsabilité.
circulent. Comme
"Même les meilleurs l'écrit Weinberg,
programmeurs «... lesces
souffrent problèmes
tentationsnenaturelles
sont pas résolus,
de tempsilsà autre.

La tendance principale de retarder le travail difficile applique également à la découverte de bugs bien que sa cause
est pas psychologique. Les défauts qui prennent plus de temps à trouver, ou qui apparaissent plus tard dans un calendrier, sera
naturellement tendance à être ceux qui sont plus compliqués (5) (comme indiqué dans la figure 15-5 ). Pour complexe,
mais des bugs de faible priorité, ce n'a pas grande importance, mais pour ceux de haute priorité, cette tendance est un grave
problème. Non seulement ces bugs prendre plus de temps que la moyenne à trouver, mais ils vont prendre plus de temps
moyenne de fixer. Les parcours en ligne droite présentés dans la figure 15-4 sont tous les deux tort: ​l'approche d'un
projet à une date est proche asymptotique (courbe) dans les résultats, et regarde de plus près à ce qui est montré dans la figure
15-6 . L'équipe peut travailler aussi dur qu'avant, mais les termes de resultsin de progrès vers
goalswill diminuer. Le plus vous êtes proche de votre jour, plus cela est vrai.

Figure 15-5. Bogues sévères ont tendance à être découvert ou fixe plus tard dans la
calendrier. Cela signifie que l'angle d'approche est pas une ligne droite, mais une
courbe pondérés contre le progrès (voir Figure 15-6 ).

Figure 15-6. Un tableau générique mais réaliste angle d'approche, en supposant une
niveau constant de l'effort de l'équipe.

Page 274

15.1.4. L'indicatif pour corriger angles d'approche

L'angle d'approche pour des jalons ou l'achèvement du projet ne sont pas un mystère. Comme tout autre
tâche liée ordonnancement (voir chapitre 2 ), il ya certaines considérations qui contribuent à la façon dont
précise un angle prédit sera. Voici les principaux facteurs à considérer:

Regardez le rendement passé pour l'équipe et pour le projet . Pour planifier l'angle, examiner
la façon dont l'équipe a fait en fin de jeu pour des projets précédents d'un type similaire. Le multi-
projets d'étape, regardent courbes d'étapes précédentes, prévue et réelle (ne pas tricher: utilisation
le plan original et le calendrier réel final). Supposons les choses seront plus difficiles sur le milestone
vous prévoyez que sur les précédents, en dépit de ce que vous pensez. Si vous avez pas de données pour fonder le
angle sur, ce qui vous fait penser que vous n'êtes pas juste deviner? Si vous devez deviner, deviner
conservatrice.

Avez estimations appropriées . L'angle est juste un autre type de tâche calendrier d'estimation. Obtenir le
personnes appropriées dans la salle, se cassent le travail restant en tâches, discuter des risques et
hypothèses, et arriver à des estimations. Si rien d'autre, ce qui fera de l'approche finale d'une équipe
effort, où les gens sentent qu'ils ont acheté dans le processus et défini l'angle ensemble.
Le moral va travailler à l'appui de l'angle, plutôt que contre l'angle.

Planifiez pour une courbe lente, pas une ligne droite . Même sans données, planifier sur le taux de progrès à
lent que les baisses de comptage de bug (voir Figure 15-6 ). Supposons que le travail va devenir plus difficile la
Plus vous vous rapprochez de votre date limite. Graphique et tableau avec des courbes qui descendent fortement vers la fin.
 Ne buvez pas l'Kool-Aid . Les graphiques sont faciles à faire. Vous pouvez mettre la ligne où vous voulez
sans aucune référence à la réalité, et vous pouvez peut-être même de convaincre les autres qu'il ya une
la logique derrière les lignes que vous avez tirées. Pensez à le pilote dans ce plan: voulez-vous voler dans cet angle
étant donné ce que vous savez? Levez le drapeau rouge; être le dénonciateur. Protégez votre équipe à partir d'un accident
atterrissage. Si votre approche est trop conservateur, le pire qui puisse arriver est que vous finirez
avance sur le calendrier, alors que si vous êtes trop agressif, toutes sortes de mauvaises choses vont arriver.

Faire une boîte noire . Si rien d'autre, assurez-vous que les données de performance réelle est capturé (voir la prochaine
section). Puis, après le crash, vous aurez la preuve de ce qui a mal tourné, et vous pouvez
faire un argument fort pour des ajustements dans le prochain projet ou d'un jalon.

Page 275

15.2. Éléments de mesure

Le suivi des progrès devient très important à la fois dans la mi-match et la fin du jeu. Le plus grand de l'équipe,
plus il est difficile de faire l'état de projet visible. Pour apporter des corrections ou des ajustements de cours
(Voir chapitre 14 ), vous devez avoir une compréhension claire de ce que déclarent le projet est à la fois à
diagnostiquer les symptômes et de prévoir comment le projet répondra aux ajustements.

Quel que soit les mesures que vous décidez d'utiliser doit être rendu visible à l'ensemble de l'équipe. Dans le chapitre
14 , je suggère que les éléments de travail sont mécanisme de suivi le plus important pour la mi-match. Ici,
nous irons plus loin dans d'autres mesures utiles pour la mi-match, mais concentrons sur le suivi pour la fin du jeu.

Pour la fin du jeu, vous pouvez réutiliser tous les tableaux de bord de projets précédemment utilisés; assurez-vous juste que le
mesure importante est donnée l'importance voulue (des mesures de chute qui ne portent pas beaucoup
signification plus, comme les éléments de travail). Le tableau de bord doit rester visible dans un couloir, et il
peut être aussi simple comme un grand tableau blanc que vous mettez à jour fréquemment ou aussi chic que un terminal dédié
(Idéalement situé à proximité des toilettes, salle de repos, ou d'autres zones à fort trafic) qui tire le
la plupart des données récentes provenant du réseau.

15.2.1. L'accumulation quotidienne

En faisant du projet construit chaque jour, vous forcez toutes sortes de questions à traiter dans le
présente, au lieu de les reporter dans le futur. Tout le monde peut regarder la version actuelle et de savoir
immédiatement ce que l'état d'avancement est. Vous pouvez compter sur les personnes de moins de rédiger des rapports d'état ou autre
busywork ennuyeux; à la place, vous pouvez toujours avoir une idée approximative en chargeant jusqu'à la version actuelle
et l'utilisation de fonctions ou caractéristiques particulières. Il peut être coûteux de maintenir une accumulation de tous les jours (et à
créer les outils nécessaires pour rendre possible (6) ), mais ça vaut le coût.

Avec constructions quotidiennes, les programmeurs (et toute l'équipe) sauront tout de suite quand un check-in a
endommagé d'autres composants, ce qui contribue à maintenir la qualité check-in élevé. Disposer d'un ensemble de cut-off time chaque
jour pour lorsque la construction sera traitée, qui met en place une base de code stable pour exécuter des tests contre la
confirmer la qualité de la construction. (Souvent, ces tests quotidiens sont appelés tests de fumée: une référence à
tester des composants électroniques, où les cartes de circuits seraient branchés pour voir si des pièces littéralement
fumé.) Après ce temps, check-ins dans l'arborescence des sources montrent tout simplement dans la prochaine génération.

Pour chaque version, il devrait y avoir une série de tests afin de déterminer la qualité de construction. Trois classements sont tout ce que vous
needgood: tous les tests passés; mixte: quelques tests passés; mauvaise: peu ou pas de tests réussis. Toute spécifique
bogues identifiés comme la cause de tout défaut de test devraient être affichés avec les informations de construction et
accordé une priorité élevée.

Ces tests build-qualité (aka construisent-vérification des tests, ou BVTS) devraient être sur le chemin de la sortie
critères pour le jalon. Dès le début de l'étape, ils pourraient être assouplies par rapport à la sortie
critères; par exemple, il peut être acceptable d'avoir une seule "bonne" construire une semaine. Mais comme l'équipe
approches disposent complète, les critères devraient augmenter. Avec quotidienne construit et tests de qualité, vous avez toujours
ont à la fois une mesure de qualité et un moyen d'étranglement qualité.

15.2.2. Bug / gestion des défauts

 Au fonctionnalité complète, le travail qui reste qui doit être fait avant la fin devrait être décalée
dans la base de données de bug. Ceci est de fournir un système de contrôle et de mesure pour le projet.
Le système utilisé pour suivre les bogues peut être simple, mais il doit y avoir un, et tout le monde doit l'utiliser. Si
certains programmeurs ont des systèmes de suivi des animaux pour leur travail, et ils sont tous différents, il est impossible
pour montrer tout contrôle au niveau du projet ou de la mesure sur les progrès. Souvent, quand les transitions de l'équipe

Page 276

sur fonctionnalité complète, quelqu'un doit harceler activement les gens à mettre des articles dans le système qui
ils ont été suivi sur leur propre.

Prenez l'habitude de demander: «Quel est le numéro de bogue pour cela?" chaque fois que des problèmes surgissent. Si ils disent
il n'y a pas un, fin à la conversation jusqu'à ce que le bug a un certain nombre. Cela peut sembler tyrannique, mais il est
dans le meilleur intérêt du projet. Les deux minutes nécessaires pour créer un certain nombre de bogues sont entièrement
intéressant du point de vue du niveau de projet. Il est bien pour les gens à suivre les choses de leur propre chef si le
question n'a pas d'impact sur la construction ou de la base de code; vous ne voulez pas que le système de bug à être embourbé
vers le bas avec des bugs qui sont des rappels personnels ou to-do list de type forum. (Ou si vous le permettez, assurez-
il ya un type de bug spécifique pour ce genre de choses, donc il peut être filtré dans les rapports et les requêtes.)

Pour référence, tous les bugs doivent avoir au moins les informations suivantes. Vous pouvez sauter cette section si vous
avoir un système de bug que vous êtes heureux avec. Il existe de nombreux types d'informations que vous pouvez
utilisent dans le suivi de bug, mais dans mon expérience, ce sont les attributs de base nécessaires pour efficacement
gérer les bugs:

Priorité . Conservez ce aussi simple que possible. Priorité 1 = doit fixer. Priorité 2 = Sera corrigé
opportuniste. Priorité 3 = Souhaitable, mais improbable. Priorité 4 = Comically improbable.

Gravité . Quelle est la gravité de l'impact du bogue? Gravité 1 = perte de données, crash du système, ou
problème de sécurité. Gravité 2 = fonctionnalité Major ne fonctionne pas comme prévu (spécifiée). Gravité 3
= Fonctionnalité mineure ne fonctionne pas comme prévu (spécifié). Gravité est distincte de priorité. Pour
par exemple, il peut y avoir une erreur de script navigateur écraser, ce qui est grave (Gravité 1), mais
car il se produit uniquement si vous tapez "PAPAYA!" sept fois, en majuscules, dans le domaine de messagerie sur un
page Web d'inscription, il est faible priorité (Gravité 1, mais la priorité 4).

Assigné à . Tous les bugs devraient être attribués à une seule personne. Nouveaux bugs peuvent être affectés à un
alias, mais une partie de l'objectif de triage (discuté prochainement) est de les assigner à un individu comme
dès que possible. Pour permettre bugs à être entré à partir alpha ou bêta de presse, de créer une valeur
appelé ou "la fête", "actif" qui bugs peuvent être assignés. Bugs assignés à cette valeur peut
être triage et donné à des personnes réelles tard.

Reproduction (aka repro) . La séquence d'actions qui permet à quelqu'un d'autre pour reproduire
l'insecte. Ceci est peut-être le domaine le plus important pour la qualité de bug. Bad cas de reproduction des déchets
le temps de l'équipe, forçant les programmeurs à investir plus d'énergie que devrait être nécessaire juste pour
comprendre ce que le bug est. Bons insectes ont repro étapes courtes et simples. (7)

Area . Pour les grands projets, les bugs devraient être classés par où ils se produisent dans le projet (la
région). Cela permet de bugs à être suivis par composante, et pas seulement par le développeur.

Ouverte par . Le nom de la personne qui a ouvert le bug, avec des informations de contact.

Statut.Un bug peut être que dans quatre Etats: actifs, fixes, résolus, ou fermées. Des moyens actifs de la
bug n'a pas encore été fixé et est toujours en place pour examen. Signifie que le programmeur fixe
croit qu'il a été fixé. Un bug devient résolu seulement lorsque la personne qui a ouvert la
bug accepte qu'il a été fixé, ou accepte de reporter. Fermé signifie que la vie de l'insecte est terminée,
et l'équipe de test a confirmé sa disparition.

Résolu que . Un bug résolu signifie qu'il est plus active. Un bug peut être résolu dans plusieurs
différentes façons: fixe, reporté à la prochaine étape ou de presse, double d'un bug existant,
ou ne sera pas fixe.

Type . Il ya deux types importants de bugs: les défauts et les régressions. Un défaut est un habitué,
plain-vieux bug. Une régression est un bug qui a été une fois fixé, mais maintenant est apparu à nouveau comme un
effet négatif de côté d'un autre changement.

Triage . Ce champ indique si le bogue a été triage et de ce que le résultat était. À

fois, les seuls les bogues qui doivent être fixés sont ceux qui ont été au triage et marqués
approuvé. Donc, ce champ a généralement trois états: approuvé, rejeté, ou d'enquêter.

Titre . Tous les bugs devraient avoir un titre d'une ligne décrivant le bug de telle sorte que un autre être humain
peut avoir l'idée de base de ce que le problème est.

Page 277

La plupart des systèmes de bug tracking offrent la connexion pour chaque bug. Cela permet de voir qui a fait
ce qui change à laquelle bug, et quand ils l'ont fait. Cela est très pratique si les décisions prises au sujet
bogues spécifiques sont contestés. Elle empêche également les gens de différents types de comportement trompeur dans la façon dont
bugs sont gérés.
 15.2.3. Le tableau de l'activité

Au niveau des projets, l'utilisation la plus efficace des bogues est de suivre les tendances dans leur découverte, l'évaluation,
et la résolution. En regardant les tendances à travers le projet, vous pouvez faire trois choses: mesure
progrès, mieux comprendre ce problème au niveau du projet pourraient exister, et de développer un sens de ce que
actions pourraient corriger ces problèmes.

Une fois que vous avez même une base de données de bugs simple, le piège est qu'il est très facile de générer de nombreux différents
types de graphiques et tendances et d'effectuer des types complexes de l'analyse. (8) Évitez la tentation d'obtenir
fancyit ya les types les plus élémentaires de tableaux qui comptent. Plus de questions et tendances de pointe peuvent être utiles
pour aider à répondre à des questions spécifiques, mais ils sont souvent les distractions («Regardez! Nos bug fix correspond de taux
à la pluviométrie taux en Espagne! "). Avant de perdre du temps à générer un nouveau type élaboré de rapport, poser
vous les questions suivantes:

1. Quelles sont les questions que nous pouvons répondre en regardant ce graphique?

2. Comment les réponses à ces questions nous aideront navire sur le temps, sur la qualité? Comment les réponses
nous aider à répondre aux critères particuliers de sortie ou les objectifs du projet?

3. Si le nombre augmente, ce que cela signifie vraiment? Vers le bas? Reste le même?

4. À la fin de chaque jour / semaine, ce sera nous aider à comprendre comment nous sommes beaucoup plus près de
achèvement?

15.2.3.1 Keep it simple

Les tendances les plus simples et les plus importants peuvent être suivis en utilisant un tableau de l'activité. Pour chaque jour de la
projet, les statistiques suivantes sont tirées de la base de données des bogues et affiche sous forme de graphiques en ligne:

Active . Le nombre total de bugs actifs qui ne sont pas fixes ou résolus.

Entrant . Le nombre total de bugs ouverte sur un jour donné (avant triage).

Fixe . Le nombre total de bugs fixés sur un jour donné.

Dans la figure 15-7 , vous pouvez voir les tendances de l'activité de base pour un projet de taille moyenne dans les premiers jours de final
jeu pour une étape. Il ya un grand nombre de bogues actifs et un taux relativement élevé entrant.
Vers le milieu du tableau (de gauche à droite), une passe de test majeur commence, et le bogue entrant
taux grimpe de façon spectaculaire (comme le nombre de bogues actif). Enfin, après la passe d'essai est terminée, le
taux fixe passe le taux entrant, et le nombre de bug actif commence à baisser. De ce simple tableau,
vous pouvez voir les relations de base: entrant par rapport fixe définit la tendance fondamentale de l'achèvement des travaux.

Figure 15-7. Un tableau de l'activité de bug de base.

Page 278

15.2.4. L'évaluation des tendances

 Tous les graphiques ou techniques d'analyse vous diront l'une des deux choses: il n'y a plus de travail à faire ou si il est
moins de travail à faire. Par exemple, si le nombre de bugs actifs continue à grimper, cela signifie que la pile de
travail croît plus vite que ça se vide, et de nouvelles questions sont encore trouvé à un rythme élevé.
Alternativement, si le compte est actif sur une tendance à la baisse, le travail est en cours d'achèvement plus rapide que nouvelle
problèmes sont découverts. Dans les deux cas, l'objectif de l'analyse des tendances est de comprendre, pour toute donnée
attribuer, laquelle des trois états les attributs sont:

Les choses empirent . Ceci est tout à fait acceptable, et même souhaitable, dans le test de détection précoce
phases d'un projet. Si les grands cols des tests sont actuellement en cours ou ont été récemment achevés,
il est naturel pour les comptages de bugs à la hausse beaucoup plus rapide que l'équipe de programmation peut gérer. (9)
Parfois, intégration de composants pourraient venir plus tard que prévu, forçant la découverte de bogue
se passer plus tard dans le processus que prévu. Ce qui est important est de comprendre pourquoi les choses sont
empirer, comment bien pire qu'ils obtiennent, et ce qui devrait être fait (si quelque chose) à
changer la tendance.

Les choses sont restées les mêmes . Parce que de vieux bogues sont corrigées et de nouvelles sont en cours de bogues
trouvé en même temps, il est tout à fait possible pour une équipe de comparaître à fouler l'eau, même si
beaucoup d'efforts sont en cours d'extension. Taux actifs pourraient se maintiennent même si les programmeurs sont
manivelle loin. Si jamais une mesure clé est en vol stationnaire, examiner ce que les entrées et sorties
contribuer à la mesure de comprendre ce qui doit arriver à tourner le coin et
quand cela se produira, ou ce qui doit être fait pour y arriver. Il est important de
communiquer à l'équipe. De nombreux programmeurs de panique quand ils sont loin parce démarrage
ils ne comprennent pas pourquoi le projet ne progresse pas (ou pire, pourquoi il est lentement en train de couler).

Les choses vont mieux . Lorsque les tendances deviennent favorables, il est important d'évaluer la
taux d'accélération et de la ligne de tendance à la fin de l'étape. Une tendance positive ne pourrait pas
être assez positif pour répondre aux critères de sortie. Si les tendances deviennent positives au début, se méfier:
ont toutes les passes de test été achevés? Y at-il des bugs untriaged? Est-bug qualité de positionnement haute? Faire
sûr que vous comprenez exactement ce qui cause la tendance à améliorer avant de supposer qu'il est
bonnes nouvelles.

15.2.5. Mesures de bogues utiles

Il ya quelques mesures communes qui prouvent utile pour le suivi de fin de jeu. Il vaut la peine de trouver un
façon de générer ces statistiques automatiquement de sorte que si elles sont nécessaires pour aider à prendre une décision, le temps
ne sera pas gaspillé la construction d'une nouvelle requête de base de données.

Page 279

Fixer taux . La vitesse à laquelle une équipe corrige des bugs est appelé le taux de correctifs. Parce que tous les bugs ne sont
égal, ce taux est le temps nécessaire pour corriger un bug de complexité moyenne. Si le taux de correction est derrière
le taux entrant et tous les bugs entrants doivent être fixés, le projet ne peut jamais expédier: il y aura
toujours plus de bugs.

Entrant Pour approuvé . Combien de nouveaux bogues ouvert réellement besoin d'être fixe et sont
pas des doublons d'autres insectes, ou de priorité 3 et 4 questions? (Le processus de fabrication de cette
détermination est appelé triage; plus de détails dans la section suivante.) Connaître l'entrant-to-
rapport triage permet de faire des estimations approximatives contre bogues untriaged. En règle générale, la qualité de bogue
devrait diminuer au fil du temps: après un point, le taux de bonnes, de viande, priorité 1 et 2 bugs va ralentir
puis déposez. Le taux brut entrant ne sera pas vous dire quand cela se passe.

Actif temps de bug . Délai moyen pour combien de temps bugs ont été actifs. Cela indique l'équipe de
la réactivité et la façon dont l'équipe gère sa charge de travail actuelle. temps de réponse devrait
augmenter à mesure que vous vous rapprochez de dates parce que l'équipe devrait être moins de bogues et gère
devrait être plus agressif au triage et d'attaquer les questions entrants. Si le temps de réponse est lente,
les gens sont occupés.

Bugs par développeur . Équilibrage de charge une équipe de développement nécessite le suivi combien actif
bogues chaque développeur est actuellement une enquête ou de travailler sur. Il est également intéressant de noter ce que
pourcentage de bogues actifs sont actuellement affectés aux testeurs, développeurs, ou GP. Bugs assigné
les GP ou testeurs ne sont pas actuellement dans le pipeline pour être fixé, et ils doivent être triés
et réaffecté périodiquement.

Défaut de rétroaction du rapport . Weinberg appelle le taux de régressions causée par un bogue fixer la faille
Ratio de rétroaction (FFR). (10) Si chaque bogue provoque fixé deux bugs supplémentaires, la FFR est de 2,0.
Selon Weinberg, un FFR de 0,1 à 0,3 est un taux acceptable de base; quoi que ce soit des moyens plus élevés
que la qualité doit être améliorée (et / ou le rythme doit être plus lent). La plupart des bases de données de bugs
permettre de nouvelles bogues être liée à celles qui existent déjà, ce qui permet de suivre la FFR. Cependant,
Je ne l'ai jamais vu ce automatedit de seulement jugés subjectivement par ceux qui effectuent l'échelle du projet
triage. (Notez que parfois fixer un bug peut provoquer des bugs précédemment à la surface. Ce cachée
ne devrait pas compter dans le FFR.)
Page 280

15.3. Eléments de contrôle

Contrôle des projets est beaucoup plus difficile que de les suivre. L'obtention de bonnes données et l'évaluation, il est un
qu'affaire de déduction, mais de trouver comment répondre aux tendances et d'influencer les oblige intuition.
Projets prennent sur leur propre dynamique, en particulier dans la fin du jeu, et ils ne peuvent pas être dirigés tant
sous l'influence. Lorsque l'activité est axée sur la collaboration avec des bugs, il ya beaucoup de particuliers
décisions prises dans l'équipe, et il exige une communication constante et des rappels à
garder les gens prennent ces décisions avec les mêmes attitudes, les hypothèses et les objectifs.

Le moyen le plus important de réfléchir sur les différents éléments de contrôle est de savoir comment ils sont souvent
appliqué. Pour certaines activités de haut niveau, tels que l'examen de la gestion, il est nécessaire d'effectuer la
l'action qu'une seule fois tous les mois. Pour d'autres, tels que le triage, il peut être une heure heure à-jour le jour ou
activité. Selon le degré de contrôle que vous avez besoin, ou le niveau d'influence que vous voulez avoir,
les intervalles de temps de contrôle sont votre considération la plus importante.

15.3.1. réunion d'examen

Ceci est principalement un mécanisme de contrôle de la mi-match. Un examen est lorsque les chefs d'équipe doivent présenter
l'état de leur projet, par rapport aux objectifs, à la haute direction, des clients, et de l'ensemble du
même équipe. La réunion d'examen devrait servir de fonction de forçage pour savoir ce qui va bien
(Par rapport aux objectifs), ce qui est pas, et ce qui est fait à ce sujet. Le format de l'examen peut
vraiment être aussi simple. Si ces questions sont répondues honnêtement, la discussion peut prendre une heure ou
Plus. Les meilleurs commentaires que je ont participé à coupe droite pour le noyau. Il y avait assez de maturité dans
la salle qui étaient oublis de bénévolat (non masqué), les demandes d'aide à l'honneur (pas ridiculisé),
et l'attention portée aux choses qui importait le plus (pas ce qui a fait les gens regardent bien ou se sentent
content).

La discussion d'examen devrait forcer l'équipe à évaluer les objectifs, les échéanciers, les technologies, et les rôles
réaliste. Rien ne doit être épargné pour un examen. Toute question qui se répercute sur le projet devrait être
ouvert à la discussion. Pour cette raison, la réunion d'examen est un élément de contrôle, et pas seulement
le suivi, car il fournit un forum pour les dirigeants et les cadres supérieurs pour discuter des ajustements qui
devront être faits portant sur un aspect du projet.

La qualité d'un examen dépend fortement de qui a le pouvoir sur le projet. Les meilleurs commentaires impliquent
discussion honnête sur ce qui se passe, avec un accent sur la compréhension des enjeux et le développement
solutions, au lieu de diriger et en esquivant blâmer. Pour cette raison, les réunions d'examen doivent être conservés
petite. Un résumé de la discussion, et des diapositives ou des matériaux utilisés dans la présentation, devrait être
présenté à toute l'équipe dans un forum séparé par la suite. (Les dirigeants devraient l'aise d'être
des comptes à leurs équipes, en particulier en ce qui concerne l'interaction avec la haute direction.)

Les équipes devraient avoir des examens prévus à intervalles réguliers au cours de chaque étape. Ce
devrait être la connaissance du public quand ils se produisent, comme une réunion de l'équipe devrait suivre. Multiple de mois
les projets doivent avoir un examen mensuel. Des projets de plusieurs semaines devraient avoir une revue hebdomadaire ou bihebdomadaire.
La plus fréquente qu'ils sont, plus informelle et rapide, ils peuvent être.
 15.3.1.1 avis client / client

Si vous êtes une équipe contractée, ou avoir des clients internes, des réunions d'examen peuvent servir comme un moyen d'obtenir
rétroaction directe de vos clients. La plupart des conseils vient d'être décrit est toujours valable. Une supplémentaire
point est que vous ne devriez jamais dépendre de ces réunions que la seule source de la rétroaction des
clients. Les intervalles entre les réunions seront toujours trop long, et la formalité de réunions
il peut être difficile d'aller très profond ou pour discuter de questions complexes.

Un aspect important de XP est qu'il encourage un représentant de la clientèle à participer

Page 281

directement dans le développement du logiciel ( Extreme Programming Explained , p. 69). Il ya tout

raison de demander au client de consacrer au moins une personne pour jouer ce rôle. Cette personne devrait utiliser
le quotidien construit et développer des relations avec les programmeurs et leurs dirigeants. Elle rend
possible pour vous et votre équipe pour obtenir des commentaires sur les questions sur une base journalière ou horaire, plutôt que
hebdomadaire ou mensuelle. Définir cette relation peut être difficile la première fois (voir la section « Définition
rôles "dans le chapitre 9 ), mais il sera toujours payer dans les décisions de projet intelligents et des clients satisfaits.

15.3.2. Triage

Tout processus où vous prenez une liste de questions et de les mettre en ordre de priorité est un processus de triage.
Ce qui rend réel le triage différent des autres types de priorités est que vous avez affaire à un
afflux constant de nouvelles questions qui doivent être compris et priorité contre tous les autres
préoccupations. Triage a lieu tout au long de la mi-jeu chaque fois qu'il ya une date intermédiaire qui doit
être touché et une métrique de qualité dans les critères de sortie. Toutefois, le triage devient une tâche principale de l'équipe
au cours de fin de jeu, consommant souvent un pourcentage significatif de travail quotidien pour les GP et les autres.

Le but de triage est de gérer le pipeline d'ingénierie (décrit dans le chapitre 14 ) d'une manière qui
maximise la valeur du travail accompli vers les critères de sortie pour l'étape. Faire cela
succès exige trois choses:

Désinfectez . Bogues entrants seront toujours varient en importance. Quelqu'un doit examiner de nouveaux bugs,
et obtenir l'information en eux à un niveau de qualité de telle sorte qu'il peut être affecté à un programmeur
et elle peut enquêter et réparer. Quelques bugs nécessitent une enquête de programmeur, mais la plupart
filtrage implique des choses triviales: remplissant les champs vides (la gravité, la priorité, etc.), l'amélioration de repro
cas, confirmant qu'il est pas un doublon d'un bug existant, etc. Ce travail est souvent juste gopher:
appels téléphoniques, de courriels et de temps avec l'accumulation spécifique pour traquer l'information.

Enquêter . Après bugs ont été désinfectés, il ya des questions plus profondes qui peuvent nécessiter
exploration avant que des décisions peut être faite. Devons-nous résoudre ce problème? Est-il contraire à l'esprit ou
lettre de l'exigence / spécification? Quel composant provoque ce problème, et ce serait
impliqué dans le fixant? Il peut y avoir un certain nombre de questions qui doivent être répondues avant un
bonne décision sur le sort d'un bug peut être faite. Certaines de ces considérations sont d'ordre technique,
d'autres non.

Prioriser . Après avoir été désinfectés et étudié, bugs peuvent être hiérarchisés et mis dans le
pipeline au niveau approprié d'importance.

Ce qui rend difficile le triage est que, pour faire l'une de ces trois choses exige bien plus de connaissances que
toute personne a. Le plus grand projet, moins il est probable que toute personne peut effectivement faire
triage seul. Donc, pour la plupart des équipes sur la plupart des projets, le triage est une activité de groupe. Dès le début, il pourrait être
bien pour les individus de triage leurs propres bogues, mais plus tard, l'accent sera mis sur les petits groupes et
sous-équipes. Ceci est la raison pour laquelle les bugs doivent être organisées autour des zones spécifiques du projet (voir le plus tôt
section « gestion Bug / défaut "). Il le rend facile pour les petits groupes de personnes responsables de cette
région de se réunir et de triage indépendamment du reste de l'équipe.

Plus tard, vers la fin de la fin du jeu, où chaque décision de bug est examiné, il devrait y avoir une
effort de triage pour l'ensemble du projet, et il doit être exécuté par un groupe restreint de chefs d'équipe (voir Figure
15-8 ; nous allons discuter de cela dans la prochaine section " de l'équipe de guerre "). Pour l'instant, il est important d'identifier le
deux types principaux de triage: quotidiens et dirigée.

Figure 15-8. Triage devient centralisée que fin-jeu progresse.

Page 282
 15.3.2.1 Quotidien / triage hebdomadaire

Triage quotidien est le processus de routine pour faire face aux nouveaux bogues et actifs. En fonction de la
timeline, ceci peut être fait une fois par semaine, une fois par jour ou une fois par heure. Le plus loin dans final
jeu, vous êtes, plus fréquemment le pouls de triage doit se produire.

Le but de triage quotidienne est simple: garder les choses sain d'esprit. L'équipe de programmation est le chemin critique pour
la fin de la partie du projet, et de triage est la seule façon d'assurer que leur pipeline est utilisé
de manière efficace. Chaque bug qui vient doit être désinfecté et comparé à la piscine existante de
bogues, de préférence avant qu'ils atterrissent sur la plaque un programmeur individuel.

Parfois, il vaut mieux (en termes d'efficacité de l'équipe) d'avoir une personne point de courir pour le triage quotidienne
pour chaque zone. En supposant que les programmeurs et testeurs d'accord sur les critères, une personne peut être
responsable de la désinfection nouveaux bugs, des doublons de marquage, et en ajustant les priorités des nouveaux bogues.
PMS sont de bons candidats pour ce, en supposant qu'ils sont assez technique pour comprendre les enjeux et
prendre des décisions de bugs de base.

Sinon, le triage devrait être fait dans une petite réunion avec des représentants de développement, de test,
et PM. Si d'autres experts sur le personnel sont neededsuch que le marketing, la conception ou usabilitythey peuvent être appelés
en tant que de besoin. Les réunions doivent être courts. Tout ce qui ne peut être résolu en quelques minutes devrait être
attribué à un programmeur pour enquêter.

Le champ de triage doit être réglé sur les bogues quand ils ont été triés. Cela donne à l'un des projets
vue supplémentaire des données de bugs, que vous pouvez ensuite séparer la quantité de bugs au triage (connu bon
bogues) du montant total des actifs bogues (bugs de qualité inconnue).

15.3.2.2 triage Réalisé

Réalisé triage est un effort concerté pour répondre à un objectif précis. Cela se fait en plus de triage par jour.
Réalisé triage est un contrôle, au niveau du projet, pour aider à avancer les choses et d'améliorer la
valeur des cartes de bugs et l'analyse des tendances. Voici quelques raisons communes pour le triage dirigé:

Lorsque le rapport de triage à-actifs est faible . Si il ya 500 bogues actifs et seulement 200 ont été
triage, il n'y a pas moyen de savoir la signification des 300 bogues restants. Ils pourraient tous être
priorité 1 plantage du système, ou ils pourraient tous être des doublons: vous avez aucune idée. Un triage dirigé
aurait pour objectif spécifique d'éliminer tous les bugs untriaged par un certain temps (de midi
demain). Si cela est un problème chronique pour une équipe, il devrait y avoir un objectif de pas actif
bogues untriaged âgés de plus d'un certain laps de temps (24 heures).

Lorsque les critères de sortie changent . Si les chefs d'équipe ou de gestion décident que les critères de sortie
doivent être ajustés, peut-être supprimer ou d'ajouter une condition, le triage est la seule façon d'amener
le projet en ligne avec ces changements. Il est courant d'utiliser de nouveaux critères de sortie comme un moyen de changer
l'angle de descente, l'élimination de certaines classes de bogues de la considération pour améliorer la
la sécurité de l'angle (mais réduire la qualité dans le processus).

Chiffres non fermées sont élevés . Quand un bug est corrigé, il doit être mis à l'état = résolu, et
attribué à la personne qui l'a ouvert pour vous assurer qu'il a été vraiment fixé. Certains pourcentage

Page 283

de ces bugs pourraient ne pas avoir été fixé correctement. Si ces bugs siègent comme non fermé, il ya un
poche de bogues qui doivent être corrigés qui ne sont pas signalés dans les chiffres de bogues actifs.
Selon le système de suivi des bogues, il peut y avoir d'autres endroits bogues peuvent se cacher. Périodiquement,
vous devez conduire l'équipe dans les débusquer.

15.3.3. équipe de Guerre

Comme un projet tire à sa fin, la répartition des pouvoirs a pour centraliser. Contrairement à la conception de fonction
et de la programmation, qui peut être distribué raisonnablement à travers une équipe, à la fin il n'y a pas
place à l'erreur. Toutes les décisions deviennent de plus en plus importante, avec de plus grands risques, ce qui signifie que plus
contrôles sont garantis. La terminologie Microsoft pour cette centralisation du contrôle est appelée équipe guerre
(Emprunté, je crois, le terme militaire salle de guerre , où les dirigeants se réunissent pour décider importante
problèmes). Un petit groupe de chefs d'équipe devient une branche exécutive dominante du pouvoir que les délais
approche. Sur de petites équipes, un changement officiel du pouvoir pourrait ne pas être nécessaire, mais à mi-taille et
de grandes équipes, ce changement est essentielle. Il soulève la barre sur toute prise de décision et fournit un forçage
 fonction à l'équipe que le jeu se termine.
La réunion de l'équipe de la guerre réelle est simple. Tout ce que vous avez besoin est une salle de conférence, un membre senior de
chaque membre du personnel (programmation, test, et PM ou d'autres pairs leaders, et peut-être le groupe de haut
gestionnaire), et un ordinateur relié à un grand écran afin que toute la salle puisse voir le bogue ou
question en cours de discussion. Pour une question de passer l'équipe de la guerre, les membres supérieurs doivent tous être d'accord (certaines équipes
opter pour une majorité des deux tiers ou des membres de l'équipe de la guerre donne un droit de veto). l'ordre du jour de l'équipe de guerre est décidé
chaque matin, et toute question peuvent être placés sur l'ordre du jour. Comme une cour de justice, ce qu'ils acceptent
ou refuser ensembles priorité pour le reste de l'équipe. réunions de l'équipe de guerre devraient être ouverts à l'équipe,
la priorité étant donnée aux personnes qui présenteront DCRs spécifiques (voir le chapitre précédent) ou
bogues proposées pour examen.

équipe de guerre devrait fixer une barre très haut. Toute personne se présentant à l'équipe de la guerre non préparée, ou manquant
les réponses aux questions de base (Quels sont les critères de sortie ne répond? Qu'est-ce régressions Serait-ce la cause?
Faites le programmeur et testeur deux d'accord que cela devrait être fixé?) Devrait être dit de partir et de
revenir quand il est prêt. le temps de l'équipe de guerre est précieux parce que le temps de l'équipe est précieux. Chaque
PM et programmeur doivent être très motivés pour avoir son histoire cloué et solide comme le roc avant
elle demande à l'approbation de l'équipe de la guerre. Cette pression crée une incitation naturelle pour l'ensemble de l'équipe de
réfléchir à des questions sur leur propre avant qu'ils choisissent de le porter à la guerre. (Mais attention: l'équipe la guerre
réunions peuvent être fortement chargés, et il ya beaucoup de chances pour épater la galerie et égocentrique
perte de temps. Il est au gestionnaire du groupe pour écraser ce genre de comportement tôt.)

L'équipe devrait avoir l'avertissement juste à propos de quoi et quand l'équipe de la guerre sera impliqué. En Figure
15-9 , certains la mise en scène de base est illustrée par ce que les choses doivent obtenir l'approbation de l'équipe de la guerre. L'objectif est d'avoir un
la centralisation progressive de l'autorité avec les dates publics lorsque ces changements se produisent. L'approbation de
DCR est souvent la première utilisation de l'équipe de la guerre parce que ceux-ci peuvent se produire dès le début, à la mi-match. Par la suite,
lorsque le nombre de bug doit être étroitement suivis, de l'approbation pour la mise bogues dans la programmation
pipelines changements à l'équipe de la guerre (bogues précédemment approuvés devraient être généralement de droits acquis en). Finalement,
dans les semaines de fermeture ou de jours, l'équipe de la guerre en revue tous les nouveaux bogues, et le contrôle du projet est efficace
centralisée.

Figure 15-9. l'équipe de guerre augmente dans autorité de fin de jeu progresse.

Page 284

réunions de l'équipe de la guerre peut commencer la semaine, mais ils devraient bientôt passer à une demi-heure par jour ou d'une heure
réunions. Il est à l'équipe de guerre pour assurer que ces réunions commencent et se terminent à temps (quelqu'un
devrait posséder clarifier l'ordre du jour avant la réunion). Si l'objectif est la prise de bonnes décisions
vers les critères et les objectifs de sortie, il est possible de revoir de nombreux DCRs et de triage de nombreux bugs dans 60,
sinon 30, minutes. Le secret est d'éviter de fin de jeu microgestion.

équipe de guerre n'a pas besoin de connaître les rouages ​de chaque bug ou chaque numéro. Au contraire, ils
seulement besoin d'assurer que les décisions prises sont dans le meilleur intérêt du projet, que le droit
des questions ont été bien posées et répondues, et que la barre de droite est réglé pour l'utilisation du reste
temps.
équipes
odieux, ildedevrait
guerreêtre
ne parviennent paspour
pris hors ligne à êtreêtre
avantageux lorsque
discuté avec les dirigeants
un membre ne parviennent
de l'équipe pasetà le
de la guerre, faire confianceil à leurs équipes. Si un problème est vraiment
lendemain,
devrait être ramené à une meilleure présentation.

Entre les objectifs du projet, les critères de sortie, les décisions de bugs priorité d'établissement, et des communications de l'équipe,
il ya beaucoup d'opportunités pour pousser faire à l'équipe décision. Parfois, l'équipe de la guerre
processus d'approbation peut être automatisée, avec des formulaires web permettant aux membres de l'équipe de la guerre d'approuver les articles
à distance sur leur propre temps. Soyez astucieux. Trouver des moyens d'éviter de faire l'équipe de la guerre un inutile ou
goulot d'étranglement involontaire.

En général, l'équipe des questions de guerre moins besoin pour gérer, mieux la haute direction du travail a
 fait dans la planification, l'exécution et menant l'équipe à travers le projet. Si les réunions de l'équipe de la guerre
régulièrement sont brutaux, des marathons de trois heures, le leadership a échoué dans une ou plusieurs manières, et il ya
leçons à tirer pour le prochain projet.

Page 285

15.4. La fin de la fin du jeu

La période de fermeture d'un projet d'ingénierie est un processus difficile et abrutissante. Jim McCarthy,
dans la dynamique de développement de logiciels (Microsoft Press, 1995), se réfère à elle comme travailler avec Jell-O.
Chaque fois que vous corriger un bug, vous êtes effectivement toucher le grand cube de Jell-O une fois de plus, et il
prend un certain temps pour elle d'arrêter de bouger et de se calmer. Les touches plus vous faites, plus la variance
il est dans la façon dont il secoue, et le plus complexe de l'interaction est parmi les ondulations de ceux
changements. Un site web ou d'un logiciel est essentiellement un vaste ensemble de déplacement fortement interconnecté
parties, et chaque fois que vous changez un, vous forcent toutes sortes de possibles nouvelles vagues de comportement par
ce. Mais contrairement Jell-O, avec le logiciel, il est pas facile de savoir quand la secousse a cessé. Code est pas
transparent. Il est seulement à travers des processus d'assurance de la qualité et l'examen manuel attentive de la
construit, que vous pouvez comprendre l'effet de ce que l'un peu de changement. (11)

Cela signifie que la véritable fin d'un projet est principalement un jeu d'attente. Des heures et des heures sont consacrées
examen des nouveaux rapports ou questions bugs et les examiner pour voir si elles répondent à la barre pour secouer
le Jell-O tout recommencer. Sur les grandes équipes, il est équipe de la guerre qui porte ce fardeau. Bien que le reste de
l'équipe devrait être scoutisme activement de nouvelles questions et en utilisant des dernières versions, chacun peut contribuer
pour le jeu d'attente d'une certaine façon.

Mais quand il ya un bug digne de secouer le Jell-O, tout se passe en pleine vitesse à nouveau. équipe de Guerre
passe par le processus de diriger l'équipe (ou, plus précisément, le programmeur) en
comprendre le problème assez bien pour faire un changement chirurgical. Ensuite, la suite de tests et
conditions doivent être exécuter à nouveau pour assurer que les choses sont exactement comme ils étaient avant, sauf pour le
petite chose minuscule qui devait être changé. Il est un processus très stressant. Contrairement au plein-sur charge de
mi-jeu, ou le plaisir de trouver des bugs dans le jeu de la fin précoce, le stress dans les derniers jours ne peut pas être soulagé
en se livrant à de grandes piles de travail. Tout est très faible, et la pression a nulle part où aller.

Il existe différentes mesures et des moments d'importance dans ce processus, mais ils ne font pas
de changer la nature du travail. Ils sont tout simplement les étapes intermédiaires sur le chemin de
libérant. Si rien d'autre, ces marqueurs briser la monotonie du travail stressant fin de fin de jeu.

Zéro bogue rebond . Lorsque le nombre de bogues active et approuvé (par l'équipe de la guerre) atteint zéro, le
équipe est dit avoir frappé zéro bug rebond (ZBB). Ceci est appelé un rebond parce que dès que la
prochaine bug arrive, l'équipe est plus à zéro bugs. Il ya quelques théories pour animaux de compagnie à la
distance entre ZBB et la libération réelle, mais aucun d'entre eux est assez fort pour être énumérées ici.

Zéro résolus . Les bogues résolus peuvent se cacher les problèmes de l'équipe ne connaît pas. Jusqu'à ce qu'il est
été fermé (et vérifié), il est pas certain qu'un bogue a été effectivement fixé dans la façon dont il était
censé être. Frapper zéro résolu et zéro actif désigne le projet est vraiment dans un état de
possible achèvement.

Bogues entrants et actives font pour les mesures pauvres à ce point parce qu'ils sont sous la
critères pour examen. Même si l'équipe étudie activement ces bugs, jusqu'à ce qu'ils soient
 apporté à l'équipe de la guerre, ils ont effectivement aucune incidence sur l'état d'avancement du projet.

15.4.1. La release candidate (RC)

La première version d'un projet qui a rempli tous les critères de sortie est appelée la release candidate. Aussitôt que
cette version est faite, un nouveau critère de sortie doit être ajouté: quels sont les problèmes trouvés dans cette build RC sera
justifier la création d'une seconde release candidate? Si il n'y a pas de critères, en supposant que la RC
construire passe tous les tests de vérification et d'assurance qualité, la compilation est calé sur le Web ou sur CD mis, et
livrés aux clients.

Si il ya un critère de RC défini, et le RC échoue ce critère, le processus de fin de jeu se répète. Guerre

Page 286

équipe décide de ce que l'enquête, la conception et la mise en œuvre devrait être fait, le changement est
approuvé et rendu, et le processus se répète.

Dans le monde du logiciel, en particulier le monde de cellophane, les CR sont chers. Il existe souvent
des tests et des procédures supplémentaires que la construction doit passer pour vérifier la configuration, la localisation,
l'image de marque, et d'autres questions. Pour le Web, tout dépend de la façon dont le projet intègre dans un autre
projets. Il peut y avoir un arbre similaire complexe de dépendances qui doit être géré.

15.4.2. Déploiement et opérations

Quand une version finale de RC est terminée, seule une partie de l'équipe arrive à célébrer. En fonction de la
nature du projet, une finale RC peut lancer une toute nouvelle série de travaux. Les équipes de test et d'assurance qualité
peut-être besoin d'aller à la vitesse supérieure pour évaluer les charges de serveur ou d'autres types de problèmes de capacité qui peut être
testé uniquement avec une version finale. Ces questions peuvent certainement être prévus pour, mais les tests ne peuvent pas commencer
jusqu'à ce que les morceaux sont en place.

La plupart des sites web ou des projets basés sur le Web en scène leurs rejets à travers une séquence de serveurs de test, où
différentes conditions et les travaux d'intégration sont donnés couverture de test final. Les plates-formes plus ou
langues le projet doit couvrir, le plus compliqué le processus de déploiement seront. Bien entendu, la
temps nécessaire pour le déploiement approprié peut être estimée et prévue pour lors de la planification initiale. Selon
sur la façon dont il est organisé, le fardeau de déploiement et des opérations pourrait être isolé à un sous-équipe ou
partagée entre l'équipe du projet.

15.4.3. Le post-mortem de projet

Comme l'achèvement d'un jalon ou un projet entier se rapproche, quelqu'un doit mettre en place l'équipe à apprendre de
ce qui a été fait juste. Ceci est souvent appelé à écrire une rétrospective ou post-mortem projet (en référence
le terme médical pour l'apprentissage de quelque chose qui a pris fin). La partie la plus difficile de le faire est que vous
vouloir capturer des informations quand il est encore frais dans l'esprit des gens, mais quand les gens sont
prêt à célébrer et envelopper les choses, ils veulent rarement à revenir en arrière et réfléchir à toutes les
problèmes qu'ils viennent traitée. La plupart des gens veulent aller de l'avant et de laisser le passé derrière.

Ceci est où le leadership entre en jeu. Les chefs d'équipe doivent être engagés à investir dans le post-mortem
processus. Comme les choses vent vers le bas, les dirigeants devraient être demander aux gens de commencer à penser à ce qui se passait
bien et ce qui ne l'a pas, même si elle est juste dans la forme de leurs propres listes privées. Un plan devrait être faite pour
les chefs d'équipe pour recueillir ces listes et de construire un rapport post-mortem. Le rapport devrait avoir deux
choses: une analyse et une synthèse des leçons apprises, et un engagement à répondre à un très petit
nombre d'entre eux dans le prochain projet (si vous choisissez un grand nombre, ils ne seront pas pris en compte; la priorité
et de se concentrer).

Il peut faire sens pour embaucher un professionnel pour faire le travail de post-mortem (12) pour vous (ou demandez à quelqu'un
pas sur votre équipe, mais dans votre organisation). Ils entrent, passent une semaine interviewer des gens sur le
équipe, et de construire un rapport basé sur ce qui a été appris, filtré à travers l'expertise du consultant. Ce
a l'avantage d'un point de vue objectif, car ils remarqueront et les choses de la voix d'autres non.
(13) Plus important encore, peut-être, ils apportent une expertise externe dans l'organisation, appliquée à la
besoins d'un projet et une équipe spécifique.
Page 287

15.5. Party time

Quand une version finale de RC est confirmé et fait son chemin à travers le processus de la mise en scène, sur le monde,
il est temps de célébrer. Après plusieurs semaines, des mois, voire des années, quoi qu'il en soit que vous étiez censé
avoir fait a été terminé. Il est une chose rare et spécial pour terminer un projet: dans le secteur de la technologie,
la plupart des projets ne sont jamais n'importe où près de cette mesure. Comme PM, il est de votre devoir de vous assurer qu'il ya une
possibilité pour tout le monde impliqué pour célébrer ensemble. Évitez cliché entreprise ou d'organisation (il est
impossible de célébrer dans une salle de conférence). Au lieu de cela, aller au pub le plus proche, réserver la grande table
à votre restaurant préféré, ou inviter des gens plus à votre domicile. Buvez manger mieux que vous avez dans et
une longue période (et manger et boire plus de lui). Si vous n'êtes pas le type de fête ou sociale, savoir qui sur
l'équipe est, et conspirent avec eux pour organiser quelque chose.

La réalisation de projets ne se produit pas souvent dans la plupart des vies. Création de bonnes choses que d'autres personnes
va utiliser dans leur vie est un défi incroyable. Il est un temps digne d'une célébration extraordinaire: en direct
vers le haut.

Page 288

15.6. Résumé

Big délais sont une série de petits délais.

Toute étape a trois échéances plus petits: la conception complète (spécifications finis), en vedette complète
(Mise en œuvre terminé), et (assurance de la qualité et de raffinement étape complète
fini).
 Définir les critères de sortie au début de jalons améliore la capacité de l'équipe à frapper ses dates.
Dates Frapper est comme l'atterrissage des avions: vous avez besoin d'une longue démarche, lente. Et vous voulez être
prêt à décoller à nouveau rapidement, sans avoir à faire des réparations majeures.

Vous avez besoin des éléments de mesure pour suivre le projet. Les éléments communs comprennent: tous les jours
construit, la gestion de bug, et le diagramme d'activité.

Vous avez besoin des éléments de commande pour projeter les réglages de niveau. Les éléments communs de contrôle
inclure: des réunions d'examen, le triage, et l'équipe de la guerre.

La fin de la fin du jeu est un processus abrutissante lente. Le défi consiste à réduire la portée de
changements jusqu'à une libération satisfaisante reste.

Il est maintenant temps pour démarrer le processus post-mortem. Donnez-vous et votre équipe au profit de
apprendre de ce qui se passait et ce qui n'a pas.

Si la fortune brille sur vous, et votre projet, il est hors de la porte, être heureux. Très très content.
Beaucoup de gens, sans aucune faute de leur part, ne sont jamais loin. Planifiez une grande nuit. Faire
amusant ridiculement et les choses extravagantes (y compris les invitant cet auteur à la partie). Donner
vous-même des histoires à raconter pour les années à venir.

Page 289

Chapitre seize. Pouvoir et la politique

 Chaque fois que vous essayez d'organiser les gens à faire quoi que ce soit , que ce soit une fête ou démarrer une
entreprise, il ya des attitudes différentes, les désirs, et de compétences entre les individus impliqués. Ce
signifie que peu importe comment intelligent ou talentueux est un chef de file à l'exécution d'un projet, il y aura quelques
personnes qui ne reçoivent pas tout ce qu'ils veulent. Ainsi, il est un instinct naturel pour motivés et
les gens ambitieux pour essayer d'obtenir ce qu'ils veulent en influencer les gens qui ont le pouvoir de faire
cela se produise. Ce, dans l'explication la plus simple que je pouvais tenir dans un paragraphe, explique pourquoi la politique existent. Il est
un sous-produit de la nature humaine dans les interactions de groupe que nous éprouvons de la frustration et
défis de situations politiques. Aristote a dit que «l'homme est un être politique," et cela est en partie ce
il voulait dire.

"Tout acte de gestion est un acte politique. Par cela, je veux dire que tout acte de gestion
en quelque sorte redistribue ou renforce le pouvoir ".

Richard Farson, de gestion de l'absurde: Paradoxes en leadership (Simon and Schuster,

1996)

Le carburant qui alimente la politique est le pouvoir. Environ défini, le pouvoir est la capacité d'une personne doit influencer
ou contrôler les autres. Alors que nous avons tendance à regarder les hiérarchies organisationnelles pour comprendre qui est puissant
et qui ne sont pas souvent les structures de pouvoir ne correspondent pas directement hiérarchies (comme décrit dans le chapitre 12 ,
puissance gagné est différente de pouvoir accordé). Une personne qui peut convaincre les bonnes personnes au
au bon moment, et appliquer ses connaissances pour résoudre des situations à la satisfaction de tout le monde, peut être plus
puissante dans une organisation que ses superiorssometimes sans les reconnaître.

Ce fait ajoute une complexité supplémentaire à la politique de l'organisation: les individus sont libres d'essayer de
cultiver puissance indépendant de la hiérarchie. Pour ce faire encore plus difficile, en fonction de la
question ou décision particulière, le pouvoir est réparti différemment dans l'équipe. Pour l'ingénierie
décisions, Harold pourraient avoir le plus de pouvoir, mais pour des questions commerciales, il est Maude. Le tout combiné, la
complexité des organisations de projets typiques crée des opportunités politiques, mais elle rend aussi

Page 290

compétition pour le pouvoir et l'influence inévitable.

Pour les gestionnaires de projet, cela signifie deux choses. Tout d'abord, il y aura des influences politiques qui influent sur vous
peu importe la puissance ou éthique que vous êtes. Deuxièmement, le pouvoir et la politique sont une partie inhérente de
leadership et de gestion. Vous devez au moins être au courant des travaux des systèmes façon politique, si vous voulez
à diminuer leurs effets négatifs, beaucoup moins d'améliorer leurs aspects positifs. Ce chapitre fournira
leçons fondamentales de la politique de projets appliqués. Je couvrirai comment diagnostiquer le paysage politique que vous êtes,
les situations courantes et pourquoi ils se produisent, et comment résoudre les problèmes de politique et de pouvoir.
Page 291

16.1. Le jour où je suis devenu politique

Ma première leçon importante à propos de la politique organisationnelle est venu en 1997 de Chris Jones, qui à l'époque
était gestionnaire de programme de groupe pour Internet Explorer. Le groupe avait traversé un couple chaotique de
mois, avec plusieurs réorganisations et changements de direction, et les choses avaient toujours pas installés.
Il y avait un rôle particulièrement important sur le teamresponsibility pour une fonctionnalité appelée chaînes
(Partie de la "technologie push" engouement malheureuse lors de la guerre des navigateurs) - qui n'a jamais bien passé.
Ce rôle était si important à nos plans, et si mal géré, que toute l'équipe était négative
impacté par elle. Beaucoup de mes camarades et moi étions en colère, mais nous ne savions pas quoi faire à ce sujet. Sentiment
impuissants, nous avons surtout blâmé la politique de notre équipe de direction. Pour aggraver les choses, à la
temps, je devais la vue la plus cynique de la politique organisationnelle. Il était quelque chose comme ceci:

Politique (N): Les mauvaises choses, la faiblesse, les gens égoïstes font.

Je ne savais pas exactement ce que ces choses étaient, ou comment elles ont été faites, mais je suis sûr que le mal et
gens faibles égoïstes dans l'équipe (quels qu'ils soient) le faisaient. Je ne pouvais pas identifier précisément
eux parce que mon évaluation de personnes, à l'époque, avaient deux paramètres: intelligents et débile. J'étais
ignorant et arrogant (souvent intéressant de voir comment ils se réunissent). Mais ma grâce de ces économies
manquements était que je devais la plus haute opinion de Chris, et de la bonne fortune d'avoir un bureau à côté de
sa. (1) Un jour, frustré et bouleversé par la situation de l'équipe, je me suis arrêté et lui a dit par mes préoccupations
sur le groupe. Il a écouté patiemment et a suggéré que nous bavardons pendant le déjeuner.

Pendant le déjeuner, il a fait le plus surprenant thinghe m'a dit que je ne pensais plus à entendre. Il a énoncé
la situation de son point de vue, en me disant juste assez de détails que je ne pouvais comprendre le primaire
problèmes, sans trahir la confiance des autres membres de son organisation. Il a décrit son haute
évaluation du niveau du problème, et les trois solutions de rechange raisonnables qu'il avait à sa disposition pour le résoudre. JE
a réalisé qu'il avait ses propres contraintes: les besoins, les désirs et les objectifs de ses propres pairs, les gestionnaires, et
Vice-présidents. Il avait la pression de notre calendrier et la concurrence stratégique (Netscape). De mon point de vue,
Je suppose son monde était plus libre que la mienne (n'a pas plus de puissance signifie plus de liberté?), Mais comme il a posé
dehors, je me suis rendu sa situation était plus difficile que la mienne.

Il a ensuite fait la deuxième thinghe plus inattendu m'a demandé mon avis. Il m'a donné une chance de
offrir mon propre logique et la perspective sur les décisions qu'il avait à faire. À droite, puis, je eu mon premier
épiphanie politique: ce truc est dur, très dur. En demandant ce que je pensais (et l'écoute de ce que je
dit), il a désamorcé tous de l'animosité et de pointer du doigt qui comprenait habituellement mes tentatives
la pensée politique. Il m'a fait réfléchir à fait les questions et les personnes impliquées. Et quand je l'ai fait, je
gelé. Comme d'être jeté dans la circulation routière venant en sens inverse, je ne savais pas par où commencer: tout semblait
terrifiante. Je me souviens encore à regarder mon demi-mangé un sandwich, à défaut de trouver rien d'intelligent à
dire. La conversation avançait, le déjeuner terminé, et je suis retourné au travail. Je ai appris beaucoup depuis
puis sur la façon dont les organisations fonctionnent, mais je repense à ce jour comme un changement important dans
perspective. Voici trois points clés que je l'ai appris depuis ce jour-là:

La politique est pas un vilain mot . Dans la plupart des dictionnaires, la première définition du mot politique vous
vous trouverez est quelque chose comme ceci:

Politique (n): L'art ou la science du gouvernement ou d'administration, en particulier l'administration d'un

entité politique, comme une nation, et l'administration et le contrôle de son interne et externe
affaires.

Vous ne trouverez pas quelque chose comme ma définition cynique, jusqu'à la quatrième ou cinquième définition listé dans
la plupart des dictionnaires anglais. La politique est l'habileté de la gestion des personnes et des organisations. C'est
possible pour être efficace sur le plan politique sans recourir à un comportement contraire à l'éthique ou sournois.

Tous les dirigeants ont des contraintes politiques et de pouvoir . Nous aimons à croire que le pouvoir figureslike
vice-présidents d'entreprise ou le président des États-Stateshave pouvoir énorme. Ils le font, mais beaucoup
il est de pouvoir par influence. Par exemple, le président des États-Unis est l'une des trois branches du
 gouvernement (l'exécutif), et sa puissance est vérifiée et équilibrée par les deux autres branches.

Page 292

Beaucoup de ses actions officielles conventions peuvent être rejetées ou rejetées. La plupart des entreprises ont des PV cadres supérieurs
rapport à ceux qui ne veut pas qu'on lui dise quoi faire, et ils exigent d'importantes quantités de
leur propre autorité. Et il va en bas de la chaîne de commandement. Donc, quand vous regardez les gens
qui ont plus de pouvoir que vous, ne présumez pas omnipotence.

Le rapport de la puissance de charge est constante . Une façon de penser à propos de la puissance est par
sa relation avec les contraintes ou les défis auxquels vous êtes censé répondre en utilisant ce pouvoir. Dire que je
était le PDG de ExampleCorp, et je vous ai donné 5 $ pour aller me chercher un café. L'autorité vous
ont est petite (bien qu'il y ait un peu), mais est si la responsabilité. D'autre part, si je donnais
vous 2,5 millions $ et un personnel de serviteurs brillants, je serais probablement vous demande de planifier, construire, et
gérer toute l'entreprise. Responsabilité, le stress, et les défis augmentent généralement en relation
à la quantité d'énergie que vous avez acquis. Pour cette raison, d'avoir plus de puissance fait rarement
les choses plus faciles parce que les défis augmentent en raison de l'augmentation de la puissance.

La politique est une sorte de résolution de problèmes . Peu importe ce que vous faites face défi organisationnel et
comment il pourrait être frustrant, il est juste un autre type de problème à résoudre. Le micromanagers, la
randomisation, et les bruns-nosers sont tous simplement différents types d'obstacles à surmonter ou
contourner. Comme bon ou mauvais que les choses pourraient être, il ya probablement un nombre fini de réaliste
choix quiconque au pouvoir peut éventuellement faire dans une situation particulière, et ils auront tous
conséquences politiques. Si vous vous approchez des problèmes d'organisation avec la même discipline et
la créativité vous approchez d'un problème de conception ou d'ingénierie, vous pouvez trouver ces choix, et de faire
de bonnes décisions (ou du moins la meilleure décision possible).

Au fil du temps je appris que blâmer la «politique» pour les problèmes que je dû relever a été d'une manière naïve et pratique à
esquiver les aspects désagréables mais inévitables de travailler avec d'autres personnes. La même allés pour pointer
doigts à la «gestion», «ingénierie» ou «marketing» et de dire comment ils stupides ou inefficaces
ont été. Pointant un doigt ne les rend pas moins stupide ou inefficaces. (Si, en effet, qui est vraiment
quel est le problème. Il est toujours possible ils sont intelligents mais tout aussi limitée par des facteurs politiques que
tu.)

La même chose vaut pour pointer du doigt tout individu programmeur, gestionnaire, ou l'auteur. Blâmer tout simplement
ne change rien, et il vous aveugle généralement des véritables causes et les remèdes possibles d'un
situation. Toute action politique ou de gestion qui prend place, peu importe comment stupide ou mal qu'il
semble, est toujours l'un d'un nombre limité de choix possibles gestionnaires ont. Les solutions de rechange pourraient
être encore pire pour le projet que le choix qui a été fait. Sans comprendre quelque chose de
l'contraintes, le jugement sera toujours basée sur plus de frustration que de ventilation sur la réalité de la
situation.

Page 293

16.2. Les sources d'énergie

Puissance (n): La capacité de faire ou d'agir; la capacité de faire ou d'accomplir quelque chose. (2)
 Pour comprendre
comprendre la politique
les bases et avoir
du pouvoir une chance
politique. d'influencer
La plupart ou de
des formes deréussir
pouvoirdans la un
dans façon dontdeles
centre choses se jouer,
l'organisation vous devez
sur ce
décisions d'un individu peut faire ou influence. Pensez à la façon dont les décisions sont prises dans votre
organisation: si il ya une décision difficile qui doit être fait, qui arrive à le faire? Qui est autorisé à
être dans la salle comme il est débattu? Dont les opinions sont le plus souvent écouté? Ce sont des gens avec
degrés de puissance. Avoir une autorité claire pour prendre une décision est la forme la plus élémentaire de la puissance, mais
ayant accès à ce décideur, poser des questions, ou de suggérer des idées est une autre forme de
pouvoir. Comme je l'ai couvert de Chapitre 12 , pouvoir accordé est la forme la plus évidente, car il descend
à travers la hiérarchie. Il est impliqué dans les titres d'emploi des personnes ou d'autres symboles de l'ancienneté. Accordée
pouvoir vient presque toujours à une personne par quelqu'un dans une position plus élevée de la puissance. Le vice-président
accorde le pouvoir à ceux qui travaillent directement pour elle, et ces individus accordent pouvoir à ceux qui
travailler pour eux. Le vice-président pourrait décider de donner à certains individus plus de puissance que ce qui était dans othersif
le meilleur intérêt de ses objectifs.

Puissance gagné est distribué organiquement. Parce que la réputation et la capacité sont subjectifs (par rapport à
titres d'emploi et de la hiérarchie), chaque individu dans un projet joue un rôle dans la détermination qui a gagné
pouvoir. Par exemple, disons que Tyler est un programmeur de l'équipe. Marla et Jack pensent hautement
de ses opinions, mais Chloé ne fait pas. Si un débat ensuit entre toute l'équipe, Marla et Jack
ont tendance à donner plus de crédibilité aux arguments de Tyler que Chloé. Dans un sens, Marla et Jack
ont tendance à transférer une partie de leur propre pouvoir pour soutenir les arguments de Tyler. Donc, le pouvoir est souvent gagné
accordé à l'individu par le comportement de ceux autour de lui. Dans un tel cas, le pouvoir gagné
peut être distribué à travers les lignes de la hiérarchie. Par exemple, un cadre supérieur dans une organisation
pourraient penser beaucoup d'un employé subalterne dans un autre.

Bien qu'il est commun pour certaines personnes à avoir gagné plus de confiance et de pouvoir que d'autres, il est
toujours subjective et relative. Différents résultats sont possibles en fonction du domaine de la
décision, qui est dans la salle, et ce pouvoir qu'ils ont. Certains disent que cela est ce qui rend la politique
intéressante: le pouvoir est constamment coule à travers une équipe, les changements de direction, et de soutenir ou
travailler contre différentes personnes à différents moments. Parce que le pouvoir est pas toujours évident jusqu'à ce qu'il soit
été utilisé, il est facile de mal interpréter qui a ce genre de pouvoir.

Par souci d'exhaustivité, la liste suivante offre des définitions spécifiques des différents types de pouvoir
(Cette liste est une interprétation très lâche d'une liste qui se trouve dans le jeux de pouvoir par Thomas rapide). Je ne vais pas consulter
à ceux-ci beaucoup, mais il est utile d'envisager dans votre organisation qui les possède, et comment ils
sont utilisés:

Récompensez . La possibilité d'accorder des primes personnes, soulève, des morceaux savoureux de nourriture, ou tout visiblement bénéfique
récompense. Parce que les gens savent que vous avez ce pouvoir et que vous voulez être destinataires de, ils vont
ont tendance à réagir et à se comporter différemment envers vous.

La coercition . Avoir le contrôle sur les sanctions et la capacité de menacer une action punitive. La menace
de ce genre de pouvoir est souvent suffisant parce que, contrairement récompenses, le pouvoir est pas dans le
recevoir de bonnes choses, mais ne pas avoir à recevoir de mauvaises choses. Pouvoir coercitif peut être aussi
simple que la capacité d'embarrasser ou ridiculiser une personne devant les autres ("Comment êtes-vous stupide?
»), Ou aussi officiel que la rétrogradation de personnes ou de réduire leurs responsabilités ou de salaire.

Connaissance . Avoir une expertise dans un domaine, ou d'avoir des renseignements précis qui est pertinent
à une décision, donne le pouvoir. En contrôlant la façon dont l'expertise est appliquée, ou comment / si
l'information est diffusée, on peut développer la puissance. Dans la forme la plus simple, il suffit d'être intelligent,
compétent, et bonne à résoudre avec ce que vous travaillez sur offre puissance problème
parce que les gens vont vous écouter et de respecter votre opinion. Dans les formes plus complexes, ayant
informations sur d'autres personnes, des équipes, des tendances, ou des réunions donne pouvoir parce que votre point de vue

Page 294

le monde est plus précis que d'autres ». Et si vous vous sentez manipulatrice, vous pouvez fausser
Les perceptions de l'état du projet ou le monde des autres.

Référent . Qui vous savez et comment vous les connaissez. Si les gens savent que vous avez le soutien ou
l'amitié de ceux qui ont le pouvoir, certaines d'entre elles est appelée à vous. Par exemple, si vous introduisez
vous-même comme «Je suis Steve, je travaille pour le projet de loi," vous misez sur le pouvoir et la réputation de Bill pour aider
vous fournir une partie de votre propre. Pouvoir de référence peut également provenir de personnes qui ont alliés
vous ou vous offrez un soutien.

Influence . Certaines personnes possèdent la capacité de persuader les autres, qui peuvent être ou ne pas être
liée à leur connaissance du problème en question. Une combinaison de compétences de communication,
la confiance, la conscience émotionnelle, et les talents d'observation contribue à la capacité d'être
influente. L'influence peut être alimenté par des gens de la matière ont pour votre connaissance, ou parce que
ils vous faire confiance, ou même tout simplement parce qu'ils pensent que vous êtes séduisante, intelligente, ou intéressant.
Influence peut aussi se développer à la suite d'une dette: quelqu'un vous doit une faveur, et l'influence
sur une décision est un moyen d'aider le rembourser. Notez que certaines personnes auront plus d'influence
sur othersit est une forme très relatif de la puissance, et non absolue.
Page 295

16.3. L'abus de pouvoir

"Si vous ne savez pas ce que vous faites, ce qui va offrir de la valeur à qui, et
comment il sera mis en œuvre, les projets auto-organise autour d'un autre but ou
buts. Typiquement, les querelles politiques de quelque nature éclate. Cela garantit
inutilité. "

James Bullock, à partir de la table ronde sur la gestion de projet

Lorsque nous parlons de la politique comme une chose mauvaise, nous entendons généralement très abus de pouvoir. Je définis un
abus de pouvoir comme toute action qui ne sert pas le plus grand bien du projet et les personnes en
il. (3) Parce que les sources d'alimentation sont naturels, et l'utilisation de celui-ci pour influencer et motiver les décisions est un
sous-produit du travail en équipe, les choses ne peuvent pas être mauvais en eux-mêmes. Il est impossible de
travailler sur un projet sans les individus qui essaient d'influencer les autres et d'utiliser leur propre pouvoir de
faire avancer le projet. (En fait, comme nous allons examiner, la discussion ouverte et le débat d'idées est
saine et positive vers la prise de meilleures décisions et de travailler efficacement, simultanément
minimisant la politique.)

Détournement de pouvoir se produit alors quand une personne travaille à ses propres intérêts. Par exemple, dans
Figure 16-1 , les objectifs d'un individu correspond que vaguement aux objectifs du projet. Beaucoup de
son énergie sera consacrée à faire ce qui est le mieux pour lui, au lieu de ce qui est le mieux pour le projet en tant que
entier. Cela représente un manque de leadership et de gestion afin de mieux aligner individuel et par équipe
(objectifs et récompenses) avec les objectifs du projet. Pour être juste envers les dirigeants, certaines lacunes sont inévitables. Gens
avoir une vie en dehors du projet. Les individus ont leurs propres motivations personnelles qui peuvent avoir
rien à voir avec le travail du tout, mais où l'individu cherche à satisfaire par le travail. Cependant,
le rôle de la gestion est de regarder ces lacunes et trouver des moyens pour les minimiser. Les gestionnaires devraient
au moins aider les employés à agir sur ces motivations d'une manière qui ne nuisent pas au projet. Dans
la fin, si de grandes lacunes existent, une tension naturelle est créée pour comment le pouvoir sera appliqué. Il y aura
fortes tentations pour les gens à se servir au lieu de servir le projet.

Figure 16-1. Les motivations personnelles doivent aligner avec le projet. Le moins
l'alignement, le comportement politique plus destructive sera.
 Il est également possible que ce qui semble être un usage égoïste du pouvoir est tout simplement un désaccord à propos de
ce qui est mieux pour le projet. Comme le montre la Figure 16-2 , il se pourrait que deux personnes ont différente
opinions sur la meilleure façon de satisfaire les objectifs du projet. La distinction entre ces deux cas peuvent
être très difficile parce que souvent ce qui est mieux pour le projet peut se révéler être mieux pour un individu
que l'autre. Discerner lorsque la motivation est purement égoïste exige la connaissance de la
personnes impliquées, des objectifs clairs du projet, et un bon cadre pour communiquer, débattre, et
en discutant des problèmes.

Page 296

Figure 16-2. Les différends sur le pouvoir peuvent se produire pour des raisons altruistes. Deux
pairs peuvent tout simplement pas d'accord sur la meilleure utilisation de l'énergie.

Quand il ya plusieurs petites équipes qui contribuent à un même projet, les problèmes sont plus
complexe. Comme le montre la Figure 16-3 , si chaque équipe a motivations à faire des choses qui ne sont pas
dans le meilleur intérêt du projet, ils vont dépenser chacun une énergie importante sur des choses qui ne conduisent pas à
la réussite globale du projet. Ce cadre applique aussi bien à des particuliers ou à des équipes entières.
Chaque fois que les objectifs divergent, la fréquence de pouvoir détournement va augmenter. Cela est (encore une fois), à moins que la personne
la gestion de toutes ces personnes ou équipes travaille activement pour obtenir ces équipes de collaborer et de
régler ouvertement les conflits d'intérêts.

Figure 16-3. Plus la divergence d'intérêt, plus le

probabilité que l'abus de pouvoir va se produire.

16.3.1. Procédé pour cause d'abus de pouvoir

Une façon plus spécifique à penser pouvoir détournement est de diviser les causes en deux groupes: processus
et de motivation. Processus entraîne la tige de défaillances dans la façon dont l'équipe ou de l'organisation est
structuré, et il est un type de gestion ou de l'échec de leadership. Les causes de motivation sont entraînés
purement par des individus et de leurs besoins personnels et les lecteurs. La plupart du temps, lorsque l'alimentation est mal utilisé,
il est une combinaison de processus et les questions de motivation.

les causes de processus sont plus dangereux que les forces de motivation parce qu'ils ne sont pas liés à un seul
le comportement de la personne. Au lieu de cela, une cause de processus est systémique et encourage tout le monde sur l'équipe
abus de pouvoir ou de l'appliquer à des causes qui ne servent qu'à eux-mêmes.
 Processus de prise de décision peu claire . Si l'équipe sait quand une grosse décision est à venir, ce qui
les critères sont, et qui est impliqué dans la décision, il ya peu de nécessité pour la politique de fantaisie.
Toute personne ayant une opinion saura qui aller ou ce forum pour présenter leurs propositions, comme
ainsi que les arguments qui seront efficaces. Il est tout simplement moins besoin d'être manipulatrice. Mais si

Page 297

le processus est caché, est trop complexe, ou manque propriétaires visibles pour les décisions, quiconque
soucis quant à l'issue seront motivés à être plus politique. Par conséquent, il est le travail du
quiconque de prendre des décisions qui ont un impact d'autres de préciser comment il sera fait, qui est impliqué, et
quels sont les critères.

Malentendu / mauvaise communication . Les équipes qui communiquent bien faire en sorte que
l'information est non seulement transmis, mais aussi comprendre et, si possible, convenu (voir
Chapitre 9 ). Les plus pauvres des habitudes de communication d'une équipe, le plus souvent d'un pouvoir est appliqué
des moyens qui ne servent pas le projet. Si la personne A et la personne B pensent des objectifs du projet
différemment, mais assumer l'autre a la même interprétation, ils vont travailler les uns contre les
autre sans même le réaliser.

L'allocation des ressources sait pas . Si le processus de la façon dont le budget, le personnel et l'équipement sont
alloué est pas défini ou rendues publiques, tout le monde va chercher ces ressources en utilisant toute
tactiques disponibles. Il est le travail de celui qui a la puissance convient de préciser pour l'équipe ce que
les critères sont pour la distribution des ressources, ou comment et quand les propositions doivent être faites
pour les acquérir.

Le manque de responsabilité . Quand les gens sont autorisés à échouer ou faire des erreurs sans prendre
la responsabilité pour eux, la politique sont inévitables. Sans responsabilité pour autrui
engagements, peu se faire confiance aux autres. Sans confiance, les gens vont utiliser leur propre pouvoir pour protéger
eux-mêmes de la dépendance sur les autres ou pour éviter la dépendance à des gens qu'ils ne font pas confiance (voir
la section " La confiance se construit à travers l'engagement "dans le chapitre 12 ).

Buts faibles ou édentés . Pour presque tous les abus de pouvoir, je l'ai mentionné, une référence
est fait pour servir les objectifs du projet. Lorsque les objectifs du projet sont faibles (voire inexistants), ceux-ci
mésusages sont probables, sinon garanti. Sans le centre de gravité des objectifs du projet, il est
aucun point de clarté que tout le monde peut entendre, ce qui signifie que tout peut être débattu et
interprété. Même si les objectifs sont forts, les chefs d'équipe doivent donner les dents buts: activement
protéger les objectifs, la mise à jour et les réviser pour les garder exacts et à assurer que tous les
les décisions sont prises pour les servir.

16.3.2. Les causes de motivation pour abus de pouvoir

Peu importe ce que votre philosophie est de la nature humaine, il est raisonnable de supposer que toutes les personnes
sont des créatures d'auto-motivés. Même lorsque nous agissons de façon altruiste, nous servons nos propres valeurs sur ce
est bon et mauvais dans le monde. Nous sommes aussi des créatures émotionnelles, et les facteurs psychologiques conduisons notre
behaviorsome dont nous sommes plus conscients de que d'autres. Les causes de motivation sont basés dans un langage simple
éléments de la psychologie humaine:

Protéger les autres . Si je laisse cette décision arrive, les gens de mon équipe ou mes pairs qui je
soucier va en souffrir.

L'intérêt . Je veux que cette augmentation de salaire, promotion, ou sentiment de fierté d'accomplir quelque chose
que je ressens est important ou bien fait.

Ego . Je veux prouver comment futé Je suis à moi-même ou tout le monde, et peut-être vous assurer qu'il est
indiscutable et visible de manière dramatique la façon beaucoup plus intelligente et mieux je suis que ce qu'ils sont. Ce
projet doit être au moins aussi parfait que je suis, ou il devrait me aider à couvrir pour imparfait je
sens que je suis.

Dislike / vengeance . Je ne veux pas travailler avec Fred, ou je veux en venir Fred de retour pour ce "qu'il
a fait pour moi "sur le dernier projet.

Ces motivations ne sont pas nécessairement mauvais. Ils causent des problèmes uniquement si elles conduisent à des comportements
Cela ne veut pas meilleur soutien les objectifs du projet. Si ces motivations peuvent être gérés d'une manière
qui ne fait pas mal d'autres sur l'équipe, alors ils sont vraiment juste un autre type de carburant à utiliser dans la conduite
avancer le projet. Regardez à nouveau la figure 16-1 : si les deux cercles se chevauchent de 90%, alors
efficacement, les motivations de l'individu sont très alignées avec les objectifs du projet. Il est le gestionnaire de
au défi de garder les forces de l'ego et de l'intérêt dans le contrôle à tout moment. Le gestionnaire doit diriger

Page 298

les énergies de ses rapports et son équipe en vue d'aider le projet et les personnes qui travaillent sur elle,
au lieu de travailler contre eux.

16.3.3. Prévenir les abus de pouvoir

 La meilleure façon de réduire ces symptômes est de dépendre fortement sur les objectifs définis par le projet
vision pour conduire l'application de la puissance. Si tout le monde se réfère aux mêmes objectifs fondamentaux et hérite de leur
objectifs individuels à partir de cette même source (voir chapitre 4 ), les tensions politiques que surface sera
gérable. Bien que certains peuvent être en désaccord et de débattre les moyens, tout le monde va se battre pour
extrémités similaires. Pour renforcer ce, à tout moment au cours d'un projet, tout le monde devrait être en mesure de poser ouvertement la
questions suivantes:

Quels sont nos objectifs pour cette semaine / mois / projet?

Sont ces objectifs généraux ou sous-équipes en conflit de quelque manière? Comment pouvons-nous gérer ou résoudre
leur?

Comment cette décision particulier sera fait et qui va le faire?

Quels sont nos critères pour faire en sorte cette décision sert le mieux le projet?

Sont vos et mes pouvoirs étant appliqué d'une manière qui contribue à nos objectifs ou soutient la
équipe?

Qu'est-ce que l'utilisation des ressources est le plus susceptible de nous conduire vers le succès? Comment pouvons-nous y arriver?

Même si les gens sont en désaccord sur les réponses, ils avoir les bons désaccords. Il sera évident
ce que les véritables causes des conflits sont, et les dirigeants et les gestionnaires auront la possibilité de fournir
clarté, redéfinir les objectifs, ou faire de nouveaux choix (éventuellement difficiles), en présence du peuple
directement touchés par eux. Au contraire, l'abus de pouvoir est garanti si les objectifs sont nettement
périmées ou divergent radicalement d'individu à individu ou une équipe pour l'équipe.

Parfois, les gestionnaires choisissent de mettre délibérément équipes jusqu'à concurrence les uns avec les autres, le pari que
la concurrence accrue mènera à un meilleur travail. Cela peut fonctionner dans certaines situations, mais il rend le
organisation plus volatile et politique, nécessitant un leader plus fort et plus actif pour tenir le tout
ensemble. Il n'a rien d'unique à ce sujet. Par exemple, chaque équipe sportive a démarreurs et
joueurs de sauvegarde. Durant chaque entraînement, l'entraîneur tente de maintenir la concurrence interne pour ceux
à partir des taches, tout en maintenant simultanément une liaison forte sur l'ensemble de l'équipe. Les bons leaders
renforcer activement les bonnes attitudes et les comportements pour garder ces forces équilibrée.

Mais pas cochée, les individus ayant des intérêts distincts ou concurrents ont plus de motivation à utiliser
le pouvoir politique à leurs propres fins. Au lieu de se concentrer sur l'esprit de compétition véritable entreprise
concurrents, il est dirigé au pairs et ses subordonnés au sein de la même équipe. D'un point de vue holistique de
le projet, ce type d'environnement est corrompu. Puissance est pas dirigé efficacement vers le
l'achèvement du projet lui-même. Sans leadership fort agit pour recentrer l'équipe et niveler le
terrain de jeu, spirales descendantes sont probables. Chaque action corrompus ou égoïstes qui va récompensé
(Ou ignorés par la direction) sera d'encourager les autres à faire de même. Bientôt, peu de gens auront confiance en chaque
assez autre pour être efficace, car ils seront toujours en question les arrière-pensées de leurs coéquipiers et
supérieurs.

Page 299

16.4. Comment résoudre les problèmes politiques

Pour cette section, je suppose deux choses. Tout d'abord, qu'il ya des objectifs pour le projet bien défini.
Deuxièmement, que ces objectifs motivent ce que vous essayez d'atteindre. Si une ou les deux de ceux-ci
hypothèses est pas vrai pour vous, cette section sera toujours d'usage, mais il y aura plus de travail pour vous
faire parce que vous aurez moins de levier pour faire bouger les choses.

Le processus décrit ici fait le plus de sens pour les grandes questions de pouvoir et lorsque vous êtes dans un
situation où vous avez besoin de plus de pouvoir que vous avez. Le plus gros de la question, plus fidèlement une
processus de pensée comme cela devrait être appliqué. Le plus petit de la question, plus de ces étapes, vous pouvez
probablement accélérer ou de sauter à travers tout à fait.

16.4.1. Clarifier ce que vous avez besoin

La seule façon de réussir à résoudre un problème politique est d'être très clair sur ce qu'il vous est
 besoin, puis élaborer un plan pour l'obtenir. Les besoins communs sont:

Ressources (temps, argent, personnel)

Le pouvoir de prendre une décision

Influence sur une décision sous l'autorité de quelqu'un d'autre

Ajustement des objectifs de d'autres pour soutenir ou aligner avec le vôtre

Réglage de vos propres objectifs de mieux aligner avec les autres »

Conseil, d'expertise ou de soutien

Cependant, vous définissez vos besoins, préparez-vous à être flexible. Même si vous décidez que le besoin réel est
des ressources, alors que vous êtes les rechercher, ne vous arrêtez pas à l'écoute des suggestions des autres qui
satisfaire les objectifs, mais ne comportent pas l'acquisition de ressources. En poussant un budget plus important ou plus
temps, vous pourrait forcer une nouvelle idée à la surface qui répond à vos objectifs tout aussi bien que plus de ressources
aurait. Donc, ne pas se focaliser sur la nécessité elle-même: il est seulement un moyen pour satisfaire vos objectifs pour le projet.

16.4.1.1 gérer jusqu'à

Le meilleur moment possible de faire ce genre d'analyse des besoins politiques est au moment où vos objectifs
sont définis. Lorsque vous êtes assis avec votre gestionnaire d'accord sur ce que vous avez des responsabilités
pour la semaine prochaine ou le mois, il ya une opportunité d'examiner si vous avez le pouvoir, vous
Besoin d'obtenir que le travail fait. Tout soutien dont vous avez besoin que vous ne possédez pas actuellement devrait être
identifié, et votre gestionnaire peut venir avec un plan pour vous aider à l'obtenir. Certaines organisations appellent
cette activité gestion upas Vous devez gérer la hiérarchie, au lieu de descendre. Clarifier
ce que vous avez besoin de la direction est la première étape dans la gestion avec succès.

Les autres étapes de la gestion jusqu'à la plupart impliquent répétant ce processus à des intervalles nécessaires. Si
vous pouvez rester en synchronisation avec votre gestionnaire et le gestionnaire de votre gestionnaire sur ce que vous faites et
ce que vous avez besoin d'eux, et vous assurer que tout est aligné vers les mêmes objectifs, vous êtes le plus de la
chemin.

La façon la plus simple de gérer jusqu'à est d'initier une discussion avec votre gestionnaire où vous proposez
spécificités pour les points suivants.

Page 300

Ce que je vous attends, mon manager, de faire pour moi (par exemple, donner des conseils, me prévenant de choses que je
besoin de savoir, soutenir mes décisions, soulignant les domaines où je besoin pour grandir)

Les ressources que je besoin pour atteindre ces objectifs, et qui je leur besoin de

Le niveau et la fréquence de la participation je besoin de vous (Pas d'implication? Examens trimestriels?

Rapports d'étape tous les jours? Un-à-un les réunions hebdomadaires? Être spécifique)

En faisant cela, au début, vous saurez exactement quel soutien vous pouvez vous attendre, et où les problèmes
viendra probablement à partir. Les alarmes devraient partent si votre gestionnaire ne répond pas, vague, ou défensive
de commettre à toutes vos demandes. Cela signifie que vous pouvez très bien être sur votre propre ou mis en place
à l'échec, et que votre gestionnaire est pas travailler activement dans vos intérêts communs.

16.4.2. Qui a le pouvoir de donner ce que vous avez besoin?

Pour chaque type d'énergie dont vous avez besoin, identifier la personne qui peut vous le donner. L'organigramme ou
la hiérarchie est un endroit facile à démarrer, mais l'utiliser seulement pour vous rafraîchir la mémoire sur les acteurs impliqués
(Voir Figure 16-4 ). Puis demandez autour pour savoir qui est le plus activement responsable de quels types de
décisions (sur les petites équipes, il devrait être évident, mais si vous n'êtes pas sûr, demandez). Utiliser les gens qui sont
engagés à vous soutenir pour aider à régler ce problème: votre manager, vos pairs, ou des rapports. Il ne devrait pas
prendre plus de quelques conversations à identifier les personnes dont vous avez besoin. Parfois, il est préférable de demander
ce genre d'information indirectement parce que vous ne voulez pas nécessairement d'approcher la personne (s) dans
question sans un plan. (Évitez comportement étrange, comme "Salut Fred. Etes-vous en charge de décider qui
obtient de nouveaux ordinateurs portables? "" Oui, pourquoi? "" Oh, juste curieux. Au revoir.")

Figure 16-4. La source pertinente du pouvoir dépend de la situation. La

org hiérarchie de tableau ne sont pas nécessairement la considération primordiale. A la mi-
personne de niveau peut avoir plus de pouvoir sur certaines questions que son patron
t.
 16.4.2.1 Comprendre leur point de vue

Pour toute personne qui a le pouvoir dont vous avez besoin, commencer par identifier ce que ses objectifs sont. Sur un bien géré
équipe, cela devrait être facile parce que ses buts sont vraiment les objectifs du projet à tous les niveaux de l'ancienneté
il arrive à avoir. Considérez ses préjugés, les opinions et les moyens préférés pour aller de faire
décisions. Le mieux votre relation est avec lui, et le plus d'expérience que vous avez à travailler avec
lui, le plus facile ce sera.

Penser à partir de son point de vue, le travail pour voir comment vos besoins et objectifs entrent dans le sien. Faites votre demande
dériver de certaines exigences de projet de niveau supérieur ou un objectif qu'il est tenu de respecter.
Au lieu de dire "je besoin d'un autre programmeur," comprenez que vous pouvez honnêtement dire "Pour atteindre
buts X et Y, mon équipe a besoin d'un autre programmeur. Notre plan de projet ne prévoyait pas les trois
demandes qui sont venus la semaine dernière, et, par conséquent, nos objectifs sont actuellement à risque élevé. "Ne pas mentir ou
induire en erreur. Soyez prêt à remettre en question vos propres demandes de ressources, si il ya de meilleures utilisations pour eux sur

Page 301

le projet. (Mais si tel est le cas, vous devriez demander pour les buts et objectifs à changer dans
lumière de cette meilleure utilisation. "Je pense que nos objectifs doivent changer. Objectif X est moins important aujourd'hui. Ces ressources
devrait passer à soutenir objectif Z. "Un superviseur intelligente vous récompensera pour cette pensée de projet-centrique.)

16.4.2.2 qui ne leur confiance et de respect?

Si vous avez identifié Fred que la personne avec la puissance dont vous avez besoin, le travail pour comprendre ce qui influence
lui. Il pourrait être un pair, une étoile sur son équipe ou son supérieur. Il pourrait être youat moins pour certains
types de décisions. Envisager des façons d'utiliser l'influence de ces personnes pour vous aider à faire votre
cas. Si vous avez une bonne relation avec ces personnes d'influence, partager votre façon de penser avec eux
et leur demander leur opinion.

Ne pas manipuler, mentir, ou faire quelque chose questionableit devrait pas être nécessaire. Au lieu de cela, placez votre
l'argument comme vous le feriez avec Fred, et demander leurs commentaires. Ils peuvent connaître les faits que vous faites
non, ont des perspectives qui amélioreront votre pensée (y compris l'évolution de votre opinion), ou ont tout simplement
des conseils sur la façon de planter votre cas. Même si vous ne possédez pas de bonnes relations avec ceux-ci influent
les gens, vous pouvez toujours demander leurs opinions ou d'observer comment ils font arguments succès ou
propositions à Fred.

16.4.2.3 L'illusion de la puissance du groupe

Parfois, ce que vous devez apparaîtra à être régi par un groupe de personnes. Il pourrait y avoir un
réunion ou comité qui semble prendre certaines décisions. Ne jamais se concentrer sur un groupe de personnes:
diviser toujours des groupes en individus et envisager qui a quel type d'influence dans ce groupe.
Malgré la façon dont ils apparaissent, réunions décident rarement quelque chose. Souvent, les gens entrent dans ces discussions
avec des opinions bien arrêtées et alliés pour les soutenir, et de la réunion porte sur une séquence de
machinations prévisibles. Pour les non-initiés, ces réunions peuvent apparaître vivante et active, mais pour
ceux qui ont le plus de pouvoir, de nombreux arguments ont été entièrement prévisible à la fois dans la nature et
résultat. Ils ont été pleinement anticipés (peut-être en utilisant un procédé similaire à celui que vous lisez
maintenant), et de bonnes contre-arguments étaient prêts à mettre fin aux discussions.

Le plus important ou une question controversée est, plus l'investissement que vous avez à faire dans le
les individus impliqués. Idées tangage aveuglément à des groupes uniquement si vous êtes confiant vous avez la logique,
l'influence et les compétences de communication pour mener une salle pleine de gens puissants avec des opinions divergentes,
vers la direction que vous pensez sert au mieux le projet.

16.4.3. Faire une évaluation

Combinant tout ce que vous avez appris dans ce livre, vous avez à évaluer quelles sont les chances de
obtenir avec succès vos besoins satisfaits. Il est tout à fait possible que, avec une structure de puissance donnée, un
notamment besoin que vous avez est impossible à satisfaire. Cela ne veut pas nécessairement l'échec de quelqu'un, pas plus
à une contrainte d'ingénieur ou de commerce est. Dans l'évaluation de votre situation, vous devez réaliser que
les structures de pouvoir ont des limites, tout comme d'autres structures font.

Quelqu'un at-il la puissance dont vous avez besoin? Les ressources dont vous avez besoin tout simplement peut-être pas
disponible. Ils pourraient tous être engagés à d'autres tâches (et ne peuvent pas être redéployés) ou le
organisation ne dispose pas des ressources à tous. Si vous demandez quelque chose au-delà de la portée
de l'organisation, être prêt à faire des arguments très convaincants pour elle. Diviser un
grande demande en plusieurs petits, et leur donner la priorité. Peut-être ces demandes plus petites peuvent
 être obtenu par des personnes différentes ou sur une période de temps.
Comment avez-vous réussi à obtenir ce type de soutien dans le passé? Considérez
vos propres expériences obtenir ce genre de pouvoir. Ce qui s'est passé? Ce qui a bien et ce qui
n'a pas fonctionné? Si vous avez pas d'expérience avec ce genre de politique, trouver quelqu'un qui fait et obtenir son
conseils. Si vous continuer malgré tout, sachez que vous aurez cotes difficiles: celui qui a le
puissance que vous essayez d'utiliser l'expérience aura affaire à des gens qui veulent avoir accès à elle,
vous placer dans une situation désavantageuse (là encore, il est possible qu'ils ne sont pas aussi brillant ou à l'écoute

Page 302

la pensée politique que vous êtes).

Comment quelqu'un a été couronnée de succès à obtenir ce genre de soutien de leur part? Si personne ne
a été en mesure de convaincre le manager de l'équipe pour changer la méthodologie de développement,
savez que si vous essayez de le faire, vous êtes innove. Au contraire, si vous essayez de
faire quelque chose d'autres ont fait, savoir comment ils l'ont fait et apprendre de leurs expériences.

Quelle est la force sont vos arguments? Je ai eu des moments où je étais prêt à parier mon entière
réputation sur une demande. Je suis tellement convaincu que je avais raison que je l'habitude de la taille de mon
engagement à aider à convaincre les gens de sa valeur. D'autres fois, je ne étais pas aussi confiant, et je
angle mes arguments de manière appropriée. Sachez où vous vous situez et comment vous vous sentez vraiment à propos
ce que vous demandez. Organisez vos arguments et des points sur leur force, et de se concentrer sur la
les plus fortes.

Quelle approche et le style qui fonctionnera le mieux? Sera abandon par le bureau de quelqu'un et de dire: «Je
besoin de cette «être plus efficace que de faire un rapport de 10 pages ou de présentation? Selon le
facteurs qui précède, la culture de l'équipe, et les personnalités des personnes impliquées,
différentes approches seront plus efficaces. Il ya pas de règle stricte ici: votre meilleur guide est
à vous demander comment formelle ou informelle vous devriez être, et quel ton Vos demandes doivent
venir. Considérons brièvement quelques approches différentes avant d'investir dans l'un d'eux.

Qui d'autre est en compétition pour les mêmes ressources? Parfois, il est évident qui d'autre est
concurrence pour le même chose que vous devez. Budgets et le personnel sont toujours limitées, et il est généralement
parmi vos pairs que les ressources de votre patron sont partagés. Si vous avez de bonnes relations, il
il devrait être possible de se réunir avec leurs pairs et de discuter de vos différentes opinions et
arguments, luttant collectivement pour faire ce qui est mieux pour l'équipe (en fait, que le directeur commune
devrait faire exactement cela: la définition et la conduite du processus pour l'équipe). Si les relations
ne sont pas aussi forte, le faire sur votre propre. Pensez à ce que leurs arguments pourraient être, et comme
objectivement que possible, de les évaluer dans le contexte de votre propre. Enfin, pensez à comment les autres
percevra votre plan d'action. Les gens vont être en colère? En colère? Sentez-vous les trahissez?
Nip ces choses dans l'œuf. Parlez aux personnes impliquées si vous le pouvez, ou positionner vos arguments
d'une manière qui minimise ces réactions négatives.

Est-ce la bonne bataille à livrer? Reconnaître que ce besoin particulier est l'un des nombreux que vous
avoir. Utilisation influence et autres stratégies politiques vous coûte du temps et de l'énergie qui ne peut pas être
passé sur d'autres choses. Assurez-vous que ce que vous cherchez est la meilleure utilisation de vos ressources.
Par exemple, vous savez peut-être qu'il ya une demande plus importante que vous aurez besoin de faire
plus tard, de sorte qu'il pourrait être préférable d'économiser votre énergie pour l'époque.

Ce que vous ne pouvez pas voir, vous fait mal . Toujours reconnaissent qu'il ya des couches de politique et de pouvoir
que vous ne pouvez pas voir d'où vous vous situez. Plus l'organisation est plus cela est vrai. Deux
ou trois niveaux au dessus de vous (si il ya que beaucoup de niveaux), il peut y avoir une série de luttes et
les débats sur les questions que vous avez pas conscience de. Vos pairs, qui peuvent avoir des objectifs différents,
utilisent leur propre influence sur les mêmes pouvoirs que vous êtes. Pensez à ce qui pourrait se passer
sur-dessus de vous et autour de vous, et être à l'affût des sources d'information qui pourraient aider
vous améliorez votre point de vue.

16.4.4. Tactiques pour pouvoir influencer

Après que vous avez fait une évaluation, il est temps d'agir. Il ya des tactiques communes pour approcher
politique de l'organisation et engageant l'utilisation de la puissance des autres. Les tactiques suivantes sont les plus simples
et la plus courante; références pour plus de moyens suivront.

16.4.4.1 La demande directe

Dans la demande directe, vous faites la chose la plus simple possible: vous allez à la personne qui a le pouvoir
vous avez besoin, et vous lui demandez. Selon l'approche et le style que vous avez identifié (voir le
liste précédente), ce pourrait être une conversation informelle, un email, ou une réunion que vous avez mis ensemble
exclusivement à cet effet. Le plus formelle que vous en faites la demande, plus les chances sont que

Page 303

d'autres personnes seront impliquées dans la discussion. Le moins formelle, la plus directe de votre conversation
et demande pourrait être. Dans la figure 16-5 , A représente la personne avec la puissance dont vous avez besoin, et B, C,
et D sont d'autres personnes de votre équipe.
 Figure 16-5. La demande directe.

16.4.4.2 La conversation

Cette collaboration est une variante de la demande directe. Si vous êtes en compétition et B pour la même
ressources et ont discuté de la question ensemble, vous demandez à un pour répondre à la fois de vous et de résoudre
la question en tant que groupe. Les équipes qui ont des objectifs forts et bon travail d'équipe font ce genre de chose
naturellement et de façon informelle. Ils font confiance à l'autre pour travailler vers les objectifs du projet partagés, et ils
concéder volontiers les points valides même lorsque ces concessions diminuent leur propre pouvoir ou d'autorité.
Solides leaders et gestionnaires encouragent ce comportement car il minimise la nécessité de leur
participation: l'équipe finira par apprendre à résoudre les problèmes sur leur propre (ils apprennent à
reproduire les philosophies de A, même sans lui présente), et impliquent un seulement quand il ya
notamment les décisions difficiles qui doivent être faits.

16.4.4.3 L'utilisation d'influence (flanquer votre objectif)

Au lieu de dépendre de votre propre influence pour convaincre A, investir dans le soutien des autres dans le
organisation d'exprimer des arguments et des opinions similaires. Choisissez avec soin parmi les personnes figurant sur votre
équipe basée sur le degré d'influence qu'ils ont sur A. Si votre influence est faible, vous devrez peut-être
obtenir l'appui de plusieurs personnes.

En termes militaires, on appelle cela flanquant votre objectif. Au lieu d'aborder de front, vous
approcher de côté, en tirer avantage. Au lieu de traiter avec vos arguments, A doit également
répondre aux arguments d'une ou plusieurs autres personnes influentes. Lorsque ces arguments viennent
des gens égaux dans l'ancienneté ou le pouvoir de A, ils sont plus difficiles à réfuter. (Cependant, soyez prudent lorsque
obtenir l'avis de personnes ayant plus d'ancienneté à A sans présent. Cela peut être considéré
fin-terme, une tentative de contourner l'autorité de A. Il dépend de la culture du groupe et A de
personnalité.)

Facultativement, cela peut être combiné avec la demande directe (comme illustré sur la Figure 16-6 ). Autre
options comprennent la façon dont vous faites usage de l'influence que vous avez gagné. Il peut ne pas être nécessaire d'avoir
B, C, et D fait dans la chambre, ou même jamais parlé à A propos de la question en cause. Aussi longtemps que
vous avez leur approbation, vous pourriez être en mesure de parler pour eux, raconter une «Je pense que nous devons réduire cette
fonctionnalité. Je parlais à B, C, et D, et ils sont tous d'accord avec moi sur cette décision. "Bien sûr, être prudent
de ne pas dénaturer ce qu'ils ont dit, et toujours être prêt à mettre ces personnes dans la salle pour
régler la question (de revenir efficacement à une conversation).

Page 304

Figure 16-6. Utilisation influence pour flanquer un objectif.

16.4.4.4 L'utilisation à plusieurs étages d'influence

 Lorsque vous ne pouvez pas obtenir l'accès aux personnes dont vous avez besoin, travailler en arrière en bas de la chaîne d'influence ou
hiérarchie. Si C est la seule personne Un va écouter, et vous ne pouvez pas obtenir C seule, savoir qui a le
plus d'influence sur C. Puis l'approcher et faire de votre cas. De là, vous pouvez travailler avant
jusqu'à ce que votre influence atteint le point où vous en avez besoin appliqué. Voir Figure 16-7 .

Figure 16-7. L'utilisation à plusieurs étages d'influence.

16.4.4.5 L'utilisation indirecte de l'influence

À l'occasion, la meilleure façon d'influencer le pouvoir est de mettre les choses en mouvement, mais rester dans les coulisses.
Peut-être que A est deux ou plusieurs niveaux au dessus de vous dans l'organigramme, et il ne répond pas bien à diriger
demandes de personnes à votre niveau. Ou, peut-être un juste ne vous aime pas ou est actuellement bouleversée à vous
à propos d'une autre question (et que vous ne pensez pas qu'il est d'être objectif à ce sujet).

Dans cette situation, obtenir l'appui d'une autre personne pour faire cette demande pour vous. Cela pourrait être
votre manager direct, un pair de votre équipe, ou quelqu'un qui travaille pour un qui arrive à avoir
influence sur le problème en question.

La façon la moins sournoise de gérer cela est d'encadrer l'ensemble de chose autour de conversations. Parlez-en à C et
voir si elle est d'accord avec vous. Si elle le fait, lui demander si elle va parler à un sujet (voir Figure 16-8 ). Quand elle
va à un, elle n'a pas à mentir ou tromper: elle peut faire l'argument de son propre point de vue
parce qu'elle est d'accord honnêtement avec vous et votre demande. Si A demande alors à vous parler à ce sujet, ou

Page 305

si vous lui demandez à ce sujet plus tard, votre argumentation aura bénéficié de l'influence de C.

Figure 16-8. Influence indirecte.

16.4.4.6 La réunion du groupe

Réunions des situations politiques très complexes. Toute personne dans la salle ne peut prendre la parole et poser des questions,
l'application de leur pouvoir politique à la discussion d'une manière qui peut rendre les choses plus difficiles. Si
quelque chose d'important doit être décidé ou discuté, assurez-vous que vous avez évalué qui sera dans le
chambre avant la réunion se produit. Vous voulez avoir suffisamment de temps pour se préparer à utiliser votre pouvoir et
influence avant la réunion (pas nécessairement d'influencer la réunion, mais pour vous aider à préparer
ce qui aura probablement lieu). Toutefois, des réunions sont très commodes. Vous pouvez obtenir tout le monde dans le
même endroit au même moment, et faire face à de nombreux types de questions en même temps.

Avant la réunion, examiner quelles questions sont susceptibles d'arriver, et quel genre de réponses chacune
personne veut entendre. Si vous connaissez bien les gens, vous pouvez faire de bons jugements de ce qui vous attend
et se préparer à tout sur votre propre. Si vous ne le faites pas, demandez autour de vous. Avant la réunion, solliciter les commentaires des
des gens importants qui seront à la réunion. Obtenez leurs préoccupations et leurs grandes questions au début, puis soit
apporter des modifications le cas échéant ou de développer votre défense du plan actuel. Si vous possédez l'ordre du jour,
planifier en conséquence.
 Parfois, la mise
fonctionne en place
rarement biend'une
pour même réunioncomplexes
des questions peut être leouseul moyenOu
subtiles. depeut-être
résoudre que
une vous
question
avezde pouvoir.
identifié Email
que Sally a besoin d'entendre
de Bob et Mike en même temps pour être convaincu que votre recommandation devrait être suivie.
Courir réunions efficaces est une habileté de son propre (voir chapitre 10 ), mais pour l'instant, se rendre compte que la meilleure
vous êtes préparé pour les questions et débats susceptibles, le plus il sera facile pour exécuter la réunion en douceur
et dans un sens favorable. (Voir Figure 16-9 .)

Figure 16-9. La réunion du groupe peut être une politique imprévisible

situation.

16.4.4.7 Faire eux pensent qu'il est de leur idée

Page 306

Dans de rares cas, vous pouvez planter des graines et les arroser avec l'ego de quelqu'un d'autre. Il va comme ceci: vous
ne pense pas une demande directe se réunira avec succès. Ainsi, au lieu de forcer une discussion où vous
identifier un problème et demander de l'aide à trouver une solution. Vous ne proposez pas les réponses vous-même, mais
au lieu de poser des questions et faire des points qui les mènent doucement vers le résultat que vous voulez. Comme tout
manipulations, ce qui peut facilement se retourner et il exige subtilité et d'improvisation compétences quelques
posséder. Mais je l'avoue, il est parfois efficace avec les cadres supérieurs qui aiment à croire qu'ils ont raison
tout le temps.

16.4.4.8 Les références aux autres tactiques

La liste précédente ne couvre que les bases. Le sujet de la tactique politique remplit de nombreuses étagères de la bibliothèque.
La meilleure ressource unique, je l'ai trouvé est de Robert Greene Les 48 lois du pouvoir (Penguin, 2001), mais être
prévenu: un peu comme Dale Carnegie Comment se faire des amis (Pocket, 1990), vous aurez
ressentir l'envie de prendre une douche après vous le lisez. Influence par Robert Cialdini (Perrenial, 1998) est plus
sur le marketing de la politique de bureau, mais certains des principes psychologiques sont similaires.
Page 307

16.5. Connaître les règles du jeu

Les dernières considérations de gestion de projets impliquent le terrain de jeu politique. Les personnes qui
ont le plus de pouvoir définir quelles sont les règles de l'équipe qui va suivre: comment le pouvoir est obtenu, appliqué, et
distribué. Quand les gens agissent unethicallymanipulating et de tromper othersit est à ceux qui contrôlent
d'identifier et de réprimander ce comportement. Il devrait être dans leur intérêt de garder le terrain de jeu
relativement équitable et permettent les bonnes personnes à utiliser le système politique aux meilleurs extrémités pour le projet.

Toutefois, si les personnes au pouvoir ne sont pas prudents dans le maintien d'un terrain de jeu équitable, il est à vous, l'un des
les joueurs, pour comprendre les règles du jeu et d'ajuster en conséquence. Soit utiliser votre pouvoir pour
essayer de changer les règles, ou de les accepter pour ce qu'ils sont. Si les pratiques trompeuses et déloyales sont
commune, de comprendre ce que cela signifie pour les résultats des approches que vous avez le choix de prendre.
Ne présumez pas que d'autres sont altruistes, si il n'y a aucune raison de le faire. Je ne recommande pas que vous
prendre une approche du plus petit dénominateur commun et de copier le comportement des autres: voilà une éthique et
choix moral que vous avez à faire pour vous-même. Mais je dis que vous avez besoin d'être conscient de ce que
jeu auquel vous jouez et qui vous jouez avec. Ajouter cette information dans votre évaluation et
bénéficier de votre capacité à prédire comment les autres jouer.

16.5.1. Création de votre propre domaine politique

Peu importe combien frustrant la politique sont, en tant que gestionnaire de projet, vous avez le pouvoir de contrôler votre
propre terrain de jeu, comme le montre la Figure 16-10 . En outre, vous contrôlez la façon dont votre pouvoir est distribué à travers
l'équipe. Il ya deux choix de base que vous avez: faire de votre domaine un endroit sûr et juste pour jouer
des gens intelligents à travailler, ou permettent les problèmes et les symptômes de la plus grande équipe d'impact sur votre monde.
Celui-ci est facile: ne rien faire. Le premier exige du leadership et de l'emploi de beaucoup de
tactiques décrites dans ce livre.

Figure 16-10. Vous avez toujours le pouvoir de définir votre propre jeu
champ.

Les bons gestionnaires trouvent toujours des façons de protéger leur équipe. Alors qu'il est vrai que pour votre équipe à grandir
qu'ils ont à vivre des situations difficiles, un bon gestionnaire protège les gens juste assez pour qu'ils
peut être efficace encore également être exposés à des expériences réelles et les possibilités d'apprentissage. De même, si votre
gestionnaire fait un bon travail, elle vous protégeant de certains problèmes et situations et activement
travailler sur votre nom pour faire de votre monde plus facile à travailler. A tous les niveaux de la hiérarchie, ce genre de
un leadership proactif faut plus de travail et de maturité pour atteindre: mais qui est la nature du bien
gestion.

Donc, ne pensez pas que parce que vos Manager vous traite mal que vous devriez passer ce message à votre

Page 308
 rapports. En tant que gestionnaire, il est vous qui décidez comment votre propre équipe devrait être gérée. Ne pas passer
les attitudes, les habitudes, ou des tactiques que vous pensez que sont destructrices. Expliquez à votre équipe les différences de
le style ou l'attitude de travail, mais ne suivent pas le long de comportement que vous pensez est contre-productif.

La plupart des conseils dans ce chapitre et ce livre va à tous les niveaux de la hiérarchie organisationnelle. Si
il n'y a pas d'objectifs clairs à votre niveau, vous pouvez toujours en créer des clairs pour votre équipe. Si il n'y a pas
des pratiques claires et au-dessus de votre niveau de l'organisation pour la répartition des ressources, vous pouvez
établir votre propre pour les zones que vous dirigez. La même chose vaut pour la planification de projet, la communication ou
la prise de décision. Vous ne serez pas toujours bénéficier directement de ces efforts, mais votre équipe sera certainement.
Il devrait être plus facile pour eux d'être efficace et obtenir plus de travail parce que vous êtes fournissant
structure efficace que le reste de l'organisation ne possède pas. (4)

En fin de compte, un leadership proactif dans votre propre sphère d'influence est le meilleur moyen de faire croître votre propre
sources de pouvoir. Initialement, vous risquez de perdre la faveur de vos supérieurs pour travailler différemment qu'ils
faire. Mais au fil du temps, les gens aimeront le terrain de jeu que vous avez créé. Ils seront plus heureux et plus
efficace de travailler avec et pour vous que d'autres. Contrairement au statu quo du reste de la
l'organisation, la qualité du travail de votre équipe sera continuellement augmenter.

Page 309

16.6. Résumé

La politique est une conséquence naturelle de la nature humaine. Lorsque les gens travaillent ensemble dans des groupes,
il ya une quantité limitée de l'autorité, qui doit être répartie entre différentes personnes
différents désirs et les motivations.

Tous les dirigeants ont des contraintes politiques. Chaque exécutif, chef de la direction, ou le président a pairs ou supérieurs
qui limitent leur capacité à prendre des décisions. En général, plus la puissance d'une personne a, plus
complexes sont les contraintes qu'ils doivent travailler au sein.
 Il ya beaucoup
référent, de différents types de pouvoir politique, y compris les récompenses, la coercition, la connaissance,
et de l'influence.

La puissance est utilisé à mauvais escient quand il est appliqué d'une manière qui ne servent pas les objectifs du projet. Un manque de clarté
autour d'objectifs, l'affectation des ressources clair ou processus décisionnels, ou des malentendus
peut contribuer à l'abus de pouvoir.

Pour résoudre les problèmes politiques, à clarifier ce que vous avez besoin. Identifier qui l'a, et ensuite évaluer comment
vous pourriez être en mesure de l'obtenir.

Si vous êtes impliqué dans la gestion de projet, vous définissez les règles du jeu politique autour
tu. Il est à vous de décider comment fou ou il est juste.

Page 310

Remarques

Chapitre un

Chapitre deux

Chapitre Trois

Chapitre Quatre

Chapitre Cinq

Chapitre Six

Chapitre Sept

Chapitre Huit

Chapitre Neuf

Chapitre Dix

Chapitre Onze

Chapitre Douze

Chapitre treize
 Chapitre quatorze

Chapitre quinze

Seize Chapitre

Page 311

Chapitre un

[1]

[1]L'esprit du débutant est un concept d'introduction du bouddhisme zen. L'histoire canonique est celui de la tasse vide: si vous tenez fermement à
ce que votre tasse est remplie, votre tasse ne sera jamais avoir de la place pour de nouvelles connaissances. Voir de Shunryu Suzuki Esprit Zen, l'esprit du
(Weatherhil,
débutant 1972).
[2]

[2]Karl Popper était un philosophe éminent de la science

e siècle.
dans leVoir
20 http://en.wikipedia.org/wiki/Karl_Popper .
[3]

[3]Le rapport CHAOS (Le Standish Group) est un papier couramment référencé sur le budget, le calendrier, et les échecs généraux du logiciel
projets. Voir http://standishgroup.com/sample_research/ .
[4]

[4]De James R. Chiles, catastrophes Invitant: Leçons de la pointe de la technologie (HarperBusiness, 2002).
[5]

[5]Un bon résumé de la matrice et d'autres types d'organisation peuvent être trouvés dans de Steven A. Silbiger Le MBA de dix jours (William Morrow et
Company, 1993), pp. 139-145. Mais presque tous les livres de théorie de la gestion traite de ce sujet.
[6]

[6]Visite http://www.tompeters.com/col_entries.php?note=005297&year=1991 .
Page 312

Chapitre deux

[1]

[1]Une fois, lors d'un dîner à la Pizzeria Uno à Pittsburgh, mes amis et moi a dit une table serait prête en 10 minutes. Exactement 10
minutes plus tard, mon ami Tchad McDaniel posé des questions sur notre table. L'hôtesse nous a dit qu'elle serait prête en 10 minutes. Tchad a demandé, "Est-c
les mêmes 10 minutes ou 10 minutes différentes? "Elle n'a pas apprécié la plaisanterie.
[2]

[2]Vous pouvez trouver une bonne discussion comparative des méthodes traditionnelles et agiles pour le développement logiciel dans l'équilibrage et Agilité
Discipline: Un Guide des égarés , par Barry Boehm et Richard Turner (Addison Wesley, 2003).
[3]

[3]Voir Humphrey Gérer le processus de logiciel (Addison Wesley Professional, Janvier 1989) pour la couverture de la définition,
la compréhension et la gestion du changement des processus logiciels.
[4]

[4]«Comprendre et logiciels contrôlant les coûts," IEEE Transactions on Software Engineering , vol. 14, no. 10, Octobre 1988,
pp.1462-77; aussi dans de Barry Boehm Software Engineering Economics (Prentice Hall, 1991).
[5]

[5]Horaires fondés sur des éléments de travail de programmeur sont appelés horaires bottom-up parce que l'équipe les génère. Horaires basée sur
besoins de gestion sont appelés horaires top-down. Comme mentionné, il est généralement une négociation entre ces deux annexes
créer le calendrier utilisé par le projet.
[6]

[6]Ceci est parce que tout programme donné pour un projet est vraiment seulement un des nombreux calendriers possibles. Selon les éventualités
(Échecs de conception, révolution politique, la peste, etc.) sont inclus et considérés par le calendrier, un échéancier très différent peut être
créé pour la même quantité de travail. Si aucun effort n'a été investi dans l'exploration des points possibles d'échec qui devraient être considérés,
il ya peu de raisons de croire que le programme a une forte probabilité de transformer la façon dont il a été défini. Le calendrier auteur
n'a pas fait preuve de créativité ou assez sceptique pour générer éventuellement un calendrier probable.
[7]

[7]Presque tous les textes de gestion de projet décrit un procédé pour créer des structures de répartition du travail. Je vais toucher doucement sur ce nouveau dan
Chapitre 14 , mais si vous voulez une véritable couverture, commencer avec http://en.wikipedia.org/wiki/Work_breakdown_structure ou contrôle total du
Stephen Devaux (Wiley, 1999).
projet , par
[8]

[8]Kent Beck Extreme Programming Explained (Addison Wesley, 1999) propose un modèle de programmation dirigée pour la répartition du travail,
où les programmeurs auto-sélectionner des éléments de travail. L'esprit est bon. Une combinaison saine d'intérêt de programmeur, équipe de programmeur en c
des considérations de gestion (qui est bon à ce qui devrait apprendre quoi), et de conception d'ingénierie devraient conduire ces décisions. Ce
devrait être un compromis entre ce qui est mieux pour le projet et ce qui est le mieux pour l'équipe.
[9]

[9]PERT signifie Technique d'évaluation et de l'examen des programmes. La formule standard est: la meilleure estimation + (4 x plus probable) + pire
estimation / 6. Cependant, il ya des zillions de variations et des théories pour la meilleure façon de calculer les estimations pondérées.
[10]

[10]
Voir Beck et de Fowler planification Extreme Programming (Addison Wesley, 2002), pp. 60-62.
Page 313

Chapitre Trois

[1]

[1]Pour une autre comparaison de différents types de projets de logiciels, voir http://www.joelonsoftware.com/articles/FiveWorlds.html .
[2]

[2]Andrew Stellman, l'un des examinateurs de la technologie de ce livre, m'a menacé à plusieurs reprises à la violence physique, si je ne vous propose
références sur les logiciels qualità sujet profond qui est juste hors de la portée de ce livre (je l'ai lu de Robert Pirsig Zen et l'art de
Motorcycle Maintenance ). Deux endroits pour commencer: W. Edwards Deming sortir de la crise (MIT Press, 2000) et de Philip Crosby qualité
Est gratuit (Signet Books, 1992).
[3]

[3]Faisal Jawdat, un des examinateurs de la technologie de ce livre, m'a menacé avec des formes uniques de torture psychologique si je ne pas souligner commen
il est ironique que je suis ensuite allé travailler pour Microsoft.
[4]

[4]Ceci est une remarque délibérément inflammatoire conçu pour rendre les gens conscients de ces notes. Mais sérieusement: lorsque les concepteurs de concept
pour eux-mêmes, ils ont tendance à sur-conception, peut-être se livrer à la liberté de ne pas avoir un client de travailler pour.

Page 314

Chapitre Quatre

[1]

[1]Lisez Daniel Schacter de Les Sept Péchés de mémoire (Mariner Books, 2002). Ou regarder le film excellent, Memento . Ils ont tous deux devraient
vous aider à reconnaître comment la mémoire humaine limitée et peu fiable est.
[2]
 [2]De Pilotage Palm: The Inside Story of Palm, Handspring et la naissance de l'industrie Billion Dollar à main, par Andrea Butter
et David Pogue (Wiley, 2002), p. 72.

Page 315

Chapitre Cinq

[1]

[1]Sirènes d'avertissement devraient éteint chaque fois une équipe a la charte de faire un travail de percée, mais travaille de la même planification
processus utilisé pour la routine, le travail simple. Il est comme attendant à faire de la chirurgie du cerveau avec une trousse de premiers soins. Les objectifs et l
correspondance, donc être préparé à l'échec de manière désordonnées.
[2]

[2]Voir "Comment donner et recevoir des critiques," http://www.scottberkun.com/essays/essay35.htm .

[3]

[3]Toutefois, une formule simple pour savoir comment faire de l'eau et d'une boussole à partir de sable seraient probablement gagner pour meilleure idée de l'ann
perdu-dans-le-désert de la concurrence ". Ceci est un exemple d'un problème bien défini qui est incroyablement dur (de chapitre 1 , il est simple mais
difficile). Donc, si jamais les gens se plaignent que les exigences et la définition des problèmes de relever le défi de la résolution de problèmes, sachez que
ils sont plein de merde. Définitions Problème Point à laquelle montagne sommet à atteindre pour, mais ils ne disent rien sur la façon de résoudre tous les
défis pour la façon de monter là-haut.
[4]

[4]Un exemple de cela est le minoxidil, un médicament destiné à traiter l'hypertension artérielle. Il est avéré ne pas aider beaucoup avec cela, mais il était
efficace contre un tout autre problème: la perte de cheveux. Jugé contre un critère, la formule de minoxidil a été un échec; contre
un autre, il a été un succès. La formule était une bonne idée ou pas? Cela dépend de quel contexte vous considérez contre.
[5]
 [5]Il était un peu comme les lieux de travail décrites dans Peopleware , par Tom Demarco et Timothy Lister, ou planification Extreme Programming ,
par Kent Beck et Martin Fowler.
[6]

[6]Question 4.02, Février 1996.

[7]

[7]Recommandations: Steve Krug Ne pas me faire croire que des principes généraux de conception de sites Web; GUI Bloopers , par Jeff Johnson, qui
décrit les erreurs de conception d'interface utilisateur commune. Check-out http://www.upassoc.org/people_pages/consultants_directory/index.html
la facilité d'utilisation
d'embaucher un ou consultant en design ou contacter l'auteur à www.scottberkun.com/services .

Page 316

Chapitre Six

[1]

[1]Un sentiment capturé par la meilleure They Might Be Giants chanson, "ancien": "Cette journée sera bientôt à sa fin, et maintenant il est encore tôt, et
maintenant il est encore tôt. Et maintenant il est encore tôt. "
[2]

[2]Du point de vue PM, il ne souvent pas d'importance ce ou lorsque les checkpoints sont, à condition qu'ils aient l'effet que le PM doit
qu'ils aient. Il est souvent préférable de laisser l'équipe de proposer les points de contrôle, car cela améliore les chances qu'ils vont croire en eux et de respect
leur.
[3]

[3]Voir http://www.ms.lt/ms/projects/toolkinds/organize.html pour une bonne liste de solutions de rechange.

[4]

[4]Voir «L'art de l'interface utilisateur de prototypage": http://www.scottberkun.com/essays/essay12.htm .

[5]

[5]Je l'ai discuté avec d'autres gestionnaires sur ce point très. Ils ne pouvaient pas imaginer ne pas permettre leur équipe au code à pleine vitesse tout le temps,
indépendamment du fait que les programmeurs ont compris le sens du projet allait. Si les programmeurs étaient ralenti, puis le projet
doit être inactif, non? Faux. Il est de l'hypocrisie ici: si le temps du programmeur est si précieux, l'utilisation de celui-ci doit être bien planifiée. "Quoi
seront les programmeurs faire? ", ils me demandent. Et je dirais,« Ils vont attendre un plan digne de leur temps, ou aider l'équipe à trouver. "
[6]

[6]Notez que si votre équipe pourrait ne pas être responsable pour les utilisateurs, quelque part le long de la façon dont votre algorithme ou base de données ne r
avec les personnes vivant, et les décisions que vous ferez un impact sur eux.
Page 317

Chapitre Sept

[1]

[1]Pour cette raison, certaines équipes mettent spécifications dans le contrôle source, avec des serrures / check-out check-in pour soutenir la capacité des multipl
personnes de modifier le document sans piétiner les uns des autres. Il est généralement une douleur à faire, mais ça vaut le coup. Dans des nouvelles similaires,
indiquer ce qui a changé d'une version à gagner du temps. Rien de plus frustrant que d'errer à travers une doc, à essayer de comprendre
ce qui est différent de la version précédente. Différents outils ou les auteurs qui se connectent changements dans la doc lui-même ("3/20 / 2004added détail pou
l'article 6 ") sont deux moyens communs pour aller.
[2]

[2]Comme sardonique que cela puisse paraître, il est vrai. En fait, le concept de la gestion des connaissances est en partie basé sur cette notion de fournir
la documentation des choses qui seraient autrement disparaissent si une personne devait, dirons-nous, pas se rendre à la prochaine version.
[3]

[3]Il est toujours un signe d'avertissement pour moi de voir de belles caractéristiques ou largement longues. Elle implique que quelqu'un est inquiet plus sur les s
à propos de ce qui se passe hors de la porte. De même, de très longues spécifications sont souvent un indicateur que personne réellement lu la chose. Je suppose
ont été la fabrication d'armes nucléaires ou de matériel chirurgical (ou les systèmes embarqués pour eux), je me sentirais différemment, mais la plupart des proj
ne nécessitent pas de niveaux implacables de détail.
Page 318

Chapitre Huit

[1]

[1]La formation par la simulation est la meilleure façon de développer les compétences décisionnelles. Je l'ai trouvé simulations mettre les étudiants au centre de
l'expérience, à la place de l'enseignant. Voir Serious Games par Clark Abt (Viking, 1970). Je l'utilise ces idées dans mes propres cours.
[2]

[2]Le MBA de dix jours par Steven Silbiger (Quill, 1999) comprend un chapitre compact et simple sur l'analyse quantitative et fondamentale
théorie d'arbre de décision. Dans l'ensemble, le livre fait un bon travail à fournir une couverture de résumé des sujets de base dans la plupart des MBA majeur
programmes.
[3]

[3]La phrase complète est "mort par mille coupures», comme dans coupures de papier. Beurk.
[4]

[4]Cela est souvent vrai dans les situations concurrentielles. Une action rapide peut changer ce qui, dans la terminologie militaire est appelé le fardeau d'incertitu
prenant
Par des mesures précoces vous forcer le concurrent dans une posture réactive et les forcer à répondre. Pour ce faire il faut effectivement le
capacité à concevoir une stratégie et faire des plans cohérents à la volée: une compétence peu de gens possèdent ou sont prêts à parier leurs armées / entreprises
sur. Souvent, celui qui se sent qu'ils ont un avantage (ressources, compétences, terrain) dans leur stratégie prend ce genre d'initiative.
[5]

[5]Une brève histoire de la liste avantages / inconvénients peut être trouvé dans le très court pamphlet, "Comment prendre une décision" (2003, Qui est là, Inc.),
qui peuvent être achetés à partir de http://www.knockknock.biz . En 32 pages divertissantes, ce titre couvre les techniques comme le retournement des pièces,
ciseaux
rock à papier, eenie meenie minie moe, etc.
[6]

[6]La faiblesse du rasoir d'Occam est sa vulnérabilité aux maximums locaux. Par exemple, si vous vous tenez sur une colline, et ne pouvez pas voir quoi que ce
l'horizon plus grand que vous, la conclusion la plus simple est que vous étiez sur le point le plus haut sur la Terre. Il peut y avoir des informations que vous ne l
avoir, ce qui, si vous l'aviez, invaliderait votre conclusion simple.
[7]

[7]Avais-je raison? Eh bien, il est impossible de dire. Le lendemain, je pris ma décision, notre développeur principal, Chee Chew, a décidé de faire le travail sur
son propre. Sans moi ou quelqu'un d'autre dire, il a travaillé une journée et une nuit et a obtenu le solde du travail effectué, sur son propre temps . La
estimation initiale de cinq jours avait été de quelqu'un de moins expérimenté avec le composant, et il a réussi à faire les pièces de base dans environ
la moitié de ce temps. Par hasard, je me suis présenté à son bureau le lendemain et a trouvé une surprise. Il me sourit comme il me l'a montré la version de
le navigateur avec ses modifications. Je suis très heureux et horrifié en même temps.

Page 319

Chapitre Neuf

[1]

[1]
 Tour
Brueghel
de Babel
étaitpeinture,
un peintre
et sa
flamand
biographie
dans complète,
le 16ème siècle,
au http://en.wikipedia.org/wiki/Pieter_Brueghel_the_Elder
célèbre pour ses peintures de paysages et de scènes paysannes.
. Vous pouvez voir son
[2]

[2]Comme le dit Peters, "Si vous n'êtes pas un vagabond régulière [dans les bureaux des gens], le début de l'errance sera, en un mot, terrifiant ...." Il
prend du temps de construire ce genre de rapports avec les gens, surtout ceux qui ont des raisons de craindre que vous.
[3]

[3]Je ne pouvais pas trouver des références pour ce cadre. Je l'avais entendu, transmis, reçus et compris, mais malgré mes recherches, je pouvais
ne trouvez pas une source pour elle. Je rajoutés les deux derniers sur mon propre. Un autre bon cadre est le modèle Satir, qui Weinberg utilise dans plusieurs de
livres. Voir Le Satir Modèle: thérapie familiale et au-delà , par Virginia Satir et al. (Science et le comportement Books, 1991). Oui, ceci est une
réserver en thérapie. Et oui, si cela vous dérange, il est probablement exactement le genre de livre que vous devez lire.
[4]

[4]Parfois, l'accord peut être aussi simple que de décider quelle personne arrive à prendre une certaine décision. Vous ne devez avoir
appui unanime pour que quelque chose d'accord qu'une personne est dans la meilleure position pour prendre une décision. Voir chapitre 8 .
[5]

[5]Une liste complète des coups bas de conversation, en catégories pratiques et cotée avec des exemples, peut être trouvé à
http://www.vandruff.com/art_converse.html . S'il vous plaît, s'il vous plaît, s'il vous plaît ne pas utiliser cela comme un playbook à suivre.
[6]

[6]Chaque mesure du travail a ses problèmes. Lignes de code impliquent la quantité, pas la qualité. Heures impliquent durée du travail, pas l'intensité.
[7]

[7]Le malin, mais sournois, chose à faire est de planifier d'inviter les deux équipes, peu importe qui gagne. Mais ne leur dites pas que, jusqu'à la
compétition est terminée.

Page 320

Chapitre Dix

[1]

[1]Il est embarrassant, mais je gardé ces petites notes de satisfaction autour email, probablement parce qu'il n'y avait pas assez d'éloges à l'extérieur
voler autour de la haute direction. IM et le courriel permettent pas d'équivalent à la tête hoche la tête ou sourires qui donnent la rétroaction secondaire
pendant les réunions: peut-être ces emails indésirables compensent que d'une certaine façon.
[2]

[2]Une histoire peut-être apocryphe à propos de Victor Hugo décrit une utilisation particulièrement intelligente de communication compact. Lorsque Les
a été publié, Hugo a envoyé un télégramme à son éditeur demandait ce que la réponse initiale était. Son télégramme était aussi concis que possible,
Misérables
composé d'un caractère "?". La réponse qu'il a reçue comprenait également un caractère. "!". Apparemment, les ventes initiales étaient
spectaculaire. Si il ya une leçon à tirer ici, il est que deux personnes qui se connaissent et se comprennent mutuellement et peuvent souvent communiquer plus
efficacement que ceux qui ne le font pas. Ceci est encore une autre raison pour l'importance de développer les relations avec les collègues.
[3]

[3]Il ya probablement une loi de communication qui affirme que le mode dominant de la communication (e-mail) dépend encore de la
Mode précédemment dominante (de téléphone) que Email
son repli IM
téléphonecourrier postal
des signaux de fumée
face à face
etc.
[4]
 [4]Deux bons endroits pour commencer sont Fieldbook de l'animateur par Tom Justice (American Management Association, 1999) et de l'exploitation minière
Gold Group par Thomas A. Kayser (McGraw-Hill, 1991).
[5]

[5]Pour plus d'informations sur SCRUM, voir http://c2.com/cgi/wiki?ScrumMeetings ou http://www.controlchaos.com/ .

Page 321

Chapitre Onze

[1]

[1]Une habitude destructrice commune, surtout chez les hommes, est de prétendre que rien ne vous dérange. Ceci est appelé le déni. À un certain
niveau émotionnel, nous sommes affectés par tout. Ces gens avec plus de conscience sont calledget prêt pour thishealthy. Avoir des sentiments et
les explorer. Ils sont bons pour vous.
[2]

[2]Ceci est culturelle. Je suis allé sur les équipes qui avaient une culture de la très bonne communication. Les choses restèrent intime même avec sept ou huit
personnes dans la salle, même sur des sujets controversés. Cependant, la plupart des équipes ne disposent pas de ce genre d'intimité. Pour couvrir le terrain rapi
commencer à petite échelle, l'élan, puis amener les gens à.
[3]

[3]La loi de Brook, en gros, est que l'ajout de personnes a deux effets négatifs: d'abord, il faut du temps pour eux de se lever à la vitesse; d'autre part, la
overhead requis pour obtenir des augmentations fait quoi que ce soit. Donc, même dans les meilleures situations, l'ajout de personnes supplémentaires auront un
Mais il ya des exceptions.
[4]

[4]Cela fait partie de la loi Pace de Marque. De Bord question annuelle du magazine, qui, en 2004, était "Quelle est votre loi?" Voir
http://www.edge.org/q2004/page6.html#brand .
[5]

[5]Voir aussi la négociation pour obtenir un avantage par Richard Shell (Penguin Books, 2000). Il fournit plus de tactiques et techniques que Arriver à
Oui , et il fait un excellent deuxième livre.
[6]

[6]Ceci est où les négociations deviennent complexes. Si Fred ne crois pas que vous êtes prêt à utiliser vos options, il verra votre BANTA
différemment. Il peut vous dire si ("Vous ne me laissez pas assis ici et mourir, voulez-vous?"). Les négociations deviennent complexes lorsque les gens bluff, m
leurs intérêts, ou la confiance manque dans l'autre partie. Dans des situations moins ridicules, les choses ont tendance à se normaliser avec Bantas sont exécutée
entreprise
Si un peut vraiment obtenir un meilleur accord, ils finiront. Si elles ne peuvent pas, ils vont céder.
[7]

[7]Pour une introduction informelle à la dynamique émotionnelle de base, essayez merveilleux de Leo F. Buscaglia vivre, aimer et d'apprentissage (Ballantine
Livres, 1985). Pour une introduction plus formelle, essayez Sur Bradshaw: La famille de John Bradshaw (Communications Santé, 1990).
 [8]
[8]Une façon plus favorable à regarder start-ups est que la force créatrice nécessaire pour innover vient seulement d'un petit groupe serré de personnes
travailler dur. Une «pénurie» de personnes est souhaitable, car elle donne à chacun une autonomie considérable. Les pirates et les Peintres de Paul
Graham (O'Reilly, 2004) présente des arguments intéressants sur les récompenses et les risques du travail de démarrage.

Page 322

Chapitre Douze

[1]

[1]Rob et Eric sur le terrain Y Samuel Douglaston, New York m'a appris tellement plus sur le coaching et la gestion de la
l'école secondaire et les entraîneurs de basketball collégial je devais plus tard. Si vous savez ces gars-là, s'il vous plaît dire à eux pour obtenir en contact avec m
[2]

[2]Dans de nombreuses organisations militaires, seules les situations décrites comme des incidents ou des missions exigent débriefings. Donc, si quelque chose d
arrive, et il est pas vraiment la faute de personne, et l'impact est minime, il pourrait y avoir pas de leçon à tous, et ça ne vaut pas l'effort de faire
une grosse affaire hors de lui. En fait, la meilleure réponse est peut-être d'exprimer ce que votre approbation est pas nécessaire pour des questions mineures sem
Page 323

Chapitre treize

[1]

[1]Le bar était pas "cette personne peut-elle tout faire?", Mais "Est-ce que cette personne savoir quand demander de l'aide pour les situations qui sont au-delà
eux? "Ceci est juste un autre genre de situation à traiter.
[2]

[2]Pour une discussion de plus à dire oui et non, voir l'essai de Richard Brenner, "Dire non: A Short Course" au
http://www.ayeconference.com/Articles/Sayingno.html .
[3]

[3]Beaucoup de manuels de gestion de projet couvrent l'analyse du chemin critique en détail. Un résumé peut être trouvé à
http://en.wikipedia.org/wiki/Critical_path . Pour une couverture plus approfondie, voir Contrôle total du projet de Stephen Devaux (Wiley, 1999).

Page 324

Chapitre quatorze
 [1]

[1]Karl von Clausewitz était un penseur militaire prussien du 19ème siècle influente. Voir http://en.wikipedia.org/wiki/Clausewitz .
[2]

[2]CMM, le modèle de maturité des capacités pour le développement d'un logiciel développé par l'Institut de génie logiciel, a défini plusieurs
les meilleures pratiques autour de la mi-jeu de gestion au niveau du projet. Voir http://www2.umassd.edu/SWPI/sei/tr25f/tr25.html ou
http://www.sei.cmu.edu/cmm/ .
[3]

[3]Il existe des moyens formels pour ce faire. Certaines équipes ont une réunion hebdomadaire où le pipeline pour chaque programmeur est brièvement
discuté: tout le monde connaît les éléments de travail pour l'équipe et pour les individus, pour la semaine. Le PM est là pour veiller à tout moment
questions sont intégrés dans le pipeline.
[4]

[4]Sur des projets à forte intensité de l'assurance-chômage, il était la gestion du pipeline de codage qui nous a permis d'itérer sur la conception. Nous aimerions g
de faire partie de l'élément de travail A, l'obtenir dans le laboratoire d'utilisabilité, apprendre une tonne de trucs formidables, affiner la conception, et ensuite fai
Pourvu que nous avons gardé le pipeline complet, et ne pas dépasser le budget pour le temps de dev ou un jalon, les concepteurs pourraient faire le travail de co
parallèle avec l'équipe de programmation.

Page 325

Chapitre quinze

[1]

[1]À somme nulle est un terme de la théorie des jeux qui signifie un ensemble fini de ressources. Tranchage un gâteau au chocolat en morceaux est un jeu à som
De plus, il ya moins pour vous. Cependant, aller à un café infiniment bien approvisionné et en ordonnant des tranches de gâteau est un jeu à somme nulle non: n
reçoivent chacun autant que nous voulons. Miam.
[2]

[2]Alternativement, les critères de sortie définis sont moins bien, plus vos chances de toucher vos dates. Le cas limite est d'avoir pas de sortie
critères, où vous dépendra de l'opinion et de la gestion caprice de comprendre lorsque vous avez terminé.
[3]

[3]Pour en savoir plus sur les plans de test et la méthodologie d'assurance qualité en général, voir Gérer le processus de test , par Rex noir (Microsoft Press,
vous êtesSisérieux au sujet de la qualité, il devrait faire partie du document de vision du projet et le processus de planification.
1999).
[4]
 [4]De Weinberg Qualité Logiciel de gestion , Volume 1: Système de Pensée (Doresett House, 1992) pp 272-273..
[5]

[5]Ibid.
[6]

[6]Un bon résumé des outils et des processus qui peut être utilisé pour ce peut être trouvé à
http://www.martinfowler.com/articles/continuousIntegration.html .
[7]

[7]Voir l'essai Bug Tracking indolore de Joel Spolsky au http://www.joelonsoftware.com/articles/fog0000000029.html .

[8]

[8]Deux livres peine de regarder si vous avez besoin de ce genre de rigueur: Tom Demarco projets de logiciel de contrôle (Prentice Hall, 1986) et
Gerald Weinberg Qualité Logiciel de gestion , Vol 1: La pensée systémique (Dorset House 1991).
[9]

[9]Test de développement piloté est une approche utile pour faire face à la qualité de l'ingénierie à l'heure, et en évitant les grosses vagues de entrant
bogues. Voir http://en.wikipedia.org/wiki/Test_driven_development .
[10]

[10]
De Weinberg Qualité Logiciel de gestion de vol 1: Systèmes de la pensée (Dorset House 1991) p. 250
[11]

[11]
Bien sûr, le mieux conçu le logiciel est, plus il est facile de prédire l'impact des changements.
[12]

[12]
Voir http://www.scottberkun.com/essays/ pour quelques conseils sur bien faire les autopsies.
[13]

[13]
Les dirigeants d'un projet auront fort investissement affectif dans ce qui est arrivé et auront du mal à être objectif. Toutefois, un expert
étranger a aucun investissement émotionnel ou histoire personnelle, et a donc de meilleures chances de succès l'examen, la compréhension,
rapports et faire des recommandations sur le projet.

Page 326

Seize Chapitre

[1]

[1]Ne jamais sous-estimer la valeur d'un espace de travail bien placé. Il m'a beaucoup appris à propos de ce qui se passait au dessus de moi dans la gestion de
cet emplacement. Il m'a permis d'avoir des discussions informelles avec toutes sortes de gens qui étaient à la recherche pour Chris et d'entendre innocemment
conversations de couloir importants. L'inconvénient est que le grand patron était juste à côté. Si cela avait été un gestionnaire de contrôle ou
les questions de microgestion, il y aurait de graves inconvénients à un tel emplacement.
[2]

[2]De le dictionnaire Random House College (1999)

[3]

[3]Je sais que je suis en esquivant le débat éthique pour ce comportement est immoral, ou même quels types de projets peuvent être considérés comme ayant des
Cependant, je dirai que backstabbing, le mensonge, de la tromperie actes inventifs, travaillent généralement contre un projet. Ils prennent gains à court terme au
détriment de la valeur de l'équipe à long terme et la confiance.
[4]

[4]Le défi de pousser pour le changement organisationnel est significative. Certainement lire sur le sujet avant d'aller trop loin sur votre propre.
Commencez avec Leading Change , John P. Kotter par, Harvard Business School Press, 1996.
Page 327

Bibliographie annotée

Livres et autres médias apparaître dans cette bibliographie pour l'une des deux raisons: soit ils ont eu le plus
influence sur mes idées, ou bien ils ont le plus de valeur pour la lecture et l'exploration future.
Page 328

Philosophie et stratégie

de Botton, Alain, les consolations de la philosophie (Vintage, 2001) ISBN 0679779175

La philosophie de gestion tire une grande partie de la philosophie orientale et occidentale classique, et ce
est un bon endroit pour commencer. Je comprenais et souvenais plus sur la philosophie occidentale à partir
ce petit livre que plusieurs années d'enseignement de la philosophie à l'université. de Botton écrit des essais
qui sont à court, susciter la réflexion, informel, amusant, agréable et mémorable. Ceci est l'une
livre je donne aux gens quand ils disent qu'ils sont intéressés à la philosophie, mais ne savent pas où
Démarrer.

Russell, Bertrand, La Conquête du bonheur (Liveright Publishing Corporation, 1930) ISBN

0871401622

Les gens heureux font de meilleurs gestionnaires. Bien que je doute le bonheur peut être vaincu, ce livre
va vous aider à démêler ce qui vous rend heureux et pourquoi. Russell était un philosophe de premier plan dans
du 20ème siècle, et en dépit de cela, il écrit très bien. Il avait quelque chose d'un
fauteur de troubles et libre penseur et il montre dans son écriture. Je l'ai lu ce livre sur un voyage sur la route
avec Chris McGee de Seattle à Banff. Je commencé sur le voyage assez malheureux avec la vie en général,
et revint prêt à faire des changements. Ce livre, Chris, et le voyage lui-même étaient tous influente
dans ma décision de quitter Microsoft et commencer à écrire.

Tzu, Sun, Art de la guerre , Pocket Edition (Shambala, 1991) ISBN 0877735379

Ce fut le premier livre de philosophie orientale je lis que fait aucun sens pour moi. Je le recommande
pour sa simplicité et sa très courte durée. Il est écrit comme un livre sur la stratégie militaire, mais a
de nombreuses applications pratiques. Depuis de nombreuses années je portais l'édition de poche de ce livre dans mon
veste, jusqu'à ce que les couvertures dissipés et la moitié des pages ont été écornés (il ya une dizaine d'années je suis tombé sur
Faisal Jawdat, qui finirait par être un examinateur de la technologie pour ce livre, à la CMU Étudiant
Centre, et nous avons été à la fois étonné de voir l'autre tirer la même édition de ce livre de sa
poche). Si vous trouvez ce livre trop obscure ou abstraite, essayer le plus direct et le plaisir Essential
Crazy Wisdom par Wes Nisker (Ten Speed ​Press, 2001) ISBN 1580083463.

Page 329
 Psychologie

Zeldin, Théodore, Une histoire intime de l'humanité ( Vintage, 1998) ISBN 0749396237

La nature humaine est plus dynamique et complexe que nous nous donnons crédit pour. Ce
collection non traditionnels d'essais basés sur des entretiens personnels offre un aperçu de ce qui fait
nous qui nous sommes. Je trouve ce livre déplacer de façon inattendue. Il est pas un livre scientifique formelle à propos
la psychologie: il est plus d'un recueil d'essais par un homme très sage, curieux et réfléchi.

High Noon . 1952. Lionsgate / Fox. 2004. DVD.

Un film western classique d'un shérif d'essayer de faire ce qu'il pense être juste. Leadership et
l'intégrité inévitablement mettre un individu dans des situations où ils peuvent avoir de rester seul. Ce
film explore la psychologie de leaders et les suiveurs dans des situations difficiles. Il éclaire pourquoi
les gens sont définis autant par ce qu'ils sont prêts à le faire, que ce qu'ils ne sont pas. Il est également juste un
bonne occidentale, avec Gary Cooper.

Douze hommes en colère . 1957. MGM / UA vidéo. 2001. DVD.

Un autre film important sur la psychologie et la dynamique de groupe de l'homme dans des situations difficiles.
Henry Fonda joue un membre du jury qui croit quelque chose de tous les autres ne le fait pas. Il a ensuite
tente de convaincre une salle pleine de gens frustrés que ce qu'ils croient passionnément ne peut pas être
vrai. Comme High Noon , des questions sur le pouvoir, l'influence, l'intégrité, et la croyance sont centrale
thèmes, et tous sont pertinents pour les personnes qui dirigent ou gèrent des autres. Il est également un classique de
cinéma, réalisé par Sidney Lumet (auteur du profil fortement recommandé de la
processus cinématographie, Making Movies , Vintage, 1996), et mettant en vedette Henry Fonda.

Page 330

Histoire

Boorstin, Daniel J., Les Créateurs: A History of Heroes of the Imagination (Vintage, 1993) ISBN
0679743758

La série de Boorstin de trois livres d'histoire ( Les Découvreurs , Les Créateurs , Les Demandeurs ) sont
valent leur pesant d'or. Les Créateurs suit l'histoire occidentale du travail créatif, de
architectes, peintres et écrivains, aux ingénieurs. Il trouve des anecdotes et des histoires qui font leur
activités directement pertinentes et d'inspiration pour tous ceux qui essaient de faire un travail de création aujourd'hui.

Kidder, Tracy, Soul of a New Machine (Back Bay Books, 2000) ISBN 0316491977
 Ce livre reflète l'esprit de la révolution de l'ordinateur au début, lorsque l'accent était encore sur
matériel et génie électrique. La force de ce livre est la capacité de Kidder pour capturer la
ingénieurs d'entraînement compulsifs et obsessionnels ont à construire et à créer. Malgré le fait que la
histoire est centrée sur les machines et les mini-ordinateurs Data General qu'ils construisaient à la fin
1970, je trouve encore ce livre mieux saisir les défis personnels et d'équipe de travail dans le
secteur technologie.

Kranz, Gene, échec est pas une option (Berkeley, 2001) ISBN 0425179877

Un compte passionnante des expériences de Kranz dans le groupe de direction de vol de la NASA. Il couvre le début
missions de mercure, tout au long de Apollo 13 . Il ya beaucoup de leçons ici pour projet
les gestionnaires sur le travail dans des délais, des engagements de livrer sur ce que sont
efficacement expériences, et comment diriger et gérer ingénieurs sous pression.

Page 331

La gestion et la politique

Farson, Richard, de gestion de l'absurde (Free Press, 1997) ISBN 0684830442

En utilisant les paradoxes et les irrationalités du comportement humain dans les organisations, ce livre
explore ce bon comportement de gestion est tout au sujet. Il a été un amusement lu principalement parce qu'il
parle beaucoup des sujets autres livres ont peur de couvrir. Farson prétend une certaine
problèmes sont compréhensibles et résoluble seulement avec l'aide de notre intuition, et que
la dépendance exclusive sur la logique nous amène souvent des ennuis.

Fisher, Rodger, Getting to Yes (Penguin Books, 1991) ISBN 0140157352

Meilleur livre de négociation par page de lecture, je l'ai trouvé. Il est bien écrit, simple, et
pratique. Hautement recommandé.

Klein, Gary, Sources of Power: Comment les gens prennent des décisions (MIT Press, 1999) ISBN 0262611465

Ce fut une source primaire pour le chapitre 8 . Je trouvais des explications et la recherche dans ce qui a aidé
m'a fait comprendre beaucoup de mes propres croyances au sujet de la prise de décision.

Silbiger, Steven, de dix jours MBA (Quill, 1999) ISBN 0688137881

Je l'ai lu beaucoup de livres d'affaires général, mais cette est celui que je reviens le plus souvent. Cela couvre
10 sujets de base de nombreux programmes de MBA, la coupe à la chasse sur les idées de base et
philosophies de chacun. Il se lit comme des notes pour un bon manuel: il est clair que certains
formalismes ont été évitées et l'auteur fournit à la place sa propre moins formelle mais easier-
 à suivre les explications de certains concepts.

Rapide, Thomas, jeux de pouvoir: Un guide pour optimiser le rendement et la réussite en affaires (F. Watt,
1985) ISBN 0531095827

Ramassé cette place sur la vente en rack utilisé. Devenu l'une des références les plus utiles pour le chapitre 16 .
Le livre est vaguement auto-assistance en ce qu'elle tente de donner un cadre pour la politique de l'organisation
et des conseils sur la façon d'atteindre certains objectifs. Il a donné le meilleur résumé de la tactique que je trouvais,
et géré les questions éthiques relativement bien. Epuisé de cette écriture, mais devrait être
disponibles dans les librairies en ligne utilisés.

Page 332

Science, l'ingénierie et l'architecture

Marque, Stewart, Comment Bâtiments savoir: Qu'est-ce qui se passe après ils sont construits (Penguin Books, 1995) ISBN
0140139966

Ce texte a accéléré ma conviction que les choses que je savais au sujet des projets et de la conception de la
secteur de la technologie avait application et la pertinence généralement dans le monde. Ceci est un de mes
livres préférés sur l'architecture en raison de la façon dont il est physiquement accessible: beaucoup de photos
et des exemples. Marque écrit et pense comme un bon professeur, rendant les choses intéressantes, et
occasionner drôle, comme il conduit votre curiosité sur des chemins intelligents, Épiphanie chargé.

Chiles, John, invitant catastrophes: les enseignements de la pointe de la technologie (Harper d'affaires 2002) ISBN
0066620821

De aérienne se bloque à des naufrages plates-formes pétrolières, les histoires dans ce livre soulignent la relation directe
entre l'ingénierie complexe et leurs faiblesses, simples, non linéaires fragiles qui peuvent conduire à
catastrophe. Bien qu'il ressemble plus à une série de longs essais sur les catastrophes spécifiques que un livre
avec un thème central ou connecté, je trouve toutes les histoires de catastrophes technologiques
intéressant et provoquer la réflexion.

Croix, Hardy, Ingénieurs et Ivory Towers (Ayer, 1952) ISBN 083691404X

Trouvé deux références à ce livre le même jour, dans des matériaux assez indépendants, et ressenti
obligé de le déterrer, et trouvé de l'or. Il est une diatribe prolongée par un ingénieur sur l'état de
la profession d'ingénieur circa 1952. Il questionne beaucoup des attitudes populaires parmi les
ingénieurs, de hubris générale, d'un manque de connaissance esthétique ou artistique, et fournit des conseils au
une meilleure, vue profonde de ce que l'ingénierie devrait être d'environ. Je trouve que ce livre est ce que je ferais
attendu de Samuel Florman existentielle Pleasures of Engineering .

Petroski, Henry, à l'ingénieur est humain: Le rôle de l'échec dans la conception réussie (Vintage Books,
1992) ISBN 0679734163

Un classique sur la fatalité de l'échec et comment apprendre d'elle est un élément clé de l'ingénierie
progrès. Petroski analyse plusieurs catastrophes d'ingénierie du pont de Tacoma Narrows à
la navette spatiale Challenger, et expose les échecs théoriques et tactiques impliqués. Bien
écrite, court, et à certains égards une source d'inspiration.
Page 333

processus de logiciel et de la méthodologie

Beck, Kent, Extreme Programming Explained: place au changement (Addison Wesley, 1999) ISBN
0201616416

Ce petit livre clarifie l'intention et la philosophie de l'XP et donne quelques rudiments pour
comment y arriver. Il est convaincante dans l'esprit et la passion, mais lit souvent plus comme un
spirituelle d'un Playbook. Il explique itérations, la vitesse, les histoires et les autres processus clés
de XP, tout en exprimant simultanément leurs avantages. Je examiné un grand nombre de l'autre extrême
et les livres de programmation agile, et nous avons constaté qu'ils généralement se chevauchent de façon significative avec le
la couverture ici. Programmation planification Extreme (également par Beck) était le seul autre texte que je XP
trouvé assez utile pour générer des notes de. Il est plus procédurale que «le changement étreinte"
(Bien que le premier semestre ne chevauche fortement avec elle).

Brooks, Fred, The Mythical Man-Month (Addison Wesley, 1995) ISBN 0201835959

Ce grand classique, d'abord publié il ya plus de 20 ans, frappe toujours à la maison sur un grand nombre majeure
des points. Brooks écrit bien, utilise des métaphores forts, et vous laisse sentir comme vous venez de
conversé avec un homme beaucoup plus sage et plus conviviale que vous êtes. Il est peut-être le plus bien
connu et très respecté livre sur la gestion des projets de développement de logiciels.

Bullock, James et Gerald Weinberg, Table ronde sur la gestion de projet : UNE FORME Forum de dialogue
(Dorset House, 2001) ISBN 093263348X

Une collection de conversations résumés de groupe de discussion SHAPE de Weinberg. J'ai aimé
ce livre. Il capture l'esprit et l'énergie de l'être dans une conversation avec un tas de très
des gens intelligents et expérimentés qui sont généreux de partager ce qu'ils savent. Ils couvrent
la plupart des sujets dans la gestion de projet logiciel de création de projet, les calendriers, les conflits,
et la politique de gestion. Le livre est court. Il est basé sur des conversations, il est donc plus moelle et
pépite que la théorie et la PlayBook.

Cockburn, Alistair, Agile Software Development (Addison Wesley, 2001) ISBN 0201699699

La deuxième moitié de ce livre offre une excellente couverture de la méthodologie de développement logiciel,
et pensées pour les futurs créateurs de méthodologie. Ce livre est fortement référencé (parfois
effroyablement donc) et décale et-vient entre un guide pratique et un niveau élevé, Théorie-
manuel sur la base. Si vous aimez un mélange des deux, ce livre est pour vous.

DeMarco, Tom et Timothy Lister, PeopleWare (Dorset House, 1999) ISBN 0932633439

Le livre de gestion classique sur les programmeurs comme des personnes. Il humanise le logiciel
processus de développement en capturant l'importance de travail et l'environnement social sont en
rendre les gens productifs. L'accent mis sur les équipes et les performances au cours hiérarchie et les règles
rend ce livre une aubaine pour les gestionnaires de nouveau à des environnements de travail tech-secteur. Rempli avec
des tonnes de suggestions et recommandations, ceci est l'un des grands.

Friedlein, Ashley, Gestion de projet Web (Morgan Kaufmann, 2001) ISBN 1558606785

Je passais beaucoup de temps à la recherche de bons livres spécifiquement sur la gestion du développement web. Je ne l'ai pas
trouver beaucoup. Ce fut le seul que je suis en mesure de générer de bonnes notes à partir. Bien qu'il soit
écrit la plupart du temps à partir de la perspective des entreprises de développement web et le travail sur une base contractuelle, ce
ne soyez pas dans la voie de l'avis. Friedlein propose une méthodologie simple et beaucoup de

Page 334
 des histoires et des études de cas, et capture l'interaction des rôles (conception, test, la programmation,
etc.) nécessaires pour faire de la production web à haute vitesse possible.

Humphrey, Watts, Gérer le processus de logiciel (Addison Wesley, 1989) ISBN 0201180952

Humphrey est l'un des grands pionniers dans les travaux de génie logiciel. Ceci était le plus
livre accessible et applicable de son que je trouvais. Il couvre le SEI CMM (Capacity Maturity
Modèle, http://www.sei.cmu.edu/cmm/cmms/cmms.html ) en détail. Il fournit générale
des conseils de gestion de développement pour la plupart des situations de base. Soyez averti que l'écriture,
bien que généralement bonne, peut être sec parfois: il est un manuel (et un prix en conséquence). La
exemples et la philosophie ont tendance à faire plus de sens pour les grandes organisations.

McCarthy, Jim, dynamique de développement logiciel (Microsoft Press, 1995) ISBN 1556158238

Un des premiers livres que je lis comme un gestionnaire de programme chez Microsoft. McCarthy, ancien
directeur du développement pour Visual C ++ de Microsoft, décompose le métier de logiciel d'expédition
en pépites bouchées, plus ou moins organisé par la chronologie dans le processus de développement. Ce livre
est l'une des premières recommandations que je fais aux nouveaux gestionnaires de programme chez Microsoft: il capture
Microsoft PM attitude de la vieille école, le bon et le mauvais, mieux que tout livre que je connais.

McConnell, Steve, le développement rapide (Microsoft Press, 1996) ISBN 1556159005

Ce livre était assis intacte sur mon étagère depuis des années uniquement en raison de sa taille énorme: jeter
cela à un petit programmeur pourrait le tuer. Toutefois, le chapitre 3 sur les défaillances logicielles communes est
vaut le prix d'entrée à lui seul. Le livre est une sorte d'encyclopédie des connaissances sur
le développement logiciel moderne: très large et concis. Ce qui rend ce livre un gagnant est de savoir comment
efficace McConnell est en offrant des conseils, et de ramasser les aspects utiles de situations ou des problèmes
couvrir.

Project Management Institute (PMI de), www.pmi.org

Ceci est l'organisation la plus connue pour les personnes intéressées dans la gestion de projet. Ils
offrir des cours et des événements à des chapitres locaux dans de nombreuses villes, publier des bulletins et magazines,
et sont une excellente ressource générale pour en apprendre davantage sur le projet formalisé
gestion.

Weinberg, Gerald, la qualité des logiciels de gestion; Volumes 1-4 (Dorset House, 2001) ISBN
0932633242

Ceci est en quatre parties opus de Weinberg sur la gestion de développement de logiciels. Volumes 1 (premier ordre
mesure) et 2 (système de pensée) fournir toutes sortes de grandes connaissances en compréhension
ce qui se passe réellement avec un projet, et de la façon de gérer et de diriger prévisible. Avec un
mélange de science, la philosophie, l'observation et l'humour, ces manuels donnent beaucoup de kilométrage
et des perspectives inattendues. Weinberg va profondément dans ce livre: il a inspiré de nombreux contemplative
pause pendant la lecture.

Whitehead, Richard, dirige une équipe de développement logiciel (Addison Wesley, 2001) ISBN
0201675269

Le livre le plus pratique et simple, je l'ai trouvé sur les principaux petites équipes de développement. JE
choisi ce sur une alouette au cours des recherches au début car je ne l'avais jamais entendu parler de ce livre
avant, et a été constamment surpris par la qualité de ce que je lis. Très pragmatique, sage,
simple, et utile. Ce fut l'un des joyaux inattendus de toutes mes recherches.

Page 335

Remerciements
Page 336

Un grand merci à Mike Hendrickson, mon éditeur chez O'Reilly, pour me donner le feu vert et beaucoup de
corde. Qualité grâce supérieur à Faisal Jawdat, Ben Lieberman, et Andrew Stellman, le brave et
généreux examinateurs technologie des premières ébauches.

La réalisation de ce livre impliqué beaucoup de gens: grâce à Marlowe Shaeffer (éditeur de la production) pour
la gestion du projet qui est ce livre, Marcia Friedman (architecte d'intérieur), Rob Romano
(Illustrateur), Jeremy Mende (concepteur de la pochette), Audrey Doyle (correcteur), Ellen Troutman-Zaig
(Indexeur), et Glenn Bisignani (directeur du marketing produit).

Les personnes suivantes ont donné de leur temps pour être interrogés, ou pour donner des commentaires sur les premières ébauches de
chapitres. Muchos gracias à Michelle Breman, Pierro Sierra, Eric Brechner, Richard Stoakley, Mark
Stutzman, Neil Enns, Jason Pace, Aly Valli, Joe Belfiore, Bill Staples, Laura John, Hillel Cooperman,
Stacia Scott, Gwynne Stoddart, Terri Bronson, Barbara Wilson, Terrel Lefferts, Mike verre,
Chromatique, et Richard Grudman. Un merci spécial à Ken Dye, mon premier manager chez Microsoft, et
Joe Belfiore de me donner ma pause dans la gestion de programme et de façonner mes premières idées sur ce que
de bons gestionnaires et les dirigeants sont censés faire.

Supplémentaires, emballés individuellement grâce à ma femme, Jill "Bear" Stutzman; Richard «Big Daddy»
Grudman; l'Reservoir Dogs (Chris «notre héros» McGee, Mike "tous les coups" Viola, David "jolie
garçon "Sandberg, Joe" gourmet "Mirza, Phil" Stud à cinq cartes "Simon); Vanessa" NYC "Longacre; Bob
«Faire le travail Web" Baxley; et l'amende gens de gnostron, déséquilibré, et le h-clinique. Général
grâce à l'idée même de l'univers; le mot de papaye; grandes forêts de grands arbres; les gens qui
rester idiot, curieux, et le plaisir au-delà de leurs années; la lettre Q et le nombre 42. Un merci appréciez
emballer pour le système de la bibliothèque du comté de King et de tous les bibliothécaires partout. Le programme de prêt entre bibliothèques
est une aubaine. Merci les gars.

La musique suit m'a gardé sain d'esprit pendant de longues heures au clavier: White Stripes, Palomar, Aimee
 Mann, The Clash, Johnny Cash, Social Distortion, Rollins Band, Sonny Rollins, Charles Mingus,
Theloneous Monk, éleveurs: Last Splash , Audioslave, MC5, grands mélanges de Chris McGee, Jack
Johnson, Patty Griffin, Akiva, Flogging Molly, Sinatra, les Beatles, Bruce Springsteen, PJ Harvey,
Radiohead, Ramones, Weezer, Tom Waits, All Girl Summer Fun Band, Best of Belly, les champs magnétiques,
Beth Orton, Elliot Smith et Nick Cave and the Bad Seeds.

Pas de gestionnaires de projets ont été blessés dans l'élaboration de ce livre. Mais malheureusement, Butch, notre chien, adopté
loin pendant la production finale. Butch, RIP 1991-2004. Il était à mes pieds alors que beaucoup des idées et
pages ici sont venus pour être. Bon chien, Butch. Vous nous manquerez.

Page 338
337

Crédits photos

Préface, Frank Lee, www.flee.com , Duomo, Florence, Italie

Chapitre 1 , Frank Lee, www.flee.com , Duomo, Florence, Italie

Part One , Scott Berkun, Marymoor Park, Redmond, WA

Chapitre 2 , Scott Berkun, Interstate 84, Idaho

Chapitre 3 , Scott Berkun, I-5 échange, Seattle, WA

Chapitre 4 , Scott Berkun, Farrel McWhirter Park, Redmond, WA

Chapitre 5 , Scott Berkun, Université de Washington

Chapitre 6 , Scott Berkun, Capilano, Vancouver, Canada

La deuxième partie , Jill Stutzman, www.uiweb.com/jillart , Redmond, WA

Chapitre 7 , David F. Gallagher, www.lightningfield.com , NYC

Chapitre 8 , Scott Berkun, Boulangerie dans le Queens, NYC

Chapitre 9 , Scott Berkun, Scott & Jill

Chapitre 10 , Scott Berkun, Sea-Tac Airport

Chapitre 11 , Scott Berkun, Portland (près de Powells)

Troisième partie , Scott Berkun, magasin de livres d'occasion, Unknown

Chapitre 12 , Frank Lee, www.flee.com , Amsterdam

Chapitre 13 , Scott Berkun, auto-portrait, Parc national de Yellowstone

Chapitre 14 , Scott Berkun, de ballon sur glace # 1, Brainerd, ND

Chapitre 15 , Scott Berkun, de ballon sur glace # 2, Brainerd, ND

Chapitre 16 , Scott Berkun, Tour Eiffel, Paris

Page 339

Colophon

A propos de l'auteur

Colophon
Page 340

A propos de l'auteur

Scott Berkun étudié l'informatique, la philosophie et le design à l'Université Carnegie Mellon.

Embauché par Microsoft en 1994 en tant qu'ingénieur de convivialité, il a travaillé sur Microsoft Office, Visual Basic, et
autres produits. En 1995, il est devenu un gestionnaire de programme sur le projet Internet Explorer, leader
la conception et le développement de nombreuses fonctionnalités majeures. Après la version 5.0, il a travaillé comme chef de file
directeur du programme sur les équipes de développement Windows et MSN. Scott a également travaillé dans Microsoft
groupe de l'excellence en ingénierie, en aidant d'autres à travers l'entreprise et l'industrie renseigner sur les meilleures
pratiques en matière de développement web et des logiciels. Il a présenté des conférences, des ateliers enseigné, et
participé à diverses formes de mal à de nombreuses conférences de l'industrie.

Scott a quitté Microsoft en 2003 dans le but de combler cette étagère (photo ci-dessus) avec des livres qu'il a
écrite. Il continue d'enseigner la gestion de projet, développement de logiciels, la pensée créatrice, et
la conception du produit en tant que consultant indépendant.

Visitez www.scottberkun.com pour les forums de discussion sur des sujets dans ce livre, des dizaines d'autres essais, et
informations sur comment vous pouvez l'aider à remplir ce plateau (dire aux autres au sujet de ce livre est une excellente
placer pour commencer). Ceci est son premier livre publié. Il vit quelque part dans les bois à l'est de Seattle.

Page 341

Colophon

Marlowe Shaeffer a été le directeur de la production et de réviseur pour L'Art de la gestion de projet .
Audrey Doyle était le correcteur. Jamie et Claire Cloutier Peppard fournies contrôle de la qualité. Ellen
Troutman-Zaig écrit l'indice. Lydia Onofrei a fourni une assistance de production.

, www.mendedesign.com , conçu la couverture de ce livre. Karen Montgomery produit

MENDEDESIGN
 la mise en page de couverture dans Adobe InDesign CS utilisant des polices Akzidenz Grotesk et orateur.
Marcia Friedman a conçu l'aménagement intérieur. Melanie Wang a conçu le modèle. Phyllis McKee
adapté le modèle. Ce livre a été converti par Joe Wizda et Keith Fahlgren à FrameMaker
5.5.6 avec un outil de conversion de format créé par Erik Ray, Jason McIntosh, Neil Walls et Mike Sierra
qui utilise des technologies Perl et XML. La police du texte est Méridien d'Adobe; la rubrique police est ITC
Bailey. Les illustrations qui apparaissent dans le livre ont été produites par Robert Romano, Jessamyn Lire,
et Lesley Borash l'aide de Macromedia FreeHand MX et Adobe Photoshop CS et l'utilisation de l'ORA
la police de la main.

Page 342

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]
Page 343

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

exactitude, la précision vs.

diagrammes d'activité
annonce attaques Hominum 2e
ajouter discussions / coupées ordonnancement
ajustements aux exigences, dessins et modèles
adversités, en surmontant
mauvaises situations courantes
liste de
reconnaissant
la résolution des conflits et la négociation
limiter les dégâts
toolkit émotionnelle
sentiments au sujet des sentiments
complexe du héros
pression
gérer des situations difficiles
rôles et une autorité claire
la prise de responsabilité
la formation et la pratique
la confiance comme une assurance contre
diagrammes affinité
Code pipelining agressive
(méthodes agiles de développement de logiciels)
communication convenu
ambiguïté
PM de rôle
la tolérance de
d'autres ennuyeux, en évitant
la création et le déploiement de processus
effets de bons procédés
email
d'autres l'ont lu en supposant
éviter comptes play-by-play
exemple de mauvaise
exemple de bonne
 limites FYIs
principes de bonne écriture
priorisation
téléphone à la place
formule de bons procédés
la gestion des processus de dessous
réunions
2ème de la facilitation
pointeurs sur
récurrent
types de réunions
sources de nuisance
catalogue les anti-
l'argument, en utilisant dans la résolution des conflits
pression artificielle
de demander aux autres de leur meilleur travail
hypothèses
causant des problèmes de communication

Page 344

clarification des définitions de rôles

qui sous-tend un projet
attitudes
meilleure attitude de travail
forcer le changement dans
des gestionnaires de projet
autorité
la prise de décision
délégation de
gagné
requis pour la planification de projet
exigences et la conception
/ traits de délégant, chefs de projet de autocrate
comportement autocratique (si nécessaire)
Page 345

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

mauvaises approches pour la planification du projet, catalogue de

équilibre du pouvoir dans les organisations
l'esprit du débutant (de shôshin)
comportement
forcer le changement dans
incompatible, la confiance grâce à perdre
en retard
croyant, gestionnaire de projet
meilleure alternative à un accord négocié (BATNA)
meilleur travail, obtenir des autres
demandant à la meilleure œuvre
/ demandes rendant difficiles
barrages de compensation
suivre les conseils
aider les autres à faire de leur mieux
inspirant
rappelant les objectifs du projet
rappelant rôles respectifs
enseignement
les grands projets de l'équipe du personnel
blâmer (problème de communication)
horaires de bas en haut
jeu de cartes de remue-méninges (ThinkPak)
rupture de travail en morceaux gérable 2e
Work Breakdown Structure (WBS)
informer l'équipe
autorité budgétaire pour les projets
bug pipeline fix
bogues
tableau d'activité
difficile, laissant jusqu'au dernier
fin de fin de jeu
l'évaluation des tendances
gestion de
triage
des mesures utiles de
perspective des entreprises sur des projets 2e
commercialisation
besoins de l'entreprise, l'intégration avec les exigences de la technologie

Page 346

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]
 célébrant la fin du projet
chaîne de commande
inciter les autres à faire de leur mieux
simplicité champion
changement
traitant de la gestion de mystère
explorer l'impact du changement
portée potentielle du changement
gérant
coups bas (attaques personnelles)
vérifier votre santé mentale
listes de contrôle, confondant avec les objectifs
checkpoints
phases de conception
pour des discussions add / coupées
jeux d'échecs
clarté
manque de communications
faire bouger les choses
compensation des barrages routiers pour susciter meilleur travail
pipeline de codage
agressif et conservateur
devenir pipeline de correction d'un bug
contrôle des ajustements à mi-parcours
préparation pour le changement
le suivi des progrès
la coercition (puissance)
engagements
rupture
renforcement de la confiance par le biais
formaliser un calendrier
2ème de communication
modèle de base
communication convenu
conversion en action utile
communication reçue
communication tramsmitted
communication compris
meilleure attitude de travail
meilleur travail, obtenir
demandant à la meilleure œuvre
difficile ou exigeante
barrages de compensation
suivre les conseils
autres inspirants
rappelant les objectifs du projet
rappelant équipe de rôles respectifs
enseignement
problèmes communs
hypothèses
dicter
manque de clarté
N'écoute pas

Page 347

attaques personnelles
problème inadéquation
aider les autres à faire de leur mieux
la gestion par la conversation
relations
la dépendance du projet sur les relations
la définition des rôles
les relations et
l'évaluation comparative 2e
poser des questions difficiles
envisager de choix hybrides
opinions dissidentes
examiner les hypothèses ou les revendications
inclure l'option "ne rien faire"
inclure des perspectives pertinentes
affiner avantages / inconvénients liste jusqu'à ce stable
commencer sur papier ou tableau blanc
la concurrence, couvrant dans les documents de vision
complexité, reconnaissant
les conflits entre les membres de l'équipe
la résolution des conflits 2e
être forte mais souple
connaître les alternatives
intérêt mutuel, à la recherche de
les conflits de personnalité
 persuasion et argumentation, en utilisant
point de l'unification conclusion
confusion, minimisant
Code conservatrice pipelining
qualité consolidé de documents de vision
consolider les idées
contraintes
politique et le pouvoir
rôle dans la résolution de problèmes et la pensée créative
équipe de contrat (petite), projet réalisé par
contrôle des projets
réunion d'examen
triage
équipe de la guerre
conversations
sur le pouvoir
diriger comme animateur de la réunion
gestion par
relations de communication
conversion de communications à l'action utile
analyse coûts-avantages pour les processus
courage
traits de chef de projet
de prendre des décisions
décisions sans choix gagnants
de bonnes décisions avec de mauvais résultats
CR (demande de modification)
des questions créatives
la pensée créative, des livres sur
travail créatif,
élan de
gestion de crise
chemin critique
critique
crainte de
points de croisement dans jalons
les critères de sortie, définissant
crunch effort pour respecter les délais

Page 348

effort de resserrement / récupération rapport de temps

expérience client comme point de départ de la conception
perspective du client sur des projets
des experts qui comprennent les clients et la conception pour eux
énoncés de problèmes
questions découlant de
demandes et la recherche sur les demandes
la recherche de la clientèle et de ses abus
Des méthodes de recherches
clients, des informations sur les (documents de vision)
Page 349

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

quotidienne construit, projet

des questions quotidiennes pour rester en tête
triage jour / semaine
limiter les dégâts
DCR (demande de changement de la conception)
délais
grands que plusieurs petits délais,
correction angles d'approche
les critères de sortie
dates frapper
pourquoi il ya pire
des efforts extraordinaires pour répondre
la prise de décision 2e
autorité pour
le courage de décider
décisions sans choix gagnant
de bonnes décisions avec de mauvais résultats
décider ce qui est en jeu
approbation ou commentaires nécessaires
problème coeur
l'expérience avec le problème
point de vue d'expert, à la recherche
l'impact et la durée de la décision
l'impact / coût de se tromper
fenêtre d'opportunité
éliminer l'impossible
preuve pour les réclamations sous forme numérique
trouver et pesant les options
comparaison, avantages et inconvénients
discuter et évaluer
émotions et de clarté
formation formelle dans
information
les décisions de contre de données
une mauvaise interprétation des données
précision vs précision
la recherche que des munitions
rétrécissement des possibilités avec rasoir d'Occam
réflexion
révision des décisions
analyse d'arbre de décision
défauts
délégation de pouvoirs
traits de délégant, chefs de projet
livrables (planification du projet) 2e
échéancier pour
travail exigeant des autres
dépendances d'un projet
 (problème de communication) de la dérision
conception 2nd3rd
méthodologies agiles et traditionnelles
comme série de conversations
autorité sur

Page 350

mauvaises idées conduisant à de bonnes idées

révision et raffinement
changements causant des réactions en chaîne
points de contrôle pour les phases
travail créatif, dynamique de
expérience client comme point de départ
exploration basée sur les exigences
la peur de l'exploration
boucle de rétroaction avec les exigences
finalisation
impact sur la programmation
itération
liste non questions
les concepteurs de produits
le progrès, la mesure
prototypes
alternatives, en utilisant pour augmenter le succès
des projets avec des interfaces utilisateur
projets sans interfaces utilisateur
départ
soutien pour les programmeurs
exigences de qualité que le point de départ
des critiques et des ajustements
spécification vs.
décisions techniques vs.
demande de modification de conception (DCR)
designers (interaction, produit ou industrielle)
commandes de dicter
persuasion vs.
dilemmes de gestionnaires de projet
demande directe pour le pouvoir
les directions, 2e changer
traitant de la gestion de mystère
explorer l'impact du changement
portée potentielle du changement
la gestion des changements
désaccords
parmi les membres de l'équipe
distractions et les pressions, traitant
diviser et conquérir stratégie pour les horaires

Page 351

Index
 [A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

gagné 2nd3rd de puissance

ECO (Engineering Change ordre)
ECR (de demande de changement de l'ingénierie)
traits ego, gestionnaires de projets
e-mail, non gênant
d'autres l'ont lu en supposant
éviter comptes play-by-play
exemple de mauvaise email
exemple de bonne email
limites FYIs
principes de bonne écriture
priorisation
téléphone, en utilisant à la place de
urgences, la manipulation
toolkit émotionnelle
sentiments au sujet des sentiments
complexe du héros
pression
naturelle et artificielle
émotions, la conscience de
fin de jeu stratégie 2e
grandes échéances que plusieurs petits délais
correction angles d'approche
les critères de sortie
dates frapper
pourquoi il ya pire
éléments de contrôle
réunion d'examen
triage
équipe de la guerre
des éléments de mesure
tableau d'activité
gestion de bug
accumulation quotidienne
l'évaluation des tendances
mesures de bogues utiles
fin de fin de jeu
célébrations
post-mortem
release candidate (RC)
déploiement et opérations
de modification technique (ECO)
demande de changement d'ingénierie (ECR)
point de vue technique sur les projets
la qualité de l'ingénierie, de la valeur du produit et
l'environnement, l'évaluation
temps pour le travail d'estimation
oublis communs dans l'estimation
difficultés de
de bonnes estimations, assurant
les critères de sortie
définissant
expérience avec l'espace de problème

Page 352

Extreme Programming (XP)

itérations
vitesse
Page 353

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

simplification
art de
pointeurs sur
diriger la conversation
discussions documentant
la conversation se termine
établir la position de l'hôte
l'écoute et la réflexion
échec
l'apprentissage de
échec d'un projet possible, couvrant dans le document de vision
complexe de défaillance
insuffisance des horaires, pour des raisons
oublis communs dans l'estimation
difficultés d'estimation
plans début spéculatives
de bonnes estimations, assurant
calendrier que la probabilité
effet boule de neige des oublis
la foi, le manque de (dans un projet)
Défaut de rétroaction du rapport (FFR)
la peur, les gestionnaires de projet et
déclarations de longs
la conversion des énoncés de problèmes à
exemples de
but de
Développement piloté par fonctionnalités
Caractéristiques
 besoins de l'entreprise
la couverture et de la technologie
dans les documents de vision
priorité aux listes ordonnées
spécification
rétroaction, processus dirigeants définissant
sentiments
sur les sentiments
conscience de
FFR (Feedback Ratio de défaut)
taux fixe (bugs)
fixation sur le processus
flanquant votre objectif
voler de l'avant de l'avion
vérifications de bonne santé
tactiques (quotidiens) des questions
des questions hebdomadaires / mensuels pour rester en tête
volant derrière votre projet
des groupes de discussion dans la recherche de la clientèle
questions ciblées
fonction de forçage
puissance fonctionnelle

Page 354

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

buts
clarifier avec les déclarations de longs
confusion
confusion avec les processus
des exemples de bonnes objectifs du projet
maintenir une grande visibilité pour
réunions
priorité aux listes ordonnées
projet, l'équipe et individuelle
rappelant équipe de, de susciter meilleur travail
soutien dans les documents de vision
bien écrit
2ème pouvoir accordé
étant autocratique
réunions de groupe, à l'aide de la puissance et de l'influence
la puissance du groupe, illusion de
Page 355

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

aider les autres à faire de leur mieux

complexe du héros
croyances motivants
discussion hautement interactif (réunions)
histoire de la gestion de projet
principaux enseignements tirés
apprentissage de l'échec
Holmes, Sherlock
les salles d'urgence de l'hôpital, la gestion de projet
Projet Hydra (exemple), les buts

Page 356
 Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

idées
gérant
points de contrôle pour les phases de conception
consolider les idées
idées hors de contrôle
liste non questions
la gestion prévisible
prototypes, développement
questions pour les itérations de prototypes
origine de
mauvaises idées
mauvaises idées conduisant à de bonnes idées
contexte de bonnes ou de mauvaises idées
expérience client commence la conception
la conception que la série de conversations
écart des exigences à des solutions
les bonnes questions, en demandant
point de vue et de l'improvisation
penser dans et hors de boîtes
idées traditionnelles idée génération
impatience, les gestionnaires de projet
exécution
méthodologies agiles et traditionnelles
l'improvisation, la perspective et
règles idée génération
un comportement incohérent, perdre la confiance par
objectifs individuels
designers industriels
2ème influence
utilisation indirecte de
l'utilisation de plusieurs étages
utilisation de
le flux d'informations dans des projets
insécurités des gestionnaires
la qualité inspiré des documents de vision
inspirer les autres à faire de leur mieux
intentionnelle la qualité des documents de vision (objectif-driven),
designers d'interaction
vue interdisciplinaire dans la planification de projet
dates provisoires sur les projets
site web intranet
Projet Hydra (exemple), les buts
énoncés de problèmes (exemple)
implication des managers, le bon type
itérations
prototypes, des questions pour
le travail de conception itérative

Page 357

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

cuisines (restaurant), la gestion de projet

KJ (Kawkita Jiro) diagrammes
la connaissance et la circulation des informations dans les projets
la connaissance en tant que puissance
Page 358

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

manque de foi (en projet)

retard, tendance
leadership
pouvoir et la politique
la confiance en tant que base de
bâtiment et perdre la confiance
assurance contre l'adversité
types de pouvoir
faisant confiance clair
erreurs
modèles, questions et conflits
faire confiance aux autres
se faire confiance
apprentissage de l'échec
écoute
importance dans la communication
rôle dans la facilitation
basse qualité
Page 359

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

faire bouger les choses

étant implacable
étant avertis
des tactiques de guérilla
keeping it real
sachant le chemin critique
priorités
listes ordonnées
dire non
la maîtrise de façons de dire non
la gestion en marchant autour (MBWA)
gestionnaires, mission de
gérer jusqu'à
MARF (gêne minimale de facteur de risque)
étude de marché
document des exigences de marketing (MRD)
marketing, fonctions de
organisation matricielle
mesure, l'avancement du projet
tableau d'activité
gestion de bug
accumulation quotidienne
l'évaluation des tendances
mesures de bogues utiles
réunions
non gênant
2ème de la facilitation
pointeurs sur les réunions
réunions périodiques
types de réunions
la planification du projet
qualité mémorable de documents de vision
méthodologies
ordonnancement
diviser et conquérir
limites de
règle des tiers
spécifications, définitions de
micromanagers, les abus commis par
Microsoft, le programme et la gestion de projet
-milieu de jeu stratégie 2e
 changer de direction
traitant de la gestion de mystère
la gestion des changements
pipeline de codage
agressif et conservateur
devenir pipeline de correction d'un bug
le suivi des progrès
la maintenance de haut niveau
rester en tête des événements
vérifications de bonne santé
tactiques (quotidiens) des questions
des questions hebdomadaires / mensuels

Page 360

prendre des mesures en toute sécurité

engagements de rupture
jalons
angle d'approche de correction
points de croisement
les critères de sortie
les critères de sortie
intermédiaires, les dates de frapper
longueur correspondant à la volatilité
correspondant à la volatilité projeter
la planification du projet
facteur de risque de gêne minime (MARF)
erreurs, la confiance et
questions mensuelles pour rester en tête
motiver les autres
motivations pour abus de pouvoir
MRD (exigences en matière de commercialisation de documents)
mutinerie, les menaces de

Page 361
 Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

pression naturelle
négociation
être forte mais souple
connaître les alternatives
chercher intérêt mutuel
les conflits de personnalité et
persuasion et l'argumentation, en utilisant
Non, disant
mastering
données numériques pour appuyer les revendications

Page 362

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

objectifs
obsession de méthodologies
Rasoir d'Occam
l'esprit ouvert (shôshin)
opérations
 compétences orales (chef de projet)
listes ordonnées
étant une machine de priorisation
les priorités sont l'énergie
priorité 1
les priorités du projet
organisations
équilibre des pouvoirs
impact sur la planification
politique
sur-implication des gestionnaires
oublis

Page 363

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

paradoxes ou dilemmes de gestionnaires de projet

patience, gestionnaires de projets
la perfection, la poursuite
la performance, la pression et
attaques personnelles 2e
les conflits de personnalité
les questions de personnel
perspectives
avantages de la perspective PM
forcer le changement dans
sur la planification de projet
équilibre des pouvoirs
point de vue commercial
perspective du client
vue interdisciplinaire
point de vue technologique
personnes ayant le pouvoir
persuasion
plus fort que la dictée
l'aide dans la résolution des conflits
PERT (de pert)
 développement
placement fragmentaire
2ème de la planification
poser les bonnes questions
répondre aux questions
y compris trois perspectives principales
fiche de questions
pas de temps pour les questions
catalogue de mauvaises approches
confusion avec les objectifs
travail créatif
la recherche de la clientèle et de ses abus
Des méthodes de recherches
intégrer les exigences commerciales et technologiques
perspectives sur
équilibre des pouvoirs
point de vue commercial
perspective du client
vue interdisciplinaire
point de vue technologique
le processus de
travail quotidien de planification
livrables
nombre de personnes impliquées
projets dont les coûts de production élevés
exigences, à l'aide
convertir problèmes de scénarios
horaires, informer l'équipe à propos
la planification de logiciels démystifié
livrables de planification commune
l'impact des organisations
la collecte des besoins

Page 364

spécification
types de projets
PM (chef de projet)
politique
la résolution de problèmes
devenir politique
contraintes sur les dirigeants
Définition de
dans la planification de projet
sachant le terrain de jeu
création de votre propre terrain de jeu
abus de pouvoir
les causes de motivation
prévention
les causes de procédé
puissance et
résoudre les problèmes politiques
évaluation obtenir vos besoins satisfaits
clarifier ce que vous avez besoin
pouvoir influencer
pouvoir de vous donner ce que vous avez besoin
sources d'énergie
des résultats positifs pour les projets
post-mortem (projet)
puissance
contraintes sur les dirigeants
sortes de
puissance gagné
2ème pouvoir accordé
sachant le terrain de jeu
création de votre propre terrain de jeu
détournement de
les causes de motivation
prévention
les causes de procédé
la politique et
priorités en tant que
rapport à la responsabilité
résoudre les problèmes politiques
évaluation obtenir vos besoins satisfaits
clarifier ce que vous avez besoin
pouvoir influencer
pouvoir de donner ce que vous avez besoin
sources de
les définitions des différents types
types de
la pratique et la formation des gestionnaires de projets
 précision vs précision
pression
naturelle et artificielle
les pressions et les distractions, traitant
prix
priorités
comme puissance
étant une machine de priorisation
confusion
listes ordonnées
priorité 1
dire non
la maîtrise des moyens à
problème décalage (en communication)
résolution de problème
point de vue et de l'improvisation

Page 365

règles pour la génération d'idées

politique comme
espace de problème
grandir et rapetisser lors de la conception
rétrécissement de
origination des exigences
déplacement de
changements causant des réactions en chaîne
expérience de l'équipe avec
énoncés de problèmes
rapports de bogues vs.
la conversion de scénarios
liste d'exemples pour le site web intranet
exigences de qualité, de l'écriture
processus
confusion avec les objectifs
la création et le déploiement
effets de bons procédés
la création de bons procédés
fixation sur
formule de bons procédés
dégoût des processus de travail
la gestion par le bas
abus de pouvoir, provoquant
la planification du projet
travail quotidien de planification
livrables
nombre de personnes impliquées
produit
les concepteurs de produits 2ème
la productivité (équipe), comme zéro ressource somme
pert (PERT)
programmeurs, d'un pipeline de codage
progrès
mesure pour le projet
tableau d'activité
gestion de bug
accumulation quotidienne
l'évaluation des tendances
mesures de bogues utiles
suivi à la mi-calendrier
gestion de projet
chez Microsoft
l'histoire de
les salles d'urgence de l'hôpital
rôle de
l'activité de gestion de projet
les gestionnaires de projet
les niveaux de participation
perspective, les avantages de
valeur unique créé
valeur ajoutée par
projets
post-mortem
types de
autorité exigences
promotion
la preuve de concept
Liste avantages / inconvénients (des décisions)
prototypes
alternatives, de plus en plus de succès avec
des projets avec des interfaces utilisateur
projets sans interfaces utilisateur
Page 366

questions pour les itérations

départ
soutien pour les programmeurs
pseudo héros
pouvoir psychologique d'un calendrier

Page 367

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

qualité
par écrit, le volume vs.
 faible
produit
des questions
clé, dans les documents de vision
conduisant à de bonnes idées
des questions créatives
questions ciblées
questions rhétoriques et
la planification du projet
répondre aux questions
fiche de questions
pas de temps pour les questions
perspectives, y compris

Page 368

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

Développement d'applications rapides

la réalité, rester en contact avec
communication reçue
le temps de récupération, le rapport à l'effort de crise
réunions périodiques
pouvoir de référence)
réflexion
comme outil de prise de décision
rôle dans la facilitation
régressions
taux causés par correction d'un bug (FFR)
relations
communication et
Améliorer la communication
aider les autres à faire de leur mieux
la dépendance de projet sur
la définition des rôles
release candidate (RC)
 poursuite incessante de buts
rapports ou modérée de discussion (réunions)
réprimandes
demande (direct), pour le pouvoir
demandes, le client
exigences
autorité sur
affaires et la technologie, l'intégration
la conversion de solutions
l'exploration de conception
la peur de l'exploration
les progrès dans la conception
écrit des exigences de qualité
documenter
2e rencontre
méthode des énoncés de problèmes, en utilisant
par exemple pour le site web intranet
des critiques et des ajustements
spécification
recherche
comme munitions de prise de décision
demandes des clients
la recherche de la clientèle et de ses abus
Des méthodes de recherches
les pénuries de ressources
ressources
pour le pouvoir politique
responsabilité
rapport de la puissance de
prendre dans de mauvaises situations
cuisines de restaurant, la gestion de projet
des périodes d'examen dans les horaires
commentaires
que des contrôles de projet
exigences et dessins

Page 369

récompenses (puissance)
questions rhétoriques
(problème de communication) de ridicule
risques
adressage tôt dans le calendrier
évaluation dans les documents de vision
rôles
confusion et
définissant
processus de planification
rôle de gestion de projet
structure de renfort de rôle de l'équipe
rappelant équipe de, pour permettre aux meilleurs travaux
déploiement et opérations
règle des tiers (ordonnancement)
développement fragmentaire
Page 370

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

l'action sécuritaire, en prenant

engagements de rupture
vérifications de bonne santé
gestion de projet avertis
évaluation de votre environnement
des tactiques de guérilla
dire non
mastering
scénarios
la conversion des énoncés de problèmes à
la couverture dans les documents de vision
horaires
la construction, des méthodologies pour
diviser et conquérir
règle des tiers
la stratégie de fin de jeu
défaut
stratégie milieu de jeu
application de la
la formalisation des engagements
de grands projets complexes
voir les efforts individuels dans le cadre de l'ensemble de
outil pour suivre les progrès
tendance des gens à être en retard
ce qui les fait travailler
pourquoi ils échouent
oublis communs dans l'estimation
difficultés d'estimation
plans début spéculatives
de bonnes estimations, assurant
calendrier que la probabilité
effet boule de neige des oublis
ordonnancement
champ d'application (la vision) documents
autosuffisance
shôshin (la esprit du débutant)
balles d'argent, les méthodologies que
simplicité
champion
les décisions de conduite (Occam Razor)
simplifiant qualité, documents de vision
simulations, la formation par la prise de décision
évaluation singulier
visites de sites (dans la recherche de la clientèle)
scepticisme
en ordonnancement
chef de projet trait
petits projets de l'équipe de contrat
(Spécifiés, mesurables, orientées vers l'action, réaliste et opportun) des objectifs SMART
effet boule de neige des oublis de planification
 les réseaux sociaux,
planification l'importance de
de logiciels
livrables de planification commune

Page 371

l'impact des organisations

la collecte des besoins
spécification
types de projets
la qualité des logiciels
projets solo-superman
solutions, écart entre les besoins et
(SMART) objectifs en temps opportun spécifique, mesurable, orienté vers l'action, réalistes et
spécifications 2e
décider ce qu'il faut spécifier
décider quand complète
combler les lacunes de l'horaire
combien est assez
la gestion des questions ouvertes
signification d'achèvement
conception vs.
développer et documenter
veiller à ce que les bonnes choses arrivent
fonctions de
obtenir des commentaires sur
responsabilité pour
avis et évaluations
procéder à l'examen
comment revoir
des questions d'examen
Qui devrait assister
effets simplificatrices de spécifications bien écrits
le temps entre les besoins et
ce qu'ils peuvent et ne peuvent pas faire
qui, quand, et comment écrire
écrit pour une contre l'écriture pour beaucoup
des conseils et des choses à éviter l'écriture
modèle en spirale (développement de logiciels)
phases
équipe du personnel (grande), complétée par des projets
les parties prenantes, la couverture dans les documents de vision
statistiques, une mauvaise interprétation des
état et de l'examen des projets réunions
stratégie
fin de jeu
grandes échéances que plusieurs petits délais
célébrations
éléments de contrôle
des éléments de mesure
fin de fin de jeu
-milieu de jeu
pipeline de codage
la maintenance de haut niveau
rester en tête des événements
prendre des mesures en toute sécurité
soulagement du stress
superman (solo) des projets
enquêtes dans la recherche de la clientèle

Page 372

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]
 questions tactiques (quotidiens) pour rester en tête
retard, tendance
l'enseignement pour permettre aux meilleurs travaux
objectifs de l'équipe
équipes
les grands projets de l'équipe du personnel
la confiance et l'expérience de travailler ensemble
questions entre les membres
la productivité des ressources à somme nulle
petits projets de l'équipe de contrat
équipe solo-superman
l'autorité technique pour les projets
spécifications techniques
point de vue de la technologie sur les projets
questions découlant de
les exigences technologiques, l'intégration avec les exigences d'affaires
critères de test, en précisant
essai
méthodologies agiles et traditionnelles
"Il n'y a pas de mauvaises idées"
"Pensez autrement"
ThinkPak (brainstorming jeu de cartes)
menaces de mutinerie
tolérer l'ambiguïté
horaires top-down
poursuite
confusion avec les objectifs
calendrier comme outil de suivi
méthodes traditionnelles (développement de logiciels)
la formation des gestionnaires de projets
traits d'un chef de projet
communication transmise
tendances, l'évaluation
triage
jour / semaine
dirigé
2ème de la confiance
engagements de rupture
bâtiment et de perdre
bâtiment grâce à l'engagement
perdre par un comportement incompatible
défini
assurance contre l'adversité
types de pouvoir
puissance gagné
2ème pouvoir accordé
en précisant
faire des erreurs
réprimandes
modèles, questions et conflits
dirigeants définissant rétroaction
puissance et
faire confiance aux autres

Page 373

délégation de pouvoirs
se faire confiance
Page 374

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

sous-estimation
communication compris
ingénieurs d'utilisabilité
études de convivialité (dans la recherche de la clientèle)
des interfaces utilisateur
prototypage pour des projets avec
prototypage pour des projets sans
théorie de l'utilité
Page 375

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

valeur
ajoutée par les gestionnaires de projet
créée par les gestionnaires de projet
définie comme la qualité de l'ingénierie
vitesse (Extreme Programming)
Diagramme de Venn, en utilisant pour éliminer les préjugés en perspective
documents de vision 2nd3rd
Le catalogue des énoncés de vision boiteux
défini
la rédaction, la révision et la révision
bons énoncés de vision et les objectifs (exemples)
étayant les allégations
bons, caractéristiques de
consolidation des idées
la qualité d'inspiration
intentionnelle qualité (par objectifs)
qualité mémorable
effets simplificatrices
maintenir en vie en interrogeant fréquemment son utilité
points clés à couvrir
principes de bonne écriture
garder les choses simples
un auteur primaire
volume par rapport à la qualité
proof-of-concept de prototype
champ d'application
questions afin de déterminer
équipe et des objectifs individuels
valeur des choses d'écriture vers le bas
des images visuelles à
visualisant les choses non-visuels
Page 376

Index

[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

équipe de la guerre
modèle en cascade (développement de logiciels)
développement web, les défis de
site Web pour ce livre
triage hebdomadaire
des questions hebdomadaires / mensuels pour rester en tête
"Que devons-nous faire?", Répondant
"Quel est le problème que vous essayez de résoudre?"
travail
meilleur travail, obtenir des autres
demandant à la meilleure œuvre
/ demandes rendant difficiles
barrages de compensation
suivre les conseils
inspirant
rappelant les objectifs du projet
rappelant rôles respectifs
enseignement
aider les autres à faire de leur mieux
l'attitude de travail (le meilleur)
Work Breakdown Structure (WBS)
pipelining agressive contre
développer et documenter
éléments de travail
distribution à travers l'équipe
priorité aux listes ordonnées
listes des éléments de travail
compétences en écriture (chef de projet)
les choses par écrit, valeur de
bien écrire
garder les choses simples
e-mail non-gênant
un auteur primaire
Conseils pour de bonnes spécifications
volume par rapport à la qualité

Page 377

Index
[A][B][C][D][E][F][G][H][I][K][L][M][N][O][P][Q][R][S][T][U][V][W][Z]

nulle ressource somme, la productivité de l'équipe en tant