M>Это да, но зато если он будет понимать, что вообще ничего не получил за 20 багов, то это может поможет!
Так тестировать, это вообще работа со стороны заказчика, а прогеру трудно тестировать свое! Вот исправлять...
Наверное деньгами можно мотивировать, только чтобы в срок уложится, т.е. контролировать "усидчивость".
А как качество-то контролировать? Например, самый огорчивший меня лансер, писал на онкликах
if Length(LangStrings)>=32 then
begin
l1:=LangStrings[31];
l2:=LangStrings[26];
end
else
begin
l1:='Не удалось записать "%s"';
l2:='Для записи AVI необходимо установить DivX/XviD кодек!';
end;
И как после просмотра сорцов, сказать, что установка дефолтных параметров должно вытекать из структуры лангфайла и
делаться разово в одном месте. Это же трудно предусмотреть заранее. И таких ньюансов дофига.
Здравствуйте, maks1180, Вы писали:
_>>P.S. А вообще, на мой взгляд деньги, программиста, нифига не мотивируют. Т.е. если человек пишет глючный и кривой код и не хочет думать, это у него просто такое отношение к работе и вряд ли оно поменяется даже если заплатить ему в 10 раз больше. M>Это да, но зато если он будет понимать, что вообще ничего не получил за 20 багов, то это может поможет!
Еще раз — это поможет тебе быть посланным на йуга. Кнут есть, пряника — нет. Это так не работает.
Здравствуйте, maks1180, Вы писали:
M>Это да, но зато если он будет понимать, что вообще ничего не получил за 20 багов, то это может поможет!
нет, он просто откажется от такой забавной схемы, т.к. имеется ненулевая вероятность неадекватного заказчика, который будет потом все что угодно называть багом, лишь бы занизить стоимость
M>>Это да, но зато если он будет понимать, что вообще ничего не получил за 20 багов, то это может поможет!
J>нет, он просто откажется от такой забавной схемы, т.к. имеется ненулевая вероятность неадекватного заказчика, который будет потом все что угодно называть багом, лишь бы занизить стоимость
А если на фул-тайм программистов такую схему использовать ?
Здравствуйте, maks1180, Вы писали: M>Это да, но зато если он будет понимать, что вообще ничего не получил за 20 багов, то это может поможет!
Лично у меня такое вызывало бы сильное раздражение. А вообще, фиг знает, попробуйте, потом поделитесь результатами.
M>>Я очень устал от ужастного кода, в котором потом приходится исправлять баги. L>Пиши юнит-тесты.
Вот хороший пример, нужно было ф-цию которая возвращает расширения файла по имени на php, 20 сек в гугл и вот 4 готовых решения: http://cowburn.info/2008/01/13/get-file-extension-comparison/
Писать юнит тест для этой ф-ции, ушло бы значительно больше — да и какой смысл, если можно сразу исправить ф-цию.
Но даже в такой простой ф-ции программист допустил ошибку.
Здравствуйте, maks1180, Вы писали:
M>А если на фул-тайм программистов такую схему использовать ?
Я по молодости работал в конторе, в которой НЕ оплачивалось время на исправление багов, зарплата состояла из постояннои (1/3) и переменной частей (2/3), переменная, в свою очередь, рассчитывалась по часам, которые ты наработал на проекте. Причем это были не формальные часы, надо было идти к ПМ и говорить что ты делал и почему это заняло столько времени. Просто идти было реально некуда, на весь город было 2 конторы, а денег переехать в мск не было.
Работали там по большей части студенты, им было по приколу потусить, да еще и деньги получать. Больше 1/2 зп на постоянной основе получал мало кто. Я же задумался почему происходит такая херня, сначала шабашил, потом понял что это путь в никуда и сделал свой первый проект. Ко времени, когда контору разогнали я уже достиг некоторого прогресса и продаж было больше чем зп. На следующий месяц я бы и сам ушел, но не суть.
Суть в том, что на таких условиях ты можешь нанять либо:
1) студентов
2) людей, которым вообще некуда податься.
А поскольку программистов сейчас хантят со страшной силой, то оба эти пункта автоматически отпадают. Ни один уважающий себя студент в настоящее время не пойдет на такую работу. Следовательно наймешь ты либо неадеквата либо криворукого, что вообщем встанет тебе еще дороже.
M>>Писать юнит тест для этой ф-ции, ушло бы значительно больше — да и какой смысл, если можно сразу исправить ф-цию.
L>Писать юниты надо для ВСЕГО. Ибо :
Если я буду писать юниты — то это менее продуктивно, если другой программист — то нет гарантии, что он так же тяп-ляп напишет. Кто за ним будет проверять ?
Здравствуйте, lozzy, Вы писали:
L>Здравствуйте, maks1180, Вы писали:
M>>Я очень устал от ужастного кода, в котором потом приходится исправлять баги. L>Пиши юнит-тесты.
M>>Хочу попробывать следующую схему работы, например программист хочет за задачу $500, я готов заплатить $800, но за каждый найден баг буду вычитать 5%. M>>Т.е. 20 багов — и программист остался без денег. Ноль багов — получил больше чем хотел. M>>Кто-нибудь пробывал такую схему ? M>>Какие мысли есть по этому поводу ?
L>Попробуй, но не обижайся, если тебя пошлют на йуг. А так скорее всего и будет.
История называется "А де бль поиск"
Работал я как-то в госконторе. Софт собственный, внутренний. Бизинесс-логика + карты + увязка в бухгалтерией и внутренним документооборотом. Версию 1.0 писал молодые обер-лейтёнанты, которые неплохие управленцы (и посваливали в банки при первой возможности), но код их был ужасен: такой мешанины гуя, логика и работы с БД в жизни не видел.
Начал править баги, но через неделю решили что развивать это нельзя. И поэтому порешили что надо поддерживать старую систему, но по ходу дела писать с нуля новую.
Написал за 2 месяца (много отвлекались, когда к вам Юрий Михалыч в гости едет, нужно чтобы работало все. А то глав.архитекору Москвы попу отмылят, а мы все в следствие остаемся без премии. А это госконтора: формальная зарплата маленькая, зато премиями да авансами процентов 70 еще сверху идет)...
Дык вот когда было закончено, сказали что УГ! Потому как нет поиска. Достал папочку с рабочими бумажками, схемами, планами и попросил указать где хоть слово про поиск было в первом релизе новой версии? И правда, ни слова ни сказали.
И сколько баксов мне нужно было вычесть с заказчика (начальника) в этом случае?
Ошибаются все. Не ошибается тот, кто ничего не делает. Так что такой подход не работает. Имхо, нужно как-то оговаривать поддержку кода — тогда сам набажил, сам и правишь (причем уже почти забесплатно). Хорошо стимулирует писание небажливого кода. А это вычитание бачинских УГ. Был опыт в американской компании на собеседовании: опоздание минута за бакс. "Нивапрос" ответил я. Тогда задержка на работе после 6-ти (или когда там кончался день) — одна минута 2 бакса. На том и расстались с улыбчивыми по американски, но нашими парнями. Гонору как у МБА, а знаний ноль — ПТУ мозги не прививает.
Так что лучше отношения выстраивать правильно, а не с ходу рублем давить.
ПС: поиск я потом в том госконторском проекте написал. Лишних обид не было. Все поняли что лажанулись-то мы вместе, т.к. работаем вместе в одном отделе. Кто-то забыл сказать про поиск, кто-то забыл сказать что не-телепат. Но мы решали проблему, и причины ее возникновения, а не вопросы "кто виноват". Кстати, оценили модульность новой версии — поиск был прикручен достаточно быстро, за три недели (он там просто весьма специфичный).
Здравствуйте, maks1180, Вы писали:
L>>Писать юниты надо для ВСЕГО. Ибо : M>Если я буду писать юниты — то это менее продуктивно, если другой программист — то нет гарантии, что он так же тяп-ляп напишет. Кто за ним будет проверять ?
А code review тебе кто-то забанил? На мой взгляд самый эффективный способ работы с удаленшиками — это после коммита переделать код немножко, подстроить его под себя и накоммитить с комментами почему так а не иначе.
И не со словами "еп, чо ты тут набаговал ема", а с похвалами, мол, молодца, так держать, но вот тут косячек есть, поправь плиз.
Короче пряники нужны, пряников побольше, кнутов поменьше. Тогда работа пойдет.
Здравствуйте, maks1180, Вы писали:
M>Хочу попробывать следующую схему работы, например программист хочет за задачу $500, я готов заплатить $800, но за каждый найден баг буду вычитать 5%. M>Т.е. 20 багов — и программист остался без денег. Ноль багов — получил больше чем хотел. M>Кто-нибудь пробывал такую схему ? M>Какие мысли есть по этому поводу ?
нужна обоюдка — если ошибка программиста это следствие ошибки или недоговоренности в техзадании, то вычитать у вас 5% и отдавать программисту
Здравствуйте, jhfrek, Вы писали:
M>>Хочу попробывать следующую схему работы, например программист хочет за задачу $500, я готов заплатить $800, но за каждый найден баг буду вычитать 5%. M>>Т.е. 20 багов — и программист остался без денег. Ноль багов — получил больше чем хотел. M>>Кто-нибудь пробывал такую схему ? M>>Какие мысли есть по этому поводу ?
J>нужна обоюдка — если ошибка программиста это следствие ошибки или недоговоренности в техзадании, то вычитать у вас 5% и отдавать программисту
Это путь вникуда. Они будут заниматься поиском багов и недомолвок друг у друга вместо того, что бы работать.
Здравствуйте, lozzy, Вы писали:
J>>нужна обоюдка — если ошибка программиста это следствие ошибки или недоговоренности в техзадании, то вычитать у вас 5% и отдавать программисту L>Это путь вникуда. Они будут заниматься поиском багов и недомолвок друг у друга вместо того, что бы работать.
это путь в практическое осознание пагубности исходной идеи.
наши посты — это всего лишь слова, а так человек все на своей шкуре прочувствует, причем очень-очень быстро
M>А если на фул-тайм программистов такую схему использовать ?
я соглашусь с теми, кто писал выше про пряник.
имхо гораздо правильнее сделать это через код-ревью и бонусы. если человек у тебя на фуллтайме, он будет обучаться (достаточно быстро, если это не законченый тупезень) по результатам код-ревью, каждый удачный релиз отмеченный премией будет приятен сотруднику, он будет чувствовать нужность и важность своей работы, будет чувствовать что проект является частично его детищем и соответственно более трепетно к нему относиться.
в данном комментарии обобщил свой опыт как работника так и работодателя
Здравствуйте, lozzy, Вы писали:
L>Еще добавлю, что неожиданный $100 бонус добавляет к скорости гораздо лучше волшебного пендаля. Правда, подозреваю, что к этому привыкают.
Фигня. Это мало. Вот 5 тыс. -- искренне вам говорю -- совсем по другому начинаешь на работу смотреть. Но это для меня -- кому то и 5 мало будет.
Вообще я понял, что все дело в деньгах. Когда видишь, что вкалываешь за копейки (ошибся с оценкой и пр.) -- вся мотивация пропадает. Но если вдруг тебе предлагают сумму, которая позволит тебе жить как человек (в т.ч. переехать в другую страну, купить там дом) -- совершенно другое отношение к работе.
А вы тут лохи со своими 100 долларами. Копейки платите, нищеброды, да еще что-то там за них горло разработчикам душите.
Здравствуйте, 0K, Вы писали:
0K>А вы тут лохи со своими 100 долларами. Копейки платите, нищеброды, да еще что-то там за них горло разработчикам душите.
Кто там пару лет назад усирался, что дом в деревне за 3к рядом с люминиевым комбинатом и GPRS модемом на телеантенне на крыше — это эпический успех?
Здравствуйте, maks1180, Вы писали:
L>>Еще раз — это поможет тебе быть посланным на йуга. Кнут есть, пряника — нет. Это так не работает.
M>И пряник есть — без багов или мало багов — получит больше чем просил ! (прочитайте внимательно первое сообщение)
у тебя вообще есть опыт работы програмером? Думаеш легко найти за собой баги? Просто ищутся только чужие баги. Все нормальные програмеры это понимают, и на такой развод с "без багов или мало багов" не соглясятся. Считать количество багов с цельню установить оплату плохая идея — во первых начнете спорить "что есть баг", во вторых важен конечный результат и вовремя, а сколько багов будет в альфа версии — пофигу, если они будут вовремя исправлены.
это путь в практическое осознание пагубности исходной идеи. 
