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