понедельник, 11 июня 2012 г.

Обзор Дилеммы Инноватора

Ссылки: озон, амазон.



Представьте такую ситуацию: вы работаете в компании с 5-10-20-50-100-летней историей, которая монополист (лидер) своего рынка. Вы и ваша компания все делаете "правильно" с точки зрения менеджмента: слушаете клиентов, знаете их от корки до корки и наперед их знаете, какая фича им нужна. Проводите маркетинговые исследования, реализуете только нужные и доходные фичи или продукты,  а те которые не нужны клиентам не делаете и не тратите на это бюджет.

В общем, пришли к успеху и это признано всем миром. И не стагнируете! А действительно планомерно развиваете свой продукт делая его все лучше и лучше!

Но, внезапно, через 5-10 лет находиться мелкий дерзкий конкурент, который захватывает весь ваш рынок и выкидывает вас с рынка или просто оставляет банкротом. Удивительно и невероятно, не правда ли? Десятки лет опыта на рынке, крепкие связи с клиентами, а вы проиграли какой-то мелкой рыбешке

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

Кто же виноват и как это случилось ?

В этом виноваты разрушительные(disruptive) технологии. В момент когда они появляются они НЕ составляют конкуренцию основному рынку, т.к. они обычно дешевле, проще(и при этом еще и менее производительны) и проще в использовании.

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

И вот инженеры, которые изобрели этот продукт отчаявшись, что в их детище компания не вкладывает деньги уходят из нее и открывают свои фирмы. И начинают искать тот рынок где были нужны лучший по критерию Х продукт (забавная аналогия из книжки про Джобса, нецарапающееся стекло для айфона никому нафиг не было нужно и было слишком дорогим для производства пока Джобс не начал делать тач-скрины, его умела производить ВСЕГО 1 фирма в мире).
Нишевой продукт находит свой рынок и полностью его захватывает. Лидеру рынка не интересна эта маааааленькая ниша, т.к. по плану то надо расти на 20% в годов, а на маленьком рынке на 20% в год не вырастешь и потому их игнорируют. Лидеры смотрят на большие и более высокоприбыльные рынки(например миграция от продажи десктопных жестких дисков к продажи жестких дисков в мейнфремы(сервера), т.к. там больше маржа дохода.

А так как основной рынок то - вот он на виду то нишевой фирме, то хочется попасть и туда)

Постепенно нишевой продукт  развивается и по остальным критериям и ВНЕЗАПНО оказывается достаточного качества, чтобы конкурировать на основном рынке(за это время  конечно продукт на основном рынке стал ЕЩЕ лучше по своим основным критериям, но он уже ОПЕРЕЖАЕТ необходимый уровень качества на рынке).

Таким образом, на рынке появляется "good enough" продукт по основным критериям + гораздо более лучший по своим нишевым и рынок начинает оценивать наличие этих качеств, как более выгодное. Лидер рынка может даже быть рад избавится от каких-то низкомаржевых бизнесов, т.к. они за это время сами продвинулись вверх по рынку и под ними образовался вакуум в которой затянуло эту самую нишевую компанию.

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

В книжке это рассмотрено на примере индустрий: сталелитейной, экскаваторной, жестких дисков и других. Все очень подробно документировано и расписано.

Реальный пример:
Чтоб не быть голословным вот пример из индустрии жестких дисков(т.к. она "history moving fast"), каждые несколько-десяток лет в ней сменяются лидеры и рынок захватывают стартапы.

1.Инженеры Seagate в 1985 изобретают 3,5 дюймовый диск, в это время рынком доминирует 5,25 дюймовые(самым большим производителем которых и является Seagate).

2.Маркетинговый отдел опрашивает самых важных клиентов относительно новой технологии, клиентам как-то не особо интересно. Дальнейшие активные исследования заворачиваются.

3.Компания инвестирует в существующие технологии. Клиенты их за это любят и дают им много денег. 1)Технология существенно улучшается, 2)продажи растут, 3)профит!

