Здравствуйте, The Lex, Вы писали:
TL>Однако айтемов окромя как "изменить название кнопки" такой "команде" реализовывать не удается.
Как показала практика данного проекта твое утверждение как минимум ложно в данном конкретном случае.
TL>С таким уровнем разделения и с такой мотивацией это вообще не _команда_.
Ну да, конечно.
Здравствуйте, Vlad_SP, Вы писали:
G>>А еще — самые дорогие ошибки возникают на границе подсистем, которые делаются разными людьми — из-за неявных допущений, которые они делают о "контрактах" и интерфейсах подсистем друг друга.
V_S>А вот это уже косяк проектировщика/архитекта, который не удосужился эти контракты и интерфейсы подробно и точно специфицировать. Программист-то (inmpementor) тут при чем?
И кстати. Вот именно поэтому я и не люблю выделенных архитекторов, и предпочитаю групповую работу над архитектурой/дизайном. Проблема состоит в том, что при наличии имплементоров, которые плохо понимают идеи, которые стоят за архитектурой, тебе нужно ну очень подробную спецификацию контрактов написать, и при этом, мы разумеется получаем что? Помимо увеличившегося оверхэда, конечно — нам продукт надо делать, а не документацию. Получаем мы значительное увеличение вероятности ошибки в этой документации, а также в силу удлиннения сроков — увеличение вероятности изменения требований.
Это имеет также прямое отношение к auftragstaktik, про который я писал недавно. Возьмем процесс для небольшой группы — человек в 6. Когда я привлекаю к работе над архитектурой всю команду, я имею гарантию, что все понимают дух архитектуры, а не букву (настолько, насколько это вообще можно гарантировать, конечно). Поэтому, во-первых, я снижаю требования к объему необходимой документации, а во вторых — сильно снижаю стоимость ошибок и недоговорок в "контрактах". Потому, что люди, понимая общий принцип и дух, во первых с большей вероятностью обнаружат ошибку на раннем этапе, а во вторых — способны сами додумать детали в общем ключе.
А от ошибок в дизайне при таком подходе я закрываюсь перекрестными design review. В данном случае — они 1) будут эффективны, потому что все в теме общей идеи архитектуры, и 2) мне опять же требуется меньше документации. При всем при этом — я получаю качественный результат гораздо быстрее, сведя объем документации к необходимому минимуму.
Что характерно — те же люди и кодируют, каждый свою подсистему, предварительное проектирование которой он выполнял на предыдущем этапе в составе группы. Код контолируется на code review — выполняется теми, кто реализует соседнюю подсистему, интерфейсную с данной. Это, опять же, дает нам сквозную ответственность за результат, и высокую вероятность обнаружения оставшихся ошибок архитектуры дизайна на этапе кодирования. Потому, что люди прекрасно понимают, что они делают, как, и зачем/почему.
При таком подходе нет "имплементоров" — есть набор вполне самостоятельных "боевых единиц", которые обучены объединяться в организованную группу для решения крупных задач — при этом следуя контролируемому ватерфолу. Так разработка получается очень сильно дешевле, по сравнению с "разделением интеллектуального труда", при лучшем качестве — этот подход сочетает лучшие свойства ватерфола и декларируемые преимущества agile.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Здравствуйте, ironwit, Вы писали:
I>>если честно не понял, Вы хотите чтобы быстрее и больше работали, или избавиться от текучки, или поднять зп(доход) программерам (заодно и себе) или Вы просто недавно ПМ, и Вам скучно? M_E>Чтобы хотели быстрее и больше работать.
такого не бывает. никто не хочет больше и быстрее работать тем более за деньги. вот когда денег более — менее хватает, тогда можно за интерес. У программистов зарплата средняя по рынку или ниже?
Здравствуйте, Kuzmenko_A, Вы писали:
K_A>В компании Toyota поставлена цель достичь совершенства и эта цель отлично мотивирует людей, которые этого хотят... суть в том что человек это внедривший чувствует свой вклад в результат и от этого счастлив. А сама компания дала ему эту возможность.
Ощущение личного вклада в результат общей деятельности, конечно же, является одним из наилучших мотивирующих факторов. На тойоте участник процесса, которому дали возможность что-то улучшить, немедленно видит результат (по крайней мере, это следует из той статьи), чувствует себя причастным и классно от этого "мотивируется".
Однако, если вернуться к исходной теме и проблеме, лично мне совершенно не ясно, с какой стати разработчики на фиксированном окладе, работающие в длительных проектах без явных промежуточных итогов (да еще и в нескольких сразу, бывает и такое), будут хотеть стремиться к достижению совершенства компании и к улучшению чего-то в процессе? Я в курсе, как строилась система мотивации на Интел, Эппл, Майкрософт и прочих изначально проектно-ориентированных фирмах, но это не имеет ничего общего с тем, как организуется работа в некоторых отечественных компаниях, представитель одной из которых и завел сей топик.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Уважаемые опытные коллеги, мне необходима ваша помощь в вопросе мотивации разработчиков.
M_E>Большое спасибо!
Буду говорить по себе как по рядовому программеру.
ИМХО, следует каким-то образом создавать дружественную и откровенную атмосферу в коллективе и говорить не только о работе. У меня большинство провалов в продуктивности было связано с личными проблемами (расстался с девушкой, провалил экзамен, и т.д.). Вот допустим такой момент... Ты приходишь со своей code review и начинаешь оценивать мой код, разбрасывать зелёные растения по офису, ставить вентиляторы мне прямо в рожу, говорить о какой-то мифической продуктивности компании (на компанию мне наплевать даже когда я относительно на пике эмоций)... мне откровенно плевать на все это. меня Катя не любит! В этот момент лучшей мотивацией было-бы, "Слухай, да чихать на эту грёбаную компанию, акции, проекты и т.д., пойдем попьем пивка и поговорим как мужчины а не как роботопрограммеры". Конечно, общение с людьми это сложно. А что ты хотел? Ты манагер, ты обязан делать так чтобы тебя любили а не вводить какие-то книжные нормативы и устои которые все ненавидят.
Вывод: манагер это работа с людьми а не "командой" или "программистами". За это ему и платят такие деньги.
Здравствуйте, The Lex, Вы писали:
TL>Проявить уникальные способности где и как? В специальным образом выдуманной "олимпиадно-конкурсной" задаче?
Задачи должны подбираться в зависимости от целей проведения соревнования. А поскольку цели проведения соревнований могут быть разными, то уникальность и заковыристость задачи — не является обязательным требованием...
TL>Имхо, и авторитет и денежка и должны и в конце концов таки и приходят от возможности и умения проявлять себя в практических задачах, которые на решение бизнеса направлены, а не на "возможность проявить уникальные способности".
А разве умение быстро и качественно решать такие практические задачи нельзя считать уникальной способностью сотрудника/команды?
TL>Но если очень хочется — можно ряд задач или вообще "твердые орешки" выделить в специальный раздел, который доступен всем и все могут предлагать решения
TL> — или же, например, создавать команды динамически и работать над решением конкретной задачи и за это решение получать денежку _командой_ — ну и опыт, и авторитет, и возможность проявить способности тоже.
Это реализуется при матричной структуре управления.
TL> Ну и эффективность "конкурентной работы" имхо сомнительна — они практически без взаимодействия работают и часто-густо одни и те же задачи выполняют каждый по отдельности, т.е. в сумме по многу раз, да еще и каждый по-разному.
Если не ошибаюсь, принцип "конкурентной работы" был использован при разработке шестой версии антивируса касперского...
И еще о конкуренции и командах.
Основываясь на своем опыте, как на гражданском, так и на армейском, рискну утверждать следующее:
конкуренция между членами команды отрицательно влияет на деятельность команды, в то время как здоровая конкуренция между командами или представителями команд, в большинстве случаев, оказывает положительное влияние на деятельность этих команд.
Завидую людям, которые могут себе позволить никуда не спешить.
Здравствуйте, Aikin, Вы писали:
M_E>>Я замечаю, что некоторые разработчики не проявляют особо рвения — начинают опаздывать, подолгу пить чай, курить, невнимательно писать код и пр., хотя, я думаю, способны на большее. Не все конечно, но некоторые — да. A>Да блин, когда уже мэнеджеры поймут, что работа программиста ТВОРЧЕСКАЯ (хорошего программиста)! Соотношение обдумывания и кодирования примерно 70:30 (хотя все зависит от задачи). Кроме того это не копание ямы -- если не с лопатой и не копаешь, то не работаешь.
Кстати, про соотношение обдумывания и кодирования ты не прав. Во-первых, это зависит от разработчика. Во-вторых, время кодирования замерять временем "ввода информации в ЭВМ" некорректно — это тупо скорость печати, надо его замерять вместе с отладкой. В этом случае, раскладка будет у новичков и студентов 5-15% на проектирование, у более опытных парней и девчонок оно дойдет до 30-40%, и этот показатель уже считается хорошим. В целом, чем более опытен разработчик, тем больше времени он тратит на проектирование. Но я думаю, у тебя в среднем меньше 70%. А у других — совершенно точно меньше.
Что, впрочем, не отменяет твоего тезиса — думать надо в том числе и при кодировании, и при отладке, и совсем не обязательно торчать при этом перед монитором. Не машинистка, чай, со слепой печатью 200 знаков в минуту.
Здравствуйте, ironwit, Вы писали:
I>такого не бывает. никто не хочет больше и быстрее работать тем более за деньги. вот когда денег более — менее хватает, тогда можно за интерес. У программистов зарплата средняя по рынку или ниже?
Средняя.
Здравствуйте, 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. Уровень вашей удовлетворенности существующей системой?
Это достаточно объемные вопросы.
Вы действительно хотите чтобы я их тут расписал?
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>как там с водой на рабочем месте (чистая \ из крана), чай кофе?
Всегда горячая вода, чай и кофе.
TL>Вызывает интерес замечательная корреляция пунктов 3) и 5) — имхо, "создать комфортную обстановку на рабочем месте" и "ввести систему отчетности" — прямо противоположные вещи.
комфортная обстановка нужна тем людям у которых есть какие-то причины помимо денег (вернее конкретной зарплаты, а не денег и карьерного роста вообще) для упорной работы
а отчеты нужны для серой массы, чтобы комфортная обстановка созданная для максимального раскрытия потенциала первых, не расхолаживала серую массу, работающую за конкретную зарплату получаю в конце месяца
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Kuzmenko_A, Вы писали:
AL>Вы всерьез считаете, что разработчики включатся в борьбу за "рост прироста функционала", "снижение кол-ва багов на единицу функционала" и т.п., и от этого будут иметь более высокую мотивацию? Что ж, спорить не буду, тем более помню, как лет 8 назад народ сильно вдохновлялся на борьбу с рутиной после прочтения, скажем, какой-нибудь Extreme Programming Explained и т.п. По моему опыту, единственное, что можно сделать в описанных в начале топика условиях, это минимизировать влияние имеющихся демотивирующих факторов и ни в коем разе не вносить новых, каковых в этой теме уже назвали предостаточно. Фиксированный оклад при отсутствии премиальных (или при чисто символических премиальных), кстати, является прекрасным демотиватором, что бы Вы не говорили про "деньги -- это не главное". Но у менеджера среднего звена здесь обычно практически нет рычагов воздействия на ситуацию.
Не согласен. Деньги имеют конечно же важное мотивирующее значение, но они не единственный мотивирующий фактор и это факт. Я точно не помню как называлась одна из ранних теорий мотивации, которая основывалась чисто на финансовых предпосылках, но она потерпела крах. Во первых потому что деньги имеют порог насыщения и для сохранения эффекта необходимо будет вводить очень значительные премии. Во вторых потому что всегда есть потребности в признании и тд, и вот они могут реализовываться через не финансовые варианты мотивации. Задача менеджера среднего звена как раз максимально использовать доступные не финансовые мотиваторы, ну и если есть возможность то и финансовые.
А отговорка нет денег для мотивации я считаю подходит только для малограмотного руководства.
Здравствуйте, Vlad_SP, Вы писали:
V_S>1. Нафига это нужно тебе лично? Что это дает именно тебе? Допускаются любые ответы по существу, включая "продвижение по службе", "повышение зарплаты", "мой начальник будет доволен" и т.п.
Дело в том, что проект, которым я руковожу, я создал практически с нуля, начав работать всего с одним программистом. Сейчас в группе 17 человек. Поэтому прежде всего я душой болею за все, что сделано и хочу, чтобы он развивался.
Кроме того есть, конечно и более прагматичный интерес — проект этот не сторонний, т.е. у нас есть наши клиенты, которые платят деньги, на которые мы в конечном счете существуем. Поэтому если мы будем проигрывать конкурентам, бы будем терять клиентов. Ну а дальше сами понимаете что может быть с проектом и с нами А других софтверных контор в нашем городе нет.
V_S>2. Нафига это нужно твоим подчиненным?
Собственно этот вопрос я здесь и обсуждаю. Как сделать так, чтобы им это было нужно.
V_S>3. Что ты можешь предложить своим подчиненным как компенсацию за "повышение объема выполняемых работ" и "больше сервиса пользователям и клиентам"? Ведь нет никаких сомнений, что они будут тратить больше сил/времени/нервов/мозгов... etc. на работу, а что при этом получат взамен? Какова компенсация?
Вот и опять — это тот вопрос, который я пытаюсь здесь решить.
Здравствуйте, Kuzmenko_A, Вы писали:
K_A>Не согласен. Деньги имеют конечно же важное мотивирующее значение, но они не единственный мотивирующий фактор и это факт. Я точно не помню как называлась одна из ранних теорий мотивации, которая основывалась чисто на финансовых предпосылках, но она потерпела крах. Во первых потому что деньги имеют порог насыщения и для сохранения эффекта необходимо будет вводить очень значительные премии. Во вторых потому что всегда есть потребности в признании и тд, и вот они могут реализовываться через не финансовые варианты мотивации. Задача менеджера среднего звена как раз максимально использовать доступные не финансовые мотиваторы, ну и если есть возможность то и финансовые.
На всякий случай еще раз повторю свою мысль: фиксированный оклад при отсутствии премиальных (или при чисто символических премиальных), кстати, является прекрасным демотиватором. А Вы, пожалуйста, еще раз уточните, с чем именно Вы не согласны.
тем более за деньги. вот когда денег более — менее хватает, тогда можно за интерес. У программистов зарплата средняя по рынку или ниже?
В этот момент лучшей мотивацией было-бы, "Слухай, да чихать на эту грёбаную компанию, акции, проекты и т.д., пойдем попьем пивка и поговорим как мужчины а не как роботопрограммеры". Конечно, общение с людьми это сложно. А что ты хотел? Ты манагер, ты обязан делать так чтобы тебя любили а не вводить какие-то книжные нормативы и устои которые все ненавидят. 
"Всё что не убивает нас, делает нас сильнее..."
