कस्टम वेब विकास: कैसे बढ़ती परियोजना पर पैमाना

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

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

प्रोजेक्ट ग्रोथ और संबंधित चुनौतियां

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

इस तरह की परियोजना पर एजेंसी को मुख्य चुनौतियों का सामना करना पड़ सकता है:

• स्केलिंग की समस्या वॉल्यूम के विकास के साथ टीम संरचना का पुनर्गठन है।
• उत्पाद और व्यावसायिक कार्यों को समझने की आवश्यकता है - मजबूत उत्पाद विश्लेषण के बिना एक बड़ी परियोजना पर प्रभावी ढंग से काम करना असंभव है।
• जटिल सॉफ्टवेयर और सर्वर वास्तुकला - परियोजना के तहत उत्पादन की मात्रा में वृद्धि के साथ हाथ में, उपस्थिति में भी वृद्धि हुई है, जिससे एक अधिक जटिल वास्तुकला और उच्च भार समाधान का उपयोग करने की आवश्यकता होती है।
• उच्च गुणवत्ता की आवश्यकताओं।
• निर्बाध रूप से 24 × 7 संचालन और घटनाओं की प्रतिक्रिया की एक उच्च गति सुनिश्चित करने की आवश्यकता, जिसमें घंटे भी शामिल हैं।
• बिक्री को रोकने के लिए जिम्मेदारी का उच्च स्तर।
• व्यापार संकेतकों की निगरानी और नियंत्रण।

बाजार की सभी एजेंसियों के पास इन सभी चुनौतियों से निपटने के लिए आवश्यक क्षमताएँ नहीं हैं। आज हम टीम को स्केल करने की समस्या के बारे में बात करेंगे - सबसे मुश्किल, मेरी राय में, एक बढ़ती परियोजना के साथ काम करने का पहलू।



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

एक छोटे से प्रोजेक्ट पर भूमिकाएं और आपको स्केल करने की आवश्यकता क्यों है

सामान्य मामले में भूमिका योजना इस प्रकार है:



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

यह एक विशिष्ट भूमिका आरेख एक छोटी सी परियोजना पर एक परियोजना टीम के अंदर जैसा दिखता है:



प्रोजेक्ट मैनेजर की दो मुख्य भूमिकाएँ होती हैं: प्रोजेक्ट मैनेजर (आरपी) और टीम लीडर।

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

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

शेष संसाधनों को आवश्यकतानुसार परियोजना से जोड़ा जा सकता है और वे विनिमेय हैं।

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

कर्मचारियों के कर्तव्यों को अलग करने और दोहराव की आवश्यकता है, और मानक भूमिका योजना का विस्तार और अधिक जटिल हो जाता है।

प्रबंधन टीम संरचना

स्केल करने के लिए सबसे कठिन इकाइयों में से एक आरपी है।
जैसे ही परियोजना बढ़ती है, यह क्लासिक जोड़ी खाता प्रबंधक - परियोजना प्रबंधक योजना को लागू करने के लिए समझ में आता है, जब एक आरपी उत्पाद मुद्दों सहित ग्राहक सेवा का ख्याल रखता है, और दूसरा कंपनी के अंदर उत्पादन प्रक्रिया का आयोजन करता है।



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

इसलिए, आगे स्केलेबिलिटी के दृष्टिकोण से आदर्श योजना इस प्रकार है:



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

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

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

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

यह योजना आसानी से स्केलेबल है और इसमें अपेक्षाकृत कम प्रवेश सीमा है, क्योंकि एक नए आरपी को जोड़ने पर, इसे परियोजना के संपूर्ण ज्ञान आधार को एक साथ कवर करने की आवश्यकता नहीं होती है, यह "आपके" उत्पादों के संचालन के सिद्धांत को समझने के लिए पर्याप्त है।

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

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

एक ही समय में, पूरी प्रबंधन टीम में सामूहिक प्रेरणा शामिल थी, जो ग्राहक अपेक्षाओं को प्रबंधित करने के लिए बंधी हुई थी, पहली बार में - परियोजना समय पर पहुंच जाना।

• महीने की शुरुआत से 10 दिन पहले, प्रत्येक आरपी अगले महीने के लिए अपने मुख्य कार्यों में से तीन से पाँच आवंटित करता है।
• महीने की शुरुआत से 5 दिन पहले, जीएच प्रत्येक प्रबंधक के लिए उनमें से दो या चार का चयन करता है और समय सीमा निर्धारित करता है: 1 - ग्राहक शब्द (50%), 2 - आंतरिक शब्द (100%) और इसे तालिका में दर्ज करें।

बोनस की स्थिति (महीने के परिणामों के अनुसार):

• यदि उसके सभी कार्य आंतरिक समय सीमा के भीतर पूरे हो जाते हैं, तो प्रबंधक को 100% बोनस प्राप्त होता है।
• प्रबंधक को 50% बोनस प्राप्त होता है यदि उसके कम से कम कार्यों में से एक आंतरिक पद छोड़ देता है, लेकिन ग्राहक के कार्यकाल में पूरा हो गया था।
• यदि क्लाइंट के समय में सामान्य सूची से कम से कम एक कार्य पूरा नहीं हुआ, तो प्रबंधकों में से किसी को भी बोनस नहीं मिलता है।

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

