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

___>5. ввести систему отчетности, когда каждый человек должен раз в неделю сдавать отчет о проделанной работе, чтобы пункты 3 и 4 не пошли во вред, расхолаживая народ

Сами писали такие отчеты? По мне так совершенно идиотская мера.

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

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

___>>5. ввести систему отчетности, когда каждый человек должен раз в неделю сдавать отчет о проделанной работе, чтобы пункты 3 и 4 не пошли во вред, расхолаживая народ

Z>Сами писали такие отчеты? По мне так совершенно идиотская мера.

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

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

G>>Лучше забудь об этом. Можно давать премии только за простые вещи — например, соблюдение стандарта кодирования, который закреплен документом и контроллируется на регулярных code review. Но это напрямую к результату не относится.
M_E>Да, но ведь как-то надо поднимать производительность труда.

В самом деле? Она что, у вас недостаточно высока? А можно узнать — а как именно вы это поняли, и в чем видите причину?

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

0rc>>Предлаю считать строчки кода. Это реально работает
M_E>Не думаю. Если ты пишешь больше кода, это не значит, что у тебя производительность или качество выше.

Я шутил. Собственно, в вашем сообщении был вопрос:

"по каким объективным характеристикам работы программистов можно осуществлять их поощрение?"

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

PS: Про строчки кода, качество итд, думаю премий не надо, т.к:
1)В случае массового характера — лекциями и обучением, допустим на час рабочего времени
2)В случае единичного характера — персональным разговором ( без "загонов" только :)

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

>позволяет выявить момент, когда работник по каким-то своим личным причинам вдруг забил на работу
>во всем остальном действительно малоэффективна

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

Думаю, что справедливо будет материально. Как именно — решать тебе, исходя из местных условий.

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

M_E>Хотелось бы стимулировать не только качество кода, но и интенсивность труда (личный пример действует не на всех, а стоять за спиной у каждого и контролировать его невозможно).

Помнится в стародавние времена наш менеджер попросил нас присылать список закрытых за день tracker items, ну или сколько примерно процентов сделал, если item большой. Никаких плюшек или наказаний за то, что вкалывал/забивал не было, вообще никакой реакции — просто отчетность, т.к. тракер такие репорты делать не умел.
Однако промотивировало будьте-нате! Как-то было совестно перед коллегами слать отчет о том, что за весь день изменил название кнопки, в то время, как народ вовсю пахал. Да и приятно в конце дня было выкатит списочек пообширнее остальных Доходило до ругани, типа "чего это ты все айтемы себе забрал! а ну делись давай".
Вот уж не знаю специально манагер так придумал, или само получилось. Так же не возьмусь ручаться, что подход переносим на другие команды.

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

V_S>>- коэффициент выполнения — соотношение планового срока и фактического, слишком большие отклонения как в плюс, так и в минус — сигнал тревоги для менеджера,
V_S>>- коэффициент поддержки — соотношение времени разработки и времени поддержки и исправления ошибок (не путать с доработкой нового функционала!).
M_E>Да, это интересные показатели, как мне кажется.
M_E>Коэффициент выполнения подсчитать достаточно просто — плановые трудозатраты есть, фактические тоже есть.
Ужасно интересные показатели. Вот я беру, и называю в полтора раза больший срок при планировании, после чего затягиваю выполнение, и выхожу точно на дату. Причем — это время трачу на отладку в экзотических сценариях, и рефакторинг для удовольствия и красоты.

M_E>А вот с коэффициентом поддержки немного сложнее — конечно, мы ассоциируем ошибки в баг трекере с компонентами системы и назначем их на разработчиков. Но здесь получается, что ошибки еще должны быть ассоциированы с той задачей, решением которой они были порождены — сейчас у меня такой привязки нет. Затем мы сможет подсчитать сколько времени ушло на поддержку.
M_E>Получается так?

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

M_E>Да, и теперь, как следует поощрять на основе этих показателей? Морально (ну т.е. кому-то будет стыдно за плохие показатели)?
Никак.

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

Z>Время от времени проводится конкурс решения проблем. Каждый желающий предлагает проблему и найденое им решение за последний период времени. Оценка результатов может производиться кем угодно в зависимости от ситуации. Результаты публикуются, первые места получают премию.

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

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

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

Большинство — не побоюсь обобщить однако — хочет от фирмы банального: просто делать свою работу и просто получать за это причитающеся деньги. У большинства — не побоюсь еще раз обобщить однако — своих забот помимо работы полон рот и обычно пара ртов, которые кормить надо — не считая своего. Задача фирмы — сделать бизнес, а не "дать каждому работнику чего он хочет" — имхо, ее и надо решать.

___>3. создать комфортную обстановку на рабочем месте — как именно, я уже описал
___>5. ввести систему отчетности, когда каждый человек должен раз в неделю сдавать отчет о проделанной работе, чтобы пункты 3 и 4 не пошли во вред, расхолаживая народ

О, да! Программисты еженедельные отчетности просто обожают!
9:00-9:15 — включал компьютер
9:15-9:30 — просматривал почту
9:30-9:45 — пил кофе
9:45-10:00 — ковырял у себя в носу
...


Вызывает интерес замечательная корреляция пунктов 3) и 5) — имхо, "создать комфортную обстановку на рабочем месте" и "ввести систему отчетности" — прямо противоположные вещи.

___>6. если есть какие-то области в проекте, позволяющие резко поднять профессиональный уровень, то назначить на эти области людей, которым действительно нужно резко поднять профессиональный уровень, и не напрягатся тем, что после поднятия уровня они уйдут в др место

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

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

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

___>>>5. ввести систему отчетности, когда каждый человек должен раз в неделю сдавать отчет о проделанной работе, чтобы пункты 3 и 4 не пошли во вред, расхолаживая народ

