Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

О рынке лимонов и маркировке апельсинов

Те из нас, кто постарше, знают что раньше компьютеры были больше, трава — зеленее, а разработка ПО велась действительно профессионально, в отличие от наших смутных времен. Кроме психологических объяснений этого феномена, существуют и объективные факторы: такие как ухудшающий отбор предложений на рынках с ассиметричной информацией. Этот эффект, впервые описанный экономистом Джорджем Акелофом (википедия) на примере рынка подержанных автомобилей (а вот и сама работа, довольно просто написана), часто обьясняют используя метафору рынка лимонов: если снаружи апельсины и лимоны выглядят одинаково, и лимоны при этом стоят дешевле, то апельсины постепенно исчезнут из продажи — по сравнению с лимонами их продавать будет невыгодно. Так как разработчики ПО знают о программах больше чем заказчики, то этот эффект работает и у нас, при этом в обе стороны: заказчики выбирают фирмы разработчиков, а фирмы разработчики — программистов

Самое смешное — эта ситуация имеет равновесное разрешение (то есть такую конструкцию рынка которая устраняет ухудшение качества), но у нас оно не применяется. Это разрешение — формы контрактов. Скажем для рынка подержанных автомобилей, когда в стандартную форму контракта вставили обязанности по страховке ремонта в течении года, поведение продавцов решительно изменилось — втюхивать неликвид с перспективой гарантийной выплаты стало невыгодно. Для рынка разработки ПО это решение не прижилось (может быть пока ?), вместо этого, рыночная эволюция пошла по пути биологической: мимикрия и защитные механизмы. Фирмы разработчики стали вырабатывать маркеры поведения, указывающие что они хорошие, а потребители начали развивать у себя компетенции разработки.

Наверное самый распространенный случай маркера поведения — это сертификация разработки по какому-то стандартy. Проблемы — сама сертификация вещь дорогая, да еще и утяжеляет процесс разработки (ISO 9001 вобще устроен незатейливо — акт проверки специально обученным человеком на каждое действие. CMM (сейчас CMMI) — позатейливей но суть та-же: параллельно с обычным процессом разработки организовывается параллельный процесс поддержки качества с контролируемым документооборотом) То есть вероятность, что в сертифицированной организации код попадет в продукцию без прохождения тестирования, конечно меньше, но каждая единица функциональности в конечном счете по честному, обойдется дороже и уж точно никак не быстрее, поэтому для значительной части рынка подобная сертификация разработчика — скорее минус чем плюс. Вторая проблема: рынок сертификационных услуг — это тоже рынок лимонов, при этом потребителю зачастую нужна не организация системы соблюдения качеством, а сертификат для демонстрации заказчику.

Мне кажется, что более строгие формы контрактов не прижились в разработке ПО, просто потому что первые наивные попытки состояли в том, что бы продавать ПО как товар, где полностью отсутствует неопределенность. (а между нами, девочками, говоря: неопределенность оценки трудоемкости разработки и есть чуть ли не основная проблема для большинства проектных менеджеров), а потом просто конъюнктура сложилась так, что всем не до этого: работы много, откровенно слабых разработок (пока ? — относительно мало), основное ограничения развития не поток заказов, а скорее наличие разработчиков. Однако все это может измениться, когда кто-то реализует 6-месячные курсы программистов без высшего образования и поставит на поток систему выполнения проектов исполнителями малой квалификации. Вот тогда-то маркеры поведения -и понадобятся.

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

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

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

LinkedIn

Схожі статті

  • Огляд IT-ринку праці: ЛуцькОгляд IT-ринку праці: Луцьк

    Dmytro Skorokhod

    Сьома стаття циклу «Огляд ІТ-ринку праці», в якій ви дизнаєтесь про ІТ-галузь у Луцьку — огляд компаній, тематичні події, профільні внз та перспективи регіону. 29

  • Огляд ІТ-ринку праці: Івано-ФранківськОгляд ІТ-ринку праці: Івано-Франківськ

    Редакція DOU

    Представляємо восьму статтю з циклу «Огляд ІТ-ринку праці», в якій ми розповідаємо про ІТ-індустрію у місті — оглядаємо компанії, тематичні події, профільні виші і галузеві перспективи регіону. 5

  • Огляд IT-ринку праці: ЛьвівОгляд IT-ринку праці: Львів

    Валентина Шимкович

    В місті працює ІТ кластер, є кілька технічних вишів з інноваційними напрямками підготовки. Оборот ІТ-галузі Львова складає 14,4% ВРП міста Львова. 23




