Создание в срок качественного программного обеспечения – ваша цель, а управление процессом – ваша работа, так что же вы делаете в свободное время? Вероятно, пишете код. Если вы доросли до начальника из программистов, вам стоит продолжить программировать, в противном случае ваше увлечение этим ремеслом будет ослабевать, и ваши навыки постепенно «сойдут на нет». Другой возможной причиной для того, чтобы искать и находить время для кодирования, является удовольствие, которое оно доставляет. Если возглавлять команду программистов – для вас дело новое и вы пока еще адаптируетесь к этой роли, то кодирование доставит вам удовольствие, поскольку именно это вы хорошо знаете и умеете делать продуктивно. Я полагаю, что продолжать писать код абсолютно необходимо, поскольку это занятие связывает вас с прошлой жизнью, с вашими корнями. Корни очень важны, ведь они определяют ваше отношение к своему ремеслу, и как руководителю вам придется пустить в грунт своей жизни несколько новых корней.

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

Исследование вашей объективности может оказаться трудной задачей, поскольку в этом процессе существенную роль играет субъективность. Для того чтобы облегчить самопроверку, взгляните на следующий перечень вопросов и обдумайте их по ходу чтения этой главы. В ее конце я предложу свои ответы на них. Эти ответы я считаю естественными для управленца, и они помогут вам стать лучшим руководителем, чем вы есть. Как теннисист, вы не можете сделать хороший замах, не сжав рукоять ракетки. Управление – это ракетка, так что предложенные вопросы требуют ваших ответов. Итак:

• Считаете ли вы, что предельные сроки завершения проекта – это рекламный прием, на самом деле не имеющий большого значения?

• Позволяете ли вы программистам самим принимать основные архитектурные решения, если вы слишком утомлены или заняты?

• Надеетесь ли вы, что ваши опытные программисты и без вас все сделают правильно, поскольку у вас просто нет времени на то, чтобы нянчиться с ними?

• Полагаете ли вы, что при приближении срока сдачи проекта все проблемы в конце концов решатся[18]?

• Считаете ли вы, что пользователи никогда не сделают ничего, что привело бы к программному сбою, просто потому, что у них не хватит ума для этого?

• Предпочитаете ли вы при управлении коллективом искать консенсус, даже если это требует массы времени и терпения?

• Считаете ли вы электронную почту эффективным средством общения при работе над проектом?

• Согласны ли вы проговорить по телефону несколько часов кряду, только чтобы убедиться, что все идет как надо?

• Считаете ли вы, что с помощью комитетов и комиссий невозможно выработать адекватные бизнес-требования?

• Считаете ли вы себя самым умным программистом в компании?

• Чувствуете ли вы ревность и страх, когда смотрите на действительно хороший код, который написан не вами?

• Делаете ли вы все возможное, чтобы успеть закончить проект в срок[19]?

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

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

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

Уильям Блейк (William Blake) писал: «Тот, кто желает, но не действует, распространяет чуму»[21]. Если вы не исправите слабые места в вашем стиле руководства, вы распространите чуму среди своих программистов. Продолжая наш поэтический экскурс (поэзия – близкая родственница программирования), отметим следующие строки:

…в сердце взгляни,
Растет в нем святое древо,
Листья дрожат, как огни,
Питает их радости чрево.[22]

Вы должны ухаживать за этим «деревом». Как Вергилий, ведший Одиссея сквозь чистилище[23], я здесь для того, чтобы провести вас к вашему новому месту во вселенной программного обеспечения.

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

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

Вы уже поняли, что кодирование больше не ваш хлеб. Иногда вы относитесь к этому как к «программистскому аду», поскольку получаемые вами задания должны быть выполнены к нереальным срокам, и вам не с кем посоветоваться, кроме себя. Как программист вы привыкли к жаре, получали удовольствие от общения с вашими собратьями-программистами и считали программирование основным делом своей жизни.

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

