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

[maximka]

Являясь руководителем отдела сопровождения аксапты на клиенте, сталкиваюсь с проблемой выработки оптимального метода нормирования работ в системе.
Мне необходимо адекватно поощрять труд моих подчиненных с одной единственной целью: чтобы производительность труда и качество продукта были на высоком уровне. Причем оценивать нужно как программистов, так и консультантов, тех, кто отвечает на звонки, пишет ТЗ, анализирует проблемы...
Читал литературу, искал в инете, но пока окончательной картины для себя не вижу. Мне известны следующие способы:

1. Стоимостной способ. Награда программиста прямо пропорциональна выручке с продаж изготовленного программного продукта.
2. Сравнительный. За эталон берем, к примеру, количество произведенного кода за прошлый месяц и сравниваем с текущим, если количество кода возросло, значит производительность увеличилась
3. Оценочный. Когда эксперт(ы) оценивает сложность задачи на основе своего опыта/знаний.
4. Количественный способ. Утрировано, оцениваем количество строк кода в месяц. Китайские и индусские программисты, я так понимаю, его в основном и используют.
5. Можно еще количественный превратить в количественно-качественный, задав стоимость в у.е. для типичных операций, например, создание простой таблицы, сложной формы и т.п.

Стоймостной не подходит, так как мы не продаем свою продукцию в чистом виде. Сравнительный грешит тем, что оценивается только количество кода, а не качество. Оценочный уязвим, когда дело доходит до работы, которую в команде еще никто не выполнял. Количественный вообще, на мой взгляд, устарел лет 20 назад. Единственное, что сейчас кажется более-менее приемлемым, это 5-й способ. Но опять же 100 рублей за 3 if'а и 2 select'а при высокой скорости работы метода, сложно сравнить с 200 рублями за 6 if'ов и 4 select'а, которые работают, но с тормозами.
В общем, вопрос для меня не решенный. Может, опыт есть у кого в этом направлении, свои наработки?

[miklenew]

Берёте месяц для оценки (ни кому не говорите).
Смотрите у каждого какие задачи, сами лезете в код и смотрите каждую задачу как что реализовывалось. Так вы поймёте и сложность самой задачи и качество реализации. Не поверхностно (даже если вы супер пупер), а лезем и смотрим.
Не забудьте приплюсовать информацию о результатах тестирования от консультантов.
Через какое-то время процедуру повторяем.
У консультантов не знаю.

[ice]

ИМХО смотреть по коду полный бред. можно назначать заранее премию за выполнение проекта в срок, тогда будет стимул, и штрафовать(лишать части премии) за баги.

[miklenew]

Цитата:

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

ИМХО смотреть по коду полный бред. можно назначать заранее премию за выполнение проекта в срок, тогда будет стимул, и штрафовать(лишать части премии) за баги.

Над проектом работают все. Как определить степень участия каждого?
Или вы про Аксаптовский проект(модификацию).
Тогда встаёт ещё более сложный вопрос: Как определять сроки модификаций?

[ice]

Цитата:

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

Над проектом работают все. Как определить степень участия каждого?
Или вы про Аксаптовский проект(модификацию).
Тогда встаёт ещё более сложный вопрос: Как определять сроки модификаций?

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

[miklenew]

Цитата:

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

то ведущий разработчик(консультант) в состоянии оценить сложность модификации(анализа) и время.

А ещё класно будет если будут идеальные ТЗ.
Всё сразу понятно где и чё.
Я уже наслушался сказок про то, что ведущие могут определить срок.
Исключения сплошь и рядом.
Мелкие да могут. Крупные нет.
Причём времени убьют меньше если увидят уже реализованную задачу.
Просмотр кода занимает минуты.
Поиск сделал по номеру модификации. И вот те весь расклад, какие классы использовались.
Вобщем я не верю, что на то что ведущие могут спрогнозировать может что-то дельное получиться в отношении нормирования.
Прогнозируй пожалуйста, после того как задача закончена.
И смотри разницу своего анализа времени и реального.
PS: А если у автора не хватит на это знаний и умений нефиг вообще в эту тему лезть.

[ice]

ИМХО проссмотр кода обязателен для проверки качества, а не для оценки сложности.

[miklenew]

Цитата:

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