4.Появляются новый компании(созданные бывших инженерами традиционных компаний).Методом проб и ошибок они находят новые рынки для своей продукции. Бывшие инженеры Seagate`a основали Corner Peripherals. Компания фокусируется на 3,5 дюймовый дисках, для них находиться рынок ноутбуков/портативных компьютеров.

5. На рынке появляются новые игроки. Производительность, объем и т.п. 3,5 дюймовых дисков постепенно позволяет им конкурировать с 5,25. 3.5- дюймовые диски начинают появляется в персоналках. Corner Peripherals вытесняет Seagate из рынка 3,5 дюймовых дисков для персоналок.

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


А происходит это не из-за недальновидности и глупости руководителей, а потому, что:


1) В хорошо управляемых компаниях на само деле КЛИЕНТЫ диктуют. куда будут вкладываться ресурсы. Лучшие инженеры, менеджеры и т.д. уходят в развитие основной технологии. Менеджеры даже не могут инвестировать в новые технологии потому, что это экономически не целесообразно и их проект просто зарубят.


2) Малые рынки не могут удовлетворить потребностей в росте больших компаний. Компании с 10 миллионами дохода, чтоб вырасти на 20%, надо заработать в следующем отчетном периоде - 2 миллиона, компании с 1000 миллионов дохода надо заработать  - 200. Зарождающиеся рынки такого не могут дать.


3) Несуществующие рынки нельзя проанализировать. Применение разрушающей технологии нельзя предсказать, возможность провала всегда существует.


4) Возможности технологии не всегда равны требования рынка. Технологии могут развиваться быстрее, чем требуется и таким образом отстающая технология может нарастить свои параметры качества.


Итого:
До определенной степени это применимо к любой технологичной компании будь она софтверной или производственной.
 
Тот же пример с
Apple показывает, что имея всего лишь преимущество "удобства" можно подвинуть Микрософт и многих других.

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



Или, может быть, вы работаете в стартапе? Тогда нужно поискать рынок, куда конкуренты нет смысла соваться и сделать лучший продукт - там. А потом дорастить его до конкуренции с основным, не теряя своих отличительных черт.

суббота, 2 июня 2012 г.

Доклад на Addconf про Riak.


С месяц назад сделал докладик на addconf.ru.

Видео: http://vimeo.com/42619422
Слайды - http://www.slideshare.net/IlyaBogunov/riak-add-presentation.

Про доклад:

Рассказывал про dynamo-based Riak. http://basho.com/products/riak-overview/.

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

Тут можно задать вопросы, если они есть по теме доклада - отвечу.

Про само выступление:

Во время выступления конечно все, что читал про правильные выступления забываешь) Рассчитанные сроки выступления съезжают, неудоменные взгляды аудитории заставляют комментировать некоторые моменты и т.д.
В следующий раз буду рассчитывать, чтобы треть времени была свободна, т.к. все равно найдутся неучтенные моменты(да, на видео я не дошел до последних слайдов с призывом к действию и вопросами/спасибо =))

После просмотра видео со стороны видно, какое гигантское количество паразитных слов все таки произносишь =) Могу заметить с 10к ошибок, которые я совершил =) Но было весело и интересно)

По крайней мере из зала особо много народу не ушло значит рассказывал не полный бред и достаточно интересно) И люди даже комментили, что в общем то говорит, что доклад ушел не совсем в пустоту)

Хотя, если честно вопросы после конференции задали, либо те кто уже используют что-то похожее (либо его же), либо что-то что, как раз, хреново масштабируется и нужно именно это. Но по количеству вопросов ясно, что тема нужна 5-20% разработчиков от силы(да, не заводиться у нас пока стартапов, которые, как в Америке вырастают за 2 месяца до нескольких миллионов пользователей).

воскресенье, 22 апреля 2012 г.

Предпренимательство по научному!(отзыв на Lean Startup)

Amazon

"There is surely nothing  quite 
so useless as doing with 
great efficiency what should 
not be done at all." 
Peter Drucker 

Обязательное чтение для каждого, в ком есть кроха предпринимательской крови =)
Если еще лет 20-30 назад предпринимательство и инновации считались искусством, то сейчас - это четкий научный процесс с метриками, опытами и всем таким) И чтобы стать Стивом Джобсом не надо быть гением со звездой во лбу, а следовать простым и понятным принципам.
Что это за правила и откуда берется планомерный процесс создания нового бизнеса расскажет Эрик Райс в своей книге "Lean Startup".
Имхо, по полезности она граничит или даже равна "4 шагам к озарению", которая тоже затесалась в мой личный топ книг)

В чем суть любого стартапа (да и вобще начинающегося бизнеса) -  в том, чтобы найти проблему, которую нужно решить, клиентов, у которых есть эта проблема, и попутно создать новую бизнес модель(т.е. ПОВТОРЯЕМЫЙ процесс зарабатывания денег)
.
Так как заранее не известно, кто станет вашими клиентами, какую проблему надо для них решить и каким образом, то основная задача стартапа - выяснить эти 3 неизвестные.
Т.е. стартап - это процесс поиска потребителей и их проблем, и эффективность его равна тому, с какой скоростью он может обучаться, предлагать гипотезы потребителей\проблем\решений, проверять и опровергать их. Фактически это исследовательская организация и настоящий "выхлоп" стартапа - это знания.

А для этого традиционные средства управления и менеджмента заточены очень плохо, и методологий, как исследовать новые бизнес модели - нет.Традиционный метод ученых - раздать гранты и надеяться, что один из них "выстрелит", -  ну очеееееень хлипкий и не подходит для такой ситуации.
Так что, правильный путь стартапа - это процесс создания "подтвержденного знания" (validated learning), через который предпрениматели смогут научиться создавать долгоживущую бизнес модель. Этот процесс отличается от учебы через fail`ы, которая жутко дорогая и не эффективная.

