💡 @OrgDev_LE

https://www.linkedin.com/posts/saebi_at-berkeley-i-let-my-students-decide-for-activity-7372851223261110273-lsJ8?utm_source=share&utm_medium=member_android&rcm=ACoAAAX9tj8B58s--BK3QPUaMre401YdMQOFvZ8

مطلبی قابل تامل در باب استفاده از چت باتهای هوشمند

💡 @OrgDev_LE

💡 @OrgDev_LE

💡 @OrgDev_LE

💡 @OrgDev_LE

💡 @OrgDev_LE

به لطف DeepSeek

#کتاب "Escaping the Build Trap: How Effective Product Management Creates Real Value" (فرار از تله ساخت: چگونه مدیریت محصول مؤثر ارزش واقعی خلق می‌کند) نوشته ملیسا پری (Melissa Perri)، یکی از آثار تأثیرگذار در حوزه مدیریت محصول است که در سال ۲۰۱۸ منتشر شد . پری در این کتاب به مشکل رایجی در سازمان‌ها اشاره می‌کند که در آن شرکت‌ها موفقیت خود را با میزان «خروجی» (Output) می‌سنجند؛ یعنی اینکه چه تعداد ویژگی یا محصول جدید تحویل داده‌اند، به جای اینکه بر «نتایج» (Outcomes) تمرکز کنند؛ یعنی اینکه آن محصولات چه ارزش واقعی برای مشتری و کسب‌وکار خلق کرده‌اند. این مشکل را «تله ساخت» می‌نامند.

این کتاب در پنج بخش اصلی سازماندهی شده است که هر کدام به جنبه‌ای از ایجاد یک سازمان محصول‌محور (Product-Led Organization) می‌پردازد. در ادامه، خلاصه‌ای معنادار و مبسوط از هر فصل ارائه می‌شود.

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

· بخش اول: The Build Trap (تله ساخت)
· بخش دوم: The Role of the Product Manager (نقش مدیر محصول)
· بخش سوم: Strategy (استراتژی)
· بخش چهارم: Product Management Process (فرآیند مدیریت محصول)
· بخش پنجم: The Product-Led Organization (سازمان محصول‌محور)

---

بخش اول: The Build Trap (تله ساخت)

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

· فصل ۱: The Value Exchange System (سیستم تبادل ارزش)
این فصل پایه و اساس تفکر محصول‌محور را معرفی می‌کند. پری توضیح می‌دهد که هدف یک کسب‌وکار، ایجاد یک سیستم تبادل ارزش است؛ جایی که شرکت برای مشتریان ارزش خلق می‌کند و در مقابل، مشتریان نیز به شکل های مختلف (مانند خرید، وفاداری، یا معرفی) به شرکت ارزش برمی‌گردانند. زمانی که این سیستم به درستی کار کند، هم شرکت و هم مشتری سود می‌برند .
· فصل ۲: Constraints on the Value Exchange System (محدودیت‌های سیستم تبادل ارزش)
در این فصل به عواملی پرداخته می‌شود که می‌توانند این سیستم تبادل ارزش را مختل کنند. این محدودیت‌ها می‌توانند شامل کمبود منابع، دانش ناکافی از مشتری، یا ساختارهای سازمانی ناکارآمد باشند که منجر به تصمیم‌گیری‌های اشتباه و در نهایت سقوط در تله ساخت می‌شوند .
· فصل ۳: Projects Versus Products Versus Services (پروژه‌ها در مقابل محصولات در مقابل خدمات)
یکی از مفاهیم کلیدی کتاب، تمایز قائل شدن بین پروژه، محصول و خدمات است. پری تأکید می‌کند که تفکر پروژه‌محور (Project-based thinking) که در آن تیم‌ها صرفاً برای تحویل یک ویژگی در یک بازه زمانی مشخص وظیفه دارند، یکی از دلایل اصلی افتادن در تله ساخت است. در مقابل، تفکر محصول‌محور (Product-based thinking) به دنبال خلق ارزش مستمر برای مشتری در طول چرخه عمر محصول است .
· فصل ۴: The Product-Led Organization (سازمان محصول‌محور)
پری انواع مختلف سازمان‌ها از نظر محوریت تصمیم‌گیری را بررسی می‌کند: Sales-Led (فروش‌محور) که فروش تعیین‌کننده است، Visionary-Led (رهبری) که بنیانگذار یا مدیرعامل تصمیم‌گیرنده است، Technology-Led (تکنولوژی‌محور) که تکنولوژی و توانمندی فنی جهت‌دهنده است، و در نهایت Product-Led (محصول‌محور) که در آن تمام تصمیمات بر اساس خلق ارزش برای مشتری و همسو با استراتژی کسب‌وکار گرفته می‌شود .
· فصل ۵: What We Know and What We Don't (آنچه می‌دانیم و آنچه نمی‌دانیم)
این فصل به مفهوم عدم قطعیت در توسعه محصول می‌پردازد. پری توضیح می‌دهد که ما همیشه با دو دسته اطلاعات مواجه هستیم: دانسته‌ها و نادانسته‌ها. وظیفه مدیر محصول این است که با آزمایش و یادگیری، نادانسته‌ها را به دانسته‌ها تبدیل کند و ریسک ساخت محصولی که کسی نمی‌خواهد را کاهش دهد .

