نحوه ارزیابی برآورد هزینه نرم افزار (برای افراد غیر فنی)

ارزیابی یک پروژه نرم افزاری و تعیین قیمت بر روی آن بسیار سخت است.

در مقاله برخی از چالش ها و چگونگی ارزیابی برآورد هزینه نرم افزار.
معرفی

بر اساس گزارش آشوب، که اغلب به آن اشاره می شود، حدود 30 درصد از تمام پروژه های نرم افزاری با شکست مواجه می شوند. این بدان معناست که یا مدت زمان پروژه خیلی طولانی می شود یا بودجه حفظ نمی شود.

در اینجا چند چالش در پروژه های نرم افزاری وجود دارد:

1) بررسی الزامات دقیق دشوار است

اگر می‌خواهید یک خانه بزرگ سفارشی بسازید، فقط در صورتی که هر قسمت از کار به درستی ارزیابی شود، قیمت آن ثابت می‌شود. تا آخرین پیچ که استفاده خواهد شد.

معمار طرحی را با یک نقشه دقیق ایجاد می کند که در آن کل خانه یا روی کاغذ یا اغلب امروزه به عنوان مدل سه بعدی تکرار می شود. و در این برنامه ها می توان محاسبه کرد که برای ساخت خانه به چند پیچ ​​و … نیاز خواهد بود.

با این اطلاعات می توان تخمین دقیقی برای پروژه ساخت خانه داد.

اما ما همچنین می دانیم: در پروژه های ساختمانی بسیار بزرگ، تخمین قیمت معمولاً درست نیست. و آنچه قرار بود 500 میلیون یورو هزینه داشته باشد، در نهایت 5 میلیارد یورو یا بیشتر هزینه خواهد داشت. فرودگاه برلین، Elbphilharmonie در هامبورگ و ایستگاه اصلی قطار در اشتوتگارت، آلمان سه نمونه هستند که در بیشتر موارد هزینه آن یک میلیارد یورو یا بیشتر کاهش یافته است.

در مورد ایستگاه اصلی قطار در اشتوتگارت، هزینه معمار حدود 36 میلیون یورو بود. با وجود اینکه به معمار چنین مبلغ بالایی دستمزد گرفته شده است. برآورد هزینه پروژه حدود 1 میلیارد یورو کاهش داشت.

چالش های مشابهی را می توان در پروژه های نرم افزاری مشاهده کرد.

به خصوص زمانی که افراد غیر فنی درگیر انتقال الزامات نرم افزار یا پروژه وب هستند. معمولاً توضیحات پروژه فقط چند خط در یک ایمیل قرار می گیرد. یا تماس تلفنی که در آن راه حل مورد نیاز مشخص شده است.

برخی از وب سایت های نمونه برای مرجع ارائه خواهد شد. به ندرت این وب سایت های نمونه طی سالیان متمادی با هزینه صدها هزار یورو، گاهی میلیون ها، ساخته شده اند.

اما بودجه برنامه وب یا راه حل نرم افزاری حدود 4000 تا 40000 یورو خواهد بود و باید ظرف 2 ماه حداکثر 3 ماه ساخته شود. (این آرزو معمولاً توسط شخصی غیر فناوری اطلاعات است که در مورد قیمت سؤال می کند).

واقعیت این است: بدون سند استعلام دقیق از سوی مشتری که حدود 10 تا 50 صفحه خواهد بود و یک پروپوزال دقیق توسط شرکت فناوری اطلاعات ایجاد شده بر اساس آن سند استعلام شده، نمی توان قیمت پروژه را تعیین کرد.

و حتی اگر سند پیشنهادی دقیقی وجود داشته باشد. معمولاً نیازمندی‌ها در طول پروژه تغییر می‌کنند، که این تمرین ایجاد پیشنهاد، که می‌تواند هفته‌ها طول بکشد، به یک کار غیر ضروری تبدیل می‌کند.

2) تغییر الزامات در طول پروژه

تقریباً هیچ پروژه فناوری اطلاعات وجود ندارد، جایی که پروژه نرم افزاری که در ابتدا نقل قول شده بود، در طول پروژه ثابت می ماند.

دلیل آن این است که تنها زمانی که نرم افزار شروع به شکل گیری می کند، مشتری متوجه می شود که چیزهای مهمی از دست رفته است که بدون آنها پروژه نمی تواند موفقیت آمیز باشد و نرم افزار به فرآیندهای تجاری کمک نمی کند.

