اولین سوال رو جواب نده
خلاصهٔ کامل‌تر
یه مهندس روی Perfetto — ابزار دیباگ پرفورمنس گوگل — یه قانون طلایی داره: اولین نسخه‌ی سوال رو جواب نده. مثلاً وقتی کسی می‌پرسه «چطور یه trace رو به چند فایل تقسیم کنم؟»، به جای جواب مستقیم می‌پرسه: «چرا اصلاً به traceهای اون‌قدر بزرگ رسیدی؟»
این رویکرد با مفهوم معروف XY Problem فرق داره. XY Problem می‌گه «بفهم واقعاً چی می‌خوان، بعد جواب بده.» اما این مهندس یه قدم جلوتر می‌ره: خود سردرگمی کاربر یه فرصته — هم برای آموزش، هم برای بهبود محصول. در این مکالمه، کاربر مدل ذهنی بهتری از ابزار پیدا می‌کنه و تیم محصول یاد می‌گیره کجا گیج‌کننده‌ست.
برای تشخیص اینکه یه سوال «غیرعادیه»، نویسنده یه چک‌لیست ذهنی داره: آیا این سوال رو قبلاً دیدم؟ آیا با معماری ابزار جور درمیاد؟ آیا کاربر داره ناخواسته با ساختار ابزار دست‌وپنجه نرم می‌کنه؟ بعد از این تشخیص، با یه سوال باز، زمینه‌ی گم‌شده رو پیدا می‌کنه.
نتیجه‌ی این مکالمه معمولاً یکی از سه حالته: کاربر فلسفه‌ی ابزار رو درک نکرده (مثلاً می‌خواد همه‌ی متریک‌ها رو از trace بگیره، در حالی که trace برای این کار گرونه)؛ مسیر درست مخفی مونده (مثل همون مثال trace splitting که راه‌حلش periodic snapshots بود و کاربر نمی‌دونست)؛ یا محصول واقعاً باید تغییر کنه.
برای حالت سوم، نویسنده تجربه‌ی تلخی از Perfetto تعریف می‌کنه: کاربرها می‌خواستن UI رو شخصی‌سازی کنن، تیم سریع این امکان رو داد، و نتیجه یه سال بدهی فنی سنگین بود. بعد از یه سال، یه Plugin API درست طراحی کردن — چیزی که از اول باید می‌ساختن. در مقابل، برای «ادغام traceها» صبر کردن تا مشکل اصلی رو کامل بفهمن و در نهایت یه راه‌حل درست و نگه‌داری‌پذیر ساختن.
نکات کلیدی:
- اولین سوال کاربر اغلب سوال واقعی‌شون نیست
- قبل از جواب دادن، بپرس «چرا؟» تا مشکل اصلی روشن بشه
- سردرگمی کاربر می‌تونه نشونه‌ی ضعف در طراحی یا مستندسازی محصول باشه
- ساختن یه فیچر قبل از فهمیدن کامل مشکل، اغلب به بدهی فنی ختم میشه
- صبر کردن برای درک عمیق‌تر مشکل، معمولاً به راه‌حل‌های بهتری منجر میشه
