"सबसे कम डेवलपर" के रूप में तकनीकी ऋण लड़ना?


20

मान लीजिए कि आप एक कंपनी के लिए काम करते हैं और आप जो करते हैं, वह उनके लिए सॉफ्टवेयर विकसित करना है। आपको बड़ी तस्वीर या शायद मामूली के बारे में पता नहीं है। आपके पास जो कार्य हैं वे समस्या ट्रैकिंग सिस्टम के माध्यम से आपको सौंपे गए हैं। आपको कार्य दिए गए हैं, आप उन्हें कार्य करने का तरीका बताते हैं कि कार्य उनका वर्णन करता है, आप उन्हें वापस भेजते हैं। जैसे 2 पूर्णांक जोड़ना:

function add(a,b){return a + b;}

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

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

आप इन स्थितियों से कैसे निपटेंगे? आप "सबसे कम डेवलपर" के रूप में तकनीकी ऋण कैसे लड़ते हैं?

स्पष्टीकरण:

  • आप "कार्यान्वयनकर्ता" हैं, जो पदानुक्रम में सबसे कम है।

  • आप समस्या देखते हैं, लेकिन इस मामले पर कोई बात नहीं है।

  • मैं तकनीकी ऋण का मूल्यांकन नहीं कर रहा हूं या उपकरण की तलाश नहीं कर रहा हूं।

  • तीसरे "डुप्लिकेट" के बारे में

    • Refactoring & Rewrite - आप अपने कार्यों के लिए बंद हैं। आपको अतिरिक्त करने के लिए भुगतान नहीं किया जाता है।
    • वास्तुकला अवलोकन - आप समग्र प्रणाली को जानते हैं, लेकिन वास्तुकला का कोई विचार नहीं है।
    • कोड फ्रीज - आपकी कॉल नहीं। आप प्रबंधन नहीं हैं।
    • संशोधन - वास्तुकला का कोई विचार नहीं। आवश्यकताएं बदलते ही मॉड्यूल बदल जाते हैं।
    • स्वचालित परीक्षण - कोई भी मौजूद नहीं है।


3
@ लगन, मुझे लगता है कि प्रश्न संबंधित हैं (विशेषकर अंतिम एक), लेकिन डुप्लिकेट नहीं। मैं इस प्रश्न को देखता हूं कि "किसी सिस्टम के वास्तुकार को लागू करने वाला नहीं है, और कार्यान्वयनकर्ताओं को सिस्टम का उच्च स्तरीय दृश्य नहीं दिया जाता है, यह कैसे सुनिश्चित किया जा सकता है कि कार्यान्वयन पर्याप्त रूप से लचीले या स्केलेबल हैं?"
मेटाफ़ाइट

1
क्या आप पूछ रहे हैं कि सामान्य रूप से तकनीकी ऋण कैसे लड़ें, या क्या आप पूछ रहे हैं कि तकनीकी ऋण से कैसे लड़ें जब आप आर्किटेक्चर में सुधार के लिए कोई ज़िम्मेदार ज़िम्मेदारी वाले कोडर की भूमिका में हों?
डॉक ब्राउन

2
@JosephtheDreamer हां, बहुत सी चीजें हैं जो स्रोत कोड को बेहतर बनाने के लिए की जा सकती हैं, लेकिन आपने अपने प्रश्न में कहा था कि समस्या किसी भी बदलाव पर कार्रवाई करने के लिए अधिकार की कमी है। मैं आपको सभी सर्वोत्तम प्रथाओं को बता सकता हूं लेकिन अगर आपको उन्हें लागू करने के लिए बड़ी मात्रा में निवेश करने की अनुमति नहीं है, तो क्या बात है? ;)
रेक्टगुलर

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

जवाबों:


22

हर बार जब आप ऐसा कुछ नोटिस करते हैं, तो अपने अंक ट्रैकिंग सिस्टम में एक नया टिकट दर्ज करें।

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

इस काम के लिए सही उपकरण का उपयोग करें। मैं इसे हमेशा करता हूं और दृढ़ता से आपको वही करने की सलाह देता हूं।

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

(वास्तविक ट्रैकर में उपयोग की जाने वाली सुविधाओं, टिकटों और कोड का नाम अस्पष्ट है, लेकिन पाठ की नकल की जाती है)।

