Абстракция всего.

Ноябрь 11th, 2008

Сегодня пообщался с Романом Поротниковым и обсудили кое какие схожести игры ГО и программирования, а потом обсудили, что хоть схожести и есть, подвести под них общую базу не удается.

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

Как пример, ну предположим программист стал играть в футбол и вот он замечает, что мол в программирование есть команда, и в футболе есть команда. В программирование есть цель и в футболе есть цель, скажем что не играя в пасс — в футболе проиграешь и также не сотрудничая с другими программистами проект не закончишь. И вот начинает, человек за уши тянуть все эти абстракции.

Вроде цель понятна, нафига тянут за уши. Так как если они подводят под одну базу обе вещи, то могут развиваться в обоих областях гораздо быстрее.

Но, лично как по мне, дальше чем схожесть в нескольких пунктах и может быть схожесть общего мышления не стоит лезть, так как есть две проблемы объединения:

О первой писал Джоэль — Закон Дырявых Абстракций. Чем больше абстракция, тем на самом деле она менее точная, особенно когда пытаешься применить детали. Ну и как вы понимаете, чтобы накрыть программирование и футбол одновременно, абстракция должна быть действительно большой.

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

Роман очень точно подметил, что после натягивания абстракций, по ним очень хорошо пройтись бритвой Окамма. Чаще всего оказывается, что половина абстракции явно лишние и не приносят никакой пользы/упрощения. А после их удаления оказывается, что внутри абстракции остались те самые 3-4 похожие пункта, которые мы подмечены с самого начала.

В общем, как по мне — играя в футбол, лучше играть в футбол, программируя — программировать. И не стоит пытаться скрещивать удава с ежиками.

Ох уж это Palm.

Ноябрь 9th, 2008

Где-то в 2000 году,Palm был мощнейшей компанией. Номер один игрок на рынке PDA и постепенно присматривающийся к только зарождающемуся рынку смартфонов. И вот, по прошествии 8 лет, их акции котируются всего лишь в 150 раз меньше, чем в том самом 2000 году, да и вообще компания достаточно в плачевном состоянии.

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

Ошибка N1:

В 2002 году, кому-то в Palm пришла замечательная идея в голову, которую они озаглавили что-то типа «Some ideas are just too big for one company». И взяли и разделили компанию на две — одна производящую софт (PalmSource), другую производящую hardware (PalmOne).

Хоть убей не понимаю, чего они хотели этим добиться. У меня сложилось такое впечатление, что они и сами не поняли, но самое важное, что они получили две компании, которые жизненно зависят друг от друга, но не могут влиять на конечные решения своей «сестринской компании». То бишь, hardwar’у нужен software, а software нужен hardware, как самый больший покупатель их софта.

То есть риски выросли у всех, операционные расходы выросли, прибыли остались та же. Где же, блин, выгода?

Ошибка N2:

В 2004 году, PalmSource (та, что производила софт) выпустила новую версию PalmOS 6.0 и вот тут где-то нашла коса на камень и PalmOne решила НЕ покупать у них эту версию. Как у меня сложилось впечатление, из-за того, что в PalmOne уже кипела идея самим писать софт и сделать самим Linux based PalmOS.

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

Ошибка N3:

PalmSource в 2005 решает продаться, так как деньги за лицензирование ей уже не светят и продается ACCESS. А вот PalmOne хлопают ушами и решают не покупать PalmSource (думаю в тот момент еще могли). Но, на секундочку они забывают, что они все еще производят устройства на софте, который писала PalmSource и что теперь уж точно им дороги назад не будет и придется свою операционку добивать.

Ошибка N4:

Тут я не совсем уверен, что это ошибка. Это скорее даже не ошибка, а обоюдоострая игра. PalmOne в 2006 выходит на рынок с Windows Mobile продуктами. Польза этого была в том, что ей эти продукты стали приносить деньги (в тот момент как Palm продукты постепенно идут на дно), вред в том, что они стали распыляться в трех направлениях — выпуск старых PalmOS устройств, выпуск WinMobile устройств и писание своей Linux операционки.

