Глава 7 особенности современных проектов

Прочитав эту главу, вы узнаете:

1. В каких условиях выполняется большинство современных проек­тов создания ПО.

2. Какую роль играет человеческий фактор в «безнадежных» проек­тах.

3. Какие процессы, средства и технологии являются предпочти­тельными в «безнадежных» проектах.

В последнее время множество проектов создания ПО выпол­няется в экстремальных условиях. Независимо от причин такие «смертельные марши» (по определению Эдварда Йордона, одно­го из ведущих мировых консультантов), или «безнадежные» про­екты, предъявляют особые требования к используемым методам управления, технологиям и средствам. Эти требования наиболее полно (и не без юмора) изложены в книге Эдварда Йордона «Death March»³⁶, выпущенной издательством Prentice-Hall в 1997 г. и в 2003 г. (второе издание).

7.1.

Категории «безнадежных» проектов

Далеко не все «безнадежные» проекты одинаковы; помимо ог­раничений в планах, штатах, бюджете и функциональности, они могут иметь различные масштабы, формы и другие особенности.

Наиболее важной отличительной характеристикой «безна­дежного» проекта является его масштаб. В зависимости от масш­таба можно выделить четыре категории проектов:

1. небольшие проекты — проектная команда включает менее 10 человек, работает в исключительно неблагоприятных ус­ловиях и должна завершить проект в срок от 3 до 6 месяцев;

2. средние проекты - проектная команда включает от 20 до 30 человек, протяженность проекта составляет 1—2 года;

3. крупномасштабные проекты - проектная команда включа­ет от 100 до 300 человек, протяженность проекта составляет 3-5 лет;

4. гигантские проекты — в проекте участвует армия разработ­чиков от 1000 до 2000 человек и более (включающая, как правило, консультантов и соисполнителей), протяженность проекта составляет 7—10 лет.

Небольшие проекты являются наиболее распространенной категорией, и шансы на их успешное завершение наиболее высо­ки. Для средних проектов они заметно ниже, а для крупномасш­табных проектов почти равны нулю. В больших проектных ко­мандах трудно поддерживать дух сплоченности. Причем решаю­щее значение имеет не только число участников проекта, но и временная протяженность: 80-часовую рабочую неделю в тече­ние 6 месяцев еще можно вытерпеть, но если работать так в тече­ние двух лет, могут возникнуть проблемы.

До сих пор остались без ответа вопросы, почему вполне ра­зумные организации предпринимают подобные проекты и поче­му разумные менеджеры и технические специалисты соглашают­ся в них участвовать. Эти вопросы будут рассмотрены ниже.

7.2.

Причины, порождающие «безнадежные» проекты

Такие проекты порождаются самыми различными причинами:

1. высокая конкуренция, вызванная появлением новых ком­паний на рынке или новых технологий;

2. сильное воздействие неожиданных правительственных ре­шений;

3. неожиданный и (или) незапланированный кризис;

4. политические «игры» высшего руководства;

5. наивный оптимизм и менталитет первопроходцев у неопыт­ных разработчиков.

Многие «безнадежные» проекты связаны с применением в первый раз новых технологий. Достаточно вспомнить первые проекты, связанные с объектно-ориентированной технологией, технологией «клиент-сервер», реляционными базами данных или Internet. Некоторые из них носили экспериментальный характер и имели целью извлечение потенциальных выгод из новой техно­логии, однако другие, вероятно, были ответом конкурентам, внедрившим такую же технологию. В последнем случае такие проекты могут быть непомерно большими, а также отягощенны­ми чрезвычайно агрессивными планами и бюджетами.

В то же время самым серьезным фактором «безнадежности» проекта, помимо его масштаба, плана и бюджета, является по­пытка использовать неопробованную технологию в критически важных приложениях. Даже если технология в принципе приме­нима, она может не годиться для крупномасштабного примене­ния; никто не знает, как использовать ее преимущества и избе­жать ее недостатков; у поставщика нет опыта ее поддержки и т.п.

