تیتراژ سریال A Million Little Things با جمله‌ای شروع می‌شود که به نظرم می‌توان مدت‌ها به آن فکر کرد و مزه مزه‌اش کرد.
آن جمله این است:

Friendship isn't a big thing...
It's a million little things.

از این جمله اگر Friendship را برداریم و به جایش چیزهای پیچیده‌ی دیگری مثل agility بگذاریم باز هم همین ماجراست. نیست؟

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

در بین تعاریف متنوعی که از رفکتورینگ (Refactoring) دیده‌ام، تعریف David West به نظرم واجد صحت و دقت بیشتری است. او می‌گوید:

Refactoring is a way for “lazy” objects to give all the hard work to other objects. Of course, when refactored and distributed to the proper objects, the work turns out not to be hard at all.

اما چرا این تعریف را برگزیده‌ام؟‌ به چند دلیل:

اول: می‌توان تاکید بر طراحی مسئولیت محور (Responsibility-Driven Design) را در این تعریف به وضوح دید.

دوم: تشخیص اینکه چه چیزی برای یک شی Hard Work است، برنامه‌نویس را وادار می‌کند تا اصطلاحا از زاویه نگاه شی به دنیای بیرون نگاه کند. این خود یک رهیافت خوب برای طراحی شی گراست که گفته‌اند: 

Object Thinking = Think Like an Object

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

چهارم: نتیجه دنبال کردن این نگرش در رفکتورینگ، سادگی (Simplicity) است. اشیا کمترین کار ممکن را می‌کنند ولی همان کار را ساده و سر راست انجام می‌دهند.

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

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

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

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

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

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

تو مگو همه به جنگند و ز صلحِ من چه آید
تو یکی نه‌ای، هزاری، تو چراغ خود برافروز

که یکی چراغ روشن ز هزار مرده بهتر
که به است یک قد خوش، ز هزار قامت کوز

#مولوی
#برای_ایران

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

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

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

🔹در میانه: سعی می‌شود به شکلی دموکراتیک، برخی از موضوعات مطروحه، انتخاب و به بحث گذاشته شوند.

🔹سرانجام: سعی می‌شود تا بر پایه توافقی جمعی (مبتنی بر آرای اکثریت) برخی اقدامات که به گمان اعضای تیم باعث بهبود و رضایت می‌شود، انتخاب شوند و همگی متعهد به رعایت آنها شوند.

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

نظریه‌ی زمینه (Theory of Context) چیست؟
در حوزه جامعه‌شناسی، تصمیماتی که توسط بازیگران گرفته می‌شود، عموما به طور توامان به خشنودی جمعی و ناخشنودی جمعی دیگر منجر می‌شود. این تصمیمات که باعث اعطا یا سلب امتیاز به/از کسانی ‌می‌شود، ذیل سرفصل «سیاست‌گذاری عمومی» مطالعه می‌شود. از این منظر، جلسه بازاندیشی اسپرینت هم نوعی از سیاست‌گذاری عمومی است که می‌تواند با وضع قوانینی هر چند محلی و محدود باعث شود توزیع امکانات و اختیارات به شکلی انجام شود که عده‌ای رضایتمند و عده‌ای ناراضی شوند. مثلا در ساحت جامعه ایران، نهادی مسؤل در حاکمیت تصمیم می‌گیرد تا در قالب طرح جوانی جمعیت به والدینی که صاحب فرزند می‌شوند امتیاز خودرو اعطا شود. یا در مقیاسی خردتر، در یک تیم عده‌ای تصمیم می‌گیرند که برای افزایش انگیزه، ساعت‌هایی در هفته به مطالعه‌ی آزاد اختصاص یابد.

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

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

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

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

ادامه 👇

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

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

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

راهکاری برای بهبود جلسات رترو:
برای اینکه رتروسپکتیوها به بهبود واقعی منجر شوند، لازم است که دو لایه‌ی تحلیلی زیر، به جلسات اضافه شود:

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

🔘طراحی نظریه‌ی تغییر: پس از درک صحیح از وضعیت موجود، راهکارها باید به‌عنوان بخشی از یک فرآیند تغییر طراحی شوند. هر راهکار باید با یک منطق علّی همراه باشد: «اگر این تغییر را ایجاد کنیم، چه اثرات زنجیره‌ای خواهد داشت و چگونه ما را به وضعیت مطلوب نزدیک می‌کند؟» علاوه بر این، باید معیارهایی برای سنجش موفقیت تعریف شوند تا بتوان بررسی کرد که آیا تغییرات اعمال‌شده واقعاً مؤثر بوده‌اند یا نه.

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

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

