Здравствуйте, bkat, Вы писали:

B>Но общие затраты/трудоемкость/стоимость увы чаще еще важнее.
B>А иначе не было бы попыток "впихнуть невпихаемое" со стороны того же менеджмента.

Важность их пропорциональна тому, на сколько увеличиваются "затраты/трудоемкость/стоимость".

В рассматриваемом примере две недели супротив одной или даже трёх дней — ерунда. Когда же вместо шести месяцев требуется "предсказуемые" два года — действительно, такая "предсказуемость" мало интересна.

Ценность же введения метрик в том, что они отучают от

завтра ты ко мне ко мне подрулишь с просьбой поправить старый баг

вы будете трендеть у меня над ухом пол-дня

стихийные совещания по чужим задачам

я работаю по 10-12 часов вместо 8

И когда это "отучание" пройдёт, когда работа, из-за оглмдки и учёта "в уме" KPI выйден на качественно новый уровень, "затраты/трудоемкость/стоимость" уменьшатся (при условии, что всё будет сделано по науке, а не по тому "как хочу").

Здравствуйте, _FRED_, Вы писали:

_FR>В рассматриваемом примере две недели супротив одной или даже трёх дней — ерунда. Когда же вместо шести месяцев требуется "предсказуемые" два года — действительно, такая "предсказуемость" мало интересна.

А почему вы считаете этот пример единственным? Снижается общая толерантность к риску у программистов и они завышают сроки. Человек получает премию за то, что сделал в срок, а не за то, что сделал быстро(проектная премия). Есть разница.

_FR>Ценность же введения метрик в том, что они отучают от
_FR>

завтра ты ко мне ко мне подрулишь с просьбой поправить старый баг

_FR>

вы будете трендеть у меня над ухом пол-дня

_FR>

стихийные совещания по чужим задачам

_FR>

я работаю по 10-12 часов вместо 8

_FR>И когда это "отучание" пройдёт, когда работа, из-за оглмдки и учёта "в уме" KPI выйден на качественно новый уровень, "затраты/трудоемкость/стоимость" уменьшатся (при условии, что всё будет сделано по науке, а не по тому "как хочу").

Похоже, вы заметили перенос программистом контекста Программмист не хочет вводить вероятность и придумывает новые риски.
Ладно, похвалил, хватит

Какой такой "качественно новый уровень"? Да, KPI для программистов есть по определению, он — в голове у менеджера проекта. Попытки сделать его формализуемым обычно ведут к ухудшению процесса разработки. Слишком много параметров, об этом уже не раз говорили.

Причина здесь вот в чем. Как только мы формализуем KPI и сделаем его всеобщим достоянием, программисты тут же начнут искать локальные оптимумы. И они обязательно их найдут. Сделаете большой приз за отсутствие багов и маленький — за сроки — будут немилосердно завышаться сроки. Сделаете большой приз за сроки и большой за баги — все останется, как было до введения KPI, поскольку простое увеличение зарплаты программисту (а это именно оно) приведет лишь к меньшей текучке, и не более того. Чудес не бывает.

Здравствуйте, Demotivated, Вы писали:

D>Конечно в единую формулу, как у конвеерных рабочих все не запихнуть, но можно попробовать более рыночные механизмы.

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

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

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, Demotivated, Вы писали:

D>>Конечно в единую формулу, как у конвеерных рабочих все не запихнуть, но можно попробовать более рыночные механизмы.

B>Можно конечно, но в итоге получите вы не программистов, а "бизнесменов" в миниатюре,
B>которые будут больше думать о "прибыле" чем о деле.

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

B>Зарплата и условия ее получения должны быть такими,
B>чтобы не отвлекать программиста от его основной деятельности
B>и чтобы он не смотрел на сторону.

Давно проехали...

B>Еще можно заделаться акционерным обществом и тогда
B>у работников появится возможность получать свой кусочек пирога

Тоже хорошо конечно, только это уже не имеет отношения к KPI.
Эффективно разве что для небольших контор и стартапов.
А когда в компании кроме тебя еще 500 чел работает, твой вклад на общем фоне не заметен.
Получаем практически тоже самое с чего начинали, кто-то проникнувшись ответственностью перед коллективом будет вкалывать,
кто-то изучать финансовые показатели компании и думать, не пора ли свалить.

