https://virgool.io/feed/@ghrst http://www.saberynotes.com fa 2026-06-10 13:02:16 https://files.virgool.io/upload/users/18361/avatar/lso4KG.png?height=120&width=120 https://virgool.io/@ghrst https://virgool.io/@ghrst/%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D9%86%D8%A7%D9%85%D9%87-lvglriewyo67 در سالهای اخیر استفاده از اسکرام (Scrum) به عنوان روشی چابک (Agile) برای توسعه نرم‌افزار رواج زیادی یافته. من هم مثل بسیاری از توسعه‌دهندگان در تیمهای چابک متعددی حضور داشته‌‌ام و شاهد پیاده‌سازی‌ها و تفاسیر خوب، بد و زشت مختلفی از اسکرام بوده‌ام.دو سال پیش از من درخواست شد وظیفه پیاده‌سازی اسکرام را در یکی از تیمهای شرکت بر عهده بگیرم. در این دو سال منابع متعددی خواندم و با چالش‌های زیادی مواجه شدم. سعی می‌کنم در این یادداشت بخشی از تجاربی که به دست آورده‌ام و منابعی که در این راه به نظرم مفید بوده‌اند را به اشتراک بگذارم.آغازهمه چیز خیلی عادی شروع شد. مثل همه روزهای قبل با عنوان “توسعه‌دهنده/محقق تکنیکی” به شرکت رفتم. آن روز با مدیر پروژه‌ جلسه مختصری داشتم. ایشان از من خواستند به علت پاره‌ای از مشکلات و درخواست اعضای تیم به سراغ اسکرام برویم. به علاوه، پیشنهاد دادند کتاب Essential Scrum: A practical guide to the most popular agile process اثر Kenneth Rubin را برای آشنایی هر چه بیشتر با اسکرام بخوانم. مدتها قبل از این روز، کتاب Agile اثر Bertrand Meyer را خوانده بودم (که باید اعتراف کنم تا حدی کسالت آور، اما بسیار ارزشمند است). با پیش فرض کسالت آور بودن کتاب Rubin به مطالعه آن پرداختم. منبع بسیار خوبی بود و بر خلاف تصور من بسیار جذاب بود. این منبع دانش کافی برای آغاز پیاده سازی اسکرام را در اختیارم قرار داد. اما پیش از آغاز پیاده سازی سوالی برایم مطرح بود: چرا اعضای تیم درخواست استفاده از اسکرام را داده بودند؟مصاحبه و مشخص شدن روند شکست کارهابرای پاسخ به این سوال که: “چرا اعضای تیم درخواست استفاده از اسکرام را داده بودند؟”؛ مصاحبه‌ای با آنها ترتیب دادم. هر چه باشد در کارشناسی ارشد مدتی را صرف یادگیری تفکر طراحی (Design Thinking) کرده بودم (برای آشنایی بیشتر با تفکر طراحی می‌توانید به این پست وبلاگ مراجعه کنید). مهمترین پیام تفکر طراحی همدلی (Empathy) و حل مشکل واقعی کاربران یک سیستم است. در این مصاحبه نکات خوبی از مشکلات تیم به دست آوردم:افراد دوست داشتند تصویر کلی آنچه در حال اتفاق افتادن است را در اختیار داشته باشنداعضای تیم دوست داشتند با هم تعاملات بیشتری داشته باشند (تیم‌تر باشند)آنها دوست داشتند در بازه‌های زمانی مشخصی که کوتاه‌تر از چند ماه است بازخورد کارهایشان را از مشتری‌ها/ذی‌نفعان دریافت کنندافراد دوست داشتند مکانیزمی در اختیار داشته باشند تا مشکلاتشان را در بازه‌های زمانی مشخص به گوش بقیه برسانندو …نتیجه مصاحبه مرا تا حدی قانع کرد که اسکرام ممکن است بتواند بعضی از این مشکلات را حل کند.بعد از مصاحبه سراغ پیاده‌سازی اسکرام رفتم. برای آنکه مفاهیم کتاب Rubin را فراموش نکنم یک MindMap از کتاب تهیه کردم تا هر وقت با ابهامی مواجه می‌شوم به آن رجوع کنم.برای پیاده سازی اولیه لازم بود روند شکستن پروژه و چگونگی مستندسازی نیازمندی‌ها را مشخص کنم. اسکرام استاندارد مشخصی برای مستندسازی نیازمندیها ندارد. در اکثر منابع از جمله Rubin پیشنهاد شده از User Story ها بدین منظور استفاده شود. برای اینکه با User Storyها آشنا شوم به منبع دیگری مراجعه کردم: User Stories Applied اثر Mike Cohn. نویسنده در این کتاب به خوبی نحوه استفاده از User Storyها را شرح می دهد. در ادامه ساختاری چهار سطحی برای شکستن پروژه‌ها طراحی کردم. در این ساختار هر پروژه به مجموعه‌ای اپیک (Epic) می‌شکند. هر اپیک که خود یک User Story درشت‌دانه است به مجموعه‌ای Story ریزدانه‌تر شکسته می‌شود. هر Story باید به اندازه‌ای باشد که در یک اسپرینت قابل انجام است. در ادامه، هر Story برای پیاده سازی به مجموعه‌ای Task شکسته می شود.اما اپیک‌ها، استوری‌ها و تسکها را چگونه باید تخمین زد؟ برای یافتن پاسخ این سوال مجبور شدم دو منبع دیگر را هم بخوانم. یکی کتاب Agile Estimating and Planning اثر Mike Cohn و دیگری کتاب Return on Software اثر Steve Tockey. با خواندن این دو کتاب با اصول و روش‌های تخمین کارها به خوبی آشنا شدم. در ادامه، برای تخمین اپیک‌ها T-Shirt Size، استوری‌ها Story Points و تسک‌ها ساعت ایده آل را برگزیدم.باید اعتراف کنم تخمین (Estimation) کارها با این واحدها عموما فرایندی دشوار و گاها مبهم است. البته این ابهام در ذات هر تخمینی نفهته است (به علت رابطه بین دانش و احتمال). اما به نظر میرسد تعریف این واحدها و به خصوص استوری پوینت گاهی به این ابهام دامن میزند. برای مثال، کوهن در سال ۲۰۰۴ در کتاب خود میگوید بهتر است هر استوری پوینت معادل یک روز کاری ایده آل باشد (پاراگراف آخر صفحه ۸۷). در ادامه کوهن در سال ۲۰۰۵ در کتاب دیگرش روز ایده آل را به کل از استوری پوینت جدا می کند و میگوید ترجیح میدهد از استوری پوینت به عنوان معیاری برای پیچیدگی کارها استفاده کند (پاراگراف اول صفحه ۷۵). در ادامه سایر نویسنده ها مثل لفینگول تعریف متفاوت تری از استوری پوینت ارائه میدهند. برخی دیگر مثل واکانتی به کل متریک های مبتنی بر استوری پوینت را زیر سوال میبرند و …در نهایت باید بگویم در دو منبع فوق تئوری تخمین‌ زدن به میزان خوبی تشریح شده اما استفاده از آنها در عمل به طور کلی با آنچه ممکن است بیندیشید تفاوت دارد. تقابل این تئوری‌ها و عمل مرا به یاد این جمله می‌اندازد: عمل همیشه به تئوری می‌خندد (یادم نیست این سخن از کدام فیلسوف است).فلسفه اسکرام برای انجام کارهاپیش از ادامه شاید بد نباشد نگاه فلسفی اسکرام به چگونگی انجام کارها را کمی تشریح کنم. این بررسی، چرایی این همه جلسه و تخمین و … را روشن‌تر می‌کند. به طور کلی اسکرام فرض می‌کند توسعه نرم‌افزار فرآیندی غیر قابل پیش‌بینی است (بررسی میزان صحت این فرض از حوصله این یادداشت خارج است). این غیرقابل پیش‌بینی بودن باعث می‌شود آموزه‌های روش‌هایی مثل روش آبشاری (Waterfall model)، که سعی می‌کنند در ابتدای پروژه کارها را به صورت دقیق بشکنند و تخمینی برای آنها ارائه دهند، در توسعه نرم‌افزار بی‌فایده شود. در عوض اسکرام سعی می‌کند برای انجام کارها روشی مشابه الگوریتم گرادیان کاهشی (Gradient Descent) برگزیند (برای اطلاعات بیشتر درباره این الگوریتم می‌توانید به این کتاب رایگانی که درباره شبکه‌های عصبی ترجمه کرده‌ام مراجعه کنید).اجازه دهید با مثالی روش اسکرام را توضیح دهم. فرض کنید بالای تپه‌ای هستید. هوا تاریک است و فقط چند متر جلوتر را می‌بینید. می‌خواهید از تپه پایین بیایید؛ چه می‌کنید؟ هدفتان مشخص است: پایین آمدن. به علاوه، به طور کلی می‌دانید برای پایین آمدن از تپه باید به سمت سراشیبی حرکت کنید. درنتیجه، به مرور با انتخاب سراشیبی‌های اطرافتان پایین می‌آیید. در طول مسیر باید توقف‌هایی هم داشته باشید و وضعیتتان را ارزیابی کنید. شاید مسیر را اشتباه آمده‌اید و مجبور شوید برگردید و تغییر مسیر دهید.اسکرام هم دقیقا از همین روش بهره می‌برد: پروژه‌ای با چشم‌انداز (هدف) مشخص داریم؛ این چشم انداز را به مجموعه‌ای نیازمندی درشت دانه (برای مثال اپیک) تقسیم می‌کنیم. با افزایش دانشمان از پروژه و با اولویت بندی کارها طبق نیازهای مشتری این نیازمندیهای درشت دانه را به نیازمندیهای ساده تر می‌شکنیم. هر اسپرینت بخشی از این نیازمندیهای ریزدانه را انجام می‌دهیم (قدمهای کوچک در جهت سراشیبی یا رسیدن به هدف). سپس بررسی می‌کنیم آیا در جهت درستی در حال حرکت هستیم یا خیر؟ در صورت لزوم تغییر مسیر می‌دهیم (ارزیابی وضعیت). هر یک از این مراحل را می‌توان به یکی از رویدادهای اسکرام نگاشت کرد.البته تئوری‌ها و مطالعات فراوانی پشت این روش ساده نهفته است. برای اطلاعات بیشتر در این باره می‌توانید از این پست وبلاگ شروع کنید.توجه داشته باشید اسکرام برای هر پروژه‌ای مناسب نیست. برای اطلاعات بیشتر می‌توانید به کتاب Rubin و منابع مربوط به چهارچوب Cynefin مراجعه کنید. هرچند گاهی منابع مربوط به چهارچوب Cynefin هم آنقدر شفاف نیستند …جلسات اسکرام و چالشهای آنهاطبق آنچه در منابع مختلف خواندم‌ اسکرام چند جلسه اصلی دارد:جلسات پلنینگ (Planning): هدف این جلسات برنامه ریزی برای کارهایی است که در طول اسپرینت انجام می‌شودجلسات روزانه (Daily): هر روز جلسه‌ای با عنوان Daily Standup برگزار می‌شود. در این جلسات اعضای تیم درباره کارهایی که باید در آن روز انجام شود با هم هماهنگ می‌شوندجلسات بازبینی (Review): در انتهای هر اسپرینت یک جلسه بازبینی برگزار می‌شود. در این جلسات کارهای انجام شده در طول اسپرینت برای ذی‌نفعان اصطلاحا دمو می‌شود و تیم توسعه بازخوردهای مربوطه را دریافت می‌کند. به علاوه، اگر نیازی به تغییر جهت انجام کارها باشد در این جلسات بحث و گفتگویی شکل می‌گیردجلسات رترو (Retrospective): در انتهای هر اسپرینت یک جلسه رترو برگزار می‌شود. در طول این جلسه اعضای تیم به بررسی اسپرینت قبل و مشکلاتی که حین انجام کارها با آن مواجه شدند می‌پردازند و سعی می‌کنند راهکارهایی برای حل برخی از این مشکلات در اسپرینت‌های آینده بیابند. در نتیجه، جلسات رترو مکانیزمی برای اصلاح فرآیند انجام کارها در اختیار اعضای تیم قرار می‌دهدتوجه داشته باشید که اسکرام دو مکانیزم اصلاح دارد: یکی برای بهینه سازی و اصلاح خروجی کار (جلسات بازبینی) و دیگری برای بهینه‌سازی فرآیند رسیدن به هدف.توضیحات فوق را در هر کتاب یا منبع اسکرامی میتوانید بیابید. اما چیزی که در اکثر این منابع به درستی مشخص نیست نحوه اجرای این جلسات است! برای مثال، ممکن است ایده برگزاری جلسات روزانه به نظر جذاب بیاید. اما وقتی سعی می‌کنید افراد را گرد هم آورید با مشکلات متعددی در این باب مواجه خواهید شد (به خصوص در دورکاری). در این باره هر کسی نظری دارد و نظر هیچ کس هم وحی منزل نیست. به طور کلی می توانید جلسات روزانه را به سه روش برگزار کنید:همگام و حضوری: همه در یک ساعت مشخص به صورت حضوری در مکانی مشخص برای برگزاری جلسه حاضر می‌شوندهمگام و آنلاین: همه در یک ساعت مشخص در یک ابزار چت صوتی/تصویری برای برگزاری جلسات حاضر می‌شوندناهمگام: در این روش همه در یک ساعت مشخص برای جلسه حاضر نمی‌شوند. بلکه هر کسی در ساعت متفاوتی مطالب خویش را در یک سیستم چت می‌نویسدبرای اطلاعات بیشتر درباره روش‌های همگام و غیرهمگام می‌توانید به این مقاله مراجعه کنید.برگزاری جلسات پلنینگ و بازبینی هم چالش‌هایی دارد (ممکن است در آینده در یک پست جداگانه به آنها بپردازم). اما، برگزاری آنها آنقدرها هم دشوار نیست. در این میان، گنگ ترین جلسه،  جلسه رترو است. هیچ یک از منابعی که خواندم به درستی به بررسی ساختار این جلسات نمی‌پردازند. به علاوه، طبق آنچه فهمیده بودم این جلسه اهمیت زیادی داشت. در نتیجه، کتاب Agile Retrospectives اثر Derby و سایرین را خواندم. با خواندن این کتاب با ساختار جلسات رترو به خوبی آشنا شدم و توانستم فرآیند آن را درک کنم.تئوری و عملتا اینجا منابع بسیاری خوانده بودم و می‌توانستم با آنچه می‌دانم اسکرام را به خوبی پیاده‌سازی کنم. در نتیجه، کار را شروع کردم و شدم اسکرام مستر تیم. در پیاده سازی و اجرای فرآیند مشکل خاصی نداشتم اما با شروع کار متوجه خلاء بزرگی در دانش خود شدم که در هیچ یک از منابع (به جز کتاب Derby و سایرین درباره جلسات رترو) به آن اشاره‌ای نشده است: نحوه تعامل با افراد بدرفتار! سخت ترین و حساس ترین قسمت کار هم همین جاست.اسکرام اولین تجربه مدیریتی من نبود اما تعریف نقش اسکرام مستر و اختیارات آن تفاوت محسوسی با نقشی مثل مدیر فنی دارد. در نتیجه، ساختار و پویایی قدرت در اسکرام بسیار متفاوت است. به علاوه، اسکرام تاکید زیادی بر تیم دارد. تیم نسبت به استرس و بدرفتاری موجودی بسیار حساس است. در نتیجه، تصمیماتی که درباره برخورد با افراد بدرفتار می‌گیرید ممکن است در اسکرام عواقب متفاوتی داشته باشد …متاسفانه در ادبیات اسکرام راهکار خاصی برای تعامل با “افراد بدرفتار” وجود ندارد. اسکرام فرض می‌کند همه اعضای تیم مطیع هستند و کاری بر خلاف هدف تیم، و سازمان انجام نمی‌دهند. در اندک مواردی که اشاره‌ای به نحوه تعامل با افراد بدرفتار شده است هم راهکار به سیب گندیده (Bad Apple) خواندن آنها، تذکر و نهایتا اخراجشان ختم می‌شود. برای مدتی این سوالات ذهن مرا به شدت مشغول کرده بود:با افراد بدرفتار چه باید کرد؟آیا تنها راهکار طرد فرد از گروه و سازمان است؟ اگر چنین نیست تا چه مدت باید با افراد بدرفتار مدارا کرد؟آیا چنین تصمیمی (که مسلما خارج از وظایف اسکرام مستر است اما وی هم در آن نقش دارد) اخلاقی است؟پس کسانی که نمی‌توانند در چهارچوبی مثل اسکرام کار کنند چه؟برای پاسخ این سوالات به فیلدهای مطالعاتی متعددی از جمله فلسفه اخلاق، نظریه تصمیم‌ (Decision Theory) و روان شناسی مراجعه کردم. البته از قبل هم در برخی از این زمینه‌ها مطالعات قابل توجهی داشتم. این سوالات مرا بر آن داشت به طور خاص در این منابع دنبال پاسخ باشم. برخی از کتبی که در این راستا خواندم عبارتند از کتاب Exploring Ethics اثر Steven Cahn، برخی از کتب اروین یالوم و کتاب An introduction to decision theory اثر Martin Peterson. مسلما خواندن این کتب خالی از لطف نبودند اما پاسخ خاصی هم در اختیارم قرار ندادند.گاهی به عنوان اسکرام مستر باید تصمیماتی بگیرید که صورت آنها بی شباهت به مسئله تراموا (Trolley Problem) نیست. در این میان نظریه تصمیم هم کمک زیادی نمی‌کند زیرا عقلانیت (Rationality) یک تصمیم در موقعیتی خاص به هدفتان بستگی دارد (به این ویژگی اصطلاحا Instrumental Rationality می‌گویند). طبق تعاریف اقتصادی هدف کارکنان یک سازمان باید در راستای اهداف آن سازمان یعنی رسیدن به ماکزیمم سود (و کاهش هزینه) باشد. در نتیجه، ممکن است طبق هدف سازمان و تحلیل‌های نظریه تصمیم به نتیجه‌ای برسید که در راستای هدف سازمان عقلانی است اما اخلاقی نیست و شما را راضی نمی‌کند…در نهایت باید بگویم (با دانش فعلی‌ام) عموما مسائل انسانی راه حل ریاضی ندارند و همان طور که در این پست به صورت مفصل شرح داده ام راه حلهای این مسائل همه را راضی نخواهد کرد.نقاط ضعف اسکراماسکرام نقاط ضعف متعددی دارد. این نقاط ضعف بدین معنی نیستند که اسکرام فرآیند بدی است. هر ابزاری مزایا و معایبی دارد. در ادامه برخی از آنها را آورده‌ام:این روش فرض می‌کند افراد به کار تیمی علاقه دارند (طبق مشاهدات من خیلی وقتها چنین نیست!)در اسکرام فرض شده شما تیمی از افراد متخصص دارید. پیدا کردن متخصص در حال حاضر در کشورهای پیشرفته هم با چالش‌هایی رو به رو استادبیات اجایل گاها ضد و نقیض است و شواهد درستی برای ادعاهایش ندارد. این نکته را برتراند میر به بهترین شکل ممکن در نقد خود از این روش ها در کتابش بیان کرده. پیشنهاد می کنم حتما این کتاب را بخوانیداساسی ترین نقطه ضعف اسکرام از نظر من خود تیم است. تیم ماهیتی بسیار شکننده دارد. حتی تاکمن (Tuckman) هم در مقاله خود به این مسئله اشاراتی داردنگاه اسکرام به برنامه‌نویس‌ها در نهایت به یک دیدگاه تیلوریستی منتهی خواهد شد (به خصوص با تجمیع روشهایی مثل تفکر طراحی با اسکرام). شرح کامل این مشکل را می‌توانید در این مقاله بخوانیدجلسات متعدد اسکرام عموما برای افراد خسته‌کننده است (هرچند برگزاری این جلسات لازم است)برای استفاده از اسکرام نیاز به آموزش نسبتا طولانی به افراد تیم وجود دارداز نظر من فرض تعهد اعضای تیم به انجام کارها در موقعیت‌های زیادی قابل قبول نیستروش‌های اجایل مجموعه‌ای Technical Practice دارند که اگر به درستی در کدنویسی استفاده نشوند خروجی‌های عجیب و غریبی به شما خواهند داد. یادگیری این Technical Practiceها توسط اعضای تیم زمان‌بر استبرای پیاده‌سازی اسکرام منبع جامعی وجود ندارد و باید اطلاعات لازم را مانند تکه‌های یک پازل از منابع مختلف و پراکنده‌ گرد هم آورید (هرچند بعضی این را نقطه قوت اسکرام می‌دانند)رعایت نظم در اسکرام اهمیت بسیار زیادی دارد. بی‌نظمی یکی از اعضا می‌تواند ضربات قابل توجهی به فرآیند وارد آورداسکرام کسانی که روحیه کار تیمی ندارند را به کلی کنار میگذاردنقض هر یک از این مفروضات شما را با مشکلات متعددی مواجه خواهد ساخت…نتیجه‌گیریدر نهایت باید بگویم اسکرام چاره همه مشکلات نیست. اما راه حل‌های معقولی برای برخی از آنها فراهم می‌آورد. هرچند این راه حل ها هزینه‌هایی هم دارند. برای استفاده از این روش باید صبور و مشتاق به یادگیری باشید. باید بیش از هر حسی، حس همدلی با اعضای تیمتان را تقویت کنید. چون تنها راه کنار هم ماندن در روزهای سخت همین حس همدلی و همدوستی است.در نهایت امیدوارم این یادداشت برایتان مفید باشد.برای آگاهی از پست های بعدی می توانید در کانال تلگرام وبلاگ عضو شوید.برای عضویت در کانال وبلاگ اینجا کلیک کنید غلامرضا صابری تبریزی غلامرضا صابری تبریزی Wed, 02 Mar 2022 20:46:28 +0330 https://virgool.io/@ghrst/%D9%85%D8%B3%D8%A6%D9%88%D9%84%DB%8C%D8%AA-%D9%BE%D8%B0%DB%8C%D8%B1%DB%8C-qzkuso0j3ody اخیرا کتابی خواندم به نام The Great ScrumMaster اثر Zuzana Sochova. نویسنده در این کتاب مدلی از مسئولیت پذیری ارائه کرده بود که به نظرم جالب آمد. ترجمه مختصری از این مدل را در ادامه آورده ام.ذهن انسان به خاطر نحوه تکاملش سعی می کند به سریع ترین شکل ممکن تصمیم بگیرد. هر وقت اتفاقی می افتد، ذهن گزینه ای برای چگونگی مواجهه با آن اتفاق در اختیارمان قرار می دهد. برای مثال، تصور کنید می خواهید ماشینتان را در یک پارکینگ طبقاتی شلوغ پارک کنید. حین پارک کردن با یکی از ماشین ها برخورد می کنید. در این حالت ذهنتان سعی می کند برای مواجهه با این اتفاق گزینه هایی در اختیارتان قرار دهد. این گزینه ها به ترتیب عبارتند از:نادیده گرفتن (Denial): ساده ترین گزینه نادیده گرفتن اتفاقی است که افتاده. اصلا به ماشین کناری خوردم؟ من که رد هیچ خط و خشی نمی بینم. آثار موجود روی بدنه ماشین دیگر هم به خاطر کثیف بودن آن است و با کارواش رفتن برطرف خواهند شد. اما صدا از کجا آمد؟ صدای خرد شدن سنگ های پارکینگ بوددنبال مقصر گشتن (Laying blame): اگر با نادیده گرفتن اتفاقی که افتاده راحت نباشید ذهنتان گزینه دیگری پیشنهاد می دهد. ناگهان در کسری از ثانیه، ذهن دنبال مقصر می گردد: اینکه به ماشین کناری خوردم مشکل راننده آن ماشین است. اگر به درستی پارک کرده بود چنین نمی شد!توجیه کردن (Justify): اگر با دنبال مقصر گشتن هم راضی نشوید ذهنتان گزینه دیگری پیشنهاد می دهد. کارتان را توجیه می کند: همه گاه و بی گاه تصادف می کنند؛ نه؟ تازه پارک کردن در پارکینگ های طبقاتی شلوغ هم سخت است.شرمندگی (Shame): گزینه بعدی شرمنده شدن است. این تصادف تقصیر من است. من هیچ وقت یاد نگرفتم در پارکینگ های طبقاتی شلوغ پارک کنم. شرمنده ام!وظیفه (Obligation): گزینه بعدی مواجهه با مشکل به گونه ایست که نشان دهد انجام یک کار خاص وظیفه شما است. شماره تلفنم را روی یک تکه کاغذ نوشتم و پشت برف پاک کن ماشینی که به آن زدم گذاشتم. در نهایت بیمه خسارتم را جبران خواهد کرد.بی خیال شدن (Quit): هر وقت بخواهید می توانید بی خیال همه چیز شوید.مسئولیت پذیری (Responsibility): این گزینه آخری است که ذهنتان در اختیار شما قرار می دهد. برای مسئولیت پذیری باید از خودتان بپرسید «دفعه بعد باید چه کار کنم تا این اتفاق نیفتد؟». در مثال پارک کردن ماشین پاسخ این سوال می تواند پارک کردن در یک جای خلوت تر، نصب سنسور پارک روی ماشین و غیره باشد.استفاده از گزینه های مختلف این مدل را در خودم و دیگران بارها دیده ام. امیدوارم با آگاهی از این مدل بتوانیم در مواجهه با مشکلات بهتر تصمیم بگیریم. غلامرضا صابری تبریزی غلامرضا صابری تبریزی Thu, 15 Apr 2021 09:17:53 +0430 https://virgool.io/@ghrst/%D8%AA%DB%8C%D9%85-%D9%87%D8%A7%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-%D9%88-%D8%B3%D9%88%DA%AF%DB%8C%D8%B1%DB%8C-%D9%87%D8%A7%DB%8C-%D8%B1%D9%88%D8%A7%D9%86%DB%8C-%D8%A2%D9%86%D9%87%D8%A7-ev341sm8gbfb Wikipediaچند وقت پیش در مدیم (Medium) مطلبی با عنوان «Software teams, and their psychological biases» نوشتم. در آن مطلب سعی کرده بودم نتایج مطالعات و مشاهداتی که طی سالها کار در صنعت نرم افزار درباره سوگیری های (Bias) روانی تیم ها با اونها مواجه شده بودم رو خلاصه کنم. از همان موقع میخواستم ترجمه فارسی این مطلب رو هم بنویسم. امروز فرصتی شد برای نوشتن این پست.طی سالهای زیادی (حدودا ۱۰ سال) که به عنوان مهندس نرم افزار کار کردم، با تیم های زیادی برخورد داشتم. بعضی از این تیم ها از روش های اجایل (چابک)، و بعضی هم از روش های قدیمی تر مثل مدل آبشاری، RUP، و غیره برای توسعه نرم افزار استفاده می کردن. اما گاهی صرفنظر از مدل توسعه، کار تیمی خودش تبدیل به چالش میشه. عموما به خاطر اینکه رفتار افراد وقتی به صورت تیمی کار می کنند با حالت فردی متفاوته. برای مثال:جلسه های بسیاری دیدم که منجر به تصمیم احمقانه ای شدن و همه (به جز یکی دو نفر) از اون تصمیم خوشحال بودن!تیم های زیادی رو دیدم که تعداد زیادی از اعضای اون هیچ کاری نمی کنن، و تمام فشار کار روی تعداد محدودیه و در لایه مدیریت هم کسی عکس العملی نشون نمیده!اما چرا؟ برای پیدا کردن جواب به منابع مختلفی مراجعه کردم و حتی چند تا دوره آنلاین گذروندم (لیست منابع رو می تونین آخر مطلب مشاهده کنید). در ادامه این مقاله سعی می کنم مطالبی که مطالعه کردم رو به طور خلاصه بیان کنم و تا حد ممکن به سوالات زیر پاسخ بدم:گروه (تیم) چیست؟چه زمانی یک گروه (تیم) شکل میگیره؟فرنودآوری کوشش (Effort Justification) چیست، و چطور بر مصاحبه های کاری تاثیر میزاره؟اثر مالکیت (Endowment effect) چیست و چگونه بر تیم تاثیر می گذارد؟آیا هوش یک تیم بیشتر از هوش یک فرد است؟گروه زدگی (Groupthink) چیست و چگونه بر تیم اثر می گذارد؟آیا گروه ها مسئولیت پذیرتر از افراد هستند؟آیا افراد وقتی عضوی از یک گروه می شوند ریسک بیشتری قبول می کنند؟آیا همه اعضای تیم تمام توان خود را برای انجام کار به صورت یکسان به کار می گیرند؟توجه: وجود این سوگیری های روانی به معنای بد بودن کار تیمی نیست. وجود این سوگیری ها یعنی کار تیمی ظرافت ها، و ویژگی هایی دارد که ما باید به عنوان اعضای تیم از آنها آگاه باشیم و آنها را مد نظر قرار بدیم. راهکارهایی برای فیصله (برای معنای دقیق فیصله به این پست مراجعه کنید) به همه این سوگیری ها وجود دارند. شما باید بر اساس شرایط خودتان بهترین راهکار را انتخاب کنید.برای بررسی روان شناسی گروهی (Group Psychology) کارم رو با خواندن کتاب «روان شناسی گروهی و تحلیل اگو» اثر زیگموند فروید (Sigmund Freud) آغاز کردم. در این کتاب فروید روان شناسی گروهی را به صورت زیر تعریف کرده است:روان شناسی گروهی با انسان به عنوان عضوی از یک نژاد، ملت، حرفه، سازمان، یا عضوی از یک توده از افراد، که در قالب یک گروه در زمانی مشخص، و برای هدفی مشخص سازمان یافته اند سر و کار دارداما از منظر فروید چه شرط ( یا شروطی) باید برای تشکیل یک گروه برآورده شوند؟پیش از اینکه توده ای تصادفی از افراد بتوانند گروهی (به معنای روان شناختی گروه) را تشکیل دهند شرطی باید برآورده شود. این افراد باید باهم یک نقطه مشترک داشته باشند. این نقطه مشترک، می تواند علاقه به یک شیء، یک سوگیری احساسی مشترک در موقعیتی خاص، یا موارد این چنینی باشد. این نقطه مشترک باید به گونه ای باشد که افراد علاقه مند شوند به صورت متقابل بر امری تاثیر بگذارند. هرچقدر این «همگرایی ذهنی» بیشتر باشد امکان شکل گیری یک گروه روانی، و ظهور ذهنیت گروهی بیشتر استحال فرض کنید یک تیم نرم افزاری داریم (یک گروه). این گروه یک علاقه مشترک دارد. این علاقه مشترک، تولید یک محصول نرم افزاری و به دست آوردن پول است. چه اتفاقی می افتد؟ از نظر من یکی از اولین کارهایی که این تیم انجام می دهد وضع مجموعه ای قانون برای عضویت در تیم است. سوگیری روانی مهمی می تواند در این نقطه شکل بگیرد. عموما وقتی می خواهیم عضو تیم (گروهی) شویم با فرنودآوری کوشش (Effort Justification) مواجه خواهیم شد. در کتاب «The art of thinking clearly» رولف دوبلی (Rolf Dobelli) فرنودآوری کوشش را چنین تعریف می کند:گروه ها از فرنودآوری کوشش برای پایبند کردن اعضای گروه استفاده می کنند - برای مثال آیین های پاگشایی. گروه های گنگستری، و انجمن های برادری برای پذیرش افراد از تست ها و کارهای وحشتناکی استفاده می کنند. تحقیقات نشان می دهند هر چقدر این «آزمون های ورودی» سخت تر باشند غرور افراد از عضویت در گروه بیشتر خواهد بود، و آنها برای عضویتشان در گروه ارزش بیشتری قائل می شوند.به نظر من در تیم های نرم افزاری این فرنودآوری کوشش خود را در قالب مصاحبه های عجیب و غریب نشان می دهد (البته این تنها هدف مصاحبه نیست). بارها دیده، و شنیده ام «فلان شرکت سوال های مصاحبه خیلی سختی دارد»؛ اما پس از ورود به شرکت افراد داستان هایی از بی نظمی های عجیب و غریب در این شرکتها تعریف می کنند! شاید این فرنودآوری کوشش دلیل افتخار بعضی افراد به تیم هایی است که عضو آن هستند. با وجود اینکه این تیم ها تفاوت چندانی با  سایر تیم های نرم افزاری ندارند. البته به نظر من این «افتخار عضویت» به اثر دیگری به نام «اثر مالکیت» (Endowment effect) هم مربوط می شود. در نهایت از نظر من دانش هم یک توزیع پارتو (Pareto distribution) دارد. در نتیجه اکثر تیم ها از نظر توانایی و دانش فنی در یک سطح قرار دارند.اما درباره هوش گروه چه می توان گفت؟ آیا گروه ها باهوش تر از افراد هستند؟ در این باره فروید می گوید:هوش یک گروه بسیار کمتر از هوش فرد است. اما، استانداردهای اخلاقی یک گروه می تواند بسیار بالاتر، یا پایین تر از فرد باشدبرای درک بهتر علت کم بودن هوش گروه، یک شبکه کامپیوتری را در نظر بگیرید. سرعت ارتباط این کامپیوترها، برابر با سرعت کندترین کامپیوتر است. می توان از قیاس مشابهی برای هوش گروهی هم استفاده کرد. البته در گروه ها مسائل روان شناختی بسیار دیگری هم درگیر هستند که منجر به کم شدن هوش گروه می شوند. یکی از شناخته شده ترین آنها گروه زدگی (Groupthink) است. منابع بسیاری به بررسی گروه زده گی می پردازند. تعریف زیر مربوط به ویکی پدیا است:گروه زدگی یک پدیده روان شناختی است. در گروه زدگی، تمایل اعضای گروه به هارمونی، و «عضوی از گروه ماندن» موجب تصمیمات غیرمنطقی و ناکارآمد می شود. انسجام گروه، یا تمایل افراد برای انسجام گروه ممکن است باعث شود افراد به هر قیمتی با تصمیمات گروه موافقت کنندگروه زدگی خود به پدیده عام تری به نام Social Proof مربوط می شود.اما آیا مسئولیت پذیری گروه ها بیشتر از افراد است؟ در پاسخ باید به پدیده ای به نام پخش مسئولیت (Diffusion of responsibility) مراجعه کنیم:در گروه ها افراد از مسئولیت پذیری شانه خالی می کنند. هیچ کس مسئولیت تصمیمات غلط گروه و نتایج آن را نمی پذیرد.یکی از مثال های بسیار خوبی که به صورت دسته اول در باره «پخش مسئولیت» با آن درگیر بودم اعضای یک تیم مانیتورینگ بود. در این تیم، همه اعضا برای گزارش دهی از یک حساب کاربری استفاده می کردند که شناسایی آنها را در قالب فرد غیرممکن می کرد. در نتیجه، این تیم می توانست در قالب یک ماهیت شکست ناپذیر و ناشناس، بارها گزارش های اشتباه بدهد و مسئولیتی درقبال آنها قبول نکند و بهبودی در عملکرد خود ندهد. برای اطلاعات بیشتر درباره این احساس شکست ناپذیری گروهی می توانید در قسمت منابع به کتاب فروید مراجعه کنید.آیا گروه ها ریسک پذیرتر از افراد هستند؟ در پاسخ به این سوال باید به اثری به نام Risky shift مراجعه کنیم:طی Risky shift اعضای یک گروه برسر تصمیمی که ریسکی از تر تصمیماتی است که افراد به تنهایی اتخاذ می کنند به توافق می رسنداین اثر را می توان ترکیب چند اثر دیگر مثل پخش مسئولیت هم در نظر گرفت. این اثر می تواند نتایج فاجعه باری به همراه داشته باشد.اما آیا اعضای یک تیم همه توانایی و تلاش خود را برای رسیدن به هدف صرف می کنند؟ پاسخ کوتاه خیر است! به این ویژگی اصطلاحا «طفره رفتن اجتماعی» (Social loafing) می گویند:در روان شناسی اجتماعی «طفره رفتن اجتماعی» پدیده ای است که طی آن فرد وقتی عضو یک گروه است تلاش کمتری برای دستیابی به هدف انجام می دهد. این پدیده یکی از دلایل پایین تر بودن بهره وری گروه ها نسبت به بهره وری ترکیبی تک تک اعضای آن ها استدر نهایت، باید بگویم سوگیری های روانی بسیاری کار تیمی را تحت تاثیر قرار می دهند. ما باید به عنوان اعضای یک تیم از این سوگیری ها آگاه باشیم و برای کمتر کردن اثر آنها تلاش کنیم. خوشبختانه روش های بسیاری برای کاهش این آثار وجود دارد. امیدوارم این مطلب مورد استفاده قرار بگیره.منابعکتاب Group Psychology and Analysis of Ego اثر زیگموند فروید (این کتاب به فارسی ترجمه شده است)کتاب The Art of Thinking Clearly اثر رولف دوبلی (این کتاب هم به فارسی ترجمه شده است)دوره آموزشی آنلاین The science of everyday thinking سایت Edxمقاله Dilemmas in a general theory of planning اثر هورست ریتل (قبلا در باره این مقاله پست مفصلی اینجا نوشته ام)دوره آموزشی Design Thinking وب سایت IDF. درباره Design Thinking هم قبلا مطلبی اینجا نوشته امکتاب Agile! The Good, the Hype and the Ugly اثر برتراند میروبسایت Wikipedia غلامرضا صابری تبریزی غلامرضا صابری تبریزی Sat, 29 Aug 2020 16:12:47 +0430 https://virgool.io/@ghrst/%D9%88%D8%B6%D8%B9%DB%8C%D8%AA-%D9%85%D9%87%D8%A7%D8%AC%D8%B1%D8%AA-%D8%AF%D8%B1-%D8%AF%D8%A7%D8%AF%D9%87-%D9%87%D8%A7%DB%8C-%D9%86%D8%B8%D8%B1%D8%B3%D9%86%D8%AC%DB%8C-%D8%AC%D8%A7%D8%AF%DB%8C-zmchdb3xxosd چند وقت پیش، موقع برگشت از شرکت با یکی از همکاران گفتگویی داشتیم. ایشان درباره داده های نظرسنجی جادی که هر سال به صورت آنلاین و در قالب یک پرسشنامه برگزار می شود اطلاعاتی به من دادند. این اطلاعات، با آنچه از سایر منابع می دانستم در تضاد بود. از این رو سعی کردم داده های این پرسشنامه را تحلیل کنم. بخشی از نتایج این تحلیل که در بررسی های مشابه مثل «بهداد بلاگ»، یا «تحلیل وبسایت جادی» موجود نبود مربوط به نرخ مهاجرت است. در ادامه تحلیل خود در این رابطه را به صورت مجموعه ای پرسش و پاسخ آورده ام.۱. برای تحلیل از چه داده هایی استفاده شده است؟ برای تحلیل از داده های سال ۹۷ استفاده کرده ام که با استفاده از این آدرس می توانید آنها را دانلود کنید۲. داده های مورد استفاده در تحلیل چند متغیر (ستون) و چند مشاهده (سطر) دارند؟ داده های مورد استفاده در تحلیل ۴۱ ستون (متغیر) و ۴۴۸۴ سطر دارند (بدون احتساب سطر مربوط به سرآیند). تعداد مشاهده های موجود در این فایل با «بلاگ بهداد» برابر است. اما در «تحلیل وبسایت جادی» این عدد ۲۹۵۷ ذکر شده (این ناسازگاری باید توسط منبع ارائه دهنده داده ها که وبسایت جادی است بررسی شود)۳. آیا این داده ها سوگیری، یا بایاس (Bias) خاصی دارند؟ بله. مهمترین این سوگیری ها، اصطلاحا سوگیری در نمونه برداری (Sampling bias) نام دارد. یعنی برخی از افراد جامعه مقصد درصد مشارکت کمتری نسبت به جامعه واقعی دارند. از آنجا که جامعه آماری شرکت کننده گان در این پرسشنامه اکثرا از کاربران توییتر و خواننده گان وبلاگ جادی هستند، دچار یک سوگیری در نمونه گیری هستند. البته این سوگیری در تحقیقات مربوط به علوم اجتماعی بسیار رایج است۴. سوگیری های موجود در داده ها چگونه خود را نشان می دهند؟ برای مثال از میان ۴۴۸۴ شرکت کننده تنها ۴۱۴ نفر از شرکت کننده گان (۹.۲۳٪) را خانم ها تشکیل می دهند. به علاوه اکثر شرکت کننده گان نسبتا کم سن و سال هستند.۵. از هر شهر چند شرکت کننده وجود دارد؟ داده های مربوط به این قسمت با استفاده از فیلد «خودتون رو متعلق به کدوم استان می دونید؟» به دست آمده اند.۶. شرکت کننده گان در کدام شهرها کار می کنند؟ نمودار زیر با استفاده از اطلاعات مربوط به فیلد «استان محل کار» رسم شده است۷. مبداء و مقصد مهاجرت برنامه نویسان ایرانی چه شهرهایی است؟ در زمان مشاهده گراف زیر این موارد را مد نظر قرار دهید (برای بزرگ کردن تصویر روی آن کلیک کنید):در گراف زیر اگر تعداد مهاجران از یک شهر به شهر دیگر بزرگتر یا مساوی ۲۰ نفر بوده باشد یک یال بین دو شهر رسم شده است. در نتیجه مهاجرت های کوچکتر رسم نشده اندشهر مقصد با نوک پیکان مشخص شده استتعداد مهاجران روی هر یال نوشته شده استحلقه (یالی از یک شهر به همان شهر نشان دهنده یکسان بودن مبداء و مقصد ذکر شده در پرسشنامه، یا عدم مهاجرت است)گراف مهاجرتاطلاعات بسیار جالبی در این گراف قابل مشاهده است:تقریبا می توان گفت مقصد نهایی تمامی مهاجرت های داخلی تهران است. البته اگر در شهرهای بزرگی چون اصفهان، یا خراسان رضوی باشید محتملا به تهران مهاجرت نخواهید کرد. اما، اگر در سایر شهرها باشید وضعیت متفاوت خواهد بوداگر ساکن تهران باشید و قصد مهاجرت داشته باشید تنها مقصدتان کشورهای خارجی، یا دورکاری استبرخی شهر ها هم هستند که مهاجرتی زیر ۲۰ نفر دارند، اما تعداد شرکت کننده گان آنها بزرگتر یا مساوی ۲۰ است. این شهرها در پایین گراف در قالب مجموعه ای جدا افتاده (Isolates) نشان داده شده اندآنچه در این داده ها دیده می شود ناخوشایند است. خوب بود اگر برنامه نویسان و کارکنان آی تی مقصدی به جز تهران در مهاجرت های داخلی داشتند…۸. در داده های موجود به طور کلی احتمال مهاجرت چقدر است؟ به طور کلی، اگر کسانی که شهر مبداء آنها مخالف شهر محل کارشان است را مهاجر فرض کنیم، و تعداد آنها را به تعداد کل شرکت کننده گان تقسیم کنیم به عدد ۰.۲۸۲ خواهیم رسید. به عبارت دیگر افراد به احتمال ۲۸ درصد برای کار مهاجرت می کنند.۹. احتمال مهاجرت از هر شهر چقدر است؟ احتمال مهاجرت از شهرهایی که بیش از ۲۰ مهاجر داشته اند در جدول زیر آمده است:احتمال مهاجرتهمان طور که در جدول فوق هم قابل مشاهده است احتمال مهاجرت از شهرهای بزرگ مثل خراسان و اصفهان به تهران یا از تهران به خارج کشور (یا دورکاری) نسبتا اندک است.البته می توان رابطه بین داده های مربوط به مهاجرت برنامه نویسان را با بسیاری از متغیرهای دیگر موجود در پرسشنامه بررسی کرد. برای مثال:آیا سن رابطه ای با مهاجرت دارد؟آیا رابطه ای میان میزان تخصص و مهاجرت وجود دارد؟جنسیت در تصمیم بر مهاجرت تاثیری دارد؟و بسیاری موارد دیگر. متاسفانه به خاطر سوگیری داده ها نمی توان برخی از این سوال ها را پاسخ داد. برای مثال به علت پایین بودن تعداد خانم ها نمی توان به سوال رابطه بین جنسیت و مهاجرت پاسخ داد. پاسخ به سایر سوالات هم به علت قالب داده ها با دشواری هایی همراه است که به زمان زیادی نیاز دارد.در انتها امیدوارم این تحلیل با همه کاستی هایش مفید واقع شود، و برای برخی سوالات موجود پاسخ مناسبی ارائه دهد.برای آگاهی از پست های بعدی می توانید در کانال تلگرام وبلاگ عضو شوید.برای عضویت در کانال وبلاگ اینجا کلیک کنید غلامرضا صابری تبریزی غلامرضا صابری تبریزی Wed, 24 Jun 2020 22:56:45 +0430 https://virgool.io/enline/%D8%B1%DB%8C%D8%A7%D8%B6%DB%8C%D8%A7%D8%AA-%D8%AA%D8%B4%D8%AE%DB%8C%D8%B5-%D9%85%D9%82%D8%AF%D9%85%D9%87-%D8%A7%DB%8C-%D8%A8%D8%B1-%D9%82%D8%A7%D9%86%D9%88%D9%86-%D8%A8%DB%8C%D8%B2-b0cqik1qy932 فرض کنید پزشک هستید، و بیماری با مجموعه ای از عوارض(Symptoms) نزد شما می آید. برای مثال، فرض کنید صورت بیمار پر از لکه های قرمز کوچک است. از آنجه که شما پزشک هستید می دانید دو بیماری هستند که می توانند موجب بروز چنین لکه هایی شوند:آبله (Smallpox): بیماری بسیار خطرناک که می تواند به راحتی بیمار را از پا در آورد، و به راحتی درمان نمی شودآبله مرغان (Chickenpox): بیماری که آنقدر خطرناک نیست و به راحتی درمان می شوداما چطور می توانید با استفاده از عوارض تشخیص دهید بیمار به کدام بیماری دچار است؟ از آنجاکه پزشک هستید می دانید احتمال بروز این عوارض به شرط آبله ۰.۹۹ و احتمال بروز عوارض به شرط آبله مرغان ۰.۸ است. در نتیجه، آیا تشخیص شما باید آبله باشد؟ می توانید اطلاعات فوق را به صورت زیر به زبان ریاضیات نشان دهید:در عبارات فوق علامت | به معنای «به شرط»، و p به معنای احتمال است. در نتیجه، (آبله | جوش های قرمز)p خوانده می شود «احتمال جوش های قرمز به شرط اینکه بیمار مبتلا به آبله باشد». اما اگر با استفاده از اطلاعات فوق نتیجه بگیریم بیمار مبتلا به آبله است تشخیص درستی داده ایم؟ پاسخ این سوال خیر است. در این محاسبات پارامتر بسیار مهمی وجود دارد که مد نظر قرار نگرفته است. این پارامتر تجربه قبلی ما در رابطه با میزان شیوع این بیماری ها در جامعه است. در واقع بیماری آبله بسیار نادر، و بیماری آبله مرغان بسیار رایج است. می توانیم این تجربه را با استفاده از یک عدد نشان دهیم. فرض کنید میزان شیوع آبله ۰.۰۰۱، و میزان شیوع آبله مرغان ۰.۱ است. حال می توانیم از این اطلاعات در تشخیص خود استفاده کنیم. با ضرب این اطلاعات در موارد قبلی به اعداد زیر خواهیم رسید:با در نظر گرفتن تجربه قبلی مان در رابطه با میزان شیوع بیماری ها تشخیص آبله مرغان منطقی تر از آبله به نظر می رسد. در نتیجه می توانیم بگوییم بیمار ما دچار آبله مرغان است و جای نگرانی چندانی نیست.آنچه با هم بررسی کردیم نمونه ای از قانون بیز (Bayes’ Theorem) است. قانون بیز یکی از قوانین بسیار پرکاربرد احتمال است که با آن می توانید تجربه قبلی خود را در محاسبه احتمالات دخیل کنید. در این قانون به تجربه قبلی ما اصطلاحا احتمال پیشین (Prior Probability)، به احتمال بیماری های مختلف اصطلاحا درست نمایی (Likelihood)، و به احتمال نهایی هر بیماری احتمال پسین (Posterior Probability) می گویند.در واقع این احتمال پیشین، یا تجربه یک پزشک، یا مهندس است که در تشخیص درست بیماری یا مشکل به کمک وی می آید. با گذشت زمان و کسب تجربه احتمال پیشین مشکلات مختلف در ذهن ما شکل می گیرد و در انجام کارها ما را یاری می کند.منبع: Bayes’ rule: A tutorial introduction to Bayesian analysis اثر جیمز استون. غلامرضا صابری تبریزی غلامرضا صابری تبریزی Sun, 27 Oct 2019 12:28:32 +0330 https://virgool.io/@ghrst/%D9%85%DB%8C%D8%B2%D8%A7%D9%86-%D8%AA%D8%A7%D8%AB%DB%8C%D8%B1-%D8%AF%D8%B1%D9%85%D8%A7%D9%86-nnt-qe5ncxjxi3wa برای آگاهی از اینکه پزشکی مدرن چقدر می تواند به بیماران کمک کند راهی وجود دارد. این راه، یک مفهوم آماری بسیار ساده به نام «عدد مورد نیاز برای درمان» (Number Needed to Treat) یا به اختصار NNT است. NNT معیاری برای میزان تاثیر دارو، یا درمان ارائه می دهد. این معیار، تعداد بیمارانی که باید درمان شوند تا، یک نفر تحت تاثیر قرار گیرد را تخمین می زند. NNT یک مفهوم آماری، اما شهودی است. همان طور که می دانید، همه افراد از مداخله پزشک یا استفاده از دارو سود نمی برند – برخی درمان می شوند، برخی هیچ نتیجه ای نمی گیرند، و برخی دیگر به علت درمان دچار آسیب می شوند. NNT تعداد افراد موجود در هر گروه را مشخص می کند.برای مثال، درمانی خیالی برای حمله قلبی به نام «ضد-حمله» را در نظر بگیرید. برای بررسی میزان تاثیر این درمان، بیماران را به دو گروه تقسیم می کنیم «گروه درمان»، و «گروه شبه دارو». «گروه درمان» را در معرض «ضد-حمله» قرار می دهیم، و به اعضای «گروه شبه دارو» هیچ دارویی نمی دهیم. فرض کنید ۷۵ درصد بیماران «گروه درمان» که «ضد-حمله» را استفاده می کنند زنده مانده، و ۲۵ درصد آنها میمیرند. در گروه «شبه دارو» ۷۵ درصد بیماران میمیرند، و ۲۵ درصد آنها زنده می مانند. همان طور که مشاهده می کنید داروی «ضد-حمله» بسیار موثر است و می تواند نرخ مرگ و میر را به میزان قابل توجهی کاهش دهد. با این حال، ۲۵ درصد بیماران گروه «شبه دارو» که هیچ دارویی دریافت نمی کنند زنده مانده، و ۲۵ درصد اعضای «گروه درمان» هم با وجود استفاده از دارو میمیرند. به طور کلی، درمان «ضد-حمله» هیچ تاثیری بر ۵۰ درصد بیماران ندارد. در مقابل ۵۰ درصد بیمارانی که از این راه درمانی استفاده می کنند هم بهبود می یابند.نکته قابل توجه، این است که در اکثر داروها و درمان ها، نمی دانیم آیا درمان به افراد کمک کرده، هیچ تاثیری بر آنها نداشته، یا باعث آسیب به آنها شده است. اگر بخواهیم حساب کنیم چند نفر باید تحت درمان «ضد-حمله» قرار گیرند تا یک نفر درمان شود این عدد ۲ نفر است (زیرا این دارو تنها ۵۰ درصد بیماران را بهبود می دهد). به عبارت دیگر، NNT درمان «ضد-حمله» برابر با ۲ است. توجه داشته باشید در بسیاری از درمان ها نرخ میزان تاثیر درمان بسیار کمتر از ۵۰ درصد است. برای مثال، ممکن است NNT درمانی خاص ۵۰ باشد. یعنی تنها دو درصد بیمارانی که تحت این درمان قرار میگیرند از آن بهره می برند. در این حالت برای درمان یک نفر ۵۰ بیمار باید تحت درمان قرار بگیرند. مسلما، از میان این ۵۰ بیمار عده ای دچار عوارض آن خواهند شد.از این رو، بهتر است موقع استفاده از دارو، یا درمانی خاص NNT، و عوارض آن را مد نظر قرار دهید.منبع: http://www.thennt.com/thennt-explained غلامرضا صابری تبریزی غلامرضا صابری تبریزی Sun, 06 Oct 2019 16:04:42 +0330 https://virgool.io/@ghrst/%D9%86%DB%8C%D9%85%DA%86%D9%87-%D8%AA%D8%AD%D9%84%DB%8C%D9%84-%D9%81%D8%B1%D9%88%DB%8C%D8%AF%DB%8C-fvtlat70l0qq زیگموند فرویدیکی از سوالاتی که همیشه برایم مطرح بوده، علت رفتار هموطنانم در برابر گرانی است. در جهانی ایده آل، می توان گفت افزایش قیمت، باعث کاهش خرید میشود. در اقتصاد، به این رابطه اصطلاحا قانون تقاضا (Law of Demand) می گویند. اما، در کشورمان با افزایش قیمت هر وسیله ای شاهد پدیده ای عجیب هستیم: پس از گران شدن کالاهای حتی غیرضروری، تقاضا برای این کالاها افزایش می یابد. این پدیده، باعث می شود قیمت اقلام، چندبرابر حالت عادی افزایش یابد!مدتی قبل به سفارش یکی از همکاران، شروع به خواندن کتاب “روانشناسی گروهی و تحلیل اِگو” اثر زیگموند فروید کردم. فروید در این کتاب به نکات بسیار جالبی اشاره می کند. در بررسی علت شکست سپاهیانی که بارها در جنگ پیروز شده اند فروید می گوید: علت شکست این سپاه، بر خلاف باور اکثر افراد، ترس نیست. علت شکست، از هم گسستن روابط بین سپاهیان است. بین افراد هر گروهی علاقه ای وجود دارد، و این علاقه، علت کنارهم ماندن افراد گروه است. وقتی این علاقه از بین برود، هر یک از اعضای گروه خود را جدا از سایرین، و تنها می بیند. این تنهایی در مقابله با سپاه دشمن در فرد ترس ایجاد می کند. در نهایت، ترس باعث می شود فرد همه تلاش خود را برای نجات خویش انجام دهد، و سایرین را نادیده بگیرد. در نتیجه، سپاه از هم متلاشی شده، و شکست می خورد.این تحلیل می تواند پاسخی ساده برای سوال من باشد. شاید، دور شدن هموطنان، و ترس از مواجهه با سختی ها باعث چنین رفتاری می شود. غلامرضا صابری تبریزی غلامرضا صابری تبریزی Thu, 02 May 2019 11:31:00 +0430 https://virgool.io/@ghrst/%D8%AA%D9%81%DA%A9%D8%B1-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-design-thinking-jwasrold5xua مدتی قبل در دورهمی IDF تهران ارائه ای درباره تفکر طراحی (Design Thinking) داشتم. اسلایدها و فایل صوتی این ارائه را می توانید به صورت رایگان از آدرس زیر دانلود کنید (همین جا و داخل پرانتز از همه دوستان و عزیزانی که این دورهمی رو برگزار کردند تشکر می کنم):دانلود اسلایدهای ارائه – دانلود فایل صوتی ارائهبه علت کم بودن زمان ارائه، بعضی از مطالبی که قصد گفتن آنها را داشتم از قلم افتاد. به علاوه، نتوانستم قسمتی از مطالب را آن گونه که شایسته بود با عمق کافی مورد بررسی قرار دهم. از این رو، در ادامه سعی کرده ام، توضیحاتی برای تکمیل فایل صوتی بنویسم. پیشنهاد می کنم برای آشنایی با ماهیت تفکر طراحی یک بار فایل صوتی را گوش دهید و همراه با آن، اسلایدها را هم مطالعه کنید.اگر تاریخچه پدید آمدن تفکر طراحی را مطالعه کنید، حتما با مقاله مهم و ارزشمند هورست ریتل (Horst Rittel) با عنوان Dilemmas in a general theory of planning مواجه خواهید شد. ریتل در این مقاله به بررسی مسائل خاصی، که خود آنها را مسائل بدخیم (Wicked Problems) می نامد پرداخته است (ممکن است بدخیم معادل فارسی مناسبی برای کلمه Wicked نباشد، اما در حال حاضر معادل بهتری برای آن نیافته ام. برخی، آن را به بدسرشت هم ترجمه کرده اند. اما، بد سرشت ترجمه مناسبی برای این واژه نیست. به خصوص وقتی با کلمه مسئله همراه می شود). مسائل بدخیم، مسائلی پیچیده (پیچیده به معنای تشکیل شده از اجزا) و چندبعدی هستند. از نظر ریتل این مسائل بیشتر در تقابل با جامعه رخ می دهند. به قول ریتل: «مشکلات اجتماعی هیچ گاه به صورت قطعی حل نمی شوند بلکه بارها و بارها فیصله می یابند». فیصله را به عنوان ترجمه Resolve به کار برده ام. وقتی مسئله ای حل می شود عموما همه طرفین از حل آن راضی هستند. اما، وقتی دعوا یا اختلافی فیصله می یابد یا اصطلاحا Resolve می شود همه طرفین رضایت ندارند!ریتل علت حل نشدن مشکلات و مسائل اجتماعی را در ذات این مسائل می داند. او این مسائل را بدخیم (در مقابل مسائل خوش خیم یا به اصطلاح Tame، مثل معادله های ریاضی که راه حلی مشخص دارند)  می نامد و ۱۰ ویژگی برای این مسائل بر می شمارد که در ادامه به بررسی این ویژگی ها می پردازیم. هدف تفکر طراحی ارائه فرآیندی برای حل چنین مشکلاتی است:مسائل بدخیم صورت مسئله مشخصی ندارند: مهمترین معضل در حل مسائل بدخیم نوشتن صورت مسئله است. منظور از «نوشتن صورت مسئله» مشخص کردن سه مورد زیر است:• نوشتن ویژگی های حالت ایده آل و حالت فعلی.• پیدا کردن علت مشکل. به عبارت دیگر، علت تفاوت بین حالت ایده آل و حالت فعلی چیست؟• انتخاب مجموعه ای از اقدامات برای رفع علت مشخص شده.مسائل بدخیم شرط توقف ندارند: در حل مسائل ریاضی یا موقع بازی شطرنج می دانیم کی مسئله حل شده یا بازی به اتمام رسیده است. اما، مسائل بدخیم شرط توقف ندارند. نمی دانیم مشکل چه موقع حل شده است. در واقع، مجموعه رویدادها و وقایع خاصی وجود ندارند که با رخ دادن آنها متوجه شویم مسئله حل شده است. عموما، کسانی که مسائل بدخیم را حل می کنند به علت اتمام وقت یا بودجه حل مسئله را متوقف می کنند.راه حل های مسائل بدخیم درست یا غلط نیستند، بلکه خوب یا بد هستند: این ویژگی دخیل بودن عوامل انسانی و قضاوت انسان در بررسی کارایی راه حل مسائل بدخیم را شرح می دهد. در حل مسائل ریاضی، فرد یا افرادی وجود دارند که می توانند با آگاهی از قوانین ریاضیات، راه حل ارائه شده را بررسی کرده و اعلام کنند آیا راه حل ارائه شده درست است یا غلط. اما، در بررسی صحت و کارایی راه حل های مسائل مرتبط با اجتماع سلیقه، بافت جامعه، ساختار اجتماعی و سلسله مراتبی و قضاوت افراد دخیل است. ممکن است راه حل از نظر یک فرد خوب و از نظر شخص دیگری بد باشد.پیش از پیاده سازی راه حل، تستی برای اینکه مشخص کند آیا راه حلی برای مسئله به دست آمده است وجود ندارد: در مسائل خوش خیم، پیش از پیاده سازی راه حل، می توان تصمیم گرفت راه حل ارائه شده تا چه حد خوب یا بد است. به عبارت دیگر، بررسی و تست راه حل کاملا در کنترل کسانی است که به حل مسئله علاقه مند هستند. در مسائل بدخیم، هر راه حلی، پس از پیاده سازی، موجی از عواقب و نتایج را به همراه خواهد داشت. این موج می تواند به مدت زمان نامتناهی ادامه یابد. به علاوه، ممکن است پس از پیاده سازی راه حل، نتایج به بار آمده آنقدر وخیم باشند که حل کننده گان مسئله به این نتیجه برسند که بهتر بود اصلا راه حلی ارائه نمی شد! نتایج و عواقب راه حل پیاده سازی شده بر زندگی تک تک افراد را نمی توان پیشاپیش و قبل از پیاده سازی راه حل بررسی کرد.هر راه حلی که برای یک مسئله بدخیم مطرح می شود بسیار حائز اهمیت است و نمی توان با سعی و خطا مسئله را حل کرد: فرض کنید می خواهید مشکلات سیستم آموزشی یک کشور را رفع کنید. نمی توانید این کار را با سعی و خطا انجام دهید. کوچکترین تغییری باعث تحت تاثیر قرار گرفتن زندگی یک یا چند نسل از جامعه می شود.مسائل بدخیم مجموعه راه حل های قابل شمارشی ندارند. به علاوه، اعمال مشخصی هم وجود ندارد که بتوان از آنها در برنامه ریزی استفاده کرد: راهی وجود ندارد که بتوان بر اساس آن اثبات کرد همه راه حل های یک مسئله بدخیم شناسایی و بررسی شده است. ممکن است به علت تناقض های منطقی که در صورت مسئله وجود دارد اصلا نتوان راه حلی یافت (برای مثال ممکن است در صورت مسئله نیاز به A و نقیض آن ذکر شده باشد). عموما، در زمان تلاش برای حل یک مسئله بدخیم، مجموعه ای از راه حل ها در نظر گرفته می شوند و مجموعه ای دیگر به طور کامل از نظر پنهان می مانند. تلاش برای افزایش اندازه مجموعه راه حل ها و انتخاب یک راه حل خاص تنها به قضاوت وابسته است.هر مسئله بدخیمی اساسا یکتا است: به ازای هر دو مسئله، می توان حداقل یک وجه تمایز یافت. اما، «اساسا یکتا» یعنی به ازای تعداد بسیار زیادی ویژگی مشابه بین دو مسئله بدخیم، یک ویژگی متمایز کننده وجود دارد که اهمیت بسزایی دارد. در نتیجه نباید برای انتخاب راه حل مسائل بدخیم عجله کرد.هر مسئله بدخیمی را می توان نشانه ای از یک مسئله بدخیم دیگر (و سطح بالاتر) در نظر گرفت: برای مثال جرم و جنایت را می توان نشانه ای از افول اخلاق در جامعه در نظر گرفت.توضیحات مختلفی برای وجود تفاوت بین حالت ایده آل و حالت فعلی در صورت مسائل بدخیم قابل ارائه است. اگر توضیح خاصی را به عنوان علت مسئله در نظر بگیرید در واقع راه حل خود را انتخاب کرده اید. برای مثال می توان علت جرم و جنایت در جامعه را افول اخلاق، فقر، تولید فیلم های خشن و غیره دانست. اگر علت خشونت در جامعه را افول اخلاق در نظر بگیرید راه حلتان هم در همین جهت پیش خواهد رفت!طراح (حل کننده گان مسائل بدخیم) حق اشتباه کردن ندارد: در علم، دانشمندان نظریه های مختلفی برای توضیح یک پدیده بیان می کنند. یک نظریه را می توان با استفاده از شواهد نقض کرد و نظریه جدیدی ارائه داد. هیچ کس، دانشمندان را برای ارائه نظریاتی که نقض می شوند سرزنش نمی کند. اما، در حل مسائل بدخیم، بر خلاف علم، هدف یافتن حقیقت نیست. هدف، بهبود شرایط زندگی مردم است. از این رو طراحان و کسانی که مسائل بدخیم را حل می کنند حق اشتباه کردن ندارند و باید مسئولیت تصمیمات خود را بپذیرند.هدف فرآیندهای گوناگون تفکر طراحی حل مسائلی است که ویژگی های فوق را دارند. مسائلی که اصطلاحا انسان-محور هستند. این گونه مسائل در بطن جامعه یا سیستمی هایی که عوامل انسانی در آنها نقش دارند (برای مثال سیستم های نرم افزاری) پدید می آیند و برای حل آنها باید نیازهای افراد مختلف در نظر گرفته شود. حال که ویژگی های مسائل بدخیم را برشمردیم می توانید برای مشاهده مراحل گوناگون فرآیند تفکر طراحی (که فرآیندی برای حل این مسائل ارائه می دهد) و انواع مختلف آن به اسلایدها مراجعه کنید. در انتها امیدوارم توضیحات فوق مفید واقع شوند. غلامرضا صابری تبریزی غلامرضا صابری تبریزی Wed, 27 Mar 2019 18:28:30 +0430