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

Итак, вопрос заключается в следующем: какую роль должен играть руководитель проекта при выборе основных проектных направлений? Что должны делать руководители проектов, отслеживать ход реализации проекта и всячески содействовать этому процессу или возглавить весь процесс? А если они его возглавят, то в какой степени они должны быть причастны к проектированию программного продукта или веб-сайта?

Перед моей командой встал выбор, покупать дорогой готовый продукт или создать подобный продукт собственными силами; мы выбрали последнее, так как для нас этот продукт был важным инструментальным средством (анализатором производительности программ), мы владели этой тематикой и собирались перенастраивать это средство в будущем. После 5-ти месяцев разработки (с месячным отставанием от первоначального графика работ) продукт так должным образом и не заработал и был весьма далек от завершения (еще 8 недель по текущим прикидкам). Стоимость собственной разработки уже превысила стоимость продукта, имеющегося в продаже. Когда именно руководитель проекта должен трезво оценить реальное положение вещей и убедить руководство купить продукт? Или должны ли мы, несмотря на неудачу, потратить солидные средства и довести свой собственный продукт до завершения?

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

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

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

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

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

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