نیازسنجی نرم‌افزار قبل از کدنویسی؛ نقشه راه ۱۰ مرحله‌ای

نیازسنجی نرم‌افزار قبل از کدنویسی از تعریف قابلیت‌ها شروع نمی‌شود؛ ابتدا باید مشکل کسب‌وکار، کاربران، فرایندهای فعلی، نتیجه مورد انتظار و محدودیت‌های پروژه مشخص شوند. سپس می‌توان قابلیت‌ها را اولویت‌بندی کرد، نمونه اولیه ساخت و درباره هزینه و زمان توسعه تصمیم گرفت.

شروع مستقیم برنامه‌نویسی بر اساس چند جلسه شفاهی یا فهرستی از امکانات، یکی از دلایل اصلی دوباره‌کاری در پروژه‌های نرم‌افزاری است. ممکن است تیم فنی تمام قابلیت‌های درخواست‌شده را پیاده‌سازی کند، اما محصول نهایی همچنان مسئله اصلی سازمان را حل نکند.

هدف نیازسنجی این نیست که پیش از توسعه، صدها صفحه مستند تولید شود. هدف این است که کارفرما، کاربران، تحلیلگر، طراح و تیم فنی درک مشترکی از مسئله، محدوده و خروجی پروژه داشته باشند.

استاندارد ISO/IEC/IEEE 29148 نیز مهندسی نیازمندی‌ها را مجموعه‌ای از فرایندها و خروجی‌هایی می‌داند که باید در چرخه عمر سیستم و نرم‌افزار مدیریت شوند.

نیازسنجی نرم‌افزار فرایند شناسایی، تحلیل، اولویت‌بندی، مستندسازی و اعتبارسنجی نیازهای کسب‌وکار و کاربران است.

در این مرحله باید مشخص شود:

نرم‌افزار قرار است کدام مشکل را حل کند.

چه افرادی از سیستم استفاده می‌کنند.

کاربران در سیستم چه فعالیت‌هایی انجام می‌دهند.

اطلاعات از کجا وارد و در کجا ذخیره می‌شوند.

چه قوانین و محدودیت‌هایی وجود دارد.

نرم‌افزار باید با کدام سیستم‌ها ارتباط داشته باشد.

چه قابلیت‌هایی برای نسخه اول ضروری هستند.

موفقیت پروژه با چه شاخص‌هایی اندازه‌گیری می‌شود.

استخراج نیازها فقط پرسیدن این سؤال نیست که «چه امکاناتی می‌خواهید؟» کاربران معمولاً راه‌حل موردنظر خود را بیان می‌کنند، در حالی که تحلیلگر باید مشکل و نیاز پشت آن درخواست را پیدا کند.

IREB نیز در فرایند استخراج نیازها بر شناسایی منابع اطلاعات، مشارکت ذی‌نفعان، انتخاب روش مناسب و حل تعارض میان خواسته‌ها تأکید می‌کند.

هر چیزی که در جلسه پروژه مطرح می‌شود الزاماً یک نیاز نرم‌افزاری نیست.

ممکن است مدیر بگوید: «یک داشبورد پیشرفته می‌خواهم.» این جمله هنوز مشخص نمی‌کند مدیر چه تصمیمی قرار است با داشبورد بگیرد، چه اطلاعاتی لازم دارد و داده‌ها از کجا تأمین می‌شوند.تحلیل درست از راه‌حل پیشنهادی عبور می‌کند و به مسئله اصلی می‌رسد. ممکن است پس از بررسی مشخص شود به‌جای ساخت اپلیکیشن جدید، اصلاح یک فرایند یا اتصال دو سیستم موجود کافی است.

فهرست قابلیت‌ها معمولاً تصویری از اجزای نرم‌افزار ارائه می‌دهد، اما رابطه آن‌ها با اهداف کسب‌وکار را مشخص نمی‌کند.

برای مثال، عبارت‌های زیر بیش از حد کلی هستند:

مدیریت کاربران

گزارش‌گیری پیشرفته

ثبت سفارش

سطح دسترسی

اعلان هوشمند

مدیریت اسناد

اتصال به حسابداری

تیم فنی برای پیاده‌سازی هرکدام از این قابلیت‌ها به اطلاعات دقیق‌تری نیاز دارد. در بخش ثبت سفارش باید مشخص شود چه کسی سفارش ایجاد می‌کند، چه اطلاعاتی اجباری هستند، قیمت چگونه محاسبه می‌شود، موجودی چه زمانی کم می‌شود و سفارش در چه شرایطی قابل ویرایش است.

