دوم از پانزدمین:‌ زمان لانچ یا زمان ریلیز؟ مسئله این است!

خیلی وقته که تو بعضی از شرکت‌ها،‌ وقتی که یه فیچر جدید رو می‌خوان به دست کاربرهاشون (که می‌تونه کارمندای خود شرکت، بیزینس‌های دیگه و در نهایت کاربر نهایی باشه) برسونن،‌ بین تیم فنی و تیم مارکتینگ جنگی به پا میشه. چه جنگی؟ معلومه! تیم مارکتینگ از هفته‌ها قبل از رسیدن فیچر،‌ شروع به تبلیغات کرده و روز خاصی و یا حتی ساعت خاصی رو معین کرده و به همه اطلاع‌رسانی کرده، اما این وسط اون روز و اون ساعت تیم فنی ممکنه در انتشار نسخه‌ی جدید سرویس دچار مشکل بشه! این یعنی یه آبروریزی بزرگ به راه می‌افته و یا چیزی منتشر میشه که با قول‌های تیم مارکتینگ تطابق نداره. جدا از این مسئله، اکثر مواقع برای بهره‌مند شدن از اون قابلیت، کاربر می‌بایست اپلیکشن‌اش رو به روز رسانی کنه و در نهایت، ممکنه در اون زمان خاصی که تیم مارکتینگ براش برنامه‌ریزی کرده، به دستش نرسه. همه‌ی این مسائل به ما این رو میگه که‌ اتفاق بزرگی که تیم مارکتینگ براش یه عالمه برنامه چیده بود به خوبی اتفاق نیوفتاده.

اگه این اتفاق تو شرکت شما هم پیش میاد شاید این نوشته به کارتون بیاد.

در ابتدا داستان باید ۲ کلمه رو براتون تعریف کنم:

زمان ریلیز

زمانی هستش که محصول شما،‌ تغییر می‌کنه و قابلیت‌های جدید بهش اضافه میشه.

زمان لانچ

زمانی هستش که کاربر باید به قابلیت‌ها و تغییرات جدید شما دسترسی داشته باشه.

تا امروز همه‌ی ما این دو زمان رو یکسان میدیم. یعنی اگه می‌خواستیم یه قابلیت جدید رو لانچ کنیم، همون موقع نسخه‌ی نرم‌افزارمون رو هم ریلیز می‌کردیم. اما در واقعیت می‌تونه این دو زمان از هم جدا در نظر گرفته بشه و این جدا کردن می‌تونه یه عالمه مزیت برای شرکت‌هامون داشته باشه.
بیاید با مثالی این اتفاق رو کمی شفاف‌تر کنیم.

فرض کنید تیم مارکتینگ شما تصمیم به عوض کردن چند عکس در نرم‌افزار شما می‌گیره و قرار میشه ساعت ‍۱۲ در روز ۲۳ مرداد این نسخه‌ی جدید رو برای همگان منتشر کنه. از دید تیم مارکتینگ نکته‌ی مهم این تصمیم، انجام شدن در راس ساعت ۱۲ هستش که اتفاق رو برای تیم فنی ممکنه سخت‌تر کنه.

در ادامه تیم فنی، بنا به این درخواست، تسکی ایجاد می‌کنه و تسک رو به نحو احسن انجام میده.

روز موعود فرا میرسه و تیم فنی در ساعت ۱۱:۰۰ به خط میشه تا مراحل انتشار نسخه‌ی جدید برنامه رو بچینه و در ساعت مقرر،‌ همه چیز بدون مشکل انجام بشه.

اما ... در زمان انتشار نسخه‌ی جدید مشکلاتی پیش میاد که خیلی هم جدی نیستند اما زمان انتشار رو از ساعت ۱۲ به ساعت ۱۲:۳۲ تغییر میده. این تغییر برای تیم مارکتینگ پذیرفته نیست و کلی سر و صدا به پا می‌کنه (جدا از هزینه‌های هدر رفته) اما با توضیحات مدیر فنی، اتفاق به فراموشی سپرده میشه.

دفعه‌ی بعد که این درخواست از سمت تیم مارکتینگ تکرار میشه، مدیر فنی تدبیر جدیدی برای این اتفاق می‌اندیشه :). به‌جای اینکه با انتشار برنامه تغییرات اعمال بشه، در تسک به توسعه‌دهندگان توضیح میده که باید تغییرات در کد و با شرط‌هایی وابسته به زمان (یعنی مثلا اگه زمان فعلی از فلان موقع بیشتر بود، عکس دیگری رو نمایش بدن) این تسک پیاده بشه، و قبل از تاریخ مقرر کد منتشر بشه. با این استراتژی اگر مشکلی برای انتشار نسخه به وجود بیاد، برای حل مشکلات زمان وجود خواهد داشت.

روز موعود فرا میرسه اما تیم فنی از قبل قابلیت مد نظر رو منتشر کرده بود و سر زمان همه چیز به خوبی و بدون نیاز به تغییری در چیزی، تغییر پیدا می‌کنه و مدیرفنی سربلند از این تسک بیرون میاد :)

اگر دقت کرده باشید مدیرفنی با جدا کردن زمان انتشار با زمان لانچ، تونسته بود که نیاز‌های تیم فنی و مارکتینگ رو با یک تیر رفع کنه. اما این روش کار در تعداد زیادی اتفاق قابل پیاده سازی نیست! درسته؟

