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

[belugin]

Цитата:

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

Обработка заявок тех.поддержкой

Есть еще такое понятие - SLA

[maximka]

Цитата:

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

Работаю на клиенте рук.проекта, проекта в стадии сопровождения и развития.
Стоит та же задача оценки, предварительно написал такую табличку: показатель и его целевое значение, т.е. к которому нужно стремиться по итогам отчетного периода (скажем, квартал, полугодие, год)...

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

[Zabr]

Цитата:

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

Согласен, такую статистику вести полезно, но оценивать по ней труд сотрудников считаю не эффективным, потому что это "количество".

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

Цитата:

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

Поэтому есть соблазн преступление, которое заведомо нераскрываемое, просто не регистрировать.

У нас заявки для решения проблем регистрируют пользователи. Техподдержка не может что-то регистрировать а что-то нет, потому что она не регистрирует ничего.

Расскажите пожалуйста о своих сомнениях по подгонке результатов по другим пунктам.

Цитата:

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

и поддерживать такой климат в коллективе, чтобы глаза у людей горели...

Это самое сложное, и огромное количество руководителей не знает как это сделать. При этом 99,9% руководителей знают, что так должно быть, так что вы просто присоединились к большинству. Расскажите, как конкретно вы собиратесь двигаться в это направлении, будет очень интересно не только мне. [Сейчас вы написали примерно следующее: "Ура, я придумал как стать богатым ! Всё очень просто: нужно заработать много денег." - расскажите как.]

[mazzy]

Цитата:

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

http://local.joelonsoftware.com/wiki...86%D0%B8%D0%B8

Вот-вот!

Цитата:

...
Разработчики очень сообразительны в этом отношении. Что бы вы ни пытались измерить, они найдут способ оптимизировать этот показатель, и вы никогда не получите именно то, чего пытаетесь добиться.

Роберт Остин (Robert Austin) в своей книге "Измерение и управление производительностью в организациях" (Measuring and Managing Performance in Organizations) пишет, что существует два этапа внедрения новой метрики для измерения производительности. Сначала вы получаете то, что хотели, потому что никто пока не понял, как обмануть систему. На втором этапе вы получаете нечто худшее, чем то, с чего начинали, потому что все будут обманывать систему, чтобы максимизировать измеряемый показатель, даже рискуя погубить компанию.

Хуже того, менеджеры, использующие экономическую мотивацию, думают, что они смогут избежать такой ситуации, просто улучшая метрики. Доктор Остин заключает, что вы не можете этого сделать. Это никогда не срабатывает. Не важно, как сильно вы стараетесь адаптировать метрики к тому, что вы хотите достигнуть, это всегда срабатывает против вас.

Самая большая проблема с управлением методом экономической мотивации, однако, в том, что это вообще не управление: это больше похоже на отречение от управления. Добровольный отказ от попытки понять, как можно сделать ситуацию лучше. Это признак того, что руководство просто не знает, как научить людей лучше работать, так что оно вынуждено заставлять сотрудников самих придумывать, как улучшить ситуацию.

...

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

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

После того, как я уничтожил командный метод управления и метод экономической мотивации, остался еще один метод, который менеджеры могут использовать, чтобы заставить людей двигаться в правильном направлении. Я называю его "методом отождествления" и завтра собираюсь рассказать о нем подробнее.

[dmitryul]

maximka, консультанты и программисты - это не менеджеры по продажам.

Подсчитывать качество и объем выполненных работ каждым специалистом и потом выдавать на основе этого бонусы - верный способ потерять команду. Будут разборки внутри коллектива. Оно Вам надо?

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

Результат есть, по срокам в пределах ожидаемого, отзывы от юзеров положительные - бонус. Нет результата - нет бонуса. По сумме - вполне пойдет премия раз в квартал в размере 30-40% от зарплаты, пустячок - а приятно! Раз в месяц не надо размазывать - подсознательно сотрудники будут считать бонусы постоянной прибавкой к зарплате, т.е. результат будет нулевым.

А совместные мероприятия никак не отражаются на результатах работы - проверено.

[RVS]

Позабавило следующее:

Цитата:

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

У нас заявки для решения проблем регистрируют пользователи. Техподдержка не может что-то регистрировать а что-то нет, потому что она не регистрирует ничего.

В одной из классических схем организации труда в разработке-поддержке софта - поддержка - как раз! - занимается регистрацией клиентских проблем, при этом:

- отражает то, то не надо регистрировать (чисто задачи HelpDesk, RTFM и прочее)
- регистрирует то, что регистрировать нужно. При этом - высасывает из пользователя максимально детализированное описание проблемы, иногда - тратит собственные усилия на то, чтобы проблему можно было воспроизвести. Иначе получаем: "Программа виснет и оставляет на столе дурно пахнущий объект, похожий на мешок навоза" - отсюда: http://russian.joelonsoftware.com/Ar...gTracking.html

Цитата:

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

Да сколько угодно. Будут закрывать задачи, не решая. Будут звонить пользователям: уговаривать их не регистрировать заявки.

Уй, ёёё...

Ваши сотрудники - настолько идиоты??? Все это ловится на раз

Смените образ мышления. Или сотрудников. Поголовно

[maximka]

Цитата:

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

Ваши сотрудники - настолько идиоты??? Все это ловится на раз
Смените образ мышления. Или сотрудников. Поголовно

Да не в сотрудниках тут дело, а в системе. Человек автоматически ищет лазейки в системе, которая его излишне контролирует. Попробуйте тесто с силой сжать в руке - откуда-нибудь да повылазит. (за пример не бить) Нормальных примеров куча: за преступление человека в тюрьму посадили. В большинстве случаев он исправится? Нет. А если срок увеличить? Нет.
Надо с людьми работать получается...

