การตรวจสอบซอฟต์แวร์ หรือที่มักเรียกว่าการตรวจสอบสถาปัตยกรรม (architecture review) อาจหมายถึงอะไรก็ได้ตั้งแต่การไล่ดูโค้ดคร่าวๆ ไปจนถึงการศึกษาเป็นเดือนๆ ที่เต็มไปด้วยแผนผัง รูปแบบนั้นสำคัญน้อยกว่าผลลัพธ์ที่ได้ การตรวจสอบที่มีประโยชน์จะช่วยให้ผู้มีอำนาจตัดสินใจเข้าใจว่าระบบทำงานอย่างไรจริงๆ จุดไหนที่เปราะบาง อะไรที่จำกัดทางเลือกของพวกเขา และควรแก้ไขอะไรก่อน
ตกลงเรื่องคำถามให้ชัดเจนก่อน
การตรวจสอบทุกครั้งควรเริ่มด้วยเหตุผลที่ชัดเจน ธุรกิจกำลังจะเติบโตอย่างรวดเร็วใช่หรือไม่? ระบบที่ผ่านมาไม่น่าเชื่อถือใช่ไหม? มีคนเสนอให้สร้างระบบใหม่หรือเปล่า? คุณเพิ่งซื้อบริษัทและได้รับซอฟต์แวร์ต่อมาใช่ไหม? หรือโครงการต่างๆ ใช้เวลานานกว่าที่ควรจะเป็นมาก?
หากไม่มีคำถามที่ชัดเจน การตรวจสอบจะกลายเป็นเพียงรายการสิ่งที่น่าสนใจแทนที่จะเป็นสิ่งที่สำคัญจริงๆ และจะมีการตกลงขอบเขตล่วงหน้า: ระบบใดบ้างที่รวมอยู่ด้วย จะคุยกับใคร และมีเวลาเท่าไหร่ การตรวจสอบสั้นๆ ไม่สามารถเช็กได้ทุกอย่าง แต่สามารถระบุอย่างตรงไปตรงมาว่าได้ดูอะไรไปบ้างและไม่ได้ดูอะไรบ้าง
ติดตามการทำงานจริงผ่านระบบ
แผนผังนั้นมีประโยชน์ แต่มันแสดงให้เห็นว่าระบบควรจะทำงานอย่างไร ซึ่งอาจไม่ตรงกับที่เป็นอยู่ในปัจจุบัน ดังนั้นจึงมักจะติดตามงานสำคัญในแต่ละวันตั้งแต่ต้นจนจบ: การสั่งซื้อ การสแกนส่งของ การปิดงบเดือน โดยดูทุกระบบและทุกขั้นตอนที่เกี่ยวข้อง และเงื่อนไขที่จำเป็นเพื่อให้งานนั้นสำเร็จ
ยังต้องมองไปไกลกว่าแค่ตัวโค้ด มีการปล่อยตัวอัปเดตอย่างไร? มีการสำรองข้อมูลไหม และมีใครเคยลองกู้คืนข้อมูลจริงๆ หรือยัง? ใครจะเป็นคนรับสายเมื่อมีอะไรเสียตอนตีสอง? นิสัยการทำงานในแต่ละวันเหล่านี้มักเป็นตัวกำหนดว่าระบบจะน่าเชื่อถือเพียงใด แผนผังที่สวยงามจะไม่มีประโยชน์เลยหากไม่มีใครรู้ว่าการสำรองข้อมูลใช้งานได้จริงหรือไม่
แยกข้อเท็จจริงออกจากการคาดเดา
การตรวจสอบที่ดีต้องชัดเจนว่าพบอะไร สงสัยอะไร และอะไรที่ยังยืนยันไม่ได้ "ไม่มีการพยายามส่งใหม่โดยอัตโนมัติเมื่อการเชื่อมต่อหลุด" คือข้อเท็จจริง "คำสั่งซื้ออาจสูญหายหากการเชื่อมต่อหลุด" คือความเสี่ยงที่อาจเกิดขึ้น "เรายังไม่ได้ทดสอบว่าจะเกิดอะไรขึ้นหากการเชื่อมต่อหลุด" คือคำถามที่ยังไม่มีคำตอบ การแยกแยะสิ่งเหล่านี้จะช่วยไม่ให้การคาดเดาถูกนำไปปฏิบัติเหมือนเป็นปัญหาที่ยืนยันแล้ว
เมื่อทำได้ จะสนับสนุนสิ่งที่พบด้วยหลักฐาน: การทดสอบ บันทึกเหตุการณ์ (log) เหตุการณ์ในอดีต หรือโค้ดส่วนที่เกี่ยวข้อง หากทำไม่ได้ก็จะระบุไว้ตรงๆ เพื่อให้ธุรกิจตัดสินใจได้ว่าจะเจาะลึกต่อ ยอมรับความเสี่ยง หรือแก้ไขมัน
เรียงลำดับตามความสำคัญ
รายการปัญหายาวเหยียดไม่ใช่แผนงาน มักจะจัดกลุ่มปัญหาตามผลกระทบต่อธุรกิจ โอกาสที่จะเกิด ความเร่งด่วน และต้นทุนในการแก้ไข เรื่องความปลอดภัยและความถูกต้องของข้อมูลมีความสำคัญพอๆ กับความเร็ว ความง่ายในการแก้ไข และความน่าเชื่อถือ โค้ดที่ยุ่งเหยิงอาจเป็นปัญหาจริง แต่มันสำคัญน้อยกว่ากระบวนการสำรองข้อมูลที่ไม่มีใครเคยทดสอบเลย
มักจะหลีกเลี่ยงระบบการให้คะแนนที่ดูเหมือนแม่นยำแต่จริงๆ แล้วไม่ใช่ การอธิบายตรงๆ ว่าอะไรอาจเกิดขึ้น ร้ายแรงแค่ไหน และมั่นใจเพียงใด มักจะมีประโยชน์กว่าตัวเลข นอกจากนี้ยังจะระบุด้วยว่าการแก้ไขหนึ่งต้องพึ่งพาอีกการแก้ไขหนึ่งอย่างไร เพื่อให้ลำดับการทำงานสมเหตุสมผล
จบด้วยขั้นตอนต่อไปที่ชัดเจน
รายงานสรุปที่ดีควรครอบคลุมถึงวิธีการทำงานของระบบ งานสำคัญในแต่ละวัน จุดแข็งที่ควรเก็บไว้ ปัญหาตามลำดับความสำคัญ ทางเลือกต่างๆ และแผนงานเป็นขั้นตอน คำแนะนำแต่ละข้อควรระบุว่าต้องการบรรลุอะไรและจะรู้ได้อย่างไรว่าสำเร็จ "ปรับปรุงการเฝ้าติดตาม" นั้นคลุมเครือเกินไป "รับการแจ้งเตือนหากคำสั่งซื้อไม่ถึงคลังสินค้าภายในหนึ่งชั่วโมง" คือสิ่งที่คุณตรวจสอบได้
รายงานควรระบุด้วยว่าอะไรที่ยังไม่ควรทำ การสร้างระบบใหม่ครั้งใหญ่หรือการย้ายไปแพลตฟอร์มใหม่มักจะเร็วเกินไปจนกว่าคุณจะเข้าใจข้อมูลและรูปแบบการล้มเหลวของระบบ บางครั้งข้อสรุปที่มีค่าที่สุดคือ "รอไว้ก่อน และทำสามสิ่งที่เล็กกว่านี้ก่อน"
ประเด็นสำคัญคือ
คุณค่าของการตรวจสอบอยู่ที่การช่วยให้คุณตัดสินใจได้ คุณไม่ได้ต้องการแผนผังที่สมบูรณ์แบบหรือรายการสิ่งที่ต้องทำที่ยาวขึ้น แต่คุณต้องการความเข้าใจที่ตรงกันเกี่ยวกับระบบ มุมมองต่อความเสี่ยงที่ตรงไปตรงมา และแนวทางที่ชัดเจนและสมเหตุสมผลในการทำให้สิ่งต่างๆ ดีขึ้น