کل صحبت ما همین بود! اما در اسکیل بزرگ و استاندارد!‌

از این به بعد در مورد روشی صحبت می‌کنیم که باهاش میشه این کار رو در اسکیل بزرگ و به صورت استاندارد (یا به قول بچه‌های فنی، به صورت تمیز) پیاده کرد.


خیلی قبل‌تر یکی از بزرگان علم کامپیوتر (مارتین فاولر) تئوری‌ای برای پیاده‌سازی قابلیت‌های جدید در سیستم‌های بزرگ ارائه داده بود. اسم اون تئوری Feature toggle یا Feature flag هستش. برای مطالعه‌ی بیشتر می تونید از این لینک استفاده کنید: https://www.martinfowler.com/articles/feature-toggles.html

برای اینکه مفهموم فیچر فلگ رو متوجه بشید، خیلی ساده سعی می‌کنم توضیح بدم که وقت زیادی ازتون گرفته‌نشه.

وقتی که در تیم‌تون می‌خواید یه قابلیتی رو پیاده کنید که نیاز دارید زمان لانچ و ریلیز متفاوتی داشته باشه، ابتدا به اون فیچر یه نام یکتا‌ی انگلیسی بدید. مثلا test-feature که در سیستم بتونید این فیچر رو شناسایی کنید.

بعدش در جایی از سیستم (مثلا دیتابیس) لیستی از فیچرها رو با وضعیتشون که شامل (public | private) هستش نگه دارید. بعد لیستی از کاربرانی رو که به اون فیچر در حالت private قراره دسترسی داشته باشن، در جای دیگه‌ای از سیستم نگه‌دارید (باز هم دیتابیس مکان خوبی هستش).

نحوه‌ی چک کردن فعال بودن یک قابلیت برای هر کاربر به این صورت هستش:
۱- اگه اون قابلیت در حالت عمومی - public بود،‌ همه‌ی کاربرها به اون دسترسی دارن.
۲- اگه اون قابلیت در حالت خصوصی - private بود، فقط کاربرانی که از قبل اعلام شده‌اند به اون قابلیت دسترسی دارن.
البته شما می‌تونید این مدل رو هر چقدر که دوست داشته باشید یا نیاز داشته باشید پیچیده‌تر و کامل‌تر کنید.

در نهایت در زمان توسعه‌دادن اون قابلیت، با یک شرط ساده که توش چک میکنید که آیا اون کاربر به اون قابلیت دسترسی داره یا نه،‌ یا نسخه‌ی قبلی سیستم رو نشون میدید یا نسخه‌ی جدید رو نشون میدید. همین و بس‌!

شاید براتون سوال باشه که مثلا سمت اپلیکیشن شما چه جوری باید این چک کردن‌ها رو انجام بده، و خب جوابش ساده است،‌ کافیه در درخواست لاگین یا گرفتن اطلاعات کاربر، لیست قابلیت‌های فعال برای اون کاربر رو به سمت اپلیکیشن برگردونیم.


قابلیت‌هایی که زیرساخت فیچرفلگ به مجموعه‌ی شما میده، از دید من (که قطعا ناقص هستش)، این‌هاست:

  • قابلیت انتشار نسخه، قبل از زمان لانچ
  • قابلیت مشاهده‌ی نسخه‌ی جدید برای بعضی از کاربران (مثلا تیم مارکتینگ یا تسترها و یا گروه تستی از کاربرها) در محیط پروداکشن
  • قابلیت انتشار فیچری خاص برای گروه خاصی از کاربران (مثلا قابلیت ویژه‌ای برای شرکت خاصی که باهاش کار میکنید)
  • بازگشت راحت به نسخه‌ی قبل برنامه در صورتی که باگ یا اروری در نسخه‌ی جدید وجود داشت باشه

برای مارکتینگ یکسری پیشنهاد و قانون برای درخواست قابلیت‌های جدید توی سال‌هایی که کار کردم تونستم در بیارم که شاید به درد شما هم بخوره و خلاصه اینهاست:

  • قبل از اینکه قابلیتی که می‌خواید،‌ ریلیز نشده و توسط شما دیده نشده،‌ هیچ وقت به لانچ کردن اون قابلیت به صورت کورکورانه فکر نکنید
  • برای لانچ کردن یک قابلیت،‌ زمانی که با تیم فنی ددلاین‌هاتون رو می‌بندید، همه‌ی کارهایی که داخلی هستش و توسط تیم‌های شرکت انجام میشه رو ببرید جلو، اما هیچ ارتباط بیرونی یا تبلیغات بیرونی‌ای انجام ندید و منتظر باشید که قابلیت ریلیز بشه و بعد از اون، ابتدا با تعداد محدودی از مشتریاتون اون قابلیت رو تست کنید، و در نهایت اگه فیچر درخواست شده،‌ از دید شما قابلیت لانچ شدن داشت، پلن لانچ بریزید و روز لانچ صرفا فیچرفلگ مد نظر رو public کنید!
  • هیچ وقت و هیچ وقت به ددلاین‌های تیم فنی، اعتماد نکنید! و هیچ قولی به هیچ مشتری‌‌ای پیروی قول تیم فنی ندید! این قول دادن‌ها ممکن هستش جز آبروریزی و از دست دادن قرارداد، براتون هیچ آورده‌ای نداشته باشه.


امیدوارم این مقاله به شما در خلق ارزش‌های بزرگ‌تر کمکی کرده باشه :)