Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте - Йордон Эдвард Страница 8

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:

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

Потому что «герои» необходимы, нужны и желанны. Только они займут своё место в истории, поскольку могут собственной грудью защитить проект от провала.

Такие люди буквально горят желанием тушить пожары. Если тебе удаётся выиграть в одном случае из десяти, в то время как остальные проигрывают во всех десяти, почему бы тебе тоже не быть героем?