क्या करें जब समय का अनुमान गलत हो जाए?


26

मान लीजिए कि आपने किसी मामले के लिए 3 दिन का समय दिया है। दिन दो में आप नोटिस करते हैं कि मामला बढ़ रहा है और नए परिदृश्य पॉप अप कर रहे हैं जिनकी गणना समय आकलन के दौरान नहीं की गई थी। नई खोज 2 दिन अतिरिक्त (कुल 5 दिन) की ओर ले जाती है। यह एक विशिष्ट समस्या है जिसे आप डेवलपर के रूप में जल्द या बाद में सामना करेंगे।

  • जब आप प्रोजेक्ट लीडर को डिलीवरी के नए समय के बारे में सूचित करने जा रहे हैं तो कौन सी रणनीति का उपयोग किया जा सकता है?
  • अक्सर आपको सवाल मिलता है कि क्यों? आप प्रसव के नए समय को कैसे प्रेरित करते हैं?

तथ्य यह है कि कई प्रोजेक्ट एसडीएलसी के दौरान विश्लेषण और डिजाइन पर ज्यादा समय नहीं लगाते हैं।

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


1
मुझे लगता है कि बेहतर सवाल यह है कि अनुमान सही होने पर आप क्या करते हैं ? ज्यादातर समय, यह नहीं होगा।
टिम पोस्ट

@ समय पोस्ट आप के बारे में सही हैं "अधिकांश समय, यह नहीं होगा" मैं जलाशय बनना चाहता था।
अमीर रज़ाई

1
+1 - EDIT के लिए धन्यवाद जिसमें ज्ञान के शब्द हैं। आपने जिस तथ्य पर प्रकाश डाला है ("" बहुत ही जटिल परियोजनाओं में, चाहे आप विश्लेषण और डिजाइन पर कितना ही उचित समय क्यों न डालें, व्यापार के नियम बहुत जटिल होने से हमेशा आश्चर्य होता है।) "" बहुत सही है।
कार्तिक श्रीनिवासन

जवाबों:


17

ख़राब न्यूज़ दे रहा है

आपको तुरंत मामले को उठाने की आवश्यकता है, हालांकि यदि आप एक उचित समय में ऐसा कर सकते हैं (जो कुछ घंटे हैं, अधिक नहीं) तो आपको इससे पहले कि आप कुछ प्रभाव आकलन कर लें।

सभी बुरी खबरों के साथ यह विस्तृत जानकारी प्रदान करने के लिए सबसे अच्छा है (सिर्फ "यह देर हो रही है")

1) उन कार्यों के लिए संशोधित अनुमान / समय-सीमा जो फिसल गए हैं।

2) भविष्य के कार्यों के लिए संशोधित अनुमान / समय-सीमा जो अब आप सोचते हैं, यह जानने के प्रकाश में कि कुछ चीजें पहले ही खत्म हो चुकी हैं, और अधिक समय लग सकता है।

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

4) यदि संभव हो तो विकल्प को पटरी पर लाना (आमतौर पर गुंजाइश कम करना लेकिन अन्य विकल्प भी हो सकते हैं - परियोजना के अन्य हिस्से समय से पहले हो सकते हैं और कार्यों को स्थानांतरित करना संभव हो सकता है)।

याद रखें कि फिसलन के साथ मनोवैज्ञानिक / विश्वसनीयता प्रभाव परिणित होता है। आप एक के साथ दूर होने में सक्षम हो सकते हैं, लेकिन दूसरा बहुत कठिन होगा और तीसरा अभी भी मुश्किल पर।

यही कारण है कि बिंदु 2 महत्वपूर्ण है - न केवल जो पहले से ही फिसल गया है बल्कि भविष्य के कार्यों को भी संशोधित करें जो आपको लगता है कि मूल रूप से प्रत्याशित से अधिक समय लग सकता है। ITs में फिसलना, अपनी गलतियों से न सीखना एक बड़ा पाप है।

बुरी खबर देने से रोकना

यहां दो परिदृश्य हैं: पहला, आपने खुद अनुमान नहीं लगाया है कि किस स्थिति में आप अनुमान लगाने के लिए धक्का देने के अलावा अन्य काम नहीं कर सकते हैं।

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

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

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

