Software engineering वेतन, तीन में से किसी एक बजट से दिया जाता है

 (swizec.com)
1 पॉइंट द्वारा GN⁺ 2024-01-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें

तीन बजट

  • Software engineering का वेतन तीन में से किसी एक बजट से आता है.
  • वेतन देने वाला बजट रोज़मर्रा के काम और career trajectory को प्रभावित करता है.
  • ये तीन बजट हैं: sales/marketing, research and development, और maintenance.

Sales/marketing बजट

  • जब आप growth organization का हिस्सा होते हैं, तो परिणामों को आसानी से quantifiable और measurable बनाया जा सकता है.
  • इसमें growth engineer, sales engineer, developer relations जैसे roles आते हैं, और ये मौजूदा product की बिक्री, features की जानकारी, और tools adoption के लिए ज़िम्मेदार होते हैं.
  • यह बजट immediate impact चाहता है.
  • measurable impact होने से ROI हमेशा पता चल सकता है, और यह सीधे revenue पैदा करता है.
  • जब measurement आसान हो, तो comparison भी आसान हो जाता है, जिससे internal competition culture पैदा हो सकता है.
  • यह short-term पर केंद्रित काम होता है, जो अगले experiment, customer, या marketing trend का पीछा करता है.
  • कंपनी investment के मुकाबले return को maximize करना चाहती है, इसलिए attrition rate बढ़ सकता है.

Research and development

  • Research and development (R&D) सबसे ज़्यादा engineers को नियुक्त करता है.
  • यह product organization के अंतर्गत काम करता है, और बड़ी कंपनियों में वास्तविक research और science organizations भी होती हैं.
  • इसमें product engineer, researcher, architect जैसे roles आते हैं, जो ऐसे products बनाते या खोजते हैं जिन्हें कंपनी बेचती है या बेच सकती है.
  • यह बजट समय के साथ growth चाहता है.
  • यहाँ का माहौल अधिक शांत होता है, और maintenance तथा नए users को आकर्षित करने वाली features के बीच संतुलन खोजा जाता है.
  • जिन कंपनियों के पास सही research department होता है, वहाँ ऐसे लोग होते हैं जो उन ideas पर research करते हैं जो कई साल बाद product बन सकते हैं.
  • development और research अलग हैं, लेकिन दोनों में समानता यह है कि वे long-term परिणामों पर ध्यान देते हैं.
  • सबसे छोटी attention span एक quarter की होती है, और काम ऐसा asset बनना चाहिए जो कई वर्षों तक value दे.

Maintenance

  • Maintenance ज़्यादातर development में समा जाता है.
  • यह बजट cost optimization चाहता है.
  • इसमें system administrator, पुराने systems को बनाए रखने वाले लोग, और कभी-कभी platform engineer शामिल होते हैं.
  • कंपनी इस काम को एक pure cost मानती है और इसे कम से कम रखना चाहती है.
  • कई कंपनियों में यह काम product development में integrate कर दिया जाता है, और इसे value न बनाने वाला काम माना जाता है.
  • कंपनियाँ इस बजट को इतना नापसंद करती हैं कि engineers को NFR काम (non-functional requirements) पर समय देने को भी खास रियायत की तरह देखा जाता है.
  • internal tools बनाना भी इस category में आ सकता है, जैसे administrative dashboard, जो कंपनी को चलाए रखते हैं लेकिन उन्हें priority नहीं मिलती.

यह क्यों महत्वपूर्ण है

  • आप जिस बजट के तहत काम करते हैं, उसके आधार पर आपका रोज़मर्रा का काम बदल जाता है.
  • growth measurable होता है और उसमें volatility ज़्यादा होती है.
  • research शांत होता है और ambiguity अधिक होती है.
  • development value पैदा करता है और समय के साथ build होता है.
  • maintenance हमेशा कटौती का लक्ष्य बना रहता है.

GN⁺ की राय

  • यह लेख software engineers को अपने career की planning करने और यह समझने में मदद करता है कि कंपनी के भीतर उनके काम को कैसे देखा जाता है.
  • हर बजट की विशेषताओं को समझकर engineers यह तय कर सकते हैं कि उनका काम long-term value बना रहा है या short-term performance पर केंद्रित है.
  • यह insight engineers के लिए अपनी role को अधिक स्पष्ट रूप से समझने और career goals हासिल करने के लिए ज़रूरी strategic decisions लेने में उपयोगी है.

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

