О рынке лимонов и маркировке апельсинов
Те из нас, кто постарше, знают что раньше компьютеры были больше, трава — зеленее, а разработка ПО велась действительно профессионально, в отличие от наших смутных времен. Кроме психологических объяснений этого феномена, существуют и объективные факторы: такие как ухудшающий отбор предложений на рынках с ассиметричной информацией. Этот эффект, впервые описанный экономистом Джорджем Акелофом (википедия) на примере рынка подержанных автомобилей (а вот и сама работа, довольно просто написана), часто обьясняют используя метафору рынка лимонов: если снаружи апельсины и лимоны выглядят одинаково, и лимоны при этом стоят дешевле, то апельсины постепенно исчезнут из продажи — по сравнению с лимонами их продавать будет невыгодно. Так как разработчики ПО знают о программах больше чем заказчики, то этот эффект работает и у нас, при этом в обе стороны: заказчики выбирают фирмы разработчиков, а фирмы разработчики — программистов
Самое смешное — эта ситуация имеет равновесное разрешение (то есть такую конструкцию рынка которая устраняет ухудшение качества), но у нас оно не применяется. Это разрешение — формы контрактов. Скажем для рынка подержанных автомобилей, когда в стандартную форму контракта вставили обязанности по страховке ремонта в течении года, поведение продавцов решительно изменилось — втюхивать неликвид с перспективой гарантийной выплаты стало невыгодно. Для рынка разработки ПО это решение не прижилось (может быть пока ?), вместо этого, рыночная эволюция пошла по пути биологической: мимикрия и защитные механизмы. Фирмы разработчики стали вырабатывать маркеры поведения, указывающие что они хорошие, а потребители начали развивать у себя компетенции разработки.
Наверное самый распространенный случай маркера поведения — это сертификация разработки по какому-то стандартy. Проблемы — сама сертификация вещь дорогая, да еще и утяжеляет процесс разработки (ISO 9001 вобще устроен незатейливо — акт проверки специально обученным человеком на каждое действие. CMM (сейчас CMMI) — позатейливей но суть та-же: параллельно с обычным процессом разработки организовывается параллельный процесс поддержки качества с контролируемым документооборотом) То есть вероятность, что в сертифицированной организации код попадет в продукцию без прохождения тестирования, конечно меньше, но каждая единица функциональности в конечном счете по честному, обойдется дороже и уж точно никак не быстрее, поэтому для значительной части рынка подобная сертификация разработчика — скорее минус чем плюс. Вторая проблема: рынок сертификационных услуг — это тоже рынок лимонов, при этом потребителю зачастую нужна не организация системы соблюдения качеством, а сертификат для демонстрации заказчику.
Мне кажется, что более строгие формы контрактов не прижились в разработке ПО, просто потому что первые наивные попытки состояли в том, что бы продавать ПО как товар, где полностью отсутствует неопределенность. (а между нами, девочками, говоря: неопределенность оценки трудоемкости разработки и есть чуть ли не основная проблема для большинства проектных менеджеров), а потом просто конъюнктура сложилась так, что всем не до этого: работы много, откровенно слабых разработок (пока ? — относительно мало), основное ограничения развития не поток заказов, а скорее наличие разработчиков. Однако все это может измениться, когда кто-то реализует
Еще одна проблема рынка лимонов — это отсутствие доверия между игроками, что в наших условиях выливается в максимальную вертикальную интеграцию фирм разработчиков: от системной архитектуры и тестирования до собственной группы поддержки процессов и инструментальных средств (ну и вплоть до собственных учебных заведений). На самом деле это очень архаичная структура, которая не очень эффективна и мешает как возникновению внутреннего рынка, так и повышению общей продуктивности разработки через специализацию. Если вы посмотрите на то, как идет разработка программного обеспечения в развитых странах, вы увидите совсем другую структуру.
Возвращаясь к контрактам — мне кажется имеет смысл смотреть в сторону соглашений о уровне сервиса (SLA) с каким-то набором взаимных обязательств и системой денежного регулирования уровня сервиса. Это будет не собственный скайп, но уже и не продажа человеко-часов.
Все про українське ІТ в телеграмі — підписуйтеся на канал DOU
18 коментарів
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.