Ознакомительная версия. Доступно 16 страниц из 76
могут выпускать свои маркетинговые материалы. Их продукты дойдут до гораздо большей аудитории через мировую дистрибьюторскую сеть Sierra. Мы возьмем на себя производство продукции, сами обработаем возвраты нераспроданных копий и займемся клиентской поддержкой. И это еще не все. Очень немногие компании, занимающиеся разработкой программного обеспечения, дорастают до превращения в публичную компанию (то есть такую, акции которой предлагаются на бирже неограниченному кругу лиц). Войдя в состав Sierra, небольшая фирма по разработке ПО сможет в один момент получить все преимущества публичной компании. Учредители смогут обменять свои неликвидные акции на ликвидные, которые можно продать, когда захочется. Они смогут выдавать своим сотрудникам опционы на акции.
Когда я хотел приобрести новую компанию, никто не рекламировал Sierra так хорошо, как президенты и разработчики уже приобретенных компаний. Они охотно подтверждали все то, что я обещал новому кандидату.
Это было соблазнительное предложение, и оно находило отклик у разработчиков. Я помню, как пытался объяснить нашу стратегию приобретения одному инвестиционному банкиру с Уолл-стрит, который просто не понимал, в чем смысл. Ему казалось, что мы переплачиваем. У него была навороченная электронная таблица, которая давала оценку по потенциальной прибыли от приобретения. А в моей формуле рассматривались продукты компании и оценивались постепенно возрастающие доходы, которые можно было бы получить, если использовать производственные, дистрибьюторские и операционные мощности Sierra. Я также учитывал возможный рост прибыли за счет использования уже имеющихся у Sierra технологий и обмена новыми, которые мы получали благодаря покупке. Банкир с Уолл-стрит заявлял, что я делаю покупку исходя из стоимости самой Sierra на момент сделки. Меня устраивала и такая интерпретация. Мой собеседник руководствовался исключительно стоимостью приобретаемой компании, а меня больше занимала ценность, которую эта покупка принесет Sierra и ее акционерам. По-настоящему важно было, чтобы компания в целом стала сильнее и успешнее, а не то, сколько денег придется за это заплатить.
Ежегодные стратегические собрания
Раз в год на каком-нибудь курорте мы проводили то, что я называл «ежегодным стратегическим собранием». Обычно там можно было весело провести время и укрепить отношения в коллективе, но в целом это были серьезные собрания, которые мы проводили в конференц-зале с меловыми досками, слайдами и всем прочим.
На собраниях присутствовало около двадцати человек: вице-президенты Sierra, руководители дочерних компаний, а иногда и члены нашего совета директоров. Проводили мы все это ради обсуждения масштабных проблем Sierra.
Собрания проходили под строгим контролем в виде нескольких раздельных сессий, например:
• Какие изменения в индустрии ожидаются в течение следующего года?
«Оборудование/Технологии
«Конкуренты
• По каким направлениям мы еще не работаем и куда нам следует расшириться?
«Фильмы, музыка, комиксы, аппаратное обеспечение, программное обеспечение для бизнеса?
«Как мы можем использовать узнаваемость нашего бренда и нашу интеллектуальную собственность, чтобы создать себе новые потоки доходов? (лицензирование? партнерство?)
• В каких каналах сбыта нас нет и куда нам следует расшириться?
«Международная экспансия
«Розничные каналы
«Прямой маркетинг
• Присутствие на каких направлениях и каналах сбыта стоит уменьшить?
• Обзор продуктов, которые, как мы планируем, должны выйти в следующем году
«Какие продукты, по нашему мнению, станут бестселлерами?
«Какие продукты нам следует отменить?
• Бюджеты подразделений (сколько денег получает каждое подразделение, какие доходы они должны приносить).
Все это может звучать хорошо, и иногда так оно и было, но мы сталкивались и с серьезными проблемами, над которыми приходилось работать каждый день.
Разработку программного обеспечения трудно вести в рамках бюджета. Как вы думаете, какой процент крупных проектов по разработке ПО завершают в срок и в рамках производственного бюджета? Если вы загадали число больше нуля, вы почти наверняка ошиблись. Sierra была невероятно хороша по части разработки программного обеспечения, но если я скажу, что мы были идеальны или что наши проекты, как правило, вписывались в дедлайны и бюджеты, то я солгу.
На ежегодном стратегическом собрании мы могли решить, что дочерняя компания, например Dynamix, получит бюджет на разработку продукта в размере 5 миллионов долларов. Этот бюджет на разработку также включал в себя и информацию о прогнозируемых доходах. Я предпочитал следующее выработанное практикой правило: проект должен приносить в четыре раза больше выручки, чем было потрачено на его разработку. В данном примере: если бы Dynamix получила 5 миллионов долларов на разработку продукта, мы бы ожидали, что этот продукт принесет 20 миллионов или больше.
Помимо общих бюджетов дочерних компаний, у нас были и бюджеты отдельных продуктов. В таком подразделении, как Dynamix, на разных стадиях завершения постоянно находилось от десяти до двадцати проектов. Некоторые из них были совершенно новыми играми, некоторые – дополнениями к существующим играм или небольшими модификациями (их вносили в ранее выпущенную игру, чтобы перевыпустить ее как новый продукт). Какие-то проекты представляли собой просто портирование старого продукта на новую платформу (например, с Windows на Mac). На каждый проект мы закладывали соответствующий бюджет. Они могли составлять от 25 тысяч долларов до более чем 1 миллиона в зависимости от масштаба проекта. Все расходы, связанные с разработкой, учитывались как расходы по единому бюджету проекта, включая траты на графику, программирование, музыку, тестирование, написание документации и т. д.
Президентам подразделений Sierra нужно было сделать так, чтобы проекты укладывались в бюджеты и в сроки. Выход за рамки бюджета – вещь неприятная, но, как мы понимали, неизбежная. И, как ни странно, превышение бюджета не приводило к немедленному увеличению расходов, оно означало лишь переносы выхода продукта и снижение его конечной прибыльности.
Собрания по обзору продуктов
Именно здесь в производственном процессе должен был участвовать я. Раз в квартал я посещал офисы каждой дочерней компании, чтобы посмотреть на продукты, которые она на тот момент разрабатывала. Мы называли эти визиты «собраниями по обзору продуктов» – благодаря им я оставался в курсе, какие продукты в разработке, укладываются ли они в бюджет, соответствуют ли прогнозам по продажам, в какой срок их можно реально представить публике.
Во время собрания по обзору продуктов менеджеры проектов один за другим показывали свои продукты. Где-то мне показывали работающий код (то есть что-то играбельное), где-то и показывать было пока нечего.
– Вы рисуете Микки Мауса?
Мне пришлось признаться, что я больше не рисую.
– Значит, вы придумываете все шутки и идеи?
– Нет, – сказал я, – я и этого не делаю.
Наконец, он посмотрел на меня и сказал:
– Мистер Дисней, а чем вы занимаетесь?
– Ну, – сказал я, – иногда я представляю себя маленькой пчелкой. Я хожу из одной части студии в другую, собираю пыльцу и как бы стимулирую всех. Думаю, это и есть моя работа.
Эта цитата Уолта Диснея висела у меня на стене – из нее я черпал вдохновение для собраний по обзору продуктов
Я ставил перед собой цель узнать о проектах все, что только можно. Укладываются ли они в сроки отгрузки? Может, продукт обещает стать еще большим хитом, чем планировалось, или это раненая лошадь, которую надо пристрелить? Может, там используется какая-то крутая технология, которой следовало бы поделиться с другой группой разработчиков? Может, в другой дочерней компании есть код, который можно было бы перенести сюда для снижения стоимости разработки?
Бывали случаи, когда приходилось играть в совсем не компьютерные игры. Например, перерасход средств заметали под ковер, перекидывая счета по одному проекту на другой. У нас были еще не начатые проекты с огромными счетами. Я пытался перехватывать подобные махинации, но, учитывая, что я ездил по дочерним компаниям только раз в квартал, это было нелегко.
Собрания по обзору продуктов проводились в самых разных местах по всему миру. Я без конца летал туда-сюда на самолетах, и мне нужна была помощь с координацией работы всех наших дочерних компаний. Я в итоге сказал, что мне нужен «умный менеджер», который мог бы помочь мне следить за всем. Именно такой человек и нашелся в лице Джерри Боуэрмана. Он пришел в компанию в качестве моего помощника и начал руководить одной из дочерних компаний. Позже он стал отвечать за все дочерние компании в качестве вице-президента по разработке продуктов. Джерри был молодым, наглым и самоуверенным. Он не был техническим специалистом, но он был отличным менеджером и быстро завоевал уважение всей компании.
Ознакомительная версия. Доступно 16 страниц из 76
