×Закрыть

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

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

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

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


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

  • Трудоемкость разработки на единицу функциональности для продукта значительно выше, чем в случае заказной разработки: если мы хотим сделать что-то лучше всех, то нам приходится прототипировать разные варианты архитектур и переписывать некоторые места десятки раз.

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

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

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

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

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

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

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

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

LinkedIn

44 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
человеко-час как прибыль vs как убытки — выходит, что заказывая продукт в аутсорсинговой компании, инвестор получает партнера, у которого диаметрально противоположные цели.

Следуя этой логике fixed-price contract является единственно правильным решением.

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

В вотерфолле — да, в аджайле — можно:
codebetter.com/...e-organization

Прочитал статью — и что?
Никаких существенных отличий в подходах между WF и Agile там не увидел...

В общем можно охарактеризовать — We will do our best...

См. коммент выше. Вкратце: в Agile окончание бюджета раньше окончания бэклога не приводит к коллапсу проекта. А в вотерфолле приходится выбирать из двух зол: раздутые эстимэйты vs неюзабельный продукт.

(Отдельная тема — открыл недавно книгу 20-летней авности, а там про отличии RUP от WF ровно той-же метафорой, по которой XP отстраивало отличие от традицуионной разработки. (Управление автомобилем))

Я — конечный заказчик, продаю колбасу, в ИТ нифига не шарю. Пришел в Люксофт и сказал: «Хочу систему под ключ. Функциональность: А, Б, В, Г. Денег — есть столько то.» Мне в Люксофте сказали: «Не вопрос! Начнем делать, по ходу дела увидим, на сколько твоих денег хватит.» Предположим, я согласился. Начали делать, под конец денег выяснилось, что сделали А и Г. А мне нужна система с «А, Б, В, Г». Я отдал свои деньги Люксофту, взамен остался с кучкой кода, который мне без Б, В — не нужен. Вопрос: что мне делать, как заказчику?

При fixed cost подход другой: у меня есть деньги, но нет компетенции. Я плачу деньги, взамен получаю обязательство поставщика сделать мне систему с А, Б, В, Г. За нарушение договора полагаются штрафные санкции.

Создание системы стоит столько, сколько оно стоит. При T&M все риски на моей стороне — стороне заказчика. Все плюшки — на стороне разработчика. Мне, как заказчику, это нафиг не надо. Я готов заплатить премию — «раздутые эстимейты», но переложить риски на сторону разработчика, т.к. он более компетентен.

Потому я и говорю, что agile и T&M подходит для in-house разработки. Для крупных проектов по прежнему классическая структура процесса, а в серединке где-то, на этапе разработки могут примоститься уже скрам-мастера со своими сертификатами :)

Хочу систему под ключ. Функциональность: А, Б, В, Г. Денег — есть столько то.

Ну вот поинт как раз в том, что или «А, Б, В, Г» (и waterfall), или «денег столько-то» (и тогда Agile).

Более того, чем крупнее проект, тем, как правило, «АБВГ» менее точные и более подвержены изменениям. Если проект на 5 лет, то я себе с трудом представляю бизнес, в котором за 5 лет ничего не поменяется. А вотерфолл на изменения требований реагирует крайне негативно.

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

А вотерфолл на изменения требований реагирует крайне негативно

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

Это то, что касается «организационной части».

А с технической части — если вам приходит такое изменение, что пол системы нужно переписать, то ее и в ВФ и в Аджайле переписать нужно.

Ну тут я не понимаю — зачем Агиле борется с чучелом Ватерфлова если последний в чистом виде уже лет 30 существует только в виде объекта для критики.

Потому что надо обязательно иметь перд глазами образ врага. Желательно такого которого можно безопасно для себя попинать, и при этом никого не обидеть, да ещё и сохранять вид мудреца :)

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

Ну не знаю, как Люксофт, а вот фирма в которой я работаю, извинится и скажет — ’не можем’. Либо последовательность итераций, где в каждой итерации мы можем сформировать естимейты не от потолка, либо никак.

Agile как-то не укладывается в fixed-price contract, не находите?

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

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

Как раз укладывается, причем гораздо лучше вотерфолла (об этом и статья). При Agile подходе мы можем зафиксировать стоимость и делать приоритетные фичи, пока есть бюджет. Все, что успеем сделать, будет гарантированно potentially shippable. А в вотерфолле, с подходом «all or none» мы обречены либо увеличивать бюджет (считай, переходить на T&M), либо же фэйлить проект в случае неточных эстимэйтов. Или же заведомо раздувать эстимэйт, что, опять же, не делает заказчика счастливее.

Вы смешиваете Agile и итеративную разработку, что все таки не одно и тоже.

all or none

— это не вопрос к методологии, это вопрос к специфике продукта. В одном случае продукт, в котором есть 70% фич имеет ценность, а в другом — никакой.

зафиксировать стоимость и делать приоритетные фичи, пока есть бюджет

Вот именно — пока есть бюджет. В этой же статье написано, но чаще всего fixed price означает еще и fixed scope and fixed time. А в таком случае эджайл не помагает...

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

