وبسایت حمیدرضا لاچین - فعال در حوزه‌ی منابع انسانی، رهبری و توسعه فردی

📌 توی چند هفته‌ی گذشته یه سری پست درباره‌ی این موضوع که چرا فقط آدم خوب داشتن یا نیت خوب داشتن کافی نیست نوشتم! توی این پست‌ها درباره‌ی اشتباهات رایج، تجربه آمازون، اصول و مکانیزم‌های اثرگذار و حتی نمونه‌ای از نتفلیکس حرف زدیم.

👇 توی این پست می‌تونی خلاصه‌ی همشونو با لینک مطالعه یه جا ببینی:

🔴 قسمت اول: نیت کافی نیست!

✅ نیت خوب به‌تنهایی منجر به نتایج مطلوب نمی‌شه. برای تحقق اهداف، نیاز به مکانیزم‌های مؤثر داریم.

🔗 مطالعه کامل

🟠 قسمت دوم: چطور یه مکانیزم مؤثر طراحی کنیم؟

✅ یه مکانیزم خوب باید تکرارشونده، پیش‌فرض رفتار درست، و قابل سنجش باشه — نه وابسته به آدم‌ها.

🔗 مطالعه کامل

🟢 قسمت سوم: اشتباهات کشنده در طراحی مکانیزم‌ها!

✅ مکانیزم‌های بی‌اثر یا اشتباه نه تنها کمکی نمی‌کنن، بلکه باعث ناکارآمدی می‌شن — آمازون با اصلاح ۴ اشتباه کلیدی این مشکل رو حل کرده.

🔗 مطالعه کامل

🟣 قسمت چهارم: مکانیزم‌ها مثل محصول ساخته می‌شن، نه طراحی!

✅ مکانیزم‌های خوب از ابتدا کامل نیستن، بلکه با ساخت، آزمون و بهبود مستمر تبدیل به ابزارهای موثر می‌شن.

🔗 مطالعه کامل

🔵 قسمت پنجم: تجربه نتفلیکس؛ آزادی با مسئولیت به جای قوانین خشک!

✅ نتفلیکس با حذف بسیاری از قوانین و تکیه بر اصولی مثل تراکم استعداد، صداقت، آزادی مسئولانه و تصمیم‌گیری غیرمتمرکز نشون داد که مکانیزم‌های کمتر ولی اصولی می‌تونن عملکرد رو بهبود بدن.

🔗 مطالعه کامل

توی پست قبلی اشتباهات رایج طراحی مکانیزم‌ها رو بررسی کردیم.

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 شروع می‌شه، آزمایش می‌شه، با داده و تجربه اصلاح می‌شه و کم‌کم جا می‌افته.

وقتی مکانیزم‌ها رو مثل محصول ببینیم، کیفیتشون هم مثل محصول رشد می‌کنه.

توی پست قبلی گفتیم مکانیزم خوب باید تکرارپذیر، پیش‌فرض رفتار درست، و قابل سنجش باشه.

http://hlachin.ir/1404/02/17/intention_vs_mechnism_2

اما خیلی وقت‌ها، حتی با نیت خوب، مکانیزم‌هایی ساخته می‌شن که نه‌تنها کمکی نمی‌کنن، بلکه فضا رو ناکارآمدتر می‌کنن.

تو این پست ۴ اشتباه رایج در طراحی مکانیزم‌ها رو با مثال‌های واقعی از آمازون می‌خوام باهاتون به اشتراک بذارم 👇

🚫 ۱. مکانیزم نمایشی

🧨 مشکل: مکانیزم‌هایی که فقط ظاهر حرفه‌ای دارن ولی رفتار افراد رو تغییر نمی‌دن.

🔸 مثال: OKRهایی که نوشته می‌شن ولی نه کسی جدی‌شون می‌گیره، نه تصمیمی بر اساسشون گرفته می‌شه.

🧭 آمازون چه کرد؟ اصول رهبری‌شو وارد استخدام، ارزیابی، جلسات و تصمیم‌گیری کرد. مثلاً مصاحبه‌گرها باید با استناد به این اصول گزارش بدن.

✅ نتیجه: ارزش‌ها از شعار به رفتار تبدیل شدن.

🚫 ۲. مکانیزم تنبیهی

🔍 مشکل: مکانیزم به جای بهبود، تمرکزش روی پیدا کردن مقصره.

🔸 مثال: جلسات بررسی خطا که با این سؤال شروع می‌شن: "کی خراب کرده؟" نه اینکه "چه شد که این خطا پیش اومد؟"

🧭 آمازون چه کرد؟ در خطاهای فنی، جلسات blameless postmortem برگزار می‌کنه تا ایرادهای سیستمی کشف شن.

✅ نتیجه: آدم‌ها اشتباه رو پنهان نمی‌کنن؛ ازش یاد می‌گیرن.

🚫 ۳. مکانیزم بدون مالک

🔍 مشکل: مکانیزم طراحی شده ولی هیچ‌کس مسئول به‌روزرسانی یا اجرای مداومش نیست.

