Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>>Чем сложнее код — тем сложнее его отладить. В чем проблема
S>>Проблема в том, что простой код может быть результатом гораздо большего труда, чем труда, вложенного в сложный код.

S>Когда ты видешь результат, т.е. что этот код делает — можно понять усложнен он или можно написать проще.
Возможно, иногда. Но я не об этом.

S>>>Чем больше ты совершаешь багов — тем ты менее эффективен. Баги делают все, разница лишь в их количестве.
S>>Баги делают все и в результирующем коде (в хорошем коде) не будет следов багов и их исправлений.

S>И что? Ты примерно знаешь что 20% времен ушло на баги. В чем проблема приплюсовать 20%?
Это уже не "то, что сделано", а еще постороннее знание.

S>Или что, у тебя 200% иногда уходит на баги?
200% — сложно представить. Но бывает, что внесение кода новой фичи занимает 5-10% от фикса багов, внесенных при ее выполнении.

S>Да и посмотри просто историю коммитов.
Коммиты — фиксация изменений в определенный момент времени. То, что было внесено и исправлено между коммитами — об этом никто и никогда не узнает. При этом, измерение продуктивности коммитами — весьма сомнительная затея.

S>>>А как иначе? А на этапе планирования — откуда ты знаешь, сколько "проведешь в отладке"? Там даже нельзя оценить насколько сложен код.
S>>Я не предлагаю как иначе. Я опровергаю тезис о том, что по сделанной работе "должно быть очень просто ее оценить".

S>Не просто, но других вариантов просто нет.
Рад, что изначальный тезис о простоте разрушен.
Но другие варианты есть. Сотрудник на зарплате.

Здравствуйте, samius, Вы писали:

S>>Когда ты видешь результат, т.е. что этот код делает — можно понять усложнен он или можно написать проще.
S>Возможно, иногда. Но я не об этом.

А о чем

S>>И что? Ты примерно знаешь что 20% времен ушло на баги. В чем проблема приплюсовать 20%?
S>Это уже не "то, что сделано", а еще постороннее знание.

Нет, код уже отлажен, все проведено генеральное тестирование, баги исправлены и качество работы устраивает заказчика.

Т.е. результат работы кода — целиком и полностью устраивает заказчика. Вопрос лишь в оценке трудозатрат. К примеру, заказчик считает, что исполнитель хочет слишком много денег.

S>>Или что, у тебя 200% иногда уходит на баги?
S>200% — сложно представить. Но бывает, что внесение кода новой фичи занимает 5-10% от фикса багов, внесенных при ее выполнении.

Никаких новых фич или даже доработок не нужно. Есть отлаженный код. Нужно его оценить — не слишком ли много денег хочет исполнитель или норм.

S>>Да и посмотри просто историю коммитов.
S>Коммиты — фиксация изменений в определенный момент времени. То, что было внесено и исправлено между коммитами — об этом никто и никогда не узнает. При этом, измерение продуктивности коммитами — весьма сомнительная затея.

Как не узнает? Сделай diff и все увидешь. Коммиты частые.

S>>>>А как иначе? А на этапе планирования — откуда ты знаешь, сколько "проведешь в отладке"? Там даже нельзя оценить насколько сложен код.
S>>>Я не предлагаю как иначе. Я опровергаю тезис о том, что по сделанной работе "должно быть очень просто ее оценить".

S>>Не просто, но других вариантов просто нет.
S>Рад, что изначальный тезис о простоте разрушен.
S>Но другие варианты есть. Сотрудник на зарплате.

Это ничего не меняет — будет вопрос не слишком ли медленно работает сотрудник и не пора ли его заменить на более эффективного.

Или же напротив — сотрудник хочет повышения оплаты, т.к. считает что он работает больше других. Дать ему повышение или оставить все как есть. Как оценить?

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>Возможно, иногда. Но я не об этом.

S>А о чем
О том, о чем написал выше. В отношении оценки сделанного вопрос "можно ли проще" не актуален.

S>Нет, код уже отлажен, все проведено генеральное тестирование, баги исправлены и качество работы устраивает заказчика.

S>Т.е. результат работы кода — целиком и полностью устраивает заказчика. Вопрос лишь в оценке трудозатрат. К примеру, заказчик считает, что исполнитель хочет слишком много денег.

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

S>Никаких новых фич или даже доработок не нужно. Есть отлаженный код. Нужно его оценить — не слишком ли много денег хочет исполнитель или норм.
А это — не собачье дело заказчика.

