BreakPoint



سازمان‌هایی که تلاش می‌کنند تا واجد صفت چابک» شوند، اگر از ارزش‌ها و اصول چابکی غفلت کنند یا دانش محدودی درباره نگرش (Mindset) چابک داشته باشند، اغلب به وضعیتی دچار می‌شوند که از چابکی تنها پوسته‌ای بر تن می‌کنند و چون به مغز و هسته‌ی چابکی توجه کافی ندارند، دور از انتظار نیست که همان روش‌های سنتی را با ظاهر چابک اجرا کنند.

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

اما ارزش‌ها و اصول چابکی چیستند؟ و چرا اهمیت آنها را دست‌کم می‌گیریم؟
نکته‌ این است که سادگی این ارزش‌ها باعث شده که آنها را بدیهی، دم‌دستی و سهل‌الوصول بدانیم. در حالی که اینگونه نیست و می‌توان گفت که:
که چابک» آسان نمود اول، ولی افتاده مشکل‌ها.

اگر مایلید شرحی دقیق و صحیح از ارزشهای چابکی و اصول مربوطه بدانید، پیشنهاد می‌کنم این کتاب جمع و جور را که به تازگی توسط Scott Duncan نوشته شده و مورد تایید بزرگانی چون Ben Linders, Ken Robin, Mike Cohn و Ron Jeffries است را مطالعه کنید.

https://www.infoq.com/minibooks/agile-values-principles

دانلود

دریافت فایل PDF

عنوان: Understanding-Agile-Values-Principals-Agile-Manifesto
حجم: 1.19 مگابایت
توضیحات: Understanding-Agile-Values-Principals-Agile-Manifesto

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

Finding service boundaries is really damn hard. There is no flowchart!
- Udi Dahan

Microservices should cleanly align to bounded contexts.
- Sam Newman

Microservices is loosely-coupled, service oriented architecture with bounded context.
- Adrian Cockroft

One microservice should cover one bounded context
- Vaughen Vernon

Why is every one so eager to establish  a 1:1 mapping between microservices and bounded contexts?
- Alberto Brandolini

فارغ از این جدالها، در این نوشتار سعی می‌کنم تا به این پرسش پاسخ دهم که برای یافتن BC ها به چه نشانه‌هایی باید توجه کرد؟

از بوم مدل کسب و کار  شروع کنید!

بوم مدل کسب و کار (Business Model Canvas) یکی از شیوه‌های ساده و کاربردی در مدل‌سازی کسب و کار است. این بوم، می‌تواند نقطه شروع خوبی برای شناسایی BC ها و ارتباط آنها با یکدیگر (Context Map) قرار بگیرد. این بوم مشتمل بر ۹ بخش به شرح زیر است:

  •     مشتریان
  •     ارزش پیشنهادی (محصولات و خدمات)
  •     کانال توزیع
  •     ارتباط با مشتریان
  •     جریان درآمد
  •     منابع اصلی و دارایی‌ها
  •     فعالیت‌های اصلی برای خلق ارزش پیشنهادی
  •     شرکای کلیدی کسب و کار
  •     ساختار هزینه‌ها

با دقت در بوم مدل کسب و کار به تصویری جامع از اجزای کلیدی مدل کسب و کار دست پیدا می‌کنید و این می‌تواند آغاز مسیری باشد که باید برای یافتن BC ها و مرزهای آنها طی کنید.

اطلاعات بیشتر:

بوم مدل کسب و کار چیست؟

سرنخ‌ها را دنبال کنید!

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

۱- مرزهای معنایی واژگان را شفاف کنید.

اریک اوانس (Eric Evans) در کتاب Domain-Driven Design: Tackling Complexity in the Heart of Software از اهمیت زبان فراگیر (Ubiquitous Language) به تفصیل سخن می‌گوید. منظور از UL زبانی است که همه‌ی افراد درگیر در پروژه آن را درک کرده، از ابهامات معنایی خالی باشد و در همه گفتگوها، کدها، تست‌ها و مستندات از آن استفاده شود. اما این زبان فراگیر تشکیل نمی‌شود مگر اینکه context مشخص باشد. او context را اینگونه معنا می‌کند:

The setting in which a word or statement appears that determines its meaning.

بنابراین یکی از سرنخ‌هایی که به تشخیص BC ها کمک مهمی می‌کند، همین تغییر معنای کلمات است. مثلا کلمه سفر» در کانتکست اعزام به ماموریت یک معنای کاملا متفاوتی در کانتکست گردشگری دارد.

۲- داده‌ها را در طول عمرشان بررسی کنید.

موضوعاتی مانند جریان داده، مالکیت داده‌، تضمین یکتایی داده‌ها و تاثیر ناشی از تغییرات داده بر داده‌های دیگر را مورد توجه جدی قرار دهید. به عنوان مثال اگر در تغییرات در داده‌های یک BC همواره باعث تغییر در  BC دیگری شود، می‌تواند نشانه‌ای از این باشد که مرزهای BC به درستی کشیده نشده‌اند.

