प्रबंधक प्रत्येक डेमो के बाद आवश्यकता विनिर्देश को बदलता रहता है [बंद]

Question

मेरे काम के माहौल की पृष्ठभूमि

मेरे प्रबंधक के पास कंप्यूटर या सॉफ़्टवेयर की कोई पृष्ठभूमि या समझ नहीं है। यह अत्यधिक संभावना है कि उन्होंने अपने जीवन में किसी भी रूप में कोड (10 फीट या उससे कम की भौतिक दूरी से भी) नहीं देखा है।

ऐसा कोई नहीं है जो मुझे लागू करने के लिए कहा गया हो, इसकी जटिलता को समझता है। इस बात के लिए कि अगर मैं सेमी-हार्डकोड करता तो किसी को पता नहीं चलता।

पर जोएल के परीक्षण हम एक अविश्वसनीय स्कोर 0 स्कोर।

समस्याये

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

प्रश्न

क्या किया जाए? विशेष रूप से वहाँ के बारे में कोई नहीं है जो मेरे कोड में सुधार को इंगित करेगा।

अद्यतन करें

एचएलजीईएम (और संभवत: अन्य) का जवाब देने के लिए मैंने क्या करने और इसे ठीक करने के लिए किया है। मैंने रेडमाइन स्थापित करने और सभी के लिए स्रोत नियंत्रण पेश करने की पेशकश की। मैंने कहा कि मैं डिस्ट्रीब्यूटेड (git या मर्क्यूरियल) की सिफारिश करूंगा लेकिन यह भी केंद्रीकृत लोगों के बारे में बात करेगा और टीम को तय करने देगा। प्रतिक्रिया थी कि चीजें की जा रही हैं और हफ्तों के भीतर किया जाएगा। यह नहीं देखा गया है और न ही मुझे पता है कि कंपनी के अन्य भागों का उपयोग करते हैं।

Comments

स्पष्ट उत्तर देने के लिए: RUN !!

— कीपला

जब तक कोई बड़ी बात न हो आप हमें नई नौकरी की तलाश शुरू नहीं कर रहे हैं।

— Zachary K

"प्रबंधक और कई बार अन्य" वरिष्ठ "आवश्यकता विनिर्देश को बदलते रहते हैं।" खैर, एक कल्पना होने पर आपको जोएल के परीक्षण पर 1 अंक मिलेगा। : पी

— आर। मार्टिनो फर्नांडीस

गैर-तकनीकी प्रबंधकों के कारण कोई संगठन स्कोर जोएल टेस्ट में 2 से कम नहीं है। आपके स्कोर को बढ़ावा देने के लिए गैर-तकनीकी प्रबंधकों से इनपुट के बिना आप और टीम के अन्य तकनीकी सदस्य कर सकते हैं। आपके पास प्रबंधक पर पूरी तरह से दोष देने का कोई बहाना नहीं है।

— मेपल_शॉफ्ट

लगता है कि आपके पास सॉफ्टवेयर प्रबंधन के रूप में बिक्री टीम भी है, मुझे सहानुभूति है।

— Wildpeaks

Answer 1

लघु संस्करण :

चलाएँ।

---

कुछ हद तक लंबा संस्करण :

यदि प्रबंधक को पता नहीं है कि परियोजना कैसे चलाना है, और यदि वरिष्ठ इसके साथ जाता है, तो आपके पास चीजों को ठीक करने का कोई मौका नहीं है।

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

मैं एक बार ऐसी ही स्थिति में था (केवल कोई वरिष्ठ नहीं था)। मैंने एक भयानक वर्ष के बाद छोड़ दिया, और कभी पीछे मुड़कर नहीं देखा (घृणा को छोड़कर)।

Comments

इस उद्धरण के लिए +1: "यदि प्रबंधक प्रोग्राम चलाना नहीं जानता है, और यदि वरिष्ठ इसके साथ जाता है, तो आपके पास चीजों को ठीक करने का कोई मौका नहीं है।"

