Рейтинг банков по кредитным картам

Рейтинг кредитных карт
Эксклюзивное исследование Банки.ру — ноябрь, 2016

Мотивация для IT-специалиста

20.08.2012 12:49 19 1 233 просмотра
Коллеги, на работе возникла потребность в описании правил работы IT-подразделения... правила эти должны быть оформлены в виде парадигм, т.е. нести одновременно ограничивающую и мотивационную функции... обсуждаем вместе с руководством, каждый предлагает свои варианты, а я бы хотел спросить совета у Вас - насколько приложенные парадигмы были бы понятны и на какие мысли они бы Вас натолкнули после прочтения smile:)

1. Знаешь как сделать лучше – сделай, покажи, а потом предложи. Будь уверен, что если ты прав, то твои усилия окупятся, а если нет, то, по крайней мере, мы не потратишь чужое время впустую.
2. Обращение к руководству, возможно в любое время и по любому вопросу, но при одном обязательном условии: запрещено использовать в разговоре частицу “не” (не знаю, не умею, не получится, нет смысла, не виноват, не я и т.п.)
3. Каждый сотрудник имеет право потратить 15% своего времени на личные разработки с привлечением ресурсов компании. При этом поставленные планы обязательны к выполнению, так как они изначально будут рассчитаны исходя не из 40, а из 34 рабочих часов в неделю.
4. Ответственность за наличие ошибок в конечном продукте несет “тестировщик”. Разработчик несет ответственность только лишь за своевременность устранения ошибок и сроки разработки продукта в целом.
5. В компании действует принцип “грехов и честных ошибок”. “Честные ошибки” дозволительны, если разработчик исправляет их в разумные сроки. Однако повторное появление одной и той же ошибки расценивается как “грех”, то есть факт неуважения к собственной работе, чужой работе и миссии компании в целом.
6. При обнаружении любой ошибки, в том числе, не относящейся к непосредственным обязанностям, сотрудник должен составить “багрепорт”. Игнорирование данного требования расценивается как “грех”.
7. Если ты делаешь одну и ту же работу с периодичностью чаще, чем раз в месяц, и на эту работу ты тратишь больше 10 минут, значит ее можно и нужно оптимизировать (программно-техническими средствами, управленческими решениями или полным исключением данной работы из функционала). Игнорирование данного требования расценивается как “грех”.
8. Не знаешь как сделать – спроси. Своим вопросом ты не только решишь свою проблему, но и дополнишь FAQ, чем существенно облегчишь работу свои коллегам, в том числе, вновь приходящим в компанию. Игнорирование данного требования расценивается как “грех”.
9. Не создавай “узких мест”. Из трех возможных вариантов решения: универсального, оптимального и нестандартного (как удобно), ты должен выбрать универсальный. В идеале все 3 варианта должны быть совмещены. Игнорирование данного требования расценивается как “грех”.
10. Если поставленная задача требует обсуждений, которые откладывают решение задачи на не зависящие от тебя сроки, то ты должен создать универсальный механизм, который будет работать вне зависимости от принятых в ходе обсуждения решений.

Комментарии 19

Шарухин Антон  (toshik80)
#
Я бы не стал ограничивать время 15ю процентами в 3м пункте, но оставил бы жесткое условие, планы должны быть выполнены.
И добавил бы:
Любая создаваемая отчетная форма, содержащая какие-либо сводные данные, должна обладать функционалом расшифровки, т.е. программа должна показать из чего сложилась та или иная цифра с возможностью выхода на электронные документы её (эту цифру) сформировавшие.
Любой программный алгоритм, который формирует цифровые показатели, путем расчета из каких-либо цифровых данных (расчет нормативов например) также должен обладать механизмом расшифровки из которого можно однозначно понять какие цифры были взяты за основу и по какой формуле произведен расчет.
А все остальное справедливо
Иван Миронов  (VanesStalkers)
#
1. а из чего в таком случае рассчитывать план? т.е. из скольки человеко-часов? smile:)
2. идея хорошая, но она скорее будет прописана в функционал аналитиков, да и отчетность у нас, слава богу, не главенствующая задача smile:)
Владимир Светлый  (lawmaster)
#
Все что описано никак не может являться мотивацией.

