कॉर्पोरेट ट्रोलिंग - 3, या अनावश्यक चिंताओं के बिना काम का वितरण

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

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

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

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

ट्रोलिंग दिशाओं का परीक्षण

आपको नहीं पता कि आपकी विफलता में कितने लोग रुचि रखते हैं! कोई आपकी मानसिक क्षमताओं के संबंध में अपने मामले को साबित करना चाहता है, कोई समय सीमा बढ़ाना चाहता है, कोई दंड का सपना देखता है, किसी को बीएमडब्ल्यू पर नए टायर की जरूरत है ... ऐसे मामलों में ट्रोल-किलर आयोग को सौंप दिया जाएगा (पहली पोस्ट देखें )। इस स्तर पर, ट्रोलिंग के तीन क्षेत्र हैं जिनसे आपको निपटना है:

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

अब विचार करें कि कार्य प्रस्तुत करते समय हमें वर्णित परेशानियों से बचने की क्या आवश्यकता है।

परीक्षण कार्यक्रम और कार्यप्रणाली

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

दस्तावेज़ की सामग्री के लिए आवश्यकताओं को GOST RD 50-34.698-90 के खंड 2.14 में वर्णित किया गया है, जिसे तकनीकी लेखक के डेस्कटॉप मानक के रूप में भी जाना जाता है। इस दस्तावेज़ में क्या होना चाहिए:

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

टेस्ट रिपोर्ट

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

परीक्षण रिपोर्ट में एक सामान्य भाग, एक परीक्षण तालिका और टिप्पणियों की एक सूची होती है।

जिस तालिका में परीक्षा परिणाम दर्ज किए जाते हैं, उसमें निम्नलिखित कॉलम हो सकते हैं:

1. संख्या के माध्यम से (आपके लिए सुविधाजनक प्रारूप में)। उदाहरण के लिए, Test_Number। Step_Number।
2. संचालक क्रिया। परिणाम प्राप्त करने के लिए ऑपरेटर क्या करता है। सुनिश्चित करें कि शब्दांकन गलत गलत व्याख्या को बाहर करता है।
3. अपेक्षित परिणाम सरल शब्दों में, ऑपरेटर के कार्यों का वर्णित परिणाम, जिसे चेक किया जा सकता है (स्पर्श, देखें, गंध)। उदाहरण के लिए: "शीर्ष पैनल पर हरी बत्ती जलाई गई है", "उपयोगकर्ताओं की सूची में एक नया उपयोगकर्ता दिखाई दिया है", "स्क्रीन पर एक गलत पासवर्ड के बारे में चेतावनी दर्ज की गई है", "सिस्टम लॉग एक्स में एक प्रविष्टि वाई दिखाई दी है"। सुनिश्चित करें कि शब्दांकन यथासंभव विशिष्ट है और दुर्भावनापूर्ण गलत व्याख्या को शामिल नहीं करता है। उन शब्दों को भी याद रखें जो ट्रोल्स के लिए खाद्य आधार हैं: "कोई भी", "सभी", "सभी", "कोई नहीं", आदि।
4. दस्तावेज़ीकरण की वस्तु (उदाहरण के लिए, उपयोगकर्ता गाइड), जो किए गए कार्यों का विस्तृत विवरण देती है या काम के बयान की गैर-कार्यात्मक आवश्यकता को बंद करती है। इस मद की उपस्थिति दो पक्षियों को एक पत्थर से मार देगी। सबसे पहले, आप यह दस्तावेज करेंगे कि डिजाइन प्रलेखन में सब कुछ परिलक्षित होना चाहिए। दूसरे, आपको ऑपरेटर के कार्यों को विस्तार से लिखना नहीं है, क्योंकि (ध्यान!) तकनीकी परियोजना की आवश्यकताओं को पूरा करने वाले कर्मचारियों के लिए परीक्षणों की अनुमति है, जिसमें आपने लिखा था कि उन्हें ऐसे और ऐसे पाठ्यक्रमों को लेना चाहिए और परिचालन दस्तावेजों से परिचित होना चाहिए।
5. इस कदम पर टीके के बिंदु या बिंदु बंद कर दिए जाएंगे। स्तंभ राशि सभी को देना चाहिए (बिल्कुल सब कुछ, बस कार्यात्मक नहीं!) टीके आवश्यकताओं। यही कारण है कि प्रोटोकॉल में दस्तावेज़ीकरण की पूर्णता की जांच के लिए "बेवकूफ परीक्षण" शामिल होंगे, जो प्रोग्राम जावा में लिखा गया है और ओरेकल डीबीएमएस डेटाबेस संबंधपरक है (हम प्रलेखन के संबंधित अनुभाग में एक उंगली पकड़ते हैं)।
6. आयोग का फैसला निम्नलिखित समाधानों पर जोर देना आवश्यक है: "पारित", "टिप्पणियों के साथ पारित", "पारित नहीं", "परीक्षण नहीं किया गया"। यहां अन्य प्रविष्टियां नहीं होनी चाहिए। प्रवेश "परीक्षण नहीं किया गया" उन परीक्षणों के लिए किया गया है जो आयोग आचरण नहीं करना चाहता था या परीक्षण के समय आचरण करना असंभव था। उदाहरण के लिए, उन्होंने क्लस्टर नोड को सॉकेट से बाहर नहीं निकालने का फैसला किया। यह बेहतर है कि प्रोटोकॉल में ऐसी कोई प्रविष्टि नहीं है, ताकि ट्रोलिंग के लिए कोई अनावश्यक अवसर न हो।
7. टिप्पणियाँ। यदि परीक्षण टिप्पणियों के साथ पारित किया जाता है, तो एक टिप्पणी संख्या होनी चाहिए। सभी टिप्पणियाँ अनुलग्नक में मुक्त रूप में प्रोटोकॉल में दर्ज की गई हैं। आप परीक्षण की संख्या निर्दिष्ट कर सकते हैं, जिसके दौरान टिप्पणियां थीं। आपके पास अधिक समय के लिए पर्याप्त समय नहीं होगा। यदि आयोग का निर्णय "पारित" है, तो कॉलम में कुछ भी नहीं लिखने का प्रयास करें "टिप्पणियाँ"

