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

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

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

• Имеет ли значение 9:30 (или любое произвольное время) на самом деле? Or является ли то, что ваша команда должна убедиться, что они не препятствуют работе других команд из-за их отсутствия?

• Имеет ли значение 5 минут? Or является ли самым важным, что все члены присоединяются к ежедневному противостоянию?

• Является ли неформальность проблемой? Or является гибкость преимущество?

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

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

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

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

Моя команда не появляется вовремя. Я пытался заставить их, и это не работает.

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

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

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

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

Для вдохновения, пожалуйста, смотрите Сет Годин Интервью на Разница между руководством и управлением . Я настоятельно рекомендую всем и каждому, кто выступает в роли лидера, посмотреть это краткое интервью.

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

Если единственная причина, по которой вы реализуете эту политику, это напряженность с людьми в других отделах, это ваша работа - управлять этой напряженностью так, чтобы ваши люди могли работать наиболее эффективно. Я не думаю, что это единственная причина. Например, что, если разработчику необходимо исправить срочную производственную проблему, которая происходит в 8 или 9 часов или в любое другое время? Однако, вряд ли вам понадобится все ваши разработчики, присутствующие для исправления этой проблемы. Что, если у вас есть “раннее” (если только кто-то не добровольно) “раннее” расписание, так что каждый разработчик должен быть там в 8:00 (или 9:00, и т.д.)? Такое решение, скорее всего, удовлетворит как потребности бизнеса, так и желания ваших сотрудников. Каждый “разделяет боль” (или причиняет ее кому-то, кто не возражает). Люди могут приходить и работать большую часть времени, когда они чувствуют, что будут наиболее продуктивными. Это только один из вариантов, но он может спровоцировать дискуссию с вашими сотрудниками о том, как решить реальные проблемы и удовлетворить интересы каждого здесь.

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

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

T […] […] […] […] […] […] […] […] […] […] […] […] […] […] […] […] […] […] […]

Первое, что вам нужно сделать, это пойти читать “Peopleware”

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

Результат:

Менее продуктивный, менее заинтересованный разработчик, который внес огромный вклад в команду. Он стал намного менее продуктивным и полезным для команды.

Все из-за какого-то глупого понятия “вовремя”.

Сосредоточьтесь больше на производительности.

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

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

Как “новый технический руководитель”, вы не можете изменить культуру в ближайшее время. Особенно в том направлении, в котором вы, кажется, хотите. Вы сделали что-нибудь, чтобы улучшить роли/работы Вашей команды?

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

Узнайте, что РЕАЛЬНО необходимо другим группам. Не “они должны быть здесь в 9:30”. Действительно выясните, в чем проблема. Тогда найдите решение этой проблемы.

Не говоря своей команде, что делать - объясните проблему, а затем ЗАПОМНИТЕЛЬНО ОТВЕТСТВЕННОСТИ / ФЕДБАК.

Вы делаете расплывчатую ссылку на “причины большого напряжения между моим отделом и другими отделами” - но непонятно, что это за напряжение - расстроены ли они тем, что с девчонками обращаются предпочтительно? В чем настоящая глубинная проблема?

Я пытался заставить их, но это не работает.

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

Опять же, читайте “Peopleware”.

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

Кто говорит вам, что они должны быть на работе в 9:30? Другие группы? Ваши боссы? Вы? Разберитесь с проблемой REAL и разберитесь с этим. Когда они появляются, это НЕ должно быть проблемой.

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

По сути, вы просите их принять сокращение их общего компенсационного пакета.

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

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

Одним словом: Не делайте этого, если не считаете, что из-за этого стоит потерять некоторых из них.

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

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

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

Чтобы изменить это, вы можете использовать морковь или палку. Вы говорите об использовании палки и, может быть, палки побольше. Если вы пойдете этим путем, я планирую нанять несколько новых разработчиков, так как я предполагаю, что некоторые из вашей команды начнут проходить собеседования в других компаниях. Я бы лично поехал по морковному маршруту, чтобы получить байин для снятия этого бонуса, ясно давая понять, что будущие акции и продвижения будут решаться теми, кто “координирует свои действия с другими отделами”. То есть руководители/значимые люди находятся на ранних стадиях, работают с другими командами, берут на себя ответственность и т.д. “Новички” получить flex бонус, но люди, серьезные о продвижении получить в срок.

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

Я тебе не завидую - как коллеге-менеджеру, мне будет тяжело. И, честно говоря, я верю, что из-за этого ты потеряешь людей. Я думаю, что у Вас есть один симптом, который исходит от Start Up -> Средний сдвиг в культуре, и не каждый разработчик собирается делать эти изменения успешно. Я думаю, что вы должны быть подготовлены с описанием должностных обязанностей и знанием того, как вы открываете запросы на работу, и я думаю, что вы должны сделать акцент на возможности нанимать новых людей и улучшать документацию…

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

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

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

• вы четко изложили это

• вы говорили о причине и необходимости перемен

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

• вы давали обратную связь

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

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

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

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

Короткий ответ заключается в том, что вы НЕ должны этого делать. Члены вашей технической команды (или, по крайней мере, should be) достаточно умны, чтобы знать, что нет никакой ощутимой пользы в том, что все присутствующие в офисе к некоторому произвольному времени; важным показателем всего является то, будет ли их работа выполнена.

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

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

