इस सॉफ़्टवेयर डेवलपमेंट प्रोजेक्ट चेकलिस्ट में आप क्या जोड़ेंगे? [बन्द है]


14

मैं चेकलिस्ट का बहुत बड़ा प्रशंसक हूं। नहीं है सफर चेकलिस्ट , चेकलिस्ट बढ़ते और यहां तक कि एक स्क्रम चेकलिस्ट

संदर्भ : आपको एक बड़े निगम द्वारा काम पर रखा गया है और पूरे सॉफ्टवेयर विकास पर्यावरण, प्रक्रियाओं, टीम, आदि की स्थापना के लिए मिशन दिया गया है। आपके पास "कार्टे ब्लैंच" है। आप सॉफ्टवेयर के कामकाजी वेतन वृद्धि के लिए जिम्मेदार होंगे। परियोजना का आकार: 2000 आदमी / दिन।

आप निम्नलिखित (जानबूझकर छोटे और अपूर्ण) चेकलिस्ट में क्या आइटम जोड़ेंगे:

  • एक सतत एकीकरण सर्वर स्थापित करें
  • एक DoD लिखें
  • एक पृष्ठ कोडिंग दिशानिर्देश लिखें
  • एक उत्पाद बैकलॉग बनाएँ
  • बग ट्रैकिंग सिस्टम स्थापित करें
  • नियमित चेहरा समय निर्धारित करें

जवाबों:


10

(1) डेवलपर्स से बात करें कि उन्हें वास्तव में क्या चाहिए! *

2.) वास्तव में तेजी से कई वातावरण लाने के लिए एक समाधान की जांच करें (यदि सार्वजनिक या निजी क्लाउड इंस्टेंस या पुराने ज़माने की आभासी मशीनों पर विचार करें, यदि आप इसका अनुपालन नहीं करते हैं)

3.) स्रोत / संस्करण नियंत्रण

4.) कोड समीक्षा प्रणाली (एक उदाहरण के रूप में Crucbile / Fisheye)

5.) कंबन की दीवार (या कुछ इसी तरह की)

6.) संचार प्रोटोकॉल (वास्तविक समय चैट एक बड़ा प्लस है), विकी भी सहयोग को प्रोत्साहित करते हैं। यह आंतरिक रूप से जनसंपर्क को भी कवर करता है - आप अपने व्यवसाय के मालिकों, तकनीकी सहायता कर्मचारियों और अन्य समूहों के साथ कैसे जुड़ने जा रहे हैं?

7.) इलेक्ट्रॉनिक व्हाइटबोर्ड

8.) डेवलपर्स के लिए आरामदायक वातावरण (सोफे, टेबल, चिलआउट एरिया, अच्छा वाईफाई आदि)

9.) बढ़िया कॉफ़ी !!!


cofee फर्क करता है:) + 1
RBA

आपके द्वारा उपयोग किए जाने वाले इलेक्ट्रॉनिक व्हाइटबोर्ड क्या हैं?

@Pierre 303 - एक सफेद बोर्ड सत्र के परिणामों को प्रिंट करना (उच्च-गुणवत्ता वाला फोटो वही चाल करेगा जो मुझे लगता है)।
मार्टिज़न वर्बर्ग

