เงินเดือนวิศวกรรมซอฟต์แวร์มาจากหนึ่งในสามงบประมาณ

 (swizec.com)
1 คะแนน โดย GN⁺ 2024-01-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

สามงบประมาณ

  • เงินเดือนของวิศวกรรมซอฟต์แวร์มาจากหนึ่งในสามงบประมาณ
  • งบประมาณที่ใช้จ่ายเงินเดือนส่งผลต่อทั้งงานประจำวันและเส้นทางอาชีพ
  • งบประมาณทั้งสามคือ ฝ่ายขาย/การตลาด, การวิจัยและพัฒนา, และการบำรุงรักษา

งบฝ่ายขาย/การตลาด

  • เมื่อสังกัดองค์กรสายการเติบโต ผลลัพธ์มักวัดเชิงปริมาณและตรวจวัดได้ง่าย
  • ตัวอย่างเช่น growth engineer, sales engineer, developer relations ซึ่งดูแลงานขายผลิตภัณฑ์เดิม การแจ้งฟีเจอร์ และการผลักดันการนำเครื่องมือไปใช้
  • งบประมาณนี้ต้องการผลกระทบทันที
  • ผลกระทบที่วัดได้ทำให้รู้ ROI ได้เสมอ และสร้างรายได้โดยตรง
  • เมื่อวัดง่าย การเปรียบเทียบก็ง่ายตามไปด้วย จนอาจก่อให้เกิดวัฒนธรรมการแข่งขันภายใน
  • งานมักโฟกัสระยะสั้น ไล่ตามการทดลองถัดไป ลูกค้ารายถัดไป หรือกระแสการตลาดล่าสุด
  • บริษัทต้องการเพิ่มผลตอบแทนจากการลงทุนให้สูงสุด จึงอาจทำให้อัตราการย้ายงานสูงขึ้น

การวิจัยและพัฒนา

  • การวิจัยและพัฒนา (R&D) จ้างวิศวกรมากที่สุด
  • มักทำงานภายใต้องค์กรผลิตภัณฑ์ และบริษัทใหญ่บางแห่งมีองค์กรวิจัยและวิทยาศาสตร์โดยเฉพาะ
  • ครอบคลุม product engineer, researcher, architect เป็นต้น โดยทำหน้าที่สร้างหรือสำรวจผลิตภัณฑ์ที่บริษัทขายอยู่หรืออาจขายได้ในอนาคต
  • งบประมาณนี้ต้องการการเติบโตเมื่อเวลาผ่านไป
  • สภาพแวดล้อมมักสงบกว่า และพยายามหาสมดุลระหว่างการดูแลรักษากับฟีเจอร์สำหรับดึงดูดผู้ใช้ใหม่
  • บริษัทที่มีฝ่ายวิจัยจริงจังจะมีคนทำวิจัยกับแนวคิดที่อาจกลายเป็นผลิตภัณฑ์ในอีกหลายปีข้างหน้า
  • งานพัฒนากับงานวิจัยไม่เหมือนกัน แต่มีจุดร่วมคือมุ่งไปที่ผลลัพธ์ระยะยาว
  • ช่วงความสนใจที่สั้นที่สุดคือระดับไตรมาส และงานที่ทำต้องกลายเป็นสินทรัพย์ที่สร้างคุณค่าได้เป็นเวลาหลายปี

การบำรุงรักษา

  • งานบำรุงรักษาส่วนใหญ่ถูกรวมกลืนเข้าไปในงานพัฒนา
  • งบประมาณนี้ต้องการการเพิ่มประสิทธิภาพต้นทุน
  • ครอบคลุมผู้ดูแลระบบ คนที่ดูแลระบบเก่า และบางครั้งรวมถึง platform engineer
  • บริษัทมองงานประเภทนี้เป็นต้นทุนล้วน ๆ และพยายามลดให้เหลือน้อยที่สุด
  • ในหลายบริษัท งานนี้ถูกรวมไว้ในงานพัฒนาผลิตภัณฑ์ และถูกมองว่าเป็นงานที่ไม่มีคุณค่า
  • บริษัทไม่ชอบงบประมาณก้อนนี้มากจนการให้วิศวกรใช้เวลากับงาน NFR (ข้อกำหนดที่ไม่ใช่เชิงหน้าที่) ถูกมองเหมือนเป็นสิทธิพิเศษ
  • การสร้างเครื่องมือภายในก็อาจอยู่ในหมวดนี้ได้ เช่น แดชบอร์ดสำหรับงานดูแลระบบที่ช่วยให้บริษัทเดินต่อได้ แต่ไม่เคยได้ลำดับความสำคัญสูง