— मेपल_शफ्ट

Answer 2

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

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

बहुत सारे शब्दजाल का उपयोग किया जाता है जो समझदारी से व्याकरणिक रूप से काम करता है लेकिन किसी भी तरह से किसी भी तरह का अर्थ निकालने में विफल रहता है।

फिर, इतना अपरिचित नहीं लगता ;;;

ऐसा कोई नहीं है जो मुझे लागू करने के लिए कहा गया हो, इसकी जटिलता को समझता है।

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

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

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

Comments

किसी ने मेरे गलत होने का क्या मतलब है? मुझे सुधारने और सीखने में मदद करना।

— जंगल हंटर

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

— जूनस पुलकका

हां आप सही हैं। मैं सुधार करने की कोशिश कर रहा हूं, लेकिन मुझे लगता है कि मेरे प्रयासों को सुधारने के प्रयास से अधिक शिकायत देखी जा रही है। ईमानदारी से मेरे प्रयास दोनों हैं, लेकिन चलो देखते हैं कि क्या मैं उन्हें दूसरा छमाही देखने के लिए मिल सकता हूं - सुधार करने का प्रयास।

— जंगल हंटर

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

— जूनस पुलकका

@ जून: मैं उन कंपनियों में रहा हूँ जहाँ मैंने VCS को पेश किया था, कोड की समीक्षा की, C ++ सेमिनार दिया, और व्हाट्सएप, लिंक की गुणवत्ता में सुधार किया। और मैं एक कंपनी में किया गया है बहुत ओपी के रूप में वर्णन करता है। यदि यह एक निराशाजनक मामला है, तो आप हार मान सकते हैं और ऐसी नौकरी की तलाश करेंगे जहां आपके संघर्ष को सफल होने की अनुमति देकर पुरस्कृत किया जाए।

— एसबीआई

Answer 3

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

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

आप जोएल परीक्षण पर एक शून्य स्कोर करते हैं? यदि आप केवल कोडर हैं (और जो आपने लिखा है कि यह लगता है) से लगता है कि वे स्रोत नियंत्रण का उपयोग क्यों नहीं कर रहे हैं? आपको क्या रोक रहा है? यदि आप एकमात्र कोडर नहीं हैं, तो कोई भी ऐसा क्यों नहीं है जो कोड समीक्षा कर सकता है? हमारे सभी देव कोड की समीक्षा करते हैं, यह विशेष रूप से प्रबंधन का कार्य नहीं है जब प्रबंधक गैर-तकनीकी होते हैं।

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

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

पॉलिश दिखने वाले डेमो को साबित न करें! डेमो को यह देखना चाहिए कि क्या वे कागज के एक टुकड़े पर कलम में लिपटे हुए हैं। अधिक पॉलिश किए गए इंटरफ़ेस को लगता है कि गैर-तकनीकी व्यक्ति सोचता है कि यह समाप्त हो गया है।

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

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

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

ऊपर से सभी निष्क्रिय नहीं हैं और ऊपर से आने वाले सुधार की अपेक्षा करते हैं।

Comments

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

— जंगल हंटर

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

— जंगल हंटर

पेन्ड्रिव्स पर उन्हें कोड देना बंद करें। यदि वे आपका कोड चाहते हैं, तो उन्हें बताएं कि यह स्रोत नियंत्रण में है और उन्हें इसका उपयोग करने का तरीका दिखाएं।

— ह्यूगो

@JungleHunter जब वे आपके कोड के लिए पूछते हैं, तो उन्हें बताएं कि आपका आधा परिवर्तन से नहीं चलेगा, लेकिन वे स्रोत नियंत्रण से अंतिम स्थिर संस्करण प्राप्त कर सकते हैं।

— किर्क ब्रॉडहर्स्ट 3

@HLGEM "तुम रोना और किस करना"? बहुत अधिक कठोर, अकेले उस के लिए अपमानजनक।

