प्रबंधन को हमारी विकास प्रक्रिया से बाहर कैसे रखा जाए


14

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

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

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


1
विकास प्रक्रिया को प्रबंधन कितनी अच्छी तरह समझता है?
जेबी किंग

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

जहाज से कूद। @ एलेक्स, हर प्रबंधन टीम को शामिल होने की परवाह नहीं है। यदि वे शामिल होना चाहते थे, तो उन्हें शामिल किया जाएगा; वे प्रबंधन कर रहे हैं। इंजीनियरिंग के नेतृत्व वाली कंपनियां अल्पसंख्यक हैं।
मार्क कैनलास

1
@ मर्क, यह आमतौर पर प्रबंधन टीम बनाने वाले लोगों को संलग्न करने की आपकी शक्ति के भीतर है। ऊपर की ओर प्रबंधन एक उपयोगी अस्तित्व / खुशी कौशल है।
एलेक्स फेइमैन

जवाबों:


5

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

मुझे स्वयं समान परिदृश्यों से निपटना पड़ा है और मैंने इसी तरह के विषय पर इस प्रश्न का उत्तर दिया है । मैंने इस बारे में भी ब्लॉग किया कि मैं यहाँ कैसे निपटा:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

यदि आपको लिंक का पीछा करने का मन नहीं है, तो मैं संबंधित प्रश्न से अपना सारांश दोहराऊंगा:

संक्षेप में, मैंने परियोजना के लिए वास्तविक घंटों के खिलाफ हमारे अनुमानित घंटों की तुलना की और फिर अन्य टीमों के दोष दर के खिलाफ हमारी दोष दर की तुलना की। हमारे मामले में इन नंबरों की तुलना अनुकूल रूप से हुई और अधिक चिंताएं नहीं थीं।

इस अनुभव के आधार पर मेरा निष्कर्ष है:

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

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


20

आपके द्वारा उपयोग की जाने वाली विधि की परवाह किए बिना नंबर एक नियम का पालन करना है

  1. डेवलपर्स को अपने काम का अनुमान लगाने का अधिकार होना चाहिए।
  2. हितधारकों को उस काम के बीच प्राथमिकता देने का अधिकार होना चाहिए।

अनुमान और प्राथमिकता दो ताकतें हैं जो दोनों पक्षों द्वारा अपनी जिम्मेदारियों को स्वीकार करने पर एक साथ बहुत अच्छी तरह से काम करती हैं। इसलिए बहस करने में समय बर्बाद करने के बजाय, इस बात पर सहमत हों और यह सम्मान करें कि दोनों पक्ष अपनी क्षमताओं के अनुसार अपना काम करेंगे।


क्या होगा अगर वे परीक्षण को कोई प्राथमिकता नहीं देते हैं?
जेफ़ो

16
परीक्षण नहीं है; क्या वे पर प्राथमिकता देने का मौका है। यह मानक विकास प्रक्रिया का हिस्सा है। उन्हें सुविधाओं को प्राथमिकता देनी चाहिए न कि प्रक्रियाओं को।
HLGEM

12

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


3
वह डरपोक है।
जेएफओ

8
और सच होने का फायदा है।
HLGEM

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

2
उन्हें नया अनुमान देकर जहां आपने अनुमान के डिबगिंग भाग में अधिक घंटे जोड़े।
HLGEM

मेरे लिए गलत रवैया। यह एक अच्छा समग्र-टीम परिणाम (incl। प्रबंधन) के साथ नहीं आएगा।
मार्क

6

उन्हें तकनीकी ऋण और इकाई परीक्षण के मूल्य के बारे में बताएं

पर देखो इस पोस्ट कुछ अच्छा विचार से तकनीकी ऋण पर है। उस पोस्ट के माध्यम से निम्नलिखित पीडीएफ़ को प्राप्त कर सकते हैं

मैं यूनिट परीक्षण के मूल्य पर इस पोस्ट को पसंद करता हूं (खोजने के लिए संभवतः अधिक हैं)

