2010-03-22 3 views
21

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

  1. मैं आसानी साथ सुविधा को लागू क्योंकि यह

  2. मैं साथ सुविधा को लागू मौजूदा मंच के साथ संगत है कठिनाई क्योंकि मैं के पुनर्लेखन के लिए है मंच की नींव का एक महत्वपूर्ण भाग

  3. ग्राहक निकाल लेता अनुरोध इसकी वजहबहुत ज्यादा 10 लागत मौजूदा मंच परियोजना की शुरुआत में

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

ग्राहक नई सुविधाओं को लागू करने के लिए समय और लागत पर निराशा व्यक्त करना शुरू कर रहा है। उनके लिए, कई फीचर अनुरोध एक ही पैमाने के हैं, जिनकी उन्होंने छह महीने पहले अनुरोध की थी। उदाहरण के लिए, एक ग्राहक पूछता है, "यदि पिछले साल आपको टिकट प्रणाली बनाने के लिए 1 सप्ताह का समय लगेगा, तो आज आपको इवेंट पंजीकरण प्रणाली बनाने में 1 महीने क्यों लगता है? एक इवेंट पंजीकरण प्रणाली टिकट प्रणाली से कहीं अधिक सरल है। यह आपको केवल 1 सप्ताह लेना चाहिए! " इस परिदृश्य के कारण, मुझे डर है कि फीचर अनुरोध जल्द ही श्रेणी 3 में उतरेंगे)। असल में, मैं पहले से ही बहुत सारी लागत खा रहा हूं क्योंकि मैं परियोजना का समर्थन करने के लिए कई घंटे स्वयंसेवक हूं।

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

पूर्णकालिक कंपनी के लिए वेतन पर काम करते समय, प्रबंधक मेरे अनुमानों के बारे में अधिक ग्रहणशील थे और मुझे अप्रत्याशित रूप से तैयार करने के लिए मेरे नंबरों को पैड करने के लिए प्रोत्साहित किया। क्या मेरे ग्राहकों को उसी तरह सोचने की शर्त है?

क्या कोई इस बारे में सलाह दे सकता है कि मैं इस वेब प्रोजेक्ट पर खुद को कितना खर्च किए बिना काम करना जारी रख सकता हूं?

अतिरिक्त जानकारी - मैं केवल 1 वर्ष के लिए पूर्णकालिक फ्रीलांस कर रहा हूं। मेरे पास अभी तक उच्च अंत ग्राहक नहीं हैं, लेकिन मैं धीरे-धीरे वहां जा रहा हूं। समय के साथ-साथ मुझे बेहतर गुणवत्ता वाले क्लाइंट मिल रहे हैं।

+1

यह एक अच्छा सवाल है, लेकिन व्यक्तिपरक और खुले अंत प्रकृति को देखते हुए, यह कम्युनिटी विकी के लिए एक अच्छी कैंडिटेशन की तरह लगता है। –

+2

@ एडम: "व्यक्तिपरक और खुले अंत प्रकृति को देखते हुए", यह बंद होने के लिए एक अच्छा उम्मीदवार है। सीडब्ल्यू ऐसे प्रश्नों को बेहतर नहीं बनाता है। –

+1

@ जॉन: शायद नहीं, लेकिन मैं इस साइट पर एक प्रश्न या विषय रखने का लाभ देख सकता हूं जैसे कि यह काफी अच्छी तरह से (और सहयोगी) संबोधित किया गया है। –

उत्तर

9

ऐसा लगता है कि आपके पास आपके आर्किटेक्चर में कुछ तकनीकी ऋण है; परिवर्तन के संबंध में यह भंगुर है। इसके अलावा, यह स्पष्ट नहीं है कि आप सही समय पर परीक्षण कर रहे हैं। अपने परीक्षण लिखने का सबसे अच्छा समय है कि आप अपना कोड लिखने से पहले, अपने परीक्षणों को अपने कोड के लिए निष्पादन योग्य विनिर्देश के रूप में कार्य करने दें।

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

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

+0

+1, मेरे विचार बिल्कुल। –

+3

+1। यह आमतौर पर तकनीकी ऋण है। ऐसा हम में से अधिकांश के साथ होता है। लेकिन इसका मतलब यह नहीं है कि यह केवल आपकी गलती है: अक्सर आपको समय सीमा के लिए भागना पड़ता है और बाद में रेडैक्टर होता है। यदि ग्राहक आपको भागना चाहता है, तो उसे बाद में रिफैक्टरिंग के लिए भुगतान करने के लिए तैयार रहना चाहिए। उसे समझाए जाने से केवल एक ही आप है। –

+0

मुझे यह उचित नहीं लगता कि भंगुर आर्किटेक्चर केवल अनुभवहीनता का परिणाम हैं; उदाहरण के लिए, उपयोगकर्ता एक ब्लॉग के लिए पूछता है, आप उन्हें एक ब्लॉग देते हैं, फिर वे पूछते हैं कि लाइन से 3 महीने नीचे 'क्या आप एक विकल्प बना सकते हैं ताकि मैं ब्लॉग पोस्ट पेज पर नहीं दिख सकूं बल्कि बदले में विकी में जाऊं?'। सोचते हुए "मैं अपने शुरुआती वास्तुकला में उस संभावना को क्यों नहीं बनाया, वास्तव में उत्पादक नहीं है।" असल में, मैं उस समय के 50% के लिए सहमत हूं जब ग्राहक अनुरोध सीधे मूल के दायरे में हैं प्रोजेक्ट, लेकिन मुझे नहीं लगता कि यह पूरी तस्वीर – Bolster

6

हाल ही में फ्रीलान्सिंग चीज कर रहे थे (अलग-अलग क्षेत्र), और मैंने अनुबंध में दो चीजें बनाईं; ए) यदि किसी भी प्रमुख (मेरी राय में) ढांचे में बदलाव/परिवर्तन किए जाने थे, प्रत्येक को अलग डिलीवरी आवश्यकताओं और लागतों के साथ एक अलग परियोजना के रूप में गिना जाता था, बी) कि मैं एक उचित स्तर का दस्तावेज प्रदान करता हूं ताकि अगर वे मेरे 'अनुमान' से खुश नहीं हैं, वे किसी और की कोशिश कर सकते हैं।

मेरे पास एक क्लाइंट विकल्प विकल्प एक बार था; वे काफी जल्दी वापस आए।

2

thesetwo लेखों पर एक नज़र डालें।

+1

धन्यवाद, वे वास्तव में अच्छे लेख हैं – John

1

मैं कैसे लागत अपने आप को बहुत ज्यादा खाने के बिना इस वेब परियोजना पर काम जारी रख सकते हैं पर किसी को भी सलाह दे सकते हैं?

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

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

संबंधित मुद्दे

 संबंधित मुद्दे