Скотт Беркун - Искусство управления IT-проектами

Мне приснился классический ночной кошмар руководителя проекта: слабые технические требования, скудная спецификация, небольшой срок выполнения заказа, отсутствие дополнительного времени или ресурсов и настоящая западня: проект ориентирован на запросы клиента, и если продукт не будет поставлен в срок и не удовлетворит заказчика, то моя компания понесет весьма существенные потери. Сгустим краски:

• Клиент настаивает на том, что каждую проблему следует считать первостепенной, и отказывается расположить проблемы по приоритетности.

• Клиент все еще проявляет активность по добавлению новых функциональных особенностей.

• Ко всему прочему, клиент сильно раздражен, поскольку не считает, что наша компания в состоянии успешно справиться с этим проектом.

• Внутренняя обстановка усугубляется тем, что руководитель группы разработчиков на грани снятия с должности, тестировщик – на грани увольнения (а замены ему нет), а я, единственный руководитель проекта, заменяю того, кто не справился с работой, но остался в компании и не горит желанием помочь мне войти в курс дела.

Меня призвали разобраться во всей этой неразберихе только вчера. Есть отправная точка – 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).