Мотивайция? - Управление проектами

M_E>Я замечаю, что некоторые разработчики не проявляют особо рвения — начинают опаздывать, подолгу пить чай, курить, невнимательно писать код и пр., хотя, я думаю, способны на большее. Не все конечно, но некоторые — да.
Да блин, когда уже мэнеджеры поймут, что работа программиста ТВОРЧЕСКАЯ (хорошего программиста)! Соотношение обдумывания и кодирования примерно 70:30 (хотя все зависит от задачи). Кроме того это не копание ямы -- если не с лопатой и не копаешь, то не работаешь.

У меня бывают дни когда работа просто не идет. И не потому что я не хочу работать, мало мотивирован или еще чего. Чаще всего у меня в голове нет четкой картины решения задачи. Я ее не чувствую. Поэтому не лежит писать код.
Я могу болтать с коллегами, пить чай, браузить инет. Но это не значит что я совсем не работаю. "Болтаем" мы преимущественно о работе: кто что прочитал, узнал, ... Браужу инет я тоже не в поисках картинок с фишек (хотя и такое бывает), я ищу интересное по программированию (пусть не для текущей задачи, но это вклад в будущее). Да и банально переключиться на тех же фишках, в разговоре "о погоде", ... от решения проблем. Попил чайку, глядишь, и удачная мысль пришла. Сел ее реализовывать и застрял так, что на час задержался на работе (у меня вчера так было), зато за 2 часа сделал "двухдневную норму". Если мне интересно, я сам выхожу в выходные на работу...
С другой стороны я часто еду в транспорте -- думаю о задаче, моюсь в душе/ложусь спать -- приходит хорошая мысль, ... Т.о. даже если я опоздал на работу, это не значит, что я это время не отработал(-аю)!

С другой стороны наболевший вопрос: "вам шашечки или ехать?", "вам отсиженные 8 часов или выполненные задачи?"?????
Неделю назад я с недоумением посмотрел на коллег из другой комманды, которые как по комманде встали, выключили компы и пошли домой. И только потом заметил, что уже 6,00 и можно домой. Как хорошо, что у нас в текущей команде не так. Когда мне надо -- я ухожу пораньше, когда нужно проекту или я могу еще поработать -- я задерживаюсь на работе.

Был у меня конфликт на почве "отрабатывать 8 часов в день" с буржуйскими заказчиками. Ну и что? После этого я стал отсылать подробнейшие отчеты каждую неделю, а делать даже меньше чем раньше. Потому что отношения испорчены. И хрен они докажут, что я затратил 2 часа на таск, а не 8. Я такую историю придумаю что мне еще доплачивать нужно будет (а задержался на работе потому, что читал книжку, RSDN, писал тестовую прогу, чтобы лучше уяснить прочитанное, ...).
Но это не значит что я рас"%яй. Если я же вижу что сроки поджимают, я сам поджимаюсь. И в итоге в недельных отчетах могу написать даже меньше чем я сделал (нафига их баловать болшим количеством выполенных тасков). Т.о. с разработчиками нужно ДРУЖИТЬ! Вы к ним хорошо относитесь -- они для вас горы свернут. Причем хорошее отношение это далеко не деньги (хотя это тоже важно), это может быть скользящий график, словесное поощрение, да и просто придти в комнату к разработчикам и рассказать хороший анекдот чтобы все посмеялись. Т.е. нужно построить такие отношения, когда подчиненные свободнее себя чувствуют, тогда они сами !по своей инициативе! задержатся на работе в критический момент и вытянут тебя из за..цы (или не допустят чтобы ты туда попал). Не нужно рамок, нужно взаимопонимание, уважение и взаимопомощь! И четкое понимание того, что вы делаете общее дело.

СУВ, Aikin

P.S. Прошу прощения за сумбурное изложение

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

A>Поэтому мои критерии:
A>1) Дубилрование кода
A>2) Покрытие нового кода тестами
A>3) Сложность методов (вложенные ифы, форы, ...)
A>4) В принципе, сюда можно добавить и количество строк кода. С одной стороны много не напишешь -- нужно покрытие тестами, много не скопипастишь,... , а с другой этому критерию можно дать низкий вес.
A>5) Если, не дай бог, кто-то залил некомпилируемый код, либо код ломающий тесты -- нещадно штрафовать (рейтингом, ессессно).
A>6-n) Ваши варианты

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

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

Баловство это чистой воды. Эта балльная оценка не имеет никакого отношения к качеству кода и реальному вкладу программистов. И зачем она тогда нужна? Надо не рейтинги подводить, а реально обеспечить необходимое качество кода и дизайна, в этом задача менеджмента. Что решается вовсе не вашей "позорной доской" или "доской отличников боевой подготовки".

Допустим вы вывели объективную, адекватную, всех устраивающую метрику. Все согласны что чем выше этот показатель, тем человек лучше работает. Вы ее используете, все довольны...

А теперь рассмотрим такую ситуацию: я потритил свое личное времея на помощь коллеге, у которого горели сроки и его таск был очень важен. В итоге он успел сделать его, а я из своего выбился (это было допустимо так как у него "main screen" у меня "пятый слева в третьем ряду экран"). Он получает премию, я получаю шиш.
Внимание, вопрос: а оно мне надо помогать своему коллеге?

Любая оценка отдельных людей будет провоцировать конкурентные отношения в команде. В итоге у вас получится группа индивидуумов каждый из которых "тянет одеяло на себя".
Эффективность, в итоге, будет много ниже чем у Команды людей которые приходят друг к другу на помощь.

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

G>>Могу добавить, что PSP/TSP запрещает даже менеджеру доступ к индивидуальным статистикам.

Их видит только сам исполнитель. Это требование процесса, которое должно реализовываться PSP-тулом.
A>Как-то мой опыт, интуиция протестуют. Но ничего конкретного сказать не могу.

Твой опыт и интуиция протестует против опыта самого Хамфри, а это автор CMM и PSP/TSP

. Который полагается кстати не на интуицию, а на точные методы. Весь PSP/TSP построен на точной статистике с реальных проектов.

G>>Опять же, ты исходишь из того, что данные метрики объективно показывают качество работы программиста. Это не так, и в этом вся проблема.
A>Нет, я считаю что можно подобрать метрики так, что они будут объективно показыать некачественную работу программиста. Т.е. я только за те метрики которые однозначно указывают на изъяны.

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

A>Есть только объективные показатели:
A>1) покрытие 53% (надо 60%),
В какой метрике твои проценты? Ты в курсе, что количество тестов для полного прогона состояний экспоненциально от размера программы зависит? А по метрике LOC 100% покрытие тестами означает только лишь то, что у тебя нет в программе "мертвого" кода, который вообще ни разу не выполнился тестами (наличие которого, кстати, часто является вполне нормальным и неизбежным явлением) и ничего больше?

Я надеюсь, ты понимаешь что данный показатель не соотносится напрямую с ошибками? Ошибка, как правильно говорит Васильев, есть несоответствие требованиям, и ничего больше. И как максимизация данного процента поможет мне эти несоответствия отловить? А? Я как менеджер этим вообще не пользовался, и считаю глупостью полагаться на это как критерий качества. По двум причинам. Первая — твои 60% ровным счетом ничего не говорят о готовности продукта к релизу и его качестве. То есть они вообще никак к этому не относятся. Надежный показатель — процент проходящих use cases, которые отранжированы по критичности. Таким образом я проверяю соответствие продукта ТЗ, и делать мне надо именно это, а не мерять какой-то абстрактный процент. И если у меня все критичные юз-кейсы работают, то я выпущу продукт в релиз, даже если у меня какая-то чертова тулза покажет всего 20% покрытие тестами. Потому что эта тулза понятия не имеет о том, кто и как будет мой продукт применять. Тратить ресурсы на подъем дурацкого покрытия силами программистов, заставляя их выдумывать тесты больше 60% — блин, лучше я потрачу это время на разработку толкового тестплана, который покажет, какие тесты мне реально нужны, и буду контролировать его наличие и соответствие ТЗ. Толку всяко больше.

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

A>2) несоответствие стилю кодирования 6 мест,
Условие прохождения code review, который делается ДО чекина, а не после. Метрику из этого делать смысла нет.

A>3) 3 метода имеют комплисити больше 5,
И что?

У тебя программа хуже работать от этого станет? Разработчики, думаешь будут следить за этой метрикой? А ты проведи опрос на заглавной странице РСДН. Ты вот сам — хорошо, в деталях понимаешь, что показывает метрика complexity, и какой у нее физический смысл? Может, ты ее предсказывать умеешь?

A>4) тест SomeModule.DoThat провалился
Условие успешного закрытия задачи, из этого не надо делать метрику. Смысла нет.

G>>Надо ли вести метрику, кто сколько раз ломает билд? Может быть. Говорит она о том, кто лучший программист? Да в общем, нет. Это исключительно характеристика разгильдяйства или невезучести.
A>Разгильдяю по башке, невезучему не может невезти всегда

Разгильдяю безусловно по башке, о чем я и сказал ниже в том посте.

G>>Весь фокус не в самой метрике, а в процессе вокруг нее. Вот каким образом ты будешь ими пользоваться? А именно — кто, когда, и зачем будет их смотреть?
A>В основном сами программисты будут следить за своими успехами/неуспехами, достоинствами/недостатками.
Ага, щаз. Делать им больше нечего. Им эти твои метрики не нужны, они нужны тебе, и нет ничего, что бы заставило их следить за "успехами и неудачами". Начать стоит с того, что редкий программист будет их связывать со значениями метрик. Опять же, проведи опрос, увидишь кто прав.

A>Тимлид мониторит динамику: прислушиваются ли разработчики к советам робота. Однажды покрытие тестами всей системы упало ниже 50%. В чем причина? Все разработчики не пишут тесты, или кто-то один всех тянет вниз. Как это узнать?

"Однажды покрытие тестами упало ниже 50%". Программисты удалили юнит-тесты?

G>>1) Дубилрование кода
G>>Интересно, как именно ты предлагаешь эту метрику считать.
A>Я знаю что есть тулзы которые считают. Более подробно этот вопрос не исследовал.
Надо хорошо, в деталях, понимать алгоритм рассчета метрик, перед тем как думать, как их применять. У меня вот, скажем, большие сомнения, что эти тулзы способны надежно сосчитать процент креативного копипаста в разрезе людей. А раз так — доверять им и строить на них процесс нельзя.

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

G>>Код работает, ошибок нет — качество в порядке.
A>Неверный вывод. Качество это не только внешняя составлящая. Но еще и внутренняя.

Неверная догадка. "Качество" в управлении разработкой ПО определяется количеством дефектов, которые находят пользователи и тестеры. Это общепринятая терминология, которой тебе лучше следовать, если ты взялся говорить об управлении проектами. Метрика, "характеризующая" качество — это "плотность дефектов" на тысячу строк кода.

A>Недавно из коммандировки я привез приложение изнутри представляюее собой кучу говнокода, а для пользователей это приложение выглядит конфеткой и самое главное -- работает корректно. Но добавить в приложение небольшое изменение представляется проблематичным (1,5 недели у меня занял таск, который при нормальном дизайне отнял бы не больше дня).

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

G>>2) Покрытие нового кода тестами
G>>Технически сложно снять такую метрику. У тебя поменялось 10 файлов, каждый на 10-20 процентов — типичная ситуация для ОО программы. Это легко посчитать по продукту целиком или по подсистеме, но не по отдельному чекину.
A>Тулы проверки покрытия кода считают буквально построчно. Можно посмотреть, например, здесь (обрати внимание на картинку внизу: подсветка отдельных строчек).

За скриншот конечно спасибо, но ты думаешь, я не знаю, что такое test coverage?

Ты привел тул, который дает самую тупую метрику coverage, вообще-то. В строках кода. Есть существенно более продвинутые метрики, которые учитывают разные способы, которыми ты попадаешь в блок кода. Тем более, к вопросу это не относится.

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

G>>Возвращаясь к вопросу кто когда и как — по хорошему надо ставить цель в области качества, и достигать ее. Скажем, покрытие кода по метрике строк кода делаем 100%. И это будет означать ровно одно — что у тебя нет кода, который в принципе ни разу не вызывался. Но это вовсе не говорит тебе о том, что у тебя программа хорошо оттестирована. А в другой метрике достичь 100% практически невозможно, это дорого и бесмысленно.
A>Я не предлагаю панацею, я предлагаю вспомогательный инструмент!!!!!!!!

А инструмент без методики его применения, и конкретной и насущной потребности, которую он решает, никому не нужен!!!!! Ты в курсе?!!!!!!

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

G>>3) Сложность методов (вложенные ифы, форы, ...)
G>>Гхм.

Эта метрика совершенно бесполезна, как и остальные метрики "сложности". Потому, что на ее основании вообще нельзя никаких выводов сделать. Ну "сложный" у тебя метод, ну дальше что?

Если ты реально решил запретить слишком длинные и глубокие методы — вноси это в код стандарт, и контроллируй на code review. Так ты добьешься выполнения правила. А этой метрикой — кто, когда, и как?
G>>Кроме того, можно плохой код десятком способов написать, а по твоей метрике чтобы написать хороший — достаточно нарезать на короткие методы как попало с бессмысленными названиями и все (кстати, именно так и поступит человек, который захочет подняться в твоем рейтинге).
A>По голове во время следующего код ревью.

1) Менеджмент имеет мало общего с битьем по голове и прочим kicking the ass.
2) Код ревью просто-напросто не пропускает код с ошибками в репозиторий, в чем его функция и состоит. Ошибкой считается либо реальный баг, либо несоблюдение кодстандарта и стилевого руководства. Все остальное — не ошибка. И если у меня есть код ревью, то мне не нужна эта твоя метрика. Просто ну совершенно не вперлась. Ну будет у меня в репозитории "плохого" кода.

G>>4) В принципе, сюда можно добавить и количество строк кода. С одной стороны много не напишешь -- нужно покрытие тестами, много не скопипастишь,... , а с другой этому критерию можно дать низкий вес.
G>>И что, чем больше пишем, тем лучше? Я могу одно и тоже в разницей в два раза написать легко, причем одинаковый тест даст то же самое покрытие.
A>Эта метрика выпадает из "нового видения" (см. начало поста)

При этом, эта метрика — единственная, которая реально полезна, из всех, которые ты перечислил. Прикинь?!

G>>>>Надо не рейтинги подводить, а реально обеспечить необходимое качество кода и дизайна, в этом задача менеджмента.
A>>>Как?
G>>Cтавить конкретные цели в области качества (это правда очень сложно), и достигать их посредством code & design review. Серьезно заниматься политикой тестирования.
A>Ок, я только не понимаю почему в эту систему не вписывается автоматическая проверка? Предварительно, как помощь для человеческих методов оценки.

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

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

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

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

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

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

Это имеет также прямое отношение к auftragstaktik, про который я писал недавно. Возьмем процесс для небольшой группы — человек в 6. Когда я привлекаю к работе над архитектурой всю команду, я имею гарантию, что все понимают дух архитектуры, а не букву (настолько, насколько это вообще можно гарантировать, конечно). Поэтому, во-первых, я снижаю требования к объему необходимой документации, а во вторых — сильно снижаю стоимость ошибок и недоговорок в "контрактах". Потому, что люди, понимая общий принцип и дух, во первых с большей вероятностью обнаружат ошибку на раннем этапе, а во вторых — способны сами додумать детали в общем ключе.

А от ошибок в дизайне при таком подходе я закрываюсь перекрестными design review. В данном случае — они 1) будут эффективны, потому что все в теме общей идеи архитектуры, и 2) мне опять же требуется меньше документации. При всем при этом — я получаю качественный результат гораздо быстрее, сведя объем документации к необходимому минимуму.

Что характерно — те же люди и кодируют, каждый свою подсистему, предварительное проектирование которой он выполнял на предыдущем этапе в составе группы. Код контолируется на code review — выполняется теми, кто реализует соседнюю подсистему, интерфейсную с данной. Это, опять же, дает нам сквозную ответственность за результат, и высокую вероятность обнаружения оставшихся ошибок архитектуры дизайна на этапе кодирования. Потому, что люди прекрасно понимают, что они делают, как, и зачем/почему.

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

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

A>>P.S. Прошу прощения за сумбурное изложение

M_E>Это все конечно верно, но не совсем

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

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

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

V_S>Дык, какие позитивные предложения у уважаемого Gaperton'а ?
V_S>Сразу оговорюсь: я знаю, что я могу "сломать" любую метрику. Равно как и легко выдумать систему демотивации. Но это все — негативные действия. "There is a time to break down and a time to build up". (Ecclesiast). В чем build up?

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

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

И просто доброе слово и признание заслуг и успехов перед коллективом или лично очень много для людей значит. Ужасно много. Гораздо больше, чем несчастные 100 баксов. Маленькая премия вообще воспринимается как оскорбление — их не имеет смысла платить. Пример?

У нас в компании ХХХ был самый удачный финансовый год за всю историю. И по этому поводу, руководство решило выплатить премии сотрудникам под новый год. И вот, к одному моему знакомому в декабре 200Х года пришел коллега, улыбаясь, и принес ему конвертик.
(мрачно)
— Что это такое?
(игриво)
— А это подарок от деда мороза!

