فهرست مطالب
سفارش ساخت نرمافزار با یک سند شروع میشود، نه با یک قرارداد: شرح نیازی که مسئله، کاربران، دادهها و معیارهای موفقیت را مشخص میکند. پس از آن، یک مرحله‌ی کوتاه شناخت یا نمونهی اولیه، قراردادی که مالکیت کد و شیوه‌ی پذیرش را تعیین میکند، آزمون پذیرش با دادههای واقعی و برنامه‌ی پشتیبانی پس از تحویل قرار دارد. بیشتر پروژه‌هایی که به نتیجه‌ی مورد انتظار نمی‌رسند، در مرحله‌ی اول، یعنی شرح نیاز، از مسیر خارج شده‌اند.
بنیان‌گذار آرتینکست در یک کلاس طراحی وب، تکلیفی داشت با یک جمله شرح نیاز: یک وب‌سایت بسازید. بیشتر هم‌کلاسی‌ها وقتی تب‌ها کار کردند، کار را تمام کردند. او تا ساعت ۳ بامداد کار کرد و ساعت ۸ صبح دوباره پشت سیستم بود، چون می‌خواست انتقال‌ها نرم‌تر باشند. هر دو نتیجه با شرح نیاز تطبیق داشتند. شرح نیازی که «تمام‌شده» را تعریف نکند، هر دو نتیجه را می‌پذیرد، و سفارشدهنده تا روز تحویل نمی‌داند کدام‌یک را دریافت خواهد کرد.
پیش از سفارش: آیا نرمافزار اختصاصی لازم است
پیش از سفارش ساخت نرمافزار، سه گزینه‌ی ارزان‌تر را بررسی کنید: یک نرمافزار آماده که با کمی تنظیم نیاز شما را برطرف میکند، قابلیتی در نرمافزارهایی که همین حالا استفاده می‌کنید و از آن استفاده نمی‌شود، یا یک فایل Excel منظم با چند قاعده‌ی مشخص. اگر یکی از این‌ها مسئله را حل میکند، به نرمافزار اختصاصی نیازی ندارید و به ما یا شرکتی مانند ما نیز نیازی ندارید.
نرمافزار اختصاصی زمانی ارزش ساخت دارد که فرآیند کاری شرکت با قواعد خود شرکت انجام میشود، دادهها میان چند نرمافزار بهصورت دستی منتقل می‌شوند یا خطای دستی در یک کار تکراری هزینهی مشخصی ایجاد میکند. مقاله‌ی دیجیتالی‌سازی شرکت‌های فنی و مهندسی شیوه‌ی انتخاب اولین فرآیند برای این کار را توضیح می‌دهد.
نوشتن شرح نیاز برای سفارش ساخت نرمافزار
شرح نیاز، مسئله را توضیح می‌دهد، نه راهحل را. «یک داشبورد می‌خواهیم» یک راهحل است. «مدیر پروژه هر هفته چند ساعت گزارش‌های چند نرمافزار را دستی در Excel ادغام میکند و ارقام آن با هم تطبیق ندارند» یک مسئله است، و سازنده بر اساس آن می‌تواند راهحل مناسب را پیشنهاد دهد. اگر راه‌حلی از پیش در ذهن دارید، آن را به مسئله‌ای که قرار است حل کند تبدیل کنید.
یک شرح نیاز کامل این موارد را مشخص میکند:
- روند کاری فعلی: چه کاری، توسط چه کسی، با چه نرم‌افزاری و با چه تکراری انجام میشود.
- کاربران: چند نفر، با چه نقش‌هایی و با چه سطحی از آشنایی با نرمافزار.
- دادهها: ورودیها و خروجیها، قالب فایل‌ها و نرمافزارهایی که باید با سیستم جدید ارتباط داشته باشند.
- محدودیتها: زیرساخت، امنیت، نسخه‌ی نرمافزارهای موجود و بودجه.
- معیارهای موفقیت: معیارهای قابلاندازهگیری، مانند زمان انجام یک کار یا تعداد خطاها، که در آزمون پذیرش بررسی می‌شوند.
- آنچه خارج از محدوده است: کارهایی که در این مرحله ساخته نمیشوند.
بند آخر به اندازه‌ی بقیه اهمیت دارد. هرچه خارج از محدوده تعریف نشود، در طول پروژه به محدوده اضافه میشود و زمان و هزینهی آن نیز افزایش می‌یابد.
مرحله‌ی شناخت و نمونهی اولیه پیش از ساخت کامل
در پروژه‌هایی که مسئله هنوز کامل صورت‌بندی نشده، یک مرحله‌ی کوتاه و جداگانه پیش از ساخت کامل، ریسک اصلی را حذف میکند. راهنمای خدمات دیجیتال دولت بریتانیا این مرحله را Discovery می‌نامد: درک کاربران، محدودیتها و معیارهای موفقیت، بدون شروع ساخت. خروجی آن یک تصمیم است، اینکه پروژه ادامه پیدا کند یا خیر، و توقف در این مرحله نیز یک نتیجه‌ی قابل‌قبول است.
پس از آن، یک نمونهی اولیه یا MVP با کمترین قابلیت‌های لازم ساخته میشود و با دادهها و کاربران واقعی آزمایش میشود. نمونه‌سازی مرحلهای مشخص میکند چه چیزی کار میکند، چه چیزی نیاز به تغییر دارد و چه چیزی اساساً نباید ساخته شود، پیش از آنکه سرمایه‌گذاری کامل انجام شود. جزئیات این مرحله در مقاله‌ی ساخت MVP برای ابزارهای داخلی آمده است.
برآورد هزینه و مدل پرداخت
دو مدل اصلی قیمت‌گذاری وجود دارد. در قیمت ثابت، محدوده و هزینه پیش از شروع تعیین می‌شوند و هر تغییر به توافق جداگانه نیاز دارد. این مدل زمانی مناسب است که شرح نیاز کامل و پایدار باشد. در پرداخت بر اساس زمان، هزینه بر اساس ساعت‌های کار محاسبه میشود و محدوده می‌تواند در طول پروژه تغییر کند. این مدل برای پروژه‌هایی مناسب است که هنوز بخشی از نیاز در حال شکلگیری است.
در هر دو مدل، پرداختها را به مراحل تحویل و پذیرش وابسته کنید، نه به گذشت زمان. هر مرحله یک خروجی مشخص و قابل‌آزمون دارد و پرداخت آن پس از پذیرش همان خروجی انجام میشود. برآوردی که پیش از مرحله‌ی شناخت داده شود، فقط یک حدس است و باید پس از آن به‌روز شود.
قرارداد ساخت نرمافزار و مالکیت کد
پرداخت هزینهی ساخت، الزاماً به معنای مالکیت کد نیست. در بسیاری از قوانین، مالکیت فکری کد نزد سازنده باقی می‌ماند، مگر آنکه قرارداد به‌صراحت آن را منتقل کند، و سازندگان گاهی فقط حق استفاده می‌دهند، به‌ویژه زمانی که بخش‌هایی از کد قبلی خود را در پروژه به کار می‌برند. اگر مالکیت برای شما اهمیت دارد، باید در قرارداد نوشته شود.
قرارداد این موارد را نیز مشخص میکند: تحویل کد منبع و مستندات در پایان هر مرحله، تکلیف کتابخانه‌های متن‌باز و کدهای شخص ثالث به‌کاررفته، محرمانگی دادههای شرکت، دوره‌ی رفع خطای پس از تحویل و شرایط خاتمه‌ی قرارداد پیش از پایان پروژه. اگر نگران ادامه‌ی فعالیت سازنده هستید، سپردن کد منبع نزد شخص ثالث (Escrow) یک گزینه است. قواعد مالکیت فکری در هر کشور متفاوت است و متن نهایی قرارداد را باید یک مشاور حقوقی بررسی کند.
آزمون پذیرش نرمافزار
آزمون پذیرش نقطه‌ای است که سفارشدهنده تأیید میکند نرمافزار با شرح نیاز تطبیق دارد. این آزمون بر اساس همان معیارهای موفقیتی انجام میشود که در شرح نیاز نوشته شده‌اند، با دادههای واقعی شرکت و توسط کاربرانی که قرار است هر روز با نرمافزار کار کنند، نه فقط توسط مدیری که آن را سفارش داده است.
خطاهای پیدا‌شده در یک فهرست مکتوب ثبت می‌شوند، با اولویت هرکدام و اینکه رفع کدام‌یک پیش از پذیرش الزامی است. پذیرش بهصورت مکتوب اعلام میشود و پرداخت آن مرحله پس از آن انجام میشود. معیار موفقیتی که از ابتدا نوشته نشده باشد، در این مرحله به یک اختلاف نظر تبدیل میشود.
پشتیبانی، نگه‌داری و تحویل دانش
نرمافزار پس از تحویل نیز تغییر میکند. نرمافزارهایی که با آن ارتباط دارد نسخه‌ی جدید منتشر می‌کنند، کاربران نیازهای تازه پیدا می‌کنند و خطاهایی ظاهر می‌شوند که در آزمون دیده نشدهاند. افزونه‌ای که برای Revit ساخته شده، با هر نسخه‌ی سالانه‌ی Revit باید بررسی و در صورت نیاز دوباره ساخته شود.
پیش از امضای قرارداد، شیوه‌ی پشتیبانی را مشخص کنید: زمان پاسخ به خطاها، هزینهی تغییرات و به‌روزرسانی‌ها، و مستنداتی که تحویل داده می‌شوند تا تیم دیگری نیز در آینده بتواند کار را ادامه دهد. معیارهای انتخاب شرکت سازنده در مقاله‌ی انتخاب شرکت توسعه پلاگین رویت آمده است، و ساخت ابزارهای اختصاصی برای تیم‌های فنی در صفحه‌ی هوشمندسازی فرآیند کاری توضیح داده شده است.
جمع‌بندی
سفارش ساخت نرمافزار با شرح نیازی شروع میشود که مسئله، کاربران، دادهها، معیارهای موفقیت و محدوده را مشخص میکند. یک مرحله‌ی شناخت یا نمونهی اولیه ریسک اصلی را پیش از ساخت کامل حذف میکند، قرارداد مالکیت کد و شیوه‌ی پذیرش را تعیین میکند و آزمون پذیرش بر اساس همان معیارها انجام میشود. «یک وب‌سایت بسازید» هم با چند تب کارکردی تطبیق دارد و هم با چیزی کاملاً فراتر از آن، و شرح نیاز تنها جایی است که این تفاوت مشخص میشود. اولین چیزی که می‌خواهید تغییر کند چیست؟
پرسش‌های متداول
برای سفارش ساخت نرمافزار از کجا شروع کنیم؟
از نوشتن شرح نیاز: روند کاری فعلی، کاربران، دادهها، محدودیتها، معیارهای موفقیت و آنچه خارج از محدوده است. این سند پایهی برآورد، قرارداد و آزمون پذیرش است.
شرح نیاز نرمافزار باید شامل چه مواردی باشد؟
توضیح مسئله بهجای راهحل، کاربران و نقشهای آنها، ورودیها و خروجیها، نرمافزارهایی که سیستم باید با آنها ارتباط داشته باشد، معیارهای قابلاندازهگیری موفقیت و کارهایی که در این مرحله ساخته نمیشوند.
قیمت ثابت بهتر است یا پرداخت بر اساس زمان؟
قیمت ثابت برای پروژهای با شرح نیاز کامل و پایدار مناسب است. پرداخت بر اساس زمان برای پروژهای مناسب است که بخشی از نیاز هنوز در حال شکلگیری است. در هر دو حالت، پرداختها را به پذیرش مراحل وابسته کنید.
آیا با پرداخت هزینه، مالک کد نرمافزار می‌شویم؟
الزاماً خیر. در بسیاری از قوانین، مالکیت فکری کد نزد سازنده می‌ماند، مگر آنکه قرارداد آن را به‌صراحت منتقل کند. انتقال مالکیت و تحویل کد منبع باید در قرارداد نوشته شوند.
آزمون پذیرش نرمافزار چیست؟
مرحلهای که سفارشدهنده بر اساس معیارهای شرح نیاز و با دادههای واقعی بررسی میکند نرمافزار با نیاز تطبیق دارد یا خیر. پذیرش بهصورت مکتوب اعلام میشود و پرداخت مرحله پس از آن انجام میشود.
چرا پیش از ساخت کامل، نمونهی اولیه بسازیم؟
نمونهی اولیه با هزینهی کمتر مشخص میکند کدام فرضها درستاند و کدام قابلیتها اساساً لازم نیستند، پیش از آنکه بودجهی اصلی صرف ساخت آنها شود.
پس از تحویل نرمافزار به چه پشتیبانیای نیاز داریم؟
رفع خطاهایی که در آزمون دیده نشدهاند، بهروزرسانی با نسخههای جدید نرمافزارهای مرتبط و تغییرات تازه. زمان پاسخ، هزینه و مستندات تحویلی را پیش از قرارداد مشخص کنید.