بخش دوم: The Role of the Product Manager (نقش مدیر محصول)

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

· فصل ۶: Bad Product Manager Archetypes (کهن‌الگوهای مدیر محصول بد)
پری سه نمونه از مدیران محصول ناکارآمد را معرفی می‌کند :
1. The Mini-CEO (مدیرعامل کوچک): کسی که به دنبال قدرت و کنترل است و بدون توجه به داده‌ها و همکاری با تیم، تصمیمات را از بالا به پایین دیکته می‌کند.
2. The Waiter (گارسون): کسی که صرفاً خواسته‌های ذی‌نفعان (Stakeholders) را جمع‌آوری کرده و بدون تفکر و تحلیل به تیم توسعه می‌دهد.

💡 @OrgDev_LE

3. The Former Project Manager (مدیر پروژه سابق): کسی که بیش از آنکه به «چرایی» و ارزش یک ویژگی فکر کند، به زمان‌بندی و تحویل به موقع آن اهمیت می‌دهد.
· فصل ۷: A Great Product Manager (یک مدیر محصول عالی)
در مقابل کهن‌الگوهای بد، پری ویژگی‌های یک مدیر محصول عالی را توصیف می‌کند. یک مدیر محصول عالی، با «چرایی» (Why) شروع می‌کند. او عمیقاً مشتری و کسب‌وکار را درک می‌کند، مشکلات را می‌یابد، چشم‌انداز محصول را ترسیم می‌کند و تیم را در مسیر خلق ارزش هدایت می‌نماید. این فصل به تمایز بین متخصص فناوری و متخصص بازار نیز می‌پردازد و تأکید می‌کند که مدیر محصول باید هر دو حوزه را درک کند .
· فصل ۸: The Product Manager Career Path (مسیر شغلی مدیر محصول)
این فصل یک دید کلی از سطوح مختلف شغلی در حوزه مدیریت محصول ارائه می‌دهد؛ از مدیر محصول کارآموز (Associate Product Manager) گرفته تا مدیر ارشد محصول (Chief Product Officer) و مسئولیت‌ها و انتظارات مربوط به هر سطح .
· فصل ۹: Organizing Your Teams (سازماندهی تیم‌هایتان)
پری در این فصل به چگونگی چیدمان تیم‌های محصول در ساختار سازمانی می‌پردازد تا بیشترین کارایی را داشته باشند. او بر اهمیت ایجاد تیم‌های خودمختار (Autonomous Teams) تأکید می‌کند که بر روی یک حوزه مشخص از محصول تمرکز دارند .

بخش سوم: Strategy (استراتژی)

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

