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