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