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

L_G>Другое дело, что могут быть затруднения с
L_G>1) определением/оценкой объема сделанного (явно не по затраченным часам и не по строкам кода же)

Алгоритм оценки нужно хранить в секрете. К примеру алгоритм оценки сайта в поисковой выдаче Google — главная тайна корпорации, иначе узнав его — можно будет легко поисковик.

Алгоритм должен включать:

1. Статический анализ кода. В т.ч. соответствие принятым соглашениям, отсутствие дублирования кода, внятные наименования. В т.ч. и индекс сложности, maintainability-индекс и т.д. Т.е. прежде чем код оценивать — он должен пройти ревью и должны быть устранены все недочеты. В т.ч. дублирование и раздувание кода.

2. Анализ математически сложных алгоритмов. Это отдельная тема — там совсем другой подход к оценке. К примеру, если было задание реализовать некий крипто-алгоритм — такую работу стандартным способом не измеришь.

3. Мнение самого разработчика о затраченных силах/времени. Т.е. если он работал без выходных, к примеру, чтобы не выйти из потока и быстрее доделать — то нужно оплачивать больше, чем просто за потраченные дни.

4. Реально затраченное время. Оплата не должна быть ниже рыночной по итогам месяца — иначе чел. пошлет вас нахрен со всеми вашими оценками. Конечно, при условии что он не отлынивал от работы (в таком случае сам согласится на меньшую оплату или просто уйдет из проекта).

L_G>В общем, как всегда, с "идеальным" в реальности возникают проблемы.

Уж лучше так, чем тупо время трекать.

L_G>От этого недалеко до варианта с оценкой задач в деньгах еще до их отдачи в работу.

Далеко. Пословица есть — "Гладко было на бумаге, да забыли про овраги".

Когда работа готова — все уже видно. Когда только планируешь — то для оценки тебе нужно видеть на 10 шагов вперед. Если ты гроссмейстер и видешь все варианты на 10 шагов вперед — то не зарывай свой талант и не трать время на разработку.

L_G>С ним проблем еще больше, а область применения еще уже (кроме фриланса — вряд ли где есть, но теоретически...
L_G>еще может быть интересен тем, что конечный исполнитель может участвовать в оценке, вплоть до тендера)

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

Если же фрилансер выполняет что-то технически сложное, то:

1. Либо его нанимают на работу на постоянку. Если хорошо работает — обязательно найдут.
2. Либо он делает фирму по софто-строению и берет нормальные заказы по нормальным ценам.

Во втором случае просто берет хороший запас, если договариваются на фикс. Запас может быть легко в 10 раз. Минимум в 3 раза.

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

L_G>Другое дело, что могут быть затруднения с
L_G>1) определением/оценкой объема сделанного (явно не по затраченным часам и не по строкам кода же)

Алгоритм оценки нужно хранить в секрете. К примеру алгоритм оценки сайта в поисковой выдаче Google — главная тайна корпорации, иначе узнав его — можно будет обманывать поисковик.

Алгоритм должен включать:

1. Статический анализ кода. В т.ч. соответствие принятым соглашениям, отсутствие дублирования кода, внятные наименования. В т.ч. и индекс сложности, maintainability-индекс и т.д. Т.е. прежде чем код оценивать — он должен пройти ревью и должны быть устранены все недочеты. В т.ч. дублирование и раздувание кода. Уже после этого можно считать строки — иначе код можно будет легко раздувать и получать больше за код более низкого качества.

2. Анализ математически сложных алгоритмов. Это отдельная тема — там совсем другой подход к оценке. К примеру, если было задание реализовать некий крипто-алгоритм — такую работу стандартным способом не измеришь.

3. Мнение самого разработчика о затраченных силах/времени. Т.е. если он работал без выходных, к примеру, чтобы не выйти из потока и быстрее доделать — то нужно оплачивать больше, чем просто за потраченные дни.

4. Реально затраченное время. Оплата не должна быть ниже рыночной по итогам месяца — иначе чел. пошлет вас нахрен со всеми вашими оценками. Конечно, при условии что он не отлынивал от работы (в таком случае сам согласится на меньшую оплату или просто уйдет из проекта).

L_G>В общем, как всегда, с "идеальным" в реальности возникают проблемы.

Уж лучше так, чем тупо время трекать.

L_G>От этого недалеко до варианта с оценкой задач в деньгах еще до их отдачи в работу.

Далеко. Пословица есть — "Гладко было на бумаге, да забыли про овраги".

Когда работа готова — все уже видно. Когда только планируешь — то для оценки тебе нужно видеть на 10 шагов вперед. Если ты гроссмейстер и видешь все варианты на 10 шагов вперед — то не зарывай свой талант и не трать время на разработку.

L_G>С ним проблем еще больше, а область применения еще уже (кроме фриланса — вряд ли где есть, но теоретически...
L_G>еще может быть интересен тем, что конечный исполнитель может участвовать в оценке, вплоть до тендера)

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

Если же фрилансер выполняет что-то технически сложное, то:

1. Либо его нанимают на работу на постоянку. Если хорошо работает — обязательно найдут.
2. Либо он делает фирму по софто-строению и берет нормальные заказы по нормальным ценам.

Во втором случае просто берет хороший запас, если договариваются на фикс. Запас может быть легко в 10 раз. Минимум в 3 раза.