- มีหลายปัจจัยที่ส่งผลต่อประสิทธิภาพของนักพัฒนา
- บางอย่างชัดเจนและวัดได้ง่าย แต่บางอย่างวัดได้ยากจึงมักถูกมองข้าม
การรู้ว่าควรสร้างอะไร (Knowing what to build)
- การสร้างสิ่งที่ผิดให้เสร็จเร็วไม่ได้มีประสิทธิภาพเลย
- ต้องรู้ว่าลูกค้าต้องการอะไร
- ต้องรู้ว่าสิ่งใดที่ทีมอื่นยอมรับได้ (เช่น ตาราง DB จะมีดัชนีได้กี่ตัว, สามารถแชร์ข้อมูลใดได้ตามกฎหมายหรือไม่?)
- ต้องรู้ว่าอะไรเคยลองมาก่อนแล้วแต่ไม่ได้ผล
การทำงานให้น้อยลง
- การทำงานให้เสร็จเร็วเป็นเรื่องดี แต่ถ้าเป็นงานที่ไม่ต้องทำเลยจะยิ่งดีกว่า
- กระบวนการของบริษัทอาจเพิ่ม “งานที่ดูยุ่งตลอดเวลา” ซึ่งลดทอนประสิทธิภาพลง
- บางครั้งสามารถปรับกระบวนการได้ง่าย ๆ เพื่อให้ส่งมอบคุณค่าเดิมด้วยงานที่น้อยกว่ามาก
- อาจต้องใช้แรงบางส่วนเพื่อ “คอยให้ระบบยังเดินต่อไป (Keep the lights on, KTLO)”
- นี่คืองานที่ต้องทำต่อเนื่องอยู่เสมอ (เช่น ตอบซัพพอร์ตทิคเก็ต) แต่ไม่ได้ช่วยให้โปรเจกต์เดินหน้า
- งานเหล่านี้อาจดูมีประสิทธิภาพในหลายตัวชี้วัด (จำนวนทิคเก็ตที่ปิด, จำนวนคอมมิตที่ merge) แต่ไม่ได้ทำให้บริษัทดีขึ้น
เครื่องมือที่ตอบสนองรวดเร็ว
- นักพัฒนาใช้เครื่องมืออยู่ตลอดเวลา: editor, git, build system
- เวลาที่เครื่องมือเหล่านี้เพิ่มเข้ามาจะกลายเป็นต้นทุนสูงมากตามความถี่ในการใช้งาน
- ไม่ใช่แค่ต้นทุนต่อชั่วโมงเท่านั้น แต่ยังทำลายสมาธิของนักพัฒนาด้วย
ความรู้ในหัวของนักพัฒนา
- วัดได้ยาก
- หากเงื่อนไขอื่นเท่ากัน นักพัฒนาที่มีความรู้เกี่ยวข้องมากกว่าจะมีประสิทธิภาพมากกว่า
- เพราะรู้ว่าโค้ดทำงานอย่างไร จึงไม่ต้องเจาะลึกโค้ดทุกครั้ง
- รู้วิธีใช้เครื่องมือ และรู้ว่าควรหลีกเลี่ยงกับดักอะไร
- ตั้งคำถามได้ถูกจุด
- นักพัฒนา 10x มีอยู่จริง และพวกเขาคือ “คนที่รู้จัก codebase เป็นอย่างดี”
- นี่หมายความว่าทีมหนึ่งไม่ควรถือครองสิ่งที่มีมากเกินกว่าที่ทั้งทีมจะเก็บความเข้าใจไว้ในหัวได้โดยรวม (ค่า Bus Factor ควรมากกว่า 1 จะดีกว่า)
- และยังหมายความว่าควรลดความถี่ของการเปลี่ยนเจ้าของให้เหลือน้อยที่สุด
- ไม่มีใครรู้เรื่องนั้นได้มากไปกว่าคนที่สร้างมันขึ้นมา
- ตามอุดมคติ คนที่เพิ่งมาใช้ระบบควรได้ทำงานร่วมกับและเรียนรู้จากคนที่คุ้นเคยกับระบบนั้นอยู่แล้ว
- จำเป็นต้องมีขอบเขตที่ชัดเจนระหว่างระบบต่าง ๆ
- อินเทอร์เฟซที่สะอาดและมี semantic ที่เรียบง่าย หมายความว่าสามารถคิดถึงคุณสมบัติของอินเทอร์เฟซได้โดยไม่จำเป็นต้องรู้ทั้งระบบที่อยู่เบื้องหลัง
- เอกสารเป็นวิธีที่ดีในการถ่ายทอดความรู้
- สำคัญเป็นพิเศษเมื่อผู้พัฒนาต้องทำงานบางอย่างที่ตนไม่คุ้นเคย
- หากเอกสารไม่เพียงพอ นักพัฒนาต้องไปค้นคว้าเองว่าจะทำงานนั้นอย่างไร ทำผิดพลาดแล้วต้องทำใหม่ หรือรอให้ทีมอื่นมาตอบคำถาม จึงทำให้งานช้าลง
- สิ่งนี้อาจทำให้งานที่ควรใช้ 1 ชั่วโมง กลายเป็นงาน 2 วันได้อย่างรวดเร็ว
- ถ้านักพัฒนา 100 คนต้องทำสิ่งนี้ ต้นทุนจากการขาดเอกสารเพียง 1 หน้าอาจเทียบเท่ากับเงินเดือนทั้งปีของนักพัฒนาหนึ่งคน
- นี่ยังหมายความว่าควรเพิ่มความเชี่ยวชาญเฉพาะทาง (Specialization) ด้วย
- การบังคับให้นักพัฒนาทุกคนทำงานได้กว้างมากเกินไปเป็นเรื่องไม่มีประสิทธิภาพ
- หนึ่งชั่วโมงที่ใช้ไปกับกระบวนการเขียนระบบความปลอดภัยหรือการวางแผน capacity บางอย่าง ไม่เหมือนกับหนึ่งชั่วโมงที่ใช้ทำความเข้าใจโดเมนเพื่อแก้ปัญหา
โครงสร้างพื้นฐานที่เป็นประโยชน์
- โครงสร้างพื้นฐานควรเป็นตัวช่วย ไม่ใช่อุปสรรค
- ควรสอดคล้องอย่างสมเหตุสมผลกับทุกงานที่ต้องทำ
- ทุกส่วนของโครงสร้างพื้นฐานถูกออกแบบโดยมี use case บางอย่างอยู่ในใจ แต่ในโปรเจกต์จริงบางครั้งก็มีกรณีที่ออกนอก use case เหล่านั้น
- หากในเวลานั้นได้ยินว่า “ต้องใช้แต่โครงสร้างพื้นฐานของเราเท่านั้น” หรือ “โครงสร้างพื้นฐานของเราไม่รองรับแบบนี้” ก็ชวนให้อึดอัดมาก
- เพราะจะทำให้ต้องหาทางทำงานอ้อมโครงสร้างพื้นฐาน หรือเสียเวลาเข้าประชุมเพื่อโน้มน้าวเจ้าของระบบให้ยอมรับความต้องการ
หนี้ทางเทคนิคที่น้อย
- โค้ดที่มีอยู่เดิมมักไม่ได้เหมาะกับงานที่คุณกำลังจะทำอย่างสมบูรณ์แบบเสมอไป
- คนที่เขียนโค้ดเดิมไม่ได้มี “ลูกแก้ววิเศษ” ที่มองเห็นได้ว่าคุณจะต้องแก้อะไรในอนาคต
- แต่โค้ดบางชุดก็แก้ไขได้ง่ายกว่าอีกหลายชุดมาก
- คำตอบของ “จะทำ X ได้อย่างไร?” ไม่ควรกลายเป็น “เราต้องออกแบบทั้งหมดใหม่”
- ถ้ามีหนี้ทางเทคนิคมาก แม้เปลี่ยนฟีเจอร์เพียงเล็กน้อยก็ต้องเปลี่ยนระบบในวงกว้าง
- การลดหนี้ทางเทคนิคช่วยลดขอบเขตที่ต้อง (a) ทำความเข้าใจ และ (b) แก้ไข
- โปรเจกต์ที่ทำเพื่อชำระหนี้ทางเทคนิคต้องทำให้เสร็จ
- หากยกเลิกกลางทางหรือลดลำดับความสำคัญ ระบบอาจแย่กว่าตอนเริ่มต้นเสียอีก
อัตราความล้มเหลวต่ำ
- หากเกิดการรันเครื่องมือล้มเหลว, build ล้มเหลว, deploy ล้มเหลว หรือ regression จากข้อผิดพลาดใน production ก็เท่ากับเสียเวลาไปเปล่า ๆ
- การลดโอกาสของความล้มเหลวเหล่านี้ช่วยเพิ่มประสิทธิภาพได้
- นอกจากวิศวกรที่เจอกับความล้มเหลวแล้ว มักยังทำให้ทีมที่เป็นเจ้าของระบบที่ล้มเหลวต้องเสียเวลาด้วย (เพราะต้องร่วมกันวิเคราะห์และแก้ไข)
แนวปฏิบัติที่เพิ่มประสิทธิภาพต้องใช้งานได้จริง (Productive practices are practical)
- วิธีที่ดีที่สุดในการเรียนรู้ว่าจะแก้ปัญหาเฉพาะอย่างไร คือการสร้าง prototype
- หากสภาพแวดล้อมขัดขวางการทำ prototyping แม้แต่วิธีการที่มีประสิทธิภาพที่สุดก็อาจถูกขัดขวางได้
- ถ้าใช้เครื่องมือ monitoring ได้ยาก นักพัฒนาก็จะสร้าง dashboard น้อยลง วัดผลน้อยลง และการตัดสินใจก็จะอิงข้อมูลน้อยลง
- ในทางกลับกัน หากแบ่งการเปลี่ยนแปลงใหญ่ให้เป็น code review ขนาดเล็ก ก็จะช่วยให้ review และ deploy โค้ดได้ง่ายขึ้น
วิศวกรมีสมาธิได้มากแค่ไหน
- วิศวกรต้องทำงานตามกำหนดการส่งมอบ และต้องมีสมาธิ
- สมาธินั้นอาจถูกแย่งไปด้วยการประชุมและการขัดจังหวะ
- การขัดจังหวะยังรวมถึงคำสั่ง CLI ที่ช้า การทดสอบที่ช้า และงานที่ไม่รู้วิธีทำจนต้องไปค้นคว้าเอง
- การต้องคิดถึงหลายเรื่องมากเกินไปในหนึ่งสัปดาห์ก็ทำลายความสามารถในการจดจ่อเช่นกัน
- deadline ที่ใกล้เข้ามา หรือคำถามที่ยังไม่ได้คำตอบจากผู้จัดการ จะกิน mental RAM แม้ตอนที่พยายามโฟกัสกับเรื่องอื่น
การปิดงานให้เสร็จ
- การทำได้ 50% ไม่ใช่ประสิทธิภาพ 50% แต่คือประสิทธิภาพ 0%
- ไม่มีอะไรไร้ประสิทธิภาพไปกว่างานที่สุดท้ายถูกทิ้ง
- บางครั้งการยกเลิกโปรเจกต์กลางทางก็อาจเป็นการตัดสินใจที่ถูกต้อง
- การต่อสู้กับ sunk cost fallacy บางครั้งก็เป็นสิ่งที่ถูกต้อง
- แต่ไม่ควรมีรูปแบบซ้ำ ๆ ของการเปลี่ยนลำดับความสำคัญก่อนที่โปรเจกต์จะเสร็จ
- เพราะในกรณีนั้น ประสิทธิภาพของทีมอาจลดลงเหลือ 0
สรุป
- แม้จะไม่สามารถสร้าง dashboard เพื่อวัดปัจจัยหลากหลายเหล่านี้ได้เสมอไป แต่เราพอรู้ได้ว่าสิ่งข้างต้นส่งผลต่อประสิทธิภาพอย่างไร
- การแก้ปัญหาเหล่านี้อาจเพิ่มปริมาณงานที่ทำได้อย่างมาก
- ปัญหาบางอย่างแก้ได้ง่ายอย่างน่าประหลาดใจ
- หากใช้เวลาไม่กี่ชั่วโมงเขียนเอกสาร บริษัทอาจประหยัดเวลาได้เป็นพันชั่วโมง
- ถ้าต้องตัดต้นไม้ให้เร็ว จงเริ่มจากการลับคมเลื่อย
7 ความคิดเห็น
เป็นบทความที่มีส่วนสรุปปิดท้ายเยอะมากเลยนะ
"หากเอกสารไม่เพียงพอ นักพัฒนาจะต้องค้นคว้าเองว่าควรทำงานอย่างไร และอาจทำผิดพลาด ต้องทำงานซ้ำ หรือต้องรอจนกว่าทีมอื่นจะตอบคำถาม ทำให้ความเร็วในการทำงานช้าลงได้"
แม้จะไม่ใช่เอกสารพัฒนาโดยตรง แต่พอเราขอให้คนที่เพิ่งผ่านการ onboarding ช่วยอัปเดตเอกสาร onboarding หลังจากผ่านไป 1 สัปดาห์ เอกสารก็ดีขึ้นนะครับ เพราะตอนที่เพิ่งเข้ามาทำงานและยังไม่มีข้อมูลอะไรเลย คนกลุ่มนั้นรู้ดีที่สุดว่าตอนนั้นต้องการอะไร
ผมก็คิดเหมือนกันว่าเหตุผลหนึ่งที่
Readme.mdของโปรเจ็กต์โอเพนซอร์สบน Github หลายแห่งเขียนไว้ค่อนข้างดี อาจเป็นเพราะมีผู้ใช้ครั้งแรกจำนวนมากเข้ามาและให้ฟีดแบ็กด้วยช่วงนี้มีงานเข้ามาเยอะเกินไปจนมึนไปหมด ฮือฮือ
โครงสร้างพื้นฐานควรเป็นตัวช่วย ไม่ใช่อุปสรรค --> แต่ตอนนี้ในบริษัทต่าง ๆ ในเกาหลี เรื่องนี้กลับไม่เป็นเช่นนั้นเลย โดยอ้างเรื่องความปลอดภัย
เข้าใจความรู้สึกครับ แต่บทความนี้เขียนเป็นภาษาอังกฤษนี่ครับ ดูเหมือนว่าบริษัทในประเทศที่ใช้ภาษาอังกฤษก็มีสถานการณ์คล้ายกันเช่นกัน
ดูเหมือนไม่ใช่แค่สรุป แต่แทบจะเป็นการแปลเลย... ขอบคุณสำหรับการสรุปอย่างละเอียดครับ