Annotation

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

- Брайан Фитцпатрик, Бен Коллинз-Сассмэн

- Отзывы о книге

- Цель этой книги

- Благодарности

- От Фитца

- От Бена

- Об авторах

- От издательства

- Введение

- Для кого предназначена эта книга

- Внимание: эта книга не является техническим пособием

- Эта книга о том, чему не учат в вузах

- Ключевая идея книги

- Глава 1. Миф о гениальном программисте

- Помогите мне спрятать свой код!

- Миф о гении

- Скрываться вредно

- Все дело в команде

- Три кита

- Скромность, уважение и доверие на практике

- Избавьтесь от самомнения

- Учитесь критиковать и быть критикуемым

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

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

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

- Будьте открытым для внешнего влияния

- Дальнейшие шаги

- Глава 2. Формирование высокой командной культуры

- Что такое культура?

- Зачем заботиться о культуре?

- Культура и люди

- Коммуникационные шаблоны успешных культур

- Высокоуровневая синхронизация

- Формулирование миссии (только не это!)

- Эффективные собрания

- Работа с «географически сложными» командами

- Проектная документация

- Текущие обсуждения

- Списки рассылки

- Онлайн-чаты

- Система отслеживания ошибок

- Общение как часть разработки

- Комментарии к исходным текстам

- Указание вашего имени в файлах с исходным кодом (проблема «ссылки на автора»)

- Требуйте рецензирования всего опубликованного кода

- Создайте настоящие процедуры тестирования и выпуска

- Все это касается кода

- Глава 3. В каждой лодке должен быть капитан

- Природа не терпит пустоты

- Устаревший подход к управлению

- Лидер – это новый менеджер

- Единственное опасение состоит… во всем!

- Лидер-слуга

- Антирекомендации

- Нанимайте плохих профессионалов

- Игнорируйте неэффективных сотрудников

- Игнорируйте социальные проблемы

- Будьте другом каждому

- Идите на компромиссы при найме

- Обращайтесь с участниками команды как с детьми

- Рекомендации лидерам

- Избавьтесь от самомнения

- Будьте дзэн-мастером

- Будьте катализатором

- Будьте учителем и наставником

- Ставьте четкие цели

- Будьте честным

- Наблюдайте за удовлетворенностью команды

- Прочие рекомендации

- Люди подобны растениям

- Внутренняя и внешняя мотивация

- Заключение

- Глава 4. Работа с вредоносными людьми

- Что значит «вредоносный»

- Усиление вашей команды

- Обнаружение угрозы

- Неуважение к времени других людей

- Самомнение

- Вседозволенность

- Легкомысленность и невразумительность при общении

- Паранойя

- Перфекционизм

- Как нейтрализовать вред

- Перенаправляйте энергию перфекционистов

- Не кормите энергетических вампиров

- Не будьте излишне эмоциональным

- Ищите факты в обвинениях

- Проявляйте любезность к троллям

- Останавливайтесь вовремя

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

- Заключительная мысль

- Глава 5. Искусство корпоративной манипуляции

- Добро, зло и стратегии

- Идеал: как команда должна работать внутри компании

- Ваша жизнь под руководством идеального менеджера

- Действительность: что делать, если окружение препятствует вашему успеху

- Ваша жизнь под руководством плохого менеджера

- Офисный политикан

- Плохая организация

- Манипулирование организацией

- «Проще попросить прощения, чем разрешения»[47]

- Если нет дороги, проложите свою

- Учитесь карьерному росту

- Удача и «учет любезностей»

- Получите безопасную должность

- Заводите влиятельных друзей

- Как попросить занятого руководителя о чем угодно по электронной почте

- План Б: эвакуация

- Не все потеряно

- Глава 6. Пользователи – тоже люди

- Работа с общественным мнением

- Обращайте внимание на первое впечатление

- Меньше обещайте, больше создавайте

- С уважением относитесь к отраслевым аналитикам

- Насколько удобны в использовании ваши программы?

- Выбирайте свою аудиторию

- Доступен ли ваш продукт?

- Измеряйте использование, а не пользователей

- Скорость имеет значение

- Не пытайтесь изобрести универсальный продукт

- Не ленитесь

- Скрывайте сложность

- Управление взаимоотношениями с пользователями

- Не страдайте высокомерием

- Будьте терпеливым

- Вызывайте доверие и восхищение

- Помните о пользователях

- Эпилог

- Заключительная мысль

- Приложение. Что еще почитать

- notes

- 1

- 2

- 3

- 4

- 5

- 6

- 7

- 8

- 9

- 10

- 11

- 12

- 13

- 14

- 15

- 16

- 17

- 18

- 19

- 20

- 21

- 22

- 23

- 24

- 25

- 26

- 27

- 28

- 29

- 30

- 31

- 32

- 33

- 34

- 35

- 36

- 37

- 38

- 39

- 40

- 41

- 42

- 43

- 44

- 45

- 46

- 47

- 48

- 49

- 50

- 51

- 52

- 53

- 54

- 55

- 56

- 57

- 58

- 59

Брайан Фитцпатрик, Бен Коллинз-Сассмэн

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

– От Бена —

Моим родителям, несущим радость и надежду и научившим меня читать не только слова, но и людей.

– От Фитца —

Моему деду, Элвину «Нику» Фитцпатрику, научившему меня рассказывать истории и слушать их.

© ООО Издательство «Питер», 2014

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

©Электронная версия книги подготовлена компанией ЛитРес (www.litres.ru)

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

Отзывы о книге

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

Винт Серф (Vint Cerf), главный интернет-евангелист компании Google

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

Дин Кэмен (Dean Kamen), основатель компании DEKA Research

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

Брайан Беллендорф (Brian Behlendorf), технический директор Всемирного экономического форума

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

Питер Норвиг (Peter Norvig), директор по исследованиям компании Google

«Если вы стремитесь создать команду, сконцентрированную на разработке высококлассного ПО, то вам необходимо прочесть эту книгу. Бен и Фитц отлично перевели такие тонкие материи, как скромность, уважение и доверие, на язык тактических ориентировок, которые будут полезны самым скептически настроенным разработчикам».

Эрик Лант (Eric Lunt), технический директор и сооснователь компании BrightTag

«Отличная книга. Она посвящена самой сложной проблеме в программировании – работе с другими программистами. Я куплю по экземпляру этой книги для всех участников команды Samba».

Джереми Эллисон (Jeremy Allison), один из создателей Samba

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

Боб Ли (Bob Lee), технический директор компании Square

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

Грег Бэдрос (Greg J. Badros), вице-президент по продуктам и инжинирингу компании Facebook

«Программы состоят из людей. Команда, эффективно управляемая с помощью принципов, которые описаны в этой книге, способна превзойти любого разработчика-индивидуалиста в изобретательности, кодировании и достигаемых результатах. Программисты, занимайтесь саморазвитием!»

Джонатан Найтингейл (Johnathan Nightingale), старший директор по разработке Firefox компании Mozilla

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

Андриан Головатый (Adrian Holovaty), сооснователь Django

«Бен и Фитц рассказывают о том, что я применял на практике, но никогда не мог выразить словами».

Гвидо Ван Россум (Guido van Rossum), Великодушный Пожизненный Диктатор в Python

«Пожалуйста, пришлите один экземпляр на имя Пул-Хеннинг Кэмпа для разработчиков ядра FreeBSD, не позже марта 1994 г.»

Пул-Хеннинг Кэмп (Poul-Henning Kamp), участник проекта FreeBSD

«Бен и Фитц не восхваляют миф о программисте-одиночке, а уничтожают его. На его поминках они рассказывают истории, которые учат благоразумных инженеров обращаться с самой сложной системой, с которой они могут столкнуться, – группой людей.

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

Джон Толва (John Tolva), технический директор City of Chicago

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

Пьяу На (Piaw Na), автор книг «Руководство инженера стартапа Силиконовой долины» (An Engineer’s Guide to Silicon Valley Startups) и «Руководство инженерами стартапа» (Startup Engineering Management)

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

Я бы хотел иметь эту книгу, когда мне был 21 год, и обладать достаточным здравомыслием для того, чтобы усвоить ее».

Брайан О’Салливэн (Bryan O’Sullivan), Facebook

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

Брюс Джонсон (Bruce Johnson), технический директор компании Google

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

Клэй Джонсон (Clay Johnson), автор книги «Информационная диета» (The Information Diet)

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

Жизнерадостный подход к преодолению инженерных и человеческих проблем в технической команде изложен в увлекательной и лаконичной форме. Эта книга должна занимать достойное место на полке любого инженера».

Джонатан Лебланк (Jonathan Leblanc), ведущий евангелист технологий разработки компании X.Commerce

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

Карл Фогель (Karl Fogel), сооснователь компании Open Tech Strategies LLC

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

Роберт Кей (Robert Kaye), главный гик Musicbrainz

Цель этой книги

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

Благодарности

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

Спасибо сотрудникам издательства O’Reilly Media: Эди Фридману (Edie Freedman) за идею обложки, а также нашему бесстрашному редактору Мэри Треселер (Mary Treseler) – без ее энтузиазма, терпения и периодического подстегивания авторов эта книга не вышла бы в свет.

Спасибо Санни Брауну (Sunni Brown) и Эмберу Льюису (Amber Lewis) из sunnibrown.com за великолепные иллюстрации, оживившие книгу: работать с вами было сплошным удовольствием.

Спасибо нашим техническим рецензентам, которые высказали множество предложений, идей и поправок, сделавших эту книгу целостной: Дастину Бозвеллу (Dustin Boswell), Тревору Фаучеру (Trevor Foucher), Майклу Хангеру (Michael Hunger), Джонатану Лебланку (Jonathan LeBlanc), Пьяу На (Piaw Na) и Джеку Уэлчу (Jack Welch). Благодарим наших друзей и коллег, которые рецензировали эту книгу в процессе написания и обнаруживали наши грубые ошибки: Дейва Баума (Dave Baum), Мэтту Каттсу (Matt Cutts), Уилла Робинсона (Will Robinson) и Билла Дюэйна (Bill Duane). Спасибо друзьям, которые слушали нас, давали советы, и просто замечательным людям: Карлу Фогелю (Karl Fogel), Джиму Блэнди (Jim Blandy), Мэтту Брейтуэйту (Matt Braithwaite), Дэнни Берлину (Danny Berlin) и Крису Дибона (Chris DiBona). Также выражаем благодарность Линде Стоун (Linda Stone), Девитту Клинтону (DeWitt Clinton), Брюсу Джонсону (Bruce Johnson), Роланду МакГрату (Roland McGrath) и Эмиту Пателю (Amit Patel) за их идеи и предложения.

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

Особая благодарность нашим старшим наставникам и учителям, коллективную мудрость которых мы постарались отразить на страницах этой книги: Биллу Когрэну (Bill Coughran), Стиву Винтеру (Steve Vinter), Алану Ойстейсу (Alan Eustace), Стью Фельдману (Stu Feldman) и Эрику Шмидту (Eric Schmidt).

Отдельное спасибо Брайану Робинсону (Brian Robinson) и Ивонне Эллисон-Сэндлер (Yvonne Ellison-Sandler) за наставничество, руководство и попечительство.

Спасибо организации Apache Software Foundation за уделенное время, внимание к профессиональному сообществу и сотрудничество.

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

Значительная часть этой книги была придумана, спланирована и написана в замечательном, приветливом и уютном месте под названием Filter Cafe в прекрасном городе Чикаго.

От Фитца

Я очень благодарен своей жене Мари за огромное терпение, понимание и воодушевление – твоя человеческая проницательность и сопереживание всегда служат для меня источником вдохновения. Спасибо моей маме за постоянную поддержку и энтузиазм. Особая благодарность моей теще Рите Гамлер (Rita Gumler) за придуманную аналогию между людьми и растениями.

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

Наконец, я благодарю мистера Чарли МакГэннона (Charlie McGannon), научившего меня излагать свои мысли на бумаге на уроках английского в 11-м классе. В то время я считал четыре черновика эссе неоправданно большой работой, но теперь я знаю, что настоящие публикации требуют гораздо большего числа редакций!

От Бена

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

Фитцу: теперь, когда один из нас дописывает фразы, начатые другим, можно без преувеличения сказать, что мы похожи на семейную пару со стажем. Я никогда не думал, что делать доклады с кем-либо – столь увлекательное занятие, не говоря уже о совместном написании программ и книг. Жизнь предоставила нам поистине замечательные возможности! Спасибо, что ты так многому научил меня.

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

Об авторах

Брайан Фитцпатрик (Brian Fitzpatrick) возглавляет команды фронта освобождения данных (Data Liberation Front) и открытого инжиниринга (Transparent Engineering) в компании Google; в прошлом он руководил командами хостинга проектов (Project Hosting) и партнерской сети Google (Google Affiliate Network). Брайан – один из основателей технического офиса Google в Чикаго, а также идейный лидер и консультант проектов компании Google, посвященных открытым данным.

Бен Коллинз-Сассмэн (Ben Collins-Sussman) – один из первых разработчиков системы контроля версий Subversion и бывший руководитель команды, занимающейся хостингом проектов; в настоящее время он является менеджером команды инженеров партнерской сети Google. Бен один из основателей технического офиса Google в Чикаго; кроме того, он перенес систему Subversion на платформу Bigtable компании Google.

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу электронной почты comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства http://www.piter.com вы найдете подробную информацию о наших книгах.

Введение

Инженерное искусство просто. Сложность – в людях.

Билл Когрэн (Bill Coughran), бывший старший вице-президент по инжинирингу компании Google

Жизнь полна неожиданных поворотов, и мы оба никогда не думали о том, что однажды напишем книгу о разработке ПО.

Как и многие компьютерные гики, мы поняли, что наше хобби и страсть – работа с компьютерами – отличный способ заработать на жизнь после колледжа. В середине 1990-х мы, подобно большинству фанатиков-программистов, собирали персональные компьютеры из комплектующих, устанавливали предварительные версии Linux с дискет и учились администрировать Unix-машины. Мы работали системными администраторами, а на заре эпохи «дот-комов» – программистами в небольших компаниях. Когда пузырь «дот-комов» лопнул, мы обосновались в выживших фирмах Силиконовой долины (вроде Apple), а затем были приглашены в стартап-компанию CollabNet в качестве штатных сотрудников для работы над Subversion – системой контроля версий с открытым кодом.

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