S>>Коммиты — фиксация изменений в определенный момент времени. То, что было внесено и исправлено между коммитами — об этом никто и никогда не узнает. При этом, измерение продуктивности коммитами — весьма сомнительная затея.

S>Как не узнает? Сделай diff и все увидешь. Коммиты частые.
Что "коммиты частые"? Это требование заказчика к продукту?

S>>Но другие варианты есть. Сотрудник на зарплате.

S>Это ничего не меняет — будет вопрос не слишком ли медленно работает сотрудник и не пора ли его заменить на более эффективного.

S>Или же напротив — сотрудник хочет повышения оплаты, т.к. считает что он работает больше других. Дать ему повышение или оставить все как есть. Как оценить?

Это задача на порядок более сложная, чем оценка трудозатрат одного проекта. В общем случае хороших метрик не найдено. Если оценивать по коммитам/строчкам/багфиксам, то программист будет коммитить/писать строчки/фиксить баги. И успешно создавать их. Победит наипродуктивнейший, но проекту это не поможет.

Здравствуйте, samius, Вы писали:

S>Заказчика обычно интересуют не трудозатраты, а продукт. Если исполнитель не вписался в заранее оговоренный бюджет заказчика, то это не проблемы заказчика.

Заказчик не хочет переплачивать и считает, что исполнитель либо слишком медленно работал (к примеру, отвлекался и т.д.) и потратил часов слишком много, либо нечестно отмечал часы. А договаривались оценивать по часам.

Не верит что заняло столько времени.

Как объективно оценить?

S>>Как не узнает? Сделай diff и все увидешь. Коммиты частые.
S>Что "коммиты частые"? Это требование заказчика к продукту?

Это инициатива исполнителя — если что-то нужно изменить/удалить — то перед этим делается коммит. Т.е. все что сделано — все зафиксировано. Нет такого, что пришлось что-то удалять/переделывать не закоммитив.

S>Это задача на порядок более сложная, чем оценка трудозатрат одного проекта. В общем случае хороших метрик не найдено. Если оценивать по коммитам/строчкам/багфиксам, то программист будет коммитить/писать строчки/фиксить баги. И успешно создавать их. Победит наипродуктивнейший, но проекту это не поможет.

Проект разбит на модули и результат работы — это готовый отлаженный модуль. Если раздуть с целью увеличения количества строк — то это легко увидеть.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>Заказчик не хочет переплачивать и считает, что исполнитель либо слишком медленно работал (к примеру, отвлекался и т.д.) и потратил часов слишком много, либо нечестно отмечал часы. А договаривались оценивать по часам.

S>Не верит что заняло столько времени.

S>Как объективно оценить?
Объективно — никак. Раз договорился по часам — платит за часы.

S>>Что "коммиты частые"? Это требование заказчика к продукту?

S>Это инициатива исполнителя — если что-то нужно изменить/удалить — то перед этим делается коммит. Т.е. все что сделано — все зафиксировано. Нет такого, что пришлось что-то удалять/переделывать не закоммитив.
Ну ок. Закоммитил с багом, закоммитил багфикс, закоммитил багфикс багфикса. Отрефакторил — коммит. День прошел. За что из этого заказчик не захочет платить по часам?

S>>Это задача на порядок более сложная, чем оценка трудозатрат одного проекта. В общем случае хороших метрик не найдено. Если оценивать по коммитам/строчкам/багфиксам, то программист будет коммитить/писать строчки/фиксить баги. И успешно создавать их. Победит наипродуктивнейший, но проекту это не поможет.

S>Проект разбит на модули и результат работы — это готовый отлаженный модуль. Если раздуть с целью увеличения количества строк — то это легко увидеть.
ой ли? Часто код пишется раздутым и что бы его свернуть требуются специальные усилия. Если эти усилия не будут оплачены, и оплата будет идти за кол-во строк, то кто будет заниматься вообще рефакторингом? Да и исправить баг в 7и местах выгоднее, чем в одном.

Здравствуйте, samius, Вы писали:

S>Объективно — никак. Раз договорился по часам — платит за часы.

Но ведь объективно — работник может работать весьма медленно — делать целый месяц то, что можно сделать за день. Может даже делать это специально.

Т.е. должен быть некий объективный критерий, позволяющий определеть адекватна ли работа затраченному времени.

S>Ну ок. Закоммитил с багом, закоммитил багфикс, закоммитил багфикс багфикса. Отрефакторил — коммит. День прошел. За что из этого заказчик не захочет платить по часам?

Думаю что микро-менеджмент как раз не имеет смысла. Один день мог сделать мало а другой много. Нужно смотреть всю работу целиком.