· فصل ۱۰: What Is Strategy? (استراتژی چیست؟)
پری با استناد به استفان بانگای (Stephen Bungay)، تعریف جدیدی از استراتژی ارائه می‌دهد: استراتژی یک «برنامه» نیست، بلکه یک چارچوب (Framework) برای تصمیم‌گیری است. یک استراتژی خوب باید شرکت را برای سال‌ها جهت‌دهی کند و به تیم‌ها کمک کند تا در مسیر درست حرکت کنند .
· فصل ۱۱: Strategic Gaps (شکاف‌های استراتژیک)
در این فصل، سه شکاف رایج که باعث ایجاد اصطکاک در سازمان می‌شوند، معرفی می‌شوند :
1. The Knowledge Gap (شکاف دانش): تفاوت بین آنچه می‌خواهیم بدانیم و آنچه می‌دانیم.
2. The Alignment Gap (شکاف هم‌راستایی): تفاوت بین آنچه می‌خواهیم افراد انجام دهند و آنچه واقعاً انجام می‌دهند.
3. The Effects Gap (شکاف تأثیرات): تفاوت بین آنچه انتظار داریم اقداماتمان به آن منجر شود و آنچه واقعاً رخ می‌دهد.
· فصل ۱۲: Creating a Good Strategic Framework (ایجاد یک چارچوب استراتژیک خوب)
پری توضیح می‌دهد که چگونه می‌توان یک چارچوب استراتژیک ایجاد کرد که چشم‌انداز شرکت را به فعالیت‌های روزمره تیم‌های محصول متصل کند. این چارچوب شامل تعیین اهداف و نتایج مشخص در سطوح مختلف سازمان است .
· فصل ۱۳: Company-Level Vision and Strategic Intents (چشم‌انداز در سطح شرکت و اهداف استراتژیک)
در بالاترین سطح، چشم‌انداز شرکت (Company Vision) قرار دارد که تصویری از آینده مطلوب در ۵ یا ۱۰ سال آینده را ترسیم می‌کند. در سطح بعدی، اهداف استراتژیک (Strategic Intents) قرار می‌گیرند که چالش‌های کلیدی کسب‌وکار برای رسیدن به آن چشم‌انداز را مشخص می‌کنند .
· فصل ۱۴: Product Vision and Portfolio (چشم‌انداز محصول و پرتفولیو)
این فصل به چگونگی ترجمه اهداف استراتژیک شرکت به چشم‌انداز محصول (Product Vision) و در نهایت به پرتفولیوی محصولات (Product Portfolio) می‌پردازد. در این سطح، رهبران محصول مشخص می‌کنند که کدام محصولات یا ویژگی‌ها می‌توانند به حل چالش‌های کسب‌وکار کمک کنند .

بخش چهارم: Product Management Process (فرآیند مدیریت محصول)

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

· فصل ۱۵: The Product Kata (کاتای محصول)
پری مفهوم "Product Kata" را به عنوان یک رویکرد علمی و سیستماتیک برای خلق محصولات بهتر معرفی می‌کند. این رویکرد برگرفته از فلسفه "Toyota Kata" است و بر یادگیری مستمر و آزمایش تأکید دارد .
· فصل ۱۶: Understanding the Direction and Setting Success Metrics (درک جهت‌گیری و تعیین معیارهای موفقیت)
اولین گام در فرآیند، درک جهت‌گیری استراتژیک و تعریف معیارهای موفقیت (Success Metrics) برای محصول است. پری در این فصل به چارچوب‌های معروفی مانند "Pirate Metrics" (AARRR) و "HEART Framework" اشاره می‌کند .
· فصل ۱۷: Problem Exploration (کاوش مسئله)
در این مرحله، تیم محصول به دنبال درک عمیق مشکلی است که قرار است حل کند. این شامل تحقیقات کاربری، اعتبارسنجی مسئله (Problem Validation) و اطمینان از اینکه مشکل واقعی و ارزش حل کردن است، می‌شود .

💡 @OrgDev_LE

