क्यूए के काम को कैसे व्यवस्थित करें। एक व्यावहारिक तरीका

प्रागितिहास

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

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

एक नई टीम से मिलने के पहले दिनों में, मैंने लंदन कार्यालय के डेवलपर्स में से एक से एक ईमानदार हतप्रभ प्रश्न सुना, "आप यहाँ क्या करेंगे?"

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

लेकिन फिर भी, निश्चित रूप से, प्रक्रिया बिल्कुल सही नहीं थी: ऐसा हुआ कि डेवलपर्स ने आवश्यकताओं को नहीं समझा, कीड़े से चूक गए और ग्राहकों की ओर से अक्सर कुछ समस्याएं थीं जिनके लिए कार्रवाई की आवश्यकता थी।

टीम में अपनी स्थिति निर्धारित करने की आवश्यकता के साथ, मैं भी नेतृत्व में गया। केवल हमारा संवाद काफी अलग तरीके से बनाया गया था, न कि मेरे दोस्त की तरह।

क्यूए इंजीनियर के काम का संगठन

सही प्रश्न पूछें।

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

फिर भी, मेरे दो सवाल थे, जिनके जवाब मुझे नहीं पता थे। उनके साथ शुरू करने का सबसे आसान तरीका।

पहला सवाल। संगठन की संरचना क्या है, अर्थात् कौन किस पर खड़ा है और कौन किसके लिए जिम्मेदार है?

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

दूसरा सवाल। कंपनी ने परियोजना में क्यूए इंजीनियर को पेश किया, मेरे लिए उनकी क्या उम्मीदें हैं, इस स्थिति को खोलने में उनके लक्ष्य क्या थे?

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

इस पर, चर्चा का पहला भाग समाप्त हुआ।

हम एक्शन प्लान पर चर्चा करते हैं

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

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

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

हम क्यूए रणनीति बनाते हैं

1. गुणवत्ता आश्वासन का परिचय

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

परीक्षण QA का एक हिस्सा है। यह हमें उस सुविधा की गुणवत्ता का स्तर निर्धारित करने की अनुमति देता है जिसका हम आकलन कर रहे हैं।

क्यूए को अंजाम देना परीक्षकों की एकमात्र जिम्मेदारी नहीं है। पूरी टीम उत्पादों और सेवाओं की गुणवत्ता के उच्च स्तर को सुनिश्चित करने के लिए योगदान दे सकती है।

2. क्यूए रणनीति का परिचय

इस बारे में तैयारी करें कि लोग और अधिक क्या पढ़ेंगे।

परीक्षण रणनीति एक विकसित दस्तावेज है जो प्रक्रियाओं और जिस तरह से हम अपने उत्पाद की गुणवत्ता सुनिश्चित करने जा रहे हैं, उसे आगे बढ़ाते हैं।

सामग्री ध्वनि। यह या तो सामग्री की एक तालिका या अधिक सार वाक्य हो सकता है। यहां, टेस्ट दृष्टिकोण, टेस्ट प्रक्रिया, टेस्ट ऑटोमेशन रणनीति और टेस्ट प्लान की आवश्यकता के अस्तित्व का उल्लेख करें।

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

3. परीक्षण दृष्टिकोण

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

शैली और अच्छी तरह से काम कर रहे दृष्टिकोण के क्लासिक्स "सक्रिय" और "जोखिम-आधारित" हैं।

हम एक सक्रिय और जोखिम आधारित परीक्षण दृष्टिकोण अपनाएंगे।

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

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

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

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

• सीधे डिजाइन की कार्यक्षमता
• आसन्न और बातचीत क्षेत्रों
• व्यावसायिक रूप से महत्वपूर्ण कार्यक्षमता
• सबसे अधिक बार क्या टूटता है
• बैकवर्ड संगतता (यदि, उदाहरण के लिए, मेटाडेटा प्रारूप बदल दिया गया है, तो मौजूदा डेटा फ़ंक्शन सफलतापूर्वक होगा)

4. टेस्ट प्रक्रिया

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

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

हम फाउंडेशन स्तर ISTQB पाठ्यक्रम में उल्लिखित परीक्षण प्रक्रिया का उपयोग करेंगे: टेस्ट प्लानिंग एंड कंट्रोल, टेस्ट एनालिसिस एंड डिज़ाइन, टेस्ट इंप्लीमेंटेशन एंड एक्ज़ेक्यूशन, एविटेटिंग एग्जिट क्राइटेरिया एंड रिपोर्टिंग, और टेस्ट क्लोजर एक्टिविटीज़।

5. जिम्मेदारियां

उत्पाद की गुणवत्ता में सुधार के क्षेत्र में अपनी और दूसरों की जिम्मेदारियों को पहचानें। अपने मिशन की रिपोर्ट करें।