بنابراین قابلیت باید در قالب یک سناریوی واقعی، قانون مشخص و نتیجه قابل‌بررسی تعریف شود.

اولین خروجی پروژه باید شرح روشنی از مشکلی باشد که قرار است حل شود.

عبارت‌هایی مانند «می‌خواهیم دیجیتال شویم»، «یک سیستم جامع لازم داریم» یا «نرم‌افزار قبلی قدیمی شده است» برای شروع کافی نیستند.

مسئله باید مشخص و ترجیحاً قابل‌اندازه‌گیری باشد:

تهیه گزارش فروش سه روز زمان می‌برد.

اطلاعات مشتریان در پنج فایل مختلف قرار دارند.

درخواست‌های داخلی وضعیت مشخصی ندارند.

پیگیری فروش به حافظه کارشناسان وابسته است.

اطلاعات موجودی با تأخیر به‌روزرسانی می‌شوند.

یک داده چند بار در سیستم‌های مختلف ثبت می‌شود.

مدیر امکان مشاهده عملکرد شعب را ندارد.

پس از تعریف مشکل باید مشخص شود حل آن چه نتیجه‌ای ایجاد می‌کند. برای مثال، هدف می‌تواند کاهش زمان تهیه گزارش از سه روز به ده دقیقه باشد.

هر قابلیت نرم‌افزاری باید به یک هدف مشخص متصل باشد. اگر ارتباط یک قابلیت با هدف پروژه معلوم نیست، احتمالاً باید اولویت آن دوباره بررسی شود.

اهداف مناسب می‌توانند شامل موارد زیر باشند:

کاهش زمان انجام فرایند

کاهش خطاهای ثبت اطلاعات

افزایش سرعت پاسخ‌گویی

یکپارچه شدن اطلاعات

افزایش شفافیت وضعیت درخواست‌ها

کاهش وابستگی به کارکنان خاص

افزایش تعداد پیگیری‌های فروش

کاهش هزینه عملیات

بهبود تجربه کاربران

صحبت کردن فقط با مدیرعامل یا سفارش‌دهنده برای شناخت نرم‌افزار کافی نیست. افرادی که هر روز با فرایند سروکار دارند، اطلاعاتی دارند که ممکن است در دستورالعمل‌های رسمی ثبت نشده باشد.

ذی‌نفعان پروژه می‌توانند شامل این افراد باشند:

مدیر یا حامی مالی پروژه

مدیران واحدهای درگیر

کاربران عملیاتی

مشتریان یا تأمین‌کنندگان

واحد فناوری اطلاعات

واحد مالی و حقوقی

مسئول امنیت اطلاعات

تیم پشتیبانی

مدیران شعب

تیم توسعه و تست

برای هر گروه باید نقش، نیاز، نگرانی و میزان اختیار مشخص شود. ممکن است مدیر فروش خواهان گزارش‌های بیشتر باشد، اما کارشناسان فروش سرعت ورود اطلاعات را مهم‌تر بدانند.

نادیده گرفتن کاربران نهایی باعث می‌شود سیستمی طراحی شود که از نظر مدیریتی کامل اما در استفاده روزانه پیچیده باشد.

پیش از طراحی وضعیت آینده باید بدانید کار در حال حاضر چگونه انجام می‌شود.

برای هر فرایند این موارد را ثبت کنید:

نقطه شروع

اطلاعات ورودی

مراحل انجام کار

افراد مسئول

تأییدهای لازم

تصمیم‌ها و قوانین

استثناها

نرم‌افزارها و فایل‌های مورد استفاده

خروجی نهایی

زمان انجام هر مرحله

برای مثال، در فرایند درخواست خرید باید مشخص شود درخواست چه زمانی ثبت می‌شود، چه کسی آن را بررسی می‌کند، سقف تأیید مدیران چقدر است و پس از رد درخواست چه اتفاقی می‌افتد.

مشاهده محیط واقعی کار در بسیاری از پروژه‌ها اطلاعات دقیق‌تری از مصاحبه به دست می‌دهد. ممکن است کارکنان فرایند رسمی را توضیح دهند، اما در عمل برای انجام سریع‌تر کار از فایل شخصی یا پیام‌رسان استفاده کنند.

