HN से पूछें: आपने जिस सबसे बेकार प्रोजेक्ट में हिस्सा लिया, वह कौन-सा था?

 (news.ycombinator.com)
1 पॉइंट द्वारा GN⁺ 2024-04-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें

अनावश्यक काम को लेकर चिंता

  • कंपनी के pipeline automation विभाग में काम करने वाले एक कर्मचारी का अनुभव.
  • टीम ने maintenance समस्याओं के कारण एक internal tool को बंद करने का फैसला किया, और अगर किसी दूसरी टीम को ज़रूरत पड़े तो इस tool के implementation को automate करने के लिए एक pipeline बनाई.
  • इस महीने टीम के एक सदस्य ने automation में सुधार की संभावना देखी, इसलिए उस कर्मचारी को पुराने tool में बदलाव लागू करने के लिए चुना गया.

pipeline automation का विरोधाभास

  • बदलाव लागू करने के बाद, उसी टीम के एक व्यक्ति द्वारा विस्तार से मांगे गए adjustments की वजह से pull request approve नहीं हुई.
  • इन adjustments का उद्देश्य बहुत ही दुर्लभ scenarios में pipeline automation की resilience बढ़ाना था.
  • लेकिन उसी हफ्ते टीम लीडर ने दूसरी टीमों को सूचित किया कि internal tool को बंद कर दिया गया है और अब उसका उपयोग नहीं किया जाना चाहिए.

अर्थहीन काम का बोझ

  • बंद किए जा चुके tool के उपयोग को implement करने वाली pipeline automation की ज़रूरत पर सवाल.
  • जब tool बंद हो चुका है, तो ऐसी automation में adjustments की ज़रूरत क्यों है जिसे कोई इस्तेमाल ही नहीं करेगा, इस पर सवाल.
  • ऐसे काम में लगाए जाने को लेकर उलझन, जो समय की बर्बादी जैसा लगता है.

GN⁺ की राय

  • यह स्थिति संगठन के भीतर communication की कमी और process management की समस्याओं को उजागर करती है. एक तरफ tool के बंद होने की आधिकारिक सूचना दी गई, लेकिन दूसरी तरफ उसी tool पर सुधार का काम अब भी चल रहा है.
  • यह समस्या resources की बर्बादी करती है और कर्मचारियों के बीच confusion और असंतोष पैदा कर सकती है. इससे कर्मचारियों का morale गिर सकता है और लंबे समय में कंपनी की productivity पर नकारात्मक असर पड़ सकता है.
  • ऐसी स्थिति से बचने के लिए project की स्थिति और उसकी प्राथमिकता पर स्पष्ट दिशानिर्देश ज़रूरी हैं, और सभी संबंधित टीमों के साथ लगातार communication महत्वपूर्ण है. साथ ही, काम की priority तय करने की प्रक्रिया में strategic approach की भी ज़रूरत है.
  • यह मामला एक सामान्य समस्या को दिखाता है जो दूसरी organizations या teams में भी हो सकती है, और इसके ज़रिए संगठन अपने processes की दोबारा समीक्षा कर उन्हें बेहतर बनाने का अवसर पा सकते हैं.
  • ऐसी स्थिति का सामना कर रहे कर्मचारियों के लिए यह महत्वपूर्ण है कि वे समय-समय पर यह जांचें कि उनकी मेहनत किसी सार्थक और उपयोगी दिशा में लग रही है या नहीं, और ज़रूरत पड़ने पर वरिष्ठ प्रबंधन या HR विभाग के सामने यह मुद्दा उठाएं.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-06