Стартапам нужен свой Build-Test(Measure)-RefactorLearn процесс, и свой continius integration  feedback(ура, инженерный практики идут в предпренимательство! =)), для получения постоянного обратной связи от клиентов и рынка. Анализируя информацию от рынка, надо решать продолжать ли с этой идеей или "свернуть в сторону"(pivot).

"Свернуть" можно по разному: расширить область решаемой проблемы, сузить ее, сменить сегмент клиентов,  платформу или технологию разработки и т .д. Не смог свернуть в ключевой момент, т.к. "на эту идею уже затрачено столько усилий", - вылетел в банкротство) Продолжительность жизни стартапа вобще равна тому на сколько "сворачиваний" хватит финансов) Стартап начинает с бизнес-модели -  "пробовать гипотезы и ошибаться до тех пор, пока не найдется рабочая бизнес-модель" =)

Кроме того, Эрик расскажет вам какие действительно должны быть метрики у стартапа. Растущая база пользователей - фигня! Вы же не способны купить себе и агамбургера с доходов от нескольких зарегистрированных пользователей ? Большинство стартапов гоняться именно за "тщеславными показателями" (vanity metrics) [черт-побери, я работаю в таком =)], для которых видимый прогресс в этих метриках - показатель успеха, не смотря на то, что платящая пользовательская база как была в районе 0-1% так и остается =) Эти метрики не показывают насколько удачно на самом деле работает стартап, успешно ли он обучается и близок ли он к своей цели - созданию повторяемого и растущего бизнеса.

Именно поэтому надо применять концепции "MVP"(minimal viable product) и концепцию малых очередей - сделать что-то и сразу проверить, а есть ли у этого покупатель, и готовы ли клиенты за эту фичу покупать про-аккаунты\оформлять подписки на сервисы.
Вполне может оказаться, что многие ваши предположения по поводу потребностей клиентов - ошибочны(так, например, оказалось в стартапе самого Эрика  - "IMVU"), и пользователи не будут готовы платить, пока вы не найдете этот самый value.

Именно это и есть "Lean Thinking", примененное к стартапу, - максимально быстрое обучение c быстрым избавлением от мусора(не подтвержденных и не работающих идей).

Если вам кажется, что это работает только в ИТ - это не так. Это работает даже в некоммерческих организациях, направленных на благотворительность. В книге есть множество примеров применения принципов Lean Startup для разных сфер деятельности и направлений .

Суммарно все эти принципы можно свести к пяти шагам:
1) Все что делает стартап - это обучение, создайте процесс обучения
2) Постройте MVP
3) Не тратьте энергию\ресурсы на ненужную деятельность - презентации\расширения рынка и т.д.
4) Проверьте свой продукт, войдите в цикл "build, measure, learn".
5) И будьте готовы свернуть =)

