Однако, зачастую, конкретные детали решений могут оставаться неясными до последнего момента, и типичная реакция высшего руководства заключается в игнорировании всех проблем, пока они не станут неизбежной реальностью. Вот вам, пожалуйста, ещё один безнадёжный проект.
Самое неприятное в подобных проектах — это конечный срок: новая система во что бы то ни стало должна быть готова к некоторой произвольной дате, например, к 1-му Января, иначе придётся платить по миллиону долларов в день. Хотя иногда бывают исключения и работу можно продлить, но, как правило, срок окончателен и обжалованию не подлежит. И при этом, если новая система не будет сдана вовремя, организацию ожидают такие же ужасные последствия, как отмечалось выше: увольнения, банкротство или другие напасти.
Следует отметить, что в подобных проектах технология обычно не причём; безнадёжность таких проектов определяется крайне сжатыми сроками. Разумеется, иногда само руководство усложняет ситуацию, не выделяя необходимого количества людей или бюджетных средств.
1.3.9 Неожиданный и/или незапланированный кризис
Вообразите, что два самых лучших программиста только что пришли к вам в офис, чтобы сказать, (а) что они вступают в брак, (б) что они вступают в Корпус Мира и (в) сегодня последний день их работы. Или, например, ваш сетевой администратор звонит и сообщает, что ваш поставщик только что обанкротился, а чтобы использовать сетевой протокол другого поставщика, необходимо за следующие 30 дней все перепрограммировать. Или, ваш юридический отдел звонит и сообщает, что компании предъявлен судебный иск на невообразимое количество долларов, потому что она нарушила подпункт 13(б) Указа Q о каком-то скрытом налоге, о котором даже никто и не знал. Или, …
Конечно, можно возразить, что в компании с хорошим руководством такие вещи, как возможный уход двух лучших программистов, стараются предвидеть заранее и быть к ним готовыми. И вы не так глупы, чтобы полностью зависеть от единственного поставщика телекоммуникационного оборудования. И руководство должно быть достаточно предусмотрительным, чтобы детально изучить Указ Q. В представлении идеалиста такие кризисы — это результат плохого планирования и плохого руководства; «незапланированный кризис» — это нонсенс.
Может быть, так оно и есть, но на практике становится все труднее и труднее предвидеть и планировать все возможные казусы, которые случаются в мире бизнеса. Хорошо это или плохо, но мы живём в мире хаоса, и безнадёжные проекты — это естественное следствие такого хаоса. В самом деле, даже если мы хорошо представляем себе, что может произойти в будущем в этом хаотическом мире, мы в состоянии отреагировать на это только безнадёжными проектами. Например, каждый, кто живёт поблизости от разлома Сан Андреас в Калифорнии, знает, что там рано или поздно произойдёт крупное землетрясение, но это не остановило начало массы всяких прожектов буквально на следующий день после того, как западная половина штата оказалась немножко поближе к Тихому Океану.
В самом деле, даже если нам точно известно, когда произойдёт кризис, все равно начинаются безнадёжные проекты, поскольку руководство склонно отмахиваться от проблем до самого последнего момента. Как ещё можно объяснить панику, охватившую многие IS/IT-организации, когда на горизонте замаячила проблема 2000 года? Мы давно знали о наступлении 1 января 2000 года, и знали, что этот конечный срок никак нельзя отодвинуть подальше. Мы точно знали, в чем заключается существо проблемы и что для её решения не требуются никакие новомодные технологии вроде Java. Я работаю над этой книгой летом 1996 года и знаю наверняка, что сейчас формируется очередная команда для безнадёжного проекта, связанного с решением проблемы 2000 года, и ещё более безумные проекты будут начаты в 1997, 1998 и 1999 году.
В любом случае, непредвиденный кризис может повлечь за собой самые разнообразные безнадёжные проекты. В худшем случае конечный срок таких проектов — «вчера, если не раньше», поскольку кризис уже наступил, и ситуация будет продолжать ухудшаться до тех пор, пока внедрение новой системы не позволит решить проблемы. В других случаях, например, при неожиданном увольнении ключевых разработчиков, «нормальный» в обычных условиях проект превращается в безнадёжный из-за нехватки рабочей силы и потери ключевых интеллектуальных ресурсов.
По различным причинам, такая ситуация приводит к наихудшим разновидностям безнадёжных проектов, поскольку заранее предвосхитить её невозможно . Если к тому же ещё имеет место синдром «Морского Корпуса», о котором говорилось выше, такое положение вообще не должно никого удивлять. С самого первого дня проекта все знают, что он, также как и все предыдущие проекты, потребует экстраординарных усилий. Что касается начинающих компаний, так они даже испытывают особенное волнение и возбуждение, начиная безнадёжный проект; ведь его успех сделает всех сказочно богатыми.
1.4 Почему люди участвуют в безнадёжных проектах?
В предыдущем разделе шла речь о том, что организации начинают и/или допускают существование безнадёжных проектов по вполне определённым причинам. Мы можем с ними соглашаться или не соглашаться, можем сочувствовать тем, кого постиг неожиданный кризис, но, в конце концов, должны принять их безоговорочно.
Однако это вовсе не означает, что мы как индивидуумы обязаны лично участвовать в безнадёжных проектах. В своей книге я в основном исхожу из предположения, что вы будете участвовать в безнадёжном проекте, хотя в дальнейшем я советую в определённых обстоятельствах отказаться от участия. И в большинстве случаев это лучше всего сделать в самом начале проекта. Когда вам говорят, что вас решили включить в такой проект в качестве менеджера или технического специалиста, следовало бы ответить: «Благодарю покорно! Я лучше постою в стороне». Если же для вашей внутрикорпоративной культуры такой ответ неприемлем, вы почти всегда оставляете за собой право сказать: «Благодарю покорно! Я лучше уволюсь».
Очевидно, некоторые разработчики и, вероятно, ещё в большей степени менеджеры возразят, что такой вариант им практически не подходит. Далее мы вкратце поговорим на эту тему, а сейчас важно отметить, что это одна из нескольких возможных «негативных» причин участия в безнадёжном проекте; в этом нет ничего особенно хорошего, но, возможно, альтернативы ещё хуже.
С другой стороны, некоторые разработчики (и менеджеры) с радостью соглашаются участвовать в таких проектах; спрашивается, почему же (не считая наивных оптимистов) нормальный здравомыслящий человек добровольно соглашается участвовать в проекте, где ему, скорее всего, придётся работать 14 часов в день, 7 дней в неделю и год или два без отпуска?
Наиболее распространённые причины приведены в табл. 1.2, ниже они будут подробно обсуждаться.
Таблица 1.2 Причины участия в безнадёжных проектах
Этот список далеко не полон. Kevin Huigens на одном из недавних совещаний предложил своей проектной команде устроить небольшой мозговой штурм, в ходе которого они попытались ответить на три моих вопроса:
1) Почему трезвомыслящие люди соглашаются участвовать в безнадёжном проекте?
2) Если ваш коллега собирается стать менеджером безнадёжного проекта, что бы вы посоветовали ему сделать?
3) Наоборот, что бы вы посоветовали ему не делать ни при каких обстоятельствах?
В результате были получены следующие ответы:
1. На первый вопрос:
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) ожидание, что проект продлится недолго.
2. На второй вопрос:
27) оставь меня в покое;
28) спасайся!
29) будь внимателен;
30) спроси: «Что я буду с этого иметь?»;
31) перед началом проекта как следует отдохни;
32) убедись, что можно полностью доверять всем своим сотрудникам;
33) помни, что разработчики тебе не враги, враги — менеджеры;
34) общение, общение и ещё раз общение;
35) не раздувай проектную команду;
36) нанимай молодых специалистов;
37) береги свою команду;
38) сделай так, чтобы к началу тестирования план тестирования был уже готов;
39) сделай так, чтобы каждый хорошо понимал, чем он занимается;
40) поддерживай документацию в актуальном состоянии;
41) каждый должен иметь доступ к документации;
42) проводи регулярно еженедельные совещания для обсуждения хода разработки;
43) проводи совещания ежедневно;
44) держи под рукой побольше хорошего кофе;
45) команда всегда должна быть в хорошем настроении;
46) обеспечь команду всем необходимым.
3. На третий вопрос:
47) не планируй бракосочетание;
48) не оставляй проблем, за которые непонятно кто отвечает;
49) не позволяй слишком беспечно относиться к внесению изменений в проект;
50) не думай, что первая версия будет и последней;
51) не раздражайся и не злись;
52) не теряй самообладания;
53) не позволяй другим терять самообладание;
54) не принимай слишком близко к сердцу успех или неудачу проекта;
55) не слишком полагайся только на одного человека из команды;
56) не относись слишком несерьёзно к распределению ресурсов;
57) не думай, что команда способна понять весь проект в целом;
58) если тебе что-то непонятно, не бойся спрашивать;
59) не начинай проект сам;
60) не начинай проект, если не хватает финансов для его завершения;
61) не соглашайся на нереальные сроки;
62) не бойся уйти из проекта, если видишь, что руководство ведёт себя неразумно;
63) не будь слишком строг к низкооплачиваемым сотрудникам;
64) не затягивай совещания больше, чем на 1,5 часа;
65) не забывай о личной жизни;
66) не бойся требовать от руководства то, что тебе необходимо;
67) не бойся начальства;
68) не забывай обновлять свой послужной список;
69) не молись на так называемых экспертов;
70) не забывай, что руководство ничего не смыслит в разработке ПО.
Естественно, все сказанное предполагает, что вы заранее знаете о безнадёжности проекта. Как отмечает эксперт Dave Kleist, это не так просто, когда вас интервьюируют по поводу новой работы:
… вряд ли можно где-нибудь увидеть объявление о найме для участия в безнадёжном проекте. Какой смысл спрашивать: «Хотите ли вы работать сверхурочно без какой-либо прибавки к зарплате?»… На самом деле, безнадёжные проекты редко объявляются таковыми во всеуслышание, и вам придётся достаточно долго проработать в нанявшей вас компании, прежде чем удастся обнаружить, что она обладает склонностью плодить безнадёжные проекты.
И, как отмечает Steve Benting (отвечая на те же три вопроса), иногда приходится сталкиваться с неприятными сюрпризами:
1) Первое время проект кажется довольно хорошо продуманным. У проекта есть лидер, есть реально заинтересованное лицо в руководстве, план выглядит достаточно солидным, а участники проекта — достаточно квалифицированными. В таком проекте действительно хочется работать. Но в один прекрасный момент все летит кувырком, потому что руководство увлеклось политическими играми, план основывался, как оказалось, на неверных предпосылках, и один или два ключевых разработчика вдруг закапризничали. Как ни старайся, невозможно полностью застраховаться от ошибок. Не хочется верить, что такое может повториться сначала. (Лично я участвовал в одном крупном проекте, но он закончился весьма неудачно. Срок завершения был перенесён с октября 1994 г. на март 1995 г. Я работал над планом действий в непредвиденных ситуациях до самого конца и ушёл вслед за большинством участников проекта в январе 1995 г. Новая система так до сих пор и не разработана. В настоящий момент компания пытается приобрести другую систему, которая не обладает и половиной требуемой первоначально функциональности.)
2) Я бы посоветовал как можно более внимательно относиться к участникам своей команды. Выставляйте их с работы в пятницу вечером и старайтесь дать им возможность нормально высыпаться. (Если месяцами работать по шесть дней в неделю и по двенадцать часов в день, то большинство разработчиков в конце концов либо уволится, либо наделает кучу ошибок.) Как бы ни шла работа, всегда заботьтесь о своих людях. Кроме того, постарайтесь сделать оплату их труда как можно более приличной. Кардинально это дела не изменит, но, по крайней мере, поможет сохранить команду в целости.
3) Не позволяйте кому-либо, помимо вас, серьёзно вмешиваться в дела ваших сотрудников и обращаться к ним с различными просьбами, отвлекающими их от работы. Это не значит, что вы сами не должны оказывать на них никакого давления, но ситуация должна быть под вашим контролем, если хотите, чтобы дела в команде шли нормально.
1.4.1 Риск высок, но вознаграждение тоже
Наилучший пример данной ситуации — это работа в начинающей компании, которая обсуждалась в подразд. 1.3.4. Если вы заверите участников проекта, что его успех принесёт компании всеобщую известность, а их самих сделает миллионерами, то они с радостью будут работать до изнеможения. Конечно, они могут отдавать себе отчёт в рискованности этой затеи, но, поскольку многие верят, что они всемогущи и бессмертны, они не обратят особого внимания на риск.
В самом деле, если принимать во внимание влияние западной культуры (особенно в США), то вовсе не удивительно наблюдать, как молодые программисты готовы добровольно участвовать в безнадёжных проектах. Мы не устаём повторять, что успех кинозвёзд, рок-певцов, выдающихся спортсменов и олимпийских чемпионов, а также лидеров в софтверном бизнесе, объясняется их колоссальной энергией, огромной работоспособностью и готовностью принести свою личную жизнь в жертву успеху. Мы никогда не слышали о том, чтобы успех могли принести хитрость и двуличность, сомнительные сделки и противозаконная деятельность. И нам не часто приходится слышать, что удачу приносит умение оказаться в нужном месте в нужное время. Например, Билл Гейтс, определённо, представляет собой книжный образ удачливого бизнесмена; однако, если бы группа руководителей IBM не появилась бы в Сиэттле, чтобы взглянуть на операционную систему для ПК, и если бы Гейтс не оказался под рукой в то время, как IBM не смогла дождаться результата от своего первоначального подрядчика, кто знает, где была бы Microsoft сегодня?
И ещё один момент: мы не слишком много знаем о реальных последствиях тех «жертв», которые обычно требует безнадёжный проект — жертв, связанных с физическим и психическим здоровьем, человеческими взаимоотношениями. Все это кажется неважным для 22-летнего специалиста и для необщительных интровертов, которые полностью поглощены работой на компьютерах. С другой стороны, несколько удивляет, что среди 40— и 50-летних тоже оказываются добровольные участники безнадёжных проектов; ведь они не только знают, что большинство таких проектов обречено на провал, но и убедились (на своём же горьком опыте!), что бессмысленно жертвовать своей семейной жизнью и хорошими отношениями с детьми.
В конце концов, это личный выбор каждого, и он зависит от системы ценностей. Я не в состоянии больше говорить на тему о том, что хорошо и что плохо. Я только хотел бы подчеркнуть, что я совсем не так уж негативно отношусь к участию в безнадёжных проектах, как можно подумать из сказанного выше. Хотя я думаю, что я не так наивен, как 30 лет назад, меня все ещё привлекают возможности предпринимательства. Поманите меня достаточно привлекательным соотношением риска и вознаграждения, и я брошусь в ещё один безнадёжный проект.
Между прочим, иногда вознаграждение является чисто психологическим, а не денежным. Как отмечает Sharon March Roberts:
Вполне понятно, когда неопытные разработчики ПО попадают под влияние демагогии руководителей, утверждающих, что их сверхчеловеческие усилия помогут революционизировать развитие человечества, победить коммунизм, вылечить рак и т.д. Однако, когда вы слышите эти басни во второй или в третий раз, это звучит, как заигранная пластинка.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Самое неприятное в подобных проектах — это конечный срок: новая система во что бы то ни стало должна быть готова к некоторой произвольной дате, например, к 1-му Января, иначе придётся платить по миллиону долларов в день. Хотя иногда бывают исключения и работу можно продлить, но, как правило, срок окончателен и обжалованию не подлежит. И при этом, если новая система не будет сдана вовремя, организацию ожидают такие же ужасные последствия, как отмечалось выше: увольнения, банкротство или другие напасти.
Следует отметить, что в подобных проектах технология обычно не причём; безнадёжность таких проектов определяется крайне сжатыми сроками. Разумеется, иногда само руководство усложняет ситуацию, не выделяя необходимого количества людей или бюджетных средств.
1.3.9 Неожиданный и/или незапланированный кризис
Вообразите, что два самых лучших программиста только что пришли к вам в офис, чтобы сказать, (а) что они вступают в брак, (б) что они вступают в Корпус Мира и (в) сегодня последний день их работы. Или, например, ваш сетевой администратор звонит и сообщает, что ваш поставщик только что обанкротился, а чтобы использовать сетевой протокол другого поставщика, необходимо за следующие 30 дней все перепрограммировать. Или, ваш юридический отдел звонит и сообщает, что компании предъявлен судебный иск на невообразимое количество долларов, потому что она нарушила подпункт 13(б) Указа Q о каком-то скрытом налоге, о котором даже никто и не знал. Или, …
Конечно, можно возразить, что в компании с хорошим руководством такие вещи, как возможный уход двух лучших программистов, стараются предвидеть заранее и быть к ним готовыми. И вы не так глупы, чтобы полностью зависеть от единственного поставщика телекоммуникационного оборудования. И руководство должно быть достаточно предусмотрительным, чтобы детально изучить Указ Q. В представлении идеалиста такие кризисы — это результат плохого планирования и плохого руководства; «незапланированный кризис» — это нонсенс.
Может быть, так оно и есть, но на практике становится все труднее и труднее предвидеть и планировать все возможные казусы, которые случаются в мире бизнеса. Хорошо это или плохо, но мы живём в мире хаоса, и безнадёжные проекты — это естественное следствие такого хаоса. В самом деле, даже если мы хорошо представляем себе, что может произойти в будущем в этом хаотическом мире, мы в состоянии отреагировать на это только безнадёжными проектами. Например, каждый, кто живёт поблизости от разлома Сан Андреас в Калифорнии, знает, что там рано или поздно произойдёт крупное землетрясение, но это не остановило начало массы всяких прожектов буквально на следующий день после того, как западная половина штата оказалась немножко поближе к Тихому Океану.
В самом деле, даже если нам точно известно, когда произойдёт кризис, все равно начинаются безнадёжные проекты, поскольку руководство склонно отмахиваться от проблем до самого последнего момента. Как ещё можно объяснить панику, охватившую многие IS/IT-организации, когда на горизонте замаячила проблема 2000 года? Мы давно знали о наступлении 1 января 2000 года, и знали, что этот конечный срок никак нельзя отодвинуть подальше. Мы точно знали, в чем заключается существо проблемы и что для её решения не требуются никакие новомодные технологии вроде Java. Я работаю над этой книгой летом 1996 года и знаю наверняка, что сейчас формируется очередная команда для безнадёжного проекта, связанного с решением проблемы 2000 года, и ещё более безумные проекты будут начаты в 1997, 1998 и 1999 году.
В любом случае, непредвиденный кризис может повлечь за собой самые разнообразные безнадёжные проекты. В худшем случае конечный срок таких проектов — «вчера, если не раньше», поскольку кризис уже наступил, и ситуация будет продолжать ухудшаться до тех пор, пока внедрение новой системы не позволит решить проблемы. В других случаях, например, при неожиданном увольнении ключевых разработчиков, «нормальный» в обычных условиях проект превращается в безнадёжный из-за нехватки рабочей силы и потери ключевых интеллектуальных ресурсов.
По различным причинам, такая ситуация приводит к наихудшим разновидностям безнадёжных проектов, поскольку заранее предвосхитить её невозможно . Если к тому же ещё имеет место синдром «Морского Корпуса», о котором говорилось выше, такое положение вообще не должно никого удивлять. С самого первого дня проекта все знают, что он, также как и все предыдущие проекты, потребует экстраординарных усилий. Что касается начинающих компаний, так они даже испытывают особенное волнение и возбуждение, начиная безнадёжный проект; ведь его успех сделает всех сказочно богатыми.
1.4 Почему люди участвуют в безнадёжных проектах?
В предыдущем разделе шла речь о том, что организации начинают и/или допускают существование безнадёжных проектов по вполне определённым причинам. Мы можем с ними соглашаться или не соглашаться, можем сочувствовать тем, кого постиг неожиданный кризис, но, в конце концов, должны принять их безоговорочно.
Однако это вовсе не означает, что мы как индивидуумы обязаны лично участвовать в безнадёжных проектах. В своей книге я в основном исхожу из предположения, что вы будете участвовать в безнадёжном проекте, хотя в дальнейшем я советую в определённых обстоятельствах отказаться от участия. И в большинстве случаев это лучше всего сделать в самом начале проекта. Когда вам говорят, что вас решили включить в такой проект в качестве менеджера или технического специалиста, следовало бы ответить: «Благодарю покорно! Я лучше постою в стороне». Если же для вашей внутрикорпоративной культуры такой ответ неприемлем, вы почти всегда оставляете за собой право сказать: «Благодарю покорно! Я лучше уволюсь».
Очевидно, некоторые разработчики и, вероятно, ещё в большей степени менеджеры возразят, что такой вариант им практически не подходит. Далее мы вкратце поговорим на эту тему, а сейчас важно отметить, что это одна из нескольких возможных «негативных» причин участия в безнадёжном проекте; в этом нет ничего особенно хорошего, но, возможно, альтернативы ещё хуже.
С другой стороны, некоторые разработчики (и менеджеры) с радостью соглашаются участвовать в таких проектах; спрашивается, почему же (не считая наивных оптимистов) нормальный здравомыслящий человек добровольно соглашается участвовать в проекте, где ему, скорее всего, придётся работать 14 часов в день, 7 дней в неделю и год или два без отпуска?
Наиболее распространённые причины приведены в табл. 1.2, ниже они будут подробно обсуждаться.
Таблица 1.2 Причины участия в безнадёжных проектах
Этот список далеко не полон. Kevin Huigens на одном из недавних совещаний предложил своей проектной команде устроить небольшой мозговой штурм, в ходе которого они попытались ответить на три моих вопроса:
1) Почему трезвомыслящие люди соглашаются участвовать в безнадёжном проекте?
2) Если ваш коллега собирается стать менеджером безнадёжного проекта, что бы вы посоветовали ему сделать?
3) Наоборот, что бы вы посоветовали ему не делать ни при каких обстоятельствах?
В результате были получены следующие ответы:
1. На первый вопрос:
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) ожидание, что проект продлится недолго.
2. На второй вопрос:
27) оставь меня в покое;
28) спасайся!
29) будь внимателен;
30) спроси: «Что я буду с этого иметь?»;
31) перед началом проекта как следует отдохни;
32) убедись, что можно полностью доверять всем своим сотрудникам;
33) помни, что разработчики тебе не враги, враги — менеджеры;
34) общение, общение и ещё раз общение;
35) не раздувай проектную команду;
36) нанимай молодых специалистов;
37) береги свою команду;
38) сделай так, чтобы к началу тестирования план тестирования был уже готов;
39) сделай так, чтобы каждый хорошо понимал, чем он занимается;
40) поддерживай документацию в актуальном состоянии;
41) каждый должен иметь доступ к документации;
42) проводи регулярно еженедельные совещания для обсуждения хода разработки;
43) проводи совещания ежедневно;
44) держи под рукой побольше хорошего кофе;
45) команда всегда должна быть в хорошем настроении;
46) обеспечь команду всем необходимым.
3. На третий вопрос:
47) не планируй бракосочетание;
48) не оставляй проблем, за которые непонятно кто отвечает;
49) не позволяй слишком беспечно относиться к внесению изменений в проект;
50) не думай, что первая версия будет и последней;
51) не раздражайся и не злись;
52) не теряй самообладания;
53) не позволяй другим терять самообладание;
54) не принимай слишком близко к сердцу успех или неудачу проекта;
55) не слишком полагайся только на одного человека из команды;
56) не относись слишком несерьёзно к распределению ресурсов;
57) не думай, что команда способна понять весь проект в целом;
58) если тебе что-то непонятно, не бойся спрашивать;
59) не начинай проект сам;
60) не начинай проект, если не хватает финансов для его завершения;
61) не соглашайся на нереальные сроки;
62) не бойся уйти из проекта, если видишь, что руководство ведёт себя неразумно;
63) не будь слишком строг к низкооплачиваемым сотрудникам;
64) не затягивай совещания больше, чем на 1,5 часа;
65) не забывай о личной жизни;
66) не бойся требовать от руководства то, что тебе необходимо;
67) не бойся начальства;
68) не забывай обновлять свой послужной список;
69) не молись на так называемых экспертов;
70) не забывай, что руководство ничего не смыслит в разработке ПО.
Естественно, все сказанное предполагает, что вы заранее знаете о безнадёжности проекта. Как отмечает эксперт Dave Kleist, это не так просто, когда вас интервьюируют по поводу новой работы:
… вряд ли можно где-нибудь увидеть объявление о найме для участия в безнадёжном проекте. Какой смысл спрашивать: «Хотите ли вы работать сверхурочно без какой-либо прибавки к зарплате?»… На самом деле, безнадёжные проекты редко объявляются таковыми во всеуслышание, и вам придётся достаточно долго проработать в нанявшей вас компании, прежде чем удастся обнаружить, что она обладает склонностью плодить безнадёжные проекты.
И, как отмечает Steve Benting (отвечая на те же три вопроса), иногда приходится сталкиваться с неприятными сюрпризами:
1) Первое время проект кажется довольно хорошо продуманным. У проекта есть лидер, есть реально заинтересованное лицо в руководстве, план выглядит достаточно солидным, а участники проекта — достаточно квалифицированными. В таком проекте действительно хочется работать. Но в один прекрасный момент все летит кувырком, потому что руководство увлеклось политическими играми, план основывался, как оказалось, на неверных предпосылках, и один или два ключевых разработчика вдруг закапризничали. Как ни старайся, невозможно полностью застраховаться от ошибок. Не хочется верить, что такое может повториться сначала. (Лично я участвовал в одном крупном проекте, но он закончился весьма неудачно. Срок завершения был перенесён с октября 1994 г. на март 1995 г. Я работал над планом действий в непредвиденных ситуациях до самого конца и ушёл вслед за большинством участников проекта в январе 1995 г. Новая система так до сих пор и не разработана. В настоящий момент компания пытается приобрести другую систему, которая не обладает и половиной требуемой первоначально функциональности.)
2) Я бы посоветовал как можно более внимательно относиться к участникам своей команды. Выставляйте их с работы в пятницу вечером и старайтесь дать им возможность нормально высыпаться. (Если месяцами работать по шесть дней в неделю и по двенадцать часов в день, то большинство разработчиков в конце концов либо уволится, либо наделает кучу ошибок.) Как бы ни шла работа, всегда заботьтесь о своих людях. Кроме того, постарайтесь сделать оплату их труда как можно более приличной. Кардинально это дела не изменит, но, по крайней мере, поможет сохранить команду в целости.
3) Не позволяйте кому-либо, помимо вас, серьёзно вмешиваться в дела ваших сотрудников и обращаться к ним с различными просьбами, отвлекающими их от работы. Это не значит, что вы сами не должны оказывать на них никакого давления, но ситуация должна быть под вашим контролем, если хотите, чтобы дела в команде шли нормально.
1.4.1 Риск высок, но вознаграждение тоже
Наилучший пример данной ситуации — это работа в начинающей компании, которая обсуждалась в подразд. 1.3.4. Если вы заверите участников проекта, что его успех принесёт компании всеобщую известность, а их самих сделает миллионерами, то они с радостью будут работать до изнеможения. Конечно, они могут отдавать себе отчёт в рискованности этой затеи, но, поскольку многие верят, что они всемогущи и бессмертны, они не обратят особого внимания на риск.
В самом деле, если принимать во внимание влияние западной культуры (особенно в США), то вовсе не удивительно наблюдать, как молодые программисты готовы добровольно участвовать в безнадёжных проектах. Мы не устаём повторять, что успех кинозвёзд, рок-певцов, выдающихся спортсменов и олимпийских чемпионов, а также лидеров в софтверном бизнесе, объясняется их колоссальной энергией, огромной работоспособностью и готовностью принести свою личную жизнь в жертву успеху. Мы никогда не слышали о том, чтобы успех могли принести хитрость и двуличность, сомнительные сделки и противозаконная деятельность. И нам не часто приходится слышать, что удачу приносит умение оказаться в нужном месте в нужное время. Например, Билл Гейтс, определённо, представляет собой книжный образ удачливого бизнесмена; однако, если бы группа руководителей IBM не появилась бы в Сиэттле, чтобы взглянуть на операционную систему для ПК, и если бы Гейтс не оказался под рукой в то время, как IBM не смогла дождаться результата от своего первоначального подрядчика, кто знает, где была бы Microsoft сегодня?
И ещё один момент: мы не слишком много знаем о реальных последствиях тех «жертв», которые обычно требует безнадёжный проект — жертв, связанных с физическим и психическим здоровьем, человеческими взаимоотношениями. Все это кажется неважным для 22-летнего специалиста и для необщительных интровертов, которые полностью поглощены работой на компьютерах. С другой стороны, несколько удивляет, что среди 40— и 50-летних тоже оказываются добровольные участники безнадёжных проектов; ведь они не только знают, что большинство таких проектов обречено на провал, но и убедились (на своём же горьком опыте!), что бессмысленно жертвовать своей семейной жизнью и хорошими отношениями с детьми.
В конце концов, это личный выбор каждого, и он зависит от системы ценностей. Я не в состоянии больше говорить на тему о том, что хорошо и что плохо. Я только хотел бы подчеркнуть, что я совсем не так уж негативно отношусь к участию в безнадёжных проектах, как можно подумать из сказанного выше. Хотя я думаю, что я не так наивен, как 30 лет назад, меня все ещё привлекают возможности предпринимательства. Поманите меня достаточно привлекательным соотношением риска и вознаграждения, и я брошусь в ещё один безнадёжный проект.
Между прочим, иногда вознаграждение является чисто психологическим, а не денежным. Как отмечает Sharon March Roberts:
Вполне понятно, когда неопытные разработчики ПО попадают под влияние демагогии руководителей, утверждающих, что их сверхчеловеческие усилия помогут революционизировать развитие человечества, победить коммунизм, вылечить рак и т.д. Однако, когда вы слышите эти басни во второй или в третий раз, это звучит, как заигранная пластинка.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24