फ्रीलांस सॉफ्टवेयर डेवलपमेंट में, डेडलाइन मिस करने पर फर्मों को किस तरह का दंड देना चाहिए? [बन्द है]


12

मैं एक सह-डेवलपर के साथ बात कर रहा था।

उसके पास एक ग्राहक है जो यह सुनिश्चित करना चाहता है कि वह समय पर उद्धार करे। ग्राहक छूटी हुई समय सीमा के लिए नतीजे चाहता है।

जबकि मैं फ्रीलांस काम नहीं करता, मैं जवाब नहीं दे सका।

तो, मेरा सवाल है:

यदि आप अपने डिलिवरेबल्स पर डेडलाइन मिस कर देते हैं (एक तरफ से निकाल दिया जा रहा है) तो आप (फ्रीलांसरों) अपने क्लाइंट से क्या सहमत हैं?


2
वह किसी भी दंड को स्वीकार करने के लिए मूर्ख होगा, कम से कम बदलते आवश्यकताओं के आधार पर एक आउट-क्लॉज के बिना। खाता परिवर्तन प्रबंधन को ध्यान में रखने से पहले, टास्क का अनुमान सबसे बेहतर तरीके से छिपाया जाता है। मूल रूप से। रन
मैट डी।

4
तो ग्राहक को समय सीमा याद करने के लिए आपके पास एक वित्तीय हित होगा? एक बहुत अच्छे विचार की तरह नहीं लगता है। यह केवल तभी समझ में आएगा जब देर होने पर ग्राहक को एक कठिन वित्तीय नुकसान होता है (जैसे कि मेनमा के उदाहरण में)।
डॉक्टर ब्राउन

2
यह मुझे पूरी तरह से स्वीकार्य लगता है। मैं टिप्पणियों से काफी हैरान हूं। आप उम्मीद करते हैं कि लोगों को काम के लिए भुगतान करना होगा, या तो कोई समय सीमा नहीं है और समय सीमा को पूरा करने के लिए कोई प्रोत्साहन नहीं है? "कार्य अनुमान छिपकर गलत है" - यह होना जरूरी नहीं है।
निमचिम्प्सकी

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

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

जवाबों:


25

सबसे प्रभावी में से एक: देरी के दिन तक जुर्माना। यह भी बड़ी परियोजनाओं के लिए किया जाता है, जुर्माना कभी-कभी हजारों डॉलर प्रति दिन होता है।

यदि एक सटीक समय सीमा मायने रखती है (उदाहरण के लिए यदि कोई ओलंपिक खेलों के लिए विकसित होता है तो एक वेब ऐप जो 2014 में घटना के प्रसारण को संभाल लेगा, तो समय सीमा 2014 में ओलंपिक खेलों की शुरुआत होगी), तो प्रभावी उपाय यह हो सकता है कि एक मामला जब परियोजना देर से होती है, तो कंपनी को भुगतान नहीं किया जाता है, और जुर्माना भी देना चाहिए।

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

