برنامهریزی سهماهه، آیینِ روزگارِ کمبود
هوش مصنوعیخلاصهٔ کاملتر
مایکل مایرنیک تو این مقاله میگه بیشتر تیمهایی که باهاشون حرف میزنه، دقیقاً مثل پنج سال پیش هدفگذاری میکنن: فیچر X رو بساز، تا تاریخ Z به متریک Y برس. به گفتهٔ اون کل این مراسم — OKR، مالکیت، تعهد سهماهه، چونهزنی سر رودمپ — برای دنیایی طراحی شده بود که شیپکردن گرون بود؛ با دقت برنامه میریختی چون ساختن کند بود و حق اشتباه نداشتی.
نویسنده معتقده اون فرض دیگه برقرار نیست: یه تیم کوچیک با ورکفلوی ایجنتی خوب، یه فیچر رو تو چند روز میده بیرون. مشکل هم فقط ناکارآمدی نیست؛ خود آیین برنامهریزی «محتاطبودن» رو بهعنوان فضیلت یاد میده — از رودمپ محافظت کن، اسپرینت رو هدر نده، قبل از ساختن هر فیچر توجیهش کن. نتیجهش اینه که برای یه فصل نقشه میکشی درحالیکه بازی به مقیاس چند روز رفته.
به گفتهٔ اون چیزی که الان واقعاً کمیابه، دونستن اینکه چی باید ساخت و آیا کار کرد ـه: شناخت مشتری، بازار و کدبیس، اونقدر که بتونی مدام شیپ کنی و یاد بگیری. پس هدف جالب دیگه «فیچر X رو بساز» نیست، بلکه اینه که «سیستمی بساز که بفهمه چی باید ساخته بشه، اعتبارسنجی کنه که جواب داده، و خودش یاد بگیره و شیپ کنه».
مثالهایی که میزنه همین تفاوت رو نشون میده: هدف قدیمی «تا آخر Q3 سیستم اندازهگیری و آزمایش رو بساز»، هدف جدید «ورکفلوی توسعهای بساز که ساختن اون سیستم — یا هر چیز دیگهای — بهجای ماهها، هفتهها طول بکشه و هر پروژه پروژهٔ بعدی رو سریعتر کنه». کار این فصل تو هر دو نسخه یکیه؛ فرق تو چیزیه که موقع تنگی از اون محافظت میکنی و چیزی که اندازه میگیری.
نویسنده تجربهٔ تیم خودش تو BotBot رو تعریف میکنه: پیشنویس اول برنامهٔ نیمهٔ دوم همون مراسم آشنا بود، ولی دیدن سختی کار دیگه شیپکردن نیست. پایپلاین اسپکی که فصل قبل ساخته بودن، از هر اسپکی که تولید کرد مهمتر شد. برای همین هدف بالادستی خودِ سیستم شد، با عددهای مشخص: فیچر اول خط پایه رو میذاره، فیچر سوم باید ۳۰٪ سریعتر باشه و تا ماه ششم هدف ۵۰٪ ـه.
خطرش رو هم میبینه: «داریم سیستم میسازیم» راحت تبدیل میشه به بهانهای برای پاسخگو نبودن. راهحلش نگهداشتن هر دو تاست — هدف سیستمی بالا، تعهدهای تحویل مشخص زیرش؛ اگه مرکبشدن سرعت تو عدد چرخهٔ واقعی دیده نشه، یعنی فلسفه جواب نداده.
در عمل سه چیز عوض میشه: اول، موقع تنگیِ اسکوپ بهجای زدنِ کارهای «متا»، باید حلقهٔ یادگیری و پایپلاین وریفیکیشن رو حفظ کرد و اسکوپ فیچر رو عقب انداخت — فیچر خروجی یه فصله، سیستم خروجی همهٔ فصلهاست. دوم، متریکها میرن سراغ شاخصهای پیشرو: زمان چرخه از ایده تا نتیجهٔ اعتبارسنجیشده، درصد وریفیکیشن خودکار، و سرعت بهرهور شدن یه عضو یا ایجنت جدید. سوم، ژست کلی تیم از احتیاط به آزمایش و تکرار سریع تغییر میکنه.
نویسنده جواب نقد رایج («این یعنی بهجای محصول، زیرساخت میسازی») رو هم میده: تلهٔ قدیمیِ زیرساخت دربارهٔ ساختن انتزاعهایی بود که کسی ازشون استفاده نمیکرد، ولی اینجا داری سیستمی رو میسازی که هر روز از توش کار میکنی و اگه کار فردا رو سریعتر نکنه، شکست خورده. به گفتهٔ اون ریسک واقعی برعکسه: هر فصلی که تو محتاطانه از رودمپ محافظت میکنی، یکی دیگه داره مدام شیپ میکنه و یاد میگیره.
نکات کلیدی:
- مراسم برنامهریزی سهماهه برای دورانی ساخته شده بود که شیپکردن گرون و کند بود؛ اون فرض دیگه درست نیست
- کمیابِ امروز، فهمیدن «چی بسازیم و آیا جواب داد» ـه، نه توان ساختن
- هدف بالادستی رو خودِ سیستم یادگیری و تحویل بذار، ولی با عدد تحویلِ مشخص زیرش تا بهانهٔ فرار از پاسخگویی نشه
- موقع تنگی اسکوپ، حلقهٔ یادگیری و وریفیکیشن رو حفظ کن و فیچر رو عقب بنداز
- شاخصهای پیشرو (زمان چرخه، درصد وریفیکیشن خودکار) مهمتر از تعداد فیچر شیپشدهست
