Предыдущий пост Поделиться Следующий пост
От занижения сроков к равновесию Нэша
lex_kravetski
За все сферы деятельности не скажу — быть может, и там тоже — но в сфере разработки программного обеспечения давно уже наблюдается занимательная тенденция: занижение сроков разработки на этапе получения заказа. Не в том смысле, что разрабатывают всё быстрее, а в том смысле, что это обещают заказчику.

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

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

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

Посмотрим, как это работает.

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

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

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

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

Фирма, воспользовавшись этим отличным способом повышения собственной конкурентоспособности, вынуждает пользоваться тем же самым и другие фирмы тоже — ведь иначе они будут терять заказы в пользу «нечестных» фирм. Компенсировать этот психологический эффект строгим соблюдением сроков нереально — заказчики на этапе заказа софта хотят обещаний, а исход разработки им ещё неизвестен. Писать с такой скоростью, чтобы уложиться в срок, который обещают другие фирмы, не теряя при этом в качестве во многие разы, тоже нереально. Единственный вариант — тоже врать о сроках. Благо для вранья клиентам давно уже есть специальные люди в штате.

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

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

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

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

Описанный процесс является частным случаем так называемого «равновесия Нэша» — одной из ключевых закономерностей «некооперативных игр». Краткая его суть состоит в том, что при определённых «правилах игры» игроки, если не сговариваются между собой, то приходят к точке устойчивого равновесия, которая может сколь угодно далеко отстоять от оптимума, достижимого при кооперативных действиях. Из данной закономерности, в частности, вытекает, что рынок с неизбежностью приводит к сговору олигополий, поскольку желание получать ещё больше у них никуда не девается, а без сговора из равновесия Нэша выйти нельзя.

Данный пример равновесия, как и само равновесие, столь интересны, что я, думаю, посвящу им ещё одну статью.



doc-файл
Публикация на «Однако»



Метки:

Ну да, а ещё сэйлы - молодцы - они привлекли клиента (назвав нереальные сроки), а чумазые программисты - ленивые косорукие твари, ничего не успевают.

Нас бог миловал - коробочными решениями барыжим, такшта сроки занижать нам ни к чему. Срываем иногда сроки доработок, но достаточно редко они реально занижены - во многом из-за косорукости. :)
Хорошо быть самими по себе. ;)

Re: Ответ на вашу запись "От занижения сроков к равновес

> Нас бог миловал - коробочными решениями барыжим, такшта сроки занижать нам ни к чему.

В этом случае клиентом выступает издатель.

Приверженцы плановой экономики считают само собой разумеющимся, что госплан неизбежно «программирует» наиболее эффективный способ производства. Только вот вспоминаю я пример такой кооперативной игры - "смыкание Госплана СССР с отдельными министерствами и ведомствами и занижение производственных мощностей и хозяйственных планов министерств".

Чтобы не путаться предлагаю назвать назвать это не менее интересное равновесие "равновесием социалистического Нэша".

Мсье много лет проработал в Госплане?.. Или теоретизируем на кухне?

А еще, довольно парадоксально, что часто сами заказчики к этому подталкивают.
Я на прошлой работе был именно такой прокладкой между программистами и заказчиком, менеджером по внешним сношениям (заказчики были из за рубежа)/руководителем проектов/директором по продажам, словом и швец и жнец и на дуде игрец.
Вот приезжает к нам в Москву заказчики из Судана, местное ФСБ грубо говоря, очередной проект, назовем его "управляющая программа для дыб и гильотин". Я, говорю - это займет 3 месяца после получения оплаты (зная что с оплатой они будут месяц тянуть и время в запасе будет). Они - ой, это долго, нам надо за месяц (причем конкурентов у нас нет). Ну естественно пообещали месяц, деньги они заплатили через полтора, и получили продукт через полтора месяца после оплаты.
А так я всегда с начальством ругался, они типа старые инженеры, я им всегда говорил "если клиента не обманем мы, его обманет другой и получит деньги". Логика тут к сожалению очень простая.

Гм. При заключении контракта всегда ставятся сроки раелизации с штрафными санкциями.

Как вашу "поправку" можно опровергнуть?

Про тенденцию к двукратному занижению я слышал начиная с 2000 года. Видимо равновесие было достигнуто уже тогда.

