در ادبیات رایج فناوری، رشد معمولاً با مقیاسپذیری (Scalability) سنجیده میشود. شرکتی موفقتر به نظر میرسد که بتواند کاربران بیشتری جذب کند، هزینه خدمترسانی به هر کاربر را کاهش دهد، بازارهای تازهای را فتح کند و با سرعت بیشتری محصول خود را توسعه دهد. این نگاه، بهویژه در اکوسیستم استارتاپی، آنقدر غالب شده که گاهی خودِ محصول نه بر اساس دوام و پایداری، بلکه بر اساس امکان رشد سریع و جذب سرمایه سنجیده میشود.
اما تجربه چند سال اخیر نشان داده است که رشد سریع، بهتنهایی، نشانه سلامت نیست. محصولی که در شرایط عادی خوب کار میکند، الزاماً در شرایط بحرانی زنده نمیماند. اختلال اینترنت، تغییر ناگهانی مقررات، شوک ارزی، کاهش قدرت خرید، بحران نقدینگی، مهاجرت نیروهای کلیدی، تحریم، محدودیت تأمین زیرساخت، تغییر رفتار کاربران یا حتی یک بحران اعتماد عمومی میتواند محصولی را که روی کاغذ مقیاسپذیر است، در عمل از کار بیندازد.
در نوشته قبلی درباره «مقیاسپذیری در برابر تابآوری»، بحث این بود که تمرکز بیش از حد بر Scale میتواند نقاط ضعف پنهانی ایجاد کند؛ نقاط ضعفی که در روزهای عادی دیده نمیشوند، اما در بحران آشکار میشوند [1]. در این نوشته میخواهم همان بحث را از سطح زیرساخت و شرکتهای بزرگ فناوری به سطح محصول بیاورم. پرسش اصلی این است: محصولی که در بازارهای پرریسک ساخته میشود، چگونه باید طراحی شود تا فقط رشد نکند، بلکه دوام بیاورد؟
به بیان دیگر، در بازارهای باثبات شاید بتوان محصول را با منطق Growth by Design ساخت؛ اما در بازارهایی مثل ایران، ترکیه، آرژانتین، نیجریه یا هر محیطی که با تورم، ابهام قانونی، محدودیت زیرساخت و شوکهای بیرونی مواجه است، باید به Survival by Design هم فکر کرد. تابآوری محصولی یعنی محصول از ابتدا برای روزهای سخت طراحی شده باشد، نه اینکه بعد از وقوع بحران با وصلههای اضطراری سرپا نگه داشته شود.
تابآوری محصولی (Product Resilience) را میتوان توانایی یک محصول برای ادامه خلق ارزش در شرایط اختلال تعریف کرد. این تعریف آگاهانه از واژه «ادامه خلق ارزش» استفاده میکند، نه صرفاً «ادامه فعالیت». چون محصول ممکن است از نظر فنی بالا باشد، صفحهها لود شوند و سرورها پاسخ دهند، اما در شرایط بحرانی دیگر ارزش اصلی خود را به کاربر نرساند.
برای مثال، یک اپلیکیشن مالی ممکن است هنگام جهش نرخ ارز همچنان باز شود، اما اگر موجودیها را با تأخیر نشان دهد، قیمتها را درست بهروزرسانی نکند، سقف تراکنشها را شفاف توضیح ندهد یا کاربر را در وضعیت تعلیق بگذارد، از نظر محصولی تابآور نیست. یک مارکتپلیس ممکن است در زمان اختلال لجستیک همچنان سفارش بگیرد، اما اگر زمان تحویل، امکان لغو، سیاست بازگشت پول و ارتباط با فروشنده نامشخص باشد، فقط بحران را از درون سیستم به کاربر منتقل کرده است.
تابآوری محصولی با تابآوری فنی همپوشانی دارد، اما یکی نیست. تابآوری فنی درباره uptime، redundancy، recovery time و تحمل خطای سیستم است. تابآوری محصولی درباره این است که کاربر در شرایط غیرعادی هنوز بتواند به هدف اصلی خود نزدیک شود. ممکن است بهترین پاسخ محصول در بحران، ارائه تجربه کامل نباشد؛ شاید باید تجربه محدودتر، صادقانهتر و قابل اعتمادتر ارائه دهد.
اینجا مفهوم graceful degradation اهمیت پیدا میکند؛ یعنی محصول در زمان اختلال به جای فروپاشی کامل، به شکل کنترلشده سادهتر شود. اگر اینترنت کند است، نسخه سبک بالا بیاید. اگر قیمت قطعی نیست، محصول به کاربر بگوید قیمت نیاز به تأیید دارد. اگر سرویس پرداخت ناپایدار است، سفارش در وضعیت رزرو موقت قرار گیرد. اگر پشتیبانی انسانی تحت فشار است، محصول شفاف بگوید زمان پاسخگویی بیشتر شده و مسیرهای اضطراری را جدا کند.
تابآوری محصولی یعنی کاربر در بحران احساس نکند محصول غیب شده، دروغ میگوید یا مسئولیت را به گردن او انداخته است.
بخش بزرگی از ادبیات محصول از محیطهایی آمده که در آنها فرضهای پایه نسبتاً پایدار است: اینترنت قابل اتکا است، پرداخت قابل پیشبینی است، نرخ ارز برای تصمیم روزمره کاربر مسئله اصلی نیست، مقررات معمولاً ناگهانی و مبهم تغییر نمیکند، دسترسی به سرویسهای ابری جهانی ممکن است، و کاربر میتواند انتظار داشته باشد حقوق مصرفکننده تا حدی از او حمایت کند.
در چنین محیطی، طبیعی است که تمرکز زیادی روی growth، activation، retention، funnel optimization و experimentation شکل بگیرد. این مفاهیم مهماند و در بازارهای پرریسک هم کاربرد دارند. اما اگر محصول فقط با همین زبان ساخته شود، بخشی از واقعیت را نمیبیند. چون در بازارهای پرریسک، اصطکاک فقط در قیف تبدیل نیست؛ اصطکاک در خود محیط وجود دارد.
کاربر ایرانی ممکن است امروز قدرت خریدی داشته باشد که ماه آینده ندارد. پذیرنده ممکن است به دلیل تغییر مقررات، ناگهان نتواند خدمت قبلی را ارائه کند. مسیر پرداخت ممکن است دچار اختلال شود. کانال ارتباطی ممکن است فیلتر شود. نیروی کلیدی محصول ممکن است مهاجرت کند. هزینه زیرساخت ممکن است با جهش ارز چند برابر شود. تصمیمی که در یک بازار پایدار یک optimization کوچک است، در این محیط میتواند مسئله بقا باشد.
به همین دلیل، Product Management در بازارهای پرریسک باید علاوه بر زبان رشد، زبان دوام را هم بلد باشد. مدیر محصول فقط نباید بپرسد «چگونه نرخ تبدیل را بهتر کنیم؟» باید بپرسد «اگر یکی از فرضهای پایه شکست، محصول چطور ادامه میدهد؟» فقط نباید بپرسد «چگونه کاربر را سریعتر به aha moment برسانیم؟» باید بپرسد «اگر کاربر مضطرب، بیاعتماد یا تحت فشار مالی بود، محصول چگونه با او حرف میزند؟»
در بازارهای باثبات، بحران معمولاً یک exception است. در بازارهای پرریسک، بحران بخشی از operating system بازار است.
مقیاسپذیری معمولاً با معیارهایی مثل رشد کاربر، کاهش هزینه واحد، افزایش تراکنش، افزایش GMV، افزایش دفعات استفاده و توسعه بازار سنجیده میشود. این معیارها همچنان مهماند. اما اگر فقط همینها را ببینیم، محصول را برای روزهای آفتابی طراحی میکنیم.
تابآوری محصولی به معیارهای دیگری هم نیاز دارد. برای مثال:
محصول در زمان اختلال چه درصدی از کارکرد اصلی خود را حفظ میکند؟
کاربر در بحران چقدر سریع میفهمد چه اتفاقی افتاده و چه کاری باید بکند؟
چند مسیر جایگزین برای پرداخت، ورود، اطلاعرسانی یا پشتیبانی وجود دارد؟
در زمان تغییر قیمت یا مقررات، محصول چقدر شفاف و قابل اعتماد رفتار میکند؟
تصمیمهای بحرانی تا چه حد قابل بازبینی و مستند هستند؟
اگر یک تیم، فروشنده، سرویس یا کانال کلیدی از دسترس خارج شود، محصول چقدر آسیب میبیند؟
این معیارها شاید به اندازه DAU یا Conversion Rate جذاب به نظر نرسند، اما در بازارهای پرریسک، تفاوت میان محصولی که فقط رشد میکند و محصولی که باقی میماند، همینجاست.
مشکل این است که تابآوری معمولاً وقتی دیده میشود که دیر شده است. مدیران و سرمایهگذاران در دوران رشد، هزینههای تابآوری را نوعی کندی یا محافظهکاری میبینند. تیم محصول هم ممکن است تحت فشار roadmap، feature delivery و KPIهای کوتاهمدت، طراحی برای سناریوهای بحرانی را عقب بیندازد. اما بحران منتظر تکمیل roadmap نمیماند.
وقتی از تابآوری حرف میزنیم، ذهن بسیاری از افراد بلافاصله به زیرساخت فنی میرود. اما بخش مهمی از تابآوری محصول در تجربه کاربری (User Experience) ساخته میشود. در بحران، کاربر بیش از هر چیز به وضوح، کنترل و صداقت نیاز دارد.
فرض کنید یک کاربر در میانه پرداخت با خطا مواجه میشود. تجربه عادی بسیاری از محصولات این است: خطای عمومی، پیام مبهم، نبودن وضعیت دقیق، و در نهایت ارجاع به پشتیبانی. این تجربه در شرایط عادی هم بد است، اما در بحران میتواند اعتماد کاربر را تخریب کند. محصول تابآور باید به کاربر بگوید پول کم شده یا نه، سفارش ثبت شده یا نه، چه زمانی وضعیت مشخص میشود، و کاربر چه گزینههایی دارد.
یا فرض کنید سرویس به دلیل اختلال اینترنت کند شده است. محصولی که فقط برای سرعت طراحی شده، ممکن است شکست بخورد. محصول تابآور میتواند نسخه سبکتر ارائه دهد، تصاویر غیرضروری را حذف کند، عملیات مهم را اولویت دهد، یا امکان ادامه کار در وضعیت نیمهآفلاین فراهم کند. در این حالت، هدف دیگر ارائه کاملترین تجربه نیست؛ هدف حفظ ارزش اصلی در بدترین شرایط است.
ارتباطات محصولی هم بخشی از UX است. در بحران، سکوت بدترین انتخاب است. کاربر وقتی نمیداند مشکل از اوست، از بانک است، از اینترنت است یا از محصول، اضطراب بیشتری تجربه میکند. یک پیام کوتاه و صادقانه که بگوید «در حال حاضر بخشی از سرویس پرداخت ناپایدار است، تراکنشهای ناموفق تا X ساعت آینده تعیین تکلیف میشوند» میتواند از دهها تماس پشتیبانی و موج بیاعتمادی جلوگیری کند.
به همین دلیل، طراحی پیامهای خطا، وضعیتهای میانی، حالتهای ناپایدار و ارتباطات بحرانی نباید به آخر کار موکول شود. اینها بخشی از خود محصولاند.
محصول فقط مجموعهای از صفحهها و APIها نیست. محصول، مدل کسبوکار هم هست. در بازارهای پرریسک، مدل کسبوکار اگر تابآور نباشد، تجربه محصول هم دیر یا زود آسیب میبیند.
یکی از مهمترین نقاط آسیب، قیمتگذاری است. در بازار تورمی، قیمت ثابت ممکن است برای کاربر قابل پیشبینی باشد، اما برای کسبوکار زیانساز شود. قیمت پویا ممکن است برای کسبوکار منطقی باشد، اما اگر بدون شفافیت اجرا شود، اعتماد کاربر را از بین ببرد. بنابراین محصول باید میان پیشبینیپذیری برای کاربر و انعطاف برای کسبوکار توازن برقرار کند.
برای مثال، در یک سرویس اشتراکی، افزایش ناگهانی قیمت میتواند ریزش شدید ایجاد کند. اما اگر محصول از قبل منطق افزایش قیمت، دوره اطلاعرسانی، گزینههای سبکتر و امکان pause کردن اشتراک را طراحی کرده باشد، شوک کمتری به کاربر وارد میشود. در یک مارکتپلیس، اگر قیمت کالاها نوسان دارد، محصول باید مشخص کند قیمت تا چه زمانی معتبر است، سفارش در چه شرایطی قابل لغو است و چه کسی مسئول اختلاف قیمت است.
تابآوری مالی هم مهم است. محصولاتی که فقط با فرض رشد مداوم ساخته شدهاند، در زمان کاهش سرمایهگذاری یا افت درآمد آسیبپذیر میشوند. اگر unit economics محصول از ابتدا مبهم باشد، بحران فقط این ابهام را آشکارتر میکند. تیم محصول باید بداند کدام قابلیتها واقعاً ارزش اقتصادی میسازند، کدام هزینهها با رشد کاربر خطی یا نمایی بالا میروند، و کدام بخشهای تجربه در زمان فشار مالی قابل سادهسازیاند بدون اینکه ارزش اصلی از بین برود.
در این معنا، تابآوری محصولی به معنای ساختن محصول کندتر یا کمجاهطلبتر نیست. به معنای ساختن محصولی است که رشدش خودش را نابود نکند.
بسیاری از محصولات در شرایط عادی دیجیتال به نظر میرسند، اما در بحران ناگهان معلوم میشود به عملیات انسانی سنگینی وابستهاند. پشتیبانی، تسویه، کنترل ریسک، رسیدگی به شکایات، تأیید مدارک، مدیریت فروشندگان و ارتباط با شرکای بیرونی بخشهایی هستند که اگر تابآور طراحی نشده باشند، تجربه کاربر را زمینگیر میکنند.
برای مثال، محصولی ممکن است ادعا کند فرایند بازگشت وجه خودکار دارد، اما در عمل هر مورد خاص نیازمند بررسی دستی باشد. در دوران عادی، این مسئله با چند نیروی پشتیبانی حل میشود. اما در بحران، تعداد درخواستها چند برابر میشود و صف رسیدگی از کنترل خارج میشود. کاربر هم تفاوت میان «سیستم فنی» و «تیم عملیات» را نمیبیند؛ برای او کل تجربه، همان محصول است.
تابآوری عملیاتی یعنی فرایندهای پشتصحنه برای فشار بالا، نیروی کمتر، خطای بیشتر و ابهام بیشتر آماده باشند. این آمادگی میتواند شامل دستهبندی خودکار درخواستها، مسیرهای اضطراری، اولویتبندی کاربران آسیبدیده، playbookهای پشتیبانی، داشبوردهای وضعیت، و اختیار تصمیمگیری روشن برای تیمهای خط مقدم باشد.
نکته مهم این است که عملیات تابآور فقط با ابزار ساخته نمیشود؛ با تصمیمگیری روشن ساخته میشود. تیم پشتیبانی باید بداند در بحران چه چیزی را میتواند خودش حل کند و چه چیزی نیاز به escalation دارد. تیم محصول باید از قبل بداند کدام تجربهها در بحران باید حفظ شوند و کدامها میتوانند موقتاً کاهش یابند. اگر همه چیز در لحظه بحران به تصمیم مدیران ارشد وابسته شود، محصول تابآور نیست.
گاهی درباره تابآوری محصول صحبت میکنیم، اما فراموش میکنیم محصول را تیم میسازد. در بازارهای پرریسک، تیمها هم تحت فشارند: خستگی، مهاجرت، تغییر اولویتهای سازمان، ابهام اقتصادی، کمبود نیرو، و فرسودگی ناشی از بحرانهای پیدرپی. محصولی که فقط در ذهن چند نفر کلیدی زندگی میکند، حتی اگر از نظر فنی خوب باشد، تابآور نیست.
تابآوری سازمانی در سطح محصول یعنی دانش، تصمیمها و منطقهای حیاتی محصول مستند و قابل انتقال باشند. اگر یک مدیر محصول، طراح، مهندس ارشد یا مدیر عملیات از تیم جدا شود، نباید فهم محصول با او از سازمان خارج شود. تصمیمهای مهم باید ردپا داشته باشند: چرا این قابلیت ساخته شد، چه فرضی پشت آن بود، چه KPIای داشت، چه چیزی باعث میشود متوقف یا تغییر کند.
این موضوع در بازارهای پرریسک اهمیت بیشتری دارد، چون turnover و جابهجایی نیروی انسانی بالاتر است و امکان جایگزینی سریع همیشه وجود ندارد. تیمی که فقط با حافظه شفاهی کار میکند، در بحران آسیبپذیر است. مستندسازی، ritualهای تصمیمگیری، postmortemهای واقعی و شفافیت در اولویتها شاید در نگاه اول کندکننده به نظر برسند، اما در بلندمدت سرعت تصمیمگیری را بالا میبرند.
از سوی دیگر، سازمان تابآور باید بداند چه زمانی نباید بسازد. در فرهنگ رشد، ساختن قابلیت جدید همیشه جذاب است. اما در بحران، گاهی بهترین تصمیم محصولی حذف، سادهسازی یا توقف است. محصولی که نمیتواند از قابلیتهای کمارزش خود دل بکند، منابع لازم برای حفظ ارزش اصلی را از دست میدهد.
یکی از ابزارهای عملی برای ساخت تابآوری محصولی، طراحی حالتهای بحرانی (Crisis Modes) است. همانطور که محصول برای حالتهای عادی user journey طراحی میکند، باید برای سناریوهای اختلال هم journey داشته باشد.
برای مثال:
حالت اینترنت کند یا ناپایدار.
حالت اختلال پرداخت.
حالت افزایش ناگهانی قیمت یا کمبود موجودی.
حالت فشار شدید روی پشتیبانی.
حالت تغییر مقررات یا توقف موقت یک خدمت.
حالت کاهش نقدینگی یا محدودیت تسویه.
حالت از دسترس خارج شدن یک شریک کلیدی.
برای هر حالت، تیم محصول باید چند پرسش روشن داشته باشد: کاربر چه چیزی میبیند؟ چه کاری هنوز میتواند انجام دهد؟ چه چیزی موقتاً غیرفعال میشود؟ چه پیامی دریافت میکند؟ چه SLAای وعده داده میشود؟ چه کسی در سازمان مالک تصمیم است؟ دادههای این وضعیت کجا ثبت میشود؟ چگونه بعداً اثر بحران تحلیل میشود؟
این نوع طراحی شاید شبیه کارهای غیرضروری به نظر برسد، تا زمانی که اولین بحران واقعی رخ دهد. آنوقت تیمی که از قبل سناریو داشته، سریعتر، منسجمتر و صادقانهتر عمل میکند. تیمی که سناریو ندارد، همزمان باید بفهمد چه شده، تصمیم بگیرد چه بگوید، محصول را تغییر دهد، پشتیبانی را هماهنگ کند و فشار مدیران و کاربران را پاسخ دهد.
در بازارهای پرریسک، crisis mode نباید سندی خاکخورده باشد. باید بخشی از تفکر محصول باشد.
تابآوری محصولی در نهایت به اعتماد کاربر برمیگردد. کاربر محصول را فقط در روزهای عادی قضاوت نمیکند. اتفاقاً لحظههای بحرانی، قویترین حافظه احساسی را میسازند. کاربری که در زمان مشکل، پاسخ شفاف گرفته، پولش تعیین تکلیف شده، مسیر اعتراض داشته و احساس نکرده تنها رها شده است، حتی اگر تجربه کامل نبوده باشد، ممکن است اعتماد بیشتری پیدا کند.
در مقابل، محصولی که در بحران پنهان میشود، پیام مبهم میدهد، مسئولیت را بین بانک، پذیرنده، اینترنت، کاربر و پشتیبانی پاس میدهد، بخشی از سرمایه اعتماد خود را از دست میدهد. این سرمایه بهسادگی برنمیگردد.
در بازارهایی که سطح بیاعتمادی عمومی بالاتر است، این مسئله شدیدتر میشود. کاربر از قبل انتظار دارد چیزی اشتباه پیش برود. بنابراین محصول باید بیش از یک محصول در بازار باثبات برای شفافیت و کنترل تلاش کند. ممکن است لازم باشد وضعیت سفارش با جزئیات بیشتری نمایش داده شود، قوانین مرجوعی سادهتر نوشته شود، تاریخچه تغییرات قیمت قابل مشاهده باشد، یا کانالهای پشتیبانی چندگانه طراحی شود.
اعتماد در چنین محیطی با شعار ساخته نمیشود. با رفتار تکرارشونده در لحظههای سخت ساخته میشود.
فرض کنیم یک محصول مالی به کاربران کمک میکند هزینههای ماهانه خود را مدیریت کنند. در شرایط عادی، ارزش محصول روشن است: دستهبندی هزینهها، بودجهبندی، گزارش مصرف، یادآوری پرداختها و شاید پیشنهاد برای صرفهجویی.
اما در زمان شوک ارزی، نیاز کاربر تغییر میکند. او دیگر فقط نمیخواهد بداند ماه گذشته چقدر خرج کرده است. میخواهد بفهمد کدام هزینهها در حال جهشاند، کدام اشتراکها دیگر ارزش ندارند، کدام پرداختها باید جلو بیفتند، کدام خریدها بهتر است عقب بیفتند، و بودجه ماهانه با فرض قیمتهای جدید چه شکلی میشود.
اگر محصول برای شرایط عادی طراحی شده باشد، شاید همان نمودارهای قبلی را نشان دهد. اما محصول تابآور میتواند وارد حالت بحران شود: دستهبندی هزینههای حساس به ارز، هشدار افزایش غیرعادی، پیشنهاد سناریوهای بودجه، امکان pause کردن برخی پرداختهای تکراری، و توضیح روشن درباره تغییر فرضهای محاسباتی.
در این مثال، تابآوری به معنای uptime بیشتر نیست. به معنای بازتعریف ارزش محصول متناسب با اضطراب واقعی کاربر است. محصولی که این کار را انجام دهد، در بحران به ابزار بقا تبدیل میشود، نه فقط ابزار گزارشگیری.
مقیاسپذیری همچنان مهم است. هیچ محصول دیجیتال جدی نمیتواند نسبت به رشد، هزینه واحد، کارایی زیرساخت و توسعه بازار بیتفاوت باشد. اما در بازارهای پرریسک، مقیاسپذیری بدون تابآوری میتواند خطرناک باشد. محصولی که سریع رشد میکند اما برای اختلال، ابهام، شوک اقتصادی و بیاعتمادی طراحی نشده، در اولین بحران جدی هزینه رشد خود را پرداخت میکند.
تابآوری محصولی یعنی از ابتدا بپذیریم که شرایط عادی، تنها حالت ممکن نیست. کاربر همیشه آرام، ثروتمند، متصل، مطمئن و دارای انتخابهای فراوان نیست. بازار همیشه پایدار نیست. زیرساخت همیشه در دسترس نیست. تیم همیشه کامل نیست. شریک تجاری همیشه قابل اتکا نیست. قانون همیشه روشن نیست. محصولی که این واقعیتها را نادیده بگیرد، شاید در نمودارهای رشد خوب به نظر برسد، اما در عمل شکننده است.
بنابراین، پرسش محصولی در بازارهای پرریسک نباید فقط این باشد که «چگونه رشد کنیم؟» باید بپرسیم «چگونه رشد کنیم بدون اینکه شکنندهتر شویم؟» باید بدانیم اگر یک فرض پایه شکست، چه چیزی از محصول باقی میماند. باید ارزش اصلی را از تزئینات جدا کنیم. باید مسیرهای جایگزین بسازیم. باید پیامهای بحران را از قبل طراحی کنیم. باید مدل کسبوکار را برای شوکها بسنجیم. باید تصمیمها را مستند کنیم. باید به کاربر کنترل و توضیح بدهیم.
در یک جمله، اگر Scale هنر بزرگ شدن است، Resilience هنر باقی ماندن است. و در بازارهای پرریسک، محصولی که باقی نمیماند، حتی اگر مدتی سریع رشد کند، محصول موفقی نیست.
[1] نوشته قبلی: «مقیاسپذیری در برابر تابآوری»
[2] Ben Thompson — Aggregation Theory and related strategy writing: https://stratechery.com/
[3] AWS Well-Architected Framework — Reliability Pillar: https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/
[4] Google SRE Book — Practical Alerting and Reliability: https://sre.google/sre-book/table-of-contents/
[5] NIST — Cybersecurity and Resilience resources: https://www.nist.gov/cybersecurity
[6] Netflix Tech Blog — Chaos Engineering and resilience practices: https://netflixtechblog.com/