Scrum is an «Art of Possible»

  • Fixed-Price с Unfixed functionlity — ну ведь это же не тот fixed-price который имелся в виду в комментарии выше, а замаскированная повременка где просто верхняя граница итерации зафиксированна, со всеми вытекабщими
  • Приоретизация независимых фич так что-бы каждая из них имела бизнес-ценность возможна только в сравнительно простых случаях. Если вы в них попали — ок. Но обычно есть некий нижний предел функциональности и связности, который не распадается на части, продаваемые независимо.

ведь это же не тот fixed-price который имелся в виду в комментарии выше

Честно говоря, «того» FP я в природе не видел на мало-мальски сложных проектах. Мне кажется, что это какой-то единорог из страны эльфов (и чем крупнее проект, тем единорог призрачнее).

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

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

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

Да

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

Ну так можно сделать последовательность работ понятной закачику. Но использовать то все-равно нельзя пока минимального набора функциональности не будет. Ну вот пример — замена биллинговой системы (или любой АСУ-ТП): там пока не построишь контур для всех бизнес-процессов, на новую систему не переключишься. Или компилятор: трансляция 50% языка особого бизнес-смысла не имеет.

С компилятором ладно (сколько процентов разработки занимают компиляторы?), а насчет АСУТП — мы сейчас делаем middle office систему процессинга трейдов. Тоже миграция со старого мейнфрейма, последние два года обе системы вполне мирно сосуществуют, часть трейдов все еще рутится в старую систему, по мере миграции функционала переключаем рутинг в новую систему.

Было бы желание.

(Да, мы тоже миграцию постепенно часто делаем.)

  • И что — вот вы одной fixed price итерацией добрались до начала миграции ?
  • Ну и главная цель заказчика (отключить старую систему и начать делать новые фичи на новой) то будет достигнута только в конце нескольких итераций. Понятно что можно ограниченно развивать функционал уже перенесенных процессов, но это уже зависит от специфики

Новые фичи — да, делаются уже на новой системе. Добрались — да, за один FP заход (изначально проект рассчитывался на 5 лет). Собственно, добрались до начала миграции за 2 года.

То есть была одна fixed-price итерация на два года ? Круто, ну вот вам и единорог ;)

Я, видимо, непонятно выразился. Был один проект на 5 лет и некую сумму денег. Первые 2 года core team из нескольких человек колбасила фреймворк системы, потом решили, что так далеко не уедешь, наняли толпу народу (в т.ч., часть аутсорснули), перешли на скрам и начали выпускать релизы (сначала раз в 2-3 месяца, последнее время — раз в 4 недели).

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

По сути Agile не дает заказчику гарантий по поводу того что он получит за свои деньги. Для человека, который платит свои деньги — самый большой минус. Многие предпочитают заплатить 10-15% сверху за предварительный анализ, чтобы все-таки очертить границы проекта, бюджет и сроки. Пусть и с долей приближения.

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

Очевидно, что чем больше проект — тем желание использовать Agile у разработчика больше. Это понятно и правильно, в таких системах оценки еффорта начинают перетекать в «предсказания».

Каждому проекту — своя методология..

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

Судячи із всього, незабаром це перестане бути жартом: code.dblock.org/...your-new-resume

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

Та не будет акого никогда

У нас може і не буде. В США вже є (якщо вірить тому, що написано в статті).

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

GitHub — це вже скоріше соціальна мережа для програмістів, аніж просто хостинг для проектів. Взагалі це не обов’язково повинен бути саме GitHub. Це може бути, наприклад, SourceForge або інший хостинг (варіантів є достатньо). Замість того, щоб дивитись куски коду програміста на співбесіді, працедавець може вияснити його рівень ще до співбесіди і вирішити, чи варто цю співбесіду взагалі проводить. Я погоджуюсь з тобою, що отфутболювать не будуть тільки із-за того, що немає аккаунта на GitHub. Але при наявності декількох претендентів на вакансію, перевага буде, більш за все, надана тому програмісту, який має «домашні» проекти, котрі можна подивитись і оцінити заздалегідь (це ті бенефіти, про які ти писав). GitHub для таких цілей — самий підходящий варіант, тому він і згадується в подібних статтях.

Ще такий баннер сьогодні побачив:

static.adzerk.net/...2a472e2b1be.png

Статью не понял. Но последняя фраза хороша, в понедельник здесь в коментах должно быть весело:).

ДОУ это как вентилятор — только успевай бросать :)

я ничего не понял, это нормально?

Колумнисты это раздел для неструктурированного потока мыслей, так что нормально.

чисто в теории, работа в oss приносит доход инженерам в виде вероятного конкурентного преимущества. мм?

p.s. оу, кажется я пролетаю со своим bitbucket’ом ;)

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

И где там написано что не будут?..

<dt>эээ... проблема в том, что в html нет тега, скрывающего текст в области действия смайлика от людей без чуства юмора </dt>

Тег скрывающий странные шутки тоже не помешал бы.

Подписаться на комментарии