(мрачно)
— Передай деду морозу, что слово "подарок" пишется с тремя нолями.

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

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

M_E>Но у нас условия таковы, что существует фиксированный фонд оплаты труда, который не особо зависит от результатов деятельности компании.

Предлаю считать строчки кода. Это реально работает

«Чем больше думаешь о прибыльности, тем больше понимаешь, как сильно она зависит от талантливости ключевых персон в организации»

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

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

Товарищи манагеры, как вы со своими "конкурсами", извините, задрали.

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

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

M_E>В литературе упоминается, система мотивации должна быть привязана к целям компании. Но у нас условия таковы, что существует фиксированный фонд оплаты труда, который не особо зависит от результатов деятельности компании. Его, конечно, можно менять, но это достаточно длительный процесс и он не зависит от итогов работы за какой-то период короткий — например, за месяц.

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

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

M_E>Таким образом, вопрос стоит так — по каким объективным характеристикам работы программистов можно осуществлять их поощрение?
M_E>Я рассматривал некоторые варианты — кол-во строк кода, кол-во допущенных ошибок и т.п. — но они показались мне не достаточно эффективными, так как они не способны в полной мере показать результаты усилий и производительность труда.

Ни в коем случае нельзя применять софтверные метрики для рассчета "коэффициентов мотивации". Вы добьетесь недостоверности метрики и ухудшения качества результата. Для KPI надо брать ту метрику, максимизируя которую человек делает пользу. Увеличение количества строк кода — идет во вред а не в пользу. Количество допущенных ошибок — вариант получше, но он не будет стимулировать разработчиков заниматься рискованными задачами. Все эти метрики — плохи, и помимо прочего вредят командообразованию.

M_E>Одним из показателей, которые я счел более-менее приемлемыми для поощрения — это результаты Code Review.
M_E>Т.е. раз в 1-2 месяца у каждого разработчика проводится Code Review "комиссией" из 3-х человек, где оценивается качество кода, комментирование, соответствие стандартам кодирования и пр., код оценивается по различным характеристикам и затем по результатам проверок выдаются небольшие премии.

Тоже плохой вариант. Code review эффективен только тогда, когда он делается часто и регулярно — перед каждым коммитом в репозиторий, а также человеком, который в теме задачи. Кроме того, Code review должен быть перекрестным, а не проводится комиссией избранных. И в третьих, цель code review — находиждение ошибок, а не оценка "качества кода" по абстрактным критериям.

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

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

M_E>Но вы немного подменяете понятния — одно дело — свобода творчества, а
Где я сказал про свободу творчества?

Я говорил про то что нельзя загонять программиста в рамки. Он из них так выйдет, что вам только хуже будет. С ним нужно дружить.
M_E>другое — отлынивание от работы
Уточните, пожалуйста, что вы пониманее под "отлыниванием от работы"?
Я привел примеры когда внешнее безделие оказываетя работой, с другой стороны я могу так запудрить глаза видимостью работы, что мне еще должны будут.

Еще раз: "вам шашечкки или ехать?"

СУВ, Aikin

Вчера, совершенно случайно, при разговоре коллега упомянул как работает сервер интеграции на его прошлой работе. И мне это очень понравилось.

Суть вот в чем. Есть сервер интеграции с системой контроля версий и прочими приблудами для сборки, прогона тестов и снятия метрик.
У этого сервера есть вэб интерфейс, на главной странице которого пишется статистика: какая версия приложения, рабочий код или нет, кто последний закомитил. Но не это самое главное.
Самое главное это: таблица ниже -- рейтинг программистов работающих над кодом.
Рейтинг этот составляется автоматически на основе анализа комитов программеров (какие критерии -- вопрос отдельный, который будет затронут ниже).
Получаем мотивационный фактор -- никто не хочет быть на последнем месте, все стараются делать свою работу лучше. Т.е. соответствовать критериям выставления рейтинга (поэтому рейтинг должен быть комплексный).
Важно чтобы эту оценку делала "бездушная машина" и могла объяснить почему она это так сделала: 10 очков получил за покрытие тестами, 5 за низкую сложность кода (complexity), 20 очков сняли потому, что закомиченный код на 87% копипаст кода Васи... Это нужно для того, чтобы люди знали что им нужно улучшить в своей работе, чтобы добится хорошего результата.

По поводу критериев. Я считаю, что оценивать нужно не количество, а качество. Когда качество всей системы станет высоким добавление новых изменений будет стоить меньше (закон диалектики, епть!). Да и сама цель "качество" более понятна чем "количество" -- почему нужно писать хороший код объяснить легче, чем зачем писать больше -- первое это важно для самого программиста (быть специалистом), а второе важно только для компании компании.

Поэтому мои критерии:
1) Дубилрование кода
2) Покрытие нового кода тестами
3) Сложность методов (вложенные ифы, форы, ...)
4) В принципе, сюда можно добавить и количество строк кода. С одной стороны много не напишешь -- нужно покрытие тестами, много не скопипастишь,... , а с другой этому критерию можно дать низкий вес.
5) Если, не дай бог, кто-то залил некомпилируемый код, либо код ломающий тесты -- нещадно штрафовать (рейтингом, ессессно).
6-n) Ваши варианты

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

Как использовать этот рейтинг: ни в коем случае не наказывать рублем! Поощрять первые места -- да, но никого не наказывать! Программисты в основном народ вменяемый, поэтому отстающему самому не понравится быть всегда на последнем месте. Можно будет попросить человека без проблем с рейтингом помочь тому у кого они есть ... Можно получить статистику с чем в вашей команде основные сложности (написание юнит тестов, сложный код, копипасты) и провести целенаправленое обучение.

Важный момент: пост Минус оценки отдельного разработчика никоем образом не потерял своей актуальности. Поэтому критерии нужно выбирать осторожно, а еще осторожнее нужно использовать статистику по этим критериям. ИМХО, задача выбрать критерии оценки таким образом чтобы хорошим разработчикам соответствовать критериям было не сложно, чтобы у них оставалось желание помогать другим. Т.е. и тут важна мера.

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

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

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

А самые сложные и беспросветные дефекты — переправлял в мою команду, зараза такая

. Колян — если ты это читаешь — привет!

К счастью, у нас в команде было заведено не так. Мы любили сложные дефекты, и умели их исправлять. Хотя, по валовому продукту, конечно, мы были позади планеты всей, but who cares?

M_E>Я думаю можно сделать автоматическую рассылку — чтобы все получали список сотрудников и кол-во задач, которые они закрыли за день или неделю.
Добрый совет. Лучше делай не так. Заведи рассылку check-in, и напиши робота, который будет посылать туда письма при каждом коммите в репозиторий. В письме должен быть комментарий к коммиту, список файлов, ссылка на веб-интерфейс чтобы посмотреть пофайловые диффы. А еще — хорошо если робот посчитает новые/измененные/удаленные/все в сумме строки кода, без пустых, комментариев, и фигурных скобок. Чтоб был виден характер и объем изменений.

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

Совет номер два. Если у тебя идет работа в рамках плана — проводи еженедельные status-meeting. На нем — сравнивай по каждому человеку и по всей группе количество задач по сравнению с запланированным.

Это элементы зрелой системы управления. Комплексные. Дружественные команде.

Здравствуйте, __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. если есть какие-то области в проекте, позволяющие резко поднять профессиональный уровень, то назначить на эти области людей, которым действительно нужно резко поднять профессиональный уровень, и не напрягатся тем, что после поднятия уровня они уйдут в др место

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

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

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

M_E>Не могли бы вы помочь мне сформировать более-менее пригодную систему мотивации?
M_E>Как видите, у нас не вполне проектная деятельность — т.е. у нас нет как таковой сдачи проекта заказчику, после которой можно раздавать бонусы.

M_E>Соответственно, хотелось бы сформировать систему, которая побуждала бы разработчиков работать более эффективно и качественно.

[...]

M_E>В литературе упоминается, система мотивации должна быть привязана к целям компании. Но у нас условия таковы, что существует фиксированный фонд оплаты труда, который не особо зависит от результатов деятельности компании. Его, конечно, можно менять, но это достаточно длительный процесс и он не зависит от итогов работы за какой-то период короткий — например, за месяц.

Иными словами, ты ищешь способ заставить людей работать всё лучше и лучше, но при этом внешние условия меняться никак не будут? Это сон? Или очередной поиск способа найти результат деления x/0?

А, я знаю. Это — вечный двигатель!

Заруби на носу и передай это руководству: должна быть экономически выразимая обратная связь между усилиями разработчиков продукта и теми условиями, в которых они будут жить. Иначе все эти поощрительные системы в виде 3-х копеек после code review и почётного вымпела "самый быстрый Гонсалес" на монитор будут цирком и профанацией. Если руководство это не понимает, то это очень большая проблема. Лучшее, что можно здесь посоветовать — не мешать людям (внимание, читать дословно) минимизировать время, затрачиваемое на работу в рамках времени, допустимого ходом проекта. Например, на подпроект отводится неделя. Управились за пару дней. Ещё три дня — гуляем, рубимся в Counter Strike, читаем форумы, изучаем технологии, переписываем другие куски по своему вкусу, левачим и т.п. Раз зарплата не меняется, то хоть свободное время будет.

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

Я согласен с постингом Gaperton'а 16.06.08 13:18. Система мотивации должна быть завязана на факторы, над которыми программист Вася Пупкин имеет непосредственный контроль, и достижение целей мотивации должно приносить пользу как Васе, так и компании.

Почему ты думаешь, что у вас "не вполне проектная деятельность"? Что-то мешает работу по доработке и сопровождению продукта или по кастомизации его под конкретного заказчика оформить как отдельный проект? Четко сформулировать фичи, которые должны быть введены (достигнуты) в этой итерации ЖЦ, сроки... Выполнили проект в срок, достигли всех поставленных целей — получите денюжку. Плохо, конечно, что вы имеете "фиксированный фонд оплаты труда, который конечно можно менять, но это, скажем так, не происходит автоматически при изменении прибыли компании." Попробуй с этим повоевать... убедить руководство. В противном случае, тебе останется только чисто моральное стимулирование, — типа вымпела "Ударника капиталистического труда", не более...

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

M_E>Уважаемые опытные коллеги, мне необходима ваша помощь в вопросе мотивации разработчиков.

M_E>Большое спасибо!

Буду говорить по себе как по рядовому программеру.
ИМХО, следует каким-то образом создавать дружественную и откровенную атмосферу в коллективе и говорить не только о работе. У меня большинство провалов в продуктивности было связано с личными проблемами (расстался с девушкой, провалил экзамен, и т.д.). Вот допустим такой момент... Ты приходишь со своей code review и начинаешь оценивать мой код, разбрасывать зелёные растения по офису, ставить вентиляторы мне прямо в рожу, говорить о какой-то мифической продуктивности компании (на компанию мне наплевать даже когда я относительно на пике эмоций)... мне откровенно плевать на все это. меня Катя не любит!

В этот момент лучшей мотивацией было-бы, "Слухай, да чихать на эту грёбаную компанию, акции, проекты и т.д., пойдем попьем пивка и поговорим как мужчины а не как роботопрограммеры". Конечно, общение с людьми это сложно. А что ты хотел? Ты манагер, ты обязан делать так чтобы тебя любили а не вводить какие-то книжные нормативы и устои которые все ненавидят.

Вывод: манагер это работа с людьми а не "командой" или "программистами". За это ему и платят такие деньги.

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

M_E>>Я думаю необходимо выразить текущую ситуация в каких-то цифрах, проанализировать их, если это возможно.

Ну хорошо, выразишь ты ситуацию в цифрах. Любых. Неважно, что именно это будет, — хоть, как пишет Геннадий Васильев, "количество нажатий на клавиши, деленное на время, проведенное за компьютером". Дальше — что? Поскольку "реальных рычагов, кроме личного примера и уговоров, нет", могу предсказать реакцию разработчиков: "Начальник? Иди ты на..., начальник!"

Кроме этого, мне кажется, что если у тебя сейчас 17 разработчиков (18.06.08 15:47), то, если ты пытаешься управлять ими всеми сам — это ошибка. Ты просто физически не сможешь эффективно управлять таким количеством подчиненных. Не говоря уж о контроле ("сейчас это на уровне общих наблюдений").

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

M_E>Да, но ведь как-то надо поднимать производительность труда.

А зачем? Какова конечная цель поднятия этой самой мифической "производительности труда"?

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

V_S>>И что? Какой прок от "конкурентных преимуществ компании" конкретно программисту Васе Пупкину?
M_E>В том то и проблема, что сейчас никакого проку. Т.е. как я написал сразу, что мы имеем фиксированный фонд оплаты труда, который конечно можно менять, но это, скажем так, не происходит автоматически при изменении прибыли компании.

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

В общем, трудно посоветовать что-либо конкретное, не зная ничего об обстановке в коллективе...

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

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

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

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

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

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

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

TL>Введи полностью сдельную з/п — или "частично сдельную": часть работы — этих самых ваших "тасков и айтемов" — перебрось в "фонд сдельной оплаты" — кто сделал таск, тот и денежку получил — конкретную денежку за конкретный таск. Если у вас процесс действительно построен на "сильной айтемизации", то такой подход будет прямо мотивировать делать больше "тасков". Будет мотивировать не всех — факт. Если дело выгорит — в смысле общая эффективность процесса повысится и ты сможешь сформировать "боевое действующее ядро", работающее и получающее деньги по этому принципу — от "лишних" потом просто избавишься — или придумаешь для них отдельный метод работы и отдельную систему мотивации, если эти "лишние" таки нужны окажутся.

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

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

V_S>>А для того, чтобы создать экономические условия, стимулирующие эффективный и производительный труд, у тебя сейчас элементарно нет исходных данных, — нет точки отсчета сейчас и "плановой" точки, скажем, через полгода. Разве не так?
M_E>Да, согласен.
M_E>Я думаю необходимо выразить текущую ситуация в каких-то цифрах, проанализировать их, если это возможно.
M_E>Вопрос только в каких.

Цифры получить нетрудно. Вся наука о метриках тебе в помощь. Остаётся неясным, что именно ты хочешь получить из этих цифр.

M_E>Сейчас я могу подсчитать для каждого разработчика количество найденных ошибок, кол-во исправленных ошибок, кол-во выполненных задач, кол-во фейленных задач, кол-во строк C# (SQL не могу). Для тестировщиков могу подсчитать сколько ошибок они нашли, сколько проверили.
M_E>Возможно, этого будет достаточно для начала. Или нет?
M_E>Можно что-то еще?

Можно всё, что хочешь, хоть количество нажатий на клавиши делённое на время, проведённое за компьютером.

M_E>Я, правда, пока не уверен, как на основе этих значений можно сформулировать план на пол года.

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

V_S>>Кстати, отталкиваясь от первого сообщения, совершенно непонятно, есть ли у тебя реальные рычаги воздействия на ситуацию. Читай пост Геннадия Васильева от 18.06.08 20:01 и попытайся пободаться с руководством.
M_E>Вот именно. Никаких сейчас реальных рычагов, кроме личного примера и уговоров, нет.

Смотри, фокус вот в чём. Люди на самом деле работают c приблизительно одинаковым темпом на всём протяжении своей трудовой деятельности. Вариации возможны, но в основном — незначительные и касаются тех, кто только начинает работать, т.е., примерно с опытом 1-3 года. Дальше максимум, который можно выжать — заставить людей отдавать работе больше времени, но здесь тоже пережимать опасно. Соответственно, лучшее, что ты как руководитель проекта можешь сделать, это, разумеется, ни в коем случае не подхлёстывать и прочим образом стимулировать "безошибочный код", а только расставить людей так, чтобы на выходе получился приемлемого качества продукт в приемлемые сроки. То есть, раздать соответствующие обязанности и контролировать их выполнение. Это и называется "организовать процесс". Дальше читай Гапертона, он много и по делу пишет.

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

В догонку пример организации с высокой мотивированностью работников
http://www.e-xecutive.ru/knowledge/announcement/345991/
Выводы делайте сами.

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

A>>P.S. Прошу прощения за сумбурное изложение

M_E>Это все конечно верно, но не совсем

M_E>Но вы немного подменяете понятния — одно дело — свобода творчества, а другое — отлынивание от работы.

Есть один интересный постинг на тему свободы творчества, почитай: Путевой дневник левой сандалеты: Прафутбол и нифутбол — 2: Как именно ему не слабо

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

A>Дальше, почему запуск тестов проводимых автоматически (по сути роботом) мы отделяем от робота который анализирует код? Ведь это тоже анализ кода.
Запуск тестов никоим образом не анализ кода.

A>У него прошито: каждый метод должен иметь покрытие не меньше 60% (число примерное, забитое в настройках число), он это и проверяет.
Я уже говорил, что тестируемые классы должны быть покрыты по максимуму, ближе к 100%, не тестируемые могут быть не покрыты вообще, какой смысл считать покрытие для отдельно взятого комита (в том мифическом случае, в котором мы вообще сможем посчитать "покрытие комита")?

A>Из маленького разгильдяйства часто вырастает большое рас^%@*дяйство.
Это я слышал, когда добивался свободного графика для себя и команды, тошнит от лозунга.
A>А "цена свеч" не так уж и высока.
Хочется увидеть хотя бы проект данной системы с оценкой трудозатарат. Спросите у ребят из JatBrains сколько стоит их система анализа кода.