सारांश: डिजाइन को शामिल करने को सरल बनाएंParticularPieceOfCode

विवरण:
TICKET-12345 के कार्यान्वयन के दौरान, कोड ParticularPieceOfCodeमें जटिल जटिलता का उपयोग होता है और इसे पढ़ना, समझना और बनाए रखना मुश्किल होता है (नीचे उदाहरण कोड स्निपेट देखें)।

इसे सरल बनाने का एक तरीका खोजें।

कोड का एक उदाहरण जो फिर से डिज़ाइन करने के लिए वांछनीय होगा, उसमें पाया जा सकता है ClassName#methodName:

<a piece of code like one behind the right door here:>
http://i.stack.imgur.com/ARBSs.jpg


एफडब्ल्यूआईडब्ल्यू मेरी सलाह स्वतंत्र रूप से लागू होती है कि आप किस "स्तर" पर हैं।

मैं इसे आपके वर्तमान ("निम्नतम") स्तर पर उपयोग कर रहा हूं और मैं अब इसका उपयोग कर रहा हूं कि मेरा स्तर "निम्नतम" से काफी दूर है और मुझे संतोषजनक "कहना" है जैसा कि आप इसे कहते हैं, और मैं इसका उपयोग करने जा रहा हूं हमेशा कोई फर्क नहीं पड़ता।

जरा इसके बारे में सोचिए, कोई स्तर नहीं, आपके पास कितना भी अधिकार है, बस कोई बेहतर तरीका नहीं हो सकता है।

यदि आप "कहते हैं" अरे, हमें एक मुद्दा मिल गया है , तो यह केवल हवा का झुनझुना है। और यहां तक ​​कि अगर आपके बॉस / लीड सहमत हैं और कहते हैं कि आप सही हैं, तो हमें एक मुद्दा मिल गया है , इससे कुछ भी नहीं बदलता है - यह केवल फिर से हवाई तेजस्वी है, और यह कुछ और नहीं हो सकता है।

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

इस काम के लिए सही उपकरण का उपयोग करें। आपके द्वारा वर्णित नौकरी के लिए, मुद्दा ट्रैकर बिल्कुल सही उपकरण है।

आप इस मुद्दे को नोटिस करते हैं, आप इसे इन पर नज़र रखने के लिए डिज़ाइन किए गए सिस्टम में दर्ज करते हैं और यह बाकी का ख्याल रखता है, सबसे अच्छे तरीके से - बस इसलिए कि इसे इसके लिए डिज़ाइन किया गया था :

कंप्यूटर सॉफ्टवेयर पैकेज जो किसी संगठन द्वारा आवश्यक के रूप में मुद्दों की सूचियों का प्रबंधन और प्रबंधन करता है ... आमतौर पर उपयोग किया जाता है ... रिपोर्ट किए गए ग्राहक मुद्दों को बनाने, अद्यतन करने और हल करने के लिए, या यहां तक ​​कि उस संगठन के अन्य कर्मचारियों द्वारा रिपोर्ट किए गए मुद्दों पर ... एक मुद्दा ट्रैकिंग सिस्टम " बगट्रैकर " के समान है , और अक्सर, एक सॉफ्टवेयर कंपनी दोनों को बेचेगी, और कुछ बगट्रॉकर्स एक मुद्दा ट्रैकिंग सिस्टम के रूप में उपयोग किए जाने में सक्षम हैं, और इसके विपरीत। किसी समस्या या बग ट्रैकिंग सिस्टम के लगातार उपयोग को "एक अच्छी सॉफ़्टवेयर टीम की पहचान" 1 में से एक माना जाता है ...

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

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


7
+1 अच्छी सलाह, लेकिन एक ऐसे वातावरण में ट्रैकिंग जारी करना जो प्रक्रिया को गले नहीं लगाता सिर्फ एक ब्लैक होल बन जाता है। क्या अच्छा है एक व्यक्ति का एक मुद्दा ट्रैकर। सबसे अच्छी तरह से फैंसी-टू-लिस्ट।
रिएक्टगुलर

