एक सॉफ्टवेयर प्रोजेक्ट को ऑफ़शोर करना - संघर्ष संकल्प [बंद]


11

मुझे एक परियोजना के प्रबंधन का काम सौंपा गया था जो कुछ यूक्रेनी डेवलपर्स के लिए आउटसोर्स किया गया था।

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

इस परियोजना में XMPP, RabbitMQ और डेटाबेस जैसी चीजों से संबंधित काम शामिल था। उनसे (हमेशा IM) मेरी पहली मुलाकात में मैंने अच्छी तरह समझाया कि उन्हें क्या करने की जरूरत है। वे इसे समझने लगे थे - और वे बहुत आश्वस्त थे कि यह आसानी से हो जाएगा।

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

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

  • उन्होंने कुछ चीजों को हार्ड-कोडित किया, जिन्हें एक विन्यास फाइल में अलग करने की आवश्यकता थी
  • वहाँ कई विन्यास फाइल थे जो मुझे एक में समेकित करने की आवश्यकता थी
  • उन्होंने बिल्कुल कोई दस्तावेज नहीं लिखा
  • कुछ अन्य छोटे बदलाव

मैंने उन्हें ये बदलाव करने के लिए कहा (प्रलेखन को छोड़कर) - और, हमारे पास एक तर्क था।

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

अंत में अब उन्होंने बदलाव किए हैं, और परियोजना समाप्त हो गई है। लेकिन यह मेरे मन में कुछ सवाल छोड़ जाता है ...

  • उन्होंने वही किया जो आवश्यक था लेकिन मुझे इसे ठीक से करने की आवश्यकता थी , और इसलिए परिवर्तन। क्या मैं वास्तव में अनुचित था?

  • मैं एक कार्यात्मक विनिर्देश के बिना उन्हें कोड देने पर सहमत क्यों हुआ?

  • मैंने यह क्यों नहीं सुनिश्चित किया कि वे पहली बार सब कुछ समझें?

क्या कोई खुद को उसी स्थिति में पाता है? क्या आपको लगता है कि आउटसोर्स परियोजनाओं को प्रबंधित करने का एक बेहतर तरीका है?

-- अपडेट करें --

सभी राय के लिए धन्यवाद - पूरे अनुभव पर प्रतिबिंबित करने के बाद, मैं निष्कर्ष निकाल सकता हूं ...

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

  • केवल यह निर्दिष्ट करना कि कोड क्या करना चाहिए पर्याप्त नहीं है। आपको यह बताना होगा कि कोड कैसा दिखना चाहिए। निर्देशिका संरचना क्या होगी; यदि संभव हो तो फ़ाइल नाम भी। यह आपको बाद में बहुत झुंझलाहट से बचाएगा। कड़ाई से कोडिंग दिशानिर्देशों, चर नामकरण सम्मेलनों, आंतरिक प्रलेखन प्रारूप आदि को निर्दिष्ट करें, यह देखें कि वे उन दिशानिर्देशों का पालन करते हैं, और यदि नहीं, तो चिल्लाएं।

  • उनकी ओर से एक कार्यात्मक विनिर्देश की मांग करें - जोर दें कि यह किसी भी कोड से पहले लिखा जाए। इससे बहुत सारे भ्रम और गलतफहमियां दूर हो जाएंगी।

  • कोड की समीक्षा करें क्योंकि इसे विकसित किया जा रहा है ताकि आप पहले की विसंगतियों की पहचान कर सकें और उन्हें ठीक कर सकें। हर दूसरे दिन कम से कम एक बार उनसे बात करें।

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


1
मैंने कभी भी एक अपतटीय परियोजना को अच्छी तरह से नहीं देखा है। मुझे लगा कि जब मैंने इसे पढ़ना शुरू किया तो मैं एक युद्ध की कहानी के लिए था।
smp7d

जवाबों:


13

सबसे पहले यह बंद करने का मुद्दा नहीं है, यह एक विक्रेता प्रबंधन का मुद्दा है

हाँ, आपने गलतियों का एक बहुत ...

उन्होंने वही किया जो आवश्यक था लेकिन मुझे इसे ठीक से करने की आवश्यकता थी, और इसलिए परिवर्तन। क्या मैं वास्तव में अनुचित था?

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