اما اگر قیمت ثابتی توافق شده باشد چه؟ چگونه ارائه دهنده خدمات فناوری اطلاعات می تواند تغییرات را در طول پروژه مجاز کند. این تقریبا غیرممکن است، زیرا در این صورت ارائه دهنده خدمات فناوری اطلاعات هیچ سودی نخواهد داشت.

از طرف دیگر، مشتری بر قیمت ثابت پافشاری می کند و می گوید: «برای این تغییر کوچک نیازی به تغییر بودجه نیست. این درخواست تغییر کوچک را می توانید در نقل قول اولیه قرار دهید.

و معمولاً معضل از اینجا شروع می شود. این بحث در مورد درخواست های تغییر ادامه خواهد داشت. و پروژه گیر می کند.

بنابراین همیشه بهتر است بودجه پروژه سیال بماند. جایی که مشتری به اندازه نیاز توسعه نرم افزار پرداخت می کند. -> البته، این می تواند برای مشتری “مثل بهشتی برای شرکت نرم افزاری” به نظر برسد، زیرا او فکر می کند که ساعات کاری آنها بیشتر از حد لازم است.

اما آن را با یک رستوران مقایسه کنید. اگر یک کوکاکولا یا یک استیک اضافی سفارش دهید، باید برای آن چیز اضافی نیز بپردازید. چرا باید در توسعه نرم افزار متفاوت باشد؟ به خصوص در فناوری اطلاعات که معمولاً نرخ ساعتی بسیار بالاتر است.

3) مشکل در درک پیچیدگی های توسعه نرم افزار توسط افراد غیر IT

درک پیچیدگی‌های توسعه نرم‌افزار معمولاً برای یک فرد غیر فناوری اطلاعات بسیار دشوار است.

“دوست من این یک وب سایت را در یک روز ساخت و دارای ویژگی های زیادی است، چرا شما به عنوان یک متخصص به بیش از 6 ماه برای توسعه این ویژگی ها نیاز دارید؟”

به احتمال زیاد آن دوست از سیستم مدیریت محتوا مانند وردپرس یا دروپال استفاده کرده و از چند پلاگین استاندارد استفاده کرده است که معمولاً عملکردهای زیادی را به همراه دارند. اما اینها راه حل های نرم افزاری سفارشی ساخته شده برای دوست نیستند. اینها سیستم‌ها و افزونه‌هایی هستند که معمولاً توسط هزار و صد هزار نفر استفاده می‌شوند و نیازمندی‌های مشابهی دارند. این راه حل های سفارشی نیستند.

اما: ساخت این پلاگین ها به احتمال زیاد به 2 تا 5 یا بیشتر توسعه دهندگان تمام وقت برای چندین ماه یا حتی سال نیاز دارد. بنابراین با وجود اینکه دوست از راه حل های به ظاهر ساده استفاده می کند. آنها در یک توسعه نرم افزاری بسیار پیچیده ایجاد شده اند.

بنابراین در صورتی که مشتری نیازهایی داشته باشد که می تواند توسط آن افزونه ها و “راه حل های آماده” برآورده شود. سپس بهتر است از آنها استفاده کنید. اما در بیشتر موارد، این سیستم‌های نرم‌افزاری «آماده» چیزی نیستند که مشتری نیاز دارد.

بهترین مثال موتور جستجوی گوگل است. در قسمت جلویی (آنچه کاربر می بیند) فقط یک نوار جستجو و دو دکمه وجود دارد. بنابراین یک فرد غیر IT می گوید: «توسعه این کار فقط یک هفته طول می کشد. فقط یک نوار جستجو و دو دکمه وجود دارد. در واقعیت، بسیاری از قابلیت‌های بک‌اند «پنهان» وجود دارد که توسط هزاران و هزاران توسعه‌دهنده و طی سال‌های متمادی توسعه یافته‌اند.

بسته به پیچیدگی، نیازهای مقیاس‌پذیری و غیره پروژه مشتری، توسعه نرم‌افزار می‌تواند بیش از حد انتظار زمان ببرد.
راه حل های ممکن

راه‌حل‌هایی وجود دارد که چگونه یک فرد غیر فناوری اطلاعات می‌تواند با ارائه‌دهنده خدمات فناوری اطلاعات به سؤال مراجعه کند.

1) یک توسعه دهنده نرم افزار را درگیر کنید

در حالت ایده‌آل، یک توسعه‌دهنده نرم‌افزار داخلی یا متخصص فناوری اطلاعات وجود خواهد داشت که می‌تواند برآورد را توسط شرکت خدمات فناوری اطلاعات بررسی کند.

معمولاً آن توسعه‌دهنده نرم‌افزار توصیه می‌کند که محدوده پروژه را انعطاف‌پذیر نگه دارد، تا بتوان تغییرات را تطبیق داد.

