Про мишей і їжачка, моделях розробки і квакерами в контексті FOSS Sea 2011

Всі ці розмови про те, що аутсорсинговим компаніям треба переходити до продуктової моделі якось сильно нагадують мені відомий анекдот про стратегічному мисленні пугача.

Однією з найперших (і найбільших) з моїх помилок в самостійному бізнесі була співпраця з однієї великої аутсорсингової компанією з метою спільної розробки продукту. Ідея була в тому, щоб об'єднати нашу експертизу в області білінгових систем та ресурси великої компанії, випустивши на ринок сучасний продукт. Розробка велася близько двох років, після чого проект був закритий без випуску будь-якої версії.

Цей провал збагатив мене, крім усього іншого, ще й розумінням відмінностей продуктової та розробки на замовлення, який можна коротко виразити наступною формулою: в аутсорсингу людино-годин, витрачений на розробку - це пряма прибуток, у той час як для продуктової розробки - це прямі збитки. Ці дві бізнес-моделі прямо протилежні і при спробі їх поєднання в рамках однієї організації слід врахувати наступне:

Для аутсорсингової компанії розробника фактично безкоштовна, якщо вона робиться пулом вільних людей і новачків. Разом - в продуктовий проект направляють новачків і тимчасово незайнятих, а коли вони чогось навчилися, перенаправляють їх на активні замовні проекти. Природно, навчання кадрів є важливою активністю, але швидкість розробки власне проекту в такому випадку наближається до нуля.
Трудомісткість розробки на одиницю функціональності для продукту значно вище, ніж у випадку розробки на замовлення: якщо ми хочемо зробити щось краще за всіх, то нам доводиться прототіпіровать різні варіанти архітектур і переписувати деякі місця десятки разів.
Так як конкурентність ринку в продуктовому випадку вище, то існує потреба швидко змінювати робочу модель чи показувати ті чи інші місця під вимоги, які складно пояснити людям, які звикли до того що якщо замовник їх вибрав, то йому швидше за все міняти команду буде невигідно. А ось витрати покупця на зміну предмета покупки нульові, якщо він його ще не купив. Вже кілька разів помічав, що люди, які встигли попрацювати в аутсорс, можуть при проханні підтягти якийсь модуль до показу партнеру або виставці демонструвати філософську неспішність і нічого не міняти в початковому плані.

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

Тобто суперечка тут між прихильниками продуктової моделі та розробки на замовлення нагадує суперечку між водіями вантажівок і гоночних автомобілів: так, гоночні машини зроблені краще і їхні водії отримують масу адреналіну, але ринок вантажних перевезень - у рази більше, ризику там на порядок менше , вхідні бар'єри нижче і для того що б сісти за кермо не обов'язково переселятися в країну, де проводяться змагання. І з точки зору бізнесу займатимуться логістикою, а не гонками - вибір цілком раціональний

Я, до речі, якось пробував водити і вантажівка і спортивну машину - прийшов до висновку, що найбільше мені подобається їздити на простій малолітражці;) Особливо якщо взяти до уваги, що там зазвичай немає необхідності ні виявитися до певного терміну в точці B, ні весь час їздити по колу. Якщо намагатися природно продовжити гомоморфізм між типами водіння і розробки, то таке водіння, напевно, відповідає науковій розробці і роботі з відкритим кодом.

При цьому що цікаво - для відкритого ПЗ і розробка, і поширення в теорії не приносять доходу, а бізнес повільно зростає, частка листівкою коду все більше і якщо ми подивимося на предмет своєї роботи, то часто бачимо що комерційна розробка - це порівняно тонка надбудова над відкритою інфраструктурою. При цьому срібної кулі там немає, технології все ті ж. Єдина відмінність - адитивність, тобто просто кожен проходить може кинути до купи камінь. І це змінює світ, джерело прибутку для бізнесу навколо OSS - це системні зміни. Зміни в екосистемі розробки, в соціальному середовищі і системах оцінки. Насправді інституційні зміни - це один з найбільш потрібних товарів для суспільства, особливо нашого.

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

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

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

Опубліковано: 10/09/11 @ 06:05
Розділ Реклама

SEO Блог

Про мишей і їжачка, моделях розробки і квакерами в контексті FOSS Sea 2011

Рекомендуємо: