Этот подход разумно применить в самом начале проекта, и тому есть ряд причин.
Наиболее очевидная причина лежит в плоскости экономики. Даже если средства хорошо работают и все знакомы с ними, их приобретение может стоить слишком дорого. Кроме того, на их получение может уйти слишком много времени — процесс приобретения в условиях обычной корпоративной бюрократии может завершиться уже после окончания проекта. Для большинства безнадёжных проектов следует сосредоточиться на небольшом количестве критически важных средств, и затем убедить высшее руководство (или соответствующую службу) в необходимости их приобретения.
С другой стороны, предположим, что команда работает в крупной корпорации, имеющей в своём распоряжении сотни различных средств, приобретавшихся в течение целого ряда лет. Следует ли их все использовать? Конечно, нет! Даже если все они работают, те умственные усилия, которые необходимо приложить, чтобы запомнить, как ими пользоваться, а также дополнительные усилия для обеспечения их совместной работы обычно сводят на нет всю выгоду. Можно провести аналогию с командой альпинистов, которые собираются штурмовать вершину и пытаются решить, какое снаряжение им использовать. Существуют вещи, которые необходимы (палатки, питьевая вода и т.д.) ; и, если маршрут не слишком сложный, можно взять с собой некоторые новомодные приспособления, о которых они прочли в своём любимом альпинистском журнале. Однако, если они собираются штурмовать Эверест, им не обойтись без помощи ослов-носильщиков или местных жителей, иначе они будут не в состоянии тащить на спине по 300 фунтов снаряжения на человека.
Команда безнадёжного проекта должна самостоятельно, независимо от принятых в организации стандартов, решить, какие средства являются необходимыми , а без каких можно обойтись. Меня очень удивил подход ряда организаций, в которых я побывал, к безнадёжным проектам, когда менеджер проекта с грустью говорил, что все проекты заставляют разрабатывать на КОБОЛе (или, в других организациях, в таком качестве может фигурировать Visual Basic или Oracle или что-нибудь ещё …), даже если эта технология совершенно не подходит для его проекта. Чепуха! Пошлите их подальше! Используйте те средства и технологии, в которых есть смысл! В противном случае это можно сравнить с ситуацией, когда кто-либо говорит руководителю команды альпинистов, собирающейся штурмовать Эверест: «Наш комитет решил, что ваша проектная команда должна взять подробную схему Нью-Йоркского метро, поскольку в большинстве проектов её сочли очень полезной». (Иногда в это дело вмешивается своими грязными руками политика. В прошлом году мне приходилось видеть несчастных сотрудников IBM, вынужденных использовать Lotus Freelance вместо PowerPoint и Lotus 1-2-3 вместо Excel, поскольку у них не было никакого желания ввязываться в противном случае в политические баталии. Аналогично, я не уверен, что хотел бы оказаться в проектной команде Microsoft, которая решила бы примерно в августе 1996 года использовать Netscape Navigator вместо Internet Explorer.)
Я думаю, очень важно, чтобы участники команды пришли к единому мнению относительно используемых в проекте средств, иначе наступит хаос. Разумеется, это утверждение не следует понимать слишком буквально; оно не означает, что все участники команды должны обязательно использовать один и тот же текстовый процессор для подготовки своих документов, однако, скорее всего, важно использовать один и тот же компилятор С++. Одна из проблем, связанных с безнадёжными проектами, заключается в том, что разработчики ПО считают допустимой полную анархию на индивидуальном уровне (например, если им хочется использовать никому не известный компилятор С++, который они переписали с университетского Web-сайта, то они считают, что это их неотъемлемое право). Это совсем не так: неотъемлемым правом обладает команда , и менеджер проекта должен неуклонно проводить его в жизнь во всех ситуациях, когда несовместимые средства могут привести к значительным разногласиям.
Это означает, что, пока участники команды не поработают вместе на нескольких безнадёжных проектах, они не придут к единому мнению относительно «минимального» набора средств. После того, как достигнут консенсус по поводу набора средств, команда может обсудить средства, которыми «следует» пользоваться, при этом проблемы заключаются в том, чтобы добиться согласия в команде и получить разрешение руководства на приобретение новых средств. Если после этого ещё останется время и желание, то можно обсудить качества неопределённого количества средств, которые «можно использовать» и в которых заинтересованы различные участники команды.
Выше я высказал мысль, что менеджер проекта должен быть готов к тому, чтобы настаивать на достижении консенсуса; в самом деле, это может быть одним из критериев, используемых менеджером для выбора потенциальных участников команды. Отметим, что то же самое можно сказать относительно процессов, которые мы обсуждали в главе 5. И, как мы увидим далее, это имеет ещё большее значение, поскольку средства и процессы тесно связаны друг с другом.
Помня обо всех высказанных предостережениях, практически невозможно для такого «дилетанта», как я, с ходу перечислить все средства, рекомендуемые для безнадёжного проекта. Когда задают такой вопрос, мой ответ — «это зависит от … » — обычен для присущего консультантам и приводящего к замешательству стремления уходить от прямого ответа на любой вопрос. Итак, поскольку вы крепко запомнили мои предыдущие советы, далее приводится перечень средств, которые мне хотелось бы видеть в безнадёжных проектах:
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 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71