मैं एक कार्यात्मक विनिर्देश के बिना उन्हें कोड देने पर सहमत क्यों हुआ? क्योंकि आप कल्पना के लिए भुगतान नहीं करना चाहते थे ! दस्तावेज़ीकरण समय लेने वाली और महंगी है, क्या उन्हें सिर्फ मुफ्त में ऐसा करना चाहिए?

मैंने यह क्यों नहीं सुनिश्चित किया कि वे पहली बार सब कुछ समझें?

वे समझ गए। लेकिन आपकी मुट्ठी की बैठक के बाद अनुबंध पर हस्ताक्षर किया गया था (और निर्धारित मूल्य पर सहमति व्यक्त की गई है) जब आपने इसे समाप्त कर दिया है! इसलिए लागत (घंटे) में कटौती करने की जरूरत है, जहां वे कर सकते हैं .. मूल रूप से केवल एक सप्ताह में एक बैठक करके, कोई भी विकल्प नहीं देते।

यहां अगली बार ऐसा करने का तरीका है ... दो चरणों में ...

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

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


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


2
आप चरण 3 और चरण 4 भूल गए: ??? और लाभ :-)
रामहाउंड

3
आप अपनी कार्यात्मक कल्पना लिखने के लिए बाहरी संस्था से कैसे पूछ सकते हैं? कार्यात्मक कल्पना उसी परियोजना की आवश्यकताएं हैं जो आप चाहते हैं कि वे काम करें। अन्यथा आप उन्हें पैसे दे रहे हैं और उन्हें बता रहे हैं, "एक समस्या को हल करें, ... मुझे नहीं पता, यह पता लगाना चाहिए कि सॉफ्टवेयर को क्या करना चाहिए, मुझे परेशान नहीं किया जा सकता है।"
maple_shaft

1
@maple_Shaft अच्छा बिंदु, आवश्यकताएँ एकत्रित करना चरण 1 का हिस्सा है। मैं अपना उत्तर अपडेट करूंगा।
मोरोंस

1
-1 पुराने जलप्रपात

3
@JarrodRoberson मैं किसी विशेष पद्धति का प्रशंसक लड़का नहीं हूं। प्रत्येक की यह योग्यता है, लेकिन कहते हैं कि वे बस असफल हो गए क्योंकि उन्होंने एजाइल का उपयोग नहीं किया है वह गलत है।
मोरोंस

17

मुझे इसे ठीक से करने की जरूरत थी

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

यह परियोजना 3 सप्ताह के बाद पूरी हुई और उन्होंने वही दिया जो आवश्यक था। उस बिंदु पर मैंने कोड की समीक्षा करना शुरू कर दिया।

फिर से, आपको प्रोजेक्ट के दौरान कोड की समीक्षा करनी चाहिए थी, बाद में नहीं।

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

आपने उन्हें काम करने वाले कोड के लिए निर्धारित मूल्य का भुगतान किया। उफ़। यह उनकी गलती नहीं है, यह तुम्हारा है। स्प्रिंट में भाग लेने के लिए उनके समय का भुगतान करें जिसे आप नियंत्रित करते हैं और आप इस समस्या में नहीं चलेंगे। आपको उन्हें समय के लिए भुगतान करना चाहिए और उपयोगकर्ता कहानियों को स्वीकार करना चाहिए, कोड के लिए नहीं।

उनसे (हमेशा IM) मेरी पहली मुलाकात में मैंने अच्छी तरह समझाया कि उन्हें क्या करने की जरूरत है। वे इसे समझने लगे थे - और वे बहुत आश्वस्त थे कि यह आसानी से हो जाएगा।

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

जब मैंने डेवलपर्स से पूछा कि क्या वह एक्सएमपीपी जानता है, तो उन्होंने कहा कि वह पहली बार इसके साथ काम कर रहे थे।

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

मैं एक कार्यात्मक विनिर्देश के बिना उन्हें कोड देने पर सहमत क्यों हुआ?

केवल आप ही इसका उत्तर दे सकते हैं, लेकिन अगली बार इसे सीखने के अनुभव के रूप में लें।