· فصل ۱۸: Solution Exploration (کاوش راه‌حل)
پس از تأیید مسئله، نوبت به یافتن بهترین راه‌حل می‌رسد. در این فصل، پری به تکنیک‌های مختلف آزمایش و اعتبارسنجی راه‌حل‌ها مانند تست کانسپت (Concept Testing)، رویکرد "کانسیرژ" (Concierge) و "وزیر جادوگر" (Wizard of Oz) می‌پردازد .
· فصل ۱۹: Building and Optimizing Your Solution (ساخت و بهینه‌سازی راه‌حل)
آخرین مرحله، ساخت و تحویل راه‌حل است. اما کار به اینجا ختم نمی‌شود. پس از عرضه، تیم باید به طور مداوم راه‌حل را با توجه به بازخورد کاربران و داده‌ها بهینه‌سازی کند. پری در اینجا به مفهوم "تعریف واقعی تمام شده" (The Real Definition of Done) اشاره دارد که صرفاً به معنای تحویل کد نیست، بلکه به معنای دستیابی به نتیجه مورد انتظار است .

بخش پنجم: The Product-Led Organization (سازمان محصول‌محور)

در بخش پایانی، نویسنده به چگونگی ایجاد و حفظ فرهنگ و ساختار سازمانی می‌پردازد که از مدیریت محصول مؤثر پشتیبانی کند.

· فصل ۲۰: Outcome-Focused Communication (ارتباطات نتیجه‌محور)
این فصل بر اهمیت تغییر نحوه ارتباطات در سازمان تأکید دارد. به جای صحبت درباره ویژگی‌ها و زمان‌بندی‌ها، تیم‌ها باید بر روی نتایج و ارزش خلق شده تمرکز کنند. پری به نقش "Product Operations" در مقیاس‌پذیری این ارتباطات و فرآیندها اشاره می‌کند .
· فصل ۲۱: Rewards and Incentives (پاداش‌ها و مشوق‌ها)
پری هشدار می‌دهد که اگر سیستم پاداش‌دهی شرکت بر اساس خروجی (مثلاً تعداد ویژگی‌های تحویل داده شده) باشد، هرگز نمی‌توان از تله ساخت فرار کرد. سیستم پاداش باید با نتایج و خلق ارزش برای مشتری همسو باشد .
· فصل ۲۲: Safety and Learning (ایمنی و یادگیری)
برای اینکه تیم‌ها بتوانند آزمایش کنند و نوآوری داشته باشند، به یک محیط امن نیاز دارند؛ محیطی که در آن شکست در آزمایش‌ها به عنوان فرصتی برای یادگیری تلقی شود، نه دلیلی برای تنبیه .
· فصل ۲۳: Budgeting (بودجه‌بندی)
فرآیندهای سنتی بودجه‌بندی سالانه با ماهیت چابک و آزمایشی توسعه محصول در تضاد هستند. پری رویکردهای نوینی برای بودجه‌بندی پیشنهاد می‌کند که به تیم‌ها اجازه می‌دهد بر اساس یادگیری‌های خود، مسیرشان را تغییر دهند .
· فصل ۲۴: Customer Centricity (مشتری‌مداری)
مشتری‌مداری واقعی به معنای قرار دادن مشتری در مرکز تمام تصمیم‌گیری‌هاست. این فصل به چگونگی نهادینه کردن این فرهنگ در سراسر سازمان می‌پردازد .
· فصل ۲۵: Marquetly: The Product-Led Company (Marquetly: شرکت محصول‌محور)
در این فصل، پری به داستان شرکت فرضی "Marquetly" که در ابتدای کتاب معرفی شد، بازمی‌گردد و نشان می‌دهد که چگونه این شرکت با به کارگیری اصول مطرح شده در کتاب، توانست از تله ساخت فرار کند و به یک سازمان محصول‌محور تبدیل شود .
· فصل ۲۶: Afterword: Escaping the Build Trap to Become Product-Led (سخن پایانی: فرار از تله ساخت برای محصول‌محور شدن)
در این بخش، نویسنده جمع‌بندی نهایی خود را ارائه می‌دهد و بر اهمیت تحول فرهنگی و ساختاری تأکید می‌کند .
· ضمیمه (Appendix): Six Questions to Determine Whether a Company Is Product-Led (شش پرسش برای تعیین اینکه آیا یک شرکت محصول‌محور است)
کتاب با یک ضمیمه کاربردی به پایان می‌رسد که شامل شش سؤال کلیدی است. مدیران می‌توانند از این سؤالات برای ارزیابی میزان محصول‌محور بودن سازمان خود استفاده کنند .

