- •Том Демарко Тимоти Листер
- •Ieee Computer Society Благодарности к первому изданию
- •Ко второму изданию
- •Предисловие ко второму изданию
- •Предисловие к первому изданию
- •I. Управление человеческим ресурсом
- •1. А в это время где‑то гибнет проект
- •Суть вопроса
- •Миражи высоких технологий
- •2. Сделал чизбургер – продай его
- •Допустимость ошибок
- •Менеджмент, простецкое определение
- •Человеческие запчасти
- •Стабилизация проекта означает его смерть
- •У нас есть время только выполнить работу, но не думать о ней
- •3. Вена ждёт тебя
- •Испанская теория управления
- •Письмо из дома
- •Сверхурочные не существуют
- •Трудоголики
- •Производительность: выигранные сражения и проигранные войны
- •4. Качество? Если успеем
- •Бегство от совершенства
- •Качество ничего не стоит, но…
- •Право вето
- •5. Ещё раз о законе Паркинсона
- •Закон Паркинсона и закон Ньютона
- •А нашего Ивана вы видели?!
- •Университет Нового Южного Уэльса: некоторые данные
- •Вариация на тему закона Паркинсона
- •6. Лаетрил
- •Худейте во сне
- •Семь сирен
- •Это и есть руководство
- •II. Офисная среда
- •Часть II посвящена некоторым причинам потери времени и мерам, которые можно предпринять для создания стабильной, способствующей работе обстановки.
- •7. Мебельная полиция
- •Полицейский менталитет
- •Единообразный пластиковый подвал
- •8. «С девяти до пяти здесь совершенно невозможно работать»
- •Политика дефолта
- •Военные манёвры разработчиков: наблюдаемые факторы производительности
- •Индивидуальные различия
- •Что не влияет на производительность
- •Об этом не стоит рассказывать боссу
- •Влияние рабочего места
- •Что мы доказали?
- •9. Экономия на пространстве
- •Моровая язва
- •Мы прерываем обличительные речи, чтобы познакомить вас с фактами
- •Качество рабочего места и качество продукта
- •Открытие, достойное Нобелевской премии
- •Интермедия
- •Замеры производительности и неопознанные летающие объекты
- •Закон Гилба
- •Не позволяйте себе не знать
- •Измерения с закрытыми глазами
- •10. Работа ума и работа тела
- •Бесконечное отсутствие потока
- •Исчисление времени, основанное на потоке
- •Фактор «с»
- •Сад платков
- •О размышлениях на работе
- •11. Телефон
- •Путешествие в альтернативную реальность
- •Байки из склепа
- •Модифицированная телефонная мораль
- •Не пробуйте повторить это сами…
- •12. Верните дверь на место
- •Нет, наша песенка пока не спета
- •Роскошь
- •Творческое пространство
- •Жизненное пространство
- •Ломка корпоративного шаблона
- •13. Танцы с зонтиком
- •Александер и его органический порядок
- •Шаблоны
- •Первый шаблон: подгонка стандартного рабочего пространства
- •Второй шаблон: окна
- •Третий шаблон: закрытое и открытое пространство
- •Четвёртый шаблон: общее пространство
- •Шаблон шаблонов
- •Возвращение в реальный мир
- •III. Подходящие люди
- •14. Фактор Хорнблауэра
- •Прирождённые против обучившихся
- •Пластиковый человек установленной формы
- •Униформа
- •Кодовое слово: Профессионализм
- •Корпоративная энтропия
- •15. Как нанять жонглёра
- •Портфолио
- •Тесты на профпригодность
- •Организация проб
- •16. Счастлив работать здесь
- •Вопрос 1. Какая текучесть кадров наблюдалась в вашей организации в последние несколько лет?
- •Вопрос 2. Сколько в среднем стоит замена уволившегося сотрудника?
- •Текучка: очевидные затраты
- •Скрытая стоимость текучки
- •Почему люди уходят
- •Особая патология: переезд компании
- •Умонастроение постоянства
- •17. Самоизлечение системы
- •Детерминированные и недетерминированные системы
- •Тайный смысл Методологии
- •Безумие Методологии
- •Умышленное повиновение
- •Как не выплеснуть ребёнка с водой
- •И снова иллюзия высоких технологий
- •IV. Создание продуктивных команд
- •18. Целое больше суммы его частей
- •Понятие кристаллизации команды
- •Управление посредством истерического оптимизма
- •Пушки острова Наварон
- •Признаки кристаллизации команды
- •Команды и клики
- •19. Чёрная Команда
- •Материал для легенд
- •Жалкие земляне, кто вам теперь поможет?
- •20. Травля команд
- •Оборонительная позиция руководства
- •Бюрократия
- •Физическое разделение
- •Дробление рабочего времени
- •Снижение качества продукта
- •Идиотские сроки сдачи
- •Насаждение клик
- •И опять на ту же грустную тему
- •21. Ужин со спагетти
- •Начинают проявляться командные эффекты
- •Что здесь происходит?
- •22. Открытое кимоно
- •Сообщите о здоровье
- •Освобождающие уловки
- •Правила существуют, и мы их нарушаем
- •Цыплята с губами
- •Кто здесь главный?
- •23. Химия формирования команд
- •Культ качества
- •Элитная команда
- •Не распыляйте силы
- •Сетевая модель поведения команды
- •Сложный выбор – меню китайской кухни
- •Компиляция
- •V. Удовольствие от работы? здесь?
- •24. Хаос и порядок
- •Наша главная проблема – прогресс
- •Пилотные проекты
- •Военные игры67
- •Мозговой штурм
- •Обучение, путешествия, конференции, торжества, отдых
- •25. Свободные электроны
- •Феномен надомного промысла
- •Никакой родительской опеки
- •26. Хольгер Датчанин
- •Почему я?
- •Спящий гигант
- •Как пробудить Хольгера
- •VI. Наследие peopleware
- •27. Снова о травле команд
- •Проклятые плакаты
- •Сверхурочные: непредвиденный побочный эффект
- •28. Конкуренция
- •Рассмотрим аналогию
- •Нужно ли это? о важности обучения
- •Снова и снова о травле команд
- •Перепутанные метафоры
- •29. Программы модернизации процессов
- •Краткий исторический экскурс
- •Парадокс модернизации процессов
- •Это же выгодно
- •Новый мировой рекорд во всех категориях
- •Модернизация процессов: ведёт ли она к Тёмной стороне?79
- •Великое противоречие модернизации процессов
- •30. Как сделать перемены возможными
- •А теперь послушаем другого знаменитого системного консультанта
- •Классная идея, босс. Займусь немедленно.
- •Другая модель изменений
- •Безопасность прежде всего
- •31. Человеческий капитал
- •Что касается людей
- •Кому какое дело?
- •Какова длина взлётной полосы для опытного работника?
- •Под дудку Уолл‑стрит
- •32. Обучение организаций
- •Опыт и обучение
- •Пример перестройки
- •Главный вопрос про обучение организаций
- •Команда руководителей
- •Опасность пустого пространства
- •33. Самый страшный грех в руководстве – это…
- •К примеру
- •Собрания, посвящённые положению дел, нужны, чтобы подчёркивать положение
- •Преждевременный набор
- •Снова дробление
- •Уважайте свои вложения
- •34. Создание общины
- •Отступление от корпоративной политики
- •Почему это важно
- •Обуздание волшебства
- •Библиография
29. Программы модернизации процессов
Те замечательные ребята, что в восьмидесятых познакомили нас с Методологией с большой буквы М, без дела не сидели. Их последнее новшество – Движение За Улучшение Процессов, более современное, более всеобъемлющее, оно лучше, в нем больше лоска, оно ещё более амбициозно… но по сути это все то же старьё. Ваша локальная Программа Модернизации Процессов – все та же Методология, но переродившаяся. На этот раз подход «универсального размера» достиг апогея: один размер теперь подходит не только всем в вашей компании, он ещё и всем во всем мире. Способности вашей организации измеряются в контексте жёсткой модели. Чем точнее вы соответствуете модели, тем выше ваш балл. Чем выше, тем лучше. Самый высокий балл – лучше всего. Если бы все организации получали самые высокие баллы, они все были бы лучшими, и (так уж получается) выполняли бы свою работу абсолютно одинаково – лучшим способом. Лучший – он и в Африке лучший, тут нет разницы между веб‑приложениями для Yahoo и подпрограммами учёта пенсий в Aetna. По крайней мере, в теории…
Краткий исторический экскурс
На случай, если последние пятнадцать лет вы прожили на другой планете, мы представляем новейшую хронологию усовершенствования процессов:
1984: Министерство обороны США (U.S. Department of Defense, DoD) создаёт Институт программной инженерии (Software Engineering Institute, SEI) при Университете Карнеги‑Меллон. На институт возлагается миссия «создания стандартов совершенства в разработке программного обеспечения».
1987: SEI публикует первую пятиуровневую схему оценки «зрелости программного обеспечения».
1988: Опубликована важнейшая работа Уоттса Хамфри (Watts Humphrey) «Characterizing the Software Process: A Maturity Framework» (Описание процесса разработки программного обеспечения: общая схема зрелости) в журнале IEEE Software за март 1988 года. Проведены и опубликованы первые оценки. Первые свидетельства о существовании СММ (Capability Maturity ModelSM – модели зрелости потенциала).
1989: Создание групп разработки стандартов и первых организаций методологической поддержки. Публикация книги Хамфри «Managing the Software Process» (Управление процессом создания ПО).
1990‑е: Распространение СММ в Минобороны США и за пределами ведомства. Создание целевых уровней СММ во многих, если не во всех, крупных организациях, участвующих в разработке ПО.
Ядром СММ является упорядоченное множество ключевых областей процесса (Key Process Areas, KPAs), каждую из которых характеризует определённый отраслевой опыт, связанный с уровнем СММ. Исходя из качества опыта в ключевых областях, шкала делится на пять уровней организационной «зрелости». Переход на уровень определяется не только количеством накопленного опыта, но также порядком накопления этого опыта (скажем, заслугой не является накопление опыта Уровня 4, если организация ещё не достигла Уровня 3).
Парадокс модернизации процессов
Стандарты – это хорошо. Слава Богу, у нас есть стандарты, ибо без них мы не могли бы вставить кассету Kodak в фотоаппарат Minolta, штепсель кофеварки не подходил бы к розетке на стене, сигнал, передаваемый местной радиостанцией, не был бы принят вашим приёмником, ваш новый телефонный аппарат не подошёл бы для работы с вашей телефонной компанией, компакт‑диски не помещались бы в проигрыватель, факсы невозможно было бы разобрать, размеры одежды и обуви стали бы бессмысленными, новые покрышки не подходили бы к старым автомобилям, а сеть Интернет оставалась бы доступной лишь людям, которые её изобрели.
Такие стандарты полезны, но следует отметить, что великий триумф стандартов в современном мире – это практически всегда успех стандартных интерфейсов. Стандарт на резьбу, на пальчиковую батарейку или кассету с плёнкой содержит много сведений о конечном продукте – о том, как он взаимодействует с другими частями, но ни слова о процессе создания этого продукта. Батарейка имеет тип АА, если отвечает стандарту соответствующего интерфейса (по форме, размеру, отказоустойчивости, электрическим характеристикам и т. д.), независимо от того, создана ли она под водой, роботами или обученными обезьянами. Из успеха стандартов на интерфейсы можно лишь с некоторой натяжкой делать вывод, что процессы тоже следует стандартизировать.
И все же огромной привлекательностью обладает поиск идеального процесса. Работы Хамфри, Полка (Palk) и других представителей SEI вдумчивы, профессиональны, амбициозны и искренни:
Когда мы с Тимом составляли сборник «Software State‑of‑the‑Art: Selected Papers» (Современное программное обеспечение: избранные статьи), Dorset House, 1990, перед нами стояла задача отобрать наиболее значимые работы восьмидесятых. Работа Уоттса Хамфри «Characterizing the Software Process» была среди первых . В тот год в статье для «American Programmer» я задался целью выбрать лучшую из работ, вошедших в сборник. Без тени сомнения из тридцати одной статьи я выбрал статью Хамфри. Воздействие его работы в последующие годы, по моему мнению, подтвердило правильность такого выбора.
Т. Д.
Поиск идеальной практики или практики, подходящей на роль таковой, – предприятие полезное. Однако программы, предписывающие использование такой практики, – это нечто совершенно иное.
Парадокс СММ в том, что модернизация процесса – дело хорошее, а вот программы модернизации плохи очень часто, если не всегда. Модернизацией процессов всегда занимаются люди компетентные: они гордятся достигнутым прогрессом, источником которого может быть лишь совершенствование в предметной области. Такого рода низкоуровневое улучшение процесса есть простейшая гигиена для любого интеллектуального труда, но формальная модернизация процесса переносит ответственность с отдельного человека на организацию. Индивидуум может стремиться к достижению, практике, пропаганде качественных навыков, а организация способна лишь наделять их законным статусом. Именно в придании статуса законности кроется опасность.
Чтобы понять проблему такого подхода к модернизации процессов, необходимо отвлечься от проектов, успешно работающих одновременно с повышением уровня процесса, и обратить внимание на проекты, которые испытывают сложности.