Hacker News राय

  • एक ERP सिस्टम डेवलपमेंट का अनुभव

    • 15 सालों में अलग-अलग डेवलपर्स द्वारा विकसित किए गए इन-हाउस ERP सिस्टम पर काम करने का अनुभव.
    • सिस्टम कंपनी का मुख्य आधार था, लेकिन मैनेजमेंट ने सिस्टम को समस्याओं की जड़ बताया.
    • नई मैनेजमेंट ने इसे एक industry-standard solution से बदलने को आगे बढ़ाया.
    • CTO और लेखक ने ज़ोर देकर कहा कि प्रोजेक्ट बजट से बाहर जाएगा और विफल होगा, लेकिन मैनेजमेंट ने vendor की बात पर भरोसा कर प्रोजेक्ट आगे बढ़ाया.
    • vendor को प्रोजेक्ट के पैमाने की समझ नहीं थी, फिर भी उसने महत्वपूर्ण features हटाते हुए आत्मविश्वास दिखाया.
    • आखिरकार 5 साल बाद, लाखों डॉलर बर्बाद करने के बाद प्रोजेक्ट विफल हो गया.

  • smart energy meter बिज़नेस में प्रवेश की कोशिश

    • एक बड़ी media company में smart energy meter बिज़नेस में उतरने की कोशिश का अनुभव.
    • हज़ारों मीटर पहले ही खरीदे, branding किए और warehouse में रखे जा चुके थे.
    • API डेवलपमेंट पूरा हो चुका था, UI में समस्याएँ थीं और उसे ठीक करने की ज़रूरत थी.
    • marketing launch के लिए लाखों डॉलर का बजट तैयार था, लेकिन launch वाले दिन कंपनी के board ने brand image और failure risk का हवाला देकर launch रद्द कर दिया.

  • एक निरर्थक प्रोजेक्ट का अनुभव

    • कंपनी में हर hallway में "EnGUAGEment meter" लगाकर कर्मचारियों के मूड दिखाने वाला सिस्टम विकसित किया गया.
    • CEO के जन्मदिन पर participation rate बढ़ाना पड़ता था.
    • आखिर में यह रोज़ाना सिर्फ 30-40% participation rate तक ही पहुँच पाया.

  • एक बड़े retailer का network access control प्रोजेक्ट

    • Cisco router ACL बनाने का काम सौंपा गया था, लेकिन लगता है कि प्रोजेक्ट बीच में ही रद्द हो गया.
    • लेखक ने automated system बनाया, लेकिन उसके बाद प्रोजेक्ट की प्रगति के बारे में कभी कुछ नहीं सुना.

  • internal tool का उपयोग बंद कराने के लिए जानबूझकर performance घटाना

    • VP के अनुरोध पर पुराने internal tool को जानबूझकर धीमा बनाने का काम किया.
    • fake error messages और random delays जोड़कर users की शिकायतें बढ़ाने की कोशिश की गई.

  • एक SaaS कंपनी का AWS पर emergency migration

    • acquisition के बाद AWS migration का निर्देश मिला, लेकिन इससे पैदा हुई ऊँची लागत के कारण अंततः फिर से data center में लौटना पड़ा.

  • न्यूज़ीलैंड की एक software और hardware कंपनी का unit test refresh प्रोजेक्ट

    • 10 million dollar के बजट के साथ unit tests को refresh करने का लक्ष्य था, लेकिन प्रोजेक्ट ने बीच में दिशा बदलकर packet inspection tool डेवलपमेंट का रूप ले लिया.
    • प्रोजेक्ट लीड बीच में ही नौकरी छोड़ गया, और नतीजा बेकार रहा, फिर भी कंपनी ने प्रोजेक्ट को सफल माना.

  • यूनिवर्सिटी की programming class में simulator डेवलपमेंट

    • पहली class के बाद लेखक प्रोफेसर से simulator डेवलपमेंट के बारे में बात करना चाहता था, लेकिन प्रोफेसर ने कहा कि class attendance माफ़ कर देंगे और A grade देंगे.
    • semester के अंत में प्रोफेसर को यह वादा याद नहीं था, और simulator दिखाने के बाद ही grade बदला गया.

  • Magic the Gathering online play site डेवलपमेंट

    • मौजूदा विकल्पों से बेहतर site विकसित की गई, लेकिन copyright issues के कारण उसे जारी नहीं किया गया.

  • satellite control board test equipment डेवलपमेंट

    • satellite control board की testing के लिए equipment विकसित किया गया, लेकिन program रद्द हो गया और equipment का उपयोग किए बिना उसे फेंक दिया गया.