جشن گرفتن موفقیتهای کوچک زمانی ارزش مدیریتی دارد که «برد» واقعاً چیزی را تغییر داده باشد: یک عدمقطعیت مهم کم شده، ریسک مشخصی بسته شده، کاربر نتیجهای را تأیید کرده یا قابلیت قابلاستفادهای ایجاد شده است. اگر هر تیک Task، جلسه یا عدد خوشایند را جشن بنامیم، تیم خیلی زود میان Activity و Outcome گم میشود.
این راهنما یک Small-Win Governance عملی میسازد: با Win Threshold تشخیص میدهید چه چیزی برد است، با Win Register شواهد و Credit را ثبت میکنید، با Cadence مناسب پیام میدهید و با Win Portfolio بردهای پراکنده را به هدف اصلی Roll-up میکنید؛ بدون Vanity progress یا Premature victory.
خلاصه اجرایی
- Small win باید محدود، کامل، قابلمشاهده و مرتبط با Outcome باشد؛ کوچکبودن بهمعنای بیاهمیتبودن نیست.
- Task completion فقط وقتی برد است که Evidence نشان دهد uncertainty، risk، delay، defect یا effort آینده را کم کرده است.
- Win Threshold پیش از شروع دوره تعریف میشود؛ بعد از دیدن نام افراد یا نتیجه، معیار را جابهجا نکنید.
- جشن، جای Acceptance، QA، جبران اضافهکاری، Performance review یا حل blocker را نمیگیرد.
- پیام خوب «Evidence + Impact + Shared credit + Next» دارد و پیروزی نهایی اعلام نمیکند.
- بردها در Portfolio به Outcome، فرضیه و ریسک باز وصل میشوند؛ فهرست Kudos کافی نیست.
- Cadence باید بین تازگی و Celebration fatigue تعادل بسازد؛ همه بردها مراسم مستقل نمیخواهند.
- اگر تعداد پیام بالا ولی Outcome راکد است، Win definition یا Incentive را متوقف و بازبینی کنید.
مرز این صفحه با راهنماهای نزدیک
| پرسش اصلی | مرجع درست |
|---|---|
| رشد فرد از Baseline تا Milestone چگونه سنجیده و دیده شود؟ | Progress Recognition در ۲۸۴ |
| قدردانی روزمره چگونه به عادت پایدار تبدیل شود؟ | Recognition Habits در ۶۱۹ |
| تلاش مفید چگونه از Busywork و اضافهکاری جدا شود؟ | Effort Calibration در ۱۱۵ |
| پس از پروژه سخت، Credit، Recovery و Closure چگونه اداره شود؟ | Hard-project Closure در ۲۷۸ |
| چه رویدادی Small win است و چگونه به Outcome تجمیع میشود؟ | همین صفحه |
Small win دقیقاً چیست؟
در این راهنما، Small win یک Outcome محدود و کامل است که شواهد قابلبررسی دارد، برای هدف مهمی مفید است و اندازهاش آنقدر کوچک است که تیم بتواند آن را بفهمد و بر مبنای آن اقدام بعدی را انتخاب کند. «کامل» یعنی واحد تعریفشده بسته شده؛ نه اینکه کل پروژه تمام شده باشد.
برای مثال، «نسخه را Deploy کردیم» Activity/Output است. «نسخه برای ۱۰٪ کاربران بدون عبور از Error budget فعال شد و فرضیه اصلی را با داده اولیه آزمود» یک برد کوچک بالقوه است. هنوز Rollout کامل نشده و ریسک باز باید صریح بماند.
Small win چه چیزی نیست؟
| رویداد | چرا بهتنهایی برد نیست؟ | چه شواهدی آن را قابلبررسی میکند؟ |
|---|---|---|
| جلسه برگزار شد | حضور، Outcome نیست | تصمیم، Owner، deadline و رفع dependency |
| Task بسته شد | ممکن است rework یا defect بسازد | Acceptance و اثر بر جریان کار |
| Prototype ساخته شد | هنوز فرضیه تأیید نشده | تست کاربر یا تصمیم آگاهانه |
| فروش بالا رفت | فصل، تخفیف یا تأخیر ثبت ممکن است علت باشد | تعریف metric و مقایسه معتبر |
| اضافهکاری شد | Input و گاهی علامت شکست سیستم است | جبران/Recovery جدا؛ نه جشن Heroism |
| ریسک «سبز» شد | Status دستی میتواند واقعیت را پنهان کند | کنترل آزموده و residual risk |
| بازخورد مثبت رسید | یک نظر ممکن است نماینده نباشد | Context، منبع و تصمیمی که تغییر میدهد |
پژوهش چه میگوید و چه نمیگوید؟
| منبع | بینش قابلاستفاده | حد استنباط |
|---|---|---|
| Weick 1984 | Outcomeهای محدود، کامل و قابلدیدن میتوانند به الگویی بزرگتر جمع شوند | مقاله درباره مسائل اجتماعی است؛ Program آماده HR نیست |
| Amabile & Kramer | در diaryهای تیمهای پروژه، progress in meaningful work با کیفیت تجربه روز کاری مرتبط بود | هر Task، جایزه یا پیام را علت بهرهوری نمیکند |
| Amir & Ariely 2008 | Progress marker در عدمقطعیت میتواند کمک کند؛ در فاصله روشن تا هدف ممکن است complacency بسازد | چهار آزمایش Task؛ نه نسخه مستقیم محیط کار ایران |
| Reay et al. 2006 | Small winهای انباشته در یک مطالعه طولی به جاافتادن Practice جدید کمک کردند | مطالعه Contextual است، نه تضمین عمومی تغییر |
| Harkin et al. 2016 | Monitoring progress در مجموعه بزرگی از مطالعهها با goal attainment مرتبط بود | انتشار عمومی یا Surveillance را تجویز نمیکند |
پس گزاره قابلدفاع این نیست که «جشن کوچک دوپامین آزاد میکند و بهرهوری را بالا میبرد». گزاره محتاطانه این است: دیدن پیشرفت معنادار میتواند برای جهتیابی و تجربه کاری مفید باشد، اما marker بدطراحیشده میتواند رضایت زودرس یا بازی با معیار بسازد.
منابع و روش استفاده
- Weick، Small Wins، ۱۹۸۴: برای تعریف Outcome محدود/کامل و قابلیت تجمیع؛ نه برای وعده عملکرد یا طراحی Reward.
- برنامه پژوهشی Progress Principle در HBS: برای رابطه Progress در کار معنادار با inner work life و شرح دامنه diary study؛ نه تعمیم به هر Task یا سازمان ایرانی.
- Amir و Ariely، ۲۰۰۸: برای ریسک complacency ناشی از markerهای گسسته وقتی فاصله هدف روشن است؛ نه پیشبینی قطعی رفتار تیم.
- Reay، Golden-Biddle و Germann، ۲۰۰۶: برای الگوی انباشت small wins در یک تغییر سازمانی طولی؛ با حفظ محدودیت Context.
- Harkin و همکاران، ۲۰۱۶: برای نقش monitoring در goal attainment؛ بدون تبدیل آن به انتشار عمومی اجباری یا Surveillance.
زنجیره Activity تا Impact
| سطح | تعریف | نمونه فروشگاه آنلاین | جشن؟ |
|---|---|---|---|
| Activity | کاری که انجام شد | سه مصاحبه مشتری | معمولاً تشکر ساده |
| Output | تحویل قابلمشاهده | گزارش علل لغو | اگر accepted/usable باشد |
| Evidence | دادهای که باور را تغییر میدهد | دو علت پرتکرار با نمونه کافی | برد یادگیری بالقوه |
| Capability | توان قابلاستفاده جدید | هشدار موجودی پیش از پرداخت | پس از آزمون کنترل |
| Outcome | تغییر مطلوب برای ذینفع | کاهش لغو ناشی از کسری | بله، با Attribution محتاط |
| Impact | اثر پایدار/وسیعتر | حفظ حاشیه و اعتماد مشتری | نیازمند زمان و شواهد بیشتر |
Win Threshold ششگانه
پیش از Sprint، ماه یا موج تغییر، تیم حداقل آستانه را تعریف میکند. یک Candidate لازم نیست در همه ابعاد عالی باشد، اما باید در Eligibilityهای اجباری قبول شود.
| معیار | سؤال Gate | رد نمونه |
|---|---|---|
| Bounded | واحد برد و مرزش روشن است؟ | «فرهنگ بهتر شد» |
| Complete | Definition of done همان واحد بسته است؟ | Draft بدون review |
| Evidence | چه شاهدی غیر از روایت صاحب کار داریم؟ | Status شفاهی |
| Meaning | به کدام Outcome/ریسک/فرضیه وصل است؟ | Feature بدون مسئله |
| Integrity | ایمنی، کیفیت، قانون و Work boundary رعایت شده؟ | تحویل با دورزدن کنترل |
| Credit | Contributor و dependency قابل اصلاحاند؟ | قهرمان واحد برای کار تیمی |
Evidence Ladder برای بردهای کوچک
| سطح | Evidence | ادعای مجاز |
|---|---|---|
| E0 | روایت/اعلام | Candidate، نه برد تأییدشده |
| E1 | Output قابل مشاهده | تحویل انجام شده |
| E2 | Acceptance مستقل | معیار واحد پاس شده |
| E3 | رفتار/عملیات واقعی | قابلیت استفاده شده |
| E4 | Outcome با baseline/context | تغییر مشاهده شده |
| E5 | Replication/persistence | نتیجه در زمان/گروه دیگر تکرار شده |
آستانه به Risk بستگی دارد. برای Experiment کمریسک، E2 میتواند «برد یادگیری» باشد؛ برای کنترل مالی، امنیت یا سلامت، E2 شاید کافی نباشد. Evidence level را پس از نتیجه پایین نیاورید.
Taxonomy بردها؛ همه بردها Outcome نهایی نیستند
| نوع Win | تعریف | نمونه | برچسب لازم |
|---|---|---|---|
| Learning | عدمقطعیت تصمیم کم شد | فرضیه قیمت رد شد | چه تصمیمی عوض شد؟ |
| Risk | Exposure معتبر کاهش یافت | Fallback پرداخت آزموده شد | Residual risk |
| Quality | Defect/variation کم شد | خطای مرجوعی کاهش یافت | Baseline/window |
| Flow | زمان انتظار/هندآف کم شد | تأیید قرارداد کوتاهتر شد | No quality trade-off |
| Customer | ارزش قابلدیدن برای مشتری | حل First-contact بهتر شد | Sample/context |
| Capability | توان پایدار ایجاد شد | Runbook و backup آزموده | Owner/adoption |
| Coordination | وابستگی مهم بسته شد | API contract دو تیم پذیرفته شد | Shared credit |
Win Card؛ واحد ثبت قابلممیزی
| فیلد | پرسش |
|---|---|
| Win ID/date | کدام رویداد و چه زمانی؟ |
| Candidate statement | چه چیزی تغییر کرد؟ |
| Win type | Learning، Risk، Quality، Flow، Customer یا Capability؟ |
| Goal/hypothesis | به چه هدف یا فرضیهای وصل است؟ |
| Threshold | کدام معیار از پیش تعیینشده پاس شد؟ |
| Evidence/link | شاهد کجاست و سطح آن چیست؟ |
| Contributors | Direct، enabling و dependency چه کسانیاند؟ |
| Open risk | چه چیزی هنوز ثابت/بسته نشده؟ |
| Next | گام بعد، Owner و موعد چیست؟ |
| Audience/preference | Private، team یا public؟ |
| Expiry/roll-up | چه وقت بازبینی و به کدام Outcome جمع میشود؟ |
از Candidate تا Verified Win
- Propose: هر عضو تیم Candidate را با Win Card کوتاه ثبت میکند.
- Verify: صاحب Outcome یا reviewer مستقل Threshold و Evidence را میسنجد.
- Classify: نوع برد، سطح Evidence و Risk باز برچسب میخورد.
- Credit: contributorهای مستقیم، enabling و dependency تأیید میشوند.
- Acknowledge: پیام با کانال و مقیاس متناسب ارسال میشود.
- Aggregate: برد به Outcome/فرضیه Portfolio وصل میشود.
- Graduate یا retire: با Evidence بیشتر ارتقا مییابد یا اگر نتیجه نپایید، annotation میگیرد.
سه سطح تصمیم و Separation of Duties
| سطح | نمونه | تأیید مناسب |
|---|---|---|
| Low risk | یادگیری تیمی یا رفع dependency کوچک | Peer/manager lightweight |
| Medium risk | ادعای کیفیت، مشتری یا صرفهجویی | Outcome owner/data owner |
| High risk | امنیت، مالی، ایمنی، انطباق، Public claim | مالک کنترل/بررسی تخصصی |
صاحب کار میتواند Candidate پیشنهاد کند، اما در ادعاهای پرریسک نباید تنها verifier باشد. این قاعده بیاعتمادی به فرد نیست؛ حفاظت از اعتبار برد است.
Premature Victory چگونه ساخته میشود؟
| الگو | علامت | Guardrail |
|---|---|---|
| Output = Outcome | Launch را Success نهایی مینامیم | Adoption/outcome window |
| Marker overload | برای هر گام جشن مستقل | Digest و aggregation |
| Goal detachment | تعداد برد بالا، هدف راکد | Portfolio roll-up |
| Risk erasure | پیام فقط بخش سبز را میگوید | Open-risk line |
| Irreversible claim | خبر عمومی پیش از validation | Evidence gate/approval |
| Reward lock-in | Threshold برای گرفتن جایزه پایین میآید | Rule version/audit sample |
قالب پیام ضد پیروزی زودرس
قالب پیشنهادی: Context → Verified change → Evidence → Contribution → Meaning → Open risk → Next.
«در پایلوت مرجوعی تهران، تیم عملیات و محصول هشدار کسری موجودی را برای ۱۰٪ سفارشها فعال کرد. کنترل rollback و ۲۰ سناریوی بحرانی پاس شد؛ بنابراین یک Risk/Capability win داریم، نه اعلام موفقیت Rollout. ممنون از نرگس برای تحلیل، امیر برای مانیتورینگ و تیم انبار برای داده اصلاحی. ریسک Performance در بار پیک باز است؛ Owner آن سارا و بازبینی پنجشنبه است.»
این پیام هم برد را کوچک نمیکند و هم واقعیت باز را پنهان نمیسازد. عبارتهایی مثل «دیگر این مشکل را نداریم» فقط پس از Evidence متناسب مجازند.
Shared Credit و Dependency Map
برد کوچک معمولاً محصول یک لحظه نمایشی نیست. برای پروژه میانبخشی، نقشها را پیش از پیام ثبت کنید. راهنمای کاملتر در Contribution Credit پروژههای میانبخشی ۴۷۲ است.
| نقش | نمونه سهم | ریسک حذف |
|---|---|---|
| Direct | تحلیل، طراحی، اجرا | فقط Presenter دیده شود |
| Enabling | داده، دسترسی، تست، آموزش | کار پشتیبان نامرئی |
| Risk/quality | کشف defect یا Stop | فقط سرعت تشویق شود |
| Operational | پوشش شیفت و adoption | دفتر مرکزی Credit بگیرد |
| External | مشتری/تأمینکننده بازخورد داد | ادعای مالکیت کامل |
فهرست Credit باید قابل اصلاح باشد. جاافتادن نام، Incident اخلاقی ابدی نیست؛ Correction سریع، توضیح بیدفاع و ثبت نسخه اعتماد را بهتر حفظ میکند.
Cadence؛ هر برد مراسم نمیخواهد
| شدت/نوع | کانال | زمان | هزینه توجه |
|---|---|---|---|
| Micro acknowledgement | Private یا thread کاری | همان روز | کمتر از ۲ دقیقه |
| Team win | Stand-up/weekly digest | این هفته | ۳ تا ۵ دقیقه |
| Cross-team win | Review/demo | پس از verification | ۵ تا ۱۰ دقیقه |
| Portfolio milestone | ماهانه/فصلی | پس از roll-up | جلسه محدود |
| High-stakes outcome | رسانه گسترده | پس از gate تخصصی | طبق plan |
اگر تیم توزیعشده است، async digest همراه لینک Evidence از جلسه اجباری بهتر است. Quiet hours، زبان، دسترسی شیفت و ترجیح فرد را رعایت کنید.
Win Portfolio؛ بردهای پراکنده را به داستان نتیجه تبدیل کنید
| ستون Portfolio | نمونه |
|---|---|
| Outcome | کاهش لغو سفارش ناشی از کسری |
| Leading wins | علتها تأیید؛ هشدار پایلوت؛ runbook آزموده |
| Lagging evidence | نرخ لغو در window تعریفشده |
| Dependencies | کیفیت موجودی شعب/تأمینکننده |
| Open risks | پیک فروش و latency |
| Next bet | Rollout از ۱۰٪ به ۳۰٪ با stop threshold |
| Retired claims | فرضیه پیامک رد شد |
Portfolio با Strategy Map پیوند میخورد، نه با تعداد Kudos. برای جلوگیری از تشویق Proxy غلط، از راهنمای همراستاسازی قدردانی و اهداف ۳۰۳ استفاده کنید.
Aggregation Rule و ضد Fragmentation
- هر Win دقیقاً یک Outcome اصلی دارد؛ لینکهای فرعی میتوانند ثبت شوند اما double count نشوند.
- چند Task مشابه در یک digest به یک برد قابلیت/جریان جمع میشوند.
- Learning win جای Outcome win را نمیگیرد؛ هر دو Label مستقل دارند.
- Win منقضی یا برگشتخورده حذف نمیشود؛ با وضعیت retired/reversed و دلیل میماند.
- Outcome بدون بردهای پیشرو هم ثبت میشود تا تیم فقط کار قابلروایت را نبیند.
- تعداد Win KPI فرد یا مدیر نیست؛ Portfolio ابزار تصمیم است.
Reversible و Irreversible win
| ویژگی | Reversible | Irreversible/High-cost |
|---|---|---|
| نمونه | Experiment محدود | اعلام عمومی، تغییر Payroll، حذف داده |
| Evidence threshold | متناسب و سبک | بالاتر/مستقل |
| پیام | «یاد گرفتیم/پایلوت پاس شد» | ادعای محدود و approved |
| Fallback | Rollback روشن | Remedy/incident plan |
| جشن | سریع و کوچک | پس از Gate |
جشن بدون Reward و مرز هزینه
Recognition، Reward و Compensation سه تصمیم جدا هستند. پیام دقیق و فرصت Demo میتواند برای یک Small win کافی باشد. هدیه یا پرداخت فقط وقتی اضافه میشود که Policy، Equity، Budget، مالیات/حقوق و تعهدات محلی بررسی شده باشد.
| گزینه | مزیت | Guardrail |
|---|---|---|
| پیام خصوصی | کمهزینه و شخصی | مشخص و بدون وعده |
| Team digest | یادگیری مشترک | Consent و Credit کامل |
| Demo/Showcase | Evidence دیده میشود | فشار ارائه نساختن |
| زمان برای بهبود | Capability را پایدار میکند | بار به دیگران منتقل نشود |
| Reward مادی | ارزش اقتصادی | Policy/Payroll/Equity |
کار پرریسک، خطا و Stop-the-line
در امنیت، سلامت، عملیات حساس یا مالی، سرعت و «تمامکردن» نباید معیار اصلی Win باشد. توقف بهموقع، گزارش Near miss یا ردکردن Release ناایمن میتواند Risk win باشد؛ اما خود Incident یا خسارت جشن گرفته نمیشود.
پیام باید رفتار مسئولانه و اثر آن را ببیند، Accountability و اصلاح سیستم را باز نگه دارد و فرد گزارشدهنده را مجبور به Public exposure نکند.
Scenario ایران: تیم محصول فروشگاه آنلاین
مسئله و تعریف آستانه
تیم در تهران میخواهد لغو سفارش بهعلت اختلاف موجودی را کم کند. هدف نهایی «کاهش پایدار لغو» است. Small win اول نه ساخت Dashboard، بلکه تأیید سه علت اصلی با تطبیق سفارش، لاگ و تماس مشتری است. Threshold پیشاپیش: حداقل دو منبع داده، پوشش روز عادی و پیک و ثبت موارد خارج نمونه.
بردهای Portfolio
- Learning win: علت غالب برخلاف فرض اولیه، تأخیر Sync یک شعبه بود.
- Risk win: rollback هشدار موجودی در محیط staging و پایلوت پاس شد.
- Capability win: runbook پشتیبانی و alert مالکدار شد.
- Outcome candidate: لغو در پایلوت کمتر شد؛ هنوز window کامل نشده است.
پیام و گام بعد
در جلسه هفتگی فقط سه برد verified در یک Story پنجدقیقهای گفته میشود، نام عملیات شعبه و پشتیبانی کنار محصول میآید و ریسک پیک باز میماند. هیچکس برای شبکاری تحسین نمیشود؛ Coverage و Recovery جدا مدیریت میشود.
Scenario ایران: واحد مالی و بستن ماه
برد ظاهری و برد واقعی
«فایل تطبیق آماده شد» Output است. برد کوچک وقتی است که اختلافهای بالاتر از Threshold با source document بسته، reviewer مستقل امضا و موارد باز به exception ledger منتقل شوند. زود تمامکردن بدون کنترل، Win نیست.
Credit و Communication
کارشناس تهیهکننده، reviewer، IT که extract را اصلاح کرده و شعبهای که سند ناقص را تکمیل کرده در Credit map میآیند. چون داده مالی حساس است، پیام تیمی فقط نوع بهبود و سهمها را میگوید؛ عدد/نام مشتری منتشر نمیشود.
تیم دورکار و چندشیفته
- Candidate path فقط در جلسه زنده نباشد؛ فرم/Thread async و مسیر جایگزین داشته باشد.
- Digest در ساعت مناسب ارسال و جلسه ضبطشده تنها مسیر دسترسی نباشد.
- Visibility denominator را بر اساس شیفت، نقش و فرصت مشاهده بررسی کنید.
- Public بودن Default نباشد؛ ترجیح گیرنده و حساسیت Evidence تعیینکننده است.
- کار offline، رفع مانع، مستندسازی و پوشش شیفت را در Taxonomy نگه دارید.
Metric Tree؛ موفقیت برنامه را با تعداد جشن نسنجید
| لایه | Metric نمونه | خطر تفسیر |
|---|---|---|
| Coverage | Opportunity/verified win به تفکیک نقش و شیفت | Quota فردی نسازید |
| Quality | درصد Win با Evidence/goal/open risk | Form completion ≠ کیفیت |
| Integrity | Reversal، correction، exception | صفر بودن میتواند underreporting باشد |
| Portfolio | Outcome با leading wins و lagging evidence | Attribution قطعی نسازید |
| Experience | Preference fit و usefulness pulse | میانگین، اقلیت را پنهان میکند |
| Cost | زمان جلسه، admin و reward | هزینه فرصت را فراموش نکنید |
آزمون اثر بدون ادعای علت جعلی
قبل از Scale، یک Pilot محدود با baseline، cohort یا staggered rollout طراحی کنید. Outcome را از program activity جدا نگه دارید و همزمان تغییر مدیر، فصل فروش، محصول و بار کاری را ثبت کنید. برای طرح دقیقتر به راهنمای آزمون علّی قدردانی و نوآوری ۱۱۹ رجوع کنید.
اگر Outcome بهتر شد، بگویید «همزمان با Pilot تغییر مشاهده شد» مگر طراحی شواهد اجازه ادعای قویتر بدهد. اگر بهتر نشد، Win Register هنوز برای یادگیری مفید است؛ اما موفقیت Program را اعلام نکنید.
Stop Rule و Anti-gaming
| Trigger | اقدام فوری | بررسی |
|---|---|---|
| Win count بالا، Outcome راکد | توقف Scale | Threshold/proxy |
| Task splitting | Aggregation اجباری | Incentive/leaderboard |
| Credit concentration | Sample review | Opportunity/network bias |
| Reversal بالا | Evidence gate بالاتر | QA/verification |
| جشن مانع بیان ریسک | Private listening | Power/psychological safety |
| اضافهکاری در بردها | Reward/پیام متوقف | Capacity/root cause/recovery |
| داده حساس در پیام | Hide/correct | Access/consent/retention |
Governance و RACI سبک
| تصمیم | Accountable | Responsible/Consulted |
|---|---|---|
| Win definition | Outcome owner | Team + risk/quality |
| Evidence rule | Data/control owner | Analyst + practitioner |
| Credit correction | Team manager | Contributors/PM |
| Channel/consent | Recognition owner | Recipient/privacy |
| Reward | HR/Finance owner | Payroll/legal محلی |
| Stop/scale | Program sponsor | Outcome/risk/employee reps |
اگر سازمان Program رسمی ندارد، چارچوب اصلی برنامه قدردانی کارکنان ۶۲۷ Purpose، governance، reward و rollout را پوشش میدهد. این صفحه فقط Use case بردهای کوچک را عمیق میکند.
پایلوت ۳۰/۶۰/۹۰روزه
| بازه | کار | Gate |
|---|---|---|
| روز ۱–۳۰ | یک Outcome، Taxonomy، Threshold، baseline و ۱۰ Win Card گذشته را نمونهخوانی کنید | تعریف قابلتوافق و داده حداقلی |
| روز ۳۱–۶۰ | یک تیم/شیفت، weekly digest، correction path و Portfolio review | Credit/visibility gap و cost قابلقبول |
| روز ۶۱–۹۰ | Outcome review، reversal، interview و anti-gaming test | Scale، redesign یا stop مستند |
چکلیست پنجدقیقهای مدیر
- چه چیزی واقعاً تغییر کرد و چه چیزی فقط انجام شد؟
- Threshold قبل از دیدن نتیجه چه بود؟
- Evidence در چه سطحی است و چه ادعایی را مجاز نمیکند؟
- این برد به کدام Outcome، فرضیه یا ریسک وصل است؟
- چه dependency و contributorی ممکن است جا افتاده باشد؟
- آیا ایمنی، کیفیت یا Work boundary برای سرعت قربانی شده است؟
- گیرنده چه کانالی را ترجیح میدهد؟
- ریسک باز و گام بعد در پیام آمده است؟
- این رویداد مستقل است یا باید در digest تجمیع شود؟
- چه علامتی ما را وادار به توقف یا اصلاح میکند؟
نتیجهگیری
جشن موفقیتهای کوچک وقتی معتبر است که تیم از «خبر خوب» به «Evidence قابلتصمیم» برسد. Win Threshold جلوی تعریف سلیقهای را میگیرد، Win Card ادعا و Credit را روشن میکند و Portfolio نشان میدهد بردهای کوچک چگونه—یا آیا—به Outcome بزرگتر جمع میشوند.
نسخه ساده شروع این است: یک Outcome انتخاب کنید، سه نوع Win مجاز و Evidence حداقلی را بنویسید، یک digest هفتگی پنجدقیقهای بسازید و همیشه Open risk و Next را کنار پیام نگه دارید. اگر جشن از واقعیت جلو زد، توقف و اصلاح خود یک رفتار مسئولانه است.
سؤالات متداول
آیا تمام Taskهای تمامشده موفقیت کوچکاند؟
خیر. Task یک Activity یا Output است. وقتی Definition of done، Evidence و ارتباط آن با Outcome، کاهش ریسک یا یادگیری معتبر روشن باشد، میتواند Candidate یک Small win شود.
چگونه از جشن زودهنگام جلوگیری کنیم؟
Threshold را پیشاپیش تعیین کنید، نوع برد و سطح Evidence را در پیام بگویید و Open risk/Next را حذف نکنید. Launch یا marker میانی را موفقیت نهایی ننامید.
برای جشن موفقیتهای کوچک بودجه لازم است؟
نه. پیام دقیق، تشکر خصوصی، Demo یا digest تیمی میتواند کافی باشد. Reward مادی تصمیم جداگانهای است و به Policy، Equity، بودجه و بررسی Payroll/مالیاتی محلی نیاز دارد.
در تیم دورکار چه Cadenceی مناسب است؟
Candidateها را async ثبت کنید، بردهای کمریسک را در digest هفتگی جمع کنید و فقط milestoneهای Portfolio را به جلسه اختصاص دهید. Quiet hours، شیفت و ترجیح خصوصی/عمومی را رعایت کنید.
از کجا بفهمیم برنامه Small Wins به بازی با معیار تبدیل شده است؟
افزایش Win count همراه با Outcome راکد، Task splitting، تمرکز Credit، Reversal زیاد و پنهانشدن ریسک علامت هشدار است. Scale را متوقف و Threshold، incentive و verification را بازبینی کنید.
