Здравствуйте, ry, Вы писали:
ry>Я уже просил, предложите объективный, эффективный, простой для понимания (но можно и сложный) и измеряемый критерий. Я с удовольствием буду его использовать.
Когда-то давным-давно здесь, на RSDN, я вычитал простой и эффективный метод управления:
D> может кто-то поделиться индикаторами производительности разработчика, D> которые используются в Вашей команде/конторе? Как рассчитывается производительность людей? D> используются ли эти показатели для подсчета успешности команда/проекта/конторы?
Мы используем собственно придуманные коэффициенты (скорее всего, кто-то это придумывал до нас):
— коэффициент исполнения плановых сроков. Считается от планового срока по задаче (согласовывается вместе с исполнителем) и его фактической протяженностью в часах
— коэффициент поддержки закрытой задачи — отношение времени, потраченного на задачу ко времени, потраченному на ее саппорт в дальнейшем. Фактически, отображает качество решения задач программистом.
Идеи, вероятно, не новы и можно придумать что-то еще, но это "автомат Калашникова": простой и надежный способ, чтобы на цифрах без субъективщины показать, кто как работает.
Автор этого метода, надеюсь, меня извинит за то, что имя его я не сохранил....
Здравствуйте, 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$. Возьмем период в три недели. С некоторой вероятностью в этом периоде ты вообще не получишь ни копейки. Означает ли это что работа не приносит тебе прибыли?
Применительно к зарплате — да, в течении трех недель у меня не было дохода и, следовательно, прибыли.
А если аналогичный пример сделать для юрлица, ведущего учет доходов и расходов по методу начислений, то за эти три недели это юрлицо все-таки получило доход, даже реально не получив денег.
Здравствуйте, Miroff, Вы писали:
M>Как этот коэффициент соотносится с эмпирическим "правилом PI раз" (Реальные сроки обычно больше рассчетных в PI раз)? Не получается ли так, что этот коэффициент всегда составляет 30%? Хотелось бы услышать, какие значения обоих коэффициентов у вас считают нормальными?
Упомянутое "правило пи раз" должно быть учтено (и реально учитывается) менеджером.
Что же касается реального коэффициента исполнения плана — то на небольших задачах (от 2 до 5 дней, это обычно достаточный уровень детализации для отслеживания реального состояния дел в проекте) он составляет, грубо, от 0.8 до 1.2 — то есть, возможны как небольшая недооценка, так и переоценка сложности задачи. На больших суммарных задачах (месяц-два-три) — обычно близок к 1.
Подчеркну, что плановый срок первоначально планируется менеджером, но обязательно согласуется с исполнителем. Большие отклонения коэффициента исполнения плана — как в меньшую, так и в большую сторону, — обычно свидетельствуют о неадекватности как менеджера, так и исполнителей. Эта проблема уже должна решаться административными методами.
Нет ничего страшного в том, что у исполнителя этот коэффициент "плавает" около единицы, отклоняясь то в плюс, то в минус. Все равно на реальных продолжительных этапах проекта эти опережения и отставания компенсируются. Вот если коэффициент постоянно в течение длительного периода времени завышен или занижен — это уже повод задуматься.....
Здравствуйте, 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>С меня пытаются вытрясти именно объективные (независящие от руководителя) критерии/показатели, которые можно измерить.
Рыночная стоимость машины программиста, с учетом ее текущей аммортизации.
