برای تعیین محدوده پروژه برنامه نویسی قبل از قرارداد، یک جلسه کشف نیاز برگزار کنید، اهداف و معیار موفقیت را مکتوب کنید، سناریوهای کاربر و فهرست قابلیت‌ها را بنویسید، هر قابلیت را با «معیار پذیرش» تعریف کنید، موارد خارج از محدوده را صریح اعلام کنید، مفروضات و وابستگی‌ها را ثبت کنید، مایلستون‌ها و شرایط پرداخت را مشخص کنید و همه اینها را در یک سند «شرح کار» (SOW) ضمیمه قرارداد کنید. این کار از اختلاف، دوباره‌کاری و تغییر محدوده ناگهانی جلوگیری می‌کند.

مراحل تعیین محدوده پروژه برنامه نویسی

  1. جلسه کشف نیاز (Discovery) 60 تا 90 دقیقه
    هدف، نتایج مورد انتظار و محدودیت‌ها را روشن کنید. ضبط صوتی یا نوشتاری جلسه را نگه دارید و در پایان، جمع‌بندی کوتاه را برای تایید تکرار کنید (Playback).

    سوال‌های کلیدی در Discovery

    • هدف کسب‌وکار چیست و چه معیاری نشان می‌دهد به آن رسیده‌ایم؟
    • کاربران اصلی چه کسانی‌اند و مهم‌ترین کارشان در سیستم چیست؟
    • چه سیستم‌ها یا APIهایی باید متصل شوند؟ مالک و دسترسی آنها کیست؟
    • محدودیت‌های زمان، بودجه، تکنولوژی و امنیت چیست؟
    • چه چیزهایی قطعا «نیست» یا «الان لازم نیست»؟

  2. تعریف هدف و معیار موفقیت (قابل اندازه‌گیری)
    هدف را با خروجی قابل سنجش بنویسید: «افزایش ثبت‌نام ماهانه تا X%»، «تحویل MVP قابل دمو تا تاریخ مشخص»، «پشتیبانی از ۱۰۰۰ کاربر همزمان در تست بار».

  3. شناسایی نقش‌ها و سناریوهای اصلی کاربران
    ۳ تا ۵ سناریوی حیاتی را به زبان کاربر بنویسید: «به عنوان فروشنده، می‌خواهم سفارش جدید ثبت کنم تا وضعیت انبار کم نشود».

  4. فهرست قابلیت‌ها + معیار پذیرش
    هر Feature باید «تمام‌شدنی» باشد. برای هر مورد، شرایط پذیرش (Acceptance Criteria) را اضافه کنید تا مرز کیفیت روشن شود.

    Feature: ثبت‌نام با ایمیل
  Scenario: ثبت‌نام موفق
    Given کاربر ایمیل معتبر و رمز عبور 8 کاراکتری وارد کرده است
    When روی دکمه ثبت‌نام می‌زند
    Then حساب ساخته می‌شود و ایمیل تایید ارسال می‌گردد
    And کاربر پیام «لطفا ایمیل خود را تایید کنید» می‌بیند

    اگر Gherkin نمی‌نویسید، حداقل 3-5 شرط روشن مانند «ایمیل تایید ارسال شود»، «فرم خطای معتبر نمایش دهد» را ذکر کنید.

  5. محدوده و خارج از محدوده (Out of Scope)
    برای جلوگیری از سوءبرداشت، به‌صراحت بنویسید چه چیزهایی نیست:

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

  6. مفروضات، وابستگی‌ها و ریسک‌ها
    نمونه مفروضه: «دسترسی به API پیامک تا تاریخ X برقرار است». اگر مفروضه نقض شود، تغییر برنامه/هزینه محتمل است. وابستگی‌ها را با مالک و زمان آماده‌سازی‌شان بنویسید.

  7. تحویل‌دادنی‌ها (Deliverables) و آثار قابل تحویل
    مخزن کد، مستندات API، فایل طراحی، اسکریپت استقرار، گزارش تست، راهنمای استقرار، ویدئوی آموزش پنل ادمین. هر مورد را با فرمت و محل تحویل مشخص کنید.

  8. زمان‌بندی، مایلستون‌ها و شرایط پرداخت
    کار را به مایلستون‌های مستقل و قابل ارزیابی تقسیم کنید. هر مایلستون باید خروجی قابل دمو داشته باشد و پرداخت بر اساس پذیرش آن آزاد شود.

  9. مدیریت تغییر (Change Control)
    فرایند شفاف برای درخواست تغییر تعریف کنید: ثبت درخواست، تحلیل اثر بر زمان/هزینه، تایید کتبی، به‌روزرسانی SOW.

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

  10. پذیرش نهایی، ضمانت رفع اشکال و پشتیبانی
    معیار پذیرش نهایی، بازه رفع باگ (مثلا رفع باگ‌های Blocker و Critical)، ساعات پاسخ‌گویی و سطح خدمات (SLA) را مشخص کنید.

