#معماری و #معمار
بنظر میرسه تعریف خیلی خوب و کوتاه از معماری میشه "فرآیندهای طراحی و ساخت سیستم ها می باشد." و معمار هم قاعدتا میشه "فرد متخصص در حوزه #تصمیم_گیری های مرتبط با معماری یک سیستم"
بنظر تعریف ها جامع و کامل هستند، ولی چرا در عمل، تصمیم گیری های این حوزه همیشه چالش برانگیز هست و با اینکه حتی سازمان ها برای توسعه انواع محصولات در بخش های مختلف اقتصادی (از ساختمان تا کارخانه، نرم افزار و ...) از متخصصان مرتبط هم استفاده می کنند، توسعه محصولات با این همه چالش و گرفتاری روبرو هست. مگر به جز اینه که معماری قراره نقشه راه توسعه ما باشه؟؟ پس چرا این همه بی راهه رفتن با وجود نقشه راه؟؟ آیا مشکل از نقشه راه هایی هست که متخصص نماها برای سازمان ها ایجاد می کنند؟؟ چجوری به عنوان یک عضو در سازمان (چه مدیر بالادستی چه زیردستی) بفهمیم نقشه ترسیمی توسط معماران ما را به کدام سمت میبرند؟؟
بیایید برای پاسخ دادن به سوالات قبل، و شفاف کردن و زدودن فهم اشتباه از کلمه معماری و معمار، یکم با توضیحات بیشتر، آنها را تبیین کنیم.

