ساختار تیم‌های مدرن نرم‌افزاری قسمت چهارم: مدیریت ارتباطات بین اعضای تیم
مدیریت ارتباطات برای هر کار تیمی لازم است
موضوعی که در این نوشته از سری نوشته‌های "ساختار تیم‌های مدرن نرم‌افزاری" می‌خواهم درباره‌اش صحبت کنم، یک موضوع عمومی و تا حدی در حوزه روانشناسی است. اما من سعی می‌کنم درباره مدیریت ارتباطات در یک تیم نرم‌افزاری بر اساس تجربه خودم صحبت کنم.
نمی‌دانم شما هم تجربه کار در تیم‌های نرم‌افزاری که صبحشون با یک سلام و علیک شروع و عصرشون با یک خداحافظی تمام می‌شه و حداکثر چند جمله رسمی در ساعات کاری بین اعضای تیم رد و بدل می‌شه رو داشتید یا خیر؟ مشکل این تیم‌ها چیه؟ ضعف ارتباطات که به صورت مستقیم باعث ضعف در خروجی تیم خواهد شد.
شاید تعجب کنید که چطور ارتباط ضعیف باعث خروجی ضعیف تیم می‌شود؟ یکی از شایع‌ترین اثرات منفی ارتباط ضعیف، تشدید سندروم کدهای قشنگ من هست که در نوشته پذیرش مسئولیت بهش اشاره کردم. اگر من ارتباط مناسب و کافی با تیم نداشته باشم، هیچ وقت متوجه ایرادات کارم نخواهم شد و به جای پذیرش مسئولیت در قالب تیم و رفع مشکلات، همیشه دنبال پیدا کردن مقصر خواهم بود.
این اثبات شده که انسان‌ها، وقتی شکست می‌خورند دیگران را در اون شکست مقصر می‌دانند و وقتی پیروز می‌شوند سهم خودشان را در پیروزی بیشتر می‌دانند (چند بار ترافیک را بهانه دیر رسیدن به جلسات کردید در حالی که دیر راه افتادن خودتان دلیل اصلی بوده؟)
راه حل چیه؟ حرف بزنیم، درباره خودمان، کار و مشکلاتش. این دیدگاهی هست که مثلاً جلسات روزانه اسکرام هم با اصول و قواعد خودشون برای بهتر کردن خروجی تیم ازش استفاده می‌کنند: ارتباط برقرار کردن بین اعضای تیم
نکات مهم در برقراری و حفظ ارتباط موثر در تیم‌های نرم‌افزاری
اولین و مهم‌ترین نکته‌ای که در ارتباط با هم تیمی‌هایتان در یک تیم نرم‌افزاری باید در نظر داشته باشید این است که هیچ وقت و تحت هیچ شرایطی به تصویری که هم تیمی شما از خودش دارد حمله نکنید! احترام به تصویر درونی افراد اولین اصل برقراری ارتباط موثر هست.
اگر developer شما فکر می‌کنه بتمن هست، اگر بت موبیل در اختیارش نمی‌گذارید، مهم نیست اما اگر بهش بگید بتمن نیست، احتمالاً دیگه نمی‌تونید روی کمکش به تیم حتی به عنوان بت کید حساب کنید!
اگر حتی با تایید اکثریت، همکار و هم‌تیمی شما دچار توهم خودخفن‌پنداری هست، باز هم راه درست شدنش اشاره مستقیم نیست. تجربه نشون می‌ده که وقتی به هویتی که آدم‌ها برای خودشان تصور می‌کنند حمله کنید، اکثر آدم‌ها احساس خطر می‌کنن و واکنش تهاجمی برای دفاع از خودشون نشان خواهند داد. نتیجه این رفتار، بروز تنش ناخواسته در تیم هست. تنشی که علاوه بر روحیه اعضای تیم، بر روی روابط آینده اون‌ها و نرم‌افزار خروجی تیم هم تاثیر نامطلوب خواهد داشت.
نکته بعدی در برقراری و حفظ ارتباط موثر، خوب دیدن و خوب گوش دادن هست. اگر دید شما نسبت به یک برنامه‌نویس مثل نگاه به یک کارگر خط تولید یک کارخانه باشه که مثل یک ربات باید خروجی تحویل بده، این نوشته برای شما نیست. اما اگر به برنامه‌نویس، نه به شکل یک ربات که به شکل یک انسان نگاه می‌کنید پس با توجه به اینکه خروجی کارش متاثر از فکرش هست (و نه نیروی بازو) بنابراین باید بتونید شرایط و محیط دوستانه‌ای رو فراهم کنید که افراد تیم بتوانند با هم حرف بزنند.
این نگاه انسانی به نیروی کار، حتی در حوزه‌های دیگه هم وارد شده: اخیراً مطلبی رو دیدم تحت عنوان "گوگل و سرمایه‌های انسانی" که نویسنده اشاره کرده بود که حتی نام بخش منابع انسانی یا سرمایه‌های انسانی (که در ایران بیشتر کارگزینی گفته می‌شه!) به بخش People Operations تغییر کرده، یا مثال دیگه در مورد تغییر ارزیابی و رتبه‌بندی سنتی در مایکروسافت و جایگزینی آن با جلسات حضوری تحت عنوان connect است.
نتیجه وجود این محیط دوستانه اینه که اعضای تیم با عشق تمام، کارشون رو شروع می‌کنند و به خاتمه می‌رسانند. نتیجه‌اش مثل ویدئوی github که در نوشته ساعات کار دلخواه بهش اشاره کردم هست که کارمند github اشاره می‌کنه به وضعیت زایمان خانمش و اینکه نتونسته بیاد سر کار و دیگران چقدر حمایتش کردند و از رئیسی که بگه فلان کار مونده و ... خبری نبوده و در نتیجه شرکت و همکارانش رو مثل خانواده‌اش می‌دونه.
اما این حرف زدن (در مورد کار) به تنهایی کافی نیست. باید مهارت گوش دادن موثر (و نه صرفاً شنیدن) و مشاهده موثر رفتارها را در خودتون (به عنوان مدیر تیم یا عضوی از تیم) تقویت کنید. بعد از تقویت این مهارت‌ها، افراد راحت‌تر به رشد و رفع نقایص خودشون و تیم کمک می‌کنند.
برای جلوگیری از طولانی شدن نوشته، ادامه موارد مربوط به مدیریت ارتباطات در تیم‌های نرم‌افزاری رو در نوشته دیگه‌ای با هم بررسی می‌کنیم.