اگر برآورد شرکت نرم افزاری قابل قبول باشد، توسعه دهنده نرم افزار چراغ سبز نشان می دهد.

به این ترتیب، همانطور که یک کارمند داخلی در حال ارزیابی پروژه است، فرد غیر فناوری اطلاعات نیز از تلاش های انجام شده برای توسعه متقاعد خواهد شد.

2) استفاده از Dedicated Developer

توسعه دهنده اختصاصی، توسعه دهنده ای است که به صورت تمام وقت در اختیار مشتری قرار می گیرد.

مزیت این کار این است که توسعه دهنده از نزدیک با مشتری و همچنین با تیم مشتری کار می کند. این باعث افزایش شفافیت می شود. و مشتری یا تیم می توانند سوالاتی بپرسند و پاسخ های زمان واقعی را دریافت کنند.

این مدل به روش های مختلفی کار می کند:

در محل: شرکت خدمات فناوری اطلاعات از توسعه‌دهنده می‌خواهد به محل مشتری برود و در محل مشتری کار کند.
برون سپاری فناوری اطلاعات: تیمی از توسعه دهندگان در محل شرکت خدمات فناوری اطلاعات کار می کنند.
برون سپاری Nearshore: توسعه دهنده اختصاصی در محل یک ارائه دهنده خدمات فناوری اطلاعات در یک کشور مجاور کار می کند. برای سوئد، لهستان یا اوکراین خواهد بود. برای ژاپن که مالزی یا چین خواهد بود.
برون سپاری فراساحلی: در اینجا توسعه دهنده در محل یک شرکت نرم افزاری در کشوری دور می نشیند. به عنوان مثال می توان به هند، پاکستان و غیره اشاره کرد. اما کلمات Nearshore یا Offshore را می توان به جای یکدیگر به کار برد. بستگی به این دارد که مشتری در کجا قرار دارد. اگر مشتری در ژاپن باشد، هند یک مقصد برون سپاری نزدیک به ساحل است.

مشتری می تواند تا زمانی که بخواهد از توسعه دهنده اختصاصی استفاده کند. تا پروژه تمام شود. در صورتی که پروژه بیش از حد طول بکشد. مشتری و تیم می‌توانند با توسعه‌دهنده صحبت کنند که برای رسیدن به اهداف سریع‌تر از کدام راه استفاده کنند.

3) از پروژه های قیمت ثابت سفت و سخت اجتناب کنید

قیمت ثابت معمولا ایده خوبی نیست. فقط در صورتی که پروژه بسیار کوچک باشد. مانند یک وب سایت یک صفحه ای یا مشابه.

قیمت های ثابت می تواند منجر به این امید کاذب شود که همه چیز در آن قیمت انجام می شود. (حتی All You Can-Eat به این شکل کار نمی کند. شما می توانید هر چقدر که می خواهید بخورید، اما فقط برای یک وعده. نه برای روزهای متوالی. اما این همان چیزی است که مشتریان انتظار دارند، زمانی که قیمت ثابتی دریافت می کنند. توسعه نرم افزار)

بهتر است به سراغ قیمت‌گذاری چابک بروید، جایی که زمان و تلاش ارائه‌دهنده نرم‌افزار بر اساس میزان تلاشی که برای توسعه انجام می‌شود، پاداش می‌گیرد.

یا از یک توسعه دهنده اختصاصی یا تیمی از متخصصان نرم افزار اختصاصی برای کار روی پروژه خود استفاده کنید.

نتیجه

بسیاری از پروژه های نرم افزاری با شکست مواجه می شوند، زیرا درک درستی از آنچه توسعه نرم افزار سفارشی مستلزم آن است وجود ندارد. پروژه های به ظاهر آسان، ممکن است هفته ها و ماه ها طول بکشد.

بنابراین باید برخی از ارزیابی ها توسط مشتری انجام شود. محدوده هزینه توسعه نرم افزار چقدر است و ارزش تجاری ایجاد شده توسط آن چقدر است. آیا ارزش کسب و کار ایجاد شده بسیار بیشتر از بودجه مورد نیاز برای توسعه نرم افزار است؟ خوب، پس خوب است که برویم. پروژه را شروع کنید.

اگر ارزش تجاری ایجاد شده و هزینه با هم مطابقت نداشته باشند. پس شاید بهتر است با پرداخت هزینه ماهانه کم، از راه حل های دستی، فایل های اکسل یا نرم افزارهای استاندارد یا راه حل های تحت وب استفاده کنید که می توانید مشترک شوید.