MVPها چه ارتباطی با accessibility دارند؟
در توسعه نرم‌افزار به روش Agile، یک مفهوم شناخته‌شده وجود دارد: محصول پذیرفتنی حداقلی (Minimum Viable Product یا MVP). هدف این مفهوم، تولید نسخه‌هایی از محصول است که نیاز کاربر را برطرف کنند. در هر مرحله، راهکاری عملی ارائه می‌شود که کاربر را از نقطه A به نقطه B می‌برد.
اما واقعیت تلخ این است که در اغلب موارد، MVPها بدون در نظر گرفتن accessibility ساخته می‌شوند. تیم‌ها معمولاً تصمیم خود را با عباراتی مانند «این فقط نسخه آلفا است» یا «ما تازه شروع کردیم» توجیه می‌کنند. اگرچه برخی بعدها به سراغ accessibility می‌روند، اما اگر از همان ابتدا به آن توجه شود، احتمال موفقیت بسیار بیشتر خواهد بود.
این موضوع همچنین نشان می‌دهد که تیم‌ها تا چه اندازه با به حاشیه راندن تجربه افراد دارای معلولیت، احساس راحتی دارند.
با اشاره به نوشته‌های هنریک نی‌برگ در مورد MVP، این پرسش را مطرح می‌کنم:
سریع‌ترین و کم‌هزینه‌ترین راه برای ساخت چیزی که قابل استفاده و accessible باشد چیست؟
نکته
در سوال بالا منظور overlayها نیست. صحبت در مورد یک راهبرد است که در آن، پیچیدگی‌های مربوط به accessibility به صورت مرحله‌ای و تدریجی اضافه می‌شود.
Technical debt تأثیر زیادی بر accessibility دارد
کدام بخش‌های MVP در محصول نهایی باقی می‌مانند؟ این موضوع به عوامل مختلفی بستگی دارد. اغلب، بخش‌هایی از طراحی و کد با همان فرضیات و تعصبات موجود در MVP، وارد محیط تولید می‌شوند.
در فرآیند معمول توسعه محصول — نه فقط در رویکرد MVP — تصمیماتی که تیم‌ها در مراحل ابتدایی اتخاذ می‌کنند، ممکن است سال‌ها باقی بمانند. گاهی از آن‌ها با عنوان لایه‌های رسوبی یاد می‌شود، با الهام از طبیعت.
رفع debt طراحی یا فنی، بدون بازنگری اساسی، تغییر بستر و شروع مجدد ممکن نیست.
اگر نمی‌توانید چیزی را accessible بسازید، کمتر انجام دهید
می‌توانیم اجزای رابط کاربری را به صورت تدریجی توسعه دهیم. (Progressive enhancement)
اگر بتوانیم نسخه‌های ساده‌تری از کامپوننت‌ها را در فازهای اولیه ارائه دهیم، می‌توانیم چیزی accessible در اختیار کاربر قرار دهیم بدون آن‌که از زمان یا بودجه فراتر برویم. سپس می‌توانیم در فرصت مناسب، ویژگی‌های بیشتری به آن اضافه کنیم.
نصیحت برادرانه:)
accessibility را به بخشی از فرهنگ تیم خود تبدیل کنید.