برآورد پروژه‌های نرم‌افزاری یا چطور پروژه رو قیمت‌گذاری کنم؟

«یه نرم‌افزار برای ما بزنید، چند در میاد؟» این سوالِ خیلی کلی، زیاد از ما پرسیده می‌شد و همین باعث شد تا در این مطلب، از نحوه برآورد و اعلام قیمت‌ به مشتری، برای شما بنویسیم.

تحلیل اولیه

یکی از ساده‌ترین روش‌هایی که معمولا وجود دارد برای اینکه یه نفر به ما بگوید که دقیقا چه چیزی نیاز دارد، این‌ است که یک نمونه کپی از محصولی که می‌خواهد و لینک یا نمونه کاتالوگ آن را برای ما ارسال کند. روش دیگر هم جلسه حضوری و یا مجازی و پرسش و پاسخ است. گاهی هم مشتری در قالب یک پروپوزال یا توضیحات صوتی و یا حتی ویدئویی نیاز یا هدف خود را برای ما شرح می‌دهد.

بک‌لاگ یا لیست قابلیت‌ها و امکانات

زمانی که ما متوجه نیازمندی‌های پروژه و تفکر کارفرما شدیم، فرایند‌ها را در لایه‌ی اول ترسیم کرده و بسته به ارزش پروژه، جزییات را به فرایند‌ها اضافه می‌کنیم. امکانات یا فیچر‌های نرم‌افزار را در کارت‌هایی می‌نویسیم. بعد از اتمام کلیه امکانات آن‌ها را از دو بُعد زمان اجرایی(فاز یا اسپرینت) و بخش (مانند فاز تحلیل یا فاز طراحی و …) دسته‌بندی می‌کنیم.

فیچر‌ها باید به تسک‌های ریز تبدیل شوند و در یک فایل اکسل به شکل زیر قرار گیرند. در این فایل باید میزان نفر‌ساعت هر تسک و نقشی که باید آن را انجام دهد مشخص شود. به طور مثال یک صفحه تماس با ما نیاز به طراحی، برنامه‌نویس سمت کاربر و برنامه‌نویس سمت بَکِند دارد. البته کارها از نظر پیچیدگی نیز به سطوح مختلفی از تخصص نیاز دارند.

دسته‌بندی و زمانبندی و نفر‌ساعت نقش‌ها

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

برآورد نهایی و تیپِ قرارداد

این برآورد ها دو حالت دارد. اول اینکه رقم ثابت قرارداد شود و شرح خدمات عینا مطابق قرارداد پیش رود و حالت دوم اینکه صرفا یک برآورد باشد و در صورت وضعیت‌های پروژه، قیمت دقیق هر فاز از پروژه مشخص شود (البته در تعامل با شرکت‌های دولتی نمی‌تواند بیش از ۲۵ درصد از برآورد اولیه انحراف داشته باشد) و پایان پروژه قیمت دقیق پروژه مشخص می‌شود (این البته منوط به این مورد است که شرح خدمات و جزییات اولیه به صورت کامل در قرار داد اولیه قید شود). در یک پروژه کارفرما یک نمونه اولیه از ما خواست و همین مشخص نبودن دقیق محدوده پروژه، حجم پروژه آنقدر بالا رفت که به جای دو ماه، هفت ماه به طول انجامید و باعث شد در برنامه‌ریزی‌های بعدی آن تیم کلا با مشکل مواجه شویم وضرر قابل توجهی متحمل شویم.

تغییر محدوده پروژه یک امر طبیعی‌ست اما…

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

هزینه‌های دیگری کارفرما به آن‌ها توجه نمی‌کند

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

با کارفرمایی کار می‌کنیم که…

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

جمع بندی

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

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

از این دست مقالات را در سایت اینوسافت هم می‌توانید از من مطالعه کنید.