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

[coolibin]

Цитата:

Сообщение от Андре

Ну, здесь тоже не все так однозначно
link

Там, во-первых, не наш военный опыт, а немецкий. А во-вторых, повеселило:

Цитата:

... Другими словами, программисты должны разбираться в продакт менеджменте и маркетинге. Не обязательно глубоко - им не обязательно уметь генерировать стратегии и знать нюансы ранка, но они ОБЯЗАНЫ ПОНИМАТЬ продуктовую стратегию, знать целевую аудиторию, ее потребности, и особенности позиционирования для того продукта, который разрабатывают.

Вообщем, в идеале, программисты должны делать вообще все сами, начиная от поиска заказчиков, принятия стратегических решений, кончая мытьем полов и послепродажным сопровождением, а управленцы должны только раз в месяц приходить за зарплатой. Вот о чем мечтает продвинутый автор указанной статьи. А так же, судя по приведенной цитате, и уважаемый George Nordic. Мечта достойная. Остается только один маленький вопрос: как этого достичь? =)

[Lemming]

Цитата:

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

А во-вторых, повеселило:
...
Вообщем, в идеале, программисты должны делать вообще все сами,

Вы упустили следующий абзац, а без него теряется смысл процитированного Вами.

Цитата:

То есть, они должны понимать, кто будет пользоваться их продуктом, и понимать, какую его потребность удовлетворяет их продукт. Не "находится в контакте с заказчиком" (это суть переваливание с больной головы на здоровую), а именно понимать - это самое главное.

Если программист не понимает цель модификации, если он банально следует ТЗ, в котором, к слову, вполне могут быть архитектурные ошибки, если он не знает как протестировать свою модификацию с точки зрения пользователя, то велика вероятность выпустить "мертворожденный" проект. Постановщик задачи(т.н. консультант) должен максимально доводить до программиста суть и цели предстоящей модификации, так как от этого зависят и сроки, и качество и успешность того или иного решения.

Почему-то вспомнился случай, когда я спросил молодого консультанта: в чем смысл пункта N в этом ТЗ? Ответ: так надо. Справедливости ради, ТЗ писал не он, ему предстояло тестировать результат моей работы, но сам его ответ говорил о том, что он так же как и я не понимает смысл указанного пункта. Со всеми вытекающими...

[coolibin]

Цитата:

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

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

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

[Zabr]

Цитата:

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

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

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

[Lemming]

Цитата:

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

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

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

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

[coolibin]

Цитата:

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

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

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

[tolstjak]

Цитата:

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

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

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

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

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

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

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



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

[Lemming]

Цитата:

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

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

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

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

[egorych]

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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

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