Как пасти котов. Наставление для программистов, руководящих другими программистами

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

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

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

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

«Я полагаю, что бизнес во многом похож на ресторан мирового класса. Если вы заглянете в двери кухни, пища никогда не будет выглядеть так же хорошо, как на вашем столе, куда она попадает великолепно украшенной, в красивой посуде. Бизнес беспорядочен и хаотичен. Я надеюсь, что вы сможете найти на нашей кухне что-нибудь, что могло бы быть полезным в достижении вашей мечты»[29 - Jack Welch, Straight from the Gut (New-York: Warner Business Books, 2001), p. XV.].

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

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

Ответы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кошачьи разборки – похоронный марш

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

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

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

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

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

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

Что дальше

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

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

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

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

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

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

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

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