Честность и принципиальность против подтасовок и лжи

В предыдущем разделе я мельком упоминал о честности – не хотелось бы продолжать эту тему, но придется. При любой попытке утверждения реалистичных сроков сдачи проекта честность вступает в противоборство с прожектерством. Большинство компаний бредят маркетингом; срок выхода на рынок – их основной приоритет. Для того чтобы сохранить положение на рынке, необходимо в процессе усовершенствования программных продуктов исходить именно из бизнес-требований. Такая ситуация накладывает на ваших сотрудников дополнительные обязательства, которые, естественно, передаются и вам. Напряжение, испытываемое вашей начальницей, еще серьезнее – ведь, скорее всего, она тоже кому-то подотчетна. Эта цепочка подчинения – очень серьезный фактор; и будьте уверены, утверждения о важности требований рынка совсем не преувеличены. Взять хотя бы мощнейшую маркетинговую машину Microsoft – эту компанию можно не любить, но с ее успехом не поспоришь[92]. Спросите директора любой компании или группу заинтересованных лиц: хотят ли они такого же успеха, как Microsoft? Вряд ли ответ будет отрицательным.

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

1. Утверждение коммерческих требований.

2. Создание проектного решения, допускающего успешную реализацию в продукте всех требований.

3. Макетирование проектного решения с целью выявления его недостатков и последующей корректировки проектного решения или требований.

4. Планирование проекта с учетом сроков разработки и тестирования.

Разработанный план позволяет с определенной уверенностью говорить о временных рамках выпуска; исключительно на их основе можно давать какие-либо обещания представителям отдела продаж. Естественно, как и во всех проектах, временные рамки выпуска должны быть обусловлены успешным бета-тестированием.

Как известно, мир, в котором мы живем, несовершенен; иначе вряд ли было бы столько разговоров о программистах, у которых под столами спальные мешки. У вас, таким образом, есть единственный выход – научиться выживать в реальных условиях[93]. При чем тут честность, спросите вы? При том, что вы должны осознавать нереалистичность поставленных перед вами задач в свете реальных условий, примеры которых перечислены ниже:

• несмотря на то что коммерческие требования сформулированы еще не полностью, в погоне за соблюдением неизвестно кем установленной даты выпуска вы вынуждены приступать к проектированию немедленно;

• из-за неразберихи с требованиями вам приходится постоянно корректировать проектное решение;

• у вас не остается времени на макетирование, или, что еще хуже, недоработанный макет превращается в код;

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

В любом случае вопреки объективной реальности вы должны всеми силами стремиться к тому, чтобы закончить работу в срок. Юность нашей индустрии и давление рыночных факторов заставляет нас совершать героические поступки. Таким образом, честностью я называю способность признаться самому себе в трудности задачи, но все-таки попытаться ее решить. Вы со мной согласны? Если согласны, присылайте резюме на мой адрес – такие, как вы, мне необходимы.

Еще пара слов насчет геройства[94]. В начале карьеры идея стать героем воодушевляет, однако реализуют ее немногие. На самом деле стремиться нужно к балансу между ожиданиями и реальными действиями, исходя при этом из соображений честности. Иначе говоря, если вы пару раз сорвете сроки, никто не удивится. Это исправимые вещи. Значительно труднее справиться с привычкой давать невыполнимые обещания. Если вы уж обещаете что-то, не забывайте в полной мере доносить до сведения начальства все те факторы, которые могут воспрепятствовать реализации плана. Любые обязательства должны быть подтверждены в проекте с некоторой долей уверенности, которая варьируется в зависимости от ситуации. Восстановить репутацию значительно сложнее, чем исправить ошибки в выпущенном продукте.

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

Обратной стороной геройства является фатализм. Фаталист – это человек, который неудачно пытался стать героем, а потом в ситуации, которую он создал сам, начинал винить судьбу. Если вам приходится иметь дело с нереальным проектом, необходимо отдавать себе отчет в том, что фактически вы и ваша команда попадаете в условия, приближенные к боевым. Регулярная работа по ночам изматывает разработчиков, в результате страдает код. Не стоит вводить в проект новых программистов – если это случится на поздней стадии разработки, вы рискуете в очередной раз подтвердить закон Брукса[95]. Именно по этой причине на начальных этапах планирования проекта так важна честность (если, конечно, у вас есть план).

Честность зависит от тщеславия и чувства собственного достоинства. Я уже в том возрасте, когда каждое утро для удовлетворения тщеславия мне нужны лак для волос, зеркало и время. Признаться, я лысею, и это – горькая правда. Я могу пытаться это скрывать, но ведь все равно окружающие узнают![96]Аналогичным образом лучше высказать голую правду о сроках, чем сочинять сказки.

Как помочь начальнице удачно спланировать процесс