ИМХО проссмотр кода обязателен для проверки качества, а не для оценки сложности.

А не надо вникать. Абстрагируйся.
Смотри чё за объект, класс, таблица, метод.
Циклы, ифы нафиг в них вникать.
Если метод показался подозрительным, ну можно конечно и вникнуть.
А так общие снимки просмотрел. И нормалёк.
Естественно если ты думал задача займёт одну строчку коду (к примеру), а она занимает 10. Надо разобраться либы ты не правильно понял и оценил задачу.
Либо косячок.

[Raven Melancholic]

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

Цитата:

Стоимостной способ. Награда программиста прямо пропорциональна выручке с продаж изготовленного программного продукта.

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

Цитата:

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

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

Цитата:

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

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

Цитата:

Оценочный. Когда эксперт(ы) оценивает сложность задачи на основе своего опыта/знаний.

На клиенте бывают специалисты, которые могут это оценить? Конечно можно привлекать сторонниих экспертов, но как часто это бывает на клиенте?

Цитата:

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

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

[Vals]

Скажите, у вас есть система оценки работы системы в целом?

Цитата:

Как определить что мы сделали для увеличения выручки?

Для затратных подразделений определяется "что вы сделали чтобы её не уменьшить"

Цитата:

Если есть экономия по сравнению с внешними исполнителями - есть повод премировать, если внешние исполнители более эффективны - то получай только оклад.

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

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

[slava09]

Я бы предложил такой вариант:

1. Аналитиком формируется ТЗ и ставится в очередь заданий, для задания аналитик выставляет желательный срок выполнения (можно еще приоритет).
2. Руководитель программистов выставляет уровень сложности задания и назначает исполнителя в соответствии с загрузкой и желаемым сроком исполнения
3. Исполнитель (программист) оценивает срок исполнения задания и согласовывает его с руководителем програмистов. В задании фиксируется оценочный срок исполнения.
4. После исполнения задание передается на тестирование и выставляется дата передачи в тестирование
5. Аналитик тестирует задачу и если не принимает то возвращает на исполнение.

Таким образом мы имеем следующие параметры каждого задания:
1. Уровень сложности
2. Оценочное время выполнения, подтвержденное экспертной оценкой руководителя
3. Фактическое время выполнения, зафиксированое системой учета заявок

По каждому исполнителю мы получаем отчет, который показывает абсолютные и относительные (от общего времени) отклонения фактического времени от оценочного, а также некий показатель "Скорректированный уровень отклонения (СУО)", на который влияет сложность задачи. Сложность задачи влияет таким образом: для каждого уровня сложности устанавливается приемлемый уровень отклонения, который "гасит" это разницу в показатале СУО. Например для несложных задача это один день, для средних 3 дня, для сложных 7 дней. Причем этот уровень может устанавливаться индивидуально для каждого программиста в зависимости от его квалификации, стажа работы, личных отношений с руководителем
Статистика по показателю СУО и покажет вам как кто работает.

К сожалению, в моей схеме не учитывается качество кода.

[Raven Melancholic]

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

[Андре]

Цитата:

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

ИМХО смотреть по коду полный бред. можно назначать заранее премию за выполнение проекта в срок, тогда будет стимул, и штрафовать(лишать части премии) за баги.

Ссылку не нашел, но имел место быть следующей эксперимент. Двум группам людей дали одинаковые математические задачи. Одной из групп пообещали достаточно большую премию, за самое быстрое решение задач. Люди из этой группы затратили больше времени на решение задач, чем люди из немотивированной группы.

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

Источник: www.ted.com

p.s. Даже не обращаясь к авторитетным источникам неужели вы сами не чувствуете это на своей шкуре?

[Андре]

Цитата:

Тогда встаёт ещё более сложный вопрос: Как определять сроки модификаций?

Спрашиваем у разработчика, который будет выполнять ее. Потом умножаем на коэффициент, больший единицы и зависящий от разработчика. Коэффициенты для разработчиков подберете в первые несколько месяцев совместной работы

Цитата:

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

Не представляю, как можно это осуществить при количестве разработчиков > 5. Разве только самому ничего не делать.

Цитата:

поощрять труд моих подчиненных с одной единственной целью: чтобы производительность труда и качество продукта были на высоком уровне

