إدارة الصراع في الفريق – عمل متوازن أم ضرورة حيوية؟

كتابة منقوشة:
ذات مرة، التقى القنفذ والدب الصغير في الغابة.
- مرحبا القنفذ!
- مرحبا أيها الدب الصغير!
لذلك، كلمة بكلمة، نكتة تلو الأخرى، تعرض القنفذ لضربة في وجهه من قبل الدب الصغير...

فيما يلي مناقشة من قائد فريقنا، وكذلك مدير تطوير المنتجات في RAS، إيجور مارنات، حول تفاصيل تعارضات العمل والطرق الممكنة لإدارتها.

تتطور معظم الصراعات التي نواجهها في العمل وفقًا لسيناريو مشابه لذلك الموضح في الفقرة أعلاه. هناك العديد من المشاركين الذين تم إعدادهم في البداية بشكل إيجابي للغاية تجاه بعضهم البعض، وهم يحاولون حل بعض الأسئلة، ولكن في النهاية تظل المشكلة دون حل، ولسبب ما يتم إفساد العلاقات بين المشاركين في المناقشة.

الحياة متنوعة، وتحدث اختلافات في السيناريو الموضح أعلاه. في بعض الأحيان، لا تكون العلاقة بين المشاركين جيدة جدًا في البداية، وأحيانًا لا توجد حتى مشكلة تتطلب حلاً مباشرًا (كما هو الحال في النقوش على سبيل المثال)، وأحيانًا بعد المناقشة تظل العلاقة كما كانت قبل أن تبدأ، ولكن لم يتم حل المشكلة في النهاية.

ما هو الشيء المشترك في جميع المواقف التي يمكن تعريفها على أنها حالة صراع العمل؟



أولاً، هناك وجهان أو أكثر. يمكن لهذه الأطراف أن تشغل أماكن مختلفة في المنظمة، أو تكون على علاقة متساوية (زملاء في الفريق)، أو على مستويات مختلفة من التسلسل الهرمي (رئيس - مرؤوس)، أو تكون فردية (موظف) أو جماعية (في حالات الصراع بين أحد الموظفين) موظف وفريق أو فريقين)، وهكذا. تتأثر احتمالية الصراع وسهولة حله بشكل كبير بمستوى الثقة بين المشاركين. كلما كانت معرفة الأطراف ببعضها البعض أفضل، كلما ارتفع مستوى الثقة، زادت فرصة التوصل إلى اتفاق. على سبيل المثال، أعضاء الفريق الموزع الذين لم يتفاعلوا وجهاً لوجه مطلقًا هم أكثر عرضة للصراع حول مشكلة عمل بسيطة من الأشخاص الذين لديهم على الأقل عدد قليل من التفاعلات وجهًا لوجه. لذلك، عند العمل في فرق موزعة، من المهم جدًا التأكد من أن جميع أعضاء الفريق يجتمعون بشكل دوري شخصيًا مع بعضهم البعض.

ثانيا، في حالة الصراع في العمل، يكون الطرفان في حالة حل بعض القضايا المهمة لأحد الطرفين، أو لكليهما، أو للمنظمة ككل. في الوقت نفسه، نظرًا لخصوصيات الموقف، عادةً ما يكون لدى الأطراف ما يكفي من الوقت ومجموعة متنوعة من الطرق لحلها (رسمية، غير رسمية، اجتماعات، رسائل، قرارات إدارية، وجود أهداف وخطط الفريق، حقيقة التسلسل الهرمي، وما إلى ذلك). ويختلف هذا عن موقف حل مشكلة العمل (أو غير العمل) في المؤسسة، من حل سؤال مهم مثلاً: "إيه يا طفل، من أي منطقة أنت؟!" في الشارع، أو الصراع من النقش. في حالة حل مشكلة العمل، فإن جودة سير العمل وثقافة حل المشكلات في الفريق مهمة.

ثالثا، العامل الحاسم للصراع (من وجهة نظر مناقشتنا) هو حقيقة أن أطراف العملية لا يستطيعون التوصل بشكل مستقل إلى حل للمسألة يناسب جميع الأطراف. ويتطلب الوضع تدخل طرف ثالث، وهو حكم خارجي. قد تبدو هذه النقطة مثيرة للجدل، لكن في جوهرها، إذا تم حل حالة الصراع بنجاح دون تدخل حكم خارجي، وتم حل القضية بنجاح ولم تتدهور علاقات الطرفين، فهذا هو الوضع الذي يجب أن نسعى إليه . على الأرجح لن نعرف حتى عن مثل هذا الصراع، أو سنكتشفه بالصدفة بعد حله. كلما زاد عدد المشكلات التي يستطيع الفريق حلها بمفرده، زادت فعاليته.

السمة المميزة الأخرى للصراع والتي تستحق التطرق إليها هي درجة الشدة العاطفية أثناء اتخاذ القرار. لا يرتبط الصراع بالضرورة بمستوى عاطفي عالٍ. لا يتعين على المشاركين الصراخ والتلويح بأذرعهم حتى يصبح الوضع، في جوهره، صراعًا. لم يتم حل السؤال، هناك توتر عاطفي معين (ربما لا يتم التعبير عنه بوضوح ظاهريًا)، مما يعني أننا نواجه حالة صراع.