Геометрические аспекты рая, чистилища и ада вполне применимы к вашему месту в иерархии управления компанией. Представьте себе, что с каждой ступенькой вверх по административной лестнице растет и высота, с которой вам, возможно, придется падать. Если ваша лестница правая (прислонена к правой стороне стенки), мужайтесь: в конце концов, вы знаете, что ваше дело правое. Кстати говоря, а куда вы движетесь как программист-начальник? Будем надеяться, по направлению к успеху – как личному (персональному), так и общему (корпоративному). Хотя успех и определяется по-разному, одно из определений я нахожу наиболее полезным и практичным: это способность радоваться своему труду и не терять своего увлечения. Может показаться, что при такой оценке увлечение ставится слишком высоко, однако оно может зажечь огонь у вас внутри и помочь вам покорить столь непредсказуемый мир разработки программного обеспечения. Увлечение – это топливо, которое может раскрутить «мотор» вашего руководства. Требуйте от своих программистов во всем добиваться безупречности, чего бы это ни стоило. Если они считают, что изящество и безупречность – это те две вещи, которые затягивают время кодирования, напомните им, что элегантность – это достижимое совершенство. Увлечение побудит их добиться этих целей. Лелейте свое увлечение – ведь для вас это единственный способ расти, приспосабливаться, превозмогать, достигать цели. Это часть обязанностей по уходу за деревом, на котором распускаются цветы успеха.

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

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

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

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

Время – это либо союзник, либо враг. Взвесьте, что сказал Френсис Бэкон (Francis Bacon) – один из отцов-основателей современной науки:

«Тот, кто не ищет новых лекарств, должен ожидать появления новых бед, ведь время – величайший новатор»[25].

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

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

Для общения вашего коллектива вполне достаточно одной встречи в неделю. Остерегайтесь тратить чересчур много времени на разговоры и мало на решения и действия. Не устраивайте встречу только ради того, чтобы получить одобрение своих решений. Поощряйте дискуссию, но ищите решения. И помните, что дьявол – в деталях, а цель любой встречи – это изгнание этих дьяволов. Если вы контролируете ход встречи, вы контролируете время. Установите предел для любой встречи: 45 минут общения обычно более чем достаточно. Зачастую могут быть нужны и 8-часовые обсуждения проекта, однако всегда имейте подробную повестку дня и следуйте ей, если вы собираетесь выдержать такую длительную мозговую атаку.

Не устраивайте встречу только ради того, чтобы получить одобрение ваших решений. Поощряйте дискуссию, но ищите решения.

Не верьте теории, утверждающей, что чистый стол – признак скудоумия. При взгляде на рисунки Эйнштейна может показаться, что на столе у него царил ужасный беспорядок, но я ручаюсь, что в его голове – нет. Вам необходимо в достаточной мере организовать процесс, но не тратить все время на планирование. Достичь равновесия трудно, но необходимо. Тема организации, необходимой для успеха, затронута глубже в главе 4. Не путайте вопросы организации работы с вопросами ее выполнения. Организация – это начальная стадия плана. Разрабатывайте план. Вспомните, что сказал Спок (Spock): «Логика – начало мудрости»[26]. Аналогично, планирование – начало выполнения.

Вы роздали задания, вернулись к вашим обязанностям и надеетесь, что все заняты выполнением заданий. Однако после ваших подробнейших объяснений Джо спокойно отправляется бороздить Интернет, даже не попытавшись заставить программный интерфейс приложения работать правильно. Если вы думаете, что промежуточные этапы не являются неотъемлемой частью поставленной вами задачи, то вы понятия не имеете о том, как работает голова программиста, даже несмотря на то, что вы – один из них. Это вполне в человеческой природе: если до срока сдачи остается месяц, времени на то, чтобы сделать работу, вполне достаточно. Время можно считать потерянным, если нет очевидного продвижения. Работа над частью нового продукта – это поступательный итерационный процесс, не подчиняющийся булевой логике и предполагающий много возможностей для проверки. Предположим, вы сообщили отделу тестирования, что дата завершения кода – XX-е января. Лучше, если эта дата не будет рабочей датой окончания работы над кодом! Вы не сможете сделать работу X, если сначала не будет выполнена часть X – Y, где Y – еженедельно определяемая часть работ. (Вы можете сказать, что «сделано за день»?) Вы наверняка слышали, что цена свободы – это постоянная бдительность, ценой же вовремя сделанного программного обеспечения является неизменное усердие.

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

