การเป็น Chief Technology Officer (CTO) ที่มีประสิทธิภาพนั้นจำเป็นต้องมีทักษะการเขียนโค้ดหรือไม่? คำถามนี้เป็นประเด็นถกเถียงในวงการเทคโนโลยีมาอย่างยาวนาน หลายคนเชื่อว่า CTO ที่ไม่มีพื้นฐานด้าน Computer Science หรือเขียนโค้ดไม่เป็นจะไม่ได้รับความเคารพจากทีมพัฒนา แต่ความจริงแล้ว ปัญหาอาจซับซ้อนกว่านั้น
ความเคารพเกิดจากความเข้าใจ ไม่ใช่คุณวุฒิหรือทักษะ
โดยพื้นฐานแล้ว นักพัฒนาไม่ได้ด่วนสรุปว่า CTO ควรได้รับความเคารพหรือไม่จากคุณวุฒิหรือความสามารถในการเขียนโค้ด แต่พวกเขาให้ความเคารพผู้ที่แสดงให้เห็นว่า "เข้าใจ" ความท้าทายที่พวกเขาเผชิญอยู่ในแต่ละวัน
ไม่มีนักพัฒนาคนไหนเดินเข้าไปถาม CTO ตรงๆ ว่า "คุณเขียนโค้ดเป็นไหม?" แล้วตัดสินความเคารพจากคำตอบนั้น แต่พวกเขาประเมินจากการตัดสินใจ นโยบาย และแนวทางการบริหารที่ CTO วางไว้ว่าสะท้อนความเข้าใจในการพัฒนาซอฟต์แวร์หรือไม่
สัญญาณอันตรายของ CTO ที่ขาดความเข้าใจ
มีหลายสัญญาณที่บ่งชี้ว่า CTO อาจไม่เข้าใจความท้าทายในการพัฒนาซอฟต์แวร์อย่างลึกซึ้ง:
1. การวัดผลงานที่ไม่สอดคล้องกับความเป็นจริง
การวัด KPI ด้วยปริมาณ Commit เป็นตัวอย่างที่ชัดเจนของการไม่เข้าใจธรรมชาติของการพัฒนาซอฟต์แวร์ Commit จำนวนมากไม่ได้หมายถึงคุณภาพของโค้ดหรือประสิทธิภาพของนักพัฒนา บางครั้ง Commit เพียงครั้งเดียวแต่ผ่านการวิเคราะห์และทดสอบอย่างละเอียดอาจมีคุณค่ามากกว่า Commit เล็กๆ หลายสิบครั้ง
2. การลดทอนปัญหาที่ซับซ้อน
เมื่อทีมพัฒนาเผชิญกับปัญหาทางเทคนิคที่ซับซ้อน แต่ CTO ตอบกลับด้วยประโยคเรียบง่ายอย่าง "ก็แค่ตั้งชื่อให้มันร่วมกันได้ก็จบ" สำหรับปัญหา Interface ระหว่างทีม แสดงให้เห็นถึงการไม่เข้าใจความซับซ้อนของปัญหา ซึ่งอาจเกี่ยวข้องกับโครงสร้างข้อมูล สถาปัตยกรรม หรือข้อจำกัดด้านเทคนิคอื่นๆ
3. การเรียกร้องสิ่งที่เป็นไปไม่ได้ทางทฤษฎี
ตัวอย่างเช่น การฝ่าฝืน CAP Theorem ซึ่งเป็นทฤษฎีพื้นฐานในระบบฐานข้อมูลกระจาย ที่ระบุว่าไม่สามารถได้ทั้ง Consistency และ Availability พร้อมกันในสถานการณ์ที่เกิด Network Partition แต่ CTO กลับบอกว่า "ก็แค่ขยันพยายามคิดหน่อย" แสดงให้เห็นถึงการไม่เข้าใจข้อจำกัดทางทฤษฎีที่แก้ไขไม่ได้ด้วยความขยันหรือการทำงานล่วงเวลา
4. การยึดติดกับกระบวนการที่ไม่ยืดหยุ่น
การเรียกร้องให้ทำ Design Document อย่างละเอียดสำหรับทุกโปรเจกต์ โดยไม่คำนึงถึงบริบทว่าบางโปรเจกต์ต้องการการทดลองหรือ Proof of Concept (POC) ก่อน เป็นตัวอย่างของการยึดติดกับกระบวนการมากเกินไปโดยไม่พิจารณาความเหมาะสม
เปรียบเทียบกับหัวหน้าเชฟที่ไม่เคยทำอาหาร
สถานการณ์นี้คล้ายกับหัวหน้าเชฟที่ไม่เคยทำอาหารแต่มาสั่งให้ใช้น้ำตาลทรายแทนน้ำตาลมะพร้าวเพื่อลดต้นทุน โดยไม่เข้าใจว่าการเปลี่ยนวัตถุดิบส่งผลต่อรสชาติอย่างไร เมื่อถูกท้วงติง กลับตอบว่า "ไม่ใช่หน้าที่ฉันที่ต้องสนใจรสชาติ ฉันสนใจแต่ภาพรวม อร่อยหรือไม่นั่นเป็นรายละเอียดที่ฉันไม่เกี่ยว"
การบริหารแบบนี้ไม่ต่างจากการใช้ Randomized Algorithm เลือกคำตอบจาก ChatGPT โดยไม่มีความเข้าใจว่ากำลังทำอะไรอยู่
คุณสมบัติของ CTO ที่มีประสิทธิภาพ
CTO ที่มีประสิทธิภาพไม่จำเป็นต้องเขียนโค้ดได้เก่งที่สุด แต่ควรมีคุณสมบัติดังนี้:
1. เข้าใจผลกระทบของนโยบาย
สามารถตอบคำถามได้ว่า "แนวทางบริหารที่วางไว้ทำให้คนเขียนโค้ดง่ายขึ้นหรือยากขึ้น และยากขึ้นขนาดไหน" ไม่ใช่ปัดความรับผิดชอบด้วยการอ้างว่าตนดูแค่ภาพรวม
2. รับฟังและเคารพข้อจำกัดทางเทคนิค
เมื่อทีมพัฒนาบอกว่ามีข้อจำกัดทางเทคนิค CTO ควรรับฟังและหาทางออกร่วมกัน ไม่ใช่บังคับให้ฝ่าฝืนสิ่งที่เป็นไปไม่ได้
3. ปรับกระบวนการให้เหมาะกับบริบท
ไม่ยึดติดกับ "วิธีที่ถูกต้อง" เพียงวิธีเดียว แต่เข้าใจว่าแต่ละโปรเจกต์มีความท้าทายและความต้องการที่แตกต่างกัน และปรับกระบวนการให้เหมาะสม
4. สร้างสภาพแวดล้อมที่เอื้อต่อการพัฒนา
มุ่งเน้นการขจัดอุปสรรคและสนับสนุนทีมพัฒนาให้ทำงานได้อย่างมีประสิทธิภาพ ไม่ใช่สร้างอุปสรรคเพิ่มด้วยนโยบายที่ไม่สมเหตุสมผล
บทสรุป
ประเด็นไม่ได้อยู่ที่ว่า CTO ต้องเขียนโค้ดเป็นหรือไม่ แต่อยู่ที่ความเข้าใจในธรรมชาติของการพัฒนาซอฟต์แวร์และผลกระทบของการตัดสินใจ
แม้ CTO ไม่จำเป็นต้องนั่ง Commit โค้ดกับทีมทุกวัน (บางครั้งการทำเช่นนั้นอาจกลายเป็นการแทรกแซงการทำงานของทีม) แต่ต้องมีความเข้าใจเพียงพอที่จะวางนโยบายและแนวทางที่สนับสนุนการทำงานของทีมพัฒนา ไม่ใช่เป็นอุปสรรค
การบริหารที่ดีต้องเริ่มจากความเข้าใจงานที่ตนบริหารอย่างลึกซึ้ง ไม่ว่าจะมาจากประสบการณ์ตรงหรือการเรียนรู้ทางอ้อม ความท้าทายของ CTO ยุคใหม่จึงไม่ใช่การเป็น "คนเขียนโค้ดที่เก่งที่สุด" แต่เป็นการพัฒนาความเข้าใจในระดับที่สามารถสนับสนุนทีมได้อย่างมีประสิทธิภาพ
ท้ายที่สุด ปัญหาไม่ได้อยู่ที่คุณวุฒิ CS degree หรือความสามารถในการเขียนโค้ด แต่อยู่ที่ "ความเข้าใจ" และ "ทัศนคติ" ในการบริหารเทคโนโลยีอย่างมีประสิทธิภาพ
Top comments (0)