Как управлять интеллектуалами. Я, нерды и гики - [12]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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