Наиболее распространенные причины, побуждающие разра­ботчиков участвовать в «безнадежных» проектах, можно охарак­теризовать следующим образом:

1. высокое вознаграждение;

2. синдром покорителей Эвереста;

3. наивность и оптимизм молодости;

4. угроза безработицы;

5. возможность будущей карьеры;

6. возможность победить бюрократию.

Наилучший пример данной ситуации — это работа в начина­ющей компании. Если заверить участников проекта, что его ус­пех принесет компании всеобщую известность, а им поможет стать миллионерами, то они с радостью будут работать до изне­можения. Конечно, они могут отдавать себе отчет в рискованнос­ти этой затеи, но, поскольку многие верят, что они всемогущи и бессмертны, они не обратят особого внимания на риск.

Разумеется, самоуверенность участников проекта выручает в ситуациях, когда обычные проектные команды терпят пораже­ние. Тот факт, что наиболее успешные продукты - от Lotus 1-2-3 до Netscape Navigator — были разработаны небольшими команда­ми в условиях, неприемлемых для нормальных людей, уже стал фольклором в индустрии ПО. Такие проекты, заканчиваясь ус­пешно, приносят проектной команде известность и славу; даже когда они проваливаются, то зачастую позволяют всем участни­кам извлечь для себя важные уроки (хотя для организации в це­лом последствия могут быть катастрофическими).

Важно отметить, что наивность и оптимизм молодости обыч­но сочетаются с огромной энергией, целеустремленностью и от­сутствием таких помех, как семейные отношения. Гораздо чаще можно встретить 22-летнего программиста, который готов и жаждет участвовать в «безнадежном» проекте со 100-часовой ра­бочей неделей в течение года или двух, чем 35-летнего женатого программиста с двумя детьми и весьма умеренной склонностью к покорению горных вершин. Молодой программист, желающий участвовать в «безнадежном» проекте, а также относительно мо­лодой менеджер проекта, дающий оптимистические обещания начальству, как бы утверждают: «Разумеется, мы обеспечим успех этого проекта и сокрушим все препятствия на своем пути!»

Индустрия ПО привлекает в основном молодых, и вряд ли си­туация изменится в ближайшие несколько лет, а молодежь утра­тит оптимизм, энергию и способности сосредоточиваться на ре­шении проблем. Что касается наивности, то эта болезнь проходит только с возрастом.

Технические специалисты и менеджеры проектов часто жалу­ются, что их корпоративные бюрократы мешают продуктивно ра­ботать и задерживают разработки ПО. Чем крупнее организация, тем сильнее бюрократия, особенно в тех организациях, где служ­ба стандартов требует строгого соблюдения требований SEI-СММ или ISO-9000. Аналогично департамент по управлению персоналом может использовать процедуры скрупулезной про­верки каждого вновь принимаемого на работу сотрудника или стороннего разработчика, привлекаемого к участию в проекте.

«Безнадежные» проекты нередко предоставляют возможность обойти некоторые, если не все, бюрократические рогатки, и это­го достаточно, чтобы раздраженные бюрократией разработчики ПО принимали участие в таких проектах. В крайнем случае про­ектная команда перебирается в отдельное здание, где ничто не мешает им выполнять свою работу. Даже в менее экстремальной ситуации «безнадежный» проект зачастую дает возможность ис­пользовать собственные средства и языки программирования, осваивать новые технологии наподобие объектно-ориентирован­ного программирования, а также сокращать большинство гро­моздких процедур и объем документации, которые в обычных условиях требуются в полном объеме. Не менее важно и то, что ме­неджер проекта получает большую свободу действий в подборе участников проектной команды, чем в обычных условиях.

Следует отметить, что некоторые аналитики смотрят на проб­лему оптимистично; они полагают, что количество «безнадеж­ных» проектов в последующие годы будет уменьшаться. Причи­ны такого уменьшения: а) рост корпоративной культуры IT-компаний; б) обучение разработчиков различным методам обеспече­ния качества в сочетании с «быстрой» разработкой ПО.

7.3.