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

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

А о чем

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

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

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

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

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

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

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

S>>>>А как иначе? А на этапе планирования — откуда ты знаешь, сколько "проведешь в отладке"? Там даже нельзя оценить насколько сложен код.
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>Но другие варианты есть. Сотрудник на зарплате.

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

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