Идеи, изложенные в этой книге, подходят как стартапам, так и крупным фирмам, которые хотят не отставать на волне инноваций. Например, интересен кейс с Intuit(.com), который поставил себе цель "быть инновационным" и завел себе метрику "доход, который получен от продуктов  созданных менее года назад" и преуспел в этом направлении.

В общем книжка читается на одном дыхании и вызывает забавное и приятное чувство - "надо побежать и применить все, что запомнил пока в голове еще свежо". 

вторник, 10 апреля 2012 г.

Software people. День первый.

Побывал сегодня на softwarepeople, вобще конференция считается самая-самая айс на нашем пост-советском пространстве. 
Потому уже можно поставить себе ачивмент - "побывал на swp" =) 
Куча знакомых и не знакомых лиц, известные гуру и т.д., в общем хороший повод по социализироваться)

Коротко опишу доклады, на которых побывал и впечатления:

Мое мнение мне прям самому кажется излишне негативным. (так, что если что есть альтернативный источник субьективных оценок - отчет от Максима Цепкова)


Первым был доклад 
Джеффа Де Люка (Nebulon Pty Ltd) "Почему мы терпим неудачи. Разработка ПО в наши дни (Why We Fail. A Discussion of Software Development Today)"
Не хочется прям быть такой негативной сволочью, но чел был - Кэпом(тм).

Рассказал про то, чтоб все практики уже известны - код ревью, дизайн-ревью, автотесты и т.д. Надо иметь дисциплину и поддерживать их. 



Чуть-чуть рассказал про модель развития команды такмана - форминг-сторминг-норминг-перформинг. Рассказал об внесении изменениях и связанным с этим падением продуктивности, через что ажайл индустрия опять же уже прошла 100500 раз(например быстрое гугление "change chaos" дало данный линк).

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

После выступления решил, что хватит с меня иностранных докладчиков пошел послушать:
Сергей Высоковских (Нетвокс Лаб) Альтернативный метод визуализации хода IT-проектах

Сергей показывал способ визуализации хода проекта в виде эдакой военной карты наступления с штриховым\пунктирным кодированием прогресса задач, цветовым кодированием их типов, указания стрелочками порядков выполнения и т.д., эдакое проецирования прогресса на плоскость. Тема новая, но мне была не слишком интересной и потому я убежал слушать
Дмитрия Ханецкого (IBM) про "Эффективное управление жизненным циклом разработки ПО"
Дмитрий рассказывал про ibm jazz это эдакий комбаин, который позволяет тем или иным образом совместить в себе чуть ли не все продукты IBM от управления требованиями и моделирование бизнес процессов, до выполнения задач, проектирования, разработки, тестирования, отчетов, деплоймента и т.д.
С возможностью оттрасировать все и вся, что в принципе удобно.

Рассказывал про 100 миллионов строк в каком-нить софте для управленяи машиной, и 20ки миллионов для банков со всеми их регуляциями и правилами.
Для какого-нить банка или производителя автомобилей я думаю очень даже удобно и вполне себе решение, может даже применимо для компаний для разработки ПО, если вы готовы отвыкать от привычных жиры\редмайна. Для меня польза от доклада -  довольно сомнительна)

После послушал 
Василия Малинова (Oktogo.ru) про "Роль продукта в успехе привлечения инвестиций", увлекательно конечно узнать про размеры инвестий и на каких стадиях их дают, но не более того, видимо все существенное я пропустил пока искал, что-то более интересное (в главном зале в это время шла живая сессия БДД\ТДД, что в общем то то же не ново).

После Василия шел  Станислав Калканов (жж, там же есть ссылка на презентацию ) про "Управление инновациями в стиле Lean Startup", т.к. я был 1 из 3х-4х человек читавших книжку (думаю допишу по ней отзыв через неделю-другую, как будет свободное время).

Станислав сказал, что  - извините, буду рассказывать - основы, потому в общем-то провел основное время общаясь в калуарах, но судя по отзывам которые, я собрал тему он не сильно донес(т.к. книжку реально сложно уткнуть в 30 минут, да еще и с вводными), хотя тема реально интересная.

После был обед, к обеду претензий нет, он был вкусный)
Во время обеда с коллегами обсуждали ажайл\не ажайл, есть ли от него толк и польза и в  результате дискуссии (мы кажется были единственные кто громко ржал во время обеда) появилась мысль : "процесс, как средство позволяющее уменьшить мудаковатость соседней команды в 2 раза =)"

