اپیگراف:
روزی روزگاری جوجه تیغی و خرس کوچولو در جنگل با هم آشنا شدند.
- سلام جوجه تیغی!
- سلام خرس کوچولو!
بنابراین، کلمه به کلمه، شوخی به شوخی، جوجه تیغی توسط خرس کوچولو مورد اصابت قرار گرفت...
در زیر بحثی از رهبر تیم ما، و همچنین مدیر توسعه محصول RAS، ایگور مارنات، در مورد ویژگی‌های تضادهای کاری و روش‌های ممکن برای مدیریت آنها وجود دارد.
بیشتر تضادهایی که در محل کار با آن مواجه می شویم، بر اساس سناریویی مشابه آنچه در قسمت بالا توضیح داده شده است، ایجاد می شود. چندین شرکت کننده وجود دارند که در ابتدا نسبت به یکدیگر کاملاً مساعد هستند؛ آنها سعی می کنند مشکلی را حل کنند، اما در نهایت مشکل حل نشده باقی می ماند و به دلایلی روابط بین شرکت کنندگان در بحث خراب می شود.
زندگی متنوع است و تغییرات در سناریویی که در بالا توضیح داده شد رخ می دهد. گاهی اوقات رابطه بین شرکت کنندگان در ابتدا خیلی خوب نیست، گاهی اوقات حتی مسئله ای وجود ندارد که نیاز به راه حل مستقیم داشته باشد (مثلاً در اپیگراف)، گاهی اوقات بعد از بحث رابطه مانند قبل از شروع آن باقی می ماند، اما مشکل در نهایت حل نمی شود
در همه موقعیت هایی که می توان آن را به عنوان وضعیت تعارض کاری تعریف کرد، چه چیزی مشترک است؟
اولا، دو یا چند طرف وجود دارد. این احزاب می توانند مکان های مختلفی را در سازمان اشغال کنند، در یک رابطه برابر (همکاران در یک تیم)، یا در سطوح مختلف سلسله مراتبی (رئیس - زیردست)، فردی (کارمند) یا گروهی (در موارد تضاد بین یک) باشند. کارمند و یک تیم یا دو تیم) و غیره. احتمال تعارض و سهولت حل آن تا حد زیادی تحت تأثیر سطح اعتماد بین شرکت کنندگان است. هرچه طرفین یکدیگر را بهتر بشناسند، سطح اعتماد بالاتر، شانس بیشتری برای رسیدن به توافق دارند. به عنوان مثال، اعضای یک تیم توزیع شده که هرگز رو در رو تعامل نکرده اند، نسبت به افرادی که حداقل چند تعامل رو در رو داشته اند، بیشتر احتمال دارد که بر سر یک موضوع کاری ساده دچار تعارض شوند. بنابراین، هنگام کار در تیم های توزیع شده، بسیار مهم است که اطمینان حاصل شود که همه اعضای تیم به طور دوره ای به صورت حضوری با یکدیگر ملاقات می کنند.
ثانیاً، در شرایط تعارض در کار، طرفین در موقعیت حل و فصل یک موضوع هستند که برای یکی از طرفین، برای هر دو یا برای کل سازمان مهم است. در عین حال، به دلیل شرایط خاص، معمولاً طرفین زمان کافی و راه‌های متنوعی برای حل آن دارند (رسمی، غیررسمی، جلسات، نامه‌ها، تصمیمات مدیریتی، وجود اهداف و برنامه‌های تیم، واقعیت یک سلسله مراتب و غیره). این با وضعیت حل یک موضوع کاری (یا غیر کاری) در یک سازمان متفاوت است و مثلاً یک سؤال مهم را حل می کند: «ای بچه، شما اهل کدام منطقه هستید؟!» در خیابان، یا درگیری از اپیگراف. در مورد حل یک مسئله کاری، کیفیت فرآیند کار و فرهنگ حل مسائل در تیم اهمیت دارد.
ثالثاً، عامل تعیین کننده تعارض (از نقطه نظر بحث ما) این واقعیت است که طرفین فرآیند نمی توانند به طور مستقل به راه حلی برای موضوع برسند که مناسب همه طرف ها باشد. این وضعیت مستلزم مداخله یک شخص ثالث، یک داور خارجی است. این نکته ممکن است بحث برانگیز به نظر برسد، اما در اصل، اگر وضعیت مناقشه بدون دخالت داور خارجی با موفقیت حل شد، موضوع با موفقیت حل شد و روابط طرفین خراب نشد، این وضعیتی است که باید برای رسیدن به آن تلاش کنیم. . ما به احتمال زیاد حتی از چنین درگیری مطلع نخواهیم شد، یا پس از حل شدن به طور تصادفی متوجه خواهیم شد. هر چه یک تیم بتواند مسائل بیشتری را به تنهایی حل کند، موثرتر خواهد بود.
یکی دیگر از ویژگی های بارز تعارض که ارزش لمس کردن را دارد میزان شدت عاطفی در هنگام تصمیم گیری است. تعارض لزوماً با سطح عاطفی بالا همراه نیست. شرکت کنندگان مجبور نیستند فریاد بزنند و دستان خود را تکان دهند تا وضعیت، در اصل، یک درگیری باشد. مسئله حل نشده است، تنش عاطفی خاصی وجود دارد (شاید در ظاهر به وضوح بیان نمی شود)، به این معنی که ما با وضعیت درگیری مواجه هستیم.
آیا اصلاً لازم است در موقعیت های درگیری مداخله کرد یا بهتر است اجازه دهیم حل آنها مسیر خود را طی کند و منتظر بمانیم تا مشکل خود به خود حل شود؟ نیاز به. حل و فصل کامل تعارض همیشه در اختیار یا صلاحیت شما نیست، اما در هر شرایطی، در یک درگیری در هر مقیاسی، می توانید موضع بزرگسالی بگیرید و از این طریق چندین نفر دیگر را در اطراف خود به سمت آن بیاورید و پیامدهای منفی آن را کاهش دهید. درگیری و کمک به حل آن.
قبل از بررسی چند نمونه از موقعیت های تعارض، اجازه دهید به چند نکته مهم مشترک در همه درگیری ها نگاه کنیم.
هنگام حل و فصل یک درگیری، مهم است که بالاتر از دعوا باشید، نه در درون آن (به این حالت "گرفتن یک موقعیت متا" نیز گفته می شود)، یعنی بخشی از یکی از طرفین در روند حل و فصل نباشید. در غیر این صورت، کمک داور خارجی به تصمیم گیری، تنها موقعیت یکی از طرفین را به ضرر طرف دیگر تقویت می کند. هنگام تصمیم گیری، مهم است که از نظر اخلاقی توسط همه طرف ها پذیرفته شود، همانطور که می گویند "خرید شده". به طوری که حتی اگر طرفین از تصمیم گرفته شده خوشحال نشدند، حداقل صمیمانه با اجرای آن موافقت کردند. همانطور که می گویند، قادر به مخالفت و تعهد. در غیر این صورت ، درگیری به سادگی ظاهر خود را تغییر می دهد ، آتش سوزان زیر باتلاق ذغال سنگ نارس باقی می ماند و در نقطه ای ناگزیر دوباره شعله ور می شود.
نکته دوم که تا حدی به مورد اول مربوط می شود این است که اگر قبلاً تصمیم به مشارکت در حل مناقشه گرفته اید، آن را تا حد امکان از نظر ارتباطات و مطالعه زمینه جدی بگیرید. با هر یک از طرفین شخصاً صحبت کنید. برای شروع، با هر کدام جداگانه. به پست بسنده نکن در مورد یک تیم توزیع شده، حداقل از طریق پیوند ویدیویی صحبت کنید. به شنیده ها و گزارش های شاهدان عینی بسنده نکنید. داستان را بفهمید، هر طرف چه می‌خواهد، چرا آن را می‌خواهد، چه انتظاری دارد، آیا قبلاً برای حل این موضوع تلاش کرده‌اند، اگر حل نشود چه اتفاقی می‌افتد، چه راه‌حل‌هایی می‌بینند، موضع خود را چگونه تصور می‌کنند. طرف مقابل، چه فکر می کنند، درست یا غلط، و غیره. تمام زمینه های ممکن را با ذهنی باز در ذهن خود بارگذاری کنید، با این فرض که همه درست می گویند. شما در درون تضاد نیستید، شما خارج از آن هستید، در یک فراپوزیسیون. اگر زمینه فقط در یک تاپیک پست موجود است، حداقل آن را به طور کامل و موضوعات و اسناد مربوط به آن را بخوانید. پس از خواندن آن، همچنان با صدای خود صحبت کنید. تقریباً مطمئن هستید که چیز مهمی را می شنوید که در نامه نیست.
سومین نکته مهم رویکرد کلی به ارتباط است. اینها چیزهای معمولی هستند، هیچ چیز کیهانی نیستند، اما بسیار مهم هستند. ما سعی نمی کنیم در زمان صرفه جویی کنیم، با همه شرکت کنندگان صحبت می کنیم، از فرد انتقاد نمی کنیم، اما عواقب اعمال او را در نظر می گیریم (نه "شما بی ادب هستید"، بلکه "شاید بچه ها ممکن است از این کار توهین شوند." این چیز»)، ما این فرصت را می دهیم که چهره را حفظ کنیم، بحث را شخصاً انجام می دهیم، نه جلوی صف.
تعارض ها معمولاً به یکی از دو دلیل ایجاد می شوند. اولی مربوط به این است که آیا شخص در زمان تعارض در موقعیت بزرگسال است یا در موقعیت کودک (در ادامه در این مورد بیشتر توضیح می دهیم). این به دلیل بلوغ عاطفی او، توانایی مدیریت احساساتش است (که اتفاقاً همیشه به سن او مربوط نمی شود). دومین دلیل رایج، ناقص بودن فرآیند کار است که موقعیت‌هایی از مناطق خاکستری ایجاد می‌کند که در آن مسئولیت بین شرکت‌کنندگان پراکنده می‌شود، انتظارات طرفین نسبت به یکدیگر شفاف نیست و نقش‌ها در فرآیند مبهم است.
بر این اساس، در حل یک تعارض (و همچنین هر موضوع دیگری)، یک مدیر باید سه دیدگاه را در نظر داشته باشد: کوتاه مدت - برای حل مسئله/تعارض اینجا و اکنون، میان مدت - برای به حداقل رساندن احتمال بروز تعارض دیگر. به همین دلیل و در دراز مدت - پرورش فرهنگ بزرگسالی در فرد تیم.
هر کدام از ما یک فرزند درونی داریم، حدوداً سه یا چهار ساله. او بیشتر اوقات در محل کار می خوابد، اما گاهی اوقات بیدار می شود و کنترل را به دست می گیرد. کودک اولویت های خودش را دارد. برای او مهم است که اصرار کند که این جعبه شنی اوست، مادرش او را بیشتر دوست دارد، ماشینش بهترین است (طراحی بهترین است، او بهترین برنامه‌ریزی می‌کند، ...). در شرایط درگیری، کودک می‌تواند اسباب‌بازی‌ها را فشار دهد، پاهایش را بکوبد و کاردک خود را بشکند، اما نمی‌تواند مسائل بزرگسالان (معماری راه‌حل، رویکردهای آزمایش خودکار، تاریخ انتشار و غیره) را حل کند، او به منافع فکر نمی‌کند. برای تیم. کودکی که در تعارض است را می‌توان تشویق کرد، دلداری داد و به رختخواب فرستاد و از او خواست با بزرگسالش تماس بگیرد. قبل از شروع بحث در یک موقعیت درگیری، مطمئن شوید که با یک بزرگسال صحبت می کنید، نه یک کودک، و خودتان در موقعیت یک بزرگسال هستید. اگر هدف صادقانه شما در حال حاضر حل یک مسئله جدی است، در موقعیت یک بزرگسال هستید. اگر هدف شما این است که پاهایتان را پاکوب کنید و تیغه شانه‌تان را بشکنید، این یک وضعیت کودکانه است. کودک درون خود را به رختخواب بفرستید و با یک بزرگسال تماس بگیرید یا بحث را دوباره برنامه ریزی کنید. شخص تصمیمی احساسی می گیرد و سپس به دنبال توجیه منطقی برای آن می گردد. تصمیمی که کودک بر اساس اولویت های کودکان گرفته شود بهینه نخواهد بود.
علاوه بر رفتار در زمان تعارض، موقعیت کودک یا بزرگسال نیز با سطح مسئولیتی مشخص می شود که فرد آماده است تا بر عهده خود باشد. در تظاهرات شدید خود، موقعیت کودکانه یک برنامه نویس، که من بیش از یک بار با آن ملاقات کرده ام، به این صورت است: من کد را نوشتم، آن را برای بررسی فرستادم - کارم تمام شد. داوران باید آن را بررسی و تایید کنند، QA باید آن را بررسی کنند، اگر مشکلی وجود داشت به من اطلاع می دهند. به اندازه کافی عجیب، حتی افراد نسبتا بالغ و باتجربه نیز گاهی اوقات این گونه رفتار می کنند. انتهای دیگر مقیاس این است که شخص خود را مسئول می داند که مطمئن شود کدش کار می کند، تحت آزمایش قرار می گیرد، شخصاً توسط او بررسی شده است، بررسی را با موفقیت پشت سر گذاشته است (در صورت لزوم، مشکلی برای پینگ کردن بازبین ها، بحث در مورد مسائل وجود ندارد. با صدا و غیره) و سرکوب شده است، QA در صورت لزوم کمک خواهد کرد، سناریوهای آزمایش شرح داده خواهد شد و غیره. در موارد عادی، برنامه‌نویس یا نزدیکتر به انتهای مقیاس بزرگسالان شروع می‌کند، یا با کسب تجربه به آنجا می‌رود (به شرطی که فرهنگ مناسب در تیم پرورش داده شود). در موارد شدید، او به کار خود ادامه می دهد، معمولاً موضعی کودکانه می گیرد، سپس او و تیم به طور دوره ای دچار مشکلات و درگیری می شوند.
پرورش فرهنگ صحیح و بالغ در یک تیم وظیفه مهمی برای هر مدیری است. این کار به زمان طولانی و تلاش روزانه نیاز دارد، اما نتیجه ارزش آن را دارد. دو راه برای تأثیرگذاری بر فرهنگ تیم وجود دارد - رهبری با مثال (که قطعاً دنبال خواهد شد؛ تیم همیشه به رهبر نگاه می کند) و بحث و پاداش دادن به رفتار درست. در اینجا هم هیچ چیز مبهم یا خیلی رسمی وجود ندارد، فقط هنگام بحث در مورد مشکلات، توجه کنید که می‌توانست در اینجا کاری انجام شود، تأکید کنید که وقتی درست تصمیم گرفته شده است، تمجید، یادداشت در طول بررسی انتشار و غیره.
بیایید چندین موقعیت درگیری معمولی، از ساده تا پیچیده را در نظر بگیریم:
درگیری هایی که به مسائل کاری مربوط نمی شود
اغلب اوقات درگیری هایی در کار وجود دارد که به مسائل کاری مربوط نمی شود. وقوع و سهولت حل آنها معمولاً مستقیماً با سطح هوش هیجانی شرکت کنندگان، سطح بلوغ آنها مرتبط است و به کمال یا ناقص بودن فرآیند کار مربوط نمی شود.
مثال‌های معمولی: شخصی اغلب به اندازه کافی از ماشین لباسشویی یا دوش استفاده نمی‌کند، که دیگران آن را دوست ندارند، کسی خفه می‌شود، در حالی که دیگران اگر پنجره را باز کنند باد می‌گیرند، شخصی خیلی پر سر و صدا است، و دیگران برای کار به سکوت نیاز دارند، و به زودی. بهتر است حل این گونه تعارضات را به تعویق نیندازیم و اجازه ندهیم مسیر خود را طی کنند. آنها به تنهایی حل نمی شوند و هر روز شما را از کار منحرف می کنند و جو تیم را مسموم می کنند. خوشبختانه، حل آنها معمولاً مشکل بزرگی نیست - فقط با یک همکار که بهداشت را نادیده می گیرد، آرام صحبت کنید (البته یک به یک)، صندلی راحت برای افرادی که سکوت/خنکی را ترجیح می دهند، بخرید، هدفون های جاذب صدا بخرید یا پارتیشن نصب کنید. ، و غیره.
مثال دیگری که در طول کار چندین بار با آن مواجه شدم، ناسازگاری روانی اعضای تیم است. به دلایلی، مردم به سادگی نمی توانند با هم کار کنند؛ هر تعاملی به یک رسوایی ختم می شود. گاهی اوقات این به این دلیل است که مردم در مورد یک موضوع مبرم (معمولاً سیاسی) دیدگاه های قطبی دارند و نمی دانند چگونه آنها را خارج از کار ترک کنند. متقاعد کردن آنها برای تحمل یکدیگر یا تغییر رفتارشان کار نسبتاً بیهوده ای است. تنها استثنایی که من با آن مواجه شده ام، همکاران جوان با ادراکات باز هستند؛ رفتار آنها هنوز هم می تواند به تدریج از طریق گفتگوهای دوره ای تغییر کند. معمولاً با جدا کردن آنها در تیم های مختلف، یا حداقل فراهم کردن فرصتی برای همپوشانی در محل کار به ندرت، مشکل با موفقیت حل می شود.
در تمام شرایط فوق، ارزش دارد که با همه شرکت کنندگان شخصا صحبت کنید، در مورد وضعیت بحث کنید، بپرسید آیا اصلاً مشکلی در این مورد می بینند یا خیر، بپرسید که به نظر آنها راه حل ها چیست و از مشارکت آنها در ایجاد این موضوع اطمینان حاصل شود. تصمیم گیری
از نظر بهینه سازی فرآیند کار (دیدگاه میان مدتی که اشاره کردم) اینجا کار زیادی نمی توان کرد؛ تنها نکته ای که برای بهینه سازی وجود دارد این است که هنگام تشکیل تیم، ضریب سازگاری را در نظر بگیریم و نفرات را قرار ندهیم. با هم پیشاپیش چه کسی درگیر خواهد شد.
از منظر فرهنگ تیمی، چنین موقعیت‌هایی کمتر در تیم‌هایی با فرهنگ بالغ اتفاق می‌افتد، جایی که افراد به تیم و همکاران احترام می‌گذارند و می‌دانند چگونه مسائل را به طور مستقل حل کنند. علاوه بر این، در تیم هایی که در آن سطح اعتماد بالایی وجود دارد، افراد برای مدت طولانی با هم کار کرده اند و/یا به طور مکرر خارج از محل کار با هم ارتباط برقرار کرده اند، این گونه درگیری ها بسیار راحت تر (اغلب به طور خودکار) حل می شود.
تعارضات مربوط به مسائل کاری:
این گونه درگیری ها معمولاً به هر دو دلیل به طور همزمان ایجاد می شوند، هم عاطفی (این واقعیت است که یکی از شرکت کنندگان در موقعیت بزرگسال نیست) و هم ناقص بودن خود فرآیند کار. شاید متداول ترین نوع درگیری هایی که من با آن مواجه شده ام، درگیری ها در طول بررسی کد یا بحث های معماری بین توسعه دهندگان باشد.
من دو مورد معمولی را در اینجا برجسته می کنم:
1) در حالت اول، توسعه دهنده نمی تواند یک بررسی کد از یک همکار دریافت کند. پچ برای بررسی ارسال می شود و هیچ اتفاقی نمی افتد. در نگاه اول، هیچ درگیری آشکاری بین دو طرف وجود ندارد، اما اگر به آن فکر کنید، این یک درگیری است. مشکل کار حل نشده است، یکی از طرفین (در انتظار بررسی) ناراحتی آشکاری را تجربه می کند. یک نوع فرعی افراطی این مورد، توسعه در یک جامعه یا در تیم های مختلف است، در حالی که ممکن است بازبینی کننده به این کد خاص علاقه نداشته باشد، به دلیل بارگذاری یا شرایط دیگر، ممکن است اصلاً به درخواست بررسی توجه نکند و داور خارجی (یک مدیر مشترک برای هر دو طرف) ) ممکن است اصلا وجود نداشته باشد.
رویکرد راه حلی که در چنین شرایطی کمک می کند دقیقاً به چشم انداز بلندمدت یعنی فرهنگ یک بزرگسال مربوط می شود. اول، فعالیت هوشمند کار می کند. نباید انتظار داشته باشید که کد آویزان شده در بررسی توجه خود بازبین را به خود جلب کند. ما باید به منتقدان کمک کنیم تا متوجه او شوند. پینگانی چند نفر، یک سوال در مورد سینکپ بپرسند، در بحث ها شرکت کنند. بدیهی است که سختگیری بیشتر از اینکه کمک کند آسیب می رساند، شما باید از عقل سلیم استفاده کنید. ثانیا، آماده سازی به خوبی کار می کند. اگر تیم بفهمد که چه اتفاقی می‌افتد و چرا، چرا اصلاً به این کد نیاز است، طرح از قبل با همه مورد بحث و توافق قرار گرفته است، مردم بیشتر به چنین کدی توجه می‌کنند و آن را برای کار می‌پذیرند. ثالثاً اختیار کار می کند. اگر می خواهید مورد بازبینی قرار بگیرید، خودتان بررسی های زیادی انجام دهید. بررسی های با کیفیت بالا، با بررسی های واقعی، آزمایش های واقعی و نظرات مفید انجام دهید. اگر نام مستعار شما در تیم شناخته شده باشد، احتمال بیشتری وجود دارد که کد شما مورد توجه قرار گیرد.
از نقطه نظر گردش کار، بهبودهای ممکن در اینجا اولویت بندی صحیح با هدف کمک به توسعه دهنده برای دستیابی به اهداف خود و تیم است (بررسی دیگران، نوشتن نامه به جامعه، همراه کردن کد با توضیحات معماری، مستندات، آزمایش ها، شرکت در بحث با جامعه و غیره)، از ماندن وصله ها در صف برای مدت طولانی و غیره جلوگیری کنید.
2) دومین مورد متداول تداخل در حین بررسی کد یا طراحی، دیدگاه های مختلف در مورد مسائل فنی، سبک کدنویسی و انتخاب ابزار است. در این مورد، میزان اعتماد بین شرکت کنندگان، تعلق به یک تیم و تجربه کار با یکدیگر از اهمیت زیادی برخوردار است. بن بست زمانی اتفاق می افتد که یکی از شرکت کنندگان موضعی کودکانه بگیرد و سعی در شنیدن آنچه که طرف مقابل می خواهد به او منتقل کند، نیست. اغلب، هم رویکرد پیشنهادی طرف مقابل و هم رویکرد پیشنهادی در ابتدا ممکن است با موفقیت کار کنند و اصولاً فرقی نمی‌کند که کدام یک را انتخاب کنیم.
یک روز، یک برنامه نویس از تیم من (بیایید او را پاشا بنامیم) یک پچ با تغییراتی در سیستم استقرار بسته آماده کرد که توسط همکاران یک بخش همسایه توسعه و پشتیبانی شد. یکی از آنها (ایگور) نظر قوی خود را در مورد اینکه دقیقاً چگونه سرویس های لینوکس باید هنگام استقرار بسته ها پیکربندی شوند، داشت. این نظر با رویکرد پیشنهادی در پچ متفاوت بود و آنها نتوانستند موافقت کنند. طبق معمول، ضرب‌الاجل‌ها رو به اتمام بود و باید به نوعی تصمیم می‌گرفت؛ لازم بود یکی از آنها در جایگاه بزرگسالی قرار بگیرد. پاشا تشخیص داد که هر دو رویکرد حق زندگی دارند، اما او می‌خواست گزینه او تصویب شود، زیرا هیچ کدام و نه گزینه دوم هیچ مزیت فنی آشکاری نداشتند.
بحث ما چیزی شبیه به این بود (البته به صورت شماتیک، مکالمه نیم ساعت طول کشید):
- پاشا چند روز دیگه یخ ویژگی داریم. مهم این است که همه چیز را جمع آوری کنیم و هر چه زودتر شروع به آزمایش کنیم. چگونه می توانیم از ایگور عبور کنیم؟
- او می‌خواهد سرویس‌ها را به گونه‌ای دیگر راه‌اندازی کند، نظرات را در آنجا برای من چسباند...
- و چه چیزی وجود دارد، تغییرات بزرگ، سر و صدا زیاد؟
- نه، یکی دو ساعت کار هست، اما در نهایت فرقی نمی کند، به هر حال کار می کند، چرا این کار لازم است؟ من چیزی ساختم که کار می کند، قبول کنیم.
- گوش کن، چند وقت است که این همه بحث می کنی؟
- بله، الان یک هفته و نیم است که زمان را مشخص کرده ایم.
-اممم... میشه یه موضوعی رو که یک هفته و نیم طول کشیده تو چند ساعت حل کنیم و نکنیم؟
- خوب، بله، اما من نمی خواهم ایگور فکر کند که تسلیم شدم ...
- گوش کن، چه چیزی برای تو مهمتر است، صدور آزادی، همراه با تصمیم خود در داخل، یا کشتن ایگور؟ ما می‌توانیم آن را مسدود کنیم، با این حال، شانس خوبی برای پرواز با انتشار وجود دارد.
- خب... البته، پاک کردن بینی ایگور خوب است، اما خوب، رها کردن مهمتر است، موافقم.
- آیا واقعا برای شما مهم است که ایگور چه فکر می کند؟ صادقانه بگویم، او به هیچ وجه به خود نمی پردازد، او فقط می خواهد یک رویکرد واحد در جاهای مختلف کاری که مسئولیت آن را بر عهده دارد.
-خب باشه بذار هرطوری که تو کامنت ها میپرسه انجام بدم و شروع به تست کنیم.
- ممنون پاشا! من مطمئن بودم که از بین شما دو نفر بالغ تر خواهید بود، اگرچه ایگورک از شما بزرگتر است :)
موضوع حل شد، آزادی به موقع آزاد شد، پاشا احساس نارضایتی زیادی نکرد، زیرا خودش راه حلی پیشنهاد کرد و اجرا کرد. ایگور به طور کلی راضی بود، زیرا ... نظر ایشان مورد توجه قرار گرفت و به پیشنهاد ایشان عمل کردند.
نوع دیگری از تضاد اساساً یکسان، انتخاب بین راه‌حل‌های فنی/کتابخانه‌ها/رویکردها در یک پروژه، به‌ویژه در یک تیم توزیع‌شده است. در یکی از پروژه‌ها که با استفاده از C/C++ قرار داشت، مشخص شد که مدیریت فنی پروژه به‌طور قاطع با استفاده از STL (کتابخانه استاندارد قالب) مخالف است. این یک کتابخانه زبان استاندارد است که توسعه را ساده می کند و تیم ما بسیار به آن عادت کرده است. معلوم شد که این پروژه به C بسیار نزدیکتر از C++ است، که چندان الهام بخش تیم نبود، زیرا مدیریت تمام تلاش خود را کرد و بازیکنان بسیار خوبی را به خدمت گرفت. در همان زمان، بخش آمریکایی تیم، اعم از مهندسان و مدیران، برای مدت طولانی در شرکت کار کرده بودند، به وضعیت موجود عادت داشتند و از همه چیز راضی بودند. بخش روسی تیم اخیراً در عرض چند هفته (از جمله من) گرد هم آمده است. بخش روسی تیم قاطعانه نمی خواست رویکرد معمول توسعه را کنار بگذارد.
بحث‌های مکتوب بی‌پایانی بین دو قاره آغاز شد، نامه‌ها روی سه یا چهار صفحه، در پست‌های گروهی و شخصی، از برنامه‌نویسان گرفته تا برنامه‌نویسان و مدیران، به این طرف و آن طرف می‌رفتند. همانطور که معمولاً اتفاق می افتد، نامه هایی به این طول توسط هیچ کس جز نویسندگان و حامیان سرسخت آنها خوانده نمی شد. چت ها با تنش به صدا در آمدند، افکار چند صفحه ای را در جهات مختلف در مورد مزایای فنی STL، چقدر تست شده، چقدر ایمن است، و به طور کلی، چقدر زندگی با آن فوق العاده است، و چقدر وحشتناک است بدون آن. .
همه اینها مدت زیادی به طول انجامید، تا اینکه در نهایت متوجه شدم که ما در حال بحث در مورد جنبه های فنی موضوع هستیم، اما مشکل در واقع فنی نبود. مشکل مزایا یا معایب STL یا سختی کار بدون آن نیست. مشکل بیشتر سازمانی است. ما فقط باید بفهمیم شرکتی که در آن کار می کردیم چگونه کار می کند. هیچ کدام از ما قبلا تجربه کار در چنین شرکتی را نداشتیم. موضوع این بود که پس از توسعه کد و عرضه به مرحله تولید، پشتیبانی توسط افراد کاملاً متفاوتی از تیم های دیگر، از کشورهای دیگر انجام شد. این تیم عظیم مهندسی متشکل از چند ده هزار مهندس (در مجموع) فقط می‌توانست حداقل یک حداقل ابزار فنی کاملاً ابتدایی، به اصطلاح، حداقل حداقل را از عهده بگیرد. هر چیزی که فراتر از استاندارد مهندسی ایجاد شده در شرکت باشد، در آینده قابل پشتیبانی نخواهد بود. سطح یک تیم با سطح ضعیف ترین اعضای آن تعیین می شود. بعد از اینکه فهمیدیم انگیزه واقعی با اقدامات بخش آمریکایی تیم، این موضوع از دستور کار خارج شد و با هم با موفقیت محصول را با استفاده از استانداردهای اتخاذ شده توسط شرکت توسعه و عرضه کردیم. نامه ها و چت ها در این مورد خوب جواب نداد؛ چندین سفر و ارتباطات شخصی زیاد طول کشید تا به یک مخرج مشترک رسید.
از نقطه نظر گردش کار، در این مورد خاص، توضیحی در مورد ابزارهای مورد استفاده، الزامات آنها، محدودیت در افزودن ابزارهای جدید و توجیه چنین محدودیت هایی کمک خواهد کرد. چنین اسنادی تقریباً مطابق با مواردی است که در پاراگراف‌های استراتژی استفاده مجدد و محیط توسعه «راهنمای مدیر توسعه نرم‌افزار» که در . علیرغم قدمت آن، تمام فعالیت‌های اصلی و مراحل برنامه‌ریزی توسعه نرم‌افزار از این نوع را کاملاً توصیف می‌کند. داشتن اسنادی از این دست، بحث درباره اینکه چه اجزا و رویکردهایی را می توان در یک محصول به کار برد، و چرا، بسیار آسان می کند.
از منظر فرهنگی، بدیهی است با موضعی بالغ تر، که در آن طرفین سعی می کنند انگیزه واقعی اقدامات همکاران خود را بشنوند و درک کنند و بر اساس اولویت های پروژه و تیم عمل کنند و نه منیت شخصی. ، تعارض راحت تر و سریعتر حل می شود.
در کشمکش دیگری بر سر انتخاب راه حل فنی، زمان قابل توجهی نیز از من گرفت تا انگیزه یکی از طرفین را درک کنم (مورد بسیار غیرعادی بود)، اما پس از مشخص شدن انگیزه، راه حل واضح بود.
وضعیت به این صورت است: یک توسعه دهنده جدید در یک تیم حدودا 20 نفره ظاهر می شود، اجازه دهید او را Stas بنامیم. در آن زمان، ابزار استاندارد ما برای ارتباط به عنوان یک تیم Skype بود. همانطور که بعداً مشخص شد، استاس از طرفداران پر و پا قرص استانداردهای باز و نرم‌افزار متن‌باز بود و فقط از ابزارها و سیستم‌عامل‌هایی استفاده می‌کرد که منابع آنها در دسترس عموم بود و از پروتکل‌های توصیف‌شده عمومی استفاده می‌کرد. اسکایپ یکی از این ابزارها نیست. ما زمان زیادی را صرف بحث در مورد مزایا و معایب این رویکرد کردیم، تلاش برای راه‌اندازی آنالوگ‌های اسکایپ در سیستم‌عامل‌های مختلف، تلاش‌های Stas برای متقاعد کردن تیم برای تغییر استانداردهای دیگر، ارسال نامه شخصی به او از طریق پست، تماس با او در تلفن، برای او کامپیوتر دوم مخصوص اسکایپ و غیره بخرید. در نهایت، متوجه شدم که این مشکل، در اصل، فنی یا سازمانی نیست، بلکه بیشتر ایدئولوژیک است، حتی، شاید بتوان گفت، مذهبی (برای استاس). حتی اگر در نهایت Stas و Skype را به هم وصل کنیم (که چندین ماه طول کشید)، مشکل دوباره در هر ابزار بعدی ایجاد می‌شود. من هیچ ابزار واقعی برای تغییر جهان بینی Stas در اختیار نداشتم و دلیلی هم برای تغییر جهان بینی تیمی وجود نداشت که در این محیط کاملاً کار می کرد. آن شخص و شرکت به سادگی در جهان بینی خود متعامد بودند. در چنین شرایطی راه حل خوب سازمانی است. ما استاس را به تیم دیگری منتقل کردیم، جایی که او ارگانیک تر بود.
دلیل این تضاد، به نظر من، ناهماهنگی بین فرهنگ شخصی یک فرد خاص (که عقیده قوی دارد که به او اجازه سازش نمی دهد) و فرهنگ شرکت است. در این مورد البته اشتباه مدیر است. در ابتدا اشتباه بود که او را به پروژه ای از این دست ببریم. استاس در نهایت به یک پروژه توسعه نرم افزار منبع باز نقل مکان کرد و در آنجا به برتری رسید.
یک مثال خوب از تعارض ناشی از نگرش کودکانه توسعه دهنده و کاستی های فرآیند کار، وضعیتی است که در آن، در صورت عدم تعریف از انجام شده، توسعه دهنده و تیم QA انتظارات متفاوتی در مورد آمادگی دارند. ویژگی به QA منتقل شده است. توسعه دهنده معتقد بود که کافی است کد را بنویسد و ویژگی را روی حصار به QA پرتاب کند - آنها آن را در آنجا مرتب می کنند. اتفاقاً یک برنامه نویس نسبتا بالغ و با تجربه بود، اما این آستانه داخلی او برای کیفیت بود. QA با این مخالفت کرد و خواست تا آنچه را که خودش بررسی کرده بود به آنها نشان دهد و توصیف کند و از آنها درخواست یک فیلمنامه آزمایشی کرد. آنها در گذشته با عملکرد این توسعه دهنده مشکل داشتند و نمی خواستند دوباره وقت خود را تلف کنند. به هر حال، حق با آنها بود - این ویژگی واقعاً کار نمی کرد، او کد را قبل از ارسال آن به QA بررسی نکرد.
برای حل این وضعیت، از او خواستم که به من نشان دهد که همه چیز واقعا کار می کند (این کار انجام نمی شود، و او باید آن را تعمیر می کرد)، ما با تیم و با تعریف QA از انجام شده صحبت کردیم (آنها موفق به انجام آن نشدند). نوشتن، چون نمی‌خواستیم این فرآیند را بیش از حد بوروکراتیک کنیم، خوب، ما به زودی راه خود را با این متخصص جدا کردیم (برای آرامش عمومی).
از نقطه نظر گردش کار، بهبودهای احتمالی در این مورد وجود تعریف انجام شده، الزامات پشتیبانی از ویژگی های هر واحد و تست های یکپارچه سازی، و شرح آزمایش انجام شده توسط توسعه دهنده است. در یکی از پروژه‌ها، سطح پوشش کد را توسط تست‌ها در حین CI اندازه‌گیری کردیم و اگر سطح پوشش پس از افزودن یک پچ کاهش یافت، تست‌ها به عنوان ناموفق علامت‌گذاری شدند، یعنی. هر کد جدیدی فقط در صورتی می‌توان اضافه کرد که آزمایش‌های جدیدی برای آن وجود داشته باشد.
نمونه بارز دیگری از تعارض که ارتباط نزدیکی با سازماندهی فرآیند کار دارد. ما یک محصول، یک تیم توسعه محصول، یک تیم پشتیبانی و یک مشتری داریم. مشتری با محصول مشکل دارد و با پشتیبانی تماس می گیرد. پشتیبانی مشکل را تجزیه و تحلیل می کند و می فهمد که مشکل در محصول است و مشکل را به تیم محصول منتقل می کند. تیم محصول در زمان شلوغی است، انتشار نزدیک است، بنابراین یک بلیط با مشکل از یک مشتری، گم شده در میان بلیط های دیگر توسعه دهنده ای که به او اختصاص داده شده است، برای چندین هفته بدون توجه معلق است. پشتیبانی فکر می کند که توسعه دهنده روی مشکل مشتری کار می کند. مشتری منتظر می ماند و امیدوار است که مشکلش حل شود. در واقعیت هنوز هیچ اتفاقی نمی افتد. پس از چند هفته، مشتری در نهایت تصمیم می گیرد به پیشرفت علاقه نشان دهد و از پشتیبانی می خواهد که کارها چگونه پیش می رود. پشتیبانی درخواست توسعه می کند. توسعه دهنده می لرزد، لیست بلیط ها را نگاه می کند و بلیطی از مشتری در آنجا پیدا می کند. با خواندن یک بلیط از یک مشتری، او می‌فهمد که اطلاعات کافی برای حل مشکل وجود ندارد و به سیاهه‌ها و زباله‌های بیشتری نیاز دارد. پشتیبانی اطلاعات بیشتری را از مشتری درخواست می کند. و سپس مشتری متوجه می شود که هیچ کس در تمام این مدت روی مشکل او کار نکرده است. و رعد و برق خواهد زد...
در این شرایط، راه‌حل تضاد به خودی خود کاملاً واضح و خطی است (تعمیر محصول، به‌روزرسانی اسناد و آزمایش‌ها، دلجویی از مشتری، انتشار یک Hotfix و غیره). تجزیه و تحلیل روند کار و درک اینکه چه کسی مسئول سازماندهی تعامل بین دو تیم است و چرا این وضعیت در وهله اول ممکن شد، مهم است. واضح است که در این فرآیند چه چیزی باید اصلاح شود - کسی باید تصویر کلی را بدون یادآوری مشتریان، به طور فعال نظارت کند. بلیط های مشتری باید در بین سایر بلیط های توسعه دهندگان برجسته باشد. پشتیبانی باید ببیند که آیا تیم توسعه در حال حاضر روی بلیط های خود کار می کند یا خیر، و اگر نه، چه زمانی می تواند شروع به کار کند و چه زمانی می توان نتایج را انتظار داشت. پشتیبانی و توسعه باید به صورت دوره ای در مورد وضعیت بلیط ها ارتباط برقرار کرده و بحث کند، جمع آوری اطلاعات لازم برای اشکال زدایی باید تا حد امکان خودکار شود و غیره.
همانطور که در جنگ دشمن سعی می کند به نقطه اتصال بین دو واحد ضربه بزند، در کار نیز معمولاً حساس ترین و آسیب پذیرترین نقطه تعامل بین تیم ها است. اگر مدیران پشتیبانی و توسعه به اندازه کافی سن داشته باشند، می توانند خودشان این روند را اصلاح کنند، در غیر این صورت، این روند به ایجاد تضادها و مشکلات ادامه می دهد تا زمانی که مدیری مداخله کند که بتواند وضعیت را اصلاح کند.
نمونه معمول دیگری که من بارها و بارها در شرکت های مختلف دیده ام، وضعیتی است که در آن یک محصول توسط یک تیم نوشته می شود، تست های یکپارچه سازی خودکار برای آن توسط تیم دوم نوشته می شود، و زیرساختی که همه آن روی آن کار می کند با تیم سوم همراه است. تیم مشکلات در هنگام اجرای تست ها همیشه به وجود می آیند و علت مشکلات در آنها می تواند هم محصول و هم تست ها و زیرساخت ها باشد. معمولاً توافق در مورد اینکه چه کسی باید تجزیه و تحلیل اولیه مشکلات، اشکالات فایل، تجزیه گزارش های محصول، تست ها و زیرساخت ها و غیره را انجام دهد، مشکل ساز است. درگیری ها در اینجا بسیار مکرر و در عین حال یکنواخت است. در مورد شدت عاطفی بالا، شرکت‌کنندگان اغلب در موقعیتی کودکانه قرار می‌گیرند و بحث‌ها در سریال شروع می‌شود: «چرا باید این کار را سرهم‌کنم»، «اون‌ها بیشتر خراب می‌شوند» و غیره.
از منظر گردش کار، مراحل خاص برای حل یک مشکل به ترکیب تیم ها، نوع آزمایش ها و محصول و غیره بستگی دارد. در یکی از پروژه‌ها، وظیفه دوره‌ای را معرفی کردیم که در آن تیم‌ها هفته به هفته تست‌ها را تک تک نظارت می‌کردند. در دیگری، آنالیز اولیه همیشه توسط توسعه دهندگان آزمایش انجام می شد، اما آنالیز بسیار ابتدایی بود و محصول کاملاً پایدار بود، بنابراین به خوبی کار می کرد. نکته کلیدی این است که اطمینان حاصل شود که فرآیند شفاف است، انتظارات برای همه طرف ها روشن است و وضعیت برای همه منصفانه است.
آیا تعارض حتی یک مشکل در یک سازمان است؟ به طور کلی خیر، زیرا اگر رشد، توسعه وجود داشته باشد، نوعی پویایی وجود دارد، مسائلی پیش می آید که قبلاً حل نشده است و در هنگام حل آنها ممکن است درگیری ایجاد شود. این نشان‌دهنده این است که برخی از حوزه‌ها نیاز به توجه دارند و زمینه‌هایی برای بهبود وجود دارد. اگر درگیری‌ها اغلب به وجود می‌آیند، حل آنها دشوار است یا زمان زیادی طول می‌کشد، بد است. این به احتمال زیاد نشانه ای از فرآیندهای کاری نابسامان و بلوغ ناکافی تیم است.
منبع: www.habr.com