Z>>Имелись ввиду работы по разработке, внедрению и поддержке самого робота.
Z>> Поддержка понадобится, настройки менять придется постоянно на этапе внедрения, да и позже.
A>Не буду утверждать то, чего не знаю. Но думается мне, что большинство CI серверов либо уже имеют такие плагины, либо предоставляют удобный интерфейс для написания своего.
Еще раз, интеграция робота в CI вообще не рассматривается как задача, по сравнению со всем остальным ей можно пренебречь.

Z>>Имейте ввиду, что каждому новичку придется уживаться не только с VCS, баг и таск трекером, CI сервером и еще какими-то инструментами, но еще и с роботом.
A>И? Ну не будет робота, не получит он от него замечаний. Зато получит во время код ревью. А был бы робот он бы объяснил ему, что и как он делает не так. Что принято в команде. И объяснит получше, чем 30-страничный труд "требования к комитам в команде".
У нас очень простое требование к комитам: законченый таск и зеленые тесты. Можно узнать, что у вас содержит занимательный документ на 30 страниц? Стандарты кодирования? К комиту они не имеют отношения.

Z>>Лишний инструмент должен давать очень хорошие бонусы, чтобы оправдать связаный с ним геморрой.
A>А какие бонусы дает CI, багтрекер, тасктрекер,... для маленького проекта на 5 человек и двух контактных лиц со стороны заказчика по сравнению с "гемороем"... Никаких!
Это даже коментировать не хочется. Это отлаженные и проверенные временем и множеством пользователей инструменты. Какой может быть геморой от их внедрения кроме выделения сервера и установки софта? Доказывать их рациональность не входит в мои планы и тему данной дискуссии.

A>Дело в другом, что все это обычно ставиться на организацию в целом, поэтому расходы по поддержке этих вспомогательных средств с течением времени стремяться к нулю.
Просто идиллия =) Переходим на C# 4.0, и мы долго и бесплатно пилим лексер робота для его поддержки. А если один из проектов лучше делать на F#?

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

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

G>>Cyclomatic complexity — это вообще бредовая метрика по сути свей.

ГВ>Да я в курсе. Это просто для примера, первое, что в голову пришло. ИМХО, вообще единственная метрика, которую имеет смысл пытаться снизить — это те самые LOC. Чем короче программа, тем на самом деле быстрее её можно понять, переколпакировать и выколпаковать. Но это ж настолько очевидно, что и обсуждать нечего.

Кстати. Вот сейчас умный мысль скажу.

Впрямую стимулировать короткие программы весьма затруднительно, по крайней мере не понятно, как это делать. Однако. Есть пара фактов:
1) В среднем разброс в размере LOC для одной и той же задачи укладывается в коридор "вдвое". Это то, что я видел своими глазами на тренингах по PSP/TSP — скажем, 7 человек уложилось в порядка 100 строк, в то время как остальные 13 — в порядка 200 строк. Единичные выбросы не считаем, на то они и выбросы.
2) Опять же, факт, что на предварительное проектирование разные люди тратят разный процент времени решения задачи. При этом, что странно, время решения задачи изменяется от этого процента почти не зависит, по крайней мере если говорить об изолированных задачах средней сложности.

Я подозреваю, что процент времени на предварительное проектирование обратно пропорционален размеру кода, ну может не пропорционален, но должен кореллировать. Отсюда вывод такой — надо стимулировать тратить больше времени на предварительное проектирование. И тогда ты добьешься более компактного кода. Менеджерам — не надо боятся делать фазу проектирования длиннее. Это именно то, что советует Том ДеМарко в Deadline — "кодируйте в последний момент". Правда, Том говорит о 1/6 на кодирование как цель, что, гхм, вызывает у меня некоторое недоверие. Но от себя скажу — не менее трети времени на проектирование, это должно быть must have. Ну, а более 60% мне становится уже как менеджеру закладывать страшновато по любому.

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

M_E>>Я замечаю, что некоторые разработчики не проявляют особо рвения — начинают опаздывать, подолгу пить чай, курить, невнимательно писать код и пр., хотя, я думаю, способны на большее. Не все конечно, но некоторые — да.
A>Да блин, когда уже мэнеджеры поймут, что работа программиста ТВОРЧЕСКАЯ (хорошего программиста)! Соотношение обдумывания и кодирования примерно 70:30 (хотя все зависит от задачи). Кроме того это не копание ямы -- если не с лопатой и не копаешь, то не работаешь.

Кстати, про соотношение обдумывания и кодирования ты не прав. Во-первых, это зависит от разработчика. Во-вторых, время кодирования замерять временем "ввода информации в ЭВМ" некорректно — это тупо скорость печати, надо его замерять вместе с отладкой. В этом случае, раскладка будет у новичков и студентов 5-15% на проектирование, у более опытных парней и девчонок оно дойдет до 30-40%, и этот показатель уже считается хорошим. В целом, чем более опытен разработчик, тем больше времени он тратит на проектирование. Но я думаю, у тебя в среднем меньше 70%. А у других — совершенно точно меньше.

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

Их видит только сам исполнитель. Это требование процесса, которое должно реализовываться PSP-тулом.
A>Как-то мой опыт, интуиция протестуют. Но ничего конкретного сказать не могу.

Я могу. Это называется самоутверждением и поиском методов самоутверждения. Не переживай и не пугайся, это проходит.

Хуже другое, нормальная команда должна быть свободна от того, чтобы её члены пытались самоутвердиться за счёт своих коллег. Ну, там, развесить ярлыки "хуже-лучше", помериться длиной органов и т.п., если это не в шуточном виде, конечно. Скандалить — можно, ругаться — вполне, а вот унижать других равных — ни-ни.

Вот поэтому Хамфри и ввёл запрет на публикацию личных метрик. У нас это, к сожалению, не понимают зачастую ни руководители, ни подчинённые.

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

G>>Я знаю, какие они обычно бывают, потому что мы измеряли фактические цифры работая по PSP/TSP.

A>Так поделись. Или это цифры что даны выше?

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

А вообще — ты легко можешь замерить свои цифры сам программой для замера времени.

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

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

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

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

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

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

ээээ
а на сколько процентов вы хотите поднять производительность?
10? 20? 30? 50? 100?

будем исходить из того, что у вас относительно нормальная среднестатистическая контора
при этом достаточно большая, чтобы отдельные личности не вносили больших погрешностей в статистику
это значит, что реально каждый человек отрабатывает 4-6 часов из 8часового рабочего дня в своем собственном индивидуальном ритме сообразно своим собственным возможностям

как можно увеличить отдачу, не увеличивая и кардинально не меняя штат работников

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

2. уволить откровенных бездельников и заменить их сотрудниками не ниже среднего

3. создать комфортную обстановку на рабочем месте — как именно, я уже описал

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

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

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

Z>Это может стать очень хорошей демотивацией.
Z>

На сложных задачах риск вылететь из срока выше. Следовательно больше получать будут те, кто делает задачи попроще.
Z>

Практически любую недооцененную задачу можно формально сдать к необходимому сроку. Вопрос только в качестве.
Z>

Возникает соблазн уменьшать фактические трудозатраты.
Z>

Да, мне тоже так кажется.
Кроме того, для того, чтобы железно вписаться в план, будет соблазн выдавать заранее завышенные оценки трудозатрат, которые потом будет нетрудно соблюсти.
Хотя, конечно, я контролирую эти оценки, но я не могу на 100% гарантировать, что в них не будет такого завышения.

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

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

В самом деле? Она что, у вас недостаточно высока?

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

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

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

Ну, вообще-то _суть_ и изначальная цель этой "отчетнсти" именно в этом...

"Начальники создают видимость что они в курсе и все под контролем". (к)

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

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

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

M_E>Вообще, интересная мысль. У нас в баг трекинге и так видно, кто сколько сегодня задач закрыл, но только вряд ли кто-то это смотрит.

наверняка смотрят....

M_E>Я думаю можно сделать автоматическую рассылку — чтобы все получали список сотрудников и кол-во задач, которые они закрыли за день или неделю.

В этом случае, надо быть готовым к ответу на следующий вопрос:
"почему при закрытии меньшего числа тасков или объема работ другой сотрудник получает такую же или большую з/п"

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

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

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

TL>Товарищи манагеры, как вы со своими "конкурсами", извините, задрали.

Если слово "конкурс" дискредитировано бездарной организацией этих самых конкурсов, то его можно заменить, например, на слово "соревнование" или "олимпиада" и т.д.

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

Кому-то лень, кому-то деньги нужны, кто-то любит соперничать с другими, кто-то любит тишину и покой... не стоит грести всех под одну гребенку

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

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

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

V_S>А я лезу в базу закрытых тасков за последние N месяцев (лет) и вижу, что сколько такой таск (в среднем) требует времени.
На словах красиво. Дьявол в деталях. Вот с этого момента поподробнее.
1) Какой это "такой" таск? Таски у нас разные — с каким параметром будешь корелляцию по времени сравнивать? Неужто со строками кода?

Поощряем значит, людей писать более размашисто, а те кто думают больше, и пишут меньше = получат от тебя по башке ни за что, когда ты в базу закрытых задач заглянешь?
2) С чего это тебе вообще тебе придет в голову мысль, что я буду делать так? Я ж тебе это говорить не буду, ты об этом не догадаешься.
3) Сделаю так не только я. Так сделает больше половины разработчиков. Стоит тебе ввести _любую_ метрику, и начать за нее премировать, и как ее в течении как раз примерно полугода научатся зашкаливать.

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

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

Зашибись, объективная метрика

. Сам-то задачу как оценивать будешь? Наверное — по своей базе за полгода? Дык, congratulations, у тебя там будет невалидняк, непригодный для планирования, как только ты премировать людей на основе метрик начнешь.

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

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

Разумеется, программист тут не причем — если, конечно, у тебя есть выделенный "архитектор". Только ты попробуй докажи, чей там именно косяк — ты ведь за него штрафовать фактически собрался. Никакая это не "премия" за качество, если она регулярная — это штраф.

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

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

M_E>>Я думаю можно сделать автоматическую рассылку — чтобы все получали список сотрудников и кол-во задач, которые они закрыли за день или неделю.
_D>В этом случае, надо быть готовым к ответу на следующий вопрос:
_D>"почему при закрытии меньшего числа тасков или объема работ другой сотрудник получает такую же или большую з/п"

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

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

G>>В самом деле? Она что, у вас недостаточно высока?

А на объективных показателях общего процесса и бизнеса в целом это "не рвение" как именно сказывается?

Можно придумать гимн, флаг, и по утрам устраивать подъем флага с распеванием гимна хором в торжественной линейке — у нас когда-то в школе было такое...

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

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

ЗЫ: опыт промышленных предприятий того же СССР изучать не пробовал?

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

G>"Рыба не водится в слишком чистом и прозрачном пруду — он должен быть немного поросшим тиной. Также и крестьяне." (Тагакурэ, "сокрытое в листве").

Кстати, это тоже пресловутые "военные методы".

Только на этот раз — японские. Самурайская литература.

Здравствуйте, Aikin, Вы писали:
A>P.S. И на заводе, и в офисе работают те же самые люди. То что одни ходят по цеху (мастера, инженеры, менеджеры, ...), а вторые сидят в за компом (программеры, тимлиды, менеджеры) сути не меняет.

Какой сути?

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

AL>Можно полюбопытствовать, в чем именно уважаемые коллеги видят связь между обсуждаемой темой и тем, что написано в том рассказе про Тойоту?

Если не ошибаюсь, в статье приводится описание результатов практической реализации одного из принципов кайдзена: борьба с муду (с несовершенством).
Предполагаю, что связь может быть выражена так:
внедрение на предприятии принципа "борьбы с муду", предполагает обновление/изменение системы мотивации труда работников предприятия.

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

M_E>Чтобы хотели быстрее и больше работать.

А зачем???

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

TL>Проявить уникальные способности где и как?

В специальным образом выдуманной "олимпиадно-конкурсной" задаче?

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

TL>Имхо, и авторитет и денежка и должны и в конце концов таки и приходят от возможности и умения проявлять себя в практических задачах, которые на решение бизнеса направлены, а не на "возможность проявить уникальные способности".

А разве умение быстро и качественно решать такие практические задачи нельзя считать уникальной способностью сотрудника/команды?

TL>Но если очень хочется — можно ряд задач или вообще "твердые орешки" выделить в специальный раздел, который доступен всем и все могут предлагать решения

об этом я пытался сказать здесь:
http://www.rsdn.ru/forum/message/2988484.1.aspx

TL> — или же, например, создавать команды динамически и работать над решением конкретной задачи и за это решение получать денежку _командой_ — ну и опыт, и авторитет, и возможность проявить способности тоже.

Это реализуется при матричной структуре управления.

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

Если не ошибаюсь, принцип "конкурентной работы" был использован при разработке шестой версии антивируса касперского...

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

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

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

комфортная обстановка нужна тем людям у которых есть какие-то причины помимо денег (вернее конкретной зарплаты, а не денег и карьерного роста вообще) для упорной работы
а отчеты нужны для серой массы, чтобы комфортная обстановка созданная для максимального раскрытия потенциала первых, не расхолаживала серую массу, работающую за конкретную зарплату получаю в конце месяца

Здравствуйте, 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. — нужна была "сторонняя ...мерялка"?

Извините, но это что угодно, только не _команда_. Проверено лучшими собаководами.

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

TL>4) В прицнипе, манагеры сюда могут еще много чего добавить — на то они и манагеры...

Я бы попросил.

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

A>Как использовать этот рейтинг:

Правильный ответ: никак. Хренисометрия — удел детского сада.

Здравствуйте, Michael_E_Smrinov,

не будет ли более эффективным разделить персонал на несколько групп (2-3 группы разработчиков, группа тестеров, группа техподдержки, группа техписателей, etc. — по реалиям организации вашего процесса), назначить/выделить лидов и спрашивать уже с них. А внутри групп — пусть они сами разбираются. Короче, делегируй часть своих полномочий (но не ответственности!).

ГВ>Правильный ответ: никак. Хренисометрия — удел детского сада.
Ок, а если позволить мерять "хрен" самому владельцу "хрена"? Т.е. "за последний месяц он у тебя вырос на 1 см, а за предыдущий укоротился на 0,2, ..."

К каким косякам это может привести?

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

A>По моему личному мнению, этот способ позволяет поднять качество кода на определенный уровень (заложенный в критериях).
A>Еще раз: те кто все делают качественно -- получают свой максимум и не могут подняться выше, те кто чего-то не (до)делают -- знают как поднять свой уровень. Вот где-то такой принцип.
A>В итоге команда должна подняться до одного уровня. После этого изложенный способ викидывается как отработавший и используются другие, более командные методики. В случае если кто-то не тянет (не хочет тянуть), то это сигнал что его стоит подумать о выведении его из команды.

Есть подозрение, что много времени будет уходить на разбирательство, почему вдруг вот этот вполне приличный код вдруг снижает какую-то метрику. Формальное покрытие кода не всегда кореллирует с полезностью данного теста. Уменьшать вложенность ифов и циклов можно довольно зверскими приемами типа:

  switch ((someVar * someVar2 / 3) % 5)
  {
        case 1, 4:
        ...
        break;
        case 2, 3:
        ...
        break;
  }

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

A>Дублирование это всегда зло. Из каких бы "благих намерений" оно не исходило.
A>Еще раз: я не говорю про "нельзя использовать чужой код", я говорю: если хватило ума понять, что Васин код может решить твою проблему -- измени его так (выделив метод, класс, ...), чтобы он так же решал бы и твою. Т.о. обе задачи решены, дублирования нет, код стал только проще.
Из любого правила есть исключения, иногда копипейст алгоритма правильнее его повторного использования просто потому, что похожесть Васиного и твоего алгоритма всеголишь сиюминутное требование которое может изменится в любой момент. Сильно мотивированный данной метрикой программист может наворотить плохоподдерживаемого кода.

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

Вобщем я за то, чтобы для оценки качества кода программист использовал мозг, вместо робота.

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

Приятно было с вами пообщаться

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

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

Cyclomatic complexity — это вообще бредовая метрика по сути свей. Она очень примерно оценивает снизу количество тесткейсов, требующихся для проверки отдельных функций, которые генерятся методом white box. И все. Это самая неинтуитивная метрика, которая не дает корреляций ни с одной другой, поэтому ее нельзя предсказать и она бесполезна. Например, часто после рефакторинга бывает, что количество строк кода сокращается, а cyclomatic complexity увеличивается. Потому, что размашисто написанный линейно-копипастный код с дубликатами имеет низкий cyclomatic complexity.

А полиморфный многовариантный код — наоборот, высокий

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

ГВ>Да я в курсе. Это просто для примера, первое, что в голову пришло. ИМХО, вообще единственная метрика, которую имеет смысл пытаться снизить — это те самые LOC. Чем короче программа, тем на самом деле быстрее её можно понять, переколпакировать и выколпаковать. Но это ж настолько очевидно, что и обсуждать нечего. И самое забавное — как тогда привязывать метрики к "производительности труда"?