هل من الضروري التدخل في حالات الصراع أصلاً أم أنه من الأفضل ترك حلها يأخذ مجراه وانتظار حل المشكلة من تلقاء نفسها؟ بحاجة ل. ليس دائمًا في سلطتك أو اختصاصك حل النزاع بشكل كامل، ولكن في أي موقف، في صراع من أي حجم، يمكنك اتخاذ موقف شخص بالغ، وبالتالي جلب العديد من الأشخاص من حولك إليه، وتخفيف العواقب السلبية للصراع. الصراع والمساهمة في حله.

قبل أن ننظر إلى بعض الأمثلة على حالات الصراع، دعونا نلقي نظرة على بعض النقاط الهامة المشتركة بين جميع الصراعات.

عند حل النزاع، من المهم أن تكون فوق القتال، وليس داخله (وهذا ما يسمى أيضًا "اتخاذ موقف فوقي")، أي ألا تكون جزءًا من أحد الأطراف في عملية الحل. وبخلاف ذلك، فإن وجود محكم خارجي يساعد في اتخاذ القرار لن يؤدي إلا إلى تعزيز موقف أحد الطرفين على حساب الطرف الآخر. عند اتخاذ القرار، من المهم أن يكون مقبولا أخلاقيا من قبل جميع الأطراف، كما يقولون، "اشترى". لذلك، حتى لو لم تكن الأطراف سعيدة بالقرار المتخذ، فقد وافقت على الأقل بإخلاص على تنفيذه. كما يقولون، لتكون قادرة على الاختلاف والالتزام. خلاف ذلك، فإن الصراع سيغير مظهره ببساطة، وستبقى النار المشتعلة تحت مستنقع الخث، وفي مرحلة ما سوف تندلع حتما مرة أخرى.

النقطة الثانية، المرتبطة جزئيًا بالأولى، هي أنه إذا كنت قد قررت بالفعل المشاركة في حل النزاع، فتعامل مع الأمر على محمل الجد قدر الإمكان من وجهة نظر الاتصالات ودراسة السياق. التحدث شخصيا مع كل من الطرفين. بشكل منفصل مع كل منهما، للمبتدئين. لا تقبل بالبريد. في حالة وجود فريق موزع، على الأقل تحدث عبر رابط الفيديو. فلا تكتفوا بالإشاعات وشهود العيان. افهموا القصة، ماذا يريد كل طرف، لماذا يريدون ذلك، ماذا يتوقعون، هل حاولوا حل هذه القضية من قبل، ماذا سيحدث إذا لم يتم حلها، ما هي الحلول التي يرونها، كيف يتخيلون موقف الطرف الآخر؟ الجانب الآخر، ما هو رأيهم، هل هو صحيح أم خطأ، وما إلى ذلك. قم بتحميل كل السياق المحتمل في رأسك، بعقل متفتح، على افتراض أن الجميع على حق. أنت لست داخل الصراع، أنت خارجه، في حالة استعارة. إذا كان السياق متاحًا فقط في موضوع ما، على الأقل اقرأه بالكامل والمواضيع والمستندات المتعلقة به. بعد قراءتها، استمر في التحدث بصوتك. يكاد يكون من المؤكد أنك ستسمع شيئًا مهمًا غير موجود في البريد.

