गुणवत्ता की "पहली ताजगी" - "फ्रिज" की वेब परियोजनाएं

मैंने लंबे समय से देखा है कि वेब प्रोजेक्ट "ताजगी" के विभिन्न वर्गों में भिन्न हैं ...

पहली ताजगी

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

प्रबंधक के लिए पुनरावृत्तियों + TK के माध्यम से या विश्वसनीय स्क्रम / एजेंडा मोड में काम करके इस तरह के उत्पाद के विकास का प्रबंधन करना अच्छा है। गैर-महत्वपूर्ण जोखिमों और खंडित समय बदलावों की बारियां उत्पाद की विश्वसनीयता और जीवन शक्ति की सामान्य समझ से सुचारू हो जाती हैं। प्रबंधक विचारों से समृद्ध है, सुविधाओं में समृद्ध है, और सर्वोच्च प्राथमिकता वाले कार्यों के नियमित कार्यान्वयन के बाद, नैतिक संतुष्टि और आशावाद की खुराक प्राप्त करता है ... और इस कंपनी में काम करना जारी रखना चाहता है :-)

तकनीकी समर्थन मामूली त्रुटियों को ठीक करता है, मुख्य रूप से प्राथमिकता वाले गुलदस्ते में ग्राहकों की इच्छाओं को इकट्ठा करता है।

संक्षेप में, खुशबू और श्रद्धा की तरह कुछ महसूस किया जाता है, और यह हर किसी द्वारा नोट किया जाता है - और सबसे ऊपर, और प्रबंधक, और डेवलपर्स, और समर्थन।

दुर्भाग्य से, ऐसी परियोजनाएं / उत्पाद पाए जाते हैं ... अक्सर। लेकिन वे करते हैं।

दूसरी ताजगी

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



कुछ के विकास में शामिल डेवलपर्स के समूह, चलो उन्हें उत्पाद के "क्षयकारी" भागों को कहते हैं, "विधवाओं, इस मॉड्यूल को लिखने वाले आनुवंशिक मूर्खों" या "कमजोर-दिमाग वाले प्रबंधकों" के बारे में व्यंग्य के संकेत दिखाना शुरू करते हैं, जो ऊपर या नीचे की ओर से जाने वाले शब्दों को मानते हैं, बिना किसी राय के। विकास दल। " "खरोंच से ब्लॉक / मॉड्यूल को फिर से लिखने की तत्काल आवश्यकता के बारे में बातचीत अभी तक ध्यान नहीं दी गई है।"

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

समर्थन अभी भी रक्षा रखता है, 3 महीने के लिए गर्मियों के छात्रों द्वारा या किसी भी तंत्रिका तंत्र वाले कर्मचारियों द्वारा उत्पाद की समस्या वाले क्षेत्रों को कवर किया जाता है।

समय-समय पर, सहकर्मियों ने एक मृत व्यक्ति की खंडित उपस्थिति के घ्राण संकेतों पर ध्यान दिया, लेकिन उन्हें अस्थायी मानें (प्रबंधक, प्रोग्रामर सबसे अधिक संभावना है कि समस्या के बारे में पहले से ही चिल्लाएं और आग लगा दें, सुनने की उम्मीद है)।

इस स्थिति में सबसे अजीब बात यह है कि कुछ परियोजना प्रबंधन समूह, कभी-कभी सबसे ऊपर, जानबूझकर अपने कानों में धुंधली पट्टियाँ और इयरप्लग पहनते हैं, उनके चेहरे से एक झूठी मुस्कान निचोड़ते हैं। जाहिरा तौर पर वे 2-3 साल से अधिक समय तक कंपनियों में काम करने के आदी हैं, इसलिए वे आसन्न आपदा के बारे में ध्यान नहीं देते हैं।

कचरा कर सकते हैं

और कल्पना कीजिए, प्रोग्रामर ऐसी परियोजनाओं में काम कर सकते हैं! लेकिन ये आमतौर पर विशेष व्यक्तित्व होते हैं:

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

2) पम्पिंग पर ट्रोल। सहकर्मी एक चरम गड़बड़ी से प्रेरित हैं और एक्सपी और डिजाइन पैटर्न के अपने ज्ञान को बहुतायत से प्रस्तुत बायोमेट्रिक पर पंप करते हैं। बेशक, कोई भी रिफैक्टिंग के बारे में नहीं सोचता है, विशेष रूप से मॉड्यूलरिटी - बस काटना।

३) छात्र। लोगों को हर कीमत पर कोई अनुभव प्राप्त करने की आवश्यकता है। खैर, क्या गलत है अगर वे 75 स्थानों पर आपके बिलिंग को तोड़ते हैं और व्यवहार में तीसरे सामान्य रूप को दूसरे से अलग करना शुरू करते हैं, तो अनियमित रूप से वित्तीय लेनदेन के एक जोड़े को खोने और 5000 पतों की ग्राहक सूची से एक मेलिंग सूची भेजने के लिए: "टेस्ट !!!" भाड़ 1 - ठीक है, बकवास 2 - त्रुटि, बकवास 3 - अशक्त। "