2
मैं "यदि आप इसे ठीक से करना चाहते हैं, तो इसे स्रोत से बाहर न करें" से असहमत हैं।
मोरोंस

1
@ मॉर्न्स आपका अधिकार निश्चित रूप से, यह कहने के लिए एक आलसी बात थी। मैं सिर्फ दिमाग के उस फ्रेम के लिए डिफॉल्ट करता हूं क्योंकि ऑफशोरिंग की संभावना के लिए सबसे ज्यादा आकर्षित होने वाली कंपनियां वही हैं जिनके पास सही ढंग से करने के लिए अनुशासन की कमी है। यदि वे अपनी आंतरिक समस्याओं को हल कर लेते हैं जहां वे इसे सही तरीके से कर सकते हैं, तो उन्हें संभवतः पहले स्थान पर भी अपतटीय करने की आवश्यकता कम होगी।
maple_shaft

3
यह कहना चाहिए "यदि आप इसे ठीक से करना चाहते हैं, तो सबसे कम बोली लगाने वाले से गुणवत्ता की उम्मीद न करें" , एक दोस्त जो एक फ्रीलांसर फोटोग्राफर है, "सबसे सस्ता ग्राहक है, के पास सबसे अवास्तविक विस्तार है"

1
मैं उस कथन से भी असहमत हूं, आपको आंतरिक टीमों या स्थानीय विकास की दुकान के साथ एक ही समस्या हो सकती है।

7

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

तो आप दोनों ने पहले एक अनुबंध किया और फिर उन्होंने आपको एक युक्ति लिखने दी, और उन्होंने उस युक्ति को अपने अनुबंध का हिस्सा बनने के लिए स्वीकार कर लिया? अगर ऐसा है, तो यह आपकी गलती नहीं है, यह आपके ठेकेदार की गलती है। आप आसानी से उन्हें 3 महीने के बजाय 3 महीने के काम के लिए एक युक्ति लिख सकते हैं - सभी एक ही कीमत के लिए।

यह अधिकांश भाग के लिए ठीक था, लेकिन वहाँ कुछ महत्वपूर्ण समस्याएं थीं:

  • उन्होंने कुछ चीजों को हार्ड-कोडित किया, जिन्हें एक विन्यास फाइल में अलग करने की आवश्यकता थी
  • वहाँ कई विन्यास फाइल थे जो मुझे एक में समेकित करने की आवश्यकता थी
  • उन्होंने बिल्कुल कोई दस्तावेज नहीं लिखा
  • कुछ अन्य छोटे बदलाव

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


3

मैंने ऑफशोरिंग के बारे में कुछ समय पहले एक प्रस्तुति दी थी। इसे "ग्लोबल आउटसोर्सिंग, आपके व्यवसाय को सशक्त बनाने के लिए 10 युक्तियां" कहा जाता था। यहां 10 युक्तियों का सारांश दिया गया है (यह 400 आउटसोर्स परियोजनाओं से आता है):

एक विकल्प

  1. सबसे कम और उच्चतम बोली लगाने वालों से बचें । यह केवल स्पष्ट है, आप कम बोलीदाताओं के साथ जोखिम नहीं उठाना चाहते हैं और उच्चतम बोलीदाताओं की मंझला की तुलना में कम मूल्यवान (मूल्य / मूल्य) है।

  2. रेटिंग (या संदर्भ) की जाँच करें । मैं हमेशा संदर्भ और रेटिंग की जांच करता हूं।

  3. प्रेरणा को प्राथमिकता दें । समान मूल्य पर, मैं वह बोली चुनता हूं जो प्रेरित थी। उदाहरण के लिए, बोली लगाने वाले से आपके प्रोजेक्ट के बारे में बात करना बहुत अच्छा संकेत है।

