Они, скорее всего, будут сильно отличаться от тех процессов и средств, с которыми новобранцам приходилось иметь дело прежде. (Ирония заключается в том, что как только прежние новобранцы примут участие в своём первом безнадёжном проекте, менеджер велит им «игнорировать все, чему их научили в классе» и усвоить более прагматичный подход к разработке ПО.)
7.4 Концепция «военных игр»
Хотя такие формы обучения выглядят разумными и рациональными, во многих небольших организациях они игнорируются; обучение проводится непосредственно во время работы, разработчикам приходится вникать в тонкости процессов и средств по ходу дела. Ещё хуже дело обстоит для менеджеров — как заметил мой приятель Tim Lister, единственное обучение, которое получает большинство менеджеров проектов, заключается в двух словах: «Желаю удачи!»
Разумеется, руководства и аудиторное обучение методам, процессам и средствам управления проектами являются важными и полезными. Однако многие организации считают, что «реальную работу» ничем не заменишь — в самом деле, они вполне сознательно игнорируют аудиторное обучение, полагая, что если вы пройдёте через реальный безнадёжный проект, то приобретёте опыт, который никогда не получите, занимаясь в классе.
Вместо того, чтобы спорить о достоинствах и недостатках аудиторного и «боевого» обучения, я думаю, что организациям стоит рассмотреть компромиссный вариант: имитацию безнадёжного проекта. Аналогия с «имитатором полётов» является более близкой, чем это может показаться на первый взгляд: пилоты авиалиний используют эти имитаторы не только для отработки нормального взлёта и посадки, но и действий в различных аварийных ситуациях, что они не могут позволить себе на реальных самолётах. Имитатор полётов даёт отличную возможность врезаться в гору, никого при этом не убив. Почему бы менеджеру проекта вместе со всеми участниками команды не направить полет своего проекта в подобие такой горы, чтобы они могли приобрести опыт решения возникших проблем, никого при этом не убивая? И почему бы не потребовать от разработчиков и менеджеров, чтобы они раз в год посещали имитатор безнадёжного проекта, как это делают пилоты авиалиний?
Скептики могут возразить, что такой имитатор не в состоянии воспроизвести тот постоянный цейтнот и напряжение, которые имеют место в реальном проекте; пилоты авиалиний, использующие свои имитаторы для отработки действий в аварийных ситуациях, будут убеждённо возражать против такой точки зрения. Однако, если нам действительно необходимо смоделировать стрессовую ситуацию в софтверном проекте, мы можем позаимствовать хорошо знакомую тактику из военной области: «военные игры». Как отмечают Tom DeMarco и Tim Lister в своей книге Peopleware [1]:
Военные игры помогают вам оценить свои относительные достоинства и недостатки, и помогают организации в целом оценить свои слабые и сильные места.
Наиболее эффективной для участников формой военной игры, позволяющей стимулировать творческий беспорядок, является командная игра.
Таким образом, военная игра по отношению к безнадёжным проектам может заключаться в следующем: несколько разных проектных команд получают один и тот же «проектный сценарий» — одинаковые требования, одинаково сжатый временной интервал, одинаковые ресурсы для работы. Или, если культура безнадёжных проектов в организации ещё не получила надлежащую формализацию и стандартизацию, предоставьте каждой команде возможность использовать любые средства и процессы, которые она захочет — все, что они смогут выпросить, одолжить или украсть в честной игре. Australian Computer Society проводит такие военные игры на своих ежегодных конференциях, начиная с 1994 года, и некоторые местные консалтинговые фирмы используют эти игры как часть своего собственного процесса обучения.
Чтобы организовать в безнадёжном проекте военную игру или любой другой «имитатор полётов», необходимо иметь имитационную модель, на которой можно было бы проиграть последствия технических и управленческих решений. Эта концепция обсуждается в моей книге Rise and Resurrection of the American Programmer, и в конце данной главы также приведён ряд ссылок; особенно следует отметить работу Tarek Abdel-Hamid, Stuart Madnick Software Project Dynamics [2], которая описывает полную и детальную имитационную модель для проекта среднего размера.
Имитационная модель может быть в принципе реализована на любом языке программирования, однако для этих целей существуют специализированные языки и средства. Возможно, наиболее известными из них являются SIMSCRIPT, DYNAMO и GPSS; модель, описанная Abdel-Hamid и Madnick, реализована на DYNAMO (в приложении к книге приведён полный текст программы). Несколько позже появился ряд средств «визуального» моделирования, большинство из которых достаточно дёшевы. Из коммерческих продуктов я отдаю предпочтение перечисленным ниже средствам:
11) iThink (Macintosh, Windows). High Performance Systems Inc., Hanover, NH. Тел. 603-643-9636, факс 603-643-9502.
12) VenSim (Windows). Ventana Systems Inc., Belmont, MA. Тел. 617-489-5234, факс 617-489-5316.
13) Professional DYNAMO (Windows). Pugh-Robert Associates, Cambridge, MA. Тел. 617-864-8880, факс 617-864-8884.
14) Extend (Macintosh, Windows). Imagine That, Inc., San Jose, CA. Тел. 408-365-0305, факс 408-629-1251.
Даже при наличии хороших средств и множества опубликованных материалов невозможно отрицать тот факт, что для создания модели, отражающей среду конкретной компании и предоставляющей руководству возможность проигрывать разнообразные сценарии безнадёжных проектов, необходимо серьёзное отношение к делу и немалые инвестиции. Исходя из своего личного опыта участия с начала 90-х годов в ряде подобных проектов по созданию имитаторов и сценариев военных игр, могу сказать, что на построение адекватной и хорошо настаиваемой модели требуется по крайней мере несколько человеко-месяцев; в качестве дополнительной иллюстрации интересно отметить, что модель, опубликованная в [2], была предметом диссертации Abdel-Hamid.
Это означает, что такая работа лежит за пределами возможностей одного-единственного менеджера проекта, если он хочет использовать такой подход в процессе обучения. Ясно, что эти инвестиции носят стратегический характер, и ими должна заниматься корпорация в целом, причём вряд ли они под силу небольшой компании из десяти человек. Однако для организации-разработчика, в штате которой работают сотни и даже тысячи человек, такие инвестиции будут весьма скромными. Напомним, о чем идёт речь: руководство пытается найти способы утвердить процессы и технологии, которые могли бы обеспечить уверенность в выполнимости планов, бюджетов и функциональности, являющихся вдвое или втрое более претенциозными по сравнению с «нормальными» проектами. Планируя такие радикальные изменения, руководство зачастую готово затратить огромные суммы денег — в некоторых случаях буквально миллионы долларов — на оснащение разработчиков новыми рабочими станциями, средствами визуального программирования и объектно-ориентированными методологиями. Ворчать по поводу затрат шести человеко-месяцев на разработку имитатора просто смешно, а лишать свои проектные команды возможности получить опыт на модели безнадёжного проекта перед тем, как рисковать миллионами долларов, просто глупо.
Увы, высшее руководство обычно так не думает. Оно и так негативно относится к затратам времени, усилий и средств на любое обучение, а на затраты, связанные с имитацией безнадёжных проектов, посмотрит ещё более косо. Это одна из главных причин, по которым культура безнадёжных проектов в большинстве крупных организаций никогда не будет успешно внедрена.
7.5 Заключение
Как неоднократно отмечалось на протяжении всей книги, безнадёжные проекты становятся неизбежными для сегодняшнего мира бизнеса с его высокой конкуренцией и хаотичностью. Некоторые организации осознали этот факт и стараются в соответствии с этим разумно спланировать свою деятельность. Тем не менее, история развития индустрии ПО за последние 40 лет говорит о том, что большинство организаций извлекают не слишком много уроков из своего опыта, и склонны воспринимать каждый новый безнадёжный проект как нечто уникальное. Даже тем организациям, которые поняли, что безнадёжные проекты не являются более делом случая, придётся испытать серьёзные трудности, поскольку бюрократия будет продолжать цепляться за старые стандарты, процедуры, методологии и средства, независимо от их непригодности.
Одним приятным исключением из этого правила являются начинающие организации. Таким организациям, по определению, не нужно изменять культуру ввиду её отсутствия, и они, скорее всего, воспримут безнадёжные проекты как нормальное явление — в конце концов, частью мифологии начинающих компаний является убеждение, что каждый должен работать как заведённый, в то время как компания подвергает себя безумному риску, чтобы преуспеть в конкурентной борьбе с крупными корпорациями. И, если начинающая компания приходит к выводу, что её успех полностью обусловлен тактикой её поведения, то она, вероятно, постарается утвердить такую тактику на будущее.
Разумеется, мои утверждения носят достаточно общий характер, и существует множество причин, по которым такой подход может не дать никаких результатов. Интересным, например, является тот факт, что ветераны разработки ПО, покидая большие бюрократические корпорации и создавая новые софтверные фирмы, приносят с собой почти все свои привычки и традиции. С другой стороны, в настоящее время, так же, как и в начале моей карьеры, молодое поколение разработчиков ПО очертя голову бросается в новые проекты, считая 18-часовой рабочий день «отдыхом». Тем не менее, среди всех происшедших драматических изменений я бы особенно выделил характер и темп работы, который народ в Netscape, Microsoft и множестве других организаций называет просто «время Internet». Для предыдущих поколений разработчиков ПО такого понятия просто не существовало, оно является одной из серьёзных причин, порождающих безнадёжные проекты.
Независимо от того, принимает ли промышленность безнадёжные проекты как норму и независимо от того, насколько успешно справляется с ними ваша компания, факт остаётся фактом — безнадёжные проекты выполняются отдельными личностями. Я не возлагаю слишком большие надежды на высшее руководство и бюрократические структуры большинства софтверных организаций, но я всерьёз беспокоюсь о тех людях, которые работают долгими ночами и по выходным над проектами, которые нередко обречены с самого начала. Безусловно, важно довести безнадёжный проект до успешного завершения, и я надеюсь, что данная книга даёт для этого некоторые практические советы; однако ещё более важно в таком проекте сохранить себя! В лучшем из миров наши безнадёжные проекты могут дать замечательные результаты для конечных пользователей, планы и бюджет — привести в восторг высшее руководство, и нам следует добиться того же по отношению к нашему здоровью, нашему разуму, нашим семьям, не теряя при этом чувства юмора.
Литература к главе:
1) Tom DeMarco, Tim Lister. Peopleware. Dorset Publishing, 1987.
2) Tarek Abdel-Hamid, Stuart Madnick. Software Project Dynamics. Englewood Cliffs, NJ: Prentice-Hall, 1993.
ГЛОССАРИЙ, СОКРАЩЕНИЯ
аутсорсинг — передача сторонней организации на договорной основе функций, связанных с информационными технологиями (разработка и сопровождение ПО, эксплуатация и техническое обслуживание систем и др.)
даунсайзинг — разукрупнение компании в целом или отдельных её систем с целью повышения эффективности управления и функционирования
реинжиниринг (бизнес-процессов) — фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов компаний для достижения коренных улучшений в основных показателях их деятельности — стоимость, качество, услуги и темпы (М. Хаммер, Дж. Чампи)
ПО — программное обеспечение
SEI — Software Engineering Institute
CASE — Computer Aided Software Engineering
CMM — Capability Maturity Model — модель зрелости процессов создания ПО (эволюционная модель развития способности компании разрабатывать ПО)
RAD — Rapid Application Development
SA/SD — Structured Analysis/ Structured Design
OOA/OOD — Object Oriented Analysis/Object Oriented Design
Сведения об авторе
Эдвард Йордан, один из ведущих независимых консультантов, является автором нескольких бестселлеров по практике программирования, включая «Подъем и возрождение Американского Программиста» и «Закат и падение Американского Программиста» (Prentice Hall PTR). Он широко известен как разработчик метода структурного системного анализа под названием Метода Йордана, а также как соавтор методологии объектно-ориентированного анализа Коада/Йордона и издатель журнала «American Programmer».
Последняя страница
Книга Эдварда Йордана «Смертельный марш» представляет собой полное руководство для разработчика программного обеспечения по выживанию в безнадёжных проектах
В процессе своей деятельности практически каждому разработчику ПО и менеджеру придётся столкнуться с проектами, характеризующимися никуда не годными персоналом, планом и бюджетом: проектами, обречёнными на неудачу. В условиях реинжиниринга деятельности корпораций такие безнадёжные проекты становятся «стилем жизни» многих организаций. Книга Эдварда Йордана является руководством по решению следующих проблем:
1) выживания в проектах, обречённых на неудачу;
2) достижения оптимальных соглашений в переговорах;
3) управления персоналом и расстановки приоритетов;
4) выбора средств и технологий;
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
7.4 Концепция «военных игр»
Хотя такие формы обучения выглядят разумными и рациональными, во многих небольших организациях они игнорируются; обучение проводится непосредственно во время работы, разработчикам приходится вникать в тонкости процессов и средств по ходу дела. Ещё хуже дело обстоит для менеджеров — как заметил мой приятель Tim Lister, единственное обучение, которое получает большинство менеджеров проектов, заключается в двух словах: «Желаю удачи!»
Разумеется, руководства и аудиторное обучение методам, процессам и средствам управления проектами являются важными и полезными. Однако многие организации считают, что «реальную работу» ничем не заменишь — в самом деле, они вполне сознательно игнорируют аудиторное обучение, полагая, что если вы пройдёте через реальный безнадёжный проект, то приобретёте опыт, который никогда не получите, занимаясь в классе.
Вместо того, чтобы спорить о достоинствах и недостатках аудиторного и «боевого» обучения, я думаю, что организациям стоит рассмотреть компромиссный вариант: имитацию безнадёжного проекта. Аналогия с «имитатором полётов» является более близкой, чем это может показаться на первый взгляд: пилоты авиалиний используют эти имитаторы не только для отработки нормального взлёта и посадки, но и действий в различных аварийных ситуациях, что они не могут позволить себе на реальных самолётах. Имитатор полётов даёт отличную возможность врезаться в гору, никого при этом не убив. Почему бы менеджеру проекта вместе со всеми участниками команды не направить полет своего проекта в подобие такой горы, чтобы они могли приобрести опыт решения возникших проблем, никого при этом не убивая? И почему бы не потребовать от разработчиков и менеджеров, чтобы они раз в год посещали имитатор безнадёжного проекта, как это делают пилоты авиалиний?
Скептики могут возразить, что такой имитатор не в состоянии воспроизвести тот постоянный цейтнот и напряжение, которые имеют место в реальном проекте; пилоты авиалиний, использующие свои имитаторы для отработки действий в аварийных ситуациях, будут убеждённо возражать против такой точки зрения. Однако, если нам действительно необходимо смоделировать стрессовую ситуацию в софтверном проекте, мы можем позаимствовать хорошо знакомую тактику из военной области: «военные игры». Как отмечают Tom DeMarco и Tim Lister в своей книге Peopleware [1]:
Военные игры помогают вам оценить свои относительные достоинства и недостатки, и помогают организации в целом оценить свои слабые и сильные места.
Наиболее эффективной для участников формой военной игры, позволяющей стимулировать творческий беспорядок, является командная игра.
Таким образом, военная игра по отношению к безнадёжным проектам может заключаться в следующем: несколько разных проектных команд получают один и тот же «проектный сценарий» — одинаковые требования, одинаково сжатый временной интервал, одинаковые ресурсы для работы. Или, если культура безнадёжных проектов в организации ещё не получила надлежащую формализацию и стандартизацию, предоставьте каждой команде возможность использовать любые средства и процессы, которые она захочет — все, что они смогут выпросить, одолжить или украсть в честной игре. Australian Computer Society проводит такие военные игры на своих ежегодных конференциях, начиная с 1994 года, и некоторые местные консалтинговые фирмы используют эти игры как часть своего собственного процесса обучения.
Чтобы организовать в безнадёжном проекте военную игру или любой другой «имитатор полётов», необходимо иметь имитационную модель, на которой можно было бы проиграть последствия технических и управленческих решений. Эта концепция обсуждается в моей книге Rise and Resurrection of the American Programmer, и в конце данной главы также приведён ряд ссылок; особенно следует отметить работу Tarek Abdel-Hamid, Stuart Madnick Software Project Dynamics [2], которая описывает полную и детальную имитационную модель для проекта среднего размера.
Имитационная модель может быть в принципе реализована на любом языке программирования, однако для этих целей существуют специализированные языки и средства. Возможно, наиболее известными из них являются SIMSCRIPT, DYNAMO и GPSS; модель, описанная Abdel-Hamid и Madnick, реализована на DYNAMO (в приложении к книге приведён полный текст программы). Несколько позже появился ряд средств «визуального» моделирования, большинство из которых достаточно дёшевы. Из коммерческих продуктов я отдаю предпочтение перечисленным ниже средствам:
11) iThink (Macintosh, Windows). High Performance Systems Inc., Hanover, NH. Тел. 603-643-9636, факс 603-643-9502.
12) VenSim (Windows). Ventana Systems Inc., Belmont, MA. Тел. 617-489-5234, факс 617-489-5316.
13) Professional DYNAMO (Windows). Pugh-Robert Associates, Cambridge, MA. Тел. 617-864-8880, факс 617-864-8884.
14) Extend (Macintosh, Windows). Imagine That, Inc., San Jose, CA. Тел. 408-365-0305, факс 408-629-1251.
Даже при наличии хороших средств и множества опубликованных материалов невозможно отрицать тот факт, что для создания модели, отражающей среду конкретной компании и предоставляющей руководству возможность проигрывать разнообразные сценарии безнадёжных проектов, необходимо серьёзное отношение к делу и немалые инвестиции. Исходя из своего личного опыта участия с начала 90-х годов в ряде подобных проектов по созданию имитаторов и сценариев военных игр, могу сказать, что на построение адекватной и хорошо настаиваемой модели требуется по крайней мере несколько человеко-месяцев; в качестве дополнительной иллюстрации интересно отметить, что модель, опубликованная в [2], была предметом диссертации Abdel-Hamid.
Это означает, что такая работа лежит за пределами возможностей одного-единственного менеджера проекта, если он хочет использовать такой подход в процессе обучения. Ясно, что эти инвестиции носят стратегический характер, и ими должна заниматься корпорация в целом, причём вряд ли они под силу небольшой компании из десяти человек. Однако для организации-разработчика, в штате которой работают сотни и даже тысячи человек, такие инвестиции будут весьма скромными. Напомним, о чем идёт речь: руководство пытается найти способы утвердить процессы и технологии, которые могли бы обеспечить уверенность в выполнимости планов, бюджетов и функциональности, являющихся вдвое или втрое более претенциозными по сравнению с «нормальными» проектами. Планируя такие радикальные изменения, руководство зачастую готово затратить огромные суммы денег — в некоторых случаях буквально миллионы долларов — на оснащение разработчиков новыми рабочими станциями, средствами визуального программирования и объектно-ориентированными методологиями. Ворчать по поводу затрат шести человеко-месяцев на разработку имитатора просто смешно, а лишать свои проектные команды возможности получить опыт на модели безнадёжного проекта перед тем, как рисковать миллионами долларов, просто глупо.
Увы, высшее руководство обычно так не думает. Оно и так негативно относится к затратам времени, усилий и средств на любое обучение, а на затраты, связанные с имитацией безнадёжных проектов, посмотрит ещё более косо. Это одна из главных причин, по которым культура безнадёжных проектов в большинстве крупных организаций никогда не будет успешно внедрена.
7.5 Заключение
Как неоднократно отмечалось на протяжении всей книги, безнадёжные проекты становятся неизбежными для сегодняшнего мира бизнеса с его высокой конкуренцией и хаотичностью. Некоторые организации осознали этот факт и стараются в соответствии с этим разумно спланировать свою деятельность. Тем не менее, история развития индустрии ПО за последние 40 лет говорит о том, что большинство организаций извлекают не слишком много уроков из своего опыта, и склонны воспринимать каждый новый безнадёжный проект как нечто уникальное. Даже тем организациям, которые поняли, что безнадёжные проекты не являются более делом случая, придётся испытать серьёзные трудности, поскольку бюрократия будет продолжать цепляться за старые стандарты, процедуры, методологии и средства, независимо от их непригодности.
Одним приятным исключением из этого правила являются начинающие организации. Таким организациям, по определению, не нужно изменять культуру ввиду её отсутствия, и они, скорее всего, воспримут безнадёжные проекты как нормальное явление — в конце концов, частью мифологии начинающих компаний является убеждение, что каждый должен работать как заведённый, в то время как компания подвергает себя безумному риску, чтобы преуспеть в конкурентной борьбе с крупными корпорациями. И, если начинающая компания приходит к выводу, что её успех полностью обусловлен тактикой её поведения, то она, вероятно, постарается утвердить такую тактику на будущее.
Разумеется, мои утверждения носят достаточно общий характер, и существует множество причин, по которым такой подход может не дать никаких результатов. Интересным, например, является тот факт, что ветераны разработки ПО, покидая большие бюрократические корпорации и создавая новые софтверные фирмы, приносят с собой почти все свои привычки и традиции. С другой стороны, в настоящее время, так же, как и в начале моей карьеры, молодое поколение разработчиков ПО очертя голову бросается в новые проекты, считая 18-часовой рабочий день «отдыхом». Тем не менее, среди всех происшедших драматических изменений я бы особенно выделил характер и темп работы, который народ в Netscape, Microsoft и множестве других организаций называет просто «время Internet». Для предыдущих поколений разработчиков ПО такого понятия просто не существовало, оно является одной из серьёзных причин, порождающих безнадёжные проекты.
Независимо от того, принимает ли промышленность безнадёжные проекты как норму и независимо от того, насколько успешно справляется с ними ваша компания, факт остаётся фактом — безнадёжные проекты выполняются отдельными личностями. Я не возлагаю слишком большие надежды на высшее руководство и бюрократические структуры большинства софтверных организаций, но я всерьёз беспокоюсь о тех людях, которые работают долгими ночами и по выходным над проектами, которые нередко обречены с самого начала. Безусловно, важно довести безнадёжный проект до успешного завершения, и я надеюсь, что данная книга даёт для этого некоторые практические советы; однако ещё более важно в таком проекте сохранить себя! В лучшем из миров наши безнадёжные проекты могут дать замечательные результаты для конечных пользователей, планы и бюджет — привести в восторг высшее руководство, и нам следует добиться того же по отношению к нашему здоровью, нашему разуму, нашим семьям, не теряя при этом чувства юмора.
Литература к главе:
1) Tom DeMarco, Tim Lister. Peopleware. Dorset Publishing, 1987.
2) Tarek Abdel-Hamid, Stuart Madnick. Software Project Dynamics. Englewood Cliffs, NJ: Prentice-Hall, 1993.
ГЛОССАРИЙ, СОКРАЩЕНИЯ
аутсорсинг — передача сторонней организации на договорной основе функций, связанных с информационными технологиями (разработка и сопровождение ПО, эксплуатация и техническое обслуживание систем и др.)
даунсайзинг — разукрупнение компании в целом или отдельных её систем с целью повышения эффективности управления и функционирования
реинжиниринг (бизнес-процессов) — фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов компаний для достижения коренных улучшений в основных показателях их деятельности — стоимость, качество, услуги и темпы (М. Хаммер, Дж. Чампи)
ПО — программное обеспечение
SEI — Software Engineering Institute
CASE — Computer Aided Software Engineering
CMM — Capability Maturity Model — модель зрелости процессов создания ПО (эволюционная модель развития способности компании разрабатывать ПО)
RAD — Rapid Application Development
SA/SD — Structured Analysis/ Structured Design
OOA/OOD — Object Oriented Analysis/Object Oriented Design
Сведения об авторе
Эдвард Йордан, один из ведущих независимых консультантов, является автором нескольких бестселлеров по практике программирования, включая «Подъем и возрождение Американского Программиста» и «Закат и падение Американского Программиста» (Prentice Hall PTR). Он широко известен как разработчик метода структурного системного анализа под названием Метода Йордана, а также как соавтор методологии объектно-ориентированного анализа Коада/Йордона и издатель журнала «American Programmer».
Последняя страница
Книга Эдварда Йордана «Смертельный марш» представляет собой полное руководство для разработчика программного обеспечения по выживанию в безнадёжных проектах
В процессе своей деятельности практически каждому разработчику ПО и менеджеру придётся столкнуться с проектами, характеризующимися никуда не годными персоналом, планом и бюджетом: проектами, обречёнными на неудачу. В условиях реинжиниринга деятельности корпораций такие безнадёжные проекты становятся «стилем жизни» многих организаций. Книга Эдварда Йордана является руководством по решению следующих проблем:
1) выживания в проектах, обречённых на неудачу;
2) достижения оптимальных соглашений в переговорах;
3) управления персоналом и расстановки приоритетов;
4) выбора средств и технологий;
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