۳- به متخصصین حوزه‌های مختلف (Domain Expert) پروژه توجه کنید.

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

۴- ساختار فعلی سازمان را زیر ذره‌بین ببرید.

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

If the architecture of the organization is at oods with the architecture of the system, the architecture of the organization wins.
--Ruth Malan

در جستجوی Autonomy

توجه کنید که وجه مشترک همه این سرنخ‌ها این است که آدرس Autonomy را به ما می‌دهند. Autonomy (استقلال داخلی) باعث ‌می‌شود تا تیم‌ها مستقل از هم کار کنند، وابستگی‌های دیتا و کدها کمینه شوند و در نهایت تحویل محصول سریعتر انجام شود. می‌شود گفت اگر BC ها طوری طراحی شوند که مانع تحویل زود به زود محصول شوند، یا تحویل یک BC وابسته به تحویل BC دیگری باشد، به احتمال زیاد در تشخیص BC ها دچار اشتباه شده‌ایم. اهمیت این موضوع تا این حد است که در بعضی منابع از Bounded Context به عنوان Autonomy Context نام برده شده است.

نکته پایانی: همه‌چیز در حال تغییر است.

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


منابع:
  •     Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans
  •     Nick Tune, DevoxxUK 2017
  •     Finding Service Boundries - Udi Dahan
  •     Thinking in Systems - Donella H. Meadows

agile-values-principles



سازمان‌هایی که تلاش می‌کنند تا واجد صفت چابک» شوند، اگر از ارزش‌ها و اصول چابکی غفلت کنند یا دانش محدودی درباره نگرش (Mindset) چابک داشته باشند، اغلب به وضعیتی دچار می‌شوند که از چابکی تنها پوسته‌ای بر تن می‌کنند و چون به مغز و هسته‌ی چابکی توجه کافی ندارند، دور از انتظار نیست که همان روش‌های سنتی را با ظاهر چابک اجرا کنند.


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

اما ارزش‌ها و اصول چابکی چیستند؟ و چرا اهمیت آنها را دست‌کم می‌گیریم؟
نکته‌ این است که سادگی این ارزش‌ها باعث شده که آنها را بدیهی، دم‌دستی و سهل‌الوصول بدانیم. در حالی که اینگونه نیست و می‌توان گفت که:
که چابک» آسان نمود اول، ولی افتاده مشکل‌ها.

اگر مایلید شرحی دقیق و صحیح از ارزشهای چابکی و اصول مربوطه بدانید، پیشنهاد می‌کنم این کتاب جمع و جور را که به تازگی توسط Scott Duncan نوشته شده و مورد تایید بزرگانی چون Ben Linders, Ken Robin, Mike Cohn و Ron Jeffries است را مطالعه کنید.

https://www.infoq.com/minibooks/agile-values-principles

دانلود

دریافت فایل PDF

عنوان: Understanding-Agile-Values-Principals-Agile-Manifesto
حجم: 1.19 مگابایت
توضیحات: Understanding-Agile-Values-Principals-Agile-Manifesto

1. Individuals and interactions over processes and tools.


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

2. Working software over comprehensive documentation


در بیانیه‌ی توسعه‌ی چابک نرم‌افزار گفته شده روشی که چابک‌کاران در توسعه‌ی نرم‌افزار پیش می‌گیرند، روشی است که در آن به نرم‌افزار در حال کار» نسبت به مستندات مبسوط و جامع» ارزش و اهمیت بیشتری داده می‌شود.
به بیانی دیگر اگر سازمان یا تیمی در تحویل مرتب و منظم نرم‌افزار کاربردی، دچار مشکل باشد، تلاش برای تهیه مستندات جامع و مبسوط هم احتمالا کمکی به چابک‌تر شدن آنها نمی‌کند. مستنداتی ارزشمندند که بتوانند تحویل منظم و زود به زود نرم‌افزارِ در حال کار را تسهیل کنند.

3. Customer collaboration over contract negotiation

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

4. Responding to change over following a plan

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


تصور کنید وارد مغازه قصابی شده‌اید و به آقای قصاب سفارش یک شقه ران گوسفندی داده‌اید! حالا به ابتدای جمله برگردید! بله عرض کردم که تصور» کنید!

 

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

 

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

 

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

 

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

 

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

 

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

 

راستی آبگوشت‌تان نوش جان!


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

 

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

 

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

 

مسلماً قرار گرفتن در موقعیت سیزیفیک، نه تنها تیم را به هیچ‌کدام از دستاوردهایی که آن مدیر تصور می‌کرد نرسانده بود، بلکه باعث شده بود تا انگیزه و اعتماد اعضای تیم از بین برود و رابطه‌ی تیم و آن مدیر، سرد و تیره شود.

 

برای تیم و به طور عام‌ برای همه انسان‌ها مهم است که مطمئن شوند که در پس رنج و زحمتی که متحمل می‌شوند، معنا» و هدفی بزرگتر وجود دارد. بی‌معنا و نابود کردن دست‌رنج افراد (حتی در حالت خفیف)، و قرار دادن آنها در شرایط سیزیفیک، انگیزه‌های فردی-تیمی را چنان از ریشه می‌خشکاند که کمتر عامل انگیزشی می‌تواند باعث شود تا تیم دوباره به وضعیت قبلی برگردد و آن کار را با شور و شوق انجام دهد.

