باگی که برمیگردد
هر تیمی نسخهای از این داستان را دارد: یک حادثهٔ تولید رفع میشود، همه ادامه میدهند، و هشت ماه بعد دقیقاً همان دسته باگ دوباره اتفاق میافتد — علامت متفاوت، همان علت ریشهای، رفعشده توسط کسی که هیچ نمیداند قبلاً هم اتفاق افتاده.
رفع اول تلف نشده بود. چیزی که کم است نیمهٔ دوم کار است: نوشتن چرا اتفاق افتاد، تا نفر بعدی مجبور نباشد آن را زیر فشار دوباره کشف کند. این شکاف یک هزینهٔ واقعی و قابلسنجش دارد — فقط در فاکتور حادثهٔ اول دیده نمیشود.
هزینه واقعاً کجا فرود میآید
زمان بررسی دوباره. یک نفر همان مراحل تشخیص را دوباره طی میکند، همان لاگها را چک میکند، همان سرنخهای اشتباه را رد میکند — کاری که یکبار انجام شده و دور ریخته شده چون فقط در حافظهٔ یک نفر یا یک کانال حادثهٔ بستهشده زندگی میکرد.
شکستن دوباره یک محدودیت رفعشده. یک راهحل موقت توسط کسی که نمیدانست چرا آنجاست حذف میشود، چون هیچچیز دلیل را ثبت نکرده بود. باگی که جلویش را میگرفت برمیگردد، معمولاً در تولید، معمولاً توسط یک مشتری کشف میشود.
فاکتور تکنفره تبدیل به قطعی واقعی. کسی که استدلال را به یاد دارد به مرخصی میرود، تیم عوض میکند، یا میرود. دانش تحویل داده نمیشود — فقط وقتی حادثهٔ بعدی به آن نیاز دارد، آنجا نیست.
بحث تکراری. یک انتخاب فنی هر بار که یک تازهوارد میآید دوباره به بحث گذاشته میشود، چون هیچ ثبتی از اینکه چه چیزی از قبل سنجیده و رد شده وجود ندارد، و چرا. هر بحث تکراری هزینهٔ یک جلسه دارد، و گاهی تصمیمی را برمیگرداند که بار اول به دلایلی درست بود که هیچکس در اتاق یادش نیست.
چرا این از آنچه در نقشهٔ راه بهنظر میرسد بدتر است
هیچکدام از اینها یک ردیف هزینه نمیشوند. در صد لحظهٔ کوچک «صبر کن، چرا اینطور کار میکند؟» پخش شدهاند، هرکدام چند دقیقه تا چند ساعت، که هیچوقت به یک صفحهٔ ویکی گمشده از یک سال پیش نسبت داده نمیشوند. این باعث میشود کمسرمایهگذاری در آن آسان باشد — هیچ گزارش حادثهٔ واحدی نمیگوید «بهخاطر تصمیم مستندنشدهٔ سهماههٔ دوم.»
نزدیکترین چیز به یک رسید، یک ریشهیابی است که با «این اتفاق افتاد چون یک راهحل موقت قبلی بدون اینکه کسی بداند چرا وجود دارد حذف شد» تمام میشود. این جمله در پستمورتمها بیشتر از آنچه بیشتر تیمها دوست دارند اعتراف کنند ظاهر میشود.
چه چیزی واقعاً جلویش را میگیرد
تصمیم را ثبت کنید، نه فقط نتیجه را. «از پولینگ بهجای وبهوک استفاده میکنیم» یک نتیجه است. «از پولینگ استفاده میکنیم چون فروشنده از وبهوک پشتیبانی نمیکند، و در اسفند یک رویکرد مبتنی بر وبهوک را امتحان و برگرداندهایم» یک ثبت تصمیم است — سال بعد در برابر پیشنهاد دوبارهٔ وبهوک زنده میماند.
آن را به کار وصل کنید، نه یک جلسهٔ جدا. تصمیمی که ماهها بعد در یک «روز مستندسازی» برنامهریزیشده نوشته میشود، از قبل بیشتر جزئیاتش را از دست داده. لحظهٔ بستهشدن یک تسک یا یک بررسی، ارزانترین زمان برای ثبت آن است — به چرا مستندسازی همیشه عقب میماند نگاه کنید تا ببینید چرا زمانبندی از نیت مهمتر است.
ثبت را خودکار کنید، نه آرمانی. یکپارچگی MCP در WKFGo — هر بار که یک ایجنت هوش مصنوعی یک تسک را میبندد — میپرسد آیا آنچه اتفاق افتاده بهصورت صفحهٔ ویکی نوشته شود. همان انضباطی است که یک مهندس خوب دستی اعمال میکند، فقط پیوسته پرسیده میشود، نه فقط وقتی کسی یادش میآید.
یک آزمون ارزان برای تیم خودتان
هر راهحل موقت یا الگوی غیرمعمول در کدبیستان را انتخاب کنید و از یکی در تیم بخواهید توضیح دهد چرا آنجاست. اگر جواب صادقانه «مطمئن نیستم، احتمالاً مهم است» باشد — این همان هزینه است که همین حالا دارد خودش را نشان میدهد، و ارزش یک صفحهٔ ویکی همین امروز را دارد، قبل از اینکه حادثهٔ فردا شود.
سؤالات متداول
آیا ثبت تصمیم فقط اضافهکاری بیشتر نیست؟
فقط اگر یک مراسم جدا باشد. اگر در لحظهٔ بستهشدن یک تسک گرفته شود — که همان کاری است که یک یادآوری «بپرس، فرض نکن» در MCP انجام میدهد — فقط هزینهٔ یک پاسخ بله/نه دارد، نه یک جلسه.
حداقل چیزی که یک ثبت تصمیم نیاز دارد چیست؟
انتخابی که شده، جایگزینی که رد شده، و محدودیتی که آن را تحمیل کرده. اغلب سه جمله کافی است.
این برای کد نوشتهشده توسط ایجنت هوش مصنوعی هم صدق میکند؟
مخصوصاً آنجا — پنجرهٔ context یک ایجنت بین جلسات کاملاً بسته میشود، پس تصمیمی که ننویسدش، درست به همان اندازه که یک آدم فراموشش کند، از بین میرود.
جمعبندی
هزینهٔ یک تصمیم مستندنشده، حادثهٔ اول نیست — آن به هر حال رفع میشود. هر ساعتی است که صرف کشف دوبارهٔ همان محدودیت میشود، بعد از اینکه کسی که پیدایش کرده رفته، حواسش پرت شده، یا خواب است.