نویسنده: WKFGo Editorial · ·
پاسخ کوتاه: OKR را چگونه به تسک‌ها وصل کنیم؟
برای اتصال OKR به تسک‌های روزانه، ابتدا یک Objective نتیجه‌محور و دو تا چهار Key Result قابل اندازه‌گیری تعریف کنید. سپس ابتکارهای هر KR را مشخص کنید و فقط تسک‌هایی را به آن ابتکار وصل کنید که واقعاً بر نتیجه اثر دارند. پیشرفت KR باید از داده نتیجه به‌روزرسانی شود، نه از درصد تسک‌های بسته‌شده.
تسک «ارسال سه کمپین» می‌تواند ۱۰۰٪ تمام شود، اما اگر نرخ فعال‌سازی تغییر نکند، KR پیشرفت نکرده است. این تفاوت، مرز بین خروجی و نتیجه است.
ساختار درست: Objective، Key Result، ابتکار، تسک
| سطح | پرسش | نمونه |
|---|---|---|
| Objective | چه تغییری می‌خواهیم؟ | شروع کاربر جدید را بی‌اصطکاک کنیم |
| Key Result | از کجا می‌فهمیم موفق شدیم؟ | فعال‌سازی ۷روزه از ۳۲٪ به ۴۵٪ برسد |
| ابتکار | چه شرطی را آزمایش می‌کنیم؟ | بازطراحی راهنمای شروع |
| تسک | چه کاری باید انجام شود؟ | تحلیل پنج نقطه ریزش، ساخت نسخه آزمایشی |
Objective نباید «راه‌اندازی داشبورد» باشد؛ آن یک خروجی است. KR نیز نباید «بهبود رضایت» باشد؛ مقدار مبنا، هدف، منبع داده و تاریخ لازم دارد.
یک نمونه کامل OKR برای تیم محصول
Objective: کاربران جدید در هفته اول ارزش محصول را تجربه کنند.
- KR1: نرخ فعال‌سازی ۷روزه از ۳۲٪ به ۴۵٪ برسد.
- KR2: میانه زمان تا ساخت اولین پروژه از ۱۸ دقیقه به ۱۰ دقیقه برسد.
- KR3: تیکت‌های «شروع کار» از ۱۲۰ به کمتر از ۸۰ مورد در ماه برسد.
ابتکار «راهنمای تعاملی شروع» ممکن است به KR1 و KR2 کمک کند. تسک‌های طراحی، پیاده‌سازی و آزمایش به این ابتکار وصل می‌شوند. اما خود KR فقط وقتی جلو می‌رود که داده رفتار کاربر تغییر کند.
۱. مالک و منبع داده را تعیین کنید
هر KR یک مالک دارد که صحت عدد را پیگیری می‌کند؛ مالک لزوماً انجام‌دهنده همه تسک‌ها نیست. منبع داده و تناوب به‌روزرسانی را همان ابتدا ثبت کنید تا پایان فصل بر سر عدد بحث نشود.
۲. خط مبنا و هدف را بنویسید
«افزایش نرخ تبدیل به ۲۵٪ تا پایان آذر، از خط مبنای ۱۸٪ در شهریور» قابل ارزیابی است. اگر خط مبنا نامطمئن است، هفته اول را به اندازه‌گیری اختصاص دهید و اطمینان داده را صریح بنویسید.
۳. ابتکارها را فرضیه ببینید
پروژه یا قابلیت تضمین نمی‌کند KR بهتر شود. آن را به شکل فرضیه ثبت کنید: «اگر مراحل ثبت‌نام را از پنج به سه کاهش دهیم، تکمیل ثبت‌نام افزایش می‌یابد.» این نگاه اجازه می‌دهد ابتکار ناموفق را متوقف کنید بدون اینکه هدف را کنار بگذارید.
۴. تسک‌ها را به ابتکار وصل کنید، نه مستقیم به هر هدف
اتصال مستقیم صدها تسک به Objective نمودار شلوغ و بی‌معنا می‌سازد. ساختار هدف ← KR ← ابتکار ← تسک، هم ردیابی دارد و هم مالکیت را روشن می‌کند. کار عملیاتی ضروری که به OKR وصل نیست نیز پنهان نشود؛ همه کارها لازم نیست استراتژیک باشند.
۵. بازبینی دوهفته‌ای انجام دهید
جلسه ۲۰ دقیقه‌ای کافی است:
- عدد فعلی و کیفیت داده؛
- روند نسبت به خط مبنا؛
- ابتکار مؤثر یا بی‌اثر؛
- مانع و تصمیم لازم؛
- ادامه، تغییر یا توقف آزمایش.
جلسه نباید به خواندن فهرست تسک تبدیل شود. بورد وضعیت اجرای کار را نشان می‌دهد؛ جلسه برای تفسیر نتیجه و تصمیم است.
وزن‌دهی و محاسبه پیشرفت
برای KR عددی، پیشرفت خطی ساده می‌تواند نقطه شروع باشد:
پیشرفت = (مقدار فعلی − مبنا) ÷ (هدف − مبنا)
اگر نرخ از ۲۰٪ به ۲۵٪ رسیده و هدف ۳۰٪ است، پیشرفت عددی ۵۰٪ است. اما این فرمول برای همه شاخص‌ها مناسب نیست؛ کاهش خطا جهت معکوس دارد و بعضی نتایج آستانه‌ای‌اند. روش محاسبه را از ابتدا تعریف کنید.
میانگین‌گرفتن ساده از نتایج کلیدی نیز ممکن است گمراه‌کننده باشد. اگر یکی شرط حیاتی موفقیت است، وزن یا وضعیت جداگانه داشته باشد. عدد کلی نباید یک نتیجه کلیدی قرمز را پشت چند نتیجه سبز پنهان کند.
اشتباهات رایج
- تبدیل فعالیت به KR: «برگزاری ۱۰ وبینار» به‌جای اثر بر جذب یا فعال‌سازی؛
- اتصال هر تسک سازمان به یک OKR برای پرکردن گزارش؛
- به‌روزرسانی پیشرفت از درصد Done پروژه؛
- تغییر تعریف یا خط مبنا در میانه فصل بدون ثبت دلیل؛
- داشتن بیش از سه Objective فعال برای یک تیم؛
- استفاده از OKR برای ارزیابی مستقیم فردی و تشویق بازی با عدد؛
- نگه‌داشتن کار عملیاتی خارج از بورد تا ظرفیت استراتژیک بیشتر دیده شود.
چه چیزی را در WKFGo ثبت کنیم؟
در WKFGo می‌توانید هدف، مالک، بازه زمانی و وضعیت را کنار پروژه و تسک نگه دارید. پیشنهاد عملی این است که برای هر KR صفحه کوتاهی شامل تعریف شاخص، منبع داده، خط مبنا و تاریخ بازبینی داشته باشید؛ ابتکارها به پروژه یا اپیک و کار اجرایی به تسک‌ها متصل شوند.
دستیار هوش مصنوعی می‌تواند تسک‌های بدون ارتباط، نتایج کلیدی بدون داده تازه یا ابتکارهای پرهزینه و بی‌اثر را پیدا کند؛ اما نباید پیشرفت نتیجه را از روی تعداد تسک حدس بزند.
داشبوردی که تصمیم می‌سازد
برای هر Objective این اطلاعات کافی است:
- مقدار فعلی، مبنا و هدف هر KR؛
- تاریخ آخرین به‌روزرسانی و سطح اطمینان؛
- ابتکارهای فعال و هزینه تقریبی؛
- ریسک یا مانع اصلی؛
- تصمیم بعدی و مالک آن.
نمودار زیاد جای داده تازه را نمی‌گیرد. KR بدون تاریخ به‌روزرسانی باید «داده کهنه» نشان داده شود، نه سبز.
تفاوت OKR و KPI چیست؟
KPI سلامت مستمر یک فرایند را پایش می‌کند؛ OKR تغییر مهمی را در یک بازه هدایت می‌کند. یک KPI مثل نرخ حفظ مشتری می‌تواند وقتی نیازمند جهش است به KR تبدیل شود.
چند OKR برای هر تیم مناسب است؟
معمولاً یک تا سه Objective فعال و دو تا چهار KR برای هرکدام تمرکز بهتری می‌دهد. ظرفیت واقعی تیم مهم‌تر از عدد نسخه‌برداری‌شده از شرکت دیگر است.
آیا هر تسک باید به OKR وصل باشد؟
خیر. نگه‌داری، پشتیبانی و الزام قانونی ممکن است ضروری باشند بدون اینکه مستقیماً یک OKR را جلو ببرند. این کارها را شفاف ثبت کنید تا ظرفیت واقعی دیده شود.
اگر همه تسک‌ها Done شدند اما KR جلو نرفت چه کنیم؟
این یک یادگیری است: فرضیه یا انتخاب ابتکار درست نبوده است. ابتکار را بازبینی یا متوقف کنید؛ برای سبزکردن گزارش، تعریف KR را عوض نکنید.
شروع عملی
یک Objective فعال را انتخاب کنید، منبع داده نتایج کلیدی را مشخص کنید و فقط یک ابتکار را به بورد وصل کنید. دو بازبینی دوهفته‌ای اجرا کنید و بعد ساختار را گسترش دهید. برای برنامه‌ریزی ظرفیت اجرای همین ابتکارها، راهنمای تحلیل بار کاری مفید است.
منابع دست‌اول و روش راستی‌آزمایی
این فهرست برای بررسی بیشتر است؛ لینک‌های داخل متن، منبع ادعای مشخص همان بخش‌اند.