فیمن — فروشگاه فارسی پوشاک مردانه

01زمینه

فروشگاه پوشاک مردانه روی یک قالب آماده

فیمن پوشاک مردانه را آنلاین می‌فروشد: کت‌وشلوار، کت تک، شلوار، پیراهن، کفش و اکسسوری، همراه با راهنمای سایز، راهنمای پارچه و خدمت دوخت سفارشی. کار در ۲ تیر ۱۴۰۵ با قالب رسمی فروشگاهی Payload و یک دور اصلاح اولیه شروع شد. تا ۲۴ شهریور، بعد از ۴۹۱ کامیت، بیشتر آن قالب عوض شده بود.

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

از ۵۱۸ فایل کد در پایان کار، ۸۰ فایل همان فایل‌های قالب‌اند. پرداخت، ورود، مرحله‌ی نهایی خرید و واحد پول کامل جایگزین شدند؛ حساب کاربری مشتری، ابزارهای پنل مدیریت و ۱۷ بلاک از ۲۵ بلاک صفحه‌ها جدیدند.

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

دوازده هفته، به ترتیب تاریخ

01
قالب۲ تیر · قالب فروشگاهی Payload و یک دور اصلاح اولیه
02
پایه‌های کار در ایران۷ تیر · چیدمان فارسی راست‌به‌چپ، قیمت ریالی و آداپتور پرداخت شاپرک

02مسئله

پنج پیش‌فرضی که در ایران درست نیست، و فروشگاهی که باید اداره شود

تنظیم کردن پیش‌فرض‌های یک قالب فروشگاهی بین‌المللی کافی نبود؛ همه‌شان باید جایگزین می‌شدند:

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

03نقش من

یک طراح، چند ایجنت

محصول را طراحی کردم و ساختنش را هدایت کردم. بیشتر کد را ایجنت‌های کدنویسی هوش مصنوعی از روی مشخصات مکتوب نوشتند؛ دامنه‌ی کار، جهت طراحی و هر انتشار روی سایت اصلی را آدم‌ها تعیین کردند.

مسئولیت با من

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

مسئولیت مشترک

همکاری

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

هر نظر خام اول با کد واقعی بررسی می‌شد و بعد به مشخصاتی تبدیل می‌شد که ایجنت بتواند بدون سؤال اضافه از رویش بسازد. هر انتشار روی سایت اصلی در دفتری ثبت شده که فقط به آن اضافه می‌شود.

هر کار چطور جلو می‌رفت

01
گزارشیک نظر خام یا اسکرین‌شات وارد فهرست پیگیری می‌شود
02
بررسیپیش از ساختن، با کد واقعی سنجیده می‌شود

04سیستم

بخش‌هایی که باید با هم کار می‌کردند

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

طراحی هم چرخه‌ی بازبینی خودش را داشت: هر مشکل با یک اسکرین‌شات شروع می‌شد، در کد و زبان طراحی بررسی می‌شد، یک کارت می‌گرفت و بعد ساخته می‌شد. ۶۳ کارت طراحی تا ۲۱ شهریور ثبت شده بود و ۵۵ تای آن‌ها انجام شده بود.

یک تابع قیمت‌گذاری به کارت محصول، سبد، صورت‌حساب و بررسی پرداخت قیمت می‌دهد؛ برای همین قیمتی که مشتری می‌بیند همان مبلغی است که از بانک خواسته می‌شود.

سیستم، به تفکیک بخش

01
فروشگاهآنچه مشتری می‌بیند
- صفحه‌ی اصلی و بخش محصولات
- فروشگاه و فیلترها
- جست‌وجو
- صفحه‌ی محصول
- راهنمای سایز و پارچه
- صفحه‌های پشتیبانی
02
خریداز سبد تا سفارش پرداخت‌شده
- سبد خرید
- پرداخت یک‌صفحه‌ای
- ورود با موبایل
- آدرس‌های ذخیره‌شده
- درگاه‌های پرداخت
- کیف‌پول
03

یک خرید، همان‌طور که در کد اجرا می‌شود

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

05کشف محصول

رسیدن به محصول درست

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

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

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

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

صفحه‌ی نمونه‌های بخش محصولات فیمن — سه ردیف کمربند، گیره‌ی کراوات و پیراهن که منبع هر ردیف و نحوه‌ی نمایش قیمتش بالای آن نوشته شده است — شکل 03بلاک «بخش محصولات» در صفحه‌ی نمونه‌های فروشگاه، که ۶۰ ترکیب از منبع، چیدمان و نحوه‌ی نمایش قیمت را کنار هم نشان می‌دهد. بالای هر ردیف منبع و نحوه‌ی نمایش قیمتش نوشته شده است.

فیمن روی گوشی — برگه‌ی فیلترهای فروشگاه با گزینه‌های مرتب‌سازی، پارچه و مناسبت

فیمن روی گوشی — دسته‌ی کت‌وشلوار با فیلتر مناسبت عروسی، برچسب قابل حذف فیلتر و شمارنده روی دکمه‌ی فیلترها

06صفحه‌ی محصول

کم کردن تردید پیش از خرید

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

سایزها باید درست می‌گفتند. در ۲۲ مرداد، ۲۳ محصول از ۲۵ محصول سایزدار دست‌کم یک سایز نشان می‌دادند که هیچ موجودی‌ای پشتش نبود. حالا یک قاعده‌ی مشترک سایزهایی را که محصول در آن‌ها تولید نمی‌شود پنهان می‌کند، سایزهای تمام‌شده را غیرفعال می‌کند و محصولی را که دیگر موجودی ندارد «ناموجود» نشان می‌دهد. وقتی کمتر از ده عدد مانده باشد، صفحه تعداد باقی‌مانده را می‌گوید.

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

دو بخش هنوز ناتمام است: ابزار انتخاب سایز در صفحه‌ی محصول نیست و نمی‌داند هر محصول واقعاً چه سایزهایی دارد، و صفحه‌ی محصول پارچه‌ی هر محصول را جدا نشان نمی‌دهد.

نسخه‌ی محلی فیمن روی گوشی — صفحه‌ی یک کت‌وشلوار با سایز ۵۰ انتخاب‌شده، سایز ۵۲ غیرفعال چون تمام شده، تخفیف و وضعیت موجودی — شکل 05صفحه‌ی محصول روی گوشی. نوار خرید پایین صفحه هنگام پیمایش همیشه در دسترس است.

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

فیمن روی دسکتاپ — فرم انتخاب سایز در کنار وعده‌های راهنما برای بازگشت رایگان و مشاوره

فیمن روی دسکتاپ — راهنمای پارچه که پارچه را با فصل تطبیق می‌دهد، همراه با جدول مقایسه و نمونه‌های پارچه

فیمن روی گوشی — صفحه‌ی ارسال با وعده‌ی ارسال رایگان برای سفارش‌های بالای مبلغی مشخص به تومان، همراه با پیگیری سفارش

فیمن روی گوشی — صفحه‌ی پرسش‌های متداول با امکان جست‌وجو، دسته‌بندی‌شده بر اساس موضوع

07خرید و پرداخت

از سبد خرید تا سفارش پرداخت‌شده

قیمت سبد خرید روی سرور و با همان تابعی حساب می‌شود که بررسی پرداخت از آن استفاده می‌کند، پس سبد و بانک نمی‌توانند درباره‌ی مبلغ اختلاف داشته باشند. هر بار که سبد باز می‌شود، قیمت‌ها از روی کاتالوگ فعلی دوباره حساب می‌شوند؛ روی سایت اصلی، جمعی که در ۴ سبد از ۱۵ سبد باز ذخیره شده بود دیگر به‌روز نبود. صورت‌حساب قیمت اصلی، تخفیف کالاها و کد تخفیف را در سطرهای جدا نشان می‌دهد.

مرحله‌ی پرداخت یک صفحه است و روی گوشی اول خلاصه‌ی سفارش می‌آید. مشتری واردنشده در همان صفحه با شماره‌ی موبایل و یک کد شش‌رقمی وارد می‌شود، و اگر شماره جدید باشد حساب برایش ساخته می‌شود. اولین آدرس ذخیره‌شده خودکار انتخاب می‌شود. فقط روش‌هایی نشان داده می‌شوند که این سفارش با آن‌ها قابل پرداخت است، و مبلغ روی خود دکمه نوشته می‌شود: «پرداخت … تومان». هر چیزی که هنوز قابل استفاده نیست با یک جمله توضیح داده می‌شود، نه با دکمه‌ای خاکستری؛ مثلاً اینکه موجودی کیف‌پول دقیقاً چقدر کم است.

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

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

نسخه‌ی محلی فیمن روی گوشی — سبد خرید با یک کت‌وشلوار تخفیف‌دار و یک تاکسیدو، کد تخفیف آزمایشی و صورت‌حسابی که قیمت، تخفیف کالا و کد تخفیف را جدا نشان می‌دهد

نسخه‌ی محلی فیمن روی گوشی — مرحله‌ی پرداخت برای مشتری واردنشده: اول خلاصه‌ی سفارش، بعد ورود با شماره‌ی موبایل

08تصمیم‌های کلیدی

شش جایگزینی، نه شش تنظیم

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

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

09حساب کاربری

حساب کاربری، بعد از خرید و بین خریدها

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

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

در درخواست بازگشت، مشتری کالا، تعداد و علت را انتخاب می‌کند و سرور مالکیت سفارش، مهلت ۷ روزه و آنچه قبلاً برگشت داده شده را بررسی می‌کند. کارکنان درخواست را از یک وضعیت به وضعیت بعد می‌برند. هیچ پولی خودکار جابه‌جا نمی‌شود؛ کارکنان می‌توانند مبلغ را دستی به کیف‌پول مشتری برگردانند. صفحه‌ی کیف‌پول به سؤال «چرا موجودی من این عدد است؟» جواب می‌دهد: هر سطر گردش حساب علت، لینک سفارش و مانده‌ی بعد از خودش را دارد. دکمه‌ی شارژ کیف‌پول وجود ندارد، چون شارژ هنوز ساخته نشده و چنین دکمه‌ای وعده‌ی چیزی را می‌داد که وجود ندارد.

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

حساب کاربری، به تفکیک بخش

01
ورودیک مسیر برای مشتری تازه و قدیمی
- شماره‌ی موبایل
- کد شش‌رقمی
- نشست ۱۴ روزه
- خروج
02
پیشخانآنچه مشتری برایش برمی‌گردد
- سفارش‌های در جریان
- موجودی کیف‌پول
- تعداد علاقه‌مندی‌ها
- بازگشت‌های باز
- سه سفارش آخر
03
سفارش‌هافقط با پرداخت تأییدشده ساخته می‌شوند

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

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

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

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

10قواعد فروش

قاعده‌هایی که پشت رابط کاربری کار می‌کنند

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

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

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

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

پنل مدیریت فیمن در نسخه‌ی محلی — کنسول تخفیف‌ها با تعداد محصولات و دسته‌های تخفیف‌دار و کدهای تخفیف — شکل 11کنسول تخفیف‌ها در پنل مدیریت (اجرای محلی، داده‌ی آزمایشی): محصولات و دسته‌های تخفیف‌دار، کدهای تخفیف و تخفیف‌هایی که به‌زودی شروع یا تمام می‌شوند.

11اداره‌ی فروشگاه

اداره‌ی فروشگاه بدون برنامه‌نویس

پنل مدیریت به‌طور پیش‌فرض فارسی است، چون کارکنان در ایران‌اند، و تاریخ تخفیف‌ها با تقویم شمسی انتخاب می‌شود. صفحه‌ها از بلاک ساخته می‌شوند: قالب ۸ بلاک داشت، فروشگاه ۲۵ بلاک دارد و ۱۷ تای آن‌ها جدیدند، از «بخش محصولات» تا راهنمای سایز، پرسش‌های متداول و قوانین بازگشت. لینک‌های سربرگ، ستون‌های فوتر، شبکه‌های اجتماعی و ترتیب دسته‌ها در پنل مدیریت ویرایش می‌شوند.

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

پیامک برای سه رویداد فرستاده می‌شود: کد ورود، خبر فروش برای کارکنان و درخواست تازه‌ی فروش سازمانی. هر رویداد متن قابل ویرایش و گیرنده‌های خودش را دارد. صفحه‌ی فروش سازمانی درخواست‌های ۵۰ عدد به بالا را به‌عنوان سرنخ فروش ثبت می‌کند؛ فروشگاه قیمت عمده یا سامانه‌ی پیش‌فاکتور ندارد.

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

پنل مدیریت فیمن در نسخه‌ی محلی — داشبورد با هشدار سفارش پرداخت‌شده‌ای که منتظر تأیید اپراتور است

پنل مدیریت فیمن در نسخه‌ی محلی — فهرست سفارش‌ها که سفارش‌های پرداخت‌شده‌ی تأییدنشده را قرمز نشان می‌دهد

12برای ایران

ترجمه کافی نبود؛ فروشگاه برای ایران طراحی شد

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

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

پول هم قاعده‌های محلی دارد: مبلغ‌ها به ریال کامل ذخیره و به تومان نمایش داده می‌شوند، و برچسب‌های قیمت ترب به تومان‌اند تا این سایت مقایسه‌ی قیمت عدد درست را نشان دهد. در فوتر نماد اینماد هست و مشتری با زدن روی آن به سامانه‌ی ثبت کسب‌وکارهای اینترنتی می‌رسد. در ۵ مهر ۱۴۰۵ تنظیمات عمومی پرداخت فروشگاه زیبال، کیف‌پول، ترب‌پی و دیجی‌پی را نشان می‌داد.

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

این تنها مورد این فهرست است که به‌جای عدد گم‌شده، عددی غلط اما باورپذیر تولید می‌کند.
— برنامه‌ی آمار فروشگاه، درباره‌ی دام ریال و تومان · نوشته‌شده در ۵ شهریور ۱۴۰۵، پیش از راه‌اندازی آمار در ۹ شهریور

13پایداری

سرپا نگه داشتن یک فروشگاه زنده

در ۱۹ مرداد فروشگاه گزارش داد که یک محصول خطای ۴۰۴ می‌دهد، در حالی که هنوز در پنل مدیریت دیده می‌شود. یک بررسی فقط‌خواندنی روی سایت اصلی اندازه‌ی واقعی مشکل را نشان داد: ۱۱۳ محصول از ۱۶۶ محصول منتشرشده در دسترس نبودند. دو باگ روی هم افتاده بودند. تابع پیش‌فرض Payload برای ساخت اسلاگ همه‌ی حروف فارسی را حذف می‌کرد، و Next.js اسلاگ‌های فارسی را کدگذاری‌شده به صفحه می‌داد؛ پس حتی اسلاگ درست هم پیدا نمی‌شد. اول کد اصلاح شد، بعد ۱۱۳ اسلاگ روی سایت اصلی ترمیم شد و بررسی دوباره برای هر ۱۶۶ محصول پاسخ ۲۰۰ گرفت.

هر انتشار از یک بررسی محلی می‌گذرد: به‌روز بودن تایپ‌ها و import map، بعد بررسی تایپ، lint، تست‌ها و build نهایی. مجموعه‌ی تست‌ها در ۱۰ شهریور حدود ۱٬۰۸۶ تست داشت که ۷۷۲ تای آن تست واحد بود، و تا ۲۱ شهریور به ۱٬۳۵۴ رسید. هر انتشار روی سایت اصلی در دفتری ثبت می‌شود که فقط به آن اضافه می‌شود. بعد از انتشار، یک اسکریپت بررسی سریع مسیر بازگشت هر درگاه، آمار بازدید و فروشگاه را امتحان می‌کند. هر بررسی این اسکریپت برای خطایی اضافه شده که یک بار به سایت اصلی رسیده بود.

در ۱۰ شهریور، ۵۴ بسته از ۵۸ بسته‌ی قدیمی به‌روز شد: در دو دسته‌ی بررسی‌شده، به‌علاوه‌ی نُه ارتقای بزرگ که هرکدام جدا انجام شد. دلیل عقب ماندن چهار بسته‌ی دیگر هم ثبت شد. سرعت صفحه‌ها هیچ‌وقت اندازه‌گیری نشد، پس اینجا ادعایی درباره‌اش نیست. تنها تغییری که در build اندازه‌گیری شد مرحله‌ی کامپایل بود: از ۸۸ به ۱۸٫۲ ثانیه.

رفع خطای ۴۰۴، به ترتیب

01
گزارشیک محصول ۴۰۴ می‌دهد ولی در پنل مدیریت هست
02
بررسی۱۱۳ محصول از ۱۶۶ محصول منتشرشده در دسترس نیستند

…چیزی را که مشتری می‌بیند تغییر نمی‌داد، چون حتی اسلاگ فارسی درست هم هنوز ۴۰۴ می‌داد.
— پیام کامیت اصلاح مسیرها، درباره‌ی ترمیم اسلاگ‌ها به‌تنهایی · ۲۰ مرداد ۱۴۰۵، روز ترمیم اسلاگ‌ها

14نتایج

فعال، همراه با فهرست کمبودها

فروشگاه از ۱۶ تیر ۱۴۰۵ روی faymen.ir فعال است و پرداخت می‌گیرد. هیچ عدد تجاری‌ای منتشر نمی‌شود. عددهای زیر مربوط به اصلاح‌هایی است که اندازه‌گیری شده‌اند؛ بقیه کارهایی است که تحویل شده.

محصولاتی که ۴۰۴ می‌دادند، پیدا و اصلاح شدند: ۱۱۳ / ۱۶۶; عنوان‌های فارسی اسلاگ خراب تولید می‌کردند؛ بیش از دو سوم کاتالوگ در دسترس نبود.; نتیجه‌ی اندازه‌گیری‌شده · کارت بازخورد و بررسی سایت اصلی، ۲۰ مرداد ۱۴۰۵
محصولات سایزداری که سایزی بدون موجودی نشان می‌دادند: ۲۳ / ۲۵; حالا یک قاعده‌ی واحد سایزها را بر اساس موجودی پنهان یا غیرفعال می‌کند.; نتیجه‌ی اندازه‌گیری‌شده · کارت سیستم سایز، ۲۲ مرداد ۱۴۰۵
سبدهای بازی که جمع قدیمی داشتند: ۴ / ۱۵; حالا سبد با هر بار باز شدن قیمت‌ها را دوباره حساب می‌کند.; نتیجه‌ی اندازه‌گیری‌شده · یادداشت کد در اصلاح سبد
فروشگاهی که مشتری از اول تا آخر با آن کار می‌کند: فروشگاه، مرحله‌ی پرداخت، حساب کاربری و پنل مدیریت: ۴۹۱ کامیت در دوازده هفته، از قالب اولیه تا خرید با شماره‌ی موبایل.; خروجی تحویل‌شده

آنچه تحویل شد

ورود فقط با موبایل
پرداخت یک‌صفحه‌ای
حساب مشتری با کیف‌پول و بازگشت کالا

15آنچه یاد گرفتم

آنچه این فروشگاه یاد داد

01
محدودیتی که شبیه کار روزمره است، تصمیم محصولی است
جمله‌ی «Docker Hub در دسترس نیست» تعیین می‌کند که می‌شود وسط حراج اصلاحی منتشر کرد یا نه. جمله‌ی «سرویس ایمیل نداریم» باعث شد ورود، مرحله‌ی پرداخت و خبرنامه از نو نوشته شوند.
02
گزارش تا با کد سنجیده نشود، کار نیست
گزارش این بود که یک محصول خطای ۴۰۴ می‌دهد ولی هنوز در پنل مدیریت دیده می‌شود. وقتی گزارش با کد و کاتالوگ سنجیده شد، معلوم شد مشکل دو سوم فروشگاه را گرفته و دو باگ جدا پشتش است.
03
فقط چیزی را نشان بده که داده پشتش است
مسیر سفارش تاریخ ندارد، چون تاریخی ثبت نمی‌شود. اگر عددی بارگذاری نشود، به‌جای صفر خط تیره نشان داده می‌شود. کیف‌پول دکمه‌ی شارژ ندارد، و ابزار انتخاب سایز سایزی را که فروشگاه نمی‌تواند بفروشد پیشنهاد نمی‌دهد.
04
اختلاف‌های زبان طراحی قرضی را بنویس
سازگار کردن یک زبان طراحی موجود ارزان‌تر از نوشتن زبانی تازه بود. اختلاف‌هایی که ثبت شد، مثل فاصله‌ی حروف فارسی و کنار گذاشتن تصویرسازی، مفیدترین بخش آن شدند.

زبان