:)

جریان‌های کاریِ معیوب و چگونگی درست کردنشان

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

مشکل رایج بعدی، برچسب “فوری” است. وقتی هر چیزی «اولویت یک» می‌شود، هیچ‌چیز اولویت ندارد. راه‌حل: یک صفِ مشترک و شفاف بسازید؛ کارها را رتبه‌بندی کنید و قبل از شروع مورد بعدی، مورد فعلی را ببندید. یک بانک بین‌المللی با همین کارو یک جلسه‌ی هفتگی که همه‌ی ذی‌نفعان در آن روی یک فهرست مشترک تصمیم می‌گرفتند—میانگینِ زمانِ تأیید پروژه‌ها را از ۱۲۰ روز به ۲۰ روز رساند.

نکته‌ی غیر شهودی اما حیاتی: استفاده‌ی ۱۰۰٪ از آدم‌ها، خروجی را بیشتر نمی‌کند؛ گلوگاه می‌سازد. کمی فضای خالی برای فکر و اصلاح بگذارید. هر جا حس کردید تیم برای عبور از یک پیچ، «میان‌بُر» می‌زند، بدانید سیستم دارد سیگنال می‌دهد: فرایند را ترمیم کنید، نه آدم‌ها را فرسوده.

برای راه‌انداختنِ جریان، از همین چند حرکت ساده شروع کنید:
•تعریف «تمام‌شدن» را برای هر کار بنویسید (چه تحویلی، با چه معیار).
•کارهای هم‌زمان را محدود کنید؛ به‌جای ۱۰ کار نیمه‌تمام، ۳ کار کامل.
•تابلوی دیداری بزنید (فیزیکی یا دیجیتال): «در صف / در حال انجام / تمام».
•جلسه‌ی هفتگیِ یک‌ساعته‌ی بین‌وظیفه‌ای برگزار کنید؛ یک فهرست مشترک، تصمیمِ واحد.
•بازخوردِ کفِ کار بگیرید؛ اگر از آنچه می‌بینید خجالت‌زده نمی‌شوید، کافی دقیق نشده‌اید.
•اندازه بگیرید: زمانِ انتظار، زمانِ انجام، و نرخ بازگشت کار برای اصلاح. فقط همین سه تا.

فلسفه‌اش ساده است: کارخانه‌ی خوب، «قهرمان» ندارد؛ جریانِ خوب دارد. هر جا کار گیر کرد، به‌جای فشار بیشتر، اصطکاک را کم کنید. با شفاف‌سازی، محدودکردن کارِ در جریان، و دیدن واقعیتِ کفِ کار، شلوغیِ بی‌حاصل به ثباتِ سودمند بدل می‌شود و ناگهان می‌بینید بدون اضافه‌کاری، خروجی بیشتر شده است
#مدیریت #رهبری #جریان_کار #گلوگاه #بهبود_فرایند #اکونومیست #سپندارند⁩⁩

"کارخانه‌ی خوب، قهرمان ندارد؛ جریان خوب دارد."

صوت جلسه 13 خوانش کتاب یادگیری تفکر سیستمی

مواردی که خارج از کتاب بهشون اشاره شد در جلسه.
-

یا امام!

https://reasonablypolymorphic.com/blog/protos-are-wrong/

🎮 ایونت حضوری منتینو: تقویت مهارت‌های نرم برای برنامه‌نویس‌ها

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

چی در انتظارتونه؟

✨ بازی گروهی تعاملی برای تمرین واقعی مهارت‌هایی مثل:
✨ کار تیمی
✨ ارتباط مؤثر
✨ حل مسئله
✨ تصمیم‌گیری درست
رو به‌طور واقعی تمرین و تقویت می‌کنی.

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

💬 پنل گفت‌وگو با چند نفر از افراد باتجربه حوزه نرم‌افزار درباره نقش مهارت‌های نرم در رشد شغلی برنامه‌نویس‌ها

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

📅 جمعه ۱۸ مهر
🕒 ساعت ۱۵ تا ۲۰
📍 تهران

🎟 ظرفیت محدوده — همین الان ثبت‌نام کن!
https://menteeno.app/fa/event/

منتظر حضور گرمتون در ایونت هستیم  🌱

رفقا این ایونت رو میتونید با کد تخفیف benazad تهیه کنید.

بچه های خوب فرانت چپتر زحمتش رو کشیدن.

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

پروژه متعلق به وزارت کار بوده و مربوط به تطبیق فرایندهای IT اداره کار با یه سیستم استاندارد (اصطلاحاً: پروژهٔ compliance).

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

دیلویت اعتراف کرده که گزارش با کمک هوش مصنوعی مولد نوشته شده و استفاده از هوش مصنوعی مولد منشاء خطا بوده.

گاردین یه گزارش مختصر ازش نوشته

#هوش_مصنوعی_مولد

Human in the loop!