- نباید فراموش کنیم موضوعات مطرح شده در انتزاع های خیلی پایین (شالوده های) اندیشه قرار داره و قطعا چون خیلی روی انتزاع های بالادستی خودش تاثیر میذاره، نیاز به کلی تفکر داره. حتی عملا چون انتزاع های بالادستی در ذهن خواننده شکل گرفته، شاید حتی به نوعی تغییر پارادایم باشه موضوع و کلی پیچیدگی دیگر! مهارت #تفکر_انتقادی اینجا خیلی به شما کمک می کنه.
- باز نباید یادمون بره فهم معماری و معمار یک مدل ذهنی توصیفی ما انسان ها برای سیستم های انسان_ساخت هست. مثلا توسعه بر اساس مدل #تکامل در دنیای موجودات زنده، نیاز به فهم معماری نداره و بر اساس آزمون و خطا و نظریه ای تحت عنوان انتخاب طبیعی شکل میگیرد.
- یادمون باشه ذهن (در مدل تبیین شده در #علوم_شناختی) انسان ها، اینروزا بخش زیادیش انسان_ساخت شده، پس فهم معماری و معمار برای توسعه ذهن هم قابل استفاده است. کلمات مرتبط مثل مربی و منتور به نوعی معمار ذهن ما هستند. فهم این دو کلمه را سعی کنید فارغ از اکوسیستمی که درش فعالیت بیشتری دارید بدست بیاورید.
- کلمات معماری و معمار، در علوم مختلف کاربرد دارد و حتی میشه گفت اینقدر که در علوم مرتبط با ساختمان در اینترنت برای این کلمه مطلب هست برای دیگر علوم موجود نیست. در حوزه مرتبط با هر علم، کلمه سیستم در تعریف را هم به کلمه پر کاربرد آن علم تغییر می دهند. مثلا وقتی از کلمه معماری در علوم مرتبط با ساختمان استفاده می کنیم، منظور معماری ساختمان هست. هرچند در همان علوم برای مشخص کردن معماری دیگر سازه ها، از مثلا معماری ساختمان پل استفاده می کنند. کلمه دیگری که باز در علوم مختلف متفاوت هست، کلمه ساخت هست که باز در علوم مرتبط با ساختمان از فعل بنا کردن استفاده می شود. در حوزه ساختمان باید بین کلمات building و construction تمایز قایل بشیم. اولی در حوزه معماری ولی دومی در حوزه عملیات ساخت استفاده می شود.
- در تعریف از کلمه ساخت (build) استفاده کردیم. باید رفع ابهام کنیم و بگوییم ساخت با پدید آوردن کمی متفاوت است. پدید آوردن بیشتر در ایجاد چیزهایی استفاده می شود که بدون طرح و برنامه مشخص و مکتوب استفاده می شود ولی ساخت یعنی درست کردن براساس نقشه و طرح قبلی. ولی چیزی که در عمل مشاهده میشه به شوخی میگن حتی یک کارگر ساده هم اجازه نظر دادن در معماری ساختمان را دارد! بحث این نیست کسی نباید نظر بدهد، بحث سر تمایز قایل شدن در #تصمیم_سازی و #تصمیم_گیری می باشد.

از اینجا به بعد برای کمی بسته شدن زاویه نگاه، معماری نرم افزار را انتخاب می کنیم. با توجه به تعریف و تبیین ارایه شده، بنظرتون آیا معمار نرم افزار، صرفا می تواند بر حسب تجربه پاسخ پرسشی را در مسیر توسعه بدهد؟ آیا معمار نرم افزار می تواند بدون #بینش عمیق از کل سیستم مورد توسعه و علوم مرتبط با آن (#تفکر_سیستمی)، ادعای پاسخ گویی صحیح به مسائل داشته باشد؟
بذارید کلمات را در تعریف با تبیین های ارایه شده جاگذاری کنیم تا جوابگویی به سوال مطرح شده کمی راحت تر شود.
معماری نرم افزار: فرآیندهای طراحی و درست کردن نرم افزار بر اساس طرح و نقشه قبلی!
معمار: متخصصی که فرآیندهای طراحی و درست کردن نرم افزار را مشخص می کند!
فکر کنم وضوح بیشتری الان نسبت به کلمات مورد نظر داریم و نقدهای وارد به این حوزه شفاف تر هستند. انتخاب فرآیندها یعنی طرح و نقشه، که می تونیم بهش #ساختار و #چارچوب_توسعه نسبت بدیم.

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

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

با دو مثال کامپیوتری شروع کنیم.
- شاید در نگاه اول CDN ها مثل microservice خیلی جذاب و خوب باشند ولی در واقعیت به پیچیدگی هایی که به سیستم های نرم افزاری اضافه می کنند واقعا نمی ارزند! اگر با نگاه کامل بررسی کنی مصداق بارز ضرب المثل "تو مو میبینی، من پیچش مو" هست واقعا. مثلا این مقاله را بخونید. شاید در نگاه اول بگیم خوبه که داده در نزدیک ترین سرور به کاربر serve بشه ولی در عمل میبینیم که ما با برون سپاری یکسری از کارها عملا مجبوریم کلی نیازمندی دیگه را هم برون سپاری کنیم مثلا نیاز داریم بدونیم چه کاربری از کجا درخواست داده، چی درخواست داده، جواب اون سرور بهش چی بوده و ... خوب اینجا مشکلات شروع میشه. اول که هرگونه مشکلی در سیستم سازمان برون سپاری شده بوجود بیاد روی سیستم ما تاثیر میذاره! از این گذشته برون سپاری انجام شده شاید در نگاه اول با هزینه کمتر، کارکرد بهتری را برای ما به ارمغان بیاره ولی واقعیت قطعا چیز دیگری هست. سیستم برون سپاری شده برای دیگر نیازمندی های ما مصداق بارز دیگر ضرب المثل فارسی یعنی "خر را میارند پای بار" (ردِّ پای ریشه ی اصطلاحاتِ عامیانه، در شاهنامه ی فردوسی - که گر خر نیاید به نزدیک بار/ تو بار گران را به نزد خر آر) می باشد، که بجای بودن منطق پردازشی، مورد نیاز داده تولید شده در سرور مرتبط، سازمان برون سپاری مجبور میشه داده را با هزینه گزاف به سرور ما برسونه! یادمون باشه این هزینه شامل زمان هم میشه، یعنی ما با قطعا با تاخیر داده را بدست میاریم فارغ از اینکه ممکنه اصلا بدست نیاریم!
یادمون باشه مفهوم بالا که بهتره منطق بره جایی که داده تولید میشه موضوعی مهم در stream processing هست و می تونید با این عبارت کلیدی بیشتر بخونید.
اگر هم دنبال راه حل هستید که چجوری به اون نیازمندی اصلی که CDN بهمون ارائه میده را حل کنیم درک فهم edge computing و حل مشکلات مرتبط با این موضوع با unikernel ها می تونه گزینه به شدت خوبی باشه.
- اگر ما با عبارت "مرجع تسویه" در سیستم های مالی آشنا نباشیم اصولا دنیای متفاوتی از درک سیستم های مالی خواهیم داشت و نوع نگاه و مدل کردن ما به شدت متفاوت خواهد بود. یعنی سیستمی را طوری معماری می کنیم که شاید در نگاه اول سیستم مالی (مو) باشد ولی در عمل ظرافت های مورد نیاز یک سیستم مالی (پیچش مو) را نخواهد داشت.

یک مثال هم از دنیای ساختمان (عمارت های انسانی) بزنیم.
اگر ما قصد طراحی سیستم تاسیساتی یک ساختمان را داشته باشیم عدم آشنایی ما با عبارت "پمپ حرارتی" و استفاده از مفاهیم تجاری مثل "کولر گازی" دنیای ذهنی کاملا متفاوتی را برای ما میسازه و نمی تونیم درک درستی از عملکرد سیستم های پمپ حرارتی داشته باشیم. برای درک درست هم در عبارت "پمپ حرارتی" باید بدونیم حالتی از "انرژی" هست و کلی قوانین مرتبط هست که ما باید در خصوص انرژی برای معماری یک سیستم بر پایه این کلمه بدونیم.


پ.ن:
- بنظرم cloudflare به اشتباه به نیازمندی های سطح auditing میگه log! اگر بخوایم این مدل به هر data model یا data field که در سیستم برای توسعه دهنده ها ایجاد میشه از صفت log استفاده کنیم عملا داده هایی مثل metric هم میرن در زیر دسته log ها که بنظرم صحیح نیست. بنظرم log ها را فقط برای ثبت خطاهای سیستمی استفاده کنیم، هر چند بهتره کلا این کلمه دارای برداشت چندگانه را کنار بذاریم.
- دلیل اشاره به پست کلادفلر، این نوشته یکی از دوستان در لینکدین بود. و دلیل بعضی از دیگر مثال ها گفت و گو در زیر این پست کامیونیتی DDD

ذهن زیبا

🧠 اگر تا حالا وقت نکردید عمیق تر در شاخه میان رشته ای #علوم_شناختی (Cognitive Science) در خصوص کلماتی مثل مغز، نورون، ذهن، هوش، یادگیری و ... پژوهش (جست و جو و مطالعه به قصد یادگیری دانش های مرتبط) کنید یا حتی دلیلی برای اینکار نداشتید، پیشنهاد می کنم این #پادکست را دنبال کنید و با گوش دادن بهش کلی #تلنگر_ذهنی براتون ایجاد بشه که برید حتی عمیق تر راجب به این موضوعات کنجکاوی کنید. قطعا بدلیل ذات میان رشته ای بودن این حوزه هیچ پشیمانی از پژوهش نخواهید داشت.

🎙 در فصل اول، آسیه علیخواه، زیست‌شناس و پژوهشگر ژنتیک، کتاب «تاریخچهٔ مختصر هوش» اثر مکس بنت رو براتون تعریف می‌کنه. 👩‍🔬📚

لینک‌ها:
CastBox | Spotify | Apple Podcast

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

تشویق برای یک نفر، تنبیه برای همه! نگاهی به سیستم پاداش و تنبیه

متاسفانه بر خلاف نظر رایج در مدیریت که میگن برعکس رسم و شعار بالا (که در ساختارهای نظامی رایج هست) عمل کنیم، جامعه اشتباهات یک اکوسیستم (سازمان، کشور، جامعه، ...) را پای همه عضوهای آن اکوسیستم می نویسد! خوب یا بد بودن این موضوع جای بحث داره که در این پست امکان باز کردنش نیست. ولی جالبه روش سومی هم داریم که اینروزا زیاد به عنوان نظم خوب ازش یاد میشه و این هست که کلا تنبیه را از مدل فکری و عملی حذف کنیم! شاید شنیدید که میگن در یک حادثه ما دنبال مقصر نیستیم و صرفا می خوایم ریشه ایجاد مشکل را پیدا کنیم و جلوگیری کنیم از ایجاد دوباره آن! بحث مسئولیت پذیری و مقصر یک #تصمیم_گیری اشتباه را کاملا نادیده میگیرند و میگویند مقصر در یک حادثه اصولا وجود ندارد و نمی توان یا نباید تنبیه برای کسی در نظر گرفت! ولی این موضوع برخلاف #فرگشت (#تکامل معادل بسیار گمراه کننده ای برای کلمه Evolution هست، بیایید استفاده اشتباه را اصلاح کنیم) #هوش در موجودات زنده نیز هست، که می دانیم، تنبیه جز جدایی ناپذیر از فرآیند یادگیری، هوش و هوشمندی هست. اگر با این موضوعات آشنایی کافی ندارید، این پست در جهت معرفی پادکست ذهن زیبا را ببینید و بشنوید.

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

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

- Computers are 100 percent human creations, no less than spoons and baseballs. There is no science of spoons
- it’s OK to create an academic department of Tablecloth Science
- math isn’t a “science” in the normal sense of the word
- computers are just fancy machines, How would you feel about “Refrigerator Science?”

البته نویسنده نقدهایی که در انتها آورد را درست میگه (به بحث این پست مربوط میشه)، ولی ربطی به نقد در مسیر عنوان مقاله نداره و اصولا نقد به اکوسیستم حول #علوم_کامپیوتر و #توسعه_نرم_افزار هست. مثلا میگه نصب نرم افزار کابوس هست! عزیزانی که هر چی بهشون نقد می کنیم که رویکردهای فعلی توسعه نرم افزار فرسنگ ها به دور از واقعیت های مورد نیاز جامعه هست، تحویل بگیرند! اشتباهات فاجعه بار این عزیزان پای همه اکوسیستم نوشته میشه متاسفانه (تیتر این پست)! نگارنده مقاله به این عزیزان تیکه هم انداخته و بهشون صفت “Computer Sadly-Deficient Engineering” میده!

- Software project management methods don’t work.
- Installing standard software is a nightmare.
- Software QA is broken.
- Software is full of horrible bugs.
- Software is full of horrible security holes.
- Software is driven by fashion instead of sound practice.

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

قبلا در این پست اشاره شد که #ارتباط_برقرار_کردن و داشتن تنوع انواع دوست در #دایره_دوستی ما مهم هست و باید بدونیم برچسب های مختلفی برای انواع دوست وجود داره، مثلا در پی نوشت این پست گفتیم که در زبان عربی ۱۲ لایه دوستی یا برچسب برای دوستان وجود داره! پس بعد از درک اهمیت این موضوع، باید پاسخ بدیم چجوری بین دوستان مختلف خودمون تمایز قائل بشیم یا حتی چجوری از ابتدا به یک فرد اجازه بدیم وارد دایره شناختی فردی (برچسب دوست) ما بشه. یکی از راه های موثر امکان شروع یک گفت و گو در هر فرصتی هست.
شاید برای شما هم پیش اومده باشه در جمعی از افراد باشید و ندونید چجوری سر صحبت را باز کنید تا باهاشون عمیق تر آشنا بشید و حتی یک روز تفریحی خوب را بگذرونید. عبارت کلیدی questions to ask in friends group شما را به لیست جذابی از سوالات میرسونه که می تونه در جمع دوستان فارغ از تخصص افراد باعث ایجاد مشارکت و گفت و گو بشه. یکی از لیست های معروف 36 questions that might lead to love هست که توسط یک روان شناس معروف تهیه شده و سوالات به شدت جذابی داره، پیشنهاد می کنم حتما یکبار در یک جمع همخوانی کنید و پاسخ بدید به سوالاتش. یادمون باشه در اکثر لیست سوال ها با این عبارت کلیدی، اشاره میشه که همون اول شفاف بگید که هر فردی دوست نداره می تونه براحتی سوال را رد کنه و جواب نده و مخاطب خاصی برای سوال ها نگذارید و اصرار اضافه هم نکنید کسی جواب بده، مثل بازی های جرات یا حقیقت!

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

#تجربه فقط یک نوع نیست! چرا نباید تجربه‌ی زیسته و علمی را یکی بدانیم؟

یکی از موضوعاتی که معمولاً نادیده گرفته می‌شود و نیاز به دقت زیادی دارد، تفاوت بین انواع تجربه است. بسیاری فکر می‌کنند تجربه فقط یک نوع دارد و مثلاً می‌گویند: "تا تجربه نکنی، چیزی را یاد نمی‌گیری!" اما این جمله یک اشتباه بزرگ دارد: تجربه‌های مختلفی وجود دارند، مثل #تجربه_زیسته (که بیشتر شخصی و احساسی است، ویکی) و #تجربه_علمی (که سیستماتیک و مبتنی بر روش‌های دقیق است، روش‌شناسی یا متدولوژی ). این دو نوع تجربه زمین تا آسمان با هم تفاوت دارند!

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

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

مهارت‌های نرم یا نحوه اندیشیدن؟ چرایی نیاز به تغییر نگرشمان (خوانش متفاوت از #مهارت_نرم)

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

- تعریف: بیایید با تعریف دو کلمه در این عبارت، شروع کنیم. بنظر تعریف جامع و مانع برای #مهارت میشه "توانایی انجام یک کار" و با توجه به مکان قرار گیری کلمه "نرم" یعنی به عنوان پسوند کلمه مهارت و تعریف ارائه شده، میشه "ذهنی". پس تعریف کلی عبارت میشه "توانایی انجام یک کار ذهنی" و وقتی میگیم کسی دارای مهارت نرم هست یعنی توانایی ذهنی کافی برای انجام کارهای مرتبط را داره.

- تاریخچه: مثل خیلی از تکنولوژی های دیگر اولین بار این عبارت در سال 1972 در کتابچه راهنمای آموزش ارتش ایالات متحده دیده شده است. در قدیم، کارها بدنی بوده ولی به مرور زمان عموما کارها تلفیقی از بدنی و ذهنی شده که اونجا تقسیم بندی مهارت نرم و سخت بوجود اومد مثل سربازی حرفه ای.

- دلایل ابهام: اگر کمی به جملات گفته شده این بخش دقت کنیم قطعا با کمی کنکاش و #تفکر_انتقادی می تونیم متوجه بشیم که چرا استفاده از عبارت مهارت نرم این‌روزها به نوعی گمراه کننده هست تا کمک کننده. مثلا اگر مهارت سخت را بجای کارهای بدنی، به اون بخش از تخصص های ذهنی یک #مهندس (هر رشته ای) که مثل توسعه نرم افزار که کار کاملا ذهنی می باشد، منتقل کنیم، اصولا جداسازی سخت/نرم صحیح می شود؟ مثلا برای یک سرباز توانایی حل مسئله مهارت نرم بود ولی برای یک مهندس این توانایی در اصل مهارت سخت هست! پس دیگر چه چیزی مهارت نرم می باشد؟ اگر قرار است به یک حوزه بگوییم مهارت نرم برای تو مهارتی جانبی ولی مهم هست ولی در جای دیگه بگوییم مهارت نرم برای تو مرزی با مهارت سخت ندارد، حرف عجیبی نزده ایم؟؟

#تلنگر_ذهنی:
- یادمون باشه به جای پژوهش (مطالعه و یادگیری) روی معلول ها یعنی خروجی سیستم (فکری)، روی علت یا نحوه اندیشیدن خودمون کار کنیم. یعنی بجای خوندن کلی مطلب در خصوص موضوع ذهنیت قربانی (Victim mentality) قطعا مطالعه و تفکر به #نظریه_انتخاب (ویکی پدیا) خیلی خیلی تاثیر گذار تر هست. چون مدل ذهنی ساده تری به ما برای رفتار و تفکر میده، بدون نیاز به حفظ کردن کلی الگوی (حتی بد) دیگر.
- نقل قول معروف میگه "تخصص گرایی یکی از اصول مهم #توسعه و دلیل این همه توسعه پذیری جوامع مدرن است" ولی در این جمله یک کج فهمی می تونه نهفته باشه که تخصص صرفا در حوزه #تصمیم_گیر‌ی، ملاک هست نه در حوزه پژوهش و یادگیری! یعنی ما اجازه نداریم به دلیل اینکه در حوزه های مختلف باید مطالعه کنیم خودمون را صاحب نظر و اجرای نظرات خودمون را یک اصل برای دیگران بدونیم.


جمع‌بندی:
در نهایت بنظر بجای گفتن "یادگیری مهارت های نرم خیلی مهمه" از این به بعد بگیم "یادگیری نحوه اندیشیدن پایه های اساسی #به_زیستی فردی و اجتماعی است" اینجوری بجای ایجاد ابهام و هدایت به سمت و سوی نامشخص، فرد به راحتی به کلی منبع موثر میرسه.
با بخش هایی از شعری از مولانا این پست را خاتمه میدم.
**هر کسی کو دور ماند از اصل خویش باز جوید روزگار وصل خویش
**هر کسی از ظن خود شد یار من از درون من نجست اسرار من

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

🧠 توهم سرعت زیاد در #پیشرفت #علم و #تکنولوژی

🌱 همیشه تا جای امکان در گفت و گوهای مختلف یادآوری می کنم، سرعت توسعه علم به شدت کند می باشد، توهم سرعت زیاد حتی در توسعه تکنولوژی نیز گمراه کننده است، آنچه خیره کننده است، #تغییرات بزرگ است نه سرعت توسعه علم و تکنولوژی. این حس سرعت زیاد، حتی القا کننده حس های بد در ما انسان ها می باشد و عموما باعث سرخوردگی می شود. پس همیشه در ذهن خود این موضوع را بخاطر داشته باشید که یادگیری موثر، مطالعه و یادگیری علوم هست.
🌱 ما در دنیایی زندگی می‌کنیم که انتظار داریم هر روز شاهد پیشرفت‌های خیره‌کننده‌ای باشیم، اما واقعیت این است که سرعت توسعه علم به شدت کند است. آنچه ما به عنوان "سرعت زیاد" می‌بینیم، اغلب نتیجه‌ی تلاش‌های طولانی و پیوسته‌ی دانشمندان و محققان است. تغییرات بزرگ و بنیادین زمان‌بر هستند و نیاز به صبر و تلاش فراوان دارند.
🌱 پس به جای تمرکز بر سرعت، بهتر است به #تغییرات_بزرگ و تأثیرات ماندگار آنها توجه کنیم. علم و تکنولوژی مانند یک درخت هستند که به آرامی رشد می‌کنند، اما ریشه‌های عمیق و ثمرات ارزشمندی دارند.

🔬 هدف اصلی این پست
اگر می‌بینید مطالب کمی در کانال منتشر می‌شود، به این معناست که انتشار موضوعات مهم و با کیفیت هدف ماست. خوانش دوباره پست‌های قبلی نیز از اهمیت زیادی برخوردار هستند. اگر تازه به جمع ما پیوسته‌اید یا حتی در گذشته مطالب را مطالعه کرده‌اید، پیشنهاد می‌کنم با استفاده از کلمات کلیدی جذاب، مطالب قبلی را دوباره مطالعه کنید. مطالعه دوباره ۱۳۰ پست که با دقت و غنای کلامی بالا نگارش شده‌اند، قطعاً برای #اندیشیدن #اندیشمندان عزیز همراه مفید خواهد بود.

📚 مثالی از مطالب قبلی
⏳ در این پست و سلسه جلسات مرتبط (فصل دوم در کست باکس)، مدل جداسازی برگرفته از #فلسفه_علم را به عنوان پایه ای ترین موضوعی که هر فعال حوزه #علم باید آگاهی و بینش کافی ازش داشته باشه را مورد کنکاش قرار دادیم. یادمون باشه در اکثر تعاریف اینجوری تبیین می کنند این علم را:

در واقع فلسفهٔ علم، دانش «مطالعه علوم» است.

یعنی وقتی کمی به موضوعات این حوزه مطالعاتی آشنا بشیم اول کمتر دچار #خطا_شناختی (سوگیری های ذهنی) میشیم و در کنارش درک بهتری از نحوه #اندیشیدن خواهیم داشت.

💬 چند مثال و #تلنگر_ذهنی جدید
⏳ وقتی با #فلسفه_علم آشنا بشیم با برخورد با علوم مختلف مثل #علم_سیاست براحتی متوجه تعاریف اشتباه در ذهن خود میشیم و با کمی #پژوهش موثر (بدلیل یادگیری موثر از پایه های علم) درک خواهیم کرد که ممکنه چقدر درک ناقضی از علوم مختلف و کلمات مرتبط باهاش در ذهن ما اتفاق افتاده باشه و براحتی مفاهیم علوم مختلف که در اینجا علم سیاست را با علم حکمرانی را با دانش و بینش اشتباه در ذهن نهادینه کرده باشیم. با یادگیری #فلسفه_علم خواهیم فهمید ذهن محدود ما در ابتدای برخورد با موضوعات بهتره از طریق یادگیری نظریه های ساختار یافته در حوزه های مختلف توسعه پیدا کنه.
⏳ یکی از نظریه‌های جالبی در علم سیاست، #نظریه‌ی_بازی ها هست. این ویدئو را ببینید تا متوجه شوید چرا همه به دانش کافی در علم سیاست نیاز دارند. تشکر ویژه هم از کیانوش داشته باشم که این ویدئو را در کانالش قرار داد و برای من یادآور مطالعات قبلی در موضوع جذاب و مهم نظریه بازی بود.
⏳ نیاز به تاکید می باشد که نظریه های تولید شده در یک علم، اغلب مبنای تفکری قوی در علوم دیگر نیز هستند. مثلا مفهوم #بازی_مجموع_صفر (ویکی پدیا) در #علم_اقتصاد نیز بسیار مهم است.

🧠 #تمرین عملی با #تجربه_زیسته دو موضوع متفاوت می باشد

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

⏳سوال معروف در حوزه #پزشکی_مبتنی_بر_شواهد (ویکی پدیا، پست هایی به قلم دکتر صمدی) این می باشد که شما حاضرید سلامتی خود را در اختیار پزشکی قرار دهید که مدعی این می باشد که مثلا بالای 30 سال تجربه در برخورد با بیماران یک بیماری خاص (مثلا صرع) را داشته و هیچ گونه داده دیگر مبنی بر مثلا درصد بهبود یا مرگ ناشی از روش های مبنی بر تجربه خودش را به شما ارائه ندهد؟ تفاوت تجربه زیسته و علم و دانش با روش شناسی های حاصل از تجربه علمی دقیقا در اینجا می باشد که هر چیزی امکان تبدیل به دانش مکتوب و مستند را نخواهد داشت به جز اینکه روش های مشخصی را طی کند.
🔬 یادمون باشه تمرین کردن برای ایجاد #بینش، پس از یادگیری #دانش مورد نیاز کاربرد دارد و بدون یادگیری موثر اولیه دانش مورد نظر، تمرین یا تجربه (زیسته) کردن صرفا میشه یکسری آزمون و خطای بی حاصل و گمراه کننده!

💬 در نهایت در جهت تمرین انواع #تفکر مانند #تفکر_انتقادی ، #تفکر_سیستمی و #تفکر_انتزاعی در زیر این پست سعی می کنم چت هایی که با چت بات ها با مدل های #ذهن_مصنوعی (قبلا اشاره کردیم چرایی اشتباه کلمه #هوش_مصنوعی) در جهت بررسی موضوعات خاص و چالش بر انگیز داشتم را منتشر کنم تا ببینید به چه راحتی می‌توانند این چت بات ها بدلیل وجود دانش غیر موثر و غلط حاصل از تجربه های زیسته اشتباه در اختیار آنها در زمان یادگیری (train شدن)، دچار انواع خطای شناختی و انواع مغالطه می شوند. هر چند اگر ما استدلال های قوی مطرح کنیم، عموما چت بات ها سریع از این خطاها و مغالطه ها مثل مغالطهٔ حفظ پیش‌فرض دوری می کنند.
اگر شما هم دوست دارید در جهت تایید یا رد موضوع استدلال های خود را مطرح کنید. و اگر هم دوست داشتید متن چت های خود را با چت بات ها که منجر به تغییر نظر چت بات ها و تذکر اشتباهات اونا بوده را منتشر کنید که بقیه هم بتونن با نحوه گفت و گوی شما بیشتر آشنا بشوند.

روز #مهندس را به تمام #اندیشمندان مجهز به #تفکر_مهندسی تبریک میگم.
همیشه به خودم گوشزد می کنم که هیچ گاه فراموش نکنم بدست آوردن هر لقب علاوه بر حس خوب مالکیت، دارای بار مسئولیت زیادی برای ما خواهد داشت و امیدوارم همگی لایق این لقب ها باشیم و در مسیر #توسعه به شایسته ترین حالت از این القاب استفاده کنیم.

تبیین عمیق تر #معماری و #معمار

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

احتمالا با الگوی Retry آشنا هستید، الگویی که در ذات بدلیل فهم ناقض و فقدان #تفکر_سیستمی می تواند #تجربه_کاربر را دچار خدشه کند. به طور مثال حتی اگر قرار به پیاده سازی این الگو باشد، عموما این الگو توسط فرآیندهای سیلو شده در تیم های بک اند انجام میپذیرد! بدلیل عدم نگاه سیستمی و وجود مرزهای بوجود آمده (فرانت/بک) فرآیند به شکل صحیح قابلیت ترسیم حتی برای خود توسعه دهندگان نیز ندارد. به دلیل همین فقدان ها یعنی نبود دانش موثر در تصمیم گیری ها، حتی شاید از پیاده سازی این الگو بدلیل پیچیدگی ها زیاد آن صرفنظر می شود و براحتی فراخوانی مجدد فرآیند را به شکل ناشیانه ای به کاربر منتقل می کنند. کاربر کلافه از فرآیندهای ناقض و خسته کننده، اگر با بازار رقابتی روبرو باشد قطعا به عنوان یک کاربر ناراضی سازمان را رها می کند و در اکثر اوقات حتی بدون داده مناسب برای سازمان و حتی خود فرد در خصوص چرایی این اتفاق، سازمان صرفا تماشاگر از دست دادن سهم بازار خواهد بود. هر چند متاسفانه در سازمان های وابسته به حکومت کشورها، این موضوع مهم بدلیل ذات انحصارگرایانه ارائه خدمت عملا منجر به ترک سازمان نمی شود ولی منجر به مشکلات اجتماعی مثل بالا رفتن سطح خشونت در جامعه خواهد شد. اتفاقی که متاسفانه در خیلی از اوقات صرفا با سرکوب معلول (خشم، ...)، بدون حل علت، به دنبال پنهان کردن آنها هستند. وقتی حرف از حل ریشه ای مشکلات می کنیم، نگاه خطی به هیچ عنوان موثر نمی باشد و قطعا نیاز به #تفکر_سیستمی خواهیم داشت.

بگذارید یک مثال واقعی هم که قبلا بهش برخورد کردم را اینجا مطرح کنیم. در نرم افزار ازکی (azki.com) وقتی قصد ثبت یک پلاک جدید دارید و سرویس مورد نظر به هر دلیلی در دسترس نباشد، به شکل عجیبی اول درخواست با استفاده از پروتکل HTTP با کد وضعیت 200 پاسخ داده می شود ولی در عملا در بدنه خطایی ارسال می شود با مضمون به زبان فارسی "در حال حاضر امکان ثبت پلاک وجود ندارد."! متاسفانه بدلیل error handleing ضعیف این نرم افزار، اولا کاربر اصلا متوجه نمی شود که خطایی رخ داده، چون خطایی نمایش داده نمی شود! مشخصا سرویس در سمت سرور قصد برقراری ارتباطی با سرورهای بیمه مرکزی یا پلیس راهور را دارد و بدلیل عدم پاسخگویی آنها، امکان ثبت مهیا نمی باشد. هر چند مشخص نیست. بدلیل ذات طولانی بودن مدت درخواست (16 ثانیه) می شود حدس زد که در سمت سرور حداقل چندبار تلاش (الگوی نام برده شده) اتفاق افتاده است! ولی آیا کاربر عادی 16 ثانیه صبر میدهد بدون اینکه بداند فرآیند در بدون چه وضعیتی می باشد؟ قطعا اگر داده مناسب جمع آوری شود براحتی می توان ادعا کرد بالای 50% از کاربرها به عنوان وجود مشکل به مرورگر دستور بارگزاری مجدد صفحه را می دهند!
قصد نیست در چند خط کوتاه پاسخ قطعی به موضوع بدهیم، ولی از دید شما بهتر نیست فرآیند به شکل عمومی تر دیده بشه و در سمت نرم افزار کاربر، در هر حال فرآیند اخذ اطلاعات و نمایش به عنوان پلاک جدید با یک وضعیت مثلا در حال بررسی نمایش داده شود و در فرآیندهای مستقل تر موضوع تایید پلاک انجام پذیرد؟ و موضوع الگوی تکرار بدون نیاز به دخالت کاربر در زمان مناسب تر انجام پذیرد؟ عموما وقتی در حال ایجاد یک خطا هستید به این فکر کنید که مخاطب خطا کیست؟ آیا اصولا نیاز به وجود این خطا می باشد یا نیاز به اصلاح یا ایجاد فرآیند درست دیگر در جهت حل مشکل در فرآیند. در کامنت های همین پست عکس های مرتبط با ازکی را قرار میدهم که ملموس تر باشد موضوع.

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

🌏🥳 سال نو مبارک 💐🌳

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

💬پیشنهاد می کنم سال جدید را با دقت به اینکه #تفکر یک حالت درونی ما انسان ها هست، بیشتر برای ارتقا این خصیصه درونی وقت بذاریم تا بتونیم درک بهتری از جهان پیرامون خودمون داشته باشیم. وقتی تاکید فراوان به یادگیری انواع تفکر مثل #تفکر_سیستمی یا #تفکر_انتقادی داریم، منظور ارتقا حالت درونی خودمون هست، نیاز نیست به سرعت انتظار داشته باشیم در خروجی های ذهن خودمون تغییری را مشاهده کنیم، یادمون باشه #توسعه امری زمان بر هست. به خودمون فرصت بدیم و از زندگی نهایت #شادی و #لذت را ببریم.

🔗 #خوانش کتاب Learning Systems Thinking: Essential Non-Linear Skills and Practices for Software Professionals
از نشر o'reilly

🤝 پس از بررسی و همفکری با همراهان همیشگی، #کتاب بعدی برای خوانش گروهی انتخاب شد. هر چند اینبار بر خلاف دفعه های قبل هنوز خوانش کتاب قبل یعنی DDIA تمام نشده است ولی به دلیل اهمیت موضوع و نیاز به مطرح شدن هر چه سریع تر موضوع خوانش را موازی شروع خواهیم کرد.
در کامنت های همین پست، جزییات شرکت در جلسات و صوت ضبط شده جلسات را قرار میدیم. مثل همیشه اگر فرصت شرکت در جلسات را نداشتید می تونید در فصل 5 کانال در کست باکس هم صوت جلسات این کتاب را گوش بدید و اگر سوال، ابهام یا نقد/پیشنهادی بود همینجا مطرح کنید.

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

✨ Self-awareness, also known as metacognition, is the ability to understand and adapt your thinking patterns. Practicing with your own thinking is, perhaps unsurprisingly, the foundation of thinking in systems.
✨ In a world so interconnected by software, systems thinking is an essential skill for navigating the compounding sociotechnical complexity in software development.

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

ویدئو این پست هم کاری از هنرمندان معاصر عزیزی هست که واقعا با هنرمندی تمام عیار قدرت کلمات بزرگان گذشته را همراه با موسیقی زیباتر در ذهن و روح ما اثر گذار می کنند. شعر این قطعه، غزل شمارهٔ ۴۸۴ سعدی و غزل شمارهٔ ۶۰۷ می باشد.
بیا که در غم عشقت مشوشم بی‌تو // بیا ببین که در این غم چه ناخوشم بی‌تو
شب از فراق تو می‌نالم ای پری‌رخسار // چو روز گردد گویی در آتشم بی‌تو
...
من چرا دل به تو دادم که دلم می‌شکنی // یا چه کردم که نگه باز به من می‌نکنی
دل و جانم به تو مشغول و نظر در چپ و راست // تا ندانند حریفان که تو منظور منی
...

🧠 #تفکر_سیستمی و #تفکر_انتقادی دو رکن جدانشدنی حل مسائل (بخصوص مسائل پیچیده) هستند.

🔬در مدل سازی و تفکر بر پایه نظریه سیستم ها، یکی از موضوعات واضح و بدیهی تا جای امکان کنار گذاشتن هر نوع پیش فرض (بررسی بیشتر در #تفکر_انتزاعی) در مدل کردن است. یکی از اهداف مهم تفکر انتقادی، شناسایی پیش فرض ها می باشد، چیزی که در مدل کردن یک سیستم برای درک و احیانا تغییری در سیستم بسیار مهم هست.

⏳توی دنیای امروز که سیستم‌ها هر روز پیچیده‌تر (complex) می‌شن، توانایی مدل‌سازی دقیق و بدون #سوگیری برای درک و بهبود این سیستم‌ها، یه مهارت کلیدی برای تصمیم گیران ارشد و کساییه که می‌خوان به سطوح بالای دانش و مهارت (حل مسئله) برسند. تفکر سیستمی به ما این امکان رو می‌ده که سیستم‌ها رو به صورت یه کل یکپارچه ببینیم و تعامل بین اجزای مختلفشون رو تحلیل کنیم. اما این مدل‌سازی وقتی واقعاً اثرگذار می‌شه که بتونیم پیش‌فرض‌های ذهنی‌مون رو با تفکر انتقادی به چالش بکشیم و از واقعی بودن پایه‌های #مدل هامون مطمئن شیم.

💬 این موضوع توی توسعه نرم‌افزار خیلی ملموس‌تره. فرض کنیم توی طراحی یه سیستم، به اشتباه "اینروزا همه کاربران به اینترنت پهنای باند بالا و پایدار دسترسی دارن." اگه این پیش‌فرض رو نقد نکنین، ممکنه توسعه به نحوی پیش بره که برای بارگذاری داده‌ها بهینه نباشه و توی دنیای واقعی، عملکرد سیستم رو برای خیلی از کاربران مختل کنه. اینجا تفکر انتقادی به کمک میاد تا این فرض رو زیر سؤال ببره و با داده‌های واقعی، شما رو به سمت توسعه (طراحی یه معماری) انعطاف‌پذیرتر و مقیاس‌پذیرتر هدایت کنه، مثلاً با درک عمیق تر مفهوم Cache و مفاهیم و تکنیک های مرتبط مثل lazy loading یا حتی بازطراحی فرآیندهای نرم‌افزار برای کاهش پیچیدگی محاسباتی یا انتقال بار پردازشی به client یا edge نودها و کاهش انتقال اطلاعات در شبکه های غیر پایدار اینترنت.

💬 یا در موضوع #حکمرانی #قانون فکر کنیم که همیشه #حکومت ها نیاز هست در پیاده سازی و نظارت به اجرای قانون باید به شکل انحصاری عمل کنند تا بتوانیم مطمئن بشیم قوانین (خواسته های جمعی آحاد جامعه) پس از نگارش به شکل متون با مدل مشخص، به شکل صحیح در جامعه، جاری می شوند. بذارید مثال عینی بزنیم که بشه مبنای فکری ما برای ایجاد تمرین های مشابه. فرض بگیرید جامعه به دلایل مختلف برای شناسایی وسایل نقلیه به یک توافق جمعی می رسد، آیا پیش فرض اینکه ما حتما نیاز به یک سازمان واحد برای ایجاد پروتکل های مورد نیاز و اجرای اون پروتکل ها داریم؟ اگر صرفا پیش فرض های گذشته در ذهن ما به شکل قوی وجود داشته باشد که #تجربه_زیسته همه جامعه ها به احداث سازمانی با عناوینی مانند سازمان راهنمایی و رانندگی ختم شود، پاسخ ما به سوال مطرح شده در جهت حل یک مسئله (شناسایی وسایل حمل و نقل) قطعا شبیه به گذشته خواهد شد، ولی با قوی شدن انواع تفکر در ما، قطعا در دام پیش فرض ها گرفتار نخواهیم شد و با پی بردن به اینکه تصمیم گذشتگان بر پایه عدم وجود سیستم های کامپیوتری بوده است، می توان تصمیم های به شدت بهینه تری در حل پرسش ها در حال، ایجاد کنیم.

💬 به بیان ساده‌تر، تفکر سیستمی بدون پشتوانه تفکر انتقادی می‌تونه به مدل‌های غیرواقعی و ناکارآمد منجر بشه. برای همین، در جلسات خوانش کتاب یادگیری تفکر سیستمی در Geniuses.Group قراره این دو مهارت رو عمیق‌تر بررسی کنیم و ببینیم چطور ترکیبشون می‌تونه به راه‌حل‌های نوآورانه و پایدار برای روبرویی با مسائل پیچیده منجر بشه.

🧠 #تکنولوژی (#فناوری) چیست؟

🔬از دید نگارنده بهترین تعریف برای فناوری میشه "دانش (تکنیک‌ها، مهارت‌ها، روش‌ها و فرایندها، ...) توسعه (ایجاد یا تغییر) سیستم ها (ابزارها، دانش ها، ...) برای تحقق اهداف مورد نظر". جالب شد، بازم کلمه سیستم رخ نمایی کرد! کلمه دانش در تعریف را هم میشه به #علم در تعریف #مهندس و #مهندسی (در این نشست در مورد تعریف مهندس صحبت کردیم) ارتباط داد و اگر متخصص های حوزه فناوری از علم در توسعه فناوری استفاده کنند، قطعا سیستم های با کیفیت تری توسعه داده می شود.
🪄از این به بعد هر جا با کلمه تکنولوژی (تک، ...) برخورد کردید با نگاهی دقیق تر موضوع را بررسی و مورد نقد و کنکاش قرار بدید. مثلا بهتر می توانیم درک کنیم که چرا در یک سازمان CTO (Chief Technology Officer) بایستی حتما دانش به شدت موثر و نسبتا عمیقی از مفاهیم مرتبط با سیستم های در حال توسعه داشته باشد، رفع مسئولیت از خود با عنوان "کمبود دانش موثر" قابل پذیرش نیست و کسی باید قبول مسئولیت کند که توانایی کسب یا نقد دانش منتقل شده از متخصص حوزه مرتبط را داشته باشد. اینجا قبلا عمیق توضیح دادیم.
🪄یادمون باشه فناوری محدود به موجودیت های عینی (موبایل، کامپیوتر، تلسکوپ، ...) نمیشه و موضوعات ذهنی (سازمان، گفتمان، ...) هم در این دسته می توانند قرار بگیرند.
🪄 در #فلسفه_علم هم تاکید می شود که مرز بین علم و فناوری برای هر اندیشمندی باید مشخص شود. یادمون باشه فناوری ارتباط عمیقی (سیستم، ...) با #تفکر_سیستمی و #تفکر_انتقادی که در گروه هم بهشون زیاد میپردازیم، دارد.

⏳راستش این پست را خیلی وقت بود می خواستم نگارش کنم ولی جنگ نالازم و پیش بینی پذیر (توییت بنده چندین ماه قبل از جنگ) گذشته، حوصله نگارش را گرفته بود، اتفاقاتی که به راحتی میشد از وقوع آنها جلوگیری کرد فقط و فقط اگر اراده و عواقب تصمیمات و صحبت های هر فرد در هر جایگاهی در #حکومت جمهوری اسلامی مشخص و گریبان گیر آنها بود. ولی بیایید #جنگ را به همین موضوع فناوری ارتباط بدیم. در ذات جنگ هم مانند هزاران موضوع دیگر یک فناوری محسوب می شود. شاید شنیدید که میگن اگر جمهوری اسلامی مثلا به فلان رادار یا هواپیما دسترسی داشت، قطعا برنده جنگ بود و ... این مدل گزاره ها صرفا از یکسری مغزهای کوچک زنگ زده تراوش می کنه! آیا درست تر این نیست که یادمون باشه تکنولوژی در خدمت کیفیت زندگی انسان ها همیشه باید باشه؟ یعنی آیا فناوری دیگه مثل #گفتمان را از ما گرفتند که که به بدترین فناوری ها متوسل بشویم؟ باز نکته مهم این هست که یادمون باشه هر تکنولوژی آداب و رسوم خودش برای استفاده را دارد، یعنی نمی شود حرف از گفتمان زد ولی در عمل به دنبال وقت خریدن و گذر زمان باشیم!
⏳یا بحث #سیاست گذاری جدید در بعضی از شهرهای ایران مبنی بر ممنوعیت غیر مستقیم داشتن حیوان خانگی! واقعا چرا اینقدر سطحی نگر؟؟ واقعا نمی دانند:

سبک زندگی خود نوعی تکنولوژی می باشد

شاید در نگاه اول این گزاره به شدت عجیب باشد. تکنولوژی شاید در ذهن خیلی از ما ارتباط غیر مستقیم با سبک زندگی داشته باشه ولی ارتباط مستقیم بهش دادن برای خیلی ها ممکنه عجیب باشه! ولی بیایید برای روشن تر شدن موضوع بر اساس تعریف بالا که نسبتا جامع و مانع می باشد موضوع را بیشتر بررسی کنیم. یادمون باشه سبک زندگی اگر به عنوان یک سیستم بهش نگاه کنیم، در تفکر سیستمی گوشزد میشه که باید به ابعاد مختلف ماجرا دقت بشه و نمیشه به فناوری های دیگر مانند خانواده، حریم خصوصی، ... را نادیده بگیریم و به شکل ساده انگارانه سعی در تغییر صرفا سبک زندگی داشته باشیم.
⏳ #تجربه_زیسته خود حکومت در قلمروی جغرافیای ایران و حتی جهان ثابت کرده منع انسان ها از چیزی به شکل #قانون با #ضمانت_اجرایی پلیس اصولا با شکست مواجه می شود ولی همانطور که همیشه می گوییم تا وقتی روی #تجربه_زیسته بیش از اندازه خودش حساب باز کنیم، همین آثار مخرب را خواهد داشت. یعنی درس نگرفتن بدلیل عدم وجود خروجی مناسب به شکل و اصولی که در #علم بهشون دست یافته ایم. در #تجربه_علمی ما سعی در ایجاد چندین خروجی به عنوان گزاره ها و در ادامه تبدیل به ترجیحا یک خروجی موثر به نام #فرضیه و در ادامه تبدیل آن به #نظریه داریم که به شکل خیلی موثر و راحت قابلیت انتقال بین انسان ها را دارا باشد بدون نیاز به مطالعه در مورد چیستی (#تفکر_انتزاعی) برای همه انسان های درگیر در موضوع. پس در خصوص این موضوع علوم مختلف مثل علوم اجتماعی، علم حقوق، حکمرانی، سیاست و ... به شکل کاملا دقیق موضوعات مرتبط را مطرح کرده اند و نیاز به مراجعه به تجربه زیسته آن هم در سیستم در حال کار نیست! دوستان توسعه نرم افزار می دانند که چقدر کار بدی هست در کدهای یک نرم افزار در حال اجرا بخواهیم تغییری ایجاد کنیم!


🔗 شما تا حالا به فناوری به چه شکلی نگاه میکردید؟ آیا نگاه مشترکی با نگارنده داشتید؟

🧠چرا تقابل کاذب (سندروم "VS") گفتمان در اکوسیستم های توسعه رو مسموم می‌کنه؟

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

🔬اخیراً در جاهای مختلف دست نوشته هایی را دیدم که اصلا انتظار این مدل نگارش‌ها را نداشتم و نگارنده ها دنبال مقایسه سیب و پرتقال هستند، شاید در ذات بگید میشه مقایسه کرد، منم میگم باشه میشه ولی هدف چی هست؟ مثلا جایی تیتر زدن که آیا مایکروسرویس و DDD برای تیم‌های کوچک مناسبه؟ (تقابل DDD با تیم های کوچک) یا رحیم فیروزی عزیز در کانالش نوشته "سادگی یا اسکیلبیلیتی؟" و جایی نوشته شد بیاین در مورد "FP vs OOP" صحبت کنیم. اما چرا همیشه این سندروم "VS" اینقدر جذاب مطرح میشه در صورتی که ترکیبی از مغالطه‌هایی مثل false dichotomy (#دوگانه_کاذب) و confirmation bias، بحث‌ها رو ساده‌انگارانه می‌کنه و راه گفتمان واقعی رو می‌بنده.
⏳در پست DDD مثل همیشه قصد اینه بگن DDD تقریبا همیشه برای توسعه در سازمان های large scale هست! حتی برای اینکه جلوی بعضی ایرادات را از همان ابتدا بگیرند، تعریف های عجیبی از مدل سازمان مورد نظر میدن که بزرگی سازمان یا تعداد کارمند را صرفا قبول ندارند! انتخاب اشتباه موضوع باعث شده همش دنبال توجیح باشند. اینجا قصد نداریم بگیم DDD بدرد چه نوع توسعه ای می خوره چون اعتقاد راسخ دارم که این رویکرد توسعه بدرد هر نوع توسعه نرم افزاری می خوره و اصلا ارتباطی به سایز پروژه یا سازمان نداره. این موضوع را به شکل عمیق در آینده ای نزدیک در جلسات #خوانش کتاب DDD اریک ایوان مطرح خواهیم کرد.
⏳در مقاله رحیم عزیز واقعیت اینه سادگی و اسکیلبیلیتی دو موضوع کاملا مجزا و حتی کاملا بی ربط به هم هستند. هر چند نیاز بود رحیم عزیز مشخص کنه منظورش از "سادگی" دقیقا چی هست؟ چون وقتی در مقابل مقیاس پذیری قرارش میدیم چندین برداشت میشه ازش داشت، مثلا من احساس کردم منظورش اینه در ابتدای توسعه هر مدلی دوست داری برو جلو، بعدا که نیاز شد تغییرش میدی! ولی این تفکر آیا با اصول #علمی در یکسو هست؟ اگر همه مهندسان دنیا اینو بگن چه بلایی سر #پایداری جامعه ها میاد؟ فکر کنید یک تیم توسعه ساختمان بگن فعلا یک طبقه ساختمان بسازیم، اگر استقبال خوب بود بعدا 20 طبقه دیگه روی این ساختمان میسازیم! این نوع نگاه ممکنه نشان از کمبود دانش موثر در توسعه بخصوص #توسعه_پایدار باشه.
⏳در موضوع FP و OOP هم همین‌طوره مثلا FP از اصول OOP مثل encapsulation عملا استفاده می کنه و اونا تکمیل‌کننده‌ن همدیگن نه چیزی در تقابل!

💬 اوضاع وقتی بدتر میشه که گوینده یا نگارنده در مقام توجیح بازم بخواد موضوعات بی ربط دیگر را به مسیر گفتمان بیاره، مثلا با آوردن صفت هایی مثل over-engineering (پیچیدگی بی‌جا) یا micro-optimization (بهینه‌سازی‌های جزئی بی‌فایده) فاجعه‌ای تمام عیار رقم می خوره. کسی دانش و بینش ضعیفی داره به طور مثال نمی تونه تفاوت complicated و complex (همان‌طور که در تئوری سیستم‌ها می‌گن، پیچیدگی ذاتی نیست، بلکه از تعاملات می‌آد) را تشخیص بده و حتی ظرافت #سوال_باز بودن این حوزه ها را درک کنه و اصولا با مفهوم خود کلمه #سیستم آشنایی کافی را ندارد و حرف از سیستم (محصول) پیچیده میزنه. یا جزییات و تفاوت های ساده‌سازی واقعی (simplification) رو از ساده‌انگاری (oversimplification) تشخیص نمیده ولی با ابهام کامل قصد داره مسیر روشنی را به دیگران هدیه بده! 😉
وای به روزی که این شخص تصمیم‌گیر باشد! سازمان (جامعه، شرکت، تیم، ...) رو به مسیر اشتباه می‌بره و هیچ‌کس جرات نمی‌کنه بگه "شاه لخته!" 😅

🔗 بیاید بحث‌هامون رو بر اساس مکمل بودن و واقعیت بسازیم، نه تقابل‌های کاذب و ساختگی.
🌟 نظر شما چیه؟ 🌟
🌟 شما کدوم "VS" بی‌ربط دیگه دیدید؟ کامنت بذارید! 🌟

🔗 در پست بعد موضوع مهم و خیلی مرتبط با این حوزه یعنی #یادگیری_تطبیقی (Adaptive Learning) را کمی بیشتر مطرح می کنیم که یادمون باشه یادگیری، اصول خیلی مهمی داره و نباید دنبال مقایسه های اشتباه باشیم و هر موضوعی و هر فردی نیاز به بررسی و توسعه یکتایی داره.

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

یک چیزی که موقع حل کردن، فکر کردن به موضوعی فراموشش میکنم اینکه من ممکنه اون المان/ویژگی را از یک #سیستم کلی جدا کنم (ساده سازی می کنم). بعد اینکه متوجه اش شدم، همون مدلی که جدا کردم و ساده کردم برای یادگیری را می‌خوام که efficient کنم. یادم میره که این المان جدا و ساده شده و هر بهبودی توی این بخش باعث بهبود در کل سیستم نمیشه.

شما هم اگر از هر زاویه ای، موضوعی مرتبط با ارتقا #تفکر (قطعا انواع تفکر مثل #تفکر_سیستمی، #تفکر_انتقادی و ...) و #اندیشیدن برخورد کردید با ما به اشتراک بگذارید. مشتاقانه منتظر نقطه نظرات شما هستیم.

گاهی وقت ها #رها_کن
رها کردن، فضایی برای فرصت‌های بهتر ایجاد می‌کنه. ولی باید یادمون باشه مقاومت در برابر رها کردن، غریزه بقا (#فرگشت) است. پس نیاز به #یادگیری و تمرین کردن داریم، ولی ارزششو داره، رها کردن می‌تونه یکی از قدرتمندترین مهارت‌هایی باشه که می‌تونیم بدست بیاریم.
آژان چاه (Ajahn Chah) راهب بودایی می‌گوید: «اگر کمی رها کنی، کمی آرامش خواهی یافت. اگر زیاد رها کنی، آرامش زیادی خواهی یافت. اگر کاملاً رها کنی، آرامش و آسایش مطلق خواهی یافت.»

ویدئو پیوست، اجرای مشترک سینا ساعی و سروین ضابطیان در مرحله فینال رئالیتی شوی کارناوال با اجرای قطعه با مضمون رها کردن هست، پیشنهاد می کنم تماشا کنید و لذت ببرید.