О мышах и ежиках, моделях разработки и квакерах в контексте FOSS Sea 2011

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

Одной из самых первых (и самых больших) из моих ошибок в самостоятельном бизнесе было сотрудничество с одной крупной аутсорсинговой компанией с целью совместной разработки продукта. Идея была в том, чтобы объединить нашу экспертизу в области биллинговых систем и ресурсы крупной компании, выпустив на рынок современный продукт. Разработка велась около двух лет, после чего проект был закрыт без выпуска какой-либо версии.

Этот провал обогатил меня, кроме всего прочего, еще и пониманием различий продуктовой и заказной разработки, который можно кратко выразить следующей формулой: в аутсорсинге человеко-час, потраченный на разработку — это прямая прибыль, в то время как для продуктовой разработки — это прямые убытки. Эти две бизнес-модели прямо противоположны и при попытке их совмещения в рамках одной организации следует учесть следующее:

• 
  Для аутсорсинговой компании разработка фактически бесплатна, если она делается пулом свободных людей и новичков. Итого — в продуктовый проект направляют новичков и временно незанятых, а когда они чему-то научились, перенаправляют их на активные заказные проекты. Естественно, обучение кадров является важной активностью, но скорость разработки собственно проекта в таком случае приближается к нулю.
  
• 
  Трудоемкость разработки на единицу функциональности для продукта значительно выше, чем в случае заказной разработки: если мы хотим сделать что-то лучше всех, то нам приходится прототипировать разные варианты архитектур и переписывать некоторые места десятки раз.
  
• 
  Так как конкурентность рынка в продуктовом случае выше, то существует потребность быстро изменять рабочую модель или показывать те или иные места под требования, которые сложно объяснить людям, привыкшим к тому что если заказчик их выбрал, то ему скорее всего менять команду будет невыгодно. А вот издержки покупателя на смену предмета покупки нулевые, если он его еще не купил. Уже несколько раз замечал, что люди, успевшие поработать в аутсорсе, могут при просьбе подтянуть какой-то модуль к показу партнеру или выставке демонстрировать философскую неспешность и ничего не менять в первоначальном плане.
  

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

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

Я, кстати, как-то пробовал водить и грузовик и спортивную машину — пришел к выводу, что больше всего мне нравится ездить на простой малолитражке ;) Особенно если принять во внимание, что там обычно нет необходимости ни оказаться к определенному сроку в точке B, ни все время ездить по кругу. Если пытаться естественно продолжить гомоморфизм между типами вождения и разработки, то такое вождение, наверное, соответствует научной разработке и работе с открытым кодом.

При этом что интересно — для открытого ПО и разработка, и распространение в теории не приносят дохода, а бизнес медленно растет, доля открыткого кода все больше и если мы посмотрим на предмет своей работы, то часто видим что коммерческая разработка — это сравнительно тонкая надстройка над открытой инфраструктурой. При этом серебряной пули там нет, технологии все те-же. Единственное отличие — аддитивность, то есть просто каждый проходящий может бросить в кучу камень. И это меняет мир; источник прибыли для бизнеса вокруг OSS — это системные изменения. Изменения в экосистеме разработки, в социальной среде и системах оценки. На самом деле институциональные изменения — это один из самых нужных товаров для общества, особенно нашего.

Классический пример, который наверное есть чуть ли не в любом учебнике по экономике — это Англия 18-го века. Там одно время непропорционально большую часть бизнеса в торговле и банковском деле контролировали квакеры [одна из ветвей протестанизма]. Почему: религия запрещала им врать. Поэтому люди предпочитали проводить сделки именно с представителями этой религии и вот такое, казалось-бы, абстрактное свойство как честность стало конкурентным преимуществом. C OSS происходит что-то подобное;

Может быть мы поговорим об этом подробней. В Одессе на FOSS-SEA на следующих выходных. Уже традиционно в сентябре будет FOSS-SEA, а в октябре OSDN, компаниям еще не поздно предложить спонсорский пакет, разработчикам — спланировать посещение, а тем кто любит разрабатывать системы и еще не в секте — задуматься.

Кстати, все уже в курсе, что с завтрашнего дня резюме программистов без аккаунта в github рассматриваться не будут? ;)

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU