چه چیزی را از نسخهٔ اول حذف کنیم
همه میدانند نسخهٔ اول باید کوچک باشد. تقریباً هیچکس نمیتواند کوچکش کند.
چون هر قابلیتی که نگاه میکنید، دلیل خوبی برای بودنش دارد. و مجموع بیست قابلیت که هرکدام دلیل خوبی دارند، یک پروژهٔ هجدهماهه است.
پس مسئله دانستن نیست، روش حذف کردن است.
آزمون اول: مسیر حیاتی
یک جمله بنویسید که کاربر با محصول شما چه میکند.
«رستوراندار سفارش عمدهاش را ثبت میکند و روز بعد تحویل میگیرد.»
حالا کوتاهترین مسیری را که این جمله را ممکن میکند ترسیم کنید. قدم به قدم، از ورود تا پایان.
هر چیزی که در این مسیر نیست، از نسخهٔ اول بیرون است.
این آزمون بیرحم است و همان چیزی است که لازم دارید. فیلتر پیشرفتهٔ محصولات؟ در مسیر نیست. پنل گزارش؟ نیست. تنظیمات کاربر؟ نیست.
آزمون دوم: چند بار در روز؟
برای هر قابلیت بپرسید: کاربر روزی چند بار از این استفاده میکند؟
- چند بار در روز → نسخهٔ اول.
- هفتهای یک بار → احتمالاً نسخهٔ اول.
- ماهی یک بار → صبر کند.
- سالی یک بار → میشود دستی انجامش داد.
آن بند آخر نکتهٔ اصلی این آزمون است: کاری که سالی یک بار انجام میشود، لازم نیست خودکار باشد. گزارش سالانه را میشود یک بار در سال دستی ساخت. ساختن قابلیتی برای آن، هفتهها کار است برای صرفهجویی چند ساعت.
آزمون سوم: کاربر یا شما؟
قابلیتها را به دو ستون تقسیم کنید: آنهایی که کاربر لازم دارد و آنهایی که شما لازم دارید.
پنل مدیریت، گزارشها، ابزار پشتیبانی — اینها مال شمایند.
با ده کاربر اول، بیشتر کارهای مدیریتی را میشود دستی انجام داد: مستقیم در پایگاه داده، یا با یک اسکریپت ساده. زشت است و کار میکند و هفتهها زمان آزاد میکند.
پنل مدیریت را وقتی بسازید که تعداد کاربر از حدی گذشت که دستی جواب ندهد. آن موقع هم دقیقاً میدانید چه صفحههایی لازم دارید، چون سه ماه دستی انجامش دادهاید.
آزمون چهارم: اگر نباشد چه؟
برای هر قابلیت: اگر این نباشد، کاربر چه میکند؟
- «نمیتواند کارش را انجام دهد» → لازم است.
- «اذیت میشود ولی میتواند» → صبر کند.
- «متوجه نمیشود نیست» → حذف.
دستهٔ دوم بزرگترین دسته است و همان جایی است که بیشترین صرفهجویی هست.
چیزهایی که تقریباً همیشه میتوانند صبر کنند
از پروژههای واقعی، به ترتیب فراوانی:
پنل مدیریت کامل. دستی انجامش دهید.
گزارشها و نمودارها. خروجی خام کافی است؛ کاربر خودش در اکسل تحلیل میکند.
تنظیمات و شخصیسازی. مقدار پیشفرض معقول بگذارید. اگر کسی اعتراض کرد، آنوقت قابل تنظیمش کنید.
چندزبانگی. مگر آنکه از روز اول دو بازار دارید. اما ساختارش را از ابتدا بگذارید — افزودن زبان به سامانهای که متنهایش در کد هستند، بازنویسی است.
اپلیکیشن موبایل، اگر سایت واکنشگرا فعلاً کافی است. مقایسهاش در اول اپ بسازیم یا سایت.
سطوح دسترسی پیچیده. دو نقش برای شروع کافی است. اما محدودهٔ داده را در مدل پیشبینی کنید — افزودنش بعداً یعنی بازبینی هر کوئری، همانطور که در سطوح دسترسی گفتیم.
اعلانها. ایمیل ساده بهجای سامانهٔ اعلان چندکاناله.
جستوجوی پیشرفته. با صد رکورد، جستوجوی ساده کافی است.
ورود با شبکههای اجتماعی. موبایل و رمز کافی است.
بهینهسازی کارایی. با صد کاربر، هیچ چیزی کند نیست. زودهنگام بهینه کردن، وقت تلف کردن است.
چیزهایی که نباید حذف شوند
و این بخشی است که در توصیههای «کوچک بساز» معمولاً گم میشود. بعضی چیزها اگر از روز اول نباشند، افزودنشان بعداً چند برابر گران است:
امنیت پایه. رمز درست ذخیرهشده، بررسی دسترسی در سرور، جلوگیری از تزریق. هرگز.
پشتیبانگیری. از روز اول. سامانهای که دادهاش برود، تمام است.
لاگ رویدادهای مهم. بدون آن، اولین مشکل تولیدی را نمیتوانید بررسی کنید.
مدل دادهٔ درست. ساختار غلط موجودیتها و روابط، تنها چیزی است که واقعاً بازنویسی میخواهد. رابط کاربری را میشود عوض کرد؛ مدل داده را بهسختی.
قابلیت اندازهگیری. بدانید کاربران چه میکنند. بدون آن، نمیفهمید چه چیزی کار میکند.
خروجی داده. حتی ساده. کاربری که نتواند دادهاش را بیرون بیاورد، احساس حبس میکند.
چطور «نه» بگوییم
سختترین بخش، وقتی خودتان بنیانگذارید و به همهٔ ایدهها علاقه دارید.
فهرست «بعداً» بسازید. نگویید «این را نمیسازیم»؛ بگویید «این در نسخهٔ دوم است» و بنویسیدش. این کار حس از دست دادن را حذف میکند و — نکتهٔ جالب — شش ماه بعد که به فهرست برمیگردید، معمولاً نصف موارد دیگر لازم نیستند.
هزینه را به زمان ترجمه کنید. «این قابلیت سه هفته است، یعنی راهاندازی سه هفته دیرتر.» تصمیمگیری دربارهٔ زمان راحتتر از تصمیمگیری دربارهٔ قابلیت است.
قاعدهٔ یکدرمیان. اگر چیزی اضافه میشود، چیزی باید خارج شود. همان الگویی که در تغییر دامنه گفتیم.
تاریخ ثابت، دامنهٔ متغیر. تاریخ راهاندازی را قفل کنید و بگذارید دامنه تنظیم شود. عکسش — دامنهٔ ثابت و تاریخ شناور — همان چیزی است که پروژهها را بیپایان میکند.
آزمون نهایی
وقتی فکر میکنید فهرست بهاندازهٔ کافی کوچک شده، این سؤال را بپرسید:
«اگر نصف این را بسازیم، باز هم کسی استفاده میکند؟»
اگر جواب بله است، نصفش کنید.
معمولاً یکی دو دور این کار ممکن است. و تقریباً همیشه نسخهای که با ترس منتشر میشود — چون «خیلی ساده است» — کافی از آب درمیآید.
چون کاربر برای حل مشکلش آمده، نه برای دیدن امکانات. مسیر کامل از ایده تا همین نقطه در از ایده تا محصول آمده.