Дык. Считать коэффициент LOC/day, как это я описываю в презентации, и делать все, чтобы ни у кого даже тени подозрения не возникло, что это кто-то в принципе может применить для оценки производительности труда. Тогда — эти коэффициенты реально помогут при планировании — конечно при условии что время и объем вообще даст корреляцию на твоих завершенных проектах. Это надо проверить.

Презентация здесь. http://files.rsdn.ru/20496/ISV%20Oracle%20final.pdf

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

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

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

Уважаемые опытные коллеги, мне необходима ваша помощь в вопросе мотивации разработчиков.

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

Не могли бы вы помочь мне сформировать более-менее пригодную систему мотивации?
Как видите, у нас не вполне проектная деятельность — т.е. у нас нет как таковой сдачи проекта заказчику, после которой можно раздавать бонусы.

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

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

Таким образом, вопрос стоит так — по каким объективным характеристикам работы программистов можно осуществлять их поощрение?
Я рассматривал некоторые варианты — кол-во строк кода, кол-во допущенных ошибок и т.п. — но они показались мне не достаточно эффективными, так как они не способны в полной мере показать результаты усилий и производительность труда.

Одним из показателей, которые я счел более-менее приемлемыми для поощрения — это результаты Code Review.
Т.е. раз в 1-2 месяца у каждого разработчика проводится Code Review "комиссией" из 3-х человек, где оценивается качество кода, комментирование, соответствие стандартам кодирования и пр., код оценивается по различным характеристикам и затем по результатам проверок выдаются небольшие премии.

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

Поэтому, я буду очень благодарен за помощь в этом вопросе.

Большое спасибо!

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

1. разрешить "совам" приходить по своему графику сна-бодрствовавния
2. создать условия для отдыха на рабочем месте — выделить помещение под небольшой спортзал — теннисный стол, базовые тренажеры
3. закупить удобные кресла и хорошие мониторы
4. провести перепланировку офиса с разбивкой его на кубиклы для 1-4х человек по желанию самих работников, чтобы каждый получил то, что хочет
5. закупить много вьющейся зелени (чтобы расставить еее по всему офису — не какие то кусты или грошки с цветами, а чтобы все стены были озеленены) и вентиляторов, чтобы вокруг была природная обстановка и легкий ветерок

думаю пункты 1,2, 4 и 5 потребуют вложений не более чем зарплата одного-двух хороших программистов в столице за 1 месяц
если у вас нет даже таких денег, то тогда ситуация безвыходная

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

M_E>Уважаемые опытные коллеги, мне необходима ваша помощь в вопросе мотивации разработчиков.

еще такая вот мысль

6. хорошенько продизайнить офис подручными средствами
— копии хороших старых картин (можно и желательно с голыми женщинами и мужчинами — зависит от полового состава коллектива)
— бумажки с прикольными надписями и картинками — офисный юмор
— всякие прикольные стильные вещи, которые можно поставить на полки илиразвесить по стенам

этосоздают комфортную психологическую обстановку

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

... << RSDN@Home 1.2.0 alpha rev. 775>>

0rc>Предлаю считать строчки кода. Это реально работает

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

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

... << RSDN@Home 1.2.0 alpha rev. 775>>

V_S>А зачем? Какова конечная цель поднятия этой самой мифической "производительности труда"?
Ну тут сразу несколько целей.
1. Чтобы не расхолаживать коллектив. Если разработчики будут работать хуже то удовлетворенность пользователей и клиентов будет снижаться, и в результате компания будет терять свои конкурентные преимущества.
2. Соответственно, чтобы повысить объем выполняемых работ, через это предоставить больше сервиса пользователям и клиентам.

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

M_E>1. Чтобы не расхолаживать коллектив. Если разработчики будут работать хуже то удовлетворенность пользователей и клиентов будет снижаться, и в результате компания будет терять свои конкурентные преимущества.
И что? Какой прок от "конкурентных преимуществ компании" конкретно программисту Васе Пупкину?

M_E>2. Соответственно, чтобы повысить объем выполняемых работ, через это предоставить больше сервиса пользователям и клиентам.
Что-то я сомневаюсь, что "повышение объема выполняемых работ" и "больше сервиса пользователям и клиентам" шибко нужно Васе Пупкину. Типа "работай больше — получай столько же"?

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

V_S>И что? Какой прок от "конкурентных преимуществ компании" конкретно программисту Васе Пупкину?
В том то и проблема, что сейчас никакого проку. Т.е. как я написал сразу, что мы имеем фиксированный фонд оплаты труда, который конечно можно менять, но это, скажем так, не происходит автоматически при изменении прибыли компании.

V_S>Мне кажется, что твоя ошибка в том, что ты пытаешься выстроить некую идеальную систему мотивации, но смотришь на ситуацию с точки зрения довольно абстрактных (для работника) "ценностей компании" — т.е., с точки зрения работодателя. Попробуй изменить взгляд и посмотреть на ситуацию с точки зрения работника: что он должен делать, чтобы больше зарабатывать, и что он реально может из этого сделать? (Любые цели мотивации должны быть — достижимы. Иначе эта мотивация работника не просто заинтересует.)
Да, я полностью с вами согласен, цели должны быть достижимы, понятны, всем известны и желательно каким-то образом измеримы.
Давайте теперь поговорим более конкретно — что для этого лучше?
Т.е. какие цели следует формировать для разработчиков на такой стадии проекта, как это нужно делать, как с этими целями потом работать, т.е. контролировать их достижение?
Я был бы весьма признателен, если бы вы описали свой конкретный опыт — это было бы очень ценно для меня.

... << RSDN@Home 1.2.0 alpha rev. 775>>

V_S>Почему ты думаешь, что у вас "не вполне проектная деятельность"? Что-то мешает работу по доработке и сопровождению продукта или по кастомизации его под конкретного заказчика оформить как отдельный проект? Четко сформулировать фичи, которые должны быть введены (достигнуты) в этой итерации ЖЦ, сроки... Выполнили проект в срок, достигли всех поставленных целей — получите денюжку. Плохо, конечно, что вы имеете "фиксированный фонд оплаты труда, который конечно можно менять, но это, скажем так, не происходит автоматически при изменении прибыли компании." Попробуй с этим повоевать... убедить руководство. В противном случае, тебе останется только чисто моральное стимулирование, — типа вымпела "Ударника капиталистического труда", не более...
В общем-то так оно и есть — действительно, большие доработки я веду по RUP, текущую деятельность — в рамках примерно 1-2 месячных циклов.
Т.е. ты предлагаешь сверять плановые и фактические трудозатраты и поощрять тех программистов, кто уложился в план.
Я все правильно понимаю?

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

M_E>В общем-то так оно и есть — действительно, большие доработки я веду по RUP, текущую деятельность — в рамках примерно 1-2 месячных циклов.
M_E>Т.е. ты предлагаешь сверять плановые и фактические трудозатраты и поощрять тех программистов, кто уложился в план.
M_E>Я все правильно понимаю?

Это может стать очень хорошей демотивацией.

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

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

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

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

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

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

0rc>>Предлаю считать строчки кода. Это реально работает

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

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

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

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

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

«Проблемы меняются от поколения к поколению, но человеческие качества, необходимые для их решения, остаются неизменными со дня С

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

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

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

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

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

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

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

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

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

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

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

Доходило до ругани, типа "чего это ты все айтемы себе забрал! а ну делись давай".

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

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

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

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

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

TL>Товарищи манагеры, как вы со своими "конкурсами", извините, задрали.

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

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

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

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

TL>Товарищи манагеры, как вы со своими "конкурсами", извините, задрали.

Полностью согласен

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

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

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

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

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

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

G>В самом деле? Она что, у вас недостаточно высока?

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

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

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 775>>

A>P.S. Прошу прощения за сумбурное изложение

Это все конечно верно, но не совсем

Но вы немного подменяете понятния — одно дело — свобода творчества, а другое — отлынивание от работы.

... << RSDN@Home 1.2.0 alpha rev. 775>>

_D>В этом случае, надо быть готовым к ответу на следующий вопрос:
_D>"почему при закрытии меньшего числа тасков или объема работ другой сотрудник получает такую же или большую з/п"
Вот здесь полностью согласен — в количестве тасков работу не измеришь.

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

TL>>Товарищи манагеры, как вы со своими "конкурсами", извините, задрали.

_D>Если слово "конкурс" дискредитировано бездарной организацией этих самых конкурсов, то его можно заменить, например, на слово "соревнование" или "олимпиада" и т.д.

Ну и какая разница каким словом "это" назвать?

Суть от этого не изменится: искусственное создание видимости активной деятельности. (к)

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

_D>Кому-то лень, кому-то деньги нужны, кто-то любит соперничать с другими, кто-то любит тишину и покой... не стоит грести всех под одну гребенку

Вот "создание конкурсов, соревнований, олимпиад" и гребет всех под одну гребенку. Скажешь нет?

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

G>>В самом деле? Она что, у вас недостаточно высока?

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

Лучше поговори с ними по человечески, выясни, что у них с мотивацией, попробуй выяснить причину. Замерь климат в команде, посмотри как они относятся друг к другу. Потом думай, и делай выводы.

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

Премии и "взятки" на мотивацию практически не влияют. Это не метод. Мотивация != зарплата и премия. Тем более, если ты награждаешь не того, кто старался (именно от этого идет ощущение "я молодец"), а пытаешься выдумать какой-то формальный критерий. Люди плохо мотивированы — а ты к ним еще более формально относиться хочешь? Программистам нельзя придумать критерий, который, будучи тупо зашкаленным вверх, не испортил бы результат. Выдумай любую метрику, и я покажу, как ее "сломать", и кого на самом деле она поощряет.

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

G>Премии и "взятки" на мотивацию практически не влияют. Это не метод. Мотивация != зарплата и премия. Тем более, если ты награждаешь не того, кто старался (именно от этого идет ощущение "я молодец"), а пытаешься выдумать какой-то формальный критерий. Люди плохо мотивированы — а ты к ним еще более формально относиться хочешь? Программистам нельзя придумать критерий, который, будучи тупо зашкаленным вверх, не испортил бы результат. Выдумай любую метрику, и я покажу, как ее "сломать", и кого на самом деле она поощряет.
Вот именно! Поэтому я и не ищу какую-то универсальную метрику, которая меня спасет.
Я понимаю, что здесь нужен комплексный подход, который будет основываться не только на метриках и не только на премиях.
Собственно, поэтому сюда и пишу.

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

TL>Ну и какая разница каким словом "это" назвать?

А почему в нашей стране не выпускают шампуня под названием "Голова и плечи"?
Потому что звучит простовато и неблагозвучно... "хэд энд шудерс" звучит непонятней и приятней

А суть одна и таже — шампунь

( возможно, этот пример не совсем удачный... )

TL>Вот "создание конкурсов, соревнований, олимпиад" и гребет всех под одну гребенку. Скажешь нет?

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

Однако, идея, доведенная до абсурда, теряет свою привлекательность и эффективность.

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

Дык, какие позитивные предложения у уважаемого Gaperton'а ?
Сразу оговорюсь: я знаю, что я могу "сломать" любую метрику. Равно как и легко выдумать систему демотивации. Но это все — негативные действия. "There is a time to break down and a time to build up". (Ecclesiast). В чем build up?

Затронута важная тема менеджмента.
По этому хотелось бы более подробно обсудить этот вопрос.
Какие наиболее эффективные системы мотивации вы знаете?
Какой подход внедрен в вашей организации?
Вопросы по вашей организации и системе мотивации:
1. Уровень зрелости организации(внедрены ли процессы, ведётся ли сбор метрик, какие KPI используются в организации)?
2. Схема мотивации? Финансовая или финансово-социальная?
3. Как осуществляется привязка мотивации к деятельности организации(к KPI, к общим финансовым результатам)?
4. Используется ли не финансовая мотивация?
5. Уровень вашей удовлетворенности существующей системой?

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

M_E>>Я думаю можно сделать автоматическую рассылку — чтобы все получали список сотрудников и кол-во задач, которые они закрыли за день или неделю.
G>... Заведи рассылку check-in, и напиши робота, который будет посылать туда письма при каждом коммите в репозиторий. В письме должен быть комментарий к коммиту, список файлов, ссылка на веб-интерфейс чтобы посмотреть пофайловые диффы. А еще — хорошо если робот посчитает новые/измененные/удаленные/все в сумме строки кода, без пустых, комментариев, и фигурных скобок. Чтоб был виден характер и объем изменений.

G>... Во-вторых, заинтересованным личностям удобно смотреть диффы. В третьих — им также виден объем изменений, и подсистемы, над которыми идет работа.

Кстати, полезная очень штука была бы в процессах с ежедневными общими билдами: устром сразу же получаешь дайджест кто что менял и в каком объеме — этого здорово не хватало в свое время!

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

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

TL>>Ну и какая разница каким словом "это" назвать?

_D>( возможно, этот пример не совсем удачный... )

Как ни назови — все равно "лучше просто иметь здоровые волосы" (к)

TL>>Вот "создание конкурсов, соревнований, олимпиад" и гребет всех под одну гребенку. Скажешь нет?

_D>Нет, это возможность проявить уникальные способности, повысить авторитет, получить денежку...

Проявить уникальные способности где и как?

В специальным образом выдуманной "олимпиадно-конкурсной" задаче?

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

_D>Однако, идея, доведенная до абсурда, теряет свою привлекательность и эффективность.

Я тебе описал практические аспекты этой "идеи": целенаправленное выдумывание "интересных задач" с целью занять (якобы) отлынивающий коллектив

— ты об идеях практических реализаций своей же "идеи" ничего не писал...

