Майкл Лопп - Как управлять интеллектуалами. Я, нерды и гики

4. Тест Рэндса

Пройдите короткий тест, чтобы оценить жизнеспособность вашей команды

Трудно назвать лучшую работу Джоэла Спольски, но если бы мне пришлось это сделать, то я бы выбрал «Тест Джоэла: 12 шагов к лучшему коду»4. Это его собственный, ужасно несерьезный и нестрогий тест для оценки качества ПО. И если кто-нибудь спрашивает меня, что не так с его командой, то обычно я начинаю с этого теста. Давайте и в этот раз начнем с него .

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

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

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

Тест Рэндса: максимум 11 очков

Давайте начнем с самой незатейливой версии теста, а затем я поясню каждый вопрос.

• Проводятся ли у вас совещания тет-а-тет?

• Проводятся ли у вас общекомандные совещания?

• Есть ли у вас отчеты по статусу проекта?

• Можете ли вы сказать своему боссу «нет»?

• Можете ли вы объяснить стратегию вашей компании незнакомцу?

• Можете ли вы рассказать о текущем состоянии дел в вашей ком­пании?

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

• Вы знаете, что хотите делать дальше? А ваш босс знает?

• У вас есть время на стратегическую деятельность?

• Вы активно боретесь с сарафанным радио?

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

Проводите ли вы регулярные совещания тет-а-тет со своими сотрудниками, на которых вы обсуждаете не только текущий статус проектов, но и другие темы? (+1)

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

Более того, как я буду объяснять далее в главе 7 «Новейшие сводки. Жалобы. Катастрофа», транслирование статуса проекта не является целью тет-а-тета. Цель тет-а-тета — провести что-то вроде беседы о сути деятельности команды. Статус проекта может быть введением к такой беседе, он может быть фундаментом такой беседы, но он не может быть ее целью. Правильный тет-а-тет должен быть стратегическим, он не должен быть пересказом тактик, статусов и сведений, которые легко можно почерпнуть из других источников.

Тет-а-тет — это еженедельное инвестирование в сотрудников, которые составляют вашу команду. Если ваши тет-а-теты нерегулярны или вы не считаете их особо ценными, то вы укрепляете миф о том, что руководители недоступны.

Проводите ли вы регулярные общекомандные совещания? (+1)

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

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

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

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

Получаете ли вы письменные отчеты о статусе проектов по электронной почте? (–1)

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

Я уверен в том, что отчеты о статусах проектов, направляемые по электронной почте, — это один из самых явных и самых верных признаков некомпетентности и лени руководителя. Причины, по которым якобы необходимо генерировать эти еженедельные отчеты по электронной почте, есть всегда: мы крупная компания, и нашим сотрудникам необходимо перекрестное опыление! Подготовка отчета занимает не более 15 минут.

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

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