استاندا‍رد تایید یا رد اپلیکیشن، دروازه ورود به استور

اگه استورها، محلی برای پیدا کردن اپلیکیشن‌های مختلف و دلخواه کاربران هستن، چه لزومی داره که برای ورود اپلیکیشن‌ها به این مرکز دانلود، فیلتر خاصی وجود داشته باشه؟

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

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

چه اتفاقی سبب شد که مایکت دست به بررسی اپلیکیشن‌ها و رد یا تایید آن‌ها بزند؟

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

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

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

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

بنابراین با تفکیک این دو تا مرحله، یعنی ابتدا «رد یا تایید کردن اپلیکیشن» و بعد «امتیاز دهی به اپلیکیشن جهت مشخص شدن سطح کیفیتش»، تونستیم پاسخ توسعه‌دهنده رو در یک فضای شفاف‌تر ارائه کنیم و از کلی‌گویی یا ایجاد احساس سردرگمی در توسعه‌دهنده جلوگیری کنیم.

درواقع نیت اصلی ما از انجام این فرایند این بود که فضای مناسبی رو برای ورود اپلیکیشن‌های نوپا و تهیه شده توسط توسعه‌دهنده‌های تازه‌کار ایجاد کنیم و به اکوسیستم کمک کنیم تا دولوپرهای مختلف تشویق بشن شانس خودشون رو برای ورود به استور امتحان کنن. ولی کلی‌گویی و بیان همه نکات توام با رد اپلیکیشن سبب ایجاد سردرگمی در توسعه‌‎دهنده شده بود که ما سعی کردیم با تغییر روش ارزیابی این مورد رو برطرف کنیم.

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

رایج ترین دلایلی که منجر به رد یک اپلیکیشن و جلوگیری از انتشار آن در مایکت می‌شود چیست؟

پاسخ به این سوال نیاز به دریافت یک گزارش آماری دقیق از تیم پشتیبانی داره اما چند مورد بسیار رایج که در حال حاضر نسبت به اونا حضور ذهن دارم، به این شرح هستن:

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

2. دومیش قوانین کپی‌رایتینگ است که طی اون توسعه‌دهنده نباید اپلیکیشن یا سورس کدی رو از یه اپلیکیشن خارجی یا هر اپلیکیشن دیگه‌ای کپی کرده و صرفا فقط اسم یا لوگوش رو عوض کنه.

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

4. درباره اپ‌های درون پرداخت، نکته‌ای که باید توسعه‌دهنده‌ها در نظر داشته‌باشن، پیاده‌سازی درون‌پرداخت مایکت است. معمولا در اپ‌های درون پرداخت ایرادهایی از این دست وجود داره.

5. اپلیکیشنی که خدمات پرداختی درون آن صورت می‌گیره باید مجوزهای لازم برای انجام این جابه‌جایی‌های مالی رو داشته‌باشه.

برنامه فعلی مایکت برای اپلیکیشن هایی که رد می‌شوند چیست؟ آیا این اپلیکیشن‌ها به طور کلی از دنیای مایکت خارج می‌مانند؟

اساسا نگاه تیم پشتیبانی به مقوله رد یا تایید کردن اپلیکیشن‌ها، کمک به آن‌ها در راستای رشد و حضورشون در اکوسیستم است. بنابراین اینطوری نیست که یک اپلیکیشن رو به طور کامل از سیستم حذف کنیم و هیچگونه راه برگشتی براش در نظر نگیریم.

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

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

آیا همه اپلیکیشن‌ها در مایکت لزوما رد یا تایید می‌شوند یا حالت میانه‌ای نیز برای ورود اپلیکیشن‌ها به استور وجود دارد؟

خب همونطور که اشاره کردیم، ما در حال حاضر دو سطح استاندارد مختلف رو برای ورود یک اپلیکیشن به مایکت طی می‌کنیم:

1. سطح استاندارد اولیه برای تایید یا رد اپلیکیشن

2. سطح استانداردی ثانویه که شامل کمک به بهینه‌سازی جنبه‌های فنی،محتوایی و گرافیکی برنامه‌ها می‌شه

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

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

برای مثال به توسعه‌دهنده میگیم که گرافیک اپلیکیشن شما ضعیف است یا محتوای درون اپلیکیشن شما مقدار مطلوبی نداشته و کافی نیست. یا برای مثال میگیم که گرافیک آیکونی که برای اپلیکیشن در نظر گرفتی در نظر کاربران جذابیت لازم را ندارد. حتی ممکن است به توسعه‌دهنده این پیشنهاد رو بدیم که برنامه‌هایی با محتوای مشابه برنامه تو در مایکت بسیار زیاد هستن، بهتره برای اینکه اپلیکیشنت در نظر کاربران متمایز باشه و بیشتر به چشم بیاد، یک نوآوری در محتوای آن ایجاد کنی.

ما تا جایی که امکانش هست به صورت کلی به توسعه‌دهنده کمک می‌کنیم تا اپلیکیشن خودش رو به بهترین نحو ممکن در مایکت به نمایش در بیاره.