Технология волшебной пули или золотого молотка (как бы вы ее ни назвали) не может решить бизнес-проблем, это делают люди. Уверен, вы применяете технологию для реализации решений, но вы тратите время попусту, если думаете, что покупка последнего дополнения к среде разработки даст скачок производительности. Следующая версия языка программирования также не решит ваших проблем. Конкурирующие производители средств разработки программного обеспечения обещают многое. Наша отрасль разделена надвое: Microsoft и все остальные. Я, конечно, понимаю, что это слишком упрощенное разделение, но оно послужит иллюстрацией моего утверждения: продукты Microsoft могут оказаться не оптимальными для решения ваших конкретных задач, так как Microsoft слишком большая и многоплановая корпорация. Не важно, много или мало у Microsoft возможностей влиять на всю отрасль и каковы эти возможности, – технология Microsoft построена на базе заранее определенного архитектурного плана. Мир Java, олицетворяемый Sun, слегка отличается, и хотя он более фрагментирован по сравнению с Microsoft, Sun также создает свои продукты на основе конкретной архитектурной схемы. Вы можете использовать Enterprise JavaBeans или NET сколько душе угодно, но в любом случае вам придется принять внутренние архитектурные ограничения. Я призываю определить ваши архитектурные задачи и планы до того, как вы выберете технологию реализации. Вам придется все переделать, если с новым инструментом дело «не выгорит». Вы уже много раз слышали: если у вас не хватает времени даже на то, чтобы сделать все правильно, где же вы его найдете на то, чтобы все переделать?

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

Классическая управленческая ловушка для начальника, вышедшего из программистов, касается распределения заданий. Вы понимаете, каким образом реализовать определенное решение, а обучение членов команды, которые вовсе не обязательно видят это решение, требует времени. Здесь применима старая китайская поговорка: «Дайте человеку рыбу, и он будет сыт один день; научите его ловить рыбу, и он будет сыт всю жизнь». Если бы все стали столь же сообразительны, как вы, было бы вам проще работать? Возможно. Потратьте время на обучение сейчас, и вы сэкономите его потом, поскольку ваши сотрудники научатся решать проблемы без вашей помощи. Тогда вы сможете эффективно распределять задания, а не давать объяснения.

Трудным заданием для тех, кто любит программировать или управлять по наитию, является документирование. При необходимости можно «опередить события» и сделать экранный прототип, но экранные снимки делаются только ради конкретизации проектной документации. Не отдавайте прототип напрямую программисту, который должен завершать проект. Может показаться, что такой прототип сэкономит время, но он может просто повести программиста неверным путем и спровоцировать фальстарт. Не думайте, что для написания кода бизнес-требований достаточно. Бизнес-требования – только начальный этап разработки документа, позволяющий обрисовать архитектуру, а дальше вы можете говорить о реализации решения в объектах кода. У вас всегда будет искушение, когда поджимает время (а разве бывает иначе?), слепить все «по-быстрому», однако надо быть настоящим счастливчиком, чтобы, не имея четкого плана, создать программный продукт, который можно будет в дальнейшем дополнять и обновлять.

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

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

Как я упомянул в этой главе ранее, в момент, когда вы впервые превращаетесь из программиста с полной занятостью в начальника с полной занятостью и одновременно программиста с частичной занятостью, административная деятельность кажется не столь продуктивной, как кодирование. Учитесь различать просто трату нервной энергии и настоящее творчество. Что я имею в виду? Если вы привыкли кодировать часами, то вы поймете, что такое нервная энергия. Это то состояние вашего ума, когда вы прикончили уже три чашки кофе[27], вам еще писать и писать, но вы уже чувствуете приближение результата. Настоящее творчество – это ощущение, когда вы видите и конечный результат, и все ступени его достижения, но при этом знаете, что должное качество будет достигнуто далеко не так быстро. Я знаю, что все сказанное трудно переварить, но вам действительно нужно как следует обдумать эту концепцию.

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

Как начальнику вам следует оценивать свою производительность объемом работы, которую выполняет ваш коллектив.

В своей крайне проницательной книге «The End of Patience» Дэвид Шенк (David Shenk) пишет:

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

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

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