S>>Проект разбит на модули и результат работы — это готовый отлаженный модуль. Если раздуть с целью увеличения количества строк — то это легко увидеть.
S>ой ли? Часто код пишется раздутым и что бы его свернуть требуются специальные усилия. Если эти усилия не будут оплачены, и оплата будет идти за кол-во строк, то кто будет заниматься вообще рефакторингом? Да и исправить баг в 7и местах выгоднее, чем в одном.

Раздутый код даже статистическими анализаторами будет видно.

Здравствуйте, Shmj, Вы писали:

S>>Объективно — никак. Раз договорился по часам — платит за часы.

S>Но ведь объективно — работник может работать весьма медленно — делать целый месяц то, что можно сделать за день. Может даже делать это специально.

Может, да. Заказчик тоже может иметь неправильное представление о том, что можно сделать за день, а что нет. И тоже, возможно, специально. В этом случае им не следует работать вместе.

S>Т.е. должен быть некий объективный критерий, позволяющий определеть адекватна ли работа затраченному времени.

Нет, не должен.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>Объективно — никак. Раз договорился по часам — платит за часы.

S>Но ведь объективно — работник может работать весьма медленно — делать целый месяц то, что можно сделать за день. Может даже делать это специально.
Так и я об этом же.

S>Т.е. должен быть некий объективный критерий, позволяющий определеть адекватна ли работа затраченному времени.
Кому должен?

S>>Ну ок. Закоммитил с багом, закоммитил багфикс, закоммитил багфикс багфикса. Отрефакторил — коммит. День прошел. За что из этого заказчик не захочет платить по часам?

S>Думаю что микро-менеджмент как раз не имеет смысла. Один день мог сделать мало а другой много. Нужно смотреть всю работу целиком.
Как именно? 2 гига репозиторий. Это много или мало?

S>>>Проект разбит на модули и результат работы — это готовый отлаженный модуль. Если раздуть с целью увеличения количества строк — то это легко увидеть.
S>>ой ли? Часто код пишется раздутым и что бы его свернуть требуются специальные усилия. Если эти усилия не будут оплачены, и оплата будет идти за кол-во строк, то кто будет заниматься вообще рефакторингом? Да и исправить баг в 7и местах выгоднее, чем в одном.

S>Раздутый код даже статистическими анализаторами будет видно.
Ну и даже пусть видно. Раз за сдувание кода не заплачено, какие вопросы?

Здравствуйте, Sharowarsheg, Вы писали:

S>Может, да. Заказчик тоже может иметь неправильное представление о том, что можно сделать за день, а что нет. И тоже, возможно, специально.

Именно. Ну за день, быть может, и сойдутся. А вот, к примеру, заказчик думает что сделанное тянет максимум на 2 недели работы, а работник говорит что работал месяц?

S>В этом случае им не следует работать вместе.

А как заранее можно определить, стоит ли работать вместе? Вот, договариваются за часы. Но работник поразумевает что за час сделает один объем а заказчик считает что другой? Как им соотнести ожидания друг друга?

Здравствуйте, samius, Вы писали:

S>>Т.е. должен быть некий объективный критерий, позволяющий определеть адекватна ли работа затраченному времени.
S>Кому должен?

Как способ разрешить конфликт. Т.е. когда работодатель говорит что слишком дорого, а работник говорит что не дорого а по рынку. Как резрешить?

S>>Думаю что микро-менеджмент как раз не имеет смысла. Один день мог сделать мало а другой много. Нужно смотреть всю работу целиком.
S>Как именно? 2 гига репозиторий. Это много или мало?

Смотреть исходный код конкретного модуля, который с нуля сделал работник. Там не будет 2 гига кода, если работа делалась 1-2 мес.

S>>>ой ли? Часто код пишется раздутым и что бы его свернуть требуются специальные усилия. Если эти усилия не будут оплачены, и оплата будет идти за кол-во строк, то кто будет заниматься вообще рефакторингом? Да и исправить баг в 7и местах выгоднее, чем в одном.

S>>Раздутый код даже статистическими анализаторами будет видно.
S>Ну и даже пусть видно. Раз за сдувание кода не заплачено, какие вопросы?

Считать количество строк отлаженного кода после проверок стат. анализаторами — это был бы выход. Т.е. можно было бы хоть как-то решать спорные ситуации, когда закачик говорит что слишком много денег хочешь.

А есть ли альтернативы?

Здравствуйте, Shmj, Вы писали:

S>>Может, да. Заказчик тоже может иметь неправильное представление о том, что можно сделать за день, а что нет. И тоже, возможно, специально.

