Нормирование труда по сопровождению Аксапты

[coolibin]

Цитата:

Сообщение от Lemming

Ответ: так надо

Так о том и речь. Налицо не недоработка программиста, который с какого-то прибабаха был "ОБЯЗАН ЗНАТЬ" сам, а недоработка руководителя, который лучше бы ПРАВИЛЬНО ОБЪЯСНИЛ ЗАДАЧУ. И в это его объяснение, если нужно, кроме тз можно также было включить и маркетинговые вопросы.

[Zabr]

Цитата:

Сообщение от coolibin

Налицо не недоработка программиста, который с какого-то прибабаха был "ОБЯЗАН ЗНАТЬ" сам, а недоработка руководителя, который лучше бы ПРАВИЛЬНО ОБЪЯСНИЛ ЗАДАЧУ.

Хороший программист должен был прочесть ТЗ и задать вопросы до того, как начать разработку. Ответ "так надо" говорит не только о том, что программист не понял сходу пункт N, но и о том, что он не попытался устранить это непонимание. Вывод: программист был неважный.

[Lemming]

Цитата:

Сообщение от Zabr

Ответ "так надо" говорит не только о том, что программист не понял сходу пункт N, но и о том, что он не попытался устранить это непонимание. Вывод: программист был неважный.

Браво, спасибо То ли я невнятно написал, то ли читают меня "задом на перед".

з.ы. Я там в роли программиста был, если из контекста непонятно.

[coolibin]

Цитата:

Сообщение от Zabr

Хороший программист должен был прочесть ТЗ и задать вопросы до того, как начать разработку. Ответ "так надо" говорит не только о том, что программист не понял сходу пункт N, но и о том, что он не попытался устранить это непонимание. Вывод: программист был неважный.

Он так и сделал, если вы не поняли. Но с нулевой пользой.

[tolstjak]

Цитата:

Сообщение от coolibin

Он так и сделал, если вы не поняли. Но с нулевой пользой.

С пользой для кого?

Если проблем с реализацией ТЗ не возникло, то наверное и проблем не было.
А если они возникли, и начинаются разборки....
И тут уже, на какой стороне ты находишься.

Если на стороне консультанта, то:
можно возразить, а почему он не настоял на том, чтобы ему все-таки объяснили смысл пункта N.

Если на стороне программиста, то:
сделаю как написано а там ....

А вывод мне кажется однозначный - начальник виноват. Одного не научил объяснять, другого спрашивать.



P.S.
А как все-таки с нормированием труда по сопровождению?
Никто не нормирует своих программистов. когда сделают, тогда и ладно?

[Lemming]

Цитата:

Сообщение от tolstjak

Если на стороне программиста, то:
сделаю как написано а там ....

А вывод мне кажется однозначный - начальник виноват. Одного не научил объяснять, другого спрашивать.

Эко тут некоторых пробило на выводы...Кстати, "другого" можно заменить на Lemming-а, что бы Ваш мессадж яснее читался, а то со стороны как-то неприлично выглядит К тому же, с чего вообще эти далеко идущие выводы: "сделаю как написано" и прочие? Где в моем посте было сказано, что ответ "так надо" меня удовлетворил и я плюнув на все, начал делать как написано?

[tolstjak]

Цитата:

Сообщение от Lemming

Эко тут некоторых пробило на выводы...Кстати, "другого" можно заменить на Lemming-а, что бы Ваш мессадж яснее читался, а то со стороны как-то неприлично выглядит К тому же, с чего вообще эти далеко идущие выводы: "сделаю как написано" и прочие? Где в моем посте было сказано, что ответ "так надо" меня удовлетворил и я плюнув на все, начал делать как написано?

Извините если обидел.

[egorych]

Цитата:

Сообщение от tolstjak

Если на стороне программиста, то:
сделаю как написано а там ....

Кстати, есть такой тип забастовки - итальянский. Когда делают ровно то, что написано в инструкции. Говорят очень эффективно на начальников воздействует.

[Мартынов Дмитрий]

Цитата:

Сообщение от tolstjak

P.S.
А как все-таки с нормированием труда по сопровождению?

Не я ее придумал, а один опытный управленец с которым я работал. В ПО он разбирался мало - но если необходимо - вникал. Я лишь пытаюсь формализовать то, что он успешно использовал.
Но сначала термин: Сопровождение давайте рассматривать, как поддержка действующей системы в рабочем состоянии.

Представим, что консультант отвечает за работоспособность определенного модуля. Тогда за каждый день работы начисляем балы следующим образом:
+ 1 если модуль работает и консультант присутствует на рабочем месте
+ 5 если модуль не работает и консультант отсутствует на рабочем месте
- 20 если модуль не работает.

Дальше, посчитайте количество балов в месяце, на вашем проекте, и исходя из этого сделайте определите стоимость бала....

Понятно, что цифры приблизительные - важен принцип. Думаю что это принцип изначально возник как протест против финансирования ИТ по остаточному принципу - "раз все работает ок, может ИТ зарплату не платить вообще - вроде все работает само..."

[Bober]

Цитата:

Сообщение от Мартынов Дмитрий

Н
Но сначала термин: ...........
начисляем балы ........

Вот-вот, начните с определения термина "балл" (или "бал" по-вашему). Хорошо - это когда много баллов или когда мало баллов? (аналогия из спорта: много баллов в фигурном катании это хорошо, а много баллов в гольфе это плохо).
Из вашего примера это непонятно. Скажем, в месяце 22 рабочих дня. Весь месяц и консультант отсутствует, и модуль не работает. По вашему пункту 2 консультант наберет плюс 110 баллов; с другой стороны, эта ситуация подпадает и под пункт 3 (система не работает, наличие консультанта не определено) , консультант набирает минус 440 баллов. Вы пишите "важен принцип", вот и объясните его, как у вас так получается, что фиг поймешь что вы пишите.

[Мартынов Дмитрий]

Цитата:

Сообщение от Bober

Вот-вот, начните с определения термина "балл" (или "бал" по-вашему). Хорошо - это когда много баллов или когда мало баллов?

Получилась ерунда, сори, действительно ошибся. Одно НЕ было лишним...
Итак правильный вариант: ("+" значит плюс к зарплате)

+ 1 если модуль работает и консультант присутствует на рабочем месте
+ 5 если модуль работает и консультант отсутствует на рабочем месте
- 20 если модуль не работает