आशा यह नहीं है कि उन्हें आपकी विकास प्रक्रिया से बाहर निकाला जाए बल्कि उन्हें सही तरीके से शामिल और प्रतिबद्ध किया जाए।

IMHO आपको अपनी मूल योजना नीचे लिखनी होगी, अध्याय 1 और 2 (एक परिशिष्ट में नहीं) जोड़ना होगा जिसमें आप तकनीकी ऋण और इकाई परीक्षण के मूल्य की व्याख्या करते हैं। उन्हें विकल्प दें:

  • कम घंटे (पूरे 150 नहीं, जो हास्यास्पद लगता है) जहां औसतन हर परिवर्तन (विकास के चरण के दौरान और रखरखाव के दौरान) औसतन लगेगा:
    • छोटे 4 घंटे
    • मध्यम 16 ​​घंटे
    • बड़े 40 घंटे
  • आपके अनुमानित घंटे जहां हर परिवर्तन (विकास चरण और रखरखाव के दौरान) औसतन लगेगा:
    • छोटे 2 घंटे
    • मध्यम 8 घंटे
    • बड़े 20 घंटे

(घंटे सिर्फ सांकेतिक हैं। आप उचित अनुमान देने के लिए बेहतर तरीके से सुसज्जित हैं।)

समय पर बजट प्रसव के लिए अपना ट्रैक रिकॉर्ड शामिल करना न भूलें।

इसे लिखें और उनके साथ इस पर चर्चा करें। वे सुविधाओं में कुछ मूल्यवान बिंदु हो सकता है वास्तव में अभी जरूरत नहीं है या कुछ तकनीकी ऋण वे समय पर वितरित करने के लिए लेने के लिए तैयार हैं। बस सुनिश्चित करें कि ये सचेत विकल्प हैं।

उम्मीद है इससे मदद मिलेगी और सौभाग्यशाली हो।


3

सबसे पहले, अनुमानित, अनुसूचित और संभावित रूप से कटौती के लिए एक अलग कार्य के रूप में "राइट यूनिट टेस्ट" को विभाजित न करें। आपका अनुमान सुविधा स्तर "XYZ - 18 घंटे लागू करें" पर होना चाहिए। उन 18 घंटों में उस सुविधा को "पूर्ण" करने के लिए आपकी प्रक्रिया में जो कुछ भी शामिल होना चाहिए, उसमें "राइट यूनिट टेस्ट" शामिल होना चाहिए।

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

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


2

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

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

और मेरी प्रोग्रामिंग जॉब में भी ऐसा ही है: सफाई करने से, मुझे एक राज्य में कोडबेस मिलता है, जहां मैं अगली बार जब जरूरत होती है, तो बहुत जल्दी कुछ दे सकता हूं। यदि नहीं, तो अगली बार इसमें बहुत अधिक समय लगेगा।


1

आप उन्हें अपनी प्रक्रिया से पूरी तरह से बाहर नहीं रख सकते, आखिरकार वे आपकी मजदूरी का भुगतान करते हैं और वे आपके उत्पाद का उपयोग करेंगे (यदि सीधे नहीं, तो संभवतः आपकी कंपनी में कोई अंतिम उपयोगकर्ता है)।

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

यह मानते हुए कि समय सीमा के लिए कोई "ड्रॉप डेड" कारण नहीं है तो मैं 2 चीजों का सुझाव दूंगा।

  1. उच्च गुणवत्ता वाले काम के अपने वर्तमान दृष्टिकोण से चिपके हुए, जो आप सोचते हैं कि आप 150 घंटों में क्या कर सकते हैं, की एक विस्तृत योजना वितरित करें। इस समय सीमा में वास्तव में क्या दिया जा सकता है, गणना करें। KeesDijk से जवाब एक ठीक कणों का स्तर पर योजना बनाने पर कुछ बहुत अच्छे संबंध हैं।
  2. सभी सुविधाओं को कवर करने के लिए विस्तृत योजना की एक ही शैली पर ले जाएं और दिखाएं कि यह 300 घंटे कैसे लेगा (या आंकड़ा जो भी बाहर आता है)।

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


