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

مسیر کار را بشناسیم

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

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

درباره نتیجه مطلوب توافق کنیم

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

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

• یک فرایند کامل را شرح دهید.
• تصمیم‌گیرنده هر مرحله را مشخص کنید.
• استثناها و پرسش‌های بی‌پاسخ را ثبت کنید.

فرض مبهم را زودتر بررسی کنیم

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

نتیجه هر بررسی و تغییر تصمیم را یادداشت کنید. این کار نمی‌گذارد یک فرض اولیه بی‌دلیل به نیازمندی دائمی تبدیل شود و برای تصمیم‌های فنی بعدی زمینه می‌سازد.

شناخت مسئله، بخشی از ساخت محصول است

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

نخستین خروجی می‌تواند یک درک مشترک باشد: مسئله چیست، چه کسانی با آن درگیرند و چه نتیجه‌ای ارزش دنبال کردن دارد. پس از آن، کد با هدف روشن‌تری نوشته می‌شود.