S>Именно. Ну за день, быть может, и сойдутся. А вот, к примеру, заказчик думает что сделанное тянет максимум на 2 недели работы, а работник говорит что работал месяц?

В договор надо смотреть, о чём договорились, так и будет.

S>>В этом случае им не следует работать вместе.

S>А как заранее можно определить, стоит ли работать вместе? Вот, договариваются за часы. Но работник поразумевает что за час сделает один объем а заказчик считает что другой? Как им соотнести ожидания друг друга?

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

S>>>Т.е. должен быть некий объективный критерий, позволяющий определеть адекватна ли работа затраченному времени.
S>>Кому должен?
S>Как способ разрешить конфликт. Т.е. когда работодатель говорит что слишком дорого, а работник говорит что не дорого а по рынку. Как резрешить?

Зачем разрешать если есть контракт?
Метрику для оценки объема сложной работы пока не придумали.
Недоволен — открывай диспут (привлекай третью сторону) или пиши отзыв и пока.

Здравствуйте, Shmj, Вы писали:

S>З.Ы.
S>Еще вспомнил случай. Было что два знакомых строителя (братья во Христе) договорились с одним сделать ремонт. Расценки заранее оговорили — среднерыночные. У них даже не супер-современные инструменты были, т.е. не было всей этой пневматики и пр. Но работали они быстро, не курили, не лялякали — были высокомотивированными. Ну и за день сделали не на десятку а на штучку всего каждый (по расценкам). Приходит ентот бизнесмен, ему показали работу — доволен. Дают прайс — и тут он начинает зеленеть — как это штука в день, "вы что хотите больше меня зарабатывать???" Ну и тогда им пришлось сбавить темп, т.к. чисто по человечески их не поняли — как это строители столько зарабатывают — где-то его хотят наколоть.

Если отказавшись от перекура и "лалаканья" можно поднять в разы производительность, то что-то с этой производительностью не то.

S>>>Платят за месяц
M>>Это лишь один из способов оплаты труда
M>>И смотря сколько платят: 2500, 5000, 8000...
S>Сильно выше среднерыночной — никто платить не будет, т.к. не понимают зачем тратить деньги.

А сколько сейчас средняя цена еды на рынке?
Включая доширак и красную икру.

S>>>и чем быстрее будешь работать — тем дешевле твой труд.
M>>Чем не нравится вариант «зарабатывать больше»? Тебе ж в топике кучу способов предложили как.

S>Потому что все предложенные способы — это не разработка а предпринимательство.
Программист-фрилансер-консультант это программист, а не предпринематель.

Здравствуйте, Sharowarsheg, Вы писали:

S>В договор надо смотреть, о чём договорились, так и будет.

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

Здравствуйте, Muxa, Вы писали:

M>Недоволен — открывай диспут (привлекай третью сторону) или пиши отзыв и пока.

Вот! Об этом и вопрос — где взять третью сторону и какую объективную методику может применить эта сторона, чтобы с ней были все согласны?

А то я найду одну третью сторону а заказчик другую. Сторона заказчика скажет что работы на 1.5-2 недели а моя сторона скажет, что работы минимум на 3 мес. Кто прав?

Здравствуйте, alzt, Вы писали:

A>Если отказавшись от перекура и "лалаканья" можно поднять в разы производительность, то что-то с этой производительностью не то.

Почему же? Перекуры и ляляканья могут занимать 50% рабочего времени. Остальные 50 работают неспешно. Потом дома еще и набухаются — вы что строителей не знаете?

Здравствуйте, Muxa, Вы писали:

M>А сколько сейчас средняя цена еды на рынке?
M>Включая доширак и красную икру.

Посмотрите потребительскую корзину — она устанавливается на уровне министерства.

Цену труда разработчика узнать не сложно — для России 100 тыр., для "столиц" — 140 тыр.

S>>Потому что все предложенные способы — это не разработка а предпринимательство.
M>Программист-фрилансер-консультант это программист, а не предпринематель.

Нет, больше предприниматель со всеми вытекающими. Умение привлечь клиента, договора и пр.

M>>А сколько сейчас средняя цена еды на рынке?
M>>Включая доширак и красную икру.
S>Посмотрите потребительскую корзину — она устанавливается на уровне министерства.
S>Цену труда разработчика узнать не сложно — для России 100 тыр., для "столиц" — 140 тыр.

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

Здравствуйте, Muxa, Вы писали:

M>Средняя зарплата может ничего не значить, если работодателю требуется что-то нестандартное, за что он будет вынужнен, а иногда и рад платить сильно выше рынка. Глупо утверждать что таких случаев не бывает.

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