🔸 مثال: فرم بازخوردی که فرستاده می‌شه ولی هیچ‌کس نگاهش نمی‌کنه، چه برسه به اینکه ازش چیزی یاد بگیریم.

🧭 آمازون چه کرد؟ هر مکانیزم یا سند تصمیم‌گیری، صاحب مشخص داره. تیم Bar Raiser هم مسئول کیفیت مستمر فرایند استخدامه.

✅ نتیجه: هیچ مکانیزمی رها نمی‌شه.

🚫 ۴. مکانیزم بدون داده

🔍 مشکل: مکانیزم اجرا می‌شه ولی کسی نمی‌دونه داره جواب می‌ده یا نه.

🔸 مثال: اجرای فرایند آنبوردینگ بدون اینکه بفهمیم آیا استخدام‌های جدید واقعا آماده‌ی کار شدن یا نه.

🧭 آمازون چه کرد؟ برای هر مکانیزم، شاخص‌های input metrics داره؛ یعنی داده‌هایی که نشون می‌دن فرایند واقعا موثر بوده یا نه.

✅ نتیجه: اصلاح یا ادامه دادن هر مکانیزم بر اساس داده انجام می‌شه، نه حس.

📌 جمع‌بندی:

مکانیزم خوب مثل موتور خودکار عمل می‌کنه. از نیت شروع می‌شه، ولی بعد از مدتی خودش رفتار درست رو تولید می‌کنه — بدون نیاز به دخالت دائم مدیر.

مکانیزم بد؟ انرژی می‌گیره، ولی هیچ‌وقت به جایی نمی‌رسه.

🔍 شما تا حالا کدوم یکی از این اشتباه‌ها رو تو سازمان خودتون دیدین؟

پست قبلی درباره‌ی اهمیت مکانیزم‌ها بود — اینکه بدون سیستم، حتی بهترین نیروها هم نمی‌تونن موفقیت رو تکرار کنن.

http://hlachin.ir/1404/02/12/intention_vs_mechnism_1

اما سوال مهم‌تر اینه:

🎯 چطور یه مکانیزم خوب طراحی کنیم؟

بر اساس تجربه‌ی آمازون و چند سازمان پیشرو دیگه، مکانیزم مؤثر معمولاً ۳ ویژگی داره:

✅ ۱. قابل تکراره (Repeatable)

یعنی فقط یه شعار یا توصیه نیست؛ یه اقدام مشخص و دائمیه.

🔸 آمازون – اصل: مشتری‌محوری

برای اینکه تمرکز تصمیم‌ها از همون اول روی نیاز مشتری باشه، یه مکانیزم ساده طراحی شده:

پیش از شروع هر پروژه، تیم‌ها موظف‌ان یه بیانیه‌ی فرضی عرضه محصول به مشتری (Press Release) بنویسن.

این کار همیشه انجام می‌شه — نه فقط وقتی کسی یادش باشه.

✅ ۲. رفتار درست، پیش‌فرض سیستمه (Not exceptional)

یعنی مکانیزم باید طوری باشه که رفتار مطلوب، نیازمند تلاش قهرمانانه نباشه.

🔸 آمازون – اصل: استخدام مطابق فرهنگ

برای جلوگیری از تصمیم‌های سلیقه‌ای، مصاحبه‌ها ساختاریافته‌ان. هر مصاحبه روی یک اصل رهبری تمرکز داره و سوال‌ها از پیش تعریف شدن. مصاحبه شونده‌ها هم آموزش کامل دیدن.

اینجوری، تصمیم درست نیازمند "فرد باتجربه" یا "حس ششم" نیست — خود مکانیزم جهت درست رو تعیین می‌کنه.

✅ ۳. قابل سنجشه (Measurable)

یعنی بشه فهمید مکانیزم نتیجه داده یا نه.

🔸 آمازون – اصل: تصمیم‌سازی دقیق و شفاف

به‌جای ارائه شفاهی، همه‌ی تصمیم‌های مهم با یک سند مکتوب (۶ صفحه‌ای) همراه‌ان.

با این مدل، می‌شه کیفیت تصمیم‌ها، دقت تحلیل‌ها، و حتی کاهش خطاها رو در طول زمان بررسی کرد.

🧠 جمع‌بندی:

مکانیزم خوب باید:

• تکرارپذیر باشه
• رفتار درست رو پیش‌فرض بگیره
• بشه اثربخشی‌شو سنجید

در غیر این صورت، همه‌چی به «آدم مناسب» یا «حال خوب» وابسته می‌مونه — که یعنی اتفاقی، نه سیستماتیک.

📌 شما چه تجربه‌ای دارین؟

آخرین باری که توی سازمان‌تون یه اصل مهم رو تبدیل به مکانیزم کردید، چی بود و چطوری طراحی‌ش کردید؟

#مدیریت #مکانیزم #فرهنگ_سازمانی #آمازون #کار_برعکس #WorkingBackwards #رهبری #سیستم_سازی