Это элементы управления персоналом, но не мотивация. А на мой взгляд вообще демотивация.
Иван Миронов  (VanesStalkers)
#
смотря с чем сравнивать smile:) если в с полным фрилансом, то конечно, любые правила - это ограничения...
а если речь идет о постоянной работе, за которую платят по факту нахождения на этой работе (просто так в законодательстве написано, что надо платить), а не за конкретные действия (за невыполнение планов нельзя оставить человека без зп), то вопрос мотивации крайне важен...
+ ко всему, если организация ставит перед собой задачу удержать сотрудника как можно дольше, при чем сделать это не только материальными средствами (что крайне сложно с демпингом Сбера)
Владимир Светлый  (lawmaster)
#
Меня мотивируют только премии и признание. А загонять в рамки может быть и нужно, но не таких как я. Так как я самомотивирован. Дали задание - как можно быстрей сделать.

У вас все на негативной мотивации в этом своде правил. Очень мало положительной.

Ну и не слова о премиях.
Иван Миронов  (VanesStalkers)
#
Владимир, я правильно понимаю, что если в какой либо компании Вам предложат больше денег и выше должность, то Вы уйдете?
Владимир Светлый  (lawmaster)
#
Нет. Если мне будут платить даже 20 тысяч рублей, я не уйду если буду чувствовать, что со временем смогу вырасти, обрести новые знания. Но если я уже достиг потолка в заработной плате и развитии и мне предложат лучшее место - я конечно же уйду.

Ну и естественно если отношения от руководства построено на отрицательной(негативной) мотивации: "Сделай все в срок и хорошо и не получишь нагоняй!". Я рано или поздно уйду. Просто очень тяжело работать когда ты находишься под постоянным прессингом.
Иван Миронов  (VanesStalkers)
#
значит я не совсем понял про "премии и признание" smile:) получается, что премии для Вас просто на втором месте, но если предложат более высокую должность в другой компании, вне зависимости от зп, то в этом случае Вы уйдете? не будете же Вы на одном месте сидеть только за обещания, что рано или поздно Вас повысят...
а вот про развитие как раз таки учтено, пункты 1,3 направлены именно на то, чтобы сотрудник почувствовал потребность компании его в личной инициативе... + тоже самое про постоянный прессинг - пункты 4,5 должны избавлять непосредственного разработчика от страха ошибиться...
Иван Миронов  (VanesStalkers)
#
добавили еще одну парадигму (10-ю)
Семен Семенович Горбунков  (Семен Семенович)
#
Согласен со Светлым где он пишет: "Все что описано никак не может являться мотивацией. Это элементы управления персоналом, но не мотивация. ".
smile;) Про "демативацию" я бы не стал бы утверждать.
Тем более, что автор под ИТ-специалистами понимает только достаточно узкий круг программистов, а "мир айтишников" гораздо шире и многограннее. smile:)
Для всех перечисленные 10 пунктов мягко говоря НЕ ВСЕГДА актуальны.
Иван Миронов  (VanesStalkers)
#
под IT-специалистами я понимаю любых творческих людей, работающих с компьютерами...
так уж получилось, что людей "не творческих", у нас не предвидится, так что и подстраивать общие правила под тех, кто собирается работать исключительно за должность и премии, т.е. потенциально проработающих у нас не больше месяца, смысла нет...

про то, что данные "правила" могут кого то не устроить, я догадывался, но в условиях, когда люди сами не знают, чего они хотят, лучше начинать с хоть каких то правил и по ходу дела их менять, чем сразу начинать с анархии smile:)
Иван Миронов  (VanesStalkers)
#
при работе с клиентами - очень даже верная позиция... но именно что мотивирует, действительно, достаточно слабо, скорее угнетает smile:)
Oila  (Oila)
#
По собственному опыту работы в не самой маленькой компании-разработчике банковского ПО, вначале как рядового разработчика, затем в качестве руководителя направления. Мотивация - результирующий продукт многих составляющих. Мотивация к повышению выполнения объемов работ, за счет, в т.ч. и личного времени это один момент. Мотивация к лояльности компании и как результат, повышению\поддержанию уровня качества собственной работы это иной момент.

