TondTech – Telegram
TondTech
2.65K subscribers
1.48K photos
169 videos
133 files
1.16K links
کالای ما دانش است


تبلیغات نداریم
Download Telegram
Forwarded from tech-afternoon (Amin Mesbahi)
📌 چطور جلسات یک‌به‌یک سازنده و مفید داشته باشیم؟ بخش اول، از منظر عضو تیم

مقدمه: چرا جلسات یک‌به‌یک مهم هستن؟

جلسات یک‌به‌یک (One-on-One یا 1:1) یکی از ابزارهای پایه‌ای لیدرشیپ محسوب می‌شن که فرصت مناسبی رو برای ایجاد ارتباط عمیق‌تر و هدفمند بین عضو تیم و رهبر تیم فراهم می‌کنن. این جلسات از جلسات معمول کاری متمایز هستن و به‌جای تمرکز روی وظایف روزمره، بر توسعه فردی، بهبود روابط کاری، و رشد متقابل تأکید دارن.

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

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

🎯 اهداف استراتژیک جلسات یک‌به‌یک

- دریافت بازخورد عملکردی: شناسایی نقاط قوت و فرصت‌های بهبود
- مطرح کردن چالش‌های کاری: حل مسائل عملیاتی و رفع موانع
- برنامه‌ریزی مسیر رشد: تعیین اهداف توسعه فردی و شغلی
- بهبود دینامیک تیم: ارائه ایده‌ها برای بهبود فرآیندها و همکاری
- درخواست منابع و حمایت: تأمین ابزار و آموزش‌های مورد نیاز

اهداف ثانویه:
- تقویت اعتماد متقابل
- افزایش انگیزه و تعلق سازمانی
- پیشگیری از فرسودگی شغلی
- ایجاد فرهنگ یادگیری مستمر

📆 تناوب و زمان‌بندی علمی

هر ۲ تا ۴ هفته یک‌بار - این بازه بر اساس تحقیقات رفتار سازمانی و تجربیات شرکت‌های پیشرو تعیین شده. زمانش هم ۳۰ تا ۴۵ دقیقه برای جلسات معمول و ۶۰ دقیقه برای جلسات فصلی یا سالانه.

چرا این تناوب؟
- کوتاه‌تر از ۲ هفته: ممکنه به سطحی‌سازی منجر بشه
- بیشتر از ۴ هفته: باعث ضعیف شدن ارتباط و انباشت مسائل می‌شه
- انعطاف‌پذیری: در دوره‌های پروژه‌های حساس یا تغییرات سازمانی می‌شه تناوب رو افزایش داد

🛠 آمادگی برای جلسه

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

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

🤔 آماده‌سازی مثال‌های عینی:
- مثال‌های موفق: پروژه‌/کاری که خوب انجام دادین
- چالش‌های خاص: مشکلی که نیاز به راهنمایی دارین
- اهداف رشد: مهارت یا موقعیتی که می‌خواهید کسب کنین

🧘‍♀️ آماده‌سازی ذهنی:
- ذهن باز و پذیرا داشته باشین
- انتظارات واقع‌بینانه‌ای رو تعریف کنین
- فضای امن برای صحبت آماده کنین

🗣 هنر گفت‌وگوی مؤثر در جلسه

صداقت سازنده:
- شفافیت: مسائل رو بدون پرده‌پوشی بیان کنین
- سازندگی: همراه با مشکل، راه‌حل پیشنهاد بدید (نقد بدون پیشنهاد راهکار عموما نِق زدن تلقی می‌شه)
- احترام: از زبان محترمانه و حرفه‌ای استفاده کنین

رویکرد راه‌حل‌محور:
- توصیفی نه قضاوتی: رفتارها و نتایج رو توصیف کنین، نه شخصیت افراد رو
- تأثیر‌محور: درباره تأثیر مسائل روی کار و تیم صحبت کنین
- آینده‌نگر: روی راه‌حل‌ها و بهبود آینده تمرکز کنین

💬 نظر و تجربه‌تون رو حتمن بگید، خوشحال می‌شم بشنوم. در ضمن در صورت استقبال بخش بعد به مثال‌هایی از گفتگو سازنده و غیرسازنده + ساختار پیشنهادی خواهم پرداخت و باز هم در صورت استقبال، مطلب بعدترش، از منظر تیم‌لیدر...
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍1
Forwarded from tech-afternoon (Amin Mesbahi)
📌 چطور جلسات یک‌به‌یک سازنده و مفید داشته باشیم؟ بخش دوم، از منظر لیدر

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

