हम इस बाइक को एक महीने में बनाएंगे

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

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

बाइक

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

वस्या को पहला आदेश मिला - हमें करना होगा ... एक साइकिल।

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

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

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

क्या करें?

1. बाइक डिजाइन करें।
2. योजना कार्य और संसाधन।
3. ग्राहक को एक तारीख दें।
4. एक बाइक बनाओ।
5. ??????
6. लाभ !!!! 11

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

कार्य योजना

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

हम अपनी समस्या का सबसे सरल अपघटन करते हैं:

जैसा कि कहानी से देखा जा सकता है, टीम को लगातार तैयार फ्रेम की कमी के कारण समस्या थी। इसलिए, पहले आपको एक फ्रेम बनाना था, और फिर बाकी काम करना था।


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


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

संसाधन और समयसीमा

आइए उपलब्ध संसाधनों पर परिणामी विकास योजना को थोपने का प्रयास करें:

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

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

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

पुनश्च: लेख, चित्र सहित, पूरी तरह से Google डॉक्स में प्रयोग के लिए बनाया गया है। सुविधाजनक बात, जैसा कि यह निकला!