انتقال مالکیت کار معمولاً از یک صبح شلوغ شروع می‌شود: کارشناس خرید استعفا داده، مدیر پروژه به مرخصی بلندمدت رفته یا مسئول پیگیری یک پرونده حقوقی ناگهان عوض شده است. روی میز نفر قبلی چند فایل اکسل، یک پوشه درایو، پیام‌های پراکنده و شماره چند نفر بیرون از سازمان می‌ماند. نفر جدید هم از همان روز اول باید جواب بدهد؛ حتی وقتی هنوز نمی‌داند چرا تأمین‌کننده از ارسال پیش‌فاکتور جدید خودداری می‌کند.
مسئله فقط گم‌شدن فایل نیست. ممکن است فایل کامل باشد، اما اختیار تأیید قیمت منتقل نشده باشد؛ ممکن است گزارش‌ها موجود باشند، ولی کسی نداند مدیر مالی روی کدام عدد حساس است؛ یا مشتری هنوز تصور کند باید با همکار قبلی تماس بگیرد. این مقاله یک پروتکل عملی برای انتقال مالکیت کار است؛ روشی که پرونده، اختیار، زمینه تصمیم و رابطه‌ها را یکجا جابه‌جا می‌کند، نه اینکه صرفاً یک پوشه را برای نفر بعدی فوروارد کند.
انتقال مالکیت کار دقیقاً چیست و چرا با تحویل‌دادن فایل فرق دارد؟
وقتی می‌گوییم مالک یک کار، منظورمان کسی است که برای پیش‌برد آن پاسخ‌گوست، اجازه اقدام دارد، به اطلاعات لازم دسترسی دارد و می‌داند در موقعیت‌های مبهم باید سراغ چه کسی برود. مالکیت، عنوان شغلی روی چارت نیست. مثلاً کارشناس منابع انسانی شاید فایل قراردادها را داشته باشد، اما اگر اجازه مذاکره با شرکت بیمه یا تأیید الحاقیه را نداشته باشد، مالک واقعی پرونده نیست.
انتقال مالکیت کار یعنی جابه‌جایی هم‌زمان پنج چیز: پاسخ‌گویی، اختیار، دسترسی، دانش زمینه‌ای و ارتباط با ذی‌نفعان. تحویل یک فهرست وظایف فقط بخش کوچکی از این ماجراست. فهرستی مثل «پیگیری قرارداد، ارسال گزارش، تماس با تأمین‌کننده» به فرد جدید نمی‌گوید قرارداد در کدام مرحله گیر کرده، گزارش برای چه تصمیمی استفاده می‌شود و تأمین‌کننده از کدام تجربه قبلی دلخور است.
هزینه انتقال ناقص معمولاً یک‌باره دیده نمی‌شود. سه روز اول، نفر جدید با سوال‌های زیاد کار را جلو می‌برد. هفته دوم، یک موعد از دست می‌رود. ماه بعد، معلوم می‌شود تخفیفی که در مذاکره شفاهی توافق شده بود هیچ‌جا ثبت نشده است. در یک شرکت خدماتی، جابه‌جایی ناقص مسئول پرونده مشتری باعث شد دو تیم، برای یک درخواست واحد، دو پیشنهاد قیمت متفاوت ارسال کنند. خسارت اصلی تخفیف نبود؛ اعتماد مشتری بود.
این پروتکل برای استعفا یا مرخصی نیست فقط. تغییر مدیر پروژه، جابه‌جایی داخلی، راه‌اندازی شعبه، ادغام دو تیم، پوشش موقت دوران زایمان و حتی تغییر تقسیم کار بین دو نفر، موقعیت‌های رایج آن هستند. اگر تیم فقط هنگام بحران سراغ انتقال مالکیت کار برود، همیشه دیر شروع می‌کند. بهتر است این کار به روال عادی پایان هر پروژه، تغییر شیفت یا تغییر نقش تبدیل شود.
پیش از انتقال: دامنه کار و مرزهای مسئولیت را شفاف کنید
اولین خطا این است که بپرسیم «چه کارهایی دست توست؟» و منتظر جواب حافظه‌ای بمانیم. بهتر است فهرست را از منابع واقعی استخراج کنید: تقویم، سامانه تیکت، صورت‌جلسه‌ها، صندوق ایمیل مشترک، داشبورد پروژه و تعهداتی که در تماس‌های بیرونی داده شده‌اند. پرونده‌های فعال، کارهای تکرارشونده، درخواست‌های معطل و تصمیم‌های باز باید در یک فهرست اولیه کنار هم قرار بگیرند.
برای هر مورد، یک ماتریس ساده بسازید. ستون‌های پیشنهادی این‌ها هستند: نام کار یا پرونده، وضعیت فعلی، اولویت، موعد بعدی، ذی‌نفعان، وابستگی‌ها، ریسک، مالک جدید و زمان اولین اقدام. لازم نیست فرم را زیبا طراحی کنید. یک جدول مشترک با ۱۸ ردیف روشن، از سندی ۴۰ صفحه‌ای که کسی بازش نمی‌کند مفیدتر است. انتقال مالکیت کار با دیدن همه تعهدها شروع می‌شود.
- وضعیت: شروع نشده، در حال انجام، منتظر پاسخ، متوقف یا بسته؛ عبارت «در جریان» وضعیت محسوب نمی‌شود.
- اولویت: اثر تأخیر را بنویسید؛ مثلاً «اگر تا سه‌شنبه ارسال نشود، پرداخت مهر انجام نمی‌شود».
- وابستگی: نام فرد، تیم یا تأییدیه‌ای که کار به آن گره خورده، همراه با راه تماس رسمی.
- ریسک: موضوعی که اگر فرد جدید نداند، احتمال خطا یا تأخیر جدی بالا می‌رود.
همه کارها یک سطح ندارند. ممکن است یک مورد فقط به پیگیری نیاز داشته باشد، مورد دیگر شامل امضای تعهد مالی باشد و سومی هنوز تعریف دقیقی نداشته باشد. در انتقال مالکیت کار باید روشن کنید مالک جدید «اجراکننده»، «هماهنگ‌کننده»، «تصمیم‌گیرنده» یا فقط «پوشش‌دهنده موقت» است. مسئولیتی که مرزش معلوم نیست، معمولاً میان چند نفر می‌افتد و هیچ‌کس آن را نمی‌بندد.
یک نمونه ملموس: مدیر آموزش می‌رود و دوره‌های پاییز را تحویل می‌دهد. برگزاری کلاس‌ها یک کار نیست؛ ثبت‌نام، قرارداد مدرس، تأیید پرداخت، اطلاع‌رسانی به شرکت‌کنندگان و رسیدگی به لغوها هرکدام مالک متفاوتی می‌خواهند. اگر فقط نوشته شود «دوره‌های آموزشی با فلانی»، فرد جدید احتمالاً وسط کار متوجه می‌شود که اجازه تأیید هزینه مدرس را ندارد. همان‌جا صف انتظار شکل می‌گیرد.
پرونده تحویل استاندارد بسازید: حداقل اطلاعاتی که نباید گم شود
برای هر پرونده مهم، یک سند تحویل استاندارد بسازید؛ سندی کوتاه اما زنده، با یک نسخه مرجع مشخص. مرجع می‌تواند فضای اشتراکی سازمان، ابزار مدیریت پروژه یا پوشه‌ای با دسترسی کنترل‌شده باشد. بدترین حالت، داشتن پنج نسخه از یک فایل با نام‌هایی مثل «نهایی۲»، «نهایی جدید» و «نسخه آخر واقعی» است. در انتقال مالکیت کار هر کس باید بداند نسخه معتبر کجاست.
سند را با هدف شروع کنید، نه با انبوه اطلاعات. بنویسید این پرونده قرار است چه مسئله‌ای را حل کند، خروجی قابل قبول چیست و چه چیزی خارج از دامنه آن است. بعد وضعیت امروز را در دو یا سه جمله ثبت کنید. مثلاً: «قرارداد بازاریابی برای امضای مدیرعامل ارسال شده؛ نسخه ۱۲ شهریور مورد تأیید حقوقی است؛ تنها بند باز، سقف هزینه تولید محتواست.» این جمله‌ها فرد جدید را سریع وارد صحنه می‌کنند.
- تاریخچه و تصمیم‌های کلیدی: چه انتخاب‌هایی شده، چه گزینه‌هایی رد شده و دلیل رد چه بوده است.
- گام بعدی و زمان‌بندی: اقدام بعدی، مسئول اقدام، موعد و نتیجه‌ای که باید ثبت شود.
- ذی‌نفعان: نام، نقش، سطح حساسیت و روش ارتباطی ترجیحی هر نفر؛ شماره شخصی را جایگزین کانال رسمی نکنید.
- فایل‌ها و دسترسی‌ها: پیوند محل نگهداری، سطح دسترسی لازم و نام مالک سامانه یا پوشه.
- ریسک‌ها و نقاط کنترل: اتفاق‌های محتمل، علامت هشدار و تاریخی که باید وضعیت دوباره بررسی شود.
زبان سند باید عملیاتی باشد. «پیگیری شود» عبارت تحویل نیست. بنویسید «تا ساعت ۱۴ چهارشنبه، نتیجه بررسی بند ۷ را از واحد حقوقی بگیرید؛ اگر پاسخ نرسید، موضوع را به مدیر حقوقی ارجاع دهید.» این درجه از وضوح، وقت تلف کردن نیست. در یک انتقال خوب، فرد جدید لازم نیست هر جمله را ترجمه کند تا بفهمد چه کاری از او انتظار می‌رود.
گاهی مدیران نگران‌اند سند تحویل تبدیل به بوروکراسی شود. نگرانی بی‌راه نیست، ولی راهش حذف سند نیست؛ سطح‌بندی است. برای درخواست ساده شاید یک کارت پنج‌خطی کافی باشد. پروژه‌ای با بودجه ۸۰۰ میلیون تومان، چند تأمین‌کننده و موعد قانونی، پرونده کامل‌تر می‌خواهد. انتقال مالکیت کار نباید یک فرم ثابت و سنگین برای همه چیز باشد؛ باید متناسب با ریسک کار طراحی شود.
دانش زمینه‌ای را منتقل کنید، نه فقط فهرست کارها را
دانش صریح همان چیزی است که در فایل، قرارداد، صورت‌جلسه یا سامانه ثبت شده. دانش ضمنی، آن بخش سرسخت‌تر است: اینکه چرا مدیر فروش با گزارش هفتگی موافق نیست، چرا بهتر است پیش از تماس با مشتری خاص با حسابداری هماهنگ شوید، یا چرا یک عدد در داشبورد ظاهراً درست است اما نباید مبنای تصمیم قرار بگیرد. شکست بسیاری از موارد انتقال مالکیت کار از همین‌جا می‌آید.
فرد قبلی باید «چرایی» تصمیم‌ها را بگوید، نه فقط تصمیم را. مثلاً به جای «با شرکت الف قرارداد نبستیم»، بنویسد یا توضیح دهد «شرکت الف قیمت پایین‌تری داشت، اما در دو پروژه قبلی تأخیر تحویلش بیشتر از ۲۰ روز بود و واحد عملیات حاضر نشد این ریسک را دوباره بپذیرد.» این توضیح کمک می‌کند فرد جدید با نخستین پیشنهاد ارزان‌تر، ناخواسته همان مسیر قبلی را تکرار نکند.
یک ابزار مفید، روایت زمانی کوتاه است. از نفر قبلی بخواهید پروژه را در پنج تا ده دقیقه تعریف کند: کجا شروع شد، کدام اتفاق مسیر را عوض کرد، چه کسی روی تصمیم‌ها اثر گذاشت و امروز گره اصلی چیست. بعد واژه‌نامه‌ای کوچک بسازید؛ مخفف‌ها، نام‌های داخلی، اصطلاحات قراردادی یا لقب پروژه‌ها برای فرد تازه‌وارد بدیهی نیستند. «طرح آبی» شاید برای تیم قدیمی روشن باشد و برای نفر جدید هیچ معنایی نداشته باشد.
در جلسه تحویل، چند پرسش ثابت کمک زیادی می‌کند: اگر فقط یک چیز را می‌توانستی به من هشدار بدهی، چه بود؟ کدام تصمیم ممکن است دوباره باز شود؟ چه کسی از تغییر مالک ناراحت یا نگران می‌شود؟ کدام گزارش گمراه‌کننده است؟ چه کاری را ظاهرش ساده می‌بینی اما معمولاً دو روز زمان می‌گیرد؟ پاسخ‌ها را در پرونده ثبت کنید، چون انتقال مالکیت کار با حافظه شفاهی دوام نمی‌آورد.
آخر جلسه از نفر جدید بخواهید برداشت خود را بازگو کند؛ نه برای امتحان گرفتن، برای پیدا کردن سوءتفاهم. مثلاً بگوید «من تا دوشنبه باید نسخه اصلاح‌شده را از حقوقی بگیرم، اگر نیامد با مدیر حقوقی تماس می‌گیرم و هم‌زمان مشتری را در جریان می‌گذارم.» اگر نفر قبلی بگوید «نه، قبل از تماس با مشتری باید تأیید مدیر پروژه را داشته باشی»، یک ریسک جدی همان لحظه آشکار شده است. این روش ساده، از حدس‌زدن جلوگیری می‌کند.
جلسه تحویل را به یک گفت‌وگوی تصمیم‌محور تبدیل کنید
جلسه تحویل وقتی مفید است که برای تصمیم و اقدام برگزار شود، نه خواندن بلند یک فایل. برای یک پرونده متوسط، ۴۵ دقیقه کافی است؛ به شرطی که سند پیشاپیش خوانده شده باشد. جلسه را با هدف و وضعیت کلی شروع کنید، بعد سراغ سه مورد با بیشترین ریسک بروید. آخر کار هم اقدام‌های هفته اول، صاحب هر اقدام و زمان پیگیری را مشخص کنید. انتقال مالکیت کار در این جلسه شکل عملی می‌گیرد.
اگر پروژه بزرگ است، یک جلسه سه‌ساعته نگذارید. تجربه تیم‌ها نشان می‌دهد بعد از ۷۰ دقیقه، کیفیت سوال‌ها افت می‌کند و بخش مهمی از جزئیات شنیده نمی‌شود. سه جلسه ۴۰ دقیقه‌ای در چند روز، همراه با مرور پرونده، معمولاً نتیجه بهتری دارد: جلسه اول برای تصویر کلی، جلسه دوم برای پرونده‌های حساس، جلسه سوم برای دسترسی‌ها و سناریوهای احتمالی.
مدیر مستقیم نقش داور بی‌طرف ندارد؛ باید مرز اختیار را روشن کند و جایی که مالک قبلی و جدید برداشت متفاوت دارند، تصمیم بگیرد. برای نمونه، اگر قرار است فرد جدید فقط دو هفته پوشش دهد، مدیر باید مشخص کند آیا او اجازه تغییر زمان‌بندی پروژه را دارد یا فقط پیگیری می‌کند. این موضوع را به توافق شفاهی واگذار نکنید. برای ثبت توافق‌های جلسه هم می‌توان از الگوی مطرح‌شده در تصمیم پساجلسه استفاده کرد.
یک سناریوی عملی اجرا کنید. بگویید «فرض کنیم ساعت ۱۰ فردا مشتری می‌گوید موعد تحویل عقب افتاده؛ چه می‌کنی؟» یا «اگر سامانه دسترسی نداد، مسیر جایگزین چیست؟» نفر جدید مسیر را توضیح می‌دهد و نفر قبلی یا مدیر اصلاح می‌کند. این تمرین سه دقیقه‌ای گاهی بیشتر از بیست دقیقه توضیح کلی، ضعف‌های انتقال مالکیت کار را آشکار می‌کند.
همان روز، خروجی جلسه را ثبت کنید: چه تصمیمی گرفته شد، چه چیزی هنوز باز است، چه کسی باید پیگیری کند و تاریخ بازبینی چیست. اگر تصمیمی نیاز به تأیید دارد، آن را با عبارت مبهم «بعداً هماهنگ می‌کنیم» رها نکنید. نام صاحب تصمیم و ضرب‌الاجل بگذارید. انتقال خوب، جلسه‌ای نیست که همه از آن احساس خوبی داشته باشند؛ جلسه‌ای است که بعدش کسی نداند قدم بعدی چیست.
دسترسی‌ها، اختیارها و کانال‌های ارتباطی را هم‌زمان منتقل کنید
فردی که فایل را می‌بیند ولی امکان ثبت درخواست خرید، تأیید هزینه یا ورود به پنل مشتری را ندارد، عملاً کار را تحویل نگرفته است. فهرست دسترسی‌ها را جداگانه بررسی کنید: ایمیل یا صندوق مشترک، پوشه‌ها، سامانه‌های مالی، ابزار پروژه، گروه‌های پیام‌رسان کاری، داشبوردها و شماره‌های تماس سازمانی. برای هر دسترسی، مالک سامانه و زمان فعال‌شدن را بنویسید. انتقال مالکیت کار بدون این بخش، فقط انتقال دانش است.
دسترسی با اختیار فرق دارد. شاید کارشناس بتواند فاکتور را ببیند، ولی حق تأیید آن را نداشته باشد؛ یا بتواند پیام مشتری را پاسخ دهد اما اجازه تغییر دامنه قرارداد نداشته باشد. در سند تحویل، سطح تصمیم را صریح کنید: چه چیزهایی مستقل انجام می‌شود، کدام موارد تأیید مدیر می‌خواهد، و در نبود مدیر، مسیر ارجاع چیست. این شفافیت از دو خطر جلوگیری می‌کند: توقف بی‌دلیل و تصمیم بی‌اجازه.
ذی‌نفعان بیرونی و داخلی باید خبر رسمی بگیرند. یک پیام کوتاه کافی است: «از امروز پیگیری پرونده X با خانم/آقای … است؛ موضوع‌های جاری در همان کانال مشترک ادامه پیدا می‌کند؛ مسئول قبلی تا تاریخ … فقط برای انتقال اطلاعات در دسترس است.» این اطلاع‌رسانی، تماس‌های پراکنده را کم می‌کند. در پرونده‌های مشترک، تعیین مالک تصمیم هم ضروری است؛ راهنمای مالک تصمیم برای همین نقطه کاربرد دارد.
وابستگی به کانال شخصی، دشمن آرام تداوم کار است. اگر اطلاعات در چت خصوصی، تلفن شخصی یا حساب شخصی یک همکار مانده، انتقالش سخت و گاهی ناممکن می‌شود. اطلاعات لازم را به کانال سازمانی منتقل کنید، دسترسی‌های غیرضروری نفر قبلی را طبق سیاست امنیتی ببندید و مالکیت حساب‌های مشترک را بازبینی کنید. درباره نگهداری دانش سازمانی و تفاوت آن با تجربه فردی، صفحه مدیریت دانش نیز چارچوب مفیدی ارائه می‌دهد.
دوره هم‌پوشانی و پیگیری پس از تحویل را طراحی کنید
امضای فرم یا پایان جلسه، پایان انتقال مالکیت کار نیست. اولین ۴۸ ساعت مهم‌اند، چون فرد جدید تازه با سامانه‌ها، پاسخ ذی‌نفعان و جزئیات واقعی کار مواجه می‌شود. یک تماس ۱۵ دقیقه‌ای در پایان روز دوم بگذارید: چه چیزی مبهم بود؟ کدام دسترسی کار نکرد؟ چه تعهدی در فهرست نبود؟ پاسخ این سوال‌ها باید به پرونده مرجع اضافه شود، نه اینکه فقط در گفت‌وگو بماند.
در هفته اول، مدیر باید روی خروجی‌های حساس نظارت کند، نه اینکه کار را از دست فرد جدید بگیرد. بررسی کنید موعدها رعایت شده‌اند یا نه، ذی‌نفعان مالک جدید را شناخته‌اند یا نه، و ارجاع‌ها درست انجام شده‌اند یا نه. برای پرونده حساس، یک صفحه شاخص کافی است: تعداد درخواست‌های معطل، موعدهای نزدیک، خطاهای دسترسی، موارد ارجاع‌شده و تصمیم‌های باز. این‌ها معیارهای واقعی سلامت انتقال هستند.
بین هفته دوم تا چهارم، مالک قبلی باید از نقش اجرا خارج شود و نقش حمایتی محدود داشته باشد. اگر او همچنان همه ایمیل‌ها را جواب دهد، همکار جدید هیچ‌وقت مالک واقعی نمی‌شود و ذی‌نفعان نیز مسیر قدیمی را ادامه می‌دهند. توافق کنید سوال‌ها در یک بازه مشخص، مثلاً دو نوبت ۳۰ دقیقه‌ای در هفته، مطرح شوند؛ مگر اینکه خطر مالی، حقوقی یا عملیاتی فوری وجود داشته باشد.
یک دام پنهان، کمک‌کردن مخفیانه است. نفر قبلی از سر دلسوزی شب‌ها گزارش را کامل می‌کند یا مستقیم به مشتری جواب می‌دهد. خروجی شاید خوب به نظر برسد، اما وضعیت پرونده برای مدیر و مالک جدید مبهم می‌ماند. هر مداخله باید ثبت شود: چه کاری انجام شد، چرا و از اینجا به بعد مالک آن کیست. انتقال مالکیت کار وقتی موفق است که نفر جدید بتواند کار را بدون تکیه دائمی به فرد قبلی جلو ببرد.
بعد از یک ماه، یک مرور کوتاه انجام دهید و درس‌آموخته‌ها را ثبت کنید. شاید بفهمید فهرست دسترسی‌ها ناقص بوده، بعضی موعدها در تقویم شخصی نفر قبلی ثبت می‌شده یا یک ذی‌نفع مهم اصلاً در ماتریس اولیه نیامده است. این یافته‌ها باید وارد قالب استاندارد شوند. هر انتقال، فرصتی برای بهترکردن انتقال بعدی است؛ وگرنه تیم هر بار همان نقص‌ها را با آدم‌های تازه تکرار می‌کند.
خطاهای رایج در انتقال مالکیت کار و راه پیشگیری از آن‌ها
شروع دیرهنگام، رایج‌ترین خطاست. گاهی فرد دو روز مانده به خروجش می‌گوید «هر چه لازم بود در پوشه گذاشتم.» راه پیشگیری روشن است: به محض قطعی‌شدن جابه‌جایی، فهرست تعهدها را آغاز کنید و برای پرونده‌های پرریسک زمان جدا بگذارید. اگر زمان کم است، همه‌چیز را یکسان تحویل ندهید؛ اولویت با موردی است که تأخیرش پرداخت، مشتری، امنیت یا تعهد قانونی را درگیر می‌کند.
خطای بعدی، هم‌وزن‌دیدن همه کارهاست. پاسخ دادن به یک درخواست داخلی و تمدید قرارداد اجاره دفتر، هر دو در فهرست هستند اما ریسکشان یکی نیست. از ماتریس اولویت استفاده کنید و برای هر مورد سطح انتقال تعیین کنید: اطلاع‌رسانی ساده، تحویل سند، جلسه عمیق یا هم‌پوشانی چند هفته‌ای. این تقسیم‌بندی، انرژی محدود تیم را صرف جایی می‌کند که واقعاً ارزش دارد.
اتکا به حافظه هم خطرناک است. جمله‌هایی مثل «فکر کنم فایلش توی درایو باشد» یا «احتمالاً مدیر قبلی می‌داند» نشانه نقص پروتکل‌اند. محل فایل، مسیر تأیید و ذی‌نفعان باید ثبت شوند. فراموش‌کردن ذی‌نفعان نیز از همین جنس است؛ نفر جدید کار را تحویل می‌گیرد، اما واحد مالی یا مشتری همچنان سراغ مالک قبلی می‌رود. پیام اعلام تغییر را بخشی از کار بدانید، نه کار جانبی.
ابهام در اختیار، خطای پرهزینه دیگری است. فرد جدید یا بیش از حد محتاط می‌شود و هر تصمیم کوچکی را بالا می‌فرستد، یا برای جلوگیری از توقف، تصمیمی خارج از حدود خود می‌گیرد. راه‌حل، نوشتن آستانه‌هاست: تا چه مبلغی، با چه سطحی از تغییر، و در چه موقعیت‌هایی اختیار مستقیم دارد. انتقال مالکیت کار وقتی قابل اتکا می‌شود که این مرزها قابل مشاهده باشند.
آخرین خطا، فرض فهم کامل است. نفر قبلی توضیح داده و خیال می‌کند موضوع تمام شده؛ نفر جدید هم برای اینکه ناتوان به نظر نرسد، سوال نمی‌پرسد. بازگویی برداشت، سناریوی عملی و پیگیری ۴۸ ساعته این شکاف را کم می‌کنند. چک‌لیست زیر را می‌توان برای هر پرونده مهم چاپ یا در ابزار کار تیم نگه داشت:
- فهرست کامل پرونده‌ها، وظایف تکراری و تعهدهای باز را تهیه کنید.
- ریسک، موعد، وابستگی و اولویت هر مورد را مشخص کنید.
- مالک جدید و سطح مسئولیت او را برای هر مورد بنویسید.
- سند مرجع تحویل را در یک محل مشترک و مشخص قرار دهید.
- چرایی تصمیم‌ها، تاریخچه و اصطلاحات داخلی را منتقل کنید.
- جلسه تصمیم‌محور برگزار کنید و اقدام‌های هفته اول را ثبت کنید.
- دسترسی‌ها، اختیارها و اطلاع‌رسانی به ذی‌نفعان را کامل کنید.
- در ۴۸ ساعت، هفته اول و پایان ماه پیگیری و اصلاح انجام دهید.
جمع‌بندی
انتقال مالکیت کار یک تشریفات اداری برای روزهای خروج همکاران نیست. سازوکاری است برای اینکه عملیات تیم با تغییر آدم‌ها قطع نشود و اعتماد ذی‌نفعان آسیب نبیند. پرونده‌ای که فقط فایلش تحویل شده، هنوز ممکن است بدون صاحب باشد؛ چون اختیار، مسیر ارجاع، منطق تصمیم و رابطه‌های کاری آن همراه فایل جابه‌جا نشده‌اند.
اگر قرار است از فردا این پروتکل را شروع کنید، با یک کار مهم آغاز کنید: یک ماتریس شفاف بسازید، نسخه مرجع پرونده را تعیین کنید، جلسه کوتاه اما تصمیم‌محور بگذارید و پیگیری ۴۸ ساعته را از قبل در تقویم قرار دهید. سپس قالب را با تجربه واقعی تیم اصلاح کنید. هدف، کامل‌کردن کاغذبازی نیست؛ هدف این است که هیچ کار مهمی بین «دیگر مسئول من نیست» و «فکر کردم دست اوست» معلق نماند.
در مطالب بعدی این مجله، سراغ جزئیات اجرایی‌تری از تداوم کار تیمی، مخصوصاً در جابه‌جایی نقش‌ها و پروژه‌های بین‌واحدی، خواهیم رفت. تجربه‌های واقعی تیم‌ها در این موضوع معمولاً از هر قالب آماده‌ای آموزنده‌ترند.
