Бен Хоровиц - Легко не будет. Как построить бизнес, когда вопросов больше, чем ответов

• Название: Легко не будет. Как построить бизнес, когда вопросов больше, чем ответов
• Автор: Бен Хоровиц
• Жанр: Поиск работы
• Год: 2015
• ISBN: 978-5-00057-255-9

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

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

На русском языке публикуется впервые.

---

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

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

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

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

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

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

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

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

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

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

Марк, быстро отреагировав: Вы разговаривали с вице-президентом по сетевым технологиям?

Агент: М-м-м, нет.

Марк: Вы лично разговаривали с вице-президентом?

Агент: Нет.

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

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

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

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

К сожалению, мы не могли наш Jive считать удачной базой для разработки кода программного обеспечения. И его нельзя было трансформировать в полноценный продукт. Поэтому я видел два возможных выхода из этой ситуации: а) запустить новый проект; б) купить одну из четырех уже существующих компаний, специализирующихся на программном обеспечении для автоматизации сетей. Еще в начале карьеры программиста я усвоил, что подобные решения объективны до тех пор, пока не написана первая строка собственного кода – после этого они диктуются эмоциями. Да к тому же в нашей команде был лучший в мире специалист в области переговоров по слияниям и поглощениям – Джон О’Фаррелл, поэтому я решил изучить возможности приобретения сторонней компании, прежде чем призывать коллектив к очередному трудовому подвигу.

Как ни странно, среди работавших в этой области компаний именно Rendition Networks, которая, с нашей точки зрения, создала продукт с лучшей архитектурой, демонстрировала наихудшие показатели объема продаж. Это заставляло некоторых предпринимателей с недоверием относиться к нашей оценке технических параметров их продукта. Но если я что-то и усвоил к этому моменту, так это то, что житейская мудрость не имеет ничего общего с истиной и удачное выведение товара на рынок часто внушает обманчивые представления о его качестве. Как иначе можно было объяснить то, что капитализация Opsware оценивалась лишь в половину суммы, которая лежала на банковском счете компании, и это при том что у нас был контракт на 20 миллионов долларов в год и 50 лучших в мире программистов? Нет, рынки отнюдь не «эффективны» в поиске истины, зато они эффективны в выработке мнения о компаниях – очень часто ложного.

Получив подтверждение тому, что купить компанию выгоднее, чем разрабатывать программное обеспечение самим, мы приступили к переговорам о покупке Rendition Networks за 33 миллиона долларов. В течение трех месяцев, пока готовилась эта сделка, Джон параллельно вел переговоры с Cisco Systems – крупнейшим разработчиком сетевого программного обеспечения в мире – по поводу продажи нашего будущего продукта. Сделка включала условие выплаты нам аванса в 30 миллионов долларов в обмен на предоставление расширенной лицензии на продукт. В результате одна только эта сделка с Cisco покрыла около 90 % наших затрат на поглощение Rendition Networks.