هدف نباید انتقال تمام مراحل فعلی به نرم‌افزار باشد. بعضی از این مراحل ممکن است زائد، تکراری یا نتیجه محدودیت ابزارهای قبلی باشند.

پیش از طراحی سیستم بپرسید:

آیا این مرحله واقعاً ضروری است؟

آیا اطلاعاتی چند بار ثبت می‌شوند؟

آیا تعداد تأییدها منطقی است؟

آیا بعضی تصمیم‌ها را می‌توان قانون‌محور کرد؟

آیا دو مرحله می‌توانند هم‌زمان انجام شوند؟

آیا اطلاعات موردنیاز از ابتدا دریافت می‌شوند؟

آیا مسئول هر فعالیت مشخص است؟

آیا فرایند برای تمام شعب یکسان است؟

اگر فرایند نادرست بدون اصلاح وارد نرم‌افزار شود، سیستم فقط همان پیچیدگی را سریع‌تر اجرا خواهد کرد.

یکی از مهم‌ترین خروجی‌های نیازسنجی، تعیین مرزهای پروژه است. باید مشخص شود چه چیزهایی در نسخه اول ساخته می‌شوند و چه مواردی خارج از محدوده هستند.نوشتن موارد خارج از محدوده به اندازه قابلیت‌های داخل پروژه اهمیت دارد. این کار از اضافه شدن انتظارات پیش‌بینی‌نشده در میانه توسعه جلوگیری می‌کند.

محدوده نباید ثابت و غیرقابل‌تغییر باشد، اما هر تغییر باید از نظر هزینه، زمان، ریسک و اثر آن بر سایر بخش‌ها بررسی شود.

نیازمندی عملکردی مشخص می‌کند سیستم چه کاری باید انجام دهد.

نمونه‌ها:

کاربر بتواند درخواست جدید ثبت کند.

مدیر بتواند درخواست را تأیید یا رد کند.

سیستم پس از تأیید، درخواست را برای واحد مالی ارسال کند.

کارشناس بتواند سوابق مشتری را مشاهده کند.

موجودی پس از ثبت خروج کالا کاهش پیدا کند.

مدیر بتواند گزارش فروش شعب را مقایسه کند.

برای هر قابلیت باید سناریوی اصلی و شرایط استثنا نیز مشخص شود.

بخش : موضوعات لازم برای تحلیل

کاربران : نقش‌ها، ثبت‌نام، ورود و بازیابی دسترسی

اطلاعات : فیلدها، نوع داده، اجباری بودن و اعتبارسنجی

گردش‌کار : مراحل، ارجاع، تأیید، رد و بازگشت

قوانین : سقف‌ها، شروط، محاسبات و محدودیت‌ها

اعلان‌ها : رویداد، گیرنده، کانال و محتوای پیام

گزارش‌ها : شاخص، فیلتر، بازه زمانی و سطح دسترسی

سوابق : ثبت تغییرات، کاربر انجام‌دهنده و زمان

خروجی : فایل، چاپ، API یا نمایش در داشبورد

User Story می‌تواند برای بیان قابلیت از دید کاربر استفاده شود؛ مانند: «به‌عنوان مدیر فروش می‌خواهم سرنخ‌های بدون پیگیری را ببینم تا فرصت‌های فراموش‌شده را شناسایی کنم.» این قالب روی کاربر، نیاز و ارزش مورد انتظار تمرکز دارد.

بسیاری از اختلاف‌های پروژه به دلیل مشخص نبودن کیفیت مورد انتظار سیستم ایجاد می‌شوند.

نیازمندی‌های غیرعملکردی تعیین می‌کنند نرم‌افزار با چه سطحی از کیفیت کار کند:

سرعت پاسخ‌گویی

ظرفیت کاربران هم‌زمان

امنیت و کنترل دسترسی

پایداری و دسترس‌پذیری

نسخه پشتیبان

قابلیت بازیابی اطلاعات

ثبت سوابق تغییرات

سازگاری با موبایل

مرورگرها و دستگاه‌های پشتیبانی‌شده

امکان توسعه در آینده

حریم خصوصی

زبان و منطقه زمانی

دسترس‌پذیری برای کاربران دارای محدودیت

به‌جای عبارت مبهم «سیستم باید سریع باشد» باید معیار مشخصی نوشته شود؛ برای مثال، صفحات اصلی در شرایط عادی باید در کمتر از سه ثانیه نمایش داده شوند.