यदि पीएम यह सवाल करता है, तो आपको उसे हर समय याद रखने की ज़रूरत है कि यह सच है (उदाहरण के लिए - उदाहरणों पर बहस करना कठिन है) और धीरे से यह भी सुझाव दें कि यह उसके हित में समय के साथ-साथ आपका भी उद्धार करना है। रूढ़िवादी होना बेहतर है?

लेकिन नीचे की रेखा: यदि आप किसी विशिष्ट कारक (इस मामले में रेंगना) के कारण हमेशा कम आंकते हैं, तो उसे अपने अनुमान में समझें।


2
+1 "सभी बुरी खबरों के साथ-साथ विस्तृत जानकारी प्रदान करना सबसे अच्छा है" हालांकि हर कोई समस्या के विवरण / जटिलता को नहीं समझता है।
अमीर रज़ाई

@Amir - मैंने थोड़ा और जोड़ा है, हालांकि जो व्यक्ति जटिलता को सरल सत्य समझता है, वह यह है कि इसे समझाना आपकी जिम्मेदारी है। वे कोई अन्य तरीका नहीं सीखने जा रहे हैं।
जॉन हॉपकिंस

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

+1 "स्लिपेज के साथ याद रखें मनोवैज्ञानिक / विश्वसनीयता प्रभाव संचयी है।"
कार्तिक श्रीनिवासन

16

समय-आधारित अनुमान भविष्य के बारे में अनुमान हैं, और यह हमेशा लंबे समय में विफल हो जाएगा। यह एक बेकार लड़ाई है जिसे आप जीत नहीं सकते।

दिनों में अनुमान लगाना बंद करें और इसके बजाय सापेक्ष अनुमान का उपयोग करना शुरू करें । ये रहा एक सरल उदाहरण:

  1. प्रत्येक कार्य के लिए एक संख्या असाइन करें। सबसे कठिन कार्य 10 और सबसे आसान कार्य 1 हो सकता है।
  2. अपने कार्यों को पूरा करने के लिए प्रोग्रामिंग शुरू करें।
  3. एक सप्ताह के बाद, अपना काम बंद कर दें और सभी पूर्ण किए गए कार्यों को जोड़ दें। कहते हैं कि आप 14 के साथ समाप्त होते हैं। यह आपका साप्ताहिक वेग है।

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


क्या आप एक उदाहरण दे सकते हैं कि आप कार्यों के आकार पर नज़र कैसे रखते हैं? क्या आप कार्य प्रकारों के साथ एक तालिका बनाते हैं (जैसे "नया रूप बनाएँ", "webservice X के लिए एक विधि जोड़ें") या यह एक आंत की भावना अधिक है?
चापलूसी

बस उन कार्यों की तुलना करें जिनका आपने पहले अनुमान लगाया है और पूरा किया है।
मार्टिन विकमैन

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

क्या शानदार विचार है! मैं निश्चित रूप से इसे और आगे बढ़ाऊंगा।
मीटपैड

3

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

यदि संभव हो तो टीम के साथियों से मदद मांगें। सुनिश्चित करें कि आप अभी भी यथासंभव उच्च गुणवत्ता वाले सॉफ़्टवेयर वितरित करते हैं।

एक शॉर्ट-कट सबसे अंत में अधिक नुकसान करेगा, और इसमें शामिल सभी को यह जानना चाहिए। या कम से कम उन्हें यह समझाना संभव होना चाहिए।


3

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

आपको प्रबंधक को समझाना होगा: क्या पहली जगह में अनुमान गलत था या प्रतिकूल परिस्थितियां थीं (एक दिन बग का शिकार करते हुए) देरी का कारण? पहले मामले में, अनुमान प्रक्रिया में कुछ गड़बड़ है, शायद यह बहुत आशावादी या भोला है। दूसरे मामले में, यह बफर के लिए एक मामला है जिसे उम्मीद है कि परियोजना योजना में शामिल किया गया था।


2

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

आदर्श रूप से आपकी सुविधाओं की सूची MoSCoWed - होनी चाहिए, चाहिए, हो सकती है, नहीं।

