فرض کنید برای اپلیکیشن سفارش آنلاین فروشگاهتان دو پیشنهاد گرفته‌اید. یکی تقریباً نصف دیگری قیمت دارد و دامنه‌اش هم کوتاه‌تر نوشته شده است. کدام را انتخاب می‌کنید؟ در انتخاب شرکت طراحی اپلیکیشن، جواب از مقایسه عدد پایین صفحه درنمی‌آید. برای هر ادعا مدرک بخواهید و فقط پیشنهادهایی را کنار هم بگذارید که دامنه‌شان یکی است.
- برای هر ادعای مجری، مدرک و مسئول مشخص بخواهید.
- پیشنهادها را پس از یکسان کردن دامنه و هزینههای جداگانه مقایسه کنید.
- مالکیت کد بدون امکان ساخت نسخه و انتقال دسترسی، تحویل کامل نیست.
- معیار پذیرش و شرایط پشتیبانی را پیش از قرارداد بنویسید.
- امتیاز وزنی به تصمیم کمک می‌کند، اما خط قرمز قراردادی را جبران نمی‌کند.
برای انتخاب شرکت طراحی اپلیکیشن چه معیارهایی را بررسی کنیم؟
برای انتخاب شرکت طراحی اپلیکیشن، این‌ها را بررسی کنید: نمونه‌کار مرتبط، نقش واقعی مجری در آن نمونه‌ها، اعضای تیم، منطق پیشنهاد فنی و زمان‌بندی. مالکیت کد و حساب‌ها، معیار پذیرش و شرایط پشتیبانی هم همین‌قدر مهم‌اند. برای هر معیار مدرک بخواهید و پیشنهادهای هم‌دامنه را با وزن‌های مشخص امتیاز بدهید. ابهام‌های قراردادی را هم پیش از انتخاب برطرف کنید، نه بعد از امضا.
کار با این چک‌لیست ساده است. کنار هر معیار انتخاب شرکت اپلیکیشن که در ادامه آمده، یکی از این سه وضعیت را بنویسید:
تأییدشده: مدرکی دیده‌اید که ادعا را نشان می‌دهد.
نیازمند مدرک: مجری ادعا کرده، اما هنوز چیزی ارائه نداده است.
نامناسب: مدرک را دیده‌اید و با نیاز پروژه جور درنمی‌آید.
پس جمله «ما این کار را زیاد انجام داده‌ایم» در جلسه هنوز تأیید حساب نمی‌شود. تا مدرکی نبینید، آن مورد در وضعیت دوم می‌ماند.
«بهترین شرکت طراحی اپلیکیشن» هم برای هر پروژه معنای خودش را دارد. بهترین گزینه مجری‌ای است که مسئله شما را قبلاً حل کرده و ریسک‌هایش را می‌شناسد. رتبه‌بندی‌های عمومی و ردیف لوگوی مشتریان در سایت، چیزی درباره تناسب با پروژه شما نمی‌گویند.
شرکت، تیم مستقل یا فریلنسر؛ کدام مناسب پروژه است؟
جواب به دو چیز بستگی دارد: پروژه چند نقش لازم دارد و چه کسی این نقش‌ها را هماهنگ می‌کند. ثبت رسمی شرکت به‌تنهایی نشانه توان اجرا نیست. ساختار پاسخ‌گویی از برچسب حقوقی مهم‌تر است.
معیار | شرکت | تیم مستقل | فریلنسر |
|---|---|---|---|
پاسخ‌گویی | یک طرف قرارداد برای کل خروجی | بسته به توافق؛ گاهی چند طرف | مستقیم، اما محدود به حوزه خودش |
پوشش تخصص‌ها | معمولاً طراحی، برنامه‌نویسی، سرور و آزمون | بسته به ترکیب اعضا | معمولاً یک یا دو تخصص |
وابستگی به افراد | کمتر، اگر جایگزین هر نقش تعریف شده باشد | متوسط | زیاد؛ غیبت یک نفر کار را متوقف می‌کند |
پیش از انتخاب شرکت طراحی اپلیکیشن، تکلیف این دو مورد را در چک‌لیست خودتان روشن کنید:
پروژه محدود است یا چندبخشی؟ اگر طراحی، بخش سرور، انتشار و نگهداری را هم‌زمان می‌خواهید، به چند نقش نیاز دارید. تعداد نقش‌ها شکل همکاری را تعیین می‌کند. مدرک: فهرست مسئولیت‌ها با اسم مسئول هر کدام.
هماهنگ‌کننده فنی دارید؟ اگر در سازمانتان کسی کار چند نفر را به هم وصل نمی‌کند، تیم مستقلی که مسئول یکپارچه‌سازی ندارد، این بار را روی دوش شما می‌گذارد.
پرسش «شرکت طراحی اپلیکیشن یا فریلنسر» را در دو سناریوی فرضی ببینید. اگر نمونه اولیه‌ای می‌خواهید که فقط ایده را به چند کاربر نشان بدهد، یک فریلنسر باتجربه اغلب سریع‌تر و کم‌هزینه‌تر است. اما محصولی با پرداخت آنلاین، پنل مدیریت و اتصال به انبار، چند تخصص و یک مسئول نهایی می‌خواهد.
این به معنای ضعیف‌تر بودن فریلنسرها نیست. مسئله فقط این است که ظرفیت مجری با دامنه کار بخواند.
نمونه‌کار و نقش واقعی مجری را چگونه بررسی کنیم؟
نمونه‌کار را با شباهت مسئله بسنجید، نه با شباهت صنعت یا ظاهر. اپلیکیشن یک کلینیک و اپلیکیشن یک پخش‌کننده کالا ممکن است هر دو به کار آفلاین یا اتصال به سامانه داخلی نیاز داشته باشند. در انتخاب شرکت طراحی اپلیکیشن، همین تجربه مشترک ارزش دارد، نه رنگ‌بندی شبیه.
اجرای زنده با داده آزمایشی: از مجری بخواهید نسخه‌ای را جلوی شما اجرا کند. لازم نیست اطلاعات محرمانه مشتری قبلی را ببینید.
شرح دامنه مشارکت: بپرسید طراحی، برنامه‌نویسی، بخش سرور و نگهداری را چه کسانی انجام داده‌اند. همان افراد در تیم پیشنهادی شما هم هستند؟
یک تصمیم فنی و پیامدش: از تیم بخواهید یک انتخاب دشوار را توضیح بدهد و بگوید بعدها چه اثری گذاشت.
اولین کاری که معمولاً در جلسه بررسی نمونه‌کار می‌کنم، امتحان یک مسیر کامل است؛ مثلاً از ثبت سفارش تا دیدن وضعیت آن. تصویرهای صفحه اپلیکیشن در فروشگاه فقط نشان می‌دهند صفحه‌ها وجود دارند. ثابت نمی‌کنند مسیر درست کار می‌کند.
گاهی محصولی که مجری ساخته دیگر در دسترس نیست. شاید مشتری کسب‌وکارش را بسته یا برنامه را درون‌سازمانی کرده است. در این حالت علت را بپرسید و شاهد جایگزین بخواهید، مثل نسخه آزمایشی یا ویدئوی کارکرد. نبود نسخه عمومی به‌تنهایی دلیل رد مجری نیست.
صفحه زیبا مهارت طراحی را نشان می‌دهد؛ مسیری که از اول تا آخر بی‌خطا کار کند، توان تحویل را.
در نمایش نمونه‌کار، یک مسیر ناموفق مثل قطع اینترنت را هم ببینید. توضیح تیم درباره بازیابی وضعیت، از نمایش چند صفحه زیبا اطلاعات بیشتری می‌دهد.
چه سؤال‌هایی درباره تیم و توان فنی بپرسیم؟
سؤال‌هایی بپرسید که جوابشان قابل بررسی باشد، نه سؤال‌هایی که فقط «بله» می‌گیرند. سوالات قبل از سفارش اپلیکیشن باید به اسم آدم‌ها و نقش‌ها برسند. سه پرسش پایه این‌هاست: مسئول فنی کیست؟ آزمون را چه کسی انجام می‌دهد؟ اگر عضو کلیدی رفت، جایگزینش کیست؟
من به‌عنوان مدیر پروژه، ظرفیت واقعی را مهم‌تر از رزومه می‌دانم. جدول نقش‌ها را بخواهید: اسم هر نفر، سهمش از وقت پروژه شما و تصمیم‌هایی که با اوست. رزومه کسی که در تیم پیشنهادی نیست، به کار شما نمی‌آید.
از تیم بخواهید انتخاب فناوری را هم توضیح بدهد. توضیح خوب به نیاز محصول، محدودیت دستگاه‌های کاربران و هزینه نگهداری در سال‌های بعد اشاره می‌کند. اگر بین ساخت جداگانه برای هر سیستم‌عامل و یک کد مشترک مردد هستید، مقایسه توسعه بومی و چندسکویی اپلیکیشن کمکتان می‌کند سؤال دقیق‌تری بپرسید.
بخش سرور (Backend) قسمتی از سیستم است که کاربر نمی‌بیند؛ جایی که داده‌ها نگهداری و سفارش‌ها پردازش می‌شوند. درباره آن این‌ها را بپرسید:
اتصال به سرویس‌های بیرونی مثل درگاه پرداخت یا پیامک را چطور مدیریت می‌کنند؟
اگر اینترنت کاربر وسط کار قطع شود، برنامه چه رفتاری دارد؟
خطاها کجا ثبت می‌شوند و چه کسی پیگیرشان است؟
داده حساس مثل شماره تماس و آدرس را چطور نگه می‌دارند؟
مدرک این بخش دو چیز است. اول، نمونه بینام بازبینی کد (Code Review)؛ یعنی هر تغییری که برنامه‌نویس می‌دهد، همکارش هم بررسی‌اش می‌کند. دوم، یک گزارش آزمون واقعی. اگر پروژه حساس است، مثلاً اپلیکیشن با پول یا داده سلامت سروکار دارد، ارزیابی فنی مستقل را هم در نظر بگیرید.
پیشنهاد فنی و زمان‌بندی چه جزئیاتی باید داشته باشند؟
پیشنهاد فنی باید آن‌قدر دقیق باشد که دو نفر از آن یک برداشت داشته باشند. این موارد را تیک بزنید:
نسخه‌های سیستم‌عامل هدف، مثلاً از کدام نسخه اندروید و iOS به بعد
فهرست قابلیت‌ها و امکانات پنل مدیریت
اتصال به سامانه‌ها و سرویس‌های دیگر
موارد خارج از تعهد مجری
مسئول تأمین محتوا، مثل متن‌ها و تصویرهای محصولات
همین فهرست مبنای مقایسه هزینه هم هست. بدون آن، دو عدد را کنار هم می‌گذارید که مال دو کار متفاوت‌اند.
برای زمان‌بندی، برنامه‌ای مرحله‌ای بخواهید که هر مرحله‌اش خروجی قابل بررسی داشته باشد. وابستگی‌ها، مسئول تأیید هر مرحله و شیوه ثبت درخواست تغییر هم باید روشن باشند. تاریخی که فرض‌های پشتش نوشته نشده، ارزش کمی دارد. اگر ترتیب کلی مراحل برایتان آشنا نیست، نقشه راه ساخت اپلیکیشن موبایل تصویر روشنی می‌دهد.
یادتان باشد تخمین اولیه با تعهد قراردادی فرق دارد. دسترسی دیرهنگام به سرویس بیرونی، تأخیر در تصمیم‌های کارفرما و روند بررسی فروشگاه، زمان انتشار را جابه‌جا می‌کنند. خوب است پیشنهاد بگوید مسئولیت هر نوع تأخیر با کیست.
یکی از رایج‌ترین خطاها در انتخاب شرکت طراحی اپلیکیشن این است که فقط هزینه ساخت را ببینید. هزینه را چهار تکه ببینید: ساخت، سرویس‌های بیرونی مثل پیامک و نقشه، زیرساخت و میزبانی، و نگهداری. پیشنهادی که فقط عدد ساخت را می‌گوید، تصویر کاملی از خرج شما نمی‌دهد.
دو پیشنهاد کاملاً فرضی و بینام را در نظر بگیرید:
مورد | پیشنهاد الف | پیشنهاد ب |
|---|---|---|
مبلغ اولیه | پایینتر | بالاتر |
آزمون روی دستگاه‌های هدف | جدا، با هزینه جداگانه | داخل دامنه |
انتشار در فروشگاه‌ها | به عهده کارفرما | داخل دامنه |
پنل مدیریت | نسخه پایه | نسخه پایه |
پیش از امتیازدهی، دامنه را یکسان کنید. یعنی هزینه آزمون و انتشار را از مجری الف بپرسید و به عددش اضافه کنید. شاید بعد از این کار هنوز ارزانتر باشد، شاید هم نه. گران‌تر بودن پیشنهاد ب هم به‌خودی‌خود مزیت نیست.
مالکیت کد، داده و حساب‌ها چگونه روشن شود؟
مالکیت را قبل از امضا روشن کنید، در متن قرارداد و فهرست اقلام تحویل؛ نه در روزهای آخر پروژه. سورس کد یعنی فایل‌های قابل ویرایش برنامه که تیم بعدی بتواند تغییرشان بدهد. تحویل سورس کد اپلیکیشن با تحویل فایل نصب فرق دارد. با فایل نصب حتی یک دکمه را هم نمی‌توانید عوض کنید.
مالکیت به تفکیک: وضعیت کد اختصاصی، اجزای آماده‌ای که مجری در چند پروژه به کار می‌برد، طرح‌ها، داده و مستندات جداگانه نوشته شود. برای اجزای ثالث، محدودیت مجوز را ثبت کنید.
فهرست اقلام تحویل: کد همراه با تاریخچه تغییرات، دستور ساخت نسخه و تنظیمات لازم برای اجرا. زمان انتقال دسترسی و ارتباطش با پرداخت‌ها هم مشخص باشد.
حساب‌ها: حساب انتشار در فروشگاه‌ها، زیرساخت و خدمات بیرونی. برای هر حساب، مالک، مدیر دسترسی و مسئول تمدید معلوم باشد.
ثبت حساب به نام شما فقط نیمی از کار است. بپرسید انتقالش در عمل چطور انجام می‌شود و فروشگاه یا ارائه‌دهنده سرویس چه محدودیتی دارد. در انتخاب شرکت طراحی اپلیکیشن، مجری‌ای که از نوشتن این جزئیات طفره می‌رود، علامت هشدار است.
اپلیکیشنی که کد و حساب‌هایش دست شما نیست، هنوز کاملاً مال شما نیست.
کلید امضای نسخه را هم جدی بگیرید. فروشگاه با این کلید تشخیص می‌دهد که به‌روزرسانی از طرف همان ناشر قبلی آمده است. اگر گم شود یا فقط دست مجری بماند، انتشار نسخه بعدی به دردسر جدی می‌افتد. شیوه تحویل امن، محل نگهداری و محدودیت‌های انتقالش را بپرسید. فرستادن رمزها در پیام‌رسان روش تحویل نیست.
بندهای حساس مالکیت و مجوز را به مشاور حقوقی بسپارید. این چک‌لیست فقط نشان می‌دهد چه چیزی باید در قرارداد باشد و جای قرارداد اختصاصی شما را نمی‌گیرد.
از مجری بخواهید ساخت نسخه را با دستورالعمل تحویلی در محیطی تازه نشان دهد. وابستگی پنهان به رایانه یک توسعه‌دهنده می‌تواند انتقال پروژه را متوقف کند.
کیفیت تحویل و پذیرش پروژه چگونه سنجیده شوند؟
کیفیت تحویل را با معیار پذیرش بسنجید. معیار پذیرش شرطی قابل آزمون است که پیش از اجرا می‌نویسید و تأیید هر خروجی به آن بسته است. ظاهر خوب به‌تنهایی معیار تحویل نیست.
یک معیار پذیرش فرضی برای پرداخت این است: اگر ارتباط هنگام پرداخت قطع شد، برنامه وضعیت تراکنش را از سرور پیگیری کند و سفارش تکراری نسازد. نتیجه مورد انتظار و محیط آزمون هم کنارش ثبت شود. در بازبینی‌ها، این همان سناریویی است که بیش از بقیه سراغش می‌روم.
مدرک آزمون: سناریوهای آزمون، فهرست دستگاه‌ها و نسخه‌های هدف، گزارش خطاها و وضعیت رفع خطاهایی که جلوی انتشار را می‌گیرند.
سرعت و ظرفیت: شرایط اندازه‌گیری و حد توافق‌شده؛ مثلاً زمان باز شدن صفحه اصلی روی دستگاه میان‌رده با اینترنت معمولی. واژه‌هایی مثل «سریع» یا «بدون باگ» را نمی‌شود سنجید.
روند تحویل: تحویل آزمایشی، مدت فرصت بررسی شما و تأیید مرحله‌به‌مرحله.
یک نکته را جدا نگه دارید.
پذیرفته شدن اپلیکیشن در فروشگاه انتشار به معنای تأیید کارکردش نیست. فروشگاه قوانین خودش را بررسی می‌کند؛ درستی مسیر سفارش را شما باید تأیید کنید.
درباره امنیت هم جمله «اپلیکیشن ما امن است» کافی نیست. برای اینکه بدانید پیش از انتخاب شرکت طراحی اپلیکیشن چه شواهدی بخواهید، مطلب اهمیت امنیت در طراحی اپلیکیشن‌های موبایلی را بخوانید.
پشتیبانی و امکان تغییر مجری را چگونه ارزیابی کنیم؟
پشتیبانی را با پیش‌نویس توافق پشتیبانی ارزیابی کنید، نه با وعده «همیشه در دسترسیم». اول ببینید چهار نوع کار از هم جدا شده‌اند یا نه:
رفع نقص نسبت به تعهد اولیه
افزودن قابلیت جدید
سازگاری با نسخه‌های تازه سیستم‌عامل
نگهداری زیرساخت
هرکدام شرایط هزینه خودش را دارد. فرض کنید چند ماه بعد از انتشار، نسخه تازه‌ای از اندروید بیاید و یک صفحه درست باز نشود. این رفع نقص است یا کار تازه؟ اگر مرزها روشن نباشد، سر هر درخواست بحث تازه‌ای پیش می‌آید.
در پیش‌نویس توافق، ساعت پوشش، سطح‌بندی شدت خطا، کانال ثبت درخواست و مسئول پاسخ را پیدا کنید. حواستان باشد زمان پاسخ با زمان رفع مشکل یکی نیست. «ظرف دو ساعت پاسخ می‌دهیم» یعنی کسی پیامتان را می‌بیند، نه اینکه مشکل حل شده است.
امکان تغییر مجری را هم از همان روز اول بسنجید. اگر همکاری تمام شود، تیم بعدی می‌تواند پروژه را بسازد و اجرا کند؟ مدرکش راهنمای راه‌اندازی، فهرست وابستگی‌ها و برنامه انتقال دانش است.
مسئول پشتیبان‌گیری از داده و آزمون بازیابی هم باید معلوم باشد. نسخه پشتیبانی که هیچ‌وقت بازگردانی‌اش امتحان نشده، فقط احساس امنیت می‌دهد.
پیش از جلسه انتخاب، این مدارک را از هر مجری بخواهید تا قبل از امتیازدهی دستتان باشد:
جدول نقش‌ها و میزان مشارکت هر نفر
پیشنهاد فنی همراه با موارد خارج از تعهد
برنامه مرحله‌ای با فرض‌ها و وابستگی‌ها
بند پیشنهادی مالکیت و فهرست اقلام تحویل
نمونه سناریوی آزمون و گزارش خطا
پیش‌نویس توافق پشتیبانی
اگر مجری به دلیل محرمانگی نمی‌تواند مدرکی را نشان بدهد، نمونه بینام یا نمایش کنترلشده در جلسه را پیشنهاد کنید. این راه هم حق مشتری قبلی را حفظ می‌کند و هم شما را بی‌مدرک نمی‌گذارد.
چگونه به پیشنهادها امتیاز بدهیم و جلسه نهایی بگیریم؟
به هر پیشنهاد با فرمی وزنی امتیاز بدهید که وزن‌هایش را پیش از دیدن پیشنهادها تعیین کرده‌اید. این کار مقایسه شرکت‌های طراحی اپلیکیشن را از سلیقه و حس‌وحال جلسه جدا می‌کند. پیشنهاد من این وزن‌هاست و می‌توانید متناسب با پروژه تغییرشان بدهید:
معیار | وزن |
|---|---|
نمونه‌کار | ۱۵ |
تیم | ۲۰ |
دامنه و برنامه | ۱۵ |
مالکیت و انتقال | ۱۵ |
پذیرش و امنیت | ۱۵ |
پشتیبانی | ۱۰ |
هزینه هم‌دامنه | ۱۰ |
جمع | ۱۰۰ |
برای نمره‌دهی، یک مقیاس ساده صفر تا پنج کافی است:
۰: مدرکی نداریم.
۱ تا ۲: مدرک هست، اما نقص مهمی دارد.
۳: کف نیاز پروژه با مدرک پوشش داده شده است.
۴: پوشش قوی و مستند.
۵: پوشش کامل نیاز با شواهد قابل بررسی.
نمره صفر یعنی «هنوز مدرکی نداریم»، نه اثبات ناتوانی. پیش از امتیاز نهایی، به مجری فرصت ارائه مدرک بدهید.
محاسبه ساده است. وزن هر معیار را در نمره‌اش ضرب و حاصل را بر پنج تقسیم کنید، بعد همه را جمع بزنید. مثلاً نمره چهار در معیار تیم با وزن بیست، شانزده امتیاز می‌شود. امتیاز کل از صد است.
اما امتیاز بالا نباید مانع قراردادی را پنهان کند. خط قرمزهای پروژه را پیش از امتیازدهی بنویسید؛ مثلاً نبود حق دسترسی لازم به کد یا نبود امکان تحویل مستقل. پیشنهادی که از خط قرمز رد شود، با هر امتیازی کنار می‌رود.
فرم را یک بار به‌صورت فایل قابل ویرایش و یک بار به‌صورت نسخه چاپی آماده کنید تا هر عضو تیم جداگانه پرش کند. ستون‌های پیشنهادی با یک ردیف فرضی:
مجری | معیار | مدرک دیده‌شده | نمره (۰ تا ۵) | امتیاز وزنی | ابهام باز |
|---|---|---|---|---|---|
مجری الف | تیم | جدول نقش‌ها | ۴ | ۱۶ | جایگزین مسئول فنی معلوم نیست |
جلسه نهایی را با دستور جلسه مشخص برگزار کنید: ابهام‌های بی‌پاسخ، فرض‌های پشت هزینه، تقسیم مسئولیت‌ها و شرایط پذیرش. صورت‌جلسه را به تأیید هر دو طرف برسانید و مبنای اصلاح پیشنهاد قرار بدهید. توافق شفاهی‌ای که به صورت‌جلسه نرسد، در عمل وجود ندارد.
اگر می‌خواهید همین هفته شروع کنید، این ترتیب را دنبال کنید:
وزن‌ها و خط قرمزهای پروژه را بنویسید و با تیم خودتان نهایی کنید.
فهرست مدارک را هم‌زمان برای همه مجری‌ها بفرستید.
یک مسیر کامل کاربر را برای امتحان نمونه‌کارها انتخاب کنید.
اگر نیاسا هم در فهرست گزینه‌هایتان است، خلاصه پروژه، قابلیت‌های ضروری، اتصال‌ها به سامانه‌های دیگر و محدودیت‌هایتان را بفرستید. بعد درباره دامنه و روش اجرا گفت‌وگو می‌کنیم؛ برآورد قطعی پیش از این بررسی معنایی ندارد. روند همکاری و جزئیات خدمت را در صفحه طراحی و ساخت اپلیکیشن موبایل در نیاسا می‌بینید.
این وزن‌ها یک الگوی تصمیم‌گیری‌اند، نه رتبه‌بندی علمی شرکت‌ها. برای محصول حساس، وزن امنیت و تداوم سرویس را پیش از دریافت پیشنهادها بیشتر کنید.
خلاصه‌ای از کاربران هدف، مسیرهای اصلی و محدودیت‌های پروژه بفرستید تا درباره دامنه کار و روش اجرای اپلیکیشن با نیاسا گفت‌وگو کنیم.
پرسش‌های پرتکرار
۴آیا تعداد زیاد نمونه‌کار برای انتخاب مجری کافی است؟
خیر. مرتبط بودن مسئله، نقش واقعی مجری و حضور افراد باتجربه در تیم پیشنهادی مهم‌تر است. یک مسیر کامل محصول را ببینید و درباره تصمیم‌ها و محدودیت‌های اجرای آن سؤال کنید.
تحویل سورس کد اپلیکیشن شامل چه چیزهایی است؟
فهرست دقیق باید در قرارداد مشخص شود. برای ادامه توسعه معمولاً کد قابل ویرایش، تاریخچه تغییرات، راهنمای ساخت و اجرا و دسترسی‌های مجاز لازم است. حق استفاده از اجزای ثالث و نحوه تحویل امن کلیدها نیز باید روشن باشد.
پیشنهاد ارزانتر را چه زمانی انتخاب کنیم؟
وقتی دامنه، شرایط تحویل و هزینههای جداگانه روشن باشند و مجری حداقلهای فنی و قراردادی شما را پوشش دهد. مبلغ اولیه پایینتر بدون احتساب آزمون، انتشار و پشتیبانی مبنای مناسبی برای تصمیم نیست.
اگر مجری به دلیل محرمانگی مدرک ارائه نکند چه کنیم؟
نمونه بینام، نمایش کنترلشده یا توضیح فنی بدون اطلاعات مشتری بخواهید. اگر همچنان شواهد کافی ندارید، آن معیار را تأییدنشده ثبت کنید و پیش از قرارداد درباره ریسک آن تصمیم بگیرید.