Если вы новичок в деле управления, не ожидайте, что почувствуете себя комфортно ранее, чем через 6 месяцев. Пусть этот дискомфорт напоминает вам о необходимости многому научиться, а также о том, что изучение новых способов быть полезным и чувствовать себя полезным требует времени, но за это воздастся в будущем.

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

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

Такие вещи вряд ли могут быть полезными. Если вы минималист, то в случае когда дело доходит до обработки ошибок (которых в идеале не бывает), вы можете не заметить отсутствия процедур обработки ошибок в коде Салли, считающей все настолько очевидным, что обработка ошибок – это просто трата места. Я могу продолжить перечень слабостей программистов, но оставлю это вам. Тем не менее вам требуется осознать необходимость постоянно быть внимательным к своим недостаткам как программиста, поскольку нельзя прощать другим то, что вы могли бы простить себе. Это может выглядеть противоречиво, и так оно на самом деле и есть, так что продолжайте работу над исправлением своих недостатков как программиста, чтобы не заразить ваших подчиненных теми же слабостями.

Чтобы вам было легче преодолевать свои слабости, представьте себе, что многие люди прошли тот же путь, что и вы. Некоторые из них проложили на этом пути вехи для вас – это книги и иногда URL-адреса. Другими словами, для того чтобы заполнить пробелы в знаниях и/или опыте, рекомендую побольше читать. Вам нужно читать по многим причинам. Вот некоторые из них:

• Читайте, чтобы оставаться «на уровне». Сюда можно отнести чтение отраслевых журналов, книг, посвященных вашему основному языку программирования, и журналов, касающихся методов, применяемых в вашей работе. Это вы должны делать почти каждый день, просто чтобы не потерять необходимые навыки.

• Читайте, чтобы быть в курсе. Такое чтение расширит ваши познания, причем некоторые из источников, используемых для сохранения вашей квалификации (чтобы оставаться «на уровне»), применимы и в этом случае. Здесь вам надо сфокусироваться на том, что, возможно, не требуется прямо сейчас, но может понадобиться в ближайшем будущем. Интернет-рассылки, форумы и прочие чудеса информационной эры могут быть необычайно полезными. Не забывайте, однако, что эра информации – это совсем не то же самое, что эра знаний.

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

• Читайте, чтобы стать мудрее. Умные люди встречаются не только в нашей области. Другие научные дисциплины, а также художественная литература могут научить вас подходить к любому вопросу с разных сторон. Очень часто в нашей профессии мы ограничиваемся вертикальным мышлением. Вертикальное мышление подразумевает поступательное движение от одного логического умозаключения к следующему и отбрасывание того, что не укладывается в рамки заранее имеющихся у нас представлений о наиболее подходящем. Разностороннее мышление – это то, что приносит оригинальные идеи и зачастую является признаком гениальности.

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

Вот пример того, что я имел в виду, говоря о деловом подходе. Джек Уэлч (Jack Welch), бывший долгое время главой General Electric, пишет:

«Я полагаю, что бизнес во многом похож на ресторан мирового класса. Если вы заглянете в двери кухни, пища никогда не будет выглядеть так же хорошо, как на вашем столе, куда она попадает великолепно украшенной, в красивой посуде. Бизнес беспорядочен и хаотичен. Я надеюсь, что вы сможете найти на нашей кухне что-нибудь, что могло бы быть полезным в достижении вашей мечты»[29].

Не правда ли, сказано будто про бизнес в области программного обеспечения? Уэлчу есть много чего сказать, причем вполне уместного и для руководителя программистов, поскольку он пишет о руководстве в течение 20 лет одной из крупнейших и доходных компаний. Учитесь у тех, кто проделал путь наверх до вас. Идите по их следам.

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

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

• Считаете ли вы, что предельные сроки завершения проекта – это рекламный прием, на самом деле не имеющий большого значения?

