👨🏾‍🤝‍👨🏼 🍎 📻 स्व-अलगाव की स्थितियों में एक वितरित टीम का काम: जैसा कि हमने लगभग अंतर पर ध्यान नहीं दिया 🐍 🛰️ 🤹

स्व-अलगाव मोड ने कई लोगों को घर से काम करने के लिए मजबूर किया। यह किसी के लिए आसान है, एक अधिक कठिन है, और किसी को बिल्कुल भी अंतर नहीं दिखाई देगा, लेकिन संगरोध सप्ताह (और फिर महीने) की घोषणा के बाद, जीवनकाल पदों में वृद्धि, दक्षता और उत्पादकता में वृद्धि हुई है।

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

कुछ निश्चित रूप से आपको (Agile, Scrum, Kanban, DevOps - wow खोजों) के लिए सामान्य प्रतीत होगा, लेकिन यह सुबह में चार्ज करना पसंद करता है: हर कोई जानता है कि यह उपयोगी है, लेकिन किसी कारण से आलस्य नियमित रूप से और पूरी ताकत से किया जाता है। तो: हम करते हैं। और यह काम करता है।

दूर से नहीं, वितरित किया गया

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

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

- विचार से लेकर उत्पादन तक प्रत्येक कार्य के जीवन चक्र को यथासंभव व्यवस्थित किया जाता है: प्रक्रियाएं, स्थितियां, चरणों के बीच संक्रमण - जो कुछ भी संभव है वह औपचारिक रूप से (लगभग 90% कार्यों)। उसी समय, हम नौकरशाही को सरल और समझ में रखने की कोशिश करते हैं, अन्यथा यह उपयोगी होना बंद कर देता है और हस्तक्षेप करना शुरू कर देता है;

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

कुछ नया नहीं, है ना? हालांकि, इस सरल दृष्टिकोण ने हमें आत्म-अलगाव की स्थितियों में बहुत मदद की: प्रत्येक कर्मचारी अपने दम पर अधिकतम लाभ ला सकता है, क्योंकि वे काम के लिए पर्याप्त विवरणों से अवगत हैं।

लेकिन पहले बातें पहले।

स्टेज 0. योजना

प्रत्येक टीम में एक बैकलॉग होता है, जिसके शीर्ष को रेट किया जाता है और प्राथमिकता दी जाती है:

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

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

कार्य पर कार्य के समय को नहीं बढ़ाने के लिए, टीम एक "उपयोगी नौकरशाही" में लगी हुई है: प्रबंधक एक स्पष्ट विवरण तैयार करता है, कलाकार सही स्थिति, नीचे दिए गए कार्य "स्प्रिंट" को स्प्रिंट बोर्ड पर रखते हैं:

यहां पूरी टीम स्प्रिंट की पूरी और वर्तमान तस्वीर देखती है। यदि कोई बीमार हो जाता है, तो ड्यूटी पर या छुट्टी पर जाता है, अन्य प्रतिभागी तुरंत अपनी वर्तमान स्थिति में कार्य करते हैं।

खैर, यह दैनिक सिंक के बिना कैसे हो सकता है, जब प्रक्रिया का औपचारिक संगठन कुछ विशेष मामलों को हल करने के लिए पर्याप्त नहीं है, और नौकरशाही प्रक्रिया के साथ हस्तक्षेप करने की अधिक संभावना है। आमतौर पर कार्यों को स्टेटस (विवरण में> प्रगति में> समीक्षा में> परीक्षण के लिए तैयार> परीक्षण> परीक्षण के लिए तैयार> देव के लिए तैयार> देव> आरसी> बंद) पर्याप्त है, लेकिन 10% मामलों में आपको कुछ स्पष्ट करने की आवश्यकता है, इसे शब्दों में कहें, समझाएं उंगलियों पर ”। वैसे, मुझे विश्वास है कि सभी कार्य बैठकों (स्टैंड-अप सहित) को वीडियो संचार का उपयोग करके किया जाना चाहिए, न कि केवल आवाज द्वारा, क्योंकि यह एक को अपने आप को काम करने के लिए मजबूर करता है और काम करने के लिए ट्यून करता है।

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

जहाँ समय जीता: सिंक्रोनाइज़ेशन, माइक्रो-डिसीजन मेकिंग

चरण 1. विकास: खुला> प्रगति में है

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

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