نیازمندی خوب باید تا حد امکان روشن، بدون ابهام و قابل‌بررسی باشد. راهنمای INCOSE نیز بر کامل، سازگار و قابل‌راستی‌آزمایی بودن نیازها تأکید می‌کند.

در پروژه‌های سازمانی، پیچیدگی اصلی همیشه رابط کاربری نیست؛ داده‌ها و ارتباط میان سیستم‌ها می‌توانند بخش دشوارتر پروژه باشند.

باید مشخص شود:

چه موجودیت‌هایی در سیستم وجود دارند؟

شناسه اصلی مشتری، کالا یا کارمند چیست؟

مالک هر داده کدام واحد است؟

چه کسی اجازه مشاهده یا ویرایش دارد؟

اطلاعات اولیه چگونه منتقل می‌شوند؟

داده‌های تکراری چگونه تشخیص داده می‌شوند؟

نرم‌افزار با چه سامانه‌هایی ارتباط دارد؟

تبادل اطلاعات لحظه‌ای است یا دوره‌ای؟

در صورت قطع ارتباط چه اتفاقی می‌افتد؟

کدام سیستم منبع اصلی اطلاعات است؟

برای مثال، اگر اطلاعات مشتری در CRM، حسابداری و فروشگاه اینترنتی متفاوت باشد، ابتدا باید درباره منبع معتبر و روش همگام‌سازی تصمیم گرفته شود.

سطح دسترسی نیز فقط به نام نقش‌ها محدود نمی‌شود. ممکن است مدیر شعبه فقط اطلاعات شعبه خود را ببیند یا کارشناس پس از نهایی شدن فاکتور اجازه ویرایش آن را نداشته باشد.

قرار نیست تمام ایده‌ها در نسخه اول توسعه داده شوند. نسخه اولیه باید کمترین مجموعه قابلیتی باشد که بتواند فرایند اصلی را از ابتدا تا انتها اجرا و ارزش محصول را آزمایش کند.

روش MoSCoW برای دسته‌بندی قابلیت‌ها قابل‌استفاده است:

اولویت باید بر اساس ارزش کسب‌وکار، تعداد کاربران، ریسک، وابستگی فنی و هزینه اجرا تعیین شود؛ نه صرفاً علاقه افراد حاضر در جلسه.

MVP نباید محصول ناقصی باشد که فرایند اصلی را اجرا نمی‌کند. نسخه اولیه باید محدود اما قابل‌استفاده و قابل‌اندازه‌گیری باشد.

نمونه اولیه یا Prototype نمایش ساده‌ای از صفحات و مسیرهای اصلی است. هدف آن آزمایش رنگ و زیبایی نیست؛ باید مشخص کند کاربر چگونه یک فعالیت را انجام می‌دهد.

نمونه اولیه می‌تواند برای این بخش‌ها ساخته شود:

ورود و داشبورد

ثبت فرم اصلی

مشاهده فهرست اطلاعات

گردش تأیید

نمایش وضعیت

گزارش اصلی

تنظیمات نقش‌ها

کاربران باید سناریوهای واقعی را روی نمونه انجام دهند. برای مثال، از کارشناس بخواهید یک سفارش ثبت کند یا از مدیر بخواهید درخواست در انتظار تأیید را پیدا کند.

اگر کاربر در نمونه اولیه مسیر را پیدا نکند، اصلاح آن بسیار کم‌هزینه‌تر از تغییر نرم‌افزار توسعه‌یافته خواهد بود.

معیار پذیرش مشخص می‌کند چه زمانی یک قابلیت کامل و قابل‌تحویل محسوب می‌شود.

برای مثال، معیار پذیرش ثبت درخواست خرید می‌تواند شامل این موارد باشد:

درخواست‌دهنده بتواند کالا، تعداد و دلیل خرید را وارد کند.

ثبت درخواست بدون انتخاب مرکز هزینه ممکن نباشد.

درخواست‌های بالاتر از مبلغ مشخص برای مدیر ارشد ارسال شوند.

پس از ثبت، شماره پیگیری ایجاد شود.

وضعیت درخواست برای ثبت‌کننده قابل‌مشاهده باشد.

تمام تأییدها در سابقه فرایند ذخیره شوند.

