Две истории

Автор статьи — Джоэль Сполски (Joel Spolsky), программист и менеджер, работавший в Microsoft, Viacom и Juno, а сейчас руководящий собственной небольшой компанией Fog Creek Software. В своём дневнике он пишет замечательные статьи о разработке программного обеспечения и не только об этом. Часть этих статей вы можете прочитать на русском языке. Если понравится, и вы захотите перевести ещё одну статью — присоединяйтесь! В оригинале эта статья называется «Two Stories». Перевод публикуется с разрешения автора.

Сегодня я расскажу вам две истории из моей жизни, которые наглядно объясняют, почему одни компании выходят в лидеры, а другие терпят поражение за поражением. Вся разница между хорошим и плохим управлением кроется в том, насколько свободно чувствуют себя разработчики. Либо вы доверяете им, и они просто делают своё дело, либо вы устанавливаете тотальный контроль, как за официантами в McDonald’s, получая взамен вместо работы весьма изобретательные отмазки или откровенный саботаж.

Первая компания, где я работал, называлась Microsoft. Первым моим проектом был макроязык для Excel. Достаточно быстро я в общих чертах сформулировал требования к языку, назвав его Excel Basic (позже он превратился в Visual Basic for Application, но это уже совсем другая история). Неожиданно на горизонте возникла некая «Группа Разработки Архитектуры Приложений» (ГРАП). Они почему-то считали, что на самом деле это они занимаются «стратегией развития макроязыков», и всё, что так или иначе связано с макросами, их касается. Они затребовали мою спецификацию.

Я поинтересовался у коллег, что же это за загадочная группа? Оказалось, что в эту группу входят всего 4 человека, имеющих степень PhD (это само по себе необычно для Microsoft). Никто из моих коллег не воспринимал эту группу всерьёз. На всякий случай я отправил им свою спецификацию и договорился о встрече — вдруг они посоветуют что-нибудь стоящее!

Как и ожидалось, ничего интересного, одна болтовня. Оказалось, что эти учёные мужи в восторге от возможности наследования. Они считали, что люди, которые пишут макросы для Excel, будут активно пользоваться наследованием. В конце концов, один из них сказал: «Ладно, всё это очень хорошо. Но кто-нибудь из руководства одобрил вашу спецификацию?»

Я рассмеялся. Несмотря на то, что я работал в Microsoft всего несколько месяцев, я знал, что никто ничего не «одобряет». Да что там одобрение, ни у кого не было времени, чтобы просто прочитать спецификацию! Программисты ежедневно требовали от меня новой порции текста, чтобы можно было писать код. Мой начальник достаточно ясно дал понять мне (а его начальник — ему), что никто ничего не понимает в макросах, и никто, кроме меня, макросами не занимается. Следовательно, все решения, которые я принимаю, уникальны, а потому правильны. И тут какой-то тип из какой-то странной группы говорит о каком-то «одобрении»!

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

Во главе ГРАП стоял некто Грег Уиттен (Greg Whitten). Это был человек №6 в Microsoft. Никто не знал, чем он занимается, но зато все знали, что он обедает с Биллом Гейтсом, и GW-BASIC назван в честь него. Получилось, что я обидел Самого. Грег собрал большое совещание, где заявил, что команда разработчиков Excel (то есть я) игнорирует принятую «концепцию макроязыков». Мы попросили его более подробно изложить свои претензии, но он не сумел привести ни одного убедительного примера. Представляете, каково это — совсем зелёному выпускнику колледжа победить в споре человека №6 в Компании? (Можете ли вы вообразить себе такую ситуацию в вашей компании? [в оригинале — Grey Flannel Suit company]) Мой начальник Бен Вальдман (Ben Waldman, сейчас вице-президент Microsoft) стоял за меня горой. В конце концов, мы же выпустили продукт, поэтому нам и судить о том, как надо делать!

На этом я считал инцидент исчерпанным. Если бы господа из ГРАП вздумали предъявить ещё какие-нибудь аргументы в пользу своей позиции, я готов был спорить с ними хоть до посинения — лишь бы не мешали работать. Но случилось нечто, выходящее за рамки моих представлений о реальности. Мы с коллегами обедали, когда ко мне подошёл Пит Хиггинс (Pete Higgins). Он был руководителем всего проекта Office, и я очень хорошо знал его, но не думал, что он знает меня.

— Как дела? — спросил он. — Я слышал, у тебя какие-то проблемы с ГРАП?

