سفارشی که سه بار در سه ابزار جدا ثبت می‌شود، هم وقت می‌گیرد و هم خطا می‌سازد. همین‌جاست که خیلی از مدیران می‌پرسند نرم افزار اختصاصی چیست و آیا جواب مشکلشان همین است. جواب کوتاه: نرم‌افزاری که برای فرایندهای مشخص یک کسب‌وکار ساخته می‌شود. اما همیشه اولین گزینه نیست. این راهنما کمک می‌کند بین ابزار آماده، اتصال ابزارهای فعلی و ساخت اختصاصی انتخاب کنید و شرح نیازتان را بنویسید.
- اندازه شرکت تعیین‌کننده نیست؛ شکاف میان نیاز ضروری و قابلیت ابزارهای موجود مهم است.
- پیش از ساخت، پوشش نیاز با ابزار آماده و امکان اتصال سامانه‌ها را آزمایش کنید.
- هزینه تصمیم فقط توسعه نیست؛ انتقال داده، آموزش و نگهداری هم سهم دارند.
- مالکیت خروجی‌ها و معیارهای پذیرش را پیش از اجرا مکتوب کنید.
- درخواست برآورد را با شرح یک مسیر کاری کامل شروع کنید، نه فهرست صفحه‌ها.
نرم افزار اختصاصی چیست و برای چه کسب‌وکارهایی مناسب است؟
اگر بخواهم در یک جمله بگویم نرم افزار اختصاصی چیست: برنامه‌ای که برای نیازها و فرایندهای مشخص یک کسب‌وکار طراحی و توسعه داده می‌شود. این راهکار به کار مجموعه‌هایی می‌آید که ابزارهای آماده نیازهای مهمشان را پوشش نمی‌دهند و اتصال سامانههای فعلی هم کافی نیست. شرط سوم این است که ارزش حل مسئله، هزینه ساخت و نگهداری را توجیه کند. اما اندازه شرکت به‌تنهایی معیار انتخاب نیست.
در بازار به همین مفهوم «نرمافزار سفارشی» هم می‌گویند. پس اگر جست‌وجو کرده‌اید «نرم افزار سفارشی چیست»، جواب همان است: سامانه‌ای که بر اساس کار شما ساخته شده، نه کار شما بر اساس آن.
اما یک سوءتفاهم رایج را همین اول کنار بگذاریم: اختصاصی بودن یعنی نوشتن همه‌چیز از صفر نیست. تیم حرفه‌ای برای ورود کاربران، پرداخت، ارسال پیامک یا ساخت گزارش سراغ کتابخانه‌ها و سرویس‌های آزموده می‌رود. بخش اختصاصی همان جایی است که قواعد کار شما با بقیه فرق دارد.
به همین دلیل، یک کارگاه کوچک با قیمت‌گذاری پیچیده ممکن است واقعاً به ساخت نیاز داشته باشد. در مقابل، شرکتی بزرگ با فرایندهای استاندارد شاید با یک ابزار آماده کاملاً راضی بماند. یعنی جواب اینکه نرم افزار اختصاصی چیست و به کار چه کسی می‌آید، از قواعد کار درمی‌آید، نه از اندازه سازمان.
تمرکز این راهنما روی سه چیز است: تعریف دقیق، تشخیص نیاز واقعی به ساخت و مسیر اجرایی‌ای که بشود ارزیابی‌اش کرد. مقایسه تفصیلی محصولات یا زبان‌های برنامه‌نویسی موضوع این متن نیست.
نرمافزار اختصاصی چه تفاوتی با نرمافزار مالکیتی دارد؟
اختصاصی بودن به هدف ساخت برمی‌گردد و مالکیتی بودن به مجوز. نرمافزار مالکیتی (Proprietary) یعنی صاحبش تعیین می‌کند چه کسی حق استفاده، تغییر یا توزیع دارد. در گفت‌وگوهای فارسی این دو واژه گاهی جابه‌جا به کار می‌روند و همین سر قرارداد دردسر درست می‌کند. پس بخشی از جواب نرم افزار اختصاصی چیست این است که بدانید چه چیزی نیست.
مفهوم | به چه چیزی مربوط است | پرسش اصلی |
|---|---|---|
اختصاصی (سفارشی) | هدف و دامنه ساخت | این نرمافزار برای کار چه کسی ساخته شده؟ |
مالکیتی | مجوز استفاده، تغییر و توزیع | چه کسی اجازه دارد آن را تغییر دهد یا بفروشد؟ |
متن‌باز | دسترسی به کد و شرایط مجوز | مجوز این کد چه تعهدی برای ما می‌سازد؟ |
یک محصول آماده با هزاران مشتری کاملاً می‌تواند مالکیتی باشد. از آن طرف، تقریباً هر سامانه سفارشی از اجزای متن‌باز استفاده می‌کند. همچنین متن‌باز بودن را با رایگان بودن یکی ندانید؛ هر مجوز شرایط خودش را دارد و تعریف مجوزهای متن‌باز نشان می‌دهد این شرایط دقیقاً درباره چیست.
فرض کنید شرکتی هزینه کامل ساخت یک سامانه را پرداخته است. دو سال بعد می‌خواهد تیم پشتیبانی را عوض کند و تازه می‌فهمد قرارداد فقط «حق استفاده» داده است. یعنی پرداخت هزینه به‌تنهایی همه حقوق را منتقل نکرده بود. این از آن اشتباه‌هایی است که بیشتر از بقیه نگرانم می‌کند، چون معمولاً وقتی کشف می‌شود که دیگر دیر است.
برای جلوگیری از این وضعیت، پیش از امضا از مجری بپرسید:
کدام بخش‌های خروجی کاملاً متعلق به ما می‌شود؟
کدام اجزا از قبل متعلق به شما بوده و با چه مجوزی در اختیار ما قرار می‌گیرد؟
مجوز کتابخانه‌های به‌کاررفته چه محدودیتی برای تغییر یا فروش آینده دارد؟
چه مسئله‌هایی با نرمافزار اختصاصی حل می‌شوند؟
مسئله‌هایی که قاعده خاص کسب‌وکار شما در آن‌ها گیر کرده و هیچ ابزار رایجی اجرایش نمی‌کند. برای اینکه بحث انتزاعی نماند، در تمام این راهنما یک سناریوی فرضی را دنبال می‌کنیم. هر جا پرسیدیم نرم افزار اختصاصی چیست و کجا لازم است، جوابش را روی همین مثال می‌سنجیم.
فرض کنید یک شرکت پخش با دو انبار کار می‌کند. حسابداری در یک نرمافزار انجام می‌شود و ثبت سفارش در ابزاری جدا. موجودی انبارها دیر به‌روز می‌شود؛ در نتیجه فروشنده گاهی کالایی را می‌فروشد که دیگر نیست. تأیید تخفیف هم قاعده خودش را دارد: تا سقفی مشخص با سرپرست فروش، بالاتر از آن با مدیر مالی.
پیش از هر تصمیمی، سه نوع مشکل را از هم جدا کنید:
مشکل فرایندی: کسی دقیقاً نمی‌داند تخفیف ویژه را چه کسی تأیید می‌کند.
مشکل کیفیت داده: یک کالا در دو انبار با دو کد متفاوت ثبت شده است.
کمبود قابلیت نرم‌افزاری: ابزار فعلی نمی‌تواند تأیید دومرحله‌ای را بر اساس مبلغ اجرا کند.
فقط مورد سوم با ساخت نرمافزار حل می‌شود، چون ریشه دو مورد اول بیرون از نرمافزار است. اگر فرایند روشن نباشد، ساختن ابزار برایش فقط ابهام را از کاغذ به کد میبرد. و ابهامی که در کد بنشیند، اصلاحش گران‌تر تمام می‌شود.
در مقابل، نیازهایی که معمولاً واقعاً ساخت می‌خواهند از این جنس‌اند: قواعد تأیید چندمرحله‌ای، تخصیص منابع با محدودیت‌های خاص، و گزارشی که داده چند منبع را با منطق شما ترکیب کند.
پس وقتی می‌پرسید نرم افزار اختصاصی چیست، پرسش دقیق‌تر این است: کدام بخش از کار من قاعده‌ای دارد که ابزارها اجرایش نمی‌کنند؟ مسئله را با این قالب بنویسید: چه کسی، در کدام کار، با چه مانعی روبه‌روست و چه پیامد قابل مشاهده‌ای دارد؟ مثلاً: «فروشنده هنگام ثبت سفارش موجودی لحظه‌ای را نمی‌بیند و بعضی سفارش‌ها پس از تأیید لغو می‌شوند.»
چه زمانی نرمافزار آماده انتخاب بهتری است؟
وقتی نیازهای ضروری شما با تنظیمات معمول یک ابزار پوشش داده می‌شوند و کمی تغییر در فرایند هم هزینه زیادی ندارد. در این حالت پیشنهاد من این است که اول ابزار آماده را جدی آزمایش کنید. بخشی از دانستن اینکه نرم افزار اختصاصی چیست، دانستن این است که کجا لازمش ندارید.
البته آزمایش جدی با تماشای نمایش فروش یا تیک زدن فهرست امکانات فرق دارد. یعنی یک مسیر واقعی کار را از ابتدا تا انتها در نسخه آزمایشی اجرا کنید. بعد ببینید می‌توانید داده‌ها را در قالبی قابل استفاده خروجی بگیرید یا نه. سطح دسترسی‌ها را هم بسنجید: آیا انباردار می‌تواند موجودی را ببیند، بی‌آنکه قیمت خرید را ببیند؟
در سناریوی شرکت پخش، اگر رزرو موجودی و تأیید دومرحله‌ای تخفیف با تنظیمات یک ابزار موجود حل شوند، ساخت سامانه تازه توجیه روشنی ندارد. حتی اگر ظاهر آن ابزار باب میل تیم نباشد. بنابراین برای این شرکت، جواب نرم افزار اختصاصی چیست ساده است: چیزی که فعلاً لازمش ندارد.
با این حال، قیمت اشتراک تنها هزینه ابزار آماده نیست. این اقلام را هم کنار هزینه ساخت بگذارید:
اشتراک چندساله، با در نظر گرفتن رشد تعداد کاربران
آموزش تیم و زمانی که صرف عادت به منطق ابزار می‌شود
محدودیت توسعه، یعنی کارهایی که هیچ‌وقت به ابزار اضافه نخواهند شد
هزینه خروج: انتقال داده و تاریخچه، اگر روزی بخواهید ابزار را عوض کنید
برای بررسی دقیق‌تر این دو مسیر کنار هم، مقایسه نرمافزار آماده و اختصاصی برای انتخاب را بخوانید.
مزایای نرمافزار اختصاصی در چه شرایطی ارزش دارند؟
فهرست مزایای نرم افزار اختصاصی فقط وقتی ارزش دارد که هر مزیت به پیامدی عملی در کار شما برسد. اما هیچ‌کدام نتیجه خودکار ساخت نیستند و هر کدام شرطی دارند.
مزیت | پیامد عملی | شرط تحقق |
|---|---|---|
انطباق با فرایند | قاعده‌ها در خود سامانه اجرا می‌شوند، نه در حافظه کارمندان | فرایند پیش از ساخت روشن و تأییدشده باشد |
کنترل مسیر توسعه | خودتان تعیین می‌کنید کدام قابلیت اول ساخته شود | به کد، مستندات و دسترسی‌ها دسترسی داشته باشید |
اتصال هدفمند | داده فقط به جایی می‌رود که لازم است | ابزارهای دیگر رابط قابل اتکا داشته باشند |
مزیت دوم بیشتر از بقیه گول می‌زند، چون روی کاغذ همیشه برقرار به نظر می‌رسد. کنترل مسیر توسعه وقتی واقعی است که اگر فردا تیم فعلی کنار رفت، تیم دیگری بتواند کار را ادامه دهد. بدون مستندات و دسترسی به خروجی‌ها، فقط وابستگی را از یک فروشنده به فروشنده دیگر منتقل کرده‌اید.
برای مثال، در شرکت پخش فرضی، اجرای خودکار قاعده تأیید تخفیف می‌تواند ثبت‌های خارج از روال را محدود کند. معیار ارزیابی هم روشن است: تعداد استثناهای ثبت‌شده در هر ماه و دلیلشان. اگر این عدد را پیش از ساخت نشمارید، بعداً نمی‌توانید بگویید چیزی بهتر شده یا نه.
همچنین درباره امنیت و سرعت اغراق نکنید. اگر مجری‌ای در توضیح اینکه نرم افزار اختصاصی چیست، امنیت و سرعت بیشتر را جزو ذاتش شمرد، دقیق‌تر بپرسید. نرمافزار اختصاصی ذاتاً امن‌تر یا سریع‌تر نیست؛ کیفیت طراحی، آزمون و شیوه بهره‌برداری نتیجه را تعیین می‌کند.
ارزش نرمافزار اختصاصی در کد نیست؛ در قاعده‌ای است که پیش از نوشتن کد روشنش کرده‌اید.
معایب نرمافزار اختصاصی و ریسک‌های قابل پیشگیری چیست؟
مهم‌ترین معایب نرم افزار اختصاصی این‌هاست: تعهد بلندمدت نگهداری، رشد کنترل‌نشده دامنه، وابستگی به یک تیم و دشواری پذیرش کاربران. هر جوابی به پرسش نرم افزار اختصاصی چیست بدون این روی سکه ناقص است. خبر خوب این است که هر کدام نشانه هشدار و راه پیشگیری مشخصی دارد.
ریسک | نشانه هشدار | اقدام پیشگیرانه |
|---|---|---|
تعهد نگهداری | بودجه فقط برای ساخت دیده شده، نه سال‌های بعد | برنامه و بودجه نگهداری از روز اول |
رشد دامنه | در هر جلسه چند قابلیت «کوچک» اضافه می‌شود | ثبت هر تغییر همراه اثرش بر زمان و هزینه |
وابستگی به تیم | فقط یک نفر می‌داند سامانه چطور مستقر می‌شود | تحویل دوره‌ای کد و مستندسازی هم‌زمان با ساخت |
پذیرش کاربران | کاربران نهایی سامانه را اولین بار در جلسه رونمایی می‌بینند | حضور کاربران نماینده در آزمون نسخه‌های میانی |
ریسک دیگری هم هست که کمتر دیده می‌شود: ساختن برای نیازی که هنوز آزموده نشده. مثلاً اگر مطمئن نیستید فروشنده‌ها واقعاً از رزرو لحظه‌ای استفاده می‌کنند، اول یک آزمایش کوچک کنید. یک فرم ساده و چند هفته استفاده واقعی، بیشتر از ماه‌ها جلسه چیز روشن می‌کند.
معمولاً اولین سؤالی که در جلسه‌های ارزیابی می‌پرسم این است: اگر توسعه فردا متوقف شود، چه کسی سامانه را اجرا، بازیابی و اصلاح می‌کند؟ اگر جواب روشنی ندارید، پس هنوز برای شروع آماده نیستید.
یکپارچه‌سازی چه زمانی جای تعویض همه ابزارها را می‌گیرد؟
وقتی هر کدام از ابزارهای فعلی کار خودش را خوب انجام می‌دهد و مشکل فقط در جابه‌جایی داده میان آن‌هاست. یکپارچه‌سازی یعنی تبادل هماهنگ و خودکار داده میان ابزارها. این کار معمولاً از راه API انجام می‌شود؛ رابطی که به دو نرمافزار اجازه می‌دهد بی‌دخالت انسان با هم داده رد و بدل کنند.
در شرکت پخش فرضی، شاید لازم نباشد حسابداری را کنار بگذارید. اتصال ابزار سفارش به سامانه انبار ممکن است کافی باشد. گزینه ترکیبی هم وجود دارد: ابزارها سر جایشان بمانند و فقط بخش قواعد خاص، مثل تأیید تخفیف، اختصاصی ساخته شود. گاهی جواب درست به نرم افزار اختصاصی چیست همین بخش کوچک است، نه یک سامانه کامل.
اما وجود API در بروشور یک محصول به‌تنهایی کافی نیست. پیش از انتخاب این مسیر بررسی کنید:
آیا دسترسی به رابط در طرح اشتراک شما هست یا هزینه جدا دارد؟
مجوز استفاده چه محدودیتی روی تعداد درخواست یا نوع داده می‌گذارد؟
داده‌های فعلی آن‌قدر تمیز هستند که انتقال خودکار، خطاها را تکثیر نکند؟
ظرفیت رابط برای حجم سفارش روزهای شلوغ کافی است؟
همچنین چهار تصمیم دیگر را روی کاغذ بیاورید. منبع معتبر موجودی کدام سامانه است؟ شناسه مشترک هر کالا در همه ابزارها چیست؟ چطور جلوی ثبت تکراری یک سفارش را می‌گیرید؟ و اگر اتصال قطع شد، سفارش‌ها کجا می‌مانند و بعداً چطور ارسال می‌شوند؟
در واقع اصول تعریف این تبادل‌ها در بیشتر پروژه‌ها شبیه است. راهنمای تعریف نیازمندی اتصال سایت به سامانه مدیریت مشتریان همین اصول را در یک مثال دیگر قدم‌به‌قدم نشان می‌دهد.
پیش از نهایی کردن دامنه، عبور یک رکورد آزمایشی از سامانه مبدأ تا مقصد را بررسی کنید. این آزمون کوچک می‌تواند محدودیت دسترسی یا ناسازگاری داده را زود آشکار کند.
چه زمانی نرمافزار اختصاصی لازم است؟
وقتی یک نیاز ضروری در هیچ ابزار آماده‌ای اجرا نمی‌شود و با اتصال ابزارها هم حل نمی‌شود. شرط سوم این است که ارزش حلش از هزینه ساخت و نگهداری بیشتر باشد. اگر از پرسش نرم افزار اختصاصی چیست گذشته‌اید و حالا می‌پرسید «چه زمانی نرم افزار اختصاصی لازم است»، این بررسی‌ها را به همین ترتیب انجام دهید:
پوشش ابزار آماده: نیازهای ضروری را با سناریوی واقعی در یکی دو ابزار بیازمایید. اگر پوشش داده شدند، مسیرتان ابزار آماده است.
امکان اتصال: اگر هر ابزار بخشی از کار را خوب انجام می‌دهد، اتصالشان را بسنجید.
ارزش اقتصادی ساخت: اگر شکافی ضروری باقی ماند، بسنجید حلش چقدر می‌ارزد.
توقف برای روشن‌کردن نیاز: اگر در هر مرحله نتوانستید بگویید نیاز دقیقاً چیست، همان‌جا بایستید.
در سناریوی فرضی، اگر مسئله فقط انتقال سفارش به انبار باشد، اتصال کافی است. ولی اگر قواعد رزرو موجودی میان دو انبار در هیچ ابزار موجودی اجرا نشوند، ساخت یک بخش محدود ارزش ارزیابی دارد.
کلمه «ضروری» هم تعریف دقیق لازم دارد. نیاز ضروری کاری است که نبودش عملیات را متوقف می‌کند یا ریسکی غیرقابل قبول می‌سازد. اما اینکه دکمه‌ها جای دیگری باشند یا رنگ صفحه‌ها سلیقه تیم نباشد، دلیل کافی برای ساخت نیست.
بنابراین تصمیم را همراه فرض‌ها و شواهد آزمون‌هایتان ثبت کنید. شش ماه بعد که شرایط عوض شد، می‌توانید ببینید کدام فرض دیگر درست نیست.
نرمافزار تحت وب بهتر است یا دسکتاپ؟
برای بیشتر کسب‌وکارهای چندشعبه، تحت وب انتخاب منطقی‌تری است؛ اما شرایط اتصال و تجهیزات محلی می‌تواند این را عوض کند. نرمافزار تحت وب در مرورگر اجرا می‌شود و دسکتاپ برنامه‌ای است که روی هر رایانه نصب می‌شود. این انتخاب ربطی به آماده یا اختصاصی بودن ندارد؛ یعنی هر جوابی به نرم افزار اختصاصی چیست بدهید، این تصمیم جداگانه گرفته می‌شود.
دو باور غلط را کنار بگذارید. تحت وب الزاماً به اینترنت عمومی وابسته نیست و می‌تواند فقط در شبکه داخلی شرکت اجرا شود. از آن طرف، دسکتاپ هم الزاماً آفلاین نیست و اغلب به یک سرور مرکزی وصل است.
معیار | تحت وب | دسکتاپ |
|---|---|---|
شعب و کاربران پراکنده | دسترسی ساده از هر جا | نصب و پیکربندی روی هر دستگاه |
اتصال ناپایدار | نیاز به طراحی ثبت محلی | کار محلی ساده‌تر، ولی همگام‌سازی همچنان لازم |
تجهیزات محلی مثل بارکدخوان و چاپگر برچسب | ممکن، گاهی با محدودیت | معمولاً دسترسی مستقیم‌تر |
به‌روزرسانی | یک بار روی سرور | روی تک‌تک دستگاه‌ها یا با سازوکار خودکار |
برای انبار فرضی که اینترنتش گاهی قطع می‌شود، ثبت محلی و همگام‌سازی بعدی را بررسی کنید. با این حال بدانید حل تعارض داده هزینه و پیچیدگی جدی اضافه می‌کند. تعارض یعنی وقتی دو نفر هم‌زمان یک موجودی را در دو جا تغییر داده‌اند.
پیش از انتخاب، یک روز کاری را شبیه‌سازی کنید: قطع ارتباط وسط کار، چند کاربر هم‌زمان روی یک سفارش، و چاپ برچسب. نتیجه این آزمون از هر بحث نظری قانع‌کننده‌تر است.
نیازسنجی و سند نیازمندی چه خروجی‌هایی دارند؟
خروجی نیازسنجی باید کاربران، مسیر کار، داده‌ها، قواعد تصمیم، استثناها و مرز پروژه را روشن کند. فهرست صفحه‌ها به‌تنهایی سند نیازمندی نیست، چون دو تیم می‌توانند با یک فهرست صفحه دو نرمافزار کاملاً متفاوت بسازند. تا اینجا پرسیدیم نرم افزار اختصاصی چیست؛ از اینجا باید روشن کنید نرمافزار شما دقیقاً چه می‌کند.
این قالب کوتاه را برای هر نیاز پر کنید:
نقش کاربر: چه کسی این کار را انجام می‌دهد؟
اقدام: دقیقاً چه کاری می‌کند؟
پیش‌شرط: قبل از آن چه چیزی باید برقرار باشد؟
نتیجه مورد انتظار: بعد از اقدام چه تغییری در سامانه دیده می‌شود؟
حالت خطا: اگر چیزی درست پیش نرفت، چه اتفاقی می‌افتد؟
برای مثال: مسئول انبار سفارش تأییدشده را رزرو می‌کند. پیش‌شرط، تأیید سفارش است و نتیجه، کم شدن موجودی قابل فروش. حالا سؤال‌های سخت: اگر موجودی کافی نباشد چه می‌شود؟ اگر دو نفر هم‌زمان آخرین واحد را رزرو کنند چه؟ بخش بزرگی از هزینه‌های پنهان پروژه در جواب همین سؤال‌هاست.
همچنین نیازهای کیفیتی را قابل آزمون بنویسید. به جای «سامانه سریع باشد» بنویسید با چند کاربر هم‌زمان، هر صفحه حداکثر در چه زمانی پاسخ دهد. کنترل دسترسی و امکان بازیابی را هم به همین شکل دقیق کنید.
دو مورد دیگر را هم ثبت کنید: نام تصمیم‌گیر هر فرایند و فهرست کارهایی که عمداً خارج از دامنه گذاشته‌اید. تجربه من این است که فهرست «خارج از دامنه» بیشتر از هر سند دیگری جلوی بحث‌های بعدی را می‌گیرد.
نسخه اولیه نرمافزار چه امکاناتی باید داشته باشد؟
یک مسیر کاری مهم، از ابتدا تا انتها و کامل؛ حتی اگر فقط همان یک مسیر باشد. این حداقلِ چیزی است که نسخه اولیه باید داشته باشد. به این نسخه گاهی MVP یا «کمینه محصول قابل استفاده» می‌گویند. اما چند صفحه ناتمام که هر کدام نیمی از کار را انجام می‌دهند، نسخه اولیه نیست.
در سناریوی شرکت پخش، نسخه اولیه می‌تواند ثبت سفارش، تأیید تخفیف و رزرو موجودی را پوشش دهد. داشبوردهای رنگی، گزارش‌های تزئینی و پیامک خودکار به مشتری می‌توانند منتظر بمانند.
برای هر قابلیت یک سؤال بپرسید: بدون آن، آزمون ارزش اصلی ممکن است؟ اگر جواب مثبت است، آن را به نسخه بعد ببرید. اینجا هم همان منطقِ جواب نرم افزار اختصاصی چیست تکرار می‌شود: فقط چیزی را بسازید که نبودنش کار را لنگ می‌کند.
با این حال، بعضی چیزها را نباید قربانی کوچک کردن دامنه کرد: امنیت پایه، صحت داده و امکان بازیابی. نسخه‌ای که زود رسیده ولی سفارش‌ها را گم می‌کند، اعتماد کاربران را از بین میبرد. بعد از آن، نسخه دوم هم دیگر جدی گرفته نمی‌شود.
همچنین نمونه نمایشی را با نسخه عملیاتی اشتباه نگیرید. نمونه نمایشی اغلب با داده ساختگی و برای سنجش تجربه کاربر ساخته می‌شود. نسخه عملیاتی اما با داده واقعی کار می‌کند و باید همه حالت‌های خطای مسیر اصلی را تاب بیاورد.
نسخه اولیه خوب کوچک است، اما هیچ‌وقت نیمه‌کاره نیست.
مراحل تولید نرمافزار و زمانبندی چگونه مشخص می‌شوند؟
کار از کشف مسئله شروع می‌شود و با طراحی، ساخت مرحله‌ای، آزمون و استقرار ادامه پیدا می‌کند. زمانبندی را چهار عامل تعیین می‌کند: دامنه کار، دسترسی به سامانههای دیگر، آمادگی داده و سرعت تأییدها. بنابراین هر عدد ثابتی که پیش از روشن شدن این چهار عامل بشنوید، بیشتر حدس است تا برآورد. این بخش از جواب نرم افزار اختصاصی چیست کمتر گفته می‌شود: ساختش مسیری مرحله‌ای است، نه سفارشی یک‌باره.
کسانی که برای «طراحی نرم افزار اختصاصی» یا «توسعه نرم افزار سفارشی» استعلام می‌گیرند، معمولاً اول یک تاریخ تحویل می‌خواهند. پیشنهاد من این است که به جای تاریخ، دنبال خروجی و شرط عبور هر مرحله باشید:
مرحله | خروجی | شرط عبور به مرحله بعد |
|---|---|---|
کشف مسئله | شرح مسئله، مسیرهای کاری، فهرست نیازها | تأیید دامنه توسط صاحب تصمیم |
طراحی | جریان کار، طرح صفحه‌ها، ساختار داده | نمونه تأییدشده توسط کاربران نماینده |
ساخت مرحله‌ای | نسخه قابل آزمایش در هر دوره | نمایش نسخه و ثبت بازخورد |
آزمون | گزارش آزمون بر پایه معیارهای پذیرش | رفع نقص‌های مهم |
استقرار | نسخه عملیاتی و مستندات استقرار | داده منتقل‌شده و تطبیق‌شده، کاربران آموزش‌دیده |
بزرگ‌ترین منبع عدم قطعیت معمولاً اتصال به سامانههای دیگر است. پس آن را به آخر پروژه موکول نکنید. در همان هفته‌های اول یک آزمون فنی کوچک انجام دهید: آیا واقعاً می‌شود از سامانه حسابداری داده خواند؟
منتظر تحویل نهایی هم نمانید، چون سوءتفاهمی که آخر کار پیدا شود گران است. نمایش دوره‌ای نسخه قابل آزمایش، همراه ثبت تغییرات، سوءتفاهم‌ها را وقتی آشکار می‌کند که هنوز ارزان‌اند.
برای شرکت پخش فرضی، عبور از هر مرحله را به یک مدرک ببندید؛ مثلاً نمونه تأییدشده جریان تخفیف یا گزارش آزمون رزرو هم‌زمان. جمله «فکر می‌کنیم آماده است» مدرک نیست.
کارفرما و تیم توسعه چه مسئولیت‌هایی دارند؟
سهم کارفرما قواعد کسب‌وکار، داده مجاز و بازخورد تجمیع‌شده است؛ سهم تیم توسعه، پیشنهاد فنی، پیاده‌سازی و شواهد آزمون. اولین قدم هم از سمت کارفرماست: یک صاحب تصمیم مشخص کنید. چون جمع کردن نظر ده کاربر با داشتن اختیار تأیید نهایی یکی نیست.
حوزه | کارفرما | تیم توسعه |
|---|---|---|
نیازمندی | توضیح قواعد و استثناها، تأیید نهایی | پرسیدن، مستندسازی، نشان دادن تناقض‌ها |
داده | آماده‌سازی نمونه مجاز و بی‌نام | طراحی ساختار و ابزار انتقال |
آزمون | اجرای سناریوهای پذیرش با کاربران نماینده | آزمون فنی و ارائه گزارش |
انتشار | زمانبندی جابه‌جایی و اطلاع‌رسانی داخلی | استقرار، پایش و برنامه بازگشت |
هیچ ردیفی را بی‌صاحب نگذارید. «مسئولیت مشترک» در عمل یعنی هیچ‌کس.
اگر داده دیر رسید یا یک تأیید سه بار عوض شد، این را در برنامه ثبت کنید. پنهان کردن این تأخیرها داخل زمان توسعه، آخر کار به بحث «چرا دیر شد» می‌رسد؛ بحثی که هیچ‌کس سندی برایش ندارد. در توضیح اینکه نرم افزار اختصاصی چیست، همین نکته معمولاً جا می‌افتد: بخش مهمی از کار دست کارفرماست.
برای جلسه‌های تصمیم این قالب ساده را به کار ببرید:
موضوع تصمیم
گزینه‌های مطرح‌شده
تصمیم‌گیر
موعد توافق‌شده
اثر تصمیم بر دامنه، زمان یا هزینه
هزینه ساخت و نگهداری چگونه برآورد می‌شود؟
پایه برآورد پیچیدگی کار است، نه تعداد صفحه‌ها. هزینه کل هم فقط برنامه‌نویسی نیست و این اقلام را در بر می‌گیرد: تحلیل، طراحی، توسعه، آزمون، اتصال‌ها، انتقال داده، آموزش، زیرساخت و نگهداری.
دو صفحه ظاهراً مشابه می‌توانند هزینه کاملاً متفاوتی داشته باشند. مثلاً صفحه‌ای که فقط سفارش را ذخیره می‌کند با صفحه‌ای که تخفیف را با سه قاعده و دو نقش کنترل می‌کند، فرق دارد. عوامل اصلی هزینه این‌هاست: پیچیدگی قواعد، تعداد نقش‌ها، استثناها، بار استفاده و کیفیت مورد انتظار. به همین دلیل پاسخ نرم افزار اختصاصی چیست و چقدر هزینه دارد را با شمردن صفحه‌ها نمی‌شود داد.
برای مقایسه پیشنهاد چند مجری، دامنه و افق بهره‌برداری را یکسان کنید. اگر یکی سه سال نگهداری را دیده و دیگری نه، این دو قابل مقایسه نیستند. موارد حذف‌شده از هر پیشنهاد را هم جداگانه فهرست کنید؛ چون ارزانی گاهی فقط حذف بی‌صدای آزمون یا انتقال داده است.
یک برآورد قابل اتکا برای هر قلم کار این ستون‌ها را دارد:
قلم کار | فرض | وابستگی | دامنه تخمین | خارج از تعهد |
|---|---|---|---|---|
اتصال به حسابداری | رابط فعلی امکان خواندن فاکتور را دارد | دسترسی آزمایشی از سوی کارفرما | یک بازه حداقل و حداکثر، نه یک عدد | تغییرات ناشی از ارتقای نرمافزار حسابداری |
برای بخش‌هایی که هنوز مجهول‌اند، به جای یک عدد درشت، یک بررسی محدود و جداگانه بخواهید. نتیجه آن بررسی، برآورد بقیه کار را واقعی‌تر می‌کند.
ارزش حل مسئله را هم با چیزهای قابل ثبت بسنجید: زمانی که هر هفته صرف ثبت دوباره و تطبیق می‌شود و پیامد خطاهایی مثل سفارش لغوشده. اما درصد صرفه‌جویی یا بازگشت سرمایه‌ای را که روی فرض بنا شده، قطعی ننویسید؛ آن را صریحاً فرض بنامید.
مجری و شرایط مالکیت خروجی‌ها چگونه ارزیابی می‌شوند؟
اولین نشانه مجری خوب این است که پیش از پیشنهاد فناوری، مسئله شما را درست بازگو کند. از او بخواهید مسئله را با زبان خودش توضیح دهد، ریسک‌های اتصال را نشان دهد و بگوید تغییرات را چطور کنترل می‌کند. پیشنهاد من این است که یک سؤال دیگر هم بپرسید: در پروژه ما، نرم افزار اختصاصی چیست و مرزش کجاست؟ انتخاب صرفاً بر اساس زبان برنامه‌نویسی یا فریم‌ورک، معیار ضعیفی است.
در قرارداد، خروجی‌ها را جدا جدا نام ببرید:
کد منبع و تاریخچه تغییرات آن
مستندات فنی و راهنمای کاربران
طراحی‌ها و فایل‌های منبعشان
ساختار پایگاه داده
دسترسی‌های مدیریتی سرور، دامنه و سرویس‌های جانبی
دستورالعمل استقرار
همچنین حقوق اجزای ازپیش‌موجود مجری و مجوز کتابخانه‌ها را از خروجی سفارشی تفکیک کنید. بندهای مالکیت فکری موضوعی حقوقی‌اند؛ پس پیش از امضا آن‌ها را به یک مشاور حقوقی متخصص نشان دهید.
یک آزمون ساده انتقال‌پذیری هم دارید: آیا تیمی دیگر فقط با دسترسی‌های قراردادی و مستندات می‌تواند نسخه را اجرا کند؟ اگر نه، مالکیت فقط روی کاغذ مانده است.
اگر می‌خواهید دامنه و ریسک‌های فنی پروژه‌تان را با یک تیم بیرونی مرور کنید، صفحه برنامه‌نویسی و نرمافزار اختصاصی نیاسا نقطه شروع این گفت‌وگوست. سؤال‌های همین بخش را آنجا هم بپرسید.
یک بسته کد بدون وابستگیها، تنظیمات و راهنمای اجرا ممکن است برای تیم بعدی قابل استفاده نباشد. تحویل را با اجرای مستقل نسخه بسنجید.
معیارهای پذیرش و امنیت چگونه قابل آزمون می‌شوند؟
با تبدیل هر نیاز به شرطی قابل مشاهده که درست یا غلط بودنش را بشود بررسی کرد. به این شرط معیار پذیرش می‌گویند. «سامانه سریع و امن باشد» معیار پذیرش نیست، چون هیچ‌کس نمی‌تواند بگوید کی برآورده شده است. در واقع اینجا جایی است که تعریف کلی نرم افزار اختصاصی چیست به جمله‌هایی قابل آزمون می‌رسد.
برای مثال، در سناریوی شرکت پخش این دو معیار قابل آزمون‌اند:
اگر یک درخواست رزرو دو بار پشت سر هم ارسال شود، فقط یک رزرو ایجاد شود.
کاربری که مجوز تأیید تخفیف ندارد، حتی با باز کردن مستقیم آدرس صفحه نتواند تخفیف را تأیید کند.
پیش از شروع آزمون، این موارد را توافق کنید: محیط آزمون، داده آزمایشی، نقش کاربران، بار توافق‌شده و مسئول تأیید. بدون این‌ها، آزمون پذیرش به بحثی سلیقه‌ای تبدیل می‌شود.
امنیت هم باید داخل دامنه باشد، نه کاری برای بعد. حداقل این‌ها را بخواهید:
هر کاربر فقط به آنچه برای کارش لازم است دسترسی داشته باشد.
رویدادهای مهم، مثل تأیید تخفیف یا تغییر موجودی، ثبت شوند.
رمزها و کلیدهای دسترسی جدا از کد نگهداری شوند.
بازیابی از نسخه پشتیبان واقعاً آزموده شود.
دسترسی کاربران و تیم‌ها به داده واقعی مشتریان محدود بماند.
برای انتخاب کنترل‌های امنیتی متناسب با پروژه، استاندارد ارزیابی امنیت نرمافزار ASVS مرجع خوبی است. اما ارجاع به یک استاندارد در قرارداد، گواهی امنیت نیست. باید معلوم باشد کدام کنترل‌ها و در چه سطحی آزمون می‌شوند.
انتقال داده و پشتیبانی پس از تحویل چگونه برنامه‌ریزی می‌شوند؟
با یک ترتیب مشخص برای انتقال و قراردادی روشن برای پشتیبانی. انتقال داده خودش پروژه‌ای کوچک درون پروژه اصلی است و این ترتیب را دارد:
بررسی کیفیت داده فعلی
نگاشت فیلدها، یعنی تعیین اینکه هر ستون قدیمی به کدام فیلد جدید می‌رود
پاک‌سازی تکراری‌ها و کدهای ناسازگار
انتقال آزمایشی
تطبیق خروجی با داده قدیمی، مثلاً جمع موجودی هر انبار
انتقال نهایی
زمان جابه‌جایی را هم دقیق برنامه بریزید. از چه لحظه‌ای تغییر در سامانه قدیم متوقف می‌شود؟ سفارش‌هایی که در این فاصله می‌رسند را چه کسی و کجا ثبت می‌کند؟ و اگر مشکلی جدی پیش آمد، بازگشت به نسخه قبلی چطور انجام می‌شود؟
در پشتیبانی، رفع نقص را از درخواست قابلیت جدید جدا کنید. نقص یعنی کاری که در دامنه توافق‌شده بوده و درست کار نمی‌کند. سطح اهمیت هر خطا، کانال گزارش و شرایط پاسخ را هم در قرارداد بیاورید.
پشتیبان‌گیری بدون آزمون بازیابی فقط احساس امنیت می‌دهد. برای ساختن این عادت، راهنمای برنامه‌ریزی پشتیبان‌گیری منظم را ببینید.
به همین ترتیب، پایش خطا، به‌روزرسانی کتابخانه‌ها و بازبینی دوره‌ای دسترسی‌ها جزو برنامه بهره‌برداری‌اند. این‌ها کارهای اختیاری بعد از تحویل نیستند، چون نرم‌افزاری که رها شود کم‌کم ناامن و شکننده می‌شود. اگر جواب شما به نرم افزار اختصاصی چیست فقط تا روز تحویل را در بر بگیرد، نیمی از ماجرا را دیده‌اید.
اگر پس از انتشار به نسخه قبلی برگردید، تکلیف داده‌های ثبت‌شده در فاصله انتشار تا بازگشت چیست؟ پاسخ این پرسش باید در برنامه جابه‌جایی باشد.
چک‌لیست تصمیم نهایی و درخواست برآورد چه چیزهایی دارد؟
یک صفحه که مسئله، کاربران، مسیر فعلی، نیازهای ضروری، ابزارهای موجود، محدودیت‌ها، معیار موفقیت و صاحب تصمیم را روشن کند. این صفحه جوابی است که خودتان به پرسش «نرم افزار اختصاصی چیست و به کار من می‌آید یا نه» می‌دهید. اگر نتوانید آن را در یک صفحه بنویسید، احتمالاً هنوز برای برآورد زود است.
مسئله: با قالب چه کسی، کدام کار، چه مانع و چه پیامد
کاربران: نقش‌ها و تعداد تقریبی هر نقش
مسیر فعلی: کار امروز چطور و با چه ابزاری انجام می‌شود
نیازهای ضروری: فقط آنچه نبودش کار را متوقف می‌کند
ابزارهای موجود: نام ابزار و امکان دسترسی به داده‌اش
محدودیت‌ها: قانونی، زیرساختی یا سازمانی
معیار موفقیت: چیزی که قبل و بعد قابل شمارش باشد
صاحب تصمیم: یک نام، نه یک واحد
انتخابتان را هم در یک جمله ثبت کنید: «ابزار آماده، چون نیازهای ضروری را پوشش می‌دهد»، «اتصال ابزارها، چون هر کدام کارشان را خوب انجام می‌دهند» یا «ساخت، چون یک شکاف ضروری باقی مانده است».
برای درخواست برآورد، نمونه داده بی‌نام‌شده، شرح یک مسیر کامل کاری و استثناهای مهم را ضمیمه کنید. اما رمز عبور، دسترسی سامانه‌ها و داده حساس مشتریان را در این مرحله نفرستید.
بودجه قابل بررسی و محدودیت زمانی کسب‌وکارتان را هم بنویسید. این‌ها ورودی گفت‌وگو هستند، نه تضمینی برای اینکه کار در همان چارچوب انجام‌شدنی است.
وقتی این شرح نیاز آماده شد، می‌توانید آن را با تیم نیاسا مرور کنید. هدف مرحله بعد روشن شدن دامنه و ریسک‌هاست، نه شروع فوری کدنویسی. گاهی نتیجه همین مرور این است که اصلاً به ساخت نیازی ندارید؛ و به نظر من این هم نتیجه خوبی است.
شرح یک مسیر کاری و ابزارهای فعلی‌تان را برای نیاسا بفرستید تا درباره گزینه مناسب و اطلاعات لازم برای برآورد گفت‌وگو کنیم.
پرسش‌های پرتکرار
۵آیا کسب‌وکار کوچک هم به نرمافزار اختصاصی نیاز دارد؟
بله، اگر یک نیاز ضروری و خاص با ابزار آماده یا اتصال ابزارها برطرف نشود. تعداد کارکنان معیار کافی نیست؛ هزینه حل مسئله و توان نگهداری سامانه را هم باید بسنجید.
آیا ساخت نرمافزار اختصاصی یعنی مالک همه کدها هستیم؟
نه لزوماً؛ دامنه مالکیت و حق تغییر یا واگذاری باید در قرارداد روشن باشد. اجزای آماده و کتابخانه‌های استفاده‌شده ممکن است مجوز مستقل داشته باشند.
ساخت نرمافزار اختصاصی چقدر زمان میبرد؟
بدون مشخص شدن دامنه و وابستگیها، زمان قابل اتکایی نمیتوان گفت. پیشنهاد اولیه باید فرضهای زمانبندی، مراحل تأیید و اثر تأخیر در داده یا دسترسی را نشان دهد.
آیا میتوان نرمافزار اختصاصی را کنار ابزارهای فعلی استفاده کرد؟
بله، گاهی ساخت یک بخش محدود و اتصال آن به سامانههای فعلی انتخاب مناسبتری است. ابتدا باید امکان تبادل داده، مجوز دسترسی و رفتار سیستم هنگام قطع اتصال بررسی شود.
اگر تیم سازنده تغییر کند، ادامه توسعه ممکن است؟
در صورت دسترسی به کد، مستندات، محیط اجرا و حقوق لازم، انتقال به تیم دیگر امکان‌پذیرتر می‌شود. بهتر است اجرای سامانه با مستندات تحویلی پیش از پایان همکاری آزمایش شود.