🧰 ویژگی‌های تیم‌لید آماده برای جلسه ۱:۱

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

📝 آمادگی قبل از جلسه برای مدیر

🔤 باید نگاهی به فعالیت‌های فرد بندازه (PRها، مشارکت‌ها، صحبت‌ها)
🔤نوت‌های جلسه قبل رو مرور کنه و ببین قول‌هایی که داده انجام شده یا نه
🔤اگر بازخورد داره، با مثال و دقت آماده می‌کنه (نه کلی‌گویی)
🔤یک فضای امن و بی‌تنش فراهم می‌کنه

💡 نکات کلیدی و رویکرد ذهنی مناسب

سؤال بپرس، سخنرانی نکن: از جنس «چه چیزی می‌تونم بهتر انجام بدم؟»
ایجاد تعهد به جای اجبار: فرد باید احساس کنه بخشی از راه‌حل‌هاست
بازخورد دوطرفه باشه: خودت هم مشتاق شنیدن بازخورد باش
نقش کوچ داشته باش نه مدیر پروژه: این جلسه جای ابلاغ وظایف نیست

آیا هر کسی می‌تونه ۱:۱ خوب برگزار کنه؟

«نه». برگزاری جلسه یک‌به‌یک موثر، نیازمند بلوغ حرفه‌ای، مهارت شنیدن، و نگرش انسانی به تیم؛ در کنار تجربه و دانش است. بدون یاد گرفتن و تمرین کردن این مهارت‌ها نتیجه‌ی مطلوب محاله!

#️⃣ اگر دوست داشتید کلیدواژه یا سرنخ برای بیشتر خوندن داشته باشید، پیشنهادم:

Active Listening
Coaching/Growth Mindset
GROW model (coaching framework)
Psychological Safety
Radical Candor
Co-Active Coaching
Mindset Shift

💬 نظر و تجربه شما به عنوان لیدر یا عضو تیم از ۱:۱ چیه؟
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍1
Forwarded from thisisnabi.dev [Farsi]
عقب افتاد اما با برنامه تر پیش میریم

من معماری وب رو خوب بلدم، پس قرار نیست اینجا فقط در مورد یک فریم ورک صحبت کنیم.

خیلی از عنوان های کتاب Andrew Lock رو هم قراره که مطالعه کنیم، اما اگر آدمی هستید که عناوین فقط براتون کافی هست، احتمالا همون دوره های رایگان داخل یوتیوب بیشتر بدردتون بخوره و بنظرم ثبت نام نکنید.

لینک پرداخت رزین پال:

https://zarinp.al/703650

بعد از پرداخت نیازی نیست کاری انجام بدید، خودمون براتون ایمیل ثبت نام می فرستیم.
2
Forwarded from Learning With M
🔥🔥 خبر خبر 🔥🔥
بلاخره زمان پیدا کردم تا دوره جدید Techlead 360 رو شروع کنم 🎉
خیلی درخواست داده بودید و من وقتش رو نداشتم، ولی حالا برای شهریور ماه این کلاس 4 روزه رو برای علاقه مندان برنامه ریزی کردم.
محتوی جدید هم بر اساس تجربه و مطالعه به دوره اضافه شده.
توی این دوره شما در مورد این یاد میگیرید که :

1. یک تکلید باید چه خصوصیاتی داشته باشه.
2. یک تکلید در تیم چه وظایفی داره.
3. یک تکلید در سازمان چه وظایفی داره.


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

بهتون پیشنهاد می کنم برنامه درسی دوره رو حتمی مطالعه کنید.

برای ثبت نام می تونید از این آدرس استفاده کنید :

ثبت نام در تکلید 360 شهریور ماه
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👎1
در باب صحبت هایی که بعد از آگهی مسعود جان دانشپور در کامنت های بعضی کانال ها دیدم، و دارا جان فرصت صحبت کردن رو بهم نداد ولی بین رسیدگی ها به بچه مدام داشتم به حرف های رد و بدل شده و صحبت های مختلف شکل گرفته فکر میکردم.

میخواهم در این متن کمی دیکتاتور باشم و آدم ها را به دو دسته ی اصلی "doer" و "type Coder" تقسیم کنم، باقی افراد را در دسته ی "سایر" قرار میدم که قشر خاکستری و کمرنگ تر این بحث ها هستند.