Начальница знает, что и когда нужно делать; вы специализируетесь на том, как этого достичь. Так… кажется, я выразился не слишком ясно. Попробуем еще раз. Как правило, планирование в масштабах предприятия проводится начальством; вы же призваны заменить общие наметки детальным планом. Час от часу не легче, так? То-то же. Планирование подчиняется формуле: два шага вперед, один шаг назад. Процесс этот напоминает рекурсивную процедуру: нужно постоянно «копать» стратегический план, наполняя его деталями, которые, кстати, вам же и предстоит реализовывать. В этом отношении вы можете оказать начальнице ценную услугу – высказать свое экспертное мнение по поводу ее глобальных задумок. В планировании кропотливая работа оттесняет вдохновенные прозрения.

В некоторых компаниях отдел разработки рассматривается как производственный цех, который, принимая на входе спецификации, в конечном счете выпускает готовый продукт. Будь это правдой, я, наверное, предпочел бы сменить профессию и из наемного рабочего превратиться во владельца такой фабрики. Во многих консалтинговых компаниях на полном серьезе рассуждают о «фабриках программных продуктов». Большинство таких компаний базируются за океаном, а выводы свои строят исходя из высокой стоимости и низкой окупаемости инвестиций – действительно, многие отделы разработки программного обеспечения в американских компаниях демонстрируют такую динамику. В двух книгах Эдварда Иордона (Edward Yourdon) – «Decline & Fall of the American Programmer» (Yourdon Press, 1993) и «Rise & Resurrection of the American Programmer» (Yourdon Press, 1996) – раскрываются причины, по которым в кругах разработчиков программного обеспечения планирование зачастую проводится недостаточно тщательно или вообще игнорируется. Возможно, связано это с тем, что мы упорствуем в восприятии программирования как одного из видов искусства[97]. Если бы мы подготавливали запуск ракеты на Луну, уверяю вас – обойтись без планирования было бы невозможно.

Кстати, скажу несколько слов об американской космонавтике. Как могло произойти, что в 1960-е годы, когда существующие программные средства уступали уровню типичного современного карманного компьютера, нам удалось высадить человека на Луну? Секрет в том, что причастные к этому проекту специалисты, исходя из имеющихся инструментальных средств, планировали свою деятельность с расчетом на успешный финал. В своих мемуарах, рассказывая о Центре управления полетами, Джин Кранц[98](Gene Kranz) раскрывает принципы, которые, по его мнению, определили заметные успехи подведомственной ему структуры.

• Дисциплина. Способность лидировать, с одной стороны, и идти в заданном направлении, с другой. Понимание того, что для решения задачи необходимо, прежде всего, совладать с собой.

• Компетентность. Космические проекты не терпят небрежности и безразличия – требуется полная готовность к выполнению задания и тотальная устремленность на успех.

• Уверенность. Вера в себя и окружающих; сознание необходимости задушить страх и неуверенность.

• Ответственность. Понимание того, что поставленную задачу нельзя никому передоверить; есть всего две альтернативы: либо сделать то, что требуется, либо потерпеть фиаско.

• Упорство. Нацеленность на преодоление возможных трудностей; последовательность в достижении цели, даже если для этого необходимо пройти по сложному пути.

• Командные усилия. Уважение к способностям друг друга и их разумная эксплуатация; ощущение работы над общей целью и коллективной ответственности за результат.

Далее Кранц утверждает, что «лучше попробовать и потерпеть неудачу, чем приложить недостаточно усилий». Придерживаясь этих принципов, он разрабатывал прекрасные планы – иногда слишком поспешно, но тем не менее ему это удавалось. Он не мог действовать без планирования – в конце концов, на него ложилась ответственность за человеческие жизни. Программные продукты, конечно, никого не убивают, но неудачный результат разработки способен сломать вашу карьеру вместе с карьерой начальницы[99].

Применимы ли принципы Кранца в нашей области? Думаю, вполне, и мне к ним даже нечего добавить. Это четкие, справедливые принципы, которые неплохо бы записать на бумажке, приклеив ее к монитору. Как я уже неоднократно говорил, совершенствование лидерских качеств повышает шансы на достижение успеха, а в части планирования без лидерства не обойтись. Не стоит сваливать эти обязанности на начальницу – не забывайте, что помимо вашего отдела ей, скорее всего, подчинены несколько других. Представьте себя локомотивом коммерческих достижений компании. Если следовать этой аналогии, получается, что вам, с одной стороны, требуются топливо и грамотная эксплуатация, с другой – кто-то должен жать на газ. Может быть, вы – свеча зажигания? Насколько резво вы искрите? Хватает ли вашей увлеченности, чтобы зажечь искру энтузиазма среди подчиненных?

Дата добавления: 2015-07-10