دقیقه
16 مهر 1405تصمیم برای ساخت نرم‌افزار اختصاصی فقط شروع کار است. اگر بدون تعریف مسئله، کاربران، فرآیندها و محدوده نسخه اول وارد مذاکره با تیم توسعه شوید، معمولاً برآوردها قابل مقایسه نیستند و در طول پروژه هم اختلاف درباره اینکه «چه چیزی قرار بود ساخته شود» بیشتر می‌شود.
لازم نیست قبل از شروع یک سند فنی صدصفحه‌ای بنویسید یا معماری سیستم را خودتان طراحی کنید. اما باید دانش کسب‌وکار را که فقط داخل سازمان شما وجود دارد، به شکل قابل‌فهم آماده کنید: مشکل چیست، چه کسانی با سیستم کار می‌کنند، امروز کار چگونه انجام می‌شود و نتیجه مطلوب چیست.
این راهنما یک Checklist عملی برای قبل از سفارش نرم‌افزار اختصاصی است؛ چیزهایی که آماده‌کردن آنها Discovery، برآورد هزینه، تعریف MVP و تحویل نهایی را دقیق‌تر می‌کند.
۱. اول مسئله را بنویسید، نه لیست امکانات را
شروع با جمله‌هایی مثل «سیستم باید Dashboard، گزارش، پیامک و اپ داشته باشد» سریعاً گفتگو را به Featureها می‌برد، درحالی‌که هنوز معلوم نیست مسئله اصلی چیست.
بهتر است ابتدا در چند جمله توضیح دهید امروز چه اتفاقی می‌افتد، چه مشکلی ایجاد می‌شود و چه نتیجه‌ای می‌خواهید. مثلاً «رزروها در چند فایل Excel ثبت می‌شوند، ظرفیت‌ها همزمان به‌روز نیستند و واحد مالی گزارش قابل اتکا ندارد» تعریف مسئله بسیار مفیدتری از «یک سامانه رزرو می‌خواهیم» است.
۲. هدف کسب‌وکار را مشخص کنید
نرم‌افزار باید روی یک نتیجه اثر بگذارد. کاهش زمان عملیات، حذف ورود تکراری داده، کاهش خطا، افزایش ظرفیت پاسخ‌گویی، ایجاد سرویس جدید یا شفاف‌شدن گزارش مدیریتی نمونه‌هایی از هدف‌اند.
اگر هدف روشن باشد، در زمان اختلاف بر سر Featureها می‌توان پرسید آیا این قابلیت واقعاً به هدف نسخه اول کمک می‌کند یا نه.
۳. کاربران و Roleها را فهرست کنید
فقط نگویید «کاربر و ادمین». در سازمان واقعی ممکن است اپراتور، مدیر واحد، مالی، پشتیبانی، مدیر سیستم، مشتری و مدیر ارشد هرکدام دسترسی متفاوت داشته باشند.
برای هر Role مشخص کنید چه کاری انجام می‌دهد، چه داده‌ای می‌بیند و چه عملیاتی نباید انجام دهد. این اطلاعات مستقیماً روی Permission Model و Scope پروژه اثر دارد.
۴. فرآیند فعلی را همان‌طور که واقعاً اجرا می‌شود مستند کنید
لازم نیست BPMN حرفه‌ای رسم کنید. یک فلوچارت ساده، چند Screenshot یا حتی مراحل شماره‌گذاری‌شده کافی است.
مهم این است که «فرآیند واقعی» ثبت شود، نه فقط فرآیندی که در آیین‌نامه نوشته شده. Exceptionها، تأییدهای تلفنی، فایل‌های جانبی و راه‌حل‌های دستی معمولاً همان جاهایی هستند که پیچیدگی نرم‌افزار را مشخص می‌کنند.
۵. فرآیند مطلوب را جدا از فرآیند فعلی تعریف کنید
نرم‌افزار اختصاصی نباید الزاماً همان فرآیند دستی را با فرم دیجیتال بازسازی کند. ممکن است بعضی مراحل حذف، ادغام یا خودکار شوند.
برای هر Workflow مشخص کنید در وضعیت مطلوب چه چیزی باید تغییر کند. این کار کمک می‌کند پروژه به «دیجیتال‌کردن ناکارآمدی» تبدیل نشود.
۶. Must-have و Nice-to-have را از هم جدا کنید
تقریباً هر پروژه در جلسات اولیه فهرست بلندبالایی از ایده‌ها دارد. همه آنها نباید وارد نسخه اول شوند.
Featureهای Must-have آنهایی هستند که بدون آنها ارزش اصلی محصول یا فرآیند قابل استفاده نیست. Nice-to-haveها ارزشمندند، اما می‌توانند بعد از اعتبارسنجی هسته اصلی ساخته شوند.
۷. محدوده MVP را مشخص کنید
MVP به معنی نسخه ناقص یا بی‌کیفیت نیست؛ یعنی کوچک‌ترین نسخه‌ای که یک مسئله واقعی را End-to-end حل می‌کند.
مثلاً در یک سامانه رزرو، ثبت کاربر، مشاهده ظرفیت، رزرو و تأیید ممکن است هسته MVP باشند، درحالی‌که Loyalty، گزارش‌های پیشرفته یا اپ موبایل به نسخه بعد منتقل شوند.
۸. نمونه داده واقعی آماده کنید
اگر سیستم قرار است مشتری، محصول، قرارداد، پرسنل یا سوابق قبلی را مدیریت کند، چند نمونه واقعی و ترجیحاً ناشناس‌شده از داده‌ها بسیار مفید است.
نمونه داده مشخص می‌کند فیلدها، Formatها، استثناها و کیفیت اطلاعات موجود چگونه است. این موضوع مخصوصاً برای Migration اهمیت دارد.
۹. تکلیف انتقال داده‌های قدیمی را روشن کنید
اگر اطلاعات فعلی در Excel، نرم‌افزار قدیمی یا Database دیگری است، مشخص کنید چه چیزی باید منتقل شود و چه چیزی می‌تواند Archive باقی بماند.
Data Migration خودش Scope دارد: Mapping، Cleaning، Validation، Duplicateها و گزارش نتیجه Import باید در نظر گرفته شوند.
۱۰. Integrationهای لازم را از ابتدا اعلام کنید
اگر سیستم باید به حسابداری، CRM، ERP، درگاه پرداخت، پیامک، Active Directory یا سرویس دیگری وصل شود، این موضوع را در مرحله برآورد مطرح کنید.
نام سرویس، مستندات API، نوع دسترسی و محدودیت‌های آن روی معماری و زمان پروژه اثر دارند.
۱۱. گزارش‌ها و خروجی‌های مدیریتی را نمونه‌سازی کنید
عبارت «گزارش کامل مدیریتی» Requirement دقیقی نیست. بهتر است نمونه جدول، Excel یا گزارشی که امروز استفاده می‌شود ارائه کنید.
مشخص کنید چه شاخص‌هایی مهم‌اند، چه Filterهایی لازم است و گزارش برای تصمیم‌گیری چه کسی استفاده می‌شود.
۱۲. Ruleها و استثناهای کسب‌وکار را بنویسید
قیمت‌گذاری، ظرفیت، تخفیف، تأیید چندمرحله‌ای، محدودیت زمانی یا شرایط لغو معمولاً بخش اصلی Business Logic هستند.
جمله‌هایی مثل «در حالت عادی این‌طور است، مگر اینکه…» را جدی بگیرید. همان «مگر اینکه»ها اغلب بیشترین پیچیدگی را ایجاد می‌کنند.
۱۳. الزامات امنیت و محرمانگی را مشخص کنید
نوع داده تعیین می‌کند چه سطحی از کنترل لازم است. اطلاعات سلامت، مالی، پرسنلی یا اسناد سازمانی با یک کاتالوگ عمومی یکسان نیستند.
نیاز به MFA، Audit Log، محدودیت IP، SSO، رمزنگاری، Retention یا سطح دسترسی خاص باید قبل از معماری مطرح شود.
۱۴. Cloud، On-premise یا شبکه بسته؟
محل استقرار روی معماری، Deployment، Backup و پشتیبانی اثر دارد. بعضی سازمان‌ها الزام دارند سیستم داخل زیرساخت خودشان یا حتی شبکه بدون اینترنت اجرا شود.
اگر چنین محدودیتی وجود دارد، باید از ابتدا گفته شود؛ انتقال یک سیستم Cloud-native به محیط بسته در پایان پروژه ممکن است ساده نباشد.
۱۵. حجم تقریبی استفاده را اعلام کنید
لازم نیست پیش‌بینی دقیق داشته باشید، اما تفاوت بین ۳۰ کاربر داخلی و صدها هزار کاربر عمومی مهم است.
تعداد کاربران همزمان، حجم فایل، تعداد تراکنش روزانه و رشد مورد انتظار به انتخاب زیرساخت و طراحی بخش‌های حساس کمک می‌کند.
۱۶. بودجه را پنهان نکنید
بودجه به تیم کمک می‌کند راه‌حل متناسب پیشنهاد دهد. اگر محدوده مالی مشخص باشد، می‌توان Scope، فازبندی و سطح Automation را واقع‌بینانه طراحی کرد.
اعلام Budget به معنی پذیرفتن هر قیمت نیست؛ همچنان باید Scope و خروجی پیشنهادها را مقایسه کنید.
۱۷. Deadline واقعی و دلیل آن را بگویید
«هرچه زودتر» Deadline نیست. اگر نمایشگاه، فصل فروش، پایان قرارداد سیستم قبلی یا الزام سازمانی دارید، تاریخ و دلیل آن را اعلام کنید.
گاهی می‌توان Scope نسخه اول را برای رسیدن به تاریخ حیاتی کاهش داد و Featureهای دیگر را بعداً منتشر کرد.
۱۸. یک Product Owner یا تصمیم‌گیرنده مشخص کنید
اگر تیم توسعه برای هر سؤال باید منتظر توافق چند واحد بماند، پروژه کند می‌شود. یک نفر باید مسئول جمع‌آوری نظرها، اولویت‌بندی و تأیید نهایی باشد.
این فرد لازم نیست برنامه‌نویس باشد؛ باید فرآیند کسب‌وکار را بفهمد و اختیار تصمیم‌گیری داشته باشد.
۱۹. معیار پذیرش را قبل از تحویل تعریف کنید
«سیستم درست کار کند» قابل تست نیست. Acceptance Criteria باید برای Flowهای مهم قابل مشاهده باشد.
مثلاً «کاربر مجاز می‌تواند رزرو را ثبت کند، ظرفیت همان بازه کاهش یابد و مدیر وضعیت جدید را در گزارش ببیند» معیار روشن‌تری است.
۲۰. درباره مالکیت کد، داده و حساب‌ها توافق کنید
از ابتدا مشخص کنید Repository، Source Code، Database، دامنه، Hosting، حساب Cloud، سرویس پیامک و Licenseها به نام چه کسی هستند و در پایان همکاری چه چیزهایی تحویل می‌شوند.
همچنین درباره Documentation، دسترسی Production و فرآیند تحویل به تیم بعدی توافق کنید.
۲۱. پشتیبانی و نگهداری بعد از Launch را جزو تصمیم اولیه ببینید
بعد از انتشار، Monitoring، Backup، Update، رفع Bug و تغییرات کسب‌وکار ادامه دارند. قرارداد ساخت و قرارداد نگهداری می‌توانند جدا باشند، اما مسئولیت‌ها باید روشن باشند.
چه چیزهایی لازم نیست قبل از سفارش آماده کنید؟
لازم نیست Stack فنی، Database، Framework یا معماری Microservice را شما انتخاب کنید؛ مگر اینکه سازمان محدودیت فنی مشخصی داشته باشد.
وظیفه شما انتقال دقیق مسئله، فرآیند و محدودیت‌های کسب‌وکار است. تیم فنی باید بر اساس این اطلاعات راه‌حل معماری پیشنهاد کند.
یک بسته اطلاعاتی ساده برای جلسه اول
اگر بخواهیم همه موارد را خلاصه کنیم، برای جلسه اولیه این موارد بسیار مفیدند:
- شرح یک‌صفحه‌ای مسئله و هدف
- فهرست Roleها
- Workflowهای اصلی
- Must-haveهای MVP
- نمونه داده و گزارش
- Integrationهای موردنیاز
- محدودیت امنیتی و استقرار
- Budget Range و Deadline
- نام تصمیم‌گیرنده پروژه
جمع‌بندی
برای سفارش نرم‌افزار اختصاصی لازم نیست قبل از جلسه اول همه پاسخ‌های فنی را بدانید. مهم این است که مسئله، کاربران، فرآیندها، داده‌ها، محدودیت‌ها و اولویت‌های کسب‌وکار را شفاف کنید.
هرچه این اطلاعات روشن‌تر باشند، Discovery کوتاه‌تر، پیشنهادها قابل مقایسه‌تر و احتمال اختلاف Scope در طول پروژه کمتر می‌شود.
اگر برای تبدیل فرآیندهای فعلی به Scope قابل توسعه نیاز به کمک دارید، از صفحه تماس با ما مسئله و فرآیند اصلی را توضیح دهید تا قبل از برآورد، محدوده نسخه اول مشخص شود.