در سال 1999 دیوید دانینگ و جاستین کروگر پژوهش مشترکی در حوزه روان‌شناسی شناخت انجام دادند با عنوان:

«ناماهر و نادان به آن: چگونه دشوار بودنِ شناختِ بی‌کفایتی خود منجر به ارزیابی متکبرانه از خویشتن می‌شود؟»

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

🟡 علت چیست؟
آزمایش‌های انجام شده نشان داد که اثر دانینگ-کروگر ناشی از دو عامل اصلی است:

🔘 نبود خودآگاهی در افراد کم‌مهارت: آن‌ها نه‌تنها در انجام وظیفه ضعیف عمل می‌کنند، بلکه ابزار لازم برای تشخیص ضعف خود را نیز ندارند.

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

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

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

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

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

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

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

اقداماتی از این دست می‌تواند اثرات منفی این سوگیری شناختی را کمتر کند:

🔘 آموزش و نظارت: برقراری جلسات منظم مربی‌‎گری میان افراد کم‌تجربه و افراد ارشد، به تعدیل برآوردهای نادرست و تقویت اعتماد به نفس واقعی کمک می‌کند.

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

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

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

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

محتوایی که به اشتراک گذاشته‌ام، فایل ارایه جلسه سوم از دوره‌ی آموزش توسعه اپلیکیشن‌های قدرت گرفته از AI است. موضوع آن درس‌گفتار، آشنایی با AI Agent ها و الزامات و الگوهای مطرح در طراحی و پیاده‌سازی آنها بود.
همینطور به شیوه‌های بهبود تجربه کاربران AI Agent ها، اشاره کرده‌ام که می‌تواند برای علاقه‌مندان به UX Design هم مفید باشد. اگر برای بیشتر دانستن درباره توسعه #AI_Agent ها دنبال سرنخ‌های خوبی هستید، این محتوا مناسب شماست.

- پی‌نوشت: این دوره همچنان در حال برگزاری است.
اپلیکیشن‌های قدرت گرفته از AI : #AI_Powered_Applications, #LLM_Powered_Applications
https://docs.google.com/presentation/d/135Pu9t-POe0Os8ElvfI22tCNH2XD7w35Z4JYB1_jBqg/edit?usp=sharing

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

ورنه خاموش است و خاموشی...

تیمی را می‌توان بهره‌مند از امنیت روانی (Psychological Safety) دانست که اعضایش احساس کنند می‌توانند آزادانه نظرات‌شان را بیان کنند، سؤال بپرسند، اشتباهات خود را بپذیرند و ایده‌های جدید مطرح کنند، بدون ترس از سرزنش، تمسخر یا تنبیه.

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

در مطالعه‌ای که در سال ۲۰۲۳ انجام شد پژوهشگران (کلارک و گروس)، از طریق بررسی داده‌های جمع‌آوری‌شده از ۴۸ تیم نرم‌افزاری در شرکت‌های فعال در حوزه فناوری دریافتند که تیم‌هایی با سطح بالای ایمنی روانی، تا ۳۵ درصد بهره‌وری بیشتری در حل مسائل پیچیده و نوآورانه از خود نشان می‌دهند.

از دیدگاه دیگر، این بدان معناست که تیم‌هایی که فاقد این مولفه حیاتی باشند، بخشی از پتانسیل خود را بلااستفاده می‌گذارند و این مترادف با هدررفت سرمایه‌های انسانی و سازمانی است. این موضوع به‌ویژه در شرایطی که تیم‌ها با ابهامات فنی یا فشار زمانی مواجه‌اند، نمود بیشتری پیدا می‌کند. مطالعه مذکور همچنین نشان داد که ایمنی روانی با کاهش خاموشی تیمی (Team Silence) – یعنی حالتی که اعضا از بیان نگرانی‌ها یا ایده‌های خودداری می‌کنند – ارتباط مستقیم دارد.

چرا ایمنی روانی برای تیم‌های توسعه نرم‌افزار حیاتی است؟
فرآیند توسعه نرم‌افزار ماهیتاً پیچیده، تعاملی و وابسته به خلاقیت و حل مسئله مستمر است. در چنین محیط‌هایی:

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

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

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

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

ایمنی روانی به این معنا نیست که مهربان باشیم؛ بلکه به این معناست که بتوانیم با یکدیگر صادق باشیم.

با این حال، می‌توان با اتخاذ برخی اقدامات، مسیر را هموارتر کرد:

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

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

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

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

پی‌نوشت:

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

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

پژو ۲۰۶، رقص بندری و قانون هایروم!