जब आप ओवररन के लिए जा रहे हों, तो कॉल्ड्स काटें, फिर शॉड्स। सुविधाओं को काटें ताकि आप समय पर जहाज कर सकें: आपकी परियोजना आमतौर पर अलगाव में नहीं रहती है, और आप पिछले रिलीज की तारीख का मतलब है कि डाउनस्ट्रीम परियोजनाएं भी अब अपने कार्यक्रम से आगे निकल जाएंगी।

आदर्श रूप से आपके पास केवल ~ 60% मस्ट होंगे। यदि आपको उन चीजों को काटना है, तो आप बहुत गहरी परेशानी में हैं (बहुत गंभीर समस्या होने पर), जिस स्थिति में आपको कोनों को काटना होगा।

सुनिश्चित करें कि कोनों को काटकर बनाई गई गंदगी को साफ करने के लिए आप खुद को पर्याप्त समय दें!


4
+1 @Frank "आप समय पर जहाज कर सकते हैं" सुविधाओं को काटें। यहां समस्या यह है कि मैं प्रोजेक्ट लीडर नहीं हूं।
अमीर रज़ाई

@Amir किस मामले में आपका ग्राहक आपकी परियोजना का नेता है (दयालु)। आप कहते हैं, "मैं पीछे हूं। मैं या तो इस सुविधा को काट सकता हूं, या उस सुविधा को। मैं क्या करूं?"
फ्रैंक शियरर

@ फ्रेंक चूंकि हम स्क्रम करते हैं, और मामले को स्प्रिंट में बैकलॉग से स्थानांतरित किया जाता है, ऐसा लगता है कि मामलों को कम करने के लिए पीएम के लिए पत्थर में लिखा गया है। हालाँकि एक अनुभव पीएम को इस तरह की समस्या नहीं हो सकती है।
अमीर रज़ाई

मुझे MoSCoW पसंद नहीं है। इसके साथ एकमात्र चतुर है। बस अपने कार्यों को प्राथमिकता वाले बैकलॉग में रखें।
मार्टिन विकमैन

1
@Martin कंधे उचकाने की क्रिया "चाहिए" का अर्थ है "यदि आप इस सुविधा का जहाज नहीं है आप सब पर कुछ भी नहीं है"। यह एक प्राथमिकता वाले बैकलॉग के लिए अलग-अलग जानकारी है, जो "आप पहले कौन सी सुविधा पसंद करेंगे?" आपके पास अभी भी MoSCoW के साथ एक प्राथमिकता वाला बैकलॉग होगा।
फ्रैंक शियरर

2

परियोजना का अनुमान जुआ, सादा और सरल है। जोखिम के बिना कोई इनाम नहीं है।

यदि प्रबंधक को यह समझ में नहीं आता है, तो यह पहली बात है जो मैं समझाऊंगा।

सवाल यह है कि जोखिम कौन कवर करता है?

यदि आप एक निश्चित मूल्य अनुबंध पर हैं, तो आप जोखिम को कवर कर रहे हैं।

यदि समय और सामग्री, तो वह जोखिम को कवर कर रहा है।

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


1

मेरा मानना ​​है कि सबसे अच्छी रणनीति लगातार आपके अनुमान को परिष्कृत कर रही है । मुझे पता है, मैं कह रहा हूं: आपका सवाल किसी तरह गलत है।

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

फुर्तीली कार्यप्रणाली इस समस्या को हल करती है, जो परियोजना के जीवन काल को कई टुकड़ों में तोड़ती है (स्प्रिंट में), और हर हफ्ते अनुमान (कहानियों को आकार देना) को दोहराती है। हर हफ्ते, आप समस्या के बारे में जो कुछ भी जानते हैं वह परिष्कृत है, और ऐसा अनुमान है।

मेरे लिए, एक अनुमान सही या गलत नहीं हो सकता। यह सिर्फ काफी परिष्कृत किया जा सकता है । एक अनुमान एक प्रतिबद्धता नहीं है। इसलिए इसे अनुमान कहा जाता है।

