एक आउटसोर्सिंग कंपनी के साथ ग्राहक बातचीत

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

इंटरैक्शन स्कीम ग्राहक पहली बैठक से लेकर रिश्ते के अंत तक एक सॉफ्टवेयर डेवलपर है।

योजना बनाते समय मेरा मतलब है:

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

विक्रेता और ग्राहक द्वारा सॉफ़्टवेयर विकास के बीच अनुबंध के पहलुओं से बचने के लिए (साधारण रूप से अनुबंध से हटाने के लिए) विक्रेता के लिए फायदेमंद है।

1. डेडलाइन को पूरा करने की जिम्मेदारी डेवलपर के पास होती है और अगर अंतिम समय पर (यानी डेवलपर को पहले से सूचित नहीं किया है कि उसके पास बंद होने से पहले समय नहीं है) तो जुर्माना लगाया जाना चाहिए (यहां विकल्पों का एक बड़ा चयन है)।
   
   कारण: समय सीमा पूरी करने में विफलता सबसे बड़ी समस्याओं में से एक है और अनुबंध में इसका उल्लेख करना बहुत दिलचस्प नहीं है, क्योंकि अधिकांश भाग के लिए, डेडलाइन को पूरा करने में विफलता डेवलपर के पास है। यहां यह ध्यान रखना आवश्यक है कि सही गणना करना मुश्किल है, लेकिन अग्रिम में चेतावनी देने के लिए कि डेवलपर के पास एक निश्चित अवधि में विकास के चरण को पूरा करने का समय नहीं है - यह अनिवार्य है और इसे अनुबंध में निर्धारित किया जाना चाहिए।
   
   
2. डेवलपर की गलती के कारण "बग" को ठीक करने के लिए वारंटी की स्थिति, जो समय पर पता नहीं लगाई गई थी। सामान्य वारंटी अवधि 3 महीने है।
   
   कारण: यह अक्सर ऐसा होता है कि कुछ "बग्स" तय नहीं किए गए थे या पहले से ही काम की प्रक्रिया में दिखाई दिए थे, इसलिए इस आइटम को अक्सर वारंटी समय को इंगित या कम करने की कोशिश नहीं की जाती है। मेरी राय है कि कम से कम 3 महीने कम हैं।
3. विकसित सॉफ्टवेयर, मॉड्यूल, ब्लॉक आदि के अधिकार। ग्राहक के हैं और बाद के पुनर्विक्रय के लिए इस्तेमाल नहीं किया जा सकता है।
   
   कारण: डेवलपर के लिए बौद्धिक संपदा अधिकार रखना या अन्य ग्राहकों के लिए सर्वोत्तम प्रथाओं को बेचने / उपयोग करने में सक्षम होना फायदेमंद है, जो बदले में ग्राहक को एक असहज बाजार स्थिति में डाल सकता है।
4. सिस्टम में एक नया मॉड्यूल विकसित करते समय जो अन्य मॉड्यूल या संपूर्ण सिस्टम के संचालन को प्रभावित करता है, डेवलपर को पूरे सिस्टम के कामकाज को सुनिश्चित करना चाहिए।
   
   कारण: अक्सर एक मॉड्यूल का विकास दूसरे मॉड्यूल या पूरे सिस्टम के काम को नुकसान पहुंचा सकता है, और आगे के सुधार ग्राहक के "कंधों" (आर्थिक रूप से) पर झूठ बोल सकते हैं। डेवलपर को पूरे सिस्टम की संरचना को ध्यान में रखना चाहिए और क्लाइंट द्वारा पाए जाने वाले "बग" के मामले में, मुफ्त में संपादित करें।
5. विकास के लिए तकनीकी दस्तावेज ग्राहक की आवश्यकताओं को ध्यान में रखते हुए तैयार किए जाने चाहिए।
   
   कारण: यह डेवलपर्स के लिए पूरी तरह से ग्राहक के साथ खुद को बाँधने के लिए फायदेमंद है, और अक्सर ऐसा होता है कि दस्तावेज़ीकरण नहीं रखा जाता है।