जहां समय प्राप्त हुआ: शक्तियों और क्षमताओं का एक स्वतंत्र मूल्यांकन, अस्थिर इंटरनेट कनेक्शन को दूर करने के लिए हमेशा आवश्यक नहीं होता है

स्टेज 2. स्वचालित जाँच: प्रगति में> समीक्षा में

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

- स्थिर विश्लेषण के लिए उपकरणों का एक मानक सेट: ESLint और Stylelint प्लग-इन के एक अमीर सेट के साथ;
- हमारे स्वयं के स्थिर चेक: अनुवाद की उपलब्धता और गुणवत्ता, यमल फ़ाइलों का सत्यापन;
- यूनिट परीक्षण के लिए मानक उपकरण: मोचा , कर्म , फैंटमज ,istanbul ;
हमारे अपने कार्यात्मक और दृश्य परीक्षण उपकरण, हरमाइन ;
- पल्स - प्रदर्शन परीक्षण के लिए - भी हमारा अपना है। उन्होंने यहां उसका उल्लेख किया ।

वैसे, किसी भी स्तर पर समस्याओं के मामले में कार्य को यहां वापस लाया जाएगा - दुर्भाग्य से, यहां तक कि सबसे सावधान योजना भी त्रुटियों से 100% नहीं बचाती है, कुछ गलत हो सकता है। वह व्यक्ति जो कार्य करने के लिए सही व्यक्ति को कॉल करता है, समस्या का सार बताता है, स्क्रीनशॉट या वीडियो अपलोड करता है, अतिरिक्त रूप से चैट पर कमांड लिख सकता है ताकि हर कोई ध्यान दे कि कार्य ठप हो गया है। जो कुछ भी है - परीक्षण के दौरान बग बाहर हो गया, डिजाइन बदल गया, बैकएंड से पर्याप्त डेटा नहीं था।

: — , - —

3. -: in review > ready for test

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

जहां आपने समय जीता: संबंधित समीक्षक के लिए खोज करें, पूल अनुरोध को संसाधित करने के लिए अनुस्मारक

स्टेज 4. परीक्षण: परीक्षण> परीक्षण किया गया

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

परीक्षक कर सकता है:

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

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

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

जहां समय प्राप्त हुआ: योजना, ऑटो परीक्षण, उपकरण वितरण: आत्म-अलगाव के साथ भी उपलब्ध

चरण 5. आसव: fev> देव के लिए तैयार

कार्य का परीक्षण किया जाता है - यह एक सामान्य शाखा में डालने का समय है।

N.B. , master trunk, dev. . trunk.

जब बहुत सारे इंजेक्शन होते हैं (उदाहरण के लिए, हमारे पास प्रति दिन 30 से अधिक इन्फ्यूज़ किए गए पूल अनुरोध हैं), दो समस्याएं उत्पन्न होती हैं:

- मामूली : गिट में इतिहास, यदि आप यादृच्छिक रूप से जुड़ते हैं और रिबेस नहीं करते हैं, तो यह बहुत भ्रमित हो जाता है, और अगर किसी तरह का बग है , रोलिंग वापस बहुत मुश्किल है;

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

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

अधिक जानकारीमर्ज कतार के बारे में।

जहां समय जीता: हम अवरुद्ध ब्रेकडाउन को रोकते हैं, आपको मैन्युअल रूप से पूल अनुरोध के जलसेक को नियंत्रित करने की आवश्यकता नहीं है

स्टेज 6. रिलीज: आरसी> बंद

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

यह स्पष्ट करना महत्वपूर्ण है कि विभिन्न टीमों के कार्य रिलीज़ में आते हैं, इसलिए यह सभी के लिए फायदेमंद है जब एक ऑन-कॉल डेवलपर को रिलीज़ के लिए स्पष्ट रूप से आवंटित किया जाता है, जो सभी सप्ताह के कामों को रोलिंग रिलीज़ और निगरानी त्रुटि की निगरानी में कर रहा है। यह अन्य परियोजना डेवलपर्स को यथासंभव नए कार्यों पर स्विच करने की अनुमति देता है (वास्तव में मर्ज कतार को भेजने के तुरंत बाद)।

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

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

जहां समय जीता: सिंक्रोनाइज़ेशन, माइक्रो-निर्णय करना।
चक्र बंद हो गया।

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

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

अंत तक पढ़ने के लिए धन्यवाद। टिप्पणियों में मिलते हैं!

स्व-अलगाव की स्थितियों में एक वितरित टीम का काम: जैसा कि हमने लगभग अंतर पर ध्यान नहीं दिया