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