معیارهای پذیرش باید کوتاه، روشن و قابل‌آزمایش باشند و نتیجه مورد انتظار را تعریف کنند، نه روش برنامه‌نویسی را.

پرسش‌های مناسب باید فراتر از فهرست قابلیت‌ها باشند:

درباره مشکل

مشکل فعلی دقیقاً چیست؟

این مشکل برای چه کسی رخ می‌دهد؟

چند بار در ماه تکرار می‌شود؟

چه هزینه یا تأخیری ایجاد می‌کند؟

اگر حل نشود چه اتفاقی می‌افتد؟

درباره کاربران

چه کسانی از سیستم استفاده می‌کنند؟

هر نقش چه فعالیت‌هایی دارد؟

کاربران چقدر با نرم‌افزار آشنا هستند؟

آیا کاربران بیرون از سازمان نیز وجود دارند؟

کدام اطلاعات برای هر نقش محرمانه است؟

درباره فرایند

شروع و پایان کار کجاست؟

تصمیم‌ها بر اساس چه قوانینی گرفته می‌شوند؟

چه استثناهایی وجود دارد؟

بیشترین تأخیر در کدام مرحله رخ می‌دهد؟

چه کارهایی بیرون از سیستم انجام می‌شوند؟

درباره داده‌ها

اطلاعات از کجا وارد می‌شوند؟

چه داده‌هایی اجباری هستند؟

اطلاعات قبلی چگونه منتقل می‌شوند؟

کدام سیستم منبع معتبر است؟

چه گزارش‌هایی واقعاً استفاده می‌شوند؟

درباره آینده

تعداد کاربران چقدر رشد می‌کند؟

چه شعب یا شرکت‌هایی اضافه می‌شوند؟

چه سیستم‌هایی باید در آینده متصل شوند؟

قوانین کسب‌وکار چقدر تغییر می‌کنند؟

چه قابلیت‌هایی احتمالاً در مراحل بعد لازم خواهند شد؟

خروجی پروژه به اندازه و پیچیدگی نرم‌افزار بستگی دارد، اما معمولاً باید شامل موارد زیر باشد:

شرح مسئله و هدف تجاری

ذی‌نفعان و نقش‌های کاربری

نقشه فرایند فعلی

فرایند پیشنهادی

محدوده داخل و خارج پروژه

نیازمندی‌های عملکردی

نیازمندی‌های غیرعملکردی

قوانین کسب‌وکار

مدل اولیه اطلاعات

سطح دسترسی‌ها

یکپارچه‌سازی‌های موردنیاز

اولویت قابلیت‌ها

تعریف MVP

نمونه اولیه صفحات

معیارهای پذیرش

فرضیات و محدودیت‌ها

ریسک‌های اصلی

برنامه انتشار نسخه‌ها

روش مدیریت تغییرات

لازم نیست تمام پروژه‌ها یک سند طولانی و رسمی داشته باشند. پروژه کوچک می‌تواند از مستندی مختصر، User Story، نمونه اولیه و معیار پذیرش استفاده کند. پروژه سازمانی و حساس به مستندات کامل‌تر و قابلیت ردیابی دقیق‌تری نیاز دارد.

سند مشخصات نیازمندی‌های نرم‌افزار یا SRS مرجع مشترک کارفرما، تحلیلگر، طراح، برنامه‌نویس و تیم تست است.

این سند باید توضیح دهد:

سیستم برای چه هدفی ساخته می‌شود.

چه قابلیت‌هایی دارد.

کاربران آن چه کسانی هستند.

چه محدودیت‌هایی وجود دارد.

سیستم با چه داده‌ها و سامانه‌هایی کار می‌کند.

هر قابلیت تحت چه شرایطی پذیرفته می‌شود.

SRS نباید به سندی تبدیل شود که فقط در ابتدای پروژه امضا و سپس فراموش شود. نیازها در طول پروژه تکمیل یا اصلاح می‌شوند و تغییرات باید با نسخه، دلیل و اثر آن‌ها ثبت شوند.

استاندارد ISO 29148 نیز علاوه بر تعریف فرایندهای مهندسی نیازمندی، بر خروجی‌ها و اقلام اطلاعاتی حاصل از این فرایندها در طول چرخه عمر تأکید دارد.

پیش از شروع توسعه باید نیازها با کاربران و تصمیم‌گیرندگان مرور شوند.

روش‌های مناسب عبارت‌اند از:

بازخوانی سناریوها در جلسه

اجرای فرایند روی نمونه اولیه

بررسی قوانین با مدیران واحدها

طراحی نمونه گزارش

مرور سطح دسترسی‌ها

اجرای سناریوهای استثنا

بررسی امکان تست هر نیاز

تطبیق قابلیت‌ها با اهداف پروژه

تأیید اولویت‌ها و محدوده

در راستی‌آزمایی بررسی می‌شود نیازها درست، کامل، سازگار و قابل‌آزمایش نوشته شده‌اند. در اعتبارسنجی بررسی می‌شود آیا همین نیازها واقعاً خواسته و هدف ذی‌نفعان را منعکس می‌کنند.

وجود ابهام جزئی طبیعی است، اما ابهام درباره مسئله، فرایند اصلی، محدوده یا کاربران نشانه آماده نبودن پروژه است.

شروع با انتخاب تکنولوژی

زبان برنامه‌نویسی و معماری باید بعد از شناخت نیاز، مقیاس، امنیت و یکپارچه‌سازی انتخاب شوند.

صحبت کردن فقط با مدیران

مدیران هدف و سیاست را می‌دانند، اما کاربران جزئیات اجرای روزانه را می‌شناسند.

تبدیل تمام خواسته‌ها به قابلیت

هر ایده‌ای نباید وارد نسخه اول شود. بعضی خواسته‌ها کم‌ارزش، پرهزینه یا حتی متناقض هستند.

نادیده گرفتن نیازهای غیرعملکردی

امنیت، سرعت، پشتیبان‌گیری و مقیاس‌پذیری اگر دیر مطرح شوند، ممکن است معماری پروژه را تغییر دهند.

تعریف نکردن محدوده

نبود محدوده روشن باعث افزایش مداوم امکانات و اختلاف درباره هزینه و زمان می‌شود.

نداشتن نمونه اولیه

بسیاری از سوءتفاهم‌ها زمانی مشخص می‌شوند که کاربر صفحات و مسیر واقعی را مشاهده کند.

استفاده از عبارت‌های مبهم

عبارت‌هایی مانند سریع، کامل، هوشمند، کاربرپسند و پیشرفته بدون معیار قابل‌اندازه‌گیری نیستند.

ثابت فرض کردن نیازها

تغییر طبیعی است، اما باید ثبت، تحلیل و مدیریت شود. تغییر بدون کنترل باعث آشفتگی در زمان‌بندی و کیفیت پروژه خواهد شد.

نیازسنجی زمان می‌گیرد، اما هدف آن حذف زمان و هزینه‌های ناشی از ساخت قابلیت اشتباه است.

این مرحله نباید ماه‌ها بدون خروجی ادامه پیدا کند. می‌توان تحلیل را به شکل مرحله‌ای انجام داد:

شناخت مسئله و چشم‌انداز کل سیستم

تحلیل دقیق نسخه اول

ساخت و اعتبارسنجی نمونه اولیه

توسعه MVP

تکمیل نیازهای نسخه‌های بعدی بر اساس بازخورد

در روش‌های چابک نیز نیازها یک‌بار برای همیشه بسته نمی‌شوند. جزئیات نزدیک به زمان توسعه تکمیل می‌شوند، اما هدف، کاربران، محدوده اولیه و ارزش محصول باید پیش از شروع روشن باشند.

نیازسنجی نرم‌افزار قبل از کدنویسی باید مسئله کسب‌وکار را به مجموعه‌ای از نیازهای روشن، اولویت‌دار و قابل‌آزمایش تبدیل کند.

مسیر درست با شناخت مشکل و کاربران آغاز می‌شود، سپس فرایند فعلی، محدوده، قوانین، داده‌ها، دسترسی‌ها و نیازهای کیفی بررسی می‌شوند. پس از آن می‌توان نسخه اولیه را تعریف کرد، نمونه صفحات را آزمایش و معیارهای پذیرش را مشخص کرد.

یک پروژه زمانی آماده توسعه است که تیم بداند چه چیزی می‌سازد، برای چه کسی می‌سازد، چه مسئله‌ای را حل می‌کند و از کجا متوجه می‌شود نتیجه موفق بوده است.

کدنویسی سریع بدون شناخت مسئله ممکن است محصول را زودتر آماده کند، اما تضمین نمی‌کند محصول درستی ساخته شده باشد.