Ошибка N5:

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

Получается, наступив на грабли в ошибки 1, 2 и 3 обнаруживается, что уже не остается ничего больше, чем наступить еще раз на грабли, заплатив $44M за то, что до ошибки 1 и так принадлежало им.

Ошибка N6:

PalmOne решает открыть еще один флаг «войны» не закрыв не один предыдущий. Этот фланг называется Palm Foleo (эдакий субнотебук). Да, я согласен Jeff Hawkins гений и дважды попал в точку (с Palm’ами и позже с Treo), но тут мне кажется он серьезно промазал. Но важнее даже не просто промазывание, а то, что при этом было на проект утащено куча ресурсов, которые и так делились уже между тремя направлениями.

Да, собственно говоря, я несколько раз говорил о деление ресурсов, потому, что Palm — это не гигант, а компания из 1000 человек , что в целом при деление на 3-4 направления становится уже не слишком большой цифрой.

И в 2007 году Foleo отменяют, когда становится понятно, что он не слишком интересен покупателям и и достаточно сырой для выпуска.

Ну из остальных, не столь весомых ошибок.

Я бы назвал то, что уж очень мало инноваций за период 8 лет они сделали. По большему счету тот самый Jeff Hawkins придумал Palm и потом его в течении 10 лет обсасывали в разных дизайнах, потом он же внутри Handspring придумал Treo и Palm купив целиком компанию, продолжила обсасывать Treo в течении уже 5 лет.

В целом, просто жалко смотреть, как компанию буквально спустили в туалет, ошибками которые видны не только по прошествии 5-8 лет, но о которых мог рассказать любой пользователь Palm’а чуть ли не ДО совершения этих ошибок.

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

Компанейская архитектура и продуктовые идеи.

Ноябрь 3rd, 2008

У меня была статья в которой я уже начал описывать структуру компании, так как я ее вижу.

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

То, что я видел в нескольким компаниях в штатах, это достаточно странный метод выбирания, что делать. Само собой идеи сыпятся со всех сторон — от заказчиков, от менеджмента, от разработчиков, что в целом нормально.

Вопрос только, заключается в том, что

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

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

в) Метод выбора идей зачастую базируется на том, кто «громче кричит» (и тем самым привлекает внимание менеджмента).

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

В этом случае, вполне понятно, кто в конечном счете отвечает за принятие решений и на основе каких параметров они принимаются.

Вопросы по партнерству

Ноябрь 2nd, 2008

На днях должен встретиться, обсудить потенциальное партнерство в одной идее.

Подготовил список вопросов, ну и чтобы добро даром не пропадало. Решил обобщить и запихнуть сюда

а) Почему нравиться именно эта идея, что в ней такого привлекательного? Не слишком ли широкая/узкая ниша у идеи?

б) Что с финансированием?

Собирается ли человек вкладывать какие-то свои деньги (если да, то какого порядка)? Собирается ли искать инвесторов (если да, то когда).

в) Моя роль в бизнесе?

Что мне понадобится делать в начале? (В целом и так ясно, что придется — педалить :), но хотелось бы знать, какой порядок приоритетов следующих задач — архитектура, написание кода, поиск программистов и тестеров, управление ими, code review, разгребание технических сложностей и т.п.

г) Чем собирается заниматься в это время он?

Д) Какой критерий неудачности?

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

Е) В случае удачи, как перераспределятся роли? Кто за что будет отвечать.

Ж) Ну и само собой Какой % компании он готов дать за мои услуги? Дополнение от Dyatel: В каком виде выдается % компании (это влияет на exit strategy).

З) От Dyatel: Минимальное контрибуция каждого участника.

И) От Stanislav Malkin: Как обстоят дела с бизнес планом.

К) От Stanislav Malkin: Тип бизнеса.

Кстати, если я что-то пропустил — пишите.