کنترل نسخه اسناد؛ مدیریت پیش‌نویس، تأیید، تاریخچه و بازگشت نسخه

فایل‌هایی با نام‌های «نهایی»، «نهایی۲» و «نهایی-واقعی» فقط ظاهر یک مشکل‌اند. مشکل اصلی این است که تیم نمی‌داند کدام نسخه مرجع است، چه کسی تغییر را تأیید کرده، چرا تغییر کرده و اگر اشتباه بود چگونه به وضعیت سالم برگردد.

کنترل نسخه سند باید چرخه پیش‌نویس، بازبینی، تأیید، انتشار و جایگزینی را مدیریت کند. تاریخچه خودکار ابزار مفید است، اما بدون نقش و قاعده، صرفاً مجموعه‌ای از Snapshotهای بی‌معنا می‌سازد.

کنترل نسخه اسناد از کدام شناسه‌ها تشکیل می‌شود؟

تاریخ به‌تنهایی نسخه نیست. دو نفر می‌توانند در یک روز دو تغییر متفاوت بسازند. همچنین نام فایل جای Metadata را نمی‌گیرد؛ قرارداد نام‌گذاری فقط به شناسایی کمک می‌کند و در این فرایند مرجع اصلی باید رکورد نسخه باشد.

وضعیت‌های پیشنهادی یک سند کنترل‌شده

چرخه سبک برای بیشتر تیم‌ها:

1. Draft: نویسنده آزادانه تغییر می‌دهد؛ برای اجرا مرجع نیست.
2. In review: محدوده بازبینی ثابت شده و نظرها جمع می‌شوند.
3. Changes requested: ایرادهای مشخص برای اصلاح برگشته‌اند.
4. Approved: شخص مجاز نسخه را تأیید کرده است.
5. Published/Effective: نسخه از تاریخ معین مرجع اجراست.
6. Obsolete/Superseded: دیگر معتبر نیست، اما برای تاریخچه نگه داشته می‌شود.

برای سند کم‌ریسک می‌توان Approved و Published را یکی کرد. برای سیاست امنیتی یا قرارداد، جدایی تاریخ تأیید و تاریخ اجرا مهم است.

نقش‌ها و تفکیک وظیفه

• Owner: پاسخ‌گوی چرخه عمر و زمان بازبینی؛
• Author/Editor: متن را تغییر می‌دهد؛
• Reviewer: صحت تخصصی، اجرایی یا حقوقی را می‌سنجد؛
• Approver: اختیار اعلام نسخه مرجع را دارد؛
• Publisher/Custodian: دسترسی، آرشیو و توزیع نسخه معتبر را اجرا می‌کند.

در تیم کوچک یک نفر ممکن است چند نقش داشته باشد، اما برای سند پرریسک نویسنده نباید تنها تأییدکننده باشد. این تفکیک را در خود Workflow بنویسید، نه در حافظه تیم.

Workflow گام‌به‌گام با کنترل تعارض

۱. نسخه مرجع را مشخص کنید

یک محل یا URL باید تنها منبع نسخه مؤثر باشد. کپی‌های دانلودشده با برچسب «کپی کنترل‌نشده» یا تاریخ دریافت شناخته شوند. پیش از ویرایش، نویسنده از نسخه مرجع Branch یا کپی کاری می‌سازد.

۲. درخواست تغییر بسازید

هر تغییر یک رکورد کوتاه دارد:

شناسه تغییر: CR-2026-041
سند: SOP-SUP-004 v2.0
علت: اضافه‌شدن کانال پیامک
دامنه: بخش‌های ۳ و ۵
ریسک: ارسال ناخواسته برای کاربر
درخواست‌کننده: مالک محصول

۳. هم‌زمانی را کنترل کنید

برای سند متنی ساده، قفل ویرایش یا یک Editor واحد در هر بازه کافی است. در همکاری هم‌زمان، Comment و Suggestion را از تغییر پذیرفته‌شده جدا کنید. اگر دو Branch ایجاد شد، ادغام باید توسط صاحب محتوا انجام و تعارض معنایی، نه فقط تعارض خط، حل شود.

۴. بازبینی را براساس معیار انجام دهید

Reviewer باید بداند دنبال چیست: صحت، انطباق، قابلیت اجرا، حریم خصوصی یا زبان. Comment مبهم «بهتر شود» قابل پایان نیست. هر ایراد باید مکان، مشکل و شرط پذیرش داشته باشد.

۵. تأیید و شماره نسخه

قاعده ساده نسخه‌گذاری:

• تغییر بزرگ در معنا، نقش یا کنترل: 2.0 ← 3.0؛
• اصلاح کوچک بدون تغییر رفتار اصلی: 2.0 ← 2.1؛
• غلط تایپی بی‌اثر: می‌تواند 2.0.1 باشد، اگر سیاست تیم این سطح را نیاز دارد.

این الگو شبیه Semantic Versioning است، اما برای سند استاندارد جهانی اجباری نیست. تعریف خودتان را مکتوب و ثابت نگه دارید.

۶. انتشار اتمیک

نسخه تازه و قدیمی را هم‌زمان مرجع نکنید. نسخه جدید را منتشر، لینک مرجع را جابه‌جا و نسخه قبلی را Obsolete کنید. مخاطبان متأثر باید بدانند چه چیزی، از چه زمانی و با چه اقدامی تغییر کرده است.

۷. آزمون بازگشت

پیش از بحران بررسی کنید که فایل نسخه قبلی، Metadata، پیوست‌ها و دسترسی آن واقعاً قابل بازیابی است. Rollback یعنی بازگرداندن یک نسخه با رکورد تصمیم تازه؛ تاریخچه را پاک نکنید.

جدول ثبت نسخه قابل کپی

برای فرایند پرتکرار، خود Workflow را نیز با قالب SOP مستند کنید. تسک بازبینی دوره‌ای می‌تواند در پروژه‌های نوتوا مسئول و موعد داشته باشد؛ فایل حساس را فقط در مخزن دارای کنترل دسترسی مناسب نگه دارید.

سناریوی تعارض؛ دو نفر یک سیاست را تغییر داده‌اند

نسخه ۲.۰ سیاست اعلان مرجع است. نویسنده A بند سهمیه پیامک و نویسنده B بند رضایت کاربر را جدا تغییر داده‌اند. روش غلط این است که فایل جدیدتر را «نهایی» اعلام کنیم. روش کنترل‌شده:

1. هر دو Change Request و Baseline مشترک ثبت می‌شوند؛
2. Owner تعارض معنایی را بررسی می‌کند: سهمیه نباید رضایت را دور بزند؛
3. تغییرها در Draft واحد ۲.۱ ادغام می‌شوند؛
4. بازبین فنی و حریم خصوصی هر دو معیار خود را می‌سنجند؛
5. تأییدکننده نسخه ۲.۱ را معتبر می‌کند؛
6. ۲.۰ Obsolete می‌شود، اما حذف نمی‌شود؛
7. مخاطبان تفاوت و تاریخ اجرا را می‌بینند.

چه چیزی را در Audit نگه داریم؟

حداقل این رویدادها قابل ردگیری باشند:

• ایجاد و دانلود نسخه؛
• ویرایش و ادغام؛
• تغییر وضعیت؛
• تأیید یا رد؛
• تغییر دسترسی؛
• حذف و بازیابی؛
• جابه‌جایی نسخه مرجع.

Log بدون ساعت معتبر، شناسه کاربر و شناسه سند برای بررسی حادثه کافی نیست. شماره موبایل، رمز یا داده حساس را در Log خام ننویسید.

خطاهای رایج

• استفاده از پوشه مشترک بدون نسخه مرجع؛
• بازنویسی فایل Approved به‌جای ساخت Draft؛
• تأیید شفاهی بدون رکورد؛
• نام نسخه بدون تعریف تغییر Major/Minor؛
• دادن مجوز Edit به همه؛
• نگه‌داشتن نسخه قدیمی در همان مسیر عمومی بدون برچسب منسوخ؛
• اعتماد به Backup به‌جای آزمون Restore؛
• حذف تاریخچه برای «تمیزشدن» فضای کاری.

چک‌لیست کنترل نسخه

• سند شناسه یکتا و Owner دارد.
• نسخه مؤثر از Draft قابل تشخیص است.
• وضعیت‌ها و اختیار تغییرشان تعریف شده‌اند.
• هر تغییر دلیل و دامنه دارد.
• بازبینی با معیار مشخص انجام می‌شود.
• نسخه قبلی منسوخ ولی قابل بازیابی است.
• تعارض هم‌زمانی مسیر حل دارد.
• Rollback دست‌کم یک بار آزموده شده است.
• تاریخ بازبینی بعدی و ماشه تغییر ثبت شده‌اند.

جمع‌بندی

کنترل نسخه سند یعنی حفظ یک زنجیره قابل اثبات از درخواست تغییر تا نسخه مؤثر. نام «final» هیچ‌کدام از این کنترل‌ها را نمی‌سازد. یک Baseline، وضعیت‌های روشن، نقش تأیید، Change log و آزمون بازگشت تعریف کنید؛ سپس ابزار را برای اجرای همین قواعد انتخاب کنید، نه اینکه قواعد را به رفتار پیش‌فرض ابزار بسپارید.