После обеда хотел послушать 
Дмитрия Евтеева (Positive Technologies) про "Собираем команду хакеров", да докладчик там чето долго колупался, а потом еще сказал ждем 5 минут, пока "что-то там".
Я решил, что лучше пойду пока кого другого послушаю, в главном зале шел Асхат Узарбаев с "Л
идерством в стиле Lean" (слайды) и хотя бы зажигательно рассказывал про свои любимые темы типа Лина, Ажайла, рассказывал про цикл Деминга PDCA, о том, что существенная часть команд останавливаетсья в развитии потому, что "итак вроде не плохо",  рассказывал про превращение работы в игру (сделай 20 тасков и получи ачивмент, стань программистом 80го уровня =)), в принципе идея не плохая тренд с бейджами и очками, вполне такой живой во всех социальных приложениях и игры, как средство получения фана от работы вполне себе идут.

После послушал 
Влада Балин(жж) (Финам) про "Разработку как процесс коллективного решения проблем".

Вот он рассказал классно, просто, понятно с примерами и вполне насущный вопрос: о том, что вся разработка ПО - по сути проектирование и как это проектирование делать правильно.

По сути разработка ПО - уже в будущем (по сравнению с материальынм производством), наше изготовление предмета занимает минуты (сборка-деплоймент), а не месяцы, как в обычном производстве: "Х времени придумывали схему устройства(проектирование), месяц ждали его изготовления(фабрика), пофикисли баги, поменяли схему(проектирование), еще месяц ждем(фабрика)" и так пару циклов.

У нас же сборка\выкатка - дело минут, тестировать можно сразу и фактические единственное, что осталось - это ТОЛЬКО проектирование.

А проектирование - это решение конкретной проблемы пользователя, ну по сути пользователи ВСЕГДА прибегает с РЕШЕНИЕМ своей проблемы - "нужно переписать риск-сервер!"(реальная проблема: в риск-сервере 10 критичных багов, их фикс займет 3 дня), "нужно сделать все на .net"(реальная проблема: никто не хочет лезть в этот код на дельфи), чаще всего пользователь даже хорошо знает о своих проблемах, просто сразу предлагает свое решение, и зачастую не самое оптимальное.

После того как проблема определена, наступает обычный инженерный этап проектирования:
- найти ВСЕ возможные варианты
- оценить их затратность, побочные эффекты и т.д.
- откинуть невозможные
- выбрать получше
а не сразу "переписать риск-сервер" =)

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



После послушал Андрея Сикорский (РИА Новости) про "Вниз по «скунсовой норе» или как внедрить UX в разработку".

Андрей рассказал про уровние юзабилити в вашей компании, (оригинал рассказал -
http://www.useit.com/alertbox/maturity.html), дал метрики индикаторы, как посчитать на каком вы уровне, + рассказал, что в принципе предшествует внедрению юзабилити в компании(падение продаж, отток пользователей, и т.д.).
Рассказал откуда его можно начинать внедрять(либо по партизански, либо имея чемпиона "бегемота" - большого босса, который скажет - "что за Х у вас тут твориться !?"), в общем интересно, НО "маловато будет")

После пошел слушать Сергея Минюрова про "Семантическая формализация требований: опыт построения проектной базы знаний", но докладчик был настолько скушен и не смог за первые 5 минут внятно донести - ни какие прям вот реально насущные проблемы со сбором требованиям у меня есть, и как их так прям резко можно решить его чудесным способом, что я просто ушел слушать Виктора Кузьмина (AlterGeo)  про то "Как выстроить разработку сервиса под несколько мобильных платформ".
Было довольно интересно. Рассказали зачем вам вобще мобильное приложение, что оно дает вместо допустим сайта(гео-* штуки, адресная книга), какие проблемы могут возникнуть.

В  кратце:
они поделили свое приложение на апи(версионное), приложение(опять же версионное) и фронт-энд, приложение имеет внутри себя стандартный BrowserController, и по большей части грузит себя через него, чем позволяет вполне себе так живенько обновляться приложению, без длительного процесса обзора в аппсторах, закачек клиентом новых версий и т.д. Ну и заодно можно поддерживать очень древнии версии своего приложения, чтоб пользователи не писали гневных отзывов мол: "два года работало и сломалось".

