مهاجرت از یک ابزار خارجی زمانی پرریسک می‌شود که تیم آن را به «کپی چند کارت» تقلیل دهد. داده پروژه فقط عنوان وظیفه‌ها نیست؛ نظرها، پیوست‌ها، مسئولان، تاریخ‌ها، چک‌لیست‌ها، تصمیم‌ها، اتصال‌ها و سابقه‌ای که معنای کار را می‌سازد نیز باید تعیین تکلیف شود. اگر مقصد زودتر از معیار پذیرش به منبع اصلی تبدیل شود، نقص انتقال تازه وسط کار روزانه آشکار می‌شود.
مهاجرت امن یعنی پیش از جابه‌جایی، دامنه داده و مسئول تصمیم روشن باشد؛ یک پروژه نماینده آزمایش شود؛ نتیجه با شمارش و نمونه‌برداری تأیید شود؛ و تا عبور از معیارها، مسیر بازگشت باقی بماند. این راهنما برای کوچ از ابزارهای مدیریت پروژه، وظیفه و دانش تیمی به یک ابزار ایرانی نوشته شده و بر انتقال کنترل‌شده تمرکز دارد، نه وعده انتقال بی‌نقص با یک کلیک.
چه زمانی مهاجرت واقعاً لازم است؟
قطع یا دشوار شدن دسترسی تنها محرک مهاجرت نیست. پرداخت نامتناسب، نیاز به تقویم شمسی، پشتیبانی فارسی، محل میزبانی داده، نبود نقش مناسب یا پراکندگی کار میان چند ابزار نیز می‌تواند تصمیم را توجیه کند. بااین‌حال، ناراحتی مقطعی دلیل کافی برای کوچ فوری نیست. ابتدا مسئله را به معیار قابل آزمون تبدیل کنید.
- کدام نقش‌ها در ورود یا استفاده روزمره اصطکاک دارند؟
- کدام قابلیت یا سیاست، کار حیاتی را متوقف می‌کند؟
- هزینه باقی ماندن شامل چه زمان، ریسک و ابزار جانبی است؟
- مقصد باید از کدام معیارهای غیرقابل‌مذاکره عبور کند؟
- اگر مهاجرت شکست خورد، تیم تا چه زمانی می‌تواند برگردد؟
این پرسش‌ها تصمیم را از ظاهر ابزار جدا می‌کنند. برای ساخت فهرست کوتاه مقصد نیز می‌توانید از مقایسه ابزارهای مدیریت پروژه ایرانی استفاده کنید و هر گزینه را با داده کم‌خطر در یک پایلوت واقعی بسنجید.
اول منبع حقیقت را مشخص کنید
پیش از انتقال، یک نفر باید مالک مهاجرت و یک نفر مالک پذیرش کسب‌وکاری باشد. مالک مهاجرت برنامه، دسترسی و اجرای فنی را هماهنگ می‌کند؛ مالک پذیرش تأیید می‌کند که کارهای ضروری، تاریخ‌ها، مسئولیت‌ها و زمینه تصمیم قابل استفاده‌اند. ممکن است این دو نقش در تیم کوچک یک نفر باشند، اما دو نوع مسئولیت باید صریح بماند.
تاریخ و ساعت «توقف تغییر» را نیز تعیین کنید. تا پیش از آن، ابزار قدیم منبع حقیقت است. در پنجره انتقال، ویرایش محدود یا متوقف می‌شود. پس از تأیید، ابزار جدید مرجع می‌شود و نسخه قدیم فقط خواندنی می‌ماند. فعال ماندن طولانی هر دو ابزار باعث اختلاف داده و سردرگمی تیم می‌شود.
گام اول: موجودی کامل داده و اتصال‌ها
فهرست مهاجرت را در چند لایه بسازید. پروژه‌های فعال و آرشیوی را جدا کنید؛ کاربران، مهمان‌ها و حساب‌های غیرفعال را بشمارید؛ سپس نوع داده و اتصال‌های بیرونی را ثبت کنید.
| لایه | نمونه موارد | تصمیم لازم |
|---|---|---|
| ساختار | فضای کاری، تیم، پروژه، برد، ستون و وضعیت | انتقال، ادغام یا آرشیو |
| کار | وظیفه، زیرکار، چک‌لیست، اولویت و برچسب | نگاشت فیلد و وضعیت |
| زمینه | نظر، پیوست، سند، لینک و تاریخچه | انتقال، بایگانی یا ارجاع |
| هویت | مالک، عضو، مهمان، گروه و نقش | تطبیق حساب و کمترین دسترسی |
| زمان | موعد، منطقه زمانی، تکرار و وابستگی | تبدیل و آزمون مرزی |
| اتصال | اعلان، فرم، ایمیل، API و خودکارسازی | بازسازی یا بازنشستگی |
در همین مرحله داده اضافی را پاک‌سازی نکنید مگر با سیاست و تأیید روشن. ابتدا موجودی خام را نگه دارید؛ سپس نسخه مهاجرت را از پروژه تکراری، حساب غیرفعال و فایل منقضی جدا کنید. حذف عجولانه می‌تواند سابقه لازم برای قرارداد، پشتیبانی یا تصمیم بعدی را از بین ببرد.
گام دوم: خروجی را مثل پشتیبان فرض نکنید
خروجی CSV یا JSON ممکن است فقط بخشی از داده را داشته باشد. یک فایل شامل عنوان و مسئول، لزوماً نظرها، نسخه پیوست، تاریخچه تغییر، شناسه قدیمی یا رابطه زیرکار را حفظ نمی‌کند. از ابزار مبدأ چند نوع خروجی موجود را بگیرید و ساختار هر فایل را مستند کنید.
نسخه خام خروجی را بدون تغییر و با تاریخ نگه دارید. برای کنترل تمامیت می‌توانید اندازه فایل و هش آن را ثبت کنید. دسترسی به آرشیو را محدود کنید، چون ممکن است اطلاعات مشتری، توکن اتصال یا داده شخصی داشته باشد. فایل خام را در پیام‌رسان یا پوشه عمومی تیم پخش نکنید و زمان حذف آن را از قبل تعیین کنید.
گام سوم: نگاشت مبدأ و مقصد
پیش از Import، یک جدول نگاشت بسازید. هر وضعیت قدیمی به کدام وضعیت جدید می‌رود؟ کاربر غیرفعال چگونه نمایش داده می‌شود؟ تاریخ بدون منطقه زمانی چگونه تفسیر می‌شود؟ چک‌لیست به زیرکار تبدیل می‌شود یا در توضیح می‌ماند؟ برای فیلدی که مقصد معادل مستقیم ندارد، یکی از چهار تصمیم را ثبت کنید: تبدیل، نگهداری در متن، بایگانی جدا یا حذف تأییدشده.
شناسه قدیمی را در یک فیلد یا جدول تطبیق نگه دارید تا بررسی و پاسخ به اختلاف آسان باشد. نگاشت را نسخه‌دار کنید؛ تغییر قانون میان دو اجرای مهاجرت بدون ثبت نسخه، نتیجه‌ها را غیرقابل‌تکرار می‌کند.
گام چهارم: مقصد را پیش از داده واقعی آماده کنید
ساختار مقصد باید از نیاز کار بیاید، نه تقلید کامل از ابزار قبلی. وضعیت‌ها، نقش‌ها، تقویم، قرارداد نام‌گذاری و محل اسناد را با یک پروژه خالی آزمایش کنید. اگر قرار است هم‌زمان با مهاجرت، گردش کار نیز بازطراحی شود، دامنه تغییر را محدود نگه دارید؛ جابه‌جایی داده و تغییر فرایند در یک روز، تشخیص علت خطا را دشوار می‌کند.
در تسکی می‌توانید برد کانبان را کنار فهرست، تقویم شمسی، سند، فرم و داشبورد نگه دارید. اگر تیم از Trello کوچ می‌کند، صفحه مقایسه تسکی و Trello نشان می‌دهد چگونه ستون‌ها، کارت‌ها و چک‌لیست‌ها را به ساختار مقصد نزدیک کنید. امکانات و شرایط روز را پیش از تصمیم نهایی در حساب آزمایشی بررسی کنید.
گام پنجم: یک پروژه نماینده را پایلوت کنید
پروژه آزمایشی باید به‌اندازه کافی واقعی باشد: چند وضعیت، کار باز و بسته، زیرکار، نظر فارسی، پیوست، تاریخ، مهمان و حداقل یک اتصال داشته باشد. ساده‌ترین برد ممکن، نقص‌های مهم را آشکار نمی‌کند. در عین حال، ابتدا داده حساس منابع انسانی یا مشتری راهبردی را منتقل نکنید.
پایلوت را از ابتدا تا انتها اجرا کنید: خروج، تبدیل، ورود، تطبیق، استفاده روزمره و خروج دوباره از مقصد. مرحله آخر مهم است؛ ابزار مقصد فقط باید داده را بپذیرد، بلکه تیم باید مسیر خروج آینده را نیز بشناسد. زمان اجرا، دخالت دستی و خطاها را ثبت کنید تا برنامه مهاجرت کامل واقع‌بینانه باشد.
گام ششم: معیار پذیرش عددی و نمونه‌ای بسازید
«چند کارت را دیدیم و درست بود» معیار پذیرش نیست. کنترل را در دو سطح انجام دهید:
- شمارش کلی: تعداد پروژه، کار، کار باز، کار بسته، کاربر، نظر و پیوست؛
- تطبیق نمونه: نمونه‌ای از کارهای قدیمی و جدید، فارسی و انگلیسی، دارای پیوست، دارای زیرکار و دارای مهمان؛
- کنترل رابطه: مالک، وضعیت، تاریخ، وابستگی و پیوند کار به پروژه؛
- کنترل دسترسی: مشاهده و ویرایش هر نقش با حساب آزمایشی؛
- کنترل کاربرد: جست‌وجو، فیلتر، اعلان و گزارش روی داده واردشده؛
- کنترل خروج: امکان دریافت نسخه مستقل از مقصد.
آستانه پذیرش را پیش از اجرای کامل تعیین کنید. برای نمونه، نبود حتی یک پروژه فعال یا دسترسی اشتباه مهمان می‌تواند مانع انتقال باشد، درحالی‌که از دست رفتن رنگ یک برچسب کم‌اهمیت شاید با ثبت استثنا پذیرفته شود. شدت خطا را با اثر کسب‌وکاری بسنجید.
گام هفتم: امنیت و دسترسی را دوباره طراحی کنید
نقش‌های مبدأ را کورکورانه کپی نکنید. عضویت‌ها را با مدیر هر تیم تأیید و حساب‌های مشترک را حذف کنید. مدیر، عضو، مهمان و پشتیبان باید فقط دسترسی مورد نیاز داشته باشند. احراز هویت چندمرحله‌ای، سیاست نشست، بازیابی حساب، ثبت رویداد و دسترسی پشتیبانی را متناسب با حساسیت داده بررسی کنید.
اگر فروشنده یا پیمانکار در مهاجرت کمک می‌کند، دامنه و مدت دسترسی او را مکتوب کنید. از داده کم‌خطر برای آزمون استفاده کنید و پس از پایان، حساب، توکن، فایل موقت و مجوز اضافی را لغو کنید. انتقال روی ارتباط رمزگذاری‌شده لازم است، اما به‌تنهایی امنیت کل فرایند را تضمین نمی‌کند.
گام هشتم: Cutover و Rollback را تمرین کنید
برای روز انتقال یک Runbook کوتاه داشته باشید: چه کسی تغییر را متوقف می‌کند، آخرین خروجی را می‌گیرد، Import را اجرا می‌کند، شمارش را تأیید می‌کند، کاربران را دعوت می‌کند و نتیجه را اعلام می‌کند؟ مسیر تماس و مهلت تصمیم نیز باید روشن باشد.
ماشه بازگشت را از قبل تعریف کنید؛ مثلاً نقص پروژه فعال، مالکیت اشتباه تعداد قابل‌توجهی کار یا خطای دسترسی پرخطر. Rollback فقط نگه داشتن فایل نیست. باید معلوم باشد چگونه ابزار قدیم دوباره مرجع می‌شود، تغییرهای پنجره انتقال کجا ثبت می‌شوند و چه کسی تصمیم بازگشت را اعلام می‌کند.
پس از انتقال چه کارهایی باقی می‌ماند؟
- یک دوره کوتاه پشتیبانی با مالک پاسخ و زمان رسیدگی تعیین کنید.
- اختلاف‌ها را در یک صف مشترک ثبت و بر اساس شدت اولویت‌بندی کنید.
- اتصال‌ها و اعلان‌ها را با رویداد واقعی آزمایش کنید.
- کاربران غیرفعال، توکن‌ها و دسترسی پیمانکار را لغو کنید.
- نسخه قدیم را تا پایان معیار نگهداری، فقط خواندنی نگه دارید.
- سپس لغو سرویس، نگهداری یا حذف داده را طبق قرارداد و سیاست داخلی پیگیری کنید.
- Runbook و نگاشت نهایی را در پایگاه دانش تیم نگه دارید.
اشتباهات رایج در مهاجرت
- انتخاب مقصد فقط با مشاهده دمو و بدون اجرای جریان واقعی؛
- فرض اینکه Export همان پشتیبان کامل و قابل بازیابی است؛
- انتقال همه آرشیو بدون طبقه‌بندی و سیاست نگهداری؛
- تغییر هم‌زمان ابزار، ساختار تیم و کل گردش کار؛
- دعوت کاربران پیش از آزمون نقش و دسترسی؛
- نداشتن پنجره توقف تغییر و منبع حقیقت روشن؛
- حذف زودهنگام نسخه قدیم یا نگه داشتن بی‌پایان آن؛
- سنجش موفقیت با ورود داده، نه قابلیت انجام کار روزمره.
مهاجرت را با یک فضای کاری آزمایشی شروع کنید
در تسکی می‌توانید یک پروژه نماینده بسازید، ساختار برد و نقش‌ها را پیش از Cutover امتحان کنید و کار، سند، فرم و گزارش تیم را در یک محیط فارسی و شمسی کنار هم قرار دهید.
جمع‌بندی
مهاجرت امن پروژه با انتخاب مقصد پایان نمی‌یابد. موجودی داده، خروجی خام، نگاشت نسخه‌دار، پروژه پایلوت، کنترل عددی و نمونه‌ای، بازطراحی دسترسی و مسیر بازگشت اجزای یک کوچ قابل دفاع‌اند. انتقال را کوچک و قابل مشاهده آغاز کنید، معیار پذیرش را پیش از اجرا بنویسید و فقط پس از تأیید کسب‌وکار، ابزار جدید را منبع حقیقت اعلام کنید.
سؤالات متداول
آیا فایل CSV برای مهاجرت کامل کافی است؟
معمولاً نباید چنین فرضی کرد. ممکن است نظر، پیوست، تاریخچه، رابطه زیرکار یا اطلاعات دسترسی در CSV نباشد. محتوای خروجی را با موجودی و نمونه واقعی تطبیق دهید.
ابزار قدیمی را چه زمانی حذف کنیم؟
پس از عبور از معیار پذیرش، پایان دوره نگهداری لازم و اطمینان از نسخه مستقل. تا آن زمان بهتر است نسخه قدیم فقط خواندنی و دسترسی آن محدود باشد.
پایلوت مهاجرت باید شامل چه داده‌ای باشد؟
یک پروژه نماینده با وضعیت‌های متنوع، کار باز و بسته، نظر فارسی، پیوست، تاریخ، زیرکار، مهمان و اتصال؛ اما بدون داده حساس غیرضروری.
چطور از گم شدن کارهای جدید هنگام انتقال جلوگیری کنیم؟
یک پنجره توقف تغییر، آخرین خروجی زمان‌دار، ثبت تغییرهای اضطراری و اعلام روشن منبع حقیقت تعیین کنید.
Rollback در مهاجرت یعنی چه؟
برنامه‌ای عملی برای بازگرداندن منبع حقیقت به ابزار قبلی در صورت عبور نکردن از معیارها؛ شامل مسئول تصمیم، ماشه بازگشت، داده‌های پنجره انتقال و نحوه اطلاع‌رسانی.
