‫‫‫‫‫‫ بهره‌وری، بخش آخر - نقش عناصر تیمی - با سید محمدجواد بطحایی

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

با جواد درباره‌ی بهره‌ورری

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

حالا با این مقدمه، بریم سراغ قسمت پنجم با عنوان «بهره‌وری».
مهمون این قسمت، جواده.

سلام جواد! حالت چطوره؟

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

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

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

جواد:
حتماً. من حدود سال ۹۰ یا ۹۱ بود که وارد دنیای آی‌تی شدم. اون موقع برنامه‌نویسی رو جدی‌تر شروع کردم. اواخر دوران دانشجویی بودم و داشتم با محصولات اینترپرایز کار می‌کردم؛ چیزهایی مثل ERP یا سیستم‌هایی که تو زنجیره تأمین استفاده می‌شن.

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

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

تا اینکه حدود ۳–۴ سال پیش، یه تحول اساسی توی مسیرم ایجاد شد.

از نارضایتی مشتری تا کشف تفکر چابک

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

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

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

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

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

فرق مایندست با فریم‌ورک و متدولوژی چیه؟

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

به نظرت این مشکل از کجاست؟ چرا بعضی تیم‌ها فکر می‌کنن با اجرای یه فریم‌ورک همه‌چی حل می‌شه؟

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

ولی مایندست اون طرز فکریه که پشت همه‌ی تصمیم‌هاست.
یعنی:

• آیا من واقعاً باور دارم که تغییر لازمه؟

• آیا به فیدبک گرفتن اهمیت می‌دم؟

• آیا خودمختاری تیم رو می‌پذیرم؟

• آیا آماده‌ام شکست بخورم و ازش یاد بگیرم؟

اینا دیگه ربطی به فریم‌ورک نداره. اینا همون چیزاییه که می‌تونه باعث موفقیت یا شکست اجرای هر متد یا چارچوبی بشه.

پدرام:
یعنی اگه کسی فقط ظاهر اسکرام رو اجرا کنه ولی هنوز فکرش این باشه که تیم باید دستور بگیره و انجام بده، در واقع چابک نشده، درسته؟

جواد:
دقیقاً!
یه اصطلاح هست که می‌گه: «Doing Agile vs. Being Agile»
یعنی فقط داری یه کارهایی می‌کنی که شبیه چابکه، ولی واقعاً هنوز تفکر چابک توی تیمت جا نیفتاده.
من خیلی وقتا با تیم‌هایی کار کردم که داشتند اسکرام اجرا می‌کردن، ولی واقعاً همون ساختار سنتی مدیریت پروژه رو فقط توی یه شکل جدید ارائه می‌دادن.

پدرام:
یه جور اسکرام‌نما، نه اسکرام واقعی!

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

از کجا بفهمیم یه تیم آماده‌ی تغییر هست یا نه؟

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

تو از چه چیزهایی می‌فهمی؟ چی برات نشونه‌ست؟

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

ولی اگه فضا طوریه که همه فقط دارن تظاهر می‌کنن که همه‌چی رو می‌دونن، یعنی احتمالاً هیچ تغییری اتفاق نمی‌افته.

پدرام:
یعنی اون حس امنیت روانی که آدم بتونه ضعف یا اشتباهش رو مطرح کنه.

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

پدرام:
پس شفافیت، اعتماد... دیگه چی؟

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

پدرام:
و اینا همه مقدماتیه برای اینکه یه فریم‌ورک، واقعاً بتونه کار کنه تو اون فضا.

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

هر فریم‌ورک چه شخصیت و کارکردی داره؟

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

بیایم با اسکرام شروع کنیم. تو اسکرام رو چجوری تعریف می‌کنی؟

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

پدرام:
در واقع یه فریم‌ورک یادگیریه، نه فقط برنامه‌ریزی.

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

پدرام:
خب حالا بریم سراغ کانبان. فرقش با اسکرام چیه؟

جواد:
کانبان خیلی روان‌تره.
اگه اسکرام یه قطار زمان‌بندیه، کانبان یه رودخانه‌ست.
تو کانبان هیچ اسپرینتی وجود نداره، فقط جریان کاره.
تمرکز روی بهینه‌سازی فلوئه، یعنی کارت از لحظه‌ای که شروع می‌شه تا وقتی که تموم می‌شه، چقدر سریع و بدون گیر پیش می‌ره.
توی کانبان معمولاً می‌ری سراغ محدود کردن تعداد کارهای در حال انجام (WIP)، که خیلی تأثیرگذار و قدرتمنده.

پدرام:
خیلی‌ها فکر می‌کنن کانبان یعنی فقط ستون بکش و کارت بچسبون!