На самом деле сроки всегда имеют значение. Ваша компания может распространять программное обеспечение с целью продажи предоставляемых им услуг, и информация о товаре должна содержать описание его свойств. Даже если пользователи не задействуют все возможности вашего продукта, они должны быть представлены в рекламном буклете. Некоторым состоятельным клиентам может потребоваться лишь одна деталь, которая не нужна остальным, и ее поддержка программным обеспечением может стать причиной ощутимой выгоды. Маркетинг может оказывать опасное влияние на разработку программного обеспечения, однако он необходим. Даже если вы не хотите, чтобы весь цикл разработки определялся отделом продаж, все равно для вас он будет одной из движущих сил в определении даты окончания работы над проектом. Постарайтесь узнать продавцов поближе, стать их другом. Заслужите их доверие пунктуальностью и узнайте от них положение вашего продукта на рынке. (См. далее врезку «Кошачьи разборки», непосредственно связанную с этим вопросом и ответом на него.)

• Позволяете ли вы программистам самим принимать основные архитектурные решения, если вы слишком утомлены или заняты?

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

• Надеетесь ли вы, что ваши опытные программисты и без вас все сделают правильно, поскольку у вас просто нет времени на то, чтобы нянчиться с ними?

Этот вопрос тесно связан с предыдущим – и опять же: если вы руководите квалифицированными людьми, то им может не требоваться ваше постоянное внимание. Только не забудьте о том, что я говорил относительно ожидания результатов без проведения проверок.

• Полагаете ли вы, что при приближении срока сдачи проекта все проблемы в конце концов решатся?

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

• Считаете ли вы, что пользователи никогда не сделают ничего, что привело бы к программному сбою, просто потому, что у них не хватит ума для этого?

Это тоже вопрос принятия желаемого за действительное. Из программистов получаются плохие бета-тестеры – поскольку мы подсознательно знаем, что определенные функции при проверке «грохнутся», мы и не пытаемся их проверять. В конечном счете ошибки всегда проявляются, так что не позволяйте поспешности влиять на качество. Как руководителю проекта вам стоит самому включиться в рабочий процесс на этапе альфа-тестирования, дабы выявить небрежности в программировании.

• Предпочитаете ли вы при управлении коллективом искать консенсус, даже если это требует массы времени и терпения?

Я коснулся этого вопроса в конце предыдущей главы, а в этой подробно осветил роль времени и необходимость сохранять терпение, поэтому полагаю, что ответ очевиден. Если ваша интуиция вас иногда подводит, скажу прямо: консенсус должен быть вашей постоянной целью, и вы должны делать все, чтобы его достичь. Более подробное обсуждение этого вопроса вы можете найти в главах 5 и 6.

• Считаете ли вы электронную почту эффективным средством общения при работе над проектом?

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

• Согласны ли вы проговорить по телефону несколько часов кряду, только чтобы убедиться, что все идет как надо?

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

• Считаете ли вы, что с помощью комитетов невозможно выработать адекватные бизнес-требования?

Иногда комитеты и комиссии бесполезны, но обычно в большой и сложной организации они необходимы. Теперь, когда вы стали ответственным лицом, вам, возможно, предстоит быть членом или председателем большего числа разнообразных комитетов и комиссий, так что будет лучше, если вы научитесь их использовать. При удачном стечении обстоятельств комиссии могут быть мощным средством объединения интеллектуальных ресурсов, так что не надо недооценивать их значение. Как-никак, ни один человек не обладает всей необходимой информацией, а без знания бизнес-требований ваше программное обеспечение сгодится разве что для забавы.

• Считаете ли вы себя самым умным программистом в компании?

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

• Чувствуете ли вы ревность и страх, когда смотрите на действительно хороший код, который написан не вами?

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

• Делаете ли вы все возможное, чтобы успеть закончить проект в срок?

Это возвращение к первому вопросу. Несоблюдение сроков может нанести убытки вашей компании и похоронить вашу карьеру. Нужны ли здесь еще какие-нибудь слова? Да. Лейтмотивом хорошего руководства разработкой программного обеспечения является прилежание, бдительность, внимание к деталям. Определение крайнего срока лежит в рамках этих составляющих руководства. Вы, может быть, вспомните, как Скотти из «Звездного пути» заслужил свою репутацию уникального работника[30], и примените схожий метод. Только не умножайте вашу исходную оценку времени, необходимого для завершения работ, на произвольное число, а назовите вашим людям какую-нибудь вымышленную дату, предшествующую дате, которую вы сообщите отделу тестирования. Чем больше вы будете практиковаться в оценке сроков, тем больших успехов вы достигнете в этом виде искусства.

