जिम्मेदारी और जिम्मेदारियों के बारे में थोड़ा सा

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

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

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

गुणवत्ता की लड़ाई में यह भयानक अराजकता क्यों पैदा होती है? मैं लेआउट और डिज़ाइन के आधार पर एक उदाहरण दूंगा। मुझे लगता है कि प्रोग्रामर आसानी से इसी तरह के उदाहरण पा सकते हैं।
So.

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


वह कोड कुछ इस तरह लिखते हैं:
<h1> साइट पर आपका स्वागत है! </ h1>
एच १ {
फ़ॉन्ट-आकार: 14 पीएक्स;
रंग: # 000000;
}
लेकिन उसके बाद वह कुछ इसी तरह के तत्व का सामना करता है, जिसमें, हालांकि, मतभेद हैं । वह याद करते हैं कि हमें डिजाइन का सख्ती से पालन करना चाहिए ... यह प्रबंधक का निर्णय है । इसलिए, तत्व को पूरा करना:


वह, एक अच्छा टाइपसेटर के रूप में जो कैस्केडिंग स्टाइल शीट को समझता है, पिछले तत्व में एक नया वर्ग जोड़ता है:
<div class = "आवरण ब्लॉक ">
<h1> पासवर्ड पुनर्प्राप्ति </ h1>
div.block h1 {
फ़ॉन्ट-आकार: 16 पीएक्स;
फ़ॉन्ट-वजन: बोल्ड;
गद्दी: 6px 0pt 4px 14px;
मार्जिन: 0pt;
}
इसके बाद, कोड प्रोग्रामर के पास जाता है। वह स्पष्ट रूप से जानता है कि लेआउट डिजाइनर एक पेशेवर है, और उसने स्पष्ट रूप से सोचा कि किन शैलियों को पेश किया जाए। यदि एच 1 हेडर के लिए उपयोग किया जाता है, तो आपको इसे हर जगह की तरह उपयोग करने की आवश्यकता है। जब उसे पृष्ठ पर शीर्षक प्रदर्शित करने की आवश्यकता होती है, तो सही प्रोग्रामर के रूप में, उसने एच 1 टैग के साथ शीर्षक को तैयार किया है। वह ब्लॉक वर्ग के बारे में नहीं जानता है, जो उसे इस विशेष मामले में डालना था। इसलिए ...
कुछ समय बाद, लेआउट डिजाइनर को परीक्षकों से एक बग मिलता है, जो यथोचित सवाल पूछते हैं: "हम पृष्ठों पर अलग-अलग शीर्षक क्यों रखते हैं?"। टाइपसेटर साहसपूर्वक भूली हुई ब्लॉक क्लास को जहाँ कहीं भी आवश्यक हो, नीचे रख देता है।
इतिहास खुद को एक सर्कल में पर्यावरणीय स्थिरता के साथ दोहराता है। लेकिन अन्य ब्लॉकों, अन्य पात्रों और शैलियों के साथ।

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

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

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

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

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

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

यहाँ मूल: http: //yuri.shilyaev.com ...