सर्गेई आर्किपेनकोव - सिद्धांत और अनुकूली परियोजना प्रबंधन का अभ्यास

Arkhipenkov सर्गेई - सॉफ्टवेयर विकास प्रबंधन में एक विशेषज्ञ, सॉफ्टवेयर विकास में 30 से अधिक वर्षों, PMP® PMI, प्रोजेक्ट मैनेजरों के उपाध्यक्ष। सॉफ्टवेयर विकास परियोजनाओं में परियोजना और लोगों के प्रबंधन के सिद्धांत और व्यवहार का एक सक्रिय "प्रमोटर" और "पुशर"। कार्यक्रम समितियों के सक्रिय सदस्य। उत्तरार्द्ध में - सम्मेलन की कार्यक्रम समिति के अध्यक्ष "सॉफ्टवेयर परियोजना प्रबंधन सम्मेलन" (नवंबर, सेंट पीटर्सबर्ग)।

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



रिपोर्ट वीडियो:
।

ऑडियो रिपोर्ट
polazhenko.podfm.ru/my/14/download/arhipenkov.mp3

स्लाइड:
www.slideshare.net/codefest/s-arkhipenkov-codefest

रिपोर्ट पाठ:
धन्यवाद, आयतोम, उन सभी आयोजकों को धन्यवाद जिन्होंने मुझे इस तरह के प्रतिनिधि दर्शकों से बात करने के लिए आमंत्रित किया।
सुप्रभात, प्रिय सहयोगियों, या बल्कि, सहकर्मियों को नहीं, बल्कि भाइयों को ध्यान में रखकर। क्योंकि एक प्रोग्रामर एक पेशा नहीं है ... निदान किसने कहा? (हँसी) - नहीं, निदान नहीं, एक प्रोग्रामर सोच का एक तरीका है और एक विशेष मानसिकता है।

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

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



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



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



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



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



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



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



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



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



सिद्धांत २ प्रभावी कार्य के लिए चार आवश्यक और पर्याप्त शर्तें।
प्रोग्रामर के लिए सेट को प्रभावी ढंग से हल करने के लिए, यह आवश्यक है कि वह:
1) मैं कार्य के लक्ष्य को समझ गया। स्पष्ट रूप से - पैसा बनाओ
२) काम कैसे करना है, कैसे करना है।
3) यदि हम एक प्रोग्रामर को प्रोग्राम लिखने के लिए मजबूर करते हैं, तो आपको उसे खाली समय देने की आवश्यकता है, ठीक है, अधिमानतः एक कंप्यूटर, हालांकि जीवन में हमने स्लिप्स पर लिखा था, फिर पंच को सौंप दिया और कंप्यूटर नहीं देखा, लेकिन अब एक कंप्यूटर की जरूरत है। यानी एक व्यक्ति को इस समस्या को हल करने में सक्षम होना चाहिए।
4) यदि किसी व्यक्ति की कोई इच्छा नहीं है, तो उसे आवंटित किए गए किसी भी समय के लिए कार्य को हल नहीं किया जा सकता है। यह व्यक्ति आपको 101 कारण बताएगा कि यह एक बार फिर क्यों टूट गया। यदि कोई मकसद नहीं है, तो वह कम से कम एक अवसर की तलाश नहीं करेगा जो उसे इस समस्या को हल करने में मदद करेगा। इसलिए, कार्य को दूसरे प्रोग्रामर में स्थानांतरित करें, और उसे कुछ दिलचस्प दें।



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

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



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

अगली कहानी Zvezdun है।



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



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

ठीक है, पहले एक उदाहरण, इससे पहले कि हम निम्नलिखित सिद्धांत का नाम दें।



एक उदाहरण है। संकोची।

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



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

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

, , – – , . . – , – , – . – .
, .

. .



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



, , : , forming, storming, norming, performing – , , , Storming. , – - . , . , – ? – , , : 10 000 , 250 000 . , , – .
– , , , - . , , -. .

.



– , – , - . - , open source , , , , – , , - , . , , . , – . , – , – . – , .
, .
, ,

7. «».



, , , , . . ., . – . , , – …
, , , , , - – , , , , , .
– , . , .
. , , – , , .
– – - , . , , Scrum. . , . , . . . RUP, , , .
, – , , , best practices.
. – , , , , .
, , . . , , , . , , . , . , , , , , . , , . , – , — , , 4 500 , – , . – -, , . . , , , , – , – , , , , - , , – – .