Leveraging Checklists (การใช้ประโยชน์จากเช็คลิสต์)
นักบินเครื่องบินโดยสารใช้เช็คลิสต์ในทุกเที่ยวบิน แม้แต่นักบินผู้เชี่ยวชาญที่มีประสบการณ์สูงสุดก็ยังมีเช็คลิสต์สำหรับการขึ้นบิน การลงจอด และสถานการณ์อื่นๆ อีกนับพัน ทั้งกรณีทั่วไปและกรณีขอบที่ผิดปกติ พวกเขาใช้เช็คลิสต์เพราะการตั้งค่าหรือขั้นตอนของเครื่องบินที่พลาดไปเพียงจุดเดียว (เช่น ลืมตั้งแฟลปให้อยู่ที่ 10 องศาก่อนขึ้นบิน) อาจหมายถึงความแตกต่างระหว่างเที่ยวบินที่ปลอดภัยกับหายนะ
ในหนังสือชื่อดังของ Dr. Atul Gawande เรื่อง The Checklist Manifesto (Picador, 2011) เขาอธิบายถึงพลังของเช็คลิสต์ในการทำให้ขั้นตอนการผ่าตัดปลอดภัยขึ้น เมื่อรู้สึกตกใจกับอัตราการติดเชื้อสแตฟฟิโลค็อกคัสที่สูงในโรงพยาบาล Dr. Gawande จึงสร้างเช็คลิสต์สำหรับการผ่าตัดขึ้นมา อัตราการติดเชื้อในโรงพยาบาลที่ใช้เช็คลิสต์ลดลงจนเกือบเป็นศูนย์ ในขณะที่อัตราการติดเชื้อในโรงพยาบาลกลุ่มควบคุมที่ไม่ได้ใช้เช็คลิสต์ยังคงเพิ่มขึ้นต่อไป
เช็คลิสต์ได้ผลจริง มันเป็นเครื่องมือที่ยอดเยี่ยมในการทำให้แน่ใจว่างานทุกอย่างได้รับการครอบคลุมและจัดการแล้ว แล้วทำไมอุตสาหกรรมพัฒนาซอฟต์แวร์ถึงไม่ใช้ประโยชน์จากมันด้วยล่ะ? จากการทำงานในอุตสาหกรรมนี้มาหลายปี เราเชื่อมั่นอย่างยิ่งว่าเช็คลิสต์สร้าง ความแตกต่างอย่างมากต่อประสิทธิภาพของทีมพัฒนา แน่นอนว่านักพัฒนาซอฟต์แวร์ส่วนใหญ่ไม่ได้จัดการกับเรื่องเป็นตายอย่างการบินเครื่องบินโดยสาร หรือการผ่าตัดหัวใจแบบเปิด กล่าวอีกนัยหนึ่งคือ นักพัฒนาซอฟต์แวร์ไม่จำเป็นต้องใช้เช็คลิสต์สำหรับทุกสิ่ง กุญแจสำคัญคือการรู้ว่าเมื่อไหร่ควรใช้และเมื่อไหร่ไม่ควรใช้
Figure 24-9 ไม่ใช่เช็คลิสต์ แต่เป็นชุดขั้นตอนตามลำดับสำหรับการสร้างตารางฐานข้อมูลใหม่ ดังนั้นจึงไม่ควรอยู่ในรูปแบบเช็คลิสต์ งานบางส่วนของมันมีความสัมพันธ์กัน ตัวอย่างเช่น ตารางฐานข้อมูลจะตรวจสอบไม่ได้หากยังไม่ได้ส่งฟอร์ม กระบวนการใดๆ ที่มีลำดับขั้นตอนที่ต้องพึ่งพากันไม่ควรอยู่ในรูปแบบเช็คลิสต์ เช่นเดียวกับกระบวนการที่ง่าย คุ้นเคย และดำเนินการบ่อยครั้งโดยไม่มีข้อผิดพลาด
Figure 24-9. ตัวอย่างของเช็คลิสต์ที่ไม่ดี
ตัวเลือกที่ดีสำหรับเช็คลิสต์คือกระบวนการที่ไม่มีลำดับขั้นตอนตายตัวหรือมีงานที่ต้องพึ่งพากัน รวมถึงกระบวนการที่ผู้คนมักข้ามขั้นตอนหรือทำผิดพลาดบ่อยๆ อย่าหักโหมจนเริ่มทำทุกอย่างให้เป็นเช็คลิสต์ สถาปนิกมักทำแบบนี้เมื่อพบว่าเช็คลิสต์ช่วยให้ทีมพัฒนามีประสิทธิภาพมากขึ้นจริงๆ พวกเขาเสี่ยงที่จะเจอกับสิ่งที่เรียกว่า Law of Diminishing Returns ยิ่งสถาปนิกสร้างเช็คลิสต์มากเท่าไหร่ นักพัฒนาก็ยิ่งมีแนวโน้มจะใช้มันน้อยลงเท่านั้น การทำเช็คลิสต์ให้สั้นที่สุดเท่าที่จะทำได้ โดยยังคงครอบคลุมขั้นตอนที่จำเป็นทั้งหมดก็เป็นเรื่องที่ฉลาด นักพัฒนาโดยทั่วไปจะไม่ทำตามเช็คลิสต์ที่ยาวเกินไป ถ้างานใดในรายการสามารถ automate ได้ ให้ automate มันและเอาออกจากเช็คลิสต์
Note (หมายเหตุ)
อย่ากังวลว่าจะพูดถึงสิ่งที่ชัดเจนอยู่แล้วในเช็คลิสต์ สิ่งที่ชัดเจนมักเป็นสิ่งที่ถูกมองข้ามบ่อยที่สุด
เช็คลิสต์สามชุดที่เราพบว่าเป็นประโยชน์มากที่สุดครอบคลุมเรื่องการทำโค้ดของนักพัฒนาให้เสร็จสมบูรณ์ การทดสอบยูนิตและฟังก์ชัน และการปล่อยซอฟต์แวร์ เราจะพูดถึงเช็คลิสต์แต่ละชุดในหัวข้อถัดไป