เศรษฐศาสตร์ของทีมซอฟต์แวร์: ทำไมองค์กรวิศวกรรมส่วนใหญ่จึง ‘มองไม่เห็น’ ภาพการเงิน
(viktorcessan.com)- องค์กรวิศวกรรมส่วนใหญ่ยัง ดำเนินงานโดยไม่สามารถวัดต้นทุนและการสร้างมูลค่าในระดับทีมเป็นตัวเลขได้ ซึ่งนำไปสู่ความไร้ประสิทธิภาพทางการเงิน
- ทีมขนาด 8 คนมีต้นทุนต่อปีราว €1.04 ล้าน (เดือนละ €87,000, วันละ €4,000) ทำให้ทุกการตัดสินใจ เช่น การพัฒนาฟีเจอร์หรือการเลื่อนปรับปรุง มีผลกระทบทางการเงินอย่างชัดเจน
- ทั้งทีมแพลตฟอร์มภายในและทีมผลิตภัณฑ์สำหรับลูกค้าสามารถคำนวณ จุดคุ้มทุน และเกณฑ์การสร้างมูลค่า 3–5 เท่า ได้ แต่มีองค์กรน้อยมากที่ติดตามสิ่งนี้จริง
- วัฒนธรรมดอกเบี้ยต่ำและเน้นการเติบโต ตลอด 20 ปีที่ผ่านมา ทำให้วินัยทางการเงินอ่อนแอลง และเปลี่ยนองค์กรขนาดใหญ่กับ codebase ที่ซับซ้อนให้กลายเป็น หนี้สิน ไม่ใช่สินทรัพย์
- การมาของ LLM ทำให้ความไร้ประสิทธิภาพเชิงโครงสร้างเหล่านี้ถูกเปิดโปง และองค์กรที่ วัดต้นทุน มูลค่า และความสามารถทำกำไรของแต่ละทีมได้เชิงปริมาณ จะได้เปรียบในการแข่งขันระยะยาว
เศรษฐศาสตร์ของทีมซอฟต์แวร์: ทำไมองค์กรวิศวกรรมส่วนใหญ่จึง ‘มองไม่เห็น’ ภาพการเงิน
- วิเคราะห์เชิงตัวเลขเกี่ยวกับ โครงสร้างต้นทุนการพัฒนาซอฟต์แวร์ และ ความคุ้มค่าทางเศรษฐกิจในระดับทีม โดยชี้ว่าองค์กรส่วนใหญ่ยังดำเนินงานโดยไม่รับรู้ข้อมูลเหล่านี้
- เมื่ออิงจากทีมขนาด 8 คน จะมีต้นทุนราว €1.04 ล้านต่อปี (เดือนละ €87,000) หรือประมาณ €4,000 ต่อวัน
- ทั้งทีมแพลตฟอร์มภายในและทีมผลิตภัณฑ์สำหรับลูกค้าสามารถคำนวณปริมาณการสร้างมูลค่าที่ต้องมีเพื่อให้ จุดคุ้มทุน (break-even) ได้ แต่แทบไม่มีองค์กรใดติดตามเรื่องนี้จริง
- สภาพแวดล้อมดอกเบี้ยต่ำและวัฒนธรรมเน้นการเติบโต ในช่วง 20 ปีที่ผ่านมา ทำให้วินัยทางการเงินอ่อนแอลง และทำให้องค์กรวิศวกรรมขนาดใหญ่กับ codebase ที่ซับซ้อนถูกเข้าใจผิดว่าเป็น ‘สินทรัพย์’
- การมาของ LLM (โมเดลภาษาขนาดใหญ่) ทำให้ความไร้ประสิทธิภาพเชิงโครงสร้างนี้ปรากฏชัด และองค์กรที่วัดต้นทุนและการสร้างมูลค่าของแต่ละทีมได้อย่างชัดเจนจะสร้างความได้เปรียบในการแข่งขัน
โครงสร้างต้นทุนจริงของทีม
- ในยุโรปตะวันตก ต้นทุนรวมต่อปีของวิศวกรซอฟต์แวร์ 1 คนอยู่ที่ €120,000~€150,000 โดยเฉลี่ยราว €130,000
- รวมเงินเดือน ค่าประกันสังคม เงินบำนาญ อุปกรณ์ ค่าใช้จ่ายด้านการจัดการ และพื้นที่สำนักงาน
- ต้นทุนรวมต่อปีของทีม 8 คนคือ €1,040,000, เดือนละ €86,667, วันละ €4,000
- แม้แต่วิศวกรและผู้จัดการส่วนใหญ่ก็ไม่รู้ตัวเลขนี้ และ การตัดสินใจจัดลำดับความสำคัญก็ไม่ได้สะท้อนการรับรู้เรื่องต้นทุน
- ทุกการตัดสินใจ เช่น การพัฒนาฟีเจอร์ การเลื่อนการปรับปรุง หรือการสร้างแพลตฟอร์มใหม่ ล้วนมี ต้นทุนทางการเงินที่ชัดเจน
- ตัวอย่าง: การพัฒนาฟีเจอร์เป็นเวลา 3 สัปดาห์สำหรับผู้ใช้ 2% คือการตัดสินใจมูลค่าราว €60,000
การคำนวณจุดคุ้มทุนของทีมแพลตฟอร์มภายใน
- สมมติว่าทีมแพลตฟอร์มขนาด 8 คนรองรับวิศวกร 100 คน
- มีต้นทุนรายเดือน €87,000 และต้องสร้างมูลค่าได้เท่ากันเพื่อชดเชยต้นทุนนี้
- ต้นทุนรายเดือนต่อวิศวกร 1 คนคือ €10,800 (ชั่วโมงละ €65)
- ถ้าประหยัดเวลาได้รวม 1,340 ชั่วโมงต่อเดือน สำหรับ 100 คน (เฉลี่ยคนละ 3 ชั่วโมงต่อสัปดาห์) ก็จะถึงจุดคุ้มทุน
- นอกจากการประหยัดเวลาแบบตรง ๆ แล้ว ยังอาจมีผลในการปกป้องรายได้โดยตรงจาก การลด incident/outage เป็นต้น
- แต่ทีมส่วนใหญ่ ไม่ได้วัดตัวเลขเหล่านี้หรือนำไปใช้ในการตัดสินใจ
- เกณฑ์ความมั่นคงทางการเงินที่สมจริงคือการสร้างมูลค่า 3–5 เท่า (เดือนละ €260,000~€430,000)
- ต้องคำนึงถึงต้นทุนการดูแลรักษา/เปลี่ยนระบบ และอัตราความล้มเหลว (50–70%)
- สิ่งที่ต้องการไม่ใช่แค่ ‘จุดคุ้มทุน’ แต่คือ ความสามารถทำกำไรอย่างยั่งยืน
ตรรกะเดียวกันสำหรับทีมผลิตภัณฑ์ที่ให้บริการลูกค้า
- ทีม 8 คนที่ทำผลิตภัณฑ์สำหรับลูกค้าก็มีโครงสร้างต้นทุนเดือนละ €87,000 เช่นกัน
- หากรายได้ต่อผู้ใช้ต่อเดือนอยู่ที่ €50 จุดคุ้มทุนคือการสร้างมูลค่าเทียบเท่า ผู้ใช้ 1,740 คน และถ้าใช้เกณฑ์ 3–5 เท่า จะต้องสร้างมูลค่าเทียบเท่า ผู้ใช้ 5,000~8,700 คน
- การปรับปรุง อัตราการยกเลิกใช้งาน (churn) คือคันโยกที่ตรงที่สุด
- ตัวอย่าง: จากผู้ใช้ 50,000 คน หากมี churn 2% ต่อเดือน (1,000 คน, สูญเสีย €50,000) → หากแก้ต้นเหตุได้ ก็จะชดเชยจุดคุ้มทุนได้เป็นส่วนใหญ่
- การปรับปรุง อัตราการเปิดใช้งาน (activation) ก็สำคัญ
- หากมีผู้ใช้ใหม่ 10,000 คนต่อเดือน แต่มีเพียง 30% ที่เปิดใช้งาน → ถ้าปรับดีขึ้น 5 จุดเปอร์เซ็นต์ จะได้ผู้ใช้ที่แปลงเพิ่มอีก 500 คน และรายได้เพิ่ม €25,000
- การเพิ่ม อัตราการแปลงเป็นลูกค้า (conversion) ก็ให้ผลแบบเดียวกัน
- จากผู้ทดลองใช้ 20,000 คน หาก conversion เพิ่มจาก 4% → 4.5% จะมีผู้จ่ายเงินเพิ่มอีก 100 คน และรายได้เพิ่ม €5,000
- การปรับปรุงเพียงเล็กน้อยในหลายตัวชี้วัด เมื่อสะสมรวมกันจะสร้างผลทางการเงินขนาดใหญ่ได้ แต่ ทีมส่วนใหญ่ ไม่ได้วัดความเชื่อมโยงระหว่างตัวชี้วัดเหล่านี้กับผลลัพธ์ทางการเงิน
ทำไมจึงไม่มีการวัดผลทางการเงิน
- หลายทีมติดตามเพียง velocity, จำนวนตั๋วงาน, จำนวนฟีเจอร์, NPS, CSAT ซึ่งเป็นเพียง ตัวชี้วัดกิจกรรมหรือความรู้สึก
- สิ่งเหล่านี้ไม่ใช่ตัวแทนของตัวชี้วัดทางการเงิน แต่เป็น คนละหมวดกันโดยสิ้นเชิง
- แม้ตัวชี้วัดกิจกรรมจะดีขึ้น แต่ ผลลัพธ์ทางการเงินอาจแย่ลงได้
- จำนวนฟีเจอร์เพิ่มขึ้น → แต่อาจเป็นฟีเจอร์ที่ผิด
- engagement สูงขึ้น → แต่จำนวนผู้ใช้ที่สร้างรายได้จริงอาจลดลง
- สาเหตุที่เลือกใช้ตัวชี้วัดเหล่านี้ เพราะ วัดง่าย รายงานง่าย และแต่งผลง่าย
- ขณะที่ตัวชี้วัดทางการเงินอาจเปิดเผยความจริงที่ไม่น่าพอใจ
- องค์กรส่วนใหญ่ ไม่ได้ตั้งใจสร้างวัฒนธรรมของการวัดผลทางการเงินอย่างโปร่งใส
ฉากหลังตลอด 20 ปีที่ผ่านมา
- 2002~2011: แม้อัตราดอกเบี้ยต่ำ แต่ นักลงทุนยังหลีกเลี่ยงความเสี่ยง ทำให้ยังมีวินัยทางการเงินอยู่
- 2011~2022: การรวมกันของ ดอกเบี้ยใกล้ศูนย์ การกลับมารับความเสี่ยง และตรรกะการเติบโตแบบ SaaS
- ตลอด 11 ปี บริษัทต่าง ๆ ได้รับการให้อภัยด้วยอัตราการเติบโต แม้จะมีการเพิ่มคนอย่างรวดเร็ว ประสิทธิภาพต่ำ และจัดลำดับความสำคัญผิดพลาด
- คนรุ่นผู้นำที่เติบโตขึ้นในช่วงเวลานี้ จึงเติบโตมาในสภาพแวดล้อมที่ ไม่ถูกบังคับให้แสดงผลลัพธ์ทางการเงิน
- ดังนั้นแม้ต้นทุนเงินทุนจะสูงขึ้นหลังปี 2022 แต่ พฤติกรรมก็ไม่ได้ปรับตามโดยอัตโนมัติ
หนี้สินขององค์กรวิศวกรรมที่ถูกเข้าใจผิดว่าเป็น ‘สินทรัพย์’
- codebase ขนาดใหญ่และองค์กรวิศวกรรมขนาดใหญ่ถูกมองว่าเป็น สินทรัพย์ (asset) มาโดยตลอด
- เช่น business logic ที่สะสมไว้ รากฐานทางเทคโนโลยี และความสามารถขององค์กร
- แต่ในความเป็นจริง มันคือโครงสร้างแบบ หนี้สิน (liability) ที่สะสมทั้งภาระการบำรุงรักษา ต้นทุนการประสานงาน และความล่าช้าในการตัดสินใจ
- เมื่อความซับซ้อนเพิ่มขึ้น ผลิตภาพจะลดลง ต้นทุนสูงขึ้น และรายได้หยุดนิ่ง
- ในอดีต สภาพแวดล้อมดอกเบี้ยต่ำช่วย ปกปิด หนี้สินนี้ไว้
-
ความจริงที่ LLM เปิดเผย
- นักพัฒนา Nathan Cavaglione ใช้ LLM agent เพื่อ โคลนฟีเจอร์หลักของ Slack ได้ 95% ภายใน 14 วัน
- ขณะที่ Slack ใช้วิศวกรหลายพันคนพัฒนามานานกว่า 10 ปี และลงทุนไปหลายพันล้านยูโร
- Nathan สร้างผลิตภัณฑ์คล้ายกันได้ในเวลาสั้น โดย ไม่มีความซับซ้อนขององค์กร สถาปัตยกรรมเดิม หรือค่าใช้จ่ายด้านการประสานงาน
- สิ่งนี้แสดงให้เห็นว่า สมมติฐานที่ว่าขนาด ความซับซ้อน และ code ที่สะสมไว้ขององค์กรขนาดใหญ่คือความได้เปรียบในการแข่งขันนั้นใช้ไม่ได้อีกต่อไป
- แม้ code ที่สร้างด้วย LLM จะยังมีปัญหาเรื่องการดูแลรักษา แต่ในสภาพแวดล้อม agent-to-agent ก็ยังได้เปรียบกว่าการดูแลรักษาโดยมนุษย์ในแง่ต้นทุนและความเร็ว
เงื่อนไขขององค์กรที่จะนำหน้าในอนาคต
- หัวใจของความสามารถในการแข่งขันคือ ไม่ใช่เทคโนโลยี แต่คือความสามารถในการวิเคราะห์
- องค์กรที่เข้าใจ ต้นทุน มูลค่า และ threshold ของความสามารถทำกำไร ของแต่ละทีมอย่างชัดเจน จะได้เปรียบเชิงโครงสร้าง
- องค์กรเหล่านี้จะสามารถทำสิ่งต่อไปนี้ได้
- ตัดสินใจ Build vs Buy บนพื้นฐานเศรษฐศาสตร์ที่แท้จริง
- ระบุ ทีมที่อยู่ต่ำกว่าขีดจำกัดความสามารถทำกำไร
- วัดเชิงปริมาณ มูลค่าที่สูญเสียจากความล่าช้า เพื่อปรับลำดับความสำคัญ
- ปัจจุบันองค์กรส่วนใหญ่ยังขาดทั้ง โครงสร้างพื้นฐานการวัดผล การไหลของข้อมูล และพฤติกรรมการใช้งาน
- การสร้างสิ่งเหล่านี้อาจไม่สบายใจ แต่จำเป็น
- เพราะอาจค้นพบว่าทีมใช้เวลาทั้งไตรมาสไปกับงานที่ ไม่เชื่อมโยงกับผลลัพธ์ทางการเงินเลย
- ในอดีต ดอกเบี้ยต่ำและตรรกะเน้นการเติบโตยังพอรองรับสิ่งนี้ได้ แต่ในสภาพแวดล้อมที่ AI ทำให้ต้นทุนการพัฒนาลดฮวบ และนักลงทุนเรียกร้องผลลัพธ์ทางการเงินมากขึ้น มันจะไม่ยั่งยืนอีกต่อไป
- องค์กรที่มีนิสัย ตั้งคำถามและวัดความคุ้มค่าทางเศรษฐกิจในระดับทีมอย่างชัดเจน จะสะสมความได้เปรียบในการแข่งขันแบบทบต้นเมื่อเวลาผ่านไป
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ประเด็นสำคัญของบทความนี้คือ สิ่งที่ยากไม่ใช่การเขียนโปรแกรมเอง แต่คือการค้นหาให้เจอว่าควรเขียนอะไรต่างหาก
ในความเป็นจริง งานส่วนใหญ่คือการลองสร้างสิ่งที่ผิดก่อนแล้วค่อยเปลี่ยนใหม่หลายรอบเพื่อสำรวจพื้นที่ของปัญหา
การเขียนโปรแกรมจึงมักไม่ใช่ผลลัพธ์สุดท้าย แต่ใกล้เคียงกับการเป็น เครื่องมือเพื่อทำให้คำนิยามของปัญหาชัดเจนขึ้น มากกว่า
ถ้าเป็นแค่การประกอบเฟรมเวิร์กเข้าด้วยกันอาจง่าย แต่ในสภาพแวดล้อมที่ต้องจัดการระบบซับซ้อน การเขียนโปรแกรมเองนี่แหละคือเรื่องที่ยากจริง
ผมเห็นคำขอเรียบง่ายถูกขยายกลายเป็นระบบขนาดยักษ์อยู่บ่อย ๆ แต่ถ้าลงทุนด้านอินฟราสตรักเจอร์อย่างชาญฉลาดแบบ Google มันก็อาจสร้างความได้เปรียบในการแข่งขันได้
แต่แนวทางแบบนี้มักดูเหมือนไม่เกิดประสิทธิผล หรือถูกเข้าใจผิดได้ง่ายว่าเป็น “คนที่พูดอะไรผิด ๆ”
นักพัฒนาจำนวนมากหลงคิดว่าโปรเจกต์ของตัวเองพิเศษ แต่ความจริงหลายครั้งแค่คัดลอก แบบออกแบบที่ผ่านการพิสูจน์แล้ว ก็เพียงพอ
ตามที่บทความบอก ความกังวลว่าถ้าโค้ดถูกสร้างได้เร็วเกินไปจะดูแลรักษายากก็มีเหตุผลอยู่ แต่ถ้าไม่ต้องให้มนุษย์เป็นผู้บำรุงรักษาเอง ความกังวลนั้นก็อาจสำคัญน้อยลง
แต่ผมคิดว่าตรรกะเดียวกันนี้ใช้กับ “โค้ช Agile แบบ LLM” ได้ด้วย เพราะตอนนี้ LLM สามารถให้ insight ส่วนใหญ่ได้ในต้นทุนที่ถูกกว่ามาก
สุดท้ายมนุษย์อาจได้ไปนั่งพักข้างสระว่ายน้ำก็ได้
ผมไม่เห็นด้วยกับคำกล่าวที่ว่า “ถึง codebase จะเละก็แก้ได้ถ้าโยนเอเจนต์หลายตัวเข้าไป”
ในความเป็นจริง มีโค้ดจำนวนมากที่ภายนอกดูสมบูรณ์แบบ แต่ภายใน ผิดโครงสร้างเหมือนตึกที่ทำจากโฟม
โค้ดแบบนี้พอเวลาผ่านไปจะขยายต่อไม่ได้ และสุดท้ายก็แข็งตัวเหมือนอิฐ
ผมเองก็เคยมีประสบการณ์ที่ โปรเจกต์สองชิ้นที่ AI สร้างล้มเหลวโดยสิ้นเชิง
ต่อให้เพิ่มเอเจนต์เข้าไปก็ไม่คืบหน้า และผลลัพธ์ที่ได้ส่วนใหญ่ก็ไปผิดทิศผิดทาง
ผมเห็นด้วยกับข้ออ้างที่ว่า “การพัฒนาซอฟต์แวร์เป็นกิจกรรมที่ใช้เงินทุนเข้มข้น” แต่บริบทของแต่ละอุตสาหกรรมก็แตกต่างกัน
บริษัทไฟฟ้าหรือผู้ผลิตมี ค่าใช้จ่ายในการดูแลโครงสร้างพื้นฐานทางกายภาพ สูงกว่า IT มาก
แต่เมื่อสัญญา SaaS มีจำนวนมากเกินไป ก็มีบริษัทจำนวนเพิ่มขึ้นที่เริ่มคิดว่าการจ้างนักพัฒนา LLM อาจคุ้มค่ากว่าไหม
ตอนแรกผมอ่านบทความนี้อย่างสนใจ แต่พอเจอ ตัวอย่างการทำสำเนา Slack ก็หมดความเชื่อถือทันที
มันเป็นข้ออ้างที่ไม่เข้าใจ ขนาด ความเสถียร และความสามารถ ของ Slack จริง ๆ เลย
ผลิตภัณฑ์สำหรับองค์กรต้องมีรายละเอียดแบบนี้อีกหลายร้อยอย่าง การทำสำเนาเฉย ๆ ไม่ใช่การแข่งขัน
บทความที่โยนแต่ตัวเลขกับกราฟเต็มไปหมดดูเหมือนงานเขียนของ คนที่อยากเอาชนะในการโต้เถียง
อย่างที่ Rory Sutherland พูดไว้ “Finance People” หมกมุ่นกับความแน่นอนและความสามารถในการคาดการณ์
แต่โลกไม่ได้เรียบง่ายแบบนั้น
มากกว่ารายละเอียดในบทความ ผมเห็นด้วยกับเรื่อง “วัฒนธรรมวิศวกรรมที่ไม่คิดเรื่องคุณค่าต่อค่าใช้จ่าย”
ระหว่างการประชุมหรือการรับมือเหตุการณ์ผิดปกติ มักมีหลายครั้งที่ตัดสินใจเกินจำเป็นโดยไม่คิดถึง ความคุ้มค่าต่อผลลัพธ์
หนี้ทางเทคนิคก็เหมือนกัน ถ้าไม่รู้ต้นทุน ก็เลือกอย่างมีความรับผิดชอบไม่ได้
การคำนวณแบบง่าย ๆ ที่ว่า “ทีมแพลตฟอร์มต้องพิสูจน์คุณค่าผ่านการประหยัดเวลา” นั้นผิด
ทีมแพลตฟอร์มไม่ได้มีหน้าที่แค่ประหยัดเวลา แต่มีหน้าที่ ลดความเสี่ยงทางธุรกิจและรับประกันคุณภาพหลัก
นี่ไม่ใช่แค่ตรรกะทางเศรษฐศาสตร์ง่าย ๆ แต่เป็นเรื่องของ โครงสร้างพื้นฐานที่จำเป็นขององค์กร
ท้ายที่สุด สิ่งสำคัญคือ ทีมรักผลิตภัณฑ์นั้นจริงหรือไม่
มีเพียงทีมที่ให้ความสำคัญกับตัวผลิตภัณฑ์มากกว่าความก้าวหน้าในอาชีพระยะสั้นเท่านั้น ที่จะสร้างผลลัพธ์จริงได้เหนือกว่าตัวชี้วัดหรือเทคนิคการจัดการ
แต่บางโปรเจกต์ก็มีโครงสร้างที่ทำให้ ยากจะรู้สึกผูกพันตั้งแต่แรก จนข้อจำกัดด้านผลิตภาพชัดเจนอยู่แล้ว