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