گزارش پس از حادثه بدون حافظه، نمایش عملکرد است
تیم بعد از انتشار دردناک گزارش پس از حادثه مینویسد، پنج بولت در اسلاید، و جلو میرود. شش ماه بعد همان الگوی شکست — وابستگی غافلگیرکننده، پیشبینی خوشبین، محدودهٔ مخفی در جلسهٔ روزانه، مالی دیر کشف میشود. روایت انسانی یاد میماند؛ سازمان به رکورد نیاز دارد.
تحلیل شکستهای گذشتهٔ پروژه با هوش مصنوعی روی کار ذخیرهشده میچرخد: ویکی گزارش پس از حادثه، تاریخچهٔ تسک، decision_log (لاگ تصمیم)، واریانس مالی، صندوق ورودی تصمیم. هوش مصنوعی الگو و شکاف را خلاصه میکند — جایگزین پاسخگویی یا آمار ثبتنشده نمیشود.
مشکل: درسی که روی هم انباشته نمیشود
شکافهای رایج:
- سند گزارش در پوشهٔ شخصی — نه
create_wiki_page - تصمیم در Slack — نه
log_decision - پیشبینی هرگز با نتیجه مقایسه نمیشود
- هوش مصنوعی «چرا شکست خورد؟» بدون بازیابی — علت را توهم میزند
یادگیری به اثر پایدار و حلقهٔ کالیبراسیون نیاز دارد.
چارچوب عملی: ثبت → ساختار → تحلیل → تغییر فرایند
- ثبت — بعد از لغزش مهم، ویکی گزارش با خط زمانی، تصمیم، سیگنال نادیدهگرفتهشده
- ساختار — برچسب الگوی شکست (وابستگی، ظرفیت، محدوده، فروشنده، کیفیت)
- تحلیل — پرسوجوی هوش مصنوعی از ویکی +
decision_log+ تاریخچهٔ تسک برای تم تکراری - تغییر — بهروزرسانی تعریف پایان کار، آستانهٔ پایش، سند onboarding — نه فقط اسلاید
ساختار لاگ در ویکی درس
| بخش | محتوا |
|---|---|
| خط زمانی | تاریخهای کلیدی انحراف دید |
| تصمیم | پیوند decision_log و ویکی جلسه |
| سیگنال از دست رفته | کهنگی، مصرف بودجه، صندوق ورودی نادیده |
| فرضیهٔ ریشه | رتبهبندی با اطمینان — نه سرزنش تکی |
| تغییر فرایند | مالک و تاریخ بازبینی هر اقدام |
وقتی پیگیری اقدامها تمام شد، صفحه را با update_wiki_page بهروز کنید — گزارش کهنه دقیقاً مثل مشخصات فنی کهنه، خواننده را گمراه میکند.
راهحل: تحلیل شکست در WKFGo
بازبینی فصلی الگوی شکست
رهبر سبد پروژه:
- پروژههای با لغزش مهم یا تجاوز بودجه (مالی + شیء انتشار)
- ویکی گزارش با
smart_searchیاsearch_docs decision_logدوره — پیشبینی در برابر نتیجه- هوش مصنوعی: «الگوی شکست بیش از یک پروژه؟ عنوان ویکی را استناد کن.»
بخش DIAGNOSIS در خروجی executive_brief فرضیههای ریشه را با درصد اطمینان رتبهبندی میکند — شواهد مخالف را هم بیاورید، نه فقط شواهدی که فرضیهٔ اول را تأیید میکنند.
کالیبراسیون یادگیری سازمانی
با log_decision وعدهٔ صریح ثبت کنید — مثلاً «ویژگی X تا تاریخ Y حذف شود تا بازیابی اتفاق بیفتد» — و بعداً نتیجهٔ واقعی را با همان وعده مقایسه کنید تا مدل کالیبره شود. اگر خطا هر بار از همان فرض میآید — مثلاً نادیده گرفتن صف بازبینی — راهحل بهروزرسانی آستانهٔ پایش است، نه سرزنش فرد.
وقتی همان موضوع دوباره در decision_inbox سر برمیآورد، لینک گزارش قبلی را در توضیح آیتم جدید بگذارید تا تصمیمگیرنده تاریخچه را ببیند.
onboarding از شکست
سرپرست جدید باید فهرست ویکی Lessons را بخواند — نه روایت شفاهی یک نفر. راهنمای مطالعه از هوش مصنوعی: «خلاصهٔ شکست یکپارچهسازی پرداخت ۱۴۰۳–۱۴۰۴؛ کاهش ریسک باز.»
مالک انسانی باید محتوا را پیش از آموزش تأیید کند.
مرز هوش مصنوعی (صادقانه)
- نرخ شکست بدون شمارش پروژه نسازد
- نمونهٔ کوچک را برچسب بزند
- همبستگی را از علیت جدا کند
- تحلیل شکست برای امتیاز فردی در دستور نباشد
پیوند شکست به onboarding
ماژول onboarding از ویکی شکست: «قبل از یکپارچهسازی پرداخت این سه صفحه؛ تسک تأیید Y بسته.» پیشنویس ماژول را هوش مصنوعی مینویسد؛ سرپرست فنی آن را تأیید میکند. با smart_search مطمئن شوید تازهوارد از همان روز اول این ماژول را پیدا میکند.
از get_user_performance یا معیارهای تحویل فقط در بازنگری سطح تیم استفاده کنید — بدون سیاست مشخص منابع انسانی، امتیازدهی خودکار به تکتک افراد را کنار بگذارید.
حافظهٔ سازمانی در برابر سرزنش
تحلیل شکست از نظر روانی امن باشد تا مفید بماند. گزارش پس از حادثه = اصلاح سیستم: پایش، سقف کار در جریان، تعریف پایان کار — نه «کی خوابید.» مدیر ارشد هم باید خطای خودش را با log_decision در مدل کالیبراسیون ثبت کند.
خلاصهٔ شکستی که هوش مصنوعی مینویسد باید به پیوند ویکی و لاگ تصمیم استناد کند — این اجباری است. اگر حدس از منبع فراتر رفت، تسهیلگر همان بخش را دور بیندازد. نمونهٔ کوچک (یک یا دو پروژه) را برچسب بزنید، و پیش از بازطراحی فرایند مطمئن شوید همان الگو در چند مورد دیگر هم تکرار شده.
نمودار flow_cfd یا خلاصهٔ ماندگی کار را ضمیمهٔ ویکی گزارش کنید تا خواننده ببیند رهبر در لحظهٔ تصمیم دقیقاً چه چیزی جلوی چشمش بوده — نه فقط روایت بعدی.
ریتم فصلی «درس آموخته»
هر فصل یک جلسهٔ ۶۰ دقیقه: سه گزارش ویکی بخوانید، خطای مشترک را در decision_log پیدا کنید، و یک آستانهٔ پایش یا تعریف پایان کار را عوض کنید — با مالک مشخص و تاریخ بازبینی. پیشنویس دستور جلسه را هوش مصنوعی بنویسد؛ رهبری خودِ جلسه دست تسهیلگر انسانی بماند. بدون اقدام بستهشده، بازنگری فقط نمایش است.
فهرست درس در Knowledge Hub
صفحهٔ Lessons: برچسب الگوی شکست، تاریخ، پروژه. جستجوی smart_search با عبارتی مثل «lessons payment» باید به همین فهرست برسد. نگهبان فصلی باید نسخههای کهنه را ادغام و بایگانی کند.
ارتباط با مالی و انتشار
گزارشی که واریانس finance_summary و زمینهٔ list_release_tasks را نداشته باشد ناقص است. پیشنویس هوش مصنوعی باید خط بودجه و نقطهٔ عطف نامدار را استناد کند. کالیبراسیون decision_log در فصل بعد باید «خطای پیشبینی در کاهش محدوده» را به همان آستانهٔ پایش وصل کند.
قالب ویکی گزارش پس از حادثه
قالب ثابت: خط زمانی، تصمیمها (پیوند به لاگ)، سیگنالهای از دست رفته، تغییرات (مالک + تاریخ). صفحه را با create_wiki_page از همین قالب بسازید؛ هوش مصنوعی میتواند پیشنویس اول را از تاریخچهٔ تسک بنویسد. تسهیلگر بیست دقیقه روی همان پیشنویس ویرایش میکند. قالب یکسان مقایسهٔ الگو بین پروژهها را آسان میکند.
اشتراک درس بین پروژهها
برای کم کردن ریسک تکرار «همان اشتباه» در پروژهٔ B بعد از شکست پروژهٔ A، فهرست Lessons را با smart_search جستجو کنید و از منشور پروژهٔ B به درسِ پروژهٔ A لینک بدهید. در صورت نیاز، نام مشتری را ناشناس کنید. سازمان یادگیرنده از تکرار شکست جلوگیری میکند.
سناریوهای تصمیم (در صورت نیاز)
| سناریو | چه زمانی بررسی شود | کد ابزار |
|---|---|---|
| تأخیر انتشار | اگر قرارداد/کیفیت اجازهٔ جابهجایی تاریخ بدهد | delay_release |
| کاهش محدوده | اگر تاریخ ثابت است و کار کمارزش قابل تعویق است | cut_scope |
| افزودن نیرو | اگر گلوگاه ظرفیت است نه وابستگی پیچیده | add_people |
| توقف پروژه | اگر سبد بیشبار است و باید شروع کار جدید قطع شود | freeze_project |
اشتباهات رایج
- بازنگری فقط سرزنش بدون مالک فرایند
- گزارش بدون عدد مالی
- رد
publish_meeting_wikiراهبری قبل از شکست - خلاصهٔ هوش مصنوعی بدون استناد
نتیجهٔ نهایی گزارش در ویکی باید با search_decisions به تصمیم مرتبط پیوند بخورد. وقتی صفحات ویکی کافی جمع شد، هوش مصنوعی میتواند تمهای مشترک شکست را بین پروژهها خوشهبندی کند — الگوی مستند شده همیشه از حکایت پراکنده قابلاعتمادتر است.
ممیزی ماهانه: آیا پاسخ هوش مصنوعی شناسهٔ تسک را از MCP استناد میکند؟
سؤالات متداول
گزارش خودکار از هوش مصنوعی؟
پیشنویس از تاریخچهٔ تسک؛ تسهیلگر نام و واقعیت حساس را تأیید کند.
تفاوت decision_log و ویکی؟
لاگ پیشبینی و انتخاب؛ ویکی روایت و زمینه — هر دو پیوند.
نگهداری درس؟
با انطباق همراستا؛ کهنه را حذف با اشارهٔ جایگزین.
تیم دوزبانه؟
زبان کاری انتشار؛ فهرست یکسان برای جستجو.
شکست → قضاوت کالیبرهشده
ثبت صادقانه، تحلیل با استناد، تغییر پایش و تعریف پایان کار.
امتحان کنید
این الگوها را روی دادهٔ زندهٔ پروژه اجرا کنید — نه اسلاید.