कैसे हमने लुटने की कोशिश की

यदि आप एक खोज इंजन में भीड़ या मोबबिंग को खोजने की कोशिश करते हैं, तो परिणामों का एक महत्वपूर्ण हिस्सा "लोगों के मनोवैज्ञानिक दुरुपयोग" के बारे में होगा। इसलिए, "भीड़ प्रोग्रामिंग" के लिए तुरंत देखना बेहतर है। फिलहाल यैंडेक्स के शीर्ष 10 परिणामों में (02/27/2019) रूसी में केवल एक लेख है (और वह एक अनुवाद है), लेकिन अंग्रेजी में कई लेख हैं। यदि आप उन्हें धाराप्रवाह देखते हैं, तो उनमें से अधिकांश एक सिद्धांत है, न कि किसी व्यावहारिक मामले का विश्लेषण। हर कोई कहता है कि यह टीम को अधिक प्रभावी बनने में मदद करेगा, स्थानीय रूप से परियोजना विशेषज्ञता वितरित करेगा, और लोगों में नरम कौशल विकसित करेगा। मैंने खुद एक ट्राम ट्रेनिंग के दौरान अभ्यास में जुटने का परीक्षण किया, और, ख़ुशी से! टीम के साथ परामर्श करने के बाद, हमने अपना टेस्ट मोबबिंग सत्र आयोजित करने का निर्णय लिया।

काम करने के इस दृष्टिकोण के फायदों के बीच, हमने अपने लिए ऐसे मूल्यों की पहचान की, जो टीम के भीतर विशेषज्ञता के प्रसार और किसी भी प्रतिभागी के लिए अतिरिक्त कौशल के विकास के रूप में हैं। भीड़ को समर्पित एक बैठक आयोजित करने के बाद, हमने खुद को तीन लक्ष्य निर्धारित किए: पहला, अभ्यास में जुटने की कोशिश करना। दूसरे, यह समझने के लिए कि हमारे मामले में इसके क्या नुकसान और नकारात्मक कारक हैं। तीसरा, यह निर्धारित करें कि यह हमारी टीम के लिए उपरोक्त मान लाएगा या नहीं।

क्या जुटा रहा है

वुडी जुइल की कार्यशैली के रूप में जुटने के संस्थापक ने उनका वर्णन इस प्रकार किया है:

एक कंप्यूटर पर एक जगह पर एक समय में एक कार्य पर एक साथ काम करने वाले अद्भुत लोग।

यही है, मोबबिंग एक कार्य शैली है जब कोई टीम किसी भी कार्य पर लगातार और एक साथ "पोज़" करती है। एक ही समय में, कार्य अपने जीवन चक्र के सभी आवश्यक चरणों से गुजरता है, और प्रत्येक टीम का सदस्य इस पर सभी के साथ मिलकर काम करता है। इस प्रकार, पूरी टीम द्वारा कार्य का विसर्जन और समझ हासिल की जाती है।

भीड़ जुटाने में कई भूमिकाएँ हैं:

• चालक: एक सामान्य कार्यस्थल में बैठता है, वही करता है जो नाविक उसे बताता है।
• नेविगेटर: ड्राइवर को निर्देश देता है। यदि वह नहीं जानता कि क्या करना है, तो वह भीड़ (टीम के बाकी सदस्यों) के साथ परामर्श करता है, चालक को आवश्यक कार्यों को प्रसारित करता है।
• Mob: विकास में भाग लेता है, नाविक को बताता है कि चालक को क्या करना चाहिए।
• PO (उत्पाद स्वामी): वास्तव में पता होना चाहिए कि क्या होना चाहिए। टीम के आंदोलन के लिए वांछित दिशा निर्धारित करता है। यह एक ड्राइवर और नाविक हो सकता है।
• सूत्रधार: नियमों के अनुपालन की निगरानी करता है, पारियों, पार्कों के विचारों की घोषणा करता है। यह वांछनीय है कि इस भूमिका में एक व्यक्ति है।

मोबिंग में एक सत्र होता है, जिसमें चक्र शामिल होते हैं, जिनमें से प्रत्येक में बदलाव होते हैं।
सत्र - समय की अवधि जिसके दौरान एक टीम एक कार्य पर काम करती है। सत्र से पहले, कार्य को चुना जाता है और चरणों में विभाजित किया जाता है, और इसका लक्ष्य निर्धारित किया जाता है - परिणाम के रूप में क्या प्राप्त करने की आवश्यकता है, उदाहरण के लिए, कार्यात्मक का वेतन वृद्धि।

