Vous êtes sur la page 1sur 301

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


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

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