بسیاری از تیم‌های نرم‌افزاری برای تعریف ویژگی‌های جدید یا توسعه‌ی قابلیت‌های هوش مصنوعی، مستقیماً از کاربران می‌پرسند چه می‌خواهند؛ پاسخی که معمولاً دریافت می‌کنند مجموعه‌ای از تمایلات ذهنی است، نه آنچه در واقعیت رخ می‌دهد. وقتی محصول بر مبنای این خواسته‌های انتزاعی ساخته میشود، در اولین مواجهه با فرایندهای غیررسمی، استثناهای روزمره و دست‌به‌دست شدن کارها بین افراد شکست می‌خورد.
حل این مسئله در بازسازی جریان کاری فعلی بر اساس رفتارهای مشاهده‌پذیر نهفته است. در این درس یاد می‌گیرید که چطور گام‌های واقعی کاربران، منابع اصطکاک، وضعیت‌های پنهان در حافظه یا چت‌ها و مرزهای اختیارات را مستند کنید تا بتوانید نیازمندی‌ها را با تکیه بر شواهد مستقیم و بدون فرضیات خوش‌بینانه بسازید.
نیازمندی‌ها در جلسه‌ای منتظر ننشسته‌اند تا جمع‌آوری‌شان کنید؛ بلکه لابه‌لای کارها، راه‌حل‌های موقت، سوابق و اختلاف‌نظرها پراکنده‌اند.
اهداف یادگیری
- مدلسازی جریان کاری (workflow) فعلی به‌صورت اقداماتی ترتیبی همراه با شواهد.
- تفکیک مشاهدات مستقیم از رفتارهای گزارششده یا استنباط‌شده.
- شناسایی اصطکاک، دست‌به‌دست شدن کارها، اختیار و وضعیت پنهان.
- شفاف نگه‌داشتن ادعاهای نامطمئن به‌جای تبدیل زودهنگام آن‌ها به نیازمندی.
کار را با سیستم فعلی شروع کنید
کار را با این سؤال شروع نکنید که افراد چه امکاناتی می‌خواهند؛ از بازسازی آنچه در حال حاضر رخ می‌دهد شروع کنید.
برای هر مرحله، موارد زیر را ثبت کنید:
| فیلد | مثال |
|---|---|
| کنشگر | مهندس کشیک (on-call) |
| محرک | دریافت هشدار پروداکشن (production alert) |
| اقدام | باز کردن هشدار و سپس جست‌وجو در داشبوردها |
| ورودی | بار دادهایِ (payload) هشدار و سوابق دیپلوی |
| خروجی | سرویس کاندید و مالک آن |
| اصطکاک | سوئیچ مداوم بین سه ابزار |
| اختیار | مدیر بحران تغییرات پایگاه داده را تأیید میکند |
| شواهد | ویدیوی ضبط صفحه‌نمایش، لاگ حادثه، دستورالعمل اجرایی (runbook) |
جریان کاری بسیار فراتر از اتفاقات روی صفحه‌نمایش است. این جریان شامل انتظار، کپی-پیست، کانال‌های فرعی، گرفتن تأییدیه‌ها، بازیابی از خطا و کارهایی است که افراد دیگر حتی متوجه انجام‌دادنشان نمی‌شوند.
شواهد درجه‌بندی دارند
از یک نردبان ساده‌ی شواهد استفاده کنید:
- رفتار مستقیم: مشاهدهی عینی، ردگیری محاسبات (trace)، ویدیوی ضبط‌شده یا رویداد سیستمی.
- دستسازه: تیکت، دستورالعمل اجرایی، لاگ، فرم یا خروجی نهایی تکمیل‌شده.
- رفتار گزارششده: فرد کاری را که انجام می‌دهد توصیف میکند.
- استنباط: تیم به این جمع‌بندی می‌رسد که احتمالاً چه اتفاقی رخ می‌دهد.
هر چهار مورد می‌توانند مفید باشند، اما فقط دو مورد اول رفتار فعلی را مستقیماً اثبات می‌کنند. بقیه‌ی موارد را برچسب‌گذاری کنید تا میزان اطمینان به‌طور کاذب و بی‌صدا بالا نرود.
به دنبال چهار چیز بگردید
- اصطکاک: تلاش‌های تکراری، تأخیر، ورود مجدد دادهها یا بازیابی.
- وضعیت پنهان: اطلاعاتی که در حافظه‌ی افراد، چت‌ها یا یادداشت‌های شخصی نگه‌داری می‌شوند.
- اختیار: فرد یا سیستمی که اجازهی اعمال تغییری تعیین‌کننده را دارد.
- استثناها: شرایطی که جریان کاری از حالت عادی خارج میشود.
قابلیت‌های هوش مصنوعی معمولاً در نقاط دست‌به‌دست شدن کار و مواجهه با استثناها شکست می‌خورند؛ چرا که فقط مسیر ایدئال و بی‌دردسر (happy path) طراحی شده است.
اختلاف‌نظرها را با میانگینگیری محو نکنید
دو کاربر ممکن است به دلایل کاملاً موجه، جریانهای کاری متفاوتی را پیش ببرند. این گونه‌های مختلف را تا زمانی حفظ کنید که بفهمید نشان‌دهنده‌ی چه چیزی هستند:
- نقش‌های متفاوت؛
- سطوح مختلف ریسک؛
- فرایند قدیمی در برابر فرایند فعلی؛
- تفاوت در سطح مهارت و تجربه؛
- یک اختلاف‌نظر واقعی بر سر سیاستها و مقررات.
یک جریان کاری میانگین‌گیری‌شده در عمل ممکن است رفتار هیچ‌کس را توصیف نکند.
پیاده‌سازی
این کارگاه عملی شواهد مربوط به هر مرحله از جریان کاری را ذخیره میکند، ترتیب مراحل و سطح اطمینان را میسنجد، نسبت شواهد مستقیم را محاسبه میکند و در نهایت فایل outputs/workflow-evidence.json را می‌نویسد.
python3 code/main.py
python3 -m unittest discover code/tests -vیک مسیر استثنا اضافه کنید که در آن سابقه‌ی دیپلوی در دسترس نیست. ترتیب اصلی مراحل را دست‌نخورده نگه دارید و مشخص کنید این branch از کجا آغاز میشود.
تمرین‌ها
- یک جریان کاری را صرفاً از روی یک لاگ و بدون مصاحبه با هیچ فردی بازسازی کنید.
- با یک کاربر مصاحبه کنید و هر ادعایی را که هنوز شواهد مستقیم ندارد علامت بزنید.
- یک مرز اختیار و یک مرحله‌ی بازیابی از شکست اضافه کنید.
- دو گونه‌ی مختلف از یک جریان کاری را بدون ادغام کردن در یکدیگر مدلسازی کنید.
- قابلیت پیشنهادی‌ای پیدا کنید که یک مرحله‌ی ظاهری را حذف میکند، اما کار پنهان را دست‌نخورده باقی می‌گذارد.
برای مطالعه‌ی بیشتر
- Nuseibeh and Easterbrook, Requirements Engineering: A Roadmap، به‌ویژه نگاه آن به استخراج ورودی به‌چشم تفسیر، مدلسازی و اعتبارسنجی، نه صرفاً ثبت و ضبط ساده‌ی اطلاعات.
- Gotel and Finkelstein, An Analysis of the Requirements Traceability Problem، درباره‌ی دشواری حفظ ارتباط میان نیازمندی‌ها و منابع آن‌ها.
خروجی این درس
فایل outputs/workflow-evidence.json را نگه دارید. این فایل در درس بعد، اصطکاک و عدم‌قطعیت‌های مشاهده‌شده را به نقشه‌ی فرضیات تبدیل میکند.