Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Глава 6. Технология и средства

Читайте также:
  1. B. Яды, наркотические средства, психотропные и иные сильнодействующие вещества;
  2. I. СЕРДЕЧНО-СОСУДИСТЫЕ СРЕДСТВА
  3. I.2.3. Средства предупреждения правонарушений.
  4. I.VI. Организация обращения со средствами разграничения доступа
  5. II. ЭЛЕКТРОННЫЕ ОБУЧАЮШИЕ СРЕДСТВА, НЕ ИМЕЮЩИЕ ПЕЧАТНОГО ПРОТОТИПА
  6. III Технология использования градиента. Создание пользовательского градиента
  7. III. Порядок пользования средствами индивидуальной защиты

 

Летом 1992 года мне довелось обедать с дружной группой менеджеров среднего уровня Microsoft. Во время завязавшейся беседы я спросил, является ли для проектных команд Microsoft обычным делом использование таких методологий, как структурный анализ или объектно-ориентированное проектирование. Ответы были примерно следующими: «иногда», «хммм, вроде бы да», «от случая к случаю» и «а что это такое?». Когда же я спросил их относительно использования CASE-средств (которые в то время все еще были довольно популярными в индустрии ПО), то из их ответов понял, в чем заключается общее мнение майкрософтовцев: такие средства годятся для «людей с улицы». С таким выражением я еще не встречался, его можно грубо интерпретировать как «невежественные дикари, которые только что вылезли из своего первобытного леса и начали обучаться программированию, в отличие от настоящих программистов, которые не нуждаются во всяких финтифлюшках».

Будучи слегка уязвленным, я поинтересовался, используют ли их проектные команды хоть какие-нибудь средства, и в ответ услышал, что каждая команда Microsoft может выбрать любые средства, которые сочтет подходящими для своего проекта. Ухватившись за такой ответ, я спросил, какое средство считает наиболее важным типичная проектная команда?

«На днях я задал одной из проектных команд такой же вопрос», - ответил один из менеджеров. «Как вы думаете, что они ответили?»

«Какой-нибудь высокопроизводительный компилятор С++?», - спросил я. «Ассемблер? Или мощное средство отладки для устранения множества ошибок в их коде (хи-хи-хи)?»

«Ничего подобного», - ответил менеджер, игнорируя мое гнусное хихиканье. «Они ответили: электронная почта. Средний разработчик Microsoft получает сотню сообщений в день; он живет в электронной почте. Уберите электронную почту, и проект умрет».

Рассказывая этот анекдотический случай, я неспроста в самом начале упомянул 1992 год: эти события происходили до начала эры Internet и World Wide Web. Сотня почтовых сообщений в день потрясла мое воображение; в 1992 году я был безумно счастлив, если получал два или три сообщения в день. Однако можно представить себе, что если бы такой же вопрос о «наиболее важном средстве» был задан в 1996 году, ответом могло быть «World Wide Web»; по аналогии, «факс» в 1987, «ПК» в 1983, «онлайновый терминал» в 1976 и «мой собственный телефон на рабочем столе» в 1964 году, когда я только начинал свою карьеру программиста.

Очевидно, не следует ожидать, что команда безнадежного проекта сможет ограничиться только одним средством. Большинство команд - даже в «нормальных» проектах - пользуются в своей повседневной работе самыми разнообразными средствами и технологиями. Правда, иногда количество средств становится чересчур большим, технологии - слишком новыми, а иногда нежелательные средства навязываются им некомпетентными менеджерами.

Если вас встревожили эти обстоятельства, позвольте мне уверить вас, что я вовсе не собираюсь агитировать за использование экзотических, суперсовременных средств, которые, телепатически взаимодействуя с программистом, получают из его беспорядочных мыслей хорошо структурированный код. Напротив, я хочу обсудить понятие «минимально необходимого набора средств» для безнадежных проектов. Я хочу также обратить особое внимание на критически важные взаимосвязи между средствами и процессами, особенно поскольку процессы в безнадежном проекте, скорее всего, отличаются от тех, которые используются в организации. И, наконец, я хочу предостеречь от использования в безнадежном проекте совершенно новых средств.

 


Дата добавления: 2015-08-18; просмотров: 74 | Нарушение авторских прав


Читайте в этой же книге: Лояльность, отношение, мотивация и вознаграждения | Стимулирование участников проекта | Сверхурочная работа | Значение коммуникации | Проблемы формирования проектной команды | Условия работы | ГЛАВА 5. ПРОЦЕССЫ | Важность управления требованиями | SEI, ISO-9000. Формальные процессы против неформальных | Наилучшая практика и наихудшая практика |
<== предыдущая страница | следующая страница ==>
Управление рисками| Минимально необходимый набор средств

mybiblioteka.su - 2015-2024 год. (0.006 сек.)