कार्यान्वयन अनुभव वास्तविक हो रहा है। 2 का भाग 2

हमारी कंपनी के उदाहरण से 37signals से वास्तविक दृष्टिकोण को लागू करने के अनुभव के बारे में लेख का दूसरा, अंतिम भाग। कल प्रकाशित करना शुरू करें।

प्रतिबंध मदद करते हैं

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

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

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

विधि बहुत ही सरल और अवैज्ञानिक है। हमने तीन मानदंड तैयार किए हैं जिनके द्वारा हम प्रत्येक कार्य का मूल्यांकन करेंगे, और प्रत्येक कार्य को शून्य से तीन तक अंक दिए गए थे। ये मानदंड हैं:

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

यहाँ इस तालिका का एक टुकड़ा है:

कार्यात्मक	पैसा	जानकारी रेखा	गति	कुल मिलाकर
नया खोज मॉड्यूल	2	1	0	3
मॉड्यूल "मिनिमागाज़िन"	3	2	1	6
मॉड्यूल "मेरा खाता"	2	2	1	5
विजेट एम्बेड प्लेटफॉर्म	2	2	1	5
टैग क्लाउड मॉड्यूल में परिवर्तन	0	0	2	2
ऑनलाइन स्टोर मॉड्यूल का परिवर्तन	3	3	0	6

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

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

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

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

और अब हम इंटरफ़ेस डिज़ाइन में बहुत बेहतर हैं और अगला ऐसा कार्य आसान होगा।

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

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

विनिर्देशों को न बनाएं

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

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

विनिर्देशों पर जीआर अध्याय को पढ़ने के बाद, मैंने इस विषय पर हाल ही में लिखित तकनीकी असाइनमेंट की पूर्वव्यापी परीक्षा आयोजित करने का निर्णय लिया। यह पता चला कि 37signals बिल्कुल सही थे: लगभग हर समय जब मैंने TK, कार्यात्मक तत्वों की सूची, फ़्लोचार्ट, और डेटा सर्किट को संकलित करने पर खर्च किया क्योंकि कोई भी वास्तव में उनका उपयोग नहीं करता था। अंतिम उदाहरण खोज मॉड्यूल के लिए तकनीकी कार्य है, जहां मैंने ऑपरेशन योजना, डेटा संरचना, अन्य मॉड्यूल के साथ इंटरैक्शन इंटरफेस का विस्तार से वर्णन किया है। मैंने बड़ी सावधानी से ऐसा किया मॉड्यूल एक दूरस्थ डेवलपर द्वारा लिखा गया था। नतीजतन, केवल उन हिस्सों जहां मॉड्यूल नियंत्रण इंटरफ़ेस का वर्णन किया गया था, उनके लिए उपयोगी थे, अर्थात्, सेटिंग्स और आउटपुट स्क्रीन। उन्होंने बाकी अध्यायों के माध्यम से देखा, लेकिन क्या यह अपना रास्ता था; उन्होंने डेटाबेस संरचना पर अध्याय भी नहीं पढ़ा। अर्थात्, दस्तावेज़ का 80 प्रतिशत सामान्य शब्दों में लिखकर कम किया जा सकता था, जो मॉड्यूल को करना था, साथ ही साथ स्क्रीन के प्रोटोटाइप को भी चित्रित करना था।

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

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

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

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

जो हम सफल नहीं हुए

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

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

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

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

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

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

निष्कर्ष

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

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

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

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