قابل‌دفاعه، ولی خوبه؟
خلاصهٔ کامل‌تر
وس کائو تو این پست می‌گه بین کاری که مفید به نظر می‌رسه و کاری که واقعاً مفیده فرق هست. یه خروجی می‌تونه قابل‌دفاع باشه، همهٔ الزامات اعلام‌شده رو برآورده کنه، تو نگاه اول مرتب بیاد و با یه لایهٔ ظاهرِ حرفه‌ای بسته‌بندی شده باشه، ولی باز هم اصل هدف رو از دست بده. به گفتهٔ نویسنده، آدم‌ها به‌طور طبیعی به‌جای «فهمیدن حقیقت»، «به دردسر نیفتادن» رو بهینه می‌کنن؛ حتی محیط‌هایی که به ضدِ متوسط‌بودن‌شون افتخار می‌کنن هم تو همین تلهٔ کفایتِ سطحی می‌افتن.
سؤالی که نویسنده می‌گه از خودش و از کسایی که کیفیت براشون مهمه می‌پرسه، همینه: «این قابل‌دفاعه، ولی خوبه؟» او معتقده منتظر موندن برای نشونه‌های آشکارِ خرابی — جهش نرخ رهاکردن، اعتراض مشتری‌ها، پاک‌کردن دسته‌جمعی اپ — فقط یه حس امنیت کاذب می‌ده. یعنی تا قبل از اون نشونه‌های دراماتیک فرض می‌کنیم همه‌چی روبه‌راهه، در حالی که خیلی وقت‌ها نیست.
نویسنده دو نمونه از کوچینگش تعریف می‌کنه. یکی تیمی که مدام بهانهٔ «داده کافی نداریم» میاره و می‌گه نرخ لغو اشتراکِ ایمیل‌ها در حد میانگینه پس نیازی به بهبود نیست — در حالی که خودِ ایمیل‌ها گیج‌کننده و بی‌ارزشن و با چشم هم معلومه. به گفتهٔ او یه استارتاپ کوچیک اصلاً در موقعیتی نیست که همه‌چی رو A/B تست کنه؛ مجبوره از خلاقیت و سلیقه‌اش استفاده کنه. نمونهٔ دوم یه مدیر مهندسیه که بازخورد گرفته دیدگاه کافی ارائه نمی‌ده و جوابش اینه: «اگه ایده نسبتاً خوب باشه، برام کافیه.»
جواب نویسنده اینه که وقتی با آدم‌های نسبتاً بلد کار می‌کنی، ایده‌های «نسبتاً خوب» زیادن؛ ولی «نسبتاً خوب» اغلب برای خرج‌کردنِ بودجه و نیروی محدود کافی نیست. اگه هر فصل فقط چند شرط‌بندی محدود داری، باید به همونی که انتخاب می‌کنی باور داشته باشی. میشه با دویدن دنبال کارهای قابل‌دفاع — پیروی از «فرایندها»، گذاشتن جلسه با مشتری — سرت شلوغ باشه ولی هیچ پیشرفت واقعی‌ای اتفاق نیفته.
نکات کلیدی:
- کارِ قابل‌دفاع لزوماً کارِ خوب نیست؛ برآورده‌کردن الزامات با ارزش‌آفرینی یکی نیست
- منتظر نشونه‌های فاجعه‌بار موندن برای شروع بهبود، امنیت کاذب می‌سازه
- تیم کوچیک همیشه توان A/B تست نداره و باید به قضاوت و سلیقه تکیه کنه
- با بودجه و نیروی محدود، «نسبتاً خوب» معیار خوبی برای انتخاب پروژه نیست
- شلوغیِ کارهای فرایندی رو با پیشرفت واقعی اشتباه نگیر