نمونه ساختار سند شرح کار (SOW) برای پیوست قرارداد

۱) خلاصه اجرایی

هدف پروژه، خروجی کلیدی، تاریخ شروع/پایان مورد انتظار.

۲) دامنه کار

  • قابلیت‌ها: فهرست Featureها با توضیح یک‌خطی
  • سناریوهای کاربر: ۳ تا ۵ سناریوی اصلی
  • محدوده/خارج از محدوده: موارد درون و بیرون محدوده

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

برای هر Feature، شرایط قابل سنجش پذیرش. مثال: «لاگین حداکثر در ۳ ثانیه پاسخ دهد».

۴) مفروضات و وابستگی‌ها

لیست مفروضات، APIها، دسترسی‌ها، داده‌های اولیه و مالک هر وابستگی.

۵) تحویل‌دادنی‌ها

فهرست آثار قابل تحویل با فرمت، محل تحویل و مسئول تایید.

۶) برنامه و مایلستون‌ها

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

۷) مدیریت تغییر

مراحل ثبت، ارزیابی، تایید و اعمال تغییر.

۸) پذیرش نهایی و پشتیبانی

تعریف «انجام‌شده»، بازه گارانتی باگ، سطح پشتیبانی.

ماتریس محدوده (Scope Matrix) نمونه

قابلیتدر محدودهتوضیح/محدودیت
احراز هویت ایمیلبلهOAuth در فاز بعد
داشبورد مدیربلهنمودارها حداقلی؛ گزارش‌گیری پیشرفته خارج از محدوده
پرداخت آنلاینبلهدرگاه داخلی؛ پرداخت ارزی خارج از محدوده
اپ موبایلخیرفقط وب ریسپانسیو

یک مثال کوتاه از تبدیل ابهام به معیار پذیرش

ابهام: «داشبورد سریع و حرفه‌ای باشد»
معیار پذیرش روشن:

  • زمان لود اولیه کمتر از ۳ ثانیه روی اتصال 4G (اندازه‌گیری با Lighthouse)
  • Core Web Vitals در وضعیت قابل‌قبول (LCP زیر 2.5s)
  • ۳ کارت کلیدی: فروش امروز، سفارش‌های باز، پیام‌های جدید

اشتباهات رایج در تعیین محدوده پروژه برنامه نویسی

  • استفاده از واژه‌های مبهم مثل «کامل»، «پیشرفته»، «مثل سایت X». راه‌حل: معیارهای کمی و مثال رفتاری اضافه کنید.
  • نادیده گرفتن خارج از محدوده. راه‌حل: بخش Out of Scope را اجباری کنید.
  • نداشتن معیار پذیرش. راه‌حل: برای هر Feature حداقل سه شرط پذیرش بنویسید.
  • فرض دسترسی به وابستگی‌ها بدون مالک و تاریخ. راه‌حل: مالک، تاریخ و ریسک جایگزین را ثبت کنید.
  • مایلستون‌های مبهم مثل «۸۰٪ انجام شد». راه‌حل: خروجی قابل دمو + چک‌لیست پذیرش برای هر مایلستون.
  • بی‌برنامگی در تغییرات و پذیرش شفاهی. راه‌حل: فرایند Change Control با تایید کتبی.

