Здравствуйте, hlt, Вы писали:
hlt>Так случилось, что в штатном расписании конторы (не IT) существуют позиции программистов, формально различающиеся категорией, а фактически только зарплатой. Назначение этих категорий людям, делается на основе субъективных выводов о продуктивности и полезности специалиста. До недавнего времени — всех это устраивало. Но теперь, в связи с увлечением ISO9000, требуется сформулировать чёткие, объективные, критерии категорий программистов. Причём, на основе этих критериев, программист должен чётко представлять, что он должен сделать, чтобы получить повышение...
hlt>Совершенно не представляю себе на 100% объективных критериев. Подскажите, куда копать?
100% объективность в данном вопросе вряд ли достижима, но каким-то образом необходимо и оценивать, и дать возможность работнику понимание, каким образом происходит такая оценка.
Я делаю следующим образом (сразу предупреждаю, что сам только-только начал это дело, и система ещё не обкатана).
Вся зарплата делится на основную часть (оклад + персональная надбавка) и различные премии (по итогам работы за год, проект).
При найме с работником согласовывается основная часть, исходя из рыночной стоимости работы (сколько хочет претендент, сколько можем (хотим) дать мы). Далее основная часть раскладывается по составляющим.
ОКЛАД
1. Квалификация (образование и опыт)
Составляем таблицу: опыт по горизонтали (например, в годах и/или в количестве проектов и/или знание каких-либо технологий), образование по вертикали (среднее, неполное высшее, высшее и т. д.). В соответствующих клеточках проставляем баллы (это называется "метод факторных точек")
2. Физические усилия
Например, лёгкая работа (а у программистов работа лёгкая — 0 баллов, владение 10-типальцевым методом набора кода — 10 баллов (по баллу за каждый палец ) и т. д.
3. Инициатива
Создаём таблицу со строками от "следует установленным инструкциям" до "создаёт политику, определяет процедуры и методы работы" с соответсвующими баллами.
4. Самостоятельность
Таблица со строками от "Решения основаны на полностью известных фактах" до "Стратегические решения" с соответсвующими баллами.
5. Коммуникабельность
Таблица со строками от "Контакты ограничены внутри одного подразделения" до "Внешние и внутренние контакты, требующие трудных переговоров, видения стратегии" с соответсвующими баллами.
6. Исполнительность (производительность и качество)
Думаю, понятно, что невозможно оценивать производительность программиста в отрыве от качества его работы.
Составляется таблица: производительность по горизонтали, качество по вертикали. И соответствющие баллы. Проблема: в чём измерять производительность программиста, если написание самого кода занимает в объёме его работы до 3% (недавно видел таблицу) и качество (количество ошибок и дефектов на количество строк кода). Я пока использую именно эти оценки. Если кто-то знает приемлемую формулу (критерии), сообщите, пожалуйста.
ПЕРСОНАЛЬНАЯ НАДБАВКА
1. Сложность работы
Таблица со строками от "Монотонная работа" до "Сложная работа (постоянно несколько групп функций, непредсказуемость их возникновения, операции не всегда четко очерчены)" с соответсвующими баллами. Здесь же начисляются дополнительные баллы только за способность сотрудника заменять другого (по должности, по профессии). Это хоть какая-то защита от ухода сотрудников. Да и просто отпустить человека в отпуск без головной боли, что всё-таки актуально для небольшой компании.
Ну и, конечно, определяем стоимость балла.
ПРЕМИЯ
Годовое собрание акционеров (у нас ЗАО) определяет процент от прибыли на премирование сотрудников. Далее по известной всем сотрудникам формуле деньги и распределяются. Где-то прочитал, что лучшей системой премирования является следующая: "Сколько хочу, столько и даю". При условии наличия в фирме высококачественного топ-менеджмента.
Напоследок хочу заметить, что один из классиков теории менеджмента качества, Уильям Эдвард Деминг, заявлял, что система аттестации и ранжирования персонала, оценка личного вклада, ранжирование по значимости, премиальные системы, плата по труду оказывют разрушительный эффект.
Здравствуйте, Miroff, Вы писали:
M>Как этот коэффициент соотносится с эмпирическим "правилом PI раз" (Реальные сроки обычно больше рассчетных в PI раз)? Не получается ли так, что этот коэффициент всегда составляет 30%? Хотелось бы услышать, какие значения обоих коэффициентов у вас считают нормальными?
Упомянутое "правило пи раз" должно быть учтено (и реально учитывается) менеджером.
Что же касается реального коэффициента исполнения плана — то на небольших задачах (от 2 до 5 дней, это обычно достаточный уровень детализации для отслеживания реального состояния дел в проекте) он составляет, грубо, от 0.8 до 1.2 — то есть, возможны как небольшая недооценка, так и переоценка сложности задачи. На больших суммарных задачах (месяц-два-три) — обычно близок к 1.
Подчеркну, что плановый срок первоначально планируется менеджером, но обязательно согласуется с исполнителем. Большие отклонения коэффициента исполнения плана — как в меньшую, так и в большую сторону, — обычно свидетельствуют о неадекватности как менеджера, так и исполнителей. Эта проблема уже должна решаться административными методами.
Нет ничего страшного в том, что у исполнителя этот коэффициент "плавает" около единицы, отклоняясь то в плюс, то в минус. Все равно на реальных продолжительных этапах проекта эти опережения и отставания компенсируются. Вот если коэффициент постоянно в течение длительного периода времени завышен или занижен — это уже повод задуматься.....
Здравствуйте, ry, Вы писали:
ry>Я уже просил, предложите объективный, эффективный, простой для понимания (но можно и сложный) и измеряемый критерий. Я с удовольствием буду его использовать.
Когда-то давным-давно здесь, на RSDN, я вычитал простой и эффективный метод управления:
D> может кто-то поделиться индикаторами производительности разработчика, D> которые используются в Вашей команде/конторе? Как рассчитывается производительность людей? D> используются ли эти показатели для подсчета успешности команда/проекта/конторы?
Мы используем собственно придуманные коэффициенты (скорее всего, кто-то это придумывал до нас):
— коэффициент исполнения плановых сроков. Считается от планового срока по задаче (согласовывается вместе с исполнителем) и его фактической протяженностью в часах
— коэффициент поддержки закрытой задачи — отношение времени, потраченного на задачу ко времени, потраченному на ее саппорт в дальнейшем. Фактически, отображает качество решения задач программистом.
Идеи, вероятно, не новы и можно придумать что-то еще, но это "автомат Калашникова": простой и надежный способ, чтобы на цифрах без субъективщины показать, кто как работает.
Автор этого метода, надеюсь, меня извинит за то, что имя его я не сохранил....
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, hlt, Вы писали:
hlt>>Совершенно не представляю себе на 100% объективных критериев. Подскажите, куда копать?
M>Сто процентов объективный критерий один -- прибыль которую программист приносит компании. Критерий четкий (чтобы получать больше, нужно приносить больше прибыли), однозначный и совершенно объективный (измеряется в однозначных и объективных рублях). У него есть только два недостатка: трудно посчитать в большинстве случаев и опасность того, что работники узнав сколько им реально достается просто разбегутся.
Совершенно глупый критерий, если только не заставлять программиста самому бегать по клиентам и продавать продукт.
Если это не "внедреж" какого-нибудь SAPа, а реальная разработка,
то программист приносит исключительно убытки
Прибыль приносят другие.
Так случилось, что в штатном расписании конторы (не IT) существуют позиции программистов, формально различающиеся категорией, а фактически только зарплатой. Назначение этих категорий людям, делается на основе субъективных выводов о продуктивности и полезности специалиста. До недавнего времени — всех это устраивало. Но теперь, в связи с увлечением ISO9000, требуется сформулировать чёткие, объективные, критерии категорий программистов. Причём, на основе этих критериев, программист должен чётко представлять, что он должен сделать, чтобы получить повышение...
Совершенно не представляю себе на 100% объективных критериев. Подскажите, куда копать?
Здравствуйте, hlt, Вы писали:
hlt>Совершенно не представляю себе на 100% объективных критериев. Подскажите, куда копать?
Сто процентов объективный критерий один -- прибыль которую программист приносит компании. Критерий четкий (чтобы получать больше, нужно приносить больше прибыли), однозначный и совершенно объективный (измеряется в однозначных и объективных рублях). У него есть только два недостатка: трудно посчитать в большинстве случаев и опасность того, что работники узнав сколько им реально достается просто разбегутся.
Здравствуйте, hlt, Вы писали:
hlt>Так случилось, что в штатном расписании конторы (не IT) существуют позиции программистов, формально различающиеся категорией, а фактически только зарплатой. Назначение этих категорий людям, делается на основе субъективных выводов о продуктивности и полезности специалиста. До недавнего времени — всех это устраивало. Но теперь, в связи с увлечением ISO9000, требуется сформулировать чёткие, объективные, критерии категорий программистов. Причём, на основе этих критериев, программист должен чётко представлять, что он должен сделать, чтобы получить повышение...
я плакал и смеялся. категории инженеров — это пережиток советской системы. подозреваю, что они назначались на основе выслуги лет, но лучше об этом спросить у кондовых совестких кадровиков. сейчас эта система де-факто заменилась на западную юниор/средний/сеньёр. для последней, вероятно, можно привести какие-то критерии исходя из формулировок объявлений о работе
Здравствуйте, ry, Вы писали:
ry>Здравствуйте, hlt, Вы писали:
hlt>>Так случилось, что в штатном расписании конторы (не IT) существуют позиции программистов...
ry>Напоследок хочу заметить, что один из классиков теории менеджмента качества, Уильям Эдвард Деминг, заявлял, что система аттестации и ранжирования персонала, оценка личного вклада, ранжирование по значимости, премиальные системы, плата по труду оказывют разрушительный эффект.
Если не трудно, уточните, пожалуйста, направление воздействия "разрушительного эффекта".
P.S. Спасибо за весьма содержательный ответ топикстартеру.
Здравствуйте, Challenge, Вы писали:
C>Здравствуйте, ry, Вы писали:
ry>>Здравствуйте, hlt, Вы писали:
hlt>>>Так случилось, что в штатном расписании конторы (не IT) существуют позиции программистов...
ry>>Напоследок хочу заметить, что один из классиков теории менеджмента качества, Уильям Эдвард Деминг, заявлял, что система аттестации и ранжирования персонала, оценка личного вклада, ранжирование по значимости, премиальные системы, плата по труду оказывют разрушительный эффект.
C>Если не трудно, уточните, пожалуйста, направление воздействия "разрушительного эффекта".
К сожалению, я могу только предполагать и, видимо, то же самое, что и Вы, так как до сих пор не прочитал первоисточник, только калькуляции с него:
1. Обиды и, следовательно, интриги в коллективе -> разложение Коллектива (с большой буквы).
2. Затраты на поддержание системы.
3. Борьба за показатели, а не работа на результат.
PS: Если бы я был полностью согласен с Демингом, то мне надо было бы увольняться. Но проблемы, согласитесь, всё-таки существуют.
Здравствуйте, ry, Вы писали:
ry>Здравствуйте, Challenge, Вы писали:
C>>Если не трудно, уточните, пожалуйста, направление воздействия "разрушительного эффекта".
ry>К сожалению, я могу только предполагать и, видимо, то же самое, что и Вы, так как до сих пор не прочитал первоисточник, только калькуляции с него: ry>1. Обиды и, следовательно, интриги в коллективе -> разложение Коллектива (с большой буквы). ry>2. Затраты на поддержание системы. ry>3. Борьба за показатели, а не работа на результат.
ry>PS: Если бы я был полностью согласен с Демингом, то мне надо было бы увольняться. Но проблемы, согласитесь, всё-таки существуют.
Соглашусь (с Вами, с Демингом — не совсем), куда же без них.
Здравствуйте, ry, Вы писали:
ry>100% объективность в данном вопросе вряд ли достижима
С этим согласен.
ry>Далее основная часть раскладывается по составляющим.
В каждой из которых с объективностью проблемы...
ry>1. Квалификация (образование и опыт) ry>2. Физические усилия ry>3. Инициатива ry>4. Самостоятельность ry>5. Коммуникабельность
Всё это конечно важно, но все эти баллы не равнозначны, и конечная производительность и качество могут быть важнее, чем "минусы" в этих пунктах.
ry> Проблема: в чём измерять производительность программиста
Здравствуйте, hlt, Вы писали:
hlt>В каждой из которых с объективностью проблемы...
ry>>1. Квалификация (образование и опыт) ry>>2. Физические усилия ry>>3. Инициатива ry>>4. Самостоятельность ry>>5. Коммуникабельность
Вот здесь-то и должна проявиться квалификация менеджера, его непредвзятость к людям, но куда же деться от субъективности. Но ведь всё равно нужно иметь единый измерительный инструмент и одинаково ко всем его применять.
hlt>Всё это конечно важно, но все эти баллы не равнозначны, и конечная производительность и качество могут быть важнее, чем "минусы" в этих пунктах.
А вот здесь и проявите своё видение важности, адаптируйте систему оплаты по мере развития фирмы, анализируйте реакцию системы (фирмы, людей) на ваши воздействия. Автоматическая система управления вряд ли возможна. Но... чем чёрт не шутит.
ry>> Проблема: в чём измерять производительность программиста
hlt>Вот сдесь, по моему, будет 100% субъективность!
А, по-моему, здесь-то как раз и нет особой субъективности, если измерять в количестве строк кода, просто, повторюсь, кодирование занимает в общем объёме труда современного программиста около 3%. Я сам в своё время удивлялся, почему, например, при 10-тикратной разнице в производительности двух программистов их зарплата отличается всего лишь в 2, от силы в 3, раза.
А вообще, если найдёте более приемлемые критерии оценки, дайте знать. Лучше в почту.
Здравствуйте, hlt, Вы писали:
hlt>Нельзя измерять производительность в количестве строк кода. Ибо — краткость сестра таланта.
Я уже просил, предложите объективный, эффективный, простой для понимания (но можно и сложный) и измеряемый критерий. Я с удовольствием буду его использовать.
Здравствуйте, bkat, Вы писали:
B>Совершенно глупый критерий, если только не заставлять программиста самому бегать по клиентам и продавать продукт.
Ну так я честно предупредил, что с подсчетом возникнут некоторые трудности.
B>Если это не "внедреж" какого-нибудь SAPа, а реальная разработка, B>то программист приносит исключительно убытки
Если бы это было так, то удаление программиста из компании повышало бы прибыль в среднесрочной перспективе.
Здравствуйте, Miroff, Вы писали:
M>Если бы это было так, то удаление программиста из компании повышало бы прибыль в среднесрочной перспективе.
Если подписать с заказчиком договор, получить 100% предоплату, а через некоторое время уволить всех программистов, то прибыль резко вырастет. По крайней мере, до срока сдачи проекта.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, bkat, Вы писали:
B>>Совершенно глупый критерий, если только не заставлять программиста самому бегать по клиентам и продавать продукт. M>Ну так я честно предупредил, что с подсчетом возникнут некоторые трудности.
B>>Если это не "внедреж" какого-нибудь SAPа, а реальная разработка, B>>то программист приносит исключительно убытки
M>Если бы это было так, то удаление программиста из компании повышало бы прибыль в среднесрочной перспективе.
Зарплата программера — это необходимые затраты, которые придется понести,
прежде чем ты сможешь мечтать о прибыле.
Считай, что это типа затрат на электричество на фабрике
Говорить о прибыли нет вообще никакого смысла, пока ты эти затраты не понесешь.
Получишь ли ты прибыль — это зависит от других вещей.
Исключения связаны с косалтерским бизнесом, когда фирма Х продает время программера Y фирме Z.
Тогда прибыль — это разница между тем, что платит Z и тем, что попадет в карман Y.
Здравствуйте, S-SH, Вы писали:
SS>Если подписать с заказчиком договор, получить 100% предоплату, а через некоторое время уволить всех программистов, то прибыль резко вырастет. По крайней мере, до срока сдачи проекта.
Это краткосрочная перспектива. В среднесрочной прибыль уменьшится до нуля.
Здравствуйте, bkat, Вы писали:
B>Зарплата программера — это необходимые затраты, которые придется понести, B>прежде чем ты сможешь мечтать о прибыле. B>Считай, что это типа затрат на электричество на фабрике B>Говорить о прибыли нет вообще никакого смысла, пока ты эти затраты не понесешь. B>Получишь ли ты прибыль — это зависит от других вещей.
То есть получу я прибыль или нет не зависит от того понесу я необходимые траты или нет?
Всегда подозревал что популярная экономика -- лженаука
Прибыль вообще нельзя считать на момент времени, максимум, можно посмотреть состояние счета с учетом обязательств. Прибыль должна считаться всегда за какой-то период, календарный или срочный, неважно. Поэтому рассуждения о том, что "без программистов ничего не получится" или "программисты не приносят прибыли" никакого смысла не имеют. Если уж рассуждать, то рассужать физически: примем процесс за стационарный и будем вность в него возмущения последовательно удаляя по одному сотруднику за раз и наблюдая как меняется прибыль в долгосрочном периоде (т.е. когда шок вызванный изменениями устаканится) Если при этом прибыль падает до нуля, то сотрудник незаменимый. (Например единственный менеджер), если существенно -- ключевой (архитектор), если уменьшается несущественно -- рядовой сотрудник, а если прибыль возрастает -- то сей сотрудник процессу только мешает. Отсюда видно, что программисты, менеджеры и даже уборщицa -- все опосредованно приносят прибыль. Более того, прибыль приносят такие, какзалось бы траты как кондиционер, и современные рабочие места. Естественно, что в реальности процесс нестационарный и натурный эксперимент будет произвести затруднительно, хотя с некоторыми приближениями, возможно.
B>Исключения связаны с косалтерским бизнесом, когда фирма Х продает время программера Y фирме Z. B>Тогда прибыль — это разница между тем, что платит Z и тем, что попадет в карман Y.
Это тривиальный случай.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, bkat, Вы писали:
B>>Зарплата программера — это необходимые затраты, которые придется понести, B>>прежде чем ты сможешь мечтать о прибыле. B>>Считай, что это типа затрат на электричество на фабрике B>>Говорить о прибыли нет вообще никакого смысла, пока ты эти затраты не понесешь. B>>Получишь ли ты прибыль — это зависит от других вещей.
M>То есть получу я прибыль или нет не зависит от того понесу я необходимые траты или нет? M>Всегда подозревал что популярная экономика -- лженаука
Затраты на программера — это необходимые, но недостаточные, для получения прибыли.
M>Прибыль вообще нельзя считать на момент времени, максимум, можно посмотреть состояние счета с учетом обязательств. Прибыль должна считаться всегда за какой-то период, календарный или срочный, неважно. Поэтому рассуждения о том, что "без программистов ничего не получится" или "программисты не приносят прибыли" никакого смысла не имеют. Если уж рассуждать, то рассужать физически: примем процесс за стационарный и будем вность в него возмущения последовательно удаляя по одному сотруднику за раз и наблюдая как меняется прибыль в долгосрочном периоде (т.е. когда шок вызванный изменениями устаканится) Если при этом прибыль падает до нуля, то сотрудник незаменимый. (Например единственный менеджер), если существенно -- ключевой (архитектор), если уменьшается несущественно -- рядовой сотрудник, а если прибыль возрастает -- то сей сотрудник процессу только мешает. Отсюда видно, что программисты, менеджеры и даже уборщицa -- все опосредованно приносят прибыль. Более того, прибыль приносят такие, какзалось бы траты как кондиционер, и современные рабочие места. Естественно, что в реальности процесс нестационарный и натурный эксперимент будет произвести затруднительно, хотя с некоторыми приближениями, возможно.
Ну если у вас уже есть проверенная модель оценки прибыли по такой схеме и
вы сможете конкретно про меня сказать, сколько я принесу прибыли именно у вас,
то я пожалуй соглашусь
Но что-то я сомневаюсь в том, что у вас (да и вообще где-либо) в таком духе могут подсчитать прибыть от уборщицы.
А иначе остаются именно тривиальные случаи с консалтерами...
Здравствуйте, S-SH, Вы писали:
SS>Не обессудьте — никогда не понимал, где именно проходят границы между всеми этими перспективами.
Краткосрочная -- в пределах одного цикла производства. Применительно к программистам это в пределах одного заказа или одного релиза.
Среднесрочная -- в пределах конечного числа циклов производства. Обычно берется от нескольких кварталов, до нескольких лет
Долгосрочная -- в пределах достаточно большого числа циклов производства.
Фича в том, что в краткосрочный период сравним по времени с интервалами платежей, т.е. они находятся в пределах погрешности, значит говорить о прибыли нельзя. Простой пример, раз в месяц тебе платят зарплату в 3000$. Возьмем период в три недели. С некоторой вероятностью в этом периоде ты вообще не получишь ни копейки. Означает ли это что работа не приносит тебе прибыли?
Здравствуйте, Vlad_SP, Вы писали:
V_S>Мы используем собственно придуманные коэффициенты (скорее всего, кто-то это придумывал до нас): V_S>— коэффициент исполнения плановых сроков. Считается от планового срока по задаче (согласовывается вместе с исполнителем) и его фактической протяженностью в часах
Как этот коэффициент соотносится с эмпирическим "правилом PI раз" (Реальные сроки обычно больше рассчетных в PI раз)? Не получается ли так, что этот коэффициент всегда составляет 30%? Хотелось бы услышать, какие значения обоих коэффициентов у вас считают нормальными?
Здравствуйте, Vlad_SP, Вы писали:
V_S>Мы используем собственно придуманные коэффициенты (скорее всего, кто-то это придумывал до нас): V_S>— коэффициент исполнения плановых сроков. Считается от планового срока по задаче (согласовывается вместе с исполнителем) и его фактической протяженностью в часах
Спасибо! Принимается.
V_S>— коэффициент поддержки закрытой задачи — отношение времени, потраченного на задачу ко времени, потраченному на ее саппорт в дальнейшем. Фактически, отображает качество решения задач программистом.
По-моему, это примерно то же самое, что и у меня: отношение количества строк кода за единицу времени к качеству (количество ошибок и дефектов на единицу строк кода), только выраженное в других попугаях.
V_S>Идеи, вероятно, не новы и можно придумать что-то еще, но это "автомат Калашникова": простой и надежный способ, чтобы на цифрах без субъективщины показать, кто как работает.
Когда нет (у меня) соответствующего образования (основы), приходится "творить, выдумывать, пробовать". Недавно нарвался на хаббардистов (принял участие в семинаре "Идельная структура предприятия"), так они призывают не думать (что совсем неприемлемо для меня-технаря), а знать (конечно же, резон есть: насколько всё быстрее делается).
Здравствуйте, Miroff, Вы писали:
M>Краткосрочная -- M>Среднесрочная -- M>Долгосрочная --
Спасибо.
M>Простой пример, раз в месяц тебе платят зарплату в 3000$. Возьмем период в три недели. С некоторой вероятностью в этом периоде ты вообще не получишь ни копейки. Означает ли это что работа не приносит тебе прибыли?
Применительно к зарплате — да, в течении трех недель у меня не было дохода и, следовательно, прибыли.
А если аналогичный пример сделать для юрлица, ведущего учет доходов и расходов по методу начислений, то за эти три недели это юрлицо все-таки получило доход, даже реально не получив денег.
Здравствуйте, hlt, Вы писали:
hlt>требуется сформулировать чёткие, объективные, критерии категорий программистов. Причём, на основе этих критериев, программист должен чётко представлять, что он должен сделать, чтобы получить повышение...
Есть варианты с трактовками Junior-Specialist-Senior-Lead
Скажем, Junior — имеет мало опыта работы с технологиями и стажа вообще, требует регулярной помощи
Specialist — хорошо самостоятельно работает в своей узкой области задач/технологий
Senior — успешнее (быстрее, меньше багов) работает в своей области и может заменить любого Specialist в своей группе
Lead — имеет административные функции по планированию работ и отслеживанию плана
И еще добавки к зарплате за функциональные обязанности
1. За обучение своих коллег
2. За совмещение обязанностей
3. За поддержку пользователей
4. За ненормированный рабочий день
И т.д, и т.п.
Тогла способ перехода на более высокй уровень по з/п становится тривиальным:
Junior -> Specialist — путем признания руководством, что Jr теперь работает самостоятельно и не требует поддержки
Specialist -> Senior — путем увеличением сферы решаемых задач и увеличением производительности
Senior -> Lead — путем выполнения еще и административных функций
Этот деление не жесткое, надо смотреть по вашим сотрудникам, сколько вам надо категорий и чем они должны отличаться. Но принцип, я думаю, понятен.
Здравствуйте, bkat, Вы писали:
B>Ну если у вас уже есть проверенная модель оценки прибыли по такой схеме и B>вы сможете конкретно про меня сказать, сколько я принесу прибыли именно у вас, B>то я пожалуй соглашусь
Я с тобой не работал, резюме твоего не видел и вообще ничего про тебя не знаю. Как я могу оценивать какую прибыль ты принесешь?
И потом, я не говорил о том что метод применим для новых сотрудников. Проблема в том, что заранее не ясно как они вольются в команду. Самый грамотный специалист может развалить самую успешную команду и наоборот, юниор месяц назад выгнанный со второго курса может дать команде новый сплачивающий фактор. Все-таки прием новых людей это менеджмент, а не экономика.
B>Но что-то я сомневаюсь в том, что у вас (да и вообще где-либо) в таком духе могут подсчитать прибыть от уборщицы.
Довольно легко. Предположим уборщицу выгнали. Однако ее работа никуда не делась и ляжет на плечи разработчиков. Разработчикам платят 10$ в час. Сколько времени это займет у разработчиков? 2 раза в неделю подметать пол (0.5 ч/ч), раз в две недели -- мыть (1 ч/ч), два раза в неделю вытирать пыль (0.5 ч/ч), 2 раза в год устраивать генеральную уборку с мытьем окон и торжественным уничтожениеим хлама (по полдня на всех) Итого, на команду из 6 человек имеем 70$ в месяц. Кроме того упадут производительность труда и престиж конторы в глазах сотрудников. Насколько именно упадут зависит от конкретных условий. Последние два критерия непредсказуемые и количественной оценке не поддаются. Одно это уже останавливает вменяемое руководство от разгона уборщиц )
Здравствуйте, S-SH, Вы писали:
SS>Есть варианты с трактовками Junior-Specialist-Senior-Lead SS>Junior -> Specialist — путем признания руководством, что Jr теперь работает самостоятельно и не требует поддержки
Примерно так это у нас и работает... Но проблема в формировании объективных показателей. С меня пытаются вытрясти именно объективные (независящие от руководителя) критерии/показатели, которые можно измерить. По мнению местных специалистов по ISO9000 — "это не должно строится на ощущении руководителя..."
Здравствуйте, hlt, Вы писали:
hlt>Но проблема в формировании объективных показателей. С меня пытаются вытрясти именно объективные (независящие от руководителя) критерии/показатели, которые можно измерить. По мнению местных специалистов по ISO9000 — "это не должно строится на ощущении руководителя..."
Формальные аттестации — зачет/не зачет, сколько баллов набрал.
Здравствуйте, hlt, Вы писали:
hlt>С меня пытаются вытрясти именно объективные (независящие от руководителя) критерии/показатели, которые можно измерить.
Рыночная стоимость машины программиста, с учетом ее текущей аммортизации.
