Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 164
что за утопическое восприятие «сотрудник — партнер».
Сотрудник раб и батрак с амбициями. Новый гугл-офис не вырастить уже, а денег зарабатывать хочется хозяину.
Ваша точка зрения «снизу» и она имеет свои доводы, конечно — но попробуйте узнать точку зрения «верха», от чего они избавились потеряв 8 программистов и 2 проекта? Может они спаслись от 3 миллиардов убытков?)
Сотрудник раб и батрак с амбициями. Новый гугл-офис не вырастить уже, а денег зарабатывать хочется хозяину.
Ваша точка зрения «снизу» и она имеет свои доводы, конечно — но попробуйте узнать точку зрения «верха», от чего они избавились потеряв 8 программистов и 2 проекта? Может они спаслись от 3 миллиардов убытков?)
Раб и батрак — это тот, кто не может взять и уйти.
А точка зрения верха врядли должна интересовать разумных людей, так как верх сам себя скомпрометировал: ставить девочку считать трудозатраты программистов и тестировщиков — это то же самое, что измерять радиационный фон градусником.
А точка зрения верха врядли должна интересовать разумных людей, так как верх сам себя скомпрометировал: ставить девочку считать трудозатраты программистов и тестировщиков — это то же самое, что измерять радиационный фон градусником.
Неверное сравнение. Раб бесплатен, а батрак по определению пашет за копейки.
Принимая на работу сотрудника, я ожидаю получить от его деятельности прибыль. Разумеется, он должен приносить прибыли больше, чем получит зарплаты. Но он этого ожидает, потому что я создаю ему условия для получения заработка. Если бы он мог создать такие условия сам, то не стал бы на меня работать.
Значит наши отношения именно партнерские: я ему создаю условия для работы и получения вознаграждения за эту работу, а он дает мне прибыль. Что это, если не партнерство?
Принимая на работу сотрудника, я ожидаю получить от его деятельности прибыль. Разумеется, он должен приносить прибыли больше, чем получит зарплаты. Но он этого ожидает, потому что я создаю ему условия для получения заработка. Если бы он мог создать такие условия сам, то не стал бы на меня работать.
Значит наши отношения именно партнерские: я ему создаю условия для работы и получения вознаграждения за эту работу, а он дает мне прибыль. Что это, если не партнерство?
Я не совсем понял, о чем ваш комментарий. Что вы предлагаете?
Сотрудник — не раб и не батрак. Сотрудник — это, прежде всего, человек, который помогает компании становиться сильнее, и не важно — замдиректора это или уборщица. Относитесь к людям уважительнее.
Сотрудник — не раб и не батрак. Сотрудник — это, прежде всего, человек, который помогает компании становиться сильнее, и не важно — замдиректора это или уборщица. Относитесь к людям уважительнее.
Один из погибших проектов — автоматизация учета оборотной тары на 8 (восьми) шоколадных фабриках «Марс». Убытки, говорите?
Это точка зрения «с середины».
Что касается того, что сотрудник, дескать, не партнёр, а батрак с амбициями.
Если цинично, то да, это так.
Но амбиции — это полезная энергия. И тебе, как руководителю, решать, что ты сделаешь с ней.
Либо ты противопоставишь амбиции сотрудника и свои, либо сделаешь так, чтобы его амбиции совпали с твоими.
Все мотивационные приемы, схемы и программы придуманы для того, чтобы амбиции сотрудника двигали компанию, а не тормозили.
Это точка зрения «с середины».
Что касается того, что сотрудник, дескать, не партнёр, а батрак с амбициями.
Если цинично, то да, это так.
Но амбиции — это полезная энергия. И тебе, как руководителю, решать, что ты сделаешь с ней.
Либо ты противопоставишь амбиции сотрудника и свои, либо сделаешь так, чтобы его амбиции совпали с твоими.
Все мотивационные приемы, схемы и программы придуманы для того, чтобы амбиции сотрудника двигали компанию, а не тормозили.
> Может они спаслись от 3 миллиардов убытков?
К сожалению в подавляющем большинстве виденных мною ситуаций, «верх» вообще не думает над этим…
Постоянно наблюдаю просто феерический тупизьм. Например уволили кассира. Ей не нравилось, что фирма разрослась за последние 2 года очень сильно и работы очень много прибавилось. Попросила прибавки к ЗП. Ее уволили… типа наглая. Взяли на ее место девочку. Она «не тянет»… взяли ей помощницу… они в двоем еле еле справляются… ибо уволенный кассир был профессионалом и все делала очень быстро и без ошибок.
В результате ЗП этих девочек уже в 2.5 раза превышает ЗП уволенного кассира. Т.е. вместо того чтобы повысить проверенного сотрудника берут новых…
И это лишь малюсенький пример.
Есть примеры кода вместо 1 поф глав буха и двух ее помощниц, которые тянули группу компаний — брали 8!!! человек и они не справлялись…
В общем я не видел компаний (а работал с крупными в нашем регионе… это >1000 человек) где «верха» реально о чем-то задумывались кроме вопроса «скока упало на счет ?»… мог бы описать просто феерическую тупизну и убытки измеряемые миллионами от этого… но штука в том, что кроме миллионов убытков у них так же миллионы прибыли и пока они что называется в плюсе их ничего не волнует. А решают на местах мелкие начальники которым важно только осознание своей мелкой власти…
К сожалению в подавляющем большинстве виденных мною ситуаций, «верх» вообще не думает над этим…
Постоянно наблюдаю просто феерический тупизьм. Например уволили кассира. Ей не нравилось, что фирма разрослась за последние 2 года очень сильно и работы очень много прибавилось. Попросила прибавки к ЗП. Ее уволили… типа наглая. Взяли на ее место девочку. Она «не тянет»… взяли ей помощницу… они в двоем еле еле справляются… ибо уволенный кассир был профессионалом и все делала очень быстро и без ошибок.
В результате ЗП этих девочек уже в 2.5 раза превышает ЗП уволенного кассира. Т.е. вместо того чтобы повысить проверенного сотрудника берут новых…
И это лишь малюсенький пример.
Есть примеры кода вместо 1 поф глав буха и двух ее помощниц, которые тянули группу компаний — брали 8!!! человек и они не справлялись…
В общем я не видел компаний (а работал с крупными в нашем регионе… это >1000 человек) где «верха» реально о чем-то задумывались кроме вопроса «скока упало на счет ?»… мог бы описать просто феерическую тупизну и убытки измеряемые миллионами от этого… но штука в том, что кроме миллионов убытков у них так же миллионы прибыли и пока они что называется в плюсе их ничего не волнует. А решают на местах мелкие начальники которым важно только осознание своей мелкой власти…
Это достаточно частый пример управления, когда работу одного профессионального сотрудника выполняют пятеро студентов, которые получают зарплату этого одного, поделенную на всех.
Причем, они не справляются, но их не гонят. Я долго пытался выяснить, почему так.
Дело просто в том, что эти студенты, в отличие от классного специалиста, послушны, управляемы и не задают неудобных вопросов. По какой-то причине в сегодняшнем российском бизнесе это почитается за ценность.
Причем, они не справляются, но их не гонят. Я долго пытался выяснить, почему так.
Дело просто в том, что эти студенты, в отличие от классного специалиста, послушны, управляемы и не задают неудобных вопросов. По какой-то причине в сегодняшнем российском бизнесе это почитается за ценность.
это все отложенный успех
Не согласен с вами. есть конторы, которые именно специализируются на том что нанимают на работу низко квалифицированную рабочую силу, типа студентов. Толку от них в проекте мало, но зато из-за того, что им платят маленькую зарплату, есть возможность поднять оклады ведущим разработчикам, ведь бюджет проекта фиксирован. Вот и получается-несколько ведущих разработчиков получают более-менее прилично, зато тянут на себе весь проект, работая как проклятые. А студенты выступают в роли заполнителя. Схема убогая и примитивная, но в нынешних условиях, когда хозяин не в коем случае не хочет увеличивать бюджет проекта, зато хочет все быстро и в срок-кое как работает
Разница между студентом и профессионалом в мотивации. Для студента нормально вкалывать за копейки потому что он для себя решает следующие задачи (и эти задачи отвечают его целям):
1) набраться практического опыта
2) получить хоть какой-нибудь стаж работы
3) осмотреться-приглядется
4) подработка
Поэтому студент и не в обиде что он работает «за копейки», потому что он замечательно двигается к целям, к успеху в своей жизни. Через годик-другой он будет уже не студент, а человек хоть с минимальным, но опытом работы, но это будет уже другая история, и другая мотивация.
У профессионала же, у которого за плечами годы работы, по жизни мотивация совершенно другая. По сути с каждым настоящим ценным профессионалом действительно приходится индивидуально договариватся. И это тоже нормальный процесс — профессионал, у которого 10 лет за плечами, может выбирать что для него наиболее интересно, и чтобы его заинтересовать, нужно «торговаться».
Кстати, 70-80% проблем с управлением персоналом иногда возникают из-за того, что просто HR забывают учитывать мотивацию (А мотивация может быть действительно очень разной: так например, финдиректору в качестве стимуляции продуктивной работы может быть интересно получить кусочек акций компании, а вот уборщица врядли поймет зачем эти акции ей нужны и уж точно врядли поможет лучше протирать полы).
Кстати, насчет плюсов студентов для работодателя. Есть еще один немаловажный плюс, кроме «дешевизны»: можно применять принцип «старателя», просеивая тонны песка в поисках золотых песчинок. Для «студенчества», характерна текучка (сегодня одни, завтра другие). Так вот, когда за год через твою фирму проходят сотни студентов, можно легко подмечать наиболее толковых и делать им предложение от когорого трудно отказаться — забирать их «на повышение» (а отказаться от такого предложения действительно трудно — другие фирмы молодому студенту без опыта работы ничего путного не предложат).
1) набраться практического опыта
2) получить хоть какой-нибудь стаж работы
3) осмотреться-приглядется
4) подработка
Поэтому студент и не в обиде что он работает «за копейки», потому что он замечательно двигается к целям, к успеху в своей жизни. Через годик-другой он будет уже не студент, а человек хоть с минимальным, но опытом работы, но это будет уже другая история, и другая мотивация.
У профессионала же, у которого за плечами годы работы, по жизни мотивация совершенно другая. По сути с каждым настоящим ценным профессионалом действительно приходится индивидуально договариватся. И это тоже нормальный процесс — профессионал, у которого 10 лет за плечами, может выбирать что для него наиболее интересно, и чтобы его заинтересовать, нужно «торговаться».
Кстати, 70-80% проблем с управлением персоналом иногда возникают из-за того, что просто HR забывают учитывать мотивацию (А мотивация может быть действительно очень разной: так например, финдиректору в качестве стимуляции продуктивной работы может быть интересно получить кусочек акций компании, а вот уборщица врядли поймет зачем эти акции ей нужны и уж точно врядли поможет лучше протирать полы).
Кстати, насчет плюсов студентов для работодателя. Есть еще один немаловажный плюс, кроме «дешевизны»: можно применять принцип «старателя», просеивая тонны песка в поисках золотых песчинок. Для «студенчества», характерна текучка (сегодня одни, завтра другие). Так вот, когда за год через твою фирму проходят сотни студентов, можно легко подмечать наиболее толковых и делать им предложение от когорого трудно отказаться — забирать их «на повышение» (а отказаться от такого предложения действительно трудно — другие фирмы молодому студенту без опыта работы ничего путного не предложат).
Это просто другая «коллизия, в которую попадает коллективный эгрегор»: с одной стороны мы боремся, чтобы квалификация сотрудников увеличивалась (увеличивается их производительность), с другой стороны мы боремся, чтобы на любой участок работы можно было бы поставить сотрудника низкой квалификации (не нужно искать суперпрофи, которого придётся учить год — можно научить вчерашнего выпускника ПТУ за два часа по шаблонной инструкции выполнять действия, для выполнения которых не нужно включать головной мозг)
В той же ИТ-индустрии: клепать веб-сайты желательно на одном и том же движке/фреймворке, быстро как печь пирожки — а не каждый проэкт заново становиться уникальным специалистом по какому-то новому движку. Экономия, понимаешь.
Поверх этой коллизии много чего ещё поверх накладывается. Умные-квалифицированные реально востребованы — поэтому утекают в более дорогие места, а то и за границу. Поэтому в России часто просто приходится делать ставку на быдло.
В той же ИТ-индустрии: клепать веб-сайты желательно на одном и том же движке/фреймворке, быстро как печь пирожки — а не каждый проэкт заново становиться уникальным специалистом по какому-то новому движку. Экономия, понимаешь.
Поверх этой коллизии много чего ещё поверх накладывается. Умные-квалифицированные реально востребованы — поэтому утекают в более дорогие места, а то и за границу. Поэтому в России часто просто приходится делать ставку на быдло.
согласен. сам был свидетелем-два ведущих разработчика попросили прибавку, им ничего не прибавили и они ушли в другую фирму. Взяли двух новых, на ту зарплату, которую просили старые разработчики! Причем эти новые за пол года наработали то всего пару документов, типа пока они изучают проект.
По-моему для России типичная ситуация «Попросил повышения ЗП и/или должности — уволен „по собственному“ — берут на твое место нового на ту ЗП и/или должность, что просил, а то ещё больше-выше»
Какое-то время назад среднему программеру было проще уволиться с повышением чем поднять зарплату.
Соответственно куча народу болталась между несколькими компаниями туда-обратно :)
Соответственно куча народу болталась между несколькими компаниями туда-обратно :)
Ну, эта система существовала ооочень давно. Едва ли что не с досоветских времен… ну, как пример, когда мой отец работал (это о далеких советских временах) в облздравотделе простым начальником отдела, то чтобы стать первым заместителем начальника обл.управления ему пришлось идти поработать два годика в областную больницу первым замом и, уже оттуда, возвращаться на должность первого зама начальника управления, а чтобы стать начальником областного управления пришлось уходить на главного врача и потом возвращаться т.к. прямого повышения никогда не было (оно и не поощрялось да и не было его) и вот только оттуда (с начальника управления) можно было попасть на нормальную должность в министерство. Т.ч. путь повышений был ВСЕГДА тернист и не прямолинеен… точно так же я могу привести себя как пример: я когда-то (с громадными сложностями и используя знакомства) перешел с должности начальника отдела на первого зам.ген.директора, — кажется обратный пример, да? Да. Но при этом долго я там удержаться не смог (по сути только и успел-то обзавестись полезными знакомствами да и все :))) — быстро заменили другим сотрудником со стороны… ну и я перешел в другую контору :)
Сам однажды уволился по такой схеме. Сначала несколько месяцев не могли найти мне замену, в это время мои обязанности пришлось выполнять зам. директора, потом нашли человека, которому сходу дали больше чем мне, но его еще пришлось пол года доучивать.
Честно говоря, я слабо понимаю логику такого поведения.
Честно говоря, я слабо понимаю логику такого поведения.
Логика очень простая — в стабильной ситуации поднять людям зарплату очень сложно.
А в случае потери квалифицированных кадров и рисков завалить работу это уже простое «авральное» решение.
К сожалению линейному руководству сложно обьяснить стоимость рисков.
А в случае потери квалифицированных кадров и рисков завалить работу это уже простое «авральное» решение.
К сожалению линейному руководству сложно обьяснить стоимость рисков.
может они боялись что если вам поднять-всей конторе поднимать придется?
Мне так сказали — сейчас ты 10% попросишь, через пару месяцев ещё 30, и т. п. Если не давать, так уйдёшь сам. Лучше в плановом порядке тебя поменять на того, кто сразу наглеть не будет, а годик-другой поработает как ты.
Я в тот момент работал в полиграфии (очень специфическая допечатная подготовка), и стоимость ошибки легко могла в несколько раз перекрыть все, что я заработал на этой фирме за два года. При этом въехать в тему довольно сложно, а перестать ошибаться — еще сложнее. В итоге получилось, что я ушел, а потом они пол года рисковали большими суммами, пока учился новый человек.
Проблема в том, что как правило, на верху сидит бизнесмен, который мало что понимает в процессе разработки ПО. Для него что программист, что молотобоец-все едино. Для них разработка ПО это то же что собрать из деталей газонокосилку или выкопать канаву. Слова — разработка требований, тестирование, рефакторинг, портирование вгоняют их в глубокое уныние. Идеальный руководитель-это сам бывший разработчик, которому не надо объяснять, что проекту нужен bug tracking, source control, build system и так далее
А бизнесмен и не должен понимать слов «разработка требований» и пр. Это обязанность специалиста или менеджера проекта. Бизнесмен должен управлять рисками.
Вот именно! Бизнесмен должен свети риск провала проекта к нулю! А чтобы это сделать, ему или самому разбираться в разработке ПО, или нанять менеджера, и слушать что он скажет
Да, не должен… Но так какого хрена он нанял меня, специалиста, и не прислушивается к моему мнению ????
Логично предположить, что нанимая специалиста бизнесмен хочет решать какую-то задачу? Ну так взял спеца — дай ему решать эту задачу! Какого мешать ему делать свою работу?
Так мало того… они потом еще и удивляются результату… и искренне причем…
Логично предположить, что нанимая специалиста бизнесмен хочет решать какую-то задачу? Ну так взял спеца — дай ему решать эту задачу! Какого мешать ему делать свою работу?
Так мало того… они потом еще и удивляются результату… и искренне причем…
Бизнесмен должен управлять финансовыми потоками. Риски — издержки управления потоками.
Я потом хотел исправить на «финансовыми потоками и рисками» :) Риски — это все-таки не издержки, а ограничения, на мой взгляд.
В моем посте под рисками следует понимать именно управление рисками. Управляя потоками бизнесмен по-любому сталкивается с рисками. Это как плотина на пути финансовых потоков. Да, они являются ограничением.
Управление рисками немного из другой области. Размер финансового потока рисковику не важен, а важен процесс минимизации рисков и его результат. Бизнесмен может выбирать между разными стратегиями минимизации рисков, но его цель в другом — умножение капитала путем перераспределения денежных потоков.
Управление рисками немного из другой области. Размер финансового потока рисковику не важен, а важен процесс минимизации рисков и его результат. Бизнесмен может выбирать между разными стратегиями минимизации рисков, но его цель в другом — умножение капитала путем перераспределения денежных потоков.
бизнесмен создает риски, а управляет и минимизирует риски — менеджер
Проблема в том что как раз управлять рисками топы почему-то не умеют. Они либо его принимают либо устраняют, а вот принять адекватные меры для снижения уровня риска — это почему-то в голове большого человека не приживается.
Вообще-то именно для этого во многих конторах и существует такая должность «технический директор». То есть человек, который разбирается в технических тонкостях, тем не менее действует на уровне управленческих решений.
А технические тонкости есть в любом деле, в этом Software Development не уникально, в том же «сборе из деталей газонокосилки» не меньше технических тонкостей.
Так вот, если «бизнесмену» вы можете навешать лапшу на уши про трудности рефакторинга, то техдиректор он сам вас отрефакторит по рефакторингу и отдебажит вдоль и поперек.
А технические тонкости есть в любом деле, в этом Software Development не уникально, в том же «сборе из деталей газонокосилки» не меньше технических тонкостей.
Так вот, если «бизнесмену» вы можете навешать лапшу на уши про трудности рефакторинга, то техдиректор он сам вас отрефакторит по рефакторингу и отдебажит вдоль и поперек.
Ну, вообще-то, не совсем так. Управленец — это совсем особый склад ума и, по сути, таких людей надо отдельно выбирать и отдельно учить в ВУЗах. Управленец и бизнесмен — это совсем-совсем разные люди. Нормальный управленец это, по сути, тот же завхоз, но по работе с людьми. Я успел побыть и тимлидом и прорабом на стройке да и на гос.службе был совсем не мало т.ч. могу с уверенностью сказать, что, в принципе, что программист, что молотобоец — все едино :) А вот действительно хороший программист сможет быть хорошим руководителем только в команде, которой, по сути, управлять и не надо… но такие команды бывают в основном только в идеальных мирах, а у нас, обычно, все намного сложнее и приземленнее и приходится… много чего приходится делать, что подчиненным не нравится.
Такой подход годится для владельца пивного ларька, но никак не для крупной компании.
Сам лично был свидетелем развала фирмы из-за тотального идиотизма директора. Из-за нежелания идти навстречу сотрудникам он сначала растерял всех своих менеджеров, затем СЕО-отдел целиком, а потом и всех опытных программистов. А в довершение всего отполировал все системой мотивации. Как итог — из программеров там только вчерашние стажеры, единственный менеджер, работающий с зарубежкой, уходит, а директор в кругах программистов города уже имеет дурную славу. Компания умерла.
Сам лично был свидетелем развала фирмы из-за тотального идиотизма директора. Из-за нежелания идти навстречу сотрудникам он сначала растерял всех своих менеджеров, затем СЕО-отдел целиком, а потом и всех опытных программистов. А в довершение всего отполировал все системой мотивации. Как итог — из программеров там только вчерашние стажеры, единственный менеджер, работающий с зарубежкой, уходит, а директор в кругах программистов города уже имеет дурную славу. Компания умерла.
Табель учета рабочего времени — выкидыш советской трудовой системы, от него надо в частных компаниях избавляться, упразднять и всячески унижать тех, кто пытается так что-то подсчитывать. ИМХО, конечно же.
Вообще, любая «компания тюремного типа» сейчас обречена либо на прозябание (если за счет контактов руководства прибыль есть: госконтракт там, поддержка), либо на скорое закрытие. При этом удивительно, как много таких контор и как они быстро самовоспроизводятся…
Вообще, любая «компания тюремного типа» сейчас обречена либо на прозябание (если за счет контактов руководства прибыль есть: госконтракт там, поддержка), либо на скорое закрытие. При этом удивительно, как много таких контор и как они быстро самовоспроизводятся…
Все эти утверждения спорны. Зарплата ни в каком виде не является самостоятельной мотивацией. Какую бы схему вы не выбрали. Адекватность руководства в принципе — это самое главное.
Можно получать фиксированную сумму в месяц и быть счастливым от осознания того, что если будешь хорошо работать, то адекватное начальство заметит и похвалит(например денежно).
А можно работать сдельно и проклинать начальство, потому что за твою мегаидею в разработке того же ТЗ они не заплатили ничего, а заплатили за «ТЗ целиком».
Можно получать фиксированную сумму в месяц и быть счастливым от осознания того, что если будешь хорошо работать, то адекватное начальство заметит и похвалит(например денежно).
А можно работать сдельно и проклинать начальство, потому что за твою мегаидею в разработке того же ТЗ они не заплатили ничего, а заплатили за «ТЗ целиком».
Полностью с вами согласен. есть очень много способов мотивации, но в нашей действительности часто одно подменяет другое. Однажды на моей старой работе участникам какого-то проекта на собрании за успехи вручили памятные доски. Приятно, но самое то главное-премий им за это не дали! Подумали-досками обойдетесь.
Если на работе поссорился с тем, кто считает твою зарплату или премию — туши свет.
Даже, если ты лучший работник отдела.
Думаю, бонусы надо давать на отдел, а в нем уже разберутся со слабым звеном самостоятельно (при условии, что это не чем-нибудь протеже).
Правильно поступили те, кто уволились.
Даже, если ты лучший работник отдела.
Думаю, бонусы надо давать на отдел, а в нем уже разберутся со слабым звеном самостоятельно (при условии, что это не чем-нибудь протеже).
Правильно поступили те, кто уволились.
Давая бонусы на отдел и предлагая им самим разобраться сколько кому выделять есть риск нарваться на большие неприятности. Когда бонус приходит каждому лично то никто особенно не волнуется. Ну да, начальство решило, если уж разбираться — то с ним. А если делить внутри отдела сразу начнутся вопросы кто сколько сделал и почему ему больше чем мне.
Было в советское время такое понятие КТУ — коэффициент трудового участия. По умолчанию у всех 1,0, на собраниях решали кому сколько ставить, а руководитель утверждал бля бухов. Или менял что-то, но в открытую.
В вашем рассуждении есть пункты (предпосылки) которые часто не выполняются. Во всяком, не выполняются в тех IT фирмах, о которых я знаю:
1. Менеджеры проектов не могут влиять и контролировать финансирование проекта. Поэтому и возможность ими перечисления с бюджета проекта зарплатных денег — это утопия.
2. Работники многие будут скорее не мотивированы, а недовольны — большинство привыкли к фиксированным ставкам зарплаты, и планируют свой бюджет из этого расчета. Ваша схема возможно сможет оптимизировать затраты работадателя, а вот что касается премий и увеличения зарплаты (премии в реальном времени) из-за отличной работы — ой не верю я.
3. К сожалению, большинство работодателей (за счастливым исключением немногих) считают что работник (прежде всего касается работников первой линии, куда включаются и программисты, тестировщики, дизайнеры и тыды и тыпы) — не столько партнер и человек, сколько рабочий ресурс. Соответственно ресурс должен работать как лампочка — на максимуме. Если работает плохо — или на него меньше тратят, или его выкидывают и заменяют новым. Про премии лампочкам за повышенную яркость никогда не слышал. Поэтому и см. пункт 2 про премии.
Схема действительно хорошая, с точки зрения логики. Вот только психологии как работодателя, так и работника — не учитывает.
1. Менеджеры проектов не могут влиять и контролировать финансирование проекта. Поэтому и возможность ими перечисления с бюджета проекта зарплатных денег — это утопия.
2. Работники многие будут скорее не мотивированы, а недовольны — большинство привыкли к фиксированным ставкам зарплаты, и планируют свой бюджет из этого расчета. Ваша схема возможно сможет оптимизировать затраты работадателя, а вот что касается премий и увеличения зарплаты (премии в реальном времени) из-за отличной работы — ой не верю я.
3. К сожалению, большинство работодателей (за счастливым исключением немногих) считают что работник (прежде всего касается работников первой линии, куда включаются и программисты, тестировщики, дизайнеры и тыды и тыпы) — не столько партнер и человек, сколько рабочий ресурс. Соответственно ресурс должен работать как лампочка — на максимуме. Если работает плохо — или на него меньше тратят, или его выкидывают и заменяют новым. Про премии лампочкам за повышенную яркость никогда не слышал. Поэтому и см. пункт 2 про премии.
Схема действительно хорошая, с точки зрения логики. Вот только психологии как работодателя, так и работника — не учитывает.
работник… — не столько партнер и человек, сколько рабочий ресурс
К сожалению на верхнем уровне управления без такого определения не обойтись (посмотрите например продукт MS Project — там сотрудник — это именно ресурс). И изначально планирование времени на проект должно делаться с использованием сугубо циничного подхода (человекочасы), а уже потом надо смотреть на личности и учитывать опыт, умение работать и прочие положительные критерии каждого сотрудника как человека. И уже конечно без комфортной рабочей атмосферы все вышесказанное будет угнетать всех сотрудников, а с комфортной атмосферой, адекватными руководителями и удобными офисами, такой подход наоборот будет систематизировать учет и ведение проектов на всех уровнях (сотрудники не будут думать что к ним относятся как к ресурсам, выжимая все соки, а руководители будут иметь возможность адекватного планирования трудозатрат).
Столкнулся как-то с учетом трудодней в администрации одного из городов. В нем завели специальный отдел, который начал считать эффективность других отделов и выдавать оценки. От оценок зависят размеры премий.
Одним из критериев эффективности, к примеру, было число обработанных обращений граждан. Чем большему числу людей ответил на вопросы — тем выше твоя эффективность, оценка и премия. При этом в силу природы вещей разным отделам доставалось разное число заявителей. Но отдел оценки это не смущало.
В определенный момент во всех отделах резко подскочило число обработанных обращений граждан. Люди в городе как будто взбесились, начав заваливать все отделы вопросами. Нам-то с вами понятно, что сотрудники администрации начали сами выдумывать обращения и отвечать на них. А вот отдел оценки до сих пор считает не время, затраченное на рассмотрение обращений (а они разноплановы и требуют до полугода на решение), а тупо их число.
На бумаге эффективность стала заоблачной, премии выросли, сотрудники стали суперменами, работающими по 20 часов в сутки. А в прохладных кабинетах почему-то по-прежнему застой, изредка слышны ленивые клики мышкой и вот-вот закипит чайник. В том числе, и в отделе оценки эффективности.
Одним из критериев эффективности, к примеру, было число обработанных обращений граждан. Чем большему числу людей ответил на вопросы — тем выше твоя эффективность, оценка и премия. При этом в силу природы вещей разным отделам доставалось разное число заявителей. Но отдел оценки это не смущало.
В определенный момент во всех отделах резко подскочило число обработанных обращений граждан. Люди в городе как будто взбесились, начав заваливать все отделы вопросами. Нам-то с вами понятно, что сотрудники администрации начали сами выдумывать обращения и отвечать на них. А вот отдел оценки до сих пор считает не время, затраченное на рассмотрение обращений (а они разноплановы и требуют до полугода на решение), а тупо их число.
На бумаге эффективность стала заоблачной, премии выросли, сотрудники стали суперменами, работающими по 20 часов в сутки. А в прохладных кабинетах почему-то по-прежнему застой, изредка слышны ленивые клики мышкой и вот-вот закипит чайник. В том числе, и в отделе оценки эффективности.
Это тактика «освоения бюджетов».
Дело в том, что городские бюджеты построены по расходной модели.
То есть, средства, выделяемые на какое-то учреждение, рассчитываются исходя из его расходов.
Поэтому во всех администрациях появляются новые странные отделы, в сельсоветах растёт число «врачей и учителей», время от времени появляются проекты типа «брендинга территорий» (в ходе которого выделяются миллионы на разработку нового имиджа города, про который потом все сразу забывают).
Дело в том, что городские бюджеты построены по расходной модели.
То есть, средства, выделяемые на какое-то учреждение, рассчитываются исходя из его расходов.
Поэтому во всех администрациях появляются новые странные отделы, в сельсоветах растёт число «врачей и учителей», время от времени появляются проекты типа «брендинга территорий» (в ходе которого выделяются миллионы на разработку нового имиджа города, про который потом все сразу забывают).
Оплата труда, сложная и смешанная из очень разносортных материалов вещь.
Не даром есть специальные методики мотивации, которые позволяют переложить на «совесть» сотрудника — его отношение к работе и зарядить на производительность «формульными» методами (премии, бонусы...).
Кнут, пряник и ласковое слово.
Формализовать эту задачу невозможно, потому что:
1. Люди не роботы. Они устают, болеют, да… даже муза не посещает порой и это должно быть заложено в расчет.
2. Люди разные. Либо подход ищи, либо команду подбирай по человеческим качествам, а не только профессиональным.
Не даром есть специальные методики мотивации, которые позволяют переложить на «совесть» сотрудника — его отношение к работе и зарядить на производительность «формульными» методами (премии, бонусы...).
Кнут, пряник и ласковое слово.
Формализовать эту задачу невозможно, потому что:
1. Люди не роботы. Они устают, болеют, да… даже муза не посещает порой и это должно быть заложено в расчет.
2. Люди разные. Либо подход ищи, либо команду подбирай по человеческим качествам, а не только профессиональным.
Есть распространенное мнение о человеке: дай человеку волю, и это порочное создание только и будет что валяться на диване, пить пиво, смотреть телевизор и заниматься сексом.
Мнение очень популярное, хотя и не соотвествует действительности. Естественно люди, придерживающеся такого мнения, будут всяческими способами вам «помогать» стать на истинный путь: считать ваши часы, строчки кода, количество нажатий клавиш мышки, количество операторов в вашей программе.
Но это ошибка, вызыванная недостаточным знанием психологии человека. А любая ошибка приводит к неудаче, о чем хорошо написали в статье.
Мнение очень популярное, хотя и не соотвествует действительности. Естественно люди, придерживающеся такого мнения, будут всяческими способами вам «помогать» стать на истинный путь: считать ваши часы, строчки кода, количество нажатий клавиш мышки, количество операторов в вашей программе.
Но это ошибка, вызыванная недостаточным знанием психологии человека. А любая ошибка приводит к неудаче, о чем хорошо написали в статье.
В других профессиях, может быть, по-другому, но.
«Программист сделает ровно столько, сколько он захочет сделать» (с) (rework или peopleware?)
Странно что никто не воспринимает этот факт всерьёз. Нельзя никак повлиять на производительность разработчиков. Тогда зачем пытаться? Пускай делает как хочет и когда хочет. Если результаты более или менее устраивают, платить ему примерную з/п. Не сошлись в з\п или оценках работы — до свидания. Потому что точнее оценить нельзя и зарплату справедливее не расчитать.
«Программист сделает ровно столько, сколько он захочет сделать» (с) (rework или peopleware?)
Странно что никто не воспринимает этот факт всерьёз. Нельзя никак повлиять на производительность разработчиков. Тогда зачем пытаться? Пускай делает как хочет и когда хочет. Если результаты более или менее устраивают, платить ему примерную з/п. Не сошлись в з\п или оценках работы — до свидания. Потому что точнее оценить нельзя и зарплату справедливее не расчитать.
«Программист сделает ровно столько, сколько он захочет сделать» != «Нельзя никак повлиять на производительность разработчиков»
В силах сделать так, что бы программист захотел сделать больше. Есть много мотиваторов, как материальных так и нет.
В силах сделать так, что бы программист захотел сделать больше. Есть много мотиваторов, как материальных так и нет.
Приведите пример мотиваторов.
Да, размер заработной платы — не вопрос мотивации творческого труда, это вопрос работы или не работы в этой организации на этой должности.
Да, размер заработной платы — не вопрос мотивации творческого труда, это вопрос работы или не работы в этой организации на этой должности.
Покажите ему
* отзывы счастливых потребителей или пользователей
* график роста объема продаж в привязке к новым функциям в системе
* графики уменьшения количества критических ошибок
* рост рыночной доли компании на рынке и ничтожность конкурентов
Дайте ему
* каникулы за счет организации
* спокойно отдохнуть в отпуске, не задалбывая постоянными «Шеф, у нас все пропало… Ааааааа»
* улучшение условий труда
* свободу выбора удобных инструментов труда
* пригласительные на интересные конференции
Замучаюсь перечислять…
* отзывы счастливых потребителей или пользователей
* график роста объема продаж в привязке к новым функциям в системе
* графики уменьшения количества критических ошибок
* рост рыночной доли компании на рынке и ничтожность конкурентов
Дайте ему
* каникулы за счет организации
* спокойно отдохнуть в отпуске, не задалбывая постоянными «Шеф, у нас все пропало… Ааааааа»
* улучшение условий труда
* свободу выбора удобных инструментов труда
* пригласительные на интересные конференции
Замучаюсь перечислять…
* отзывы счастливых потребителей или пользователей
Разработчик и сам знает достоинства и недостатки своего продукта. Чаще всего под давлением сроков и руководства разработчик вынужден делать то, что не делает пользователей счастливыми.
* график роста объема продаж в привязке к новым функциям в системе
* рост рыночной доли компании на рынке и ничтожность конкурентов
это всё проблемы менеджмента и отдела продаж, а не программистов.
* графики уменьшения количества критических ошибок
Графики уменьшения кол-ва критических ошибок в природе не существуют.
* каникулы за счет организации
* спокойно отдохнуть в отпуске, не задалбывая постоянными «Шеф, у нас все пропало… Ааааааа»
* улучшение условий труда
* свободу выбора удобных инструментов труда
* пригласительные на интересные конференции
Пока разработчик вынужден приходить к 8 утра, писать объяснительные в случае опоздания и необходимости отлучиться, отсиживать часы по секундомеру в системе пропусков, ему плевать на всё это.
Я кажется понимаю о каких мотиваторах вы говорите. Но все они — просто «отключение» демотиваторов.
С этим слогласен. Нужно просто не мешать.
Разработчик и сам знает достоинства и недостатки своего продукта. Чаще всего под давлением сроков и руководства разработчик вынужден делать то, что не делает пользователей счастливыми.
* график роста объема продаж в привязке к новым функциям в системе
* рост рыночной доли компании на рынке и ничтожность конкурентов
это всё проблемы менеджмента и отдела продаж, а не программистов.
* графики уменьшения количества критических ошибок
Графики уменьшения кол-ва критических ошибок в природе не существуют.
* каникулы за счет организации
* спокойно отдохнуть в отпуске, не задалбывая постоянными «Шеф, у нас все пропало… Ааааааа»
* улучшение условий труда
* свободу выбора удобных инструментов труда
* пригласительные на интересные конференции
Пока разработчик вынужден приходить к 8 утра, писать объяснительные в случае опоздания и необходимости отлучиться, отсиживать часы по секундомеру в системе пропусков, ему плевать на всё это.
Я кажется понимаю о каких мотиваторах вы говорите. Но все они — просто «отключение» демотиваторов.
С этим слогласен. Нужно просто не мешать.
Еще забыли — душ и хорошие обеды в офис! Можно еще небольшой тренажерный зал или хотя бы стол для тениса.
Душ осообенно актуален жарким летом. Тренажеры, да и любой другой повод подвигаться — позволяют разгрузить мозги быстрее чем просто сидение на диване или «пойдем покурим». Хорошие обеды в офисе необходимы чтобы человек на обед шел не в какую-то забегаловку, а обедал вместе со своими коллегами, обсуждая не только важные матчи их любимой футбольной команды, но и проблемы текущих проектов. Практика показывает что за такими обсуждениями порой принимаются важные решения.
Да, все вышеперечисленное это дополнительные накладные расходы, но они во-первых повысят продуктивность каждого члена команды, а во-вторых позволят сохранить вам ценные кадры.
Душ осообенно актуален жарким летом. Тренажеры, да и любой другой повод подвигаться — позволяют разгрузить мозги быстрее чем просто сидение на диване или «пойдем покурим». Хорошие обеды в офисе необходимы чтобы человек на обед шел не в какую-то забегаловку, а обедал вместе со своими коллегами, обсуждая не только важные матчи их любимой футбольной команды, но и проблемы текущих проектов. Практика показывает что за такими обсуждениями порой принимаются важные решения.
Да, все вышеперечисленное это дополнительные накладные расходы, но они во-первых повысят продуктивность каждого члена команды, а во-вторых позволят сохранить вам ценные кадры.
да, да — правильно. Я, к примеру, на всякие вопросы из группы типа, что вам помогло бы сделать работу лучше или что привело к тому, что какая-то работа сделана хуже — обычно отвечаю заготовленной фразой, мол, я не знаю т.к. не умею работать хуже или лучше чем я умею.
Собственно, как и вопросы о том что, мол, можем ли мы это сделать? — на такие вопросы я всегда отвечаю, что мы можем все, а что не можем мы можем тоже, но это будет стоить не менее чем… — в общем, заказчики теперь меня спрашивают: «насколько просто \ сложно \ дорого это сделать» — что есть, конечно, правильные вопросы.
Собственно, как и вопросы о том что, мол, можем ли мы это сделать? — на такие вопросы я всегда отвечаю, что мы можем все, а что не можем мы можем тоже, но это будет стоить не менее чем… — в общем, заказчики теперь меня спрашивают: «насколько просто \ сложно \ дорого это сделать» — что есть, конечно, правильные вопросы.
>>делает как хочет и когда хочет.
в таком случае, думаю справедливо будет платить ему зарплату таким же образом
в таком случае, думаю справедливо будет платить ему зарплату таким же образом
Верно. Это дворника можно уволить и найти другого который так же будет мести (хотя тут тоже можно «попасть»).
С программистами все гораздо сложнее — как правило действительно хороших программистов на рынке мало, а все которые есть уже где-то работают.
Если вы не гугл, то к вам очередь стоять не будет.
Плюс, даже если вы нашли нового хорошего специалиста — то нужно будет время, как минимум, для того чтобы человек освоился с новой работой, новыми правилами, системами и т. п.
С программистами все гораздо сложнее — как правило действительно хороших программистов на рынке мало, а все которые есть уже где-то работают.
Если вы не гугл, то к вам очередь стоять не будет.
Плюс, даже если вы нашли нового хорошего специалиста — то нужно будет время, как минимум, для того чтобы человек освоился с новой работой, новыми правилами, системами и т. п.
Если работник и работотадель не могут сойтись в оценке труда и оплате за него, других выходов нет. Однозначно и объективно оценить труд по разработке ПО нельзя, поэтому довогориться в этом случае невозможно.
зачем так все усложнять? з/п платится рыночная вот и всё.
Дополнительно, присутствие на рабочем месте можно контролировать смарт-картой на вход/выход. Кто систематически прогуливает — того систематически нагибают.
Дополнительно, присутствие на рабочем месте можно контролировать смарт-картой на вход/выход. Кто систематически прогуливает — того систематически нагибают.
а я категорически не готов дома и в нерабочее время работать. есть дела поважнее работы
вы считаете работа дома в нерабочее время принципиально больше даст вам в будущем?
Мне «сидение дома» дало одну из профессий — веб-разработчика.
Вот что значит нерабочее время? Когда работаешь, тогда и рабочее время. Я вот чаще всего работаю вечером и ночью. Уже довольно долгое время. Это что получается, я несколько лет работаю в нерабочее время? Если так, ну и что с того?
По-моему нерабочее время это когда работать не хочется =)
По-моему нерабочее время это когда работать не хочется =)
вы видимо не работаете в офисе совсем?
<rejected />
тут речь вроде про офис шла изначально?
тут речь вроде про офис шла изначально?
Да все просто. Работа \ наличие сотрудника в офисе это не регулятор эффективности, мотиватор или что-то ещё, это всего лишь вопрос доступности сотрудника для руководства в режиме 8/5, для подчиненных ~ 4/4 и, иногда, доступности для не-сотрудников в режиме ~ 3/4 (к примеру, часы приема, — но это, конечно, может очень сильно варьироваться).
Я вон, к примеру, с несколькими клиентами (их всего-то два т.к. больше, мне кажется, нереально) работаю в режиме 23/7 — работы, как таковой, вообще не много, но я гарантирую, что даже где-то в разгаре отдыха или в день похорон бабушки (а было такое дело) я всегда буду доступен для них и мы сможем спланировать работу… ну, и стоит такое удовольствие существенно дороже чем простая работа и на эффективность или, там, качество как таковое это не влияет совершенно.
Я вон, к примеру, с несколькими клиентами (их всего-то два т.к. больше, мне кажется, нереально) работаю в режиме 23/7 — работы, как таковой, вообще не много, но я гарантирую, что даже где-то в разгаре отдыха или в день похорон бабушки (а было такое дело) я всегда буду доступен для них и мы сможем спланировать работу… ну, и стоит такое удовольствие существенно дороже чем простая работа и на эффективность или, там, качество как таковое это не влияет совершенно.
Работал в компании, где «рабочее время» почти у всех было с 14-00 до 18-00, 5 дней в неделю, офис открывался в 9-00, закрывался в 23-00. Задания давались из расчёта 40 часов в неделю. 20 часов «просиди», будь добр, в офисе, остальное время хочешь утром приходи, хочешь до ночи сиди, хочешь дома работай.
Присутствие на рабочем месте — это то, что зачастую обеспечивает необходимый уровень коммуникации в команде. Поэтому это требование не является бессмысленным. А на зарплату сотрудника по-хорошему должен влияеть непосредственный начальник, который может оценить пользу, приносимую сотрудником (для девелопера это тим-лид, к примеру).
Нет, ну понятно, что бывают разные исключительные ситуации — то обычно идут навстречу и никто не будет штрафовать, но если человек регулярно нарушает принятый в организации режим (с которым его ознакомили при приеме на работу) — то меры надо принимать однозначно.
Режим нужен там, где от отсутствия человека на работе могут зависеть человеческие жизни. В таких творческих профессиях как программирование, режим не только ухудшает рабочую обстановку, но и существенно понижает производительность труда.
Все равно, даже в компаниях, где режим не лимитирован, возникает спонтанный общий режим работы. Например у нас он примерно с 11-12 до 19-20. Т.е. с 12 до 19 гарантированно большинство команды пересекается между собой. Так удобно всем.
Если у вас острое желание устраивать тотальный контроль и заставлять неукоснительно следовать бюрократическим процессам, то вам нечего делать как руководителю в ИТ сфере.
Все равно, даже в компаниях, где режим не лимитирован, возникает спонтанный общий режим работы. Например у нас он примерно с 11-12 до 19-20. Т.е. с 12 до 19 гарантированно большинство команды пересекается между собой. Так удобно всем.
Если у вас острое желание устраивать тотальный контроль и заставлять неукоснительно следовать бюрократическим процессам, то вам нечего делать как руководителю в ИТ сфере.
Есть пожалуй одно исключение, когда режим нужен девелоперам: это если у них есть договоренность, что они в определенный час перед уходом коммитятся и собирают версию.
Типа вечерней сборки Chromium.
Но если установлен web-svn или git то необходимость в присутствии не такая острая.
Типа вечерней сборки Chromium.
Но если установлен web-svn или git то необходимость в присутствии не такая острая.
Режим не нужен девелоперам. Они сами его себе придумают и будут ему следовать гораздо лучше, чем если их палкой на работу загонять. Происходит самоорганизация. Социальная составляющая человека берет верх над индивидуальной.
Главное — организация информационных потоков в команде. Команда должна постоянно что-то обсуждать: новые фичи, способы реализации, подходы, выполненные куски работы, проблемы и баги… Если человек выпадает из информационного потока, то он начинает ощущать свою беспомощность и бесполезность команде. Его производительность падает, ошибки, которые он допускает, все больше его отдаляют от команды. Как результат — человек или снова возвращается в коллектив, или увольняется.
Главное — организация информационных потоков в команде. Команда должна постоянно что-то обсуждать: новые фичи, способы реализации, подходы, выполненные куски работы, проблемы и баги… Если человек выпадает из информационного потока, то он начинает ощущать свою беспомощность и бесполезность команде. Его производительность падает, ошибки, которые он допускает, все больше его отдаляют от команды. Как результат — человек или снова возвращается в коллектив, или увольняется.
Вот организацию обмена информацинй бешено плюсую.
Приходилось работать в компании, где каждый тихонечко себе чего-то там пилил в углу, коммуницируя только через руководство между собой.
Ходят слухи, что они до сих пор разрабатывают тот же самый проект;)
Приходилось работать в компании, где каждый тихонечко себе чего-то там пилил в углу, коммуницируя только через руководство между собой.
Ходят слухи, что они до сих пор разрабатывают тот же самый проект;)
а подойти поговорить религия не позволяет? :)
Если это приветствуется — то не можно, а нужно. Но если тебя «заперли» в конуре и программист-программисту волк, то любые попытки разговорить кого-то будут расценены как попытку подсидеть, самоутвердиться за его счет, унизить профессиональные навыки и так далее.
Да и в условиях бюрократического управления компанией любые разговоры могут быть расценены как нарушение дисциплины, неэффективной работой или нежеланием работать, что незамедлительно наказывается штрафами.
Да и в условиях бюрократического управления компанией любые разговоры могут быть расценены как нарушение дисциплины, неэффективной работой или нежеланием работать, что незамедлительно наказывается штрафами.
Вы совсем какой-то трудовой лагерь описываете. валить из такой конторы надо!!!
Типичные госконторы или конторы, в которых руководители еще старой, советской закалки. Некоторые крупные корпорации таким балуются. И ничего, люди работают годами. Там просто другое поведение работника. Он соглашается на те условия и зачастую получает деньги за просиживание штанов. Минимум ответственности, условная стабильность, статус.
у меня такое впечатление что вы весьма смутно представляете себе работу реальной команды разработчиков
>>Происходит самоорганизация
Редко. Многие любят после обеда приходить и до глубокой ночи сидеть, другие в 8 утра уже на работе, а к 16 сваливают, и ни за какие ковриги не хотят менять свой график
>>Команда должна постоянно что-то обсуждать
Команда должна работать, обсуждать надо только по мере необходимости. Митинги и обсуждения выбивают программистов из фокуса
>>Происходит самоорганизация
Редко. Многие любят после обеда приходить и до глубокой ночи сидеть, другие в 8 утра уже на работе, а к 16 сваливают, и ни за какие ковриги не хотят менять свой график
>>Команда должна постоянно что-то обсуждать
Команда должна работать, обсуждать надо только по мере необходимости. Митинги и обсуждения выбивают программистов из фокуса
Конечно, только ваше представление единственно верное.
Обсуждать должны обязательно, что делают и как, во-первых происходит согласование представлений о результате (раньше кто-то не так понял или что-то упустил), во-вторых вербализация своих мыслей зачастую приводит к более быстрому и эффективному решению своей задачи.
Обсуждать должны обязательно, что делают и как, во-первых происходит согласование представлений о результате (раньше кто-то не так понял или что-то упустил), во-вторых вербализация своих мыслей зачастую приводит к более быстрому и эффективному решению своей задачи.
я не настаиваю. просто 8 лет в команде.
>>раньше кто-то не так понял или что-то упустил
для этого есть спецификации и таск-трекер. Если что-то не понял — спрашиваешь.
>>вербализация своих мыслей зачастую приводит к более быстрому и эффективному решению своей задачи
вербализация ваших мыслей отвлекает от работы других программистов. Чтобы вернуться в фокус нужно до получаса. Если весь день что-то обсуждают работа вообще стоит.
>>раньше кто-то не так понял или что-то упустил
для этого есть спецификации и таск-трекер. Если что-то не понял — спрашиваешь.
>>вербализация своих мыслей зачастую приводит к более быстрому и эффективному решению своей задачи
вербализация ваших мыслей отвлекает от работы других программистов. Чтобы вернуться в фокус нужно до получаса. Если весь день что-то обсуждают работа вообще стоит.
Если что-то не понял
Это если программист осознает, что не понял. а если не совсем правильно понял и свято уверен, что так и надо?
Так же не стоит возводить понятие фокуса в абсолют.
>>а если не совсем правильно понял и свято уверен, что так и надо?
если такое происходит регулярно, значит либо руководитель недостаточно четко ставит задачу, либо программист уходит из команды.
>>не стоит возводить понятие фокуса в абсолют
кто бывал в этом состоянии со мной согласится, кто не бывал — у вас еще все впереди.
Кроме бешеного удовольствия такое состояние в разы повышает производительность. это не миф
если такое происходит регулярно, значит либо руководитель недостаточно четко ставит задачу, либо программист уходит из команды.
>>не стоит возводить понятие фокуса в абсолют
кто бывал в этом состоянии со мной согласится, кто не бывал — у вас еще все впереди.
Кроме бешеного удовольствия такое состояние в разы повышает производительность. это не миф
Можно очень сильно производительно наделать чепухи. И потом три раза еще переделывать, так как разработчик неверно понял задание. В итоге эффективность такого разработчика будет гораздо хуже, хотя продуктивность его будет космических масштабов.
Цель — не настрочить кода, а решить задачу максимально эффективным способом. Например, если два разработчика работают над одной задачей параллельно, то они как минимум должны договориться о способах реализации, соствить ряд договоренностей, рассказать друг другу как они понимают задачу. При этом должен присутствовать руководитель разработки (тимлид, ПМ, неважно) и корректировать этих двоих, чтобы все все поняли именно так, как нужно. Но это знание не должно умереть с этими тремя, его лучше всего размножить на большую группу людей, чтобы все понимали ход мышления соседа. Короче, у нас это работает.
Цель — не настрочить кода, а решить задачу максимально эффективным способом. Например, если два разработчика работают над одной задачей параллельно, то они как минимум должны договориться о способах реализации, соствить ряд договоренностей, рассказать друг другу как они понимают задачу. При этом должен присутствовать руководитель разработки (тимлид, ПМ, неважно) и корректировать этих двоих, чтобы все все поняли именно так, как нужно. Но это знание не должно умереть с этими тремя, его лучше всего размножить на большую группу людей, чтобы все понимали ход мышления соседа. Короче, у нас это работает.
Да, очень смутно, уже четвертый год как в коматозном состоянии руковожу разработкой… :)
Самоорганизация происходит, потому что мы результатоориентированы. Никому не интересно краснеть перед командой, почему он неправильно что-то понял и сделал. Никто за это не наказывает, но психология упертая штука…
Нереально программисту работать 8 часов без остановки. Он, конечно, может проработать в таком режиме, но недолго. Как итог — человек перегорает и увольняется. Страдают все.
Самоорганизация происходит, потому что мы результатоориентированы. Никому не интересно краснеть перед командой, почему он неправильно что-то понял и сделал. Никто за это не наказывает, но психология упертая штука…
Нереально программисту работать 8 часов без остановки. Он, конечно, может проработать в таком режиме, но недолго. Как итог — человек перегорает и увольняется. Страдают все.
>>же четвертый год как в коматозном состоянии руковожу разработкой… :)
так может стоит попробовать как-то изменить схему работы? Больше отдать полномочий сотрудникам. Выделить лидеров, повесить часть ответственности на них.
Много народу-то?
>>Нереально программисту работать 8 часов без остановки.
вот тут категорически согласен.
Но есть нюанс: если человека не отвлекают, он сам может тормознуться и передохнуть, когда ему удобно, потрещать на хабре опять же. Есть силы углубиться и работать — пожалуйста. Если же кто-то постоянно дискуссию заводит, то сосредоточиться просто нереально.
Если так уж хотите обсуждать, наверное правильнее выделять под это специальное время.
так может стоит попробовать как-то изменить схему работы? Больше отдать полномочий сотрудникам. Выделить лидеров, повесить часть ответственности на них.
Много народу-то?
>>Нереально программисту работать 8 часов без остановки.
вот тут категорически согласен.
Но есть нюанс: если человека не отвлекают, он сам может тормознуться и передохнуть, когда ему удобно, потрещать на хабре опять же. Есть силы углубиться и работать — пожалуйста. Если же кто-то постоянно дискуссию заводит, то сосредоточиться просто нереально.
Если так уж хотите обсуждать, наверное правильнее выделять под это специальное время.
Порой отсутствие человека на рабочем месте может стопорить разработку. К тому же режим обычно не жесткий, просто регламентируется то рабочее время, когда человек обязан быть в офисе — например с 12 до 18, а куда сдвигать свой график — на утро или на вечер он решает сам.
у нас приблизительно такая же схема. работает. код пишется, текучка кадров маленькая.
Да, может. Если процесс разработки — жеско последовательный. Это уже проблема управленцев, что они не организовали работу так, чтобы как можно лучше параллелить процесс разработки. Еще почитайте мой ответ чуть выше.
СКУД в настоящий момент не умеет определять, прогуливает человек, или выполняет рабочие поездки.
К примеру, для нормального продажника постоянное сидение на рабочем месте — это свидетельство не его усердия, а скорее наоборот — профнепригодности. Как это объяснить СКУДу?
Соответственно, над скудом должна стоять ERP, которая будет корректировать, насколько «профильно» для данного сотрудника быть всегда на рабочем месте. Тогда это будет работать.
К примеру, для нормального продажника постоянное сидение на рабочем месте — это свидетельство не его усердия, а скорее наоборот — профнепригодности. Как это объяснить СКУДу?
Соответственно, над скудом должна стоять ERP, которая будет корректировать, насколько «профильно» для данного сотрудника быть всегда на рабочем месте. Тогда это будет работать.
А кто вовремя приходит и проводит все время на Хабре?
Нужен спец надсмоторщик, какие материалы читаются- относящиеся к делу или нет.
И надсмоторщик над надсмоторщиком, вдруг первый галки от балды ставит, а сам все время чай пьёт.
Нужен спец надсмоторщик, какие материалы читаются- относящиеся к делу или нет.
И надсмоторщик над надсмоторщиком, вдруг первый галки от балды ставит, а сам все время чай пьёт.
Если у вас типовая вакансия, то пожалуйста. Кассира мотивировать порой не нужно — написать ему правила и достаточно. От него мало, что зависит.
Но если люди в организации весьма весомы, когда от них порой напрямую или косвенно зависит доход — людей нужно мотивировать.
Чтобы человек мог больше сделать, больше вложиться, принести большую пользу компании.
Если человека поместить в жесткие рамки времени нахождения на работе и поставить это приоритетным — то он будет относиться к своим обязанностям формально и выполнять работу аналогично. Ведь ему платят за посещаемость рабочего времени, а не его старания и инициативы.
Всегда есть места, когда мотивированный человек лучше, не мотивированного:
— программист на указанный ему срок может сказать, что срок мал, он за него не успеет и сделает за три таких срока (а просрочка, допустим, произошла по вине другого отдела). Мотивированный программист скажет: «ок, хорошо, я постараюсь, поработаю в эти выходные».
— менеджер проекта не мотивированный будет делать все формально, отказываться от работы сверх его нормы.
Мотивированный будет стараться выполнить все быстрее, договориться с заказчиком, не затягивать проект и т. п.
Хотя, конечно же, каждому свое. Кому-то важна гарантированная фиксированная сумма денег и все. Ему так проще и спокойнее. А кому-то нужны перспективы и возможности, что от его работы, качества и объема напрямую зависит его размер зарплаты. Это будет мотивировать отдаваться работе на все 100.
Но если люди в организации весьма весомы, когда от них порой напрямую или косвенно зависит доход — людей нужно мотивировать.
Чтобы человек мог больше сделать, больше вложиться, принести большую пользу компании.
Если человека поместить в жесткие рамки времени нахождения на работе и поставить это приоритетным — то он будет относиться к своим обязанностям формально и выполнять работу аналогично. Ведь ему платят за посещаемость рабочего времени, а не его старания и инициативы.
Всегда есть места, когда мотивированный человек лучше, не мотивированного:
— программист на указанный ему срок может сказать, что срок мал, он за него не успеет и сделает за три таких срока (а просрочка, допустим, произошла по вине другого отдела). Мотивированный программист скажет: «ок, хорошо, я постараюсь, поработаю в эти выходные».
— менеджер проекта не мотивированный будет делать все формально, отказываться от работы сверх его нормы.
Мотивированный будет стараться выполнить все быстрее, договориться с заказчиком, не затягивать проект и т. п.
Хотя, конечно же, каждому свое. Кому-то важна гарантированная фиксированная сумма денег и все. Ему так проще и спокойнее. А кому-то нужны перспективы и возможности, что от его работы, качества и объема напрямую зависит его размер зарплаты. Это будет мотивировать отдаваться работе на все 100.
Очень интересная идея. Видел ли кто-нибудь имплементацию подобного кабинета сотрудника? Мне кажется это был бы замечательный инструмент при работе с фрилансерами.
Про лучшую систему оплаты писал Джоэл Спольски:
1) Все участники проекта работают фуллтайм на постоянной основе в штате.
2) Выплачивается фиксированная ежемесячная (или еженедельная) зарплата.
3) Зарплата повышается после каждого успешного проекта.
Это в идеале.
В реальности же не все сотрудники работают фултайм, часто приходится привлекать специалистов временно (дизайнер, флешер...), поэтому я использую такую схему:
1) Исполнитель САМ оценивает трудоёмксть каждой задачи и оценивает её в часах.
2) Исполнитель САМ назначает цену своего часа.
3) Либо я соглашаюсь с его решениями; либо мы аргументированно обсуждаем их и он вносит правки; либо я отказываюсь от его услуг (что нормально).
4) Если во время работы выясняется, что на задачу потребуется больше времени, то мы согласуем такое превышение лимита, и либо оставляем всё в недоработанном виде, либо продолжаем работу, увеличивая оценку.
5) По итогам работы исполнитель представляет отчёт с ФАКТИЧЕСКИМИ расходами времени, обычно они отличаются от первоначальной оценки: некоторые в меньшую сторону, большинство — в большую (и это нормально!).
6) Я могу поспорить с отчётом, если какие-то часы были потрачены по вине исполнителя. После согласования и принятия отчёта, я оплачиваю всю работу по утверждённой нами ранее ставке. Если у нас остались взаимные претензии, то мы просто не работаем больше. Чаще всего всё удаётся аргументированно урегулировать, все довольны.
Преимущества такой системы: ответственность исполнителя за оценку своего труда, возможность планирования времени, наглядность и понятность методики рассчёта итоговой оплаты.
Недостатки: менеджер должен иметь достаточно высокую квалификацию в предметной области исполнителя, чтобы ставить задачи и оценивать их трудоёмкость.
На практике можно сочетать обе схемы: менеджер работает на ставке (с повышением после каждого проекта, хотя бы символическим), а временные исполнители работают в почасовом режиме с этим менеджером.
1) Все участники проекта работают фуллтайм на постоянной основе в штате.
2) Выплачивается фиксированная ежемесячная (или еженедельная) зарплата.
3) Зарплата повышается после каждого успешного проекта.
Это в идеале.
В реальности же не все сотрудники работают фултайм, часто приходится привлекать специалистов временно (дизайнер, флешер...), поэтому я использую такую схему:
1) Исполнитель САМ оценивает трудоёмксть каждой задачи и оценивает её в часах.
2) Исполнитель САМ назначает цену своего часа.
3) Либо я соглашаюсь с его решениями; либо мы аргументированно обсуждаем их и он вносит правки; либо я отказываюсь от его услуг (что нормально).
4) Если во время работы выясняется, что на задачу потребуется больше времени, то мы согласуем такое превышение лимита, и либо оставляем всё в недоработанном виде, либо продолжаем работу, увеличивая оценку.
5) По итогам работы исполнитель представляет отчёт с ФАКТИЧЕСКИМИ расходами времени, обычно они отличаются от первоначальной оценки: некоторые в меньшую сторону, большинство — в большую (и это нормально!).
6) Я могу поспорить с отчётом, если какие-то часы были потрачены по вине исполнителя. После согласования и принятия отчёта, я оплачиваю всю работу по утверждённой нами ранее ставке. Если у нас остались взаимные претензии, то мы просто не работаем больше. Чаще всего всё удаётся аргументированно урегулировать, все довольны.
Преимущества такой системы: ответственность исполнителя за оценку своего труда, возможность планирования времени, наглядность и понятность методики рассчёта итоговой оплаты.
Недостатки: менеджер должен иметь достаточно высокую квалификацию в предметной области исполнителя, чтобы ставить задачи и оценивать их трудоёмкость.
На практике можно сочетать обе схемы: менеджер работает на ставке (с повышением после каждого проекта, хотя бы символическим), а временные исполнители работают в почасовом режиме с этим менеджером.
Примерно так я осуществляю планирование: russian.joelonsoftware.com/Articles/PainlessSoftwareSchedules.html
Буквально с приведённой там табличкой и работаю: высылаю экселевский файл исполнителю и прошу заполнить. Сначала некоторые артачатся, а потом самим же удобно становится: вписывают цифры по мере выполнения этапов работы (и оплаты) и высылают мне.
Буквально с приведённой там табличкой и работаю: высылаю экселевский файл исполнителю и прошу заполнить. Сначала некоторые артачатся, а потом самим же удобно становится: вписывают цифры по мере выполнения этапов работы (и оплаты) и высылают мне.
О вреде премирования
Альфи Кон (Alfie Kohn) в уже ставшей классической статье в журнале Harvard Business Review пишет:
… по крайней мере два десятка исследований за последние тридцать лет определённо показывают, что люди, ожидающие получить награду за выполнение задания или за успешную работу просто не работают так же хорошо, как те, кто не ожидает какого-либо поощрения. [Harvard Business Review сентябрь-октябрь 1993]
Он приходит к выводу, что «премии (или взятки) просто неэффективны на рабочем месте». ДеМарко и Листер идут дальше и недвусмысленно отмечают, что любой вид соревнований на рабочем месте, любая схема кнута и пряника, и даже старый трюк «поимки людей с поличным за деланием чего-то полезного с последующим награждением» — все они приносят больше вреда, чем пользы. Любая раздача пряников (например, церемониальное вручение мемориальных досок победителям соцсоревнования) подразумевает, что они работали, чтобы получить эту люситовую доску; то есть они не обладают достаточной самостоятельностью, чтобы работать не за пряник; это унизительно и обидно.
Мне кажется, что не учитывается момент в котором каждый человек по своему оценивает премии и т.п. поощрения. Для некоторых премии приносят результат, а вот у других совсем наоборот негатив.
Все потому что люди имеют, по мимо физического развития, еще психологическое развитие( детство, подросток, юноша, взрослый) которое и делает разницу в системе ценностей.
Разработчики создают, в какой то мере, комплиментарную группу с общими интересами и практически одинаковым психологическим развитием. Согласен с утверждением что «достаточной самостоятельностью, чтобы работать не за пряник; это унизительно и обидно» это подчеркивает некоторую общую психологическую черту.
Но утверждение в общем плане не корректно.
Все потому что люди имеют, по мимо физического развития, еще психологическое развитие( детство, подросток, юноша, взрослый) которое и делает разницу в системе ценностей.
Разработчики создают, в какой то мере, комплиментарную группу с общими интересами и практически одинаковым психологическим развитием. Согласен с утверждением что «достаточной самостоятельностью, чтобы работать не за пряник; это унизительно и обидно» это подчеркивает некоторую общую психологическую черту.
Но утверждение в общем плане не корректно.
Приведите пожалуйста мне примеры успешного использования премий в IT-сфере.
Может для дворников это работает (у каждого свой участок и в чужой залазить не следует), то в разработке ПО — нет.
Любой соревновательный элемент в творческом и/или командном труде заведомо вреден.
Может для дворников это работает (у каждого свой участок и в чужой залазить не следует), то в разработке ПО — нет.
Любой соревновательный элемент в творческом и/или командном труде заведомо вреден.
Хм, меня не правильно поняли.
Мое утверждение:
Да согласен с вашим тезисом про то, что соревнование(в виде премий и т.п.) и нездоровая конкуренция вредна.
Но уточнил:
Это утверждение не абсолютно в общем для всех. И постарался объяснить почему.
Резюме
Ваша точка зрения совпадает с мое в этом плане. Не вижу противоречий.
Мое утверждение:
Да согласен с вашим тезисом про то, что соревнование(в виде премий и т.п.) и нездоровая конкуренция вредна.
Но уточнил:
Это утверждение не абсолютно в общем для всех. И постарался объяснить почему.
Резюме
Ваша точка зрения совпадает с мое в этом плане. Не вижу противоречий.
> Про лучшую систему оплаты писал Джоэл Спольски
Онлайн такого материала не нашёл. Но это было в одной из книжек, вроде как «Руководство Джоэла Спольски по подбору программистов и управлению ими».
Онлайн такого материала не нашёл. Но это было в одной из книжек, вроде как «Руководство Джоэла Спольски по подбору программистов и управлению ими».
> менеджер должен иметь достаточно высокую квалификацию в предметной области исполнителя, чтобы ставить задачи и оценивать их трудоёмкость
И да, менеджеру следует описывать максимально требуемый результат, и, возможно, помогать (но не более) выделять мелкие задачи из общей цели, но в общем исполнитель должен САМ составить детальный список задач и оценить их по времени.
И да, менеджеру следует описывать максимально требуемый результат, и, возможно, помогать (но не более) выделять мелкие задачи из общей цели, но в общем исполнитель должен САМ составить детальный список задач и оценить их по времени.
«Но для типичных задач 21 века этот механистический подход кнута и пряника не подходит, часто не действует и часто вредит [производительности]»
Награждать за действие — прошлый век. Награждать за действия в будущем — еще хуже, конечно )
http://www.ted.com/talks/dan_pink_on_motivation.html (есть руские субтитры)
Результативность моей работы «в системе» оказалась на порядок (в 7 раз) менее эффективнее подхода из этого ролика. Я не переживаю о деньгах. Я не переживаю о сроках. Мы работаем над задачей до тех пор, пока она, по нашему мнению, не достаточно хороша чтобы двигаться дальше.
И конечный результат нравится людям:
— 9% посещений сайта больше 10 минут
— 8.64% людей смотрят более 20 страниц
— экспериментальным путем мы узнали, что google analytics не учитывает, если кто-то просмотрел более 500 страниц за визит
Порядок затрат на проект тоже был несопоставимо меньшим, так как на основе хорошей базы легко создавать новый функционал.
В итоге, когда мне вчера звонил HR из Luxoft я отказался сразу — я не могу принять предложение работы в такой компании, где думают о мотивации и поощрениях. Я хочу работать не для премии, а для результата.
Награждать за действие — прошлый век. Награждать за действия в будущем — еще хуже, конечно )
http://www.ted.com/talks/dan_pink_on_motivation.html (есть руские субтитры)
Результативность моей работы «в системе» оказалась на порядок (в 7 раз) менее эффективнее подхода из этого ролика. Я не переживаю о деньгах. Я не переживаю о сроках. Мы работаем над задачей до тех пор, пока она, по нашему мнению, не достаточно хороша чтобы двигаться дальше.
И конечный результат нравится людям:
— 9% посещений сайта больше 10 минут
— 8.64% людей смотрят более 20 страниц
— экспериментальным путем мы узнали, что google analytics не учитывает, если кто-то просмотрел более 500 страниц за визит
Порядок затрат на проект тоже был несопоставимо меньшим, так как на основе хорошей базы легко создавать новый функционал.
В итоге, когда мне вчера звонил HR из Luxoft я отказался сразу — я не могу принять предложение работы в такой компании, где думают о мотивации и поощрениях. Я хочу работать не для премии, а для результата.
Все больше понимаю, что работа на результат — самая большая мотивация. Если результат нравится разработчику, ему будет приятно работать дальше, думая только о будущем результате. Если результат нравится потребителят труда разработчика, то денежное вознаграждение работника должно еще больше укреплять желание работать на результат.
Может это особенность небольших команд – но у меня схема с оплатой по рабочим часам вполне работает. По-моему нормальный сотрудник заинтересован записывать ровно столько сколько он работает, так как вполне можно записать и 60 часов в неделю например.
Плюс дает дополнительный самоконтроль, если не записывать время – легко весь день провтыкать.
Правда мы работаем не в офисе, может в этом еще дело.
Плюс дает дополнительный самоконтроль, если не записывать время – легко весь день провтыкать.
Правда мы работаем не в офисе, может в этом еще дело.
Это типична схема 1С-ников… меня плющило с этого подхода т.к. если смотреть на результат, то я работал примерно в 3-4 раза эффективнее (то бишь быстрее и делал меньше ошибок при этом) чем коллеги по цеху. Но ЗП у нас была одинаковая, т.к. мы отработали одинаковое количество часов.
Спрашивается где здесь мотивация?
Ваша схема работает… но она «уравнивает» персонал… в конце концов у вас останутся «слабые середнячки», которым лишь бы время просидеть…
Ибо постоянно идут конфликты между сотрудниками вида «мы одинаково часов отработали, а он больше получает» и «Я блин в 3 раза больше сделал и у меня не было ошибок а я получил так же как все»…
Спрашивается где здесь мотивация?
Ваша схема работает… но она «уравнивает» персонал… в конце концов у вас останутся «слабые середнячки», которым лишь бы время просидеть…
Ибо постоянно идут конфликты между сотрудниками вида «мы одинаково часов отработали, а он больше получает» и «Я блин в 3 раза больше сделал и у меня не было ошибок а я получил так же как все»…
в этом примере руководство упустило важный момент: коллеги не должны знать кто сколько получает, тогда не будет обид
Научная фантастика у нас в другом отделе. Как это осуществимо?
фиг знает как руководство этого добилось, но у нас это реально не обсуждают. не принято.
А в чём проблемы? Начальство установило правило — сотрудники его соблюдают. Никогда не знал сколько получают окружающие и мыслей спрашивать их об этом как-то даже не возникало.
мыслей спрашивать их об этом как-то даже не возникало.
Информации свойственно распространяться, не исключено, что узнаете без вашего желания.
Как-то в коллективах, где я работал/работаю вовсе даже не свойственно разговаривать о том, о чём нельзя.
да это даже не столько «нельзя» сколько «неприлично»… если меня кто-то спросит сколько я получаю я в лучшем случае изображу смайлик, в худшем подниму бровь и проигнорирую :) Но зарплаты тех кто мне подчинен я знаю и также в соответствие с этим корректирую требования. Они, кстати, тоже не обсуждают зарплаты, на сколько я знаю, хотя, может быть это потому что у меня из ex-USSR только один человек да и тот в глубоком субподряде… а может это и не имеет значения.
У разных сотрудников разная почасовая ставка.
Если сотрудник недоволен своей ставкой, ее можно увеличить. Ставки у меня в целом заметно выше чем по региону.
Основное – платить человеку столько сколько он считает достаточным. Часы достаточно удобная метрика чтоб оценить объем выполненной работы относительно того как вообще работает даный человек, а не относительно других.
Почасовая ставка очень хороша тем что есть мотивация делать всякую нудную фигню которая нужна для доведения проектов до ума. Мало кто любит двигать туда-сюда пиксели, исправлять опечатки, делать обработку ошибок и т.п.
Если сотрудник недоволен своей ставкой, ее можно увеличить. Ставки у меня в целом заметно выше чем по региону.
Основное – платить человеку столько сколько он считает достаточным. Часы достаточно удобная метрика чтоб оценить объем выполненной работы относительно того как вообще работает даный человек, а не относительно других.
Почасовая ставка очень хороша тем что есть мотивация делать всякую нудную фигню которая нужна для доведения проектов до ума. Мало кто любит двигать туда-сюда пиксели, исправлять опечатки, делать обработку ошибок и т.п.
Нет, вы что — 60 часов в неделю это же сверхурочные. Знаете, какой это геморрой для начальства?
В большинстве мест вам тупо можно написать либо меньше, либо впритык.
В большинстве мест вам тупо можно написать либо меньше, либо впритык.
При нормированой неделе в офисе писать часы таки да, тупняк. У нас просто гибкость максимальная: бывает и 10 часов в неделю получается.
Тут просто дело в том что нет другого более-менее очевидного способа оценить производительность хотя бы с точки зрения самого работника.
Тут просто дело в том что нет другого более-менее очевидного способа оценить производительность хотя бы с точки зрения самого работника.
О том и речь.
Только часы работы — это трудозатраты, а не производительность.
Производительность, в итоге — это результат, разделённый на трудозатраты как раз.
Пример: Вася и Петя оба написали по ещё одному текстовому редактору с подсветкой. Для простоты — реалзовали требования одного и того же ТЗ. У Васи это заняло 2 часа, а у Пети 4.
Если мерять производительность в часах, то Петя в 2 раза круче Васи, и платить ему надо больше.
Если же рассуждать логически, то я бы себе нанял Васю, и платил бы ему больше Пети.
Только часы работы — это трудозатраты, а не производительность.
Производительность, в итоге — это результат, разделённый на трудозатраты как раз.
Пример: Вася и Петя оба написали по ещё одному текстовому редактору с подсветкой. Для простоты — реалзовали требования одного и того же ТЗ. У Васи это заняло 2 часа, а у Пети 4.
Если мерять производительность в часах, то Петя в 2 раза круче Васи, и платить ему надо больше.
Если же рассуждать логически, то я бы себе нанял Васю, и платил бы ему больше Пети.
На практике имеет смысл нанять обеих и платить Васе больше в час чем Пете. Так как они оба толковые программисты. Действительно худший программист потратит в 10 раз больше времени и не факт что закончит проект. А толковые достаточно редко встречаются.
Ну так и я об том же.
>имеет смысл нанять обеих
Внезапно Вася и Петя оказались девочками:)
>имеет смысл нанять обеих
Внезапно Вася и Петя оказались девочками:)
Я знал девочку по имени Вася :)
Василиса, дайте угадаю?
А вот тут говорится, что Петя — это женская форма имени Петар у болгар.
Так что всё нормально, гендерный этикет соблюдён.
А вот тут говорится, что Петя — это женская форма имени Петар у болгар.
Так что всё нормально, гендерный этикет соблюдён.
Спасибо, что рассуждаете на тему мотивации. Очень важная и очень противоречивая тема.
Вы правильно написали «Как известно, что поощряется — то растёт.»
Но большинство известных мне руководителей не смогли построить KPI и премирование по важным для них целям.
А одной компании, например, разработчики советом отказались от продуманного KPI и настояли на сохранении прорабского метода. Для этих разработчиков уже был достигнут уровень денежного комфорта, а отказываться от психологического комфорта они не захотели.
Чаще всего успешно работает прорабский метод управления сложноструктурированными процессами. Хоть все и понимают, его неточность.
Пишите еще :)
Вы правильно написали «Как известно, что поощряется — то растёт.»
Но большинство известных мне руководителей не смогли построить KPI и премирование по важным для них целям.
А одной компании, например, разработчики советом отказались от продуманного KPI и настояли на сохранении прорабского метода. Для этих разработчиков уже был достигнут уровень денежного комфорта, а отказываться от психологического комфорта они не захотели.
Чаще всего успешно работает прорабский метод управления сложноструктурированными процессами. Хоть все и понимают, его неточность.
Пишите еще :)
Чтобы повысить эффективность сотрудников, компании выстраивают различные мотивационные схемы.
Для сотрудников начинается игра:
* если ты дольше поработал — получи бонус
* если написал больше строк кода — бонус
* если «надсмотрщик» хорошо оценил твою эффективность — бонус
* если не зарабатываешь бонусы, то получишь небольшую дефолтную зарплату — приходится играть
О какой эффективности может идти речь, если во время работы сотрудник думает не про работу, и о том как ее лучше сделать, а про мотивационную игру, и как бы в ней побольше выиграть.
Для сотрудников начинается игра:
* если ты дольше поработал — получи бонус
* если написал больше строк кода — бонус
* если «надсмотрщик» хорошо оценил твою эффективность — бонус
* если не зарабатываешь бонусы, то получишь небольшую дефолтную зарплату — приходится играть
О какой эффективности может идти речь, если во время работы сотрудник думает не про работу, и о том как ее лучше сделать, а про мотивационную игру, и как бы в ней побольше выиграть.
Суть поста — не будьте долбоёбами.
Хм, я вот работал в конторе, где на работу можно было приходить как угодно, но в разумных пределах, и когда угодно — тоже в разумных пределах. Зарплата была фиксирована.
В итоге, лично я, поколебавшись между «всегда на работе до 22-00» и «я сегодня не приду», остановился на простой схеме — я работаю до тех пор, пока прет работать. Когда уже не прет, отдохну 15 минут, и если все еще не прет — ухожу заниматься чем-то еще (например, домой заниматься хобби — радиоэлектроникой). В итоге производительность была весьма хорошей.
Как-то раз я три недели ходил на работу через день и писал себе ТЗ, а потом еще за полторы недели закодил, и полторы — отлаживал и устанавливал. Итого, начальство получило хорошо масштабируемую систему распределенной обработки изображений за полтора месяца, которая работает на общее благо конторы вот уже лет пять, наверное, и лююбые правки в ней делаются за день максимум — потому что было предусмотрено в свое время. Начальство меня похвалило и выдало премию, было приятно — вот он, мотиватор.
При этом коллега приезжал каждый день к 9, уходил в 18, и вполне нормально работал — ему было так удобнее. Когда мы писали пересекающиеся проекты — просто я приезжал так, чтобы рабочее время пересекалось, и планировали каждый день так, чтобы мое отсутствие утром не повлияло на работу. И все получалось.
А как-то раз, когда проектов «под меня» не было особо, но пипец как нужно было строить два объекта, меня попросили быть представителем заказчика. Я и был… три месяца ложился спать в 4 часа ночи, вставал в 9 утра, весь день мотался по Москве, согласования, совещания, пинки таджикам, ругань с подрядчиками, итд, итп. Построили. Ни спасибо, ни премии, ибо был кризис, денег у конторы не было, и как-то начальству было не до того.
Так вот лично для меня то, что не было премии, было не так обидно, как то, что не было «спасибо, Ваша работа была очень нужна нам».
Ну и вообще, курс начальства стал «блин, не до спасибов, денег нет, проблем есть». В итоге поработал немного, да и уволился, когда предложили уйти в отпуск «потому что денег мало, а проектов — тоже мало».
Мораль — каждому разработчику, который стоит каких-то денег и умеет что-то большее, чем «Word, Excel и PHP» — индивидуальный подход к мотивации и демотивации, и все будет :)
p.s. Хотя, конечно, лично для меня идеальный сферическим работодателем в вакууме будет тот, который скажет: «вот тебе квартира, вот тебе зарплата в X рублей, достаточная чтобы прожить, вот тебе 1% доли в доходах, и контракт на 10 лет, а теперь, когда тебя больше ничего не тревожит, покажи, на что способен, и сверни горы». Но так не бывает, да :)
В итоге, лично я, поколебавшись между «всегда на работе до 22-00» и «я сегодня не приду», остановился на простой схеме — я работаю до тех пор, пока прет работать. Когда уже не прет, отдохну 15 минут, и если все еще не прет — ухожу заниматься чем-то еще (например, домой заниматься хобби — радиоэлектроникой). В итоге производительность была весьма хорошей.
Как-то раз я три недели ходил на работу через день и писал себе ТЗ, а потом еще за полторы недели закодил, и полторы — отлаживал и устанавливал. Итого, начальство получило хорошо масштабируемую систему распределенной обработки изображений за полтора месяца, которая работает на общее благо конторы вот уже лет пять, наверное, и лююбые правки в ней делаются за день максимум — потому что было предусмотрено в свое время. Начальство меня похвалило и выдало премию, было приятно — вот он, мотиватор.
При этом коллега приезжал каждый день к 9, уходил в 18, и вполне нормально работал — ему было так удобнее. Когда мы писали пересекающиеся проекты — просто я приезжал так, чтобы рабочее время пересекалось, и планировали каждый день так, чтобы мое отсутствие утром не повлияло на работу. И все получалось.
А как-то раз, когда проектов «под меня» не было особо, но пипец как нужно было строить два объекта, меня попросили быть представителем заказчика. Я и был… три месяца ложился спать в 4 часа ночи, вставал в 9 утра, весь день мотался по Москве, согласования, совещания, пинки таджикам, ругань с подрядчиками, итд, итп. Построили. Ни спасибо, ни премии, ибо был кризис, денег у конторы не было, и как-то начальству было не до того.
Так вот лично для меня то, что не было премии, было не так обидно, как то, что не было «спасибо, Ваша работа была очень нужна нам».
Ну и вообще, курс начальства стал «блин, не до спасибов, денег нет, проблем есть». В итоге поработал немного, да и уволился, когда предложили уйти в отпуск «потому что денег мало, а проектов — тоже мало».
Мораль — каждому разработчику, который стоит каких-то денег и умеет что-то большее, чем «Word, Excel и PHP» — индивидуальный подход к мотивации и демотивации, и все будет :)
p.s. Хотя, конечно, лично для меня идеальный сферическим работодателем в вакууме будет тот, который скажет: «вот тебе квартира, вот тебе зарплата в X рублей, достаточная чтобы прожить, вот тебе 1% доли в доходах, и контракт на 10 лет, а теперь, когда тебя больше ничего не тревожит, покажи, на что способен, и сверни горы». Но так не бывает, да :)
плюс один, вы мне платите за работу или за сидение на рабочем месте? Если работа сделано — могу и вообще на работе не показываться. А если нет — кого волнует, что сегодня выходной?
Отличная статья о наболевшем!
Спасибо автору!
Пример из жизни:
обычная веб-студия, в студии 2 разработчика, один как полагается в статусе ведущего, второй «типо тыл», куда летят все задачи от первого.
Второй разработчик проработал в компании 2 месяца, исправно решая задачи, но иногда не укладывающийся в сроки, т.к. по сути все на нем (в том числе вся рутина), а ведущий только «рулит» и помогает местами.
По окончанию двух месяцев руководство говорит, что мол ты плохо работаешь, мы не видим твоей работы и т.д в том же русле… А получи ка 70% оклада и 50% премии (ранее он получал 100%'ый оклад, премий не было, по новой схеме он бы получил 120% в максималке), типо мы тебя замотивируем! А то нифига не работаешь!
Странно, подумал разработчик, ведь он всегда приходит до начала рабочего времени, работа ему нравится, он видит в ней свое будущее, поэтому никаких вконтактов и онных штук на работе, словом одна только работа, решение задач иногда доходило до 10-15 штук в день.
И начал разработчик писать отчет о проделанной работе, чтобы показать его перед оценкой его труда. Прошел месяц, отчет был показан… И… Руководство решило, что «вау!» как много ты делаешь, а давай ка мы вернемся к 100% окладу без премий!..
Вот такая вот «мотивационная политика».
Вот такое не постоянство и не доверие подрывает любое стремление, что либо делать для компании вне рабочего времени и провоцирует работать «не спеша»…
P.S. В компании есть система учета задач, но видимо она абсолютно не используется для оценки работы…
Спасибо автору!
Пример из жизни:
обычная веб-студия, в студии 2 разработчика, один как полагается в статусе ведущего, второй «типо тыл», куда летят все задачи от первого.
Второй разработчик проработал в компании 2 месяца, исправно решая задачи, но иногда не укладывающийся в сроки, т.к. по сути все на нем (в том числе вся рутина), а ведущий только «рулит» и помогает местами.
По окончанию двух месяцев руководство говорит, что мол ты плохо работаешь, мы не видим твоей работы и т.д в том же русле… А получи ка 70% оклада и 50% премии (ранее он получал 100%'ый оклад, премий не было, по новой схеме он бы получил 120% в максималке), типо мы тебя замотивируем! А то нифига не работаешь!
Странно, подумал разработчик, ведь он всегда приходит до начала рабочего времени, работа ему нравится, он видит в ней свое будущее, поэтому никаких вконтактов и онных штук на работе, словом одна только работа, решение задач иногда доходило до 10-15 штук в день.
И начал разработчик писать отчет о проделанной работе, чтобы показать его перед оценкой его труда. Прошел месяц, отчет был показан… И… Руководство решило, что «вау!» как много ты делаешь, а давай ка мы вернемся к 100% окладу без премий!..
Вот такая вот «мотивационная политика».
Вот такое не постоянство и не доверие подрывает любое стремление, что либо делать для компании вне рабочего времени и провоцирует работать «не спеша»…
P.S. В компании есть система учета задач, но видимо она абсолютно не используется для оценки работы…
Прочитал. Сам HR. Ничего нового не узнал. Рад за автора и его открытия
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Битва за трудочасы. Как надо считать зарплату?