В первую очередь, в моем понимании, мотивация - это четко определенные, понятные рядовому разработчику(тестировщику) и поддающиеся самостоятельному расчету показатели влияющие на твой лично финансовый результат. Это в плане непосредственной работы.
В плане же лояльности к компании, мотивация - это, также, и поощрительные по отношению к сотруднику действия руководства уже при отсутствии у него проколов в работе за определенный рабочий период. В этом же ключе, мотивация - это наличие в организации прозрачных регламентных документов дающих сотруднику уверенность в том, что его уровень дохода будет проиндексирован с учетом инфляции.
Что касается озвученных пунктов, то это скорее постулаты построения межотдельских и личностных отношений в организации работы коллектива. К мотивации первоочередного уровня прямого отношения не имеет, к мотивации лояльности будет иметь отношение только в зависимости от качеств руководства среднего и высшего звена.
Непосредственно по паре озвученных позиций:
Пункт 1-й
Будет работать только в условиях полной не загруженности конкретных людей. В противном случае, на то, чтобы делать (именно делать самому, а не просто предложить альтернативное решение) работу за другого просто нет времени. Да и не окупается, как показывает опыт, т.к. в том, что предложенное лучше надо еще убедить(при наличии на то времени и желания у объекта убеждения).
Пункт 4-й.
Самый прагматичный из предложенных. Никак не мотивация, конечно, просто разумный подход к разделению работы, да же при условии, что тестировщики при этом начинают "дуть на воду" и волынить с отправкой результатов выполненных работ клиенту.
Иван Миронов  (VanesStalkers)
#
благодарю за Ваше мнение...
не сочтите за претензию, но для меня в очередной раз становится понятно, что придумать что-то кроме материальной мотивации достаточно трудно (а если кто-то и придумал, то будет держаться за это 'ноу-хау' и не станет раскрывать секреты потенциальным конкурентам)...
с моей точки, зрения мотивация к повышению объемов выполненных работ напрямую зависит от мотивации к лояльности компании, который является первоисточником вообще любой мотивации, соответственно все предложенные качества направленны именно на то, чтобы описать "нематериальную" мотивацию, повышающую лояльность сотрудников...
при этом лично для меня, в настоящий момент как "чистого программиста", озвученные правила были бы очень удобны (в том числе и в плане раскрепощенности по отношению к результатам работы) и достаточно сильно отличали бы ту организацию, где я работаю, от других подобных...

по пункту 1 не соглашусь... если специалист загружен на 100% от своего рабочего времени, то это может означать следующее: 1. не объективно жестко установленные планы 2. слабая эффективность работы сотрудника... надо понимать, что современная трудовая деятельность - это не каторга, где ты работаешь пока не упадешь... есть планы (объем работ), есть оплата (за конкретный объем) - никто не платит за проведенное на работе время, это было бы глупо... при этом эффективный сотрудник всегда будет перевыполнять установленные нормы (иначе эти нормы можно считать каторжными) и у него всегда будет свободное время...
Дмитрий Дмитриев  (ddmitriev)
#
Поддержу Светлого в том, что написанное - не мотивация. Мотивация - это внутренняя потребность человека сделать что-то определенным образом. В настройке мотивации для руководителя есть 2 задачи: показать, какой ему хочется получить результат (это как раз и сделано Вами - написаны правила) и сформировать внутри подчиненных потребность достичь заданного результата.

И вот это последнее - жутко сложная вещь: надо как-то привязать уже существующие у человека потребности к качественному выполнению работы. В идеале - брать на работу самомотивированных людей. Для них достаточно создать нормальный климат “без фигни”: не придираться, не штрафовать, светло, тепло, еда, кофе-чай, тишина, удобные места и т.п. - см. про офис google.

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

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

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

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

Большая проблема - работа на стыках зон ответственности. Вот, мне, например, жутко не нравится Ваш 4-й пункт: “Ответственность за наличие ошибок в конечном продукте несет “тестировщик”. Ну вдумайтесь: получается, что разработчики могут делать сколь угодно плохой продукт, главное - это в заданные сроки “спихнуть” его на тестирование. Ужасно. Ответственность за ошибки несет ВСЯ команда.

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