6. वेबसाइट विकसित करने के मामले में, ठेकेदार को साइट के लिए एसईओ अनुकूलन को ध्यान में रखना चाहिए, अर्थात्: छवियों, पृष्ठों का विवरण ...
   
   कारण: "छोटी चीजों" पर समय की बचत, जो अनुबंध की शर्तों के आधार पर, ग्राहक के लिए वित्तीय नुकसान का कारण बन सकती है (सॉफ्टवेयर डेवलपर समय / वित्त बचाता है)।
7. सिस्टम परीक्षण सिस्टम डिजाइनर द्वारा प्रदान किया जाना चाहिए।
   
   तैयार मॉड्यूल के ग्राहक द्वारा स्वीकृति को सिस्टम परीक्षण में नहीं बदलना चाहिए, अर्थात। डेवलपर अपने खर्च पर ग्राहक द्वारा पहचाने गए "बग" को खत्म करने के लिए बाध्य है। डेवलपर द्वारा उत्पाद की गुणवत्ता परीक्षण सुनिश्चित करने के लिए यह आवश्यक है। जब तक डेवलपर का कहना है कि "किया" और परीक्षण ग्राहक की ओर से शुरू होता है - "कीड़े" मुफ्त में तय किए जाते हैं।
8. डेवलपर द्वारा परियोजना को ग्राहक पक्ष में रखने की जिम्मेदारी ली जाती है। उसी समय, ग्राहक साइट के लिए तकनीकी आवश्यकताओं का अनुपालन सुनिश्चित करने के लिए बाध्य है।
   
   कारण: ग्राहक की ओर से एक परियोजना रखना कभी-कभी कुछ कठिनाइयों का कारण बन सकता है, जिससे कैप-एंड-मॉर्गेज हो सकता है, इसलिए सर्वर को रखने और स्थापित करने की जिम्मेदारी सॉफ्टवेयर डेवलपर की तरफ होनी चाहिए।
9. यदि सॉफ़्टवेयर डेवलपर को अपनी टीम के बाहर के विशेषज्ञों की सहायता का सहारा लेने के लिए मजबूर किया जाता है, तो वह रिसाव, डेटा हानि या किसी अन्य क्षति के लिए सभी संबद्ध जोखिमों को मानने के लिए बाध्य होता है जो बाहरी कर्मचारी द्वारा उसकी कार्रवाई या निष्क्रियता के कारण हो सकता है।
   
   कारण: ऐसा होता है कि डेवलपर बीमार हो सकता है, छोड़ दिया, आदि। कर्मचारियों में से कोई भी। इस मामले में, ग्राहक का बीमा होना चाहिए।
10. परियोजना की बैकअप प्रतियां डेवलपर की ओर से प्रति दिन कम से कम 1 बार प्रदान की जानी चाहिए। डेवलपर द्वारा परियोजना पर डेटा के नुकसान के साथ कोई भी समस्या का समाधान किया जाना चाहिए।
    
    कारण: यहां यह इंगित करना आवश्यक है कि किसी भी विफलता के मामले में परियोजना की सुरक्षा के लिए कौन जिम्मेदार है।
11. डेवलपर को चुनते समय उसके द्वारा उपयोग की जाने वाली प्रौद्योगिकियों के उपयोग की लोकप्रियता से आगे बढ़ना चाहिए।
    
    कारण: मालिकाना प्रौद्योगिकियों के लिए बाध्य होना जो ग्राहक के किसी अन्य डेवलपर के संक्रमण के कारण जीवन को जटिल बना देगा।

वास्तविकता के सापेक्ष आउटसोर्सिंग की लागत को कम करने के ज्ञात तरीके। मुझे लगता है कि वहाँ अधिक हैं।

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

संबंध पैटर्न 'ग्राहक - सॉफ्टवेयर विकास विक्रेता', जो, मेरी राय में, व्यावहारिक उपयोग के सबसे करीब है।

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

इसके अलावा, मुझे लगता है कि परियोजना के कुल लागत की गणना को ध्यान में रखते हुए सॉफ्टवेयर विकसित करना पैसे की बर्बादी और एक तंत्रिका है, इस तरह के विकास से आमतौर पर संघर्ष की स्थिति पैदा होती है।

