जहां फुर्तीली भयानक है, विशेष रूप से घबराहट

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

मैंने देखा कि स्क्रीम नामक कितने चंचल वेरिएंट वास्तव में कंपनी को मारते हैं। "मार" से मेरा मतलब "सांस्कृतिक गिरावट" नहीं है, बल्कि यह है कि जब कंपनी के शेयरों में दो साल में लगभग 90% की गिरावट आती है।

चंचल क्या है?


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

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

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

हिंसक पारदर्शिता


आईटी वर्कप्लेस में कई ट्रेंड हैं जो प्रोग्रामिंग करियर को बेहद बदसूरत बनाते हैं, खासकर क्रिएटिव, स्मार्ट लोगों के लिए।

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

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

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

फुर्तीली और स्क्रैम विशिष्ट दोष


1. व्यवसाय उन्मुख विकास।


चंचल अक्सर एक "झरना" की तुलना में परोसा जाता है। एक झरना क्या है?

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

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

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

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

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

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

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

अंत में, एजाइल (जैसा कि अभ्यास किया गया है) और झरना व्यवसाय-उन्मुख विकास के रूप हैं, और इसलिए, उनमें से कोई भी गुणवत्ता सॉफ्टवेयर विकसित करने या कर्मचारियों को प्रेरित करने के लिए उपयुक्त नहीं है।

2. युवा की अधीनस्थ स्थिति।


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

दो सप्ताह के एजाइल पुनरावृत्तियों (या स्प्रिंट) और उपयोगकर्ता कहानियों के साथ समस्या यह है कि कोई बाहर निकलने की रणनीति नहीं है। कोई विकल्प नहीं है "जब तक हम [एक्स] तक नहीं पहुँचते तब हमें ऐसा नहीं करना पड़ेगा।" इस प्रणाली को हमेशा के लिए माना जाता है: व्यवसाय-उन्मुख रैलियां कभी गायब नहीं होंगी। आर्किटेक्चर, आरएंडडी और उत्पाद विकास प्रोग्रामर के काम को छोड़ देते हैं क्योंकि वे परमाणु "उपयोगकर्ता कहानियों" और दो सप्ताह के स्प्रिंट में फिट नहीं होते हैं।

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

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

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

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

3. बहुत अल्पकालिक दृष्टिकोण, जो बेवकूफ और खतरनाक है।


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

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

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

जो लोग व्यर्थ कार्यों के फेरबदल से सहमत हैं, वे इसे सहन कर सकते हैं, लेकिन वास्तव में अच्छे इंजीनियरों को सोमवार की सुबह काम करने से नफरत है, यह नहीं जानते कि वे उस दिन क्या काम करेंगे।

4. करियर बनाने से उनका कोई लेना-देना नहीं है।


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

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

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

5. लक्ष्य कम दर निर्धारित करना है, लेकिन गलत सकारात्मक परिणामों का स्तर अस्वीकार्य रूप से उच्च है।


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

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

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

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

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

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

अक्सर, सबसे अच्छे कर्मचारी एजाइल / स्क्रैम कार्यान्वयन से पीड़ित होते हैं, क्योंकि आर एंड डी को प्रभावी ढंग से समाप्त कर दिया जाता है। अल्पकालिक "पुनरावृत्तियों" या स्प्रिंट के साथ जुनून का मतलब है कि कुछ नया, जोखिम भरा प्रयास करने में असमर्थता।

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

6. शराबी प्रभाव।


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

, , , : «» 7+ Scrum, 3- 4- 5-. , 7 5 , 5 3. ( ), , Scrum, .

Scrum Agile , . , , . 5 3 ( ) , .

Agile/Scrum , . , , , ( 50% , 10-30 ).

, , «» — . 22- 6, , 3 Scrum, 50- 9, , , 9 8,5, 3 6. , , . . , . , 5- , ( ) 4, 8 8.

7. .


Scrum. , Scrum « Agile», — Agile. (, : , Agile).

Scrum : , . , .

Scrum


, Agile , Scrum « » « ». , , .

, (, “Scrum Master”) . , « » ( ). , . «», , , , , , . , , . .

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

, . — « ». ( ) 4 , - , . -, , , .


, Scrum , «» : , , , . . .

, . , , . , , . , . , , .

(-?) , . Scrum - , (« ») ( «»), .

Agile Scrum . . , «-». . , , — , . , , .

, . , «» . , . , , « » ( ). , , Scrum — .

Agile Scrum, . , , , , . Scrum , — , , — «» , Agile . ( «-», ) .


, . . , -, , . , - , - « » — . : . Agile, , , , , — , , , . - — . , .

Source: https://habr.com/ru/post/hi430890/


All Articles