- ชีวิตการทำงานประจำวันและเส้นทางอาชีพของวิศวกรได้รับอิทธิพลอย่างมากจากการที่เงินเดือนมาจากงบประมาณ ฝ่ายขาย/การตลาด, วิจัยและพัฒนา, หรือ บำรุงรักษา
- งานวิศวกรรมที่อยู่ใต้งบฝ่ายขาย/การตลาดใกล้ชิดกับรายได้และวัดผลได้ง่าย แต่ก็อาจนำไปสู่วัฒนธรรม stack ranking และการแข่งขันภายใน
- งบวิจัยและพัฒนาจ้างวิศวกรมากที่สุดภายใต้องค์กรผลิตภัณฑ์ และให้ความสำคัญกับคุณค่าระยะยาวและการสะสมเป็นสินทรัพย์มากกว่าการทดลองระยะสั้นระดับ รายไตรมาสขึ้นไป
- งบบำรุงรักษามักถูกมองเป็นเป้าหมายของการเพิ่มประสิทธิภาพด้านต้นทุน โดยงาน sysadmin, การดูแลระบบเก่า, platform engineering บางส่วน, และงานเครื่องมือภายในอาจอยู่ในหมวดนี้
- ถ้ารู้ว่างานของตนอยู่ในงบประเภทใด ก็จะสามารถนำการเปลี่ยนแปลงบ่อยของงานสายเติบโต, การลงทุนระยะยาวของวิจัยและพัฒนา, และลำดับความสำคัญที่ต่ำของงานบำรุงรักษา ไปใช้ประกอบการตัดสินใจด้านอาชีพได้
งบประมาณสามแบบที่แบ่งงานวิศวกรรมออกจากกัน
- เงินเดือนวิศวกรรมซอฟต์แวร์มักมาจาก หนึ่งในสามงบประมาณ ใหญ่ ๆ
- ฝ่ายขาย/การตลาด
- วิจัยและพัฒนา
- บำรุงรักษา
- ลักษณะของงบประมาณส่งผลต่อ รูปแบบการทำงานประจำวัน และทิศทางอาชีพของวิศวกร
- การแบ่งแบบนี้อาจมีประโยชน์เมื่อคิดเรื่องวิสัยทัศน์อาชีพหรือการวางตำแหน่งของตัวเอง
งบฝ่ายขาย/การตลาด: ผลลัพธ์ทันทีที่วัดได้
- งานวิศวกรรมที่อยู่ในองค์กรด้านการเติบโตนั้น วัดเชิงปริมาณ ได้ค่อนข้างง่าย
- มักเห็นโครงสร้างค่อนข้างชัดว่าทำอะไรแล้วตัวเลขจะดีขึ้น
- หมวดนี้รวมบทบาทอย่าง growth engineer, sales engineer, devrel
- ทำให้ผลิตภัณฑ์เดิมขายได้ดีขึ้น
- ทำให้ผู้คนรู้จักฟีเจอร์
- และช่วยให้ผู้ซื้อรับเครื่องมือไปใช้ใน workflow ของงาน
- สิ่งที่บริษัทคาดหวังคือ ผลกระทบทันที
- ข้อดีคือดูผลตอบแทนจากการลงทุนได้ง่าย และงานเชื่อมโยงกับรายได้โดยตรง
- แต่เพราะวัดได้ง่าย การเปรียบเทียบระหว่างคนก็ง่ายตามไปด้วย
- อาจเกิด stack ranking ระหว่างพนักงาน
- และวัฒนธรรมการแข่งขันภายในอาจเข้มข้นกว่าวัฒนธรรมการร่วมกันแก้ปัญหา
- จังหวะของงานโดยทั่วไปจะเน้นระยะสั้น
- การทดลองถัดไป
- ลูกค้ารายถัดไป
- หรือการไล่ตามกระแสการตลาดถัดไป
- บริษัทมองคุณค่าของงบนี้จากตัวคูณที่เงินก้อนนั้นสร้างได้ และในกระบวนการไล่หาการเพิ่มประสิทธิภาพก็อาจเกิด ปรากฏการณ์ประตูหมุน ได้
งบวิจัยและพัฒนา: สินทรัพย์ที่สะสมมูลค่าเมื่อเวลาผ่านไป
- วิจัยและพัฒนา หรือ R&D คือพื้นที่ที่จ้างวิศวกรมากที่สุด
- โดยปกติมักอยู่ภายใต้องค์กรผลิตภัณฑ์
- ในบริษัทที่ใหญ่กว่านั้นอาจมีองค์กรวิจัยหรือองค์กรวิทยาศาสตร์จริง ๆ อยู่ด้วย
- หมวดนี้รวมบทบาทอย่าง product engineer, researcher, architect
- สร้างสิ่งที่บริษัทนำไปขาย
- หรือสำรวจสิ่งที่บริษัทอาจขายได้หากมันทำงานได้ดี
- สิ่งที่บริษัทคาดหวังคือ การเติบโต เมื่อเวลาผ่านไป
- สภาพแวดล้อมค่อนข้างสงบมากกว่า
- มองหาสมดุลระหว่างฟีเจอร์เพื่อรักษาผู้ใช้เดิมกับฟีเจอร์เพื่อดึงผู้ใช้ใหม่
- อาจเอนมาทางการเติบโตด้วยการสร้างฟีเจอร์ที่เพิ่มการ active usage หลังสมัครใช้งาน
- หรือบางครั้งก็เอนมาทางการวิจัยด้วยการสำรวจสายผลิตภัณฑ์ใหม่
- ในบริษัทที่มีแผนกวิจัยอย่างจริงจัง ก็มีคนที่ทำงานกับไอเดียที่อาจยังไม่กลายเป็นผลิตภัณฑ์ไปอีกหลายปี
- แท้จริงแล้ววิจัยและพัฒนาเป็นการจับ สองงบประมาณที่ต่างกัน มาอยู่ในหมวดเดียวกัน
- การพัฒนาและการวิจัยนั้นต่างกัน
- แต่จุดร่วมคือการโฟกัสที่ ผลลัพธ์ระยะยาว
- ช่วงเวลาสั้นที่สุดที่ให้ความสำคัญมักเป็นระดับรายไตรมาส
- งานของวิศวกรถูกออกแบบให้กลายเป็นสินทรัพย์และสร้างคุณค่าไปอีกหลายปีข้างหน้า
- การทดลองที่สั้นกว่านั้นเป็นเพียงก้าวรองรับในกระบวนการนี้
- แม้วัดผลได้ยาก แต่บริษัทมองงานนี้เป็น การลงทุน
- โดยตั้งอยู่บนสมมติฐานว่ายิ่งผลิตภัณฑ์ดีขึ้น ยอดขายและอัตราการคงอยู่ก็จะดีขึ้นตาม
งบบำรุงรักษา: ต้นทุนที่อยากลดลง
- งานบำรุงรักษาโดยมากถูกดูดรวมเข้าไปในงานพัฒนามาโดยตลอด
- สิ่งที่งบประเภทนี้ต้องการคือ การเพิ่มประสิทธิภาพด้านต้นทุน
- sysadmin, คนที่คอยดูแลให้ระบบเก่ายังทำงานต่อไป, และบางครั้ง platform engineer อยู่ในหมวดนี้
- บริษัทมองงานนี้เป็นต้นทุนล้วน ๆ และพยายามทำให้เหลือน้อยที่สุด
- ในหลายบริษัท บทบาทด้านบำรุงรักษากระจายปนอยู่ในงานพัฒนาผลิตภัณฑ์
- เป็นงานที่ไม่ค่อยได้รับการประเมินความสำคัญ
- แต่สุดท้ายถ้ามีใครเดือดร้อนมากพอก็จะมีคนมาจัดการ
- บางครั้งบริษัททำเหมือนว่าการให้เวลาแก่วิศวกรเพื่อจัดการ NFR หรือ ข้อกำหนดที่ไม่ใช่เชิงหน้าที่ เป็นสวัสดิการพิเศษ
- เช่น การให้เวลา 2 วันในแต่ละสปรินต์เพื่อจัดการงานน่ารำคาญต่าง ๆ
- การสร้างเครื่องมือภายในก็อาจอยู่ในหมวดนี้
- มีแดชบอร์ดแอดมินที่ช่วยให้บริษัทดำเนินงานได้
- แต่ก็มักไม่ได้รับลำดับความสำคัญมากพอ
ตำแหน่งของงบประมาณส่งสัญญาณอะไรต่อการตัดสินใจด้านอาชีพ
- งานที่อยู่ในงบประเภทใดเป็นตัวกำหนด ประสบการณ์ในแต่ละวัน ของวิศวกร
- งานสายเติบโตวัดผลได้และเปลี่ยนแปลงบ่อย
- งานวิจัยสงบกว่าแต่ผลลัพธ์ไม่ชัดเจน
- งานพัฒนาได้รับการให้คุณค่าและสะสมต่อยอดไปตามเวลา
- งานบำรุงรักษาถูกปฏิบัติราวกับเป็นสิ่งที่ตัดทิ้งได้ทุกเมื่อ
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ไม่ใช่แค่ต้องรู้ว่าเงินเดือนของคุณมาจากงบประมาณหมวดไหน แต่การรู้ว่าองค์กรประเมินคุณค่าของ การพัฒนาซอฟต์แวร์ อย่างไรก็ส่งผลอย่างมากต่ออาชีพเช่นกัน
ถ้าบริษัทเป็นบริษัทคอนซัลต์ที่ขายเวลาพัฒนา ความสามารถด้านความสัมพันธ์กับลูกค้าและความสามารถในการสร้างซอฟต์แวร์ที่พอใช้ได้อย่างรวดเร็วจะได้รับการประเมินค่า ส่วนถ้าเป็นบริษัทผลิตภัณฑ์ที่ขายผลิตภัณฑ์ซอฟต์แวร์ ความสามารถในการสร้างและดำเนินงานซอฟต์แวร์จะได้รับการประเมินค่า
ถ้าเป็นธุรกิจอื่นที่มีซอฟต์แวร์เป็นส่วนหนึ่งหรือถูกขับเคลื่อนด้วยซอฟต์แวร์ ความสามารถในการส่งมอบภายในงบประมาณจะได้รับการประเมินค่า แต่ยากที่จะได้เป็นตัวเอกบนเวที
ที่น่าสนใจคือ การแบ่งแบบนี้สอดคล้องกับสามหมวดที่ผู้เขียนพูดถึงพอดี: คอนซัลติ้งสอดคล้องกับฝ่ายขาย/การตลาด, ผลิตภัณฑ์สอดคล้องกับวิจัยและพัฒนา, ที่เหลือสอดคล้องกับการบำรุงรักษา
ตอนเป็นวิศวกรอาวุโสในสตาร์ทอัพซอฟต์แวร์ ผมได้รับการปฏิบัติแบบดาวเด่น มีสต็อกออปชัน และมีวัฒนธรรมออฟฟิศอย่างที่คาดหวังได้ ส่วนตอนเป็นคอนซัลแตนต์อาวุโสในบริษัทคอนซัลติ้ง IT ผมต้องเป็นเหมือนพนักงานขายที่ทำ PowerPoint ได้ดีมากกว่า
ต้องทำให้ชั่วโมงที่เรียกเก็บเงินได้มากที่สุด และห้ามทำโปรเจกต์ให้เสร็จเร็วหรือจบด้วยโค้ดน้อยที่สุด
คงพอเดาได้ว่าตอนนี้ผมอยู่ที่ไหน
เรื่องนี้ไม่ใช่สิ่งที่ซื้อเป็นผลิตภัณฑ์สำเร็จรูปได้ โดยปกติจะเป็นรูปแบบที่ต้องปรับแต่งหลายระบบอย่างหนักแล้วฝืนเชื่อมเข้าด้วยกัน และหลายครั้งก็ไม่ได้ถูกออกแบบมาตั้งแต่แรกให้ทำงานร่วมกัน
แต่ละบริษัทก็มีวิธีต่างกัน
ผมสนุกกับงานนี้ และถนัดการคิดถึงระบบโดยรวมที่ข้ามหลายแผนก
การจะฝ่าปัญหาไปได้ต้องอาศัยความรู้เรื่องการเมืองภายในด้วย และตรงจุดนั้นเองที่คุณค่าของผมเกิดขึ้น
ในฐานะโปรแกรมเมอร์ผมก็พอใช้ได้ แต่ยังไม่ถึงระดับความเชี่ยวชาญของคนที่ยึดงานโปรแกรมมิงเป็นอาชีพ
ในอีกสองกรณี คุณจะกลายเป็นต้นทุนที่ควรถูกลดให้น้อยที่สุดหรือตัดออก
คุณจะกลายเป็นสินทรัพย์ที่สร้างรายได้ก็ต่อเมื่อคุณทำผลิตภัณฑ์หลักของบริษัทเท่านั้น
ผมก็เคยพลาดแบบนั้น และถูกเรียกเข้าประชุม ถูกถามว่า “เป็นอย่างไรบ้าง” แล้วทันทีหลังจากนั้นก็ได้ยินว่า “ไม่ต้องลงรายละเอียดนะ”
การทำงานในข้อ 3 คือการสร้างวิธีแก้ที่น่าเบื่อและถูกลืม และคุณอาจลงเอยด้วยการสร้างวิธีแก้ที่แม้จะสมเหตุสมผลทางเทคนิค แต่เป็นการฆ่าตัวตายทางการเมือง
ตัวอย่างเช่น ถ้าทำงานใน ผู้ผลิตฮาร์ดแวร์ ไม่ใช่แค่ไม่ได้เป็นตัวเอก แต่ยังยากที่จะได้รับความเคารพด้วยซ้ำ
บุคลากรซอฟต์แวร์ถูกมองเป็นต้นทุน และเป็นต้นทุนที่บริษัทไม่อยากจ่ายถ้าเลี่ยงได้
ต่อให้ส่งมอบตรงเวลาและใช้งบน้อยกว่าที่กำหนด ก็ไม่ได้ทำให้โดดเด่น แต่กลับยิ่งหายไปจากความสนใจ
ผมเข้าใจได้ยากกับคำกล่าวที่ว่าในวัฒนธรรมเทคโนโลยีสมัยใหม่ งานบำรุงรักษา มักอยู่ท้ายสุดของรายการเสมอ ถูกตัดงบ และไม่ได้รับงบประมาณที่เหมาะสม
ตลอด 20 ปีที่ผ่านมาผมได้ยินคำพูดแบบนั้นมาตลอดจากหลายบริษัท แต่แทบไม่เคยเห็นด้วยเลย
บริษัทต้องการฟีเจอร์ใหม่ ๆ เพื่อออกสู่ตลาดก็จริง แต่ในขณะเดียวกันก็ต้องการให้บริการทำงานได้อย่างถูกต้องด้วย
แม้ในช่วงปลดพนักงานหรือหยุดรับคน ผมก็เห็นว่าองค์กรลักษณะ SRE มักอยู่รอดได้ดีกว่าองค์กรวิจัยและพัฒนา
อย่างไรก็ตาม มีบริษัทหนึ่งที่วัฒนธรรมเปลี่ยนไปเป็นการสร้างของใหม่ไปเรื่อย ๆ และไม่ให้รางวัลกับการดูแลของเดิม ส่งผลให้เกิดการย้ายเครื่องมือภายในอย่างต่อเนื่อง การเลิกใช้งานไม่หยุด และการไมเกรตที่ค้างคาครึ่ง ๆ กลาง ๆ
เมื่อคนที่สร้างผลิตภัณฑ์ได้เลื่อนตำแหน่งแล้วก็ย้ายไปทำงานพอร์ตโฟลิโอถัดไป สิ่งที่เคยใหม่และดูดีไม่นานก็ถูกปล่อยทิ้ง และทีมใหม่ก็สร้างสิ่งทดแทนขึ้นมาอีก
ภายใน 6 ปี เครื่องมือภายในตัวหนึ่งถูกแทนที่ด้วยเครื่องมือภายในตัวใหม่ถึง 4 ครั้ง และผู้ใช้ก็กระจัดกระจายอยู่ในเครื่องมือทั้งสี่ตัว
อาจเรียกได้ว่าเป็นเพียงความล้มเหลวในการดำเนินงาน แต่การมีวัฒนธรรมที่พูดว่าธุรกิจไม่ได้มองว่างานบำรุงรักษามีคุณค่านั้นเป็นอันตรายมากและนำไปสู่การทำลายตัวเอง
สมมติว่าทุกครั้งที่นักพัฒนาเพิ่มฟีเจอร์ใหม่ จะใช้พื้นที่ดิสก์มูลค่า 1,000 ดอลลาร์ และสร้างรายได้ใหม่ 10,000 ดอลลาร์
ผู้ดูแลระบบซื้อไฟล์เซิร์ฟเวอร์ขนาดใหญ่ และสมมติว่าเซิร์ฟเวอร์ใหม่หนึ่งเครื่องราคา 500,000 ดอลลาร์
ในองค์กรที่เป็นระบบราชการ ผู้ดูแลระบบจะเรียกเก็บค่าพื้นที่ดิสก์ภายในจากนักพัฒนา และเมื่อจำเป็นต้องซื้อไฟล์เซิร์ฟเวอร์ใหม่ เงินก็เตรียมไว้แล้ว
ในองค์กรที่บริหารดีและมีความเป็นราชการน้อยกว่า ผู้บริหารจะเข้าใจว่าบิล 500,000 ดอลลาร์นั้นทำให้โครงการที่ให้ผลตอบแทน 5 ล้านดอลลาร์เป็นไปได้ และยินดีจ่าย
ในองค์กรที่บริหารผิดพลาด ผู้บริหารจะตกใจเพราะ 500,000 ดอลลาร์ดูแพงและไม่ได้ผูกกับโครงการใดโครงการหนึ่งโดยตรง ผู้ดูแลระบบจึงไปบอกคนถัดไปที่ต้องการพื้นที่ดิสก์มูลค่า 1,000 ดอลลาร์ให้จ่าย 500,000 ดอลลาร์ และอีกฝ่ายก็ปฏิเสธ
สุดท้ายผู้ดูแลระบบต้องปฏิเสธคำขอ และโน้มน้าวนักพัฒนาให้ลดการเก็บ log จาก 7 วันเหลือ 3 วัน แล้วไม่นานผู้บริหารก็เริ่มได้ยินฟีดแบ็กไม่ดีเกี่ยวกับผู้ดูแลระบบ
สภาพแวดล้อมที่อธิบายมาดูเหมือนเป็นความจริงที่ธุรกิจไม่ได้มองว่างานบำรุงรักษามีคุณค่าเสียมากกว่า
คำว่า “งานบำรุงรักษาอยู่ท้ายสุด” น่าจะเป็นการบรรยายสิ่งที่เกิดขึ้นจริงมากกว่าการเสนอว่าควรทำแบบนั้น
ผู้เขียนไม่ได้วิเคราะห์ว่าทำไมจึงเป็นเช่นนั้น หรือแนวทางอื่นจะดีกับธุรกิจหรือไม่ แต่ถ้าให้คุณค่ากับสิ่งที่ทำงานได้ถูกต้องและมีคุณภาพสูง ก็ย่อมต้องการผลลัพธ์ที่ต่างออกไป
อย่างไรก็ตาม หากมีบริษัทเพียงน้อยมากที่ทำเช่นนั้น ก็มีความเป็นไปได้สูงว่าจะมีเหตุผลเกี่ยวกับการจัดแนวผลประโยชน์อยู่เบื้องหลัง
เพราะคุณขายงานบำรุงรักษาให้ลูกค้าไม่ได้ สิ่งที่ขายได้คือฟีเจอร์เท่านั้น
ในมุมของนักพัฒนา งานบำรุงรักษาก็เป็นงานที่อยากหลีกเลี่ยงเช่นกัน
ใส่ “งานบำรุงรักษา” ลงในเรซูเม่ให้ดูโดดเด่นได้ยาก และทุกคนก็อยากเห็นผลงาน โครงการที่เปิดตัว และเทคโนโลยีสมัยใหม่
การทำให้บริการดำเนินต่อไปได้ในระดับที่ลูกค้าต้องการเป็นเรื่องที่ทุกคนให้ความสำคัญสูง
ไม่มีบริษัทไหนอยากลด SRE ลงจนระบบล่มแล้วลูกค้าหนีไป
แต่ SRE ใกล้เคียงกับงานปฏิบัติการของบริษัทแบบดั้งเดิมมากกว่า กล่าวคือเป็นฟังก์ชันที่หลีกเลี่ยงไม่ได้หากต้องให้บริการ และต่างจากงานบำรุงรักษาที่พยายามเลื่อนออกไปให้มากที่สุด
จากมุมมองนี้ งานบำรุงรักษาคือสิ่งอย่างการลดหนี้ทางเทคนิค การปรับปรุงเครื่องมือภายใน และการลดเวลาวนรอบการทดลอง ซึ่งงานเหล่านี้มักถูกประเมินค่าต่ำกว่าผลกระทบต่อผลิตภัณฑ์
บทความพูดถึงอย่างหลัง และบอกว่าการไปอยู่ในหมวดที่ 3 คือ การฆ่าตัวตายทางอาชีพ
ถ้าคุณไม่ใช่คนประเภท ‘เลื่อนตำแหน่งหรือออกไป’ การใช้เวลาในหมวดที่ 3 ก็อาจเป็นสิ่งที่พิจารณาได้
แน่นอนว่าซอฟต์แวร์เริ่มเก่าทันทีที่ถูกใช้งาน ดังนั้นคนที่คิดว่าตัวเองอยู่ในหมวดที่ 2 จริง ๆ แล้วอาจใช้เวลาส่วนใหญ่ในหมวดที่ 3 และใช้เวลาเพียงส่วนน้อยมากในหมวดที่ 2
ถึงอย่างนั้น งบประมาณก็ถูกจัดสรรปีละครั้ง หรืออย่างมากไม่กี่ครั้งต่อปี ดังนั้นหากตอนนั้นคุณอยู่ในที่ที่ถูกจัดเป็นหมวดที่ 2 คุณก็ยังอยู่ในตำแหน่งที่ดีกว่า
“ฝ่ายขาย/การตลาด” และ “วิจัยและพัฒนา” เป็นหมวดหมู่ที่เห็นได้ในรายงานประจำปีของบริษัท แต่ งานบำรุงรักษา ไม่ได้ปรากฏออกมาในลักษณะนั้น
ควรลองอ่านงบการเงินของบริษัทดู
คุณจะเห็นรายการอย่าง “ต้นทุนขาย” หรือ COGS, “ค่าใช้จ่ายทั่วไปและบริหาร” และค่าใช้จ่ายครั้งเดียวอย่างการควบรวมและซื้อกิจการ ซึ่งแต่ละรายการมีพลวัตต่างกัน และทำงานแตกต่างกันไปในแต่ละบริษัทด้วย
การเข้าใจ โครงสร้างธุรกิจ ของอุตสาหกรรมที่ตัวเองอยู่ก็สำคัญเช่นกัน
แม้ในเธรดนี้ก็มีหลายกรณีที่ตัดสินว่าบางบริษัท “ไม่ให้คุณค่า” กับวิศวกรรมซอฟต์แวร์ แต่การเปรียบเทียบบริษัทโซเชียลมีเดียที่มีอัตรากำไรขั้นต้น 70% กับบริษัท รถยนต์·การบิน ที่อยู่ราว 15–20% นั้นไร้เดียงสา
เป็นเรื่องธรรมดาที่อุตสาหกรรมหนึ่งจะจ้างวิศวกรได้มากกว่า จ่ายได้มากกว่า และให้ของแถมกับสวัสดิการได้มากกว่า
แม้ภายในบริษัทเดียวกัน ผลิตภัณฑ์และฟังก์ชันบางกลุ่มก็ได้รับการลงทุนระยะยาว ขณะที่บางกลุ่มมีมาร์จินสูงกว่ากลุ่มอื่น
เงินที่ใช้กับผลิตภัณฑ์ซอฟต์แวร์ได้จะแตกต่างกันมากตามงบประมาณ
วิศวกรควรมองการเงินของบริษัทควบคู่ไปกับการคิดถึงงานของตนเอง
บริษัทไม่ใช่องค์กรการกุศลหรือโบสถ์ แต่เป็นธุรกิจที่ต้องถ่วงดุลกระแสเงินสด รายได้ กลยุทธ์ระยะยาว และต้นทุนการพัฒนาผลิตภัณฑ์
บทความนี้ก็ดี แต่บทความของ patio11 ก็อธิบายโดยแบ่งเป็น ศูนย์ต้นทุนและศูนย์กำไร ได้ดีเช่นกัน
เขาอธิบายได้อย่างโน้มน้าวว่าทำไมจึงควรอยู่ติดกับศูนย์กำไร และถ้ายังไม่เคยอ่าน ก็มีเนื้อหาดี ๆ อื่นอีกมาก
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
กฎข้อที่ 2 คือภายในศูนย์กำไรนั้น ให้รับบทบาทที่เชื่อมโยงกับความสามารถทำกำไรอย่างต่อเนื่องได้อย่างน่าเชื่อถือ
ไม่จำเป็นต้องเป็นคนหาเงินโดยตรง แต่ต้องชัดเจนว่าถ้าผมหยุดทำงาน เงินจะได้รับผลกระทบโดยตรง
นอกเรื่องเล็กน้อย แต่ผมเคยอ่าน Serverless Handbook ที่ Swizec เขียนเมื่อหลายปีก่อนแล้วพบว่ามีประโยชน์มาก และติดตามจดหมายข่าวทางอีเมลที่รอบคอบและลึกซึ้งของเขามานาน
เขายืนหยัดอยู่ในสาย “เรียนรู้ด้วยการลงมือทำ / เรียนรู้แบบเปิดเผยต่อสาธารณะ” อย่างชัดเจน และทำได้ดีมากในการแบ่งปันกระบวนการเรียนรู้
ขอแนะนำอย่างยิ่งให้ติดตามหรือสมัครรับข่าวสาร
ในอดีต วิศวกรรมซอฟต์แวร์เคยเป็นส่วนหนึ่งของ ฟังก์ชัน IT และ IT ก็มีจุดเริ่มต้นมาจากงานบัญชี
ก่อนที่เครื่องจักรจะทำหน้าที่นี้ “คอมพิวเตอร์” เคยเป็นชื่อตำแหน่งงานของคนจริง ๆ
แม้ในปัจจุบัน สำหรับหลายธุรกิจ งานบัญชีก็ยังเป็นตัวขับเคลื่อนหลักของซอฟต์แวร์และเป็นแหล่งงบประมาณหลักอยู่
ในทางปฏิบัติมีหมวดงบประมาณอยู่สี่ประเภท
ข้อ 1 คือ R&D ซึ่งโดยทั่วไปจะมีการปฏิบัติทางภาษีและเครดิตภาษีแบบพิเศษ
ข้อ 2 คือฝ่ายขาย/การตลาด ซึ่งรวมถึงวิศวกรพรีเซลส์ และบางครั้งก็รวมงาน implementation ด้วย
ข้อ 3 คือการบำรุงรักษา ได้แก่เหล่านักพัฒนาที่แก้บั๊กและทำงานโค้ดที่ไม่ใช่ R&D ซึ่งโดยทั่วไปไม่เข้าข่ายการปฏิบัติทางภาษีหรือเครดิตแบบพิเศษ
ข้อ 4 คือ operations ในบริการโฮสติ้ง, PaaS และ SaaS ซึ่งโดยปกติจะรวมเงินเดือนของวิศวกรซอฟต์แวร์อยู่ในระดับหนึ่ง
การเข้าใจผลกระทบทางภาษีตามว่างบมาจากส่วนไหนและทำงานอะไรนั้นสำคัญมาก และจะซับซ้อนขึ้นมากเมื่อองค์กรมีขนาดใหญ่ขึ้น
มองว่าโมเดล ศูนย์กำไรเทียบกับศูนย์ต้นทุน ดีกว่า
ตามอุดมคติแล้ว ทุกแผนกควรรับผิดชอบทั้งรายได้และต้นทุน
ถ้าวัดไม่ได้ นั่นคือปัญหาของ KPI
KPI อาจถูกตั้งให้เน้นต้นทุนจนจัดแนวผิดได้ แต่ไม่ได้แปลว่าแผนกนั้นเองจะกลายเป็นศูนย์ต้นทุน
เพียงแต่ชอบที่มีการเพิ่มการแยก R&D เข้ามา
ผมมองว่าทีมที่เน้นการบำรุงรักษาก็ควรทำ R&D เพื่อลดต้นทุนการบำรุงรักษา เช่นเดียวกับทีมขายที่ดีทำ R&D เพื่อเพิ่มกำไรจากการขาย
ทั้งสองให้มุมมองที่ต่างกันและสามารถเสริมกันได้
ในบริษัทที่ผมเคยทำงานมา ไม่มีที่ไหนที่ เงินเดือนของ growth engineering มาจากงบการตลาดเลย
และก็ไม่มีสิ่งที่เรียกว่า “งบบำรุงรักษา” แยกต่างหาก ทุกอย่างเป็นเพียง R&D/วิศวกรรม
ความคาดหวังอาจแตกต่างกันมากตามทีมหรือบทบาท แต่เรื่องนั้นไม่ใช่ปัญหางบประมาณ หากขึ้นอยู่กับวิธีที่บริษัทติดตามเป้าหมาย
โดยทั่วไปคือหนึ่งในสามอย่าง: กำลังทำเงินตอนนี้, สร้างมูลค่าระยะยาว, หรือค่อย ๆ จมอยู่กับผลิตภัณฑ์เดิม