توی پست قبلی اشتباهات رایج طراحی مکانیزم‌ها رو بررسی کردیم.
http://hlachin.ir/1404/02/22/intention_vs_mechnism_3
تو سازمان‌ها، معمولاً این‌طوری فکر می‌کنیم:
«بشینیم یه بار برای همیشه یه مکانیزم عالی طراحی کنیم، بعد بذاریمش تو اجرا.»
اما در واقعیت برای اینکه درگیر این اشتباهات نشیم و بتونیم یه مکانیزم خوب طراحی کنیم، باید بدونیم که هیچ مکانیزم خوبی، از اول خوب نبوده. مکانیزم خوب، محصول ساختن، آزمون، بازخورد و بهبود مستمره.
🔍 بیاید ببینیم آمازون چطور این کارو میکنه:
🧠 مثال 1: PR/FAQ (نوشتن قبل از ساختن)
اولش فقط یه ایده بود: قبل از شروع هر پروژه، یه سند بنویس که انگار پروژه تموم شده و الان داریم به مشتری معرفی‌ش می‌کنیم.
📍 بارها تست شد. اول سبک نوشتنش مشکل داشت، بعد آدم‌ها جدی نمی‌گرفتنش، بعد شد ابزار رسمی.
امروز؟ PR/FAQ یکی از اصلی‌ترین مکانیزم‌های تصمیم‌گیری محصوله.
🧠 مثال 2: Bar Raiser (نگهبان کیفیت استخدام)
اول فقط چند مدیر باتجربه بودن که تو مصاحبه‌ها نقش داور داشتن. بعد دیدن این مدل جواب می‌ده، آموزش براش گذاشتن، سازوکار بازخورد و ارزیابی براش ساختن.
📍 امروز Bar Raiserها نه‌تنها در استخدام، بلکه در نگه‌داشت فرهنگ سازمانی نقش کلیدی دارن.
🧠 مثال ۳: اصول رهبری (از تجربه به اصل)
اصول رهبری آمازون مثل «Customer Obsession» یا «Dive Deep» اولش روی کاغذ نبودن. از مشاهده و تحلیل مدیران موفق درون سازمان دراومدن. بعد به‌مرور نوشته، تست و در فرایندها ادغام شدن.
📍 امروز، همه‌ی تصمیم‌گیری‌ها، ارزیابی‌ها و جلسات، به این اصول رجوع دارن.
📌 جمع‌بندی:
مکانیزم خوب طراحی نمی‌شه، ساخته میشه.
از MVP شروع میشه، آزمایش میشه، با داده و تجربه اصلاح میشه و کم‌کم جا می‌افته.
وقتی مکانیزم‌ها رو مثل محصول ببینیم، کیفیتشون هم مثل محصول رشد میکنه.