В 2005-м мы открыли технический офис Google в Чикаго и продолжили программистскую карьеру. В то время мы уже были активно вовлечены в мир открытого кода; мы не только работали над системой Subversion, но и участвовали в сообществе Apache Software Foundation (ASF). Мы перенесли Subversion в инфраструктуру BigTable, разработанную Google, и запустили службу хостинга проектов с открытым кодом (аналогичную SourceForge) под флагом Google Code. Мы начали посещать конференции для разработчиков, а затем и выступать на них – OSCON, ApacheCon, PyCon и, наконец, Google I/O. Работая в обеих корпорациях и занимаясь проектами с открытым кодом, мы незаметно собрали кладезь знаний и историй о том, как работают настоящие команды разработчиков ПО. Серия забавных докладов о неэффективных процессах разработки («Худшие практики Subversion») в конечном счете превратилась в выступления о защите команд от деструктивно настроенных людей («Как избавить проект от вредоносных участников»). Все большие и большие толпы людей собирались на наших презентациях, которые больше напоминали сеансы групповой терапии для разработчиков. Каждый участник осознавал свою причастность к проблемам, о которых мы рассказывали, и хотел поделиться ими с группой.

Спустя шесть лет в нашем арсенале было множество докладов о социальных проблемах разработки ПО, проходивших исключительно в переполненных залах. Мэри Треселер, редактор издательства O’Reilly Media, рекомендовала нам оформить эти доклады в виде книги. Остальное – достояние истории.

Если вы хотите делать отличные программы, то эта книга – для вас

Для кого предназначена эта книга

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

• читатель работает в команде программистов, например принимает участие в проекте с открытым исходным кодом;

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

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

Внимание: эта книга не является техническим пособием

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

В этой книге вы не найдете ничего подобного.

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

Мы хотели бы сделать еще пару оговорок. Как мы обычно говорим на выступлениях, «изложенная информация является исключительно нашим мнением, основанным на личном опыте. Если вы не согласны с ним, то милости просим выступить с собственным докладом». Как и на устных выступлениях, мы приветствуем любые дискуссии, которые могут возникнуть вокруг тем, представленных в этой книге. Мы рады обсудить с читателями отзывы, исправления, мнения и разногласия. С нами можно связаться через сайт http://www.benandfitz.com/. Содержимое этой книги отражает наш личный «боевой» опыт и уроки, извлеченные из многочисленных ошибок.

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

Эта книга о том, чему не учат в вузах

Большинство известных нам программистов потратило от 4 до 10 лет на обучение компьютерным технологиям и программированию. На момент написания этой книги мы не знаем ни одного курса,[1] обучающего студентов навыкам общения и совместной работы в команде или компании. Конечно, во время учебы большинству студентов приходится хотя бы однажды участвовать в групповом проекте, но обучать человека методам успешной работы с другими людьми и принуждать его к командной работе – совершенно разные вещи. Для большинства студентов такой опыт заканчивается разочарованием.

Ключевая идея книги

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

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

Глава 1. Миф о гениальном программисте

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

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

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

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

Помогите мне спрятать свой код!

Мы много раз выступали на конференциях по программированию за последние шесть лет. Будучи участниками первого состава команды, которая запустила службу хостинга проектов с открытым кодом в поисковой системе Google в далеком 2006 году, мы получали много вопросов и пожеланий, связанных с нашим продуктом. Вот несколько типичных вопросов и пожеланий середины 2008 года:

Создайте, пожалуйста, возможность скрытия определенных ветвей кода в Subversion на Google Code.

Сделайте так, чтобы было можно «спрятать» проект с открытым кодом в начале работы над ним и опубликовать его в уже готовом виде.

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

Общая тема в этих запросах очевидна, не правда ли?

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

Миф о гении

Для начала скажем прямо: мы не поклонники спорта. Когда наши жены ликуют во время просмотра бейсбольных или футбольных матчей по телевизору, мы чешем затылки, недоумевая по поводу такого накала страстей. Тем не менее в 1990-е годы мы были свидетелями чемпионатов с участием «Chicago Bulls» (это баскетбольная команда, к слову). В то время мы оба жили в Чикаго, и национальные СМИ на протяжении многих лет были наполнены статьями об этой удивительной команде.

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

Программисты подчиняются тому же инстинкту – искать идолов и поклоняться им. Линус Торвальдс, Ричард Столлмэн, Билл Гейтс – все это герои, изменившие мир своими подвигами. Линус ведь создал Linux своими руками, не так ли?

Избегайте естественного инстинкта идолизации вещей

На самом же деле Линус написал лишь прототип Unix-подобного ядра и опубликовал его в списке рассылки. Это была непростая задача, и ее решение, безусловно, впечатляет, однако это всего лишь верхушка айсберга. Операционная система Linux разрабатывалась сотнями квалифицированных людей. Настоящее достижение Линуса в том, что он руководил этими людьми и координировал их работу; Linux же – блестящий результат их коллективного труда (сам Unix был создан небольшой группой специалистов Bell Labs, а не исключительно усилиями Кена Томпсона и Дэнниса Ричи).

Продолжим рассуждение: являются ли все программы Free Software Foundation результатом творчества исключительно Столлмэна? Он написал первое поколение Emacs, однако сотни других людей отвечали за создание bash, цепочки инструментов GCC и других программ, работающих на Linux. Стив Джобс руководил целой командой, создавшей Macintosh; главное достижение Билла Гейтса, известного автора интерпретатора BASIC для первых домашних компьютеров, заключается в создании успешной компании вокруг MS-DOS. Тем не менее все эти люди стали лидерами и символами своих коллективных достижений.

А как на счет Майкла Джордана?

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

Так почему же во всех этих историях мы постоянно идолизируем одного человека? Почему люди покупают продукты, рекламируемые знаменитостями? Почему мы хотим купить платье как у Мишель Обама или кроссовки как у Майкла Джордана? Знаменитость всегда на первом месте. Естественный инстинкт людей – искать лидеров и ролевые модели, идолизировать их и пытаться подражать им. Для вдохновения всем нам нужны герои, и такие герои есть и в мире программирования. Феномен «знаменитого технаря» уже почти стал частью мифологии. Мы все хотим создать нечто способное изменить мир, как Linux, или разработать очередной выдающийся язык программирования.

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

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

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

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

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

Мы знаем, о чем вы сейчас думаете: «Ну и что? Разве нельзя дать людям возможность работать так, как они хотят?» На самом деле нет. Мы утверждаем, что в этом случае вы поступаете неправильно, и это важно. Попробуем объяснить, почему.

Скрываться вредно

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

Откуда вы знаете, правильным ли путем идете?

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

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

Работа в изоляции приводит к разочарованию

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

Демонстрация результатов работы на ее ранних стадиях не только проверит идеи и предотвратит ваши ошибки. Но и увеличит то, что мы называем автобус-фактором проекта.

Автобус-фактор (сущ.): число участников проекта, которые должны быть сбиты автобусом, чтобы проект потерпел окончательный крах.

Каков автобус-фактор вашей команды?

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

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

Вот еще одна аналогия: задумайтесь о том, как вы работаете с компилятором. Создавая большую программу, нажимаете ли вы кнопку «компилировать» в первый раз через несколько дней или недель написания кода, когда уверены в том, что все готово и идеально? Разумеется, нет. Представьте, какая неудача ожидает вас при попытке скомпилировать 50 тысяч строк кода с нуля! Как программисты, мы лучше всего работаем в коротких циклах обратной связи: пишем новую функцию и компилируем, добавляем тест и компилируем, реорганизуем код и компилируем. Сгенерировав код, мы исправляем ошибки и опечатки как можно раньше. Компилятор подстраховывает нас на каждом маленьком шаге; некоторые среды разработки способны выполнять компиляцию в то время, когда мы набираем код. Таким способом мы поддерживаем высокое качество кода и гарантируем корректную и поступательную разработку нашего ПО.

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

Инженер и офис

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

Мы полагаем, что большинству инженеров не только необязательно, а опасно работать в отдельной комнате.[2] Сегодня ПО разрабатывается коллективами, а не отдельными людьми, и постоянная оперативная связь разработчика с коллегами важнее, чем непрерывное подключение к Интернету. Можно работать хоть 24 часа в сутки, но двигаясь в неверном направлении, вы просто теряете время. Зайдите в офис любой быстроразвивающейся высокотехнологичной компании, созданной в XXI веке, и вы увидите, что инженеры сидят группами в кабинках или за общими столами; случаи, когда инженеры изолированы друг от друга в отдельных кабинетах, встречаются редко.

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

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

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

Итак, наши рассуждения сводятся к следующему: работа в одиночку более рискованна, чем работа в команде. Опасаясь, что кто-то может украсть вашу идею или усомниться в вашем интеллекте, не забывайте опасаться потерять кучу времени, работая в неправильном направлении.

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

Не вносите свой вклад в эту печальную статистику.

Все дело в команде

Итак, давайте остановимся и соберемся с мыслями.

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

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

Сформулируем эту мысль проще:

Разработка программного обеспечения – это командный вид спорта.

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

Помните, что разработка ПО – это командный вид спорта

Недостаточно быть блестящим одиночкой, запертым в собственной «пещере». Вы не измените мир и не поразите воображение миллионов пользователей компьютеров своим секретным изобретением. Вам необходимо работать с другими людьми. Рассказывайте о своих идеях. Трудитесь вместе с другими людьми. Учитесь у коллег. Создайте первоклассную команду!

Сколько вы можете назвать успешных и популярных программ, созданных одним-единственным человеком? Некоторые приведут в пример программу LaTeX, однако ее едва ли можно назвать широко используемой, если только не считать, что люди, пишущие научные работы, составляют статистически значимую часть всех пользователей ПК!

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

Три кита

Итак, мы сформулировали основную мысль о командной работе. Если командная работа – лучший способ разработки отличного ПО, то как создать (или найти) отличную команду?

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

Скромность

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

Уважение

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

Доверие

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

Фактически наш главный тезис напрямую базируется на этих «трех китах»:

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

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

Будучи уверенными, что эти принципы важны, мы положили их в основу нашей книги.

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

В главе 2 мы рассматриваем сложности построения команды, в основе которой лежат «три кита». Следующий важный шаг к успеху – формирование командной культуры: это та самая «команда мечты», о которой мы уже говорили.

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

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

Усвойте принцип скромности, уважения и доверия, чтобы войти в коллективную нирвану

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

Давайте сделаем небольшую паузу.

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

Вот отрывок из известной лекции Ричарда Хэмминга (Richard Hamming):[4]

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

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

Скромность, уважение и доверие на практике

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

Избавьтесь от самомнения

Это простое пожелание человеку, не страдающему излишней скромностью, изменить свою позицию. Никто не хочет работать с лицом, которое постоянно ведет себя так, как будто оно – самая важная персона в комнате. Даже если вы знаете, что являетесь самым умным среди спорящих, не бросайте свою убежденность людям в лицо. Например, испытываете ли вы постоянное желание вставлять первое или последнее слово по каждому поводу? Хочется ли вам комментировать каждую деталь предложения или обсуждения? Знаете ли вы людей, которые любят так поступать?

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

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

Джон Тьюки почти всегда носил очень простую одежду. Он ходил в пафосные офисы, и проходило немало времени, пока его собеседник понимал, что перед ним важная персона, которую следует слушать с вниманием. Джон долго преодолевал в себе проявление скромности. Это пустая трата сил! Я не говорю, что вам следует подчиняться правилам; я лишь утверждаю, что такое поведение поможет вам достичь значительных успехов. Если вы собираетесь искать способы отстоять свое эго («я сделаю так, как считаю нужным»), то вы платите в течение всей вашей профессиональной карьеры небольшую постоянную цену, которая за вашу жизнь превращается в огромное количество ненужных проблем. […] Если вы понимаете, что вам нужно использовать систему, и изучаете способы заставить систему работать на вас, то вы учитесь адаптировать систему к вашим желаниям. Иначе вы постоянно боретесь с ней на маленькой, необъявленной войне, длящейся всю вашу жизнь.

Учитесь критиковать и быть критикуемым

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Будьте открытым для внешнего влияния

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

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

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

Честность и скромность – не плоды воображения

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

Дальнейшие шаги

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

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

Глава 2. Формирование высокой командной культуры

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

Что такое культура?

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

Вам нужна хорошая закваска

Если вы когда-либо пробовали великолепный хлеб на закваске и общались с тем, кто умеет его выпекать, то вы знаете, что основным ингредиентом такого хлеба является закваска, содержащая дрожжи и молочнокислые бактерии, которые питаются углеводами и водой. Хлеб поднимается на дрожжах, а бактерии придают ему характерный замечательный аромат. Человечество знает много вариантов заквасок, применяемых в хлебопечении, – одни создают более приятный аромат, чем другие, и когда пекарь находит закваску (то есть смесь бактериальной культуры и дрожжей), дающую лучший аромат, он стремится поддерживать и выращивать именно эту культуру, подпитывая ее мукой и водой. Затем пекарь добавляет закваску при приготовлении теста, и – ура! – у него получается отличный хлеб! Эта технология работает потому, что культура в закваске не только создает требуемый вкус, но и обладает достаточной силой для того, чтобы победить другие, «дикие» виды дрожжей и бактерий, присутствующие в ингредиентах для приготовления хлеба и воздухе пекарни.

Благодаря хорошей закваске новички усваивают вашу культуру

Культура вашей команды очень похожа на хорошую буханку хлеба: закваска (основатели команды) прививает культуру тесту (новичкам), и с ростом дрожжей и бактерий (участников вашей команды) получается отличная буханка хлеба (ваша команда). Если у вас сильная закваска, то, скорее всего, она победит нежелательные «дикие сорта» культур, которые привносит с собой новый участник команды.[6] Если же закваска слабая, то ваша команда уязвима для неизвестных штаммов культур, приносимых новичками. Неизвестные культуры приводят к непредсказуемым результатам, поэтому проще начинать с закваски, которую вы знаете.

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

