ТОП авторов и книг ИСКАТЬ КНИГУ В БИБЛИОТЕКЕ
Все сказанное должно способствовать максимальному единению участников проекта.
К сожалению, этого явно недостаточно для большинства менеджеров безнадёжных проектов, поскольку они работают в организациях, пренебрегающих человеческим фактором даже в «нормальных» проектах. Хотя может показаться, что в таких условиях безнадёжные проекты обречены на провал, иногда получается как раз наоборот. Как отмечалось в главе 3, менеджер может быть вынужден согласиться с нереальными сроками или бюджетом, но в качестве компенсации может настаивать на своих решениях по вопросам персонала (на праве нанимать нужных исполнителей, соответствующим образом вознаграждать их и обеспечивать им нормальные условия работы).
Безнадёжный проект может восприниматься как угроза теми, кто желает сохранить бюрократическое статус-кво. Менеджер проекта имеет возможность обойти бюрократические ограничения, связанные с персоналом, с помощью непосредственных распоряжений высшего руководства, однако он должен быть готов к тому, что, поступая таким образом, приобретёт себе вечных врагов в лице кадровой службы и различных других администраторов. Тем не менее, если безнадёжный проект будет иметь громкий успех, он может послужить катализатором к изменению кадровой политики в последующих «нормальных» проектах.
В любом случае, в этой главе я вовсе не ставлю перед собой задачу менять сложившуюся в организации культуру управления людскими ресурсами. На эту тему уже написано достаточно много, включая отдельные главы в моих книгах Rise and Resurrection of the American Programmer и Decline and Fall of the American Programmer (ряд ссылок содержится также в конце этой главы). Главный вопрос данной главы заключается в следующем: если вы уже знакомы с «основами» управления персоналом, что нового привносят безнадёжные проекты?
4.1 Кадровые вопросы
Первая отличительная особенность безнадёжного проекта — явно выраженный акцент на правильном формировании проектной команды. Сотрудничая с софтверными организациями в разных странах, я сталкивался с четырьмя наиболее общими стратегиями формирования команды безнадёжного проекта:
1) нанять суперпрограммистов и предоставить им свободу действий;
2) настаивать на привлечении команды, которая готова к «невыполнимой миссии» и имеет опыт совместной работы;
3) набрать команду из простых смертных, но при условии, что они будут знать, на что идут;
4) взять любых сотрудников, которых вам дают, и сделать из них команду «невыполнимой миссии».
Первая стратегия выглядит весьма заманчиво, поскольку существует предположение, что суперпрограммисты будут невероятно продуктивны и достаточно изобретательны, чтобы предложить для безнадёжного проекта новые решения. С другой стороны, эта стратегия рискованна, поскольку суперпрограммисты обычно являются суперэгоистами и могут не ужиться друг с другом. Кроме того, такая стратегия для многих организаций проблематична, поскольку руководство не желает платить суперпрограммистам такую высокую зарплату, какую они требуют. И даже если это вам по карману, мало шансов на то, что они согласятся работать над безнадёжным проектом — ведь они все работают в Netscape или Microsoft или ещё где-нибудь, где, по их мнению, имеют место действительно впечатляющие проекты.
Вторая стратегия почти наверняка будет идеальной для большинства организаций, поскольку она не требует привлечения суперпрограммистов; кроме того, такой тип проектной команды воспет телесериалом «Невыполнимая миссия». Однако, если ваша организация предпринимает свой самый первый безнадёжный проект, такой команды просто не существует. Если же такие проекты ранее имели место, и они носили характер «самоубийственных», «камикадзе» или «отвратительных» проектов, то их команды в дальнейшем, скорее всего, распались и прекратили своё существование. Таким образом, стратегия сохранения в целости проектной команды успешного безнадёжного проекта должна, как правило, планироваться заранее как корпоративная стратегия, исходя из предположения, что безнадёжные проекты могут снова иметь место в будущем (более детально это будет обсуждаться в главе 7).
Третья стратегия по вполне очевидным причинам является наиболее распространённой для тех организаций, в которых мне довелось побывать. В большинстве организаций нет суперпрограммистов и нет тех, кто уцелел в предыдущих безнадёжных проектах. Следовательно, команда каждого нового безнадёжного проекта комплектуется заново. Участники команды вполне компетентны и, возможно, выше среднего уровня разработчиков в данной организации, однако от них нельзя ожидать сотворения чудес. Для данной стратегии жизненно важно, чтобы участники команды понимали, на что они идут; даже хотя они являются простыми смертными, им придётся совершать необычайные подвиги в разработке ПО.
Последней стратегии следует избегать при любых затратах. Если проект превращается в «свалку» для сотрудников, которых не хотят брать ни в какие другие проекты, он почти наверняка будет «самоубийственным». Такой тип команды также воспет Голливудом, особенно в таких фильмах, как Чёртова Дюжина ; их смысл заключается в том, что отверженных и неудачников может сплотить сильный, харизматический лидер и заставить их совершать чудеса, которые все считали невозможными. Все это хорошо, однако Голливуд ничего не рассказывает нам обо всех таких проектах с собранными из неудачников командами, которые закончились провалом. Мне думается, что если вы согласитесь руководить таким проектом (или участвовать в нем), то вас ждёт судьба самоубийцы.
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
К сожалению, этого явно недостаточно для большинства менеджеров безнадёжных проектов, поскольку они работают в организациях, пренебрегающих человеческим фактором даже в «нормальных» проектах. Хотя может показаться, что в таких условиях безнадёжные проекты обречены на провал, иногда получается как раз наоборот. Как отмечалось в главе 3, менеджер может быть вынужден согласиться с нереальными сроками или бюджетом, но в качестве компенсации может настаивать на своих решениях по вопросам персонала (на праве нанимать нужных исполнителей, соответствующим образом вознаграждать их и обеспечивать им нормальные условия работы).
Безнадёжный проект может восприниматься как угроза теми, кто желает сохранить бюрократическое статус-кво. Менеджер проекта имеет возможность обойти бюрократические ограничения, связанные с персоналом, с помощью непосредственных распоряжений высшего руководства, однако он должен быть готов к тому, что, поступая таким образом, приобретёт себе вечных врагов в лице кадровой службы и различных других администраторов. Тем не менее, если безнадёжный проект будет иметь громкий успех, он может послужить катализатором к изменению кадровой политики в последующих «нормальных» проектах.
В любом случае, в этой главе я вовсе не ставлю перед собой задачу менять сложившуюся в организации культуру управления людскими ресурсами. На эту тему уже написано достаточно много, включая отдельные главы в моих книгах Rise and Resurrection of the American Programmer и Decline and Fall of the American Programmer (ряд ссылок содержится также в конце этой главы). Главный вопрос данной главы заключается в следующем: если вы уже знакомы с «основами» управления персоналом, что нового привносят безнадёжные проекты?
4.1 Кадровые вопросы
Первая отличительная особенность безнадёжного проекта — явно выраженный акцент на правильном формировании проектной команды. Сотрудничая с софтверными организациями в разных странах, я сталкивался с четырьмя наиболее общими стратегиями формирования команды безнадёжного проекта:
1) нанять суперпрограммистов и предоставить им свободу действий;
2) настаивать на привлечении команды, которая готова к «невыполнимой миссии» и имеет опыт совместной работы;
3) набрать команду из простых смертных, но при условии, что они будут знать, на что идут;
4) взять любых сотрудников, которых вам дают, и сделать из них команду «невыполнимой миссии».
Первая стратегия выглядит весьма заманчиво, поскольку существует предположение, что суперпрограммисты будут невероятно продуктивны и достаточно изобретательны, чтобы предложить для безнадёжного проекта новые решения. С другой стороны, эта стратегия рискованна, поскольку суперпрограммисты обычно являются суперэгоистами и могут не ужиться друг с другом. Кроме того, такая стратегия для многих организаций проблематична, поскольку руководство не желает платить суперпрограммистам такую высокую зарплату, какую они требуют. И даже если это вам по карману, мало шансов на то, что они согласятся работать над безнадёжным проектом — ведь они все работают в Netscape или Microsoft или ещё где-нибудь, где, по их мнению, имеют место действительно впечатляющие проекты.
Вторая стратегия почти наверняка будет идеальной для большинства организаций, поскольку она не требует привлечения суперпрограммистов; кроме того, такой тип проектной команды воспет телесериалом «Невыполнимая миссия». Однако, если ваша организация предпринимает свой самый первый безнадёжный проект, такой команды просто не существует. Если же такие проекты ранее имели место, и они носили характер «самоубийственных», «камикадзе» или «отвратительных» проектов, то их команды в дальнейшем, скорее всего, распались и прекратили своё существование. Таким образом, стратегия сохранения в целости проектной команды успешного безнадёжного проекта должна, как правило, планироваться заранее как корпоративная стратегия, исходя из предположения, что безнадёжные проекты могут снова иметь место в будущем (более детально это будет обсуждаться в главе 7).
Третья стратегия по вполне очевидным причинам является наиболее распространённой для тех организаций, в которых мне довелось побывать. В большинстве организаций нет суперпрограммистов и нет тех, кто уцелел в предыдущих безнадёжных проектах. Следовательно, команда каждого нового безнадёжного проекта комплектуется заново. Участники команды вполне компетентны и, возможно, выше среднего уровня разработчиков в данной организации, однако от них нельзя ожидать сотворения чудес. Для данной стратегии жизненно важно, чтобы участники команды понимали, на что они идут; даже хотя они являются простыми смертными, им придётся совершать необычайные подвиги в разработке ПО.
Последней стратегии следует избегать при любых затратах. Если проект превращается в «свалку» для сотрудников, которых не хотят брать ни в какие другие проекты, он почти наверняка будет «самоубийственным». Такой тип команды также воспет Голливудом, особенно в таких фильмах, как Чёртова Дюжина ; их смысл заключается в том, что отверженных и неудачников может сплотить сильный, харизматический лидер и заставить их совершать чудеса, которые все считали невозможными. Все это хорошо, однако Голливуд ничего не рассказывает нам обо всех таких проектах с собранными из неудачников командами, которые закончились провалом. Мне думается, что если вы согласитесь руководить таким проектом (или участвовать в нем), то вас ждёт судьба самоубийцы.
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