केवल अंतिम कोड परीक्षण नहीं - क्यूए कमांड

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

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

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

ऐसा दृष्टिकोण लंबे समय तक डिबगिंग के जोखिम को कम कर सकता है और रिलीज की तारीखों में देरी कर सकता है।

टाइमलिड्स - दक्षता या विनिमेयता?

जैसे ही दूसरी टीम लीड परियोजना के लिए पेश की जाती है, सवाल तुरंत पॉप हो जाता है - जिम्मेदारियों की वितरण योजना क्या लागू की जानी चाहिए?

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

संसाधन उपयोग के संदर्भ में दोनों विकल्प अच्छे हैं, लेकिन विनिमेयता के मामले में महान जोखिम उठाते हैं।

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

इसलिए, परियोजना पर एक हाइब्रिड योजना का उपयोग करना सार्थक है, जिसमें प्रत्येक टीम के नेता अपने स्वयं के कार्यों में लगे हुए हैं, लेकिन कई गतिविधियां हैं जिनमें सभी या कम से कम दो टीम टीम के नेता समर्पित हैं।

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



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

अलग-अलग, यह टीम के नेताओं को अलग-थलग गतिविधियों से जोड़ने के लिए समझ में आता है: एक उत्पाद जो परियोजना के मुख्य भाग से वास्तुशिल्प रूप से तलाकशुदा है, या एक गतिविधि जो समानांतर में लगी हो सकती है। उदाहरण के लिए, टीम लीड लेआउट को सिंगल आउट करना पूरी तरह से संभव है जो पूरी तरह से सभी फ्रंट-लाइन ऑपरेशंस पर नियंत्रण रखेगा; अलग-अलग प्रतिष्ठित टीम लीड QA, डिज़ाइन, एनालिटिक्स की भूमिकाएँ हैं।

टीम के सदस्य विनिमेयता

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

यहां कई उपकरण हैं जो लगभग सभी परियोजनाओं पर अच्छा प्रदर्शन करते हैं।

डिजाइन प्रणाली

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

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

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

प्रलेखन

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

परियोजना प्रलेखन 4 प्रकारों में विभाजित करने के लिए समझ में आता है:

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

सभी दस्तावेज़ों को एक ऑनलाइन ज्ञानकोष (विकी) में एकत्र किया जाना चाहिए और अद्यतित रखा जाना चाहिए।

GIT

कंपनी की अन्य परियोजनाओं से नए डेवलपर्स के कनेक्शन में तेजी लाने के लिए, GitFlow के लिए एक मानक दृष्टिकोण पेश किया जा रहा है। AGIMA में हम "दो मुख्य शाखाओं के साथ काम करते हैं" दृष्टिकोण का उपयोग करते हैं।

मास्टर शाखा का उपयोग करने के बजाय, प्रोजेक्ट इतिहास की दो मुख्य शाखाओं का उपयोग किया जाता है: फीचर शाखाओं से विकसित कार्यक्षमता को मर्ज करने के लिए रिलीज़ और विकसित करने के लिए मास्टर।

कार्यप्रवाह

एक और उपकरण जो सभी टीम के सदस्यों के काम को नियंत्रित और मानकीकृत करता है, सप्ताह के दिन तक वर्कफ़्लो होता है।

प्रत्येक सप्ताह एक मानक उत्पादन चक्र है: रिलीज़ मंगलवार और गुरुवार को सख्ती से किए जाते हैं; बुधवार - मूल्यांकन का दिन; नए शिपमेंट की पूर्वव्यापी और योजना सप्ताह के अंत में होती है - गुरुवार और शुक्रवार को। यह परियोजनाओं में से एक से एक वर्कफ़्लो का एक उदाहरण है, प्रत्येक विशिष्ट मामले के लिए, एक दृष्टिकोण विकसित किया जाना चाहिए।

क्लाइंट को वर्कफ़्लो में भी शामिल होना चाहिए - ऐसी प्रणाली एकतरफा काम नहीं कर सकती है।

कोई कम महत्वपूर्ण कार्य स्थितियों पर वर्कफ़्लो नहीं है, जो परियोजनाओं के बीच कर्मचारियों के संक्रमण को सरल करता है। यह कंपनी की सभी परियोजनाओं पर समान होना चाहिए। AGIMA में, यह इस तरह दिखता है:

टीम के सदस्यों को जानकारी देते रहे

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

1. उत्पाद बैठकों

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

2. अवसंरचना अनुभाग

परियोजना गतिशील रूप से बढ़ रही है, यह बुनियादी ढांचे के निरंतर विकास और विस्तार को मजबूर करता है। नियमित वर्गों में, बुनियादी ढांचे के विकास के लिए वर्तमान समस्याओं और कार्यों पर चर्चा की जाती है, और उनमें से प्रत्येक के कार्यान्वयन पर प्रगति पर चर्चा की जाती है।

3. पूर्वव्यापी और कार्य योजना

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

निष्कर्ष

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

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