اجازه بدهید قبل از هرچیز تعریف خودم رو از "type Coder" ارائه بدهم. عزیزان دلی که خیلی هم ارزشمند هستند و حقوق های خوبی هم میگیرند ولی تمرکزشان نوشتن کدهاییست برای پاس کردن درست DOD ها و تست ها و QA ها. این عزیزان تمرکز تمام و کمال دارند بر فریم ورک ها و زبان هایی که یادگرفته اند. بخش بزرگی از نیروهای سازمان ها را همین عزیزان تشکیل میدهند و اگر نبودند، قطعا خیلی از پیشرفت هایی که اکوسیستم کرده، تا به حال اتفاق افتاده نمی افتاد.

مسئله اینجا دایره ی دید و تمرکز سنگین این عزیزان بر دایره ی اطرافشان هست، چون مدام و هر لحظه در حال انجام دادن "تسک" ها هستند و فرصت و در اکثر موارد اجازه ی بزرگ تر دیدن مسائل و راهکارها را ندارند.

در مقابل "doer" ها کسانی هستند که اگر تسک های شبیه گروه قبل رو به این گروه بدهید، مدام با چرا و چطورهای مختلف روبرو خواهید شد.

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

اینجا تمرکز بر "مهندسی" ست ، یک یا چند لایه بالاتر از type Coding که بسیار قابل مشاهده ست در مواجهه با یک تسک، ابعاد مختلف اون بررسی میشه و خیلی از اوقات صحبت در این باره ممکنه به تغییر رویه اون تسک هم برسه.
اما تمرکز بحث ما، بیشتر روی "ابزار توسعه بودن زبان ها و فریم ورک ها" ست. پس بیاید با هم در این مورد دقیق تر بشیم.

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

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

فکر میکنم این حالت را خیلی جاهای دیگر هم لمس کرده باشید یا حداقل شنیده باشید.

اما حالت دوم، جایی که وارد سازمانی می شویم که سیستم غالب، بر خلاف تجربه ما که مثلا؛ عموما با دات نت کار کرده ایم قبل از این، با PHP یا هر زبان دیگری ست.
همینجا متذکر میشوم که شوخی و کل کل سر زبان ها همیشه متداول بوده ولی منطقا doer ها این مسئله را در سطح همان شوخی ها و کل کل ها نگه میدارند.
اما برای type Coder ها که وابسته به زبان و فریم ورک خودشان هستند، قضیه ناموسیست و حتی گاهی دچار وسواس های بیشتر هم می شوند که از آن عبور میکنیم.


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

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

امیدوارم که توانسته باشم منظورم را درست رسانده باشم.

با عشق
مسعود بیگی
چند روز بعد از بازگشت #رسمیو به میدان ها.
👍71
Forwarded from .NET Fun
Media is too big
VIEW IN TELEGRAM
ساختن چت بات با Ollama و Semantic Kernel ساده تر از اونی هست که فکر میکنید.

بخشی از دوره Fundamentals Of Building Microservices

👈👈 معرفی دوره 👉👉

✏️✏️ ثبت نام ✏️✏️

20 درصد تخفیف فقط تا جمعه با کد summer404

دانلود کد های این بخش
🔥2
Forwarded from refhub
بعد از به فنا رفتن مجدد libgen ، امروز دیدیم که https://annas-archive.org/ هم به فنا رفت ، حداقل سرویس هاش در دسترس نیست.
ولی ما نزدیک 20 هزارکتاب رو هنوز دایرکت لینک داریم روی S3 اختصاصی خودمون.
👍5🔥2
TondTech
بچه ها فرشته از دوستان ماست، متاسفانه سرطان خون و شرایط سخت زندگی و اقتصادی روزهای سختی رو براش رقم زده. در صورت امکان حمایتش کنید 🙏🌱 فرض کنید این حمایت شما عیدی به منه
سلام رفقا، شبتون به خیر، خواستم بگم به فرشته سر زدیم و تا اونجا که از دستمون براومد کمک کردیم. ولی مشکل داره هنوز، اگر براتون مقدوره کمکش کنید دوباره، هرچقدر که در توانتون هست، شرایط بعد از جنگ برای همه مون سخته و زیاد سخت نگیرید ولی با هر رقمی که میتونید در این کار خیر شریک باشید.