Элементы, составляющие командную культуру, очень разнообразны. Некоторые из них непосредственно касаются написания ПО – например, рецензирование программного кода, разработка на основе тестирования и создание хорошей проектной документации перед началом создания больших объемов кода. Некоторые элементы ориентированы на людей: например, выходы на ланч в определенный ресторан по четвергам или выпивка в любимом баре по пятницам. Какие-то элементы могут показаться глупыми или нелепыми внешнему наблюдателю: например, технический офис Google в Питтсбурге находился рядом с железнодорожными путями, по которым ходили товарные поезда, и каждый раз, когда поезд проходил мимо (а это, как вы знаете, сопровождается сильным шумом), все сотрудники вскакивали с мест и кидались друг в друга дротиками.[7] Все эти вещи образуют командную культуру и влияют на ее продуктивность и способность привлекать и удерживать хороших участников.

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

Зачем заботиться о культуре?

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

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

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

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

Мы многократно наблюдали культуры с самоотбором в организации Apache Software Foundation. Множество команд разработчиков, работающих в ней, объединены в сообщества и сотрудничают на принципах консолидации. Множество новичков появлялись в списке рассылки и своим безразличным или агрессивным поведением нарушали правила, принятые в командной культуре. Участники сообщества обычно пытались обучить их (иногда деликатно, иногда не вполне), и если они не переставали игнорировать принципы работы ASF, то, как правило, отправлялись восвояси в поисках более подходящего проекта.

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

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

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

Культура и люди

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

А чтобы в вашей команде работали замечательные инженеры, нужно сначала нанять их! Возможно, это звучит странно, но большинство первоклассных инженеров хочет работать в командах с другими первоклассными инженерами. Многие передовые инженеры, которых мы знаем, тянутся к командам, где у них есть возможность учиться у мастеров своего дела.[9] Как же привлечь таких инженеров?

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

Многие, услышав про команду людей, которыми движет согласие, немедленно представляют себе лагерь хиппи, распевающих «кумбайя» у огня и никогда не принимающих никаких решений и действий, однако этот стереотип больше относится к неработоспособной команде, нежели к консолидированной. Консенсус – это состояние, в котором каждый испытывает сильное чувство сопричастности и ответственности за успех проекта, а лидеры прислушиваются к своей команде (с акцентом на составляющей «уважение»). Это означает, что иногда для успеха необходимо долго обсуждать и обдумывать продукт, а иногда вся команда понимает, что ей нужно двигаться быстрее. Во втором случае участники могут прийти к соглашению о том, чтобы поручить принятие повседневных рутинных решений одному или нескольким руководителям команды.[10] Чтобы это произошло, вся команда должна прийти к согласию относительно своей миссии, и, хотите – верьте, хотите – нет, ключом к этому является разработка формулировки миссии команды (более подробно о ней – далее в этой главе).

Не менее важным аспектом, кроме процесса принятия решений, является и манера обращения участников друг с другом, поскольку она выполняет функцию самоотбора в большей степени, чем что-либо другое. Если среди участников вашей команды принято тыкать пальцем в грудь и кричать друг на друга, то вам удастся привлечь (и удержать) только людей агрессивных поведенческих типов, которые естественно чувствуют себя в среде, состоящей из сильных индивидуальных эго (большинство известных нам женщин считают такую среду особенно отталкивающей). Если вы создадите культуру скромности, уважения и доверия, где участники команды вежливы друг с другом и прилагают усилия, для того чтобы сделать критику конструктивной, вы не только привлечете значительно большее количество людей, но и вложите гораздо больше энергии в написание ПО. Наличие сильного командного эго[11] является благом; индивидуальные эго, заслоняющие команду, – путь к катастрофе. Мы обсудим, как избежать такой ситуации, в главе 4.

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

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

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

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

Коммуникационные шаблоны успешных культур

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

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

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

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

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

Высокоуровневая синхронизация

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

Формулирование миссии (только не это!)

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

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

Как ни странно, я еще не встретил никого, кто бы с почтением относился к этой компании!

Вот еще один пример миссии другой крупной корпорации:

Предоставление решений в реальном времени для удовлетворения потребностей наших клиентов.

Что это вообще значит? Данная фраза может иметь абсолютно любой смысл; даже если бы мы работали в этой компании, и то не смогли бы понять, какая деятельность в ней важнее – написать программу, починить протекающую трубу или доставить пиццу. Из-за такой двусмысленности формулировки миссий имеют дурную репутацию.

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

Несколько лет назад, когда компания Google решила перевести разработку Google Web Toolkit (GWT) в проект с открытым исходным кодом, мы выступили в роли наставников команды. Мы рассказали о многочисленных различиях разработки ПО с открытыми и закрытыми кодами, уделив особое внимание сложностям проектирования, обсуждения и написания ПО в обстановке, где каждый может высказать свое мнение, предложить патч или подвергнуть критике самый незначительный аспект вашего продукта.[14] Рассмотрев эти проблемы, мы сказали участникам команды, что им нужно сформулировать свою миссию, чтобы в общих словах объяснять другим людям цели их продукта (и чего они собираются избежать).

Одни инженеры проигнорировали наше предложение по причинам, упомянутым ранее, однако другие проявили к нему интерес, и было похоже, что руководитель группы посчитал идею удачной. Когда мы сели за написание миссии, начались активные дебаты об ее содержании, сущности и стиле. После многочисленных дискуссий (и нескольких дополнительных встреч) команда не только прекрасно и лаконично сформулировала свою миссию, но и создала целый документ под названием «Как улучшить GWT» (Making GWT Better),[15] в котором объяснила смысл каждой фразы миссии. Участники команды даже включили в этот документ раздел, в котором описывались антицели проекта. Вот как выглядит формулировка их миссии:

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

В этом предложении содержится огромный смысл, и мы считаем, что это прекрасный пример формулировки миссии: он включает как направление деятельности (улучшить удобство работы… дав разработчикам возможность), так и ограничение масштаба (инструменты Java). Через несколько лет мы обедали с руководителем этой команды, и Фитц поблагодарил его за поддержку наших усилий, приложенных к формулированию миссии команды. Он ответил, что посчитал эту затею пустой тратой времени, когда мы в первый раз предложили ее, однако начав обсуждать ее с командой, он открыл для себя то, чего не знал прежде: между его ведущими инженерами были разногласия по поводу направления развития продукта!

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

Формулировка миссии помогает вашей команде выявить несогласия и договориться

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

Эффективные собрания

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

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

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

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

Бесполезные собрания могут показаться пыткой

Собрания часто прерывают то, что многие называют «творческой работой» под влиянием статьи Пола Грэма (Paul Graham) «График творца и график менеджера» («Maker’s Schedule, Manager’s Schedule»).[16] Инженерам бывает трудно сконцентрироваться, если они постоянно прерывают работу для участия в совещаниях. Создайте в своем календаре блоки длительностью 3–4 часа с метками «занят» или «творческая работа» и занимайтесь делом. Назначая встречу, постарайтесь выбрать для нее время рядом с естественным перерывом в рабочем дне, например до/после обеда или в конце дня. В компании Google существует старая и, к сожалению, часто игнорируемая традиция «четвергов без совещаний»,[17] которая освобождает время для завершения работ. Это хороший шаг к тому, чтобы выделять 20–30 часов для «творческой работы» на более крупных тайм-фреймах.

Вот пять правил проведения совещания

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

• Составляйте план и раздавайте его до начала совещания.

• Если цели совещания достигнуты, завершайте его раньше срока.

• Во время совещания придерживайтесь составленного плана.

• Старайтесь назначить совещание близко к «точкам прерывания» рабочего дня (таким как обед или окончание дня).

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

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

Ведущий собрания должен быть ведущим, а не ведомым, и без колебаний (хотя и мягко) прерывать тех, кто отклоняется от темы или, еще хуже, пытается диалог превратить в монолог. Это и непросто, но оправданно. И что важнее всего, не бойтесь закончить совещание раньше, если все запланированные вопросы будут решены.

Работа с «географически сложными» командами

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

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

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

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

Проектная документация

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

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

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

Текущие обсуждения

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

Списки рассылки

Мы не знаем ни одной команды, которая разработала бы ПО без хотя бы одного списка рассылки, однако есть несколько аспектов, с помощью которых вы можете сделать списки рассылки более полезными.

Во многих крупных успешных проектах используются отдельные списки рассылки, посвященные разработке, анализу программного кода, дискуссиям пользователей, объявлениям, оперативным сообщениям и административным вопросам. Иногда в небольших проектах предпринимаются попытки имитировать подобные системы в самом начале работы, когда на трех инженеров и двух пользователей приходится полдюжины списков рассылки. Это выглядит так же, как общение пяти людей в шести переговорных комнатах: обсуждения несогласованны, содержат много повторений, а комнаты большую часть времени пустуют. Начните с единственного списка и добавляйте новые списки только тогда, когда количество трафика в одном списке перестанет поддаваться управлению (обычно в этот момент участники списка начинают просить о пощаде). Уделите время формированию надлежащего этикета в обсуждениях по электронной почте – соблюдайте вежливость и предотвращайте атаки «агрессивного меньшинства».[18]

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

Онлайн-чаты

Онлайн-чат – удобный способ командной коммуникации, он позволяет быстро обратиться к коллеге, не отрывая его от работы (конечно, если его чат-приложение настроено так, чтобы не отвлекать его!). Этот инструмент хорош, когда команда выполняет какую-нибудь легкую работу вечером или на выходных или если один из участников отсутствует в офисе день или два. Персональный чат также полезен и имеет право быть одним из методов командной коммуникации, однако мы настоятельно рекомендуем командам использовать групповой чат.[19]

За несколько лет до того, как мгновенные сообщения получили широкую популярность, команды «сидели» в IRC-каналах (Internet Relay Chat, ретранслируемый интернет-чат) и большая часть их дискуссий проходила в групповом чате. Такое общение иногда становилось «шумным», а участники команды также могли легко уйти в персональный чат, если обсуждаемая ими тема не представляла интерес для других коллег. Тем не менее дискуссии, как правило, проходили «в присутствии» всей команды. Это позволяло другим людям подключаться к обсуждениям, молча наблюдать за ходом дискуссий или читать обсуждения, которые состоялись без их участия. Групповые чаты полезны не только потому, что дают начало предметным обсуждениям, но и потому, что помогают объединять даже географически распределенные команды. Часто новичок получает много информации, просто наблюдая за различными дискуссиями (или читая их позже) и необязательно участвуя в них.

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

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

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

Система отслеживания ошибок

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

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

Общение как часть разработки

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

Комментарии к исходным текстам

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

Комментарии наиболее полезны на уровне функций и методов, особенно как способ документирования API. Они должны не быть слишком подробными и подчиняться греческой максиме – «ничего лишнего». Потратьте время на выработку стиля написания комментариев и внедрите его в вашу команду; мы считаем, что единообразие стиля важнее, чем его суть.[20] Руководство по стилю программирования также должно объяснять, для чего оно существует и какие предписания содержит. Ниже представлено введение в руководство по стилю программирования на C++ компании Google:[21]

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

Цель настоящего руководства – компенсировать сложность языка С++ подробным описанием допустимых и недопустимых практик создания кода. Эти правила обеспечивают управляемость кодовой базы и в то же время позволяют программистам продуктивно использовать возможности С++. Под стилем (или читабельностью) мы понимаем соглашения, которым соответствует наш код на языке C++. Мы используем термин «стиль» не вполне корректно, поскольку эти соглашения охватывают гораздо больше аспектов, чем форматирование файлов с исходными текстами программ.

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

Еще одна проблема, решаемая данным руководством, – «раздутые» возможности C++. Язык C++ очень мощный и содержит в себе большое количество сложного функционала. Иногда мы ограничиваем и даже запрещаем использование некоторых возможностей языка, чтобы упростить код и избежать распространенных ошибок и проблем, связанных с этими возможностями. Настоящее руководство содержит список таких возможностей с пояснениями о причинах ввода ограничений на их использование.

Проекты с открытым кодом компании Google соответствуют требованиям настоящего руководства. Обращаем внимание на то, что данное руководство не является учебником по C++ – мы предполагаем, что читатель владеет этим языком.

Указание вашего имени в файлах с исходным кодом (проблема «ссылки на автора»)

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

# –

# Создан: Октябрь 2013 г., автор: Иван Петров <petrov@12345.ru>

# –

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

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

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

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

Обозначая свою «территорию», легко впасть в крайность

Требуйте рецензирования всего опубликованного кода

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

Создайте настоящие процедуры тестирования и выпуска

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

Все это касается кода

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

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

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

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

Глава 3. В каждой лодке должен быть капитан

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

Существуют десятки книг по менеджменту для профессиональных управленцев, однако эта глава предназначена для инженеров, которые оказались в роли лидера не по должности. Большинство инженеров боится становиться менеджерами, но ни одна команда не может работать без лидера. Мы пишем это не для того, чтобы убедить вас стать менеджером (хотя сегодня мы оба являемся техническими руководителями!), а чтобы объяснить, почему командам нужны лидеры, почему инженеры боятся становиться лидерами и как лучшие лидеры служат команде, используя принципы скромности, уважения и доверия. Мы постараемся дать рекомендации и антирекомендации лидерам, а также рассмотрим вопросы мотивации.

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

Природа не терпит пустоты

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

Каждому кораблю нужен капитан, а каждой команде – лидер

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

Устаревший подход к управлению

Современная концепция агрессивного менеджера была отчасти унаследована из военной иерархии и впоследствии приспособлена к условиям промышленной революции[23] (более 100 лет назад!). Повсюду стали возникать фабрики, которым требовались рабочие (как правило, неквалифицированные) для конвейерного производства. Этими рабочими управляли мастера, и, поскольку одних рабочих было легко заменить на других, крайне заинтересованных в получении работы, у мастеров-менеджеров не было причин хорошо обращаться с рабочими и улучшать условия их труда. Гуманность такого подхода спорна, однако он был эффективен на протяжении многих лет, пока рабочие выполняли только механические действия.

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

