Все и сразу
Мне приснился классический ночной кошмар руководителя проекта: слабые технические требования, скудная спецификация, небольшой срок выполнения заказа, отсутствие дополнительного времени или ресурсов и настоящая западня: проект ориентирован на запросы клиента, и если продукт не будет поставлен в срок и не удовлетворит заказчика, то моя компания понесет весьма существенные потери. Сгустим краски:
• Клиент настаивает на том, что каждую проблему следует считать первостепенной, и отказывается расположить проблемы по приоритетности.
• Клиент все еще проявляет активность по добавлению новых функциональных особенностей.
• Ко всему прочему, клиент сильно раздражен, поскольку не считает, что наша компания в состоянии успешно справиться с этим проектом.
• Внутренняя обстановка усугубляется тем, что руководитель группы разработчиков на грани снятия с должности, тестировщик – на грани увольнения (а замены ему нет), а я, единственный руководитель проекта, заменяю того, кто не справился с работой, но остался в компании и не горит желанием помочь мне войти в курс дела.
Меня призвали разобраться во всей этой неразберихе только вчера. Есть отправная точка – 15 апреля. Мне нужна весьма изощренная стратегия, чтобы выстроить свой путь через всю внутреннюю и клиентскую политику, успокоить раздраженного клиента и поставить ему качественный программный продукт через четыре недели!
Сознание начинающего является начальным понятием дзен-буддизма. В канонической притче фигурирует пустая чаша: если сконцентрироваться на том, чем заполнена ваша чаша, в ней никогда не будет места для новых знаний. См. книгу Сюнрю Судзуки (Shunryu Suzuki) «Zen Mind, Beginner’s Mind» (Weatherhill, 1972).
Об этом свидетельствует отчет «CHAOS Report» (The Standish Group) – документ о бюджете, календарном плане и общих провалах проектов разработки программного обеспечения. Публикуется по адресу http://standishgroup.com/sample_research/.
Карл Поппер был одним из видных философов ХХ века. (См. http://en.wikipedia.org/wiki/Karl_Popper).
Из книги Джеймса Чайлза (James R. Chiles) «Inviting Disaster: Lessons from the Edge of Technology» (HarperBusiness, 2002).
Хорошее описание как матричного, так и других типов организации можно найти в книге Стивена Силбигера (Steven A. Silbiger) «The Ten-Day MBA» (William Morrow and Company, 1993) на с. 139–145. Впрочем, эту информацию можно найти практически в любой книге, посвященной теории управления.
Опубликована по адресу http://www.tompeters.com/col_entries.php?note=005297&year=1991.
Как-то в Питтсбурге мы с приятелями зашли пообедать в пиццерию и получили заверение, что столик будет готов через десять минут. Ровно через десять минут мой друг Чад МакДаниел поинтересовался готовностью столика и получил ответ распорядителя, что все будет готово через десять минут. Тогда он спросил: «Это те же десять минут или другие десять минут?» – но его шутку должным образом так и не оценили.
В оригинале «Feature-driven development». – Примеч. ред.
Сравнительное обсуждение традиционных и гибких методов разработки программных средств вы сможете найти в книге Барри Боэма (Barry Boehm) и Ричарда Тернера (Richard Turner) «Balancing Agility and Discipline: A Guide for the Perplexed» (Addison Wesley, 2003).
Информацию об определениях и понятиях изменений процесса разработки программного обеспечения, а также об управлении этими изменениями можно найти в книге Уоттса С. Хамфри (Watts S. Humphrey) «Managing the Software Process» (Addison Wesley Professional, January 1989).
«Understanding and Controlling Software Costs», IEEE Transactions on Software Engineering, т. 14, № 10, октябрь 1988, стр. 1462–77; а также книга «Software Engineering Economics» (Prentice Hall, 1991).
Календарные планы, основанные на имеющихся работах, называются восходящими, потому что они создаются командой, а календарные планы, основанные на потребностях управления, – нисходящими. Обычно разногласия между ними согласовываются.
В зависимости от характера непредвиденных обстоятельств (просчеты проектантов, политические революции, нашествия пришельцев и т. д.), заложенных в календарный план, рабочий график может быть разным. Если возможные провалы не рассматривались, календарный план не может вызывать доверия. Его создатель не проявил должного творческого подхода или скепсиса.
Процесс проведения структурной декомпозиции работ описан во многих книгах. К этой теме я вернусь в главе 14, но если вы хотите изучить ее более обстоятельно, начните с материалов, размещенных по адресу http://en.wikipedia.org/wiki/Work_breakdown_structure, или с книги Стефана Дево (Stephen Devaux) «Total Project Control» (Wiley, 1999).
В книге Кента Бека (Kent Beck) «Extreme Programming Explained» (Addison Wesley, 1999) предлагается программно-ориентированная модель распределения работ, при которой программисты сами выбирают себе работы. В идеале должен быть выдержан компромисс между тем, что лучше для проекта, и тем, что лучше для отдельных специалистов команды.
См. книгу Кента Бека (Kent Beck) и Мартина Фоулера (Martin Fowler) «Planning Extreme Programming» (Addison Wesley, 2002), стр. 60–62.
Стандартная формула для метода PERT: лучший расчет + (4 × наиболее вероятный расчет) + худший расчет/6. Имейте в виду, что существует огромное количество разновидностей и теорий наилучших взвешенных расчетов.
Сравнить другие типы проектов вы сможете, обратившись по адресу http://www.joelonsoftware.com/articles/FiveWorlds.html.
Эндрю Стеллман (Andrew Stellman), один из научных редакторов данной книги, несколько раз угрожал мне физической расправой, если я не расскажу о качестве программного продукта, но эта глубокая тема так и не вписалась в рамки моей книги. Для начала порекомендую вам две другие книги: «Out of the Crisis» (MIT Press, 2000) У. Эдвардса Дэминга (W. Edwards Deming) и «Quality Is Free» (Signet Books, 1992) Филиппа Кросби (Philip Crosby).
Файзал Джафдат (Faisal Jawdat), один из научных редакторов данной книги, угрожал мне изощренными пытками, если я не отмечу всю иронию ситуации, в которой после всего сказанного я продолжал работать на Microsoft.
Эта сноска дана специально, чтобы заставить читателя обращать на сноски хоть какое-то внимание. А если серьезно: когда проектировщики работают на себя, они имеют склонность многократно переделывать сделанное, возможно, расслабляясь в отсутствие образа потребителя, на которого надо работать.
Обратите внимание на замечательную книгу Дональда Гауса (Donald Gause) и Джералда Вейнберга (Gerald Weinberg) «Exploring Requirements: Quality Before Design» (Dorset House, 1989).
Этот метод описан в книге Алистера Кокборна (Alistair Cockburn) «Writing Eff ective Use Cases» (Addison Wesley, 2000).
Прочтите книгу Дэниела Шактера (Daniel Schacter) «The Seven Sins of Memory» (Mariner Books, 2002) или посмотрите замечательный фильм «Помни» («Memento»). Это поможет вам осознать, сколь ограничена и ненадежна человеческая память.
Из книги «Piloting Palm: The Inside Story of Palm, Handspring and the Birth of the Billion-Dollar-Handheld Industry» авторов Андреа Баттера (Andrea Butter) и Дэвида Поги (David Pogue) (Wiley, 2002), стр. 72.
Если команда получает заказ на прорывную разработку, но подходит к планированию как к рутинной рядовой работе, нужно быть настороже. Это похоже на нейрохирургическую операцию, проводимую с использованием бытовой аптечки. Если планирование не отвечает сложности задач, так или иначе готовьтесь к провалу.
Дополнительный материал можно найти в книге Дональда Гауса (Donald Gause) и Джеральда Вейнберга (Gerald Weinberg) «Exploring Requirements: Quality Before Design» (Dorset House, 1989).
См. статью «How to give and receive criticism» по адресу http://www.scottberkun.com/essays/35-how-to-give-and-receive-criticism/.
Тем не менее изобретатель простой формулы добычи воды или создания компаса из песка получит первый приз в конкурсе на лучшую идею года при проведении соревнований «Затерявшийся в пустыне». Это пример четко обозначенной проблемы с невероятно сложным решением (простая, но трудноразрешимая). Когда люди жалуются, что требования настолько сложны, что проблему решить невозможно, значит, голова у них забита всякой чепухой. В формулировках проблем указано, на какую гору следует забраться, но там ничего не говорится о том, как взобраться на вершину.
В качестве одного из примеров можно привести миноксидин, лекарственный препарат для лечения повышенного кровяного давления. Оказалось, он эффективен в решении совершенно иной проблемы – облысения. По одному из критериев формула миноксидина может оцениваться отрицательно, по другому – положительно. Так была эта формула хорошей идеей или нет? Все зависит от того, в каком контексте ее рассматривать.