ทำไมเรื่องนี้จึงสำคัญ

  • งานประจำวันจะแตกต่างกันไปตามงบประมาณที่คุณสังกัด
  • สายการเติบโตวัดผลได้และมีความผันผวนสูง
  • งานวิจัยนิ่งกว่า แต่ก็คลุมเครือกว่า
  • งานพัฒนาสร้างคุณค่าและค่อย ๆ สั่งสมไปตามเวลา
  • งานบำรุงรักษามักเป็นเป้าหมายของการลดงบอยู่เสมอ

ความเห็นของ GN⁺

  • บทความนี้ช่วยให้วิศวกรซอฟต์แวร์วางแผนอาชีพของตนเอง และเข้าใจว่างานของตนถูกมองอย่างไรภายในบริษัท
  • เมื่อเข้าใจลักษณะของแต่ละงบประมาณ วิศวกรจะประเมินได้ว่างานของตนกำลังสร้างคุณค่าระยะยาว หรือเน้นผลลัพธ์ระยะสั้น
  • มุมมองเหล่านี้มีประโยชน์ต่อการทำความเข้าใจบทบาทของตนให้ชัดเจนขึ้น และช่วยตัดสินใจเชิงกลยุทธ์เพื่อไปให้ถึงเป้าหมายอาชีพ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-05