18 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Если вы посмотрите на то, как идет разработка программного обеспечения в развитых странах, вы увидите совсем другую структуру.
як організована розробка ПЗ в кращих компаніях (світового рівня)?
Чим відрізняється від української моделі розробки?

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

Хотелось бы, чтобы последнее предложение из этого абзаца было расписано как весь этот абзац. Бо схоже на демагогию.

у разных по разному, но сплошная вертикальная интеграция это несомненный признак отсталости ;) Кажется «конкуренция» Поттера это самый классический труд с подробным объяснением.

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

Может всё-таки «Портера»?

Да, конечно Майкл Портер

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

Разработка ПО скорей ближе к рисованию картин чем торговля апельсинами.

Ну а давний страх —

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

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

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

Вообще говоря, сама выдача сертификатов — это нехилый такой бизнес

Руслан,
обе ссылки (wikipedia и перевод оригинала статьи) не работают.
ru.wikipedia.org/...Акерлоф,_Джордж

igiti.hse.ru/.../5_1_4Akerl.pdf

спасибо, исправил

(однако баг у ДОУ в движке — удвоение кавычек в href при редактировании текста [сейчас засубмичу] )

поббрюзжать: потребовалось прочитать 2\3 статьи, чтобы понять, что тут речь идёт не о «программист-контора», а про «айтиконтора-заказчик» :)

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

опять же про СЛА. как ты себе представляешь СЛА (и его последствия) в случае с недавним простоем амазоновского облака? там же вертится всё что угодно — от домашних страничек до стартапов, которые мониторят сердечников... и простой одного совершенно не тоже самое, что простой второго по возможному урону. а вот с точки зрения амазона — это одно и то же — стоит сайт. что им делать? подписывать разный сла? не пускать мишн-критикал приложения к себе?

всё сложно.

то же самое с мс — повисла винда дома = ребутнулся и всё или повисла винда = сорвалась презентация = потерян «$1М+» контракт....

1. patches welcome. (ну на самом деле это потому что ты или кто-то другой, найти не могу сейчас писал статью про рынок лимонов и программистов на рынке труда: я ее вспомнил когда про 2 стороны написал)

2. Все сложно .. — ну да. Решать сложные проблемы за деньги — это в каком-то смысле предназначенье бизнеса.

1. на брюзжание не надо обращать внимания :) а писали и я и макс дорофеев.

2. не-не. тут дело в том, что

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

пути решения, которые приходят на ум:

1. задирать цену продукта, чтобы покрыть риски «дорогих» клиентов. но это несправедливо по отношению к тем, для кого качество\надёжность менее важны (оракл-вей).

3. забить за риски и продавать without any warranty (мс-вей).2. составлять _разные_ контракты для разных клиентов, но это приведёт к тому, что _один и тот же продукт_ _стоит по разному_ из-за вариантов его использования. тогда уж лучше зааутсорсить страховку страховым конторам, имхо. так кто-то делает?

Ну или искать оптимум (какое соотношение нао твоему клиенту) или действительно — разные уровни и разные риски.

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

Помню, лет 5 назад тогдашние крупнейшие айти-компании украины (Миратех, Софтлайн и тд) поголовно обзаводились ISO и CMM (как можно более вісоких степеней), ну и MBA у руководства. Как видим, оказалось, что в айти это не работает.

А кстати, тогда может и работало ... ну правда, по моим ощущениям: где-то 10 а не 5 лет назад могло работать (типа тут не только пустыня но и ISO сертификация).

Работало 10 лет назад, а сертфицировались лет 5-7 назад, с понятным результатом.

ISO работает, в определенных вертикалях.

Не знаю, все, с кем я общался, говорили, что в software development ISO — это чисто показуха для MBA. Может, оно работает на других уровнях компании, типа, если сейлзы работают по ISO, то им это помогает. Тут я не знаю, как оно.

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