जब एक ग्राहक के पास अवास्तविक अपेक्षाएं हों तो क्या करें? [बन्द है]


23

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

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

चूंकि ग्राहक एक सॉफ्टवेयर कंपनी नहीं है, और विभिन्न नीतियों के कारण, मुझे अपनी मशीन पर अधिकार देने के लिए लगभग 20-25 दिन लग गए, ताकि मुझे पर्यावरण स्थापना, सामान स्थापना में देरी के बाद भी Eclipse, Tomcat, इत्यादि सामान स्थापित करने में मदद मिले। वे अभी भी मुझे उसी दो महीने की अवधि में परियोजना को पूरा करने की उम्मीद कर रहे थे।

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

छह महीने के बाद भी आवेदन समाप्त नहीं हुआ है, और हर कोई मुझे दोष दे रहा है, लेकिन वे यह महसूस करने में विफल हैं कि हमने पहले कुछ बैठकों में चर्चा की तुलना में कई और सुविधाएँ जोड़ी हैं।

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

आवेदन का दायरा हर दिन बढ़ता जा रहा है लेकिन उन्हें अभी भी लगता है कि यह दो महीने का प्रोजेक्ट है जिसमें देरी हुई। जब मैंने उन्हें बताया कि गुंजाइश बढ़ गई है तो वे पूछते हैं कि मैंने शुरुआत में आवश्यकता क्यों नहीं पूछी।

मैं पहले से ही रोज 11-12 घंटे काम करता हूं और 3-4 घंटे की यात्रा करता हूं, और अब वे मुझसे शनिवार को भी आने की उम्मीद करते हैं।

मुझे यहां सब कुछ करना है: आवश्यकताओं, डिजाइन, कोड और परीक्षण लेना।

कृपया मुझे सलाह दें कि ऐसे मामले में क्या करें?

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


11
आप वास्तव में इसे तेजी से पूरा करेंगे अगर आप केवल 8 घंटे के दिन और कोई सप्ताहांत काम करते हैं। थकावट आपकी उत्पादकता को रोक रही है। alternet.org/visions/154518/...
HLGEM

10
लगता है जैसे आप किसी और का बलि का बकरा बन रहे हैं

क्या आप यह बताते हुए एक संपादन जोड़ सकते हैं कि यह स्थिति कैसे हल हुई? यह भविष्य के पाठकों की मदद कर सकता है यदि वे खुद को एक समान स्थिति में पाते हैं।
राडू मुरझिया

आपको अपनी नई नौकरी कहां मिली?
मावग

जवाबों:


65

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

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

यदि आपका प्रबंधक आपको वापस नहीं करता है और इसमें आपका समर्थन करता है - और मैं यह बहुत बार नहीं कहता - दूसरी नौकरी की तलाश शुरू करें। क्योंकि आप शायद पूरी गंदगी के लिए बलि का बकरा बनेंगे। और अगर आप 11 घंटे दिन और 3 घंटे काम करने को तैयार हैं, तो जाहिर है कि आप एक बहुत समर्पित व्यक्ति हैं जो बेहतर के हकदार हैं।