И, конечно, если вы проходите через обязательное "вы должны быть в офисе к времени X” политика, это только справедливо, чтобы дополнить его с “вы должны покинуть офис к времени Y” политика, и “вы не должны работать из дома в нерабочее время” политика. Это справедливый способ защитить баланс между работой и личной жизнью вашего сотрудника, так как я ставлю на то, что многие члены вашей команды, которые не появляются до 11:00, вероятно, либо задерживаются допоздна, либо проводят дополнительное время дома.

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

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

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

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

Раньше я работал в некоммерческой организации, у которой была эта проблема. Встречи всегда начинались с опозданием, опоздание на 10 минут стало “стандартом”.

Потом мы получили нового менеджера проекта для большого ключевого проекта (и одного на фиксированной временной шкале). Она созвала первую встречу. Люди заходили как обычно, опаздывали на минутку и случайно общались. Она сидела в своем кресле и ничего не говорила - вообще ничего - в течение нескольких минут. В конце концов, чаты “затихли” до тех пор, пока не наступила тишина. Мы все ждали, когда услышим ее речь. Она позволила тишине продолжаться еще немного. Она оглянулась вокруг и сказала: “Мне нужно все прояснить”. Встречи начинаются вовремя. Если вы опаздываете на 5 минут, не утруждайтесь приездом, просто увидите меня после. Хорошо, теперь для проекта, который мы делаем на этой неделе [неважно]…“… Это произвело большое впечатление, и люди приложили реальные усилия, чтобы быть вовремя для ее встреч.

Примечание: Добавлен дополнительный ответ ниже._

Счет за работу, проделанную удаленно.

Часто самые высокие производители делают большую часть своей работы remotely в любом случае, поэтому они иногда ставят столько же времени удаленно, как и в офисе. Это важный момент как для рассмотрения, так и для общения с другими отделами. Это общение должно быть тонким - не звоните на собрание, просто начните искать способы показать "да, Джо вчера не спал допоздна, работая над Х” и “да, Мэри исправила это в воскресенье, она не спала "до полуночи”.

Поговорите открыто о поездке на работу. Если кто-то зайдет в 10.30, его поездка может занять 15 минут. Если им нужно быть в 9 или 9.30, их поездка может занять час. Плюс это будет то же самое, что ехать домой, если они работали 8 или 9 часов. Многие люди чувствуют, что это большая потеря их жизни. Они предпочитают работать удаленно некоторое время, а потом приезжать после этого. Посмотрите, чтобы объединить этот факт с вашими потребностями при установке времени и убедитесь, что другие отделы знают об этом тоже, снова упомянув его часто.

Убедитесь, что вы используете technology, чтобы помочь. Например, я работаю виртуально - 100% времени. Так что включение Skype, отображение моего статуса онлайн, видеокамера и т.д. тоже может помочь.

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

Самым практичным и простым решением…

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

Команда действительно не имеет никакого представления о том, что происходит с другими отделами и что они РЕАЛЬНО должны делать.

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

Так как другие отделы начинаются в 8 вы можете ** использовать эту задержку встречи команды в вашу пользу. Между 8 и 11 у вас есть **3 часа, чтобы помочь вашей команде с деятельностью по управлению проектами, такими как (не в определенном порядке или приоритете):

• Пойти на встречи и собрать цели и требования от других отделов
• выяснить, что было закончено со вчерашнего дня
• Управление ожиданиями и обязательствами с другими отделами о том, что нужно и может быть сделано в течение рабочего дня
• Доставка хороших новостей и плохих новостей для других отделов
• Обновите любые планы, имеющие отношение к команде, если есть
• выяснить, какие проблемы с кодом и программной архитектурой должны иметь внимание сегодня
• сказать “нет” на запросы, которые не обеспечивают никакой деловой ценности
• принять критику от других квартир и принести извинения с уверенностью, что проблемы будут исправлены
• и т.д.. (всегда есть что-то, что должно быть рассмотрено)

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

Во время встречи с командой вам нужно две вещи из них:

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

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

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

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

Что касается перемещения разработчиков в какое-то фиксированное расписание доступности, лучшим вариантом будет обеспечить максимально возможное смягчение любых “трудных часов”. Например, если “часы ядра” с 11:00 до 15:00, то вы также можете убедиться, что часы ядра в пятницу не присутствуют, а пятница - это настоящий день гибкого времени. Так как вторник, среда и четверг традиционно считаются самыми продуктивными днями недели, вы можете иметь возможность применить основные часы в эти дни и позволить понедельник и пятницу также быть полными гибкими днями.

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

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

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

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

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

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

Есть еще несколько способов решения этой проблемы, одним из которых было бы изменение роли, которую играет отдел, например: Если вы работаете с разработчиками программ, вы можете изменить роль для определенного человека или людей в течение недели, чтобы они оказывали поддержку другим отделам, что требует, чтобы 1 или более человек пришли в 9 или более ранние сроки, и если это не сработает, вы всегда можете сослаться на пункт о неподчинении, который обычно присутствует в любом руководстве по трудоустройству ** в США. Лично я всегда был против использования этого пункта, который дает менеджеру возможность сделать выговор и даже уволить кого-то ** по причине, но в вашем случае это может быть уместно. Так что просмотрите Справочник работника и обсудите его с вашим начальником, если у вас есть что-то, что вы будете делать это.

Основная идея заключается в следующем:

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

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

• BlogSpot
• Duhaime

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

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

В принципе, вы должны решить, что важнее - правильно выполнить работу или сидеть за своим рабочим столом 8 часов в назначенное время?