جواد:
متأسفانه آره!
ولی کانبان اصول خودش رو داره:

• بصری‌سازی

• مدیریت جریان

• محدودسازی کار در جریان

• بهبود تدریجی و تکامل

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

پدرام:
XP یا همون Extreme Programming رو چطوری می‌بینی؟

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

پدرام:
نکسوس و PSK چطور؟

جواد:
نکسوس بیشتر برای وقتیه که چند تیم اسکرام باید با هم روی یه محصول کار کنن.
مثل یه لایه هماهنگی برای چند تیم اسکرامی.
اما PSK یا Professional Scrum with Kanban، ترکیب دو دنیاست.
هم ساختار اسکرام رو داری، هم اصول کانبان رو برای بهبود جریان کار.
برای تیم‌هایی که اسکرام دارن ولی حس می‌کنن هنوز توی فلو مشکل دارن، PSK عالیه.

کِی کدوم فریم‌ورک؟ تصمیم‌گیری بر اساس مسئله، نه ابزار

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

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

مثلاً:

• اگه تیمی داریم که اصلاً کار در جریانشون رو نمی‌دونن، هیچ شفافیتی ندارن، خب شاید بهترین کار شروع با کانبان باشه.

• اگه تیمیه که نیاز به نظم زمانی داره و دوست داره ریتم داشته باشه، اسکرام بهتر جواب می‌ده.

• اگه چندتا تیم داریم که روی یه محصول مشترک کار می‌کنن، نکسوس یا SAFe رو باید بررسی کنیم.

• اگه تیم توسعه‌ای داریم که دنبال کیفیت کده، XP رو حتماً باید مد نظر داشته باشیم.

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

جواد:
آره، من همیشه این جمله رو می‌گم:
«مشکل رو با دقت ببین، بعد ابزار رو انتخاب کن. نه اینکه ابزار رو انتخاب کنی، بعد هی زور بزنی مشکل رو باهاش حل کنی.»

و گاهی هم لازمه ترکیبی کار کنیم. مثلاً یه تیم با اسکرام شروع کرده ولی توی فلو مشکل داره، خب PSK می‌تونه کمکش کنه.

پدرام:
یه چیز دیگه هم هست. بعضی وقتا سازمان یا تیم فقط یه فریم‌ورک رو قبول داره. یعنی مثلاً می‌گه فقط اسکرام!
تو این جور موقع‌ها چی کار باید کرد؟

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

فریم‌ورک بدون فرهنگ؟ یه دکور قشنگ ولی بی‌اثر

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

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

پدرام:
یه جورایی انگار فریم‌ورک می‌شه فقط یه ویترین. یه دکور قشنگ.

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

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

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

• اعتماد باشه

• باز بودن به تغییر وجود داشته باشه

• یادگیری ارزشی باشه، نه فقط شعار

• و آدم‌ها بتونن اشتباه کنن، بدون ترس از سرزنش

جواد:
آره. و نکته‌ی مهم اینه که این فرهنگ، یه شبه شکل نمی‌گیره.
ولی می‌شه ساختش. با کوچیک‌ترین تغییرها.
مثلاً اگه یه مربی یا لیدر، اولین نفری باشه که اشتباهش رو اعتراف کنه، اون یه جرقه‌ست.

پدرام:
مثل اینه که بذر فرهنگ رو می‌کاری، بعد کم‌کم با رفتار روزمره آبیاریش می‌کنی.

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

چرا تغییر این‌قدر سخته؟ از مقاومت تا تحول تدریجی

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

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

پدرام:
یعنی اون جمله‌ی معروف: "جهنم آشنا بهتر از بهشت ناآشنا!"

جواد:
آره دقیقاً همینه.
دومین دلیل، تجربه‌های قبلیه.
اگه قبلاً یه بار تغییری اومده باشه و بد اجرا شده باشه، یا باعث دردسر شده باشه، دیگه آدم‌ها شرطی می‌شن.
یعنی با خودشون می‌گن: «باز یه مدل جدید؟ ولش کن، قبلی هم بدتر شد.»

پدرام:
یه جور واکنش دفاعی.
و سومی؟

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

پدرام:
و اینجاست که مشارکت آدم‌ها توی طراحی تغییر خیلی کلیدی می‌شه.

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

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

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

تجربه‌های واقعی از تغییر: از زمین خوردن تا یاد گرفتن

پدرام:
جواد، تا اینجا خیلی خوب و تئوریک گفتیم که چرا تغییر سخته و چجوری می‌تونیم بسترش رو فراهم کنیم.
حالا بیا بریم سراغ تجربه‌های واقعی خودت.
تا حالا پیش اومده که بخوای تغییری ایجاد کنی و با شکست مواجه شی؟ یا برعکس، تغییری که واقعاً جواب داده باشه؟

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