जब मैंने अपने प्रबंधक से इस बारे में बात की, तो वह सहायक थे। लेकिन यह सब इस बात पर निर्भर करता है कि अब बैठक में क्या होता है :(
आशीषजमश्रम

1
मेरे अनुभव में, प्रोग्रामर्स को हर चीज के लिए प्रबंधन को दोष देने की बहुत जल्दी है जो गलत हो जाता है ... बोल्ड पहले भाग ने मुझे इसे पढ़ने से रोक दिया अन्यथा यह बहुत अच्छा जवाब था। यदि प्रबंधक इस मुद्दे से अनभिज्ञ था, तो उसे पूरी तरह से दोष देना कठिन है (हालांकि एक अच्छा प्रबंधक "बस जानता है" व्हाट्सएप चल रहा है कोई बात नहीं)। यह एक डेवलपर पर निर्भर है कि इस तरह के मुद्दों को लाने के बाद प्रबंधकों को जल्द से जल्द ध्यान दें।
मटनज़

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

1
@GrandmasterB। मिलने के लगभग एक हफ्ते बाद, अधिक संगठित तरीके से काम करने के बारे में बहुत कुछ कहा गया लेकिन कुछ भी नहीं बदला है। मैंने उन सभी चीजों को सूचीबद्ध करने की कोशिश की जो हमने आवश्यकताओं की बैठकों में चर्चा की और ग्राहकों को ईमेल की। किसी ने उन्हें पढ़ने की जहमत नहीं उठाई और इसके बजाय मुझे ग्राहकों से "यह ईमेल लिखने में आपका एक घंटा बर्बाद हो गया होगा"। :(
आशीषजमश्रम

1
मैं उत्सुक हूं कि यह कैसे समाप्त हुआ। आपका ग्राहक अज्ञानी और स्वार्थी है। वे आपकी बात नहीं मानते क्योंकि उनके पास नहीं है। आपको एक दृढ़ कथन देना होगा कि अब आप इस तरह से काम नहीं कर सकते। तो क्या आप चले गए? या फिर आपने काम को पूरा नहीं किया?
फोर्ज़ा

21

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

आप एक बैठक आयोजित करते हैं जहाँ अतिरिक्त सुविधाओं की आवश्यकता होती है? इसे बाद में लिखें, प्रत्येक आइटम पर "+ X दिनों से वर्तमान शेड्यूल" टैग करें और इसमें शामिल सभी को मेल करें। यदि आप केवल ग्राहक की आंतरिक मेल प्रणाली का उपयोग करते हैं, तो अतिरिक्त रूप से इसका प्रिंट आउट निकालते हैं, जिसमें:: cc: और bcc: प्राप्तकर्ताओं की सूची शामिल है और इसे ध्यान से संग्रहित करें। इसके अलावा, जैसा कि ग्रैंडमास्टरबी ने कहा, ग्राहक को मूल आवश्यकताओं के लिए ऐसे परिवर्तनों पर हस्ताक्षर करना चाहिए।

यदि आवश्यक शेड्यूल आयोजित नहीं किया जा सकता है, तो उन्हें लिखें। यदि कोई परिवर्तन होता है, तो उसे लिखें, परिणाम सहित। और इसी तरह।

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


16

आप जो वर्णन करते हैं, उससे यह प्रतीत होता है कि आप एक शास्त्रीय डेथ मार्च प्रोजेक्ट में भाग ले रहे हैं :

में परियोजना प्रबंधन , एक मौत मार्च वैकृत परियोजनाओं के कई प्रकार के किसी भी एक dysphemistic शामिल, असली करने के लिए काले हास्य सादृश्य है मौत जुलूस, जैसे कि भीषण रूप से अति-कार्य किया जा रहा है, और (अक्सर और सबसे विशेष रूप से) एक परियोजना पर बीमार-स्थापित कारणों के लिए भीषण रूप से अति-कार्य किया जा रहा है जो जाहिर तौर पर खराब परिणाम के उच्च जोखिम पर है (यानी, परियोजना की विफलता, और संभवतः व्यक्तिगत और समूह प्रतिष्ठा क्षति का खतरा) । इस प्रकार "डेथ मार्च" नाम एक ऐसी परियोजना पर लागू किया जा सकता है जो अंततः सफल होती है, लेकिन इसमें किसी भी बुद्धिमान, सूचित सदस्य को विफल होने (या है) को देखने के लिए एक सतत ओवरवर्क, या (शायद अधिक बार) का एक घर शामिल होता है। विफलता के बहुत उच्च जोखिम पर) लेकिन सदस्यों को फिर भी अपने वरिष्ठों द्वारा किसी भी तरह बाहर निकलने के लिए मजबूर किया जाता है ...

फेनोमेनन अच्छी तरह से जाना जाता है और आगे बढ़ने के तरीके के बारे में बहुत सारे साहित्य हैं - जिसमें सेमिनल एडवर्ड ऑर्डन की किताब डेथ मार्च: द कम्प्लीट सॉफ्टवेयर डेवलपर की गाइड टू सर्वाइविंग 'मिशन इम्पॉसिबल' प्रोजेक्ट शामिल है

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


अपने जूतों में घूमना, पहली बात मैं अपने प्रबंधक को उपरोक्त लेख का संदर्भ देना चाहूंगा।

इस तरह से उन्हें पता चल जाएगा कि मैं क्या कर रहा हूं, इसके बारे में जानता हूं, और संभवत: उन्हें इस धारणा के लिए प्रदान किए गए ढांचे के संदर्भ में मार्गदर्शन करने में भी मदद करता हूं, जैसे "देखो, हमारा वर्तमान राज्य Xयेरडॉन में अध्याय में वर्णित एक के करीब है । बारीकी से, संबंधित अध्याय Yआदि के साथ ... "

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


11

ईमानदारी से, यदि आपके लिए ऐसा करना संभव है, तो सबसे अच्छा समाधान छोड़ना है। इस तरह की स्थिति आपके लिए विषाक्त है और वे समय के साथ शायद ही कभी बेहतर होते हैं, चाहे आप कितनी भी कोशिश कर लें।

अपने नुकसान को काटने और एक अलग टमटम खोजने के लिए सबसे अच्छा है। लेकिन, अपने अनुभव को प्रतिबिंबित करें और इस धागे पर अन्य उत्तरों से सलाह लें।


2
यह एक बुरा जवाब नहीं है, कृपया इसे बिना स्पष्टीकरण के न दें। हां, यह गॉर्डियन गाँठ को काटने जैसा है, लेकिन ओपी द्वारा वर्णित स्थिति (और उसकी हताशा) को देखते हुए यह सबसे अच्छी बात हो सकती है जो वह कर सकता है। कार्य + यात्रा 14 घंटे प्लस शनिवार को काम करते हैं? आपके शारीरिक और मानसिक स्वास्थ्य की तरह लगता है कि एक गंभीर खतरा है।
तमसे सजेलेई

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

यह सबसे ऊपर और स्वीकृत उत्तर क्यों नहीं है? quit++;
मग

11

यह एक गंभीर बात है issue in project management । ऐसा लगता है कि आपके Project Managerको डिलीवरी योग्य सूची पर काम करना चाहिए और उन्हें ग्राहक के साथ प्राथमिकता देना चाहिए ।

सबसे महत्वपूर्ण , आपका पीएम should discussऔर क्लाइंट के साथ आपके अनुमानों में समय सीमा (समस्या / समाधान के डिजाइन और विश्लेषण सहित) से सहमत हैं।

clear estimation of your work loadपरियोजना के आइटम होने और वितरित करने से आपको तनाव से राहत मिलेगी, साथ ही, आपके काम में मन की शांति और आत्मविश्वास भी बढ़ेगा।

अपने आइटम को स्प्रिंट (2-3 सप्ताह) में वितरित करके और क्लाइंट के साथ UAT (उपयोगकर्ता स्वीकृति परीक्षण) बनाकर चुस्त दृष्टिकोण का उपयोग करने का प्रयास करें । याद रखें, स्प्रिंट शुरू करने से पहले हमेशा अपनी स्प्रिंट प्लानिंग करें।

यहाँ छवि विवरण दर्ज करें

संपादित करें: टिप्पणियों से यह स्पष्ट है कि यह वास्तव में आपके प्रोजेक्ट मैनेजर की विफलता है । आपकी जैसी गंभीर परियोजना के लिए समुचित परीक्षण और / या विकास का माहौल न होना, एसडीएलसी प्रक्रिया के लिए एक बड़ा छेदproject है।


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

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

2
चंचल दृष्टिकोण के लिए +1। यह करो, और यह करने के लिए, हर तरह से छड़ी।
ब्रूनो शापर

1
@ वी फेलोमन - "+1" का अर्थ है कि आप उत्तर को बढ़ाते हैं।
मौविसील जूल 25'12

@ मौविसील याप। मैं नहीं था? जहाँ तक मैं देख सकता हूँ मैंने किया है ..
ब्रूनो स्कैपर

10

जबकि मैं मानता हूं कि यह एक प्रबंधन विफलता है, यह आपकी ओर से विफलता भी है। इस स्तर पर इसे ठीक करना बहुत कठिन होगा, इसलिए आपको इस से बाहर निकलने की आवश्यकता है कि भविष्य की परियोजनाओं को कैसे संभालना है।

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

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

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

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

अगला, अपने आप को 11-घंटे के दिनों और सप्ताहांत में काम करने की अनुमति न दें। यह छोटी अवधि (प्रत्येक छह महीने या उससे कम 1 सप्ताह) में ठीक है, लेकिन लंबी अवधि के लिए यह स्वीकार्य नहीं है। थके हुए लोग धीमी गति से कोड करते हैं और वे अधिक गलतियां करते हैं। आप नियमित रूप से 11 घंटे की तुलना में 8 घंटे नियमित रूप से काम कर रहे उच्च गुणवत्ता के साथ अधिक काम कर सकते हैं। और सप्ताहांत।


1
उत्तर के लिए धन्यवाद। मुझे देखने के लिए बहुत अच्छे अंक।
आशीषजमेश्रम

+1 के लिए "आप समय सीमा को स्थानांतरित करने के लिए नहीं कहते हैं, आप उन्हें बताते हैं कि यह नई आवश्यकता के कारण बढ़ रहा है।" यह इंगित करता है कि समय सीमा आपके द्वारा बनाई गई कुछ नहीं है, लेकिन परियोजना की आंतरिक संपत्ति है।
सालेके जुले

1
you need to insist ona a requirements baseline document at the start of the project, Next, you tell them how long it takes to do the work and that sets the deadline., And every time they add another piece on, you tell them how much longer it will take and how much the additional work will move the deadline. ग्रेट सलाह लेकिन ऐसी स्थिति में किया जा रहा है एक बार मैं जाहिरा तौर पर साथ काम करने के लिए असंभव होने के लिए एक महीने से भी कम में निकाल दिया गया था। वास्तविक स्थिति यह है कि अन्य लोग इसे कैसे लगाते हैं, इस प्रकार की कंपनियां बलात्कारी और बहाने चाहती हैं, न कि उत्पादक यथार्थवादी सॉफ्टवेयर डेवलपर्स।
maple_shaft

4

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

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

से विकी :

गैंट चार्ट एक परियोजना के टर्मिनल तत्वों और सारांश तत्वों की शुरुआत और समाप्ति तिथियों का वर्णन करता है।


अगर इस जवाब को वोट दिया जा रहा है, तो कृपया मुझे बताएं कि क्यों। धन्यवाद।
AidanO

1
+1 - गैंट चार्ट पुराने स्कूल हो सकते हैं लेकिन ऐसा लगता है कि ग्राहक प्रोजेक्ट में खरीदारी नहीं कर रहा है, इसलिए गंट्ट चार्ट जितना सरल हो सकता है, यह उनकी अतिरिक्त आवश्यकताओं का असर दिखा सकता है।
डेव
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.