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