كيف حاولنا المهاجمة

إذا حاولت العثور على mobbing أو Mobbing في محرك بحث ، فسيكون جزء كبير من النتائج حول "الإيذاء النفسي للأشخاص". لذلك ، من الأفضل أن تبحث على الفور عن "برمجة الغوغاء". في أفضل 10 نتائج لـ Yandex في الوقت الحالي (02/27/2019) لا يوجد سوى مقال واحد باللغة الروسية (وهذا واحد هو ترجمة) ، ولكن هناك العديد من المقالات باللغة الإنجليزية. إذا نظرت إليهم بطلاقة ، فمعظمهم نظرية وليست تحليلًا لأي حالة عملية. يقول الجميع إنه سيساعد الفريق على أن يصبح أكثر فاعلية ، ويوزع خبرات المشروع محليًا ، ويطور المهارات اللينة لدى الأفراد. أنا نفسي اختبرت التطفل في الممارسة أثناء أحد التدريبات على الطبول ، وبصراحة شعرت بالسعادة! بعد التشاور مع الفريق ، قررنا إجراء جلسة اختبار لدينا.

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

ما هو السخرية

يصفه مؤسس المهاجمة كأسلوب عمل لـ Woody Zuill على النحو التالي:

أناس رائعون يعملون معًا في مهمة واحدة في وقت واحد في مكان واحد على جهاز كمبيوتر واحد.

وهذا يعني أن "موبينج" هو أسلوب عمل عندما يعمل الفريق معًا بشكل مستمر معًا "ينقض" على أي مهام. في الوقت نفسه ، تمر المهمة بجميع المراحل اللازمة لدورة حياتها ، ويعمل كل عضو من أعضاء الفريق عليها في وقت واحد مع الجميع. وبالتالي ، يتم تحقيق الغمر وفهم المهمة من قبل الفريق بأكمله.

هناك العديد من الأدوار في المهاجمة:

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

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

تغيير - الفاصل الزمني بين تغيير أدوار السائق والملاحة. يستمر التغيير ، كقاعدة عامة ، 15-20 دقيقة. تسهم التحولات الأقصر في زيادة السرعة وزيادة مشاركة الفريق.

قواعد اللعبة

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

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



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

سلبي

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

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

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

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

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

يرغب فريق آخر في الحصول على مزيد من الوقت للتفكير "بصمت" ومناقشة الأفكار ، ولكن التحولات المتكررة أثارت محاولة الفحص أكثر بأيدي أكثر من النظرية المفترضة.

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

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

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

تحولت الإعدادات في بيئة التطوير إلى حجر عثرة: كل من المطورين مرتاحون لمعاييرهم المحددة. في هذه الحالة ، كانت هناك بيئة تطوير واحدة فقط ، وبالطبع ، لم يحب الجميع إعداداته.

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

كما ترون ، نشأت بعض العوامل السلبية نتيجة للأخطاء التنظيمية ، ولكن مع ذلك ، فقد أظهرت كيفية القيام بعمل أفضل ولماذا.

إيجابي

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

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

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

النتائج

بعد أن ناقشنا التعليقات الواردة من بعضنا البعض حول الجلسة ، توصلنا إلى بعض الاستنتاجات.

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

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

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

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

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

في نهاية المطاف ، هناك حاجة إلى التحولات لفترة أطول. على الأقل 15-20 دقيقة ، بدلا من 5 لدينا. وتحتاج إلى القيام بشيء ما مع القاعدة التي مفادها أن السائق هو مجرد أيدي المستكشف ، دون رأسه.

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

PS
يمكنك قراءة ورؤية المواد التالية حول هذا الموضوع:
GOTO 2017 - Mob Mob برمجة: A Team Team Approach - Woody Zuill
وودي زويل - يوم من برمجة الغوغاء
مدونة Agilix الاستشارية: قتل قوائم الانتظار وتسريع فريق باستخدام Mobbing