आपकी विकास टीम का एक बड़ा कारोबार होगा, आपको लोगों को लुभाना होगा - लेकिन, ध्यान दें, लोग अभी भी बने रहेंगे। सच्चे काम की संभावना नहीं है।

प्रबंधन। यहाँ बेतुका रंगमंच है।

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

"पागलों" - इस तरह के चरम परियोजनाओं में कहीं से भी, प्रबंधकों को दिखाई देता है ... जो इसे पसंद करते हैं। वे देर शाम तक काम करने के लिए दौड़ेंगे, "नाव पर खड़े", पैडलिंग डेवलपर्स और निचले स्तर के प्रबंधकों को "दलदल" में लहराते हुए व्यवस्थित रूप से समाप्त करें।

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

लेकिन संकट प्रबंधकों के बारे में क्या? :-) मुझे विश्वास है कि उन्हें "दूसरी ताजगी" के उत्पादों के लिए आना चाहिए - और यहाँ सबसे अधिक संभावना है कि आप कुछ भी नहीं बदलेंगे।

क्या किसी उत्पाद को हमेशा "पहले ताजगी" में बनाए रखना संभव है?

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

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

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

इस बीच, सरल, अनुभव-परीक्षणित नियमों से चिपके रहें:

1) कई अच्छे प्रोग्रामर खोजने की कोशिश न करें। एक खोजने की कोशिश करें और इसे 2-3 गुना अधिक महंगा होने दें। बाकी छात्र, शुरुआती, मध्यवर्ती आदि हो सकते हैं। - प्रोजेक्ट बजट के अनुसार।

2) यदि परियोजना में जटिल व्यावसायिक तर्क, बिलिंग आदि हैं। - तैयार समाधान / ढांचे ( ZendFramework , BitrixFramework , आदि) का उपयोग करें - इसलिए आपको कुछ भी जटिल नहीं करना है। यदि यह काम नहीं करता है, तो एक, अच्छा, सिस्टम विश्लेषक ढूंढना सुनिश्चित करें।

3) इन सहयोगियों को कुछ भी नहीं बनाना चाहिए। उनका कार्य तंग नियंत्रण और स्क्रीनिंग है। कोड, एपीआई, वास्तुकला उनके माध्यम से गुजरते हैं, या वे समझौता किए बिना नहीं गुजरते हैं। हां, सबसे पहले आपके पास एक कर्मचारी टर्नओवर होगा, लेकिन फिर ऐसे लोग होंगे (या उपरोक्त विशेषज्ञ उन्हें शिक्षित करेंगे) जो उच्च गुणवत्ता और सामान्य ज्ञान फिल्टर के माध्यम से पारित होने वाले कामों को करने में सक्षम होंगे।

4) हर दिन, साथी विशेषज्ञों से पूछें:
- क्या उत्पाद को मॉड्यूलर बनाया जा रहा है? अपेक्षित उत्तर: हां, या रिफैक्टिंग का काम सौंपा गया है।

5) सुनिश्चित करें कि समय का एक निश्चित प्रतिशत हमेशा रीफैक्टरिंग (नई कार्यक्षमता जोड़ने के बिना कोड को बदलते हुए) के लिए आवंटित किया जाता है। यह बहुत महत्वपूर्ण है।

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

7) परियोजना पर परीक्षण करने से डरो मत ... आपकी कंपनी के कर्मचारी और ग्राहकों के कुछ समूह। जितना अधिक आप आंख ढूंढते हैं, उतना बेहतर है। समझें कि आपको 100 या अधिक लोगों के कर्मचारियों के साथ एक परीक्षण विभाग बनाने की अनुमति नहीं दी जाएगी :-)

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

9) अपने प्रोजेक्ट टीम को अपने सभी साथियों - सहयोगियों और टॉपर्स से सुरक्षित रखें। रचनात्मकता की प्रशंसा करें और प्रोत्साहित करें, जीवन का माहौल बनाएं। किसी को भी निराशाजनक रूप से "फ्रिज" को तोड़ने न दें जो आपके उत्पाद / परियोजना को ताजा रखता है।

दिल मत हारो, अगर आपकी परियोजना सभी समान रूप से लड़खड़ाने लगी है - इसे जल्द से जल्द एक नए राज्य में वापस करने की कोशिश करें, रिफैक्टिंग के लिए समय बढ़ाना और अपर्याप्त शर्तों के बाहरी दबाव को बनाए रखना और आवश्यकताओं को बदलना। आप अवश्य सफल होंगे।

सौभाग्य है