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