अपने डेवलपर्स द्वारा बंधक बनाए जाने से बचें

hostage100107इस सप्ताह के अंत में मैंने एक स्थानीय कलाकार के साथ बातचीत शुरू की, जो अपने बॉस के मालिक के वेब अनुप्रयोगों के प्रबंधन में अपने बॉस की सहायता कर रहा है।

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

डेवलपर ने डोमेन नाम स्थानांतरित किए ताकि वह उन्हें प्रबंधित कर सके। डेवलपर अपने होस्टिंग खाते पर एप्लिकेशन भी होस्ट करता है। संक्षेप में, डेवलपर अब उन्हें बंधक बना रहा है।

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

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

कुछ सुझाव यदि आप एक आउटसोर्स विकास दल प्राप्त करने जा रहे हैं:

  1. डोमेन पंजीकरण

    अपनी कंपनी के नाम में अपने डोमेन नाम पंजीकृत करें। अपने डेवलपर को खाते में तकनीकी संपर्क के रूप में रखना बुरा नहीं है, लेकिन कभी नहीँ अपनी कंपनी के बाहर किसी को भी डोमेन का स्वामित्व हस्तांतरित करें।

  2. अपने एप्लिकेशन या साइट को होस्ट करना

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

  3. खुद का कोड

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

  4. दूसरी राय लें!

    यह मेरी भावनाओं को आहत नहीं करता है जब लोग मुझे बताते हैं कि वे बोलियां ले रहे हैं या अन्य पेशेवरों के साथ परामर्श कर रहे हैं। असल में, मैं इसकी अनुशंसा करता हूं!

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

6 टिप्पणियाँ

  1. 1

    मैं एक वेब ऐप डेवलपर हूं और मैं आपके अधिकांश बिंदुओं (शायद सभी) से सहमत हूं, लेकिन मैं # 3 पर स्पष्टीकरण चाहूंगा।

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

    उदाहरण:
    ग्राहक पृष्ठ स्तर और क्षेत्र स्तर नियंत्रण उपयोगकर्ता भूमिकाओं से बंधा हुआ चाहता था। ASP.Net के लिए "बॉक्स से बाहर" कार्यक्षमता फ़ोल्डर स्तर की अनुमति देती है। इसलिए मैंने .Net के लिए मूल अनुमतियाँ बढ़ा दीं और समाधान को एक समग्र वेब एप्लिकेशन के भाग के रूप में दिया।

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

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

    • 2

      ज़रुरी नहीं,

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

      डॉग

  2. 3

    मैं देखता हूं कि आप कहां से आ रहे हैं और जब तक मैं 100% (मेरे पास कैविटीज़) से सहमत नहीं हूं, कंपनियों को हमेशा इसे ध्यान में रखना चाहिए।

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

    2. मैं आंशिक रूप से इससे सहमत होना चाहता हूं लेकिन फिर यह स्थिति पर निर्भर करता है। यदि आप एक सरल PHP ऐप की तैनाती कर रहे हैं और सभी तरीकों से कम लागत वाली होस्टिंग की आवश्यकता है, तो एक LunarPages या DreamHost खाता या कुछ और प्राप्त करें और इसे वहां डंप करें। डेवलपर को एक्सेस दें। हालांकि, कम लागत वाली साझा होस्टिंग निश्चित रूप से कमियां हैं ... खासकर बड़ी चीजों के लिए। लेकिन अगर आप इस बारे में चिंतित होने के लिए पर्याप्त हैं कि आपके पास कर्मचारियों पर कोई तकनीकी होना चाहिए जो इससे निपट सके। इसके बारे में बहुत कुछ स्पष्ट रूप से विश्वास के बारे में है। यकीन है कि नरक में एक अनुबंध में कुछ डाल अगर आप इस तरह की चीज़ (प्रतिबंध और इस तरह) के बारे में कर सकते हैं। यदि डेवलपर को कुछ भी फैंसी करने की आवश्यकता नहीं है, तो थर्ड पार्टी होस्टिंग बढ़िया है। मैं मानता हूँ कि मैं फटा हुआ हूँ क्योंकि यह वास्तव में स्थितिजन्य बात है। यह साइट के आकार, उपयोग की गई तकनीकों की सरणी पर भी निर्भर करता है। यदि यह बड़ा होने वाला है, तो कर्मचारियों पर एक व्यक्ति को काम पर रखने पर विचार करें। हमेशा एक विकल्प नहीं, लेकिन बड़े सामान के लिए सुरक्षित।

    3. यह भी मेरी पूर्व कंपनी ने कुछ किया है। आप छोड़ सकते हैं, वे आपको HTML, चित्र आदि देंगे…। लेकिन कोई कोड नहीं। कोड मूल रूप से एक पट्टे पर सेवा थी। कहा जा रहा है, वहाँ मालिक और मालिक है। मैंने हमेशा एक गैर-अनन्य बिक्री की है। मूल रूप से, मुझे अपने घटकों का पुन: उपयोग करने में सक्षम होने की आवश्यकता है। मेरे पास इसके ग्राहक के साथ कोई समस्या नहीं है, जो वे इसके साथ चाहते हैं वह कर रहे हैं और किसी और ने इस पर काम किया है ... लेकिन मैं खुद को गिरवी नहीं रख रहा हूं और हर बार पहिया को फिर से मजबूत करना है।

    4. हमेशा। हमेशा। हमेशा।

  3. 4

    अच्छी पोस्ट ... अच्छी तरह से किया, हालांकि मैं एक आइटम (# 2) से असहमत हूं:

    "यह बहुत अच्छा है कि आपके डेवलपर के पास एक होस्टिंग कंपनी हो सकती है और वह आपके लिए आपकी साइट की मेजबानी कर सकता है, लेकिन ऐसा न करें।"

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

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

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

    फिर से, अच्छी पोस्ट और बहुत उपयोगी जानकारी।

    धन्यवाद!
    माइकल रेनॉल्ड्स

    • 5

      हाय माइकल,

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

      व्यापार में चीजें होती हैं जो रिश्तों को तोड़ती हैं और उन्हें नकारात्मक नहीं होना चाहिए। शायद आपके डेवलपर / फर्म को एक बहुत बड़ा क्लाइंट मिलता है और वह आपको समय नहीं दे सकता है। शायद वे व्यावसायिक उद्देश्यों को स्थानांतरित करते हैं। कभी-कभी उनकी होस्टिंग कंपनी के मुद्दे हो सकते हैं।

      मैं वकालत कर रहा हूं कि आप नियंत्रित करते हैं और अपनी मेजबानी के लिए जिम्मेदार हैं ताकि आप अपने डेवलपर पर निर्भर कर सकें कि वह किस चीज में महान है - विकासशील!

      मैं पुश-बैक, माइकल की सराहना करता हूं।

  4. 6

    मैं एक वेब ऐप डेवलपर भी हूं, और मुझे लगता है कि आपने सिर पर कील ठोक दी है। कुछ विचार:

    मुझे लगता है कि ज्यादातर सभी सहमत होंगे (और नीचे टिप्पणी के आधार पर) # 1 एक निरपेक्ष है। कभी नहीं, कभी करो। कभी। किसी भी परिस्थिति में।

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

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

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

    जैसा कि दूसरों ने कहा है, # 4 हमेशा अनुशंसित है। हमेशा!

    सादर,
    टिम यंग

तुम्हें क्या लगता है?

यह साइट स्पैम को कम करने के लिए अकिस्मेट का उपयोग करती है। जानें कि आपका डेटा कैसे संसाधित किया जाता है.