Comments 42
Я думаю эт фишка просвещенной демократии такая, нам не понять.
Доморощенные "демократы" фанаты яблок, видимо заминусовали :))
Занятно - такую же унылую петросянщину про кровавый российский режим обычно так сильно не минусят. Так что я таки поставлю на доморощенных демократов.
Либо уменьшение выплат после увольнения, если они есть в тех странах.
Либо ещё что то, что я не могу придумать.
Либо ещё что то, что я не могу придумать.
Да элементарные шаблоны доступов например. У минимальной должности, минимум прав в систему. А не удаляют/блокируют на случай если не все дела были корректно переданы/закрыты.
Слушайте, ну взаимно однозначное соответствие между ролями доступа и позицией в штатном расписании - это какой-то прям фантастический костыль.
это какой-то прям фантастический костыль.
Если этом минимальный набор, так сказать 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 причине.
Кстати прикольная идея. Создать скрипт аля на сайте компании который просто выбором должности сотрудника выдаёт ему те или иные права, создает нужные учетки и тэдэ
Думаю, проще. Apple исторически не любит раскрывать внутреннюю кухню. И здесь тоже - просто очень не хочет раскрывать структуру и соответствие зарплат должностям для автоматических сборщиков.
Если это происходит даже когда человек уходит в отпуск, то я готов спорить, что это окажется багом.
Кто-то когда-то давно, писал сервис для отдела кадров, но перепутал название столбца. В колонке pos_at_work, 0 значит помощник, а в колонке cur_time_at_work - 0 это не работает. Ну или что-то в таком духе.
Даже если предположить, что делалось это специально - мотивов данного действия , руководствуясь логикой я представить не могу. Даже с позиции удержания сотрудников, если об этом будут знать все - то это моментальный штраф. А если об этом не знает никто, то и сотрудников это не удержит
На самом деле, учитывая некоторую параноидальность apple, вполне понятно. Если сотрудник ищет работу, например во время отпуска, то любое уточнение будет звоночком об этом в компанию. Кроме того, это может затруднять работу хедхантерам, они, конечно, могут найти информацию о должности и в другом месте.
InVerify может предоставить полную и точную информацию о заработной плате в компании по номеру соцстрахования соискателя, соотнеся её таким образом с той или иной должностью.
В Германии за подобное миллиардные штрафы...
То ли дело у нас: бумажные трудовые книжки, где раз написано "старший подползающий к младшему помощнику" - топором не вырубишь...
Такое нельзя написать без подписи сотрудника. Переводы (все) проводятся исключительно с подписью сотрудника, в России.
в России уже есть электронные тр. книжки.
И какой смысл для других работодателей вообще проверять по этой базе? Ведь если у ВСЕХ бывших сотрудников Apple будет одна и та же должность - значимость этой базы примерно равна нулю.
Поэтому они не проверяют по базе. А проверяют по телефону. А когда срабатывает телефон - звучит звоночик: "ваш сотрудник меняет работу."
Нужно эйчару иметь IQ на уровне плинтуса, чтобы всерьез делать такой финт ушами: HR будущего работодателя звонит текущему работодателю, типа, а действительно у вас такой работает на такой-то должности, и, чтобы дважды не вставать, можете ему характеристику дать?)ь
Кроме того, если HR Apple так реагирует на звонки, то сразу возникает идея троллинга со стороны конкурентов - звонить и спрашивать про конкретных ценных для Apple сотрудников, которые даже не собирались искать другую работу.
Эппл начинает нагнетать атмосферу подозрительности вокруг жертвы, после чего её можно уже спокойно переманивать - всё равно ничего хорошего в Apple попавшего в черный список сотрудника уже не ждёт...
RIP Steve Jobs, CEO associate.
Работодатель обманывает увольняющихся сотрудников и портит им дальнейшую карьеру. Никогда такого небыло и вот - опять!
А если серьёзно, то чего еще ожидать от компании, которая всерьёз патентует «прямоугольник со скругленными углами»…
в армии при увольнении всем срочникам в части всех повышали в звании до старших сержантов ради выплат
Как обнаружилось в базах данных, к которым компании обращаются при проверке информации о должностях работников, Apple перед увольнением меняет название должности каждого сотрудника на Associate (сотрудник, помощник).
Я правильно понял, что информация о работнике хранится в какой-то сторонней БД? У работодателя (не только Apple) есть обязанность передавать в нее информацию о своих текущих (в отпуске) и бывших сотрудниках? Информаация по закону должна быть достоверной? Доступ к этой БД может получить любой (рекрутер)?
Почему база данных не может предоставлять историю изменений вместо последней записи?
Apple уличили в смене должности всех сотрудников по увольнении на максимально низкую