با عشق
عمو
16🔥3
Forwarded from tech-afternoon (Amin Mesbahi)
#️⃣ در ستایش اعداد...
1️⃣ قسمت اول: کُدمتریکس

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

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

📈 انواع رایج Code Metrics

متریک Cyclomatic Complexity (CC): این شاخص، پیچیدگی منطقی کد رو بر اساس تعداد مسیرهای مستقل اجرا در یک تابع یا متد اندازه‌گیری می‌کنه. هر عبارت شرطی، حلقه یا انشعاب جدید، این عدد رو افزایش می‌ده. پیچیدگی بالا نشون‌دهنده‌ی کد دشوارتر برای درک، تست، و نگهداریه. معمولاً پیچیدگی کمتر از ۱۰ مطلوب، بین ۱۰ تا ۲۰ قابل قبول و بالاتر از ۲۰ نیازمند بازطراحیه.

متریک Lines of Code (LOC): این شاخص، تعداد خطوط کد موجود در یک پروژه یا ماژول رو اندازه‌گیری می‌کنه. معمولاً به دو صورت SLOC (Source Lines of Code) که شامل خطوط حاوی کد اجراییه و KLOC (Kilo Lines of Code) که هر هزار خط کد رو نشون می‌دن، ارائه می‌شه. این متریک اگرچه ساده است اما می‌تونه شاخص تقریبی از پیچیدگی و حجم پروژه باشه، هرچند نمی‌تونه به تنهایی کیفیت کد رو تعیین کنه.

متریک Maintainability Index (MI): این شاخص ترکیبیه که کیفیت نگهداری کد رو بر اساس عوامل مختلف از جمله پیچیدگی، حجم کد، تکرار و مستندات محاسبه می‌کنه. مقدارش بین ۰ تا ۱۰۰ است که عدد بالاتر نشون‌دهنده کد قابل نگهداری‌تره. این متریک به توسعه‌دهنده‌ها کمک می‌کنه تا قسمت‌های کد که نیاز به بهبود داره رو شناسایی کنیم.

متریک Cognitive Complexity: یکی از متریک‌های مدرن و پیشرفته‌تر برای اندازه‌گیری پیچیدگی کده که برخلاف Cyclomatic Complexity که صرفاً تعداد مسیرهای اجرا رو می‌شماره، تمرکز اصلیش روی میزان دشواری درک کد از دیدگاه ذهن انسانه. هدف اصلیش پیش‌بینی میزان تلاش ذهنی مورد نیاز برای خوندن، درک و اصلاح کده.

متریک Depth of Inheritance: یکی از متریک‌های مهم در برنامه‌نویسی شی‌گرا است که عمق سلسله مراتب وراثت در یک کلاس رو اندازه‌گیری می‌کنه. این متریک تعداد کلاس‌های والد (ancestor classes) که یک کلاس خاص ازشون ارث‌بری می‌کنه رو می‌شماره. این متریک اهمیت زیادی در ارزیابی پیچیدگی طراحی داره چون عمق وراثت بالا که بعضا هنر و سواد بالای طراحی برنامه‌نویس تصور/تخیل می‌شه، مشکلات متعددی ایجاد می‌کنه.

متریک Coupling and Cohesion: میزان وابستگی بین ماژول‌ها و کلاس‌های مختلف رو اندازه‌گیری می‌کنه که کمتر بودنش مطلوبه. Cohesion هم درجه‌ایه که اجزای یک ماژول با هم مرتبط هستن، که بالا بودنش بهتره. این دو متریک کیفیت طراحی و معماری نرم‌افزار رو نشون می‌دن و کد با Coupling پایین و Cohesion بالا قابلیت نگهداری و توسعه بهتری داره.

متریک Code Duplication: این شاخص درصد کدی رو که در پروژه تکرار شده رو اندازه‌گیری می‌کنه. کد تکراری مشکلات زیادی ایجاد می‌کنه از جمله افزایش حجم کد، دشواری در نگهداری و احتمال بالای باگ. ابزارهای مختلف می‌تونن این تکرارها رو شناسایی کنن و پیشنهاداتی برای حذف یا اجماع اون‌ها ارائه بدن. معمولاً کمتر از 3% تکرار قابل قبول در نظر گرفته می‌شه. در ضمن منظور از تکرار، کپی نعل‌به‌نعل نیست، گاهی الگوی یکسان باعث مشابهت می‌شن ولو اینکه اسامی متفاوت باشه.

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