8
  • Toolchain setup - IDEs, CI सर्वर, कोड क्वालिटी सर्वर, सोर्स कंट्रोल, वेबसर्वर, डेटाबेस, इश्यू ट्रैकर आदि।
  • बैकअप - टीम में प्रत्येक व्यक्ति की क्या भूमिका है? वह कौन-सी प्रक्रिया / मॉड्यूल करता है, वह 'खुद' करता है और उसका बैकअप कौन है?
  • (उपयोगकर्ता-स्वीकृति) परीक्षण पर्यावरण सेटअप - न केवल निरंतर एकीकरण w। इकाई परीक्षण, लेकिन वास्तव में खराब चीजों, कई प्लेटफार्मों, एप्लिकेशन सर्वर, वीएम आदि को कवर करने के लिए एकीकरण परीक्षण।
  • प्रदर्शन टेस्ट सेटअप - पहले बेहतर, चूंकि आपको जवाब देने के लिए ऐतिहासिक डेटा की आवश्यकता होगी "किस फीचर / मील के पत्थर के साथ प्रदर्शन में इतनी गिरावट आई?"
  • (अंतिम-उपयोगकर्ता) प्रलेखन रूपरेखा - प्रलेखन में क्या होने जा रहा है? किस प्रकार के दस्तावेजों की आवश्यकता है?
  • विपणन चैनल - आंतरिक मील के पत्थर और बाहरी रिलीज की घोषणा कैसे की जा रही है? क्या आपके पास सॉफ्टवेयर, लोगो, रंग, शब्द आदि के लिए एक अच्छा नाम है?
  • आंतरिक संचार - परिवर्तन के बारे में अन्य टीमों के साथियों को कैसे सूचित किया जाएगा? सहयोग कैसे किया जा रहा है? विकी? पहुंच अधिकार?
  • गुणवत्ता आश्वासन लोग और प्रक्रिया - कौन क्या, कितनी बार और किन मानदंडों के साथ परीक्षण करने जा रहा है?
  • रिहाई की प्रक्रिया - कब, कितनी बार, कैसे, कौन कर रहा है, कौन जारी कर रहा है आदि।
  • जोखिम प्रबंधन - वर्स्ट-केस परिदृश्य (एक प्रोजेक्ट एमजीएमटी पीओवी और एक रनटाइम पीओवी से, उदाहरण के लिए 'ग्राहक पैसा खो रहा है क्योंकि सॉफ्टवेयर मॉड्यूल एक्स पर विफल रहा है, बैकअप योजना क्या है?)
  • मुख्य विकास पर्यावरण की सुरक्षा , उदाहरण के लिए इसे एस्क्रो के लिए वर्चुअलाइज करना
  • औपचारिक और अनौपचारिक बैठकों के लिए स्थान
  • सभी लोगों के लिए प्रशिक्षण या इंट्रो, इसलिए वे जानते हैं कि सभी सेटअप क्या हैं, प्रत्येक भाग क्या है और वे इसका उपयोग कैसे करते हैं।
  • कार्यवाहक की पहचान करना और उसे सभी चीजें देना (जैसे अनुमतियाँ) उसे वास्तव में ध्यान रखना चाहिए जब चीजें खराब हो जाती हैं

बैकअप और प्रशिक्षण के लिए +1
Liviu T.

बैकअप, मुझे लगता है कि इसमें से कुछ अतिरंजित है।
BlackICE

5

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


4

आइए अपने प्रोजेक्ट के लिए सही पेशेवरों की एक अच्छी टीम को किराए पर लें। एक विशिष्ट व्यवसाय ऐप में आपको एक डेटाबेस डेवलपर और एक डीबीए, एक क्यूए व्यक्ति, एक सिस्टम व्यवस्थापक, एक व्यापार विश्लेषकों, एप्लिकेशन डेवलपर्स, एक यूआई विशेषज्ञ और टीम को न्यूनतम स्थान पर रखना होगा। डीबीए, सिस्टम एडमिन, व्यापार विश्लेषकों और क्यूए को विकास टीम से अलग रिपोर्टिंग श्रृंखला में होना चाहिए। विकास डेटाबेस विशेषज्ञ को एप्लिकेशन डेवलपर्स और UI विशेषज्ञ के समान तकनीकी लीड को रिपोर्ट करना चाहिए।

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

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

जैसे ही सर्वर सेट होते हैं, फाइल sytem, ​​डेटाबेस और डेटाबेस ट्रांजेक्शन लॉग का बैकअप निर्धारित करते हैं। ऐसा करें कि पहले दिन चीजें सेट-अप हों। साप्ताहिक बंदी का बैकअप लेने के लिए आयरन माउंटेन जैसी फर्म को किराए पर लें।

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

वाणिज्यिक सॉफ़्टवेयर खरीदें या उन टूलसेट के लिए ओपन सोर्स सॉफ़्टवेयर डाउनलोड करें, जिसे आपने सभी उचित उपयोगकर्ताओं के लिए लाइसेंस के साथ उपयोग करने का निर्णय लिया था।

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

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

निर्धारित करें कि किस क्रम (महत्वपूर्ण पथ) में क्या करना है। महत्वपूर्ण पथ के अंत में कार्यों को तब तक असाइन न करें जब तक कि वे जिन कार्यों पर निर्भर करते हैं वे पूर्ण नहीं हैं।

टेस्ट प्लान और आवश्यकताएं बनाएं।

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

प्रदर्शन परीक्षण के लिए एक वातावरण सेट करें, न केवल एक उपयोगकर्ता की गति, बल्कि एक जहां आप एक साथ उपयोगकर्ताओं की अपेक्षित संख्या का परीक्षण कर सकते हैं। लाइव होने से पहले दिन तक इस परीक्षण को करने के लिए इंतजार न करें।

प्रोजेक्ट प्लानिंग में, मान लें कि क्यूए को कीड़े मिलेंगे और उन्हें ठीक करने में समय लगेगा। अंत में केवल एक दिन के लिए क्यूए शेड्यूल न करें।

परीक्षण डेटा बनाएँ जो मोटे तौर पर आकार आपको लगता है कि डेटाबेस होगा। सभी डेवलपर्स इस आकार के डेटाबेस के खिलाफ अपने कोड का परीक्षण करें। डेवलपर्स को केवल अपने व्यक्तिगत मशीनों पर एक छोटे डेटाबेस के खिलाफ विकसित करने की अनुमति न दें। यह कोड का एक लगातार कारण है जो उत्पादन को हिट करने तक ठीक काम करता है।

बजट में पुरस्कार की योजना बनाएं। यह लोगों को तब डिमोटिव करता है जब वे महीनों के लिए अपने चूतड़ों को काम करते हैं और केवल प्रबंधकों को बोनस मिलता है। साथ ही बार-बार और लिखित रूप से धन्यवाद कहें।

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


मुझे लगता है कि परीक्षण उपयोगकर्ता मशीन "धीमी गति से चल रही" होनी चाहिए, न कि "धीमी गति से चिल्ला";) बहुत अच्छी सूची।
BlackICE