21.09.2010 15:10, genre пишет:
>
> Именно поэтому во всех твоих сообщениях сквозит презрение к менеджменту
> во всех его проявлениях?
Ну а как можно уважать "эффективных русских менеджеров"?

> Не мешайте программерам работать, это не конструктив.Так работа не
> делается.
Делается.

> Это очевидно любому, кто хоть раз был вынужден отвечать на
> вопросы о сроках и качестве.
Ты считаешь что твое мнение можно возвести в абсолют?

>
> V>Они работают за деньги, но если им не мешать подавляющее большинство
> V>хочет сделать хорошо и отлично.
>
> Подавляющее большинство хочет сделать быстро, получить зарплату и пойти
> домой к семье/хобби/телевизору/итд
Не надо обо всех судить по себе.

> V>И как? Работает? ))))))
> V>Подобная методика гарантирует завышение сроков раза в 2-3.
> Да, работает.
Так я ж и не говорю, что это всегда плохо завышать сроки в 2-3 раза.
Очень часто это, наоборот, наиболее эффективно с точки зрения попила бабла.

Здравствуйте, Vzhyk, Вы писали:

>> Это очевидно любому, кто хоть раз был вынужден отвечать на
>> вопросы о сроках и качестве.
V>Ты считаешь что твое мнение можно возвести в абсолют?

Ну предложи методику определения эстимейтов на проект силами программистов.

Здравствуйте, Kernan, Вы писали:

K>Здравствуйте, starina_bz, Вы писали:

_>>Здравствуйте, Aptekar, Вы писали:

A>>>Руководителям компании важно, сколько принес денег каждый проект, в конце концов именно они эти проекты открывают и закрывают. Это их цель — сделать прибыль. Мне — не важно, я с этих денег ничего не имею, пусть я и добросовестно выполняю свою работу в рамках проекта, что мне отведён (а кто каким проектом занимается, решаю не я).

_>>Попробуйте изменить свой подход, увидеть лес за деревьями и всё-же стараться делать прибыль, а не работать работу в рамках проекта. Проработаете так полгода-год, сами удивитесь, насколько всё поменяется и поймёте. Что и успешность проекта и Ваше вознаграждение и продвижение совсем не на 95% ... зависит от менеджмента стратегического и оперативного. А может даже и на 100%, а в большей степени зависит от Вас самого.
K>Не надо простому программисту в конторе, где программист это ресурс пытаться увидеть лес, т.к.
K>- Не его зона материальной ответственности.
K>- Он всё равно ни на что не повлияет.

Это пассивная позиция.
Человек может очень сильно влиять на многое, любой. А уж на эффективность проекта — тем более.

K>- Вознаграждение оговорено в ТД.

Да. Но если человек работает не эффективно то его можно уволить. Если хорошо — можно премировать.

Здравствуйте, Vzhyk, Вы писали:

V>18.09.2010 11:08, mag745 пишет:
>>
>> Единственный параметр который мне нравится — это количество повторных
>> багов, т.е. появляется ли баг еще раз после его исправления. Т.е. чинил
>> одно — сломал другое, да еще то, что уже было починено.
V>А если то, что чинить приходится напоминает небоскреб построенный на
V>основе собачьей будки?
V>Т.е. код настолько ужасен, что починка в одном месте ломает в другом?

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

Здравствуйте, Vzhyk, Вы писали:

V>19.09.2010 16:40, mag745 пишет:
>>
>> Полностью согласен. Это хорошие параметры для оценки работы команды. Но
>> как показатель конкретного человека — не приемлемо. И именно как KPI.
V>В чем разница здесь? Команда или человек. Я понимаю, если эта команда
V>или человек работает абсолютно независимо от других и не использует
V>никаких сторонних инструментов (такая сферическая команда в вакууме).

Тут я соглашусь. Всетаки эти параметры могут быть применены как к программисту, так и к команде в целом. Мы же всегда можем рассматривать одного программера как команду из одного человека.
Конечно если брать среднее кол-во ошибок на человека и т.д., то и в этом случае просто делим на 1.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, mag745, Вы писали:

M>>Исходя из краткого определения KPI — это ключевой легко рассчитываемый параметр, который влияет на доходы компании.
_FR>А почему вы принимаете, что "легко рассчитываемый"? Ни разу. Методика расчёта может быть весьма и весьма тяжёлой, учитывающей десятки/сотни/тысячи показателей, каждый из который необходимо или нормировать, или помножить на нетривиальным образом подобранный/высчитанный весовой коэффициент.
_FR>Если KPI у вас считается "легко", то это должно вызывать определённые подозрения

KPI не должен рассчитываться сложно, иначе он теряет наглядность, если я не могу себе объяснить что означает эта цифра и почему если полученный результат выходит за пределы какого-то диапазона — это плохо, а за пределы другого — это отлично. Рассчет должен быть четкий и понятный. Иначе это просто волшебные цифры. А раз так — будем подгонять их. Например, рассчет KPI для продавца — ему ставится план продаж, превысил — бонус, ниже — нет не только бонуса, но есть и антибонус. Всё четко и понятно. При работе с заявками: среднее время исполнения заявки — всё ясно любому. И для программиста KPI должен быть не сложнее. Или программисты не люди и им нужно всё считать только трехэтажными формулами

M>>Отдел занимается техподдержкой внутренних продуктов компании и результат влияния на доходы косвенный.
M>>И как вообще можно загнать работу программиста в рамки KPI?
_FR>Надо не так: требуется [для начала] вокруг работы програмиста выстроить измерения тех или иных показателей.
Согласен что надо. Ваше предложение? Какие параметры выстроить можно?

_FR>"Загонять" же "работу" очень сложно :о) потому что тогда люди начитают трудиться не на результат работы, а на показатель. Если вы с "рамками" ошибётесь, то это то, что вам и нужно, а вот если промахнётесь, то результат может оказаться плачевным.
Мой пост — это просьба о помощи. Напишите конкретное предложение. Общими фразами я уже сыт. Мне нужна конкретная помощь.

M>>Вот какие показатели предлагает руководство:
M>>1) Некое отношение трудозатрат к приоритетности (удельному коммерческому весу).
_FR>ИМХО, это подсчитать возможно.
Подсчитал. Кстати хороший показатель оказался. Показывает насколько важными для организациями задачами нагружен отдел. Очень полезно, чтобы выявить те задачи, которые следуют отдать на аутсорс или консультантам, работающим с пользователями напрямую. Но как KPI он не катит. Он показывает качественную работу, но ведь за то какие задачи дают на разработку программист ответсвености не несет. Т.е. как KPI для оценки работы программиста не подходит.

M>>2) Количество новых/изменившихся требований с момента утверждения ТЗ.
_FR>И это тоже.
Посчитать можно. Но бестолковое занятие. Показывает, насколько увеличился срок выполнения проекта при таком-то количестве новых требований и изменений. Это и так очевидно без подсчета. Как по этому параметру оценить работника? Что сказали делать, то он и делал.

M>>3) «Количество» экспертиз, которыми надо обладать для решения задачи.
_FR>Тут я не понимаю, что означает "экспертиза". Квалификация? Умение? Тогда и с этим не будет сложности.
Тут я тоже теряюсь. Знание каких-то конкретных технологий. И уровень знания. А кто будет определять уровень знания? Кто решает? Это уже не объективно. Или проводить сертификацию в технологиях — это накладно для компании.

M>>На мой взгляд это параметры, которые нереально посчитать.
_FR>Реально-реально. Это же какая отличная инженерная задача — измерить неизмеримое
Задача интересная. Это точно.

M>>Ранее я сталкивался с такими параметрами: сколько задач сделано, по плану или сверх плана, дисциплина – фиксировалось время когда пришел – когда ушел, написание стольких-то ТЗ за год, написать патент. Но это вообще смешные показатели. Можно еще строки кода считать.
_FR>Сколько сделано по-плану/сверх того — отличный показатель эффективности. Прочее — ради фона с невысоким весовым коэффициентом учитывать очень даже можно так же.
И часто можно налюдать ситуацию, что сделано сверх плана? Ведь 80% проектов идут с перерасходом и денег и времени.