Такой стиль управления встречается и сегодня и даже в тех отраслях, где необходимо проявлять творческий подход к работе и решать нестандартные задачи (например, в инженерном деле!). При этом многочисленные исследования свидетельствуют, что метод «морковки и хлыста» неэффективен[24] и негативно отражается на продуктивности инженеров. Если конвейерного рабочего можно было обучить за несколько дней и уволить в любой момент, то инженеру могут потребоваться месяцы на то, чтобы освоиться в новой команде. В отличие от конвейерного рабочего, который должен был эффективно выполнять механические действия, инженеру нужны знания, время и пространство для размышлений и творчества.

Лидер – это новый менеджер

Большинство людей продолжает использовать термин «менеджер» в инженерной сфере, хотя он и утратил актуальность. Мы считаем, что на смену устаревшему понятию менеджера должно прийти понятие лидера. В последнее время слово «менеджер» обрело негативную окраску, поскольку само происхождение слова (от англ. manage – «управлять») стимулирует новых менеджеров управлять своими отчетами. Проводя аналогию, можно сказать, что менеджеры – это родители,[25] а инженеры – дети. С точки зрения концепции скромности, уважения и доверия эту ситуацию можно описать так: если менеджер проявляет доверие к своему подчиненному, то подчиненный чувствует необходимость оправдать это доверие. Лидер прокладывает путь команде и заботится о ее безопасности и благополучии, при этом обеспечивая потребности ее участников.

Одну из основных идей этой главы можно сформулировать следующим образом.

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

Менеджеры заботятся о качестве работы, лидеры прокладывают путь

Несколько лет назад Фитц взял в свою команду нового инженера – Джерри. Предыдущий менеджер (в другой компании) строго требовал, чтобы Джерри каждый день находился на своем рабочем месте с 9-ти до 17-ти, и при его отсутствии считал, что тот работает недостаточно (что, разумеется, было нелепым допущением). В свой первый рабочий день Джерри пришел к Фитцу в 16:40 и, извинившись, попросил разрешения уйти на 15 минут раньше, чтобы попасть на встречу, которую он не мог перенести. Фитц с улыбкой посмотрел на него и открыто сказал: «Послушай, если ты будешь работать по 75 часов в неделю,[26] то мне все равно, когда ты будешь уходить из офиса». Джерри в течение нескольких секунд сверлил Фитца взглядом, затем криво усмехнулся и ответил: «Отлично! Тогда у меня будет гораздо больше свободного времени, чем на моей предыдущей работе!» Фитц повел себя с Джерри как со взрослым; Джерри всегда успевал закончить работу вовремя, и Фитцу никогда не приходилось беспокоиться о том, на месте ли Джерри, поскольку за Джерри не требовалось присматривать.

Статус лидера необязательно означает, что вы несете ответственность абсолютно за все. Существуют разные виды лидерства, в том числе технические и личностные. В компании Google для лидеров команд предусмотрены две роли (и две должности): технический лидер и технический менеджер.[27] Технический лидер отвечает за техническое руководство процессом или его частью, а технический менеджер также отвечает за карьеру и удовлетворенность членов команды. Это позволяет инженерам, желающим сконцентрироваться на продукте, избежать управления людьми.

Единственное опасение состоит… во всем!

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

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

Не игнорируйте тот факт, что, будучи лидером, вы создаете нечто особенное

Еще одна важная причина, по которой люди не хотят становиться менеджерами, часто не произносится вслух, но вытекает из известного принципа Питера: «В иерархической системе любой работник поднимается до уровня своей некомпетентности». Большинству людей приходилось работать под руководством менеджеров, неспособных выполнять свою работу или попросту плохо управлявших людьми;[28] мы знаем инженеров, которые работали только с плохими менеджерами. Если в течение всей вашей карьеры вами руководили непрофессионалы, то откуда у вас возьмется желание быть менеджером? Почему вы должны стремиться занять место, для которого у вас нет навыков?

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

Лидер-слуга

Начинающие менеджеры подвержены «склерозу»: они забывают обо всех ужасных поступках, которые совершали по отношению к ним их прежние менеджеры, и начинают применять те же методы «управления» к своим подчиненным. Вот лишь некоторые симптомы этой болезни: микроменеджмент – игнорирование неэффективных сотрудников и найм непрофессионалов. Без надлежащего лечения эта болезнь способна погубить всю команду. Лучший совет из всех, что мы получили, впервые став техническими руководителями в Google, нам дал технический директор Стив Винтер (Steve Vinter). Он сказал: «главное – боритесь с желанием управлять». Одно из самых сильных стремлений новоиспеченного менеджера – активно «управлять» своими сотрудниками, поскольку именно этим и должен заниматься менеджер, не правда ли? Как правило, такое «управление» приводит к катастрофическим последствиям.

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

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

Антирекомендации

Перед тем как мы начнем изучать принципы работы успешных лидеров, рассмотрим несколько правил, которым не рекомендуется следовать, если вы хотите стать успешным лидером. Мы наблюдали, как этими правилами пользовались известные нам неэффективные руководители, а в некоторых случаях и мы сами.[29]

Нанимайте плохих профессионалов

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

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

Игнорируйте неэффективных сотрудников

Когда Фитц стал лидером команды в компании Google, ему пришлось вручать своим коллегам премиальные письма. Он усмехнулся и сказал своему руководителю: «Я обожаю быть техническим менеджером!» Менеджер Фитца, ветеран своего дела, тут же парировал: «Иногда ты можешь играть роль зубной феи, но в остальное время тебе приходится быть дантистом».

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

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

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

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

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

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

Игнорируйте социальные проблемы

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

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

Будьте другом каждому

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

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

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

Идите на компромиссы при найме

Стив Джобс однажды сказал: «Лучшие нанимают лучших; средние нанимают худших». Очень легко стать жертвой этого принципа, особенно при поспешном найме. Мы наблюдали следующий типичный подход: если команде требовалось нанять пять инженеров, то ее участники просматривали множество резюме, проводили собеседования с 40 или 50 кандидатами и выбирали из них пятерых фаворитов независимо от степени их соответствия требованиям вакансии. Это один из самых быстрых способов сформировать посредственную команду.

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

Обращайтесь с участниками команды как с детьми

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

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

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

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

Рекомендации лидерам

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

Некоторые их этих моделей мы успешно реализовали на практике; некоторым моделям следуют наши собственные лидеры.

Избавьтесь от самомнения

Мы говорили об этом в главе 1, изучая принципы скромности, уважения и доверия, однако избавление от самомнения особенно важно, если вы играете роль лидера-слуги. Этот принцип часто трактуют неправильно: лидер должен быть ковриком, об который его команда вытирает ноги. Мы полагаем, что есть тонкая грань между понятиями «быть скромным» и «позволять другим использовать себя», однако скромность – это не отсутствие уверенности. Можно быть уверенным в себе человеком, иметь собственные убеждения и при этом не являться эгоистом.

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

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

Если вам не приходится подвергать свою команду тотальному контролю, то можете быть уверены в том, что ваши квалифицированные исполнители знают детали своего дела лучше, чем вы. Вы можете формировать консенсус и помогать команде в выборе направления, но практические решения о том, как достичь поставленных целей, лучше всего принимают те, кто создает продукт. Это вызывает у членов команды не только сильное чувство сопричастности, но и ответственность за успех (или провал!) продукта. Хорошая команда, имеющая возможность задавать планку качества и производительности работы, достигнет более значительных результатов, чем команда, управляемая морковкой и хлыстом.

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

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

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

Будьте дзэн-мастером

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

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

Оммммммммм…

Вот пример: у Фитца был менеджер по имени Билл[30] с великолепным самообладанием. Какие бы форс-мажорные ситуации не случались, Билл никогда не поддавался панике. Он клал одну руку на грудь, опирался подбородком на другую руку и просил инженера, который, как правило, пребывал в полном ужасе, объяснить суть проблемы. Это успокаивало инженера и помогало ему сосредоточиться на разрешении ситуации вместо того, чтобы бегать кругами, не понимая, что происходит. Фитц в шутку говорил, что если бы кто-нибудь зашел к Биллу и сказал ему, что космические пришельцы атаковали 19 центров хранения данных, то он поинтересовался бы, почему они для ровного счета не уничтожили еще один.

Оцените соотношение размеров шестеренок в вашей организации

Этот пример иллюстрирует еще один прием дзэн-менеджмента: задавать вопросы. Если участник команды советуется с вами, это прекрасно, поскольку у вас наконец-то появляется шанс что-то исправить! Именно этим вы занимались много лет, прежде чем оказались в положении лидера. По этой причине вы бросаетесь решать проблему, однако в этой ситуации нужно действовать совсем иначе. Инженер, который просит у вас совета, не хочет, чтобы вы решали его проблему, ему требуется помощь в поиске решения, и простейший способ помочь ему – задать вопросы. При этом вы не должны уподобиться «волшебному» шару с номером 8 в бильярде, который мешает игре. Воспользуйтесь принципом скромности, уважения и доверия и помогите инженеру решить проблему, исследуя ее и задавая уточняющие вопросы. В результате инженер находит свое решение,[31] что укрепляет его чувство сопричастности и ответственности, о котором мы говорили ранее в этой главе. Независимо от того, знаете ли вы ответ на вопрос инженера, этот метод почти всегда вызывает у инженера ощущение, что этот ответ есть. Хитро, не так ли? Сократ гордился бы вами.

Будьте катализатором

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

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

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

Однажды команда Фитца пыталась в течение нескольких недель решить проблему с юридическим отделом компании. Когда их терпение иссякло, они рассказали об этой проблеме Фитцу, и он решил ее менее чем за два часа, поскольку мог войти в контакт с нужным человеком. В другой раз команде Бена были нужны ресурсы сервера, которые они никак не могли получить. К счастью, Бен общался с другими командами компании, и в тот же день ему удалось достать для своей команды то, что ей требовалось. Однажды инженер из команды Фитца ломал голову над непонятным фрагментом Java-кода, и хотя Фитц не был экспертом в Java, он нашел другого инженера, который четко указал причину проблемы. Чтобы устранять препятствия, вам не нужно знать ответы на все вопросы, но полезно знать людей, которые могут прийти на помощь. Знать подходящих людей зачастую ценнее, чем правильный ответ.

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

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

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

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

Будьте учителем и наставником

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

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

Ставьте четкие цели

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

Если вы хотите, чтобы телега (или продукт) двигалась на север как можно быстрее, то недопустимо, чтобы каждый участник команды тянул веревку, куда ему заблагорассудится, – вся команда должна тянуть телегу на север.

Все ли участники команды тянут телегу в одном направлении?

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

Будьте честным

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

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

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

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

Избегайте «сэндвича комплиментов»

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

Форма оценки или критики коллеги является ключевым фактором того, что ваше сообщение будет услышано и воспринято правильно. Если ваш собеседник займет оборонительную позицию, он будет думать не о том, как измениться, а о том, как контратаковать вас, чтобы продемонстрировать вашу неправоту. Однажды Бен был менеджером инженера (мы будем называть его Дином), который отличался большой категоричностью и спорил с остальными участниками команды по любому поводу, от миссии команды до расположения виджета на веб-странице. Дин спорил обо всем с одинаковой убежденностью и эмоциональностью, не оставляя без внимания ни один вопрос. Через несколько месяцев Бен встретился с Дином, чтобы поговорить о его агрессивном поведении. Если бы Бен сказал фразу вроде «Дин, прекрати вести себя как идиот», то Дин наверняка бы воспринял ее в штыки. Бен много размышлял о том, как объяснить Дину, что его действия наносят вред команде, и, наконец, придумал следующую метафору.

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

Эта история не только добавила юмор в сложившуюся ситуацию, но и дала возможность Бену объяснить Дину, как его «выпрыгивание перед поездами» мешало команде и впустую поглощало энергию Дина.

Наблюдайте за удовлетворенностью команды

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

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

Спустя некоторое время после того, как Фитц пришел в Google, он был приглашен на встречу с тогдашним главой компании Эриком Шмидтом (Eric Schmidt). Эрик спросил его: «Есть ли что-нибудь, чего тебе не хватает?» Этот вопрос стал полной неожиданностью для Фитца, который подготовил множество других тем для этой встречи. Тогда он сидел, уставившись перед собой бессмысленным взглядом, но к следующему разу он наверняка знал ответ на этот вопрос!

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

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

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

Прочие рекомендации

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

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

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

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

Иногда нужно гнать волну, даже если вам этого не хочется

Защищайте свою команду от хаоса. Соглашаясь на роль лидера, вы через некоторое время поймете, что за пределами вашей команды находится наполненный хаосом и неопределенностью (и даже безумием) мир, с которым вам никогда не приходилось сталкиваться в качестве исполнителя. Когда в 1990-е годы Фитц впервые стал менеджером (впоследствии он вернулся к исполнительской роли), он был поражен, насколько неопределенной и хаотично организованной оказалась его компания. Фитц спросил другого менеджера, почему прежде спокойную компанию вдруг стало лихорадить, в ответ тот разразился приступом смеха, вызванного наивностью Фитца: хаос существовал все время, но прежний менеджер защищал от него Фитца и его команду.

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

Хвалите команду за успехи. Иногда новоиспеченные лидеры уделяют так много внимания недоработкам членов своих команд, что забывают хвалить их с достаточной регулярностью. Указывая на ошибки, указывайте и на достижения, а о крупном успехе следует говорить не только его «виновнику», но и всей команде.

Наконец, есть принцип, которым пользуются эффективные лидеры, когда их предприимчивые подопечные стремятся к частым экспериментам: легко говорить «да», если можно без труда ликвидировать последствия. Если ваш инженер просит выделить ему день или два на то, чтобы освоить новый инструмент или библиотеку, способную ускорить разработку продукта, и сроки сдачи проекта это позволяют, соглашайтесь. Если же инженер хочет начать разработку продукта, который вам придется поддерживать в ближайшие 10 лет, подумайте, прежде чем ответить. Опытные лидеры хорошо чувствуют, насколько легко можно устранить последствия того или иного действия.