💬 چقدر به این متریک‌ها یا به صورت کلی‌تر، به اعداد اهمیت می‌دید؟ در مورد اعداد دیگه صحبت کنیم؟
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
Forwarded from Peivast | پیوست
This media is not supported in your browser
VIEW IN TELEGRAM
🔺 پشت پرده دستگیری مدیران رسمیو: دوران داده‌های باز در ایران به پایان رسیده است؟

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

🔹او از فشارها، چالش‌های پیش روی تیم و آینده این داده‌های باز در ایران می‌گوید؛ روایتی که می‌تواند تصویری تازه از آنچه در پشت پرده ماجرای رسمیو گذشت ارائه دهد.

🔹متن کامل این گفت‌وگو در شماره ۱۳۷ ماهنامه پیوست منتشر می‌شود و نسخه کامل ویدئویی آن نیز پس از انتشار، در دسترس خواهد بود.


🔗 لینک ویدیو در کانال یوتیوب پیوست

🔗 لینک ویدیو در کانال آپارات پیوست

🆔 @peivast
👍51🤣1
Forwarded from tech-afternoon (Amin Mesbahi)
#️⃣ در ستایش اعداد...
2️⃣ قسمت دوم: متریک‌های عملکرد تیم توسعه

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

توی قسمت دوم، چند متریک مرتبط با تحلیل رفتار تیم در طول اسپرینت‌ها و بازخوردهایی که از طریق Jira، GitHub/GitLab، و یا سایر سیستم‌های دخیل در چرخه توسعه نرم‌افزار رو مرور می‌کنیم.

📈 متریک‌های تحلیلی تیم در اسپرینت‌ها

معیار Capacity: ظرفیت تیم و تک‌تک افراد برای انجام کار که با عدد story point سنجیده می‌شه، قبل از شروع اسپرینت باید مرخصی و... رو لحاظ کرد، و به صورت دوره‌ای هم بررسی capacity در کنار velocity و burn down و... باید برای تخمین بهتر و تدقیق اعداد لحاظ بشه.

معیار Velocity: نرخ تحویل تیم در هر اسپرینت، معمولاً بر حسب story points یا تعداد آیتم‌های کامل‌شده اندازه‌گیری می‌شه. اگرچه این عدد در بلندمدت معنا پیدا می‌کنه، اما کاهش یا نوسان زیادش ممکنه نشونه‌ی مشکلاتی در planning، تمرکز تیم یا دخالت‌های خارج از برنامه باشه.

معیار Capacity Utilization: این متریک نشون می‌ده که چه درصدی از ظرفیت اعلام‌شده‌ی تیم واقعاً صرف تحویل کار شده. تطابق نداشتن capacity و velocity می‌تونه نشونه‌ای از کارهای ad-hoc، باگ‌های اضطراری، یا estimation ضعیف باشه. اگر همیشه ۱۰۰٪ باشه، احتمالاً تیم over-committed هست و خطر burnout بالاست. اگر مدام کمتر از ۷۰٪باشه، ممکنه مشکل در تخمین‌گذاری یا تعریف کارها باشه. بهینه معمولاً بین ۷۵-۸۵٪ در نظر گرفته می‌شه.

معیار Commitment Reliability (Planned vs Delivered): مقایسه بین storyها و وظایفی که در ابتدای اسپرینت برنامه‌ریزی شدن با اون‌هایی که واقعاً کامل شدن. عدد پایین معمولاً نشونه‌ی overcommitment یا تغییر اولویت‌ها در طول اسپرینت هست.

معیار Bug Trend per Sprint: تحلیل تعداد باگ‌های گزارش‌شده، اولویت‌هاشون، و نسبت اون‌ها به featureهای جدید می‌تونه نشون‌دهنده‌ی کیفیت تحویل، فشار کاری بیش از حد، یا ناکارآمدی در QA باشه.

معیار Sprint Goal Achievement Rate: درصد اسپرینت‌هایی که هدف اصلی‌شون رو به طور کامل محقق می‌کنن. این متریک مهم‌تر از velocity خامه، چون نشون می‌ده تیم چقدر روی اهداف تجاری متمرکزه. نرخ کمتر از ۷۰٪ نشانه مشکل در برنامه‌ریزی یا اولویت‌بندیه.

ادامه دارد...