Пользователи (вот ведь подлецы) существа ленивые и вот прям не очень то хотят обновлять свои приложения и потому их надо мотивировать:

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

Рассказали про свои проблемы с приемом в эппловский апп-стор.

Последним был 
Руслан Мартимов (General Satellite) с докладом "Death march projects и развитее разработки в компании", рассказывал хоть и очевидные вещи, но вполне живо: придется рубить углы, команда важна, безнадежный проект - хороший повод посмотреть, где у вас узкие места, чтоб сделать работу эффективнее. Извлек из доклада спорную мысль "Deathmarch, как двигатель прогресса" =)

четверг, 5 апреля 2012 г.

Прочитал "Eric Sink on the Business of Software"

Амазон


Довольно интересная книга - рассказывает, как развивать бизнес по разработке По(в данном случае массового, а не заказного). Думаю, было бы полезно всем тем, кто хочет делать свой стартап\уже пилит его по ночам\планирует написать новый веб-сервис или айфон-приложение)
Я почерпнул из нее некоторые основы финансового учета, маркетинговые концепции типа loss leader и еще пару-тройку полезных фактов и мыслей по схожим темам.

Эрик имеет свой бизнесс и пишет исключительно о своем опыте. Некоторые моменты довольно сильно привязаны к области его деятельности и проблематике, но узнать, с чем придется столкнуться во время своего свободного плаванья в мире предпринимательства, будет полезно.

Хотя автор книги и занимается десктопным софтом (в частности разрабатывает систему управлению версиям, да-да не все пользуются git`ом и svn`ом =)), но его советы касаются достаточно общих вопросов предпринимательства, работы с людьми, маркетинга и продаж.

Если б я в свое время не читал "Четыре шага к озарению" и прочие ..., то эта книга кардинально бы раскрыла для меня многие моменты, а так она позволила мне еще глубже понять, что разработать и придумать продукт - это 20-30% работы, а найти для него аудиторию и продать - все 70-80%.

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

Поэтому автор советует не соваться в те области, где объем рынка достаточно велик, чтоб заинтересовать Микрософт, Оракл и другие крупные фирмы. Что кажется контр-интуитивным, но несет немалую долю смысла =).

Секция предпринимательства начинается так :
Автор предлагает начать с таких простых вещей: как оценка - а потянешь ли ты ?) А что делать если дело прогорит ? Есть ли запасной план ?
Посчитать насколько большой рынок ты пытаешься захватить\создать, поделить это на  5-10 раз, т.к. все равно ошибешься. Потом посчитать во сколько обойдется создание первоначальной версии хотя бы на первый год, учитывая ВСЕ мелочи(даже кофе, телефон, не говоря уже об арендной плате) и соответственно подвести баланс, сколько денег ты ПОТЕРЯЕШЬ за первый год( и это еще хорошо, если зарплату никому не надо платить, себе ведь можно платить - 0), т.к. скорее всего дохода не будет, или он будут очень мизерный.

Потом идет секция бухгатерского учета для гиков) Что такое Income statement\Cash Flow Statement \какой должен быть Profit Margin (читал в оригинале, потому не знаю русских аналогов).

Автор начинал свою компанию  в одиночку  (в параллели с основным бизнесом) и заваливает ее, переоценив рынок и переоценив насколько полезна "Отличительная особенность" продукта от другого похожего софта (он писал солитер, который всегда можно выиграть).
В общем, совершил кучу ошибок)
Автор удивляется, как можно стать довольно успешным, как он, совершив СТОЛЬКО ошибок) И тут же говорит - совершайте их побольше)

Вторая часть, как я уже говорил про подбор сотрудников: там рассказывается, как выбирать разработчиков( а не "программистов" и "кодеров"), которые могут решить большее количество проблем и не прочь замарать свои руки тем, что нужно бизнесу, а не разговорами "я не продаю\общаюсь с пользователями\занимаюсь исследованием рынка\и т.д.". Звездный программист не всегда лучший работник для вашей компании.

Рассказывает он и о том, как набирать продавцов и что это должны быть за люди. Не буду пересказывать всю книгу, а то вы ведь не станете ее читать)

