अपतटीय मामलों के परास्नातक

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

इस लेख का उद्देश्य उन विशिष्ट बिंदुओं पर ध्यान आकर्षित करना है जो अपतटीय टीमों द्वारा कार्यक्रमों के लेखन के साथ-साथ कार्य योजना और ग्राहकों के साथ संचार की विशिष्टताओं के साथ हैं।

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

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

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

ग्राहक की नज़रों में एक ऑफशोर टीम को अच्छा दिखने में मदद करने के लिए यहां युक्तियां / टिप्पणियां दी गई हैं।

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

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

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

4. मेट्रिक्स / विकास पर्यावरण
डिफ़ॉल्ट रूप से, एक बिल्ड सर्वर, यूनिट टेस्ट कवरेज, जीरा, आदि को स्थापित किया जाना चाहिए। इस जानकारी का उपयोग करना, परियोजना प्रबंधक के लिए उच्च प्रबंधन को प्रगति दिखाना आसान होगा। यही है, हम इस बात की परवाह करते हैं कि प्रबंधन के सामने प्रबंधक कैसे "दिखता है"।
इसके अलावा, ये मीट्रिक परियोजना की प्रगति के वस्तुनिष्ठ आकलन हैं।

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

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

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

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

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

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

9. "फॉरवर्ड" समाधान
सिस्टम को अतिरिक्त आवश्यकताओं के माध्यम से "पुश" करने के लिए ग्राहक पसंद करते हैं, खासकर जब काम का 90% पहले से ही किया गया हो और सशर्त खाली समय हो।
दो समाधान हैं:
* कार्यों के निष्पादन को इस तरह से प्रदर्शित करें जैसे कि यह आभास देने के लिए कि हमारे पास कार्यक्षमता का 10% करने का समय नहीं है, और केवल "अविश्वसनीय" प्रयासों और टीम वर्क की मदद से, हमने यह सब किया
* परियोजना के लिए प्रारंभिक आवश्यकताओं का उपयोग करते हुए वापस लड़ें - आप सभी के पास पत्र और दस्तावेज हैं जिन पर चर्चा की गई थी, और इस मात्रा में काम करने के लिए सहमति प्राप्त की गई थी।

12. निषिद्ध शब्द
संचार में निषिद्ध शब्दों का उपयोग न करें। उदाहरण के लिए, "हम एक सप्ताह में सिस्टम को फिर से लिखेंगे" वाक्यांश मौलिक रूप से गलत है। यदि आप "फिर से लिखना" कहते हैं, तो अगला सवाल होगा कि "आप इस समय क्या कर रहे हैं?" ग्राहक की भाषा का ज्ञान उचित स्तर पर न होने के कारण ऐसे क्षण उत्पन्न हो सकते हैं। "सिस्टम को बेहतर बनाना" या "सिस्टम को ट्यून करना" लिखना बेहतर है।

13. यकीन नहीं है - फिर से पूछें
कई पूछने से डरते हैं, इसलिए यह दिखाने के लिए नहीं कि वास्तव में कुछ भी नहीं समझा गया है। लेकिन जब किसी कार्य को पूरा करने की बात आती है, तो समस्याएं शुरू हो जाती हैं।
हर कोई समझता है कि सब कुछ और प्रश्नों / चर्चाओं को जानना असंभव है जो एक व्यक्ति समझना चाहता है, और यह हमेशा स्वागत और समर्थित है।

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

टिप्पणियों का स्वागत है।