بیشتر بنیانگذارانی که با آنها کار کردهام، وقتی روی یک آپدیت بزرگ ماهها کار میکنند، بهطور طبیعی میخواهند آن را با صدای بلند و برای همه کاربران همزمان معرفی کنند. این خواسته کاملاً قابلدرک است؛ بعد از هفتهها کدنویسی، تست و جلسات طراحی، دلتان میخواهد نتیجه کار را یکجا ببینید و واکنش بازار را دریافت کنید. اما دقیقاً همین انگیزه، یکی از رایجترین دلایلی است که آپدیتهای بزرگ محصول را به فاجعه تبدیل میکند. الگویی که بارها در پروژههای مختلف دیدهام این است: تیمی با انرژی بالا آپدیتی را برای صد درصد کاربران همزمان باز میکند، و در عرض چند ساعت با انبوهی از باگهای پیشبینینشده، شکایت کاربران قدیمی و افت ناگهانی معیارهای کلیدی روبهرو میشود.
چند ماه پیش، یک بنیانگذار حوزه فینتک برایم تعریف کرد که تیمش شش ماه روی بازطراحی کامل داشبورد کار کرده بود. صبح روز لانچ، آپدیت را برای همه دوازده هزار کاربر فعال همزمان باز کردند، بدون هیچ مرحله میانی. تا ظهر همان روز، نرخ churn روزانه سه برابر معمول شده بود و صندوق پشتیبانی پر از پیامهای گیج و عصبانی کاربرانی بود که دیگر جای دکمههای آشنا را پیدا نمیکردند. تیم مجبور شد ظرف دو روز بخشی از تغییرات را rollback کند؛ اتفاقی که اگر لانچ مرحلهای انجام میشد، به این شکل هیچوقت رخ نمیداد.
این تجربه تنها یکی از دهها نمونه مشابهی است که در اکوسیستم استارتاپی دیدهام. مشکل اصلی، خودِ آپدیت نبود؛ مشکل روش لانچ آن بود. در ادامه این مقاله دقیق بررسی میکنیم چرا لانچ یکباره آپدیتهای بزرگ ریسک واقعی محصول شما را بالا میبرد، لانچ مرحلهای دقیقاً چطور کار میکند و چه گامهای عملی باید بردارید تا آپدیت بعدی محصولتان، بهجای فاجعه، یک داستان موفقیت شود.
چرا لانچ یکباره آپدیتهای بزرگ خطرناک است
وقتی آپدیتی را همزمان برای همه کاربران باز میکنید، در واقع دارید یک آزمایش بزرگ و برگشتناپذیر را روی کل پایگاه کاربری خود اجرا میکنید. هرچقدر هم که تیم QA شما دقیق باشد، محیط تست هرگز نمیتواند تنوع واقعی دستگاهها، شبکهها، عادتهای کاربری و سناریوهای لبهای (edge case) را که در دنیای واقعی وجود دارد، کامل شبیهسازی کند. نتیجه این است که مشکلاتی که در تست داخلی هرگز دیده نشدهاند، دقیقاً همان روزی که بیشترین تعداد کاربر در حال استفاده از محصول شماست، خودشان را نشان میدهند. وقتی این اتفاق برای صد درصد کاربران همزمان بیفتد، دیگر راه عقبنشینی آرام و کنترلشدهای ندارید؛ باید در حالت بحران تصمیم بگیرید، همان جایی که بیشترین اشتباهات مهندسی و ارتباطی رخ میدهد.
بعد بُعد فنی، یک بُعد رفتاری هم وجود دارد که اغلب دست کم گرفته میشود. کاربران قدیمی به رابط کاربری، جریان کار و حتی محل قرارگیری دکمهها عادت کردهاند؛ وقتی همهچیز یکشبه تغییر میکند، حتی اگر نسخه جدید عینی بهتر باشد، مغز کاربر آن را بهعنوان یک اختلال درک میکند. در همان پروژه فینتکی که پیشتر گفتم، تحلیل دادهها بعداً نشان داد که بیشتر شکایتها نه درباره باگ واقعی، بلکه درباره «گمشدن» کاربران در چیدمان جدید بود. اگر همان آپدیت را برای پنج درصد کاربران باز کرده بودند، این الگوی رفتاری را زودتر و با هزینه بسیار کمتر کشف میکردند، پیش از آنکه به کل پایگاه کاربری آسیب برساند.
لانچ مرحلهای دقیقاً چیست
لانچ مرحلهای یا staged rollout به این معناست که آپدیت جدید را نه برای همه، بلکه ابتدا برای درصد کوچکی از کاربران فعال میکنید و بهمرور، بر اساس داده و بازخورد واقعی، این درصد را افزایش میدهید تا در نهایت به صد درصد برسد. ابزار فنی این کار معمولاً feature flag است؛ یعنی قابلیتی که به شما اجازه میدهد بدون نیاز به دیپلوی مجدد کد، یک ویژگی را برای گروه مشخصی از کاربران روشن یا خاموش کنید. برخی تیمها از رویکرد مشابهی به نام canary release استفاده میکنند که در اصل از دنیای زیرساخت و DevOps آمده، اما همان منطق در سطح محصول هم کاملاً کاربردی است: ابتدا یک گروه کوچک را در معرض تغییر قرار میدهید تا اگر مشکلی هست، «قناری» زودتر آن را نشان دهد.
نکتهای که معمولاً از قلم میافتد این است که لانچ مرحلهای فقط یک ابزار فنی برای کاهش ریسک باگ نیست؛ یک ابزار یادگیری هم هست. وقتی آپدیت را برای هزار کاربر بهجای صد هزار کاربر باز میکنید، میتوانید مکالمه واقعی با آن هزار نفر داشته باشید، بازخورد کیفی جمع کنید و حتی مصاحبه کوتاه بگیرید. این سطح از توجه فردی وقتی همه کاربران همزمان درگیر میشوند، عملاً غیرممکن است. به همین دلیل تیمهایی که لانچ مرحلهای را جدی میگیرند، معمولاً نسخه نهایی محصولشان به مراتب پختهتر و منطبقتر با نیاز واقعی کاربر از آب درمیآید.
سه مرحله عملی برای لانچ ایمن آپدیت بزرگ
در عمل، لانچ مرحلهای را میتوان در سه گام اصلی خلاصه کرد؛ گامهایی که هم برای یک تیم دونفره و هم برای استارتاپی با چند ده کارمند قابل اجراست، فقط با مقیاس متفاوت.
مرحله اول: گروه کوچک و بازخورد واقعی
در این مرحله، آپدیت را فقط برای یک گروه کوچک و مشخص باز میکنید؛ معمولاً بین یک تا پنج درصد کاربران، یا یک گروه انتخابی از کاربرانی که پیشتر تمایل خود را برای تست ویژگیهای جدید اعلام کردهاند. هدف این مرحله پیدا کردن باگ نیست، هدف اصلی فهمیدن این است که آیا فرضیه محصولی شما اصلاً درست بوده یا نه. در یکی از پروژههایی که همراهیاش کردم، تیمی که میخواست سیستم قیمتگذاری محصولش را کاملاً بازطراحی کند، همین مرحله را برای دویست کاربر اجرا کرد و متوجه شد که فرض اصلیشان درباره رفتار خرید کاربران اشتباه بوده؛ چیزی که اگر مستقیم برای همه کاربران لانچ میشد، هزینه بازگشت از آن چند برابر میشد.
مرحله دوم: گسترش تدریجی و رصد داده
وقتی گروه اول نتایج قابلقبولی نشان داد، نوبت به گسترش تدریجی میرسد؛ معمولاً از پنج درصد به بیست درصد، سپس به پنجاه درصد و در نهایت صد درصد، با فاصله زمانی چند روزه بین هر مرحله. در هر مرحله باید معیارهای مشخصی را از قبل تعریف کرده باشید: نرخ خطا، زمان بارگذاری صفحه، نرخ تکمیل کار اصلی کاربر (task completion) و شاخصهای رضایت کاربر. اگر هرکدام از این معیارها در یک مرحله افت معناداری نشان دهد، گسترش را متوقف میکنید و مشکل را قبل از رفتن به مرحله بعد حل میکنید. این رویکرد اجازه میدهد بهجای واکنش هیجانی به یک بحران بزرگ، با آرامش و بر اساس داده تصمیم بگیرید.
مرحله سوم: انتشار عمومی و آمادهسازی تیم پشتیبانی
رسیدن به صد درصد کاربران نباید مرحله پایانی بیدقتی باشد؛ برعکس، همینجاست که آمادهسازی تیم پشتیبانی اهمیت پیدا میکند. تا این مرحله، شما داده کافی برای نوشتن یک سند پرسشهای متداول داخلی، آموزش تیم پشتیبانی روی سناریوهای واقعی مشکل و آماده کردن پیامهای درونبرنامهای برای معرفی تغییرات را دارید. تیمهایی که این مرحله را جدی میگیرند، معمولاً حجم تیکتهای پشتیبانی بعد از انتشار عمومی را تا حد قابلتوجهی پایینتر تجربه میکنند، چون بیشتر سؤالات کاربران را از قبل پیشبینی و پاسخ دادهاند.
چطور معیارهای موفقیت هر مرحله را از قبل تعریف کنیم
بزرگترین تفاوت بین تیمی که لانچ مرحلهای را با انضباط اجرا میکند و تیمی که فقط اسم آن را وام میگیرد، در یک چیز است: تعریف روشن معیار موفقیت پیش از شروع، نه در وسط راه. پیش از باز کردن اولین درصد کاربران، بنشینید و برای هر مرحله عدد مشخصی تعیین کنید؛ مثلاً «نرخ خطا نباید از دو درصد بیشتر شود» یا «امتیاز رضایت کاربر نباید بیش از نیم واحد افت کند». این اعداد باید قبل از دیدن هر داده واقعی نوشته شوند، چون بعد از دیدن داده، وسوسه توجیه کردن نتایج ضعیف بهشدت بالا میرود و تیمها ناخودآگاه معیار را خم میکنند تا با واقعیت جور دربیاید.
همراه با معیارهای کمّی، یک کانال ثابت برای جمعآوری بازخورد کیفی هم تعریف کنید؛ میتواند یک فرم کوتاه درونبرنامهای باشد، چند تماس تلفنی کوتاه با کاربران گروه اول، یا حتی یک کانال تلگرامی اختصاصی برای کاربران بتا. من همیشه به تیمها توصیه میکنم این دو نوع داده را در کنار هم و نه جدا از هم بررسی کنند؛ چون خیلی وقتها عدد خوب به نظر میرسد، اما داستان پشت آن عدد نگرانکننده است. تنها راه دیدن آن داستان، گوشدادن مستقیم به کاربر واقعی است، نه فقط نگاهکردن به یک نمودار در داشبورد آنالیتیکس.
اشتباهاتی که حتی در لانچ مرحلهای هم دیدهام
لانچ مرحلهای بهخودیخود ضمانت موفقیت نیست؛ چند اشتباه رایج میتواند حتی این رویکرد را بیاثر کند. رایجترین اشتباه، عجله در گسترش است: تیمی بعد از یک روز بدون شکایت جدی، بلافاصله از پنج درصد به صد درصد میپرد، در حالی که بسیاری از مشکلات رفتاری تنها بعد از چند روز استفاده مکرر خودشان را نشان میدهند. اشتباه دوم، تعریفنکردن معیار موفقیت پیش از شروع است؛ بدون معیار روشن، تیم نمیداند چه زمانی باید متوقف شود و چه زمانی باید ادامه دهد، و تصمیمها بر اساس حس شخصی گرفته میشود، نه داده.
اشتباه سوم، توجهنکردن به بازخورد کیفی است. بسیاری از تیمها فقط به داشبورد آنالیتیکس نگاه میکنند و پیامهای مستقیم کاربران، نظرات درونبرنامهای یا واکنشهای شبکههای اجتماعی را نادیده میگیرند؛ در حالی که خیلی از مشکلات مهم قبل از اینکه در عدد نمایان شوند، در متن یک پیام کاربر قابلشناساییاند. به یاد دارم تیمی که در مرحله بیستدرصدی، عدد churn طبیعی به نظر میرسید، اما وقتی پیامهای پشتیبانی را خواندند، متوجه شدند بخش بزرگی از کاربران قدیمی بهسادگی از ویژگی جدید استفاده نمیکنند و در سکوت به نسخه قبلی چسبیدهاند؛ سیگنالی که هیچ نموداری آن را نشان نمیداد.
چه زمانی لانچ یکباره واقعاً منطقی است
لانچ مرحلهای قانون مطلق نیست و برای هر تغییری لازم نیست. برای رفع باگهای امنیتی فوری، اصلاحات کوچک متنی یا تغییرات بصری جزئی که ریسک رفتاری پایینی دارند، معمولاً لانچ یکباره سریعتر و منطقیتر است؛ چون هزینه راهاندازی زیرساخت مرحلهبندی، از ریسک خودِ تغییر بیشتر میشود. تفاوت اصلی در مقیاس تأثیر تغییر است: هرچقدر آپدیت روی جریان اصلی درآمد، تجربه کاربری هستهای یا داده حساس کاربران اثر بیشتری بگذارد، ضرورت لانچ مرحلهای بالاتر میرود. تصمیم درست معمولاً از یک سؤال ساده شروع میشود: اگر این تغییر برای همه کاربران همزمان خراب شود، چقدر بازگرداندن وضعیت به حالت قبل زمانبر و پرهزینه خواهد بود؟ هرچقدر پاسخ به این سؤال ترسناکتر باشد، دلیل بیشتری برای مرحلهبندی دارید.
برای بنیانگذارانی که تازه میخواهند این فرهنگ را در تیمشان جا بیندازند، پیشنهاد میکنم قبل از هر لانچ بزرگ، یک بار به چکلیست ۱۰ گام قبل از لانچ نسخه دوم محصول سر بزنید و آن را کنار فرآیند مرحلهبندی خودتان قرار دهید. همچنین اگر میخواهید بدانید چرا بسیاری از لانچها اصلاً فیدبک کافی دریافت نمیکنند، مقاله چرا بیشتر لانچها هیچ فیدبکی نمیگیرند؟ را هم بخوانید؛ خیلی از دلایل آن، مستقیماً به روش لانچ یکباره برمیگردد.
اگر میخواهید آپدیت بعدی محصولتان را با اطمینان بیشتری لانچ کنید، بهترین قدم اول این است که همین حالا فرآیند لانچ فعلی تیم خود را کنار ۵ اشتباه مرگبار در لانچ محصول مرور کنید و ببینید کدامیک از آنها در تیم شما هم تکرار میشود. برای معرفی رسمی آپدیتهای بعدی خود به جامعه فارسیزبان استارتاپی، میتوانید از همین حالا در لانچینو ثبتنام کنید و لانچ محصولتان را با جامعهای از بنیانگذاران و کاربران اولیه به اشتراک بگذارید.