در انتها، می‌توان گفت که "Escaping the Build Trap" یک نقشه راه عملی برای سازمان‌هایی است که می‌خواهند از خلق بی‌هدف ویژگی‌ها دست کشیده و به طور سیستماتیک به دنبال خلق ارزش واقعی برای مشتریان و کسب‌وکار خود باشند. این کتاب بر اهمیت نقش مدیر محصول، استراتژی منسجم، فرآیندهای علمی و فرهنگ سازمانی حمایت‌کننده تأکید دارد.

💡 @OrgDev_LE

جمله ساده ولی عمیقی هست

... شرکت برای تداوم بخشیدن به روند رشد این محصول تا هنگام حصول موفقیت، آمادگی ندارد ...

#کتاب
#نجات_محصول_از_تله_تولید

💡 @OrgDev_LE

💡 @OrgDev_LE

چگونه فرهنگ سازمانی سالم و مطلوب به فرهنگ سازمانی ناسالم و مریض تبدیل می شود؟

تصمیمات مدیریتی غلط
عدم پذیرش عواقب
عدم پاسخگویی
عدم مسئولیت پذیری
عدم نکوهش خرده رفتارهای سمی
بها دادن به افراد سمی
عدم ضمانت اجرایی مسئولیت‌ها و ماموریت‌ها
عدم پشتیبانی و حمایت مدیریت
تصمیمات سلیقه ای و غیرداده محور
عدم پایبندی به استانداردها و فرایندهای سازمانی
و ...


برسد به دست مسئولین منظور!

💡 @OrgDev_LE

💡 @OrgDev_LE

💡 @OrgDev_LE

💡 @OrgDev_LE

💡 @OrgDev_LE

💡 @OrgDev_LE

#kanban
#scrum
#scrumban
💡 @OrgDev_LE

رضایت کارکنان از واحد منابع انسانی شروع نمی‌شود؛ از استراتژی شروع می‌شود.
«حقوق را افزایش دادیم، مزایا را بهتر کردیم، دوره‌های آموزشی برگزار کردیم؛ اما رضایت کارکنان آن‌طور که انتظار داشتیم بهتر نشد.»
این تجربه برای بسیاری از سازمان‌ها آشناست. چون اغلب تصور می‌کنیم رضایت کارکنان فقط به عملکرد واحد منابع انسانی بستگی دارد، در حالی که واقعیت چیز دیگری است.
رضایت کارکنان نتیجه یک زنجیره مدیریتی است؛ زنجیره‌ای که از استراتژی سازمان آغاز می‌شود و تا تجربه روزانه کارکنان ادامه پیدا می‌کند.

استراتژی
↓
مدل عملیاتی
↓
ساختار سازمانی
↓
فرآیندها
↓
شفافیت نقش‌ها
↓
مدیریت عملکرد
↓
اهداف و نتایج کلیدی (OKR)
↓
تجربه کارکنان
↓
رضایت کارکنان
↓
مشارکت کارکنان
↓
عملکرد بهتر سازمان

اگر در هر کدام از این حلقه‌ها مشکلی وجود داشته باشد، اثر آن دیر یا زود به رضایت کارکنان می‌رسد.
فرض کنید استراتژی سازمان مشخص نیست. در این صورت، اولویت‌ها مدام تغییر می‌کنند. اگر اولویت‌ها مشخص نباشند، ساختار و فرآیندها هم دچار ابهام می‌شوند.
وقتی نقش افراد شفاف نباشد، ارزیابی عملکرد نیز عادلانه نخواهد بود. و اگر اهداف سازمان به‌درستی به OKRها ترجمه نشوند، کارکنان ارتباط بین کار روزانه خود و موفقیت سازمان را احساس نمی‌کنند.
نتیجه چیست؟
کاهش انگیزه، کاهش مشارکت و در نهایت کاهش رضایت کارکنان.