K_A>В догонку пример организации с высокой мотивированностью работников http://www.e-xecutive.ru/knowledge/announcement/345991/
Тем кому лень читать (хотя тоже много получилось

:

истинная причина процветания концерна – в том, что Чед Бакнер формулирует так: «Мы всегда стремимся к большему». И это не просто принцип работы – это образ мыслей компании.

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

Вечные перемены и мысли о том, что еще можно улучшить, вряд ли принесут вам победу над конкурентами в следующем квартале. Они принесут вам победу в следующем десятилетии.

В газетах нередко пишут, что за год на сборочной линии Toyota в Соединенных Штатах внедряются тысячи инноваций. Эта цифра не просто велика, она громадна. Что переменилось в вашем повседневном труде за последние десять лет? Рядовые сотрудники компании Toyota за год вносят десятки изменений в свои ежедневные обязанности.

Погоня за совершенством – не дополнение к основной деятельности и не специальный проект, выходящий за рамки постоянных обязанностей.

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

Проблемы в первую очередь

«Где бы я не работал раньше, мы всегда занимались поиском «серебряной пули» – стремились к глобальным переменам. Я полагал, что если цель достигнута, можно остановиться. Мне нравилось так думать», – рассказывает Вайсман. Он был типичным представителем американской корпоративной культуры и считал, что совещания – не место для разговоров о проблемах и неудачах.

В те дни завод в Джоджтауне возглавлял Фудзио Чо (сегодня он – председатель совета директоров Toyota). Каждую пятницу топ-менеджеры предприятия собирались на совещание. «Поначалу, выступая там, я рассказывал о своих небольших успехах, – вспоминает Вайсман. – Однажды я описал один из наших проектов – тогда мы планировали обнародовать информацию о расширении фабрики. Я говорил очень позитивно, хвастался. Мое выступление длилось две или три минуты, затем я сел. Фудзио удивленно посмотрел на меня и сказал: «Джим-сан, нам известно, что вы хороший менеджер, иначе мы бы не наняли вас. Но, пожалуйста, расскажите о ваших трудностях, и мы сможем решить их вместе».

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

В компании Toyota уверены: вы не можете решить проблемы, пока не признаете факт их существования. Здесь действует презумпция несовершенства. Идеал – это прекрасно, но небольшие перемены к лучшему гораздо более реальны, человеку проще поставить перед собой локальную цель.

Как только вы понимаете, насколько это увлекательно – постоянно стремиться к совершенству, каждое улучшение в отдельности становится неинтересным.

Бесконечность

«Если вы приедете на завод Большой тройки, то увидите там что-то похожее на работу менеджмента Toyota, – говорит Джеффри Ликер, профессор инженерного дела в университете Мичигана, автор книги The Toyota Way, объясняющей многие методы компании. – Но заниматься этой работой будет некая инженерная группа, консалтинговая компания Большой шестерки или кто-то из гуру менеджмента. Не исключено, что они ничуть не хуже специалистов Джорджтауна. Но вот какая штука: такие специалисты превратят весь проект в презентацию, развесят информацию о нем на каждом углу и будут хвалиться большими достижениями. Такое случается каждый год на одном из предприятий Большой тройки. И внимание всей компании будет приковано только к этому».

«Toyota, – продолжает Ликер, – делает то же самое каждый день во всех отделах. Они справляются сами, без помощи приглашенных именитых специалистов».

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

Тому, что ежедневно происходит в Джорджтауне, можно научить и научиться. Но это не цель, ибо цель предполагает точку финиша, а здесь ее нет. Это нельзя применить, потому что это – не список инноваций. Это другое мировоззрение. К нему нельзя потерять интерес, пожать плечами и отступить, как невозможно потерять интерес к своему будущему.

«Людям, которые попадают сюда из других фирм, приходится многому учиться, – рассказывает Джон Шук, преподаватель Университета Мичигана, бывший сотрудник Toyota, известный консультант по использованию идей компании. – Какое-то время такие сотрудники не могут понять, что происходит. Они делают то же, что и все остальные менеджеры Америки – продолжают ставить цели. И даже идут вперед, что-то улучшают… Но неизменно ищут плато. Пока вы ищете плато, все происходящее кажется борьбой. Это трудно. Выхода из подобной ситуации нет».

В Toyota вам придется познакомиться с философией Дзэн. «Как только вы понимаете, что это и есть сам процесс, и искать плато не нужно, вы можете расслабиться. Выполнение работы и улучшение ее качества становятся единым целым, – говорит Шук. – Вот это и означает – приступить к делу».

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

M_E>Уважаемые опытные коллеги, мне необходима ваша помощь в вопросе мотивации разработчиков.

если честно не понял, Вы хотите чтобы быстрее и больше работали, или избавиться от текучки, или поднять зп(доход) программерам (заодно и себе) или Вы просто недавно ПМ, и Вам скучно?

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

TL>

— ты об идеях практических реализаций своей же "идеи" ничего не писал...

Я нигде не писал о выдумывании задач. Рассказать другим как ты решил возникшую проблему в работе может быть интересно и полезно, как рассказчику так и коллегам. Незнакома ситуация, когда один и тот же велосипед изобретают разные разработчики в команде раз за разом? Никогда в чужом коде не замечали, что кто-то сделал то-же самое, что и вы, но лучше/хуже?

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

Я все равно не готов вводить это в таком виде на практике, но вы истолковывали идею совершенно превратно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

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

AL>Можно полюбопытствовать, в чем именно уважаемые коллеги видят связь между обсуждаемой темой и тем, что написано в том рассказе про Тойоту?
Это стеб или действительно непонятно?

P.S. И на заводе, и в офисе работают те же самые люди. То что одни ходят по цеху (мастера, инженеры, менеджеры, ...), а вторые сидят в за компом (программеры, тимлиды, менеджеры) сути не меняет.

AL>Какой сути?
Сути управления этими людьми. Сути мотивации этих людей. Сути создания эффективного производства. Сути...

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

TL>>

— ты об идеях практических реализаций своей же "идеи" ничего не писал...

Z>Я нигде не писал о выдумывании задач. Рассказать другим как ты решил возникшую проблему в работе может быть интересно и полезно, как рассказчику так и коллегам. Незнакома ситуация, когда один и тот же велосипед изобретают разные разработчики в команде раз за разом? Никогда в чужом коде не замечали, что кто-то сделал то-же самое, что и вы, но лучше/хуже?
Z>Премировать за это деньгами может и не обязательно, вполне достаточно одобрения коллег.

Угу. И что бы мы, программеры, без вас, манагеров, делали бы, бедненькие мы...

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

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

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

ЗЫ: рассказывать целенаправленно — да и выспрашивать "ну и расскажи как же ты это сделал?" — чаще не получится в виду не сильно развитого красноречия у "программиста обыкновенного".

Z>Я все равно не готов вводить это в таком виде на практике, но вы истолковывали идею совершенно превратно.

Да нет — просто ты не подал никакой конкретики в плане практики, а "чистую идею" передал вовсе не так, как описал только что...

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

M_E>>>Я думаю можно сделать автоматическую рассылку — чтобы все получали список сотрудников и кол-во задач, которые они закрыли за день или неделю.
G>>... Заведи рассылку check-in, и напиши робота, который будет посылать туда письма при каждом коммите в репозиторий. В письме должен быть комментарий к коммиту, список файлов, ссылка на веб-интерфейс чтобы посмотреть пофайловые диффы. А еще — хорошо если робот посчитает новые/измененные/удаленные/все в сумме строки кода, без пустых, комментариев, и фигурных скобок. Чтоб был виден характер и объем изменений.

G>>... Во-вторых, заинтересованным личностям удобно смотреть диффы. В третьих — им также виден объем изменений, и подсистемы, над которыми идет работа.

TL>Кстати, полезная очень штука была бы в процессах с ежедневными общими билдами: устром сразу же получаешь дайджест кто что менял и в каком объеме — этого здорово не хватало в свое время!

Это очень хорошо делает связка Bamboo + JIRA от Atlassian. Там билд-сервер умеет связывать воедино дефекты-задачи, коммиты, и билды. И все — автоматически. Ты всегда видишь не только какой билд идет, но и работы по каким дефектам туда вошли. И какие изменения были сделаны. Рекомендую, это круто.

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

Да, я думаю надо такое организовать.

G>Совет номер два. Если у тебя идет работа в рамках плана — проводи еженедельные status-meeting. На нем — сравнивай по каждому человеку и по всей группе количество задач по сравнению с запланированным.

Статус-митинги провожу каждую неделю и в принципе примерно это и делаю

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

I>если честно не понял, Вы хотите чтобы быстрее и больше работали, или избавиться от текучки, или поднять зп(доход) программерам (заодно и себе) или Вы просто недавно ПМ, и Вам скучно?
Чтобы хотели быстрее и больше работать.

... << RSDN@Home 1.2.0 alpha rev. 775>>

Здравствуйте, The Lex, Вы писали:
...
TL>Введи полностью сдельную з/п — или "частично сдельную": часть работы — этих самых ваших "тасков и айтемов" — перебрось в "фонд сдельной оплаты" — кто сделал таск, тот и денежку получил — конкретную денежку за конкретный таск. Если у вас процесс действительно построен на "сильной айтемизации", то такой подход будет прямо мотивировать делать больше "тасков". Будет мотивировать не всех — факт. Если дело выгорит — в смысле общая эффективность процесса повысится и ты сможешь сформировать "боевое действующее ядро", работающее и получающее деньги по этому принципу — от "лишних" потом просто избавишься — или придумаешь для них отдельный метод работы и отдельную систему мотивации, если эти "лишние" таки нужны окажутся.
...
У нас примерно так и есть. Только частично премиальная, так как основная часть з/п — оклад. Премии могут доходить до 20-25%. Мне такая система нравится.

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

TL>Угу. И что бы мы, программеры, без вас, манагеров, делали бы, бедненькие мы...

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

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

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

TL>ЗЫ: Гапертон привер хороший метод автоматического доведения приватных решений до "all" — рассылку информации о коммитах с комментариями всем желающим: при такой реализации не быть в курсе об аналогичном решении, только что реализованном соседней бригадой в другом модуле, можно только при явном нежелании это делать. имхо.

Хороше само по себе решение, но врядли сработает по нескольким причинам. Нет нормальных инструментов для просмотра всего этого дела (нужен гибрид сравнимый со студией+решарпер по возможностям навигации и с diff+log+blame от TortoiseSvn, теоретически можно докрутить эклипс какойнибудь, конечно, но это не тривиально). Вторая причина — неравномерность этих самых комитов и несовпадение их с моментами, когда нужно отвлечься от задачи чтобы освежить мозги. На практике есть Trac, в котором все это можно посмотреть, но искать жемчуг в куче кода неудобно и нерационально. Без отсутствия необходимости разбираться в чужом коде большинство программистов пошлют эту задачу далеко на первом непонятном месте (спросить почему так сделано просто постесняются). Никакая рассылка не заменит живого общения с горящими глазами, размахиванием руками и исписанной доской.

TL>ЗЫ: рассказывать целенаправленно — да и выспрашивать "ну и расскажи как же ты это сделал?" — чаще не получится в виду не сильно развитого красноречия у "программиста обыкновенного".

А отсутствие красноречия от того, что мало рассказывал. Объяснить по каким причинам было сделано именно так, должен уметь (или учиться это делать) любой программист.
Очень полезно, понять какую именно проблему ты решаешь и решать именно ее. Чем чище сформулирована задача (не начальником, а самим человеком для себя) тем чище код. Формулировать для себя проблему можно учиться на своих и чужих примерах. Часто коллега, задавая мне вопрос и пытаясь его правильно сформулировать резко замолкает и восклицает: "Все, сам разобрался".

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

AL>Здравствуйте, Aikin, Вы писали:
A>>P.S. И на заводе, и в офисе работают те же самые люди. То что одни ходят по цеху (мастера, инженеры, менеджеры, ...), а вторые сидят в за компом (программеры, тимлиды, менеджеры) сути не меняет.

AL>Какой сути?

Мотивация может выражаться не только в финансовом отношении результата и затрат.
В компании Toyota поставлена цель достичь совершенства и эта цель отлично мотивирует людей, которые этого хотят. Кто улучшил процесс(в статье дан пример копеечного улучшения при сборке машин, вместо разных контейнеров с запчастями применили один, это дало копеечное улучшение результата для одной машины, в масштабах тойота большое) суть в том что человек это внедривший чувствует свой вклад в результат и от этого счастлив. А сама компания дала ему эту возможность.

В Honda есть R&D подразделение, которое часто занимается не машинами. С одной стороны у них нет четкой связи между экономической эффективностью Honda и
R&D но это позволяет добиться более высокой мотивации персонала R&D для достижения глобальных целей, а не копеечных улучшений. Они не занимаются улучшением гаек и болтов, я уверен для этого у них есть схожие с Toyota принципы управления.

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

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

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

TL>Однако айтемов окромя как "изменить название кнопки" такой "команде" реализовывать не удается.

Как показала практика данного проекта твое утверждение как минимум ложно в данном конкретном случае.

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

Ну да, конечно.

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

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

I>>если честно не понял, Вы хотите чтобы быстрее и больше работали, или избавиться от текучки, или поднять зп(доход) программерам (заодно и себе) или Вы просто недавно ПМ, и Вам скучно?
M_E>Чтобы хотели быстрее и больше работать.

такого не бывает. никто не хочет больше и быстрее работать

тем более за деньги. вот когда денег более — менее хватает, тогда можно за интерес. У программистов зарплата средняя по рынку или ниже?

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

K_A>В компании Toyota поставлена цель достичь совершенства и эта цель отлично мотивирует людей, которые этого хотят... суть в том что человек это внедривший чувствует свой вклад в результат и от этого счастлив. А сама компания дала ему эту возможность.

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

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

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

V_S>А зачем???

Ну это я уже выше писал.

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

I>такого не бывает. никто не хочет больше и быстрее работать

тем более за деньги. вот когда денег более — менее хватает, тогда можно за интерес. У программистов зарплата средняя по рынку или ниже?
Средняя.

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

AL>Однако, если вернуться к исходной теме и проблеме, лично мне совершенно не ясно, с какой стати разработчики на фиксированном окладе, работающие в длительных проектах без явных промежуточных итогов (да еще и в нескольких сразу, бывает и такое), будут хотеть стремиться к достижению совершенства компании и к улучшению чего-то в процессе? Я в курсе, как строилась система мотивации на Интел, Эппл, Майкрософт и прочих изначально проектно-ориентированных фирмах, но это не имеет ничего общего с тем, как организуется работа в некоторых отечественных компаниях, представитель одной из которых и завел сей топик.

Я расширил исходную тему до темы мотивации всей компании и организации работ в ней. Мне было более интересно обсудить опыт различных компаний.
Как это может помочь создателю топика:
1. Понимание того, что даже при бюджетной организации труда для мотивации можно использовать не финансовую мотивацию.

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

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

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

K_A>Затронута важная тема менеджмента.
K_A>По этому хотелось бы более подробно обсудить этот вопрос.
K_A>Какие наиболее эффективные системы мотивации вы знаете?
K_A>Какой подход внедрен в вашей организации?
K_A>Вопросы по вашей организации и системе мотивации:
K_A>1. Уровень зрелости организации(внедрены ли процессы, ведётся ли сбор метрик, какие KPI используются в организации)?
K_A>2. Схема мотивации? Финансовая или финансово-социальная?
K_A>3. Как осуществляется привязка мотивации к деятельности организации(к KPI, к общим финансовым результатам)?
K_A>4. Используется ли не финансовая мотивация?
K_A>5. Уровень вашей удовлетворенности существующей системой?

Это достаточно объемные вопросы.
Вы действительно хотите чтобы я их тут расписал?

... << RSDN@Home 1.2.0 alpha rev. 775>>

G>Кстати, про соотношение обдумывания и кодирования ты не прав.
Да я знал что будут вопросы к этим цифрам. Только я ожидал их много раньше

Сразу скажу что эта цифра из головы. И это не более чем мое ощущение. Так что твои цифры вполне могут быть точнее.

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

В принципе, отладка к этому времени тоже относиться.

G>Но я думаю, у тебя в среднем меньше 70%. А у других — совершенно точно меньше.
Не, я не какой-то там особенный

Я совершенно обычный

Кстати, обдумывание можно совместить с кодированием. Используя, например, TDD. В процессе написания тестов ты обдумываешь как будет удобнее использовать твой класс. В итоге двойная польза: классы более приспособлены для использования, ты получил рабочие тесты.

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

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

Вы всерьез считаете, что разработчики включатся в борьбу за "рост прироста функционала", "снижение кол-ва багов на единицу функционала" и т.п., и от этого будут иметь более высокую мотивацию? Что ж, спорить не буду, тем более помню, как лет 8 назад народ сильно вдохновлялся на борьбу с рутиной после прочтения, скажем, какой-нибудь Extreme Programming Explained и т.п. По моему опыту, единственное, что можно сделать в описанных в начале топика условиях, это минимизировать влияние имеющихся демотивирующих факторов и ни в коем разе не вносить новых, каковых в этой теме уже назвали предостаточно. Фиксированный оклад при отсутствии премиальных (или при чисто символических премиальных), кстати, является прекрасным демотиватором, что бы Вы не говорили про "деньги -- это не главное". Но у менеджера среднего звена здесь обычно практически нет рычагов воздействия на ситуацию.

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

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

I>>такого не бывает. никто не хочет больше и быстрее работать

тем более за деньги. вот когда денег более — менее хватает, тогда можно за интерес. У программистов зарплата средняя по рынку или ниже?
M_E>Средняя.
тогда вам реально трудно. чуть перегнете палку они свалят. тем более что работа скучная и не интересная. тут может постаратся немного поднять зарплату? но скорее всего это невозможно. у программистов много доп обязанностей? отчеты, планы, разжевывание своему рук-ву что и как они будут писать? ну итд.
как там с питанием? есть рядом столовка? есть комната для еды\трепа\совещаний?
как там с водой на рабочем месте (чистая \ из крана), чай кофе?

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

M_E>Ну это я уже выше писал.

А я читал.

Обычный набор дежурных фраз, начальственная трескотня (bullshit) — про "конкурентные преимущества", "повышение объема выполняемых работ" и "больше сервиса пользователям и клиентам". Ты можешь четко, ясно и по существу ответить на следующие вопросы:
1. Нафига это нужно тебе лично? Что это дает именно тебе? Допускаются любые ответы по существу, включая "продвижение по службе", "повышение зарплаты", "мой начальник будет доволен" и т.п.
2. Нафига это нужно твоим подчиненным?
3. Что ты можешь предложить своим подчиненным как компенсацию за "повышение объема выполняемых работ" и "больше сервиса пользователям и клиентам"? Ведь нет никаких сомнений, что они будут тратить больше сил/времени/нервов/мозгов... etc. на работу, а что при этом получат взамен? Какова компенсация?

Отвечаю:

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

I>тогда вам реально трудно. чуть перегнете палку они свалят. тем более что работа скучная и не интересная. тут может постаратся немного поднять зарплату? но скорее всего это невозможно. у программистов много доп обязанностей? отчеты, планы, разжевывание своему рук-ву что и как они будут писать? ну итд.
Не особо много. Отчет обычно в виде закрываения багов и задач. Иногда отметка прогресса.
План обычно для них всегда составляю я, иногда вместе с ними — по ситуации.
Как делать обычно для них разжевывает архитектор.

I>как там с питанием? есть рядом столовка? есть комната для еды\трепа\совещаний?
Столовка рядом есть и не одна. Комната для еды\трепа\совещаний тоже есть.

I>как там с водой на рабочем месте (чистая \ из крана), чай кофе?
Всегда горячая вода, чай и кофе.

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

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

AL>Вы всерьез считаете, что разработчики включатся в борьбу за "рост прироста функционала", "снижение кол-ва багов на единицу функционала" и т.п., и от этого будут иметь более высокую мотивацию? Что ж, спорить не буду, тем более помню, как лет 8 назад народ сильно вдохновлялся на борьбу с рутиной после прочтения, скажем, какой-нибудь Extreme Programming Explained и т.п. По моему опыту, единственное, что можно сделать в описанных в начале топика условиях, это минимизировать влияние имеющихся демотивирующих факторов и ни в коем разе не вносить новых, каковых в этой теме уже назвали предостаточно. Фиксированный оклад при отсутствии премиальных (или при чисто символических премиальных), кстати, является прекрасным демотиватором, что бы Вы не говорили про "деньги -- это не главное". Но у менеджера среднего звена здесь обычно практически нет рычагов воздействия на ситуацию.

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

А отговорка нет денег для мотивации я считаю подходит только для малограмотного руководства.

Отвечаю

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

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

А других софтверных контор в нашем городе нет.

V_S>2. Нафига это нужно твоим подчиненным?
Собственно этот вопрос я здесь и обсуждаю. Как сделать так, чтобы им это было нужно.

V_S>3. Что ты можешь предложить своим подчиненным как компенсацию за "повышение объема выполняемых работ" и "больше сервиса пользователям и клиентам"? Ведь нет никаких сомнений, что они будут тратить больше сил/времени/нервов/мозгов... etc. на работу, а что при этом получат взамен? Какова компенсация?
Вот и опять — это тот вопрос, который я пытаюсь здесь решить.

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

K_A>Не согласен. Деньги имеют конечно же важное мотивирующее значение, но они не единственный мотивирующий фактор и это факт. Я точно не помню как называлась одна из ранних теорий мотивации, которая основывалась чисто на финансовых предпосылках, но она потерпела крах. Во первых потому что деньги имеют порог насыщения и для сохранения эффекта необходимо будет вводить очень значительные премии. Во вторых потому что всегда есть потребности в признании и тд, и вот они могут реализовываться через не финансовые варианты мотивации. Задача менеджера среднего звена как раз максимально использовать доступные не финансовые мотиваторы, ну и если есть возможность то и финансовые.

На всякий случай еще раз повторю свою мысль: фиксированный оклад при отсутствии премиальных (или при чисто символических премиальных), кстати, является прекрасным демотиватором. А Вы, пожалуйста, еще раз уточните, с чем именно Вы не согласны.

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

A>В Toyota вам придется познакомиться с философией Дзэн. «Как только вы понимаете, что это и есть сам процесс, и искать плато не нужно, вы можете расслабиться. Выполнение работы и улучшение ее качества становятся единым целым, – говорит Шук. – Вот это и означает – приступить к делу».

проблема заключается в том, что эта философия основана на социальной структуре азиатских обществ
а один из основоплогающих принципов этих обществ гласит:

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

это глубоко чуждо европейскому и тем более американскому стандарту мышления

понятно, что Россия далеко не западная страна
но далеко не всем в компании такой принцип понравится

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

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

M_E>Отвечаю:
I>>как там с водой на рабочем месте (чистая \ из крана), чай кофе?
M_E>Всегда горячая вода, чай и кофе.
блин. полумеры не помогли

еще такой вопрос — на что чаще всего за пивом жалуются программеры? или просто когда запарка — о чем вспоминают чаще всего о плохом?
некоторых вот напрягает к примеру плохой инет, бумагу брать по расписке

еще какие то мелочи, которые по штучно не важны. но бесят. но это так — больше к удержанию команды. а вот чтоб работали больше...

есть ли шанс — сделать версионную разработку? в каждый выпуск версии включить список багов на устранение + новый фунционал. Сделали вовремя — премия, сделали раньше премия*1,5, сделали позже. ничего не получили. (но если позже — получите и вы

)

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

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

A>>В Toyota вам придется познакомиться с философией Дзэн. «Как только вы понимаете, что это и есть сам процесс, и искать плато не нужно, вы можете расслабиться. Выполнение работы и улучшение ее качества становятся единым целым, – говорит Шук. – Вот это и означает – приступить к делу».

___>проблема заключается в том, что эта философия основана на социальной структуре азиатских обществ

На территории завода компании Toyota в американском Джорджтауне есть покрасочный цех.

Это америка, в статье рассмотрены американские заводы.

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

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

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

A>>>В Toyota вам придется познакомиться с философией Дзэн. «Как только вы понимаете, что это и есть сам процесс, и искать плато не нужно, вы можете расслабиться. Выполнение работы и улучшение ее качества становятся единым целым, – говорит Шук. – Вот это и означает – приступить к делу».

___>>проблема заключается в том, что эта философия основана на социальной структуре азиатских обществ
A>

На территории завода компании Toyota в американском Джорджтауне есть покрасочный цех.

A>Это америка, в статье рассмотрены американские заводы.

я не о заводах
я о философии
и о ее применимости к управлению людьми выросшими в др культуре

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

A>Вчера, совершенно случайно, при разговоре коллега упомянул как работает сервер интеграции на его прошлой работе. И мне это очень понравилось.

Да, мне тоже такая идея очень понравилась, если честно.
А чем они пользовались?

... << RSDN@Home 1.2.0 alpha rev. 775>>

M_E>А чем они пользовались?
Спросил: Maven все делают плагины:

reporting:
clover 2.4 Generate a Clover report. NOTE: Moved to Atlassian.com // покрытие тестами
checkstyle 2.1 Generate a checkstyle report.
...

Еще оказалось, что он абсолютно бесплатен.

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

Несогласен с этим. Все зависит от способностей конкретного менеджера, как это преподнести и какое обоснование всего этого он сможет найти.
>>Вы всерьез считаете, что разработчики включатся в борьбу за "рост прироста функционала", "снижение кол-ва багов на единицу функционала" и т.п., и от >>этого будут иметь более высокую мотивацию? Что ж, спорить не буду, тем более помню, как лет 8 назад народ сильно вдохновлялся на борьбу с рутиной >>после прочтения, скажем, какой-нибудь Extreme Programming Explained и т.п.

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

K_A>Несогласен с этим. Все зависит от способностей конкретного менеджера, как это преподнести и какое обоснование всего этого он сможет найти.
>>>Вы всерьез считаете, что разработчики включатся в борьбу за "рост прироста функционала", "снижение кол-ва багов на единицу функционала" и т.п., и от >>этого будут иметь более высокую мотивацию? Что ж, спорить не буду, тем более помню, как лет 8 назад народ сильно вдохновлялся на борьбу с рутиной >>после прочтения, скажем, какой-нибудь Extreme Programming Explained и т.п.

Извините, но в цитируемом Вами моем тексте вообще нет каких-либо утверждений, поэтому подозреваю, что не согласны Вы все-таки с чем-то другим (или с кем-то)

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

Здравствуйте, Michael_E_Smrinov,

Так. Отлично! Удалось получить конкретный и четкий ответ. Наконец-то (после двух дней дискуссий) мы стали продвигаться в правильном направлении. Ну почему все это нужно из тебя клещами вытягивать под пытками?

Теперь следующая группа вопросов:
Вот ты пишешь, (16.06.08 14:48) что "как-то надо поднимать производительность труда". Ты считаешь текущую производительность низкой? Как ты ее измерил? За какой период? Каков разброс данных и доверительный интервал полученной тобою цифры? Какую цифру производительности ты считал бы "нормальной"? А "высокой"? Откуда взяты эти цифры? Чем обоснованы?

На самом деле, ответы на эти вопросы — ключевые в твоей деятельности. Это — определение цели деятельности и критериев ее достижения. Только потом можно разрабатывать и обсуждать способых достижения. "Ни один ветер не будет попутным для корабля, не знающего, куда ему плыть." (Луций Анней Сенека)

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

M_E>>А чем они пользовались?
A>Спросил: Maven все делают плагины:

А вы не в курсе случайно, есть ли что-либо похожее, чтобы было заточено не только под Java?

e_k>А вы не в курсе случайно, есть ли что-либо похожее, чтобы было заточено не только под Java?
Мопед не мой

Я просто делюсь тем что вчера услышал

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

e_k>>А вы не в курсе случайно, есть ли что-либо похожее, чтобы было заточено не только под Java?
A>Мопед не мой

Я просто делюсь тем что вчера услышал

А можно попробовать узнать там же про другие мопеды?

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

0rc>>Предлаю считать строчки кода. Это реально работает

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

а как на счет: 1/"ко-во строк кода"?

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

G>>Кстати, про соотношение обдумывания и кодирования ты не прав.
A>Да я знал что будут вопросы к этим цифрам. Только я ожидал их много раньше

A>Сразу скажу что эта цифра из головы. И это не более чем мое ощущение. Так что твои цифры вполне могут быть точнее.

Так у меня к этим цифрам нет вопросов

. Я знаю, какие они обычно бывают, потому что мы измеряли фактические цифры работая по PSP/TSP.

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

TL>>4) В прицнипе, манагеры сюда могут еще много чего добавить — на то они и манагеры...