— बेन एच।

Answer 4

अगर मैं तुम होते तो मैं दूसरी नौकरी खोजने की कोशिश करता। क्यूं कर? मुझे लगता है कि आप जानते हैं कि, दुर्भाग्य से, आपका प्रबंधक, "अच्छा नहीं" है। यद्यपि आपको अपने प्रबंधक के साथ कुछ सामान बनाने की कोशिश करनी चाहिए।

यदि आप छोड़ना नहीं चाहते हैं, और / या आप किसी से बात नहीं करने जा रहे हैं, तो आप स्वयं कुछ खोजने जा रहे हैं। यदि कंपनी में कोई भी आपके कोड के बारे में नहीं जानता है, तो आपके प्रबंधक को यह कैसे पता होना चाहिए कि आप आवश्यकताओं को पूरा करते हैं? बस केह रहा हू।

Comments

वह सिर्फ एक डेमो को देखता है। कहते हैं, इसे इस तरह और उस तरह से बदल दें। और फिर वहां पर बाढ़ की आहट है।

— जंगल हंटर

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

— maple_shaft

@maple_shaft: मुझे लगता है कि यह एक उत्कृष्ट विचार है।

— जंगल हंटर

@maple_shaft: या शायद समय से बहुत आगे पहुंचाने के बजाय, बस अंत की ओर वितरण करें। ;)

— जंगल हंटर

एक मिडिल स्कूली

Answer 5

बात करें अपने प्रबंधक और इस बारे में वरिष्ठ नागरिकों के लिए। अपने मुद्दों को समझाएं और समाधान सुझाएं। बात को थोड़ा तैयार करें ताकि आप उस सामान्य संदेश को जान सकें जिसे आप बताना चाहते हैं।

बात के बाद, इसे कुछ समय दें । देखें कि चीजें बदलती हैं या नहीं। यदि वे नहीं करते हैं, तो अपने आप को परिवर्तनों को लागू करने का प्रयास करें और प्रबंधक और वरिष्ठों को आपके परिवर्तनों के सकारात्मक परिणाम दिखाएं ।

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

Comments

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

— जंगल हंटर

@ जंगल: फिर ASAP चलाएं।

— sbi

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

— मेपल_शॉफ्ट।

Answer 6

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

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

मेरे पास एक गैर-तकनीकी प्रबंधक भी है और जोएल टेस्ट स्कोर को 4 से बढ़ाकर 8 करने में सक्षम था, क्योंकि मैं गया और उन्हें किया और अनुमति नहीं मांगी।

आपके समूह को एक मजबूत तकनीकी नेता की जरूरत है और किसी ने भी थाली में कदम नहीं रखा है।

की जाँच करें http://community.rallydev.com/ वे एक समुदाय संस्करण है कि चंचल परियोजना प्रबंधन और दोष ट्रैकिंग का एक बहुत अच्छा काम करता है की है। वह अकेले ही आपके जोएल स्कोर को टक्कर देगा और आपको सेट करने के लिए कोई सर्वर स्थान या समय खर्च नहीं करेगा।

Comments

हाँ! मुझे लगता है कि प्रमुख मुद्दा है। हमारे पास एक मजबूत तकनीकी नेता नहीं है।

— जंगल हंटर

Answer 7

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

आवश्यकताओं में परिवर्तन हमेशा रहेगा, और आपका काम उन्हें गले लगाना है, जो चुस्त विकास के आधार सिद्धांतों में से एक है :

विकास में देरी का स्वागत करते हैं, यहां तक ​​कि देर से विकास। चंचल प्रक्रियाएं ग्राहक के प्रतिस्पर्धात्मक लाभ के लिए बदलाव बदलती हैं।

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