Ну и соответственно 3я и 4я четверть повествуют о маркетинге и продажах. О том, как найти свою нишу, о поиске проблемы и идеи для ее решения. О том, что в сущности технология - очень малая часть решения той или иной проблемы. Как провалидировать свою идею, как оценить, сколько времени она займет, как понять, кто будет ее покупать и нужен ли тот, кто ее будет продавать. О том как выбирать конкурентов, и о том, что отсутствие конкурентов - ОЧЕНЬ плохой знак. Естественно, не обошлось без упоминания и о пропасти между энтузиазистами и прагматиками\консерваторами. О том, как выбрать технологическую платформу и почему это решение с точки зрения бизнеса, а не вашего личного предпочтения.

Кроме того рассказывается о том, как ходить на конференции\торговые выставки в выбранной  области, как оформлять стенды("выйграй айпад" особо популярно в последнее время =)), как заказывать рекламу в журналах и интернете.
Естественно к этому прилагаются советы по продажам, ценообразованию и т.д.

В общем этакий "how to о создании бизнеса по разработке софта за 10 простых шагов", думаю поможет всем, кто завязан в нашей Ит-шной области, чтоб понимать, чем занимается он сам или его коллеги.
Скорее всего кому-то вроде продакт менеджера в достаточно крупной компании типа  Abbyy\Parallels`а данная книга ничего не расскажет.
Зато она написана в достаточно интересном и ироничном стиле с кучей метафор, что даже прожженный продажник поймет, что такое разработка софта, а бородатый программист поймет зачем нужны маркетинг и продажи и "чем занимается эта куча менеджеров, вот программисты то понятно, чем занимаются" (ц) цитата коллеги, из моего прошлого =) 

понедельник, 2 апреля 2012 г.

Отзыв на биографию Стива Джобс От Уолтера Айзексона

Ссылка на Озон

Пока Эппл еще на волне интерес к личности Стива Джобса и созданной им компании есть, так что почитал с удовольствием и узнал многие факты, которые слегка поколебали мое текущие понимании мира.

Из жизни Джобса мне было известно только по "Пиратам силиконовой долины", так что, как можно создать такую компанию и каким человеком был Джобс узнать было довольно увлекательно.

Мне вот, например, было неизвестно, что Джобс оказался брошен в свое время родителями (и был приемным сыном) и это повлияло на всю его судьбу и ощущение особенности.

Что в студенческие годы он увлекался кислотой и просветлением сидел на всяческих фруктовых диетах, не мылся неделями, т.к. считал что его просветление и диеты делают его "чистым", не смотря на все недовольство окружающих) Был исключен из колледжа, но продолжал ходить на интересные ему курсы, считал себя бунтарем, но при этом все стремился продавать и был вобще таким предпренимательского типа человеком. Успел поработать техником в Атари и там научился, что такое бизнесн и как быть бизнесменом от ее владельца. Искал просветления, ездил в Индию, принимал странные диеты, да и вобще вел дикий образ жизни и т.д.)

Саша Панкратов и Слава Орлов учат, что софт скиллз и умение наладить отношение с людьми - это в нашем мире почти все) Но вот Джобс вобще делил людей на гениев и идиотов, беззастенчиво опускал своих сотрудников и коллег, был чрезвычайно высокомерен, да и вобще на приятную личность не особо тянет. Но при этом мог мотивировать словами, не что нужно конкретному работнику(там деньги, карьеры, признание и т.д.), а мы - "чувак да мы с тобой поменяем мир!" =)
В общем почти антипример всех книг по софт-скиллз, управлению людьми и т.д.)

Но вот из-за своего маркетингового и сейлз-талантов, личной харизмы и стремления к совершенству таки создал компанию мирового уровня.
В самой компании считали что у Стива есть "Поле искажения реальности", т.е. они приходил и настолько увлеченно убеждал в своей идее, что все с ним соглашались, а когда он уходил все понимали, что согласились на что-то невероятное, невозможное и безумное.
В общем после книжки реально начинаешь верить, что маркетинг - это наше все)

Сейчас кажется, что Эппл всегда была великой и хорошей, но на этом пути она успела завалить кучу проектов: apple lisa, macintosh portable, apple messagepad и т.д., причем в эти моменты шла война между внутренними офисами и Джобс сам подрывал продажи некоторых своих продуктов, т.к. они были сделаны не по его мнению.

Джобс ныл и плакал, предавал друзей, например со-сонователя Эппла - Стива Возняка, после того как тот ушел из Эппла и основал свою компанию, по производству пультов дистанционного управления, Стив звонил его поставщикам и угрожал, что Эппл разорвет с ними контракт, если они и дальше будут ему поставлять компоненты. Он был раздражительным и несдержанным. Джобс втайне готовил заговоры, чтоб сместить неугодных ему людей из менеджмента и боролся за власть с советом директоров, за что его сначала сместили с управленческих должностей, а потом он ушел из Эппл. Он называл людей критинами, а их идеи - идиотчкими, но через пару дней обдумав, говорил что его посетила гениальная мысль и выдавал идею за свою)

Его стремление к идеальному дизайну иногда выходило ему боком(вспомним нашумевший случай с антенной Айфона, когда из-за дизайна сделали не всегда работающую конструкцию, хотя инженеры сказали, что так делать нельзя). И как Джобс выкрутился из нее сказав, что " Мы несовершенны. Телефоны несовершенны. Все мы это знаем." =)

Еще в книге упоминается конечно же работа в Pixar и выпуск "Истории игрушек", борьба и сотрудничество с Диснеем. Его возвращение в Эппл разработки иподов, ифонов и айпадов, о том какие они офисы создавали, чтоб поощрять креативность и коммуникации, как ни странно отдаленно напоминает Scrum/Agile и все такое с тесно-интегрированными, постоянно общающимися командами.


По прочтению сложилось двоякое впечатление: "как ТАКОЙ человек мог создать столь успешный бизнес ?", и вторая мысль: "вот же оно как бывает, тут есть чему научится" =)

Upd. В частности, что софт-скиллз, пипл-менеджмент и все такое бывает разный, кто-то умудряется личной харизмой и упорством покрыть все свои недостатки, выжимать из людей все соки, но заставлять добиваться прекрасного результата. Хотя задним числом люди будут считать это издевательством, и будут уходить не выдерживая, но результат будет получен.

Не все смогут такое провернуть, я даже не совсем уверен, что знаю хоть 1го человека, кто на такое способен. Но, что такое возможно, и что это в принципе повторяемо - да.

пятница, 30 марта 2012 г.

Тони Бюзен. Супермышление(The Mind Map Book)

Ссылки: Озон. Амазон

Еще в феврале дочитал данное творенье. Но, что-то все не было времени написать отчет.

Давно был наслышан о технике и даже имел какое-то свое представление, но довольно ущербное. Что-то вроде: "хитрые визуальные иерархические списки". Решил таки просветиться и grok`нуть что-же это такое)

