وقتی مهارت تعهد می‌آورد، اما انگیزه عقب می‌ماند؛ چاره‌اندیشی برای یک چالش تیمی واقعی

روایت یک تیم نرم‌افزاری از تعارض پنهان بین تخصص، تعهد و رضایت

تهران – مهر ۱۴۰۴

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

🎯 از مهارت تا مسئولیت: مرز کجاست؟

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

در نگاه اول شاید ساده باشد: «کاری که قولش را دادی، انجام بده.» اما در نگاه اجایل، سوال مهم‌تری مطرح است:

آیا تیم با فرضیات مبهم پیش می‌رود، یا با توافق‌های شفاف و قابل بازنگری؟

🔍مشکل چیست؟

سه لایه از تعارض وجود دارد:

1. تفاوت برداشت از تعهد اولیه (توسعه‌دهنده vs تیم لید)

2. عدم تطابق بین مسئولیت و انگیزه (کار بیشتر، اما نارضایتی حقوق)

3. فقدان گفتگو درباره‌ ظرفیت واقعی و تعادل تیمی

🤝 راه‌حل اجایل: شفافیت، همدلی، همکاری

مدل اجایل به‌جای تحکم، بر پایه گفت‌وگو بنا شده است.
پیشنهادها:

• بازنگری توافقات کاری (Working Agreements): آیا انتظارات از ابتدا مشخص بوده یا بر اساس نیازهای لحظه‌ای شکل گرفته‌اند؟

• نقشه مهارت‌ها (Skill Mapping): تیم باید بداند چه مهارت‌هایی در اختیار دارد، و چطور می‌توان آن‌ها را به صورت عادلانه توزیع کرد.

• تقسیم بار کاری از طریق Pairing یا Swarming: اگر یک نفر تنها متخصص حوزه‌ای خاص است، وظیفه تیم است که این مهارت را پخش کند، نه اینکه فشار را متمرکز کند.

• مدیریت WIP: شاید مشکل، مهارت نیست؛ بلکه حجم بیش از حد کار در جریان است.

• فرهنگ قدردانی: گاهی مشکل مالی نیست—بلکه حس دیده‌نشدن.

Swarming (هجوم تیمی) Pairing (جفت‌کاری) چیست؟

👯‍♂️ Pairing (جفت‌کاری)

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

🐝 Swarming (هجوم تیمی)

🔹 یعنی دو نفر به‌طور همزمان روی یک آیتم کاری کار می‌کنند—معمولاً روی یک کامپیوتر (یا یک محیط کدنویسی/تحلیل).
🔹 یکی نقش Driver دارد (تایپ می‌کند) و دیگری Observer/Navigator است (فکر می‌کند، پیشنهاد می‌دهد).
🔹 مرتب جای‌شان را عوض می‌کنند.

• Pairing = دو نفر روی یک کار → برای دقت و یادگیری

• Swarming = چند نفر روی یک کار → برای سرعت و رهایی از گره

💡 تصمیم‌گیری متمرکز یا خودسازمان‌دهی؟

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

جمع‌بندی: راه‌حل اجایل، گفتگو و رشد است؛ نه اجبار

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

«تغییر با سرعت‌دهی به اعتماد اتفاق می‌افتد.»
“Change happens at the speed of trust.” – Stephen M.R. Covey
– استیفن ام. آر. کاوی

🧠 یعنی هرچه اعتماد بین اعضای تیم یا سازمان بیشتر باشد، تغییرات سریع‌تر و مؤثرتر اتفاق می‌افتند. بدون اعتماد، حتی بهترین برنامه‌ها هم به کندی پیش می‌روند یا اصلاً پیش نمی‌روند.