[gudzon]

Цитата:

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

Нормальных примеров куча: за преступление человека в тюрьму посадили.

Сравнение тюрьмы с IT-командой это "нормальный пример"?!

[maximka]

Цитата:

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

Сравнение тюрьмы с IT-командой это "нормальный пример"?!

Дык не турму, а процесс. Ну а так-то везде люди

[RVS]

Цитата:

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

Человек автоматически ищет лазейки в системе, которая его излишне контролирует.

По себе судите?

Цитата:

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

Человек автоматически ищет лазейки в системе, которая его излишне контролирует.

А "излишне"-то - зачем?

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

У вас - не так? Тогда - мои сочувствия

[maximka]

Цитата:

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

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

Значит вам повезло, что попался такой коллектив, очень повезло. Значит глаза горят, атмосфера в коллективе хорошая, каждый делает, что ему нравится... Далеко не везде так.

Цитата:

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

У вас - не так? Тогда - мои сочувствия

У нас не так, но смотрю на вопрос шире.

[maximka]

Цитата:

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

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

Да, можно подумать. Интересная мысль.

Цитата:

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

А совместные мероприятия никак не отражаются на результатах работы - проверено.

Напрямую - возможно. Но считаю, что коллектив должен работать в одной струе т.с. Понимание нужно друг друга и смысла вообще работы. Мероприятия совместные (как обычные, так и узконаправленные типа семинаров, коллоквиумов) должны сплачивать народ, тогда и работать будет легче и ясно будет место сотрудника в коллективе/фирме. Отсюда и производительность... мне кажется так.

[George Nordic]

Цитата:

Единство людей -- ствол, выбрасывающий разные ветви, -- вот цельность, к которой я стремлюсь и которая и есть суть моего царства, она видна, когда отдалишься. А вблизи видишь суету матросов, каждый из них тянет в свою сторону свой канат. Издалека виден фрегат, плывущий по морю.
Скажу больше: если я воодушевлю мой народ любовью к морским странствиям, если их отягощенные любовью сердца подтолкнут их всех к единому руслу, ты увидишь, как по-разному каждый из них будет действовать в зависимости от склада своей натуры. Один будет ткать паруса, другой блестящим топором валить сосны. Один ковать гвозди, другой наблюдать за звездами, чтобы научиться управлять кораблем. И все-таки они будут единым целым. Корабль строится не потому, что ты научил их шить паруса, ковать
гвозди, читать по звездам; корабль строится тогда, когда ты пробудил в них страсть к морю и все противоречия тонут в свете общей для всех любви.
Поэтому все на свете союзники мне и я открываю объятья моим врагам, чтобы они укрепляли меня и возвышали. Я знаю: есть ступень, с которой наша схватка покажется мне любовным бореньем.
Я создаю корабль совсем не тем, что продумываю его во всех деталях. Если я примусь в одиночку чертить чертежи, я упущу главное. Когда дело дойдет до строительства, чертежи мои не понадобятся, их сделают другие. Не мне знать каждый гвоздь корабля. Мой долг разбудить в людях стремление к морю.

Антуан де Сент-Экзюпери. Цитадель

С Уважением,
Георгий

[Андре]

Цитата:

Вот только не надо военный опыт накладывать на гражданскую жизнь, я вас умоляю!

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

[coolibin]

Цитата:

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

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

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

Цитата:

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

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

[Lemming]

Цитата:

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

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

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

Цитата:

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

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

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

[coolibin]

Цитата:

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

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

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

[Zabr]

Цитата:

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

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

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

[sukhanchik]

Работая еще давно давно программистом, работающим над своей самопиской - услышал похожую идею от директора - "Если нет проблем, то и программист не нужен".
Поэтому я бы посчитал, что во второй пункт вкралась досадная "опечатка" - следует читать так:

Цитата:

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

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

Количество баллов прямо пропорционально зарплате консультанта (т.е. плюс - это хорошо), однако коэффициент убывает от месяца к месяцу.
Т.е. в первый месяц после запуска - если все работает - консультант - супермолодец. (считаем + 5 баллов в день)
Если и во второй месяц ничего не выявилось - то - просто молодец (допустим + 2 балла в день)
В третий месяц - 1 балл. В четвертый - уже можно не платить, т.к. если система долго не требует участия консультанта - то он наверное и не нужен.

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

Но это все теория. На практике - математически точно всегда высчитывать баллы - мне кажется не получится. К этому надо стремиться конечно, но идеального варианта наверное не получится.

PS. Пока писал - уже ответили

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

Цитата:

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

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

Нет, количество балов не убывает. Кстати, если есть удаленный доступ, то, удаленное исправление чего либо можно приравнивать к присутствию.

Попробую разъяснить:

+1 Если для того чтобы все работало консультант чтото колдует (в этом случае риски больше)
+5 Если все работает само - это значит что все хорошо отлажено, пользователи обучены, процесс не требует ручной доводки. Платиться без уменьшения - нельзя обижать консультанта, завтра тебе потребуется другой модуль и а спец уйдет к кому то. Т.е. деньги платятся за то что модуль работает.
-20 Не работает. Тут все ясно - может быть и -50 все зависит от конкретной компании

Цитата:

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

То есть, консультант пришел на работу = плюс один к зарплате, а прогулял = плюс пять? Пробовали предлагать такую схему своему руководству?

Данная схема использовалась, но не совсем как я описал. Эти балы использовались для оценки, нужен нам такой консультант или не нужен...

Цитата:

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

PS Ваша логика меня давно уже 'восхищает'. Может и хорошо что Компьютерра закрылась.

Спасибо, уверенно воспринимаю это как комплимент.! Я, кстати, скоро книгу издам про ERP.