После прочтения стал понимать некоторые концепции работы этой методики :
- использования цветового кодирования и картинок для усиления ассоциаций
- и использования визуальных методов для более компактной записи и соответственно более быстрого чтения
- ну и возможность спускаться вверх\вниз по иерархии для изменения уровня детализации.

Теперь о самой книге и ее авторе:

Не буду рисовать майнд-мап а нагло воспользуюсь списками =)

Недостатки:
- Автор приписывает изобретения концепции себе, хотя техники типа concept map, существуют еще с 70х, уже дает повод для беспокойства.
- Очень много продажи, очень много преувеличения типа: этот метод сделает вас гением, позволит повысить продуктивность в 10 раз, решит все ваши проблемы и проблемы человечества и т.д. Может я конечно дурак, но просветления не получил =)
- Автор использует псевдо-научные(ну или как минимум уже опровергнутые факты) типа ваш мозг работает на 10%, если равномерно нагружать левое и правое полушарие то вы станете гением и т.д.)
- Очень много повторения, повторение конечно помогает запомнить и все такое, но постояно возникающий вопрос: "разве я это еще не прочитал ?" вызывает жесткое желание пропустить 10к-другой страниц)

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

Итого:
Если честно слегка разочарован, поверхностное понимание вроде бы теперь есть, но вот прям чтоб применять их везде и всюду как-то не тянет.
С другой стороны, как визуал рисовать диаграммы и связи я и так привык, так что вот прям Америку для себя я не открыл.
Думаю как-нибудь найду что-то более научное и полезное по данной тематике. Советы и рекомендации приветствуются)