@MathewFoscarini पोस्ट करने से पहले, मैंने टिप्पणियों में ओपी के साथ इसे स्पष्ट किया (मेरे जवाब में "आपके मुद्दे पर नज़र रखने की प्रणाली के तहत लिंक") - 'हाँ, इसलिए "कार्य" (मुद्दे, टिकट, जो भी आप उन्हें कॉल कर सकते हैं) ...' मैं यह भी नहीं कहूंगा कि "ब्लैक होल" मामलों के बारे में निराशावादी, लंबे समय में चीजें बदल जाती हैं, खासकर अगर "सबसे निचले स्तर" डेवलपर्स एक पहल करते हैं और ट्रैकर को बनाए रखने और अपने स्वयं के उपयोग को बढ़ावा देने के प्रयास में निवेश करते हैं (वहां ऐसा किया गया है) )
gnat

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

1
@ जेन्सजी "लोगों को टिकट प्रणाली को प्रदूषित करने के लिए दोषी ठहराया जा रहा है" - यह एक ज्ञात घटना है, शायद एक समर्पित प्रश्न के योग्य है (या शायद यह पहले से ही पूछा और उत्तर दिया गया था, मैं खोज नहीं किया था)। यदि संस्कृति फिट नहीं होती है, तो टिकट सिस्टम को मददगार बनने के लिए अतिरिक्त विशिष्ट प्रयासों की आवश्यकता होती है (जैसा कि मैंने पूर्व टिप्पणी में लिखा है कि मैं इससे पहले भी रहा हूँ)।
gnat

8

मुझे आपके परिदृश्य के बारे में बुरा लग रहा है, जैसा आपने हेडलाइन में लिखा है और कई बार प्रश्न पाठ में:

आप श्रृंखला में सबसे कम डेवलपर हैं

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

लेकिन भले ही आप रैंक के संबंध में सबसे कम डेवलपर हों, फिर भी यह काफी सही नहीं है। यहाँ कुंजी यह महसूस करना है, कि आप केवल अपने आप को सबसे कम विकासकर्ता मान रहे हैं । क्या आपने कभी उस आत्म-धारणा को दूर करने की कोशिश की है और वास्तव में किसी चीज़ की जिम्मेदारी ली है ?

लेना! रुको नहीं, जब तक कोई तुम्हें जिम्मेदार नहीं बनाता।

  • आप समस्या देखते हैं, लेकिन इस मामले पर कोई बात नहीं है।
  • मैं तकनीकी ऋण का मूल्यांकन नहीं कर रहा हूं या उपकरण की तलाश नहीं कर रहा हूं।
  • आप अपने कार्यों के लिए बंद हैं। आपको अतिरिक्त करने के लिए भुगतान नहीं किया जाता है।
  • तुम्हारी पुकार नहीं। आप प्रबंधन नहीं हैं।

आमतौर पर यह काफी विपरीत होता है: आपको अधिक भुगतान किया जाता है और आपकी राय का अधिक सम्मान किया जाता है, एक बार जब आप दिखाते हैं कि आप पैसे के लायक हैं । यह "पहले है", दूसरे तरीके से नहीं।

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

इसे दूसरे तरीके से करने के लिए: कोई भी कार्यकर्ता मधुमक्खियों को बढ़ावा नहीं देता है, लोग निष्क्रिय रूप से उन्हें सौंपे जाने वाले कार्यों की प्रतीक्षा करते हैं, यहां तक ​​कि पहल के सबसे बुरे पलक की कमी है " क्योंकि उन्हें इसके लिए भुगतान नहीं किया जाता है ", अंत में यह कहते हुए कि उन्हें कभी मौका नहीं मिला।

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


8

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

उदाहरण के लिए, मान लीजिए कि आप अपनी कार को मैकेनिक के पास ले जाने के लिए ले गए हैं। मैकेनिक ने चार बातें नोटिस की:

  1. दीपक की ओर जाने वाला तार भुरभुरा और खतरनाक होता है। लेकिन, विशेष रूप से लागत में वृद्धि के बिना इसे छंटनी की जा सकती है। आप उसे तार को ट्रिम करने के लिए कुछ मिनट लगने की उम्मीद करेंगे, संभवतः वह भी बिना इसे देखे।
  2. एक बोल्ट ढीला है। यह पूरी तरह से असंबंधित है, वह सिर्फ इसे देखने के लिए हुआ था। आवश्यक ड्राइवर को हथियाने और इसे कसने के लिए उसके समय का 20 सेकंड है; इसलिए, आप उससे ऐसा करने की उम्मीद करेंगे।
  3. दीपक के लिए चेसिस को फोड़ दिया जाता है, जिससे दीपक खड़खड़ होगा। इसे बदलना महंगा है। और यह आवश्यक नहीं है। इसलिए, वह आपको इसके बारे में पूछने के लिए कहता है - यदि आप "नहीं" कहते हैं, तो वह आपकी यात्रा के सारांश पर एक लिखित सिफारिश करता है।
  4. कार के नीचे काफी मात्रा में ब्रेक फ्लुइड होता है। जब तक आप किसी को रिसाव को ठीक करने की अनुमति नहीं देते हैं, तब तक आपको कार का उपयोग करने से रोकने के लिए पेशेवर के रूप में भी उसकी आवश्यकता हो सकती है ।

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

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

