ฉันคิดว่าเมื่อฉันโตขึ้น เกมตำหนิทั้งหมดคงจะจบลง แต่ฉันเดาว่าคงไม่ใช่เพราะมันเป็นสิ่งที่ฉันได้ยินบ่อยเกินไปในที่ทำงาน ข้อผิดพลาดเกิดขึ้นและมีการเปลี่ยนแปลงในโค้ดที่เราเขียนทุกวัน แต่ฉันยังคงไม่เห็นคุณค่าในการหาคนมาปักหมุดเป้าหมาย
ในระดับสูง (อย่างน้อยในสายตาของฉัน) มันเป็นกลไกการป้องกัน “หากมีเรื่องเลวร้ายเกิดขึ้นและไม่ได้เกี่ยวข้องกับฉัน นั่นหมายความว่าฉันปลอดภัยแล้ว” แน่นอนว่าฉันเดาว่ามันถูกต้องในระดับหนึ่ง แต่ก็ยังขาดจุดรวมของการเป็นทีมด้วย เราชนะเป็นทีมและเราแพ้เป็นทีม มีสาเหตุบางประการที่ทำให้การพัฒนาซอฟต์แวร์เป็นกีฬาประเภททีม ผมจะอธิบายเหตุผลบางประการ:
- เราสามารถทำงานร่วมกันในการออกแบบโค้ดได้ สองหัวย่อมดีกว่าหัวเดียว
- หากผู้คนติดขัด บางครั้งการพูดคุยกับผู้อื่นก็ช่วยได้
- คนอื่นอาจเคยลองสิ่งที่คล้ายกันในอดีตแต่ไม่ได้ผล พวกเขาสามารถอธิบายได้ว่าทำไม
โดยธรรมชาติแล้วจำนวนองค์กรต่างๆ ตั้งค่าพื้นที่เก็บข้อมูลของตน โดยทั่วไปแล้วคุณจะต้องมีบุคคลอื่นอย่างน้อย 2 คนเพื่อตรวจสอบโค้ดของคุณและบอกว่าเป็นการดีที่จะรวมเข้าด้วยกัน หากคนที่ทำการตรวจสอบนั้นกำลังทำงานของพวกเขาอยู่ แล้วเป็นไปได้อย่างไรที่เราจะเริ่มเกมตำหนิและชี้นิ้วไปที่บุคคลที่ทำการเปลี่ยนแปลงโดยตรง โดยทั่วไปแล้วเราจะพลาดข้อเท็จจริงที่ว่าควรมีอย่างน้อยสามคนที่ควรจับประเด็นนี้ ไม่ใช่คนเดียว แต่ถึงอย่างนั้นก็เป็นการหลีกเลี่ยงประเด็น
นักพัฒนาส่วนใหญ่ที่ภาคภูมิใจในงานของตนจะไม่เพียงแต่ “มองข้าม” ปัญหาที่พวกเขาก่อขึ้นเท่านั้น ในอดีตเมื่อฉันทำผิดพลาด ฉันก็เป็นศัตรูตัวฉกาจที่สุด ฉันจะไตร่ตรองและเอาชนะตัวเองกับความผิดพลาดที่เกิดขึ้นเพื่อพิจารณาว่าฉันจะทดสอบหรือวางแผนให้ดีขึ้นได้อย่างไร เพื่อที่ฉันจะได้ไม่ทำผิดพลาดแบบเดิมอีก ฉันไม่ต้องการให้คนอื่นกระโดดขึ้นไปบนเกวียนเพื่อชี้ให้เห็นว่าฉันทำไปแล้ว นั่นแค่ช่วยขุดคุณลงไปในหลุมที่ลึกลงไปอีก ทีมจะคอยช่วยเหลือซึ่งกันและกันเมื่อเราล้มลง ไม่ฝังลึกลงไปอีก
ฉันยังจำวันหนึ่งในสำนักงานได้เมื่อข้อผิดพลาดในการโหลดข้อมูลพุ่งเข้าสู่ระบบ โดยพื้นฐานแล้วเรามีการเปลี่ยนแปลงสองครั้งที่อยู่ในพื้นที่ที่คล้ายกันมาก (ไม่ได้ช่วยให้การเปลี่ยนแปลงเหล่านั้นอยู่ในแพ็คเกจ SSIS ซึ่งไม่สามารถรวมเข้าด้วยกันได้) เมื่อรวมเข้ากับสาขาหลักแล้ว การทดสอบการสร้าง/อัตโนมัติของการโหลดข้อมูลก็เริ่มล้มเหลว อย่างแรกเลย นี่มันเยี่ยมมาก! ระบบอัตโนมัติของเราพบปัญหาก่อนที่จะเข้าสู่การใช้งานจริง และแล้วเกมโทษก็เกิดขึ้น เนื่องจากคนสองคนอยู่ในทีมสปรินต์ที่แตกต่างกันสองทีม มันจึงกลายเป็นประเด็นทางการเมืองเล็กน้อยที่ว่า “ใครเป็นคนทำ คุณจึงต้องแก้ไข” ส่วนที่แย่ที่สุดคือ นักพัฒนาที่กล่าวโทษรู้สึกเหมือนกำลังกระหายเลือด เป็นเป้าหมายของการโจมตี เพื่อนร่วมทีมของผมที่เป็นนักพัฒนาที่พูดจานุ่มนวลมากกว่า ดังนั้นพวกเขาจึงไม่ปกป้องตัวเอง พวกเขาพ่ายแพ้และถูกทุบตี
เมื่อถึงจุดนั้น ฉันก็แค่พูด และพูดต่อว่า “ฉันไม่สนใจว่าใครเป็นคนเขียนโค้ด ตอนนี้เราอยู่ตรงนี้แหละ เราจะแก้ไขมันอย่างไร” ในที่สุด หลังจากยืนกรานที่จะค้นหาข้อผิดพลาดประมาณ 10 นาที เราก็เข้าสู่ขั้นตอน "ฉันจะแก้ไขได้อย่างไร" จนถึงทุกวันนี้ ฉันไม่เห็นคุณค่าใด ๆ ในการสนทนาที่ดำเนินไปนานเกินไปในการหาข้อตำหนิ มันเป็นเพียงการเสียเวลา
ฉันยังมีบางคนที่ถามฉันว่า “ใครเป็นคนทำการเปลี่ยนแปลง” เมื่อมีการพบจุดบกพร่อง คำตอบของฉันคือ “ไม่สำคัญ” หรือ “ฉันไม่รู้” เสมอ ใช่ ถ้าฉันต้องการจริงๆ ฉันสามารถรู้ได้ แต่สำหรับการพัฒนาแอปพลิเคชัน มันไม่สำคัญเลยจริงๆ ทั้งหมดนี้จะทำให้ภาพลักษณ์ของนักพัฒนาเสื่อมเสียในสายตาของพวกเขา เมื่อทั้งทีมของฉันคือคนที่ยอมรับการเปลี่ยนแปลงนี้
เกมตำหนิไม่ได้ทำอะไรเลยนอกจากสร้างความเสียหายให้กับผู้พัฒนารายอื่นเพื่อสร้างเกมอื่นขึ้นมา และควรหลีกเลี่ยงไม่ว่าจะด้วยวิธีใดก็ตาม เมื่ออยู่ในสถานการณ์ที่ตรวจพบปัญหา อย่าถามว่า “ใครเป็นคนก่อ” แต่ถามอย่างสร้างสรรค์ว่า “เราจะทำอย่างไรเพื่อแก้ไขมัน” สิ่งนี้จะช่วยนำไปสู่การสนทนาที่ดีต่อสุขภาพมากขึ้น
เผยแพร่ครั้งแรกที่ https://blog.judd.dev.