यदि यह एक प्रकार की परियोजना है, जहां आपका प्रबंधक वह है, जो सभी आवश्यकताओं के साथ आता है, तो आपको उसके चंचल ग्राहक की तरह कार्य करना चाहिए, और उन्हें एक ही बात समझाना चाहिए (गुंजाइश <-> समय सीमा समझौता )।

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

ये कुछ कदम हैं जिनकी आपको पूरी तरह से आवश्यकता है, और शायद आपको उन्हें स्वयं करने की आवश्यकता होगी:

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

याद रखें कि आपके पास अपनी मशीन पर स्थानीय रूप से SVN रिपॉजिटरी हो सकती है। एक साधारण TODO सूची एक गरीब-आदमी की बग ट्रैकिंग प्रणाली (थोड़ा चरम, लेकिन हे) के रूप में काम कर सकती है। और स्क्रिप्ट नहीं बनाने के लिए कोई बहाना नहीं है।

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

Comments

"ग्राहक के प्रतिस्पर्धी लाभ" के लिए महत्वपूर्ण है। बाद में आज मैंने उनसे पूछा कि वह ऐसा क्यों करते हैं, कहते हैं, ग्राहक को प्रभावित करने के लिए। : |

— जंगल हंटर

मेरे पास अपने लिए जगह / जगह है। लेकिन मैं अभी मैनुअली टेस्टिंग करता हूं। मुझे स्वचालित इकाई परीक्षणों पर ध्यान देना चाहिए।

— जंगल हंटर

Answer 8

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

कोड या जटिलताओं को समझने के लिए प्रबंधकों की आवश्यकता नहीं होती है। संसाधनों, लागत और जोखिम को समझने की जरूरत है।

स्रोत कोड संस्करण, कोड गुणवत्ता, जटिलता, आदि या तो पीएम जिम्मेदारी या वरिष्ठ डेवलपर हैं।

समाधान यह है:

1-प्रोजेक्ट टीम संरचना और उनकी जिम्मेदारियों को परिभाषित करें

2-सॉफ्टवेयर प्रबंधन में खराब प्रबंधन के कारण प्रबंधक को शिक्षित करना - तकनीकी विवरण से दूर रहना। आप गुग्लिंग द्वारा कुछ उदाहरण पा सकते हैं।

Comments

"तकनीकी विवरण से दूर रहें।" मैं विरोध करने की कोशिश करूंगा। ;) यह बात बताने के लिए धन्यवाद।

— जंगल हंटर

Answer 9

विशेष रूप से वहाँ के बारे में कोई नहीं है जो मेरे कोड में सुधार को इंगित करेगा।

क्या आप कोड समीक्षाएं सेट करने का प्रयास नहीं कर सकते ताकि कोड को देखने वाले लोग हों? क्या ऐसे सम्मेलन और मानक हैं जो कोड को कुछ संरचना देने में मदद करेंगे? यह माना जाता है कि आप केवल डेवलपर ही नहीं हैं।

जब आप कम जगह में होने की संभावना रखते हैं, तो क्या ऐसा लगता है कि यह अंत में काम कर रहा है? क्या परियोजनाएं पूरी हो रही हैं और चीजें आगे बढ़ रही हैं? बातें हो रही हैं? डक्ट टेप प्रोग्रामर जोएल लेख होगा जिसे आप पढ़ना चाहते हैं।

Comments

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

— जंगल हंटर

Answer 10

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

विकल्प 2 - उन्हें वह दें जो वे चाहते हैं। जब वे आपके द्वारा कहे गए कुछ के बारे में शिकायत करते हैं '

Comments

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

— जंगल हंटर

@ जंगल शिकारी - हर किसी के पास अपनी नौकरी छोड़ने का विकल्प नहीं है, कभी-कभी आपको स्थिति को पार करना होगा। मैंने पागलपन को संभालने का सबसे अच्छा तरीका पा लिया है कि इसे पागल लोगों पर वापस लाया जाए। केवल पागल ही अपने पागलपन के खिलाफ बहस कर सकते हैं। सौभाग्य।

— 16