ग्राहक के लिए ध्यान दें:

  1. कई देरी खुद ग्राहकों की गलती है। कारण कई हो सकते हैं:

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

    • अंतिम समय सीमा से दो सप्ताह पहले आना और यह बताना कि यह परियोजना अब तक जावा में नहीं हुई थी और Oracle का उपयोग करती थी: पायथन में फिर से लिखना और MySQL का उपयोग करना अनिवार्य है, क्योंकि ग्राहक ने कल एक पत्रिका पढ़ी है यह बताना कि वे प्रौद्योगिकियां भविष्य हैं।

    • हर बैठक में आवश्यकताओं का एक ताजा सेट के साथ आ रहा है। बोनस अंक जब उन आवश्यकताओं को अब तक दी गई हर आवश्यकता के विपरीत है।

  2. एक अच्छी परियोजना के लिए अच्छा संचार आवश्यक है।

    कई अन्य देरी संचार की कमी के कारण हैं। प्रैक्टिस जहां ग्राहक के पास कंपनी के साथ महीनों तक कोई संवाद नहीं होता है और उम्मीद करता है कि उत्पाद समाप्त होने और पॉलिश होने के बाद ही संपर्क किया जाएगा।

  3. आप जिसके लिए भुगतान करते हैं वह आपको प्राप्त होता है।

    विशिष्ट प्रक्रियाएं हैं जो परियोजना को व्यवस्थित रखने में मदद करती हैं, और वास्तव में, प्रोग्रामिंग को बड़ी परियोजनाओं के लिए केवल 10 से 15% समय और मध्यम परियोजनाओं के लिए 15% से 20% समय लेना चाहिए। उन परियोजनाओं को उन लोगों द्वारा भी किया जाना चाहिए जो जानते हैं कि वे क्या कर रहे हैं।

    व्यवहार में, ग्राहक $ 800 / दिन एक विश्लेषक का भुगतान करने के लिए तैयार नहीं हैं, जो वास्तुकला और सॉफ्टवेयर डिजाइन बनाएंगे, और वे न तो अन्य चरणों के लिए भुगतान करना चाहते हैं। एक नौसिखिया अल्बानियाई प्रोग्रामर जो $ 50 / दिन के लिए काम करने के लिए खुश है, बहुत अधिक लाभप्रद लगता है।

    शिकायत न करें कि परियोजना एक आपदा है जब आप केवल विनाशकारी परियोजनाओं के लिए भुगतान करने के लिए तैयार हैं।

  4. काम करने के लिए आवश्यक समय पर बातचीत न करें।

    मैं अक्सर इस तरह की चर्चा करता हूं:

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

    बातचीत का समय आपदा का एक नुस्खा है।

  5. अपनी प्राथमिकताओं को जानें।

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

    इसके दो कारण हो सकते हैं:

    • जब परियोजना सही ढंग से नहीं की जाती है, यानी 100% समय प्रोग्रामिंग के लिए समर्पित होता है, जो आवश्यकताओं को इकट्ठा करने, वास्तुकला, डिजाइन और परीक्षण के लिए 0% छोड़ता है, तो क्या होता है कि प्रोग्रामर को काम करने के बारे में कोई पता नहीं है, और उन्हें पता चलता है परियोजना के पूरे जीवन के दौरान नए कार्य। परियोजना को तैयार करने से उन सभी कार्यों को समझने में मदद मिलेगी, जिन्हें पूरा किया जाना चाहिए।

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

    प्राथमिकताओं को सीधे रखने और परियोजना को सही ढंग से पूरा करने की आवश्यकता से उन कंपनियों को उम्मीदवारों की सूची से दूर करने में मदद मिलती है।


3
"शिकायत न करें कि परियोजना एक आपदा है जब आप केवल विनाशकारी परियोजनाओं के लिए भुगतान करने के लिए तैयार हैं।" क्या मैं उसका उपयोग कर सकता हूं? यह एक महान पोस्ट btw है, और अच्छी तरह से दोनों पक्षों से जोखिमों को बोता है।
मैट डी

+1 बहुत अच्छे अंक। इसके अलावा, एक खुशी पढ़ने के लिए :)
रादु मुराज़े

5
@ मैट: स्टैक एक्सचेंज पर जवाब क्रिएटिव कॉमन्स एट्रिब्यूशन-शेयरएलाइक 3.0 के तहत लाइसेंस प्राप्त है, इसलिए हां, आप कर सकते हैं। इसके अलावा, मेरे ब्लॉग पर संबंधित पोस्ट पढ़ने के लिए स्वतंत्र महसूस करें: समय और लागत निर्धारित करना: हमें हमेशा गलत क्यों मिलता है? , साथ ही साथ मेरे सवाल का जवाब यहां: programmers.stackexchange.com/q/158640/6605
Arseni Mourzenko

उस ब्लॉग पोस्ट में कोई भाग 4, 5, 6 आदि क्यों नहीं है?
राडू मुरझिया
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.