M>>Если кто-то сталкивался с этим или у вас внедрена система оценки по KPI для программистов — поделитесь, пожалуйста, информацией.
_FR>На прежни работах пытались. Выливалось всё [на мой строгий взгляд] в исключительно измерение того, на сколько своевременно предоставлен еженедельный отчёт
Это интересно и показательно.

M>>Какие же параметры загнать в KPI?
_FR>Пляшите от ответа на вопрос, что для вас есть "эффективность работы програмиста", чем по-вашему её стоит измерять?
А что Вы посоветуете в качестве эффективности работы программиста? Если есть варианты — напишите пожалуйста. Выбрать всегда легче, чем выявить, придумать или найти.

M>>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.
_FR>ИМХО, это крайне важно. Но настолько глупо в большом количестве случаев получается, что может быть и действительно отказаться от этогобудет лучшим для всех
Отказаться не получится.

Здравствуйте, mag745, Вы писали:

M>KPI не должен рассчитываться сложно, иначе он теряет наглядность, если я не могу себе объяснить что означает эта цифра и почему если полученный результат выходит за пределы какого-то диапазона — это плохо, а за пределы другого — это отлично. Рассчет должен быть четкий и понятный. Иначе это просто волшебные цифры. А раз так — будем подгонять их. Например, рассчет KPI для продавца — ему ставится план продаж, превысил — бонус, ниже — нет не только бонуса, но есть и антибонус. Всё четко и понятно. При работе с заявками: среднее время исполнения заявки — всё ясно любому. И для программиста KPI должен быть не сложнее. Или программисты не люди и им нужно всё считать только трехэтажными формулами

Можно и простыми и результат будет отличный, примерно такой http://www.rsdn.ru/forum/flame.comp/3917527.1.aspx

Автор: FR
Дата: 13.08.10

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, mag745, Вы писали:

M>>KPI не должен рассчитываться сложно, иначе он теряет наглядность, если я не могу себе объяснить что означает эта цифра и почему если полученный результат выходит за пределы какого-то диапазона — это плохо, а за пределы другого — это отлично. Рассчет должен быть четкий и понятный. Иначе это просто волшебные цифры. А раз так — будем подгонять их. Например, рассчет KPI для продавца — ему ставится план продаж, превысил — бонус, ниже — нет не только бонуса, но есть и антибонус. Всё четко и понятно. При работе с заявками: среднее время исполнения заявки — всё ясно любому. И для программиста KPI должен быть не сложнее. Или программисты не люди и им нужно всё считать только трехэтажными формулами

FR>Можно и простыми и результат будет отличный, примерно такой http://www.rsdn.ru/forum/flame.comp/3917527.1.aspx

Автор: FR
Дата: 13.08.10

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

Здравствуйте, mag745, Вы писали:

M>Здравствуйте!

M>Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом.

Правильно, мудрое руководство.

M>Исходя из краткого определения KPI — это ключевой легко рассчитываемый параметр, который влияет на доходы компании.
M>Отдел занимается техподдержкой внутренних продуктов компании и результат влияния на доходы косвенный.

M>И как вообще можно загнать работу программиста в рамки KPI?

Можно

M>В литературе по KPI написано:
M>Работу технических специалистов (бухгалтеров, инженеров, программистов) проще описывать должностной инструкцией. А подобрать для них справедливую «линейку» очень сложно.

M>Вот какие показатели предлагает руководство:

А ну давайте-ка глянем...

M>1) Некое отношение трудозатрат к приоритетности (удельному коммерческому весу).

Фигня

M>2) Количество новых/изменившихся требований с момента утверждения ТЗ.

Тоже фигня — как это относится к девелоперам? Может это все-таки вопрос к отделу маркетинга?

M>3) «Количество» экспертиз, которыми надо обладать для решения задачи.

А есть не поньимат чито бить экспертиза? Судебно-медецинская экспертиза? Или трассологическая?

M>На мой взгляд это параметры, которые нереально посчитать.

... а также очень трудно вообще понять