ख। पर्यवेक्षण

  1. अपनी बौद्धिक संपदा की रक्षा करें । यह सबसे बड़ी गलती में से एक है। आमतौर पर आपके द्वारा उपयोग किए जाने वाले प्लेटफ़ॉर्म द्वारा नियंत्रित किया जाता है (जैसे कि vworker या elance)।

  2. कस्टम फ्रेमवर्क को मना करें । या आप इसे करने के लिए बंधे होने का जोखिम, या विशेष रूप से डेवलपर को लिखा है कि;)

  3. मानकों का पालन करें । पिछले टिप से संबंधित। मानक का उपयोग करने से आपके स्रोत कोड का मूल्य बढ़ जाता है क्योंकि यह बड़ी मात्रा में डेवलपर्स द्वारा समझा जा सकता है।

  4. जल्दी समीक्षा करें, अक्सर समीक्षा करें । यदि आप पहले सप्ताह या काम के बाद स्रोत कोड की समीक्षा करते हैं तो अधिकांश समस्या "समायोजित" हो सकती है।

C. रणनीति

  1. छोटी परियोजनाओं के साथ परीक्षण प्रदाताओं । इससे पहले कि मैं एक प्रदाता को एक बड़ी परियोजना देता हूं, मैं इसे एक या दो छोटी परियोजनाओं के साथ परीक्षण करता हूं।

  2. जोखिम कम करने के लिए कई बोलीदाताओं को स्वीकार करें । महत्वपूर्ण परियोजना के लिए, मैं दो या तीन बोलीदाताओं का चयन करता हूं फिर मैं सबसे अच्छा कार्यान्वयन लेता हूं। छोटी परियोजनाओं ($ 5000 से कम) के साथ सबसे अच्छा काम करें।

  3. घटकों को इकट्ठा करें । एक और रणनीति घटकों को आउटसोर्स करना है जिसे आप बाद में इकट्ठा करते हैं। एक लाभ यह है कि आप प्रदाताओं के बीच आसानी से स्विच कर सकते हैं और कोई भी वास्तव में पूरी चीज तक नहीं पहुंच सकता है (बौद्धिक संपदा जोखिम को कम करें)।


1

मैं पूरी तरह से Maple_shaft के जवाब से सहमत हूं।

आपने कोड स्वीकार कर लिया और मैंने मान लिया कि चेक लिखा है, फिर कोड की समीक्षा की, आपने सब कुछ पीछे कर दिया।

मैं एक कार्यात्मक विनिर्देश के बिना उन्हें कोड देने पर सहमत क्यों हुआ?

क्योंकि आपने इसे अनुबंध में नहीं लिखा था। चूँकि आप काम पूरा करना चाहते थे, आपने उनके कारणों को स्वीकार कर लिया, भले ही इसकी वही बात जो आपको परेशानी में डाले।

मैंने यह क्यों नहीं सुनिश्चित किया कि वे पहली बार सब कुछ समझें?

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

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

आप खुशकिस्मत हैं कि उन्होंने वो बदलाव किए जो आप चाहते थे। वे कह सकते थे: कठिन भाग्य

क्या कोई खुद को उसी स्थिति में पाता है? क्या आपको लगता है कि आउटसोर्स परियोजनाओं को प्रबंधित करने का एक बेहतर तरीका है?

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

कम से कम इसे स्वयं करके आप प्रतिदिन परियोजना की स्थिति की जांच कर सकते हैं। यदि आप पीछे हैं तो नुकसान को नियंत्रित करने के लिए आप कर सकते हैं, कम से कम सिद्धांत में।


1
companies are starting to realize having to pay ... to do it 3 and 4 times is more expensive then doing it right once.यह इस से अधिक है, मुझे लगता है कि ऑफशोरिंग सॉफ्टवेयर विकास के साथ उद्योग हनीमून का चरण समाप्त हो रहा है और अधिक कंपनियां यह महसूस करना शुरू कर रही हैं कि यह स्वर्ण बछड़ा नहीं है कि उन्हें लगा कि यह होगा ( या कहा गया था) सलाहकारों द्वारा )। अधिकांश प्रबंधन बेकार है और उन्हें पता नहीं क्यों, इसलिए वे अपनी सभी समस्याओं को हल करने के लिए सिल्वर बुलेट डु पत्रिकाओं की तलाश करते हैं। ऑफशोरिंग बहुत अच्छा है अगर आप इसे सही करते हैं, लेकिन अधिकांश के पास उस तरह का अनुशासन नहीं है।
maple_shaft
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.