- ในบริษัทที่มีหนี้ทางเทคนิคจำนวนมหาศาล มักเกิดความไร้ประสิทธิภาพจากการคัดลอกโค้ดและการใช้เฟรมเวิร์กที่ล้าสมัย
- ระหว่างการเดินหน้าโปรเจกต์ การสูญเสียความไว้วางใจจากฝ่ายบริหาร และการต่อต้านการเปลี่ยนแปลงภายในองค์กรกลายเป็นอุปสรรคสำคัญ
- ต้นตอของหนี้ทางเทคนิคคือปัจจัยด้านคน เช่น ความต้องการที่ไม่ชัดเจน กำหนดการที่ไม่สมจริง การเลือกใช้เทคโนโลยีเก่า การตัดสินใจระยะสั้นของผู้บริหาร และอัตตาส่วนบุคคล
- ความสำเร็จของโปรเจกต์ต้องอาศัยไม่ใช่แค่ผลลัพธ์ทางเทคนิค แต่รวมถึงการบริหารการรับรู้และการสื่อสาร
- นอกจากทักษะทางเทคนิคแล้ว วิศวกรยังต้องมีความสามารถในการทำงานร่วมกันและการประสานความสัมพันธ์ภายในองค์กร
ปัญหาหนี้ทางเทคนิคและโค้ดที่ซ้ำซ้อน
- บริษัทที่เคยทำงานมีหนี้ทางเทคนิคอย่างรุนแรง ด้วยโค้ดหลายล้านบรรทัด ไม่มี unit test และใช้เฟรมเวิร์กที่มีอายุมากกว่า 10 ปี
- เพื่อให้โมดูลที่ใช้ได้เฉพาะบน Windows ทำงานบน Linux จึงใช้วิธีคัดลอกและวางโค้ดหลายแสนบรรทัด
- ผลคือเกิด codebase สองชุด ทำให้การเพิ่มฟีเจอร์และแก้บั๊กต้องทำแยกกันทั้งสองฝั่ง
- สถานการณ์แบบนี้นำไปสู่โครงสร้างที่บำรุงรักษาไม่ได้ และในระยะยาวความแตกต่างระหว่างโค้ดทั้งสองก็ยิ่งมากขึ้น
หนี้ทางเทคนิคที่เกิดจากปัญหาเรื่องคน
- โปรเจกต์หนี้ทางเทคนิคมักอธิบายให้ผู้บริหารเห็นด้วยได้ยาก และเพราะแทบไม่มีการเปลี่ยนแปลงด้านฟีเจอร์ จึงขาดผลลัพธ์ที่มองเห็นได้ชัด
- เมื่อโปรเจกต์ล่าช้า ก็ยิ่งสูญเสียความเชื่อมั่นจากผู้บริหาร
- แก่นของปัญหาไม่ใช่เรื่องเทคนิค แต่เป็นทัศนคติของคนและวัฒนธรรมองค์กร
- นักพัฒนาจำนวนมากต่อต้านการเปลี่ยนแปลงและยึดติดกับวิธีเดิม
- โครงสร้างโค้ดสะท้อนบุคลิกและระดับการยอมรับการเปลี่ยนแปลงของผู้เขียน
- หนี้ทางเทคนิคเกิดจากความต้องการที่ไม่ชัดเจน, คำมั่นสัญญาที่ไม่สมจริง, การเลือกเทคโนโลยีเก่า, การตัดสินใจหยุดงานโดยผู้บริหาร, อัตตาส่วนตัว เป็นต้น
- ยิ่งทีมมีแนวโน้มหลีกเลี่ยงการเปลี่ยนแปลงมากเท่าไร โค้ดก็ยิ่งสะท้อนลักษณะการปฏิเสธการเปลี่ยนแปลงมากขึ้นเท่านั้น
- นักพัฒนาหลายคนยังคงทำงานแบบเดิมมาหลายปี และถึงขั้นมีคำพูดว่า “ไม่อยากเรียนรู้อะไรใหม่แล้ว”
- ในสภาพแวดล้อมแบบนี้ หนี้สะสมเร็วกว่าอัตราการสะสาง ดังนั้นก่อนจะลดหนี้ ต้องหยุดไม่ให้หนี้เพิ่มขึ้นก่อน
- เหมือนกับการทำ triage (การคัดแยกลำดับความสำคัญ) ในห้องฉุกเฉิน ที่ต้องเริ่มจากการ “หยุดเลือด” ก่อน
ช่องว่างระหว่างโลกในอุดมคติกับความเป็นจริง
- แทบไม่มีสภาพแวดล้อมในอุดมคติที่จะแก้ปัญหาวิศวกรรมโดยแยกออกจากบริบททางการเมืองหรือองค์กรได้
- โปรเจกต์ส่วนใหญ่มักมีผู้มีส่วนได้ส่วนเสียที่ไม่ใช่สายเทคนิค
- ท่าทีแบบ “เรากำลังทำอยู่ ก็เชื่อเราเถอะ” ใช้ไม่ได้ผล
- การบริหารการรับรู้ต่อผลงาน สำคัญพอ ๆ กับผลงานจริง
- คนที่ไม่ใช่สายเทคนิคมักไม่เข้าใจโดยสัญชาตญาณว่าทำไมต้องจัดการหนี้ทางเทคนิค จึงต้องอธิบายด้วยตัวเลขและคุณค่าทางธุรกิจ
- หากผู้นำไม่มีพื้นฐานวิศวกรรม ก็จำเป็นต้องแสดงตัวชี้วัดและผลลัพธ์ที่มองเห็นได้
- สุดท้ายแล้ว การที่ทีมดูมีประสิทธิภาพก็สำคัญพอ ๆ กับประสิทธิภาพจริง
ทักษะที่วิศวกรระดับซีเนียร์ต้องมี
- เมื่ออยู่ในระดับซีเนียร์ขึ้นไป ความสามารถในการทำงานข้ามแผนกและการประสานความสัมพันธ์ระหว่างคน เป็นสิ่งจำเป็น
- ในการศึกษาวิทยาการคอมพิวเตอร์ มักไม่ได้สอนเรื่องการจัดการคนอย่าง บุคลิก อัตตา และความสัมพันธ์
- แม้วิศวกรบางคนจะมีความสามารถทางเทคนิคยอดเยี่ยม ก็อาจรับมือกับปัญหาที่ต้องอาศัยการเปลี่ยนแปลงขนาดใหญ่ในระดับองค์กรไม่ได้
- ผลิตภาพส่วนบุคคลอาจสูง แต่อิทธิพลต่อทั้งองค์กร ยังมีข้อจำกัด
- บทบาทของ ‘Heads up coder’ มีความสำคัญ
- คือคนที่ยังคงมีความเชี่ยวชาญทางเทคนิคเชิงลึก พร้อมกับมองเห็นความเสี่ยงของโปรเจกต์ตั้งแต่เนิ่น ๆ และช่วยปรับจูนทีมได้
- แทนที่จะทำงานเร็วคนเดียวเหมือน single core ก็ทำหน้าที่พาทีมทั้งทีมให้ทำงานได้อย่างมีประสิทธิภาพ
- ต่างจากวิศวกรสายเทคนิคล้วนตรงที่สามารถอ่านบริบทและความเสี่ยงขององค์กรไปพร้อมกันได้
สรุป
- เบื้องหลังปัญหาทางเทคนิคมักมีเรื่องของคนอยู่เสมอ
- ปัญหาทางเทคนิคส่วนใหญ่มักลงเอยที่ปัญหาเรื่องคน วัฒนธรรม และการสื่อสาร
- หนี้ทางเทคนิคไม่ใช่แค่ปัญหาของโค้ด แต่เป็นผลลัพธ์จากรูปแบบพฤติกรรมและวัฒนธรรมขององค์กร
- การแก้หนี้ทางเทคนิคต้องเริ่มจากการยอมรับการเปลี่ยนแปลงในระดับองค์กรและความเข้าใจจากผู้นำ
- และยังมีปัญหาที่ความเป็นเลิศทางเทคนิคเพียงอย่างเดียวไม่อาจแก้ได้ รออยู่บนเวทีที่ใหญ่ขึ้นในช่วงหลังของเส้นทางอาชีพ
- วิศวกรซีเนียร์ที่แท้จริงคือผู้นำที่สมดุลระหว่างความเข้าใจด้านเทคนิคและความเข้าใจมนุษย์
2 ความคิดเห็น
สำหรับผู้ที่อยากทราบรายละเอียดเกี่ยวกับเรื่องนี้มากขึ้น ขอแนะนำให้อ่าน Peopleware!
ความคิดเห็นจาก Hacker News
รู้สึกว่าปัญหาส่วนใหญ่คือ ปัญหาการสื่อสาร
วิศวกรถูกตัดขาดจากวิสัยทัศน์ของผลิตภัณฑ์หรือจากลูกค้า ขณะที่ทีมผลิตภัณฑ์ก็ปฏิบัติต่อวิศวกรเหมือนเป็นแค่ ทีมเอาต์ซอร์สภายในบริษัท
ฝ่ายขายและ CS ไม่เข้าใจว่าคำมั่นสัญญาของพวกเขาส่งผลต่อโรดแมปผลิตภัณฑ์อย่างไร
สุดท้ายเป้าหมายและตัวชี้วัดความสำเร็จก็ไม่สอดคล้องกัน จนทุกคนพายเรือกันคนละทิศ
ทางแก้ไม่ใช่การหา “คนที่ดีกว่า” แต่คือทำให้ทุกคนทุ่มไปกับเป้าหมายเดียวกัน และเข้าใจว่าบทบาทของตัวเองเชื่อมกับภาพรวมอย่างไร
หนี้เทคนิคเก่าก็เหมือนกัน ต่อให้เมินมันก็ไม่หายไป ต้องประเมินต้นทุนและความเสี่ยงที่หนี้นั้นสร้างให้บริษัทเป็นตัวเลข แล้วค่อยวางแผนถ่วงดุลกับเป้าหมายอื่นและทยอยชำระมัน
เป็นเซสชันที่ผู้ใช้นั่งอยู่ข้าง ๆ กัน ได้เจอกันตรง ๆ กลายเป็นเพื่อนกัน และเรียนรู้ชีวิตประจำวันกับบริบทของอีกฝ่าย
ระบบจะจัดตารางให้อัตโนมัติทุก 3 สัปดาห์ และไม่มี action item เพิ่มเติม ทุกครั้งผู้คนจะประหลาดใจเสมอ มีบั๊กเล็ก ๆ ถูกแก้ และเกิดความเชื่อมโยงขึ้น
ตอนนี้กำลังรันผ่านตัวจัดตารางอัตโนมัติที่เชื่อมกับ Slack API และส่วนที่ยากที่สุดคือการนัดเวลาและทำให้คนยอมเข้าร่วม
ผู้บริหารไม่ฟังคนระดับล่าง ส่วนคนระดับล่างก็แข่งขันกันเพื่อให้ตัวเองได้รับความสนใจ
ไม่นานมานี้ในแผนกเราก็มีที่ปรึกษาเสนอให้ย้ายไปแพลตฟอร์มใหม่ ไม่มีใครเห็นด้วยแต่ก็หยุดไม่ได้ สุดท้ายก็ไม่มีใครฟังใคร
พอถามว่า “ทำไมเราต้องทำสิ่งนี้?” ก็ได้แต่คำตอบแนว ๆ “เชื่อฉันเถอะน่า”
พฤติกรรมแบบนี้ของ PM คงไม่เปลี่ยน ดังนั้นวิศวกรเลยเริ่มรับบทบาทฝั่งผลิตภัณฑ์เองเพื่อปิดช่องว่างด้านการสื่อสาร
ฉันได้ตระหนักว่าหลายคนจริง ๆ แล้ว ไม่ได้ภูมิใจในงานของตัวเอง
สำหรับบางคน มันก็เป็นแค่งานรับเงินเดือน
โดยเฉพาะเพื่อนร่วมงานที่อายุมากกว่า เคยผ่านประสบการณ์เห็นระบบพังมาแล้ว เลยพยายามไม่ให้เกิดแบบนั้นอีก
ทุกครั้งที่ย้ายงานใหม่ ฉันพยายามตั้งแนวทางที่ชัดเจนไว้ในแผน 90 วัน แต่สุดท้ายแก่นสำคัญก็คือทีม
บางทีมกระหายการเปลี่ยนแปลง บางทีมขัดขวางมัน
ถ้าผู้นำไม่รู้เรื่อง หรือเลือกแต่ทางที่เร็วและถูกที่สุด ทุกอย่างก็ยิ่งยากขึ้น
มันทำให้นึกถึงกรณีอย่าง Post Office scandal ของสหราชอาณาจักร ที่คนในรู้ปัญหาแต่ถูกปิดกั้น
ในอดีตคนมากกว่าครึ่งเป็นเจ้าของกิจการของตัวเอง แต่ตอนนี้เหลือราว 10% เท่านั้น
สิ่งที่เราสร้างจึงไม่ใช่ “ของเรา” แต่เป็น “ของนายจ้าง”
ทำงานหนักขึ้นก็ไม่ได้รางวัล กลับยิ่งโดนโยนงานเพิ่ม
สุดท้ายคนก็ถูกปฏิบัติเป็น ทรัพยากร และถ้าไม่จำเป็นก็ถูกทิ้ง
เวลาเกิดวิกฤต คนที่ถูกปลดก่อนคือพนักงาน ส่วน CEO ได้เงินหลายล้านดอลลาร์
ในโครงสร้างแบบนี้ จะคาดหวังให้พนักงานทุ่มเทเพื่อบริษัทก็คงเป็นไปไม่ได้
คนที่ทำงานน้อยกว่ากลับได้เงินเดือนมากกว่า และคุณอาจถูกเลิกจ้างเพราะมีคนมาทดแทนได้ด้วยค่าแรงครึ่งเดียว
การสัมภาษณ์ก็ยิ่งยากขึ้น ผลงานก็ถูกขโมยไป และเงินเฟ้อก็กัดกินเงินเดือน
สุดท้ายคำถามว่า “ทำไมความภูมิใจถึงหายไป” ดูเหมือนปริศนา แต่จริง ๆ คำตอบชัดอยู่แล้ว
แต่บริษัทก็รู้ว่าคนส่วนใหญ่ไม่ได้มีโอกาสทำงานที่อยากทำ จึงหันไปเน้นที่ process และ workflow แทน
สำหรับแต่ละคน ทางเลือกที่ดีที่สุดคือได้ทำงานที่ชอบพร้อมกับได้รับค่าตอบแทนที่ดี
คำพูดของนักพัฒนาที่ว่า “ไม่อยากเรียนรู้อะไรใหม่แล้ว” ไม่จำเป็นต้องเป็นเรื่องแย่เสมอไป
ความเหนื่อยล้าจากเฟรมเวิร์กที่เปลี่ยนทุกวันแบบ ecosystem ของ JavaScript นั้นต่างจาก เสถียรภาพทางเทคนิค แบบ Go หรือระบบที่ยึด LTS
ความเสถียรยังช่วยเรื่องความคล่องตัวของผลิตภัณฑ์ด้วย
คุณอาจต้องไปเจรจากับวิศวกรอาวุโสที่ดูแล codebase C++ เก่า ๆ แต่การเรียกสิ่งนั้นว่า หนี้เทคนิค แบบเหมารวมนั้นมีอคติ
การจะตัดสินว่าเป็นหนี้เทคนิคหรือไม่ ควรเป็นหน้าที่ของ lead IC ที่รับผิดชอบ codebase นั้นและผู้จัดการของเขาเท่านั้น
การพูดถึงปัญหาเชิงมนุษย์ในการสัมภาษณ์เป็น วิธีตกสัมภาษณ์ที่ดีมาก
ผู้สัมภาษณ์จำนวนมากคิดว่ามีแต่คำตอบเชิงเทคนิคเท่านั้นที่ถูกต้อง และมองข้ามมุมมองด้านมนุษย์
สำหรับฉันกลับให้คุณค่ากับมุมมองแบบนั้นมาก แต่ต้องไปถกเถียงเกลี้ยกล่อมกับเพื่อนร่วมงานอีกที
ฉันบอกว่าถ้าปริมาณข้อความอยู่ในระดับหนึ่ง การประมวลผลแบบ batch ก็อาจเพียงพอแล้ว เขากลับฟันธงว่าฉัน “ไม่รู้จัก queue”
แม้ฉันจะบอกว่าทำงานกับผลิตภัณฑ์ข้อมูลระดับเพตะไบต์มานานกว่าสิบปี แต่ก็ยังถูกปฏิเสธเพราะไม่ตรงกับแนว system design ของเขา
สุดท้ายตอนนี้ทีมนั้นกำลัง รวบทุก microservice ไว้หลัง API เดียว
ถ้าทีมไม่เข้าใจสมดุลแบบนั้น ก็ไม่จำเป็นต้องไปร่วมทีม
ในฐานะ data engineer ของ Big Tech ปัญหาที่ยากที่สุดมีอยู่สองอย่าง
อย่างแรกคือเพราะ Conway’s Law แต่ละแผนกจึงมี toolchain และแนวคิดเรื่องข้อมูลของตัวเอง
อย่างที่สองคือแต่ละไซโลต่างยืนยันว่ามีแต่วิธีของตัวเองที่ถูกต้อง แต่ก็ยังอยากได้ข้อมูลของกันและกัน
สาเหตุที่ทำให้มาตรฐานร่วมกันเกิดขึ้นไม่ได้ ก็เพราะผู้นำแต่ละแผนกเชื่อว่าวิธีของตัวเองเท่านั้นคือคำตอบเดียว
พอมองตามความจริงแล้ว แนวทางส่วนใหญ่ก็ทั้งถูกและผิดในเวลาเดียวกัน
ภายนอกอาจดูเหมือนปัญหาเทคนิค แต่สุดท้ายมันคือ ปัญหาคน
ระบบต้นน้ำเปลี่ยนก็ไม่มีการแจ้ง ทำให้มารู้ก็ตอนปลายน้ำมี alarm ดัง
มีคำขอเฉพาะหน้ามากจน สปรินต์ไร้ความหมาย และมีความรู้ที่ไม่ถูกบันทึกไว้มากมาย
ประสบการณ์แบบนี้เองที่ทำให้ฉันมีแรงจูงใจไปศึกษาวิทยาการคอมพิวเตอร์ในระดับลึกลงไป
ถ้าอยากขับเคลื่อนการเปลี่ยนแปลง คุณต้องสร้างเครือข่าย ดึงคนให้มารวมกัน และ สื่อสารการเปลี่ยนแปลง อย่างโปร่งใส
แต่ถ้าอยากให้เกิดการเปลี่ยนแปลงจริง ก็ต้องมีการสนับสนุนจากผู้นำระดับสูงอย่าง director หรือ VP
AWS มีคู่มือเรื่องการเปลี่ยนแปลงองค์กรลักษณะนี้ออกมา และ AWS Prescriptive Guidance ก็เป็นพิมพ์เขียวที่ยอดเยี่ยม
ทุกอย่างเริ่มต้นจากแนวคิดว่า “มารวมทุกคนไว้ในโซลูชันเดียวกันเถอะ” แต่ไม่นานก็แตกออกเป็นโปรเจกต์แยกตามแต่ละหน่วยงาน
ถ้าอยากกันไม่ให้เป็นแบบนั้น ต้องมีผู้นำที่มีอำนาจจริงจัง
โดยเฉพาะภาครัฐยิ่งยาก เพราะหลายแห่งเกลียดกันเอง ส่วนภาคเอกชนอย่างน้อยก็ยังมีเป้าหมายร่วมเรื่อง การรักษางานของตัวเอง
อย่างที่ Jerry Weinberg พูดไว้ใน 『Secrets of Consulting』
“ต่อให้ดูเหมือนปัญหาเทคนิค แต่ มันคือปัญหาคนเสมอ”
รากของปัญหาเทคนิคสุดท้ายก็มาจากการตัดสินใจ การสื่อสาร การจัดการ และความสามารถของคน
ฉันเคยทำงานเป็นนักวิเคราะห์ในโปรเจกต์เปลี่ยนระบบ
ระบบเดิมแจกงานแบบ round robin ง่าย ๆ แต่ระบบใหม่แจกงานอย่างยุติธรรมโดยดูภาระงานของแต่ละคน
แต่กลับมีพนักงานบางคน บิดเบือนระบบให้ตัวเองดูยุ่ง ส่งผลให้คนที่ขยันจริงต้องรับงานมากขึ้น
เราอธิบายอย่างชัดเจนว่าต้นตอของปัญหาไม่ใช่เทคโนโลยี แต่เป็น การขาดการกำกับดูแล ทว่าสุดท้ายก็ยังถูกบังคับให้หาทางแก้เชิงเทคนิค
ด้วยธรรมชาติของมนุษย์ งานมักจะขยายตัวเต็มเวลาที่มีอยู่ และแรงจูงใจที่ผิดเพี้ยนแบบนี้ต้องถูกควบคุมด้วยเทคนิค
ถ้าออกแบบระบบโดยตั้งสมมติฐานว่ามนุษย์จะสมบูรณ์แบบ ก็ล้มเหลวแน่นอน
Jerry Weinberg เน้นหลักการนี้มาตั้งแต่ 『The Psychology of Computer Programming』 (1971) ว่า
“ต่อให้ดูเหมือนปัญหาเทคนิค มันก็เป็นปัญหาคนเสมอ”
หนังสือของเขายังมีคุณค่าแม้อ่านในวันนี้
ฉันไม่ชอบท่าทีที่ชอบกล่าวโทษว่าคนอื่น “ไม่ภูมิใจในงานของตัวเอง”
พนักงานส่วนใหญ่ ไม่ได้เป็นเจ้าของงานนั้น บริษัทต่างหากที่เป็นเจ้าของ
ถ้าบริษัทบังคับให้เดินไปในทิศทางหนึ่ง และลงโทษเมื่อคุณคัดค้าน แล้วจะให้สู้ไปทำไม
เราเป็นแค่ ฟันเฟืองในเครื่องจักร และถ้าถูกปฏิบัติแบบนั้น ก็แค่ตอบสนองตามนั้น
ท่าที เอาตัวเองเป็นศูนย์กลาง ของผู้เขียนทำให้รู้สึกขัดใจ
ตอนนี้ฉันค่อนข้างอาวุโสแล้ว และทำงานตรงกับฝ่ายสปอนเซอร์งบประมาณกับคนดูแล requirement
พวกเขาจะถามว่า “ช่วยทำอันนี้ให้หน่อย ราคาเท่าไหร่?” แต่ฉันต้องตีราคาคร่าว ๆ ให้ได้ภายใน 18 นาทีจากประชุม 30 นาที
พวกเขาไม่เข้าใจเทคนิค แต่เข้าใจ ภาษาแห่งเงินและการเมือง อย่างสมบูรณ์
ปัญหาบางอย่างฉันแก้ได้ด้วยข้อความเพียงฉบับเดียว แต่งบประมาณกลับอยู่ที่ 6 ล้านดอลลาร์
ขณะที่บางโปรเจกต์โดนอีกทีมเอาไปทำ ใช้เงินเผาไป 35 ล้านดอลลาร์แล้วล้มเหลว
สปอนเซอร์ที่ถือเงินส่วนใหญ่ ให้การเมืองมาก่อน และเป้าหมายคือ “ตำแหน่งถัดไป”
พอมองเส้นทางอาชีพของพวกเขาแล้ว บ่อยครั้งก็อดคิดไม่ได้ว่า “ขึ้นไปถึงตรงนั้นได้ยังไงกัน”