لغو درخواست با پاک‌کردن اثر آن فرق دارد
طراحی لغو و برگشت عملیات در نرم‌افزار سازمانی یعنی تعیین کنیم کاربر در هر مرحله چه چیزی را می‌تواند متوقف یا اصلاح کند، چه اثری قبلاً ایجاد شده و چه مدرکی برای پایان اصلاح لازم است. یک دکمه «لغو» برای درخواست اجرا‌نشده، رزرو انجام‌شده و کاری که به سامانه دیگری ارسال شده، معنای یکسانی ندارد. ابتدا وضعیت واقعی را مشخص کنید؛ سپس عمل مجاز را به کاربر نشان دهید.
برای سفارش‌دهنده نرم‌افزار، این موضوع بخشی از نیازمندی اصلی است، نه قابلیتی که بعد از اولین اشتباه اضافه شود. هدف این راهنما تعریف رفتار قابل فهم، حفظ سابقه و کاهش اصلاح‌های دستی خارج از سامانه است. مثال‌ها درباره طراحی محصول‌اند و جایگزین قواعد مالی، قراردادی یا عملیاتی سازمان شما نیستند. هیچ وعده‌ای هم وجود ندارد که بتوان اثر تمام اقدام‌ها را کاملاً به وضعیت گذشته برگرداند.
چهار مفهوم را در جلسه نیازسنجی جدا کنید
«انصراف» معمولاً یعنی کار هنوز اجرا نشده و نباید ادامه پیدا کند. «توقف» می‌تواند موقتی باشد و امکان ادامه داشته باشد. «اصلاح» یعنی اطلاعات یا نتیجه با روش مجاز تغییر کند. «برگشت اثر» یعنی برای اقدام انجام‌شده، عملیات مرتبط دیگری اجرا شود تا وضعیت کسب‌وکار به حالت معتبر برسد. نام دقیق این عمل‌ها باید با واژگان کارکنان هماهنگ باشد، اما تفاوتشان نباید پنهان شود.
برای هر قابلیت، یک مثال واقعی از سازمان بخواهید. اگر مسئول انبار می‌گوید «این درخواست را برگردان»، ممکن است منظورش آزادکردن رزرو باشد، نه ثبت دریافت فیزیکی کالا. اگر مدیر می‌گوید «تأیید را حذف کن»، باید روشن شود آیا کار وابسته‌ای شروع شده است یا نه. همین پرسش‌های ساده از ساخت دکمه‌ای جلوگیری می‌کند که چند انتظار ناسازگار پشت آن قرار گرفته است.
ماتریس وضعیت و اقدام را پیش از طراحی فرم بنویسید
از وضعیت‌هایی مانند پیش‌نویس، ارسال‌شده، تأییدشده، درحال‌اجرا و تکمیل‌شده شروع کنید. روبه‌روی هر وضعیت مشخص کنید کدام اقدام مجاز است، چه کسی اجازه آن را دارد و نتیجه چه وضعیتی خواهد بود. لازم نیست همه سامانه‌ها همین نام‌ها را داشته باشند؛ مهم این است که کاربر و تیم فنی از هر وضعیت برداشت مشترکی داشته باشند و انتقال مبهم باقی نماند.
مثلاً حذف یک پیش‌نویس بدون اثر جانبی می‌تواند ساده باشد، اما لغو یک درخواست تأییدشده ممکن است نیازمند دلیل و اطلاع به مسئول اجرا باشد. برای کار تکمیل‌شده شاید اصلاً گزینه لغو وجود نداشته باشد و فقط درخواست اصلاح ثبت شود. این ماتریس باید مبنای کنترل سمت سرور نیز باشد؛ پنهان‌کردن دکمه در صفحه به‌تنهایی مانع اجرای اقدام نامعتبر از مسیرهای دیگر نیست.
قبل از برگشت، اثرهای ایجادشده را فهرست کنید
یک عملیات ظاهراً ساده ممکن است رزرو منابع ایجاد کند، پیام بفرستد و در سامانه مقصد رکورد بسازد. برای هر اثر بنویسید آیا هنوز انجام نشده، قابل اصلاح است یا به رسیدگی جداگانه نیاز دارد. کاربری که درخواست لغو می‌دهد باید بداند چه چیزی متوقف می‌شود و چه چیزی همچنان باقی خواهد ماند. پیام ارسال‌شده را نمی‌توان از حافظه دریافت‌کننده حذف کرد.
در فرایند چندسامانه‌ای، الگوی عملیات جبرانی مایکروسافت توضیح می‌دهد که اصلاح اثرها لزوماً به معنی بازگرداندن دقیق تمام داده‌ها به گذشته نیست. در طراحی خود نیز از وعده عمومی «بازگشت کامل» پرهیز کنید. برای هر اثر، نتیجه معتبر مورد انتظار و شاهد تأیید آن را جدا بنویسید؛ تصمیم کسب‌وکاری نباید از روی نام یک الگوی فنی گرفته شود.
مثال فرضی: لغو درخواست تجهیزات پس از رزرو
فرض کنید کارمند برای یک جلسه، نمایشگر و کابل درخواست کرده است. درخواست تأیید شده، نمایشگر رزرو شده و پیام آماده‌سازی برای مسئول تجهیزات ارسال شده است؛ اما هنوز تحویلی انجام نشده. اکنون جلسه لغو می‌شود. تغییر وضعیت درخواست به «لغوشده» فقط یک بخش کار است. رزرو باید آزاد شود و مسئول آماده‌سازی باید از تغییر مطلع شود تا کار غیرضروری ادامه پیدا نکند.
در همین مثال آموزشی، اگر نمایشگر قبلاً تحویل شده باشد، مسیر دیگری لازم است: ثبت درخواست بازگشت، دریافت واقعی دستگاه و تأیید مسئول. نرم‌افزار نباید صرف کلیک کارمند، موجودی قابل استفاده را افزایش دهد. بنابراین یک دکمه مشابه در دو زمان متفاوت نمی‌تواند نتیجه یکسان داشته باشد. معیار تصمیم، آخرین وضعیت معتبر عملیات است، نه وضعیت صفحه‌ای که کاربر چند دقیقه قبل باز کرده است.
درخواست برگشت را به عملیات اصلی متصل نگه دارید
برگشت باید شناسه مستقل و ارتباط روشن با عملیات اصلی داشته باشد. ثبت کنید چه کسی درخواست داده، چرا، در چه زمانی و در چه محدوده‌ای. اگر فقط بخشی از کار اصلاح می‌شود، همان بخش را مشخص کنید. برای مثال بازگرداندن یک قلم از چند قلم نباید کل درخواست را بسته نشان دهد یا سابقه اقلام باقی‌مانده را از دسترس خارج کند.
در صفحه اصلی، خلاصه وضعیت برگشت و پیوند مشاهده جزئیات را نمایش دهید. در صفحه برگشت هم راه بازگشت به عملیات اولیه وجود داشته باشد. این ارتباط به پشتیبانی کمک می‌کند زنجیره تصمیم‌ها را دنبال کند. راهنمای ثبت تاریخچه تغییرات نرم‌افزار مکمل این بخش است؛ تاریخچه نشان می‌دهد چه اتفاقی افتاده، ولی به‌تنهایی جایگزین گردش مجاز اصلاح و تأیید نتیجه نمی‌شود.
مجوز درخواست، تأیید و اجرا را مستقل بررسی کنید
ممکن است همه کاربران بتوانند اشتباه را گزارش کنند، اما فقط مسئول مشخصی اجازه تأیید برگشت داشته باشد. در بعضی عملیات، اجرای نهایی نیز در اختیار واحد دیگری است. این تفکیک را متناسب با حساسیت کار طراحی کنید؛ ایجاد چند مرحله تأیید برای هر اصلاح کوچک می‌تواند کارکنان را به روش‌های خارج از سامانه سوق دهد و نتیجه معکوس داشته باشد.
در طراحی نقش‌ها و سطوح دسترسی، دامنه مجوز اهمیت دارد. شخصی که برای یک شعبه مجاز است نباید با تغییر شناسه درخواست، برگشت شعبه دیگر را انجام دهد. همچنین اختیار امروز او را هنگام اجرا بررسی کنید. اینکه فرد هنگام ایجاد درخواست نقش مناسبی داشته، دلیل کافی برای مجازبودن اجرای نهایی پس از تغییر مسئولیت یا خروج از سازمان نیست.
تغییر هم‌زمان را به تصمیم اشتباه تبدیل نکنید
ممکن است اپراتور درخواست را آماده لغو کند، درحالی‌که همکارش همان لحظه آن را اجرا می‌کند. کنترل باید نزدیک لحظه تغییر نهایی انجام شود. اگر وضعیت عوض شده، نرم‌افزار باید اقدام را متوقف کند و توضیح دهد چرا مسیر قبلی دیگر معتبر نیست. نمایش پیام مشخص همراه با وضعیت تازه، بهتر از یک خطای عمومی یا اجرای تصمیم بر مبنای اطلاعات قدیمی است.
در برگشت جزئی نیز مقدار باقی‌مانده را از آخرین اطلاعات معتبر محاسبه کنید. دو درخواست هم‌زمان نباید بتوانند یک سهم را دوبار برگردانند. در نیازمندی پروژه، رفتار این رقابت را به زبان کسب‌وکار بنویسید و در آزمون با دو کاربر بررسی کنید. انتخاب روش فنی کنترل هم‌زمانی بر عهده تیم اجراست، اما نتیجه مورد انتظار باید برای سفارش‌دهنده قابل مشاهده باشد.
برگشت ناقص را به‌عنوان یک وضعیت واقعی نمایش دهید
گاهی یک اثر اصلاح می‌شود و اثر دیگر هنوز باقی است. در مثال تجهیزات، رزرو آزاد شده ولی سامانه پیام‌رسان در دسترس نیست. آیا این وضعیت برای ادامه کار کافی است یا باید مسئول با روش دیگری مطلع شود؟ پاسخ را پیشاپیش تعیین کنید. سامانه نباید همه اثرها را موفق گزارش کند فقط به این دلیل که اولین مرحله برگشت تمام شده است.
برای وضعیت ناقص، مسئول رسیدگی، گام باقی‌مانده و زمان آخرین تلاش را نشان دهید. اجرای دوباره نباید بخش انجام‌شده را بی‌جهت تکرار کند. همچنین تأیید دستی باید با دلیل و مدرک همراه باشد، نه صرفاً دکمه‌ای برای سبزکردن وضعیت. وقتی نتیجه یک سرویس نامعلوم است، ابتدا روش بررسی آن را اجرا کنید؛ ارسال مجدد بدون شناخت اثر قبلی می‌تواند مسئله تازه بسازد.
پیام تأیید باید پیامد را توضیح دهد
پرسش «آیا مطمئن هستید؟» اطلاعات کمی به کاربر می‌دهد. بهتر است نام عملیات، محدوده تغییر و نتیجه قابل انتظار مشخص باشد. مثلاً بگویید رزرو آزاد خواهد شد، ولی تحویل انجام‌شده از این مسیر قابل برگشت نیست. اگر بررسی انسانی لازم است، از ابتدا بنویسید که دکمه فقط درخواست را ثبت می‌کند و به معنی تکمیل برگشت نیست.
کاربر باید پس از ثبت، شناسه پیگیری و وضعیت بعدی را ببیند. در صورت رد درخواست نیز دلیل قابل فهم و مسیر مجاز ادامه ارائه کنید. برای فرم دلیل، گزینه‌های استاندارد می‌تواند گزارش‌گیری را بهتر کند، اما امکان توضیح ضروری را حذف نکنید. از کارکنان نخواهید اطلاعات محرمانه غیرمرتبط را در متن آزاد وارد کنند؛ دلیل باید برای تصمیم کافی و متناسب با موضوع باشد.
گزارش‌ها باید اصل عملیات و اصلاح آن را از هم جدا کنند
گزارش عملیاتی باید نشان دهد چه تعداد کار اصلی انجام شده، چه بخشی اصلاح شده و چه درخواست‌هایی هنوز در انتظار تصمیم‌اند. اگر با هر برگشت، رکورد اصلی ناپدید شود، فهم علت اختلاف گزارش‌ها دشوار خواهد شد. یک گزارش خالص ممکن است برای کار روزمره مفید باشد، اما باید بتوان اجزای تشکیل‌دهنده آن را نیز دید و ارتباطشان را دنبال کرد.
تعریف بازه زمانی هم مهم است. عملیاتی که هفته قبل انجام شده و امروز اصلاح می‌شود، در گزارش هر دو بازه چه اثری دارد؟ این پاسخ را با مالک گزارش تعیین کنید. در این مقاله فرمول مالی یا قاعده عمومی برای دوره‌های بسته پیشنهاد نمی‌کنیم. نرم‌افزار باید قرارداد گزارش‌گیری مورد تأیید سازمان را پیاده کند و با تغییر نمایش، سابقه صادرشده را بی‌دلیل بازنویسی نکند.
آزمون پذیرش را با سناریوهای ناموفق کامل کنید
مسیر ساده را آزمایش کنید: درخواست هنوز اجرا نشده، کاربر مجاز است و لغو بدون اثر باقی‌مانده تمام می‌شود. سپس شرایط دشوارتر را اضافه کنید: تحویل انجام‌شده، برگشت بخشی از اقلام، دو کاربر هم‌زمان، تغییر نقش، قطعی مقصد و دریافت دیرهنگام پاسخ. برای هر سناریو، وضعیت نهایی و اثرهای مجاز را پیش از اجرا بنویسید تا موفقیت قابل قضاوت باشد.
پس از آزمون، فقط صفحه کاربر را بررسی نکنید؛ نتیجه را در مقصد و گزارش مرتبط هم ببینید. سابقه باید نشان دهد کدام درخواست موجب کدام اصلاح شده است. معیار قبولی، نبودن خطای ظاهری نیست؛ باید معلوم شود اثر ناخواسته ایجاد نشده، مقدار برگشت از محدوده مجاز بیشتر نیست و هیچ مورد ناقصی بدون مسئول باقی نمانده است. این شواهد را همراه تحویل نرم‌افزار نگه دارید.
جمع‌بندی: برگشت را مانند یک فرایند واقعی طراحی کنید
قابلیت اصلاح قابل اعتماد با یک آیکون برگشت ساخته نمی‌شود. وضعیت معتبر، حدود اختیار، اثرهای جانبی، سابقه و راه رسیدگی به شکست باید کنار هم تعریف شوند. از یک عملیات پرتکرار شروع کنید و تمام مسیرهای آن را با کاربران بررسی کنید. هر جا بازگشت واقعی ممکن نیست، محدودیت را صریح نشان دهید و مسیر جایگزین مورد تأیید سازمان را طراحی کنید.
برای طراحی نرم‌افزار سفارشی با گردش اصلاح قابل پیگیری، می‌توانید یک نمونه فرایند را با ایزی‌ساز بررسی کنید. نمونه درخواست، وضعیت‌های فعلی، نقش‌های مسئول و خطاهای پرتکرار را آماده کنید. این داده‌ها کمک می‌کند دامنه قابلیت و آزمون‌های پذیرش روشن شود؛ نتیجه مطلوب، کاهش ابهام و اصلاح‌های خارج از سامانه است، نه وعده غیرواقعی اینکه هر عملی همیشه قابل بازگرداندن خواهد بود.