تجزیه‌ی مسئله و نقشه‌ی راه

در فصل ۱.۲ حلقه‌ی ایجنت را دیدی و در ۱.۳ دیدی که context با هر دور بزرگ‌تر و شلوغ‌تر می‌شود. حالا این دو را کنار هم بگذار.

وقتی یک کار بزرگ را یک‌جا می‌سپاری، سه چیز اتفاق می‌افتد:

• خطا انباشته می‌شود. اگر قدم سوم کمی کج برود، قدم‌های چهارم تا دهم روی همان کجی بنا می‌شوند. آخرش می‌بینی نتیجه غلط است ولی نمی‌دانی از کجا.
• context شلوغ می‌شود — همان context rot فصل ۱.۳ — و کیفیت دقیقاً وسط کار افت می‌کند.
• و نقطه‌ی بازبینی نداری. تا آخر کار هیچ چیزی برای دیدن نیست، و وقتی چیزی هست، دیگر برای تصحیحِ ارزان دیر است.

سومی مهم‌ترین است. مشکل کار بزرگ این نیست که سخت است؛ این است که تا آخرش نمی‌فهمی درست پیش می‌رود یا نه.

معیارِ یک مرحله‌ی خوب ساده است:

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

مثال. کار: «از فایل سفارش‌ها یک گزارش هفتگی بساز.»

شکستن بد: ۱) فایل را بخوان ۲) پردازشش کن ۳) گزارش بده. قدم دوم خروجیِ قابل‌دیدن ندارد — «پردازش» یعنی چه؟

شکستن خوب:

1. فایل را بخوان و بگو چند ردیف دارد و ستون‌هایش چیست. ← می‌توانم ببینم درست خوانده یا نه.
2. ردیف‌های مشکل‌دار را فهرست کن (تاریخ خراب، خانه‌ی خالی). ← می‌توانم ببینم همان‌هایی را پیدا کرده که خودم می‌دانم هست.
3. جمع به تفکیک محصول را بده، فقط برای ردیف‌های سالم. ← می‌توانم یکی‌اش را دستی چک کنم.
4. خروجی را در قالب نهایی بنویس.

حالا اگر عددِ آخر غلط باشد، دقیقاً می‌دانی کدام قدم را باید نگاه کنی.

روشی که برای هر کاری جواب می‌دهد، و عمداً از آخر شروع می‌شود:

1. B را بنویس — وضعیت نهایی. این همان «تمام شد» spec است.
2. A را بنویس — همین حالا چه داری.
3. از B رو به عقب بیا: «برای اینکه B ممکن شود، بلافاصله قبلش چه چیزی باید آماده باشد؟» و همین را تکرار کن تا به A برسی.

چرا از آخر؟ چون وقتی از اول جلو می‌روی، کارهایی می‌نویسی که به نظر لازم می‌آیند. وقتی از آخر عقب می‌آیی، فقط کارهایی می‌نویسی که واقعاً برای رسیدن به B ضروری‌اند. این تفاوت معمولاً نصفِ فهرست را حذف می‌کند.

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

برای هر مرحله یک سؤال: «برای انجام این، چه چیزی باید از قبل آماده باشد؟» هر چیزی که در جواب آمد، باید قبلش بیاید.

دو تله‌ی رایج:

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

و اگر دو مرحله به هم وابسته نیستند، ترتیبشان مهم نیست — آن را بگذار که ارزان‌تر است، تا زودتر یاد بگیری.

نقشه که آماده شد، یک خطر می‌ماند: نگاه‌کردن به نقشه و شروع‌نکردن.

پس یک سؤال آخر: کوچک‌ترین کاری که همین حالا می‌شود انجام داد و چیزی به من یاد می‌دهد چیست؟

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

مثال: اگر کل نقشه‌ات به این بستگی دارد که ایجنت بتواند آن PDF فارسی را بخواند، همان را اول امتحان کن — با یک صفحه. اگر نشد، کل نقشه عوض می‌شود و بهتر است الان بفهمی، نه بعد از سه مرحله. (اینکه چه چیزی روی فارسی کار می‌کند، درس ۴.۲ است.)

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