सॉफ्टवेयर डेवलपर और क्लाइंट की बातचीत में मुख्य बिंदु, जिसे मैं इष्टतम मानता हूं:

1. कर्मचारियों के काम या पूरी विकास टीम के विशेषज्ञ के काम की औसत लागत के आधार पर काम के लिए भुगतान। विकास के चरणों का आकलन आवश्यक है। मैं मूल्य निर्धारण के इस रूप पर विचार क्यों करता हूं:
   
   
   • किसी परियोजना के मूल्यांकन में इसे बहुत ही स्पष्ट दृष्टिकोण की आवश्यकता नहीं होती है, जिसे 100% सटीक बनाना लगभग असंभव है। यदि मूल्यांकन गलत तरीके से किया जाता है और सॉफ्टवेयर डेवलपर इसे समझने लगता है, तो कार्यक्षमता का "उल्लंघन" जहां कहीं भी संभव होता है, जो अंततः प्रयोज्य को प्रभावित करेगा।
   • सॉफ्टवेयर डेवलपर और क्लाइंट के बीच समझ को बेहतर बनाता है मुख्य कार्य सिद्धांत को कम किया जाता है - "इसे जल्दी और कुशलता से करें", न कि "एक तंग बजट में निवेश करें और यह कैसे अच्छी तरह से काम करेगा"।
   • ग्राहक, खर्च किए गए घंटों पर दैनिक रिपोर्ट के आधार पर, यह देख सकता है कि विकास के दौरान कर्मचारी विभिन्न ब्लॉकों पर किस समय बिताते हैं, जो सॉफ्टवेयर डेवलपर कर्मचारियों के काम की गति और गुणवत्ता की समझ देता है।
   • ग्राहक और परियोजना प्रबंधक के बीच बातचीत यथासंभव प्रत्यक्ष है, अर्थात। स्काइप, फोन आदि का उपयोग करते समय।
2. केवल 2-सप्ताह की रिपोर्ट और योजनाएँ मेल द्वारा (नियंत्रण के बिना) भेजी जानी चाहिए।
3. यदि आवश्यक हो तो एक क्लाइंट एक प्रोटोटाइप एप्लिकेशन प्रदान करता है या एक सॉफ्टवेयर डेवलपमेंट टीम द्वारा विकसित किया जाता है:
   • परियोजना की मुख्य कार्यक्षमता की समझ को सरल करता है।
   • परियोजना के विकास की समग्र गति को बढ़ाता है।
   • ग्राहक और डेवलपर दोनों की कार्यक्षमता के लिए स्पष्ट आवश्यकताएं।
   • परियोजना कहां स्थानांतरित होगी, इसकी स्पष्ट समझ।
4. परियोजना की प्रगति की निगरानी के लिए एक परियोजना प्रबंधन प्रणाली और प्रक्रिया की निगरानी करने की क्षमता, विकास कार्य प्रत्येक कार्य पर अलग से खर्च किया जाता है। दुर्भाग्य से, डेवलपर्स द्वारा पहुंच शायद ही कभी प्रदान की जाती है।
5. यह वांछनीय है कि पूरी परियोजना एक टीम द्वारा की गई थी, अर्थात्। ऐसा नहीं होना चाहिए कि एक चरण एक कंपनी द्वारा किया जाता है, दूसरा - दूसरा, आदि।
6. नियंत्रण अंक ("रन") प्रत्येक 2 सप्ताह परियोजना को नियंत्रित करने का सबसे अच्छा समय है।
7. विकास में, किसी भी स्थिति में आसान अनुकूलन के लिए, जब यह अन्य डेवलपर्स के लिए परियोजना को स्थानांतरित करने के लिए आवश्यक है, तो प्रसिद्ध रूपरेखाओं को प्राथमिकता दी जाती है।
8. डेवलपर की ओर से गुणवत्ता परीक्षण एक प्रत्यक्ष जिम्मेदारी है। क्लाइंट को प्रोजेक्ट या उसके किसी भी हिस्से में स्थानांतरित करते समय, सब कुछ पूरी तरह से जांचना चाहिए।
9. विभिन्न ब्राउज़रों का समर्थन करने के लिए डेवलपर का प्रत्यक्ष कार्य है

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