Человеческий фактор в программировании
Добавить в закладки К обложке
- Предисловие - Страница 1
- Предисловие к первому изданию - Страница 3
- IГрупповая разработка - Страница 5
- 2Консенсус и компромисс - Страница 7
- 4Скромный и высокопоставленный писарь - Страница 11
- 5Официальное пространство - Страница 14
- 6Раздражающие прерывания - Страница 17
- IIКовбои и ковгерлы - Страница 19
- 8Возвращение блудного ковбоя - Страница 22
- 9Единство в разнообразии - Страница 25
- 10Кодеры-ковбои и программисты-мудрецы - Страница 28
- IIIОрганизация работы - Страница 33
- 12Методы хаоса - Страница 36
- 13Открытая архитектура - Страница 39
- 14Синхронное плавание - Страница 42
- 15Командная политика - Страница 45
- 16Все сразу - Страница 47
- 17Заговор упрямцев - Страница 49
- IVИнструменты, модели и методы - Страница 51
- 19Вопросы моделирования - Страница 54
- 20Свет мой, зеркальце - Страница 56
- 21Методичное сумасшествие - Страница 58
- 22Говоря по существу - Страница 60
- 23Будущие формы - Страница 63
- 24Цели программного обеспечения - Страница 66
- 25Шито белыми нитками - Страница 69
- VСовершенствование процесса - Страница 73
- 27Повторение и вознаграждение - Страница 76
- 28Суперобучение - Страница 79
- 29Вверх по водопаду - Страница 81
- 30Своевременная поставка - Страница 83
- 31Под давлением - Страница 85
- 32Re: Архитектура - Страница 87
- 33Пошаговое улучшение качества - Страница 89
- VIЮзабилити программного обеспечения - Страница 95
- 35Сложность и прогрессирующий функционизм - Страница 98
- 36Назад к истокам - Страница 101
- 37Цветной язык - Страница 104
- 38Совершенствующиеся середнячки - Страница 107
- 39Пригодны ли вы - Страница 110
- 40Редактирование интерфейсов - Страница 113
- 41Сервис - Страница 115
- VIIУдобные объекты - Страница 117
- 43Глубокое понимание - Страница 121
- 44Абстрактные объекты - Страница 125
- 45Новая среда - Страница 128
- 46Полезные ситуации - Страница 132
- 47Эффективные объекты - Страница 136
- 48Связанные объекты - Страница 140
- VIIIЭто превосходное новое программное обеспечение - Страница 143
- 50Интерфейсы разнообразные - Страница 146
- 51Мастеры - Страница 148
- 52Образы будущего - Страница 150
- IXКультура и качество - Страница 152
- 54Агенты изменения - Страница 154
- 55Встроено самое лучшее - Страница 156
- 56Заметки из итальянского ресторана - Страница 159
- 57Наставничество - Страница 162
- 58На обучение - Страница 164
- 59Одаренные программисты - Страница 166
- 60Иконы отрасли - Страница 168
- 61Импресарио - Страница 170
- Приложение - Страница 172
- Библиография - Страница 174
К техническому консенсусу лучше приходить в диалоге и переговорах, чем в споре и препирательствах. Очень полезными могут быть сведения о переговорах, почерпнутые в других областях. Прежде всего, следует порекомендовать две великолепные книги, изданные в рамках «гарвардской программы по ведению переговоров»: Фишер (Fisher) и Юри (Ury) «Getting to Yes» (Как добиться согласия), 1981 [37] и Фишер и Браун (Brown) «Getting Together» (Как добиться единства), 1988 [38].
Вечной проблемой в переговорах является то, что участвующие в них стороны садятся за стол, зачастую придерживаясь какой-то позиции, размышления над которой уже отняли много сил. Вместо того чтобы быть искренне открытым, каждый приходит с заранее определенным решени-ем. Подобные переговоры трудны сами по себе. В лучшем случае они могут привести к компромиссу, но не к консенсусу. Кроме того, они легко могут перейти в перепалку между сторонниками разных подходов.
На помощь могут прийти простейшие методы. «Гарвардская программа по ведению переговоров» помогла понять, что переговоры идут лучше, если несогласные между собой участники садятся рядом, лицом к «их общей проблеме», а не рассматривают друг друга, сидя по разные стороны стола. Я обнаружил, что если при спорах по техническим вопросам группировки садятся вместе перед белой доской или экраном монитора, то это способствует более продуктивному обсуждению и скорейшему разрешению проблемы.
Собирая все вместеБывает так, что избежать применения заранее подготовленных предложений или уже выработанных решений не удается. Например, две группы в одной и той же компании, возможно, уже провели какую-то работу, которую необходимо принять во внимание. В некоторых компаниях даже поощряется конкуренция среди разработчиков на внутреннем свободном рынке идей. Когда приходит время создавать какую-то систему, авторы или соперники выставляют «на продажу» и описывают свои подходы. Достичь консенсуса будет легче, если перед началом обсуждения все альтернативы представит сотрудник, который менее пристрастен, чем те, кто эти варианты предложил. Выбор верного тона для обсуждения будет способствовать проектным решениям на основе согласия. Участников обсуждения следует поощрять к поиску сильных сторон других предложений, перед тем как переходить к критике. Стоит поощрять и реализм в оценке исходных позиций: «Поскольку для нас важнее знать о технических слабостях наших систем, чем делать вид, будто они идеальны, пусть каждый из вас расскажет о недостатках своего подхода».
Если в подготовке предложенных решений участвовали отдельные подгруппы, то после первоначальных обсуждений каждой подгруппе может быть предложено вернуться назад и улучшить свое предложение, используя то, что по их мнению является лучшим в подходах, предложенных другими. Тогда в начале следующей встречи противостоящие точки зрения окажутся ближе друг к другу.
В общем, технический консенсус достигается на основе комбинирования лучших черт всех вариантов и даже генерации новых. Вместо того чтобы начинать с конкретных технических предложений, зачастую бывает более разумно и эффективно начать с самой задачи. Первым делом команде нужно выяснить основные технические аспекты, присутствующие в раз-личных вариантах, а также базовые предпосылки и техническое обоснование исходных позиций и предлагаемых решений.
Процесс творческого синтеза начинается еще до первой встречи. Вместо того чтобы обдумывать, скажем, структуру файлов, члены команды могут очертить круг вопросов, связанных с разработкой эффективной файловой структуры. Они могут составить список конкретных критериев для принятия решений и определить их приоритетность. Их можно даже попросить пока не думать об идеях и предложениях. С большинством тех разработчиков программного обеспечения, которые в большей мере являются одиночками, проблема состоит, скорее, не в том, чтобы побудить их к работе, сколько в том, чтобы сдержать их пыл перед тем, как они сорвутся с мест.
Из журнала Computer Language Magazine, том 9, № 5, май 1992 г.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176