เอกสารประกอบแบบ A-A-Manual และเอกสารประกอบ As-A-Checklist
ฉันเคยพูดคุยกับบุคคลอื่นในแผนกของฉันเกี่ยวกับเอกสารโดยเฉพาะระดับรายละเอียดและข้อกำหนด ในมุมมองของพวกเขาเอกสารเป็นรายการตรวจสอบอย่างง่ายของสิ่ง Y ที่ต้องทำเมื่อสิ่ง X ผิดพลาด ฉันไม่เห็นด้วย. ฉันคิดว่านี่เป็นทึกทักว่าปัญหาทั้งหมดใน IT สามารถถูกต้มลงในรายการตรวจสอบอย่างง่ายของกระบวนการกู้คืน ฉันคิดว่ามันไม่สนใจความซับซ้อนของสถานการณ์อย่างสมบูรณ์และเนื่องจากคนอื่น ๆ ในแผนกไม่ได้มีความเข้าใจอย่างลึกซึ้งเกี่ยวกับปัญหา (ซึ่งเป็นสาเหตุที่ฉันเขียนเอกสาร - ดังนั้นพวกเขาจึงมีบางสิ่งบางอย่างที่จะอ้างถึง ) ว่าเอกสารควรมีเนื้อหาพื้นหลังพื้นฐานบางอย่างเช่น: วัตถุประสงค์ของระบบ (ย่อย) ที่เป็นปัญหา ทำไมมันถูกกำหนดค่าในลักษณะที่ ความคาดหวังของเหตุการณ์ที่จะเกิดขึ้นเมื่อมีการใช้การตั้งค่า / ขั้นตอน ปัญหาที่อาจเกิดขึ้นซึ่งอาจทำให้กระบวนการล้มเหลว อย่างไรก็ตามฉันค่อนข้าง outvoted ในเรื่องนี้ดังนั้นเอกสารของฉันจะต้องเขียนใหม่ในแบบฟอร์มที่ระบุว่า "ขั้นตอน ABC ที่ใช้ในการสั่งซื้อจะแก้ไขปัญหา X" ฉันมักจะได้ยินถึงความโศกเศร้าที่ต้องใส่ลงในกระดาษหน้าเดียว ลองอธิบายการกำหนดค่า Squid ACL ให้กับใครบางคนในลักษณะนี้รวมถึงการแก้ไขปัญหาผ่านเอกสารหน้าเดียว นั่นเป็นเพียงหนึ่งในเอกสารครึ่งโหลที่ "รอการเขียน" เป็นรายการตรวจสอบการกู้คืน เป็นวิธีที่ฉันเรียกร้องให้ลงน้ำจริงๆหรือไม่? หรือว่าถูกต้องและฉันควรคำนึงถึงธุรกิจของฉันที่นี่และเขียนรายการตรวจสอบง่ายๆ ความกังวลของฉันคือว่าไม่ว่าคุณจะเขียนรายการตรวจสอบขั้นตอนได้ดีเพียงใดมันไม่ได้แก้ปัญหาที่ต้องใช้ SysAdmin เพื่อคิดสิ่งต่าง ๆ หากคุณใช้เวลาทำรายการตรวจสอบขั้นตอนการกู้คืนซึ่งไม่สามารถแก้ไขปัญหาได้ (เนื่องจากมีปัจจัยเพิ่มเติมที่ไม่ได้เป็นส่วนหนึ่งของเอกสารเนื่องจากจุดเน้นที่แคบของเอกสาร ) …