پدرام:
چرا؟ چی باعث شد نشه؟

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

پدرام:
یه جورایی مثل این بود که بخوای بذر رو تو زمین شوره‌زار بکاری.

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

پدرام:
یعنی یه جور روند «تغییر از دل تیم»، نه «تحمیل از بیرون».

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

نقش رهبری در ساختن فضا برای چابکی

پدرام:
جواد، به نکته‌ی خیلی خوبی اشاره کردی.
اون لحظه‌ای که گفتی «مدیر تیم اشتباهش رو پذیرفت» واقعاً برام الهام‌بخش بود.
بیایم یکم عمیق‌تر وارد نقش رهبران و مدیران بشیم.
به نظرت یه لیدر یا مدیر، اگه بخواد فضای تیمش واقعاً چابک بشه، باید چه رفتارهایی از خودش نشون بده؟

جواد:
سؤال خیلی خوبیه.
اول از همه، رهبر باید خودش الگوی شفافیت باشه.
یعنی اگه می‌خوای تیمت شفاف باشه، اول باید خودت باشی.
اگه اشتباهی کردی، بگو. اگه چیزی رو نمی‌دونی، بگو. این رفتار، به تیم پیام می‌ده که «اینجا جای امنیه برای صداقت».

پدرام:
و همین باعث می‌شه بقیه هم احساس امنیت کنن برای بیان واقعیت‌ها.

جواد:
دقیقاً.
دومین ویژگی، توانایی گوش‌دادنه، نه فقط شنیدن.
خیلی از مدیرها حرف تیم رو می‌شنون ولی واقعاً گوش نمی‌دن.
یه رهبر خوب باید بتونه مکث کنه، فضا بده، و از دریچه‌ی نگاه تیم، دنیا رو ببینه.

پدرام:
یه جور همدلی فعال.

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

پدرام:
یعنی از فضای ترس به فضای رشد حرکت کنیم.

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

پدرام:
و این رها کردن، یعنی اعتماد واقعی.

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

استخدام، فرهنگ و تأثیرش روی بهره‌وری تیم

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

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

پدرام:
دقیقاً. حالا سؤال اینه: استخدام درست یعنی چی؟ دنبال چی باید باشیم؟

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

پدرام:
یعنی باید دنبال سازگاری فرهنگی باشیم، نه فقط رزومه‌ قوی.

جواد:
آره، من بهش می‌گم "Culture Add" نه فقط "Culture Fit".
یعنی دنبال آدمی باش که بتونه چیزی به فرهنگ تیمت اضافه کنه، نه فقط جا بشه توی قالب فعلی.

پدرام:
این فوق‌العاده‌ست. حالا بگو توی مصاحبه‌ها دنبال چه نشونه‌هایی می‌گردی که بفهمی اون فرد احتمالاً با فرهنگ چابک جور درمیاد؟

جواد:
من معمولاً دنبال اینم ببینم:

• چقدر راحت درباره‌ی اشتباهاتش حرف می‌زنه؟

• آیا تجربه‌ای از یاد گرفتن از شکست داره؟

• آیا توی تیم‌هایی کار کرده که تصمیم‌گیری جمعی بوده؟

• چقدر در برابر تغییر انعطاف‌پذیره؟

اینا برای من مهم‌تر از اون چیزیه که تو رزومه نوشته شده.

پدرام:
یعنی در واقع یه جور غربالگری برای مایندسته.

جواد:
دقیقاً. چون اگه مایندست نباشه، حتی با بهترین فریم‌ورک هم، تیم به انسداد می‌خوره.
ولی اگه آدم با مایندست درست بیاد تو تیم، خیلی راحت‌تر یاد می‌گیره، رشد می‌کنه، و به تیم کمک می‌کنه بهتر بشه.

جمع‌بندی و اولین قدم برای ساختن تیم چابک

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

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

پدرام:
یه جور مشاهده‌ی بی‌قضاوت؟

جواد:
دقیقاً.
دومین نکته اینه که کوچیک شروع کن.
لزومی نداره از فردا صبح بگی «ما از این به بعد اسکرام داریم!»
کافیه بگی: «بیاید یه برد بزنیم ببینیم رو چه کارهایی داریم کار می‌کنیم»
همین یه حرکت ساده می‌تونه آغازگر شفافیت و گفت‌وگو باشه.

پدرام:
یعنی به‌جای آوردن فریم‌ورک، دعوت به گفت‌وگو کنیم.

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

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

جواد:
مرسی از تو. گفت‌وگو باهات همیشه برام الهام‌بخشه.

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

خدانگهدار.