ड्रेस रिहर्सल

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

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

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

प्रभावी युगल

परिवर्तन के लिए इष्टतम टीम एक कार्यान्वयनकर्ता (या प्रोग्रामर) और एक व्यापार विश्लेषक (सलाहकार) की एक जोड़ी है।

कार्यान्वयनकर्ता (प्रोग्रामर):

• सिस्टम के साथ काम करता है, इंटरफ़ेस की महारत को प्रदर्शित करता है
• तकनीकी सवालों के जवाब

विश्लेषक (सलाहकार):

• ग्राहक के साथ सिस्टम के बारे में बात करता है, बातचीत करता है
• सामान्य सवालों के जवाब
• एक रिकॉर्ड रखता है
• कार्यान्वयनकर्ता (प्रोग्रामर) की तालिका के तहत किक

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

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

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

यह कुछ भी नहीं है कि पश्चिमी "आईटी प्रचारक" जोड़े में काम करना पसंद करते हैं।

प्रक्रिया शुरू हो गई है!

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

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

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

टिप्पणी

वे करेंगे, आपको कोई संदेह नहीं हो सकता। ऐसी कोई व्यवस्था नहीं है जिस पर कोई टिप्पणी न हो। आपका काम ग्राहक को सभी टिप्पणियों को महत्वपूर्ण और महत्वपूर्ण नहीं में विभाजित करने के लिए मजबूर करना है। ट्रायल ऑपरेशन में सफल स्थानांतरण के लिए पहले को सही किया जाना चाहिए। ट्रायल ऑपरेशन के दौरान दूसरे को सही किया जा सकता है। तदनुसार, यह बेहतर है कि पहले वाले बिल्कुल मौजूद न हों या केवल वही हैं जिनका सुधार मुश्किल नहीं है।

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

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

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

सब कुछ छूट गया तो क्या करें

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

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

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

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

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

निष्कर्ष

इसलिए, इस पर मैं कॉरपोरेट ट्रॉल्स पर त्रयी को पूरा करने के लिए जल्दबाजी करता हूं, जिसे डर नहीं होना चाहिए, लेकिन किसी तरह से सम्मान और यहां तक ​​कि प्यार भी किया जाना चाहिए, क्योंकि वे आईटी कारोबार के आलसी बंदरों को पेड़ों से लपटों से गिरने नहीं देते हैं, हमें अच्छे आकार में रखते हैं और हमें भी लाते हैं। insanely उबाऊ में कुछ रुचि है, लेकिन बहुत डिजाइन काम की जरूरत है।

UPD 06/23/2011 से । उपयोगकर्ता igendo टिप्पणियों में जोड़ता है कि अनुबंध के समापन के चरण में परियोजना के आधिकारिक दस्तावेजों के रूपों को पहले से ही अनुमोदित करना अच्छा होगा।

मैं बोली:

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

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

LiveJournal उपयोगकर्ता ryzhij_papa जोड़ता है कि व्यापार पर उनके प्रभाव की डिग्री पर टिप्पणियों की रैंकिंग का अभ्यास है, रैंकिंग तकनीक भी पीएमआई में दर्ज की गई है।

मैं बोली:

यह महत्वपूर्ण रूप से वर्णन करने के लिए आवश्यक है कि महत्वपूर्ण, उच्च, मध्यम और निम्न प्राथमिकता की टिप्पणियां क्या हैं। विवरण व्यवसाय के संदर्भ में बनाया गया है। यदि आप अतिरंजना करते हैं, तो यह है: $ 1000 के नुकसान के साथ महत्वपूर्ण प्राथमिकता, उच्च यदि $ 100, औसत जब कर्मचारी साबुन में होते हैं, लेकिन हमारे पास कोई नुकसान नहीं है, कम - ऐसे बग के साथ जीवन के 5-6 वर्षों तक मामूली पागलपन के मामले हो सकते हैं ...