— Ничего страшного, — ответил я.

— Понял, — ответил он. А на следующий день меня ждало невероятное известие: Группа Разработки Архитектуры Приложений была распущена. Мало того, все её члены были переведены в разные отделы, подальше друг от друга. Я больше никогда не слышал ни об одном из них.

Меня, разумеется, не тронули. В Microsoft так заведено — если ты руководишь проектом разработки продукта, то ты — царь и бог во всём, что касается этого продукта. То, что ты работаешь в компании меньше полугода, не имеет никакого значения. Никто не может ставить тебе палки в колёса, даже человек №6.

У такой идеологии есть два огромных преимущества. Во-первых, разработчик начинает более ответственно относиться к своей работе. Он уже не может спрятаться за широкую спину менеджера, который «одобрил» спецификацию. Менеджеры вообще не читают спецификаций; их задача — нанять умных людей и обеспечить им условия для работы. Во-вторых, разработчику просто нравится работать в такой компании. Ну скажите, кому не хочется быть «царём и богом» хотя бы в своей маленькой области? Особенность процесса разработки программного обеспечения в том, что его достаточно легко разбить на мелкие независимые подзадачи, разделив тем самым ответственность между разработчиками. Именно это и есть главная причина, почему программисты так любят работать в Microsoft.

Прошли годы. Теперь я работал в Juno — компании, занимающейся предоставлением всевозможных online-сервисов, в том числе, бесплатной почты. Обстановка здесь была прямо противоположной той, которую я наблюдал в Microsoft. У меня в подчинении было два программиста, но мой начальник без конца подрывал мой и без того невысокий авторитет, раздавая им задания. При этом часто он даже не ставил меня в известность. Даже для того, чтобы взять отгул, мои подчинённые должны были получить его одобрение.

Через несколько лет работы в Juno я занимался разработкой новой процедуры регистрации. Мы готовили новый релиз программного обеспечения, Juno 3.x, и группа под моим руководством должна была полностью переделать эту процедуру. К тому времени я уже занимал относительно высокую должность. У меня были серьёзные достижения, и моё начальство было довольно моей работой. Но доверять мне они не могли. «Тотальный контроль и слежка» — это было у них в крови.

В процессе регистрации пользователь должен ввести свой день рождения. Это очень незначительная часть вопросника, который Juno предлагала своим клиентам. Почти 30 экранов самых разных вопросов — ваш любимый вид спорта, сколько у вас детей и сколько им лет, и так далее, около сотни вопросов. Чтобы сделать процедуру регистрации хотя бы чуточку проще, я решил сделать поле для ввода даты обычной строкой. Пользователь мог набрать «8/12/74» или «12 Aug 74» или даже «August 12, 1974». В общем, как в Outlook — как бы вы ни ввели дату, программа всё равно её распознает.

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

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

Я не хочу сказать, что уволился из Juno из-за этого случая, но причина, по которой я оттуда ушёл, должна быть вам понятна: сколько бы ты там ни работал, какая бы у тебя ни была репутация, какую бы должность ты ни занимал — ты на самом деле ничего не решаешь, даже на самом примитивном уровне. Можешь взять все свои идеи, наработки, опыт, ум, свернуть их в трубочку и засунуть в …. В Juno куча менеджеров, примерно четверть от общего количества сотрудников, и большую часть времени они занимаются тем, что суют свой нос всюду, куда могут дотянуться, и контролируют всё, что поддаётся контролю. Разительный контраст с Microsoft, где для того, чтобы подтвердить твои полномочия в принятии решений могут запросто выгнать вице-президента.

В какой-то мере такой ужасный менеджмент в Juno — следствие географического положения компании: она расположена не на Западном побережье, а в Нью-Йорке, куда ещё не докатились «новые веяния». Кроме того, это следствие крайней неопытности менеджеров снизу доверху, включая директора — молодого человека 29 лет от роду, никогда не работавшего нигде, кроме D. E. Shaw. Директор постоянно лез в дела, которые его совершенно не касались, например, исправлял сообщения об ошибках. Главный инженер постоянно кричал на своих подчинённых, стоило им чуть-чуть усомниться в правильности его решений. Они вымещали свою злость на программистах, а те, в свою очередь, приходили домой и давали пинка собаке. Сравните это с Microsoft, где большинство менеджеров ведут себя так, словно их важнейшая работа — убрать с дороги мебель, чтобы программист, не дай бог, не споткнулся и не сбился с мысли.

15.05.2003