(Удалённый комментарий)
> Что, впрочем, можно наблюдать не только в сфере разработки софта, но и почти в любой другой, только не всегда настолько наглядно

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

Re: Ответ на вашу запись "От занижения сроков к равновес

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

судя по росту доходов по разработке софта, особых проблем это пока не вызывает

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

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

Ибо эстимейтами сроков чаще всего занимается не менеджмент - это дело рук кого-то из технических специалистов (и я тоже таким специалистом была, на эти грабли наступала). А у тех могут быть разные причины не вписываться в поставленные ими же рамки - будь то простой оптимизм на этапе закладки (от которого лечит практика учёта velocity в гибких методологиях разработки и тот факт, что менеджеры, напротив, пытаются "перезаложиться"), неясные техтребования (которые порой ещё и меняются по несколько раз в ходе разработки, потому что заказчику ВНЕЗАПНО захотелось какую-то супермодную фичу), или просто ввиду каких-то форс-мажоров. И в итоге технический же специалист остаётся крайним, работая по выходным и объясняясь с великой и ужасной Левой Пяткой заказчика, которая едва ли не каждый день выдаёт очередную "хочушку" и раздувает scope (как я когда-то писала у себя, есть в этом какой-то элемент садо-мазо). Что с этим делать в глобальном масштабе - я не знаю. А в локальном я просто перестала работать в сфере аутсорсинга и ушла в компанию со своим программным продуктом и куда более здоровым отношением к срокам, фичам и приоритетам.

Edited at 2013-08-26 12:10 (UTC)

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

Это не равновесие Нэша, это ближе к недавней нобелевке - про "рынки лимонов и апельсинов".

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

Несмотря на всю простоту, результаты выполнения этого задания нередко весьма впечатляют. Иногда люди не понимают, что в часе всего 60 минут, а не 180. Иногда они пытаются наворотить гору свистелок, забыв об основном функционале. Очень часто код не соответствует элементарным принципам безопасности и не содержит хоть сколько-либо полезных комментариев. В итоге, лишь примерно 1 из 8 соискателей могут выдать что-то, на что можно смотреть без слёз, несмотря на то, что они - "специалисты с пятилетним опытом".

Итак, о чём это я? О том, что исполнителей надо проверять. Обещания обещаниями, а на деле оказывается, что студент, готовый работать за еду, оказывается лучше половины горе-специалистов. Если контора не готова к тому, чтобы держать у себя толкового программиста (его же ещё и найти надо), то есть товарищи, готовые провести независимый аудит исполнителей за весьма быстрый срок и очень скромные суммы. Скромные относительно того, что придётся заплатить дабы переварить результат труда погромистов =)

Re: Ответ на вашу запись "От занижения сроков к равновес

1. В общем случае заказчик не в состоянии проверить исполнителей, поскольку не имеет даже сотой доли требуемой квалификации.

2. В общем случае можно каждого тщательно проверять, но работать всё равно придётся с теми, кто есть. Ибо если проверки не выдержал ни один, ниодного нельзя заставить написать программу.

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

Re: Ответ на вашу запись "От занижения сроков к равновес

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

как все это до боли знакомо...
а, главное ж, ВЕРЯТ! верят что им за месяц построят нью-йорк со всеми пригородами...

Кстати, частный случай: если заказчиком выступает госучреждение, то ситуация может быть вообще фантастической. Т.е. продукт не соответствует ТЗ или имеет кучу нареканий на работу, выявленных в процессе опытной эксплуатации. Исполнитель тянет со сроками устранения, имитируя деятельность, естественно не успевает. Но! Допустим этот продукт создавался в рамках некой федеральной программы. На выходе имеем дилемму: или расписаться, что заказчик - лох и сорвал выполнение федеральной программы (а это значит, что пострадают очень уважаемые люди, хоть исполнитель при этом и будет наказан по всей строгости), или принять у исполнителя то, что есть, отрапортовав наверх об успешном выполнении, а это недоразумение скинуть на плечи своего IT подразделения с приказом - долепить на коленке так, чтобы работало.

Приветствую!

Если заказчиком выступает госучреждение, то 94ФЗ открывает такие мрачные бездны смыслов выражения "хотели как лучше, получилось как всегда"(c), что непосвященным туда лучше вообще не заглядывать:)

С уважением, Dargot.

?

Log in

No account? Create an account