G>Я бы попросил.

Типа, а хороших манагеров назовем "лидами"...

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

TL>>>4) В прицнипе, манагеры сюда могут еще много чего добавить — на то они и манагеры...

G>>Я бы попросил.

TL>Типа, а хороших манагеров назовем "лидами"...

Хороших манагеров назовём номинально: руководителями. Зачем на хороших людей нехорошие эпитеты вешать?

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

V_S>Вот ты пишешь, (16.06.08 14:48) что "как-то надо поднимать производительность труда". Ты считаешь текущую производительность низкой? Как ты ее измерил? За какой период? Каков разброс данных и доверительный интервал полученной тобою цифры? Какую цифру производительности ты считал бы "нормальной"? А "высокой"? Откуда взяты эти цифры? Чем обоснованы?

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

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

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

V_S>На самом деле, ответы на эти вопросы — ключевые в твоей деятельности. Это — определение цели деятельности и критериев ее достижения. Только потом можно разрабатывать и обсуждать способых достижения. "Ни один ветер не будет попутным для корабля, не знающего, куда ему плыть." (Луций Анней Сенека)
Здесь я с тобой согласен, да.
Как думаешь, как их, эти цели, можно более-менее формально сформулировать?

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

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

Значит, таков стиль их работы. Будет чуть больше работы тестерам — ничего страшного. Значит, эти члены команды работают, в конечном итоге, медленнее других.

M_E>Но проблема не в том, чтобы тех, кто любит похалявить, призвать к ответу. Я бы хотел сделать так, чтобы у них не было такого желания — похалявить, а было желание поработать.

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

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

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

M_E>>Но проблема не в том, чтобы тех, кто любит похалявить, призвать к ответу. Я бы хотел сделать так, чтобы у них не было такого желания — похалявить, а было желание поработать.

ГВ>Это невозможно. Немедленно заканчивай даже думать о подобных вещах, пока у тебя не случилось жестокого разочарования в людях.

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

то есть то, автор вопроса хочет, добиться в принципе можно, но нужно тщательно подбирать коллектив по менталитету

крайности в принципе две
1. набрать "роботов" и двигаться по японской модели
2. набрать "американцев" и "европейцев", для которых труд является ценностью, и которые понимают смысл выражения "радость труда"

во всех остальных случаях народ будет халтурить

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

M_E> Я бы хотел сделать так, чтобы у них не было такого желания — похалявить, а было желание поработать.

Уфф! Сними розовые очки. Welcome to the real world, fellow!
Либо ты их поставишь в такие экономические условия, которые неизбежно вызовут у них желание поработать, чтобы заработать. Либо — никак. Ну посуди сам — нафига зря напрягаться, если зарплата все равно одна и та же? А ФОТ у вас фиксированный и не меняется — 16.06.08 12:40.

А для того, чтобы создать экономические условия, стимулирующие эффективный и производительный труд, у тебя сейчас элементарно нет исходных данных, — нет точки отсчета сейчас и "плановой" точки, скажем, через полгода. Разве не так?
Кстати, отталкиваясь от первого сообщения, совершенно непонятно, есть ли у тебя реальные рычаги воздействия на ситуацию. Читай пост Геннадия Васильева от 18.06.08 20:01 и попытайся пободаться с руководством.

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

V_S>Уфф! Сними розовые очки. Welcome to the real world, fellow!
V_S>Либо ты их поставишь в такие экономические условия, которые неизбежно вызовут у них желание поработать, чтобы заработать. Либо — никак. Ну посуди сам — нафига зря напрягаться, если зарплата все равно одна и та же? А ФОТ у вас фиксированный и не меняется — 16.06.08 12:40.
Да, все так. В этом-то и проблема.

V_S>А для того, чтобы создать экономические условия, стимулирующие эффективный и производительный труд, у тебя сейчас элементарно нет исходных данных, — нет точки отсчета сейчас и "плановой" точки, скажем, через полгода. Разве не так?
Да, согласен.
Я думаю необходимо выразить текущую ситуация в каких-то цифрах, проанализировать их, если это возможно.
Вопрос только в каких.
Сейчас я могу подсчитать для каждого разработчика количество найденных ошибок, кол-во исправленных ошибок, кол-во выполненных задач, кол-во фейленных задач, кол-во строк C# (SQL не могу). Для тестировщиков могу подсчитать сколько ошибок они нашли, сколько проверили.
Возможно, этого будет достаточно для начала. Или нет?
Можно что-то еще?

Я, правда, пока не уверен, как на основе этих значений можно сформулировать план на пол года.

V_S>Кстати, отталкиваясь от первого сообщения, совершенно непонятно, есть ли у тебя реальные рычаги воздействия на ситуацию. Читай пост Геннадия Васильева от 18.06.08 20:01 и попытайся пободаться с руководством.
Вот именно. Никаких сейчас реальных рычагов, кроме личного примера и уговоров, нет.

... << RSDN@Home 1.2.0 alpha rev. 775>>

> Смотри, фокус вот в чём. Люди на самом деле работают c приблизительно одинаковым темпом на всём протяжении своей трудовой деятельности. Вариации возможны, но в основном — незначительные и касаются тех, кто только начинает работать, т.е., примерно с опытом 1-3 года.

Сам-то понял что сказал?

Posted via RSDN NNTP Server 2.1 beta

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

>> Смотри, фокус вот в чём. Люди на самом деле работают c приблизительно одинаковым темпом на всём протяжении своей трудовой деятельности. Вариации возможны, но в основном — незначительные и касаются тех, кто только начинает работать, т.е., примерно с опытом 1-3 года.

G>Сам-то понял что сказал?

Да, неточно выразился. Я имею в виду примерно следующее.

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

Естественно, если сама задача и средства её решения хорошо знакомы, то темп будет примерно одинаковым.

2. Изменения в этом показатели возможны пока специалист ещё "начинающий". Здесь, думаю, понятно — он чего-то боится, чего-то не знает, где-то регулярно и где-то долго думает, и т.п.

> 1. Зрелый специалист работает с приблизительно одинаковым темпом после своего, условно говоря, "становления". Под словом "темп" я имею в виду некую линейную характеристику, например, число строк или число ошибок за период времени. Здесь, конечно, будет разброс в зависимости от сложности задачи.
>
> Естественно, если сама задача и средства её решения хорошо знакомы, то темп будет примерно одинаковым.

Нда? Странно... Таких примеров практически не встречал.

Posted via RSDN NNTP Server 2.1 beta

V_S>Кроме этого, мне кажется, что если у тебя сейчас 17 разработчиков (18.06.08 15:47), то, если ты пытаешься управлять ими всеми сам — это ошибка. Ты просто физически не сможешь эффективно управлять таким количеством подчиненных. Не говоря уж о контроле ("сейчас это на уровне общих наблюдений").
Нет, у меня 17 человек, но из них только 8 непосредственно разработчиков — остальные тестировщики, тех. саппорт и пр.
А так — да, конечно, 17-тью невозможно самому управлять.

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

G>Нда? Странно... Таких примеров практически не встречал.

Я знаю, что звучит это странно. Честно говоря, когда измерил — сам удивился. Ради интереса попробуй сам сделать такие же замеры (скажем — KLOC/Day на интервале в неделю, а лучше — месяц).

> G>Нда? Странно... Таких примеров практически не встречал.
>
> Я знаю, что звучит это странно. Честно говоря, когда измерил — сам удивился. Ради интереса попробуй сам сделать такие же замеры (скажем — KLOC/Day на интервале в неделю, а лучше — месяц).

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

Posted via RSDN NNTP Server 2.1 beta

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

>> Я знаю, что звучит это странно. Честно говоря, когда измерил — сам удивился. Ради интереса попробуй сам сделать такие же замеры (скажем — KLOC/Day на интервале в неделю, а лучше — месяц).
G>А ну тогда понятно откуда такое неверное представление. Замерил за неделю — не изменилось, ...

Я оговорился. Не "на интервале", а "с интервалом".

G>...теперь в полной уверенности, что до конца жизни программист будет с такой производительностью работать. И вроде бы как исчезает необходимость темплейты учить или методики разрабатывать.

Это-то здесь при чём? Темплейты не так уж и влияют на LOC/Day.

G>И у вас задачи разве не требуют каких-то мыслительных усилий? Разве не бывает так, что не можешь чего-то придумать с первого раза или проработать алгоритм качественно?

Человек же не всё время только и делает, что выдумывает шаблонные конструкции и глубоко продумывает алгоритмы, правильно? Он их ещё отлаживает, время от времени пишет документацию, где-то пишет код попроще, и т.п. Потому и метрики снимаются с некоторым интервалом.

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

G>Добрый совет. Лучше делай не так. Заведи рассылку check-in, и напиши робота, который будет посылать туда письма при каждом коммите в репозиторий. В письме должен быть комментарий к коммиту, список файлов, ссылка на веб-интерфейс чтобы посмотреть пофайловые диффы. А еще — хорошо если робот посчитает новые/измененные/удаленные/все в сумме строки кода, без пустых, комментариев, и фигурных скобок. Чтоб был виден характер и объем изменений.

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

Вот этот совет мне очень понравился. Надо будет так и сделать.

... << RSDN@Home 1.2.0 alpha rev. 775>>

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

ГВ>Я знаю, что звучит это странно. Честно говоря, когда измерил — сам удивился. Ради интереса попробуй сам сделать такие же замеры (скажем — KLOC/Day на интервале в неделю, а лучше — месяц).

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

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

ГВ>>Я знаю, что звучит это странно. Честно говоря, когда измерил — сам удивился. Ради интереса попробуй сам сделать такие же замеры (скажем — KLOC/Day на интервале в неделю, а лучше — месяц).