عددها همیشه حرف آخر رو نمی‌زنن، اما خیلی وقت‌ها شروع بهتری برای گفت‌وگو و تصمیم‌های جمعی هستن. ترکیب داده‌های Jira، Git، CI/CD، و ابزارهای متنوع موجود یا استفاده از API پلتفرم‌ها برای استخراج و بعدش آنالیز اعداد، می‌تونه دید بسیار روشنی از سلامت فرآیند توسعه و رفتار تیم به ما بده و این جزوی از وظایف engineering managerها یا team leadهاست که نسبت به اعداد بی‌تفاوت نباشن و به صورت روشمند تحلیل کنن...

💬 چقدر عدد توی تیمتون مهمه و چه متریک‌هایی رو دنبال می‌کنید؟ داده‌های کمی چقدر توی تصمیم‌گیری‌ها دخیلن؟
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
Forwarded from Learning With M
فقط ۱۴ ثانیه!

چند وقت پیش پستی در لینکدین دیدم که یکی از عزیزان از این‌که رزومه‌اش تنها در ۱۴ ثانیه رد شده بود ناراحت بود.

نظرم رو در کامنت نوشتم: به‌عنوان کسی که بارها رزومه بررسی کرده، این ۱۴ ثانیه برای یک رزومه عدد عجیبی نیست!

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

🎯 «رویداد ۱۴ ثانیه‌ای!»

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

اگه دوست داری بدونی توی اون ۱۴ ثانیه چه اتفاقی برای رزومه‌ات می‌افته، این رویداد دقیقاً برای توئه.

📌 اگر علاقه‌مندی:

ثبت نام کن ← عضو گروه اطلاع رسانی ای که در پروفایلت بعد از ثبت نام قرار میگیره بشو ← رزومتو بفرست و روز جلسه آنلاین باش تا بررسی رزومتو ببینی.

منتظرت هستم تا با هم بفهمیم در ۱۴ ثانیه چقدر میشه تأثیر گذاشت!

لینک ثبت نام رایگان : https://yun.ir/14sec1
دوره شهریور ماه تکلید ۳۶۰ : https://yun.ir/tl3603
2
Forwarded from جادی | Jadi
💌 پیام وارده


جادی عزیزم سلام

ما کمپین رایگان شدن دوره های مکتب‌خونه رو با پیام همدلی در مسیر یادگیری شروع کردیم
۱۰۰ تا دوره تو حوزه های مختلف رو رایگان کردیم
از برنامه نویسی گرفته تا شبکه و هوش مصنوعی و کلی مهارت های نرم و حتی مثلا گیتار و فرانسوی و تعمیر خودرو و غیره
خلاصه بهترین دوره های مکتب‌خونه رو گلچین کردیم و رایگان کردیم تا آدما یادگیریشون رو متوقف نکنند
چون یادگیری باعث رشد همه و حال خوب و حس پیش رفتن و زنده بودن میده

این لینک دوره CEH شماس
https://mktb.me/3w7y/

اگه از کل کمپین هم حمایت کنی ممنونت میشم. هرچقدر آدمای بیشتری ببینن و بیام ازشون استفاده کنند ما حالمون بهتر میشه

این لندینگ همه دوره های رایگان شده س
https://mktb.me/txvk/

کد HAMDELI
10
Forwarded from iCodeNext
StyleCop.Analyzer and EditorConfig

🌀 خیلی وقت ها سورس کدهای تیم هارو میبینم چه به صورت متن باز در گیت هاب و یا به صورت خصوصی در شرکت ها که از این امکان استفاده نمیکنن. این شد که گفتم یه ویدیوی کوچیک هم ازش بسازیم. بد نیست، اگه شما هم استفاده نمیکنید، کم کم توی سورس خودتون اد کنیش. ( احتمال خیلی زیاد تقریبا همه باهاش کار کردند)


00:00 With Out EditorConfig
05:00 .editorConfig file
10:00 StyleCop.Analyzer package

🚢 پلی لیست : C# in a nutshell
🕶
مدت ویدیو : 15 دقیقه
📺
لینک ویدیو :
https://youtu.be/jKq1lbnC2g8

❤️❤️ بعد از 70 روز مجدد شروع کردم به تولید، واقعیتش اصلا تصمیمی به ادامه نداشتم، اما خوب دوستان لطف دارن و پیگیری میکنن که چرا چند وقتیه محتوی نمیاد. خلاصه بریم ببینیم چند چند هستیم. دمتون گرم.
10
Forwarded from tech-afternoon (Amin Mesbahi)
#️⃣ در ستایش اعداد...
3️⃣ قسمت سوم: متریک‌های همکاری تیمی و کیفیت تحویل در مخازن کد

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

