گاهی محصول در نقطهای قرار میگیره که اگر فیچر جدید منتشر نکنه، به نظر میرسه محصول عقب رفته؛
در حالی که اگر منتشر کنه، ممکنه اصلاً امکان ادامه مسیرش رو از دست بده. مدیریت این تضاد، یکی از سختترین وضعیتهای مدیریت محصوله. چون در نگاه اول، رشد با «اضافه شدن» قابلیتها و خروجیها شناخته میشه. اما گاهی مسئله اصلاً توسعه نیست؛ مسئله اینه که سیستم توان تحمل تغییر رو داره یا نه.
هر محصول یک نقطه پنهان داره؛ نقطهای که فشار برای حرکت، از ظرفیت واقعی سیستم جلو میزنه. از بیرون همهچیز هنوز شبیه یک سیستم فعال و در حال کاره، اما درونش ممکنه منابع، تمرکز یا زیرساخت در وضعیتی باشن که هر تغییر جدید به جای کمک، تبدیل به بار اضافه بشه. در چنین اوضاعی، تصمیم درست درباره این نیست که «چه چیزی ساخته بشه». بلکه درباره اینه که «چه چیزی نباید ساخته بشه»؛ و مهمتر اینکه آیا اضافه شدن یک قابلیت یا فیچر واقعاً سیستم رو جلو میبره یا فقط پیچیدگی به ماجرا اضافه میکنه.
یک مثال واقعی از محصول خودمون اینجا میتونه کمککننده باشه. در یک مقطع، فشار مالی بالا رفته بود، منابع محدود شده بودن و همزمان زیرساخت و اینترنت هم ناپایدارتر شده بود. تصمیم این بود که توسعه محصول متوقف بشه. ما عملا وارد فاز فریز محصول شده بودیم و قرار بود تمام منابع باقیمونده صرف یک هدف بشه: زنده نگه داشتن سیستم. این تصمیم شاید از بیرون شبیه «رشد نکردن» به نظر بیاد، اما اشتباه نبود. چون هر محصول در هر مقطع، مسئله متفاوتی داره. گاهی مسئله رشد کردنه، گاهی کشف مشکل واقعی کاربره، گاهی فروشه و گاهی فقط دوام آوردنه. هیچ کدوم از این مسائل مشکلی ایجاد نمیکنن. اشتباه از جایی شروع میشه که همه این وضعیتها با یک معیار سنجیده میشن.
در خیلی از تیمها، موفقیت مدیر محصول بهمرور با تعداد فیچرهای منتشرشده تعریف میشه. انگار اگر چیزی بیرون نیاد، محصول جلو نرفته. در حالی که همیشه اینطور نیست. یک محصول میتونه ماهها فیچر جدید نده، اما همچنان تصمیمهای درست بگیره. اتفاق خطرناکتر وقتی رخ میده که مدیر محصول، بدون درک وضعیت واقعی سیستم، محصول رو وارد فاز توسعه کنه درحالیکه زیرساخت تحملش رو نداره. وقتی منابع فنی فقط برای پایداری کنار گذاشته شدن، حتی یک قابلیت ساده هم میتونه به جای پیشرفت، فشار مضاعف ایجاد کنه.
از بیرون با این تصویر مواجه میشیم که فیچر منتشر میشه، جلسهها بیشتر میشن، تسکها در جریانن و نمودار فعالیت بالا میره. اما این تصویر لزوماً نشانهی سلامت سیستم نیست. اون هم در شرایطی که زیرساخت هم قابل اتکا نباشه، اینترنت ناپایدار باشه، رفتار کاربر تغییر کنه، خطاهای جدید ظاهر شن و حتی فرضهای پایه محصول زیر سؤال برن. در چنین فضایی، یک تغییر کوچک هم میتونه اثرات زنجیرهای بسازه؛ نه فقط روی تجربه کاربر، بلکه روی کل پایداری سیستم.
خبر بدی که وجود داره اینه: این نوع ریسک معمولاً دیر دیده میشه. چون سیستم هنوز از هم نپاشیده؛ هنوز کاربر هست، هنوز سرویس کار میکنه. و همین «هنوزها» فشار برای حرکت بیشتر ایجاد میکنن، نه کمتر. اینجاست که نقش واقعی مدیریت محصول خودش رو نشون میده.
مدیریت محصول فقط ساختن فیچر نیست. بخش مهمترش اینه که بتونی تشخیص بدی: الان مهمترین کاری که نباید انجام بدیم چیه؟ و گاهی پاسخ این سؤال، نه سرعت بیشتره، نه خروجی بیشتر؛ بلکه توقف آگاهانهست. حتی وقتی بیرون از سیستم، همه چیز خلافش رو فریاد میزنه. اینجا مفهوم کمحرکتی آگاهانه شکل میگیره؛ توانایی دفاع از تصمیم انجام ندادن، وقتی اضافه کردن هر چیز جدید میتونه هزینهای بزرگتر از فایدهاش داشته باشه. این نوع تصمیمگیری ضد رشد نیست؛ اتفاقاً یکی از بالغترین شکلهای مدیریت محصوله. چون به جای خروجی کوتاهمدت، از ظرفیت تصمیمگیری سیستم محافظت میکنه. این تصمیم اگر درست روایت بشه، خودش یک دستاورد محسوب میشه و مدیر محصول باید بتونه تعریف موفقیت رو برای ذینفعان عوض کنه و بهجای اینکه در ارائههای خودش بگه «چی ساختیم؟» باید بگه «از فروپاشی چه چیزی جلوگیری کردیم؟»
این یعنی جابهجایی KPIها از خروجی به سمت پایداری. اگر بخوایم این تغییر زاویه نگاه رو در عمل ببینیم، باید معیارهای موفقیت رو هم عوض کنیم. نه در سطح شعار، بلکه در سطح عدد و رفتار سیستم. در این نگاه، KPIها دیگه فقط عدد نیستن؛ تبدیل میشن به سیگنالهایی که میگن سیستم در چه وضعیه و آیا اصلاً اجازه ادامه دادن داریم یا نه. اگر بخوایم این رو به اجرا ترجمه کنیم، هر دسته از این سیگنالها یک سؤال مرکزی جلوی ما میذاره:
پایداری سیستم: اینجا سؤال این نیست که چقدر خروجی داریم؛ سؤال اینه که آیا سیستم اساساً قابل اتکاست یا نه و برای رصد، این موارد بررسی میشن:
درصد در دسترس بودن سرویس
تعداد اختلالهای بحرانی
میانگین زمان بین خرابیها (MTBF)
میانگین زمان رفع خرابی (MTTR)
سلامت خطاها: اینجا به جای رشد، داریم گوش میدیم به اینکه سیستم کجاها داره از کنترل خارج میشه و در این زمینهها دادهها کمک میکنن:
نرخ خطا در درخواستها
خطاهای تکرارشونده
خطاهای سمت کاربر
نرخ شکست عملیاتهای کلیدی
تابآوری سیستم: سؤال اصلی اینه: وقتی فشار وارد میشه، سیستم فقط میشکنه یا میتونه برگرده. در این زمینه میتونیم شاخصهای زیر رو داشته باشیم:
زمان بازگشت به وضعیت پایدار بعد از اختلال
میزان موفقیت در failover / fallback
تحمل سیستم در شرایط ناپایدار
درصد بازیابی بدون مداخله انسانی
سلامت انتشار: اینجا انتشار دیگه نشونه رشد نیست؛ تبدیل میشه به آزمون پایداری سیستم. برای رصد این موضوع این موارد مهم هستن:
نرخ انتشار بدون خطای بحرانی
تعداد rollback یا بازگشت از انتشار
تعداد hotfixهای اضطراری
زمان شناسایی تا رفع مشکل بعد از انتشار
فشار عملیاتی: این دسته نشون میده تیم واقعاً در چه سطحی از تنش کار میکنه، نه اینکه فقط چقدر کار انجام میده. برای این موضوع این موارد رو رصد میکنیم:
تعداد رخدادهای پشتیبانی
درخواستهای فوری و اضطراری
escalations به تیم فنی
زمان پاسخگویی به مسائل بحرانی
ثبات تجربه کاربر: اینجا داریم اثر واقعی تصمیمها رو روی رفتار کاربر میبینیم، نه روی خروجی تیم! برای رسیدن به این هدف باید این موارد بررسی بشن:
نوسان در نرخ استفاده
نرخ ریزش ناشی از خطا
ثبات در تکمیل مسیرهای اصلی کاربر
تغییرات ناگهانی در رفتار کاربران
سلامت تیم در شرایط بقا: این بخش مهمترین بخشه و اگر آسیب ببینه، بقیه KPIها معنی خودشون رو از دست میدن و موارد زیر میتونن نکات زیادی رو بهمون نشون بدن:
حجم کار خارج از برنامه
نشانههای فرسودگی تیم
نسبت کار واکنشی به کار برنامهریزیشده
ظرفیت باقیمانده برای کار توسعهای واقعی
گاهی بهترین تصمیم، نساختن یک فیچره، گاهی بهترین تصمیم، کند کردن ریتم تغییره و گاهی موفقیت یعنی اینکه در یک سیستم شکننده، ریسک تازهای وارد نکنی. چون همه حرکتها نشونه پیشرفت نیستن. بعضی حرکتها فقط دیرتر نشون میدن که تعادل از قبل بههم خورده بوده.