1 टिप्पणियां

 
GN⁺ 2024-01-05
Hacker News राय

  • सॉफ़्टवेयर डेवलपमेंट के प्रति किसी संगठन का नज़रिया समझना महत्वपूर्ण है, और इसका करियर पर बड़ा प्रभाव पड़ता है।

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

  • यह समझना कठिन है कि आधुनिक टेक संस्कृति में maintenance हमेशा बजट कटौती का निशाना क्यों बनता है और उसे कम आंका जाता है।

    • नए features बनाना महत्वपूर्ण है, लेकिन features का सही तरह काम करना भी उतना ही महत्वपूर्ण है।
    • एक कंपनी में maintenance की तुलना में लगातार नई चीज़ें बनाते रहने की संस्कृति थी, जिससे internal tools बार-बार बदलते रहे।
    • maintenance को महत्व न देना business के लिए हानिकारक और आत्म-विनाशकारी है।

  • सॉफ़्टवेयर इंजीनियरिंग को "मूल्यहीन" मानना इस उद्योग के business को न समझने जैसा है।

    • अन्य उद्योगों की तुलना में बजट और profit margins अलग होते हैं, इसलिए engineers को hire और compensate करने के तरीक़े भी अलग होते हैं।
    • कंपनी के भीतर अलग-अलग product lines और functions के अनुसार long-term investment अलग होता है, और इसका असर सॉफ़्टवेयर products के बजट पर पड़ता है।

  • किसी कंपनी की annual report में "Sales and Marketing" और "Research and Development" आमतौर पर दिखते हैं, लेकिन "Maintenance" का उल्लेख बहुत कम होता है।

    • कंपनी के financial statements पढ़ने से अलग-अलग cost items और उनकी dynamics को समझा जा सकता है।

  • patio11 का ब्लॉग cost centers और profit centers के बीच अंतर करता है, और यह तर्क देता है कि profit center का हिस्सा होना महत्वपूर्ण है।

    • उस ब्लॉग में और भी बहुत सी उपयोगी जानकारी दी गई है।

  • बजट को बाँटने की चार श्रेणियाँ होती हैं:

    1. Research and Development: इस पर विशेष tax benefits और tax credits लागू होते हैं।
    2. Sales/Marketing: इसमें sales engineers और implementation शामिल हो सकते हैं।
    3. Maintenance: इसमें bug fixes और ऐसा code work करने वाले developers शामिल होते हैं जिन पर विशेष tax benefits लागू नहीं होते।
    4. hosting service/PaaS/SaaS में operations में सॉफ़्टवेयर engineers के वेतन का एक स्तर शामिल होता है।
    • tax के नज़रिए से यह समझना महत्वपूर्ण है कि कौन-सा काम किस बजट से किया जाता है।

  • Swizec ने "Serverless Handbook" नाम की एक उपयोगी किताब लिखी है और लंबे समय से एक जानकारीपूर्ण email newsletter भी लिखते आ रहे हैं।

    • वे "करके सीखना / सार्वजनिक रूप से सीखना" का समर्थन करते हैं और सीखी हुई बातों को साझा करने में बेहद अच्छे हैं।

  • बजट को "buckets" कहना रूपक की तरह लगता है, लेकिन लेख में इसका उपयोग शाब्दिक अर्थ में किया गया है।

    • maintenance role को product development में शामिल किया जाता है, और हर sprint में maintenance के लिए दिया गया समय सीमित होता है।
    • growth और developer relations engineers आमतौर पर product organization का हिस्सा होते हैं।

  • ऐतिहासिक रूप से सॉफ़्टवेयर इंजीनियरिंग, IT function का एक हिस्सा थी, और इसकी जड़ें accounting में हैं।

    • आज भी कई businesses में accounting ही सॉफ़्टवेयर के पीछे की मुख्य प्रेरक शक्ति है।

  • अनुभव के आधार पर growth engineering की salary कभी marketing budget से नहीं आई, और "maintenance" budget जैसी कोई चीज़ भी नहीं रही।

    • सब कुछ R&D/engineering budget में शामिल होता है; expectations टीम/role के अनुसार अलग हो सकती हैं, लेकिन यह बजट का नहीं बल्कि भूमिका का मामला है।