यह जवाब बिल्कुल वही है जो मैं करूंगा। मैं इस मुद्दे पर नजर रखने में छोटे काम नहीं कर रहा हूँ। मैं सिर्फ रिफ्लेक्टर करता हूं। मुद्दों के बैकलॉग में हर छोटे से छोटे तकनीकी ऋण को शामिल करने से मुद्दों की एक बड़ी सूची बन जाती है, जिससे उनके लिए दृश्यता हासिल करना कठिन हो जाता है, और जब तक कोई भी इस तरह के कार्य पर काम करता है, तब तक समस्या दूर हो सकती है, परिवर्तित रूप , बिगड़ गए, चले गए, या कौन जानता है कि क्या। यदि 5 मिनट लगते हैं, तो इसे ठीक करें!
ब्रैंडन

5

आप उसी तरह से करते हैं जैसे एक लॉ ऑफिस में एक क्लर्क अनैतिक व्यवहार से लड़ता है, एक फास्ट फूड वर्कर अनैतिक व्यवहार से लड़ता है, या पार्किंग प्रवर्तन अधिकारी पुलिस भ्रष्टाचार से लड़ता है।

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

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

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


2
"तकनीकी ऋण शायद ही कभी एक उद्यम की रोजगार-समाप्ति विफलता का कारण बनता है।" मुझे इतना यकीन नहीं होगा। कई सॉफ्टवेयर परियोजनाओं की विफलता के पीछे कारण एक तकनीकी ऋण है।
व्यंग्य

2
एक परियोजना एक उद्यम नहीं है, @Euphoric। मोज़िला सिर्फ इसलिए ख़राब नहीं है क्योंकि सनबर्ड ने कभी छुट्टी नहीं ली। यदि आपकी परियोजना विफल हो जाती है, तो आप उसी नियोक्ता के साथ एक नई परियोजना पर जाते हैं। यदि आपका उद्यम विफल हो जाता है, तो आपको एक नई नौकरी खोजने की आवश्यकता है।
डगएम

यह उत्तर बहुत गलत है। मैंने तकनीकी ऋण को एक उद्यम उत्पाद को नष्ट करते देखा है। और जैसा कि "तकनीकी रूप से ऋण वास्तव में आपकी समस्या नहीं है", जिसकी जिम्मेदारी सॉफ्टवेयर डेवलपर्स की नहीं, तो किसकी है?
ब्रैंडन

2

मैंने कभी ऐसे संगठन के बारे में नहीं सुना है जो यह नहीं चाहता था कि इसमें कर्मचारी भाग लें। आप कहते हैं कि आपको केवल कार्य करने के लिए भुगतान किया जाता है। मुझे पूरी तरह से संदेह है कि आपके पास सही कार्य हैं। क्योंकि आपको अच्छा सॉफ्टवेयर लिखने के लिए भुगतान किया जाता है।

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


4
क्या यह केवल आपकी राय है या आप इसे किसी तरह वापस कर सकते हैं? ओपी ("सबसे कम") स्तर पर, "ब्रेक पर कदम रखते हुए, मेरे अनुभव में" नहीं "कहना शायद ही कभी ठीक निकला। न प्रोजेक्ट के लिए, न करियर के लिए। पीछे मुड़कर मैं उन मामलों को स्पष्ट रूप से याद कर सकता हूं जब मैं एक या दो चूक गए जब वरिष्ठ सहयोगियों / लीड / मैनेजर की दृष्टि के खिलाफ "नहीं" कह रहा हूं
gnat

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

2
मैं इस पढ़ने की सलाह देता हूं, जो निम्न स्तर के देवों को
आर्थर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.