فرض کنید شما به انجام یک سری محاسبات بسیار پیچیده ریاضی نیاز دارید، برای این کار سراغ دو ریاضیدان، یکی در شرق کره خاکی و دیگری در غرب میرید. مسئله رو برای هردو بیان میکنید، با در نظر گرفتن اینکه مسئله برای شما یک جواب واحد داشته باشه آیا جواب هر دو ریاضیدان باید یکی باشه؟ آیا منطق و ریاضیات وابسته به نقطه جغرافیایی کار میکنه؟ یعنی جواب ۲ + ۲ در شرق از غرب متفاوته؟ تو ساعت های مختلف چطور؟ (رجوع کنید به formal system ها)

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

این مقاله که امروز صبح خوندم خیلی جالب بود. به طور خیلی خلاصه داستان یک باگ رو میگه در کامپایلر زبان کاتلین که روی سیستم هایی که زبان ترکی داشتند، کاراکتر i و I اشتباها به معادل ترکیشون یعنی İ و ı مپ میشدند. مقاله جالبیه و به نظرم حتما بخونید.

اما مسئله ای که من میخوام بهش اشاره کنم که درون مایه این مقاله رو پوشش میده، مسئله Local Agnostic هست.

اول بگیم locale یعنی چی؟ میتونیم اینطوری تعریفش کنیم که هرچیزی که به یک منطقه، محیط یا کانتکست وابسته است و میتونه نسبت به مکان و یا نحوه اجرای نرم افزار متفاوت بشه، locale نرم افزار ما حساب میشه!
مثال های ساده ای هم ازش وجود داره: مثلا تایم زون، زبان سرور، کشور استقرار سرور، محیط و ...

درمورد رگولاتوری ها هم یک پرانتز باز کنم، رگولاتوری ها به معنی کلاسیک یک Locale حساب نمیشن یعنی system locale نیستن اما میتوان اونها رو به عنوان environment locale به حساب آورد چون در سطح جغرافیایی و سیاسی وجود دارند و باید اعمال بشن. مثلا شما با قوانین اروپا در آمریکا operate نمیکنی یا بالعکس پس من برای ساده سازی موضوع یک دسته بزرگی به اسم Environment Locale در نظر میگیرم که شامل System Locale هم میشه از اینجا به بعد با اسم Locale میریم جلو.

حالا که فهمیدیم locale دقیقا چیه میتونیم بپرسیم locale کجا ها مشکل آفرینه و چطوری میتونیم حلش کنیم؟ locale اونجایی مشکل میشه که تبدیل شه به یک ساید افکت کریتیکال در اجرای برنامه! یعنی چی ؟ یعنی اینکه نرم افزار شما برای درست اجرا شدن و رفتار غیر قابل پیش بینی نشون ندادن باید به این ساید افکت متکی باشه. مثلا باید حتما در تایم زون UTC+4 باشه و در تایم زون های دیگه خروجی های غیر منتظره میده و درست رفتار نمیکنه. توی همین مقاله این موضوع با زبان سیستم عامل تکرار شده.

حالا راه حل چیه؟
اینکه نرم افزار رو درجهتی توسعه بدیم که بیشتر و بیشتر به Locale Agnostic شدن نزدیک بشیم! یعنی چی؟ یعنی اینکه نرم افزار "آگاه" باشه از کانفیگ های سمت سرور و رگولاتوری های جغرافیایی ولی برای Operate کردن در هر نقطه از جهان به اون ها متکی نباشه! مثلا از تایم زون سرور برای ارسال و دریافت زمان استفاده نکنه. Locale-agnostic بودن یعنی abstract کردن این شکل تفاوت‌ها، نه نادیده گرفتنشان.

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

صوت جلسه 14 خوانش کتاب یادگیری تفکر سیستمی

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

عجب جلسه ای!

وایب کدینگ برای همه نیست!

فرصت نشد درمورد این مقاله باحال از Anthropic مطلب بنویسم، گفتم بزارمش که دیر نشه، فقط خیلی سوسکی بگم که LLM ها هم DDOS میشن!

https://www.anthropic.com/research/small-samples-poison

فعلا فقط نسخه macos ش اومده
https://chatgpt.com/atlas?openaicom_referred=true

هیچ چیز دندون گیری نداشت، باید منتظر آپدیت موند.

https://aws.amazon.com/message/101925/
آنچه گذشت!

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

این صحبتا بد نیست باشه ولی فکر میکنم با Redundant کردن سرویس ها میشه تا حدودی از بیزنستون در قبال این جور داستان ها محافظت کرد! حالا اگه بیزنستون اونقدری بزرگ نیست که همچین حرکتی بخواید براش بزنین اشکال نداره، ولی حداقل به عنوان یه تصمیم ساز در نظر بگیریدش (یا با تصمیم ساز ها سازمانتون مطرحش کنین)