Люди подобны растениям

Жена Фитца была младшей из шести детей в семье, и перед ее матерью стояла сложная задача – воспитать шесть очень разных личностей, у каждой из которых были свои потребности. Фитц спросил свою тещу, как ей это удалось (понимаете, что мы у нее делали?), и она ответила, что дети подобны растениям. Одни похожи на кактусы: им не нужно много воды, зато требуется много солнца; другие напоминают африканскую фиалку и нуждаются в рассеянном свете и влажной почве, а третьи похожи на помидоры и прекрасно чувствуют себя при достаточном количестве удобрений.

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

Для развития инженерам нужны разные вещи

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

Взгляните на следующую матрицу.

Где находятся ваши сотрудники?

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

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

Внутренняя и внешняя мотивация

Существует два типа мотивации: внешняя, обусловленная воздействием внешних сил (например, денежной компенсации), и внутренняя, зависящая от личности человека. Дэн Пинк (Dan Pink) в своей книге «Драйв» (Drive)[34] объясняет, что сделать людей максимально продуктивными и довольными можно не за счет внешней мотивации (например, больших премий), а развивая их внутреннюю мотивацию. Дэн утверждает, что можно увеличить внутреннюю мотивацию, предоставив людям три вещи: независимость, мастерство и цель.[35]

Инженер обладает независимостью, если он может действовать самостоятельно без постоянного контроля с чьей-либо стороны.[36] Независимым инженерам можно указывать общее направление разработки продукта, но позволять им самим принимать решение о том, как достичь требуемого результата. Такой подход увеличивает мотивацию не только потому, что инженеры теснее связаны с продуктом (и, скорее всего, лучше вас знают, как создать его), но и потому, что сильнее ощущают свою причастность к нему. Чем больше их ставка на успех продукта, тем больше и заинтересованность в том, чтобы этот успех состоялся.

Концепция мастерства в первую очередь подразумевает, что инженеру нужно дать возможность получать новые навыки и совершенствовать существующие. Благоприятные условия для развития мастерства не только мотивируют инженеров, но и повышают их профессиональный уровень, что усиливает команду.[37] Инженерные навыки подобны лезвию ножа: вы можете потратить десятки тысяч долларов и заполучить в свою команду лучших инженеров, но если вы не затачиваете этот «нож» в течение многих лет, его лезвие затупится, и нож станет неэффективным, а иногда и вовсе бесполезным. Условия, позволяющие инженерам осваивать различные новые навыки и совершенствовать свое мастерство, делают их «хорошо заточенными», квалифицированными и эффективными.

Конечно, никакая независимость и мастерство не способны мотивировать человека, если его действия лишены смысла; по этой причине необходимо определить цель работы инженеров. Работая над важными продуктами, многие инженеры удалены от положительного эффекта, который эти продукты могут оказывать на их компанию, клиентов или даже планету. Даже если продукт имеет более скромный масштаб, вы можете мотивировать свою команду, найдя причину для их усилий и объяснив ее им. Если вам удастся придать работе смысл, вы увидите, что мотивация и эффективность команды значительно вырастут.[38] Мы знаем инженера, внимательно следящего за отзывами о своем продукте (небольшого масштаба), поступающими в компанию. Когда он узнает, что продукт оказался полезным лично для клиента или для его бизнеса, он немедленно пересылает сообщение инженерам. Это не только мотивирует команду, но и дает им пищу для размышлений, как сделать продукт еще лучше.

Заключение

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

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

Глава 4. Работа с вредоносными людьми

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

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

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

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

Что значит «вредоносный»

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

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

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

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

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

Усиление вашей команды

Вернемся к примеру с изготовлением теста для хлеба. Командная культура растет из «закваски»; единственным ключевым фактором, определяющим культуру команды в долгосрочной перспективе, является ее первоначальный состав. Если исходные участники команды не сформируют достаточно сильную культуру, то «сорняки» из других культур вытеснят ее. Если же основатели команды четко определят, какое поведение является приемлемым, а какое – нет, то их представления будут существовать в течение многих лет.

Мы оба долго занимались проектами с открытым кодом, и наш опыт хорошо согласуется с этой идеей. Проект Subversion, над которым мы работали дольше всего, был запущен маленькой группой людей. Они были очень скромными и испытывали друг к другу естественное уважение и доверие. За 11 с лишним лет существования проекта в нем сменилось как минимум три или четыре поколения участников (большинство основателей покинуло его), однако его культура осталась неизменной: все коллеги были доброжелательны, вежливы и ожидали такого же поведения от других. Эта культура сохранялась не только благодаря высоким стандартам, но характерному для культур свойству самоотбора. Приятные люди, как правило, тянутся к приятным обществам.

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

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

Защищайте свою команду от недопустимого поведения

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

• создайте понятную формулировку миссии, которая позволит вам сконцентрироваться как на целях, так и на антицелях;

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

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

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

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

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

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

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

Обнаружение угрозы

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

Особому риску подвергаются внимание и фокус команды.

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

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

Вы должны защищать внимание и фокус своей команды

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

Ниже перечислены некоторые типичные сигналы и нюансы, которые следует распознавать. Обнаруживая эти нюансы в поведении человека, мы устанавливаем для него «флаг вредоносности» – иначе говоря, отмечаем, что этот человек периодически ведет себя деструктивно и при общении с ним нужно соблюдать особую осторожность.

Неуважение к времени других людей

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

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

Самомнение

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

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

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

Вседозволенность

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

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

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

Легкомысленность и невразумительность при общении

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

Паранойя

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

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

Перфекционизм

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

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

Как нейтрализовать вред

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

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

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

Перенаправляйте энергию перфекционистов

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

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

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

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

Не кормите троллей

Не кормите энергетических вампиров

Это старая фраза из Usenet.[40] Она лучше всего действует против троллей – людей, которые намеренно провоцируют вас или вашу команду. Чем сильнее вы реагируете, тем больше вашей энергии тролль забирает себе и тем больше времени вы теряете. Обычно наилучшей реакцией на тролля является молчание. Как бы вам ни хотелось вставить меткую фразу, чтобы поставить его на место, сдержитесь. Когда никто не обращает внимания на тролля, он теряет интерес к ситуации и исчезает. Конечно, для того чтобы воздержаться от ответа, требуется проявить определенную силу воли. Сохраняйте хладнокровие!

Не будьте излишне эмоциональным

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

Ищите факты в обвинениях

Продолжаем тему минимализации количества эмоций; совет: ищите факты. Внимательно выслушайте жалобу. Дайте собеседнику кредит доверия, даже если он говорит агрессивно или грубо. Есть ли у него аргументы? Можно ли извлечь что-нибудь полезное из его опыта? Есть ли у него идея, заслуживающая обсуждения? Очень часто ответ на эти вопросы положительный: несмотря на саркастический тон собеседника, в его словах есть определенный смысл. Всегда возвращайте обсуждение в техническую плоскость.[41]

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

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

Проявляйте любезность к троллям

Можно развить описанный выше подход (оставаться хладнокровным и сосредоточенным на фактах) и отпугивать людей с помощью нарочитой любезности! Ниже приведена расшифровка разговора, в действительности состоявшегося в IRC-канале проекта Subversion:

harry: Subversion – ерунда. От нее никакой пользы, кроме вреда.

sussman: Если Вам нужна помощь, мы будем рады ее предоставить.

harry: Я хочу сохранить файлы в cvs. Или нет, я хочу пожаловаться. Мой коллега зациклился на Subversion и поэтому у него svn вместо cvs.

sussman: Скачайте svn-клиента и выгрузите его исходники.

harry: Я загружаю этот Subversion… можно ли установить Subversion через make install, как cvs? Конечно, нет. Он виноват больше, чем авторы subversion.

sussman: Если у *Вас* не получается сделать./configure; make; make install, то это еще не значит, что в архиве баг. Другие пользователи успешно проделывают то же самое с tar-файлом svn каждый день.

harry: Я не говорил, что это баг.

sussman: Вы думаете, что мы выложили бы архив, если бы в нем была такая серьезная ошибка?

harry: Я просто ворчу на этого придурка. Мне надо поставить expat или libxml. *вздыхает*

sussman: Такие вещи обычно предустановлены на большинстве систем.

sussman: Ваш коллега пользуется apache-сервером? Может быть, вам достаточно просто скачать бинарник.

harry: Я не знаю, он говорит – svn…

sussman: Каким дистрибутивом вы пользуетесь?

harry: FreeBSD

sussman: Перейдите в дерево портов и создайте порт.

harry: Вы разрушили мои планы… Я пришел сюда поспорить, но вы слишком дружелюбны и любезны.

sussman::-)

harry: Когда еще зайдешь в IRC и все кинутся тебе помогать? Эх…

– Harry ушел.

Останавливайтесь вовремя

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

Вернемся к истории с Чарли, доброжелательным философом, который постоянно делился своими мыслями через список рассылки Subversion. В какой-то момент мы проанализировали переписку и выяснили, что Чарли находится на третьем месте по частоте публикаций за последние два месяца; первые два места занимали ключевые участники проекта, и 70 % их писем были ответами, адресованными Чарли! Наша энергия и усилия тратились впустую, хотя сам Чарли не имел злого умысла. В конце концов, мы написали ему личное письмо, в котором попросили прекратить столь частые публикации в рассылке. Это было непросто, в основном потому, что он не понимал масштаба порождаемого им хаоса. Поскольку его поведение не претерпело значительных изменений, через несколько недель один из нас долго (и с еще большим трудом) общался с ним по телефону и попросил его вообще прекратить переписку. Чарли немедленно выполнил просьбу и, хотя был огорчен и сконфужен, проявил уважение к желанию команды. Все чувствовали себя немного виноватыми, поскольку Чарли не понимал, какой вред причинял, однако команда решила, что поступить таким образом будет правильно. Эта ситуация требовала деликатного разрешения, и мы активно использовали принцип скромности, уважения и доверия, чтобы уладить дело мирно и адекватно.

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

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

• Действительно ли вы верите в то, что проект получит выгоду в долгосрочной перспективе, несмотря на кратковременное снижение внимания и концентрации команды?

• Верите ли вы в то, что сможете извлечь пользу из разрешения конфликта?

Концентрируйтесь на важных вещах, а не на сиюминутных переживаниях

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

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

Грег Хадсон (Greg Hudson)

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

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

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

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

Заключительная мысль

В этой главе мы рассмотрели целый ряд типовых ситуаций, после изучения которых у вас может развиться сильный параноидальный синдром. Помните, что не весь мир состоит из идиотов. Как говорит Роберт Ханлон (Robert J. Hanlon), никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью. Вместо глупости мы предпочитаем говорить о безразличии, однако это не меняет смысл фразы.

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

Глава 5. Искусство корпоративной манипуляции

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

Добро, зло и стратегии

Большие компании – это сложные организмы. Чтобы совершить путешествие даже через лучшие из них, нужен GPS-навигатор, фонарик и большой запас еды.

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

Путешествие внутри компании – непростое приключение

Идеал: как команда должна работать внутри компании

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

Концентрируйтесь на вашей непосредственной работе…

Ваша жизнь под руководством идеального менеджера

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

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

…но делайте больше, чем от вас ожидают

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

Принимайте на себя риски и не бойтесь провала. В главах 3 и 4 мы много говорили о том, что важно идти на риски и не бояться неудач. При талантливом менеджере неудачи – это отличный способ приобретать опыт, определять границы возможного и невозможного и расширять эти границы с течением времени. Наш друг Стив Хейман (Steve Hayman), который часто ездит в командировки, говорит: «Если вы не опаздываете на самолет хотя бы раз в год, то вы приезжаете в аэропорт слишком рано». Это наблюдение прекрасно подходит к разработке ПО: если вы не терпите неудачу хотя бы раз в год, то вы недостаточно рискуете. Принимая на себя риски и дополнительную ответственность, вы демонстрируете, что способны на большее.

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

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

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

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

Эти приемы эффективны для идеальной организации, однако что делать, если ваша организация далека от совершенства?

Действительность: что делать, если окружение препятствует вашему успеху

Все счастливые семьи счастливы одинаково, каждая несчастливая семья несчастлива по-своему.

Лев Толстой. Анна Каренина[42]

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

Ваша жизнь под руководством плохого менеджера

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

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

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

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

Некоторые люди любят держать информацию в тайне

Требуя для себя роли посредника при обмене информацией и общении, плохие менеджеры склонны присваивать себе ваши успехи[44] и обвинять вас в неудачах (иногда и в своих собственных). Часто такие менеджеры рассматривают вас исключительно как способ продвижения себя любимого, они не заинтересованы в вашей карьере и еще меньше беспокоятся об удовлетворенности вашей команды.

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

Плохой менеджер контрастирует с лидером-слугой, которого мы обсуждали в главе 3: все, что его интересует, это какую пользу вы принесли ему в последнее время. А как насчет низкоэффективных участников вашей команды? Они не исчезают, если только не парализуют работу коллектива полностью: для плохого менеджера слишком обременительно иметь с ними дело.

Офисный политикан

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

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

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

Плохая организация

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

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

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

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

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

Случалось ли, что в компании к вам относились как к непослушному ребенку? Отсутствует ли у вас возможность посещать безобидные веб-сайты из-за слишком строгих ограничений корпоративного брандмауэра? Приходится ли вам тщательно документировать каждую минуту вашего рабочего дня в хронометражной карте? В некоторых компаниях продуктивность сотрудников измеряется бессмысленными (и, как правило, крайне неточными) методами вроде количества строк кода, написанного программистом за неделю.[46]

Обращаются ли с вами как с непослушным ребенком?

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

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

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

Манипулирование организацией

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

Морфеус

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

«Проще попросить прощения, чем разрешения»[47]

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

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

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