*️⃣معیار Lead Time for Changes:
زمان بین باز شدن یک pull request تا merge نهایی، یکی از شاخص‌های کلیدی DevOps برای سنجش تحویل سریع و با کیفیته. افزایش Lead Time معمولاً به دلیل منتظر موندن برای review، test failure، یا فقدان reviewer فعاله.

*️⃣معیار Time to First Response: فاصله زمانی بین باز شدن PR و اولین بازخورد (review یا comment). زمان بالا نشونه‌ی کمبود تعامل، فقدان مسئولیت‌پذیری یا توزیع نامتوازن کارها توی تیمه.

*️⃣معیار Code Review Coverage:
نسبت PRهایی که حداقل یک بررسی‌کننده‌ی انسانی (non-author) داشتن. پوشش پایین می‌تونه امنیت، کیفیت و حتی حس تعلق تیمی رو تحت تاثیر قرار بده. اینکه ۱ نفر مرورکننده رو هم حذف یا جزو مستحبات حساب کنیم نتایج خوبی نداره؛ برخی شرکت‌های بزرگ تا ۱۲ نفر (به جز AI داخلی) هر PR رو مرور می‌کنن برای سنجش کیفیت و امنیت کد.

*️⃣معیار Pull Request Size:
اندازه‌ی PRها از نظر تعداد خطوط تغییر یافته. PRهای بزرگ‌تر باعث کاهش کیفیت review، فرسایش توجه reviewerها، و احتمال بیشتر برای بروز باگ می‌شن. عدد مناسب معمولاً زیر ۴۰۰ خطه (البته خودش شمارش خطوط کد بحث مفصلیه که انواع خط کد چیه؟ یا چجوری باید شمرد...)

*️⃣معیار Merge Frequency:
چند بار در روز یا هفته PR merge می‌شه؟ این عدد نشون می‌ده که آیا تیم به صورت پیوسته و در بازه‌های کوچک تحویل انجام می‌ده یا تحویل به صورت big-bang و آخر اسپرینت صورت می‌گیره. بازه‌های کوچک‌تر = ریسک کمتر = feedback سریع‌تر. البته به استراتژی و سیاست‌های توسعه نرم‌افزار شرکت خیلی وابسته است.

*️⃣معیار Pull Request Cycle Time:
زمان از باز کردن PR تا merge شدنش. این متریک شامل چند مرحله‌ست: Time to First Review، Review Duration، و Time to Merge. PR های که بیش از ۴۸ ساعت طول می‌کشن، معمولاً کیفیت کد و روحیه تیم رو تحت تأثیر منفی قرار می‌دن.

*️⃣معیار Rework Rate:
درصد تغییراتی که پس از merge، نیاز به اصلاح یا revert پیدا می‌کنن. عدد بالا می‌تونه نشونه‌ی ضعف در review یا تست ناکافی باشه.

*️⃣معیار Defect Escape Rate:
تعداد باگ‌هایی که بعد از merge به محیط‌های بالاتر (Staging یا Production) منتقل می‌شن. این عدد برای سنجش کیفیت تحویل و اثربخشی فرآیند تست قبل از ادغام حیاتیه.

*️⃣معیار Review Participation Rate:
نسبت اعضای تیم که در بازه‌ای مشخص، در reviewهای دیگران شرکت می‌کنن. مشارکت کم می‌تونه باعث ایجاد bottleneck یا کاهش کیفیت کد بشه.

*️⃣معیار Stale PRs
PRهایی که مدت زیادی باز می‌مونن بدون فعالیت. این موارد معمولاً نشان‌دهنده مشکلات در اولویت‌بندی، درگیری منابع، یا ابهام در نیازمندی‌هاست.

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

💡 «هیچ» بهبودی یهویی نخواهد بود...
و در عین حال بدون شروع ولو با گام‌های کوچیک هم چیزی محقق نمی‌شه!
Please open Telegram to view this post
VIEW IN TELEGRAM
اگه یه جایی بود، که کانال ها، بلاگ ها، یوتیوب و پادکست های فنی توش بودن و ملت بهش رای میدادن و خودشون هم اضافه می کردن به نظرتون باگش چی بود ؟
اسم فرضیش رو بزاریم WhiteList.com
👍2
Forwarded from DotNet | دات نت
۱۲ قاعدهٔ طلایی برای ترتیب Middleware در ASP.NET Core

