ТОП авторов и книг ИСКАТЬ КНИГУ В БИБЛИОТЕКЕ
Как сказал 150 лет назад Генри Дэвид Торо, люди становятся орудиями в руках собственных средств.
Литература к главе:
1) Mellir Page-Jones.The Seven Stages in Software Engineering. American Programmer, July-August 1990.
2) Paul G. Basset. Framing Software Reuse: Lessons from the Real World. Upper Saddle River, NJ: Prentice Hall, 1996.
Дополнительная литература:
1) Michael Schrage. No More Teams! Mastering the Dynamics of Creative Collaboration. New York: Doubleday-Dell Publishing Company, 1995.
ГЛАВА 7.
БЕЗНАДЁЖНЫЕ ПРОЕКТЫ КАК ОБРАЗ ЖИЗНИ
На протяжении всей книги я утверждал противоречие, которое нам сейчас необходимо разрешить. С одной стороны, я утверждал, что безнадёжные проекты качественно отличаются от всех остальных «нормальных» проектов, выполняемых организациями-разработчиками. С другой стороны, в главе 1 я отметил, что условия, порождающие безнадёжные проекты — сжатые сроки и бюджет, чрезмерные требования к функциональности — встречаются в сегодняшних организациях все чаще и чаще.
Многие разработчики и менеджеры могут задать вопрос: разумно ли вообще планировать безнадёжные проекты. John Boddie, автор Crunch Mode, таким образом высказался относительно отрасли, в которой ему довелось работать:
Я провёл годы в лотерейном бизнесе, где все делается в экстремальных условиях, поскольку это единственный способ существования и развития отрасли. Если вы не желаете работать в таком режиме, то не сможете играть в этой песочнице. Разработчики в данной отрасли мирятся с таким положением, поскольку им доставляет удовольствие добиваться успеха в краткосрочных и в высшей степени интенсивных проектах и получать взамен значительную свободу действий, включая, в частности, двухмесячные отпуска между проектами. Эти команды считают себя элитой, и компании всячески поддерживают такие убеждения.
И, как отмечает Doug Scott:
Руководством движут различные мотивы. Они знают, что риск лишиться своей власти в наши дни особенно велик, и стремятся этого избежать, затевая различные проекты. Они также понимают, что на их выполнение нам потребуется не так уж мало времени из-за различных бюрократические процедур. Они полагают, что если особо обозначить важность конкретного проекта по сравнению с остальными, то эти процедуры можно будет обойти, не предпринимая для этого никаких специальных действий. Они понимают, что не могут привлечь к этой работе самых лучших специалистов; они также понимают, что самые лучшие технологии могут помочь в том случае, если они не потребуют длительного цикла обучения, что, в свою очередь, лишает возможности использовать такие технологии в данном проекте. Или наоборот, они верят шумной рекламе и считают, что новые технологии чудесным образом окажутся вполне зрелыми, свободными от ошибок, и их тотчас же сможет понять каждый.
Однако, если безнадёжные проекты являются нормой, следует ли тогда называть их безнадёжными? Не становятся ли они частью корпоративной культуры? Далее мы обсудим, почему такая трансформация может иметь место в нормальных организациях-разработчиках ПО, и затем перейдём к более серьёзному вопросу: каким образом можно изменить культуру обычной сегодняшней организации с тем, чтобы она могла эффективно справляться с безнадёжными проектами, не считая их какой-то аномалией?
7.1 Почему безнадёжные проекты становятся нормой
Начнём с анализа вероятности того, что безнадёжные проекты будут становиться нормой. На протяжении всей книги я приводил по крайней мере три причины, по которым это могло бы стать реальностью:
1) Организация находится в разгаре продолжающегося кризиса — это может быть результатом неудачного совпадения нескольких неожиданных кризисов, случившихся за небольшой промежуток времени; однако чаще это относится к организациям, оказавшимся в трудном положении, отчаянно пытаясь справиться с «потоком изменений» на рынке или с используемой технологией. В большинстве случаев такие организации оказываются в слишком отчаянном положении, чтобы суметь отступить на шаг назад и реорганизовать свою работу таким образом, чтобы спокойно планировать и выполнять все свои проекты. Редким исключением является ситуация, когда в компанию приходит новый руководитель, призванный вывести её из кризиса; при этом он может внедрить в компании совершенно иной стиль работы.
2) Руководство и пользователи принимают такой подход в качестве своей стандартной позиции во время переговоров — как отмечалось в главах 1 и 2, в таком духе зачастую начинается первый безнадёжный проект; однако, если такой подход сработает один раз, почему бы не повторить его снова? Если департамент маркетинга или департамент финансов, или некоторое другое подразделение в организации столкнётся с необходимостью «перманентного» реинжиниринга для достижения конкурентоспособного уровня, они могут также принять соответствующее решение и настаивать, чтобы все разработчики и поставщики, с которыми они взаимодействуют, аналогичным образом подвергли себя реинжинирингу. С точки зрения таких подразделений департамент информационных технологий рассматривается как ещё один «поставщик» продуктов и услуг. Вариацией на эту тему является указание высшего руководства департаменту информационных технологий: «Если ваши люди не улучшат радикально свою продуктивность во всех проектах, мы отдадим все на аутсорсинг в Индию!»
3) Это часть «стратегического преимущества» компании — такой подход может иметь место в организациях, подобных EDS, и он является вполне определённым в таких организациях, как Cambridge Technology Partners. Он имеет смысл для консалтинговых организаций, где производительность проектных команд является их бизнесом.
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
Литература к главе:
1) Mellir Page-Jones.The Seven Stages in Software Engineering. American Programmer, July-August 1990.
2) Paul G. Basset. Framing Software Reuse: Lessons from the Real World. Upper Saddle River, NJ: Prentice Hall, 1996.
Дополнительная литература:
1) Michael Schrage. No More Teams! Mastering the Dynamics of Creative Collaboration. New York: Doubleday-Dell Publishing Company, 1995.
ГЛАВА 7.
БЕЗНАДЁЖНЫЕ ПРОЕКТЫ КАК ОБРАЗ ЖИЗНИ
На протяжении всей книги я утверждал противоречие, которое нам сейчас необходимо разрешить. С одной стороны, я утверждал, что безнадёжные проекты качественно отличаются от всех остальных «нормальных» проектов, выполняемых организациями-разработчиками. С другой стороны, в главе 1 я отметил, что условия, порождающие безнадёжные проекты — сжатые сроки и бюджет, чрезмерные требования к функциональности — встречаются в сегодняшних организациях все чаще и чаще.
Многие разработчики и менеджеры могут задать вопрос: разумно ли вообще планировать безнадёжные проекты. John Boddie, автор Crunch Mode, таким образом высказался относительно отрасли, в которой ему довелось работать:
Я провёл годы в лотерейном бизнесе, где все делается в экстремальных условиях, поскольку это единственный способ существования и развития отрасли. Если вы не желаете работать в таком режиме, то не сможете играть в этой песочнице. Разработчики в данной отрасли мирятся с таким положением, поскольку им доставляет удовольствие добиваться успеха в краткосрочных и в высшей степени интенсивных проектах и получать взамен значительную свободу действий, включая, в частности, двухмесячные отпуска между проектами. Эти команды считают себя элитой, и компании всячески поддерживают такие убеждения.
И, как отмечает Doug Scott:
Руководством движут различные мотивы. Они знают, что риск лишиться своей власти в наши дни особенно велик, и стремятся этого избежать, затевая различные проекты. Они также понимают, что на их выполнение нам потребуется не так уж мало времени из-за различных бюрократические процедур. Они полагают, что если особо обозначить важность конкретного проекта по сравнению с остальными, то эти процедуры можно будет обойти, не предпринимая для этого никаких специальных действий. Они понимают, что не могут привлечь к этой работе самых лучших специалистов; они также понимают, что самые лучшие технологии могут помочь в том случае, если они не потребуют длительного цикла обучения, что, в свою очередь, лишает возможности использовать такие технологии в данном проекте. Или наоборот, они верят шумной рекламе и считают, что новые технологии чудесным образом окажутся вполне зрелыми, свободными от ошибок, и их тотчас же сможет понять каждый.
Однако, если безнадёжные проекты являются нормой, следует ли тогда называть их безнадёжными? Не становятся ли они частью корпоративной культуры? Далее мы обсудим, почему такая трансформация может иметь место в нормальных организациях-разработчиках ПО, и затем перейдём к более серьёзному вопросу: каким образом можно изменить культуру обычной сегодняшней организации с тем, чтобы она могла эффективно справляться с безнадёжными проектами, не считая их какой-то аномалией?
7.1 Почему безнадёжные проекты становятся нормой
Начнём с анализа вероятности того, что безнадёжные проекты будут становиться нормой. На протяжении всей книги я приводил по крайней мере три причины, по которым это могло бы стать реальностью:
1) Организация находится в разгаре продолжающегося кризиса — это может быть результатом неудачного совпадения нескольких неожиданных кризисов, случившихся за небольшой промежуток времени; однако чаще это относится к организациям, оказавшимся в трудном положении, отчаянно пытаясь справиться с «потоком изменений» на рынке или с используемой технологией. В большинстве случаев такие организации оказываются в слишком отчаянном положении, чтобы суметь отступить на шаг назад и реорганизовать свою работу таким образом, чтобы спокойно планировать и выполнять все свои проекты. Редким исключением является ситуация, когда в компанию приходит новый руководитель, призванный вывести её из кризиса; при этом он может внедрить в компании совершенно иной стиль работы.
2) Руководство и пользователи принимают такой подход в качестве своей стандартной позиции во время переговоров — как отмечалось в главах 1 и 2, в таком духе зачастую начинается первый безнадёжный проект; однако, если такой подход сработает один раз, почему бы не повторить его снова? Если департамент маркетинга или департамент финансов, или некоторое другое подразделение в организации столкнётся с необходимостью «перманентного» реинжиниринга для достижения конкурентоспособного уровня, они могут также принять соответствующее решение и настаивать, чтобы все разработчики и поставщики, с которыми они взаимодействуют, аналогичным образом подвергли себя реинжинирингу. С точки зрения таких подразделений департамент информационных технологий рассматривается как ещё один «поставщик» продуктов и услуг. Вариацией на эту тему является указание высшего руководства департаменту информационных технологий: «Если ваши люди не улучшат радикально свою продуктивность во всех проектах, мы отдадим все на аутсорсинг в Индию!»
3) Это часть «стратегического преимущества» компании — такой подход может иметь место в организациях, подобных EDS, и он является вполне определённым в таких организациях, как Cambridge Technology Partners. Он имеет смысл для консалтинговых организаций, где производительность проектных команд является их бизнесом.
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