FR>Если брать большие временые промежутки месяц и больше то да есть некое среднее, но на малых колебания на порядки, я например бывает свою среднюю дневную норму могу и за пару часов сделать, а бывает и за неделю

Да, как раз об этом и речь. На малых промежутках колебания могут быть +/- бесконечность. Константа появляется на больших интервалах.

G>Я знаю, какие они обычно бывают, потому что мы измеряли фактические цифры работая по PSP/TSP.

Так поделись. Или это цифры что даны выше?

Извиняюсь что долго не отвечал -- вермени было мало, а тут нельзя ответить быстро.

A>>Получаем мотивационный фактор -- никто не хочет быть на последнем месте, все стараются делать свою работу лучше. Т.е. соответствовать критериям выставления рейтинга (поэтому рейтинг должен быть комплексный).
TL>Ну, мотивационным фактором это будет в первую очередь "для хвоста" и "для головы"
Я общался с непосредственным участником эксперимента, который довольно неплохо отзывался об этом методе.

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

A>>Важно чтобы эту оценку делала "бездушная машина" и могла объяснить почему она это так сделала: 10 очков получил за покрытие тестами, 5 за низкую сложность кода (complexity), 20 очков сняли потому, что закомиченный код на 87% копипаст кода Васи... Это нужно для того, чтобы люди знали что им нужно улучшить в своей работе, чтобы добится хорошего результата.
TL>... тем более что чаще всего большее количество этих "автоматических критериев" выбирается менеджерами и обратно таки "лично-ориентированы", а не "системно-ориентированы".
Мы говорим про критерии которые я предложил или про критерии вообще? В том то и дело что нужно выбирать "системно-ориентированые" критерии -- общие характиристики кода.

TL>С точки зрения "личной мотивации" — таки да, предполагается что типа нехорошо коммитить решение, скопипастеное у Васи, потому как получается "меньший личностный вклад" — а вот с точки зрения системы как раз _правильно_ комитить именно _едиообразное_ решение, дабы не плодить в коде может и "один лучше другого", но, тем ни менее, "зоопарк".
Это был пример, и в качестве "Васи" мог бы выступать тот же самый программер, т.е. "скопипастил у себя". Источник совершенно не важен, важен сам факт дублирования кода, так как оно увеличивает сложность системы.

TL>Правильным решением было бы передать решение участка "на 87% васиного кода" самому Васе, ибо он над этим кодом как миниму думал и наверняка сможет даже более лучшее решение найти быстрее, а заодно и внедрить то же самое улучшенное решение и в свой более старый код — но это, конечно, идеал, и никакой "Вася" при "лично-рейтинговом" подходе к оценке его работы таки заниматься не захочет.

Правильным решением было бы выделить "васин код" в отдельный метод, класс, ... и вызывать из двух разных мест: моего и "васиного".

TL>1) Дублирование кода само по себе без рефакторинга не решается —
Вот, вот! Раз видишь, что "Васин код" может решить твою задачу -- рефакторь его, чтобы ты мог использовать его для решения своей!
TL>пусть лучше будет легко-отслеживаемое дублирования с возможностью дальнейшего нахождения аналогичных участков и вынесения их в обобщение, чем вагон велосипедов, в стремлении "ни в коем случае не скопипастить чужое".
Дублирование это всегда зло. Из каких бы "благих намерений" оно не исходило.
Еще раз: я не говорю про "нельзя использовать чужой код", я говорю: если хватило ума понять, что Васин код может решить твою проблему -- измени его так (выделив метод, класс, ...), чтобы он так же решал бы и твою. Т.о. обе задачи решены, дублирования нет, код стал только проще.
TL>А вообще при подходе "все разжевано архитекторами — над кодом трудится бригада (обезьянок-)кодеров" совершенно непонятно, откуда оное вообще берется — архитекторы чего-то недосмотрели ага?

Откуда вообще взялись архитекторы?

TL>2) Это, конечно, правильно — увы, далеко не всегда реализуемо на практике. Ну и потом грамотное покрытие с должной эффективностью способен сделать грамотный QA Eng. —
QA Eng. -- это потом, это у них будет 100% покрытие тестами и тыды, я говорю про юнит-тесты -- тесты которые пишут разработчики.
TL>у девелоперов, а тем более кодеров, чаще получается именно (1) — "просто дублирование пришедших в голову вариантов".
Пусть даже так, но "хреновые тесты" в любом случае лучше их отстутствия. Хотя бы тем, что люди их пишут (начали писать), а это шаг в правильном направлении.
TL>А так вообще тест-кейзы должны быть заданы еще архитекторами — в идеале...

LowLevel архитекторов в сад
Дедикэйтед архитекторы нужны только для синхронизации действий отдельных команд, т.е. они должны разрабатывать только HighLevel архитектуру.

TL>3) Это в целом просто смешно. Без коментариев.
Ну тогда придеться мне прокомментировать.
Сложные длинные методы с большой вложенностью -- это всегда плохо: плохо понимаются, плохо сопровождается, плохо тестируется, плохо расширяются, плохо...
Длинные методы с большой вложенностью всегда выполняют больше одной обязанности.
Длинные методы с большой вложенностью необходимо снабжать комментариями объясняющими что делает этот кусок кода, а что это.
Длинные методы с большой вложенностью всегда можно разбить на несколько мелких с говорящими именами, упростив тем самым понимание кода.

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

TL>ЗЫ: интересно, а зачем тогда вообще "делать билд", "заливать код", "писать тесты", если потом святым трепетом бояться все это поломать?

А затем, что у человека элементарно голова должна быть на плечах. Он элементарно должен а) взять из репозитория последние изменения, б) скомпилировать код, в) прогнать все тесты.
Если он это не делает, то о каком качестве и дисциплине может идти речь?

Если же он поломал код или тесты, которые ему недоступны (код и тесты другой команды), то:
Какого он вообще полез в публичный интерфейс их куска, изменил методы, сигнатуры, классы без команды архитектора (high-level)?
Какого он не объявил старый интерфейс Deprecated и Obsolete, чтобы дать возможность другим командам отреагировать на изменения?
....

TL>Лично я с трудом представляю себе "команду", в которой отдельные ее представители и вся команда в целом плохо представляет себе реальный вклад каждого в отдельности в общее дело и для "показания оного" нужны все эти "рейтингомерялки".

Извините, но это что угодно, только не _команда_. Проверено лучшими собаководами.

Да, да, да. Только никто не говорит, что у нас уже есть команда! Команду еще нужно создать.

А даже если у нас уже есть Команда, что мешает провайдить не рейтинг, а общее состояние системы: общий процент дублирования, общее покрытие тестами, общая сложность системы, общее...?

СУВ, Aikin.

G>Угу. Понятно, в каком направлении развивалась бы ваша мысль, если вас сделать менеджером.

Не, тьфу-тьфу-тьфу. Я себя организовать не могу, не то что других

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

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

G>Публикации подлежат только агрегатные средние метрики команд.
Чисто на правах идеи: а что если вывешивать только агрегатные метрики, а характиристики отдельного комита отсылать только самому программисту, чтобы он мог посмотреть что он сделал не так (или так), что ему нужно улучшить в своей работе... Хранить эту статистику в приватном месте, для последующего анализа менеджером, чтобы на основе их принимать решения об обучении команды, решения о выведении человека из команды, ...

G>Баловство это чистой воды. Эта балльная оценка не имеет никакого отношения к качеству кода и реальному вкладу программистов. И зачем она тогда нужна?
Прошу пояснить.

G>Надо не рейтинги подводить, а реально обеспечить необходимое качество кода и дизайна, в этом задача менеджмента.
Как?

G>Что решается вовсе не вашей "позорной доской" или "доской отличников боевой подготовки".
Позорную доску в топку, я это уже понял, спасибо.

FR>У нас похоже эта философия плохо приживается http://www.autonews.ru/autobusiness/news.shtml?2008/06/23/1372071
Как я понял из статьи, в Питере слишком много заводов, рабочим есть куда идти -- вот они и идут. Причем на той же Тойоте "настоящее время... текучка кадров ... составляет менее 2%". Так что, ИМХО, все еще устаканиться.

Больше всего мне не понравилось мнение российских экспертов: "дайте им больше денег и будет все хорошо". Других предложений нет.
Я конечно понимаю, что сравнивать программеров с рабочими на конвейере не стоит -- программеры (хорошие) любят свою работу, но все же: неужели у нас (СНГ) единственный стимул -- деньги?

V_S>Короче, делегируй часть своих полномочий (но не ответственности!).
А "выделенное" еще почему?
Естественно, что перед вышестоящим начальством отвечать придеться ему лично. Но что мешает доверять членам своей команды и полагаться на их слово? Все перепроверить все равно не получиться.
Например, если я говорю своему тимлиду, что я сделал/сделаю к/нужно дополнительное время/.. для задачи он мне верит, а не перепроверяет мои слова.

Здравствуйте, Aikin,

разве я где-нибудь писал о недоверии и многократных перепроверках? Своим людям (каждому! члену своей команды) нужно доверять! Что, конечно же, не снимает с лида/пиэма ответственности принимаемые решения и за успех проекта в целом, — не только перед начальством, заказчиками и т.п., но и перед своей командой — в первую очередь. Ибо успешно завершенный проект "цементирует" команду гораздо лучше как бы team-building'овых совместных посиделок с пивом. (Впрочем, одно не исключает другое

)

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

G>>Публикации подлежат только агрегатные средние метрики команд.
A>Чисто на правах идеи: а что если вывешивать только агрегатные метрики, а характиристики отдельного комита отсылать только самому программисту, чтобы он мог посмотреть что он сделал не так (или так), что ему нужно улучшить в своей работе... Хранить эту статистику в приватном месте, для последующего анализа менеджером, чтобы на основе их принимать решения об обучении команды, решения о выведении человека из команды, ...

Могу добавить, что PSP/TSP запрещает даже менеджеру доступ к индивидуальным статистикам.

Их видит только сам исполнитель. Это требование процесса, которое должно реализовываться PSP-тулом.

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

Положим, такие вещи, как "кто-то сломал билд" — это понятное дело нехорошо, и это довольно просто и надежно проверяется механически. Да. Что должно гарантировать прохождение билда? Следование простой процедуре, не требующей особого креатива — программист должен протестировать код перед чекином, обновить из репозитория, и проверить, что он после этого компилируется. То есть, соблюдение принятой процедуры и аккуратность позволит нам избежать такой ошибки. Однако, иногда билд ломается даже при соблюдении этой процедуры. Стоит ли за это наказывать? Нет. А вот за ее несоблюдение надо давать по башке. Причем можно и публично, чтобы все видели.

Надо ли вести метрику, кто сколько раз ломает билд? Может быть. Говорит она о том, кто лучший программист? Да в общем, нет. Это исключительно характеристика разгильдяйства или невезучести.

G>>Баловство это чистой воды. Эта балльная оценка не имеет никакого отношения к качеству кода и реальному вкладу программистов. И зачем она тогда нужна?
A>Прошу пояснить.

Весь фокус не в самой метрике, а в процессе вокруг нее. Вот каким образом ты будешь ими пользоваться? А именно — кто, когда, и зачем будет их смотреть?

1) Дубилрование кода
Интересно, как именно ты предлагаешь эту метрику считать. Но в любом случае — лучше не допускать этого на code review (вместе с проверкой соответствия стилевому руководству и стандарту кодирования) или design review. Когда у тебя код оказался задублирован в репозитории, и он успешно проходит тесты, строго говоря претензии к качеству предъявлять поздно. Код работает, ошибок нет — качество в порядке.

2) Покрытие нового кода тестами
Технически сложно снять такую метрику. У тебя поменялось 10 файлов, каждый на 10-20 процентов — типичная ситуация для ОО программы. Это легко посчитать по продукту целиком или по подсистеме, но не по отдельному чекину.

Возвращаясь к вопросу кто когда и как — по хорошему надо ставить цель в области качества, и достигать ее. Скажем, покрытие кода по метрике строк кода делаем 100%. И это будет означать ровно одно — что у тебя нет кода, который в принципе ни разу не вызывался. Но это вовсе не говорит тебе о том, что у тебя программа хорошо оттестирована. А в другой метрике достичь 100% практически невозможно, это дорого и бесмысленно.

Как надо поступать, если серьезно относиться к качеству. Надо описать политику тестирования, показать, что отрабатываем все значимые сценарии, после чего реализовать их в виде тестов. С умом, короче, подойти надо, а не тупо задирать метрики вверх.

3) Сложность методов (вложенные ифы, форы, ...)

Гхм.

Если ты реально решил запретить слишком длинные и глубокие методы — вноси это в код стандарт, и контроллируй на code review. Так ты добьешься выполнения правила. А этой метрикой — кто, когда, и как?

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

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

И что, чем больше пишем, тем лучше? Я могу одно и тоже в разницей в два раза написать легко, причем одинаковый тест даст то же самое покрытие.

G>>Надо не рейтинги подводить, а реально обеспечить необходимое качество кода и дизайна, в этом задача менеджмента.
A>Как?

Cтавить конкретные цели в области качества (это правда очень сложно), и достигать их посредством code & design review. Серьезно заниматься политикой тестирования.

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

ГВ>>Правильный ответ: никак. Хренисометрия — удел детского сада.
A>Ок, а если позволить мерять "хрен" самому владельцу "хрена"? Т.е. "за последний месяц он у тебя вырос на 1 см, а за предыдущий укоротился на 0,2, ..."

Объясняю метафорически: засунь свою линейку туда, откуда вынул. У меня своя линейка.

Понятно?

A>К каким косякам это может привести?

Ещё раз повторяю: засунь свою линейку...

Значит я не так тебя понял.
V_S>делегируй часть своих полномочий (но не ответственности!).
Что означает: "но не ответственности!"
ИМХО, ответственность делегировать все равно не получиться -- начальство будет против. Ответственность можно делегировать, но она в любом случае будет ответственностью перед тобой.

Короч неважно.

Начну отвечать с конца.

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

Z>Есть подозрение, что много времени будет уходить на разбирательство, почему вдруг вот этот вполне приличный код вдруг снижает какую-то метрику.
Могу представть это только на время обкатки критериев, а точнее границы хорошо/плохо.
То же покрытие у девелоперов не должно быть 100% (будет только хуже) оно должно быть где-то 60% (эту цифру нужно уточнить).
Копипаст же, чтобы однозначно было признаным копипастом должнен содержать больше 80% совпадений (опять же цифра не точна). Я даю 100%, что если дать один и тот же таск (нетривиальный) разным девелоперам, то фиг мы получим болше 80% совпадений.
Сложность методов довольно скользкий момент, но благо легко решаемый выделением нового метода. Поэтому к этому тоже стоит приучивать.
Проверка на соответствие стилю кодирования однозначно должна быть отдана роботу, так как отлично формализуется. Про компилируемость и тесты тоже нет вариантов.

Z> Формальное покрытие кода не всегда кореллирует с полезностью данного теста.
Человек написал формальные тесты. Добился 60%-го покрытия. Т.е. он потратил время. Потратил еще раз, еще, ...
Потом ему репортят баг -- он чешет репу: а почему вот этот тест не отловил его

Раз я на него тратил время, может нужно было потратить еще 5% времени и написать тест лучше?..
...
В любом случае это путь в правильном направлении.

Z>Уменьшать вложенность ифов и циклов можно довольно зверскими приемами типа:
Ну этот код не пройдет другие проверки, например по стилю кодирования ("волшебные числа" и именование переменных). Привели в соответствие со стилем кодирования. Все тесты прошли. Ну и что? Робот ведь не последняя инстанция. Будет еще код ревью (который этот кусок может просто не заметить)...

Z>Очень неприятно когда к программировнию люди начинают относиться слишком формально. Качество кода показатель далеко не формальный, за него отвечает тимлид и ему очень трудно будет кому-то объяснить, что именно здесь надо сделать "хуже" по меркам робота.
Отвечает? Пусть отвечает. Я не говорю про замену тимлида роботом

(а прикольная идея

, я знаю такие экземпляры которые можно безболезненно заменить

), я говорю про то что робот может помочь тимлиду.

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

Z>Я иногда ловлю себя на том, что после рефакторинга код становится менее читабельным, требующим более серьезного изучения перед расширением, в нем сложнее заметить элементарные ошибки. Такой рефакторинг я просто откатываю, хотя робот за него дал бы более высокую оценку.
Что ж поделать. Такова жизнь.

СУВ, Aikin

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

A>Отвечает? Пусть отвечает. Я не говорю про замену тимлида роботом

(а прикольная идея

, я знаю такие экземпляры которые можно безболезненно заменить

), я говорю про то что робот может помочь тимлиду.

Я попытался объяснить, что он будет часто мешать, в случае, когда оценка робота хоть что-то значит для программиста.

Достаточное среднее покрытие в 60% например, означает 100% покрытие 60% методов, а не 60% покрытие 100% за которым может уследить робот. Таким образом он будет ставить минусы за 40% комитов, что далеко от хорошей мотивации. С другой стороны, за 70% покрытие методов требующих 100% будет поставлен плюс, что запросто может играть роль отмазки от нудной доработки.

