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