انتخاب و طراحی پروژه‌ی خودت

در فصل ۰.۱۱ فهرستی از کارهای تکراری‌ات نوشتی. آن موقع نمی‌دانستی کدامشان شدنی است — حالا می‌دانی. پس اولین کارِ این ماژول این است: همان فهرست را باز کن و دوباره بخوانش.

و احتمالاً سه چیز عوض شده:

• بعضی‌ها که غیرممکن به نظر می‌رسیدند، حالا ساده‌اند.
• بعضی‌ها که ساده به نظر می‌رسیدند، حالا می‌دانی گیر دارند — مخصوصاً هر چیزی که PDF اسکن‌شده یا قضاوتِ انسانی در آن هست (M4 و ۸.۳).
• و چیزهای تازه‌ای اضافه شده که در این هشت ماژول به ذهنت رسیدند.

اگر بک‌لاگی ننوشته بودی، اشکالی ندارد — ولی همین حالا بنویس، قبل از ادامه. یک هفته کارهای تکراری‌ات را یادداشت کن. انتخابِ پروژه بدون فهرست، انتخاب از حافظه است — و حافظه فقط چیزهایی را می‌آورد که همین دیروز آزارت داده‌اند.

سه معیار، و هر سه لازم‌اند. پروژه‌ای که دو تا را دارد و سومی را ندارد، معمولاً نیمه‌کاره رها می‌شود — و برای هر کدام دلیلِ متفاوتی:

• کوچک — در یک تا سه نشست تمام شود. اگر بزرگ‌تر است، تکه‌اش کن و یک تکه را بردار (فصل ۲.۵.۲). پروژه‌ی بزرگ نه به‌خاطر سختی‌اش، بلکه به‌خاطر فاصله‌ی زیاد تا اولین نتیجه رها می‌شود.
• واقعی — کاری که واقعاً انجامش می‌دهی، نه چیزی که «خوب است داشته باشم». اگر این هفته انجامش ندادی، پروژه‌ی درستی نیست — چون هیچ‌وقت نمی‌فهمی جواب می‌دهد یا نه.
• مالِ خودت — تصمیمش با تو باشد، داده‌اش دستت باشد، و خرابی‌اش کسِ دیگری را زمین نزند. این هم کار را ساده می‌کند و هم ریسکِ M5 را حذف می‌کند.

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

و چند نمونه‌ی خوب، که هر سه معیار را دارند: خلاصه‌ی هفتگی از یادداشت‌های جلسات · مرتب‌کردن و نام‌گذاری فایل‌های ورودی · تبدیل یک فهرست به‌هم‌ریخته به جدول تمیز · گزارش ماهانه‌ای که هر بار دستی می‌سازی.

و چند نمونه‌ی بد برای پروژه‌ی اول — نه چون نشدنی‌اند، بلکه چون برای اولین پروژه بد هستند: چیزی که به داده‌ی مشتری دست بزند · چیزی که ایمیل به بیرون بفرستد (فصل ۸.۵.۴) · یا چیزی که کلِ یک فرآیندِ کاری را جایگزین کند.

این دوره پیش‌فرضش کار اداری بوده. ولی اگر آن‌طور کار نمی‌کنی، پروژه‌ی پایانی همچنان برایت هست:

• فریلنسر: پیگیری پروژه‌ها و پرداخت‌ها · ساختن پیش‌فاکتور از یک الگو · جمع‌کردن ساعت‌های کارکرد · یک فایل برای هر مشتری با تاریخچه‌ی گفت‌وگوها (که همان سیستمِ M6 است).
• دانشجو: خلاصه‌کردن مقاله‌ها با ساختار یکسان · ساختن کتابخانه‌ی منابع با یادداشت · تبدیل جزوه‌های پراکنده به یک سند مرتب · یا آماده‌کردن جدول داده‌های آزمایش.
• کسب‌وکار کوچک: گزارش فروش هفتگی · پیگیری موجودی · جواب‌های آماده برای سؤال‌های تکراری مشتری‌ها · یا مرتب‌کردن فاکتورها (فصل ۸.۳ — با تأیید انسانی).
• و اگر هیچ‌کدام: یک پروژه‌ی شخصی. مرتب‌کردن کتابخانه‌ی کتاب‌هایت، پیگیری خرج ماهانه، یا خلاصه‌ی هفتگی از چیزهایی که خوانده‌ای. یاد گرفتن با پروژه‌ی شخصی، هیچ کم‌تر از پروژه‌ی کاری نیست — مهارت همان است.

حالا spec بنویس. همان چهار بندِ فصل ۲.۴.۲، به‌علاوه‌ی سه چیزی که در این هشت ماژول یاد گرفتی و آن موقع نمی‌دانستی:

1. ورودی: چه چیزی، از کجا، و در چه قالبی.
2. خروجی: چه چیزی، و کجا می‌رود (فصل ۸.۵.۵ — و این را همین حالا تصمیم بگیر، نه آخرِ کار).
3. «تمام شد» یعنی چه: سه شرطِ قابل بررسی. نه «خوب کار کند».
4. دامنه: چه چیزی در این نسخه نیست.
5. راستی‌آزمایی: از کجا می‌فهمی خروجی درست است؟ (M4)
6. trigger: دستی یا خودکار؟ (فصل ۸.۶ — و برای پروژه‌ی اول، دستی جوابِ درست است.)
7. و داده: چیزی حساس در جریان هست؟ (فصل ۵.۳.۱)

و بندِ چهارم را جدی بگیر. نوشتنِ آنچه نمی‌سازی، همان چیزی است که پروژه را کوچک نگه می‌دارد — چون وسط کار همیشه ایده‌های تازه می‌آیند و بدون این بند، هر کدامشان وارد می‌شوند.