я тут придумал новый способ оплаты заказов
обычно сначала оговаривается сумма, но в этой схеме исполнитель заинтересован делать задачу минимально приемлемого качества подталкивая заказчика запрашивать новые поправки и соотв рано или поздно скажет ему что пора бы и доплатить
а что если сделать наоборот: заказчик сразу предлагает сумму например превышающую в 2 раза необходимую, но в случае любых недочетов вычитает из неё часть бабла
в этом случае исполнитель заинтересован сделать сразу и хорошо
а заказчик хоть и переплачивает может, но он получает максимальное качество максимально быстро, ибо исполнитель не заинтересован в доработках
т.е. исполнителю сразу предлагается большой бонус за качественное исполнение
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>а что если сделать наоборот: заказчик сразу предлагает сумму например превышающую в 2 раза необходимую, но в случае любых недочетов вычитает из неё часть бабла
выходит что для заказчика выгодно докапываться до всего, и продукт лучше и дешевле.
Здравствуйте, GarryIV, Вы писали:
GIV>Здравствуйте, Barbar1an, Вы писали:
B>>а что если сделать наоборот: заказчик сразу предлагает сумму например превышающую в 2 раза необходимую, но в случае любых недочетов вычитает из неё часть бабла GIV>выходит что для заказчика выгодно докапываться до всего, и продукт лучше и дешевле.
да, но у заказчика время ограничено, он не может докапываться до бесконечности, а исполнитель может растягивать разработку скока хочет
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B> заказчик сразу предлагает сумму например превышающую в 2 раза необходимую, но в случае любых недочетов вычитает из неё часть бабла...
заказчик всегда жадныйв большинстве случаев пытается минимизировать затраты.. и в общем обычно нет проблемы по мере проявления доп. требований к задаче, за них доплачивать и дозаказывать работу. просто обеим сторонам это надо понять и проблемы нет.
Мне кажется, что такое подходит для более-менее стандартизированных проектов (например, сайт-визитка или интернет-магазин с базовой функциональностью под ключ), с которыми подрядчик имеет большой опыт работы — может реалистично оценить усилия / сроки и правильно зафиксировать delivery scope. Иначе, либо подрядчику придется брать на себя очень большой риск, либо все закончится разборками с заказчиком на тему это баг или фича.
Здравствуйте, Barbar1an, Вы писали:
B>я тут придумал новый способ оплаты заказов B>обычно сначала оговаривается сумма, но в этой схеме исполнитель заинтересован делать задачу минимально приемлемого качества подталкивая заказчика запрашивать новые поправки и соотв рано
Нельзя сделать плохо, если сделать плохо, то придут другие которые сделают лучше.
Если заказчик будет чувствовать что его раскручивают на деньги, делают плохо, а у него реальные проблемы в бизнесе, то тем быстрее он найдет тех кто делает лучше.
Поэтому система сама себя балансирует и нужно делать хорошо.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, Barbar1an,
B>обычно сначала оговаривается сумма, но в этой схеме исполнитель заинтересован делать задачу минимально приемлемого качества подталкивая заказчика запрашивать новые поправки и соотв рано или поздно скажет ему что пора бы и доплатить B>а что если сделать наоборот: заказчик сразу предлагает сумму например превышающую в 2 раза необходимую, но в случае любых недочетов вычитает из неё часть бабла B>в этом случае исполнитель заинтересован сделать сразу и хорошо
Ничего не понял.
Вообще-то в fixed price проектах scope работ четко очерчивается Техническим заданием. Требования фиксируются при подписании ТЗ. Все, что перечислено в ТЗ, выполняется исполнителем за эту самую fixed price. И, разумеется, исполнитель заинтересован в минимизации издержек, т.е. будет делать с минимально приемлемым качеством, чтобы вписаться в требования ТЗ. Не выполнил требования ТЗ — все исправления и доработки за свой счет. Все же, что сверх требований, перечисленных в ТЗ — делается за отдельные деньги и в отдельные сроки.
Или ты имеешь в виду случай, когда заказчик сам не знает, чего хочет, и требования постоянно меняются? Тогда это не fixed price, а схема оплаты проекта time and materials.
Здравствуйте, Barbar1an, Вы писали:
B>я тут придумал новый способ оплаты заказов B>обычно сначала оговаривается сумма, но в этой схеме исполнитель заинтересован делать задачу минимально приемлемого качества
Для заказчиков это решается только:
— наличием отлаженной системы контроля за качеством (никакая халтура не продйет)
— штрафные санкции за срыв срока, за низкое качество (выдал с ошибками — получил штраф)
— право заказчика привлечь стороннего исполнителя для устранения косяков, за счет исполнителя
Да, вот на таких условиях работает крупный бизнес с ИТ компаниями.
Знаю проект наших бывших конкурентов:
— исполнитель работал год, сделал работ на 100к$
— в проекте были неустранимые ошибки, полуил возможность отказаться от оплаты полностью (была пост оплата)
— заказчик получил с исполнителя штраф 80к$ за срыв сроков
— заказчик привлек стороннюю компанию за 100к$ Для устранения недостатков.
В итоге исполнитель не получил 100к$, должен потрешению суда заказчику 180к$.
Исполнитель имел на счетах своей компании авансы других клиентов, решил их вывести на счет своего другого юр. лица, чтобы не платить штраф 180к$. В итоге свой бизнес он как-то сохранил, но получил такой удар по репутации, что практически перестал работать на своем сегменте рынка и сдулся до нескольких человек.
ИМХО идеальная схема это оплата по времени. Качество просто так не берётся, качество напрямую зависит от времени. Если я пишу код для себя, я его могу покрыть чуть ли не стопроцентными тестами, я могу каждый компонент переписать по 5 раз, пока не почувствую, что он идеален. Понятно, что суммарно это занимает раз в 20 больше времени, чем если бы я писал просто рабочий код. Другой вопрос, что если оплачивать конкретно рабочие часы, возникают вопросы отслеживания этих часов; если оплачивать рабочие сутки, возникает вопрос того, что программист может отдыхать вместо работы (или даже работать чужую работу). Но всё же если программист честен и его КПД устраивает заказчика, оплата по времени без контроля имхо идеальный способ получить результат нужного качества.
Гмм. С постоплатой, без аванса и с конскими штрафами за просрочку? Видимо, для исполнителя это был очень-очень "вкусный" проект. И при таких условиях профукать его — это надо было суметь....
Кстати, вот если немного призадуматься над приведенным примером....
Что такое 100 к$ ? Это, если грубо, 6 млн рублей. Из которых ФОТ — миллиона 2. 2 млн на год — это примерно 160 тыр в месяц. С учетом всяких отчислений в ПФР, ОМС и прочего, до исполнителя дойдут тысяч 80-90. А что такое 80 тыр в месяц? Это, грубо говоря, один джуниор или пара студентов на полставки. (ТС же в Москве, не так ли?)
Итак, наш джуниор корпел над проектом год. Очевидно, что никакого контроля за его работой — всяких там дизайн-ревью и код-ревью — не было. Вот и причина "неустранимых ошибок в проекте" — джун же писал, варясь в собственном соку...
Теперь взглянем на "фирму". Провал одного проекта объемом в 1 джуно-год привел фирму на грань краха. Ну, вы поняли, каков размер этой фирмы, да?
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, sharpcoder,
V_S>Гмм. С постоплатой, без аванса и с конскими штрафами за просрочку? Видимо, для исполнителя это был очень-очень "вкусный" проект. И при таких условиях профукать его — это надо было суметь....
Видимо исполнитель просто дурак.
Не по Сеньке шапка.