А приведенные правила - это просто попытка очень-очень дешево... не решать задачу мотивации. Да, Вы сможете тыкать в нее в разговорах с подчиненными и обвинять их в “грехах”, но к мотивации это уже не имеет никакого отношения.
Иван Миронов  (VanesStalkers)
#
очень доходчиво написано, постараюсь также и ответить...
Цитата
Мотивация - это внутренняя потребность человека сделать что-то определенным образом. В настройке мотивации для руководителя есть 2 задачи: показать, какой ему хочется получить результат (это как раз и сделано Вами - написаны правила) и сформировать внутри подчиненных потребность достичь заданного результата.

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

Цитата
И вот это последнее - жутко сложная вещь: надо как-то привязать уже существующие у человека потребности к качественному выполнению работы. В идеале - брать на работу самомотивированных людей. Для них достаточно создать нормальный климат “без фигни”: не придираться, не штрафовать, светло, тепло, еда, кофе-чай, тишина, удобные места и т.п. - см. про офис google.

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

Цитата
А вот если внутренней потребности работать нет, то нужно думать - искать, что человек (каждый конкретный - отдельно!) хочет, чего он боится, во что верит, к чему имеет склонность?..

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

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

Цитата
Большая проблема - работа на стыках зон ответственности. Вот, мне, например, жутко не нравится Ваш 4-й пункт: “Ответственность за наличие ошибок в конечном продукте несет “тестировщик”. Ну вдумайтесь: получается, что разработчики могут делать сколь угодно плохой продукт, главное - это в заданные сроки “спихнуть” его на тестирование. Ужасно. Ответственность за ошибки несет ВСЯ команда.

распределенная ответственность обычно подразумевает отсутствие какой либо ответственности smile:)
именно поэтому обязанности и ответственность должны быть точечно прописаны - это возвращаясь к неопределенности, когда из двух решений: сделать что-то или ничего не делать, - принимается второе, так как ты не знаешь точно, окажешься ты в итоге виноват или нет...
Дмитрий Дмитриев  (ddmitriev)
#
Ох!.. Сложно отвечать письменно по такому объемному вопросу smile:)
Я, читая Ваш ответ, понял, что не достаточно внятно проговорил основные идеи мотивации, как ее вижу я. Тезисно:

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

Вот, например, сидит ваш архитектор и больше всего хочет сделать “красивую” систему, чтобы написать о ней статью на banki.ru. Он не боится вас, ему не нужно больше денег, чем у него есть, он плевать хотел на ваших пользоателей и ваш бизнес вообще. Вот и думайте, как использовать его тягу к славе.

А другой боится потерять работу, и поэтому не спорит с вами, даже если вы принимаете рискованные решения, он не любит ваши пункты 1, 2, 3 и 8, потому что давно уяснил, что даже если явно его не уволят за дурацкую идею, то потом, когда нужно будет кого-то сократить, вспомнят со словами: “А, это тот, кто год назад предложил 2 идиотских нововведения?..” Как использовать его страх, чтобы заставить его работать больше и лучше?

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

2. Вы должны - как угодно - описать параметры результата, который хотите получить, и увязать описанный результат с мотиваторами подчиненного. Где можно сделать это хотя бы сколько-нибудь формально и точно - ура, делаем. Парни из группы управлния инцидентами, как учит нас ITSM, имеют основную задачу - минимизировать время закрытия инцидентов. Любым способом, лишь бы побыстрее. Это легко объяснить и легко контролировать.

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

Однако, управление инцидентами - отдых для строителя системы мотивации. Беда для него - все тот же архитектор. Много ли книг “Сторим архитектуру сложных финансовых систем” в серии “Для чайников”? Кто знает метрики для оценки качества архитектуры? Вот и получается, что качество архитектуры определяет сам архитектор. Он может обсудить его с коллегой из другой компании или попросить помощи у подрядчика, но для вас этот мир - закрыт. Он не боится потери работы - его быстро возьмут на новую. Он не уважает вас как эксперта, потому что в его работе вы - не эксперт. Он, скорее всего, не любит вас - а за что ему вас любить, ведь вы - не женщина?..