Причем акцент я бы смещал на качество, а не на производительность. Этак в отношении 1/10. Хорошее качество доработок сегодня залог высокой производительности в будущем, так как снижает затраты на поддержку и развитие функционала.

IMHO, оценка должна быть сугубо личностной, но не обязательно завязанной на одного человека.

Цитата:

Стоимостной способ. Награда программиста прямо пропорциональна выручке с продаж изготовленного программного продукта.

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

Я молчу про то, что выделить прибыль привнесенную одним разработчиком достаточно тяжело, если вы конечно не разрабатываете заказные модули.

Цитата:

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

... и что это значит ? Это значит только одно - теперь у вас стало больше кода, который вам надо поддерживать. Все - больше это ничего не значит.

Цитата:

Оценочный. Когда эксперт(ы) оценивает сложность задачи на основе своего опыта/знаний.

Угу. В качестве экспертов могут выступать пара руководителей отделов (разработки и консалтинга) + менеджер проекта.

Цитата:

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

Первое, что в первую очередь вам напишут - это кодогенератор

Цитата:

Но опять же 100 рублей за 3 if'а и 2 select'а при высокой скорости работы метода, сложно сравнить с 200 рублями за 6 if'ов и 4 select'а, которые работают, но с тормозами.

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

Цитата:

К сожалению, в моей схеме не учитывается качество кода

То есть, самое главное

[miklenew]

Цитата:

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

Не представляю, как можно это осуществить при количестве разработчиков > 5. Разве только самому ничего не делать.

5-10 минут достаточно, чтоб посмотреть и понять, что сделал разработчик за день.
Если ты конечно разработчик хороший.
Ну сколько он за день сделает 5 таблиц 5 форм 5 классов (максимум). Ну и сопутствующая мелочёвка, которую и смотреть не обязательно.
Неужели это сложно просмотреть.
Когда создаёт с нуля пишет больше.
Если модифицирует старый функционал меньше. Значит и смотреть меньше.
Вот и получается 5*10(макс)=50 минут каждый день.
А что вы хотели? Изобрести волшебную кнопку, получить за неё премию и пусть она всё делает. Автор гений. Разработчики счастливы. Клиент доволен.
Ага. Щаз.
Смотреть конечно надо не каждый день, а по завершению задачи.

[Андре]

Цитата:

Ну сколько он за день сделает 5 таблиц 5 форм 5 классов (максимум). Ну и сопутствующая мелочёвка, которую и смотреть не обязательно.
Неужели это сложно просмотреть.

Вопрос не в том, что это сложно, а в том, что я не вижу в этом смысла. Лично я предпочитаю смотреть только архитектуру, а точнее обсуждать ее до модификации, а не после того, как она свершилась.

Если мы говорим про code review - то тут здорово помогает автоматическая проверка Best Practices, соблюдения которой последнее время MBS требует от своих партнеров.

Но упаси меня бог оценивать результативность (я предпочитаю это слово) разработчика основываясь на просмотре форм и таблиц - если только на испытательном сроке.

Цитата:

Вот и получается 5*10(макс)=50 минут каждый день.

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

Цитата:

А что вы хотели? Изобрести волшебную кнопку, получить за неё премию и пусть она всё делает

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

[ice]

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

[belugin]

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

[maximka]

Да-да!
Продолжение: http://www.effman.ru/2008-05-19/104

[Zabr]

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

Обработка заявок тех.поддержкой
1 Среднее время реагирования на заявку
2 Среднее время закрытия заявки
3 Динамика закрытия заявок (например, закрытие 90% заявок за Х часов, Закрытие 100% заявок за N часов)
4 Среднее ежедневное число заявок, не более
5 Удовлетворенность тех.поддержкой (определяется периодическими опросами пользователей, несколько типовых вопросов, оценки например по 5-ти бальной системе)

Выполнение программных модификаций
1 Исправление ошибок (не более Х часов на каждую)
2 Новый отчет (не более Х часов на каждый)
3 Прочий функционал (не более Х часов на каждый - да, посчитать конечно очень сложно, но берём в среднем за длительный период, а задачи стараемся разбивать на такие модификации, по которым результат можно было бы получить оценить отдельно до окончания задачи в целом).

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