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