M>Ранее я сталкивался с такими параметрами: сколько задач сделано, по плану или сверх плана, дисциплина – фиксировалось время когда пришел – когда ушел, написание стольких-то ТЗ за год, написать патент. Но это вообще смешные показатели. Можно еще строки кода считать.

M>Если кто-то сталкивался с этим или у вас внедрена система оценки по KPI для программистов — поделитесь, пожалуйста, информацией.
M>Какие же параметры загнать в KPI?
M>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.

На самом деле такие показатели нужны, и при том не только руководству, а и самому программеру — иначе на основании чего он будет через полгода работы просить повышения з/п? Типа "ну я ведь крутой перец! А вы видели мои экспертизы? Да я вам прямо щас их достану!"
На вскидку, можно предложить следующие KPI:
1. По каждому таску, возложенному на благородного дона — среднее время задержки при выполнении задания (расчитывается по результатам, сделал вовремя — плюс, опережение графика является доп.плюсом, отстование — соотвественно минусом).
2. Точно также по каждому таску (модулю, куску функционала) — а) количество багов, найденных тестерами, б) количество багов, которые были переоткрыты (т.е. чувак вроде починил, запостил в соурс сейф, а оказывает он лажу напедалил и поскакало все по новому кругу) ну и т.п.
Если у вас контора, скажем так, "продуктовая", т.е. вы педалите свой продукт, и при этом у вас открытый диалог внутри конторы и все могут вносить предложение по продукту, процессам и т.п., и соотвественно эти предложения обсуждаются, внедряются/отклоняются, то можно еще считать такой показатель как количество внесенных предложений за год, количество принятых руководством как полезные — в умных книжках пишут, что это очень распространенная хрень у японцев и последнее время немцев и американцев в автоотрасли (тойота с ее бережливым производством ну и т.п.). Плюс это позволяет выявить людей, которые "не на своих местах" — скажем чувак у вас значится девелопером и педалит вроде бы неплохо, но при это имеет отличное видение бизнеса, понимание продукта, маркетинговых моментов, хорошее чутье относительно процессов, происходящих в конторе ну и т.п. Опять же повторюсь: для такой процедуры нужно понимание ее необходимости и полезности как в верхах, так и среди персонала — однако такой консенсус в одном месте и в одно время встречается крайне редко, а зачастую даже не привествуется одной из сторон.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, mag745, Вы писали:

M>>Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом.

Pzz>По-моему, надо начинать неторопясь искать другую работу...

Сто пудов! А то это работодатели кроме того что денег платят, так им еще и измеримый результат подавай! Вот ведь кровососы!

Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, mag745, Вы писали:

M>>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.

AAV>Мне нравится как это объясняет Дорофеев: http://cartmendum.livejournal.com/60982.html

Полная херня написана. Особенно вот эта аналогия:

Давайте на минутку забудем о том, что программисты пишут код и в этом коде потом кто-то ищет баги. Задачи все разные, люди еще более разные… Предположим, что эти цифры я получил в ходе очень простой игры:
У каждого из ребят есть ведро
В ведре насыпано 100 красных шариков, 900 белых и все это хорошо перемешано
Каждый из ребят закрывает глаза, и наугад вытягивает 100 шариков
Потом в выборке каждого мы считаем число красных шариков (типа багов)

Почему херня? Да потому что девелоперы не с закрытыми глазами педалят. Это как раз их задача номер 1, им за это деньги и платят: сидеть с открытыми глазами, скрипеть мозгами и реализовывать то, что необходимо по проекту. Если уж автор статьи так любит аналогии, интересно что он скажет вот на такую задачу:
Автор строит дом и ему нужно развести электричество (выключатели, распаечные коробки, розетки ну и т.п.). Он зовет электрика, с которым договаривается, что тот за оговоренную сумму сделает ему эту работу. Электрик копается месяц, а в конце на этапе приема/сдачи работы оказывается, что треть розеток и выключателей не работает — заплатит ли автор все 100% оговоренной суммы? Крупно сомневаюсь.

Здравствуйте, Glоbus, Вы писали:

G>Автор строит дом и ему нужно развести электричество (выключатели, распаечные коробки, розетки ну и т.п.). Он зовет электрика, с которым договаривается, что тот за оговоренную сумму сделает ему эту работу. Электрик копается месяц, а в конце на этапе приема/сдачи работы оказывается, что треть розеток и выключателей не работает — заплатит ли автор все 100% оговоренной суммы? Крупно сомневаюсь.

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

Электрик совершенно справедливо будет требовать 100% оплаты, потому, что когда он это делал все работало и уже проблем автора в том, что он пожлобился на прораба.

Здравствуйте, Glоbus, Вы писали:

Pzz>>По-моему, надо начинать неторопясь искать другую работу...

G>Сто пудов! А то это работодатели кроме того что денег платят, так им еще и измеримый результат подавай! Вот ведь кровососы!

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

Здравствуйте, mag745, Вы писали:

M>>>Исходя из краткого определения KPI — это ключевой легко рассчитываемый параметр, который влияет на доходы компании.
_FR>>А почему вы принимаете, что "легко рассчитываемый"? Ни разу. Методика расчёта может быть весьма и весьма тяжёлой, учитывающей десятки/сотни/тысячи показателей, каждый из который необходимо или нормировать, или помножить на нетривиальным образом подобранный/высчитанный весовой коэффициент.
_FR>>Если KPI у вас считается "легко", то это должно вызывать определённые подозрения

M>KPI не должен рассчитываться сложно, иначе он теряет наглядность, если я не могу себе объяснить что означает эта цифра и почему если полученный результат выходит за пределы какого-то диапазона — это плохо, а за пределы другого — это отлично. Рассчет должен быть четкий и понятный. Иначе это просто волшебные цифры.

Железная логика Вы имеете в виду какую-то конкретную методику расчёта KPI или просто озвучиваете своё мнение? Поищите всё-таки информацию по теме от квалифицированных советчиков. Начать можно отсюда: http://www.kpilib.ru, например вот.

_FR>>"Загонять" же "работу" очень сложно :о) потому что тогда люди начитают трудиться не на результат работы, а на показатель. Если вы с "рамками" ошибётесь, то это то, что вам и нужно, а вот если промахнётесь, то результат может оказаться плачевным.
M>Мой пост — это просьба о помощи.

В первую очередь — ознакомьтесь подробно с тем, как рассчитывают KPI буржуины для самых разных специальностей. Если вы дилетантски подойдёте к данному вопросу, наслушавшись и попытавшись повторить, то ничего хорошего не выйдет. Ну разве что вам требуется сделать дело "для галочки" и втиреть очки руководству Если же нет — то, чем вам поручено заняться не только очень ответственная задача, но и сложная. И подхода требует соответствующего.

M>Напишите конкретное предложение. Общими фразами я уже сыт.

Без "общих фраз" никак. То, за что вы взялись, имеет огромную теоритическую и практическую базу

M>Мне нужна конкретная помощь.

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

Здравствуйте, Miroff, Вы писали:

M>Здравствуйте, Glоbus, Вы писали:

G>>Автор строит дом и ему нужно развести электричество (выключатели, распаечные коробки, розетки ну и т.п.). Он зовет электрика, с которым договаривается, что тот за оговоренную сумму сделает ему эту работу. Электрик копается месяц, а в конце на этапе приема/сдачи работы оказывается, что треть розеток и выключателей не работает — заплатит ли автор все 100% оговоренной суммы? Крупно сомневаюсь.

M>Это опять же неверная аналогия. Правильно так:

А, ну тебе конечно виднее

M>Электрик совершенно справедливо будет требовать 100% оплаты, потому, что когда он это делал все работало и уже проблем автора в том, что он пожлобился на прораба.

Ты наверное стройкой и ремонтами никогда не занимался Прораб — это самое большое попадалово во всей этой кухне Если возможность есть (а для мегасупердевелоперов это не составляет никаких проблем — по крайней мере не должно) нужно самому быть прорабом.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Glоbus, Вы писали:

Pzz>>>По-моему, надо начинать неторопясь искать другую работу...

G>>Сто пудов! А то это работодатели кроме того что денег платят, так им еще и измеримый результат подавай! Вот ведь кровососы!

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

Ходить строем — само собой маразм. Но к метрикам это никак не относится. И к порядку в конторе тоже.