درک علل ریشه ای تعارض در تیم های مهندسی

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

  • اختلاف نظرهای فنی: نظرات در مورد انتخاب های معماری، ابزار، استانداردهای برنامه نویسی، یا روش های پیاده سازی سالم هستند، این ها در صورت بحث سازنده، اما می تواند افزایش یابد اگر خود شخصی به یک راه حل خاص متصل شود.
  • تجزیه و تحلیل ارتباطات: انتظارات بدخواهانه، الزامات نامشخص، یا به روز رسانی های بی نظیر، از راه دور و تیم های هیبریدی به ویژه در برابر این آسیب پذیر هستند، زیرا ارتباطات نوشته شده فاقد لحن و زبان بدن است.
  • ] [بخش اول و تعارض اولویت: [FLT 1 ] تقاضاهای رقابتی برای زمان محدود، بودجه یا پرسنل.هنگامی که دو ویژگی توسط ذینفعان مختلف اولویت بالا محسوب می شوند، تنش در میان اعضای تیم ایجاد می شود که باید تصمیم بگیرند که در کجا تمرکز کنند.
  • طرح و نقش ابهام: [FLT 1] مالکیت عمو، مسئولیت های همپوشانی، و یا اختیارات تصمیم گیری تعریف نشده، بدون محافظان روشن، وظایف ممکن است تکرار یا نادیده گرفته شود، سرخوردگی پرورش.

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

استراتژی های اصلی برای حل مناقشات مهندسی

۱- تشویق ارتباطات باز

ایجاد یک محیط امن از نظر روانی که اعضای تیم می توانند بدون ترس از تلافی، نگرانی های خود را بیان کنند، پایه حل تعارض است.رهبران باید با اعتراف به اشتباهات و دعوت از مخالفت، آسیب پذیری های روزانه را به صورت مختصری از "blockers" که به طور عادی باعث اختلاف نظر های عمیق تر می شود، در نظر بگیرند انجمن های ساختار یافته مانند "retrospectivetivetives" که در آن تمرکز بر بهبود است، نه سرزنش.

تمرین گوش دادن فعال

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

۳- شناسایی و Reframe اهداف مشترک

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

۴- تسهیل رسانه های

هنگامی که گفتگوی مستقیم شکست می خورد، یک شخص ثالث خنثی – مانند یک رهبری فناوری، مدیر مهندسی یا واسطه اختصاصی – می تواند به نقش واسطه کمک کند، راه حل را تحمیل نمی کند، بلکه برای هدایت بحث، اطمینان حاصل می کند که هر طرف شنیده می شود و به تیم کمک می کند تا گزینه های سازش را بررسی کند.

۵- ایجاد نقش های روشن و مسئولیت های مسئولیت

بسیاری از درگیری های مهندسی از ابهام ناشی می شود که چه کسی دارای چارچوب هایی مانند RACI (Responsponsible، Accountable، Inform) برای روشن کردن اختیارات تصمیم گیری است.به عنوان مثال، یک مهندس ارشد ممکن است برای نوشتن کد "مسئولانه" باشد، اما رهبری فناوری "حساب" برای جهت معماری است.

۶- ترویج حل مسئله همکاری

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

پیاده سازی سیاست های حل تعارض رسمی

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

پرورش فرهنگ مثبت تیمی که مانع از تعارض می شود

ایمنی روانشناختی به عنوان یک پیشگیری

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

ارتباطات شفاف Rituals

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

شناسایی و حلقه های بازخورد

بازخورد منظم، ساختار یافته – هم مثبت و هم سازنده – باعث ایجاد خشم می شود. پیاده سازی یک سیستم تشخیص سبک (به عنوان مثال، کانال ضعیف #kudos) و بررسی های 360 درجه ماهانه می شود، زمانی که بازخورد منفی می دهد، از مدل SBI (Situation-Bavior-Impact) برای ایجاد هدف و انجام این درگیری طبیعی به جای یک حمله شخصی استفاده می کند.

ساخت تیم با هدف

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

سناریوهای عملی و چگونگی پیاده سازی این استراتژی ها

سناریوی 1: عدم توافق معماری

تعارض: دو مهندس ارشد در مورد استفاده از React یا Vue برای یک جبهه جدید اختلاف نظر دارند.

[FLT: 1] مدیر جلسه ای را تسهیل می کند که هر دو الزامات اصلی خود را فهرست می کنند (عملکرد، پشتیبانی جامعه، منحنی یادگیری) آنها با یک ویژگی کوچک در هر دو چارچوب بیش از یک سرعت، پس از بررسی هر دو نمونه اولیه، آنها یکی را انتخاب می کنند که مطابق با معیارهای بیشتر، این درگیری را به تصمیم گیری داده محور تبدیل می کند.

سناریوی 2: تنش بین فردی

تعارض: یک مهندس جوان احساس می کند که کد خود را به طور مداوم "انتخاب" توسط یک بررسی ارشد، منجر به خشم و عقب نشینی.

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

سناریوی 3: تعارض منابع بین تیم ها

تعارض: دو تیم محصول نیاز به زمان همان مهندس DevOps برای استقرار ویژگی های حیاتی قبل از همان مهلت.

در عمل: مدیر مهندسی یک جلسه اولویت بندی با هر دو مدیر محصول و شناسایی بالاترین تاثیر کسب و کار مذاکره می کند: 60٪ زمان به تیم A برای دو هفته، سپس 40٪ به تیم B، با نقاط عطف روشن، آنها همچنین سند تجارت - اخراج و ارتباط با چرا برخی از ویژگی های تصمیم گیری شفاف است.

نتیجه گیری

حل تعارض موثر در تیم های مهندسی در مورد اجتناب از اختلافات نیست - بلکه در مورد کانال سازی آنها به طور مولد است.با درک علل ریشه، استفاده از استراتژی های ساختاری مانند ارتباطات باز، گوش دادن فعال و میانجیگری، و به طور فعال ساخت فرهنگ از ایمنی روان شناختی و شفافیت، تیم ها می توانند تعارض را به یک راننده نوآوری تبدیل کنند، به جای یک منبع اختلال در خواندن عمیق تر، منابع را کشف کنند [FETF]