وقتی با یک شرکت برنامه‌نویسی در شیراز درباره سفارش نرم‌افزار صحبت می‌کنید، اولین پرسش معمولاً هزینه است. اما دو تیم ممکن است برای جمله «یک سامانه فروش می‌خواهم» دو محصول کاملاً متفاوت تصور کنند. یک شرح نیاز کوتاه، این تفاوت را آشکار می‌کند و به شما کمک می‌کند پیشنهادها را بر اساس خروجی یکسان مقایسه کنید. هدف این راهنما آماده کردن سندی است که بتوانید پیش از جلسه نیازسنجی برای تیم مجری بفرستید.
اول مسئله را بنویسید، سپس امکانات را
به‌جای شروع با فهرست دکمه‌ها، توضیح دهید امروز چه کاری انجام می‌شود و کجای آن مشکل دارید. مثلاً «سفارش‌ها در سه فایل اکسل ثبت می‌شوند و مسئول انبار برای تأیید موجودی باید تماس بگیرد» یک مسئله قابل بررسی است. عبارت «یک پنل حرفه‌ای و سریع» هنوز معیاری برای طراحی و تحویل نمی‌دهد.
برای همان مثال، نتیجه مطلوب می‌تواند این باشد: کارشناس فروش سفارش را ثبت کند، انباردار موجودی را تأیید کند و مدیر وضعیت سفارش را ببیند. اگر مسئله شما بیشتر به مدیریت فایل‌های پراکنده مربوط است، ابتدا راهنمای تبدیل اکسل به نرم‌افزار اختصاصی را بخوانید؛ ممکن است اصلاح فرایند موجود، پیش از ساخت سامانه کامل، ارزش بیشتری داشته باشد.
یک برگه نیازسنجی با هفت بخش بسازید
- هدف: این پروژه چه مشکل مشخصی را حل می‌کند و مسئول تأیید نتیجه چه کسی است؟
- کاربران: مشتری، کارمند، مدیر و پشتیبان هرکدام چه کاری انجام می‌دهند؟ حدود دسترسی آن‌ها را جدا بنویسید.
- مسیر اصلی: یک کار واقعی را از شروع تا پایان شرح دهید؛ مثلاً ثبت درخواست تا تأیید و بستن آن.
- داده‌ها: چه اطلاعاتی وارد می‌شود، از کجا می‌آید و چه خروجی یا گزارشی لازم دارید؟ نمونه بی‌نام کافی است.
- اتصال‌ها: حسابداری، پیامک، درگاه یا سیستم انبار موجود را معرفی کنید؛ داشتن مستندات اتصال را هم مشخص کنید.
- محدودیت‌ها: زمان مورد نیاز، سقف بودجه مورد نظر، حجم تقریبی کار و نیاز به موبایل یا کار بدون اینترنت را توضیح دهید.
- تحویل: نسخه قابل استفاده، آموزش، مستندات، کد و دسترسی‌های مدیریتی مورد توافق را فهرست کنید.
نمونه: نسخه اول یک سامانه پیگیری سفارش
فرض کنید یک کسب‌وکار محلی می‌خواهد سفارش‌های فروش و تحویل را هماهنگ کند. نسخه اول می‌تواند فقط سه نقش فروش، انبار و مدیر داشته باشد. مسیر اصلی چنین است: فروش سفارش پیش‌نویس را ثبت می‌کند؛ انبار موجودی را بررسی می‌کند؛ فروش زمان تحویل را با مشتری هماهنگ می‌کند؛ مدیر سفارش‌های معطل را گزارش می‌گیرد. ساخت اپلیکیشن مستقل مشتری، باشگاه امتیاز و اتصال به چند شعبه فعلاً بیرون از این نسخه قرار می‌گیرد.
این مرزبندی به معنی کنار گذاشتن توسعه آینده نیست. کمک می‌کند مرحله اول قابل تحویل باشد و تصمیم‌های بعدی بر اساس استفاده واقعی گرفته شود. برای هر امکان خارج از نسخه اول، دلیل و زمان بازبینی بنویسید تا در جلسه‌های بعد دوباره به‌عنوان ضرورت فوری مطرح نشود.
معیار پذیرش را با یک سناریو بنویسید
برای «گزارش سفارش‌ها» مشخص کنید چه ستون‌هایی لازم است، چه کسانی آن را می‌بینند و چه فیلتری دارد. نمونه معیار پذیرش: «مدیر با انتخاب بازه تاریخ و وضعیت، سفارش‌ها را ببیند؛ مجموع گزارش با سفارش‌های همان بازه برابر باشد؛ کارشناس فروش به گزارش کل شعب دسترسی نداشته باشد.» تیم مجری و سفارش‌دهنده باید بتوانند همین سناریو را هنگام تحویل اجرا کنند.
حالت خطا را هم فراموش نکنید: اگر موجودی کافی نبود، اتصال قطع شد یا یک کاربر دو بار روی ثبت کلیک کرد، چه اتفاقی باید بیفتد؟ این پرسش‌ها جلوی بخشی از اختلاف‌هایی را می‌گیرند که پس از نمایش ظاهر سایت آشکار می‌شوند.
پیشنهاد دو شرکت را چگونه مقایسه کنیم؟
از هر تیم بخواهید فرض‌ها، موارد خارج از محدوده و مسئولیت آماده کردن داده‌ها را روشن کند. برآوردی که به اتصال تأییدنشده حسابداری وابسته است، با برآورد یک سامانه مستقل قابل مقایسه مستقیم نیست. هزینه توسعه، زیرساخت، ورود اطلاعات و پشتیبانی را جدا ببینید. برای بررسی کیفیت تیم، از راهنمای انتخاب شرکت برنامه‌نویسی در شیراز و نمونه‌کارهای گلجام کمک بگیرید.
پرسش‌های رایج
آیا باید قبل از جلسه، تمام جزئیات فنی را بدانم؟
خیر. مسئله، کاربران، نمونه کار واقعی و محدودیت‌ها را آماده کنید. انتخاب فناوری و بررسی امکان اتصال‌ها، بخش مهمی از نیازسنجی مشترک است.
آیا سند کوتاه برای برآورد قطعی کافی است؟
همیشه کافی نیست. سند اولیه برای مشخص کردن ابهام‌ها و محدوده مناسب است؛ قیمت و زمان نهایی به بررسی جزئیات و توافق بر سر خروجی بستگی دارد.
برای شروع، همین هفت بخش را در یک فایل بنویسید و همراه یک سناریوی واقعی به تیم گلجام برای نیازسنجی نرم‌افزار بفرستید. جزئیات خدمت را نیز در صفحه نرم‌افزار اختصاصی و اتوماسیون ببینید.