مطالعات Gallup نشان می‌دهد تیم‌هایی که کارکنان مشارکت بیشتری دارند، به‌طور متوسط ۲۳ درصد سودآوری بیشتری نسبت به تیم‌هایی با مشارکت پایین دارند.
از طرف دیگر، پژوهش‌های McKinsey نشان می‌دهد شفاف بودن انتظارات، بازخورد مستمر و یک سیستم مدیریت عملکرد منصفانه، از مهم‌ترین عوامل ایجاد تجربه مثبت برای کارکنان هستند. به همین دلیل، اگر می‌خواهیم رضایت کارکنان را افزایش دهیم، نباید فقط از خودمان بپرسیم:
«واحد منابع انسانی چه کاری انجام دهد؟»
شاید سؤال مهم‌تر این باشد:
آیا استراتژی ما به‌درستی به ساختار، فرآیندها، مدیریت عملکرد و OKRها ترجمه شده است؟
اگر پاسخ این سؤال منفی باشد، حتی بهترین برنامه‌های رفاهی هم فقط اثر کوتاه‌مدت خواهند داشت.
رضایت کارکنان زمانی پایدار می‌شود که همه اجزای سازمان، از استراتژی تا اجرای روزانه، در یک مسیر مشترک حرکت کنند.

منابع
Gallup – World's Largest Ongoing Study of the Employee Experience (2024)
McKinsey & Company – What Works—and Doesn't in Performance Management (2024)

چندی پیش این ویدئو و این متن در گروهی از همکاران ارسال شد:

✍فردی چندین سال شاگرد نقاش بزرگی بود و تمامی فنون و هنر نقاشی را آموخت.
استاد به او گفت که دیگر شما استاد شده ای و من چیزی ندارم ک به تو بیاموزم.

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

غروب که برگشت دید که تمامی تابلو علامت خورده است و بسیار ناراحت و افسرده به استاد خود مراجعه کرد.

استاد به او گفت: آیا می توانی عین همان نقاشی را برایم بکشی؟
شاگرد نیز چنان کرد و استاد آن نقاشی را در همان میدان شهر قرار داد. ولی این بار رنگ و قلم را قرار داد و متنی که در کنار تابلو قرار داد این بود که :
"اگر جایی از نقاشی ایراد دارد با این رنگ و قلم اصلاح بفرمایید"

غروب برگشتند دیدند تابلو دست نخورده ماند.
استاد به شاگرد گفت:
"همه انسانها قدرت انتقاد دارند ولی جرأت اصلاح نه...

💡 @OrgDev_LE

در نگاه اول شاید فکر کنیم واااو، چه درست و جالب می‌گویند. واقعا همینطور است ...

اما

به نظرم این زاویه دید همیشه درست نیست.

مثلا اگر کیفیت غذای یک شرکت به کارکنانش پایین باشد و کارکنان اعتراض کنند، آیا پاسخ درستی است که بگویند: «اگر ناراضی هستید، خودتان آشپزی کنید»؟ یا اگر خیابان خراب باشد و با ۱۳۷ تماس بگیریم، منطقی است که بگویند: «خودتان درستش کنید، این‌قدر غر نزنید»؟

در این موارد، اسم کار «غر زدن» نیست؛ اسمش مطالبه‌گری است. و در یک جامعه سالم، افراد حق دارند نسبت به خدمات، تصمیم‌ها یا عملکردها نقد و مطالبه داشته باشند، بدون اینکه به خاطر آن برچسب «غرغرو» یا هر چیز دیگر بخورند.

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

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

به نظرم این نوع روایت‌ها گاهی ناخواسته باعث می‌شن مطالبه‌گری با غر زدن یکی تلقی شود؛ در حالی که این دو کاملا متفاوت‌اند. حتی در برخی جوامع، از چنین ادبیاتی برای کم‌رنگ کردن مطالبه‌گری و سوق دادن مردم به سکوت و انفعال استفاده می‌شود.
وقتی افراد از ترس برچسب خوردن سکوت کنند، طبیعی است که مطالبه‌گری کاهش پیدا می‌کند و در نتیجه، پاسخ‌گویی هم کمرنگ‌تر می‌شود!

💡 @OrgDev_LE