И похожие проблемы - со многими другими ИТ-специальностями. Можно ли, посмотрев на ТЗ, поставить ему оценку? Можно ли оценить качество тестирования? Наверное, но не легко (посмотрите, как интересно: http://habrahabr.ru/post/149903/ - видно, что человек много думал про свою работу). Мотивация в таких творческих зонах - чистое искусство, непрерывное изучение людей в целом и конкретно тех, с кем вы работаете. А правила? Ну, забавно... местами - спорно и даже очень (хотя это субъективно), но из всей работы по мотивации, как мне кажется, разработка таких правил - это даже не 1% от всего, что нужно сделать. Могу предположить, что люди прочтут, хмыкнут (“вот, начальнику делать нечего”) и разойдутся работать в том же стиле, что и ранее, потому что “а зачем следовать этим правилам”?
Иван Миронов  (VanesStalkers)
#
Цитата
Вот, например, сидит ваш архитектор и больше всего хочет сделать “красивую” систему, чтобы написать о ней статью на banki.ru. Он не боится вас, ему не нужно больше денег, чем у него есть, он плевать хотел на ваших пользоателей и ваш бизнес вообще. Вот и думайте, как использовать его тягу к славе.

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

Цитата
Ваши слова: “боятся все как минимум одного точно”, - это почти хрестоматийный пример ошибки типа “проекция”, когда руководитель вместо изучения подчиненных использует для построения системы мотивации свои желания и страхи. Это Вы боитесь неопределенности, а каждый из ваших подчиненных боится чего-то своего - пауков там, или смерти, позора, бедности, старости...

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

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

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

Цитата
Могу предположить, что люди прочтут, хмыкнут (“вот, начальнику делать нечего”) и разойдутся работать в том же стиле, что и ранее, потому что “а зачем следовать этим правилам”?

ну как минимум наше начальство начало с того, что данные правила предложили на обсуждение всем сотрудникам, чтобы они сами могли определить, насколько хорошо они будут мотивировать нас и вновь вливающихся в нашу команду специалистов... так что, как минимум, все не так однозначно smile;)
Комментарии и отзывы могут оставлять только зарегистрированные пользователи.
Авторизуйтесь или зарегистрируйтесь.

Популярные сообщения

FINAL CALL 11/16
15 ноября вышли данные по исполнению федерального бюджета за очередной месяц — октябрь. 1. В апреле — августе 2016 года из Резервного фонда изъяли
0
Как вернуть «тетрадочный» вклад?
Короткий ответ: показать документы о вкладе в банке-агенте. Длинный ответ. Наверное, уже практически все вкладчики знают, что во многих банках с
6
Почему опасно оплачивать покупку в инетмагазине переводом на кошелек ЯД?
Почему опасно оплачивать покупку в инетмагазине переводом на кошелек ЯД? 1. Сервисы ЯД (Яндекс Деньги) очень удобны для мошенников, так как ЯД зарабатывают
10
Меркурий в Стрельце
Меркурий вошел в Знак Зодиака Стрелец и проходит здесь до 03 декабря. Что же интересного нам принесет этот транзит? Людей в это время отличает свобода
0
Рынок нефти 1 декабря
ОПЕК после почти годичных переговоров и восьми лет перерыва приняла решение о сокращении добычи нефти. Отдельным успехом для рынка в целом и картеля в
0

Новые сообщения

  • Рынок нефти 1 декабря
    ОПЕК после почти годичных переговоров и восьми лет перерыва приняла решение о сокращении добычи нефти. Отдельным успехом для рынка в целом и картеля в
  • FINAL CALL 11/16
    15 ноября вышли данные по исполнению федерального бюджета за очередной месяц — октябрь. 1. В апреле — августе 2016 года из Резервного фонда изъяли
  • Рынок нефти 30 ноября
    Рынок в ожидании решения ОПЕК. Сегодня должна быть поставлена точка в многомесячных и весьма непростых переговорах о потенциальном ограничении на нефтяном
  • Рынок нефти 29 ноября
    Над нефтяным рынком нарастает неопределенность, новостной фон концентрируется исключительно на предстоящем заседании ОПЕК. По итогам прошедших технических
  • Венера в Козероге
    Венера вошла в Знак Зодиака Козерог и пробудет здесь до 09 декабря. Вместо иллюзий и идеализма приходят сдержанность в проявлении чувств, строгость оценок