Здравствуйте, Gaperton, Вы писали:
M_E>>Я думаю можно сделать автоматическую рассылку — чтобы все получали список сотрудников и кол-во задач, которые они закрыли за день или неделю. G>... Заведи рассылку check-in, и напиши робота, который будет посылать туда письма при каждом коммите в репозиторий. В письме должен быть комментарий к коммиту, список файлов, ссылка на веб-интерфейс чтобы посмотреть пофайловые диффы. А еще — хорошо если робот посчитает новые/измененные/удаленные/все в сумме строки кода, без пустых, комментариев, и фигурных скобок. Чтоб был виден характер и объем изменений.
G>... Во-вторых, заинтересованным личностям удобно смотреть диффы. В третьих — им также виден объем изменений, и подсистемы, над которыми идет работа.
Кстати, полезная очень штука была бы в процессах с ежедневными общими билдами: устром сразу же получаешь дайджест кто что менял и в каком объеме — этого здорово не хватало в свое время! Особенно это касается "команд из конкурирующих сдельщиков", которые между собой выполнение своих "тасков" над одним и тем же проектом фактически никак не согласовывают.
Здравствуйте, _Dinosaur, Вы писали:
TL>>Ну и какая разница каким словом "это" назвать? _D>( возможно, этот пример не совсем удачный... )
Как ни назови — все равно "лучше просто иметь здоровые волосы" (к)
TL>>Вот "создание конкурсов, соревнований, олимпиад" и гребет всех под одну гребенку. Скажешь нет? _D>Нет, это возможность проявить уникальные способности, повысить авторитет, получить денежку...
Проявить уникальные способности где и как? В специальным образом выдуманной "олимпиадно-конкурсной" задаче?
Имхо, и авторитет и денежка и должны и в конце концов таки и приходят от возможности и умения проявлять себя в практических задачах, которые на решение бизнеса направлены, а не на "возможность проявить уникальные способности". Но если очень хочется — можно ряд задач или вообще "твердые орешки" выделить в специальный раздел, который доступен всем и все могут предлагать решения — или же, например, создавать команды динамически и работать над решением конкретной задачи и за это решение получать денежку _командой_ — ну и опыт, и авторитет, и возможность проявить способности тоже. имхо, важно формировать команды, а не способствовать росту "мелких дельцов-сдельщиков". Но как вариант наверняка возможно и последнее — таких людей, думаю, немного, но они есть — почему бы не использовать и их потенциал? (Гапертону) Вопрос в том что грести под эту гребенку всех не получится априри — проверенный факт. Ну и эффективность "конкурентной работы" имхо сомнительна — они практически без взаимодействия работают и часто-густо одни и те же задачи выполняют каждый по отдельности, т.е. в сумме по многу раз, да еще и каждый по-разному.
_D>Однако, идея, доведенная до абсурда, теряет свою привлекательность и эффективность.
Я тебе описал практические аспекты этой "идеи": целенаправленное выдумывание "интересных задач" с целью занять (якобы) отлынивающий коллектив — ты об идеях практических реализаций своей же "идеи" ничего не писал...
истинная причина процветания концерна – в том, что Чед Бакнер формулирует так: «Мы всегда стремимся к большему». И это не просто принцип работы – это образ мыслей компании.
Если ваш завод просто выпускает автомобили, то раз в день звучит сигнал, все расходятся по домам и с конвейера уже не сойдет ни одной машины. Если ваш завод ищет новые методы производства, то рабочий день бесконечен.
Вечные перемены и мысли о том, что еще можно улучшить, вряд ли принесут вам победу над конкурентами в следующем квартале. Они принесут вам победу в следующем десятилетии.
В газетах нередко пишут, что за год на сборочной линии Toyota в Соединенных Штатах внедряются тысячи инноваций. Эта цифра не просто велика, она громадна. Что переменилось в вашем повседневном труде за последние десять лет? Рядовые сотрудники компании Toyota за год вносят десятки изменений в свои ежедневные обязанности.
Погоня за совершенством – не дополнение к основной деятельности и не специальный проект, выходящий за рамки постоянных обязанностей.
Работа стала частью его повседневной жизни. «Я стригу газон и думаю о том, как улучшить этот процесс. Пробую разные способы – может быть, так получится быстрее»
Проблемы в первую очередь
«Где бы я не работал раньше, мы всегда занимались поиском «серебряной пули» – стремились к глобальным переменам. Я полагал, что если цель достигнута, можно остановиться. Мне нравилось так думать», – рассказывает Вайсман. Он был типичным представителем американской корпоративной культуры и считал, что совещания – не место для разговоров о проблемах и неудачах.
В те дни завод в Джоджтауне возглавлял Фудзио Чо (сегодня он – председатель совета директоров Toyota). Каждую пятницу топ-менеджеры предприятия собирались на совещание. «Поначалу, выступая там, я рассказывал о своих небольших успехах, – вспоминает Вайсман. – Однажды я описал один из наших проектов – тогда мы планировали обнародовать информацию о расширении фабрики. Я говорил очень позитивно, хвастался. Мое выступление длилось две или три минуты, затем я сел. Фудзио удивленно посмотрел на меня и сказал: «Джим-сан, нам известно, что вы хороший менеджер, иначе мы бы не наняли вас. Но, пожалуйста, расскажите о ваших трудностях, и мы сможем решить их вместе».
Это было похоже на озарение. Оказывается, даже после завершения успешных проектов мы задавались вопросом: а что можно было сделать лучше? Только теперь я понял истинный смысл выражения: плохие новости в первую очередь».
В компании Toyota уверены: вы не можете решить проблемы, пока не признаете факт их существования. Здесь действует презумпция несовершенства. Идеал – это прекрасно, но небольшие перемены к лучшему гораздо более реальны, человеку проще поставить перед собой локальную цель.
Как только вы понимаете, насколько это увлекательно – постоянно стремиться к совершенству, каждое улучшение в отдельности становится неинтересным.
Бесконечность
«Если вы приедете на завод Большой тройки, то увидите там что-то похожее на работу менеджмента Toyota, – говорит Джеффри Ликер, профессор инженерного дела в университете Мичигана, автор книги The Toyota Way, объясняющей многие методы компании. – Но заниматься этой работой будет некая инженерная группа, консалтинговая компания Большой шестерки или кто-то из гуру менеджмента. Не исключено, что они ничуть не хуже специалистов Джорджтауна. Но вот какая штука: такие специалисты превратят весь проект в презентацию, развесят информацию о нем на каждом углу и будут хвалиться большими достижениями. Такое случается каждый год на одном из предприятий Большой тройки. И внимание всей компании будет приковано только к этому».
«Toyota, – продолжает Ликер, – делает то же самое каждый день во всех отделах. Они справляются сами, без помощи приглашенных именитых специалистов».
Вы можете покупать книги, приглашать консультантов, применять программы, исповедовать регулярные перемены – и, в конце концов, устанете, утратите энтузиазм, удивитесь, почему новая программа не нашла поддержки и не сумела изменить ваш бизнес. А потом поставите толстые тома на полку и вернетесь к привычным методам.
Тому, что ежедневно происходит в Джорджтауне, можно научить и научиться. Но это не цель, ибо цель предполагает точку финиша, а здесь ее нет. Это нельзя применить, потому что это – не список инноваций. Это другое мировоззрение. К нему нельзя потерять интерес, пожать плечами и отступить, как невозможно потерять интерес к своему будущему.
«Людям, которые попадают сюда из других фирм, приходится многому учиться, – рассказывает Джон Шук, преподаватель Университета Мичигана, бывший сотрудник Toyota, известный консультант по использованию идей компании. – Какое-то время такие сотрудники не могут понять, что происходит. Они делают то же, что и все остальные менеджеры Америки – продолжают ставить цели. И даже идут вперед, что-то улучшают… Но неизменно ищут плато. Пока вы ищете плато, все происходящее кажется борьбой. Это трудно. Выхода из подобной ситуации нет».
В Toyota вам придется познакомиться с философией Дзэн. «Как только вы понимаете, что это и есть сам процесс, и искать плато не нужно, вы можете расслабиться. Выполнение работы и улучшение ее качества становятся единым целым, – говорит Шук. – Вот это и означает – приступить к делу».
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Уважаемые опытные коллеги, мне необходима ваша помощь в вопросе мотивации разработчиков.
если честно не понял, Вы хотите чтобы быстрее и больше работали, или избавиться от текучки, или поднять зп(доход) программерам (заодно и себе) или Вы просто недавно ПМ, и Вам скучно?
Здравствуйте, The Lex, Вы писали:
TL> Я тебе описал практические аспекты этой "идеи": целенаправленное выдумывание "интересных задач" с целью занять (якобы) отлынивающий коллектив — ты об идеях практических реализаций своей же "идеи" ничего не писал...
Я нигде не писал о выдумывании задач. Рассказать другим как ты решил возникшую проблему в работе может быть интересно и полезно, как рассказчику так и коллегам. Незнакома ситуация, когда один и тот же велосипед изобретают разные разработчики в команде раз за разом? Никогда в чужом коде не замечали, что кто-то сделал то-же самое, что и вы, но лучше/хуже?
Премировать за это деньгами может и не обязательно, вполне достаточно одобрения коллег.
Я все равно не готов вводить это в таком виде на практике, но вы истолковывали идею совершенно превратно.
AL>Можно полюбопытствовать, в чем именно уважаемые коллеги видят связь между обсуждаемой темой и тем, что написано в том рассказе про Тойоту?
Это стеб или действительно непонятно?
P.S. И на заводе, и в офисе работают те же самые люди. То что одни ходят по цеху (мастера, инженеры, менеджеры, ...), а вторые сидят в за компом (программеры, тимлиды, менеджеры) сути не меняет.
Здравствуйте, Aikin, Вы писали: A>P.S. И на заводе, и в офисе работают те же самые люди. То что одни ходят по цеху (мастера, инженеры, менеджеры, ...), а вторые сидят в за компом (программеры, тимлиды, менеджеры) сути не меняет.
Здравствуйте, Ziaw, Вы писали:
TL>> Я тебе описал практические аспекты этой "идеи": целенаправленное выдумывание "интересных задач" с целью занять (якобы) отлынивающий коллектив — ты об идеях практических реализаций своей же "идеи" ничего не писал... Z>Я нигде не писал о выдумывании задач. Рассказать другим как ты решил возникшую проблему в работе может быть интересно и полезно, как рассказчику так и коллегам. Незнакома ситуация, когда один и тот же велосипед изобретают разные разработчики в команде раз за разом? Никогда в чужом коде не замечали, что кто-то сделал то-же самое, что и вы, но лучше/хуже? Z>Премировать за это деньгами может и не обязательно, вполне достаточно одобрения коллег.
Угу. И что бы мы, программеры, без вас, манагеров, делали бы, бедненькие мы... Описанное взаимодействие реализуется сейчас в основном теми самыми "неформальными чаепитиями" — о чем, кстати, упоминал Гапертон: в нормальной команде — не "конкурирующей" — обмен идеями совершенно естественный процесс. К сожалению, применение "личных показателей заапрувленых тасков" к такой команде невозможно в виду работы команды как единого механизма.
В глобальном плане я уже пытался ратовать за создание некоего глобального репозитария готовых решений — но пока что реализации не было — я согласен считать это моей личной виной виду слабой моей личной мотивации — ленью, если короче.
ЗЫ: Гапертон привер хороший метод автоматического доведения приватных решений до "all" — рассылку информации о коммитах с комментариями всем желающим: при такой реализации не быть в курсе об аналогичном решении, только что реализованном соседней бригадой в другом модуле, можно только при явном нежелании это делать. имхо.
ЗЫ: рассказывать целенаправленно — да и выспрашивать "ну и расскажи как же ты это сделал?" — чаще не получится в виду не сильно развитого красноречия у "программиста обыкновенного".
Z>Я все равно не готов вводить это в таком виде на практике, но вы истолковывали идею совершенно превратно.
Да нет — просто ты не подал никакой конкретики в плане практики, а "чистую идею" передал вовсе не так, как описал только что...
Здравствуйте, The Lex, Вы писали:
M_E>>>Я думаю можно сделать автоматическую рассылку — чтобы все получали список сотрудников и кол-во задач, которые они закрыли за день или неделю. G>>... Заведи рассылку check-in, и напиши робота, который будет посылать туда письма при каждом коммите в репозиторий. В письме должен быть комментарий к коммиту, список файлов, ссылка на веб-интерфейс чтобы посмотреть пофайловые диффы. А еще — хорошо если робот посчитает новые/измененные/удаленные/все в сумме строки кода, без пустых, комментариев, и фигурных скобок. Чтоб был виден характер и объем изменений.
G>>... Во-вторых, заинтересованным личностям удобно смотреть диффы. В третьих — им также виден объем изменений, и подсистемы, над которыми идет работа.
TL>Кстати, полезная очень штука была бы в процессах с ежедневными общими билдами: устром сразу же получаешь дайджест кто что менял и в каком объеме — этого здорово не хватало в свое время! Особенно это касается "команд из конкурирующих сдельщиков", которые между собой выполнение своих "тасков" над одним и тем же проектом фактически никак не согласовывают.
Это очень хорошо делает связка Bamboo + JIRA от Atlassian. Там билд-сервер умеет связывать воедино дефекты-задачи, коммиты, и билды. И все — автоматически. Ты всегда видишь не только какой билд идет, но и работы по каким дефектам туда вошли. И какие изменения были сделаны. Рекомендую, это круто.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Можно полюбопытствовать, в чем именно уважаемые коллеги видят связь между обсуждаемой темой и тем, что написано в том рассказе про Тойоту?
Если не ошибаюсь, в статье приводится описание результатов практической реализации одного из принципов кайдзена: борьба с муду (с несовершенством).
Предполагаю, что связь может быть выражена так:
внедрение на предприятии принципа "борьбы с муду", предполагает обновление/изменение системы мотивации труда работников предприятия.
Завидую людям, которые могут себе позволить никуда не спешить.
Здравствуйте, 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Х года пришел коллега, улыбаясь, и принес ему конвертик.
(мрачно)
— Что это такое?
(игриво)
— А это подарок от деда мороза!
(мрачно)
— Передай деду морозу, что слово "подарок" пишется с тремя нолями.
G>Эта рассылка полезна много чем. Во первых, конечно, ты видишь "поток работ", и тебя это успокаивает. Во-вторых, заинтересованным личностям удобно смотреть диффы. В третьих — им также виден объем изменений, и подсистемы, над которыми идет работа.
Да, я думаю надо такое организовать.
G>Совет номер два. Если у тебя идет работа в рамках плана — проводи еженедельные status-meeting. На нем — сравнивай по каждому человеку и по всей группе количество задач по сравнению с запланированным.
Статус-митинги провожу каждую неделю и в принципе примерно это и делаю
Здравствуйте, ironwit, Вы писали:
I>если честно не понял, Вы хотите чтобы быстрее и больше работали, или избавиться от текучки, или поднять зп(доход) программерам (заодно и себе) или Вы просто недавно ПМ, и Вам скучно?
Чтобы хотели быстрее и больше работать.
Здравствуйте, 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 принципы управления.
Другой пример СССР там использовалась иная мотивация: есть общий враг капитализм и есть коммунизм, задача коммунизм всей планете(коммунизм == светлое будущее человечеству). В результате стахановское движение и тд. Страна которая была разрушена и обескровлена, поднялась после войны.
Проблема СССР это неэффективная система управления с точки зрения экономической и рыночной эффективности. Сама идея коммунизма была чисто политической не имела под собой экономической подоплеки в отличии от капитализма. В результате в отличии от капиталистов мы не сумели создать эффективную школу менеджмента. В планировании задавались нереальные цели, на этапе контроля допускались громадные расхождения с результатом. А вот мотивация какое то время была на высоте
Проблема только финансовой мотивации в быстром насыщении работника, не всегда достижении его текущих целей и тд. По этому нужны в том числе косвенные ее формы (социальная и тд.).
Особенно это касается "команд из конкурирующих сдельщиков", которые между собой выполнение своих "тасков" над одним и тем же проектом фактически никак не согласовывают. 
Как ни назови — все равно "лучше просто иметь здоровые волосы" (к) 
— ты об идеях практических реализаций своей же "идеи" ничего не писал... 
Описанное взаимодействие реализуется сейчас в основном теми самыми "неформальными чаепитиями" — о чем, кстати, упоминал Гапертон: в нормальной команде — не "конкурирующей" — обмен идеями совершенно естественный процесс. К сожалению, применение "личных показателей заапрувленых тасков" к такой команде невозможно в виду работы команды как единого механизма. 
