प्रभावी विकास का भ्रम: प्रबंधन

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

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

परिचय

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

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

प्रबंधक अभी भी लोग हैं

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

प्रोग्रामर भी लोग हैं

मुझे यह कहने की आवश्यकता है कि परियोजना का परिणाम उन पर किस हद तक निर्भर करता है? यह आवश्यक है। अपने क्षेत्र में व्यावसायिकता के स्पष्ट स्तर के अलावा, आपको यह समझने की आवश्यकता है कि निम्नलिखित कारक मायने रखते हैं:

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

और सोना चाहिए

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

एक महत्वपूर्ण मूल्य के रूप में यादृच्छिकता

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

पांच मिनट की सब्जेक्टिविटी

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

निष्कर्ष

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