Когда кто-то из отдела маркетинга предложил Фитцу рассказать о своей команде Data Liberation руководству Google, Фитц поделился со своей референтной группой следующей идеей: дать руководству кусачки для болтов с логотипом Data Liberation и закрытые коробки с деньгами, ключи от которых находились внутри. Они рискнули и воплотили этот замысел в жизнь, и он отлично сработал. Когда через несколько лет Фитцу пришло в голову напечатать «деньги» на принтере, та же референтная группа посчитала идею слишком рискованной, и Фитц отказался от нее. Намереваясь действовать без разрешения, доверьтесь своей интуиции, однако дополнительное мнение доверенного источника имеет огромную ценность.

Если нет дороги, проложите свою

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

Если вы пытаетесь убедить кого-либо, то лучший способ повысить шансы на успех – найти людей, согласных с вами, и попросить их «вбросить» вашу идею (или предложение/просьбу) в разговор с этим человеком. Даже если ваша «мишень» полностью осознает, что происходит, то элементарная человеческая психология вынуждает его придать этой идее большее значение, поскольку она исходит из нескольких источников, а не только от вас.

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

Проложите новый путь

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

Учитесь карьерному росту

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

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

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

«Наступательная» и «оборонительная» работа

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

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

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

Теперь у нас есть удобное жизненное правило: команда никогда не должна тратить больше трети (максимум – половины) своего времени и энергии на «оборонительную» работу независимо от размера технического долга. Вложение большего количества времени в «оборонительную» работу – путь к политическому самоубийству.

Удача и «учет любезностей»

Хотите – верьте, хотите – нет, но в какой бы компании вы ни работали, не так уж сложно добиться в ней некоторых успехов. Ричард Уайзмен (Richard Wiseman), автор книги «Фактор удачи» (The Luck Factor),[50] описал эксперимент, который он провел для проверки способности людей видеть случайные возможности.[51]

Я раздал счастливым и несчастным людям газету, попросил их просмотреть ее и сказать мне, сколько в ней фотографий. Несчастным людям в среднем требовалось около двух минут для того, чтобы подсчитать количество фотографий, в то время как счастливые люди делали это за считанные секунды. Почему? Дело в том, что на второй странице газеты было напечатано сообщение: «Перестаньте считать. В этой газете 43 фотографии». Оно занимало половину страницы и было напечатано буквами высотой больше 5 см. Сообщение бросалось в глаза читающему, но несчастные люди, как правило, не замечали его, в то время как счастливые люди находили.

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

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

«Однажды… Я попрошу тебя помочь мне»

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

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

Получите безопасную должность

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

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

Чем выше положение вы можете занять в организации (как исполнитель или как менеджер), тем больше вы способны контролировать свою участь внутри компании. Если вы находитесь в комфортной для себя должности и при этом тратите небольшие усилия на карьерный рост, то вы делаете отличный вклад в свою удовлетворенность и безопасность в случае, если с вашей компанией или командой случится что-то неприятное. Наблюдайте за своими достижениями и используйте их для самооценки. Обновляйте свое резюме и передавайте его своему менеджеру или кадровому отделу.

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

Заводите влиятельных друзей

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

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

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

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

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

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

Как попросить занятого руководителя о чем угодно по электронной почте

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

Больше десяти лет назад, когда Фитц работал в компании Apple, он купил своей маме бракованный iMac и по совету своего коллеги послал «короткое» письмо Стиву Джобсу.[53] Это письмо вчерне демонстрирует, как следует обращаться за помощью к руководителю:

Date: Thu, 1 Feb 2001

To: sjobs@apple.com

Subject: Ужасное обслуживание нашего клиента – что делать?

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

Я купил своей маме iMac на последний День матери; она работает проректором школы Монтессори в Нью-Орлеане и на работе пользуется старым компьютером Macintosh. Она была очень рада и даже получила от школы средства на приобретение нескольких iMac для школьной лаборатории.

Тем не менее земляничный iMac, который я купил ей, оказался бракованным.

– в июле он заснул и больше не проснулся. Мама отнесла его авторизованному дилеру Apple, где ему диагностировали неисправность материнской платы и заменили ее.

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

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

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

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

Что я могу сделать, чтобы моя мама получила работающий iMac (кроме приобретения нового)?

С уважением,

Фитц

Меньше чем через 20 часов Фитцу позвонил кто-то из коллег Стива, а спустя две недели мама Фитца получила новый (и абсолютно исправный) iMac.

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

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

Мы называем этот метод «Три пункта и призыв к действию»; он значительно повышает вероятность того, что адресат, который не знает вас, отреагирует на ваше письмо с просьбой[54] или, как минимум, ответит на него, причем этот принцип распространяется на всех людей, а не только на руководителей.

Так должна выглядеть просьба о пони

Хорошее письмо, составленное в соответствии с принципом «Три пункта и призыв к действию», содержит не больше трех тезисов, описывающих проблему, и один – только один! – призыв к действию. Все! Ничего больше в письме быть не должно. Адресат должен иметь возможность легко переслать письмо дальше, а если оно будет длинным или в нем будет идти речь о четырех не связанных между собой вещах, то письмо потребует от адресата слишком большого умственного напряжения, и он удалит его. Тезисы должны состоять из коротких предложений (каждое из которых должно помещаться на одной строке без наложений), а призыв к действию следует формулировать максимально сжато.[55]

Ваше письмо должно быть написано в духе скромности, уважения и доверия: соблюдайте вежливость, почтительность, не допускайте грамматических ошибок и опечаток. Если вам необходимо включить в письмо дополнительную информацию или пояснения, поместите их в конец письма (после подписи) и пометьте словами «подробности» или «пояснения».

Возвращаясь к письму Фитца, отметим, что оно несколько многословно: если бы мы написали его сегодня, то оно выглядело бы так:

Date: Thu, 1 Feb 2001

To: sjobs@apple.com

Subject: Плохое обслуживание клиента – просим вашей помощи!

– Я купил iMac своей маме, школьному администратору. Она очень обрадовалась и даже получила средства на приобретение еще нескольких iMac для школьной лаборатории.

– В июле компания Apple заменила в iMac неисправную материнскую плату, а месяцем позже – аналоговую плату.

– В сентябре у iMac перестал корректно работать режим сна, а в декабре начались проблемы с монитором. В настоящее время он находится у дилера.

Моя мама дает всем своим знакомым крайне негативные отзывы об iMac, и никто из моих знакомых в Apple не знает, как разрешить эту ситуацию. Как мне получить для своей мамы исправный iMac?

С уважением,

Фитц

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

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

План Б: эвакуация

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

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

Контролируя будущее, вы становитесь значительно свободнее. Если вы изучите текущую ситуацию и убедитесь в том, что можете сменить работу, не исключено, что вы внезапно обнаружите, что стали добиваться значительно лучших результатов на текущей работе (при существенно меньшем стрессе), поскольку увольнение не представляет для вас угрозы! Ниже приведена публикация[56] из блога Чад Менг Тана (Chade-Meng Tan) – инженера, который долгое время работал в Google; она очень вдохновляет нас и влияет на то, как мы работаем.

Приносите пользу и ждите, когда вас уволят

Новые сотрудники Google (мы называем их «нуглерами») часто спрашивают меня, как я достигаю эффективности в работе. Я полушутя отвечаю, что очень просто: я делаю что-то полезное для Google и для мира, а затем сижу и жду, когда меня уволят. Если меня не увольняют, то мой труд принес пользу всем. Если же меня увольняют, то я неправильно выбрал работодателя. В любом случае я выигрываю; такова моя стратегия построения карьеры.

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

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

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

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

Не все потеряно

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

Глава 6. Пользователи – тоже люди

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

Начните с небольшой группы квалифицированных программистов. Сдабривайте команду прочной культурой скромности, доверия и уважения. Будьте руководителем-слугой, побуждайте своих инженеров к сотрудничеству и принимайте грамотные решения. Обеспечивайте команду водой, солнцем, указывайте ей направление роста и по необходимости повышайте внутреннюю мотивацию. Защищайте ее от негативных воздействий – деструктивных влияний (или сред), угрожающих ее культуре и возможности развиваться. Выпекайте при температуре 163 °C в течение полугода и в результате получите отличный софт. Все готово, не так ли?

Многие программисты на этом пункте останавливаются. Они написали прекрасную программу, довольны результатом и объявляют о своей победе.

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

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

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

Работа с общественным мнением

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

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

Почему эта идея так раздражает нас? Почему мы с содроганием думаем о менеджере по маркетингу?

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

Поскольку маркетинг для нас – это нечто искажающее истину, он противоречит инстинктивному стремлению инженера к меритократии. Мы убеждены, что всегда должен побеждать наилучший продукт. «Наилучший продукт» – это программа, которая объективно обладает самым высоким качеством и эффективностью, а не самой яркой рекламой на телеканале. Мы вновь и вновь разочаровываемся, когда видим, как терпят поражение превосходные технологии: многие убеждены, что Betamax был лучше, чем VHS, Laserdisc – лучше, чем DVD, а Lisp до сих пор является лучшим языком программирования (мы просто не можем не сказать об этом!). Даже в сфере инструментов для контроля версий среда Subversion завоевала корпоративный сегмент вопреки техническому превосходству более современных систем.

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

У нас для вас есть две новости – плохая и хорошая.

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

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

Не будьте таким, как он

Компания Apple – бесспорный мастер технологий, апеллирующих к эмоциям людей, которые не обладают техническими познаниями. Возвращаясь в 2012 год, спросим себя: имеет ли iPhone существенное превосходство над Android-телефоном? С точки зрения функционала они почти идентичны, однако если пользователь, не сведущий в технике, поверит в волшебство iPhone, то iPhone станет волшебным как минимум для него. Восприятие – это реальность, или, как мы говорили ранее, «девять десятых закона».

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

Обращайте внимание на первое впечатление

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

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

Меньше обещайте, больше создавайте

В этом вопросе не отдавайте всю власть маркетологам. Если пользователи интересуются функциями будущего продукта или датами его выходов, то по возможности высказывайте максимально консервативные оценки. Если маркетологи станут распространять слухи, то вы попадете в ситуацию, которая произошла с игрой «Дюк Нюкем навсегда» (Duke Nukem Forever), выпущенной с 15-летним опозданием. Если же ваша (более точная) информация будет появляться первой, то пользователи окажутся заинтригованными. Компания Google прекрасно владеет этим приемом; в ней намеренно применяется принцип: никогда не анонсировать возможности продуктов. Появление новых функций, как правило, становится приятным сюрпризом. Кроме того, такой подход упреждает внутрикорпоративные форс-мажоры, вызываемые необходимостью успеть выпустить продукт к нереальной, но уже объявленной дате. Выпуск продукта происходит тогда, когда он действительно готов к использованию.

С уважением относитесь к отраслевым аналитикам

Многие программисты ненавидят средства массовой информации, считая их всего лишь разновидностью маркетинга. Но когда представители отраслевых журналов или исследовательских фирм появляются на пороге, многие компании встречают их с распростертыми объятиями и делятся любой информацией. Общеизвестно, что хороший (или плохой) отзыв способен оказать решающее влияние на успех продукта у публики. Тем не менее такое влияние и почет вызывают раздражение у многих инженеров. Например, одно время участники сообщества Apache Software Foundation (ASF) имели проблемы в общении с аналитиками. Когда аналитик просил участников MSF поделиться с ним стандартными публикациями, описывающими их HTTPD-сервер Apache, ему, как правило, отвечали в духе «прочтите документацию на веб-сайте так, как это делают все». Хотя глубокая приверженность разработчиков ПО с открытым кодом к меритократии была удовлетворена, это негативно влияло на их восприятие публикой, в особенности корпоративными пользователями. В конечном счете PR-специалист ASF изменил подход ряда участников сообщества к аналитикам и научил их работать с ними более продуктивно. Пассивно-агрессивное противодействие системе, каким бы сильным оно ни было, не имеет смысла. С таким же успехом вы можете попросить ресторанного обозревателя убраться восвояси после интервью. Следует ли ставить обозревателя в привилегированное положение? Скорее всего, нет. Стоит ли из принципа демонстрировать ему свое негативное отношение? Тоже нет; этим вы навредите только себе. Выбирайте противников своего веса.

Насколько удобны в использовании ваши программы?

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

Если под успешным ПО понимать программы, которые с удовольствием используются большинством людей, то вам необходимо обратить особое внимание на свою аудиторию. У Google есть известный девиз: Концентрируйтесь на пользователе, и все остальное последует за этим.

Пользователь должен быть в центре вашего внимания

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

Потенциальные пользователи вашего ПО

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

Рассмотрим несколько важных способов фокусировки внимания на пользователях вашего программного продукта.

Выбирайте свою аудиторию

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

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

С другой стороны, распределенные системы контроля версий могут быть гораздо более сложными. Git и Mercurial – зрелые продукты с почти одинаковыми возможностями, хотя на момент написания этой книги Git пользуется огромной популярностью у самых квалифицированных программистов. Мы всегда отдавали предпочтение системе Mercurial, поскольку ее интерфейс проще. Mercurial очень близка к Subversion, стремится обеспечивать согласованный интерфейс, удобные команды и имена переключателей и скрывает детали своей реализации. Интерфейс Git, напротив, напоминает оголенную связку схем и проводов. Большинству пользователей необходимо разобраться во внутренней архитектуре Git просто для того, чтобы эффективно работать с ней! Многие Git знают «спасительные волшебные заклинания», но живут в постоянном страхе, что система уничтожит их работу, если они случайно совершат ошибку.

Насколько удобна в использовании система Subversion?

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

Но не забывайте, что Unix и Git – примеры отклонения от нормы. Они предназначены для сугубо технической аудитории, а большинство программных продуктов позволяют сдвинуть вертикальную линию намного левее. Это справедливо в отношении таких популярных программ, как Gmail, Facebook или операционной системы iOS компании Apple. В целом чем больше пользователей у вашего продукта, тем больше его успех (и прибыль компании!).

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

Насколько удобна в использовании система Git?

Доступен ли ваш продукт?

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

