Оценка работы программистов.
Эээ. Проще по схеме с фиксированными ценами и оговоренными доплатами в случае форсмажора (10-50%). Имхо. А то запаришься вычислять скиллы каждого внешнего прогера, придумывать мегапоправки к "стандартному" прогеро-часу и проч. На почасовой оплате нужно работать с крутыми профи с хорошей репутацией. Опять же имхо.
Просто фишка в чем, если прогер захочет какую-то сумму, он найдет способ привести число часов к ней. Начиная от неточностей в тз и заканчивая тестированием. А с фикс суммой все более-менее четко сразу для обеих сторон. И не будет скандалов в конце по поводу "х*ли вы мне недоплатили, я там бекдор оставил, да и базу вам потер. случайно!"
т.е. при фиксированной сумме нужно стреситься убедить кодера, что на работу требуется меньше времени, чем оно требуется реально, чтобы он согласился на как можно меньшую его стоимость? 
запость в джобе, от полученной цифры возьми логарифм.
ага, и получишь результат с точностью до аддитивной величины... 
ну да, в джобе же умножают, а не суммируют
Блин, типа работодатели разные бывают, а данная схема вообще никак не относится к теме на*балова "несчастных" фрилансеров. Просто мое имхо, что она более разумна для обеих сторон для среднестатистических внешних разрабов. Так как в ней четко все оговорено, прогер получает ровно столько, сколько договаривались, и работодатель теряет ровно столько, сколько договаривались. И никаких зарплатных скандалов по окончанию проекта.
Платить почасовуху имеет смысл только проверенным и хорошим спецам, которые действительно смогут эффективно работать при динамическом или слегка расплывчатом тз, хорошо понимающих заказчиков в силу опыта работы с подобными задачами, не прибавляющим себе часы в неразумных пределах (так или иначе все любят деньги нахаляву, здесь же это практически как премия за отличную работу) и тыды. Для всех остальных - статичное и очень подробное тз + фиксированная оплата. Новые фичи? Опять четко ставим подзадачу, определяем стоимость и вписываем в дополнение к договору при согласии обеих сторон. Большие затраты на определение и постановку задач? Ну так не жалейте денег на грамотную команду под грамотным руководством и работайте "гибко", кто ж мешает.
Платить почасовуху имеет смысл только проверенным и хорошим спецам, которые действительно смогут эффективно работать при динамическом или слегка расплывчатом тз, хорошо понимающих заказчиков в силу опыта работы с подобными задачами, не прибавляющим себе часы в неразумных пределах (так или иначе все любят деньги нахаляву, здесь же это практически как премия за отличную работу) и тыды. Для всех остальных - статичное и очень подробное тз + фиксированная оплата. Новые фичи? Опять четко ставим подзадачу, определяем стоимость и вписываем в дополнение к договору при согласии обеих сторон. Большие затраты на определение и постановку задач? Ну так не жалейте денег на грамотную команду под грамотным руководством и работайте "гибко", кто ж мешает.
Вопрос, как оценить работу, в случае не совсем стандартного куска?
Как и все. Берешь доверенного программиста (замени любым доверенным спецом, хоть лично собой, если квалификация позволяет спрашиваешь о времени, умножаешь на его (доверенного программиста) рыночную стоимость. С этой суммой идешь к фрилансеру и торгуешься в рамках 5-10% (замени любой позволительной для заказчика погрешностью) погрешности. Понимаешь, стандартный или нестандартный кусок не имеет значения. Имеет значение, есть четкое тз или его нет. Именно четкость тз влияет на непредсказуемые риски увеличения затрат в первую очередь, имхо. Если "нестандартный" означает, что вы не можете поставить задачу четко, то блин, у вас проблемы. Ну например, наймите этого исполнителя на небольшой срок для проведения анализа сложностей реализации либо вариантов реализации (положите ему некоторую пусть даже почасовую зп, благо срок короткий). По результатам принимайте решение, составьте тз и нанимайте этого же исполнителя на саму задачу. Но вообще для больших задач предпочтительно иметь свой небольшой штат хороших спецов под такие проблемы. То есть наружу отдавать только продуманные и подтвержденные задачи.
При оплате за час получается, что чем лучше работаешь, тем меньше получаешь Схема явно неустойчивая.
Схема явно неустойчивая.Дык, по этому поводу и нужно норму выставлять. Та же проблема с программистами в штате. Например, ставка - 2000 у.е. в мес.
Типа предполагается, что 40 часов чувак за нее работает.
Но один за 40 часов до хрена сделает, а второй - в два раза меньше. В итоге получается хрень.
Типа предполагается, что 40 часов чувак за нее работает.
Но один за 40 часов до хрена сделает, а второй - в два раза меньше. В итоге получается хрень.
Но один за 40 часов до хрена сделает, а второй - в два раза меньше. В итоге получается хрень.В итоге первому повысят до 4000 в месяц, и никакой хрени не будет.
По какой метрике оценивать? Количество строк кода?
Можно дохрена бестолкового кода написать. Как уйти от субъективизма - вроде этот сделал больше.
Можно дохрена бестолкового кода написать. Как уйти от субъективизма - вроде этот сделал больше.
Почему нельзя исходить из бюджета продукта?
ок, предложи методику.
Допустим есть продукт, на него бюджет x тысяч у.е. Дальше что?
Допустим есть продукт, на него бюджет x тысяч у.е. Дальше что?
Дальше разбиваем продукт на куски с выставлением каждому стоимости в процентах от бюджета. И ищем людей который за эти деньги готовы сделать каждый кусок.
По какой метрике оценивать? Количество строк кода?Я думаю, что существуют методики, которые позволяют это определить. Весьма показательной может быть даже статистика по багтрекеру.
Можно дохрена бестолкового кода написать. Как уйти от субъективизма - вроде этот сделал больше.
Что делать, если априорная оценка трудоемкости кусков оказалась неверной? В программировании же заранее очень мало известно, даже если прототип написан.
В программировании же заранее очень мало известно, даже если прототип написан.Количество багов тоже важно - безусловно. Вопрос - какие есть готовые методики, чтобы велосипед не изобретать.
Что делать, если априорная оценка трудоемкости кусков оказалась неверной?Можно какую то часть бюджета оставить для возможного лавирования, да и относительный сравнения менее подвержены ошибкам чем абсолютные.
по хорошему нужно создать иститут оплаты интеллектуального труда.
В этом инстетуте выпускать госты, в частности на прогерство, которые буду составляться на основе исследования написания стандартных задач, на различных языках. Потом произвольный проект разбивать на подзадачи и считать
хотя гемора на самом деле будет огого
В этом инстетуте выпускать госты, в частности на прогерство, которые буду составляться на основе исследования написания стандартных задач, на различных языках. Потом произвольный проект разбивать на подзадачи и считать
хотя гемора на самом деле будет огого
Тут и начинается вопрос - а как оценивать лавирование?
И более интересный вопрос - а как составлять бюджет проекта?
И более интересный вопрос - а как составлять бюджет проекта?
Тут и начинается вопрос - а как оценивать лавирование?А зачем его оценивать? Где получилось сделать дешевле, залавировали в плюс, где дороже в минус.
а как составлять бюджет проекта?
Бюджет в плане какую общую сумму стоит потратить?
Еще раз. Решили А,Б,В,Г писать продукт. Разбили на 4 части. Примерно поровну по трудоемкости.
Выяснилось, что часть А - гораздо легче, по мнению, Б,В. Но Г согласен с А, что часть равноценна.
Б - считает, что его часть самая тяжелая, но с ним никто не согласен.
В - считает, что его часть тяжелей чем обычно, и уж точно тяжелей по сравнению с А
ну и.т.п. - в итоге на выходе, если мы делим бабки поровну, получается команда недовольных программеров, дело может даже до документации не дойти, а еще продукт нужно поддерживать.
Т.е. нужно объявить какие-то правила игры, по которым оценивается кто сколько сделал и с чем все будут согласны.
Как для штатных, так и для фрилансов. Вопрос, как это сделать?
Придумывать с нуля не хочется.
Выяснилось, что часть А - гораздо легче, по мнению, Б,В. Но Г согласен с А, что часть равноценна.
Б - считает, что его часть самая тяжелая, но с ним никто не согласен.
В - считает, что его часть тяжелей чем обычно, и уж точно тяжелей по сравнению с А
ну и.т.п. - в итоге на выходе, если мы делим бабки поровну, получается команда недовольных программеров, дело может даже до документации не дойти, а еще продукт нужно поддерживать.
Т.е. нужно объявить какие-то правила игры, по которым оценивается кто сколько сделал и с чем все будут согласны.
Как для штатных, так и для фрилансов. Вопрос, как это сделать?
Придумывать с нуля не хочется.
Мне б для ответа конкретики побольше
По какой метрике оценивать? Количество строк кода?Да ну забей уже. Оценивай так, как хочешь, если на тебе лежит ответственность за проект. Работай через премии. Ну ошибешься раз, дашь кому-то то, что он не заслуживает. Ну и что, ошибся раз - и хрен с ним. От субъективизма ты никогда никуда не денешься все равно. А так три раза премируешь - пора поднимать ставку.
Можно дохрена бестолкового кода написать. Как уйти от субъективизма - вроде этот сделал больше.
Т.е. нужно объявить какие-то правила игры,Объявить одного начальником.
по хорошему нужно создать иститут оплаты интеллектуального труда.есть НИИ труда, по идее оно и должно этим заниматься. Не знаю, может быть у него и исследования какие-то есть на эту тему. Проблема только в том, что 1) такие институты без должного финансирования нормально работать не будут, т.е. актуальных нормативов не будут выдавать 2) В России госдумские законодатели на рекомендации подобных институтов плюют, и выдают нормативы от собственной балды (время от времени выкидывают какие-то фичи для работников, оставшиеся от советского законодательства) 3) работодатели кладут жирный член на российское законодательство. И собственно, каждый из этих пунктов следует из остальных
Так что по-хорошему такой институт есть, а толку?
Я все таки хочу уйти от субъективизма. Правильно ли я понял, что о существовании не субъективных оценок ты не знаешь?
Скажем так, даже "объективные" оценки (кол-во кода, кол-во тестов, качество и того и другого, выполнение подзадач по графику или быстрее) все равно делаются людьми. Я же не предлагаю кидать кости и выдавать премии. Но везде будет оценка человека, а она субъективна по определению.
Я все таки хочу уйти от субъективизма. Правильно ли я понял, что о существовании не субъективных оценок ты не знаешь?
Делишь задание на 4 части, устраиваешь турнир по Starcraft, Quake или еще какой, хоть в карты. Победивший первым выбирает себе задание, и т.д. проигравший кодит что осталось.
была такая старая задачка про n пиратов, делящих клад. можно попробовать её применить. 
задачка про "справедливый" раздел пирога? 
Она тут не годится сразу по ряду причин
Она тут не годится сразу по ряду причинЗадача.Вот такие проблемы всегда встают у руководителей, которые пытаются руководить программистами, но при этом сами программистами не являются. А фриланс тут не причём. В офисе встанет та же проблема, ведь программист сидя за компом не всегда программирует.
Есть программисты, работающие как фрилансеры и пишущие разные куски кода. Вопрос - как оценивать стоимость того или иного задания?
Устоявшаяся практика - стоимость часа на количество часов, тогда вопрос - как оценивать адекватность заявленного времени работы?
Думаешь оценка одного программиста босса будет восприниматься остальными адекватно? Я могу давать оценку трудоемкости того или иного куска с точностью плюс/минус валенок, важно чтобы все кто работает, воспринимали оценку как справедливую.
Если у тебя есть авторитет в коллективе - будет восприниматься. Нет - тогда и "объективность" не поможет. И конкретно к программистам это не относится, это все общечеловеческое. Кстати, я уже перестал понимать, тебе что конкретно нужно, методика выставления оценок или согласие фрилансеров с твоими оценками? Так вот последнее ты никогда не предскажешь заранее.
Вот здесь достаточно авторитетный товарищ рассуждает о том, что формальные метрики не работают:
http://blogs.msdn.com/larryosterman/archive/2004/04/20/11699...
http://blogs.msdn.com/larryosterman/archive/2004/04/20/11699...
про формальные метрики еще страуструп писал. в третьем издании, по крайней мере, было.
Ну тогда не надо выеживаться, а надо - чтобы начальник сам определял сложность частей работы, а если возникнут неожиданные проблемы, или задача окажется труднее чем казалось - был в состоянии переоценить сложность.
типа того
Бред.
Дело не в том, что она будет субъективна.
Дело в том, что она, как любой другой формальный критерий, не будет означать то, что хочется (реально затраченный труд). Потому что при любом формальный критерии можно ничего не делать, а повышать его результат; или, наоборот, по уши уйти в работу и получить очень низкую оценку. Примерами могут служить количество багов, количество потраченного времени итд (неважно, что считается лучше - меньшее значение или большее).
Дело не в том, что она будет субъективна.
Дело в том, что она, как любой другой формальный критерий, не будет означать то, что хочется (реально затраченный труд). Потому что при любом формальный критерии можно ничего не делать, а повышать его результат; или, наоборот, по уши уйти в работу и получить очень низкую оценку. Примерами могут служить количество багов, количество потраченного времени итд (неважно, что считается лучше - меньшее значение или большее).
Дело в том, что она, как любой другой формальный критерий, не будет означать то, что хочется (реально затраченный труд)Это кто сказал, что в программировании оценивается реально потраченный труд? Во многом идет оплата и за то, что "знал, где стукнуть". См зарплаты ораклистов, например.
То, что ты написал, это какой-то лепет младенца. Формальная методика оценивает именно то, что она должна, твои желания тут не учитываются. Если ты решишь ставить свою оценку по методике Н, то извини, ты субъективно решил, что она оценивает то, что ты хочешь, а не то, что она действительно оценивает. Все эти формальные методики дают тебе некоторое дополнительное поле для размышления и постановки своей субъективной оценки.
Если ты решишь ставить свою оценку по методике Н, то извини, ты субъективно решил, что она оценивает то, что ты хочешь, а не то, что она действительно оцениваетЭто не я решил.
Это какой-то гипотетический начальник из этого треда пытается понять, как оценить труд программистов, и ищет наилучшую методику, не понимая, что все они никакого отношения к собственно труду не имеют.
имхо: много прогеров не оптимально решают поставленные задачи, зачастую ващще делать ничего не нужно а нужно тока научить юзверей правильно пользоваццо существующей системой а руковосдтво не сечет этого, ставит криво задачу а прогер в лоб ее делает - в итоге он и деньги сдерет и систему ухудшит, а главное что поймут это когда нужно будет обновлять например и тогда придется заплатить большие бабки.. имхо: лучше платить крутому прогеру за ничего не делание чем слабому прогеру меньшие бабки за "стучание по клавишам"
лучше платить крутому прогеру за ничего не делание чем слабому прогеру меньшие бабки за "стучание по клавишам"кстати, совершенно верно. Также, иногда лучше когда крутой ленивый прогер найдёт фришную или дешёвую либу, чем когда крутой, но трудолюбивый наваяет что-то своё и кривое.
своё и кривое.все большие сильно нетиповые решения писанные не крупными авторитетными фирмами кривые
Когда над задачей пару лет работает группа из 10-20 разработчиков и работа финансируется крупной фирмой, то результат будет по-любому лучше, чем если ты с парой коллег сам что-то за месяц наваяешь.
Когда над задачей пару лет работает группа из 10-20 разработчиков и работа финансируется крупной фирмой, то результат будет по-любому лучше, чем если ты с парой коллег сам что-то за месяц наваяешь.+1
да и еще зачастую многие руководители забывают что вопрос поддержки стоит много денег для самописных решений, ну написал геней решение и поехал отдыхать на канары а дальше кто будет в его соплях разбираццо? про мелкие фирмы можно сказать тоже самое, а вот крупная компания-разработчик все-таки несет хоть какуето ответственность..
Не, синдром NIH - наше всё, а фришные либы зачастую оказываются диким дерьмом 
зачастую ващще делать ничего не нужно а нужно тока научить юзверей правильно пользоваццо существующей системой а руковосдтво не сечет этогоЭто ты что имел в виду?
Мы, например, на свою панель потратили N человеколет, зато каждому пользователю при каждой операции сократили время... да пусть даже на одну минуту - это значит, что после 2000*N операций сэкономленного времени будет больше, чем потраченного (а на самом деле, есть куча таких операций, которые в других существующих решениях делаются через жопу или вообще вручную...)
Может, тот же 1С тоже не надо было разрабатывать, а надо было обучить юзверей правильно пользоваться существующими счётами, калькуляторами и папками для бумаг?
а в чем тогда крутость прогера, если он может наваять что-то кривое?
Вопрос - как оценивать стоимость того или иного задания?если тебя интересует научная сторона вопроса, то могу подсказать что по этому поводу придумало человечество (занимался одно время, даже статьи некие есть
)COCOMO, IFPUG и иже с ними , а дальше здравый смысл (обязательный этап!)
Вот здесь достаточно авторитетный товарищ рассуждает о том, что формальные метрики не работают:http://blogs.msdn.com/larryosterman/archive/2004/04/20/11699...наверно интересная статья,
жаль что англицки, - я по ненашему не умею подиагонали читать =(
Есть бумажная на русском.
вот в этом и крутость. По-настоящему крутой программер способен наваять даже нечто кривое.
мм =)
загляну тогда к вам как-нибудь
загляну тогда к вам как-нибудь
Есть бумажная на русскомТак запостил бы.... И первую часть тоже.
Устоявшаяся практика - стоимость часа на количество часов, тогда вопрос - как оценивать адекватность заявленного времени работы?
Проси их оценить, сколько понадобится времени на каждую задачу, до начала работы. Если заявленная оценка не адекватна, ты сможешь отдать задачу другому программисту, или сделать ее сам. Если кто-то регулярно превышает заявленное время – делай соответствующие выводы. Чем более детальная разбивка на задачи, тем больше контроля, но и больше времени потребуется на управление всем этим.
Оставить комментарий
and-guzij
Задача.Есть программисты, работающие как фрилансеры и пишущие разные куски кода. Вопрос - как оценивать стоимость того или иного задания?
Устоявшаяся практика - стоимость часа на количество часов, тогда вопрос - как оценивать адекватность заявленного времени работы?