🥇एक आईटी परियोजना पर एक टीम में कार्यप्रवाह का संगठन

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

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

और यह सब अंततः टूटी हुई समय सीमा, ओवरटाइम, किसे दोष देना है, और ग्राहक असंतोष - जहां और कैसे सब कुछ चल रहा है, के बारे में निरंतर तसलीम में परिणत होता है। काफी बार, यह सब प्रोग्रामर और यहां तक कि पूरी टीमों के परिवर्तन की ओर जाता है। एक ग्राहक की हानि, प्रतिष्ठा में गिरावट इत्यादि।

एक समय, मैं सिर्फ एक ऐसे प्रोजेक्ट पर गया था, जहाँ ये सभी प्रसन्नताएँ थीं।

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

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

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

हमारी ओर से इस दृष्टिकोण के लिए धन्यवाद, ग्राहक ने हमारी कंपनी से एक और मार्केटप्लेस ऑर्डर करने का फैसला किया, जो अच्छी खबर है।

चूंकि यह मेरे प्रोजेक्ट पर काम करता है, शायद यह किसी की मदद भी करेगा। तो, प्रक्रिया ही, जिसने हमें परियोजना को बचाने में मदद की:

"मेरी पसंदीदा परियोजना" परियोजना पर टीम वर्क की प्रक्रिया

ए) एक टीम प्रक्रिया के भीतर (डेवलपर्स के बीच)

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

बी) ग्राहक के साथ काम करने की प्रक्रिया

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

ग) हम टीम में क्या स्वीकार नहीं करते हैं:

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

और बहुत सारे प्रश्न / थीसिस जो मैं कभी-कभी अपने ग्राहक से सभी गलतफहमियों को दूर करने के लिए कहता हूं:

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

एक नियम के रूप में, ग्राहक तुरंत समझता है कि सॉफ्टवेयर विकास में सब कुछ इतना सरल नहीं है, और अकेले इच्छा स्पष्ट रूप से पर्याप्त नहीं है।

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

पीएस मैं स्पष्ट करना चाहता हूं कि हमारी तरफ से कोई प्रोजेक्ट मैनेजर नहीं है। यह क्लाइंट की तरफ है। तकनीकी विशेषज्ञ तो बिल्कुल नहीं। यूरोपीय परियोजना। सभी संचार केवल अंग्रेजी में हैं।

अपनी परियोजनाओं पर सभी को शुभकामनाएँ। निराश न हों और अपनी प्रक्रियाओं को बेहतर बनाने का प्रयास करें।

मेरे में स्रोत ब्लॉग.

स्रोत: www.habr.com