Каким бы ни было объяснение этого феномена, я уже пришёл к следующему трезвому заключению: безнадёжные проекты являются нормой, а не исключением . Я полагаю, что сегодняшние разработчики ПО и менеджеры проектов достаточно изобретательны и полны желания управлять проектами разумным образом; я также полагаю, что сегодняшние пользователи и высшее руководство обладают гораздо большей компьютерной грамотностью, чем предыдущее поколение, и гораздо менее наивны относительно результатов, которые можно ожидать от разработчиков ПО в условиях ограниченных ресурсов. Однако это не останавливает и тех, и других от участия в очередном безнадёжном проекте, поскольку это диктуется необходимостью выживания в конкурентной борьбе, а также заманчивыми возможностями, предлагаемыми новыми технологиями. Бизнес-менеджеры могут вполне осознавать, что при разумном планировании разработка новой системы займёт 12 календарных месяцев, однако в то же время они будут настойчиво утверждать, что отсутствие готовой системы через 6 месяцев позволит конкурентам захватить весь рынок и вытеснить их новый продукт или услугу. Аналогично, технические специалисты могут вполне осознавать высокий риск использования новых технологий, таких, как Internet, однако они также будут утверждать, что новая технология в случае успеха обеспечит им стратегическое преимущество в конкурентной борьбе, и это оправдывает любой риск.
С другой стороны, отчёты таких организаций, как Standish Group, а также статистические данные таких авторитетных экспертов, как Capers Jones, Howard Rubin, Paul Strassman и Larry Putnam, говорят о том, что в среднем продолжительность проекта превышает плановую на 6-12 месяцев, а стоимость превышает бюджет на 50-100%. Конкретная ситуация зависит от размера проекта и ряда других факторов, но в любом случае суровая реальность заставляет вас предполагать, что условия вашего проекта повлекут за собой некоторую степень обречённости на неудачу, и это отразится на поведении менеджера проекта и его технических специалистов. Если проект с самого начала характеризуется высокой степенью риска, это наверняка повлечёт за собой массу сверхурочной работы, потерянных выходных, и, скорее всего, массу эмоциональных и физических стрессов до самого его завершения. Если даже проект начинается в разумной и спокойной обстановке, все равно велика вероятность, что по мере своего продолжения он выродится в безнадёжный — то ли первоначальные план и бюджет окажутся крайне нереалистичными, то ли у пользователей появится много новых требований, которые никак не учитывались при составлении первоначального плана и бюджета.
Итак, спрашивается: если невозможно избежать безнадёжных проектов, как их можно выдержать? Что следует предпринять для повышения своих шансов на успех? Когда следует быть готовым к компромиссу — и когда следует быть готовым уйти в отставку, если дальнейшее продолжение работы невозможно? Именно об этом идёт речь в данной книге. Очевидно, решение перечисленных проблем затрагивает такие вопросы, как кадровое обеспечение, процессы и методологии, а также методы и средства. Если вы собираетесь руководить безнадёжным проектом, следует ли настаивать на свободе выбора при формировании проектной команды? Следует ли занимать твёрдую позицию в отношении процессов и методологий, таких, как модель SEI-CMM, или следует позволить проектной команде отказаться от любых формальных методологий, если они считают, что это поможет им нормально выполнить работу? Следует ли настаивать на использовании определённых языков программирования, рабочих станций и CASE-средств, или более важно активно участвовать в политических баталиях?
Эти вопросы одинаково актуальны как для менеджера, отвечающего за проект, так и для технических специалистов, мозолистыми руками которых система проектируется, программируется, тестируется и документируется; все главы книги адресуются в равной степени обеим группам. Пару слов относительно менеджеров и технических специалистов: некоторые из комментариев, которые вы обнаружите в следующих главах, предполагают, что менеджеры «злые», а участники проектной команды — невинные, угнетённые жертвы. Очевидно, такая ситуация не является обязательной для всех проектов и всех компаний, хотя само существование безнадёжных проектов является, как правило, результатом сознательных решений руководства.
Если в этот момент вы решили, что у вас нет времени читать всю книгу, скажу только одно слово, которое может окупить время, потраченное на чтение предисловия: приоритетность ( triage ). Если вы участвуете в безнадёжном проекте, почти наверняка окажется недостаточно ресурсов, чтобы реализовать всю функциональность и возможности ПО, которые требуются конечному пользователю, в рамках утверждённого плана и бюджета. Так или иначе придётся решать, какие возможности следует реализовывать в первую очередь, а какими можно пожертвовать. Действительно, некоторые из незначительных возможностей не будут реализованы никогда , поэтому самое лучшее — это дать им спокойно умереть собственной смертью. Другие возможности являются достаточно важными, но также относительно легко реализуемыми, например, с помощью поставляемой библиотеки классов или используемых вами CASE-средств. Говоря языком медиков, эти возможности выживут сами по себе. Успех или неудача безнадёжного проекта зачастую зависит от способности проектной команды выделить критические функции и возможности, которые нельзя реализовать, не вкладывая значительные ресурсы и энергию.
Разумеется, чтобы спасти безнадёжный проект, недостаточно одной только правильной расстановки приоритетов в реализации функций (данный вопрос рассматривается в главе 3). Необходимо рассматривать также такие вопросы, как кадровое обеспечение, процессы и методологии, методы и средства. Я старался быть как можно более немногословным, чтобы вам хватило пары часов на прочтение всей книги; она могла бы помочь, как минимум, более реалистично оценить очередной безнадёжный проект.
Пожалуйста, ни в коем случае не воспринимайте эту книгу как «библию», и не думайте, что она может преподнести вам решение всех проблем. Стопроцентно правильных решений не существует; то, что срабатывает в одних компаниях и ситуациях, может не сработать в других. Также важно, что компромиссы, на которые готовы пойти некоторые менеджеры и технические специалисты, будут совершенно неприемлемы для других. Я предлагаю те решения, которые считаю разумными, но в конечном счёте вы сами должны определить, какие из них годятся для вас, а какие — нет.
Кроме всего прочего, я намереваюсь постоянно собирать на своём Web-сайте ( информацию и практические рекомендации от различных проектных команд по поводу наилучшей практики, наихудшей практики и разнообразных проблем. Даже если в вашем проектном бюджете недостаточно денег на покупку этой книги (такой крохотный бюджет уже говорит о рискованности проекта!), ровным счётом ничего не стоит обратиться к Web-странице.
Как бы вы не решили поступить, желаю самой большой удачи вашему очередному безнадёжному проекту.
ГЛАВА 1.
ВВЕДЕНИЕ
Что такое безнадёжные проекты? Почему они существуют? По какой причине здравомыслящие люди соглашаются участвовать в таких проектах?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55