النقطة الثالثة المهمة هي النهج العام للتواصل. هذه أشياء عادية، وليست كونية، لكنها مهمة جدًا. نحن لا نحاول توفير الوقت، ونتحدث مع جميع المشاركين، ولا ننتقد الشخص، ولكننا نأخذ في الاعتبار عواقب أفعاله (ليس "أنت وقح"، ولكن "ربما يشعر الرجال بالإهانة بسبب ذلك" هذا الشيء")، نعطي الفرصة لحفظ ماء الوجه، ونجري المناقشات شخصيًا، وليس أمام الصف.

عادة ما تكون النزاعات ناتجة عن أحد سببين. الأول يتعلق بما إذا كان الشخص وقت النزاع في وضع شخص بالغ أو في وضع طفل (المزيد حول هذا أدناه). ويرجع ذلك إلى نضجه العاطفي وقدرته على التحكم في عواطفه (والتي بالمناسبة لا ترتبط دائمًا بعمره). السبب الشائع الثاني هو النقص في عملية العمل، وهو ما يخلق حالات من المناطق الرمادية التي تتوزع فيها المسؤولية بين المشاركين، ولا تتسم توقعات الأطراف بالشفافية تجاه بعضها البعض، وتكون الأدوار في العملية غير واضحة.

وبناء على ذلك، عند حل النزاع (وكذلك أي قضية أخرى)، يجب على المدير أن يضع في اعتباره ثلاث وجهات نظر: على المدى القصير - لحل المشكلة/الصراع هنا والآن، على المدى المتوسط ​​- لتقليل احتمالية نشوء صراع آخر لنفس السبب، وعلى المدى الطويل، تنمية ثقافة البالغين لدى أعضاء الفريق.

كل واحد منا لديه طفل داخلي يبلغ من العمر حوالي ثلاث أو أربع سنوات. ينام معظم الوقت في العمل، لكنه في بعض الأحيان يستيقظ ويتولى زمام الأمور. الطفل لديه أولوياته الخاصة. من المهم بالنسبة له أن يصر على أن هذا هو صندوق الحماية الخاص به، وأن والدته تحبه أكثر، وجهازه هو الأفضل (التصميم هو الأفضل، وهو الأفضل في البرمجة، ...). في حالة الصراع، يمكن للطفل أن يضغط على الألعاب، ويدوس بقدميه ويكسر ملعقة، لكنه لا يستطيع حل مشكلات البالغين (هندسة الحلول، وأساليب الاختبار الآلي، وتواريخ الإصدار، وما إلى ذلك)، ولا يفكر في الفوائد لأجل الفريق. يمكن تشجيع الطفل الذي يعاني من النزاع ومواساته وإرساله إلى السرير من خلال مطالبته بالاتصال بشخص بالغ. قبل البدء في مناقشة في حالة الصراع، تأكد من أنك تتحدث إلى شخص بالغ، وليس طفلاً، وأنك أنت نفسك في وضع شخص بالغ. إذا كان هدفك الصادق في الوقت الحالي هو حل مشكلة خطيرة، فأنت في وضع شخص بالغ. إذا كان هدفك هو الدوس بقدميك وكسر كتفك، فهذه وضعية طفولية. أرسل طفلك الذي بداخلك إلى السرير واتصل بشخص بالغ، أو قم بإعادة جدولة المناقشة. يتخذ الإنسان قراراً عاطفياً، ثم يبحث عن مبرر عقلاني له. القرار الذي يتخذه الطفل بناءً على أولويات الأطفال لن يكون الأمثل.

بالإضافة إلى السلوك في وقت الصراع، يتميز وضع الطفل أو الشخص البالغ أيضًا بمستوى المسؤولية التي يكون الشخص مستعدًا لتحملها على عاتقه. في مظاهره المتطرفة، يبدو الموقف الطفولي للمبرمج، الذي التقيت به أكثر من مرة، كما يلي: لقد كتبت الكود، وأرسلته للمراجعة - انتهى عملي. يجب على المراجعين مراجعته والموافقة عليه، ويجب على ضمان الجودة التحقق منه، وإذا كانت هناك مشاكل، فسيبلغونني بذلك. ومن الغريب أن حتى الأشخاص الناضجين وذوي الخبرة يتصرفون بهذه الطريقة أحيانًا. الطرف الآخر من المقياس هو أن الشخص يعتبر نفسه مسؤولاً عن ضمان عمل الكود الخاص به، وتغطيته الاختبارات، وقد تم فحصه شخصيًا من قبله، واجتاز المراجعة بنجاح (إذا لزم الأمر، لا توجد مشكلة في فحص المراجعين، ومناقشة المشكلات عن طريق الصوت، وما إلى ذلك) وتم منعه، ستقدم ضمان الجودة المساعدة إذا لزم الأمر، وسيتم وصف سيناريوهات الاختبار، وما إلى ذلك. في الحالات العادية، إما أن يبدأ المبرمج بالقرب من نهاية المقياس للبالغين، أو ينتقل إلى هناك مع اكتسابه الخبرة (شريطة أن يتم تنمية الثقافة الصحيحة داخل الفريق). في الحالات القصوى، يستمر في العمل، وعادةً ما يتخذ موقفًا طفوليًا، ثم يواجه هو والفريق بشكل دوري مشاكل وصراعات.

يعد تعزيز الثقافة الصحيحة والناضجة في الفريق مهمة مهمة لأي مدير. يستغرق الأمر وقتًا طويلاً ومجهودًا يوميًا، لكن النتيجة تستحق العناء. هناك طريقتان للتأثير على ثقافة الفريق - القيادة بالقدوة (والتي سيتم اتباعها بالتأكيد؛ الفريق يتطلع دائمًا إلى القائد) ومناقشة السلوك الصحيح ومكافأته. لا يوجد شيء غامض أو رسمي جدًا هنا أيضًا، فقط عند مناقشة المشكلات، لاحظ أنه كان من الممكن القيام بشيء ما هنا، وأكد على أنك لاحظت عندما تم اتخاذ القرار بشكل صحيح، والثناء، والملاحظة أثناء مراجعة الإصدار، وما إلى ذلك.

دعونا ننظر في العديد من حالات الصراع النموذجية، من البسيطة إلى المعقدة:

الصراعات التي لا تتعلق بقضايا العمل

في كثير من الأحيان تكون هناك صراعات في العمل لا تتعلق بقضايا العمل. عادة ما يرتبط حدوثها وسهولة حلها ارتباطًا مباشرًا بمستوى الذكاء العاطفي للمشاركين ومستوى نضجهم ولا يرتبط بكمال أو نقص عملية العمل.

أمثلة نموذجية: شخص ما لا يستخدم الغسالة أو الدش كثيرًا بما فيه الكفاية، وهو ما لا يحبه الآخرون، شخص خانق، بينما يصاب الآخرون بالرياح إذا فتحوا النافذة، شخص صاخب جدًا، والبعض الآخر يحتاج إلى الصمت للعمل، و قريباً. ومن الأفضل عدم تأخير حل النزاعات من هذا النوع وعدم تركها تأخذ مجراها. لن يتم حلها من تلقاء نفسها وسوف تصرفك عن العمل كل يوم وتسمم الجو في الفريق. ولحسن الحظ، فإن حلها لا يمثل عادةً مشكلة كبيرة - ما عليك سوى التحدث بهدوء (ثنائيًا بالطبع) مع زميل يهمل النظافة، أو توفير مقاعد مريحة للأشخاص الذين يفضلون الصمت/البرودة، أو شراء سماعات رأس ممتصة للصوت أو تركيب حواجز ، إلخ.

مثال آخر واجهته عدة مرات أثناء عملي هو عدم التوافق النفسي بين أعضاء الفريق. لسبب ما، لا يستطيع الناس ببساطة العمل معًا، فكل تفاعل ينتهي بفضيحة. يرجع ذلك في بعض الأحيان إلى حقيقة أن الناس لديهم وجهات نظر قطبية بشأن بعض القضايا الملحة (السياسية عادة) ولا يعرفون كيفية تركهم خارج العمل. إن إقناعهم بالتسامح مع بعضهم البعض أو تغيير سلوكهم هو مهمة عقيمة إلى حد ما. الاستثناء الوحيد الذي واجهته هو الزملاء الشباب ذوي التصورات المنفتحة، حيث لا يزال من الممكن تغيير سلوكهم تدريجياً من خلال المحادثات الدورية. عادةً ما يتم حل المشكلة بنجاح عن طريق فصلهم إلى فرق مختلفة، أو على الأقل إتاحة الفرصة للتداخل في العمل نادرًا جدًا.

في جميع المواقف المذكورة أعلاه، من المفيد التحدث مع جميع المشاركين شخصيًا، ومناقشة الموقف، والسؤال عما إذا كانوا يرون مشكلة في هذه الحالة على الإطلاق، والسؤال عن الحلول في رأيهم، وضمان مشاركتهم في صنع هذا الأمر. قرار.

من وجهة نظر تحسين سير العمل (المنظور المتوسط ​​المدى الذي ذكرته)، لا يمكن فعل الكثير هنا؛ النقطة الوحيدة للتحسين هي مراعاة عامل التوافق عند تشكيل الفريق وعدم وضع الأشخاص معا مقدما الذين سوف يتعارضون.

من منظور ثقافة الفريق، تنشأ مثل هذه المواقف بشكل أقل كثيرًا في الفرق ذات الثقافة الناضجة، حيث يحترم الأشخاص الفريق والزملاء ويعرفون كيفية حل المشكلات بشكل مستقل. بالإضافة إلى ذلك، يتم حل مثل هذه النزاعات بسهولة أكبر (في كثير من الأحيان تلقائيًا) في الفرق التي يوجد فيها مستوى عالٍ من الثقة، وقد عمل الأشخاص معًا لفترة طويلة و/أو تواصلوا بشكل متكرر خارج العمل.

الصراعات المتعلقة بقضايا العمل:

عادة ما تكون مثل هذه الصراعات ناجمة عن كلا السببين في وقت واحد، عاطفيًا (حقيقة أن أحد المشاركين ليس في وضع شخص بالغ) ونقص عملية العمل نفسها. ولعل أكثر أنواع التعارضات شيوعًا التي واجهتها هي التعارضات التي تحدث أثناء مراجعات التعليمات البرمجية أو مناقشات التصميم بين المطورين.

أود أن أسلط الضوء هنا على حالتين نموذجيتين:

1) في الحالة الأولى، لا يمكن للمطور الحصول على مراجعة التعليمات البرمجية من زميل. يتم إرسال التصحيح للمراجعة، ولا يحدث شيء. للوهلة الأولى، لا يوجد صراع واضح بين الجانبين، ولكن إذا فكرت في الأمر، فهذا صراع تمامًا. لم يتم حل مشكلة العمل، أحد الأطراف (في انتظار المراجعة) يعاني من انزعاج واضح. النوع الفرعي المتطرف لهذه الحالة هو التطوير في مجتمع أو في فرق مختلفة، في حين أن المراجع قد لا يكون مهتمًا بهذا الكود المحدد، بسبب التحميل أو ظروف أخرى، وقد لا ينتبه لطلب المراجعة على الإطلاق، والمحكم الخارجي (مدير مشترك بين الطرفين) ) قد لا يكون موجوداً على الإطلاق.

إن نهج الحل الذي يساعد في مثل هذه الحالة يرتبط على وجه التحديد بالمنظور طويل المدى، وثقافة الشخص البالغ. أولا، النشاط الذكي يعمل. لا تتوقع أن الكود المعلق على المراجعة سوف يجذب انتباه المراجع نفسه. نحن بحاجة لمساعدة المراجعين على ملاحظته. بينجاني بضعة أشخاص، يطرحون سؤالاً حول الإغماء، ويشاركون في المناقشات. من الواضح أن الإلحاح من المرجح أن يضر أكثر من المساعدة، فأنت بحاجة إلى استخدام الحس السليم. ثانيا، الإعداد المسبق يعمل بشكل جيد. إذا فهم الفريق ما يحدث ولماذا، ولماذا هناك حاجة إلى هذا الرمز على الإطلاق، فقد تمت مناقشة التصميم والاتفاق عليه مسبقًا مع الجميع، فمن المرجح أن ينتبه الأشخاص إلى هذا الرمز ويقبلونه للعمل. ثالثا، تعمل السلطة. إذا كنت تريد أن تتم مراجعتك، فقم بإجراء الكثير من المراجعات بنفسك. قم بإجراء مراجعات عالية الجودة، مع فحوصات حقيقية واختبارات حقيقية وتعليقات مفيدة. إذا كان لقبك معروفًا جيدًا في الفريق، فهناك فرصة أكبر لأن يتم ملاحظة الكود الخاص بك.

من وجهة نظر سير العمل، التحسينات الممكنة هنا هي تحديد الأولويات الصحيحة التي تهدف إلى مساعدة المطور على تحقيق أهدافه وأهداف الفريق (مراجعة الآخرين، وكتابة رسائل إلى المجتمع، وإرفاق الكود بوصف البنية، والوثائق، والاختبارات، والمشاركة في المناقشات مع المجتمع، وما إلى ذلك)، ومنع التصحيحات من التعليق في قائمة الانتظار لفترة طويلة جدًا، وما إلى ذلك.

2) الحالة الثانية الشائعة للتعارضات أثناء مراجعات التعليمات البرمجية أو التصميم هي وجهات النظر المختلفة حول المشكلات الفنية وأسلوب الترميز واختيار الأدوات. من الأهمية بمكان في هذه الحالة مستوى الثقة بين المشاركين، والانتماء إلى نفس الفريق، وخبرة العمل معًا. يحدث طريق مسدود عندما يتخذ أحد المشاركين موقفا طفولي ولا يحاول سماع ما يريد المحاور أن ينقله إليه. في كثير من الأحيان، قد يعمل كل من النهج الذي يقترحه الطرف الآخر والنهج المقترح في البداية بنجاح، ولا يهم من حيث المبدأ أي منهما يجب اختياره.

في أحد الأيام، قام أحد المبرمجين من فريقي (دعنا نسميه باشا) بإعداد تصحيح يحتوي على تغييرات في نظام نشر الحزم، والذي تم تطويره ودعمه من قبل زملاء من قسم مجاور. كان لدى أحدهم (إيجور) رأيه القوي فيما يتعلق بكيفية تكوين خدمات Linux بالضبط عند نشر الحزم. اختلف هذا الرأي عن النهج المقترح في التصحيح، ولم يتمكنوا من الاتفاق. كالعادة، كانت المواعيد النهائية تنتهي، وكان من الضروري التوصل إلى نوع من القرار، وكان من الضروري أن يتولى أحدهم منصب شخص بالغ. وأدرك باشا أن كلا النهجين لهما الحق في الحياة، لكنه أراد أن يمر خياره، لأنه لم يكن لدى أي من الخيارين أو الخيار الثاني أي مزايا تقنية واضحة.

بدت مناقشتنا على هذا النحو (بشكل تخطيطي للغاية، بالطبع، استمرت المحادثة لمدة نصف ساعة):

— باشا، لدينا ميزة تجميد في غضون أيام قليلة. من المهم أن نجمع كل شيء معًا ونبدأ الاختبار في أقرب وقت ممكن. كيف يمكننا أن نصل إلى إيغور؟
- يريد إعداد الخدمات بشكل مختلف، لقد علق لي تعليقات هناك...
- وماذا هناك، تعديلات كبيرة، الكثير من الضجة؟
- لا، هناك عمل لبضع ساعات، لكن في النهاية لا يوجد فرق، سيعمل في كلا الاتجاهين، لماذا هذا ضروري؟ لقد صنعت شيئًا ناجحًا، فلنقبله.
- اسمع، منذ متى وأنت تناقش كل هذا؟
- نعم، لقد تم تحديد الوقت لمدة أسبوع ونصف الآن.
- أم... هل يمكننا حل مشكلة استغرقت أسبوعًا ونصف في بضع ساعات، ولا يمكننا حلها؟
- حسنًا، نعم، لكنني لا أريد أن يعتقد إيجور أنني استسلمت...
- اسمع، ما الأهم بالنسبة لك، إصدار إخلاء سبيل مع قرارك في الداخل، أم قتل إيجور؟ يمكننا حظره، ومع ذلك، هناك فرصة جيدة للمضي قدمًا مع الإصدار.
- حسنًا... سيكون من الرائع، بالطبع، مسح أنف إيغور، لكن حسنًا، الإصدار أكثر أهمية، أوافق على ذلك.
- هل من المهم حقًا بالنسبة لك ما يعتقده إيجور؟ لكي نكون صادقين، فهو لا يهتم على الإطلاق، فهو يريد فقط اتباع نهج موحد في أماكن مختلفة من الشيء الذي هو مسؤول عنه.
- حسنًا، حسنًا، دعني أفعل ما يطلبه في التعليقات ولنبدأ الاختبار.
- شكرا لك يا باشا! كنت متأكدًا من أنكما ستكونان أكثر نضجًا، على الرغم من أن إيجوريك أكبر منك :)

تم حل المشكلة، وتم إصدار الإصدار في الوقت المحدد، ولم يشعر باشا بعدم الرضا كثيرا، لأنه هو نفسه اقترح الحل ونفذه. كان إيغور سعيدًا بشكل عام، لأنه... تم أخذ رأيه بعين الاعتبار وفعلوا ما اقترحه.

هناك نوع آخر من نفس الصراع بشكل أساسي وهو الاختيار بين الحلول/المكتبات/المناهج التقنية في المشروع، خاصة في فريق موزع. في أحد المشاريع، الذي تم وضعه على أنه يستخدم C/C++، اتضح أن الإدارة الفنية للمشروع كانت ضد استخدام STL (مكتبة النماذج القياسية). هذه مكتبة لغة قياسية تعمل على تبسيط عملية التطوير، وقد اعتاد فريقنا عليها كثيرًا. اتضح أن المشروع أقرب إلى لغة C منه إلى لغة C++، الأمر الذي لم يلهم الفريق كثيرًا، لأنه لقد بذلت الإدارة قصارى جهدها وقامت بتوظيف لاعبين رائعين حقًا. وفي الوقت نفسه، عمل الجزء الأمريكي من الفريق، سواء من المهندسين أو المديرين، في الشركة لفترة طويلة، وكانوا معتادين على الوضع الحالي، وكانوا سعداء بكل شيء. تم جمع الجزء الروسي من الفريق مؤخرًا، في غضون بضعة أسابيع (بما في ذلك أنا). لم يرغب الجزء الروسي من الفريق بشكل قاطع في التخلي عن النهج المعتاد في التنمية.

بدأت مناقشات مكتوبة لا نهاية لها بين القارتين، وتطايرت الرسائل على ثلاث أو أربع شاشات ذهابًا وإيابًا، في رسائل جماعية وأخرى شخصية، من المبرمجين إلى المبرمجين والمديرين. وكما هو الحال عادة، لم يقرأ أحد رسائل بهذا الطول سوى المؤلفين ومؤيديهم المتحمسين. صرير الدردشات من التوتر، وتمر أفكار الشاشات المتعددة في اتجاهات مختلفة فيما يتعلق بالمزايا التقنية للمحكمة الخاصة بلبنان، ومدى جودة اختبارها، ومدى أمانها، وبشكل عام، كم هي رائعة الحياة معها، وكم هي فظيعة بدونها .

استمر كل هذا لفترة طويلة، حتى أدركت أخيرًا أننا كنا نناقش الجوانب الفنية للمسألة، لكن المشكلة في الواقع ليست تقنية. المشكلة ليست في مميزات أو عيوب STL أو صعوبة العمل بدونها. المشكلة تنظيمية إلى حد ما. كنا بحاجة فقط إلى فهم كيفية عمل الشركة التي نعمل بها. لم يكن لدى أي منا خبرة في العمل في مثل هذه الشركة من قبل. كان الأمر هو أنه بعد تطوير الكود وإصداره في مرحلة الإنتاج، تم التعامل مع الدعم بواسطة أشخاص مختلفين تمامًا من فرق أخرى ومن بلدان أخرى. هذا الفريق الهندسي الضخم الذي يضم عشرات الآلاف من المهندسين (في المجموع) لا يمكنه سوى توفير الحد الأدنى الأساسي من الوسائل التقنية، إذا جاز التعبير، الحد الأدنى من الحد الأدنى. أي شيء يتجاوز المعايير الهندسية المعمول بها في الشركة لا يمكن دعمه ماديًا في المستقبل. يتم تحديد مستوى الفريق من خلال مستوى أضعف أعضائه. بعد أن فهمنا الدافع الحقيقي من خلال تصرفات الجزء الأمريكي من الفريق، تمت إزالة هذه المشكلة من جدول الأعمال، ونجحنا معًا في تطوير المنتج وإصداره باستخدام المعايير التي اعتمدتها الشركة. لم تنجح الرسائل والمحادثات في هذه الحالة بشكل جيد، فقد استغرق الأمر عدة رحلات والكثير من الاتصالات الشخصية للتوصل إلى قاسم مشترك.

من وجهة نظر سير العمل، في هذه الحالة بالذات، قد يكون من المفيد الحصول على وصف للأدوات المستخدمة، ومتطلباتها، والقيود المفروضة على إضافة أدوات جديدة، وتبرير هذه القيود. تتوافق هذه المستندات تقريبًا مع تلك الموصوفة في الفقرات "استراتيجية إعادة الاستخدام وبيئة التطوير" في "دليل المدير لتطوير البرمجيات"، الذي تم تطويره في وكالة ناسا. على الرغم من عمره، فإنه يصف بشكل مثالي جميع الأنشطة الرئيسية ومراحل التخطيط لتطوير البرمجيات من هذا النوع. إن الحصول على مستندات كهذه يجعل من السهل جدًا مناقشة المكونات والأساليب التي يمكن استخدامها في المنتج، ولماذا.

من وجهة نظر ثقافية، من الواضح، مع موقف أكثر نضجًا، حيث يحاول الطرفان سماع وفهم الدافع الحقيقي لأفعال زملائهم والتصرف بناءً على أولويات المشروع والفريق، وليس الأنا الشخصية. سيتم حل الصراع بشكل أسهل وأسرع.

وفي صراع آخر حول اختيار الحل التقني، استغرق الأمر مني أيضًا قدرًا ملحوظًا من الوقت لفهم دوافع أحد الطرفين (كانت حالة غير عادية جدًا)، ولكن بعد أن كان الدافع واضحًا، أصبح الحل واضحًا.

الوضع هو كما يلي: يظهر مطور جديد ضمن فريق مكون من حوالي 20 شخصًا، دعنا نسميه Stas. في ذلك الوقت، كانت أداة التواصل القياسية لدينا كفريق هي Skype. كما اتضح لاحقًا، كان Stas من أشد المعجبين بالمعايير المفتوحة والبرمجيات مفتوحة المصدر، واستخدم فقط الأدوات وأنظمة التشغيل التي كانت مصادرها متاحة للعامة والتي استخدمت البروتوكولات الموصوفة علنًا. Skype ليس إحدى هذه الأدوات. لقد أمضينا الكثير من الوقت في مناقشة مزايا وعيوب هذا النهج، ومحاولات إطلاق نظائر Skype على أنظمة تشغيل مختلفة، ومحاولات Stas لإقناع الفريق بالتبديل إلى معايير أخرى، والكتابة إليه شخصيًا عبر البريد، والاتصال به شخصيًا على هاتفًا، اشتري له جهاز كمبيوتر ثانيًا مخصصًا لـ Skype، وما إلى ذلك. أخيرًا، أدركت أن هذه المشكلة، في جوهرها، ليست تقنية أو تنظيمية، بل هي أيديولوجية إلى حد ما، حتى يمكن القول، دينية (بالنسبة لستاس). حتى لو قمنا في النهاية بتوصيل Stas وSkype (والذي استغرق عدة أشهر)، فستظهر المشكلة مرة أخرى على أي أداة لاحقة. لم يكن لدي أي وسيلة حقيقية تحت تصرفي لتغيير نظرة ستاس للعالم، ولم يكن هناك سبب لمحاولة تغيير النظرة العالمية لفريق عمل بشكل مثالي في هذه البيئة. كان الشخص والشركة متعامدين ببساطة في نظرتهما للعالم. في مثل هذه الحالات، الحل الجيد هو الحل التنظيمي. قمنا بنقل Stas إلى فريق آخر، حيث كان أكثر عضوية.

سبب هذا الصراع في رأيي هو التناقض بين الثقافة الشخصية لشخص معين (الذي لديه رأي قوي لا يسمح له بالتنازل) وثقافة الشركة. وفي هذه الحالة، فهذا بالطبع خطأ المدير. كان من الخطأ في البداية اصطحابه في مشروع من هذا النوع. انتقل Stas في النهاية إلى مشروع تطوير برمجيات مفتوحة المصدر وتفوق هناك.

من الأمثلة الجيدة على الصراع الناجم عن كل من الموقف الطفولي للمطور وأوجه القصور في عملية العمل هو الموقف الذي، في غياب تعريف ما تم، يكون لدى المطور وفريق ضمان الجودة توقعات مختلفة فيما يتعلق باستعداد تم نقل الميزة إلى ضمان الجودة. يعتقد المطور أنه يكفي كتابة الكود وإلقاء الميزة فوق السياج إلى ضمان الجودة - وسوف يقومون بفرزها هناك. بالمناسبة، كان مبرمجًا ناضجًا وذو خبرة إلى حدٍ ما، لكن هذا كان عتبة الجودة الداخلية لديه. لم يوافق ضمان الجودة على ذلك وطالبهم بإظهار ووصف ما قام بفحصه بنفسه، وطالبهم بنص اختبار. لقد واجهوا مشاكل مع وظائف هذا المطور في الماضي ولم يرغبوا في إضاعة وقتهم مرة أخرى. بالمناسبة، كانوا على حق - الميزة لم تعمل حقًا، ولم يتحقق من الرمز قبل إرساله إلى ضمان الجودة.

لحل الموقف، طلبت منه أن يوضح لي أن كل شيء يعمل حقًا (لم ينجح، وكان عليه إصلاحه)، وتحدثنا مع الفريق ومع تعريف ضمان الجودة لـ "تم" (لم ينجحوا في ذلك) الكتابة، لأننا لم نرغب في جعل العملية بيروقراطية للغاية)، حسنًا، سرعان ما افترقنا عن هذا المتخصص (للإغاثة العامة).

من وجهة نظر سير العمل، تتمثل التحسينات المحتملة في هذه الحالة في وجود تعريف لما تم إنجازه، ومتطلبات دعم كل ميزة وحدة واختبارات التكامل، ووصف الاختبار الذي أجراه المطور. في أحد المشاريع، قمنا بقياس مستوى تغطية الكود عن طريق الاختبارات أثناء CI وإذا انخفض مستوى التغطية بعد إضافة تصحيح، تم وضع علامة على الاختبارات على أنها فاشلة، أي. لا يمكن إضافة أي كود جديد إلا إذا كانت هناك اختبارات جديدة له.

مثال نموذجي آخر للصراع يرتبط ارتباطًا وثيقًا بتنظيم عملية العمل. لدينا منتج وفريق تطوير منتج وفريق دعم وعميل. يواجه العميل مشاكل مع المنتج ودعم جهات الاتصال. يقوم الدعم بتحليل المشكلة وفهم أن المشكلة موجودة في المنتج وينقل المشكلة إلى فريق المنتج. فريق المنتج في وقت مزدحم، الإصدار يقترب، لذا فإن التذكرة التي بها مشكلة من العميل، المفقودة بين التذاكر الأخرى للمطور الذي تم تعيينه له، معلقة لعدة أسابيع دون اهتمام. يعتقد فريق الدعم أن المطور يعمل على حل مشكلة العميل. ينتظر العميل ويأمل أن يتم حل مشكلته. وفي الواقع، لم يحدث شيء حتى الآن. وبعد بضعة أسابيع، قرر العميل أخيرًا الاهتمام بالتقدم المحرز وطلب الدعم حول كيفية سير الأمور. الدعم يطلب التطوير. يرتجف المطور ويبحث في قائمة التذاكر ويجد تذكرة من العميل هناك. عند قراءة تذكرة من العميل، يدرك أنه لا توجد معلومات كافية لحل المشكلة، ويحتاج إلى المزيد من السجلات والمقالب. يطلب الدعم معلومات إضافية من العميل. وبعد ذلك يدرك العميل أنه لم يكن أحد يعمل على حل مشكلته طوال هذا الوقت. وسيضرب الرعد..

