در پروژه‌های نرم‌افزاری و سیستم‌های مبتنی بر مدل‌های زبانی، تیم‌ها معمولاً لاگ‌ها، خطاها، بازخوردها و تیکت‌های فراوانی جمع‌آوری می‌کنند. با وجود این حجم از داده، بیشتر سیستم‌ها تغییر ملموسی نمی‌کنند؛ چرا که این اطلاعات بدون مسیر مشخص و بدون مسئول رها می‌شوند و صرفاً به تله‌متری بدون استفاده بدل می‌گردند.
این درس به شما می‌آموزد که چگونه سیگنال‌های دریافتی از رفتار کاربر، ارزیابی‌ها و خطاهای زمان اجرا را به اقدامات چرخدندهای (Ratchet Action) تبدیل کنید. به‌جای افزودن مداوم پاراگراف‌های جدید به پرامپت، یاد می‌گیرید مشکل را در مناسب‌ترین لایه (مانند تست، مرزهای دسترسی یا محیط اجرا) حل کنید.
علاوه بر این، انباشت قوانین و گاردریل‌های متناقض در درازمدت هزینه‌بر و کندکننده است؛ بنابراین تعیین شرط بازنشستگی برای هر کنترل و اتخاذ تصمیم‌های مبتنی بر شواهد، ضامن پایداری سیستم خواهد بود.
با تحویل محصول، یک چرخه‌ی ساخت بسته میشود و چرخه‌ی یادگیری آغاز به کار می‌کند. شواهد حتماً باید سیستم را تغییر دهند؛ وگرنه به داده‌های تله‌متری (Telemetry) بی‌صاحبی تبدیل می‌شوند که هیچ‌کس پیگیرشان نیست.
اهداف یادگیری
- تبدیل رخدادها، ارزیابی‌ها، رفتار کاربران و اصلاحات به اقداماتی دارای مسئول مشخص.
- هدایت هر سیگنال به بافت (Context)، ارزیابی، خطمشی، محیط اجرا یا بک‌لاگ.
- اولویت‌بندی تکرار بر اساس شدت و فراوانی.
- تعیین شرط بازنشستگی برای تک‌تک سازوکارهای کنترلی.
- انتقال تصمیم تحویل همراه با شواهد، موازنه‌ها (Tradeoffs) و فرد پاسخ‌گو.
بازخورد همان زیرساخت است
یک تیم می‌تواند ردگیری محاسبات، ارزیابی‌ها، تیکت‌های پشتیبانی و لاگ‌های رخداد را بدون ذره‌ای یادگیری جمع‌آوری کند. سازوکار مفقوده، «ارتقا» (Promotion) است: مسیری مشخص از مشاهده تا تغییری ماندگار، همراه با مسئولی مشخص و مدرک اثبات.
این چرخه به شرح زیر است:
- مشاهده‌ی یک سیگنال ملموس؛
- پیوند زدن آن به یک خروجی، محدودیت یا فرض؛
- شناسایی اولیهترین لایهی سیستم که علت را در اختیار دارد؛
- ایجاد تغییری کران‌دار و مشخص؛
- تأیید اینکه احتمال تکرار کمتر میشود؛
- بازنگری در اینکه آیا سازوکار کنترلی باید باقی بماند یا خیر.
هدایت به لایهی صاحب مسئله
| سیگنال | مقصد |
|---|---|
| مثبت کاذب، پس‌رفت، نتیجه‌ی اشتباه | ارزیابی یا تست |
| بافتِ جاافتاده، کار تکراری، فکتِ منسوخ | منبع بافت یا مسیر بازیابی |
| اقدام ناامن یا نبودِ سطح دسترسی | خطمشی یا مرز دسترسیها |
| اتمام مهلت زمانی (Timeout)، رگبار تلاش مجدد، وابستگی در دسترس‌نبوده | کنترل محیط اجرا |
| نیاز محصولی جدید یا موازنه‌ی حل‌نشده | قلم کاری شکل‌گرفته در بک‌لاگ |
ریشه‌ی مشکل را در اولیهترین لایهی کارآمد برطرف کنید. وقتی یک تست یا تعیین سطح دسترسی می‌تواند مانع وقوع خطا شود، پاراگراف دیگری به پرامپت اضافه نکنید.
احساس مسئولیت بخشی از سازوکار کنترلی است
هر اقدام چرخدندهای (Ratchet Action) به این موارد نیاز دارد:
- یک مسئول واحد؛
- اولویتی بر پایه‌ی پیامد و میزان تکرار؛
- دست‌سازه‌ای که باید تغییر کند؛
- تأییدیه‌ای که درستی تغییر را اثبات کند؛
- بازهی زمانی برای بازنگری یا انقضا؛
- شرط بازنشستگی.
بهبودی که مسئولی نداشته باشد، صرفاً مشاهده‌ای با قالب‌بندیِ تمیزتر است.
بازنشستگی سازوکارهای کنترلی منسوخ
سیستم‌های بازخورد به‌مرور خط‌مشی‌های زیادی روی هم تلنبار می‌کنند. این خط‌مشی‌ها ممکن است متناقض و پرهزینه شوند. در این شرایط سازوکارها را بازنگری کنید:
- معماری یا جریان کاری تغییر کند؛
- گزاره‌ای پایا در سطحی پایینتر جایگزین دستورالعملی در سطحی بالاتر شود؛
- خطایی که جلوی آن گرفته شده بود، در کل بازهی انتخابی رخ نداده باشد؛
- سازوکار کنترلی بیشتر از آنکه جلوی آسیب را بگیرد، مانع کارهای موجه شود.
بازنشستگی هم نیاز به شواهد دارد. صرفاً به این دلیل که سازوکاری قدیمی به‌نظر می‌رسد آن را حذف نکنید.
پیوند بازخورد ساخت و ایجنت کدنویسی
همان سازوکار چرخدندهای به هر دو مسیر خدمت می‌کند:
- شواهد محصول، چارچوب خروجی، فرضیات، برش کار یا برنامه‌ی سنجش را تغییر میدهد.
- اصلاحات ایجنت کدنویسی باعث تغییر تست‌ها، بافت، دامنه، خودکارسازی یا تحویل کار میشود.
- رخدادها می‌توانند هم مرز محصول و هم میزکار ایجنت را دگرگون کنند.
به همین دلیل شکل‌دهی ساخت، مرحله‌ای نیست که پیش از کدنویسی تمام شود؛ بلکه با هر تغییر پذیرفته‌شده ادامه می‌یابد.
پیاده‌سازی از صفر
این بخش عملیاتی سیگنال‌ها را دسته‌بندی می‌کند، اقدامات چرخ‌دنده‌ایِ صاحب‌دار می‌سازد، آن‌ها را اولویت‌بندی می‌کند و در outputs/feedback-backlog.json می‌نویسد.
python3 code/main.py
python3 -m unittest discover code/tests -vیک سیگنال اتمام مهلت زمانی محیط اجرا اضافه کنید و مطمئن شوید به‌جای بک‌لاگ عمومی، به خود محیط اجرا هدایت میشود.
آزمایشگاه عملی: مسئولیت یک تصمیم پس از شکست
یکی از جریان‌های کاری پروژه‌ی پورتفولیوی مسیر شغلی‌تان را انتخاب کنید. آن را از میان یک تصمیم، یک آزمایش کوچک و یک بازنگری پیش ببرید. شواهد را در career-delivery-evidence.md مستند کنید.
کد پایتون این درس نمونه‌هایی از اقدامات بک‌لاگ تولید می‌کند، اما به مشاهده‌ی رفتار کاربران، اندازه‌گیری اثر مداخله یا اثبات آمادگی شغلی نمی‌پردازد. اجرای موفق آن، صرفاً پیش‌نیازی برای این تمرین است.
1. بررسی دقیق آنچه اتفاق افتاده است
کاربر، وظیفه، جریان کاری فعلی و خروجی مدنظرتان برای بهبود را ثبت کنید. لینکی از یک مشاهده‌ی باکسب‌اجازه، پرونده‌ی پشتیبانی بازبینی‌شده (بدون داده‌های حساس) یا ردگیری قابل‌تکرار یک وظیفه قرار دهید. آنچه را مستقیماً مشاهده کرده‌اید، از آنچه دیگران گزارش داده‌اند و آنچه خودتان استنباط کرده‌اید، تفکیک کنید.
شکستی را بیابید: فرضی که رد شده، خروجی غیرقابل استفاده، هزینه‌ای پیش‌بینی‌نشده یا تحویلی که به تأخیر افتاده است. توضیح دهید کدام شواهد دیدگاه شما را دگرگون کرد. یک شکست نیازمند واکنش و تصمیم است، نه یک قصه‌ی موفقیت‌آمیزِ ساختگی که دور آن بافته شود.
اگر امکان کار با کاربران را ندارید، شبیه‌سازی مشخصی با برچسب شفاف همراه با طرف ارتباط یا بر اساس سناریویی معین اجرا کنید. مشاهدات شبیه‌سازی‌شده را جدا از شواهد کاربران واقعی نگه دارید. هرگز مصاحبه‌ها، تأییدیه‌ها، میزان پذیرش کاربر یا تأثیرات کسب‌وکاری ساختگی از خود تولید نکنید.
2. پیشبرد کار در دامنه‌ی اختیارات
فهرستی از مجهولات تهیه کنید و ارزان‌ترین اقدامِ برگشت‌پذیر را انتخاب کنید که می‌تواند مهم‌ترین مجهول را برطرف کند. مشخص کنید چه مواردی را خودتان می‌توانید تصمیم بگیرید، چه مواردی در دامنه‌ی توافقات قبلی محدود شده‌اند و چه بخش‌هایی پیش از اجرا نیازمند مجوز رسمی هستند.
برای نمونه، ممکن است در حین انتظار برای دریافت مجوز داده‌های مشتری، بازپخش آفلاینِ پالایش‌شده‌ای آماده کنید. ابتکار عمل یعنی پیش‌بردن کارهای مجاز و شفاف‌کردن تصمیمی که متوقف مانده است؛ این کار اختیارات دسترسی یا حقوق تأیید شما را فراتر نمی‌برد.
3. مقایسه‌ی گزینه‌ها و ارائه‌ی خلاصه به صاحب تصمیم
یک خلاصه‌ی تصمیم کوتاه برای شخصی بنویسید که نیازی به جزئیات پیاده‌سازی ندارد. این موارد را درج کنید:
- صورت مسئله‌ی کاربر و شواهدی که برنامه‌تان را تغییر داد؛
- دست‌کم دو گزینه، از جمله یک گزینهی دستی ارزان‌تر یا گزینهی عدم ساخت در صورت امکان؛
- موازنه‌های مربوط به کیفیت، طراحی تعامل، تلاش لازم، هزینه‌ی اجرا و ریسک؛
- پیشنهاد شما، ابهام‌های باقی‌مانده و تصمیمی که باید گرفته شود؛
- صاحب تصمیم، ذی‌نفعان تحت تأثیر و تاریخی که تصمیم باید تا آن روز نهایی شود.
از یکی از طرف‌های ارتباط بخواهید نقش ذی‌نفعی متأثر را بازی کرده و یکی از موازنه‌ها را به چالش بکشد. این مخالفت و میزان تأثیرگذاری آن را روی توصیه‌ی نهایی‌تان ثبت کنید. بازخورد حاصل از این نقش‌آفرینی را با برچسب شبیه‌سازی‌شده مشخص کنید؛ چنین چیزی هرگز جایگزین توافق واقعی ذی‌نفعان نیست.
4. اجرای آزمایشی کران‌دار
بر اساس سؤالی که باید پاسخ دهید، کار را در قالب پیش‌نمونه، پایلوت یا محیط عملیاتی انتخاب کنید. پیش از جمع‌آوری نتایج، مخاطبان، داده‌ها، سطح اختیارات، مدت‌زمان، روش بازگشت به عقب (Rollback) و شرایط ادامه، تغییر یا توقف را شفاف سازید.
مسیر تعامل را از نقطه‌ی شروع کاربر تا اتمام وظیفه مرور کنید. موردی از خروجی نادرست یا داده‌های ناقص را نیز بگنجانید. دقت کنید که آیا کاربر متوجه خطا میشود، می‌تواند آن را تصحیح کند و بدون کمک پنهانیِ شما به حالت عادی بازگردد یا خیر.
زمان بازبینی و اصلاح انسانی را جزئی از جریان کاری به حساب آورید. پاسخ سریع‌تر مدل، باز هم می‌تواند کل وظیفه را کندتر یا اعتماد به آن را سخت‌تر کند.
5. مقایسه‌ی خروجی‌ها و تحلیل اقتصادی
یک خط مبنا و نتیجه‌ی پیگیری را با تعریف معیار یکسان، جامعه‌ی وظایف یک‌دست، روش گردآوری مشابه و بازه‌های مشاهده‌ی قابل‌مقایسه ثبت کنید. حجم نمونه‌ها، موارد مستثنی‌شده و لینک‌های شواهد را کنار اعداد قرار دهید. اگر این شرایط تغییر کردند، توضیح دهید چرا مقایسه‌ی صورت‌گرفته محدودیت دارد.
یک خروجی کاربر، یک گاردریل کیفیت یا ایمنی و کل زحمت بازبینی انسانی را ثبت کنید. نتیجه را حتی در صورت نرسیدن به هدف بنویسید. نمونه‌های کوچک یا شبیه‌سازی‌شده، زمینه‌ساز ادعای یادگیری کران‌دار هستند، نه اثبات تأثیر کسب‌وکاری.
هزینه‌ی هر وظیفه‌ی موفق را با در نظر گرفتن فراخوانی‌های مدل، تلاش‌های مجدد، سرویس‌های پشتیبان و بازبینی انسانی تخمین بزنید. فرضیات مربوط به دستمزد ساعتی را ذکر کنید و مصرف واقعی را از برآوردها جدا نگه دارید. این هزینه را با روش دستی جایگزین یا فرضیات ارزشِ پروژه مقایسه کنید.
از درس موجودِ FinOps for LLMs برای تخصیص دقیق‌تر هزینه‌ها و اقتصاد واحد استفاده کنید. تغییر مدل فقط یکی از پاسخ‌های ممکن است؛ گاهی محدود کردن جریان کاری یا حفظ یک مرحله‌ی دستی، تصمیم محصولیِ بهتری به‌شمار می‌رود.
6. بستن چرخه
بر اساس معیارهای اعلام‌شده از قبل، توصیه‌ی خود مبنی بر ادامه، تغییر یا توقف را ارائه دهید. اگر شواهد قطعی نیست، مشاهده‌ی گم‌شده و آزمایش کران‌دار بعدی را نام ببرید. پاسخ صاحب تصمیم را ثبت کنید؛ اگر هنوز تصمیمی گرفته نشده، آن را در حالت معلق بگذارید.
یک بهبود برای خودِ فرایند تحویل انتخاب کنید: شفاف‌تر کردن چارچوب وظایف، پیمایش زودهنگام مسیر توسط کاربر، چک‌لیست بازبینی بهتر، بسته‌ی تحویل کوچک‌تر به ایجنت یا موردی دقیق‌تر برای ارزیابی. یک مسئول و تاریخ بازنگری برای آن مشخص کنید.
در زمان بازنگری، تصمیم بگیرید که این بهبود را حفظ کنید، تغییر دهید یا بازنشسته سازید. شواهد مربوط به این تصمیم را ثبت کنید. چک‌لیست جدیدی که فقط کار اضافه بتراشد بدون اینکه جلوی خطای مورد نظر را بگیرد، شایستگی ماندگاری ندارد.
خروجی این درس
فایل career-delivery-evidence.md را در پروژه‌ی خود کپی کرده و آن را با پیوند به شواهد تکمیل کنید. الگوی ثبت‌شده را برای استفاده‌های بعدی دست‌نخورده نگه دارید. خلاصه‌ی تصمیم، پیمایش تعامل، مقایسه‌ی سنجش‌ها و پیگیری‌های دارای مسئول را همراه با دستسازهی پورتفولیوی شغلی‌تان ذخیره کنید.
بررسی صحت کار
این شیوه‌نامه‌ی نمره‌دهی پذیرش دستی را همراه با طرف ارتباط به‌کار بگیرید. هر ردیف را با برآورده شد، نیازمند بازنگری یا مشاهده نشد علامت بزنید و لینکی به شواهد یا مشاهده‌ی ازدست‌رفته‌ی مشخصی ارائه دهید. صِرف پر بودن یک فیلد، دلیلی بر درست بودن داوری نیست.
| بررسی | شواهدی که آن را برآورده می‌کند |
|---|---|
| جریان کاری مستند | مشاهده‌ای قابل پیگیری از مسئله پشتیبانی می‌کند؛ ادعاهای گزارش‌شده، استنباط‌ها و شبیه‌سازی‌ها برچسب دارند. |
| رعایت دامنه‌ی اختیارات | اقدامات برگشت‌پذیر بعدی شفاف هستند و اقدامات محدودشده منتظر صاحب تصمیم واقعی می‌مانند. |
| انتقال موازنه‌ها | گزینه‌های واقع‌بینانه، مخالفت ذی‌نفع، پیشنهاد مشخص و درخواست شفاف برای تصمیم‌گیری ثبت شده‌اند. |
| تست تعامل | پیمایش مسیر شامل موفقیت، شکست، بازیابی و میزان زحمت بازبینی انسانی میشود. |
| مقایسه‌ی خروجی‌ها | تعاریف خط مبنا و پیگیری یکسان هستند؛ نمونه‌ها، گاردریل‌ها، هزینه‌ها و محدودیت‌های مقایسه مشخص‌اند. |
| پذیرش مسئولیت شکست | شواهد روی تصمیم ادامه/تغییر/توقف و اقدام مشخص بعدی تأثیر می‌گذارند. |
| بهبود فرایند | یکی از بهبودهای جریان کاری دارای مسئول، تاریخ بازنگری و تصمیم مبتنی بر شواهد برای حفظ/تغییر/بازنشستگی است. |
رفتار مشاهده‌نشده‌ی کاربران واقعی، حتی اگر تمام مراحل شبیه‌سازی‌شده موفق باشند، کماکان یک خلأ باقی می‌ماند. این مرز را در ادعاهای پورتفولیو حفظ کنید و مشاهده‌ی بعدی لازم برای بستن آن را مشخص سازید.
تمرین‌ها
- یک رخداد و یک شکایت کاربر را به اقدامات چرخدندهای تبدیل کنید.
- اولیهترین لایه‌ای را که می‌تواند جلوی هر تکرار را بگیرد، نام ببرید.
- دستورهای تأیید صحت یا مشاهدات جدیدی به خروجی کد این بخش اضافه کنید.
- شرط بازنشستگی یک قاعده‌ی خطمشی را مشخص کنید.
- یکی از اصلاحات پذیرفته‌شده را تا چارچوب وظیفه‌ی بعدی ردیابی کنید.
برای مطالعه‌ی بیشتر
- مقاله‌ی The Goal Question Metric Approach نوشته‌ی Basili، Caldiera و Rombach؛ برای یادگیری سازمانی از طریق سنجش‌های هدف‌محور.
- مقاله‌ی Building Blocks for Continuous Experimentation نوشته‌ی Fagerholm و دیگران؛ برای بررسی چرخه‌ی فنی و سازمانی پیونددهنده‌ی شواهد به ادامه‌ی توسعه‌ی محصول.
- مقاله‌ی Requirements Engineering: A Roadmap نوشته‌ی Nuseibeh و Easterbrook؛ درباره‌ی نگاه به نیازمندی‌ها به‌صورت پدیده‌ای که در طول چرخه‌ی حیات سیستم تکامل می‌یابد.
دستاوردهای شما
فایل outputs/feedback-backlog.json را به‌عنوان نمونه‌ی هدایت سیگنال‌ها و سند تکمیل‌شده‌ی شواهد تحویل مسیر شغلی را به‌عنوان سابقه‌ی تصمیم‌های خود نگه دارید. این دو در کنار هم مسیر «قضاوت محصولی و تحویل» را می‌بندند و چارچوب خروجی بعدی را شکل می‌دهند.