Эти вопросы не были тестом – это были размышления о вашем положении начальника, позволившие выявить слабости, которые могли бы помешать вашему успеху.

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

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

Роджер размышлял о том, что он мог бы сказать Джеффу такого, что было бы внове для него и могло бы заставить его наконец-то завершить работу. Он знал, что Джефф подолгу задерживается на работе вечерами и в выходные, – он звонил ему на всякий случай. Хоть бы код был написан не на С, тогда, может быть, Роджер смог бы помочь. Ну что ж, думал Роджер, он сделал все, что мог.

Прошло около тридцати минут рабочего дня, когда президент заглянул в просторный кабинет Роджера и сказал: «Спуститесь в мой кабинет на несколько минут. Вы мне нужны для небольшого разговора». Роджер поежился и подумал, что «небольшой разговор» – это обычная словесная выволочка от вышестоящего начальства. Когда Роджер присел напротив письменного стола руководителя компании, секретарь закрыла дверь в кабинет. Президент посмотрел в глаза Роджеру и произнес: «Вы догадываетесь, зачем я вас позвал?» Роджер не имел ни малейшего понятия, но пробормотал несколько слов о том, что сожалеет. Президент, как казалось, был в затруднении и просто сказал: «Собирайте ваши вещи. Вы уволены. Я вам месяц назад сказал, что к этому последнему сроку мы должны закончить. Чек с вашим выходным пособием получите у моего секретаря. Я хочу, чтобы вы покинули здание до полудня. До свидания».

Чему вы можете научиться из этой истории? Многому – в ней на каждом шагу намеки. Речь идет об очевидно успешной и богатой компании, отделом продаж в которой руководит очень напористый вице-президент. Он уже подписал контракты на систему, которая даже не была закончена. Другой же неудачливый вице-президент, ответственный за разработку программного обеспечения, на самом деле не имел необходимых технических навыков для того, чтобы понять, с какими затруднениями столкнулся программист Джефф. Вдобавок вместо того, чтобы сидеть вместе с Джеффом вечерами и в выходные и убедиться, что работа действительно сделана, он ограничивался телефонными «проверками» Джеффа.

Этот уволенный вице-президент совершил много ошибок. Во-первых, он не ощущал важности окончания работы в срок. Это проистекало из неуважения к деловым обязательствам. «Я сделал все, что мог», – замечательные последние слова, достаточно иррациональные и произнесенные исключительно для самоутверждения. Во-вторых, он был некомпетентен в данной проблеме. Этот вице-президент не знал С, но управлял программистом, который знал этот язык (но, очевидно, не очень хорошо). В-третьих, этот вице-президент не смог определить, в чем настоящая причина проблемы, – в программисте или в программном обеспечении. Он так и не выявил истинных причин надвигающегося бедствия. Итак, итоги вскрытия таковы: его уволили, и рассказанная история была реквиемом по делу, которое он делал.

На протяжении всей этой главы я держал перед вами зеркало (зеркало – метафора самопроверки и самонаблюдения). Глядеться в него было, возможно, неприятно и даже болезненно, но без боли вам не удастся вырасти до руководителя мужчин и женщин, разрабатывающих программное обеспечение в условиях жестких временных рамок. Есть ли секреты в управлении самим собой? Я не знаю ни одного, но точно знаю, что мое определение «сделаю все, что смогу» в контексте руководства программистами имеет другое значение. Бывает, когда фраза «я сделал, что смог» произносится под конец, в случае неудачи. Не думайте об этих словах в таком ключе. Эти слова означают приложение максимума усилий – их можно оценивать каждодневно, успех же иногда приходит только в самом конце. Так что если секрет и есть, то он таков: каждый день проверяйте себя как руководителя и старайтесь стать лучше уже на следующий день. Ваш перечень вопросов к самому себе мог бы выглядеть так:

1. Подвергаю ли я качество своего управления ежедневной оценке?