Чтобы проиллюстрировать данную мысль, представим себе популярные языки сценариев. Большинство программистов поддержит высказывание о том, что Perl, Python и Ruby «лучше», чем PHP. Они скажут, что программы на Perl/Python/Ruby легче читать и поддерживать в долгосрочной перспективе, для них существует много развитых библиотек и, кроме того, они надежнее и безопаснее работают в открытой Всемирной паутине. Тем не менее PHP значительно популярнее, по крайней мере при веб-разработке. Почему? Потому, что любой студент способен освоить его, скопировав сайт своего сокурсника. Ему не нужно читать книги, следовать длинным руководствам или изучать сложные паттерны программирования. Это способствует самообучению: достаточно начать разбираться с собственным сайтом и перенимать приемы использования PHP у своих коллег.

Можно привести еще один пример с текстовыми редакторами. Какой из них следует использовать программистам: Emacs или vi? Имеет ли это значение? На самом деле нет, но как выбрать? Вот реальная история: когда Бен впервые начал изучать Unix во время своей студенческой практики в 1990-х, он искал в нем текстовый редактор. Он открыл существующий файл, запустив vi, и испытал жестокое разочарование: у него получалось перемещаться внутри файла, но он не мог ничего напечатать! Конечно, пользователи vi знают, что для изменения файла требуется перейти в режим редактирования, но для новичка первый опыт может окончиться неудачей. Когда вместо этого Бен запустил Emacs, он смог сразу начать редактировать файл так же, как в знакомом ему текстовом редакторе DOS. Поскольку первые действия Emacs были в точности такими, к каким привык Бен, он с первой же минуты решил пользоваться Emacs. Эта причина явно недостаточна для того, чтобы предпочесть один продукт другому, но подобные вещи происходят постоянно! Первая минута пользования продуктом критически важна.

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

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

Прекрасный пример почти беспрепятственного доступа к программному продукту – веб-служба TripIt для управления путеводителями. Чтобы воспользоваться ей, достаточно просто переслать адреса электронной почты для подтверждения заказов, связанных с путешествиями (авиабилетов, отелей, аренды автомобилей и др.) в почтовый ящик plans@tripit.com. После этого можно пользоваться службой: она создает для вас временную учетную запись, считывает адреса электронной почты, создает красивую страницу с маршрутом и посылает вам электронное сообщение о том, что она готова к работе. Ее действия напоминают работу квалифицированного секретаря, который появляется мгновенно; при этом вам потребовалось всего лишь переслать несколько сообщений! Почти без усилий вы попадаете в систему и перемещаетесь по страницам сайта как ее постоянный пользователь. К этому моменту у вас появляется желание создать реальную учетную запись.

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

Измеряйте использование, а не пользователей

Оценивая размер пользовательской базы своего приложения и простоты его освоения, подумайте, как измерять использование приложения. Обратите внимание: мы имеем в виду именно использование, а не количество установок или зарегистрированных пользователей; вам нужно, чтобы как можно большее число людей пользовалось вашим продуктом, а не просто скачивало его. Часто разработчики говорят: «у моего продукта 3 миллиона скачиваний, а значит, и 3 миллиона счастливых пользователей». Стоп! Сколько человек из этих 3 миллионов действительно работает с вашим ПО? Именно это мы подразумеваем под использованием.

Приведем экстремальный пример: на скольких Unix-компьютерах установлена утилита ar? Почти на всех, в том числе во всех версиях Linux, Mac OS X, BSD и т. п. А сколько людей пользуется этой программой? Какое количество пользователей знают о ее существовании? Вот образец программы, миллионы копий которой установлены на компьютерах, но ее использование близко к нулю.

Многие компании (в том числе Google) прилагают много усилий для измерения использования своих программ. Часто использование измеряется в количестве времени, которое пользователь тратит на работу с программой в течение недели или месяца. Это важный показатель, он содержит правдивую информацию об успешности вашего приложения. Не обращайте внимание на счетчик скачиваний; придумайте вместо него способ измерения текущего использования вашего приложения. Это реальный индикатор популярности вашего ПО.

Скорость имеет значение

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

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

Реальная история от Google: однажды команда инженеров снизила задержку в службе Google Maps. Информация об этом не объявлялась и не публиковалась в блогах: внедрение новинки прошло в полной тайне. Тем не менее в течение первых двух дней уровень использования на графике активности подскочил вверх и остался на новом уровне. В этой ситуации на первый план выступил психологический аспект!

Изменение вовлеченности пользователей во времени

Если вы занимаетесь поддержкой веб-приложения, важны даже небольшие сокращения его задержки. Допустим, главная страница приложения загружается за 0,75 секунды; этого вполне достаточно, не так ли? Почти все пользователи будут удовлетворены такой скоростью, однако если вы сократите время загрузки до 0,25 секунды, то разница в полсекунды при каждой загрузке в совокупности станет очень заметной. Если у вашего приложения миллион пользователей, каждый из которых обращается к нему 20 раз в день, то вы сэкономите 116 лет пользовательского времени; экономьте время ваших пользователей! Снижение задержек – один из лучших способов повысить использование программы и удовлетворенность пользователей. Как говорят основатели Google, «скорость – это функция».

Не пытайтесь изобрести универсальный продукт

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

Для чего предназначен этот продукт?

Мы часто шутим по поводу устройств, рекламируемых в журналах: эй, посмотрите, вот походный фонарь – у него есть встроенный радио– и телеприемник, а также таймер, и будильник, и… Получается полная неразбериха. Представьте себе, что ваша программа – это нехитрый тостер. Умеет ли он готовить борщ? Безусловно, нет. Зато он готовит много востребованной еды, полезен почти любому человеку и не требует излишнего внимания. Будьте как этот тостер. Меньшее часто приводит к большему.

Не ленитесь

Остерегайтесь лени. Некоторые возразят, что лень – это добродетель программистов, поскольку она способствует автоматизации работы. С другой стороны, можно легко написать код, который вызовет у пользователей много проблем. Создание ПО, с которым пользователям легко работать, может оказаться малоприятным занятием для программиста. Концентрируйте усилия на пользователе, а не на том, что легко разработать. Если создание кода не вызывает у вас энтузиазма, запаситесь терпением.

Классическое проявление лени – предоставить пользователю слишком большое количество опций. В поколении продуктов Microsoft Office конца 1990-х появились панели кнопок, которые были удобны тем, что позволяли мгновенно получить доступ к любому пункту меню. Разработчики пользовательских интерфейсов любят шутить над этой идеей, утрируя ее.

Слишком большое количество опций сбивает с толку, создает неудобства и пугает пользователя. Существуют книги, в которых описываются проблемы слишком большого выбора.[57] Будьте внимательны даже к содержимому диалогового окна с настройками программы (знаете ли вы, что у популярного клиента электронной почты Eudora было 30 панелей с настройками?). Предлагая пользователю заполнить форму, гибко работайте с вводимыми данными: самостоятельно добавляйте разделительные символы, знаки пунктуации и тире. Не заставляйте пользователя заниматься синтаксическим разбором! Берегите его время. Ситуации, в которых программист имел возможность позаботиться, чтобы пользователю было легко и приятно, но не сделал этого, очевидны и вызывают раздражение.

Не демонстрируйте свою лень, показывая все опции одновременно

Скрывайте сложность

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

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

Снова обратимся к компании Apple. Дизайн ее продуктов легендарен, а одно из ее наилучших достижений – творческое решение проблемы управления музыкальными MP3-коллекциями. До появления iPod существовал ряд неуклюжих портативных устройств со встроенными средствами управления музыкой. Гениальность Apple в осознании того, что управлять MP3 на маленьком экране слишком сложно; по этой причине решение было перенесено на большой компьютер. Так появился iTunes; вы можете управлять музыкальной коллекцией с помощью компьютера с большим экраном, клавиатурой и мышью, а затем пользоваться iPod исключительно для воспроизведения. Это позволяет iPod быть простым и изящным устройством, а организация музыкальной коллекции больше не вызывает раздражения пользователей.

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

Основной замысел в том, что интерфейсы Apple и Google кажутся волшебными.[58] Всем разработчикам стоит стремиться к этой цели, поскольку она является ключом к удобству работы с программами.

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

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

Управление взаимоотношениями с пользователями

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

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

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

Больше всего пользователи хотят быть услышанными

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

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

Измерение числа пользователей вашего продукта

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

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

Удовлетворенность ваших пользователей во времени

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

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

Не страдайте высокомерием

Распространенное заблуждение, подпитывающее страх прямого контакта с пользователями, в том, что пользователи глупы. Они не пишут программы, поэтому ничего не понимают в них, верно? Когда вам, наконец, предоставляется возможность пообщаться с ними, постарайтесь не быть высокомерным. Хорошие пользовательские навыки не являются адекватным показателем общего уровня развития человека. Многие выдающиеся люди пользуются компьютером только как инструментом. Их не интересует отладка программ или диагностика проблем с применением научных методов. Большинство из нас не имеет понятия о том, как разбирать и чинить автомобили; считать ваших пользователей глупыми – то же самое, что считать глупым себя из-за того, что вы не можете собрать коробку передач и не интересуетесь диагностикой проблем со сцеплением. Машина – это черный ящик: вы просто ездите на ней. Для большинства людей компьютер (и ваши программы) тоже являются черным ящиком. Пользователи не хотят участвовать в анализе; им требуется, чтобы для них просто делали определенную работу. Это не имеет ничего общего с интеллектуальным уровнем! По умолчанию отношение к пользователям должно быть уважительным.

Будьте терпеливым

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

Ваш родитель: По-моему, мой компьютер тормозит из-за того, что закончилось место на диске.

Вы: Откуда ты знаешь? Ты проверял диск?

Ваш родитель: У меня на экране полно ярлыков, наверное, поэтому мне больше некуда скачивать электронную почту. Может быть, мне стоит удалить куки, чтобы освободить место, а? Кажется, в прошлый раз это сработало.

Вы: </facepalm>

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

У Фитца есть замечательная история про его бабушку, которая спросила его по телефону: «Брайан, нужен ли нам старый компьютер дедушки?» Фитц ответил отрицательно, поскольку это был очень старый Mac Classic без соединения с Интернетом и его было разумнее утилизировать. Бабушка сказала: «Хорошо. Я включаю его только тогда, когда мне нужно заточить карандаш». Фитц некоторое время пребывал в полном замешательстве, после чего решил задать бабушке несколько вопросов, чтобы разобраться, что она имела в виду.

Оказалось, что Mac был включен в один удлинитель с электрической точилкой для карандашей. Раз в неделю бабушка Фитца приходила в комнату с карандашами и втыкала удлинитель в розетку. Mac подавал сигнал и начинал загружаться. Бабушка затачивала карандаши и, уходя, отключала удлинитель от сети, не дав компьютеру закончить загрузку.[59] Этот пример хорошо иллюстрирует, как несведущий в технике человек пытается объяснить ситуацию с помощью ограниченного терминологического аппарата и обстановки, которая характеризует его взаимодействие с компьютером.

Запомните этот бедный замученный Mac

Многие люди также обладают мистическими предубеждениями относительно поисковой службы Google. Они считают, что она является частью их компьютера. В 2005 году мы часто ловили на себе удивленные взгляды людей, когда рассказывали, что работаем инженерами в Google. Они отвечали нечто вроде: «Ничего себе! А я не знал(а), что там кто-то работает!» Бывало и наоборот: однажды подруга бабушки Фитца расстроилась, узнав, что Google в полном составе собирается на лыжную прогулку (это происходило еще в то время, когда Google была небольшой компанией). «Это ужасно! – говорила она, – Как они могут все вместе уехать кататься? Кто будет искать для меня информацию?» Конечно, со стороны Google было легкомысленно не оставить в офисе нескольких операторов, которые бы поддерживали работоспособность сервиса.

Вызывайте доверие и восхищение

Существует еще два понятия, которые должны лежать в основе ваших взаимоотношений с пользователями: доверие и восхищение.

Доверие – непростой термин. Мы уже рассматривали его в контексте принципа скромности, уважения и доверия; мы говорили о том, стоит ли проявлять доверие к своим коллегам, и как это делать. Теперь мы говорим о завоевании доверия со стороны ваших пользователей. Когда пользователь доверяет вашей команде или компании, это в первую очередь является эмоциональным состоянием: очень немногие люди говорят нечто вроде: «Я доверяю продукту X потому, что у меня есть длинный список фактов, подтверждающих, что его использование не создает никаких рисков». Большинство людей доверяет потому, что сотрудничество с вами укрепило их положительные эмоции по отношению к вам.

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

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

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

Хороший пример этого тезиса (на момент написания книги в конце 2011 года) продемонстрировала компания Netflix, на некоторое время испортившая отношения со своими пользователями. Netflix предоставляет услугу потоковой трансляции фильмов через Интернет и заказа DVD по почте. За десять лет ее популярность значительно выросла: сервис был простым, удобным, необычным и при этом дешевым. В начале 2011 года у Netflix было более 23 миллионов подписчиков.

В какой-то момент времени руководители бизнеса пришли к выводу, что DVD и потоковое видео представляют собой разные услуги с различными принципами извлечения прибыли, потребностями в управлении и прочим. Они решили взимать плату за каждую услугу в отдельности и подняли ежемесячные платежи для некоторых пользователей на 60 %. Клиенты оказались очень недовольны. Netflix объявила о том, что собирается разделиться на две компании, чтобы сделать бизнес четким и удобным; для пользователей это означало необходимость оплачивать два счета вместо одного. Поняв, что отношения с клиентами катастрофически ухудшились, компания аннулировала свое заявление, но было уже поздно – удар по репутации нанесен. Несмотря на то что впоследствии компания демонстрировала устойчивый рост, за три месяца она потеряла 800 000 подписчиков. Доверие, накопленное за 10 лет, было разрушено двумя небольшими действиями, которые выглядели как простые и нужные для бизнеса, но не имели ничего общего с взаимоотношениями с клиентами.

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

Для начала не воспринимайте себя слишком серьезно. У Google есть традиция делать смешные анонсы продуктов на 1-е апреля; например, однажды все видеоролики на главной странице YouTube открывали совершенно другие ссылки. Еще один пример – сайт www.woot.com; он предназначен для ежедневных распродаж, но его рекламная копия полна самоиронии и эксцентричного юмора.