- روح‌الله دلپاک

مطالعه بیشتر: 

Work and Meaning

 


اصطلاحاتی مانند Continues Delivery, Continues Deployment, Continues Refactoring, Continues Exploration, Continues Integration مدتهاست که به نقل محافل توسعه‌دهندگان نرم‌افزار به خصوص آنهایی که برای چابک‌تر شدن تلاش می‌کنند، تبدیل شده است. اما منظور از Continues بودن کاری چیست و چرا اینقدر بر ویژگی Continues بودن چنین کارهایی تاکید می‌شود؟

 

برای انتخاب ترجمه مناسب واژه Continues با مشکل چندانی روبرو نیستیم. می‌توانید از بین این واژگان یکی را انتخاب کنید: پیوسته، مستمر، مداوم، بی‌وقفه، متوالی، همیشگی، پی در پی.
(در ادامه، از واژه همیشگی» به جای Continues استفاده می‌کنم.)

 

اگر کاری ارزشمند است چرا آن را به صورت همیشگی» انجام ندهیم؟ اگر کنکاش در نیازمندی مشتریان، بازسازی کدها (Code Refactoring)، یکپارچه‌سازی اجزای محصول و تحویل ارزش به دست مشتری کارهایی ارزشمندند، چرا آنها را به صورت همیشگی انجام ندهیم؟ 

 

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

 

از سوی دیگر، انجام همیشگی» یک کار منجر به این می‌شود که برای آن کار یک جریان» (Flow) ایجاد شود. وقتی کاری به صورت یک جریان» در می‌آید، نشانه این است که موانعی که سر راه آن کار وجود داشته‌اند به مرور حذف شده‌اند. این همان وضعیتی است که تیم‌های چابک برای رسیدن به آن تلاش می‌کنند؛ یعنی برداشتن موانع بر سر راه خلق ارزش برای مشتری.

 

اما ایجاد جریان» مزیت دیگری هم دارد. این مزیت را با ذکر مثالی بیان می‌کنم: 

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

 

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

 

شما دوست دارید ساکن کدام روستا باشید؟ مشتریان شما هم همین را دوست دارند. اگر بتوانید جریان» تحویل ارزش به مشتری را مانند جریان آب آرام یک رودخانه برای مشتری فراهم کنید، آنها بهتر می‌توانند به توسعه کسب و کار خود بپردازند. مشتریان و ذینفعان خود را با این جریان همیشگی وفق خواهند داد و به شما اعتماد می‌کنند و دیگر از بابت نسخه جدید محصول (Big-Bang Release) که ممکن است برای آنها حکم همان سیل را داشته باشد، حیران و سرگردان نخواهند شد. 

جمع‌بندی:
تاکید بر ویژگی انجام دادن کارهای ارزشمند به صورت همیشگی» باعث می‌شود تا تیم به تکاپوی انجام راحت‌تر آن کار بیفتد و از این راه در انجام آن کار به چیره‌دستی و تبحر برسد. همچنین انجام یک کار ارزشمند به صورت همیشگی» باعث ایجاد جریان پایدار برای آن کار می‌شود. جریانی که می‌توان به آن اعتماد کرد و از احتمال وقوع اتفاقات غیر قابل پیش‌بینی (نظیر آن سیلاب) کاست.


 
کارل دانکر (Karl Duncker)، - روان‌شناس آلمانی – در سال ۱۹۴۵ آزمایشی ترتیب داد که نتایجش تا دهه‌ها بعد مورد توجه دانشمندان علوم رفتاری قرار گرفت. آزمایشی به نام Candle Problem که دریچه‌های تازه‌ای به دنیای پیچیده‌ی انگیزش، شناخت، قضاوت و تصمیم‌گیری گشود.

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

Why all Leaders should know about the "Candle Problem"

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

The Mystery Of Motivation



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

https://en.wikipedia.org/wiki/Candle_problem

اما بد نیست بدانید که بعد از دانکر، دانشمندان دیگری با اهدافی متفاوت، این آزمایش را تکرار کردند. یکی از آن دانشمندان توری هیگینز» (Edward Tory Higgins) – دانشمند، پژوهشگر، نظریه پرداز در زمینه روان‌شناسی اجتماعی، شخصیت و رشد - بود. هیگینز و همکارانش پی بردند که شیوه جمله‌بندی در بیان مساله» منجر به تغییر چشمگیر تعداد افرادی شود که راه‌حل بهینه را می‌یابند! تاییدی بر اینکه تغییر در بیان» می‌تواند بر شیوه فکر کردن ما و فهم ما تاثیرگذار باشد. گویی که فکر ما در سیطره‌ی ساختار و محدودیت‌های زبانی است که با آن حرف می‌زنیم. اما چطور؟

ادامه مطلب


آخرین ارسال ها

آخرین وبلاگ ها

آخرین جستجو ها