Здравствуйте, Shmj,

S>1. Риск получить плохое качество работы.

Решается вменяемым ТЗ и испытаниями на соответствие каждому пункту ТЗ. Да, несомненно, написать это самое вменяемое ТЗ — немалый труд, по моему опыту хорошее ТЗ — это 60% работы. Но по крайней мере наличие оного означает, что заказчик четко представляет, что именно он хочет получить на выходе.
А если заказчик сам не знает, чего он хочет и как оценить "качество работы", то подход один — T&M.

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

Обыкновенный риск бизнеса, который нужно учесть в плане предупреждения рисков. И от "строгого контролирования часов" полезный выхлоп сильно меньше. Не говоря уж о том, что такой подход применим только для фрилансеров, апворкеров etc., но не для постоянных сотрудников. То есть тех, на кого можно скинуть неосновные производственные задачи. Для проектов с FP контроль часов вообще лишен смысла.

S> Но тут тоже риск — вдруг оценят не верно, сначала вроде будут укладываться в график, а когда потрачено 80% бюджета, выяснится что сделано не 80% работы а 20%

И это тоже обыкновенный риск бизнеса. (Отмечу, что в 90% случаев он реализуется ) По п.2 все — совершенно стандартные управленческие задачи, для толкового менеджера ни разу не проблема.

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

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

— то может довольно точно определить, пригден ли данный код вообще и примерно сколько у него бы ушло времени/энергии на написание в обычном режиме работы (ускоренный шаг, скажем так, но не бег).

Если же чел. вообще плохо знаком с программированием, то все намного сложнее. Оценивать как-то нужно не заглядывавая в код. Риски такие:

1. Риск получить плохое качество работы.

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

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

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

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

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

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

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

Когда-то много лет назад мою работу оценил человек, совсем не знающий программирования. По результатам мне присвоили 2-ю категорию, минуя 3-ю. Человек хорошо разбирался в своей предметной области.

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

S>Было ли у вас, когда вашу работу оценивал тот, кто нулевой в программировании?
Было.
Задача ставилась в юз-кейсах. Принималась по ним же.

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

S>было ли сотрудничество плодотворным?
Софт работает почти 10 лет.

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

P>Когда-то много лет назад мою работу оценил человек, совсем не знающий программирования. По результатам мне присвоили 2-ю категорию, минуя 3-ю. Человек хорошо разбирался в своей предметной области.

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

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

V_S>Обыкновенный риск бизнеса, который нужно учесть в плане предупреждения рисков.
V_S>И это тоже обыкновенный риск бизнеса.

Вопрос в том, как этого избежать, если ты работаешь "вслепую".

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

M>Думаю, что с рейтом я тогда поскромничал. При этом, в момент договора он показался заказчику высоким.
M>В итоге, глядя на общую сумму, я считаю, заказчик сэкономил.

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

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

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

Иначе получается как игра в карты — награждается не твой труд а твое умение выторговать/убедить.

Здравствуйте, Shmj,

S> Вопрос в том, как этого избежать, если ты работаешь "вслепую".

То есть как??? PMBoK тебе в помощь. Эти-то риски (перерасход бюджета и выход за сроки проекта) совершенно стандартные.

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

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

Человек работал с софтиной, которую делал в том числе и я. Он сам и его подчинениые с нашей программой работали, а не мы сидели и выполняли его указания. А программы гипнозом не владеют.
По ходу работы они задавали вопросы, что естественно. Повторно с одной и той же проблемой к нам не возвращались. Время — начало тотальной компьютеризации всего и вся. 90-е. Компов тогда все боялись, как огня.

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

Здравствуйте, Shmj,

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

Гм. Если проект провальный (грубо говоря, все деньги проели, а коммерческого продукта так и нет и/или продажи не пошли) — из каких денег ты рассчитываешь получить "достойную награду"?

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

V_S>То есть как??? PMBoK тебе в помощь. Эти-то риски (перерасход бюджета и выход за сроки проекта) совершенно стандартные.

Там наверняка будет привлечение экспертов, который смогут оценить и качество и стоимость... Но не для всех это подходит.

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

V_S>Гм. Если проект провальный (грубо говоря, все деньги проели, а коммерческого продукта так и нет и/или продажи не пошли) — из каких денег ты рассчитываешь получить "достойную награду"?

Проект может быть провальный по множеству причин — это стандартные риски бизнеса. Вы можете отлично выполнить свою работу, а проект все-равно будет провальным, т.к. кроме вас еще множество людей могут налажать и/или изменится ситуация на рынке (или же изначально сделано ошибочное предположение).

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

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

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