Идеальная IT-компания. Как из гиков собрать команду программистов - Брайан Фитцпатрик

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

С другой стороны, вам также необходимо учиться принимать критику. Это подразумевает не только скромность по отношению к собственным навыкам, но и доверие к тому, что другой человек искренне неравнодушен к вашим ключевым интересам (и интересам вашего проекта!) и не считает вас идиотом. Программирование – такой же навык, как и любой другой. Он совершенствуется с практикой. Если коллега указал вам на то, как можно усовершенствовать ваши приемы, то воспримете ли вы это как нападки на ваш характер и попытку унизить ваше достоинство? Надеемся, что нет. Аналогичным образом, ваша самооценка не должна быть связана с кодом, который вы пишете. Вы и ваш код – не одно и то же. Повторяйте это снова и снова. Вы и ваш код – не одно и то же. Вы должны не только сами поверить в это, но и заставить поверить в это ваших коллег по работе.

Не отождествляйте самооценку с качеством вашего кода

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

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

Ошибайтесь часто, учитесь и повторяйте

В бизнес-сообществе существует широко известная (и банальная) легенда о менеджере, который совершил ошибку и потерял 10 миллионов долларов. На следующий день он пришел в офис и стал паковать вещи. Услышав неизбежное приглашение в кабинет генерального директора, он поплелся туда и молча протянул директору лист бумаги. «Что это?» – спросил директор. «Заявление об увольнении, – ответил менеджер. – Я полагаю, что вы пригласили меня именно за этим». «Уволить тебя? – недоверчиво спросил директор. – С чего мне это делать? Я только что вложил 10 миллионов долларов в твое обучение!»[5]

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

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

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

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

Хорошо составленные «результаты вскрытия» должны содержать в себе следующую информацию:

• краткий отчет;

• хронологию проблемы – от ее обнаружения до исследования и разрешения;

• основную причину проблемы;

• оценку последствий и ущерба;

• список действий, направленных на немедленное решение проблемы;

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

• сделанные выводы.

Выделяйте время на обучение

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

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

Учитесь быть терпеливым

Несколько лет назад Фитц занимался созданием инструмента, который конвертировал CVS-репозитории в Subversion (а впоследствии и в Git).

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