Нарушения стандартов кодирования, которые легко проверить автоматически довольно редки и также легко исправляются автоматически (Resharper -> Reformat all) не являются особой проблемой, которая мешает проекту. Нарушение других стандартов (например правил именования сущностей в программе, правила использования исключений) проверяются далеко не так тривиально.

Возможно получилось излишне сумбурно. Главная мысль — оценку кода должен делать человек который отвечает за его качество (или те, кому он делегировал эту ответственность) и никто другой.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

G>Могу добавить, что PSP/TSP запрещает даже менеджеру доступ к индивидуальным статистикам.

Их видит только сам исполнитель. Это требование процесса, которое должно реализовываться PSP-тулом.
Как-то мой опыт, интуиция протестуют. Но ничего конкретного сказать не могу.

G>Опять же, ты исходишь из того, что данные метрики объективно показывают качество работы программиста. Это не так, и в этом вся проблема.
Нет, я считаю что можно подобрать метрики так, что они будут объективно показыать некачественную работу программиста. Т.е. я только за те метрики которые однозначно указывают на изъяны.

Я еще вчера сказал, что нету рейтинга, а раз нету рейтинга, то нету и конкретных баллов.
Есть только объективные показатели:
1) покрытие 53% (надо 60%),
2) несоответствие стилю кодирования 6 мест,
3) 3 метода имеют комплисити больше 5,
4) тест SomeModule.DoThat провалился
...

G>Надо ли вести метрику, кто сколько раз ломает билд? Может быть. Говорит она о том, кто лучший программист? Да в общем, нет. Это исключительно характеристика разгильдяйства или невезучести.
Разгильдяю по башке, невезучему не может невезти всегда

G>Весь фокус не в самой метрике, а в процессе вокруг нее. Вот каким образом ты будешь ими пользоваться? А именно — кто, когда, и зачем будет их смотреть?
В основном сами программисты будут следить за своими успехами/неуспехами, достоинствами/недостатками.
Тимлид мониторит динамику: прислушиваются ли разработчики к советам робота. Однажды покрытие тестами всей системы упало ниже 50%. В чем причина? Все разработчики не пишут тесты, или кто-то один всех тянет вниз. Как это узнать?

G>1) Дубилрование кода
G>Интересно, как именно ты предлагаешь эту метрику считать.
Я знаю что есть тулзы которые считают. Более подробно этот вопрос не исследовал.
G>Но в любом случае — лучше не допускать этого на code review (вместе с проверкой соответствия стилевому руководству и стандарту кодирования) или design review.
Одно другому не мешает. К ревью можно приступить имея на руках результат автоматического анализа.
G>Когда у тебя код оказался задублирован в репозитории, и он успешно проходит тесты, строго говоря претензии к качеству предъявлять поздно.
Всегда можно сделать новый коммит, который уберет дублирование.
G>Код работает, ошибок нет — качество в порядке.
Неверный вывод. Качество это не только внешняя составлящая. Но еще и внутренняя. Недавно из коммандировки я привез приложение изнутри представляюее собой кучу говнокода, а для пользователей это приложение выглядит конфеткой и самое главное -- работает корректно. Но добавить в приложение небольшое изменение представляется проблематичным (1,5 недели у меня занял таск, который при нормальном дизайне отнял бы не больше дня).

G>2) Покрытие нового кода тестами
G>Технически сложно снять такую метрику. У тебя поменялось 10 файлов, каждый на 10-20 процентов — типичная ситуация для ОО программы. Это легко посчитать по продукту целиком или по подсистеме, но не по отдельному чекину.
Тулы проверки покрытия кода считают буквально построчно. Можно посмотреть, например, здесь (обрати внимание на картинку внизу: подсветка отдельных строчек).

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

G>3) Сложность методов (вложенные ифы, форы, ...)
G>Гхм.

G>>>Надо не рейтинги подводить, а реально обеспечить необходимое качество кода и дизайна, в этом задача менеджмента.
A>>Как?
G>Cтавить конкретные цели в области качества (это правда очень сложно), и достигать их посредством code & design review. Серьезно заниматься политикой тестирования.
Ок, я только не понимаю почему в эту систему не вписывается автоматическая проверка? Предварительно, как помощь для человеческих методов оценки.

Z>Я попытался объяснить, что он будет часто мешать, в случае, когда оценка робота хоть что-то значит для программиста.
Непонимаю почему?

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

Вот цитата из моего поста:

Я еще вчера сказал, что нету рейтинга, а раз нету рейтинга, то нету и конкретных баллов.
Есть только объективные показатели:
1) покрытие 53% (надо 60%),
2) несоответствие стилю кодирования 6 мест,
3) 3 метода имеют комплисити больше 5,
4) тест SomeModule.DoThat провалился
...

Z>Достаточное среднее покрытие в 60% например, означает 100% покрытие 60% методов, а не 60% покрытие 100% за которым может уследить робот. Таким образом он будет ставить минусы за 40% комитов, что далеко от хорошей мотивации. С другой стороны, за 70% покрытие методов требующих 100% будет поставлен плюс, что запросто может играть роль отмазки от нудной доработки.
Это тоже отлавливается. А что отлавливается можно включить в метрику.
Z>Нарушения стандартов кодирования, которые легко проверить автоматически довольно редки и также легко исправляются автоматически (Resharper -> Reformat all) не являются особой проблемой, которая мешает проекту.
Довольно редки для тебя, для меня,... У новичков дело обстоит похуже.
Но в любом случае это не значит, что их не стоит держать хотя бы для страховки (если строители ходят в казках, это не значит, что им на голову каждый день кирпичи падают).
Z>Нарушение других стандартов (например правил именования сущностей в программе, правила использования исключений) проверяются далеко не так тривиально.
Что не может проверить робот -- проверяет человек.
Z>Возможно получилось излишне сумбурно. Главная мысль — оценку кода должен делать человек который отвечает за его качество (или те, кому он делегировал эту ответственность)
Бесспорно, но помочь ему робот может.
Z> и никто другой.
Как ты понимаешь, я с этим не согласен

Z>Ресурсы на разработку, внедрение и поддержку данного робота, тоже не стоит сбрасывать со счетов. Врядли они окажутся копеечными.
Внедрение -- да, поддержку -- врядли. Но не думаю, что это сложная задача.
Говорю не голословно, так как поднимал интегрэйшен сервер у себя в команде, на nAnt-овских скриптах (чисто get code, compile, deploy и письмо команда в случае неудачи). Поддержки это не требует никакой.

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

Z>>Я попытался объяснить, что он будет часто мешать, в случае, когда оценка робота хоть что-то значит для программиста.
A>Непонимаю почему?

A>Эти метрики конечно же не должны мешать работе. В этих метриках должны быть зашиты общие принципы (которые можно формализовать) требований к качеству.
A>Причем я не предлагаю отказывать в комите на основе этих показателей (а это можно сделать). Если есть причины проигнорировать комментарии робота -- игнорируй. Но ты должен сделать это осознанно.

A>1) покрытие 53% (надо 60%),
Как считать покрытие нового кода? Откуда взялись 60% именно для данного комита?
A>2) несоответствие стилю кодирования 6 мест,
Это наиболее объективная метрика из всех.
A>3) 3 метода имеют комплисити больше 5,
О чем это говорит?
A>4) тест SomeModule.DoThat провалился
Это проверит запуск тестов, билд окажется поломаным и никакой отчет робота уже не потребуется.

Z>>Достаточное среднее покрытие в 60% например, означает 100% покрытие 60% методов, а не 60% покрытие 100% за которым может уследить робот. Таким образом он будет ставить минусы за 40% комитов, что далеко от хорошей мотивации. С другой стороны, за 70% покрытие методов требующих 100% будет поставлен плюс, что запросто может играть роль отмазки от нудной доработки.
A>Это тоже отлавливается. А что отлавливается можно включить в метрику.
И как робот будет отличать код который требут 100% покрытия от кода не требующего покрытия вообще.

Z>>Нарушения стандартов кодирования, которые легко проверить автоматически довольно редки и также легко исправляются автоматически (Resharper -> Reformat all) не являются особой проблемой, которая мешает проекту.
A>Довольно редки для тебя, для меня,... У новичков дело обстоит похуже.
A>Но в любом случае это не значит, что их не стоит держать хотя бы для страховки (если строители ходят в казках, это не значит, что им на голову каждый день кирпичи падают).
Страховки от чего? От того, что кто-то увидит код с плохоми отступами? Это не крипич по голове, это нажатие 2х кнопок и устный выговор тому, кто это закомитил. В принципе я не против робота в данной ситуации, но игра стоит свеч только при очень высоких требованиях к стандартизации кода, например разработка библиотек и фреймворков.

Z>> и никто другой.
A>Как ты понимаешь, я с этим не согласен

Вобщем-то оценивать может кто угодно, лишь бы он не лез с этой оценкой в процесс разработки.

Z>>Ресурсы на разработку, внедрение и поддержку данного робота, тоже не стоит сбрасывать со счетов. Врядли они окажутся копеечными.
A>Внедрение -- да, поддержку -- врядли. Но не думаю, что это сложная задача.
A>Говорю не голословно, так как поднимал интегрэйшен сервер у себя в команде, на nAnt-овских скриптах (чисто get code, compile, deploy и письмо команда в случае неудачи). Поддержки это не требует никакой.
Интеграцию робота в CI я вообще не учитывал.

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

Имейте ввиду, что каждому новичку придется уживаться не только с VCS, баг и таск трекером, CI сервером и еще какими-то инструментами, но еще и с роботом. Лишний инструмент должен давать очень хорошие бонусы, чтобы оправдать связаный с ним геморрой.

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

Начну с того, что метрики которые я дал в самом начале были даны как пример. Сейчас мы обсуждаем целесообразность этого метода вообще, а не конкретные метрики. Конкретные метрики обсудим позже. Но за основу можно взять Reporting plugins к Maven (checkstyle, clover, docck).
Дальше, почему запуск тестов проводимых автоматически (по сути роботом) мы отделяем от робота который анализирует код? Ведь это тоже анализ кода.

Z>И как робот будет отличать код который требут 100% покрытия от кода не требующего покрытия вообще.
А зачем ему это отличать?
У него прошито: каждый метод должен иметь покрытие не меньше 60% (число примерное, забитое в настройках число), он это и проверяет.

Z>>>Нарушения стандартов кодирования, которые легко проверить автоматически довольно редки и также легко исправляются автоматически (Resharper -> Reformat all) не являются особой проблемой, которая мешает проекту.
A>>Довольно редки для тебя, для меня,... У новичков дело обстоит похуже.
A>>Но в любом случае это не значит, что их не стоит держать хотя бы для страховки (если строители ходят в казках, это не значит, что им на голову каждый день кирпичи падают).
Z>Страховки от чего? От того, что кто-то увидит код с плохоми отступами? Это не крипич по голове, это нажатие 2х кнопок и устный выговор тому, кто это закомитил. В принципе я не против робота в данной ситуации, но игра стоит свеч только при очень высоких требованиях к стандартизации кода, например разработка библиотек и фреймворков.
Не утрируй. Из маленького разгильдяйства часто вырастает большое рас^%@*дяйство. А "цена свеч" не так уж и высока.

Z>>> и никто другой.
A>>Как ты понимаешь, я с этим не согласен

Z>Вобщем-то оценивать может кто угодно, лишь бы он не лез с этой оценкой в процесс разработки.
Т.е. ты там поиграйся с кодом, а отчет можешь себе в ... засунуть?
Еще раз: отчеты робота носят рекоментдательный характер с одной стороны, и предварительный анализ с другой.

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

Z>Имейте ввиду, что каждому новичку придется уживаться не только с VCS, баг и таск трекером, CI сервером и еще какими-то инструментами, но еще и с роботом.
И? Ну не будет робота, не получит он от него замечаний. Зато получит во время код ревью. А был бы робот он бы объяснил ему, что и как он делает не так. Что принято в команде. И объяснит получше, чем 30-страничный труд "требования к комитам в команде".

Z>Лишний инструмент должен давать очень хорошие бонусы, чтобы оправдать связаный с ним геморрой.
А какие бонусы дает CI, багтрекер, тасктрекер,... для маленького проекта на 5 человек и двух контактных лиц со стороны заказчика по сравнению с "гемороем"... Никаких!
Дело в другом, что все это обычно ставиться на организацию в целом, поэтому расходы по поддержке этих вспомогательных средств с течением времени стремяться к нулю.

Нет, я понимаю о чем ты говоришь. Даже разделяю твой скептицизм. И со многим согласен. Но я представляю сторонников подхода (так как я ее предложил)

Самое главное, что я хочу извлечь из этого обсуждения: нужно ли рассматривать эту идею в работе или нет.
Например идея с рейтингом (пуличным и нет) с треском провалилась. За это спасибо Гапертону. Вполне возможно вся идея так же провалится. Тоже хорошо.

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

G>>Код работает, ошибок нет — качество в порядке.
A>Неверный вывод. Качество это не только внешняя составлящая. Но еще и внутренняя.

Вот тольки не надо передёргивать термины. Качество — это соответствие между требованиями и продуктом.

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

Да, можно выставить некоторые эстетические требования (например — соглашение о наименовании, ограничение дины строки, размер отступа и т.п.) и на основании замеров таких показателей вывести некий показатель "внутреннего качества кода", но к качеству конечного продукта этот показатель будет самое опосредованное отношение. Ты ещё попробуй докажи, что, например "высокие эстетические характеристики" обусловили выполнение проекта в срок. Во поэтому в целях экономии ресурсов менеджмент не занимается такой чепухой, как вычисление "эстетики" путём просчёта глубины if.

То же самое и с покрытием тестами. Да, можно покрыть каждый модуль на 100%, но что это даст? Правильный ответ: это даст самоудовлетворение разработчику от того, какой клёвый, всесторонне проверенный модуль он написал. Всё. На этом прямая польза заканчивается, потому что можно написать совершенно правильный модуль по очень неправильной спецификации. А если спецификация правильная, то достаточно чтобы текущий test case покрывал потребности модуля (модулей) верхнего уровня. При это совершенно не имеет значения, покрывается 95% внутренней структуры низкоуровневого модуля или, скажем, 41%.

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

То есть опять таки, какие-то априорно необходимые показатели покрытия сработают в неизвестную сторону.

A>Недавно из коммандировки я привез приложение изнутри представляюее собой кучу говнокода, а для пользователей это приложение выглядит конфеткой и самое главное -- работает корректно. Но добавить в приложение небольшое изменение представляется проблематичным (1,5 недели у меня занял таск, который при нормальном дизайне отнял бы не больше дня).

Ну откуда мы знаем, а вдруг оставшийся "говнокод" был написан в рекордно короткие сроки маленькой командой разработчиков, которая, если бы занималась изысками "внутреннего качества", разрабатывала бы его в пять раз дольше, поставив под вопрос само существование проекта?

G>>>>Надо не рейтинги подводить, а реально обеспечить необходимое качество кода и дизайна, в этом задача менеджмента.
A>>>Как?
G>>Cтавить конкретные цели в области качества (это правда очень сложно), и достигать их посредством code & design review. Серьезно заниматься политикой тестирования.
A>Ок, я только не понимаю почему в эту систему не вписывается автоматическая проверка? Предварительно, как помощь для человеческих методов оценки.

Ну потому что в первую очередь политика управления качеством нацеливается на качество конечного продукта, а не на то, насколько красив и изящен код и сколько в % Copy-Paste. Соответственно, и test cases должны в первую очередь покрывать сценарии работы конечного пользователя.

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

От:	Aikin	kavaleu.ru
Дата:	17.06.08 07:32
Оценка:	89 (16) +9

От:	Gaperton	http://gaperton.livejournal.com
Дата:	18.06.08 15:00
Оценка:	12 (1) +7

От:	Aikin	kavaleu.ru
Дата:	17.06.08 09:53
Оценка:	4 (2) +6

От:	Gaperton	http://gaperton.livejournal.com
Дата:	26.06.08 11:29
Оценка:	38 (4) +2

От:	Gaperton	http://gaperton.livejournal.com
Дата:	17.06.08 17:25
Оценка:	15 (5)

	От:	The Lex
	Дата:	16.06.08 21:59
	Оценка:	9 (1) +2

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	18.06.08 16:01
Оценка:	7 (2) +1

От:	chipsеt	http://merlinko.com
Дата:	18.06.08 06:38
Оценка:	1 (1) +1

	От:	Vlad_SP
	Дата:	23.06.08 09:01
	Оценка:	1 (1) +1

	От:	Kuzmenko_A
	Дата:	17.06.08 10:34
	Оценка:	15 (1)

	От:	__steven__
	Дата:	16.06.08 12:43
	Оценка:	1 (1)

От:	nikov	http://www.linkedin.com/in/nikov
Дата:	18.06.08 14:14
Оценка:	1 (1)

От:	Michael_E_Smrinov	http://www.msmirnov.ru
Дата:	16.06.08 12:31
Оценка:	+1

От:	A.Lokotkov	http://www.linkedin.com/pub/alexander-lokotkov/a/701/625
Дата:	17.06.08 11:58
Оценка:	+1

	От:	Maxim S. Shatskih
	Дата:	02.07.08 14:49
	Оценка:

От:	Joker3D	http://blog.trunin.com
Дата:	20.07.08 18:50
Оценка:

	От:	rinat.mergenbaev
	Дата:	05.08.08 18:05
	Оценка: