انتخاب دامنهی کوچک
هفت فصل قبل قطعهها را دادند. این فصل سرِ هم کردنشان است — و مهمترین تصمیمش همین اولی است.
دامنه را کوچک بگیر. کوچکتر از آنقدری که فکر میکنی معقول است. سه معیار:
- یک نوع چیز، نه چند نوع. «فاکتورها»، نه «امور مالی».
- در هفته چند بار پیش میآید — کمتر از آن، بازخوردی نمیگیری که سیستم را اصلاح کنی.
- و مالِ خودت باشد. اگر خرابکاریِ اولین دور به کسِ دیگری آسیب بزند، دامنهی اشتباهی را انتخاب کردهای.
و یک نکتهی روانشناختی که واقعی است: سیستمی که در یک نشست ساخته شود، بهکار میرود؛ سیستمی که سه هفته طراحی شود، نه. هدف این فصل یک سیستمِ کاملِ کوچک است، نه شروعِ یک سیستمِ بزرگ.
طراحی روی کاغذ
قبل از ساختن هیچ پوشهای، چهار چیز را بنویس. این همان specِ کوچکِ فصل ۲.۴.۲ است، فقط برای یک سیستم:
- چه چیزی وارد میشود، از کجا؟ (فصل ۶.۶.۲)
- چه اتفاقی رویش میافتد؟ — قدمها، به ترتیب.
- کجا تمام میشود؟
- و «تمام شد» یعنی چه؟ (فصل ۲.۴.۳) — بدون این، هیچوقت نمیدانی سیستم کار کرد یا نه.
روی کاغذ، چون کاغذ ارزان است و پاککردنش هزینهای ندارد. اگر همین چهار سؤال را نتوانستی جواب دهی، ساختنِ پوشهها کمکی نمیکند — فقط ابهام را به یک شکلِ مرتبتر منتقل میکند.
ساختن پوشهها و فایلها
حالا بساز. کمترین چیزی که یک سیستم کامل میسازد این است:
- سه پوشهی مرحلهای — ورودی، در جریان، آرشیو (فصل ۶.۲.۲).
_قانون.md— سه تا پنج بند (فصل ۶.۴)._وضعیت.md— چهار بخش (فصل ۶.۳.۳).- و اگر کارِ تکراریای دارد، یک فایل الگو.
میتوانی از ایجنت بخواهی همین ساختار را بسازد — ولی خودت طراحیاش کن. ساختن، کارِ مکانیکی است؛ طراحی، کارِ توست. و چون این کار فایل میسازد و نه بازنویسی، از کمخطرترین کارهای فصل ۵.۱.۴ است.
بهخاطر بسپار ساختار را قبل از داشتنِ داده بساز، ولی قانون را بعد از دیدنِ اولین داده نهایی کن. ساختار حدسزدنی است؛ قانون نه — قانون باید به موارد واقعی جواب بدهد و موارد واقعی همیشه عجیبترند از آن چیزی که تصور میکردی.
نوشتن قانون
سه تا پنج بند، با الگوی «وقتی … ، … — مگر …» (فصل ۶.۴.۲). و برای این سیستمِ اول، این سه بند تقریباً همیشه لازماند:
- قانون ورود: چه چیزی وارد ورودی میشود و با چه حداقلِ اطلاعاتی. (ارزان نگهش دار.)
- قانون نامگذاری: نامِ فایل چه شکلی است. این یکی بیشترین سود را در درازمدت دارد.
- قانون پایان: کِی چیزی به آرشیو میرود و چه کسی تصمیم میگیرد.
و قبل از اینکه به قوانینت اعتماد کنی، تستِ ابهام را بگیر: از ایجنت بخواه برای هر بند سه حالت مبهم بگوید. این پنج دقیقه، معمولاً یک دورِ کاملِ خرابکاری را حذف میکند.
آزمودن با یک ورودی واقعی
حالا مهمترین قدم. و تأکید روی یک کلمه است: واقعی.
نمونهی ساختگی سیستم را تأیید میکند، چون تو ساختگیاش را مطابق طراحیات ساختهای — پس بدیهی است که جا میشود. ورودیِ واقعی این کار را نمیکند: ناقص است، بدشکل است، در دو دسته جا میشود یا در هیچکدام. همین است که ارزش دارد.
حین آزمودن، این چهار چیز را بنویس:
- کجا مکث کردی و نمیدانستی چه کنی؟
- کدام قانون جوابی نداشت؟
- چه چیزی در ساختار جا نشد؟
- و چه کاری کردی که در هیچ قانونی نوشته نشده بود؟
آن مورد چهارم ارزشمندترین است، چون قانونِ نانوشتهای را لو میدهد که در سرت بود — و قانونِ نانوشته، دفعهی بعد رعایت نمیشود (فصل ۶.۲.۳).
اصلاح دور اول
حالا اصلاح کن — ولی با ترتیبِ درست، چون ترتیبش مهم است:
- اول ساختار. اگر چیزی جا نشد، شاخهی کمشده را اضافه کن. ساختارِ غلط را با قانون وصله نکن.
- بعد قانون. ابهامها را رفع کن و استثناها را اضافه کن.
- آخر از همه، نقش یا رویه — و فقط اگر دردش را حس کردی (فصل ۶.۵.۴).
و یک قاعدهی خودداری: در دور اول، هر ایرادی را رفع نکن. بعضی ایرادها یکبارمصرفاند و دیگر تکرار نمیشوند؛ اگر برای هر کدام قانونی بنویسی، به فایل قانونِ سیبندی میرسی که کسی نمیخواندش (فصل ۶.۴.۳). منتظر تکرار بمان. چیزی که دو بار اتفاق افتاد، الگوست؛ چیزی که یک بار افتاد، ممکن است فقط یک بار باشد.
و همینجا کارِ این ماژول تمام است. سیستمی داری که جا دارد، حافظه دارد، قانون دارد، جریان دارد — و یک بار با واقعیت روبهرو شده و از آن جان سالم برده. این تفاوت یک سیستم با یک نقشه است.
تمرین (ساختنی + توضیحی)
سیستمت را بساز و به کار بینداز. بعد بنویس:
- اولین ورودی واقعی چه چیزی را خراب کرد؟
- آن خرابی از ساختار بود، از قانون، یا از جریان؟
- چه چیزی را اصلاح کردی — و چه چیزی را عمداً اصلاح نکردی و چرا؟
پاسخنامه — یک دور واقعی، و چرا آن بند آخر مهمترین است
سیستم: پیگیری فاکتورهای پرداختنشده. سه پوشه، سه قانون.
اولین ورودی واقعی چه چیزی را خراب کرد: یک فاکتور که نصفش پرداخت شده بود. سیستم دو حالت داشت — پرداختشده و پرداختنشده — و این مورد در هیچکدام جا نمیشد. من همان لحظه گذاشتمش در «در جریان» و در ذهنم گفتم «بعداً درستش میکنم».
علت: ساختار، نه قانون. قانون درست بود برای دو حالتی که تعریف شده بود؛ مشکل این بود که حالتِ سوم وجود داشت و دیده نشده بود. و آن جملهی «بعداً درستش میکنم» دقیقاً همان قانونِ نانوشتهی بخش ۶.۸.۵ است.
چه چیزی اصلاح شد: یک حالت سوم اضافه شد — «پرداخت جزئی» — با یک بند در قانون که میگوید مبلغِ باقیمانده در نام فایل بیاید. یعنی اول ساختار، بعد قانون؛ همان ترتیبِ بخش ۶.۸.۶.
و چه چیزی عمداً اصلاح نشد: یک فاکتور به ارز خارجی رسید. برای آن قانونی نوشته نشد، چون سالی یکی دو بار پیش میآید — و قانونی که سالی دو بار به کار میرود، تا آن موقع فراموش شده و فقط فایل قانون را شلوغ کرده است. تصمیم: هر بار دستی انجامش بده.
و چرا این بند مهمترین بند تمرین است: چون خودداری از اصلاح، سختترین بخشِ نگهداشتنِ یک سیستم است. سیستمها معمولاً از کمبودنِ قانون نمیمردند؛ از زیادبودنش میمیرند — به فایلی میرسند که خواندنش از انجامِ دستیِ کار سختتر است، و آنجاست که رها میشوند.