@ डेविड, मुझे आपका सुझाव पसंद आया और मैंने इसे पाठ में बदल दिया है।
HLGEM

शानदार जवाब - बुलेट पॉइंट या सेक्शन के नाम थोड़ी मदद कर सकते हैं।
JBRWilkinson

3

कुछ चीजें जो मैं सवाल और बाद के उत्तर में नहीं देखता:

  • आपदा पुनर्प्राप्ति योजना। आप देव बक्से, मंचन, परीक्षण आदि का समर्थन कैसे कर रहे हैं? क्या हर देव के पास कभी-कभार बर्फ के दिन घर से काम करने की जरूरत होती है? आदि।

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

  • एक उपकरण की स्थिति। क्या यह "हम आपको सभी MSDN सदस्यता प्रदान करते हैं? कृपया अपने कार्य मशीनों पर कुछ और स्थापित न करें" तरह का स्थान या "हम आपका कोड चाहते हैं, लेकिन हमें परवाह नहीं है कि आप इसका उपयोग क्या करते हैं, इसे संकलित और परीक्षण करने के लिए उपयोग करते हैं।" “तरह की जगह। निर्णय लें और रिकॉर्ड करें।

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


2

अधिक मानव-दिन नेगोटिएट करें।

यह एक दुर्लभ घटना है जब लोग शुरू में पर्याप्त रूप से आवंटित करते हैं।

[बाद में ... फिर से और भी नकारात्मक ...]


यह देखने के बाद कि अधिक आदमी दिनों पर हमेशा बातचीत करनी चाहिए कुछ ऐसा नहीं है जिसकी मैं सिफारिश करूंगा, मैं नौकरी या परियोजनाओं की अवधि के सटीक और विश्वसनीय अनुमान प्रदान करना पसंद करूंगा।
निमचम्पस्की

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

@ ओर्ब्लिंग वे मौजूद हैं जहां मैं काम करता हूं। ब्रिटेन में एक फुट 250 सूचीबद्ध राष्ट्रीय खुदरा विक्रेता। कुछ परियोजनाएं देर से हैं, लेकिन देर से नहीं, और वे अपवाद हैं।
निमचिम्प्स्की

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

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

2

3 पार्टी पुस्तकालयों और उनके उपयोग के साथ मुझे सबसे अधिक समस्या हुई है:

  1. उन पुस्तकालयों और संस्करणों का निर्धारण करें जिनका आप उपयोग करने जा रहे हैं।
  2. अपनी परियोजना के लिए पुस्तकालय अद्यतन को एकीकृत करने की प्रक्रिया बनाएँ।
  3. सुनिश्चित करें कि डेवलपर्स सभी पुस्तकालय विकल्पों पर बोर्ड पर हैं।
  4. उपयोग की जा रही प्रौद्योगिकियों पर खुली चर्चा के लिए एक लाभकारी चैनल बनाएं।

क्यों? मैं आपको कई बार नहीं बता सकता कि तीसरी पार्टी के पुस्तकालयों (मालिकाना) में कई बार कीड़े थे जिन्होंने हमें विकास के हफ्तों में वापस भेजा क्योंकि हमारे पास ऊपर या नीचे जाने की कोई प्रक्रिया नहीं थी। या डेवलपर्स के साथ यह कहते हुए कि "आपने किस संस्करण का उपयोग किया? आपने चिह्नित कार्यों का उपयोग क्यों किया?"


1

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

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

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


मैं उत्सुक हूं, यह प्रोजेक्ट सेटअप चेकलिस्ट का हिस्सा होना चाहिए? मैं इसे सॉफ्टवेयर डेवलपमेंट के हिस्से के रूप में रखूंगा, लेकिन मुझे प्रोजेक्ट सेटअप के बारे में जानकारी नहीं है। मैं इसे देव मील के पत्थर के साथ रखूँगा, लेकिन मुझे नहीं लगता कि ओपी के बारे में क्या पूछ रहा था, मैं गलत हो सकता हूं।
BlackICE

डेविड - शायद आप सही कह रहे हैं कि विस्तार का यह स्तर नहीं होना चाहिए, लेकिन मुझे लगता है कि सुरक्षा के लिए कम से कम एक पंक्ति वस्तु होनी चाहिए। बेहतर?
रोरी अलसॉप

1

1. इसे टीम में ले जाएं

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

2. निरीक्षण और अनुकूलन

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.