در بسیاری از پروژهها، وسوسه میشویم پاسخ را قبل از صورت مسئله انتخاب کنیم. نتیجه معمولاً ساختاری است که روی کاغذ مرتب بهنظر میرسد، اما در برابر تغییرهای واقعی محصول مقاومت میکند.
اول مسئله را قاب بگیرید، بعد اسم الگوها را بیاورید.
قبل از هر تصمیم فنی، باید بدانیم چه چیزی قرار است تغییر کند، چه چیزی نباید بشکند و کدام محدودیت واقعاً هزینه میسازد. پاسخ درست از دل همین سه سؤال بیرون میآید، نه از فهرست ابزارهایی که از قبل دوستشان داریم.
چه چیزی متغیر است؟
مکانهایی را پیدا کنید که احتمال تغییر قواعد، داده یا جریان کار در آنها بیشتر است.
هزینهٔ اشتباه چیست؟
ریسک عملیاتی، زمان تیم و پیچیدگی نگهداری را همزمان در تصمیم ببینید.
چه چیزی را اندازه میگیریم؟
برای هر فرض، یک نشانهٔ قابل مشاهده تعریف کنید تا تصمیم بعداً قابل بازبینی باشد.
trade-offها همان بخشی هستند که تصمیم را واقعی میکنند.
هر ساختار بهتر، هزینهای هم دارد. اگر نتوانیم آن هزینه را برای تیم توضیح دهیم، احتمالاً هنوز تصمیم را کامل نفهمیدهایم. بهجای «بهترین راه»، دنبال راهی باشید که محدودیت امروز را پوشش دهد و مسیر تغییر فردا را نبندد.
معماری خوب، پیچیدگی را حذف نمیکند؛ آن را به جایی منتقل میکند که تیم بتواند آگاهانه مدیریتاش کند.
برای هر انتخاب، سه هزینه را بنویسید.
- هزینهٔ ساخت و یادگیری
- هزینهٔ تغییر در شش ماه آینده
- هزینهٔ تشخیص خطا در production
تصمیم را به یک آزمایش کوچک و قابل برگشت تبدیل کنید.
وقتی ابهام زیاد است، راهحل کامل نسازید. یک برش کوچک از جریان کار را انتخاب کنید که بتواند فرض مهم شما را محک بزند. این کار هم سرعت یادگیری را بالا میبرد و هم از سرمایهگذاری زودهنگام روی ساختار اشتباه جلوگیری میکند.
Problem: کدام بخش قرار است بیشترین تغییر را تجربه کند؟
Constraint: چه چیزی نباید در این تغییر آسیب ببیند؟
Decision: کوچکترین انتخاب قابل بازگشت چیست؟
Signal: از کجا میفهمیم انتخابمان درست بوده است؟
نظرتان را به بحث اضافه کنید.
۲ نظر از خوانندههای این یادداشت
بخش «قابل برگشت بودن تصمیم» دقیقاً همان چیزی بود که در طراحیهای روزمره فراموش میکنیم. مثال decision note هم خیلی کاربردی بود.
دقیقاً؛ اگر تصمیم کوچک و قابل بازگشت باشد، تیم هم راحتتر میتواند از واقعیت محصول یاد بگیرد.