«Ладно, мы будем двигаться дальше и обойдёмся без этого идиота Мелвина из департамента маркетинга; все, на что он способен — это не соглашаться никогда и ни с чем». При этом может возникнуть следующая проблема: Мелвин, получив серьёзную «политическую» пощёчину и чувствуя, что его игнорируют (и что менеджер проекта считает его идиотом!), скорее всего найдёт способ саботировать проект.
Теоретически каждый понимает и соглашается с такой точкой зрения, однако на практике просто удивительно наблюдать, как безнадёжные проекты потихоньку обрастают все новыми и новыми требованиями. Дополнительные требования, модификации существующих требований и недвусмысленные предложения игнорировать некоторые требования — все это сваливается на проектную команду в виде телефонных звонков, посланий по электронной почте и разговоров с глазу на глаз с менеджером проекта. Многие из этих предложений предваряются такими успокаивающими фразами, как «извини, что я забыл об этом сказать на нашем последнем совещании, но … » или «я рассчитывал, что у нашей группы управления будет время справиться с этой проблемой, но … ».
Существует ли у менеджера проекта такая формальная группа управления — т.е., группа, состоящая из акционеров и заинтересованных лиц, которая оценивает полученные в проекте результаты и принимает определённые решения относительно приоритетности требований — или нет, в данном случае не имеет значения; это зависит от того стиля управления и организации проектов, который сложился в каждой организации. Но что действительно имеет значение для успешного завершения безнадёжного проекта — это тщательное документирование каждой модификации, вносимой в исходные требования, и извещение о ней всех акционеров и заинтересованных лиц. Если вице-президент по финансам хочет потихоньку вставить в проект ещё одно приоритетное требование, это замечательно; однако при этом менеджер проекта должен позаботиться, чтобы об этом узнали вице-президент по маркетингу и исполнительный директор.
5.3 SEI, ISO-9000. Формальные процессы против неформальных
Некоторые менеджеры, прочтя предыдущий раздел данной главы, могут высказать недовольство: «Вот здорово! Это выглядит гораздо более формальным, чем все, что мы когда-либо делали!» Когда мне приходилось сталкиваться с такой реакцией в некоторых консалтинговых проектах, это просто ставило меня в тупик. С одной стороны, я уверен, что документирование, определение приоритетов и управление требованиями просто необходимы (независимо от того, какие средства и методы для этого используются) ; с другой стороны, я опасаюсь следующего: когда проектной команде, и без того заваленной работой выше головы, навязывается совершенно новый и незнакомый процесс, то этот процесс — например, управление требованиями — может оказаться последней каплей, переполнившей чашу терпения.
В самом деле, у меня нет для этой дилеммы другого решения, кроме как надеяться, что проектная команда все же сможет справиться с одной новой идеей среди прочих своих средств и процессов. Однако, меня охватывает гораздо большее беспокойство, когда я вижу команды, которые предпринимают свой первый безнадёжный проект с решением (или, что более вероятно, с указанием, навязанным им блюстителями методологии), обязывающим их использовать формальные процессы, например, те, которые регламентируются SEI-CMM или ISO-9000. Формальные процессы — это великая вещь, если вы хорошо знаете, что делаете, и если вы уже использовали их прежде. Однако, реальность такова, что такие формальные процессы, как правило, ранее вообще не использовались в организации, и безнадёжный проект представляет собой пилотный проект для апробации структурного анализа или ISO-9000.
Какое безумие! Это действительно последняя капля, которая переполнит чашу терпения; в конце концов типичный безнадёжный проект пытается выполнить то, что раньше никогда не делалось, и (несмотря на мои предостережения в главе 4) команда нередко состоит из людей, которые никогда раньше не работали вместе. Так мало того, они ещё вынуждены осваивать использование незнакомой методологии или процесса, не будучи уверенными в том, что это им необходимо в первую очередь, и, напротив, будучи убеждёнными, что это только затормозит их работу. Чему же тогда удивляются блюстители методологии, когда они в подобных обстоятельствах сталкиваются с сопротивлением? Консультант Doug Scott недавно привёл мне пример такой ситуации:
В одном проекте, насколько мне известно, потребовался диаграммер для ERD, и они приобрели Excelerator. Обнаружив, что он поддерживает методологию SSADM, они внедрили её без какого-либо обучения персонала, после чего обнаружили, что темп работы на проектом значительно снизился (фактически, работа просто остановилась), в то время как каждый был занят чтением руководств, освоением средств и решением проблемы, что делать дальше (или переделывать то, что было сделано в «неправильном» порядке). Почти идеальный сценарий для тех, кто наблюдает за безнадёжными проектами.
Чтобы достичь успеха, проектная команда должна придти к соглашению, какие процессы будут формализованы — например, контроль исходного кода, управление изменениями и (хорошо бы) управление требованиями — и какие будут выполняться на полностью неформальной основе (например, проектирование пользовательского интерфейса). Бессмысленно навязывать какой-либо процесс в обязательном порядке, если никто не собирается ему следовать. Блюстители методологии просто зря теряют время, пытаясь сделать это, а в результате, что гораздо хуже, может напрасно потерять время проектная команда (во многих случаях эти деятели не совершают ничего полезного, кроме суеты вокруг департамента информационных технологий и надоедания и без того уставшей от всего проектной команде).
Это означает, что менеджер безнадёжного проекта должен безоговорочно настаивать на процессах, которые он считает принципиально важными — например: «Каждый, кто посмеет внести изменения в исходный код, минуя процесс управления изменениями, будет немедленно уволен!» Или проектная команда должна сама сознательно пойти на внедрение процесса, понимая, что это позволит сократить затраты. Такое может скорее произойти в том случае, если участники команды ранее уже работали вместе и приобрели общий опыт использования различных процессов создания ПО; и наоборот, это маловероятно, если только один из участников команды встанет и скажет: «Я глубоко уверен, что структурный анализ является критически важным для успеха нашего проекта», в то время как другие и понятия не имеют, о чем это он говорит. Ещё одно утверждение, следующее из этого правила: попытка внедрить в безнадёжном проекте новый, незнакомый процесс может закончиться катастрофически, даже если команда верит, что он может помочь в работе. Проблемы с освоением, неизбежная путаница и споры по поводу деталей процесса обычно сводят на нет все выгоды.
Это означает, что такие формальные подходы, как SEI-CMM, ISO-9000 или внедрение новых методологий анализа/проектирования должны иметь место где-нибудь за пределами безнадёжного проекта. Внедрение таких процессов имеет смысл как часть долговременной корпоративной стратегии, и должно начинаться с выполнения пилотного проекта (который не должен быть безнадёжным проектом), сопровождаясь организацией необходимого обучения.
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
Теоретически каждый понимает и соглашается с такой точкой зрения, однако на практике просто удивительно наблюдать, как безнадёжные проекты потихоньку обрастают все новыми и новыми требованиями. Дополнительные требования, модификации существующих требований и недвусмысленные предложения игнорировать некоторые требования — все это сваливается на проектную команду в виде телефонных звонков, посланий по электронной почте и разговоров с глазу на глаз с менеджером проекта. Многие из этих предложений предваряются такими успокаивающими фразами, как «извини, что я забыл об этом сказать на нашем последнем совещании, но … » или «я рассчитывал, что у нашей группы управления будет время справиться с этой проблемой, но … ».
Существует ли у менеджера проекта такая формальная группа управления — т.е., группа, состоящая из акционеров и заинтересованных лиц, которая оценивает полученные в проекте результаты и принимает определённые решения относительно приоритетности требований — или нет, в данном случае не имеет значения; это зависит от того стиля управления и организации проектов, который сложился в каждой организации. Но что действительно имеет значение для успешного завершения безнадёжного проекта — это тщательное документирование каждой модификации, вносимой в исходные требования, и извещение о ней всех акционеров и заинтересованных лиц. Если вице-президент по финансам хочет потихоньку вставить в проект ещё одно приоритетное требование, это замечательно; однако при этом менеджер проекта должен позаботиться, чтобы об этом узнали вице-президент по маркетингу и исполнительный директор.
5.3 SEI, ISO-9000. Формальные процессы против неформальных
Некоторые менеджеры, прочтя предыдущий раздел данной главы, могут высказать недовольство: «Вот здорово! Это выглядит гораздо более формальным, чем все, что мы когда-либо делали!» Когда мне приходилось сталкиваться с такой реакцией в некоторых консалтинговых проектах, это просто ставило меня в тупик. С одной стороны, я уверен, что документирование, определение приоритетов и управление требованиями просто необходимы (независимо от того, какие средства и методы для этого используются) ; с другой стороны, я опасаюсь следующего: когда проектной команде, и без того заваленной работой выше головы, навязывается совершенно новый и незнакомый процесс, то этот процесс — например, управление требованиями — может оказаться последней каплей, переполнившей чашу терпения.
В самом деле, у меня нет для этой дилеммы другого решения, кроме как надеяться, что проектная команда все же сможет справиться с одной новой идеей среди прочих своих средств и процессов. Однако, меня охватывает гораздо большее беспокойство, когда я вижу команды, которые предпринимают свой первый безнадёжный проект с решением (или, что более вероятно, с указанием, навязанным им блюстителями методологии), обязывающим их использовать формальные процессы, например, те, которые регламентируются SEI-CMM или ISO-9000. Формальные процессы — это великая вещь, если вы хорошо знаете, что делаете, и если вы уже использовали их прежде. Однако, реальность такова, что такие формальные процессы, как правило, ранее вообще не использовались в организации, и безнадёжный проект представляет собой пилотный проект для апробации структурного анализа или ISO-9000.
Какое безумие! Это действительно последняя капля, которая переполнит чашу терпения; в конце концов типичный безнадёжный проект пытается выполнить то, что раньше никогда не делалось, и (несмотря на мои предостережения в главе 4) команда нередко состоит из людей, которые никогда раньше не работали вместе. Так мало того, они ещё вынуждены осваивать использование незнакомой методологии или процесса, не будучи уверенными в том, что это им необходимо в первую очередь, и, напротив, будучи убеждёнными, что это только затормозит их работу. Чему же тогда удивляются блюстители методологии, когда они в подобных обстоятельствах сталкиваются с сопротивлением? Консультант Doug Scott недавно привёл мне пример такой ситуации:
В одном проекте, насколько мне известно, потребовался диаграммер для ERD, и они приобрели Excelerator. Обнаружив, что он поддерживает методологию SSADM, они внедрили её без какого-либо обучения персонала, после чего обнаружили, что темп работы на проектом значительно снизился (фактически, работа просто остановилась), в то время как каждый был занят чтением руководств, освоением средств и решением проблемы, что делать дальше (или переделывать то, что было сделано в «неправильном» порядке). Почти идеальный сценарий для тех, кто наблюдает за безнадёжными проектами.
Чтобы достичь успеха, проектная команда должна придти к соглашению, какие процессы будут формализованы — например, контроль исходного кода, управление изменениями и (хорошо бы) управление требованиями — и какие будут выполняться на полностью неформальной основе (например, проектирование пользовательского интерфейса). Бессмысленно навязывать какой-либо процесс в обязательном порядке, если никто не собирается ему следовать. Блюстители методологии просто зря теряют время, пытаясь сделать это, а в результате, что гораздо хуже, может напрасно потерять время проектная команда (во многих случаях эти деятели не совершают ничего полезного, кроме суеты вокруг департамента информационных технологий и надоедания и без того уставшей от всего проектной команде).
Это означает, что менеджер безнадёжного проекта должен безоговорочно настаивать на процессах, которые он считает принципиально важными — например: «Каждый, кто посмеет внести изменения в исходный код, минуя процесс управления изменениями, будет немедленно уволен!» Или проектная команда должна сама сознательно пойти на внедрение процесса, понимая, что это позволит сократить затраты. Такое может скорее произойти в том случае, если участники команды ранее уже работали вместе и приобрели общий опыт использования различных процессов создания ПО; и наоборот, это маловероятно, если только один из участников команды встанет и скажет: «Я глубоко уверен, что структурный анализ является критически важным для успеха нашего проекта», в то время как другие и понятия не имеют, о чем это он говорит. Ещё одно утверждение, следующее из этого правила: попытка внедрить в безнадёжном проекте новый, незнакомый процесс может закончиться катастрофически, даже если команда верит, что он может помочь в работе. Проблемы с освоением, неизбежная путаница и споры по поводу деталей процесса обычно сводят на нет все выгоды.
Это означает, что такие формальные подходы, как SEI-CMM, ISO-9000 или внедрение новых методологий анализа/проектирования должны иметь место где-нибудь за пределами безнадёжного проекта. Внедрение таких процессов имеет смысл как часть долговременной корпоративной стратегии, и должно начинаться с выполнения пилотного проекта (который не должен быть безнадёжным проектом), сопровождаясь организацией необходимого обучения.
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