Pull to refresh

Comments 42

Я думаю эт фишка просвещенной демократии такая, нам не понять.

Доморощенные "демократы" фанаты яблок, видимо заминусовали :))

Занятно - такую же унылую петросянщину про кровавый российский режим обычно так сильно не минусят. Так что я таки поставлю на доморощенных демократов.

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

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

Причина вероятно, чтобы работник помыкавшись вернулся обратно или же зная чем грозит(от уволившихся коллег) и не думал увольняться.
Либо уменьшение выплат после увольнения, если они есть в тех странах.
Либо ещё что то, что я не могу придумать.

Либо ещё что то, что я не могу придумать.

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

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

 это какой-то прям фантастический костыль.

Если этом минимальный набор, так сказать Default RO access, то почему нет? Вполне удобная полиси. Лишний раз избавляет от человеческого фактора, когда кто-то где-то что-то забыл отозвать.

Опять же из личного опыта: большинство лидов не хотят (и я тут с ними согласен), на каждого нового сотрудника запрашивать все необходимые ему доступы. Нет. Им хочется чтобы условный программист проекта А автоматически by Default, получал доступ к ресурсам 1-3-5 и проуктам X и Y. Для этого формируются рабочие default правила для различных проектов, департаментов и должностей.

Кто ж спорит, доступы гораздо удобнее (=> меньше ошибок => безопаснее) раздавать не поштучно, а по ролям. Но о том и речь, что ролевая модель должна быть гораздо более гибкой, чем штатное расписание. Старший разработчик сайта apple.com, который у всех на виду, и старший разработчик какого-нибудь секретного проекта типа беспилотных автомобилей - явно очень разные доступы имеют. Даже у похожих проектов (Apple TV и Music) - наверняка к репозиториям друг друга доступов нет.

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

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

Тут, чтобы понять причину и следствие надо знать как внутри система устроена и как HR процессы интегрированы со всем остальным.

. Даже у похожих проектов (Apple TV и Music) - наверняка к репозиториям друг друга доступов нет.

Да, но это и регулируется базовыми шаблонами + кастомными настройками. Как специалисты уровня А, работники обоих их департаментов имеют доступы к ресурсам X, Y и Z. И уже в добавок в ним сверху имеют дополнительные доступы в рамках своих проектов.

А теперь представим, что перевод любого из них на роль Associate автоматически отзывает все выданные ранее доступы, но при этом сохраняет в системе саму учетную запись для истории и возможных контактов (в том числе и рабочих) с бывшим сотрудников впоследствии. Т.е. это что-то вроде Default User получается.

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

А нельзя банально заблокировать учётку по дате увольнения/ухода в отпуск?

Можно. Но перед блокировкой все равно правильно отозвать все начисленные доступы и провести полный аудит того, что на эту учетку выдавалось.

А это далеко всегда тривиально. Поэтому блокировка никак не исключает изменения статуса самой учетки. Перевели в низший ранг - > Отключили.

Теперь даже если ее реанимируют, доступов на ней все равно не будет. А реанимировать ее могут по 1001 причине.

UFO just landed and posted this here

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

Думаю, проще. Apple исторически не любит раскрывать внутреннюю кухню. И здесь тоже - просто очень не хочет раскрывать структуру и соответствие зарплат должностям для автоматических сборщиков.

но остаётся необъясненным, почему "разжалуют" на время отпуска.

Ещё вариант: чтоб конкуренты не собирали их бывших/отлучившихся сотрудников, чтоб использовать их знания в конкуренции.

Если это происходит даже когда человек уходит в отпуск, то я готов спорить, что это окажется багом.

Кто-то когда-то давно, писал сервис для отдела кадров, но перепутал название столбца. В колонке pos_at_work, 0 значит помощник, а в колонке cur_time_at_work - 0 это не работает. Ну или что-то в таком духе.

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

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

UFO just landed and posted this here

 InVerify может предоставить полную и точную информацию о заработной плате в компании по номеру соцстрахования соискателя, соотнеся её таким образом с той или иной должностью.

В Германии за подобное миллиардные штрафы...

UFO just landed and posted this here

То ли дело у нас: бумажные трудовые книжки, где раз написано "старший подползающий к младшему помощнику" - топором не вырубишь...

Бумажные трудовые книжки хранятся у работодателя и могут заполняться задним числов при уволнении (или проверки) и туда тоже можно записать, что угодно.
UFO just landed and posted this here
Практика показывает, что совсем уж что угодно оттуда можно выкорчевать решением суда.

Сейчас все трудовые книжки имеют электронную версию, которую можно посмотреть через госуслугу ПФР.

Такое нельзя написать без подписи сотрудника. Переводы (все) проводятся исключительно с подписью сотрудника, в России.

в России уже есть электронные тр. книжки.

Ну да, Эппл пролоббировал ;)

И какой смысл для других работодателей вообще проверять по этой базе? Ведь если у ВСЕХ бывших сотрудников Apple будет одна и та же должность - значимость этой базы примерно равна нулю.

Поэтому они не проверяют по базе. А проверяют по телефону. А когда срабатывает телефон - звучит звоночик: "ваш сотрудник меняет работу."

Нужно эйчару иметь IQ на уровне плинтуса, чтобы всерьез делать такой финт ушами: HR будущего работодателя звонит текущему работодателю, типа, а действительно у вас такой работает на такой-то должности, и, чтобы дважды не вставать, можете ему характеристику дать?)ь

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

Работодатель обманывает увольняющихся сотрудников и портит им дальнейшую карьеру. Никогда такого небыло и вот - опять!

Наверняка таким образом Apple борется с дискриминацией бывших сотрудников. Сплошное равенство.
А если серьёзно, то чего еще ожидать от компании, которая всерьёз патентует «прямоугольник со скругленными углами»…

в армии при увольнении всем срочникам в части всех повышали в звании до старших сержантов ради выплат

Как обнаружилось в базах данных, к которым компании обращаются при проверке информации о должностях работников, Apple перед увольнением меняет название должности каждого сотрудника на Associate (сотрудник, помощник). 

Я правильно понял, что информация о работнике хранится в какой-то сторонней БД? У работодателя (не только Apple) есть обязанность передавать в нее информацию о своих текущих (в отпуске) и бывших сотрудниках? Информаация по закону должна быть достоверной? Доступ к этой БД может получить любой (рекрутер)?

Почему база данных не может предоставлять историю изменений вместо последней записи?

Sign up to leave a comment.

Other news