"Эдвард Йордан "Смертельный марш" (Полное руководство для разработчика программного обеспечения по выживанию в безнадежных проектах)" - читать интересную книгу автора

каком-нибудь замечательном проекте GUI/DSS/DWH/HTML? Каково будет узнать,
что трехзвенная архитектура "клиент-сервер" позволит остальным участникам
проекта обойтись без вашей помощи?"
На самом деле, безнадежные проекты редко объявляются таковыми во
всеуслышание, и вам придется достаточно долго проработать в нанявшей вас
компании, прежде чем удастся обнаружить, что она обладает склонностью
плодить безнадежные проекты.
Если вашему коллеге приходится руководить безнадежным проектом, то ему
можно посоветовать включить в контракт пункт, позволяющий цивилизованным
способом выйти из проекта. Одна из серьезных причин выхода - неспособность
высшего руководства воспринимать правдивую информацию о проекте.
Принимающий на себя руководство безнадежным проектом должен быть готов к
тому, что у него будет практически отсутствовать пространство для маневра
в отношении функциональности, затрат или времени.

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

1.1 Определение безнадежного проекта

Под безнадежным проектом (death march) я понимаю такой проект, параметры
которого отклоняются от нормальных значений по крайней мере на 50%. По
отношению к софтверным проектам это обычно означает одно или более из
следующих ограничений:
* План проекта сжат более чем наполовину по сравнению с нормальным
расчетным планом; таким образом, проект, требующий в нормальных условиях
12 календарных месяцев, приходится выполнять за 6 или менее месяцев.
Жесткая конкуренция на мировом рынке делает такую ситуацию наиболее
распространенной.
* Количество разработчиков уменьшено более чем наполовину по сравнению с
действительно необходимым для проекта данного размера и масштаба; таким
образом, вместо формирования проектной команды из десяти человек,
менеджера проекта убеждают, что достаточно и пяти. Такое представление
может быть результатом наивной веры в магические возможности новых
CASE-средств или языков программирования удваивать производительность
труда разработчиков - несмотря на то, что разработчики не обучались или не
имеют практического опыта работы с новой технологией и, скорее всего, с
ними никто не советовался по поводу решения использовать новую технологию.
На сегодняшний день более общей причиной уменьшения количества
разработчиков является сокращение штатов компании в результате
реорганизации, реинжиниринга и т.д.
* Бюджет и связанные с ним ресурсы урезаны наполовину. Зачастую это
результат сокращения компании и других противозатратных мер, хотя это
может быть и результатом конкурентной борьбы за выгодный контракт. В этой
ситуации менеджер проекта в консалтинговой фирме получает из отдела
маркетинга следующую информацию: "У нас хорошая новость - мы выиграли
тендер, но есть и плохая новость - мы были вынуждены наполовину урезать
бюджет, чтобы победить конкурентов". Такое ограничение часто
непосредственно влияет на количество нанимаемых разработчиков, однако