اگر می‌خواهید اپلیکیشن ASP.NET Core شما پایدار، امن و قابل توسعه باشد، رعایت ترتیب صحیح Middlewareها (میان‌افزارها) حیاتی است. در ادامه ۱۲ گام کلیدی را برایتان آورده‌ام:

1️⃣ UseForwardedHeaders()
اگر پشت پروکسی هستید، حتماً اول این middleware را اضافه کنید تا آدرس کلاینت درست شناسایی شود.

2️⃣ UseHttpsRedirection()
قبل از همه‌چیز، کاربر را به HTTPS هدایت کنید تا ارتباط امن باشد.

3️⃣ UseRouting()
قبل از هر middlewareی که به اطلاعات مسیر نیاز دارد، این یکی را فراخوانی کنید.

4️⃣ UseCors()
بلافاصله بعد از Routing، اما قبل از Authentication، سیاست‌های CORS را اعمال کنید.

5️⃣ UseAuthentication()
تأیید هویت کاربران پیش از اعمال مجوزها باید رخ دهد.

6️⃣ UseAuthorization()
پس از Routing و Authentication بیاید تا قوانین دسترسی به درستی اجرا شود.

7️⃣ UseExceptionHandler()
نزدیک به بالای پشته برای گرفتن و مدیریت همه خطاها قرارش دهید.

8️⃣ UseRateLimiter()
اوایل pipeline تا از حملات DOS یا بار زیاد روی API جلوگیری کند.

9️⃣ UseResponseCompression()
بعد از Routing و پیش از endpoints تا پاسخ‌ها فشرده و کارایی بالاتر برود.

🔟 UseStaticFiles()
اگر فقط محتوای استاتیک می‌دهید، قبل از Routing قرارش دهید.

1️⃣1️⃣ Custom Middleware
(مثل Logging، Tracing و …) هر چه زودتر تا سراسر درخواست را پوشش دهد.

1️⃣2⃣ UseEndpoints()
حتماً آخرین Middleware باشد تا درخواست‌ها به endpoint مناسب برسند و pipeline خاتمه یابد.


---

با رعایت این ترتیب:
• از بروز خطاهای عجیب جلوگیری می‌کنید
• پرفورمنس و امنیت اپلیکیشن‌تان بالاتر می‌رود
• نگهداری و توسعهٔ کد ساده‌تر خواهد شد

🎺برای یادگیری بیشتر و دریافت مطالب مفید در زمینه .NET و برنامه‌نویسی، به کانال ما بپیوندید!

📚💻 @dotnetcode 🖥👨‍💻
Please open Telegram to view this post
VIEW IN TELEGRAM
💯95👍2👏1
دبیان ۱۳ با اسم رمز «Trixie» از راه رسید🎉🍻
توزیعی که هنوزم کاربرای ‎#لینوکس برای انتشارش لحظه‌شماری می‌کنن.
این‌بار دبیان با کلی تغییر مهم، خوش‌قولی در انتشار و نتایج خیره‌کننده بنچمارک‌ها، کاربراشو حسابی خوشحال کرد.

توضیحات بیشتر :
https://x.com/YaserShahi/status/1954696279373582589
2
#سرآوا سهام خود در #تخفیفان را به هم بنیانگذار شرکت واگذار کرد.
در راستای اجرای استراتژی خروج از سرمایه گذاری های صورت گرفته و پس از خروج موفق از #علی_بابا ، #گروه_دیجی_کالا ،#گروه_هزاردستان (دیوار، کافه بازار، ستون، بلد، کارنامه)، #نوار ،#الو_پیک، #ایوند ، و سایر سرمایه گذاری های صورت گرفته، این‌بار #سرآوا در قالب فروش سهام، تمام سهام خود در شرکت #تخفیفان را به هم‌بنیانگذار شرکت واگذار کرد و از ترکیب سهامداری #تخفیفان خارج شد.
از پرتفو #سرآوا فقط #کارخانه_نوآوری_آزادی (#همآوا) باقی مانده است.
💔421
میخواستم از جمنای استفاده کنم، برای کشیدن یه سری نمودارهای C4 مدل ، گفتم بزار اول یادآوری کنم بهش کلا کانتکس چیه و ازش پرسیدم میدونی C4 Model چیه، که ته توضیحاتش سورپرایز شدم !
7😍4