2. Действительно ли я с каждым днем руковожу все лучше или я постоянно откладываю совершенствование стиля и сути моего управления на потом?

3. Нравится ли мне то, что я делаю?

4. Теряю ли я попусту время при выполнении своих служебных обязанностей?

5. Оцениваю ли я свою производительность тем, сколько сделали мои подчиненные под моим руководством, или у меня есть ощущение, что сам я не сделал ничего?

6. Как мои слабости дали себя знать сегодня (по отношению ко мне самому или другим)?

7. Чему я научился сегодня, чтобы оставаться в курсе, чтобы быть осведомленным, чтобы углубить и расширить свои знания?

Этот перечень содержит семь пунктов; число семь древние считали совершенным. Вы не достигнете совершенства ни сегодня, ни назавтра, ни, возможно, в течение всей вашей жизни, но вы можете сделать максимально эффективными свои усилия, направленные на самосовершенствование, делая все, что нужно, ежедневно.

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

Примечания:

1

Мои шутки, по большей части размещаются в сносках, так что они не будут вас отрывать от основной мысли. Ну вот, например: что значит «обратная совместимость»? Это значит, что новая операционная система с тем же успехом, что и старая, может грохнуть все ваши программы.

2

Вы ведь знаете, что такое «ниндзя», правда? Это слово обозначает исключительность. Получается своего рода «черный пояс в программировании».

3

Большинство этих терминов разъясняются в издании The New Hacker's Dictionary, Third Edition, by Eric S. Raymond (The MIT Press, 1998).

18

Это то же самое, что предпочесть синюю пилюлю красной в «Матрице», культовом фильме многих программистов.

19

Южанин бы сказал: «Я пойду за этим в пасть дьявола». Это значит, что вы ни перед чем не остановитесь ради того, чтобы достичь своих целей. Природа этой аллегории происходит от изображения ада в виде ужасной разинутой пасти, готовой поглотить вас, – очень напоминает срок сдачи проекта, к которому невозможно успеть. Вы проявляете твердость и с мечом в руках рубитесь у врат ада, преодолевая силу, стремящуюся вас уничтожить.

20

Помните «Звездные войны»? Что Оби-Ван, говоря об отце Люка, сказал о природе правды и точки зрения? (Когда умер Йода.)

21

Эту и многие другие прелестные вещи, в равной степени поучительные и гнетущие, можно найти в поэмах Блейка «Marriage of Heaven and Hell». Упомянутая выше цитата взята из «Proverbs of Hell» – William Blake, The Complete Poetry and Prose of William Blake, cd. David Erdman (Derkelcy, CA: University of California Press, 1982).

22

Уильям Батлер Йейтс (William Butler Yeats), избранные поэмы (New York: Collier Books, 1986). Перевод В. А. Савина (http://zhurnal.lib.ru/s/sawin_w_a/rtfrtf.shtml).

23

Вы можете освежить ваше классическое образование, прочтя современный перевод Чистилища Данте. Когда вы окажетесь в роли руководителя, вам может показаться, что вы находитесь где-то между раем и адом, однако в действительности это не так – это наше видение обычной жизни.

24

Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams, Second Edition (New York: Dorset House Publishing, 1999).

Русский перевод книги доступен на http://lib.rus.ec/b/72962 (прим. сост. FB2)

25

См. эссе Бэкона «Of Innovations» (1625). Еще одна занятная цитата: «Время – это огонь, в котором мы горим». Это, возможно, взято из произведения какого-нибудь великого классического писателя, но черт меня возьми, если я смогу выяснить, кого именно, так что нам пришлось ограничиться Бэконом.

26

Помните как в «Звездном пути» Спок напился с Валарисом после их беседы об изгнании людей из рая? Гм, возможно, рай – это просто работа программиста в сравнении с работой руководителя, – вам решать.

27

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

28

David Shеnk, The End of Patience: Cautionary Notes on the Information Revolution (Bloomington, IN: Indiana University Press).

29

Jack Welch, Straight from the Gut (New York: Warner Business Books, 2001), p. xv.

Русский перевод книги доступен на http://lib.rus.ec/b/99731  (прим. сост. FB2)

30

Скотти просто умножал оценочное время ремонта на 4.