परिवर्तन - चालक और नाविक की भूमिकाओं को बदलने के बीच का समय अंतराल। बदलें, एक नियम के रूप में, 15-20 मिनट तक रहता है। कम शिफ्टर्स उच्च गति और अधिक से अधिक टीम में योगदान करते हैं।

खेल के नियम

शिफ्ट के दौरान, चालक साझा कंप्यूटर पर बैठता है और वही करता है जो नाविक उसे बताता है। टीम देखती है और, यदि आवश्यक हो, चर्चा करती है कि क्या किया जाना चाहिए। नाविक ने इस चर्चा को संरचित किया और चालक को प्रसारित किया कि उसे अब क्या करना है। ड्राइवर केवल नाविक के निर्देशों को सुनता है और उससे सवाल पूछ सकता है। नाविक टीम को सवाल प्रसारित कर सकता है। सूत्रधार "पार्क" विचारों को आवाज दी गई थी लेकिन एक कारण या किसी अन्य के लिए उपयोग नहीं किया गया था।

भूमिका के परिवर्तन के अंत में, ड्राइवर और नाविक भूमिकाओं को पूर्वनिर्धारित कतार में अन्य लोगों को स्थानांतरित किया जाता है: वर्तमान नेविगेटर भीड़ में जाता है, चालक नाविक बन जाता है, और कतार में अगला व्यक्ति भीड़ से चालक बन जाता है। जब टीम के प्रत्येक सदस्य ने प्रत्येक भूमिकाओं का दौरा किया, तो "सर्कल बंद हो जाता है", यानी चक्र समाप्त होता है।



भीड़ सत्र के बाद, हम में से प्रत्येक ने अपने छापों को साझा किया, जिसके आधार पर कुछ निष्कर्ष निकाले गए। नतीजतन, हमें एक ऐसा परिणाम मिला, जिसमें यह समझने की कोशिश की गई कि कैसे और कब मोबाइल का उपयोग करना बेहतर है, और क्या यह हमारी टीम को सूट करता है। मैं नकारात्मक छापों से शुरू करूंगा।

नकारात्मक

कभी-कभी नाविक की भूमिका पूरी तरह से स्पष्ट नहीं होती है। कुछ बिंदु पर, उदाहरण के लिए, विश्लेषक इस भूमिका में हो सकता है, और डेवलपर चालक हो सकता है। नाविक ने कहा कि टीम उसे बता रही थी, विकास के अनुभव की कमी के कारण "यह सब क्या है," पूरी तरह से समझ में नहीं आ रहा है। नतीजतन, ऐसी स्थितियां उत्पन्न हुईं, जहां नाविक ने केवल कमांड के निर्देशों को प्रसारित करने का कोई मतलब नहीं निकाला, क्योंकि, सबसे पहले, डेवलपर कमांड सुनता है, इसलिए उसे एक मध्यस्थ की आवश्यकता क्यों है? दूसरे, चालक यह समझता है कि इस स्थिति में कैसे कार्य करना है, लेकिन भूमिका के नियमों के अनुसार, उसके हाथ बंधे हुए हैं।

हमने यह भी नोट किया कि अगर नेविगेटर को अगला कदम निर्धारित करने के लिए विकास के माहौल में अगले टैब को देखने की जरूरत है, तो उसे इस विचार को आवाज देने और ड्राइवर को टैब स्विच करने के लिए इंतजार करने की आवश्यकता है। उन्होंने खुद ऐसा किया होगा जब उन्होंने ड्राइवर से अनुरोध किया था, सभी के साथ "इतने दयालु" और "कृपया-धन्यवाद करें"।