چگونه نتیجه را بررسی کنیم و ریسک تغییر محدوده را کم کنیم

  1. بازپخش نیاز (Playback): جمع‌بندی ۵ تا ۱۰ بندی جلسه Discovery را برای تایید ارسال کنید.
  2. نمونه تعاملی کم‌هزینه: وایرفریم یا ماکاپ قابل کلیک برای ۳ سناریوی اصلی بسازید تا مسیرها تایید شوند.
  3. داده نمونه و سناریوهای تست: برای هر سناریو، داده ورودی و خروجی مورد انتظار را مشخص کنید.
  4. پروتکل پذیرش مایلستون: قبل از شروع، چک‌لیست پذیرش هر مایلستون را توافق کنید.
  5. بازبینی مفروضات: در شروع هر مایلستون، صحت مفروضات و دسترسی‌ها را چک و مستند کنید.

الگوی کوتاه «تعریف انجام‌شده» (Definition of Done)

  • کد در مخزن اصلی و Merge شده
  • تست واحد حداقل برای مسیرهای بحرانی
  • پوشش خطا و پیام مناسب کاربر
  • مستند نصب/استقرار به‌روز
  • دموی موفق به ذینفعان

قالب‌ها و چک لیست آماده استفاده

چک لیست ۱: Discovery

  • هدف و معیار موفقیت روشن شد
  • ۳ سناریوی اصلی کاربر نوشته شد
  • محدودیت‌های زمان/بودجه/فنی ثبت شد
  • وابستگی‌ها با مالک و تاریخ مشخص شد

چک لیست ۲: دامنه و پذیرش

  • فهرست قابلیت‌ها + معیار پذیرش برای هر مورد
  • Out of Scope صریح نوشته شد
  • تحویل‌دادنی‌ها و فرمت آنها مشخص شد
  • تعریف انجام‌شده توافق شد

چک لیست ۳: برنامه و تغییر

  • مایلستون‌ها با خروجی قابل دمو
  • شرایط پرداخت وابسته به پذیرش مایلستون
  • فرایند تغییرات و تایید کتبی
  • بازه گارانتی و سطح پشتیبانی

مثال خلاصه SOW برای یک MVP فروشگاه

  • هدف: امکان ثبت سفارش آنلاین و مدیریت سفارش در ۶ هفته
  • کاربران: خریدار، مدیر
  • قابلیت‌ها: فهرست محصول، سبد خرید، پرداخت داخلی، داشبورد سفارش مدیر
  • Out of Scope: اپ موبایل، پرداخت ارزی، کوپن تخفیف پیشرفته
  • پذیرش: پرداخت موفق درگاه X، ایمیل تایید سفارش، وضعیت سفارش در داشبورد
  • وابستگی: دسترسی درگاه پرداخت تا تاریخ Y
  • مایلستون ۱: کاتالوگ و سبد خرید (دمو + پرداخت ۳۰٪)
  • مایلستون ۲: پرداخت و تاییدیه‌ها (دمو + پرداخت 40٪)
  • مایلستون ۳: داشبورد مدیر و استقرار (پذیرش نهایی + پرداخت 30٪)
  • گارانتی: رفع باگ‌های بحرانی در بازه توافقی

گام بعدی چیست؟

یک جلسه Discovery کوتاه برنامه‌ریزی کنید، از قالب SOW بالا برای نوشتن محدوده استفاده کنید، معیارهای پذیرش هر قابلیت را کامل کنید و سپس SOW را به‌عنوان پیوست قرارداد برای امضا ارسال کنید. از همین امروز، Out of Scope و فرایند تغییر را شفاف بنویسید تا اجرای پروژه بدون اصطکاک شروع شود.