A>В Toyota вам придется познакомиться с философией Дзэн. «Как только вы понимаете, что это и есть сам процесс, и искать плато не нужно, вы можете расслабиться. Выполнение работы и улучшение ее качества становятся единым целым, – говорит Шук. – Вот это и означает – приступить к делу».
проблема заключается в том, что эта философия основана на социальной структуре азиатских обществ
а один из основоплогающих принципов этих обществ гласит:
человек НЕ может поднять свой социальный статус сам, не нарушив закон, ничего не украв или не упоубивав кучу народа
только Господин может поднять твой статус
вся твоя жизнь предопределена от рождения
не надо рыпаться и стремится к каким-то целям, просто наслаждайся процессом
это глубоко чуждо европейскому и тем более американскому стандарту мышления
понятно, что Россия далеко не западная страна
но далеко не всем в компании такой принцип понравится
В дополнение если есть возможность посмотреть книгу "Основы менеджмента" Мескон там в разделе теория мотивации Герцберга приведены интересные данные исследования мотивирующих факторов и их количественное выражение. По себе могу сказать, что данные очень близки к моей собственной оценке.
Вообще чисто финансовая мотивация применима разве, что к предпринимателям. Программисты зачастую такими не являются, поэтому и система мотивации у них сложнее.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Отвечаю: I>>как там с водой на рабочем месте (чистая \ из крана), чай кофе? M_E>Всегда горячая вода, чай и кофе.
блин. полумеры не помогли
еще такой вопрос — на что чаще всего за пивом жалуются программеры? или просто когда запарка — о чем вспоминают чаще всего о плохом?
некоторых вот напрягает к примеру плохой инет, бумагу брать по расписке еще какие то мелочи, которые по штучно не важны. но бесят. но это так — больше к удержанию команды. а вот чтоб работали больше...
есть ли шанс — сделать версионную разработку? в каждый выпуск версии включить список багов на устранение + новый фунционал. Сделали вовремя — премия, сделали раньше премия*1,5, сделали позже. ничего не получили. (но если позже — получите и вы )
Я не умею быть злым, и не хочу быть добрым.
Предлагаю мотивировать не количество, а качество работы
Вчера, совершенно случайно, при разговоре коллега упомянул как работает сервер интеграции на его прошлой работе. И мне это очень понравилось.
Суть вот в чем. Есть сервер интеграции с системой контроля версий и прочими приблудами для сборки, прогона тестов и снятия метрик.
У этого сервера есть вэб интерфейс, на главной странице которого пишется статистика: какая версия приложения, рабочий код или нет, кто последний закомитил. Но не это самое главное. Самое главное это: таблица ниже -- рейтинг программистов работающих над кодом.
Рейтинг этот составляется автоматически на основе анализа комитов программеров (какие критерии -- вопрос отдельный, который будет затронут ниже).
Получаем мотивационный фактор -- никто не хочет быть на последнем месте, все стараются делать свою работу лучше. Т.е. соответствовать критериям выставления рейтинга (поэтому рейтинг должен быть комплексный).
Важно чтобы эту оценку делала "бездушная машина" и могла объяснить почему она это так сделала: 10 очков получил за покрытие тестами, 5 за низкую сложность кода (complexity), 20 очков сняли потому, что закомиченный код на 87% копипаст кода Васи... Это нужно для того, чтобы люди знали что им нужно улучшить в своей работе, чтобы добится хорошего результата.
По поводу критериев. Я считаю, что оценивать нужно не количество, а качество. Когда качество всей системы станет высоким добавление новых изменений будет стоить меньше (закон диалектики, епть!). Да и сама цель "качество" более понятна чем "количество" -- почему нужно писать хороший код объяснить легче, чем зачем писать больше -- первое это важно для самого программиста (быть специалистом), а второе важно только для компании компании.
Поэтому мои критерии:
1) Дубилрование кода
2) Покрытие нового кода тестами
3) Сложность методов (вложенные ифы, форы, ...)
4) В принципе, сюда можно добавить и количество строк кода. С одной стороны много не напишешь -- нужно покрытие тестами, много не скопипастишь,... , а с другой этому критерию можно дать низкий вес.
5) Если, не дай бог, кто-то залил некомпилируемый код, либо код ломающий тесты -- нещадно штрафовать (рейтингом, ессессно).
6-n) Ваши варианты
Я думаю они не сами эту систему придумали, систему оценок и готовые парсеры для вычисления рейтинга (и набор критериев к ним) могут предложить большинство ПО для серверов интегрирования. Но посоветовать ничего не могу, так как наш выполняет только функцию сборки и деплоя в тестовую среду.
Как использовать этот рейтинг: ни в коем случае не наказывать рублем! Поощрять первые места -- да, но никого не наказывать! Программисты в основном народ вменяемый, поэтому отстающему самому не понравится быть всегда на последнем месте. Можно будет попросить человека без проблем с рейтингом помочь тому у кого они есть ... Можно получить статистику с чем в вашей команде основные сложности (написание юнит тестов, сложный код, копипасты) и провести целенаправленое обучение.
никоем образом не потерял своей актуальности. Поэтому критерии нужно выбирать осторожно, а еще осторожнее нужно использовать статистику по этим критериям. ИМХО, задача выбрать критерии оценки таким образом чтобы хорошим разработчикам соответствовать критериям было не сложно, чтобы у них оставалось желание помогать другим. Т.е. и тут важна мера.
Здравствуйте, __steven__, Вы писали:
___>Здравствуйте, Aikin, Вы писали:
A>>В Toyota вам придется познакомиться с философией Дзэн. «Как только вы понимаете, что это и есть сам процесс, и искать плато не нужно, вы можете расслабиться. Выполнение работы и улучшение ее качества становятся единым целым, – говорит Шук. – Вот это и означает – приступить к делу».
___>проблема заключается в том, что эта философия основана на социальной структуре азиатских обществ
На территории завода компании Toyota в американском Джорджтауне есть покрасочный цех.
Это америка, в статье рассмотрены американские заводы.
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, __steven__, Вы писали:
___>>Здравствуйте, Aikin, Вы писали:
A>>>В Toyota вам придется познакомиться с философией Дзэн. «Как только вы понимаете, что это и есть сам процесс, и искать плато не нужно, вы можете расслабиться. Выполнение работы и улучшение ее качества становятся единым целым, – говорит Шук. – Вот это и означает – приступить к делу».
___>>проблема заключается в том, что эта философия основана на социальной структуре азиатских обществ A>
На территории завода компании Toyota в американском Джорджтауне есть покрасочный цех.
A>Это америка, в статье рассмотрены американские заводы.
я не о заводах
я о философии
и о ее применимости к управлению людьми выросшими в др культуре
Re: Предлагаю мотивировать не количество, а качество работы
Здравствуйте, Aikin, Вы писали:
A>Вчера, совершенно случайно, при разговоре коллега упомянул как работает сервер интеграции на его прошлой работе. И мне это очень понравилось.
Да, мне тоже такая идея очень понравилась, если честно.
А чем они пользовались?
... << RSDN@Home 1.2.0 alpha rev. 775>>
Re[2]: Предлагаю мотивировать не количество, а качество рабо
Несогласен с этим. Все зависит от способностей конкретного менеджера, как это преподнести и какое обоснование всего этого он сможет найти. >>Вы всерьез считаете, что разработчики включатся в борьбу за "рост прироста функционала", "снижение кол-ва багов на единицу функционала" и т.п., и от >>этого будут иметь более высокую мотивацию? Что ж, спорить не буду, тем более помню, как лет 8 назад народ сильно вдохновлялся на борьбу с рутиной >>после прочтения, скажем, какой-нибудь Extreme Programming Explained и т.п.
Здравствуйте, Kuzmenko_A, Вы писали:
K_A>Несогласен с этим. Все зависит от способностей конкретного менеджера, как это преподнести и какое обоснование всего этого он сможет найти. >>>Вы всерьез считаете, что разработчики включатся в борьбу за "рост прироста функционала", "снижение кол-ва багов на единицу функционала" и т.п., и от >>этого будут иметь более высокую мотивацию? Что ж, спорить не буду, тем более помню, как лет 8 назад народ сильно вдохновлялся на борьбу с рутиной >>после прочтения, скажем, какой-нибудь Extreme Programming Explained и т.п.
Извините, но в цитируемом Вами моем тексте вообще нет каких-либо утверждений, поэтому подозреваю, что не согласны Вы все-таки с чем-то другим (или с кем-то) Тем более, что после слов "не согласен", были Ваши слова: "Деньги имеют конечно же важное мотивирующее значение...", а потом дополнительный отдельный пост со сссылкой на данные о финмотивации из книги "Основы менеджмента". В общем, спасибо за общение, вопросов у меня больше нет.
Так. Отлично! Удалось получить конкретный и четкий ответ. Наконец-то (после двух дней дискуссий) мы стали продвигаться в правильном направлении. Ну почему все это нужно из тебя клещами вытягивать под пытками?
Теперь следующая группа вопросов:
Вот ты пишешь, (16.06.08 14:48) что "как-то надо поднимать производительность труда". Ты считаешь текущую производительность низкой? Как ты ее измерил? За какой период? Каков разброс данных и доверительный интервал полученной тобою цифры? Какую цифру производительности ты считал бы "нормальной"? А "высокой"? Откуда взяты эти цифры? Чем обоснованы?
На самом деле, ответы на эти вопросы — ключевые в твоей деятельности. Это — определение цели деятельности и критериев ее достижения. Только потом можно разрабатывать и обсуждать способых достижения. "Ни один ветер не будет попутным для корабля, не знающего, куда ему плыть." (Луций Анней Сенека)
Re[3]: Предлагаю мотивировать не количество, а качество рабо
Здравствуйте, Aikin, Вы писали:
e_k>>А вы не в курсе случайно, есть ли что-либо похожее, чтобы было заточено не только под Java? A>Мопед не мой Я просто делюсь тем что вчера услышал
А можно попробовать узнать там же про другие мопеды?
Здравствуйте, Michael_E_Smrinov, Вы писали:
0rc>>Предлаю считать строчки кода. Это реально работает M_E>Не думаю. Если ты пишешь больше кода, это не значит, что у тебя производительность или качество выше.
а как на счет: 1/"ко-во строк кода"?
Re: Предлагаю мотивировать не количество, а качество работы
Здравствуйте, Aikin, Вы писали:
A>Получаем мотивационный фактор -- никто не хочет быть на последнем месте, все стараются делать свою работу лучше. Т.е. соответствовать критериям выставления рейтинга (поэтому рейтинг должен быть комплексный).
Ну, мотивационным фактором это будет в первую очередь "для хвоста" и "для головы" — тем более что...
A>Важно чтобы эту оценку делала "бездушная машина" и могла объяснить почему она это так сделала: 10 очков получил за покрытие тестами, 5 за низкую сложность кода (complexity), 20 очков сняли потому, что закомиченный код на 87% копипаст кода Васи... Это нужно для того, чтобы люди знали что им нужно улучшить в своей работе, чтобы добится хорошего результата.
... тем более что чаще всего большее количество этих "автоматических критериев" выбирается менеджерами и обратно таки "лично-ориентированы", а не "системно-ориентированы". С точки зрения "личной мотивации" — таки да, предполагается что типа нехорошо коммитить решение, скопипастеное у Васи, потому как получается "меньший личностный вклад" — а вот с точки зрения системы как раз _правильно_ комитить именно _едиообразное_ решение, дабы не плодить в коде может и "один лучше другого", но, тем ни менее, "зоопарк".
Правильным решением было бы передать решение участка "на 87% васиного кода" самому Васе, ибо он над этим кодом как миниму думал и наверняка сможет даже более лучшее решение найти быстрее, а заодно и внедрить то же самое улучшенное решение и в свой более старый код — но это, конечно, идеал, и никакой "Вася" при "лично-рейтинговом" подходе к оценке его работы таки заниматься не захочет.
Проверим?
A>Поэтому мои критерии: A>1) Дубилрование кода A>2) Покрытие нового кода тестами A>3) Сложность методов (вложенные ифы, форы, ...) A>4) В принципе, сюда можно добавить и количество строк кода. С одной стороны много не напишешь -- нужно покрытие тестами, много не скопипастишь,... , а с другой этому критерию можно дать низкий вес. A>5) Если, не дай бог, кто-то залил некомпилируемый код, либо код ломающий тесты -- нещадно штрафовать (рейтингом, ессессно). A>6-n) Ваши варианты
Сперва: смешно — правда.
1) Дублирование кода само по себе без рефакторинга не решается — пусть лучше будет легко-отслеживаемое дублирования с возможностью дальнейшего нахождения аналогичных участков и вынесения их в обобщение, чем вагон велосипедов, в стремлении "ни в коем случае не скопипастить чужое". А вообще при подходе "все разжевано архитекторами — над кодом трудится бригада (обезьянок-)кодеров" совершенно непонятно, откуда оное вообще берется — архитекторы чего-то недосмотрели ага?
2) Это, конечно, правильно — увы, далеко не всегда реализуемо на практике. Ну и потом грамотное покрытие с должной эффективностью способен сделать грамотный QA Eng. — у девелоперов, а тем более кодеров, чаще получается именно (1) — "просто дублирование пришедших в голову вариантов". А так вообще тест-кейзы должны быть заданы еще архитекторами — в идеале...
3) Это в целом просто смешно. Без коментариев.
4) В прицнипе, манагеры сюда могут еще много чего добавить — на то они и манагеры...
5) Ну так я предлагал по утрам поднимать флаг и петь гимн — поломавших билд как раз тогда удобно выводить и расстреливать.
ЗЫ: интересно, а зачем тогда вообще "делать билд", "заливать код", "писать тесты", если потом святым трепетом бояться все это поломать?
A>Как использовать этот рейтинг: ни в коем случае не наказывать рублем! Поощрять первые места -- да, но никого не наказывать! Программисты в основном народ вменяемый, поэтому отстающему самому не понравится быть всегда на последнем месте. Можно будет попросить человека без проблем с рейтингом помочь тому у кого они есть ... Можно получить статистику с чем в вашей команде основные сложности (написание юнит тестов, сложный код, копипасты) и провести целенаправленое обучение.
Не страшны дурные вести,
Начинаем бег на месте,
В выигрыше даже начинающий.
Красота: среди бегущих
Первых нет и отстающих —
Бег на месте общепри-
миряющий
Лично я с трудом представляю себе "команду", в которой отдельные ее представители и вся команда в целом плохо представляет себе реальный вклад каждого в отдельности в общее дело и для "показания оного" нужны все эти "рейтингомерялки". Если это дивизия никак не связанных друг с другом (обеъзьянок-)кодеров — тогда да. А чтобы _команде_ для понимания своих сложностей в чем-либо — написание юнит тестов, сложный код, копипасты, сроки, опоздания, засиживания, нежелание работать, неопрятный вид, etc. — нужна была "сторонняя ...мерялка"? Извините, но это что угодно, только не _команда_. Проверено лучшими собаководами.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>В литературе упоминается, система мотивации должна быть привязана к целям компании. Но у нас условия таковы, что существует фиксированный фонд оплаты труда, который не особо зависит от результатов деятельности компании. Его, конечно, можно менять, но это достаточно длительный процесс и он не зависит от итогов работы за какой-то период короткий — например, за месяц.
ИМХО, премии и повышение зарплаты не очень сильно влияют на производительность программистов. Впрочем, большая прибавка может добавить энтузиазма, но ненадолго. В основном люди работают так, как работается. С другой стороны, деньги могут существенно влиять на решение человека сменить работу или остаться, и на то, новых специалистов какого уровня вы можете привлечь.
Здравствуйте, Aikin, Вы писали:
G>>Кстати, про соотношение обдумывания и кодирования ты не прав. A>Да я знал что будут вопросы к этим цифрам. Только я ожидал их много раньше A>Сразу скажу что эта цифра из головы. И это не более чем мое ощущение. Так что твои цифры вполне могут быть точнее.
Так у меня к этим цифрам нет вопросов . Я знаю, какие они обычно бывают, потому что мы измеряли фактические цифры работая по PSP/TSP.
Re: Предлагаю мотивировать не количество, а качество работы
Здравствуйте, Aikin, Вы писали:
A>Поэтому мои критерии: A>1) Дубилрование кода A>2) Покрытие нового кода тестами A>3) Сложность методов (вложенные ифы, форы, ...) A>4) В принципе, сюда можно добавить и количество строк кода. С одной стороны много не напишешь -- нужно покрытие тестами, много не скопипастишь,... , а с другой этому критерию можно дать низкий вес. A>5) Если, не дай бог, кто-то залил некомпилируемый код, либо код ломающий тесты -- нещадно штрафовать (рейтингом, ессессно). A>6-n) Ваши варианты
Угу. Понятно, в каком направлении развивалась бы ваша мысль, если вас сделать менеджером.
Софтверные метрики не игрушки, методики, которые на них основаны, например PSP/TSP, категорически запрещают любое их применение для любых оценок персонала. Личные метрики — приватная информация, их нельзя публиковать на таких сайтах. Публикации подлежат только агрегатные средние метрики команд.
Баловство это чистой воды. Эта балльная оценка не имеет никакого отношения к качеству кода и реальному вкладу программистов. И зачем она тогда нужна? Надо не рейтинги подводить, а реально обеспечить необходимое качество кода и дизайна, в этом задача менеджмента. Что решается вовсе не вашей "позорной доской" или "доской отличников боевой подготовки".
Re[2]: Предлагаю мотивировать не количество, а качество рабо
)
Извините, но это что угодно, только не _команда_. Проверено лучшими собаководами. 
