यह फुर्तीली के बारे में सब है - 2: चुस्त कार्यान्वयन सुविधाएँ

हम अभ्यास में होने वाले चुस्त विकास की बारीकियों के बारे में जारी रखते हैं। कैसे समझें कि एजाइल को सही तरीके से लागू किया गया है, कौन सा अभ्यास किस कार्य और उद्योग के लिए उपयुक्त है, कंपनी में किसको काम को "एजाइल-रेल" में स्थानांतरित करना चाहिए? वसील सावुनोव, एजाइल कोच स्क्रैमट्रैक, Mail.Ru Cloud Solutions ब्लॉग के संपादकों के साथ अपने अनुभव को साझा करना जारी रखता है।

पिछली बार, वसीली ने इस बारे में बात की थी कि एजाइल क्या है, इसमें कौन सी कार्यप्रणाली शामिल है और इसके चारों ओर क्या रूढ़ियाँ हैं। अब इसके कार्यान्वयन के बारे में बात करते हैं।

फुर्तीली कंपनियों के बारे में

- लचीली कार्यप्रणाली में "उद्योग की प्राथमिकताएँ" हैं?

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

एक व्यक्ति के रूप में जिसने सीधे एकत्रित आंकड़ों का विश्लेषण किया, और कई उत्तरदाताओं के साथ काम किया, मेरा मानना ​​है कि यह दो चीजों के कारण होता है:

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

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


विभिन्न उद्योगों में चुस्त विकास प्रथाओं को अपनाया गया। राशियाँ 100% के बराबर नहीं हैं क्योंकि एक से अधिक वस्तुओं का चयन किया जा सकता है। छवि / स्क्रेमट्रैक

- और मोबाइल डेवलपर्स के बारे में क्या? क्या एजाइल के पास मोबाइल विकास की बारीकियां हैं?

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


सामान्य तौर पर, एजाइल मोबाइल विकास के साथ अच्छी तरह से चला जाता है: इसके लिए विभिन्न विशेषज्ञों की त्वरित प्रतिक्रिया, भागीदारी और समन्वित कार्य की आवश्यकता होती है, जल्दी से परिणाम प्रदान करने की क्षमता और, यदि आवश्यक हो, तो इसे बदल दें।

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

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

उसी समय, स्क्रैम गाइड शुरू में स्क्रैम वर्कफ़्लो में किसी भी अन्य दृष्टिकोण और उपकरणों को शामिल करने पर रोक नहीं लगाता है जो उत्पाद विकास के लिए उपयोगी हो सकता है। इसलिए, उपरोक्त सभी को "क्लासिक" स्क्रैम के ढांचे में लागू किया जा सकता है।

- विशेष परिस्थितियों में संशोधित करने के तरीके कितने लचीले हैं?

इसे अलग से स्क्रैम और कानबन माना जाना चाहिए।

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

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

- अनुकूलन में सामान्य गलतियां क्या हैं स्क्रैम एक व्यवसाय बनाता है?

लचीली कार्यप्रणाली को लागू करने में मुख्य गलती यह समझने के बिना उपकरणों का उपयोग है कि उन्हें विशेष रूप से क्यों इस्तेमाल किया जाना चाहिए।

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

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

इस तरह के अयोग्य "कार्यान्वयन" के कई नकारात्मक परिणाम हैं, लेकिन वे यांत्रिकी को पुन: पेश करने के प्रयास से शुरू होते हैं, लेकिन स्क्रैम का सार नहीं। कोडरफेस्ट 2017 के सम्मेलन में मेरी रिपोर्ट " स्टॉप सिग्नल फ़ॉर एजाइल " के बारे में विस्तार से बताया गया।

- मूल्यांकन कैसे करें कि कंपनी में कितनी लचीली कार्यप्रणाली लागू की गई है?

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

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


रडार स्क्रेमट्रैक। हम रेटिंग के बिखराव को देखते हैं


रडार स्क्रेमट्रैक। हम मध्यस्थों को देखते हैं

आरेख में बहुत सारी उपयोगी जानकारी है।

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

एक छोटा सा प्रसार आम सहमति और अच्छी टीमवर्क को दर्शाता है।

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

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

स्क्रेम लागू करने वाली टीमों के बारे में

- फुर्तीली विकास पद्धतियों के कार्यान्वयन की शुरुआत कंपनी को किससे करनी चाहिए?

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

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

आदर्श जब पहल शीर्ष प्रबंधन से आती है। इस दिशा में अग्रिम रूसी बाजार में ध्यान देने योग्य हैं।

- लचीली कार्यप्रणाली की शुरुआत के साथ एक संगठन या टीम में क्या नई भूमिकाएं और कार्य उत्पन्न होते हैं? उनमें से कौन से आवश्यक हैं, जो वैकल्पिक हैं?

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

स्क्रम-मास्टर और उत्पाद के मालिक के सहायक हो सकते हैं जो अपने कर्तव्यों का हिस्सा लेते हैं, जबकि परिणाम के लिए जिम्मेदारी स्करम-मास्टर या उत्पाद के मालिक के साथ बनी रहती है।

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

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


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

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

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


- उत्पाद के मालिक और स्क्रैम-मास्टर "एक आदर्श दुनिया में" कैसे अलग हैं?

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


- जो तरीके और प्रबंधकीय मॉडल उन लोगों के लिए माहिर हैं जो पहले वर्णित भूमिकाओं में से एक पर लेने जा रहे हैं?

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

उत्पाद के मालिक को उत्पाद बनाने के लिए लीन स्टार्टअप, ग्राहक विकास और अन्य आधुनिक दृष्टिकोण सीखना चाहिए।

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

- क्या कोड का सामूहिक स्वामित्व वास्तव में "स्टार" डेवलपर्स पर कंपनी की निर्भरता को कम करता है? क्या उनकी प्रेरणा गिर रही है?

लचीली कार्यप्रणाली के बिना सामूहिक कोड स्वामित्व संभव है। पर्याप्त कोड समीक्षा समझौतों और अन्य औपचारिक नियमों, और डेवलपर्स परमाणु कार्य कर सकते हैं।

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

यह एक दुविधा है: या तो अल्पकालिक या दीर्घकालिक सफलता। ऐसा लगता है कि "स्टार" को किराए पर लेना व्यापार के लिए अच्छा है। लेकिन इस तरह के एक समर्थक कंपनी में शामिल होने के बाद तीन साल, पांच, सात साल में क्या होगा? वह अपरिहार्य हो जाएगा। और कम से कम तीन नकारात्मक परिणामों के साथ।

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

-, . , , , . : , , , , . , .

-, «» . , : , «», «» . : , , .

— , - ?

• , «»: . .
• . , , .
• «» , , , , . . . , , .
• «». «» , «- ». Scrum-, «», , «» , , . , , «».

, , . , « ». , , « » . , « . - ».

Mail.Ru Cloud Solutions .