از ایده تا spec

spec یعنی نوشتنِ قبل از شروع اینکه دقیقاً چه می‌خواهی. نه یک سند رسمی — نصف صفحه کافی است.

چرا لازم است؟ چون بدون آن، دو اتفاق می‌افتد که هر دو را احتمالاً تجربه کرده‌ای:

• هیچ‌وقت تمام نمی‌شود. هر بار که نتیجه را می‌بینی یک چیز دیگر به ذهنت می‌رسد. نه چون بی‌نظمی — چون هیچ‌جا ننوشته‌ای که «تمام شد» یعنی چه.
• چیزی می‌سازی که نمی‌خواستی. ایجنت به سؤالی که پرسیدی جواب می‌دهد. اگر سؤالت مبهم بود، جوابِ مبهم می‌گیری — و اشکال از او نیست.

و یک فایده‌ی سومِ کمتر واضح: خودِ نوشتن spec، مشکل را روشن می‌کند. خیلی وقت‌ها وسط نوشتنش می‌فهمی که خودت هم دقیقاً نمی‌دانستی چه می‌خواهی — و پیدا کردن این، ارزان‌تر از فهمیدنش بعد از دو روز کار است.

پنج تکه، و هیچ‌کدام بیش از چند خط:

1. ورودی چیست؟ دقیقاً چه فایلی، از کجا، با چه قالبی. «فایل فروش» کافی نیست؛ «فایل CSV که هر دوشنبه از پنل می‌گیرم، با این ستون‌ها» کافی است.
2. خروجی چیست؟ چه چیزی، در چه قالبی، کجا ذخیره شود.
3. چه کاری روی ورودی انجام شود؟ قاعده‌ها — همان چیزی که معیار «قاعده‌مندی» فصل ۲.۱ می‌سنجید.
4. «تمام شد» یعنی چه؟ بخش بعدی.
5. چه چیزی جزو این کار نیست؟ این تکه را همه جا می‌اندازند و مهم‌ترین است — بخش ۲.۴.۴.

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

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

مقایسه کن:

• ❌ «گزارش خوبی تولید کند.» — چه کسی می‌گوید خوب است؟
• ❌ «داده را تمیز کند.» — تا کجا؟
• ✅ «برای فایل نمونه‌ی این ماه، یک فایل خروجی بسازد که جمع فروش هر محصول را داشته باشد، مرجوعی‌ها کم شده باشند، و ردیف‌های مشکوک جدا فهرست شده باشند.»

مورد سوم را می‌شود امتحان کرد. دو مورد اول را نه.

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

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

رایج‌ترین دلیل شکستِ اولین پروژه‌ها این نیست که سخت‌اند. این است که بزرگ‌اند.

و بزرگ‌شدن معمولاً بی‌سروصدا اتفاق می‌افتد: «حالا که دارم این را می‌سازم، بگذار این را هم اضافه کنم…» — هر بار منطقی به نظر می‌رسد و دفعه‌ی دهم دیگر نمی‌دانی کجای کاری.

دو ابزار ساده:

• بنویس چه چیزی جزو این کار نیست. فهرست «بیرونِ دامنه» را همان اول بنویس. هر چیزی که وسط کار به ذهنت رسید، به‌جای اضافه‌کردن به کار، به این فهرست اضافه کن.
• نسخه‌ی اول را عمداً ناقص طراحی کن. «فقط برای فایل این ماه»، «فقط برای یک محصول». وقتی کار کرد، گسترشش آسان است — و مهم‌تر، آن‌وقت می‌دانی داری چه چیزی را گسترش می‌دهی.

این همان چیزی است که در ماژول ۹ به‌عنوان معیار انتخاب پروژه‌ی پایانی برمی‌گردد: کوچک، واقعی، مالِ خودت.

در فصل ۰.۱۰ درخواست را آماده به تو دادیم. حالا ببینیم spec‌اش چه شکلی بود:

• ورودی: پوشه‌ی نمونه‌ها/اسناد/ — هشت فایل متنی اداری، بدون ساختار مشترک، در زمین بازی.
• خروجی: یک فایل متنی، حداکثر یک صفحه، در همان پوشه.
• قاعده‌ها: هر هشت فایل خوانده شوند · کارهای باز فهرست شوند · هر چیزی که مبهم است جدا فهرست شود · هیچ چیزی حدس زده نشود.
• تمام شد یعنی: گزارش هر سه موردِ شناخته‌شده را آورده باشد — عدد اردیبهشت که خودِ فایل دربارهٔ‌اش تردید کرده، فایل بی‌عنوان به‌عنوان مبهم، و بودجه‌ی تبلیغات به‌عنوان کار فراموش‌شده.
• بیرونِ دامنه: مرتب‌کردن یا تغییر نام فایل‌ها · تصمیم‌گیری درباره‌ی کارها · هر فایلی بیرون این پوشه.

حالا نگاه کن به تکه‌ی «تمام شد»: این دقیقاً همان سه چیزی است که در بخش ۰.۱۰.۴ گفتیم بگرد. یعنی آن راستی‌آزمایی، در واقع همین spec بود که از قبل نوشته شده بود — تو فقط نمی‌دانستی اسمش این است.