Сообщений 50 
Оценка 841
[+1/-0]
Оценить 
| Сообщений 50 Оценка 841
[+1/-0]
Оценить
|
Роберт Скобл, создатель замечательного блога, не так давно написал: "Я бы предпочел видеть больше софтовых компаний, а не меньше". Я полностью с ним согласен.
Может, кому-то это покажется очевидным, но, тем не менее - каждая компания по разработке ПО (Independent Software Vendor, ISV) создана бизнесменом, преодолевшим страх неудачи. Создание новой компании обычно связано с часами изучений, взвешиваний и обсуждений, большая часть которых сводятся к единственному вопросу: "Удастся ли мне заставить ЭТО заработать?".
Это — нормальный и необходимый процесс. Он включает в себя исследования рынка, перемалывание цифр, презентации, предположения, кофе… — все жизненно важные составляющие бизнес-успеха.
Этот процесс также неизменно содержит немалую долю самоанализа. Главный вопрос - не "Может ли этот бизнес вообще работать?", а "Смогу ли я заставить его заработать?". И это опять же является естественным. Я видел научные исследования, доказывающие - самоанализ является фактором успеха номер один. Ничто не заменит вам твердого знания собственных возможностей и ограничений.
Но самоанализ также зачастую включает в себя некоторые страхи. Предприниматели склонны бояться совершения ошибок. В отличие от прочих исследований и обдумываний, которые происходят при создании новой компании, эти страхи далеко не так полезны.
Продолжая цитировать только гигантов индустрии, приведу замечание Томаса Дж. Уотсона, основателя и бывшего президента IBM:
Вы хотите, чтобы я дал Вам формулу успеха? На самом деле она проста: удвойте частоту Ваших неудач. Вы считаете ошибки врагами своего успеха, но это не так. Можно быть обескураженым неудачей, а можно извлечь из нее урок. Так что двигайтесь вперед и совершайте ошибки. Делайте все возможное. И помните - только так можно добиться успеха.
Томас Дж. Уотсон.
Не думаю, что Уотсон защищает смелость в смысле безрассудства. В конце концов, я уверен, что в период его правления IBM делала огромное количество благоразумных планирований и исследований рынка. Но в его словах содержится важный совет для начинающих бизнесменов - ошибки должны не только пугать Вас.
Жизнь в небольшой софтовой компании напоминает нескончаемый поток решений, ко многим из которых Вас никто не готовил:
Никакие предметы в колледже не учили меня, как принимать такие решения, так что пришлось учиться этому самостоятельно. Правильнее будет сказать: я научился принимать решения, выполняя эту работу плохо. За семь лет со дня основания SourceGear я совершил множество ошибок. И, хотя временами их действительно больно вспоминать, уроки, которые я из них извлек, были очень ценными.
Пройдя сквозь череду ошибок, я научился их различать. Мы называем "ошибкой" любое решение, которое приводит к плохому результату, но, в действительности, нужно отличать глупые ошибки от неудачных прогнозов.
В школе я как-то оставил свою математическую команду без награды, написав в ответе значение "102/17". Я не сделал ошибки в вычислениях, но… не догадался, что эту дробь можно сократить до 6. Выдать ответ в неверной форме не было взвешенным риском - я просто не видел другого способа решения. Наставник моей команды быстро объяснил, каким я был болваном. И он был прав, это - глупая ошибка.
Если и нужно опасаться каких-то ошибок, так это глупых. Это то, за чем вы не смогли увидеть приближающейся неудачи.
Некоторым утешением является то, что здесь помогает опыт. Со временем мы обычно совершаем все меньше и меньше глупых ошибок. Однако Вам не помогут постоянные сомнения типа: "А не делает ли моя компания такую ошибку именно сейчас?".
Можно до некоторой степени уменьшить вероятность глупых ошибок, занимаясь чтением. Почти каждый успешный предприниматель — ненасытный читатель. Но будьте осторожны, бизнесу можно научиться из книг, но, только если Вы правильно к ним подходите.
Важно относиться к прочитанному скептически. Подумайте об обстоятельствах автора и сравните их с собственными. Действительно ли этот совет применим к Вашей ситуации?
Ознакомьтесь с различными мнениями. Не читайте одну книгу по маркетингу — прочтите десять.
С помощью чтения нельзя найти ответы на Ваши вопросы, но, с другой стороны, чтение подготавливает почву для принятия собственных решений.
Иногда ошибкой называют взвешенный риск, который не принес желаемого результата. Вы заранее учитывали возможность плохого развития событий. Вы сделали ставку на то, что плохих событий не произойдет, и ошиблись.
Это основы принятия рискованных решений. Изучите все возможные последствия, проанализируйте вероятности и принимайте решение. Помните - это постоянная процедура. Если Вы не хотите становиться экспертом в области рискованных решений, Вам не нужно становиться предпринимателем. Множество Ваших ставок не сработает, но Вам нужно возвращаться к столу и пытаться снова и снова. Не существует бизнеса без риска.
Вы также должны быть готовы ко встрече с теми, кто ждет вашей неудачи, чтобы лишний раз позлорадствовать. Когда вы принимаете рискованное решение и проигрываете, тут же звучит хор голосов "я_же_тебе_говорил" – как правило, из тех, кто вообще не отваживается первым на рискованные поступки. Возможно, их отношение к риску просто отличается от Вашего. Вы же предприниматель — следовательно, заведомо более склонны к риску, чем большинство окружающих. Наверняка, среди ваших знакомых найдется как минимум один, кто бросит покер с четырьмя валетами на руках, если есть вероятность, что у противника стрит-флэш.
Иногда нужно игнорировать назойливых советчиков. Если Вы знаете, что звезды на Вашей стороне, Вы можете вернуться и вновь решиться на тот же риск, даже если люди считают Вас безумцем.
Когда в 2002 году у меня брали интервью по поводу попадания SourceGear в Inc. 500, мне задали вопрос: что в моей предпринимательской деятельности было для меня наибольшим сюрпризом? Я ответил: самым большим сюрпризом является то, что человек, совершивший так много ошибок, попал в список Inc. 500. :-)
Я часто делюсь следующим советом с другими бизнесменами: "Делайте сколько угодно несмертельных ошибок, но не совершайте одной-единственной - фатальной". Следуя этому правилу, я счастлив имея все те ошибки, которые я допустил. А, как вы сейчас увидите, мне довелось совершить немало глупостей, но SourceGear до сих пор в бизнесе.
Ниже я привожу несколько рассказов о моих крупнейших промахах в SourceGear. Некоторые из них действительно могут меня смутить, но они — важная часть моей истории. Из каждой такой ошибки я извлек важный урок, и я не сожалею о них.
Первым нашим годом в бизнесе был 1997-й. Мы начали с создания ПО для крупных заказчиков — компаний, больших, чем наша. В числе наших первых сделок был заказ от одной крупнейшей и известнейшей в мире бухгалтерской компании. Проект был большой возможностью заполучить звучного, "баннерного" клиента.
Задачей проекта было создание приложения для замены очень сложной таблицы MS Excel. Наш заказчик достиг практически всех ограничений таблиц Excel. Мы решили писать приложение на Java. После определения необходимых требований, мы согласились создать приложение за фиксированную сумму в $28 000…
Проект стал кошмаром.
Мы знали, что цена довольно низка, но, в конце концов осознали, что ошиблись в множителе. К тому моменту, как проект был окончательно похоронен, мы потратили свыше $100 000.
Полученный урок: относитесь с осторожностью к проектам с фиксированной ставкой.
До 1998 года ставка на Java для создания GUI-приложения была самоубийством. Платформа к тому времени попросту еще недостаточно повзрослела для создания качественных пользовательских интерфейсов. Я выбрал Java, потому что был без ума от нее. Я обожал концепцию кросс-платформенного C-подобного языка со сборкой мусора. Мы надеялись получить богатый опыт программирования на Java и сделать эту восхитительную технологию своей специальностью.
Но Java привела к ужасному крушению планов. Контрол ScrollPane паршиво справлялся с прокруткой. Поддержка печати регулярно отваливалась. Потребление памяти было невероятно высоким.
Мне пришлось покончить со своими религиозными пристрастиями и написать это приложение на Visual Basic.
Полученный урок: будьте осторожны при использовании ультрамодных технологий.
Создавая компанию, я снял одну комнату в офисном здании.По мере того, как компания росла, мы просто арендовали новые комнаты. В конце концов, мы стали поговаривать о переезде. После рассмотрения нескольких вариантов, я проигнорировал совет мудрого друга и купил офисное здание. Через год мы переросли и это здание и мне пришлось продать его с убытком.
Полученный урок: небольшие "софтовые" компании должны заниматься своим делом и держаться в стороне от дел с недвижимостью.
В начале 1998 года Netscape провозгласила, что исходный код ее браузера станет доступен всем желающим. Как бывший участник войны браузеров, я счел эти новости замечательными. Я знал откуда-то, что OpenSource становится заметной тенденцией. Я запрыгнул в этот поезд обеими ногами, запустив AbiSource - попытку создания офисного пакета в рамках OpenSource, начиная с текстового процессора.
У меня было большое видение. Я предсказывал, что нахлынет волна Open Source-акционерных проектов на Linux и одним из них будет AbiSource. Я начал писать бизнес-планы и готовиться к приему финансирования. Мы писали код в жуткой спешке и анонсировали публичный релиз AbiWord на конференции O'Reilly Open Source Developer Day в августе 1998-го.
AbiWord произвел большую шумиху. Людям действительно это понравилось. Наши выставочные павильоны были забиты народом. Пресса восприняла нашу идею как нечто новое и любила писать о нас истории. Самым странным признанием полученного нами внимания было упоминание AbiWord Microsoft-ом на судебных заседаниях антимонопольного комитета (на странице 16 распечатки) как доказательство наличия заметных конкурентов у Microsoft Office.
Но, несмотря на то, что AbiWord всем понравился, он так и не стал бизнесом. Поиск вкладчиков не увенчался успехом. Слава AbiWord открывала нам двери, но мы всегда выходили из них без денег. Тим О'Рейли ответил отказом. Боб Янг ответил отказом. Френк Баттен ответил отказом. Билл Кайзер ответил отказом. Оглядываясь назад, видишь, что эти джентльмены действительно так умны, как мы о них думаем.
Хадар Педхазур также ответил отказом, но не только. Хадар, возможно, самый прозорливый вкладчик в рискованные предприятия, из всех, кого я знаю. Он потратил много времени в беседах со мной, и в конце концов, ему удалось меня убедить, что заставить бизнес-модель AbiWord заработать будет чрезвычайно трудно. Затраты на исследование и разработку слишком высоки, чтобы упускать проект на сторону. После обсуждений с Хадаром, я принял решение прекратить разработку AbiWord в качестве нашего бизнеса. (На момент написания этой статьи проект AbiWord продолжает развиваться как общественный).
Полученный урок: инвесторы не любят бизнес-модели с малой прибылью.
После смерти AbiWord, наша компания стала задаваться вопросом: "и что теперь?" У нас был довольно удачный продукт для разработчиков, но мы хотели большего, и продолжили искать новые бизнес-идеи. Мы еще не были готовы отказаться от мира Open Source, поэтому решили применить этот танец для рынка программных инструментов. Нами был создан продукт под кодовым названием "RADish", который, по замыслу, должен был стать "Visual Basic-ом для Linux". Достаточно сказать, что идея не жила слишком долго. В большинстве своем VB применяется как средство быстрой разработки приложений в корпоративном окружении. Linux тогда (да и сейчас) еще не проник в эту область. RADish был создан для решения проблем, которых почти ни у кого не возникало.
Полученный урок: рынок без конкурентов — не рынок.
Сейчас это кажется древней историей, но во времена AbiWord и RADish я действительно хотел привлечь внешние источники финансирования. Я видел, как мыльный пузырь доткомов приводит к обалденному росту оценки компаний, и тоже хотел включиться в эту игру. Я разослал свои бизнес-идеи самым разным инвесторам. Когда это не сработало, я решил нанять кого-то со стороны для мобилизации внешнего капитала. Это обернулось крупной ошибкой.
Мне нужно было спросить совета у Дага Колбета. До того, как основать собственную компанию, я работал в SpyGlass, где Даг был президентом. Во времена акционирования SpyGlass Даг с юмором объяснял нам иерархию величайших подонков в мире:
Конечно, не все инвесторы из числа банкиров настолько никудышные. Но все же есть какая-то ирония в том, что шутка Дага обрела долю правды в моем случае. Когда я находился в ореоле своей "акционерной компании", со мной связался один парень, чья фирма специализировалась в размещении частных капиталов для небольших компаний. В итоге я подписал банковское соглашение с этим парнем: он обещал связать нас с некими инвесторами, у которых полно денег. Как вы уже, наверное, догадались, мы так и не нашли ни одного инвестора с его помощью.
Полученный урок: негативный смысл слова "посредник" часто является заслуженным.
Верите вы этому или нет, но история продолжилась еще хуже. Я не заставил своего поверенного просмотреть этот контракт, и в нем обнаружилась большая проблема. В итоге нам пришлось заплатить этому парню $40 000 для того, чтобы расторгнуть соглашение.
Полученный урок: все контракты должны просматриваться юристами. Без исключений.
Я бы хотел, чтобы история с банковским пронырой оказалась моим худшим финансовым решением. К сожалению, это далеко не так.
Осенью 2000 года мы надеялись выйти на рынок высокотехнологичных веб-сайтов. Кто-то познакомил нас с новоиспеченным печатным журналом, имевшим большие планы расширения. Люди, создающие журнал, искали как инвесторов, так и партнера по технологии, который поможет им перенести свой журнал на Web. Мы решили стать и тем, и другим.
В результате сделка обернулась финансовым кошмаром. Они так и не нашли больше ни одного инвестора. Они так и не заплатили нам за фазу 1. Фаза 2, разумеется, так и не наступила.
Полученный урок: деньги должны перетекать к вам от ваших клиентов, а не наоборот.
Не все мои идиотские действия связаны с финансами. Каким-то образом мне удалось выкроить время и для нескольких технологических ляпсусов.
После провала с текстовым процессором и изданием журнала мы решили: возможно, пора сфокусироваться на том, в чем мы действительно разбираемся - на программных продуктах для разработчиков. Все это время нашим титульным продуктом оставался SourceOffSite. В конце 2000 года мы решили создать новую версию этого продукта с поддержкой совместной работы. Продукт (который мы продаем и сейчас) было решено назвать SourceOffSite Collaborative Edition, или, вкратце, "Collab".
Вообще-то у Collab были уже тысячи покупателей, которым, он, в-основном, нравился. В конце концов, это неплохой продукт. Самая главная проблема — то, что мы затратили на его создание слишком много времени. Мы построили чересчур развитую платформу для его поддержки, вместо того, чтобы довольствоваться готовыми платформами.
Все стало для нас очевидным на PDC-2001. Выслушивая посвященные Microsoft .NET презентации, мы внезапно осознали, что создали с нуля свою собственную реализацию Web-сервисов, полностью несовместимую со всеми остальными.
Полученный урок: маленкие софтовые фирмы должны создавать приложения, а не платформы.
К моменту написания этой статьи со времен PDC-2001 прошло всего два года. Сейчас понятно, что это событие было тем моментом, когда многие полученные мной уроки наконец-то начали работать. Сразу после той конференции мы приняли много верных решений о направлении развития компании. Мы перестали создавать софт на заказ, что позволило сосредоточиться исключительно на собственных продуктах. Мы решили создать Vault, который приобрел большую популярность. С тех пор SourceGear обрела свое собственное лицо. В будущем мы вступим в новые соревнования и вновь попытаемся выяснить, на какие риски мы готовы пойти.
Как видите, я совершил несколько глупых ошибок, и пошел на некоторые риски, которые себя не оправдали. Эти ошибки неразрывно связаны с моим успехом и составляют мою историю. Говоря по правде, у любого президента компании найдутся в запасе такие истории. Если рассказать их все, мы почти наверняка увидим, что успехи и неудачи сильно взаимосвязаны, как и сказал Уотсон.
Надеюсь, вы прочитали эти истории и сказали себе: "Я могу действовать лучше!". Эти рассказы являются моим вкладом в подавление страха неудачи. Как сказал Скобл, нам нужно больше софтовых компаний, а не меньше.
Эрик Синк является не легендарным основателем SourceGear, компании по производству ПО для разработчиков, расположенной в Иллинойсе — месте с самой худшей погодой на земле (по крайней мере, он сам так говорит). Адрес его блога: http://software.ericsink.com/.
| Сообщений 50 Оценка 841
[+1/-0]
Оценить
|