Периодически делайте своим клиентам небольшие подарки

Радуйте пользователей небольшими сюрпризами (в этом и заключается суть восхищения, не так ли?). Хотя Google является кузницей сложных компьютерных технологий, ничто так не радует ее пользователей, как забавные иллюстрации к празднику или какой-нибудь годовщине. Появление небольшой картинки посреди рабочего дня вызывает бесконечный поток писем и обсуждений в офисных коридорах.

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

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

Помните о пользователях

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

Маркетинг. Уделяйте внимание тому, как люди воспринимают ваше ПО; от этого зависит, захотят ли они хотя бы опробовать его.

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

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

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

Эпилог

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

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

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

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

Заключительная мысль

Итак, настало время «вытащить кота из мешка». Если вы еще не пришли к такому выводу сами – большинство советов этой книги применимо не только к разработке ПО.

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

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

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

Приложение. Что еще почитать

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

• Peopleware: Productive Projects and Teams, 2nd edition, by Tom DeMarco (Dorset House). (Том ДеМарко. Человеческий фактор. Успешные проекты и команды. СПб.: Символ-Плюс. 2011.)

• Drive: The Surprising Truth About What Motivates Us by Daniel H. Pink (Riverhead).

• «You and Your Research» by Richard Hamming (http://www.cs.virginia.edu/~robins/YouAndYourResearch.pdf).

• Predictably Irrational: The Hidden Forces That Shape Our Decisions by Dan Ariely (HarperCollins).

• The Mythical Man-Month: Essays on Software Engineering, 2nd Edition, by Frederick P. Brooks (Addison-Wesley Professional). (Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы. СПб.: Символ-Плюс. 2010.)

• Startup Engineering Management by Piaw Na (self-published).

• Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman (http://shop.oreilly.com/product/9780596518387.do) by Dave Hoover and Adewale Oshineye (O’Reilly).

• Quiet: The Power of Introverts in a World That Can’t Stop Talking by Susan Cain (Crown).

• Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns (Addison-Wesley).

• The Art & Adventure of Beekeeping by Ormond Aebi (Rodale Press). (Дастин Босуэлл, Тревор Фаучер. Читаемый код, или Программирование как искусство. СПб.: Питер, 2012.)

• «Maker’s Schedule, Manager’s Schedule» by Paul Graham (http://www.paulgraham.com/makersschedule.html).

• The Art of Readable Code (http://shop.oreilly.com/product/9780596802301.do) by Dustin Boswell and Trevor Foucher (O’Reilly).

• Mastery: The Keys to Success and Long-Term Fulfillment by George Leonard (Plume).

• «The Significance of Task Significance: Job Performance Effects, Relational Mechanisms, and Boundary Conditions» (2008) by Adam M. Grant (Journal of Applied Psychology 93:1, pp. 108–124).

• Project Retrospectives: A Handbook for Team Reviews by Norman L. Kerth (Dorset House).

• The Luck Factor by Richard Wiseman (Miramax).

• Search Inside Yourself by Chade-Meng Tan (HarperOne).

• Being Geek (http://shop.oreilly.com/product/9780596155414.do) by Michael Lopp (O’Reilly).

• The Paradox of Choice: Why More is Less by Barry Schwartz (Ecco).

• Critical Chain by Eliyahu M. Goldratt (North River Press).

• Delivering Happiness: A Path to Profits, Passion, and Purpose by Tony Hsieh (Hachette Book Group). (Тони Шей. Доставляя счастье. От нуля до миллиарда. История создания выдающейся компании из первых рук. М.: Манн, Иванов и Фербер. 2010.)

notes

Примечания

1

Мы прочитали замечательную книгу Тома Де Марко (Tom DeMarco) «Человеческий фактор» (PeopleWare), но она адресована не столько инженерам, желающим научиться эффективнее взаимодействовать с людьми, сколько менеджерам, стремящимся сделать свои команды более успешными.

2

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

3

Это особенно трудно, если в прошлом вы имели негативный опыт передачи работы некомпетентным людям.

4

«Вы и ваши исследования» (You and Your Research), http://www.cs.virginia.edu/~robins/YouAndYourResearch.pdf

5

Дюжину вариантов этой легенды можно найти в Интернете применительно к различным известным менеджерам.

6

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

7

Это чертовски напугало Фитца, когда он впервые оказался в питтсбургском офисе Google.

8

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

9

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

10

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

11

Другими словами, командной гордости.

12

См. замечательное выступление Сьюзан Кейн (Susan Cain) «Сила интровертов» (The Power of Introverts), http://www.youtube.com/watch?v=c0KYU2j0TM4, или ее книгу «Интроверты. Как использовать особенности своего характера» (Quiet: The Power of Introverts).

13

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

14

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

15

Этот документ находится по адресу http://code.google.com/webtoolkit/makinggwtbetter.html, и его стоит прочитать как образец формулировки миссии.

16

http://www.paulgraham.com/makersschedule.html

17

Вице-президент компании Google Engineering Уэйн Розинг (Wayne Rosing) ввел эту традицию в 2001 году, стараясь улучшить качество жизни инженеров. Фитц на протяжении многих лет «блокировал» свои четверги, и, нужно сказать, этот подход работает очень эффективно, хотя и требует постоянного внимания и периодического написания гневных писем, когда кто-то планирует совещание на четверг.

18

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

19

Разумеется, если инженеру необходимо работать, не отвлекаясь, и «переключение контекста» является для него «непозволительной роскошью», то игнорирование чата – абсолютно нормально.

20

Комментариям посвящен замечательный раздел в книге Дастина Босвелла и Тревора Фаучера «Искусство создания читабельного кода» (Dustin Boswell, Trevor Foucher. The Art of Readable Code) издательства O’Reilly.

21

Это и другие руководства по стилю можно найти по адресу http://code.google.com/p/google-styleguide/

22

Рой. Бегущий по лезвию (Roy, Blade Runner), 1982.

23

В Европе промышленная революция началась в XVIII веке, в США – в XIX веке.

24

http://www.ted.com/talks/dan_pink_on_motivation.html

25

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

26

Как говорит Фогхорн Легхорн (Foghorn Leghorn), «это шутка, сынок».

27

Здесь Google использует слово менеджер в значении «человек, перед которым отчитываются», а не «человек, выкрикивающий команды своим подчиненным».

28

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

29

См. раздел о неудачах в главе 2.

30

Это его настоящее имя.

31

См. также статью «Rubber duck debugging» («Метод резиновой уточки»), http://en.wikipedia.org/wiki/Rubber_duck_debugging

32

См. также выступление Альберто Савойя (Alberto Savoia) «Манифест претотипирования» (The Pretotyping Manifesto), http://www.youtube.com/watch?v=t4AqxNekecY

33

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

34

Как мы отмечали ранее в этой главе, стоит посмотреть на замечательное выступление Дэна по этому вопросу на TED.

35

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

36

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

37

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

38

http://www.management.wharton.upenn.edu/grant/Grant_JAP2008b_TaskSignificance.pdf

39

Магистр Йода, скорее всего, прокомментировал бы тезис о том, что нужно избегать Темной стороны силы.

40

Возможно, эта фраза попала в Usenet из серии «День голубя» (Day of the Dove) сериала «Звездный путь» (Star Trek), где энергетический вампир питался отрицательными эмоциями. Керк и его соперник Канг из цивилизации Клингонов приказали своим людям перестать кормить энергетического вампира, и он покинул Энтерпрайз. Как видите, данный метод заимствован из «Звездного пути».

41

Более подробно об этой теме пишет Норман Керт (Norman Kerth) в разделе «Ретроспектива Первой Директивы» (The Retrospective Prime Directive) своей книги «Ретроспективы в проектах» (Project Retrospectives).

42

См. «Принцип Анны Карениной», http://ru.wikipedia.org/wiki/%CF%F0%E8%ED%F6%E8%EF_%C0%ED%ED%FB_%CA%E0%F0%E5%ED%E8%ED%EE%E9

43

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

44

Что разочаровывает вдвойне, поскольку вы добились успеха вопреки их руководству.

45

Для сравнения: на первой рабочей неделе в Google Фитц нашел ошибку в Gmail. Он открыл исходный код, исправил ее и отправил патч команде Gmail, которая сердечно поблагодарила его. В больших компаниях не всегда происходят трения!

46

Не следует ли начислять дополнительные баллы за эффективность при удалении строк кода?

47

Это высказывание часто приписывается адмиралу Грейсу Мюррею Хопперу (Grace Murray Hopper), соавтору языка COBOL и одаренному программисту.

48

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

49

В оригинале высказывание звучит так: «Собственность – это девять десятых закона». – Примеч. перев.

50

ISBN: 978-1401359416.

51

http://www.telegraph.co.uk/technology/3304496/Be-lucky-its-an-easy-skill-tolearn.html

52

Технологическая сфера значительно у́же, чем вам кажется, а люди говорят значительно больше, чем вы себе представляете. Если сегодня вы доставляете кому-то неприятности, то этот «кто-то» вполне может уничтожить ваше резюме лет через десять! Если вы не собираетесь заняться плетением корзин на необитаемом острове, то разрыв прежних связей станет для вас дорогостоящей ошибкой. Друзья приходят и уходят, а враги остаются.

53

Сначала Фитц написал Стиву бессвязное сообщение, которое не принесло ему абсолютно никакого результата (кроме извещения об увольнении). Коллега посоветовал Фитцу выражаться короче и по существу, а закончить письмо призывом к действию.

54

Внимание: вам вряд ли удастся договориться об интервью с Президентом США, заказать у Шевроле стеклоочистители с лазерным приводом или пригласить на ланч директора по продажам Whole Foods. Этот метод работает только для реалистичных просьб.

55

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

56

http://www.mengstupiditis.com/2011/06/do-right-thing-wait-to-get-fired.html

57

Schwartz, B. The Paradox of Choice: Why More Is Less (Ecco).

58

См. третий закон Артура Кларка (Arthur C. Clarke).

59

Для интересующихся судьбой Mac: с того момента его страдания прекратились.

Table of Contents

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

Отзывы о книге

Цель этой книги

Благодарности

От Фитца

От Бена

Об авторах

От издательства

Введение

Для кого предназначена эта книга

Внимание: эта книга не является техническим пособием

Эта книга о том, чему не учат в вузах

Ключевая идея книги

Глава 1. Миф о гениальном программисте

Помогите мне спрятать свой код!

Миф о гении

Скрываться вредно

Все дело в команде

Три кита

Скромность, уважение и доверие на практике

Избавьтесь от самомнения

Учитесь критиковать и быть критикуемым

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

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

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

Будьте открытым для внешнего влияния

Дальнейшие шаги

Глава 2. Формирование высокой командной культуры

Что такое культура?

Зачем заботиться о культуре?

Культура и люди

Коммуникационные шаблоны успешных культур

Высокоуровневая синхронизация

Формулирование миссии (только не это!)

Эффективные собрания

Работа с «географически сложными» командами

Проектная документация

Текущие обсуждения

Списки рассылки

Онлайн-чаты

Система отслеживания ошибок

Общение как часть разработки

Комментарии к исходным текстам

Указание вашего имени в файлах с исходным кодом (проблема «ссылки на автора»)

Требуйте рецензирования всего опубликованного кода

Создайте настоящие процедуры тестирования и выпуска

Все это касается кода

Глава 3. В каждой лодке должен быть капитан

Природа не терпит пустоты

Устаревший подход к управлению

Лидер – это новый менеджер

Единственное опасение состоит… во всем!

Лидер-слуга

Антирекомендации

Нанимайте плохих профессионалов

Игнорируйте неэффективных сотрудников

Игнорируйте социальные проблемы

Будьте другом каждому

Идите на компромиссы при найме

Обращайтесь с участниками команды как с детьми

Рекомендации лидерам

Избавьтесь от самомнения

Будьте дзэн-мастером

Будьте катализатором

Будьте учителем и наставником

Ставьте четкие цели

Будьте честным

Наблюдайте за удовлетворенностью команды

Прочие рекомендации

Люди подобны растениям

Внутренняя и внешняя мотивация

Заключение

Глава 4. Работа с вредоносными людьми

Что значит «вредоносный»

Усиление вашей команды

Обнаружение угрозы

Неуважение к времени других людей

Самомнение

Вседозволенность

Легкомысленность и невразумительность при общении

Паранойя

Перфекционизм

Как нейтрализовать вред

Перенаправляйте энергию перфекционистов

Не кормите энергетических вампиров

Не будьте излишне эмоциональным

Ищите факты в обвинениях

Проявляйте любезность к троллям

Останавливайтесь вовремя

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

Заключительная мысль

Глава 5. Искусство корпоративной манипуляции

Добро, зло и стратегии

Идеал: как команда должна работать внутри компании

Ваша жизнь под руководством идеального менеджера

Действительность: что делать, если окружение препятствует вашему успеху

Ваша жизнь под руководством плохого менеджера

Офисный политикан

Плохая организация

Манипулирование организацией

«Проще попросить прощения, чем разрешения»[47]

Если нет дороги, проложите свою

Учитесь карьерному росту

Удача и «учет любезностей»

Получите безопасную должность

Заводите влиятельных друзей

Как попросить занятого руководителя о чем угодно по электронной почте

План Б: эвакуация

Не все потеряно

Глава 6. Пользователи – тоже люди

Работа с общественным мнением

Обращайте внимание на первое впечатление

Меньше обещайте, больше создавайте

С уважением относитесь к отраслевым аналитикам

Насколько удобны в использовании ваши программы?

Выбирайте свою аудиторию

Доступен ли ваш продукт?

Измеряйте использование, а не пользователей

Скорость имеет значение

Не пытайтесь изобрести универсальный продукт

Не ленитесь

Скрывайте сложность

Управление взаимоотношениями с пользователями

Не страдайте высокомерием

Будьте терпеливым

Вызывайте доверие и восхищение

Помните о пользователях

Эпилог

Заключительная мысль

Приложение. Что еще почитать

Примечания

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59