1. Проверить качество кода, насколько легко читается и поддерживается.
2. Увидеть сложные места, на которые могло уйти много времени/сил.
3. Посмотреть на общий объем кода.
— то может довольно точно определить, пригден ли данный код вообще и примерно сколько у него бы ушло времени/энергии на написание в обычном режиме работы (ускоренный шаг, скажем так, но не бег).
Если же чел. вообще плохо знаком с программированием, то все намного сложнее. Оценивать как-то нужно не заглядывавая в код. Риски такие:
1. Риск получить плохое качество работы.
Что делать? Ну конечно, смотреть как работает программа. Но тут риск — уже было, что не доведя до конца разработчики бросают/уходят с проекта, а новые или не хотят браться или говорят что эту хрень нужно только переписывать с нуля.
2. Риск перерасхода бюджета. Возьмет слишком много денег а работы даст мало.
Как решить? Варианты решения:
строго контролировать часы, чтобы оно сидело не рабочем месте не менее положенного и не занималось посторонними вещами. Ну и платить по рынку, то есть, к примеру, 600-800 руб. в час. для не Москвы. Так имеем как бы надежду, что оно отрабатывает и получится по рынку (т.е. нигде в другом месте дешевле не получится). Однако же вдруг оно просто просижывает часы и работает медленно?
исходить из общей стоимости, сколько гарантированно готовы потратить на проект. Разбить на этапы, попросить разработчиков самих же оценить в часах (стоимость часа типа константа), потом поторговаться и/или выкинуть лишнее, чтобы подогнать под нужную сумму денег. Но тут тоже риск — вдруг оценят не верно, сначала вроде будут укладываться в график, а когда потрачено 80% бюджета, выяснится что сделано не 80% работы а 20%
И в чем, собственно, вопрос. Было ли у вас, когда вашу работу оценивал тот, кто нулевой в программировании? Остались ли вы довольны, было ли сотрудничество плодотворным? Как организовали процесс?
Здравствуйте, Shmj, Вы писали:
S>Если же чел. вообще плохо знаком с программированием, то все намного сложнее. Оценивать как-то нужно не заглядывавая в код. Риски такие:
Когда-то много лет назад мою работу оценил человек, совсем не знающий программирования. По результатам мне присвоили 2-ю категорию, минуя 3-ю. Человек хорошо разбирался в своей предметной области.
Re: Когда оценивает работу не умеющий программировать...
Здравствуйте, Shmj,
S>1. Риск получить плохое качество работы.
Решается вменяемым ТЗ и испытаниями на соответствие каждому пункту ТЗ. Да, несомненно, написать это самое вменяемое ТЗ — немалый труд, по моему опыту хорошее ТЗ — это 60% работы. Но по крайней мере наличие оного означает, что заказчик четко представляет, что именно он хочет получить на выходе.
А если заказчик сам не знает, чего он хочет и как оценить "качество работы", то подход один — T&M.
S>2. Риск перерасхода бюджета. Возьмет слишком много денег а работы даст мало. S> строго контролировать часы, чтобы оно сидело не рабочем месте не менее положенного и не занималось посторонними вещами. Однако же вдруг оно просто просижывает часы и работает медленно?
Обыкновенный риск бизнеса, который нужно учесть в плане предупреждения рисков. И от "строгого контролирования часов" полезный выхлоп сильно меньше. Не говоря уж о том, что такой подход применим только для фрилансеров, апворкеров etc., но не для постоянных сотрудников. То есть тех, на кого можно скинуть неосновные производственные задачи. Для проектов с FP контроль часов вообще лишен смысла.
S> Но тут тоже риск — вдруг оценят не верно, сначала вроде будут укладываться в график, а когда потрачено 80% бюджета, выяснится что сделано не 80% работы а 20%
И это тоже обыкновенный риск бизнеса. (Отмечу, что в 90% случаев он реализуется ) По п.2 все — совершенно стандартные управленческие задачи, для толкового менеджера ни разу не проблема.
Re: Когда оценивает работу не умеющий программировать...
Здравствуйте, Shmj, Вы писали:
S>Было ли у вас, когда вашу работу оценивал тот, кто нулевой в программировании?
Было.
Задача ставилась в юз-кейсах. Принималась по ним же.
S>Как организовали процесс?
Почасовая оплата на полном доверии. S>Остались ли вы довольны,
Думаю, что с рейтом я тогда поскромничал. При этом, в момент договора он показался заказчику высоким.
В итоге, глядя на общую сумму, я считаю, заказчик сэкономил.
S>было ли сотрудничество плодотворным?
Софт работает почти 10 лет.
Re[2]: Когда оценивает работу не умеющий программировать...
Здравствуйте, Privalov, Вы писали:
P>Когда-то много лет назад мою работу оценил человек, совсем не знающий программирования. По результатам мне присвоили 2-ю категорию, минуя 3-ю. Человек хорошо разбирался в своей предметной области.
Не факт — может у вас развита способность внушать и быть убедительным и вам понравилось, что профан оценил ваши навыки выше чем есть на самом деле.
Re[2]: Когда оценивает работу не умеющий программировать...
Здравствуйте, Vlad_SP, Вы писали:
V_S>Обыкновенный риск бизнеса, который нужно учесть в плане предупреждения рисков. V_S>И это тоже обыкновенный риск бизнеса.
Вопрос в том, как этого избежать, если ты работаешь "вслепую".
Re[2]: Когда оценивает работу не умеющий программировать...
Здравствуйте, Mihas, Вы писали:
M>Думаю, что с рейтом я тогда поскромничал. При этом, в момент договора он показался заказчику высоким. M>В итоге, глядя на общую сумму, я считаю, заказчик сэкономил.
Вот именно — это уже тебе не выгодно. Если бы ты стал говорить, что сделано больше, потому что ты думал не о том, как бы быстрее получить деньги, а о проекте — то заказчик бы тебя не понял. Типа договаривались же за столько, так чего ты хочешь...
Если же чел. понимает сложность работы, может ее оценить — то просто даст тебе бонус, чтобы у тебя и далее была мотивация работать лучше — осознавая что труд будет увиден и награжден.
В долгосрочной перспективе лучше когда твой труд могут оценить. Именно твой труд, а не вообще результат запуска проекта — т.е. даже если проект провальный, но твой труд качественный — хочется получить достойную награду.
Иначе получается как игра в карты — награждается не твой труд а твое умение выторговать/убедить.
Здравствуйте, Shmj, Вы писали:
S>Не факт — может у вас развита способность внушать и быть убедительным и вам понравилось, что профан оценил ваши навыки выше чем есть на самом деле.
Человек работал с софтиной, которую делал в том числе и я. Он сам и его подчинениые с нашей программой работали, а не мы сидели и выполняли его указания. А программы гипнозом не владеют.
По ходу работы они задавали вопросы, что естественно. Повторно с одной и той же проблемой к нам не возвращались. Время — начало тотальной компьютеризации всего и вся. 90-е. Компов тогда все боялись, как огня.
Чувствую я, что мой оппонент снова заготовил себе ответ и ждет, когда его кто-нибудь здесь озвучит. Вера — она такая.
Re[3]: Когда оценивает работу не умеющий программировать...
Здравствуйте, Shmj,
S> Именно твой труд, а не вообще результат запуска проекта — т.е. даже если проект провальный, но твой труд качественный — хочется получить достойную награду.
Гм. Если проект провальный (грубо говоря, все деньги проели, а коммерческого продукта так и нет и/или продажи не пошли) — из каких денег ты рассчитываешь получить "достойную награду"?
Re[4]: Когда оценивает работу не умеющий программировать...
Здравствуйте, Vlad_SP, Вы писали:
V_S>То есть как??? PMBoK тебе в помощь. Эти-то риски (перерасход бюджета и выход за сроки проекта) совершенно стандартные.
Там наверняка будет привлечение экспертов, который смогут оценить и качество и стоимость... Но не для всех это подходит.
Re[4]: Когда оценивает работу не умеющий программировать...
Здравствуйте, Vlad_SP, Вы писали:
V_S>Гм. Если проект провальный (грубо говоря, все деньги проели, а коммерческого продукта так и нет и/или продажи не пошли) — из каких денег ты рассчитываешь получить "достойную награду"?
Проект может быть провальный по множеству причин — это стандартные риски бизнеса. Вы можете отлично выполнить свою работу, а проект все-равно будет провальным, т.к. кроме вас еще множество людей могут налажать и/или изменится ситуация на рынке (или же изначально сделано ошибочное предположение).
А награду вы получите не из прибыли а из начальных инвестиций, ведь до получения прибыли может пройти несколько лет (или вообще никогда не быть).
S>И в чем, собственно, вопрос. Было ли у вас, когда вашу работу оценивал тот, кто нулевой в программировании? Остались ли вы довольны, было ли сотрудничество плодотворным? Как организовали процесс?
да, конечно, у меня в работе это норма, нежели исключение.
все участвующие как правило довольны результатами.
процесс организован довольно просто:
— наша команда работает над проектом, реализуя необходимую заказчику функциональность
— далее проект приводится в соответствие требованиям сертификации
— продукт проходит сертификацию и поступает в продажу (сертификация подразумевает собой проверку конечного продукта на соответствие списку требований, без анализа исходного кода)
— продажи приносят деньги заказчику (и иногда нам), все довольны
Re: Когда оценивает работу не умеющий программировать...
Здравствуйте, уважаемый 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>И в чем, собственно, вопрос. Было ли у вас, когда вашу работу оценивал тот, кто нулевой в программировании? Остались ли вы довольны, было ли сотрудничество плодотворным? Как организовали процесс?
В контексте именно тех понятий, что знакомы тому, кто руководит
А как же иначе?