📌 چطور جلسات یک‌به‌یک سازنده و مفید داشته باشیم؟ بخش اول، از منظر عضو تیم

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

📌 چطور جلسات یک‌به‌یک سازنده و مفید داشته باشیم؟ بخش دوم، از منظر لیدر

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

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

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

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

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

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

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

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

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

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

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

💬 نظر و تجربه شما به عنوان لیدر یا عضو تیم از ۱:۱ چیه؟

#️⃣ در ستایش اعداد...
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 و جلوگیری خودکار از ورود کد فاقد متریک‌های قابل قبول به محیط‌های استیج و پروداکشن است.

💬 چقدر به این متریک‌ها یا به صورت کلی‌تر، به اعداد اهمیت می‌دید؟ در مورد اعداد دیگه صحبت کنیم؟

#️⃣ در ستایش اعداد...
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هاست که نسبت به اعداد بی‌تفاوت نباشن و به صورت روشمند تحلیل کنن...

💬 چقدر عدد توی تیمتون مهمه و چه متریک‌هایی رو دنبال می‌کنید؟ داده‌های کمی چقدر توی تصمیم‌گیری‌ها دخیلن؟