حالت نقشه‌ی فنی فعال است — تصمیم‌های طراحی این سایت را ببینید

انتخاب تکنولوژی برای محصول: چطور بدون وسواس تصمیم بگیریم

بحث بر سر «بهترین فریم‌ورک» معمولاً وقت تلف کردن است. معیارهای مهم‌تر این‌ها هستند: تیم، عمر محصول، هزینه‌ی تغییر و قابل‌جایگزینی بودن. اینجا چارچوب تصمیم را می‌بینید.

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

اول: این تصمیم چقدر برگشت‌ناپذیر است

همه‌ی انتخاب‌ها هم‌وزن نیستند. دو دسته را جدا کنید:

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

برای دسته‌ی دوم وقت زیاد نگذارید. برای دسته‌ی اول، ثبت تصمیم کنید.

معیارهایی که واقعاً مهم‌اند

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

دام‌های رایج

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

یک روش ساده برای تصمیم

  1. فهرست الزامات غیرقابل‌مذاکره را بنویسید.
  2. دو یا سه گزینه‌ی واقع‌بینانه انتخاب کنید، نه ده تا.
  3. یک «آزمون باریک» بسازید: کوچک‌ترین جریان واقعی با هر گزینه.
  4. تصمیم و دلیلش را بنویسید.
  5. مهلت بازبینی تعیین کنید.

لایه‌ها را جدا کنید تا انتخاب کم‌ریسک شود

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

چه چیزی را نباید بحث کرد

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

جمع‌بندی

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

برای طراحی معماری و انتخاب فناوری محصولتان، گفت‌وگو را شروع کنید.

نویسنده

محمد علی اسلامی‌پور

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