सबसे अच्छा आप तब कर सकते हैं जब आप देर से होते हैं (और तब भी जब आप "अग्रिम में वितरित करने के लिए जोखिम", क्योंकि समस्या एक ही है: आपने बुरी तरह से अनुमान लगाया है) जितनी जल्दी हो सके ग्राहक को तथ्य बढ़ाना और उठाना है। इसे जोखिम प्रबंधन कहा जाता है। जितनी जल्दी आप एक प्रतिक्रिया देंगे, उतनी ही प्रभावी प्रति-गणना होगी। आमतौर पर इसका मतलब है कि, यदि आपके पास सबूत हैं कि आप सब कुछ नहीं दे सकते हैं, तो यू को अपने ग्राहक से बात करनी चाहिए, उसे बताएं कि आप प्रतिबद्धता का केवल 70% प्रदान कर सकते हैं और उसे यह तय करने दें कि उसके लिए अधिक व्यावसायिक मूल्य क्या है और उसे पहले तैनात किया जाना चाहिए

मैंने इसके बारे में यहाँ लिखा है गलत अनुमान, मदद! मुझे देर हो गई! सुविधाओं में कटौती और झरना बंद करो!


1

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

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


0

सभी टीम को इसकी जानकारी दें और इसका हल ढूंढने का प्रयास करें। मैं 3 समाधान सुझाता हूं, प्राथमिकता में उच्च से निम्न तक:

ए। एक अस्थायी हॉट-फ़िक्स, या एक त्वरित-चारों ओर खोजने की कोशिश करें

ख। जो काम आप कर सकते हैं, उसे बेहतरीन तरीके से करें। क्लाइंट को अपने काम का उत्कृष्ट हिस्सा दिखाने के बाद, उनकी मदद के लिए पूछें: हम ऐसा कर सकते हैं, लेकिन कुछ समस्या है, और यह आपके काम की उत्पादकता को धीमा कर सकता है ... शायद आप उनसे पूछ सकते हैं कि क्या कोई अनावश्यक अनुरोध है / सुविधा जिसे गिराया जा सकता है, या काट दिया जा सकता है।

उनकी समस्या के लिए एक वैकल्पिक दृष्टिकोण का प्रस्ताव शायद एक अच्छा विचार है।

सी। ओवरटाइम काम


मैंने अपना प्रश्न अपडेट किया। यह परियोजना का नेता है जिसे अधिसूचित किया जाएगा।
अमीर रज़ाई

मैं काफी नहीं समझता। आप परियोजना के नेता हैं, या केवल एक प्रोग्रामर हैं?
लॉन्ग

0

विकल्प:

  • सुविधाओं में कटौती
  • कट क्वालिटी (बाद के लिए बग फिक्स छोड़ दें)
  • उत्पादकता बढाओ
    • ब्लॉकर्स ढूंढें और निकालें
    • तोड़ / बाकी
    • व्यक्तिगत / नींद का समय काटें
    • अधिक कार्यबल प्राप्त करें
    • बेहतर उपकरण प्राप्त करें
    • प्रशिक्षण
    • प्रेरणा बढ़ाएँ
      • मुफ्त भोजन
      • [का वादा] उठाना / पदोन्नति / छुट्टी / बोनस / आदि।
      • धमकी
      • काम करने की स्थिति में सुधार (बेहतर हार्डवेयर, फर्नीचर, आदि)
      • पर्यावरण बदलें - एक कॉफी शॉप से ​​काम करें या पूरी टीम को कहीं और स्थानांतरित करें - एक पहाड़ लॉज या एक झील घर?

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

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

0

यह एक आम समस्या है :)

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

बड़ी टीमों में अधिक लोग हैं जो बीमार हो सकते हैं और कम लोग हैं जो "सब कुछ" जानते हैं।

नई प्रौद्योगिकियां हमेशा उन लोगों की तुलना में जोखिम भरी होती हैं जिन्हें आप पहले से जानते हैं।

और जब आप देखते हैं कि आप अनुमानित तिथि पर समाप्त नहीं होंगे, तो हितधारकों के साथ जल्दी संवाद करें। हो सकता है कि आप ग्राहक / हितधारक के साथ बात करने के बाद सामान को फिर से प्राथमिकता दे सकते हैं या कुछ सुविधाओं में देरी कर सकते हैं।

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