Z>>Сами писали такие отчеты? По мне так совершенно идиотская мера.

___>позволяет выявить момент, когда работник по каким-то своим личным причинам вдруг забил на работу
___>во всем остальном действительно малоэффективна

В отчете так и напишут:
13:55-18:45 — "по своим личным причинам забил на работу" (к)

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

V_S>... Однако еженедельные отчеты создают у начальников видимость того, что "все под контролем", а они, начальники, само собой, — "держат руку на пульсе"...

Ну, вообще-то _суть_ и изначальная цель этой "отчетнсти" именно в этом... "Начальники создают видимость что они в курсе и все под контролем". (к)

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

O>Однако промотивировало будьте-нате! Как-то было совестно перед коллегами слать отчет о том, что за весь день изменил название кнопки, в то время, как народ вовсю пахал. Да и приятно в конце дня было выкатит списочек пообширнее остальных Доходило до ругани, типа "чего это ты все айтемы себе забрал! а ну делись давай".

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

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

С таким уровнем разделения и с такой мотивацией это вообще не _команда_.

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

Z>>Время от времени проводится конкурс решения проблем. Каждый желающий предлагает проблему и найденое им решение за последний период времени. Оценка результатов может производиться кем угодно в зависимости от ситуации. Результаты публикуются, первые места получают премию.

TL>Товарищи манагеры, как вы со своими "конкурсами", извините, задрали. Словно нам, программерам, кроме как "в конкурсах решения проблем участвовать" делать больше ну совсем-совсем нечего...

+1. Это не вам делать нечего, у вас конкретная работа есть. Это у менеджеров проблема, чем себя занять.

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

А во-вторых — программисты by default отлично мотивированы, любят свою работу, и даже by default лояльны компании, если конечно не относиться к ним как к умственно отсталым детям и не портить им жизнь разными другими способами, которых есть широкий спектр. И ведь что удивительно, программистам эти вещи очевидны, но когда они становятся менеджерами, у них частенько как будто память отшибает. Бывает.

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

TL>Товарищи манагеры, как вы со своими "конкурсами", извините, задрали. Словно нам, программерам, кроме как "в конкурсах решения проблем участвовать" делать больше ну совсем-совсем нечего...

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

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

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

А я лезу в базу закрытых тасков за последние N месяцев (лет) и вижу, что сколько такой таск (в среднем) требует времени. И если ты систематически будешь называть завышенные в полтора раза цифры, — я так же систематически буду эти цифры "резать" до реальных, с раздачей люлей, если при реализации ты не уложился в срок. Ну или, как крайний вариант, — расстаемся...

G>А еще — самые дорогие ошибки возникают на границе подсистем, которые делаются разными людьми — из-за неявных допущений, которые они делают о "контрактах" и интерфейсах подсистем друг друга.

А вот это уже косяк проектировщика/архитекта, который не удосужился эти контракты и интерфейсы подробно и точно специфицировать. Программист-то (inmpementor) тут при чем?

G>В самом деле? Она что, у вас недостаточно высока? А можно узнать — а как именно вы это поняли, и в чем видите причину?
Ну скажем так — она могла бы быть выше. Не у всех конечно, но у некоторых.
Я замечаю, что некоторые разработчики не проявляют особо рвения — начинают опаздывать, подолгу пить чай, курить, невнимательно писать код и пр., хотя, я думаю, способны на большее. Не все конечно, но некоторые — да.

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

O>Помнится в стародавние времена наш менеджер попросил нас присылать список закрытых за день tracker items, ну или сколько примерно процентов сделал, если item большой. Никаких плюшек или наказаний за то, что вкалывал/забивал не было, вообще никакой реакции — просто отчетность, т.к. тракер такие репорты делать не умел.
O>Однако промотивировало будьте-нате! Как-то было совестно перед коллегами слать отчет о том, что за весь день изменил название кнопки, в то время, как народ вовсю пахал. Да и приятно в конце дня было выкатит списочек пообширнее остальных Доходило до ругани, типа "чего это ты все айтемы себе забрал! а ну делись давай".
O>Вот уж не знаю специально манагер так придумал, или само получилось. Так же не возьмусь ручаться, что подход переносим на другие команды.
Вообще, интересная мысль. У нас в баг трекинге и так видно, кто сколько сегодня задач закрыл, но только вряд ли кто-то это смотрит.
Я думаю можно сделать автоматическую рассылку — чтобы все получали список сотрудников и кол-во задач, которые они закрыли за день или неделю.

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

G>Ужасно интересные показатели. Вот я беру, и называю в полтора раза больший срок при планировании, после чего затягиваю выполнение, и выхожу точно на дату. Причем — это время трачу на отладку в экзотических сценариях, и рефакторинг для удовольствия и красоты.
Именно так — я вчера писал об умышленном завышении сроков.

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

0rc>Однозначно ответить трудно, поскольку я не знаю ни степень зрелости ваших процессов, ни степень зрелости персонала, ни степени зрелости организации. А это важно... Но обобщенно можно ответить :) В вашем случае, думаю, нужно действовать исключительно по ситуации. Точечно. Т.е. если допустим, сотрудник имеет какие-то временные трудности и вы считает что премия промотивирует его — сделайте это. Если все хорошо, и есть допустим сотрудник, который лидер по всем показателям. Ну примируйте его, публично поздравьте, можно по ситуации — с занесением в трудовую. Короче все должно быть точечно с одной стороны, с другой — будьте последовательны в своих решениях и мотивации (могут быть даже нефинансовые) должны иметь систематичный характер...

Полностью согласен на счет систематического характера.
В так случае можно сформировать фиксированный премиальный фонд (ежемесячный или ежеквартальный) и объявлять премии публично на Status meeting'ах и указывать за что они выданы.