في هذه الحالة، يكون حل التعارض نفسه واضحًا وخطيًا تمامًا (إصلاح المنتج، وتحديث الوثائق والاختبارات، وإرضاء العميل، وإصدار إصلاح عاجل، وما إلى ذلك). من المهم تحليل سير العمل وفهم المسؤول عن تنظيم التفاعل بين الفريقين، ولماذا أصبح هذا الوضع ممكنًا في المقام الأول. من الواضح ما يجب إصلاحه في هذه العملية - يجب على شخص ما مراقبة الصورة العامة بشكل استباقي دون تذكير من العملاء. يجب أن تبرز التذاكر المقدمة من العميل بين التذاكر الأخرى المقدمة من المطورين. يجب أن يرى الدعم ما إذا كان فريق التطوير يعمل حاليًا على التذاكر الخاصة به، وإذا لم يكن الأمر كذلك، متى يمكنه بدء العمل ومتى يمكن توقع النتائج. يجب أن يتواصل فريق الدعم والتطوير بشكل دوري ويناقش حالة التذاكر، ويجب أن يكون جمع المعلومات اللازمة لتصحيح الأخطاء آليًا قدر الإمكان، وما إلى ذلك.

وكما هو الحال في الحرب، يحاول العدو الوصول إلى نقطة التقاطع بين وحدتين، كذلك فإن النقطة الأكثر حساسية وضعفًا في العمل هي عادةً التفاعل بين الفرق. إذا كان مديرو الدعم والتطوير كبارًا بما يكفي، فسيكونون قادرين على إصلاح العملية بأنفسهم، وإذا لم يكن الأمر كذلك، فستستمر العملية في توليد الصراعات والمشاكل حتى يتدخل المدير الذي يمكنه إصلاح الموقف.

مثال نموذجي آخر رأيته مرارًا وتكرارًا في شركات مختلفة هو الموقف الذي تتم فيه كتابة المنتج من قبل فريق واحد، ويتم كتابة اختبارات التكامل التلقائي له من قبل فريق ثانٍ، وتكون البنية التحتية التي يتم تشغيل كل شيء عليها مصحوبة بفريق ثالث فريق. تنشأ مشكلات عند إجراء الاختبارات طوال الوقت، ويمكن أن يكون سبب المشكلات فيها هو المنتج والاختبارات والبنية التحتية. عادة ما يكون من الصعب الاتفاق على من يجب عليه إجراء التحليل الأولي للمشاكل، وأخطاء الملفات، وسجلات التحليل للمنتج، والاختبارات والبنية التحتية، وما إلى ذلك. الصراعات هنا متكررة جدًا وفي نفس الوقت موحدة. في حالة الشدة العاطفية العالية، غالبا ما يقع المشاركون في موقف طفولي وتبدأ المناقشات في السلسلة: "لماذا يجب علي العبث بهذا"، "إنهم ينهارون في كثير من الأحيان"، وما إلى ذلك.

من منظور سير العمل، تعتمد الخطوات المحددة لحل مشكلة ما على تكوين الفرق ونوع الاختبارات والمنتج وما إلى ذلك. في أحد المشاريع، قدمنا ​​واجبًا دوريًا، حيث تقوم الفرق بمراقبة الاختبارات واحدًا تلو الآخر، أسبوعًا بعد أسبوع. وفي الحالة الأخرى، كان يتم إجراء التحليل الأولي دائمًا بواسطة مطوري الاختبار، ولكن التحليل كان أساسيًا للغاية وكان المنتج مستقرًا تمامًا، لذلك كان يعمل بشكل جيد. والمفتاح هنا هو ضمان شفافية العملية، وأن التوقعات واضحة لجميع الأطراف، وأن الوضع يبدو عادلاً للجميع.

هل يعتبر الصراع مشكلة في المنظمة؟ هل يعد حدوث الصراعات في كثير من الأحيان (أو بشكل دوري فقط) علامة سيئة في فريقك؟ بشكل عام، لا، لأنه إذا كان هناك نمو، وتطوير، فهناك نوع من الديناميكيات، فستنشأ المشكلات التي لم يتم حلها من قبل، وعند حلها قد تنشأ صراعات. وهذا مؤشر على أن بعض المجالات تحتاج إلى الاهتمام، وأن هناك مجالات تحتاج إلى التحسين. من السيئ أن تنشأ النزاعات في كثير من الأحيان، أو يصعب حلها أو تستغرق وقتًا طويلاً. من المرجح أن تكون هذه علامة على عدم تبسيط عمليات العمل وعدم نضج الفريق بشكل كافٍ.

المصدر: www.habr.com