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

S>Если работу оценивает тот, кто может:

S>1. Проверить качество кода, насколько легко читается и поддерживается.
S>2. Увидеть сложные места, на которые могло уйти много времени/сил.
S>3. Посмотреть на общий объем кода.

S>- то может довольно точно определить, пригден ли данный код вообще и примерно сколько у него бы ушло времени/энергии на написание в обычном режиме работы (ускоренный шаг, скажем так, но не бег).
+100500
Когда твой шеф умеет программировать — с ним всегда легче найти общий язык и вообще работать

S>Если же чел. вообще плохо знаком с программированием, то все намного сложнее. Оценивать как-то нужно не заглядывавая в код. Риски такие:
S>1. Риск получить плохое качество работы.
+100500
Нужны четкие критерии понятия "качество_работы"!

S>Что делать? Ну конечно, смотреть как работает программа. Но тут риск — уже было, что не доведя до конца разработчики бросают/уходят с проекта, а новые или не хотят браться или говорят что эту хрень нужно только переписывать с нуля.

Говорить, что нужно переписывать с нуля — будет студент
Профессионал — сумеет разобраться и подправить то, что нуждается в правке.

S>2. Риск перерасхода бюджета. Возьмет слишком много денег а работы даст мало.

Для этого и существует "испытательный_срок".

S>Как решить? Варианты решения:

S>

строго контролировать часы, чтобы оно сидело не рабочем месте не менее положенного и не занималось посторонними вещами. Ну и платить по рынку, то есть, к примеру, 600-800 руб. в час. для не Москвы. Так имеем как бы надежду, что оно отрабатывает и получится по рынку (т.е. нигде в другом месте дешевле не получится). Однако же вдруг оно просто просижывает часы и работает медленно?

Очень плохая идея — что для Москвы, что для Минска, что для Парижа.

S>

исходить из общей стоимости, сколько гарантированно готовы потратить на проект. Разбить на этапы, попросить разработчиков самих же оценить в часах (стоимость часа типа константа), потом поторговаться и/или выкинуть лишнее, чтобы подогнать под нужную сумму денег. Но тут тоже риск — вдруг оценят не верно, сначала вроде будут укладываться в график, а когда потрачено 80% бюджета, выяснится что сделано не 80% работы а 20%

Также идея некудышная...
Ну есть задача — разработка ПО для марсохода.
Как будешь оценивать и торговаться?

S>И в чем, собственно, вопрос. Было ли у вас, когда вашу работу оценивал тот, кто нулевой в программировании? Остались ли вы довольны, было ли сотрудничество плодотворным? Как организовали процесс?

В контексте именно тех понятий, что знакомы тому, кто руководит
А как же иначе?

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

S>Если работу оценивает тот, кто может:

S>1. Проверить качество кода, насколько легко читается и поддерживается.
S>2. Увидеть сложные места, на которые могло уйти много времени/сил.
S>3. Посмотреть на общий объем кода.

S>- то может довольно точно определить, пригден ли данный код вообще и примерно сколько у него бы ушло времени/энергии на написание в обычном режиме работы (ускоренный шаг, скажем так, но не бег).
+100500
Когда твой шеф умеет программировать — с ним всегда легче найти общий язык и вообще работать

S>Если же чел. вообще плохо знаком с программированием, то все намного сложнее. Оценивать как-то нужно не заглядывавая в код. Риски такие:
S>1. Риск получить плохое качество работы.
+100500
Нужны четкие критерии понятия "качество_работы"!

S>Что делать? Ну конечно, смотреть как работает программа. Но тут риск — уже было, что не доведя до конца разработчики бросают/уходят с проекта, а новые или не хотят браться или говорят что эту хрень нужно только переписывать с нуля.

Говорить, что нужно переписывать с нуля — будет студент
Профессионал — сумеет разобраться и подправить то, что нуждается в правке.

S>2. Риск перерасхода бюджета. Возьмет слишком много денег а работы даст мало.

Для этого и существует "испытательный_срок".

S>Как решить? Варианты решения:

S>...строго контролировать часы, чтобы оно сидело не рабочем месте не менее положенного и не занималось посторонними вещами. Ну и платить по рынку, то есть, к примеру, 600-800 руб. в час. для не Москвы. Так имеем как бы надежду, что оно отрабатывает и получится по рынку (т.е. нигде в другом месте дешевле не получится). Однако же вдруг оно просто просижывает часы и работает медленно?

Очень плохая идея — что для Москвы, что для Минска, что для Парижа.
Строгий контроль по часам == недоверие_к_работнику
Hint: высиживание часов ещё ничего не говорит о реальном качестве продукта.

S>...исходить из общей стоимости, сколько гарантированно готовы потратить на проект. Разбить на этапы, попросить разработчиков самих же оценить в часах (стоимость часа типа константа), потом поторговаться и/или выкинуть лишнее, чтобы подогнать под нужную сумму денег. Но тут тоже риск — вдруг оценят не верно, сначала вроде будут укладываться в график, а когда потрачено 80% бюджета, выяснится что сделано не 80% работы а 20%

Также идея некудышная...
Ну есть задача — разработка ПО для марсохода.
Как будешь оценивать и торговаться?

S>И в чем, собственно, вопрос. Было ли у вас, когда вашу работу оценивал тот, кто нулевой в программировании? Остались ли вы довольны, было ли сотрудничество плодотворным? Как организовали процесс?

В контексте именно тех понятий, что знакомы тому, кто руководит
А как же иначе?