कठिनाई यह थी कि हमारे पास दो डेवलपर्स दूर से काम कर रहे हैं। सबसे पहले, इसने इस तरह के ऑपरेशन के लिए समय जोड़ा जैसे कि "कर्सर पर अधिकार स्विच करना": ताकि दूरस्थ व्यवस्थापक स्क्रीन पर कुछ दिखा सके, लेकिन एक ही समय में माउस का नियंत्रण न करें। ऐसा करने के लिए, कॉन्फ्रेंस कंट्रोल विंडो को विस्तारित करना, कर्सर को नियंत्रित करने के लिए सही व्यक्ति को सक्षम करना और विंडो को छोटा करना आवश्यक था। इसमें इतना समय नहीं लगता है, लेकिन यह बहुत विचलित करता है, इसे एक कार्य से बाहर निकालता है (जो कि अभी शुरू हो गया है), और आम तौर पर हस्तक्षेप करता है। नतीजतन, प्रत्येक पारी के बाद, नए नाविक को पिछले एक से पूछना था कि वह अब क्या करना चाहता है, दोनों को यह याद रखना था, "सिंक्रनाइज़ करें", और उसके बाद ही आगे बढ़ें।

कुछ कर्मचारियों के "पश्चाताप" के कारण एक और कठिनाई उनके पड़ोसियों की है। कुछ बिंदु पर, रिमोट नेविगेटर के एक पड़ोसी ने पूरे घर में छेद ड्रिल करने का फैसला किया, इसलिए हमने प्रवर्धन के साथ ध्वनियों की एक पूरी श्रृंखला सुनी। यह, जैसा कि आप जानते हैं, हमारी बिल्कुल मदद नहीं की।

चूंकि हम समय में बहुत सीमित थे (एक घंटे प्रति भीड़ सत्र), हमारी शिफ्ट्स बहुत कम थीं - प्रत्येक में 5 मिनट (ताकि प्रत्येक प्रतिभागी के पास इस या उस भूमिका को देखने का समय कम से कम एक बार हो)। यह मेरी राय में, प्रगति में परिलक्षित होता है। जैसा कि पहले कहा गया था, सत्र के सभी प्रतिभागियों को शिफ्ट के अंत में कार्य में विसर्जित किया गया था (अंत तक 1-2 मिनट), और इस छोटी अवधि के बाद हर कोई स्विच द्वारा विचलित हो गया था। यह स्पष्ट है कि आपने इस तरह से बहुत कुछ नहीं किया है।

एक और टीम "चुपचाप" सोचने और विचारों पर चर्चा करने के लिए अधिक समय लेना चाहेगी, लेकिन लगातार बदलाव ने सिद्धांत में परिकल्पना की तुलना में हाथों से अधिक जांच करने की कोशिश की।

हमने एक घंटे के प्रयोग के लिए सबसे सरल मामला नहीं लिया: एक अन्य परियोजना का एक कार्य जो हमारी टीम से बहुत परिचित नहीं था। अधिकांश समय हमने यह पता लगाया कि कोड का वह टुकड़ा जिसे हमें आमतौर पर काम करने की आवश्यकता होती है। काम के कुल 7 घंटे (प्रत्येक टीम के सदस्य के लिए 1 घंटे) से अधिक, हम वास्तव में यह नहीं समझ पाए कि इस कार्य को करने के लिए कौन सा पक्ष है।

कारक का उल्लेख किया गया था कि पूरी टीम एक निश्चित बिंदु से समस्या का समाधान देखती है, जिसमें एक परीक्षक भी शामिल है। हमने सुझाव दिया कि भविष्य में (जब हम उचित स्तर पर पहुंचे) यह परीक्षण की निष्पक्षता को नकारात्मक रूप से प्रभावित कर सकता है, क्योंकि हम सभी को पता होगा कि "यह कैसे काम करता है", और अवचेतन रूप से हम बाधाओं से बचने की कोशिश करेंगे। दुर्भाग्य से, यह सिर्फ एक धारणा है।

लेकिन हमारी अन्य परिकल्पना की पुष्टि की गई थी। सत्र से पहले भी, हमने सुझाव दिया था कि यदि एक ही कार्य पर काम करते समय अलग-अलग दृष्टि वाले लोग आते हैं, तो विचारों की एक दौड़ होगी। यह ठीक वैसा ही हुआ: कुछ डेवलपर्स ने एकीकरण परीक्षणों के माध्यम से स्थानीय डिबगिंग का संचालन करने का सुझाव दिया, अन्य - पूरी तरह से व्यवसाय प्रक्रिया को लागू करने के द्वारा जिसे बदलना चाहिए था। प्रत्येक पक्ष ने ठोस तर्क दिए। हम इस तथ्य के कारण इस स्थिति से बाहर निकल गए कि हमने पहले एक दृष्टिकोण की कोशिश करने का फैसला किया, और अगर समय पर सहमत बिंदु पर हमें पता चलता है कि इस पद्धति में अधिक श्रम की आवश्यकता है, तो हम एक वैकल्पिक विकल्प का उपयोग करेंगे।

विकास के माहौल में सेटिंग्स एक ठोकर के रूप में निकली: प्रत्येक डेवलपर्स अपने स्वयं के विशिष्ट मापदंडों के साथ सहज है। इस मामले में, केवल एक विकास का माहौल था, और निश्चित रूप से, सभी को इसकी सेटिंग्स पसंद नहीं थी।

हम यहां तक ​​कि एक सुविधा की गलती करने में कामयाब रहे: शिफ्ट के अंत से कुछ समय पहले, भविष्य के ड्राइवर चाय के लिए गए। नतीजतन, उनके नाविक ने चाय पीना भी छोड़ दिया, और हम समय के साथ एक शिफ्ट में खो गए।

जैसा कि आप देख सकते हैं, संगठनात्मक त्रुटियों के परिणामस्वरूप कुछ नकारात्मक कारक उत्पन्न हुए, लेकिन, फिर भी, उन्होंने दिखाया कि बेहतर कैसे और क्यों करना है।

सकारात्मक

प्रतिभागियों ने कहा कि यह कार्यशैली उन लोगों को अनुमति देती है जो सामान्य रूप से व्यवसाय से कार्यों को प्राप्त करते हैं, विश्लेषण करते हैं और उनका परीक्षण करते हैं, इन समस्याओं को सीधे हल करने की प्रक्रिया में तल्लीन करते हैं। उन्होंने दूसरी तरफ से उन पर काम देखा: एक कार्य जो इसके कार्यान्वयन के रास्ते पर चलता है। यह उनके लिए स्पष्ट हो गया कि डेवलपर्स इसके समाधान के लिए कैसे समझें, इसके लिए क्या कार्यवाही कर रहे हैं। इस प्रकार, हर कोई देखता है और समझता है कि वर्तमान में कार्य के साथ क्या हो रहा है।

यह हम में से कुछ के लिए स्पष्ट हो गया है कि क्यों डेवलपर्स को अक्सर किसी कार्य का वर्णन करते समय अधिक गहराई से विश्लेषण की आवश्यकता होती है, और वे कभी-कभी पहली नज़र में, बल्कि अस्पष्ट, सवाल स्पष्ट करते हैं।

निस्संदेह, यह हम में से प्रत्येक के लिए एक नया, मूल्यवान अनुभव है। इसके अलावा, इस तरह के असामान्य सहयोग से टीम को मजबूत बनाने में मदद मिलती है, यानी यह एक तरह की टीम बनाने का काम करता है: पहली बार, किसी ने दूसरे व्यक्ति के प्रत्यक्ष काम को देखा, एक निश्चित स्थिति में अपने विचारों को सीखा।

परिणाम

सत्र के बारे में एक-दूसरे से मिली प्रतिक्रिया पर चर्चा करने के बाद, हम कुछ निष्कर्षों पर पहुंचे।

हमारे परिणामों के अनुसार, यह पता चला कि भीड़ में आपको पूरी टीम के साथ बिल्कुल काम नहीं करना चाहिए, या कम से कम लगातार नहीं करना चाहिए। हमारी वास्तविकता में, यदि पूरी टीम केवल एक कार्य पर काम कर रही है, तो ठेकेदारों के साथ बातचीत नहीं की जाती है और उपयोगकर्ता अनुरोध संसाधित नहीं किए जाते हैं। आप निश्चित रूप से अपनी शिफ्ट आने तक ऐसा कर सकते हैं, लेकिन फिर आपको विचलित होने की ज़रूरत है, उस कार्य पर स्विच करें जिसे हर कोई हल कर रहा है, फिर इसे फिर से छोड़ दें और याद रखें कि आपने शिफ्ट से पहले क्या बंद कर दिया था।

यह आवश्यक है कि नाविक चालक की तुलना में थोड़ा अधिक अनुभवी हो। अन्यथा, यह एक टूटे हुए फोन का एक खेल बन जाता है, जब नाविक चालक को शाब्दिक रूप से पारित करने की कोशिश करता है कि उसने क्या कहा, पूरी तरह से समझ नहीं "यह सब क्या मतलब है।" उदाहरण के लिए, आप बदले में भूमिका नहीं बदल सकते। यदि आप जोड़ों को अधिक शक्तिशाली नेविगेटर प्रदान नहीं कर सकते हैं, लेकिन आपको लोगों को न केवल उनकी विशेषज्ञता के अनुसार काम करने की शिक्षा देने की आवश्यकता है, तो, हमारी राय में, जोड़ी प्रोग्रामिंग अधिक प्रभावी होगी।

हमें यह धारणा मिली कि जब नए डेवलपर टीम में दिखाई देते हैं, तो भीड़ अच्छी तरह से काम करेगी या टीम का कोई व्यक्ति निश्चित रूप से कार्यक्रम करना चाहता है। फिर, जब अनुभवी डेवलपर्स के साथ भीड़ का संचालन करते हैं, तो नवागंतुक जल्दी से टीम परियोजनाओं में खुद को विसर्जित कर देंगे और आम तौर पर स्वीकृत सिद्धांतों और काम के नियमों को समझेंगे।

उसी तरह, आप एक ऐसे काम पर काम कर सकते हैं जिसमें एक टीम में केवल एक ही व्यक्ति के पास विशेषज्ञता है (हां, हमारे पास ऐसा व्यक्ति और ऐसी परियोजना है) बाकी के बीच ज्ञान फैलाने के लिए।

हमारे पास यह धारणा थी कि भीड़ जुटाना बाघ-टीमों के लिए अच्छा है: कुछ जरूरी काम को हल करने के लिए बनाई गई टीमें। लेकिन यह काम कर सकता है अगर, कम से कम, टीम एक ही कमरे में है और बहुमत के लिए तैयार विकास के माहौल के साथ है। अन्यथा, अनावश्यक संचार कारकों के कारण समय की हानि होगी।
यदि एक टीम अभी बनी है, और आदर्श रूप से, इसके साथ एक नई परियोजना बनाई जा रही है, तो भीड़ अच्छी तरह से काम कर सकती है। इस मामले में, प्रत्येक प्रतिभागी देखेंगे कि कैसे और क्यों कुछ वैचारिक, वास्तु और अन्य निर्णय किए जाते हैं, परियोजना के बारे में ज्ञान में असंतुलन होगा।

अंतत: शिफ्टों में अधिक समय की जरूरत होती है। हमारे 5 के बजाय कम से कम 15-20 मिनट। और आपको इस नियम के साथ कुछ करने की आवश्यकता है कि एक चालक सिर्फ एक नाविक के हाथों का है, बिना अपने सिर के।

इसलिए, हमने अपनी टीम के काम की परिस्थितियों में अभ्यास करने की कोशिश की। कुछ नियमों ने हमारे साथ हस्तक्षेप किया, कुछ हमने गलत समझा, कहीं न कहीं हमने गलतियां कीं। फिर भी, हमने खुद पर महसूस किया कि यह क्या है, क्या यह संभव है और क्या हमें इस शैली में काम करने की आवश्यकता है। इस प्रयोग के परिणामों के अनुसार, हमने उन मूल्यों को पूरी तरह से प्राप्त नहीं किया जिन्हें हमने अपने लिए सबसे महत्वपूर्ण माना था। यह विचार करने योग्य है कि हमने केवल एक घंटे के लिए बहुत कम पारियों के साथ जुटने की कोशिश की, क्योंकि ये परिणाम सबसे विश्वसनीय नहीं हो सकते हैं। "पूर्ण-समय" पर काम करते समय, कुछ समस्याएं उत्पन्न नहीं होंगी, और कुछ प्रक्रिया के "अनुकूलन" के बाद दूर हो जाएंगे। शायद, हमने केवल उन मूल्यों को प्राप्त करने का प्रबंधन नहीं किया जिनकी हमें इतने कम समय में जरूरत थी। यह निश्चित रूप से जानने के लिए, यह अन्य स्थितियों में जुटने की कोशिश करने लायक है, लेकिन यह पूरी तरह से अलग कहानी होगी।

पुनश्च
आप विषय पर निम्नलिखित सामग्रियों को पढ़ और देख सकते हैं:
गोटो 2017 - मॉब प्रोग्रामिंग: ए होल टीम अप्रोच - वुडी जुइल
वुडी जुइल - मोब प्रोग्रामिंग का एक दिन
एगिलिक्स कंसल्टिंग ब्लॉग: किलिंग क्यूज़ और एक टीम को मोबिंग के साथ त्वरित करना