امیدوارم که شما هم این صحنه‌‌ را دیده باشید که راننده‌ (اکثرا جوان) خودرویی مثل پژو ۲۰۶، در حالی که ترمز دستی را کشیده، با بازی گاز و کلاچ، قسمت عقب ماشین بیچاره را به حالت بلرزان (چیزی شبیه رقص بندری) در می‌آورد! اما چرا گفتم که امیدوارم دیده باشید؟ چون شرح آنچه که در ادامه خواهم گفت آسانتر خواهد شد و اگر هم ندیده‌اید تصورش کار سختی نیست و می‌توانید با خیال راحت به خواندن ادامه دهید :)

طراحان پژو ۲۰۶ هنگام طراحی پدال گاز و کلاچ و ترمز‌دستی در واقع چند واسط (Interface) ساده ایجاد کرده‌اند تا رانندگان بتوانند خودرو را بدون آگاهی از جزییات فراوان آن (implementation) کنترل کنند. آن طراحان شاید هیچ‌وقت گمان نمی‌کردند که این واسط‌ها برای ایجاد حالت بلرزان و نوعی تلاش برای جلب توجه استفاده شود!

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

برگردیم به پژو ۲۰۶. همان‌طور که گفتم طراحان این خودرو با ایجاد واسط‌های ساده‌ای مانند پدال گاز، کلاچ و ترمز دستی، قصد داشتند رانندگان را قادر سازند تا خودرو را به راحتی و بدون نیاز به درک پیچیدگی‌های فنی آن کنترل کنند. این واسط‌ها در واقع یک لایه انتزاعی (abstraction) ایجاد کرده‌اند که راننده را از جزئیات پیاده‌سازی مانند نحوه عملکرد موتور، سیستم انتقال قدرت و ترمزها جدا می‌کند. این همان چیزی است که در مهندسی نرم‌افزار نیز به عنوان یک اصل مهم شناخته می‌شود: ایجاد رابط‌هایی که کاربران را از پیچیدگی‌های داخلی سیستم دور نگه می‌دارد.

اما همان‌طور که در قانون هایروم اشاره شد، با افزایش تعداد کاربران، برخی از آن‌ها به جزییات رفتارهای قابل مشاهده سیستم وابسته می‌شوند و از آنها برای اهدافی غیرمنتظره‌ استفاده می‌کنند. مثلا رانندگانی که با کشیدن ترمز دستی و بازی با گاز و کلاچ، خودرو را به حالت «بلرزان» درمی‌آورند، در واقع از جزییات قابل مشاهده سیستم به شیوه‌ای استفاده می‌کنند که احتمالاً طراحان خودرو هرگز آن را در نظر نگرفته بودند. این وابستگی‌ها، اگرچه خارج از هدف اصلی طراحی انتزاعی است، اما به مرور زمان به بخشی از انتظارات کاربران تبدیل می‌شود و حتی ممکن است به یک ویژگی ضمنی (implicit interface) تبدیل شود.

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

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

این پدیده به طراحان و مهندسان نرم‌افزار یادآوری می‌کند که حتی اگر یک رابط (interface) به دقت طراحی شده باشد، با افزایش تعداد کاربران، رفتارهای غیرمنتظره‌ای از رابط‌ها ممکن است ظاهر شوند که باید در هنگام تغییر پیاده‌سازی‌ها، در نظر گرفته شوند. این موضوع به ویژه در سیستم‌های بزرگ و پیچیده اهمیت دارد، جایی که تغییرات کوچک می‌توانند تأثیرات گسترده‌ای بر استفاده‌کنندگانی داشته باشند که عمیق‌تر از آنچه که گمان می‌کنیم به جزییات پیاده‌سازی وابسته شده‌اند.

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

وایب کدینگ؛ نشانه یا راه‌حل؟

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

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

وایب کدینگ: فرار از مسئولیت یا بازتعریف مرزهای حرفه‌ای؟

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

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

ادامه: https://telegra.ph/وایب-کدینگ-نشانه-یا-راه‌حل-04-06

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

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

از سوی دیگر Liberating Structures تکنیک‌های ساده‌ای هستند که با ایجاد فضای مشارکتی، تأثیر سوگیری‌هایی مثل تسلط گروهی را کاهش می‌دهند. این کارگاه ۴ ساعته به مربیان چابک، تیم‌لیدها، مدیران محصول و پروژه، و علاقه‌مندان به بهبود همکاری تیمی کمک می‌کند تا با شناخت ۱۰ سوگیری شناختی و ابزارهایی مثل 1-2-4-All، تصمیم‌گیری بهتری داشته باشند.

🔅مخاطبان: مربیان چابک، تیم‌لیدها، مدیران محصول و پروژه، فعالان استارتاپ‌ها و هر علاقه‌مند به بهبود کار تیمی، خلاقیت و بهره‌وری