सबसे पहले, फिर से जोर दें कि प्रत्येक टीम का सदस्य अपने आप में एक परीक्षक है , हर कोई परीक्षण कर रहा है कि वे किससे संबंधित हैं। कोड लिखा - इसका परीक्षण करें।

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

तीसरा, इंगित करें कि आप प्रबंधकों और डेवलपर्स के साथ कैसे बातचीत करते हैं । उदाहरण के लिए, तीन अमीगोस फुर्तीली दृष्टिकोण पर रोकें

व्यवसाय, विकास और क्यूए के बीच सहयोग
एक। व्यवसाय - हम किस समस्या को हल करने की कोशिश कर रहे हैं?
ख। विकास - हम उस समस्या को हल करने के लिए एक समाधान कैसे बना सकते हैं?
सी। परीक्षण - इसके बारे में क्या, संभवतः क्या हो सकता है

6. परीक्षण स्तर और क्यूए स्वचालन रणनीति

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

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

7. फ़ीचर वर्कफ़्लो

आज, मेरी परियोजना दो सप्ताह के स्प्रिंट का उपयोग करते हुए स्क्रैम पर काम करती है। इसलिए, मेरे पास प्रत्येक कहानी के लिए एक चरण-दर-चरण लिखित जीवन चक्र दस्तावेज़ है।

परियोजना जिस भी पद्धति का पालन करती है, उसका वर्णन करें कि दैनिक कार्य चरण दर चरण कैसे करें। यदि ऊपर हमने कार्रवाई की रणनीति के बारे में अधिक बात की है, तो स्पष्ट संकेत होना चाहिए कि पहले क्या आता है, फिर क्या।

उदाहरण के लिए, मेरा संस्करण है

नीचे दिया गया वर्कफ़्लो उस प्रक्रिया का विवरण देता है जिसे हम आंतरिक रूप से अपनाएंगे।
1. योजना सत्र से पहले कहानी प्राप्त करें
2. स्वीकृति मानदंड और विवरण के अनुसार एक चेकलिस्ट बनाएं
3. अस्पष्ट विवरण / प्रश्न नोट करें
4. योजना पर सवाल स्पष्ट करें
5. चेकलिस्ट को अपडेट करें
6. किसी भी निर्भरता को हाइलाइट करें और आप उन्हें कैसे दूर करने जा रहे हैं
7. जब कहानी समीक्षा की जाँच में है कि स्वीकृति मानदंड ऑटोटेस्ट द्वारा कवर किए गए हैं
8. डेवलपर को सभी स्वीकृति मानदंडों को ऑटोटेस्ट के साथ कवर करने के लिए प्रोत्साहित करें या स्वयं करें
9. जब परीक्षण के लिए कहानी तैयार हो जाती है तो चेकलिस्ट का उपयोग करके मैन्युअल परीक्षण करें
10. कहानी के लिए बग बनाएँ और यदि वे मौजूद हैं और आइटम को विकास में लौटाते हैं
11. जब बग्स को ठीक किया जाता है तो चेकलिस्ट का उपयोग करके फिर से मैन्युअल परीक्षण करें
12. जांचें कि क्या सभी ऑटोटेस्ट पास हैं
13. यदि आवश्यक हो तो अतिरिक्त एकीकरण ऑटोटेस्ट को लागू करने के लिए एक कार्य बनाएं
14. QA उत्तीर्ण राज्य में कहानी ले जाएँ

8. टेस्ट प्लान

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

इस परियोजना पर, मेरी टेस्ट योजना प्रत्येक कहानी के लिए जाँचकर्ताओं का एक समूह है। स्वचालन के वर्तमान स्तर के साथ, यह अभी के लिए पर्याप्त है।

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

यदि आपके पास बहुत सारे मैनुअल परीक्षण हैं, तो परीक्षण मामलों को विस्तार से लिखें, ताकि परियोजना में आने वाले कोई भी नया QA इंजीनियर स्वतंत्र रूप से प्रदर्शन कर सके।

दस्तावेज़ के साथ कैसे काम करें

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

प्रत्येक वाक्य को लिखते समय, प्रश्नों के बारे में सोचना अच्छा होगा: "क्या मैं वास्तव में इस तरह काम करना चाहता हूं?" , "क्या मैं वास्तव में इस परियोजना पर जीवन लाने जा रहा हूं?"

यदि दोनों उत्तर सकारात्मक हैं, तो आत्मविश्वास से प्रिंट करें।

यदि उत्तरों में से एक "नहीं" है, तो मेरी राय में, यह एक निश्चित संकेत है कि अनावश्यक कर्तव्यों को न लटकाएं।

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

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

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

धन्यवाद!