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