🔅سرفصل‌ها: معرفی سوگیری‌های شناختی متداول در کار تیمی، آشنایی با Liberating Structures، تمرین عملی و Role Play

🔅تاریخ: ۲۷ شهریور ۱۴۰۴

🔅ظرفیت: ۱۶ نفر - (کارگاه حضوری برگزار می‌شود)

🔅مهلت ثبت‌نام زودهنگام: ۳۱ مرداد

اطلاعات بیشتر و ثبت‌نام: https://evnd.co/5gGNR
@DelpakLog

گندم از گندم بروید، جو ز جو! (قسمت اول)

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

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

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

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

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

@DelpakLog

--—————

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

https://evand.com/events/understanding-10-common-cognitive-biases-in-teamwork


#teamwork #agile #agilecoach #LiberatingStructures #facilitation

گندم از گندم بروید، جو ز جو! (قسمت دوم)

کریگ لارمِن (Craig Larman) بنیانگذار چارچوب LeSS در شروع یکی از سخنرانی‌هاش که ۱۲ سال پیش انجام شده، یک جوک تعریف میکنه که هنوزم تر و تازه‌ست!
اون جوک را اینجا نمی‌گم و خودتون بهتره ویدیو رو ببینید و از اکت و ادای لارمن هم لذت ببرید. :))
موضوعش اما «ارتباط موثر» و چالش‌های اونه. چالشی که به قول لارمن هم در زندگی مشترک وجود داره و هم درون سازمان‌ها!

شخصیتی که لارمن توی جوکش از اون صحبت میکنه، واضحا دو تا سوگیری شناختی داره که باعث میشه اون وضعیت کمدی ایجاد بشه:

۱- سوگیری تأیید (Confirmation Bias)

سوگیری تأیید تمایل ذهنی ماست که:

▪️به دنبال اطلاعاتی بگردیم که باورها یا فرضیات موجود خودمون رو تأیید کنه.
▪️اطلاعات متناقض رو نادیده بگیریم یا کمتر ارزش‌گذاری کنیم.
▪️حتی شواهد خنثی رو به شکلی تفسیر کنیم که باور اولیه‌مون رو تایید کنه.

۲- سوگیری خودمحوری (Egocentric Bias)

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

این سوگیری باعث می‌شه:

▪️افراد فکر کنند بیشتر از دیگران در یک موفقیت نقش داشتند.
▪️سهم خودشون رو در یک شکست کمتر و سهم دیگران رو بیشتر بدونند.
▪️فرض کنند که دیگران دنیا را همان‌طور که خودشون می‌بینند، درک می‌کنند.

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

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

ساختارهای رهاساز (Liberating Structures) تا حدود زیادی همین هدف رو دنبال می‌کنند و با مجموعه‌ای از تکنیک‌ها، کمک حال تیم‌ها میشن تا به سطح عملکرد بهتری برسند. مثلا تکنیک‌هایی مانند:

- What, So What, Now What? (W³)
- Triz
- Wicked Questions

میتونن کمک کنند که اعضای تیم گرفتار سوگیری تایید نشن.

و یا مثلا برای غلبه بر سوگیری خودمحوری، تکنیک‌هایی مثل:

- Appreciative Inquiry
- Troika Consulting

تاثیر درخشانی دارند.

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

@DelpakLog

--—————
اگر علاقه‌مندید که در باره سوگیری‌ها و تکنیک‌های LS بیشتر بدونید و تمرین کنید و تجربه بیاموزید، فرصت شرکت در این کارگاه فراهمه.
https://evand.com/events/understanding-10-common-cognitive-biases-in-teamwork


#teamwork #agile #agilecoach #LiberatingStructures #facilitation

چطور جلسات کتاب‌خوانی گروهی را اثربخش و سودمند کنیم؟

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

آیا این سرنوشت محتوم همه‌ی جلسات کتاب‌خوانی گروهی‌ست؟ چاره‌ای؟ راه‌حلی؟

مدتی قبل داشتم درباره کتاب Fearless Organization مطلبی می‌خواندم که اتفاقی رسیدم به یک فایل راهنما! راهنمایی که برای تسهیلگران جلسات هم‌خوانی همین کتاب تهیه شده بود و به شکلی دقیق و هدف‌مند و همراه با جزییات فراوان به تسهیلگران جلسات‌شان ایده‌هایی می‌داد که چطور هر جلسه و کل فرآیند کتاب‌خوانی را مدیریت کنند.

این راهنما را می‌توانید از اینجا ببینید. راهنمایی که می‌تواند الگوی خوبی برای کسانی باشد که علاقه‌مندند تا تسهیلگر بهتری برای جلسات ارزشمند کتاب‌خوانی گروهی‌شان باشند.

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

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