1

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

निचला रेखा: अपने अनुमान के साथ अपनी बंदूकों से चिपके रहें। आपका ट्रैक रिकॉर्ड आपको दिखाता है कि आप किस बारे में बात कर रहे हैं, और आपके अनुमान (मान्यताओं, अपेक्षाओं, पिछले प्रदर्शन, आदि) के आधार पर एक उचित उत्तर दे सकते हैं। ऐसा लगता है जैसे आपके ऊपरी प्रबंधन के पास दृश्यता नहीं है, उन्हें एक उचित अनुमान बनाने की आवश्यकता है। क्या वे बैठकों के लिए बिना किसी रुकावट के 8 घंटे का दिन मान रहे हैं? क्या वे अपने अनुमानों में सिस्टम परीक्षण के लिए बजट दे रहे हैं? आपके ट्रैक रिकॉर्ड को देखते हुए वे उस नंबर के साथ कैसे आए जो आपका आधा हिस्सा है?


-1

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


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

4
निम्न गुणवत्ता प्रदान करना एक बुरा विचार है, इस टीम को एक अच्छी प्रतिष्ठा है, जो हमेशा के लिए खो सकती है, या लंबे समय तक, अगर वे खराब गुणवत्ता वाले काम करते हैं।
स्टीव

1
मत करो। आप सुविधाओं को छोड़ने या कुछ सुविधाओं को कम-प्राथमिकता (एक ही चीज़) करने की पेशकश कर सकते हैं। लेकिन उद्देश्य पर छोटी गाड़ी सॉफ्टवेयर बनाना केवल अव्यवसायिक है।
नीकी

मैं उद्देश्य से छोटी गाड़ी का सॉफ्टवेयर बनाने का सुझाव नहीं दे रहा हूं। मैं उनके सामने यह बताने का सुझाव दे रहा हूं कि बोली में कटौती करना, लेकिन आवश्यकताओं के परिणामस्वरूप बगगी सॉफ्टवेयर नहीं होगा। यह उनकी पसंद है।
क्रेग

-1

वैली क्या करेगा?

प्रबंधन आपसे क्या पूछता है, इसकी व्याख्या करने के कई तरीके हैं, एक यह है कि वे आपको समय पर वितरित नहीं करना चाहते हैं।

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


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

-1

तुम अचार में हो। यदि आप अपनी बंदूकों से चिपके रहते हैं और यूनिट परीक्षणों के साथ रहना चाहते हैं, और 300 घंटे का दावा करना चाहते हैं, तो आप दुश्मन बना देंगे।

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

किसी भी तरह से, आप खो देते हैं।

या ऐसा लगता है।

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

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

आपका प्रबंधन, यह विश्वास करता है या नहीं, आरओआई अनुमान बनाने में माहिर है (यही वह व्यवसायिक स्कूल में पढ़ाता है) और कई आरओआई अनुमान चला सकता है और "अगर हम कार्य करते हैं तो हम बहुत अधिक पैसा कमाएंगे" सॉफ्टवेयर पर रखरखाव के लिए ट्रिपल भुगतान के साथ आईटी में bozos के बारे में शिकायत करते हैं। "

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

दूसरे शब्दों में: आपको जो बताया गया है उसे करें। यदि प्रबंधन जानता है कि वह क्या कर रहा है, तो आप आगे आएंगे। यदि नहीं, तो आप नौकरी से बाहर हैं, इकाई परीक्षण या नहीं।

आप क्या पूछें ROI निवेश पर प्रतिफल। हालांकि यह एक बुरा नाम है। इसके लिए रिटर्न ऑन टाइमली इन्वेस्टमेंट (ROTI) होना जरूरी है, क्योंकि निवेश में टाइमिंग ही सबकुछ है।


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