پاسخ کوتاه: مدیریت زمان در انتقال شغل یعنی سه جریان را با هم قاطی نکنید: پایان مسئولانه در شغل فعلی، امور اداری/شخصی میان دو شغل و یادگیری پس از ورود به نقش جدید. از آخرین روز و تاریخ شروع به عقب برنامهریزی کنید؛ برای هر کار خروجی، مالک بعدی، معیار پذیرش و موعد بنویسید. دانش را منتقل کنید، اما رمز عبور، کلید خصوصی، داده محرمانه یا فایل سازمان را در سند شخصی نگذارید. برنامه ۳۰روزه شغل جدید را نیز پس از گفتوگو با مدیر و براساس نقش واقعی بسازید، نه بهعنوان وعدهای که پیش از دسترسی و شناخت سازمان دادهاید.
دامنه این راهنما؛ انتقال از چه زمانی شروع میشود؟
این برنامه برای زمانی است که خروج از نقش فعلی و شروع نقش بعدی به اندازه کافی قطعی شدهاند و میتوانید تاریخها، تعهدها و محدودیتها را با طرفهای مربوط هماهنگ کنید. اگر هنوز پیشنهاد مکتوب، نتیجه بررسیهای استخدامی یا تاریخ شروع روشن نیست، تصمیمهای برگشتسخت مثل استعفا را فقط براساس هیجان یا پیام غیررسمی نگیرید.
قرارداد، دوره اعلام، مرخصی، محرمانگی، منع رقابت، مالکیت فکری، مالیات و بیمه به کشور، نوع همکاری و متن توافق بستگی دارند. این مقاله مشاوره حقوقی/مالی نیست. متن قرارداد و policy رسمی را بخوانید و برای تصمیم پرریسک از HR، منبع رسمی بهروز یا متخصص واجدصلاحیت همان حوزه کمک بگیرید.
سه جریان کار را جدا کنید
| جریان | هدف | مالک تصمیم | نمونه خروجی |
|---|---|---|---|
| خروج از نقش فعلی | کاهش کار بیمالک و انتقال امن | مدیر/مالک فرایند فعلی | فهرست کار باز، بسته انتقال، صورت دسترسی |
| پل شخصی و اداری | حفظ ظرفیت، مدارک و قطعیت تاریخها | فرد + HRهای مربوط | تقویم، مدارک، تجهیزات، رفتوآمد/مراقبت |
| ورود به نقش جدید | شفافیت نقش، تسلط تدریجی و اتصال اجتماعی | مدیر جدید + تیم + فرد | برنامه onboarding، نقشه ذینفع، هدف ۳۰روزه |
یک فهرست واحد میتواند هر سه را نشان دهد، اما زمان، داده و حسابهایشان جدا بماند. وظیفه شرکت آینده را روی سامانه شرکت فعلی و فایل محرمانه شرکت فعلی را روی دستگاه شخصی/شرکت آینده نگه ندارید.
از دو تاریخ لنگر به عقب برنامهریزی کنید
دو تاریخ مستقل دارید: آخرین روز دسترسی در سازمان فعلی و نخستین روز/شیفت رسمی در سازمان جدید. ممکن است بین این دو فاصله، همپوشانی یا ابهام باشد. با روش برنامهریزی معکوس milestoneها را بسازید، اما فرضهای حقوقی و سازمانی را از واقعیت تأییدشده جدا کنید.
| بازه نمونه | تصمیم اصلی | تحویل قابلمشاهده |
|---|---|---|
| T-۱۵ تا T-۱۰ | چه چیزی تمام، منتقل، متوقف یا renegotiate شود؟ | inventory و تصمیم مدیر |
| T-۹ تا T-۵ | چه دانشی برای ادامه امن لازم است؟ | runbook/decision log + جلسه walkthrough |
| T-۴ تا T-۱ | دارایی، حساب، مخاطب و کار باز چگونه بسته شود؟ | پذیرش انتقال و چکلیست offboarding |
| فاصله میان دو شغل | کدام امور اداری/بازیابی واقعاً لازماند؟ | مدرک، تجهیزات، مسیر رفتوآمد، استراحت |
| T+۱ تا T+۳۰ | نقش، شبکه، سیستم و خروجی اولیه چیست؟ | برنامه مشترک یادگیری/تحویل و بازخورد |
این روزها نمونهاند و با notice period، حساسیت نقش، شیفت، تعطیلی و فرایند سازمان تغییر میکنند. هدف داشتن dependency و owner است، نه فشردهکردن همه انتقال در ۱۵ روز.
روز صفر: محدودیتها و تعهدها را روی یک صفحه بیاورید
- آخرین روز کاری، آخرین روز دسترسی و تاریخ پرداخت/مزایا—هرکدام جدا؛
- تاریخ شروع، ساعت/منطقه زمانی، محل، نام مدیر و وضعیت تجهیزات؛
- تعهدهای جاری که فقط شما میتوانید تکمیل کنید و دلیل آن؛
- کارهایی که باید منتقل، متوقف یا با scope کمتر تحویل شوند؛
- مرخصی، مراقبت، جابهجایی، درمان یا دسترسپذیری لازم؛
- محدودیت محرمانگی، تعارض منافع و استفاده از ابزار/حساب؛
- ریسکهای باز مثل تأخیر قرارداد، بررسی استخدامی یا آمادهنبودن دستگاه.
اگر ظرفیت با تعهدها نمیخواند، زود مذاکره کنید. راهنمای تریاژ اضافهبار کاری کمک میکند شکاف را به کار تکمیل/انتقال/توقف تبدیل کنید؛ شبکاری پنهان ظرفیت واقعی نمیسازد.
Inventory خروج؛ هر کار باید تصمیم داشته باشد
| فیلد | پرسش | نمونه |
|---|---|---|
| خروجی/خدمت | چه نتیجهای باید ادامه یابد؟ | گزارش هفتگی، سرویس، قرارداد مشتری |
| وضعیت شواهدی | Done/درحال/مسدود با چه مدرکی؟ | نسخه، لینک مخزن، آخرین تصمیم |
| گام/تصمیم بعدی | بعد از خروج دقیقاً چه رخ میدهد؟ | تأیید بودجه یا اجرای release |
| مالک بعدی | چه کسی اختیار و ظرفیت دارد؟ | نقش/نام تأییدشده، نه «تیم» |
| پذیرش | چه کسی انتقال را قبول کرده است؟ | manager/process owner |
| ریسک/dependency | چه چیزی ممکن است ادامه را متوقف کند؟ | vendor، دسترسی، deadline، تصمیم |
| محل رسمی | اطلاعات کجا نگهداری میشود؟ | wiki، ticket، repository، DMS |
فهرست فعالیت کافی نیست؛ باید خروجی و تصمیم بعدی را نشان دهد. «پروژه X — درحال انجام» به جانشین نمیگوید کدام فرض معتبر، کدام trade-off تصویب و چه چیزی منتظر تصمیم است.
چه چیزی را تمام، منتقل، متوقف یا کوچک کنیم؟
چهار مسیر تعریف کنید و مدیر/مالک خروجی را وادار به انتخاب کنید:
- Finish: کار کوتاه و پرارزش که تا موعد با معیار پذیرش واقعی تمام میشود؛
- Transfer: نتیجه لازم است اما اجرای آن از بازه شما بیرون میرود؛
- Stop: ادامه ارزش/مجوز ندارد و بستهشدنش ثبت میشود؛
- Rescope: حداقل خروجی پذیرفتهشده تحویل و باقیمانده تصمیمدار میشود.
خروج نزدیک، هر کار را فوری نمیکند. مدیر ممکن است رابطه، ریسک یا تعهدی را بداند که شما نمیدانید. تصمیم را مستند کنید تا آخرین روز به مسابقه اثبات فداکاری تبدیل نشود.
انتقال مسئولیت، صرفاً معرفی جانشین نیست
مالک بعدی به چهار چیز نیاز دارد: اختیار، دسترسی، ظرفیت و معیار Done. اگر فقط نام او در سند بیاید اما مدیر اختیار تصمیم یا زمان کار را منتقل نکند، واگذاری صوری است. راهنمای واگذاری اختیار و پاسخگویی برای طراحی acceptance مناسب است.
برای هر مورد جلسه walkthrough کوتاه بگذارید: جانشین سناریو را با حساب خودش اجرا یا تصمیم بعدی را توضیح دهد؛ شما شکاف را ثبت کنید. حضور در جلسه بهتنهایی acceptance نیست. اگر جانشین تعیین نشده، manager مالک موقت ریسک است.
بسته انتقال دانش چه اجزایی دارد؟
- Purpose و scope: این فرایند/سیستم چه نتیجهای میدهد و چه چیزی بیرون دامنه است؟
- Current state: نسخه، آخرین خروجی، کار باز، blocker و تاریخ freshness.
- Cadence و trigger: چه رخداد یا تاریخی کار را آغاز میکند؟
- تصمیمها: چه گزینهای، چرا، با کدام فرض و چه زمانی بازبینی شود؟
- Runbook: مسیر عادی، failure mode، escalation و rollback.
- People map: نقش، مسئولیت و کانال رسمی؛ نه فهرست روابط خصوصی.
- Access map: چه نوع دسترسی لازم است و owner صدور/لغو کیست؛ بدون credential.
- Next 3 actions: مالک، موعد، dependency و acceptance.
سند حجیم با لینکهای مرده انتقال دانش نیست. یک task واقعی را از روی بسته اجرا کنید و تاریخ/مالک نگهداری سند را بنویسید. اگر خروج موقت و بازگشت خودتان مطرح است، دامنه متفاوتِ برنامه مرخصی و handoff را ببینید.
هرگز فهرست رمز عبور تحویل ندهید
رمز، private key، token، کد بازیابی و credential شخصی «دانش ضمنی» نیستند. آنها را در Word، ایمیل، پیامرسان یا فایل بسته انتقال ننویسید. دسترسی باید از مسیر IT/امنیت، حساب فردی یا vault سازمانی و براساس policy منتقل شود؛ حساب مشترک ناگزیر نیز owner، rotation و audit میخواهد.
NIST ۸۰۰-۱۷۱ Rev.۳ حفاظت authenticator را شامل در اختیار نگهداشتن و بهاشتراکنگذاشتن آن و در پایان همکاری، لغو credential و بازیابی دارایی امنیتی میداند. این استاندارد برای محیطهای مشخص آمریکایی نوشته شده، اما اصل امنیتیِ «credential را منتقل نکن؛ دسترسی را provision کن» کاربرد عمومی دارد. منبع: NIST SP 800-171 Rev.3.
قطع دسترسی وظیفه فرایند سازمان است
کارمند نباید خودش حساب را به نفر بعد بدهد یا برای کمک آینده دسترسی پنهان نگه دارد. فهرست حسابها، گروهها، دستگاهها، badge، کلیدها، repository، SaaS، API، forwarding و مالک داده را به IT/manager اعلام کنید؛ سازمان زمان لغو، انتقال مالکیت و نگهداری رکورد را تعیین کند.
راهنمای NCSC توصیه میکند فرایند joiners, movers and leavers وجود داشته باشد تا دسترسی در تغییر نقش اصلاح و هنگام خروج لغو شود؛ حساب موقت نیز باقی نماند. منبع: راهنمای مدیریت هویت و دسترسی NCSC. این منبع قانون ایران یا زمانبندی شرکت شما نیست؛ policy و سطح ریسک سازمان مقدم است.
مرز داده و مالکیت فکری را حفظ کنید
- فایل مشتری، کد، قرارداد، فهرست تماس، prompt، گزارش یا سند داخلی را برای «نمونهکار» کپی نکنید؛
- پیامهای شخصی مجاز را طبق policy جدا کنید، نه با export کامل mailbox؛
- داده شخصی همکار/مشتری را وارد CRM یا دفترچه شرکت جدید نکنید؛
- خروجی عمومی و نقش خود را بدون افشای جزئیات محرمانه برای رزومه توصیف کنید؛
- قبل از حذف یا انتقال فایل، retention، legal hold، backup و owner را بررسی کنید؛
- پس از خروج، سؤالها فقط از کانال و دامنه توافقشده پیگیری شوند.
«من این فایل را ساختهام» بهتنهایی مالکیت یا حق انتقال را ثابت نمیکند. قرارداد و policy را مبنا قرار دهید.
تقویم دو کارفرما را مخلوط نکنید
در ساعت و تجهیزات شغل فعلی، برای شرکت آینده کار نکنید مگر هر دو طرف و قرارداد اجازه روشن داده باشند. پیش از شروع، امور اداری لازم مثل فرم مجاز، انتخاب تجهیزات یا هماهنگی ساعت را از یادگیری/تولید واقعی جدا کنید. اگر شرکت آینده تکلیف، جلسه یا خروجی میخواهد، وضعیت استخدام، زمان، جبران و دسترسی امن را مکتوب روشن کنید.
برای جلوگیری از «همیشه در دسترس» شدن، ساعات، کانال عادی، فوریت و استثنا را تعیین کنید. راهنمای مرزبندی ساعات کاری کمک میکند تعهد پاسخ را از courtesy جدا کنید. عنوان «انتقال» مجوز کار شبانه نامحدود نیست.
پیش از شروع شغل جدید چه کاری مجاز و مفید است؟
| کار | پیشفرض محتاطانه | سؤال تأیید |
|---|---|---|
| فرم/هویت/حقوق و مزایا | فقط پورتال و درخواست رسمی | مهلت، حریم داده، contact رسمی؟ |
| تجهیزات و دسترسی | ثبت نیاز، نه دورزدن کنترل | چه کسی تحویل/فعال میکند؟ |
| مطالعه عمومی | محدود و داوطلبانه | آیا واقعاً برای روز اول لازم است؟ |
| آموزش/جلسه/کار واقعی | نیازمند توافق روشن | زمان، جبران، محرمانگی و owner چیست؟ |
| شبکهسازی | دعوت رسمی و کمفشار | آیا فرد موظف/آماده تعامل است؟ |
پروفایلگردی گسترده همکاران شناخت فرهنگ نیست و میتواند حریم را نقض کند. از manager بخواهید stakeholder map، برنامه روز اول و مواد رسمی را ارائه کند. «اثر اولیه خوب» با کار رایگان یا نمایش آمادگی افراطی تضمین نمیشود.
فاصله میان دو شغل را کاملاً پُر نکنید
اگر فاصلهای دارید، همه آن را به دوره آنلاین، شبکهسازی و آمادهسازی تبدیل نکنید. امور ضروری را جدا کنید: خواب/بازیابی، مراقبت، رفتوآمد، لباس/ابزار لازم، اسناد و برنامه روز اول. اگر فاصله ندارید، نسخه کوچک بازیابی مثل پایان روشن روز آخر، غذای آماده و حذف تعهد غیرضروری بسازید.
برای تمایز خستگی، ساعات طولانی و بازیابی از تشخیص پزشکی، راهنمای برنامه بازیابی کار و زندگی را ببینید. بیخوابی مداوم، اضطراب شدید یا اختلال عملکرد با time blocking درمان قطعی نمیشود.
Onboarding مسئولیت مشترک است، نه پروژه مخفی تازهوارد
CIPD، induction را فرایندی برای یادگیری سازمان، تیم و نقش معرفی میکند و بر اطلاعات policy/administration، معرفی افراد و روشنکردن مسئولیت/انتظار تأکید دارد. منبع: راهنمای induction مؤسسه CIPD. این راهنمای حرفهایِ بریتانیاست، نه قانون یا تضمین retention.
فرد تازهوارد میتواند سؤال، یادداشت و بازخورد فعال داشته باشد، اما manager/HR/IT نیز باید دسترسی، context، آموزش، expectation و اتصال به افراد را فراهم کنند. شکست onboarding را به «کمبود انگیزه» فرد تقلیل ندهید.
بهجای طرح ثابت ۳۰–۶۰–۹۰، چهار خروجی سازگار بسازید
یک متاآنالیز روی ۷۰ نمونه مستقل، role clarity، self-efficacy/task confidence و social acceptance را سازوکارهای نزدیکِ adjustment بررسی کرد و ارتباط آنها را با پیامدهای شغلی مدل کرد. این پژوهش از برنامه عددی ۳۰–۶۰–۹۰ یا نتیجه تضمینی برای هر نقش دفاع نمیکند. منبع: مرور متاآنالیتیک newcomer adjustment.
- Role clarity: خروجی، اختیار، priority، معیار کیفیت و escalation روشن شوند؛
- Task mastery: دسترسی و تمرین برای یک جریان واقعی، با بازخورد و محیط امن؛
- Social connection: افراد مرتبط با کار، نه تعداد زیادی coffee chat؛
- Context: مشتری، سیستم، واژگان، تصمیمهای قبلی و constraintهای سازمان.
برای هر خروجی، milestone را با manager co-create کنید. نقش اضطراری، senior، فروش، عملیات، کارآموز و انتقال داخلی سرعت/ریسک متفاوت دارند.
برنامه ۳۰روزهای که با مدیر ساخته میشود
| بازه | پرسشها | خروجی نمونه |
|---|---|---|
| روز ۱–۳ | دسترسی، ایمنی، نقش، ساعات و سؤال فوری چیست؟ | access map و glossary اولیه |
| هفته اول | سه خروجی مهم، ذینفع و تعریف کیفیت چیست؟ | role charter و stakeholder map |
| هفته دوم | یک کار کمریسک چگونه end-to-end اجرا میشود؟ | نمونه تحویل + feedback |
| هفته سوم | کدام dependency یا فرض اشتباه بود؟ | risk/decision log بهروز |
| هفته چهارم | چه چیزی ادامه، اصلاح یا متوقف شود؟ | مرور ۳۰روزه و برنامه بعدی |
روزها نمونهاند. دسترسی دیررس، تعطیلی، پیچیدگی سیستم یا نقش حساس timeline را تغییر میدهد. خروجی زودهنگام نباید برای نمایش سرعت، کنترل ایمنی یا review را دور بزند.
هفت سؤال هفته اول
- سه نتیجهای که این نقش برای چه کسی تولید میکند چیست؟
- چه چیزی اکنون اولویت نیست؟
- چه تصمیمهایی در اختیار من، manager یا گروه دیگری است؟
- تعریف Done/quality و شواهد پذیرش چیست؟
- کدام سیستم منبع رسمی و کدام سند ممکن است قدیمی باشد؟
- برای blocker، incident، خطا و درخواست دسترسی به چه کانالی میروم؟
- feedback در چه cadence و با چه مثالهایی داده میشود؟
سؤالها را batch کنید اما blocker امنیتی یا توقف کار را پشت جلسه هفتگی نگه ندارید. یادداشت محرمانه را در ابزار شخصی یا سرویس تأییدنشده ذخیره نکنید.
یادگیری و تحویل را در یک portfolio محدود کنید
در هفتههای اول چهار سبد کافی است: mandatory/safety، role-critical، relationship/context و improvement later. WIP یادگیری را محدود کنید؛ ده دوره همزمان mastery نمیسازند. یک مسیر واقعی را انتخاب کنید، مشاهده کنید، با نظارت اجرا کنید، بازخورد بگیرید و سپس سطح استقلال را بالا ببرید.
ریتم انرژی خود را مشاهده کنید، اما صبح را برای همه «بهترین زمان» ننامید. راهنمای مدیریت انرژی در کار برای تطبیق نوع کار با وضعیت واقعی و محدودیت جسمی مناسب است.
ریسکهای انتقال را پیش از بحران بنویسید
| ریسک | نشانه زودهنگام | پاسخ/مالک |
|---|---|---|
| تأخیر/تغییر شروع | تاریخ یا شرطهای پیشنهاد نامشخص | تأیید مکتوب HR؛ تصمیم مالی/حقوقی جدا |
| جانشین/پذیرش نامعلوم | نام مالک در inventory خالی است | manager مالک موقت و rescope میکند |
| تجهیزات/دسترسی دیر | ticket یا مسئول روز اول نیست | IT/manager مسیر جایگزین امن میدهد |
| درخواست کار پیش از شروع | deadline بدون وضعیت/جبران | شفافسازی کتبی با HR/manager |
| نقش مبهم | ذینفعان معیارهای متعارض دارند | role charter و priority decision |
| ظرفیت/سلامت | شبکاری، خواب مختل، تعهد ناممکن | کاهش scope، استراحت، حمایت/کمک لازم |
Counteroffer، لغو پیشنهاد یا فاصله درآمدی تصمیمهای چندبعدیاند. هزینه، قانون، بیمه، ویزا، خانواده و برگشتپذیری را با منابع مربوط بسنجید؛ هیچ تکنیک زمان بهتنهایی پاسخ درست نمیدهد.
فشار انتقال را فردیسازی نکنید
WHO بار زیاد، ساعات طولانی/نامنعطف، کنترل کم، نقش مبهم، حمایت محدود و ناامنی شغلی را از ریسکهای روانیاجتماعی کار میداند و مداخله سازمانی روی شرایط کار را توصیه میکند. منبع: برگه اطلاعات سلامت روان در کار WHO.
پومودورو، ورزش یا مثبتاندیشی جای کمبود نیرو، deadline ناممکن، آزار یا تعارض قرارداد را نمیگیرد. نشانههای شدید، پایدار یا مختلکننده نیازمند ارزیابی حرفهایاند؛ خطر فوری را به خدمات اورژانسی/حمایتی محل ارجاع دهید.
مرور دوگانه هفتگی
تا آخرین روز، دو مرور جدا داشته باشید:
- Exit review: چه چیزی پذیرفته شد، مالک کجاست، چه ریسکی باز است و چه دسترسی/دارایی باید تحویل شود؟
- Personal bridge review: تاریخها، مدارک، ظرفیت، خواب، خانواده و فقط امور رسمی شرکت جدید چه وضعی دارند؟
پس از شروع، exit review بسته و onboarding review جای آن را میگیرد. از الگوی مرور هفتگی برای جمعکردن کار باز استفاده کنید، اما داده دو سازمان را در یک سند غیرمجاز ادغام نکنید.
شاخصهای سالم انتقال
- درصد کارهای باز با تصمیم finish/transfer/stop/rescope و مالک پذیرفتهشده؛
- تعداد runbookهایی که با یک سناریوی واقعی walkthrough شدهاند؛
- ریسکهای باز با owner و next review، نه صفر ریسک نمایشی؛
- دارایی/حسابهایی که IT/مالک رسمی دریافت و ثبت کرده است؛
- در شغل جدید: زمان تا دسترسی لازم، role clarity و feedback cadence؛
- یک خروجی کمریسک پذیرفتهشده، نه تعداد ساعت آنلاین یا جلسه؛
- اضافهکاری، خواب و نقض مرز بهعنوان هشدار ظرفیت، نه رتبه فرد.
تعداد سند، پیام LinkedIn، دوره آموزشی و coffee chat KPI موفقیت نیست. کیفیت انتقال را با ادامه کار و کاهش ابهام بسنجید.
سه مثال زمینهمند
مهندس نرمافزار با دسترسی حساس
سرویسها، runbook، incidentهای باز، repository و access owner ثبت میشوند؛ secret در سند نمیآید. جانشین با حساب خودش یک deploy کمخطر را در مسیر رسمی تمرین میکند. IT لغو حساب و rotation لازم را مالک است.
مدیر پروژه با قرارداد مشتری
هر پروژه next decision، stakeholder، تعهد، assumption، change و acceptance دارد. تماس شخصی مشتری به شرکت جدید منتقل نمیشود. manager فعلی معرفی مالک بعدی را رسمی و موعدهای ناممکن را rescope میکند.
تازهوارد دورکار بدون تجهیزات روز اول
فرد از دستگاه شخصی وارد داده حساس نمیشود. manager کار امنِ بدون دسترسی، زمان تحویل دستگاه و escalation را تعیین میکند. طرح ۳۰روزه پس از روشنشدن سیستم/نقش اصلاح میشود و تأخیر به ضعف انگیزه فرد نسبت داده نمیشود.
خطاهای رایج
- قهرمانبازی روزهای آخر: همه کارها finish و شبکاری جای rescope میشود.
- سند بیمالک: صد صفحه نوشته میشود اما کسی آن را نپذیرفته است.
- فهرست رمز: credential بهجای provision دسترسی تحویل میشود.
- کپی برای نمونهکار: داده/کد سازمان بدون مجوز خارج میشود.
- تماس دائمی پس از خروج: دامنه، کانال، زمان و جبران روشن نیست.
- کار رایگان پیش از شروع: task واقعی با «آمادگی» اشتباه میشود.
- طرح ۳۰–۶۰–۹۰ یکطرفه: بدون manager، access یا شناخت constraint تعهد ساخته میشود.
- شبکهسازی نمایشی: تعداد ارتباط جای role clarity و کار واقعی را میگیرد.
- پرکردن فاصله: بازیابی با دوره و تکلیف بیشتر حذف میشود.
- خودمراقبتی بهجای طراحی کار: بار ناممکن و نقش مبهم فردیسازی میشوند.
چکلیست نهایی انتقال شغل
- پیشنهاد/خروج و تاریخها در سطح لازم تأیید شدهاند.
- قرارداد، policy و نیاز مشورت حقوقی/مالی مشخصاند.
- سه جریان خروج، پل شخصی و onboarding جدا هستند.
- هر کار خروج تصمیم، owner، acceptance، risk و محل رسمی دارد.
- بسته انتقال با سناریوی واقعی آزمایش و تاریخدار شده است.
- هیچ password، token، key یا فایل محرمانه منتقل نشده است.
- IT/امنیت مالک provision/revoke و داراییهاست.
- کار پیش از شروع از امور اداری جدا و وضعیتش روشن است.
- برنامه ۳۰روزه با manager و براساس نقش واقعی co-create شده است.
- role clarity، task mastery، social connection و context پوشش دارند.
- نسخه بازیابی، ریسک و مسیر تغییر/لغو تاریخ وجود دارد.
- داده دو سازمان در حساب یا سند غیرمجاز مخلوط نشده است.
پرسشهای متداول مدیریت زمان در انتقال شغل
در روزهای آخر کدام کارها را انجام دهم؟
با مدیر هر مورد را finish، transfer، stop یا rescope کنید. اول تعهد پرریسک، دانش لازم برای ادامه و پذیرش مالک بعدی؛ کار تازه فقط اگر ارزش و ظرفیت روشن دارد.
آیا رمز عبور را در فایل تحویل بنویسم؟
خیر. credential را به اشتراک نگذارید. نوع دسترسی و owner صدور را ثبت کنید و انتقال/لغو را از IT، حساب فردی یا vault تأییدشده انجام دهید. secret موجود در کد/سند باید طبق policy rotate شود.
قبل از روز اول چقدر برای شغل جدید وقت بگذارم؟
عدد عمومی وجود ندارد. امور اداری رسمی و هماهنگی تجهیزات را انجام دهید؛ کار، آموزش اجباری یا جلسه واقعی باید وضعیت، زمان، جبران و محرمانگی روشن داشته باشد. مطالعه عمومی را محدود و داوطلبانه نگه دارید.
آیا برنامه ۳۰–۶۰–۹۰ روزه لازم است؟
قالب ممکن است مفید باشد، اما قانون علمی نیست. ابتدا با مدیر نقش، اولویت، دسترسی و معیار پذیرش را روشن کنید؛ سپس milestoneهای یادگیری و تحویل را بسازید و با داده جدید اصلاح کنید.
اگر شرکت فعلی پس از خروج مدام تماس گرفت چه کنم؟
پیش از خروج کانال، موضوعهای مجاز، مدت دسترسپذیری و در صورت لزوم قرارداد/جبران را روشن کنید. درخواست محرمانه یا نیازمند دسترسی را از مسیر رسمی برگردانید؛ دسترسی قبلی را برای پاسخ حفظ نکنید.

