विकास में अराजकता के खिलाफ जीरा: कार्यों को कैसे नहीं खोना है

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

दिए गए:

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

समस्याएं:

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

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

क्या वह परिचित है? आइए इस बारे में सोचें कि हम इसके बारे में क्या कर सकते हैं।

परियोजना की संरचना

मैं विकास के उदाहरण में समस्या का विश्लेषण करूँगा। तो प्रोजेक्ट कैसे काम करता है? परियोजना किन चरणों से गुजरती है? एक विशिष्ट नई सुविधा में कई टीमों की भागीदारी की आवश्यकता होती है?

आइडिया और डिजाइन

उत्पाद प्रबंधक (पीएम), जो उत्पाद में सुधार किया जा सकता है, के साथ आ रहा है, जीरा में टाइप प्रोजेक्ट के साथ एक पीआरडी टिकट बनाता है। इस टिकट के विवरण में कंफ्लुएंस (एटलसियन विकी का एक एनालॉग जो जीरा के साथ एकीकृत होता है) में एक पृष्ठ के लिए एक लिंक होता है। इस पृष्ठ को हम PRD (उत्पाद आवश्यकताएँ दस्तावेज़) कहते हैं। यह विकास का एक प्रमुख तत्व है। वास्तव में, यह एक विस्तृत विवरण है कि परियोजना के ढांचे में क्या किया जाना बाकी है।


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

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

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

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



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

यह प्रवाह अनुकूलन Jira ScriptRunner प्लगइन पर आधारित है, जिसे मैंने पिछले लेख में लिखा था।

सड़न

PRD के साथ एक नया MAPI टिकट प्राप्त करने के बाद, सिस्टम आर्किटेक्ट तय करते हैं:

• तर्क का कौन सा भाग सर्वर की तरफ से लागू किया जाना चाहिए, और क्लाइंट पक्ष पर कौन सा भाग;
  
• क्लाइंट को क्या कमांड भेजनी चाहिए और सर्वर से इसे क्या प्रतिक्रियाएं मिलनी चाहिए;
  
• कौन सा टोकन ग्राहक को "वायर्ड" होना चाहिए, और जो सर्वर की तरफ से आना चाहिए।
  

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

आप इस बारे में अधिक जान सकते हैं कि आर्किटेक्ट की हमारी टीम कैसे काम करती है और रिपोर्ट से हमारा एपीआई विवरण देखें।

सिस्टम आर्किटेक्ट्स के काम के परिणाम हैं:

1. परियोजना के लिए पूर्ण तकनीकी दस्तावेज की उपस्थिति (पीआरडी में वर्णित व्यावसायिक तर्क मामलों के संदर्भ में क्लाइंट-सर्वर इंटरैक्शन प्रोटोकॉल का विवरण)।
   
   
   वर्तमान में निष्क्रिय सुविधाओं में से एक के प्रलेखन के भाग का स्क्रीनशॉट

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

इस प्रकार, परियोजना की संरचना को निम्नलिखित चित्र के रूप में दर्शाया जा सकता है:

विकास और प्रक्षेपण

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

आमतौर पर, एक विशेषता निम्न परिदृश्य में लॉन्च की जाती है:

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

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

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

इन समस्याओं को कैसे समतल किया जाए? यह कैसे सुनिश्चित करें कि परियोजना के टुकड़े खो नहीं गए हैं, और टीम प्राथमिकता वाली परियोजनाओं पर ध्यान देती हैं?

जीरा स्टैंडर्ड फीचर्स

मानक जीरा कार्यक्षमता इन समस्याओं को हल करने के लिए परियोजना प्रबंधक को क्या दे सकती है? इतना नहीं:

• फिल्टर;
  
• कंबन बोर्ड।
  

फिल्टर

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

कानबन बोर्ड

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

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

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


एक उत्पाद कन्नन बोर्ड की योजना, जिस पर पीएम परियोजनाओं के टिकट टीमों द्वारा समूहीकृत किए जाते हैं

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

एक्सेल

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



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

"और चलो पार!"

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

उपकरण आवश्यकताएँ निम्नानुसार थीं:

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

पीएम ने टूल के साथ काम करना शुरू कर दिया, अपना स्थान (यूनिट) बनाकर, अपने नाम और JQL क्वेरी को इंगित करता है:



अगला, निर्दिष्ट JQL क्वेरी के लिए परियोजनाओं की एक सूची प्राप्त करने के लिए जीरा से अनुरोध किया जाता है। जीरा में लिंक का उपयोग करके भी इंजीनियरिंग टीमों के सभी व्युत्पन्न टिकट हैं। परिणाम कुछ इस तरह है:



ऊपर इकाइयों के बीच स्विच करने के लिए लिंक हैं।

तालिका पंक्तियाँ इकाई की मूल PROD टिकट हैं। कोशिकाओं में हम विशिष्ट इंजीनियरिंग विभागों के लिए परियोजना के कार्यों को देखते हैं। प्रोजेक्ट टिकटों को एक-दूसरे से जोड़ने के नियमों के अधीन भरने से स्वत: ही लग जाते हैं। पूर्ण चरण हरे रंग में चिह्नित होते हैं, लाल रंग में बिना रंग के, और पीले रंग के होते हैं।

लिंक जीरा के टिकट के लिए नेतृत्व करते हैं। आप लिंक पर मँडरा कर टिकट के बारे में संक्षिप्त जानकारी भी प्राप्त कर सकते हैं:



हर कुछ मिनटों में एक बार की आवृत्ति के साथ, सभी इकाइयों के लिए परियोजनाओं की एक-अप-टू-डेट सूची प्राप्त करने के लिए, टिकटों के डेरिवेटिव्स की सूची को सिंक्रनाइज़ करने के लिए, साथ ही साथ उनकी वर्तमान स्थितियों के लिए जीरा एपीआई से अनुरोध किया जाता है।

सूची में वांछित स्थान पर वांछित परियोजना को केवल खींचने और छोड़ने के द्वारा छंटनी की जाती है:



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

निष्कर्ष

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

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

ध्यान देने के लिए आप सभी का धन्यवाद!