ความเห็นจาก Hacker News

  • การเข้าใจมุมมองขององค์กรที่มีต่อการพัฒนาซอฟต์แวร์เป็นเรื่องสำคัญ และส่งผลอย่างมากต่อเส้นทางอาชีพ

    • ในบริษัทที่ปรึกษา ความสัมพันธ์กับลูกค้าและทักษะการพัฒนาซอฟต์แวร์พื้นฐานเป็นสิ่งที่ถูกให้ความสำคัญ
    • ในบริษัทผลิตภัณฑ์ ความสามารถในการสร้างและดูแลซอฟต์แวร์ให้ทำงานได้จริงเป็นสิ่งสำคัญ
    • ในบริษัทประเภทอื่นที่ซอฟต์แวร์มีบทบาทเสริม ความสามารถในการส่งมอบงานให้อยู่ในงบประมาณเป็นสิ่งสำคัญ และมักเป็นงานที่ไม่ค่อยได้รับความสนใจ

  • ไม่เข้าใจวัฒนธรรมเทคโนโลยีสมัยใหม่ที่มองว่างานบำรุงรักษาเป็นเป้าหมายของการตัดงบอยู่เสมอและประเมินคุณค่าต่ำเกินไป

    • การพัฒนาฟีเจอร์ใหม่สำคัญก็จริง แต่การทำให้ฟีเจอร์ทำงานได้อย่างถูกต้องก็สำคัญเช่นกัน
    • เคยอยู่ในบริษัทแห่งหนึ่งที่มีวัฒนธรรมให้สร้างของใหม่ต่อเนื่องมากกว่าบำรุงรักษา ซึ่งนำไปสู่การเปลี่ยนเครื่องมือภายในอยู่ตลอดเวลา
    • การไม่ให้ความสำคัญกับงานบำรุงรักษาเป็นเรื่องที่ทำร้ายธุรกิจและมีลักษณะทำลายตัวเอง

  • การประเมินว่าวิศวกรรมซอฟต์แวร์ "ไม่มีคุณค่า" สะท้อนว่าไม่เข้าใจธุรกิจของอุตสาหกรรมนี้

    • เมื่อเทียบกับอุตสาหกรรมอื่น งบประมาณและอัตรากำไรแตกต่างกัน จึงทำให้วิธีจ้างและตอบแทนวิศวกรแตกต่างกันไป
    • การลงทุนระยะยาวแตกต่างกันตามสายผลิตภัณฑ์และฟังก์ชันอื่นภายในบริษัท ซึ่งส่งผลต่อการจัดงบให้กับผลิตภัณฑ์ซอฟต์แวร์

  • ในรายงานประจำปีของบริษัท มักพบคำว่า "การขายและการตลาด" กับ "การวิจัยและพัฒนา" แต่แทบไม่ค่อยเห็นการกล่าวถึง "การบำรุงรักษา"

    • การอ่านงบการเงินของบริษัทช่วยให้เข้าใจหมวดค่าใช้จ่ายต่าง ๆ และพลวัตที่แตกต่างกันของแต่ละส่วน

  • บล็อกของ patio11 แยกความแตกต่างระหว่าง cost center กับ profit center และย้ำว่าการอยู่ฝั่ง profit center เป็นเรื่องสำคัญ

    • บล็อกดังกล่าวยังมีข้อมูลที่เป็นประโยชน์อีกมาก

  • มีการแบ่งงบประมาณออกเป็น 4 หมวด:

    1. การวิจัยและพัฒนา: ได้รับสิทธิประโยชน์ทางภาษีและเครดิตภาษีพิเศษ
    2. การขาย/การตลาด: อาจรวมถึง sales engineer และงาน implementation
    3. การบำรุงรักษา: นักพัฒนาที่ทำงานแก้บั๊กและงานโค้ดที่ไม่ได้รับสิทธิประโยชน์ทางภาษีพิเศษ
    4. ในบริการโฮสติ้ง/PaaS/SaaS งานปฏิบัติการรวมเงินเดือนวิศวกรซอฟต์แวร์ในระดับหนึ่งไว้ด้วย
    • การเข้าใจว่างานประเภทใดถูกจัดอยู่ในงบประมาณใดเป็นเรื่องสำคัญในมุมภาษี

  • Swizec เป็นผู้เขียนหนังสือที่มีประโยชน์ชื่อ "Serverless Handbook" และเขียนอีเมลข่าวสารที่ให้ประโยชน์มาเป็นเวลานาน

    • เขาสนับสนุนแนวคิด "เรียนรู้ผ่านการลงมือทำ / เรียนรู้แบบเปิดเผย" และโดดเด่นในการแบ่งปันสิ่งที่ได้เรียนรู้

  • การเปรียบงบประมาณเป็น "bucket" เป็นการเปรียบเปรย แต่ในบทความนี้ใช้ในความหมายตรงตัว

    • บทบาทด้านการบำรุงรักษาถูกรวมอยู่ในการพัฒนาผลิตภัณฑ์ และมีเวลาที่จัดสรรให้งานบำรุงรักษาอย่างจำกัดในแต่ละสปรินต์
    • วิศวกรด้านการเติบโตและนักพัฒนาสัมพันธ์มักอยู่ภายใต้องค์กรผลิตภัณฑ์

  • ในเชิงประวัติศาสตร์ วิศวกรรมซอฟต์แวร์เคยเป็นส่วนหนึ่งของฟังก์ชัน IT และสิ่งนี้มีรากมาจากการบัญชี

    • ทุกวันนี้ ในหลายธุรกิจ การบัญชียังคงเป็นแรงขับหลักที่อยู่เบื้องหลังซอฟต์แวร์

  • จากประสบการณ์ ไม่เคยเห็นเงินเดือนของ growth engineering มาจากงบการตลาด และก็ไม่มีสิ่งที่เรียกว่า "งบบำรุงรักษา"

    • ทุกอย่างถูกรวมอยู่ในงบ R&D/วิศวกรรม โดยความคาดหวังจะแตกต่างกันตามทีม/บทบาท แต่ไม่ใช่ประเด็นเรื่องงบประมาณ