23 KiB
BRN WMS (200-WMS-26-001-00) — บทเล่าเรื่องสำหรับวันตรวจประเมิน ISO/IEC 29110
เอกสารช่วยจำสำหรับทีม ใช้เล่าเรื่องโครงการต่อผู้ตรวจประเมินตั้งแต่เปิดจนปิดโครงการ ทุกประโยคต้องชี้ไปที่เอกสารจริงได้ทันที ถ้าผู้ตรวจถามสิ่งที่ไม่มีในเอกสาร ให้ตอบตามจริงว่า "ไม่ได้บันทึกไว้" ห้ามแต่งเพิ่ม
วิธีใช้
- เล่าตามลำดับบทที่ 1–8 ใช้เวลารวมประมาณ 25–30 นาที แล้วเปิดให้ผู้ตรวจเลือกเส้นสอบกลับเอง
- แต่ละบทมี ผู้เล่า เอกสารที่เปิด และ ประโยคหลัก ให้เปิดเอกสารบนจอก่อนพูดทุกครั้ง
- ผู้เข้าตรวจมี 2 คน: PM (ApS) เล่ากระบวนการบริหารโครงการ (PM) และ SA (NoC) เล่ากระบวนการพัฒนา (SI)
- งานของ Developer (ThS), QA (PaNg), Document Control (YaB) และ Project Sponsor (SeV) ให้เล่าจากบันทึก โดยอ้างชื่อผู้รับผิดชอบตามเอกสาร เช่น "ตาม Test Report ที่คุณปริญ (PaNg) บันทึก…" ห้ามตอบแทนในเรื่องที่บันทึกไม่ได้ระบุ ให้ตอบว่าจะประสานผู้รับผิดชอบ
- แบ่งงานตอนผู้ตรวจถาม: คำถามเรื่องแผน ความก้าวหน้า ความเสี่ยง การเปลี่ยนแปลง การตรวจรับ → PM; ความต้องการ การออกแบบ Code การทดสอบ การสอบกลับ → SA
โครงเรื่องในหนึ่งย่อหน้า
โครงการพัฒนาระบบบริหารจัดการคลังสินค้า 11 ระบบงาน ระยะเวลา 232 วัน (5 ม.ค. – 24 ส.ค. 69) ทีม 6 คน เราตั้ง Baseline ความต้องการ 80 รายการก่อนเริ่มพัฒนา ควบคุมงานด้วยรายงานความก้าวหน้า 15 งวดและการประชุม 11 ครั้ง ตรวจสอบเอกสาร 4 รอบ ทดสอบ 45 Test Case แล้ว พบข้อบกพร่องระดับสูง 4 รายการ ซึ่งเราบันทึกตามจริง แจ้งผู้รับมอบ และผู้รับมอบตรวจรับแบบมีเงื่อนไขให้แก้ไขภายใต้การบำรุงรักษา — เรื่องนี้คือจุดแข็งของกระบวนการ ไม่ใช่จุดอ่อน
เส้นเวลา (ใช้เปิดเรื่อง)
| ช่วงเวลา | เหตุการณ์สำคัญ | หลักฐาน |
|---|---|---|
| 5 ม.ค. 69 | ประชุมเปิดโครงการ | Statement of Work, Minutes of Meeting 5 ม.ค. |
| 16–23 ม.ค. 69 | ระบุผู้มีส่วนได้ส่วนเสีย อนุมัติกฎบัตร | Stakeholder Register, Project Charter, MoM 23 ม.ค. |
| 6–18 ก.พ. 69 | ความต้องการ 80 รายการ แผนโครงการ ตั้ง Baseline | Customer Requirements, Software Project Plan, Work Schedule, MoM 18 ก.พ. |
| 19 ก.พ. – 29 พ.ค. 69 | ออกแบบและพัฒนา ตั้ง Baseline การพัฒนา 29 พ.ค. (a0677d6) |
SRS, Software Design, Correction Register ISS-001–027 |
| 17 มี.ค. / 29 พ.ค. / 31 ก.ค. / 17 ส.ค. 69 | ตรวจสอบเอกสาร 4 รอบ (3+3+3+6 ชม.) | Verification Results V0.1–V1.0 |
| 31 ก.ค. 69 | Test Case 45 รายการ และ Traceability Record | Test Case and Test Procedures, Traceability Record |
| 3–10 ส.ค. 69 | แก้ไขหลัง Baseline (ISS-028) และอนุมัติแผนทดสอบ | Correction Register, MoM 10 ส.ค. |
| 10–14 ส.ค. 69 | ทดสอบระบบและ UAT บน Build b2c4374 |
Test Report, Validation Results |
| 17 ส.ค. 69 | ชุดติดตั้ง Docker และ Baseline ส่งมอบ 6c39700; ตรวจสอบรอบที่ 4 |
Software Configuration, Verification Results V1.0 |
| 19 ส.ค. 69 | ประชุมสรุปผลทดสอบและ UAT | MoM 19 ส.ค. |
| 22–23 ส.ค. 69 | อบรมผู้ใช้ 6 คน ปิดงานควบคุมปฏิบัติการ OP-001/OP-002 | Training Report, Product Operation Guide |
| 24 ส.ค. 69 | ตรวจรับแบบมีเงื่อนไขและปิดโครงการ | Acceptance Report, MoM 24 ส.ค., List of Evidence |
บทที่ 1 — ทำไมต้องมีโครงการนี้ และใครเกี่ยวข้อง
ผู้เล่า: PM (ApS) เปิด: Statement of Work → Project Charter Report → Stakeholder Register → Software Project Plan §5
ประโยคหลัก
- "บริษัทบันทึกคลังสินค้าแยกจากงานขายและบัญชี ยอดไม่ตรงกัน เราจึงตั้งโครงการรวม 11 ระบบงานไว้ในระบบเดียว ระยะเวลา 232 วัน"
- "ผู้มีส่วนได้ส่วนเสียมี 10 กลุ่ม คือทีม 6 คน และผู้ใช้ 4 กลุ่ม — ฝ่ายคลัง ฝ่ายขาย/จัดซื้อ ฝ่ายบัญชี และผู้ดูแลระบบ รายชื่อชุดเดียวกันอยู่ทั้งใน Stakeholder Register และ Software Project Plan §5.1–5.2"
ถ้าถูกถาม: "ใครอนุมัติขอบเขต?" → Project Sponsor (SeV) อนุมัติกฎบัตรในการประชุม 23 ม.ค. 69 เปิด Project Charter หน้าลงนามและ MoM 23 ม.ค.
บทที่ 2 — วางแผนและตั้ง Baseline ก่อนลงมือ
ผู้เล่า: SA (NoC) เล่าความต้องการ แล้วส่งต่อ PM (ApS) เล่าแผนและความเสี่ยง เปิด: Customer Requirements → Software Project Plan §6–§9 → Work Schedule → MoM 18 ก.พ.
ประโยคหลัก
- "เราเก็บความต้องการ 80 รายการใน 14 หมวด (CR01–CR14) ลูกค้าสรุปผลยอมรับทุกรายการ แล้วตั้ง Baseline ในการประชุม 18 ก.พ. 69 ก่อนเริ่มพัฒนา 19 ก.พ."
- "แผนกำหนดความเสี่ยง 8 ข้อ (R1–R8) และแผนตรวจสอบ 4 รอบ รวม 15 ชั่วโมง ตามข้อแนะนำให้ตรวจราวทุก 2 เดือน"
ถ้าถูกถาม: "ความเสี่ยงไหนเกิดจริง?" → R1 (ความต้องการเปลี่ยนระหว่างพัฒนา) เกิดจริงในเรื่อง Rack → Bin (บทที่ 4) และ R4/R5 (ข้อมูลรั่วข้ามบริษัท, ความลับรั่ว) ปรากฏเป็นข้อบกพร่อง ISS-031/ISS-032 ในรอบทดสอบ (บทที่ 6)
บทที่ 3 — พัฒนาและควบคุมงาน
ผู้เล่า: PM (ApS) เล่าการติดตามงาน แล้วส่งต่อ SA (NoC) เล่าการพัฒนาและการควบคุม Source Code เปิด: Progress Status Record (เลือก 1 งวด) → Minutes of Meeting ที่แนบ → Correction Register → Software Configuration
ประโยคหลัก
- "เราออกรายงานความก้าวหน้า 15 งวด ทุกฉบับถูกนำเสนอในการประชุมที่มีรายงานการประชุมรองรับ ดูได้จากช่อง 'สิ่งแนบ' ของรายงานการประชุม"
- "การประชุมแต่ละครั้งจัดในวันทำการ หลังงานที่ทบทวนเสร็จอย่างน้อย 5 วัน เพื่อให้มีเวลาตรวจผลงานก่อนรายงานว่าเสร็จ"
- "ข้อบกพร่องที่พบระหว่างพัฒนา 28 รายการ (ISS-001–028) ทุกรายการเชื่อมกับ Commit ที่แก้และ Test Case ที่ใช้ตรวจ"
- "Source Code อยู่บน Branch
mainเท่านั้น สำรองไปยัง Backup Remote ตั้ง Baseline การพัฒนา 29 พ.ค. และ Baseline ส่งมอบ6c39700"
ตัวอย่างที่ควรเปิดให้ดู: PSR 17 มี.ค. 69 → นำเสนอในการประชุม 23 มี.ค. 69 ซึ่งทบทวนงาน Security & Database (Commit สุดท้าย 17 มี.ค.)
บทที่ 4 — การควบคุมการเปลี่ยนแปลง
ผู้เล่า: PM (ApS) เปิด: Change Report ส่วนที่ 1–3 → MoM 18 พ.ค. → Correction Register ISS-023
ประโยคหลัก
- "เราใช้เกณฑ์ว่า 'ถ้าไม่ทำ ยังส่งมอบได้หรือไม่' ถ้ายังส่งมอบได้ ไม่ถือเป็นคำขอเปลี่ยนแปลง แต่บันทึกการพิจารณาไว้ทุกเรื่อง"
- "มี 3 เรื่องที่ผ่านการพิจารณา ไม่มีเรื่องใดเข้าเกณฑ์ จึงไม่มีคำขอเปลี่ยนแปลงตลอดโครงการ"
- "ตัวอย่าง: ที่ประชุม 18 พ.ค. มีมติเปลี่ยนคำว่า Rack เป็น Bin ทั้งระบบ เป็นการเปลี่ยนคำเรียก ไม่เพิ่มฟังก์ชัน ไม่กระทบ Man-day
ทีมแก้ใน Commit
8f57ab5(27 พ.ค.) และพบว่าเปลี่ยนไม่ครบ จึงบันทึก ISS-023 และแก้ใน5df6736(28 พ.ค.)"
ถ้าถูกถาม: "8 เดือนไม่มี CR เลยหรือ?" → เปิดเกณฑ์ใน Change Report ส่วนที่ 1 แล้วไล่ทั้ง 3 เรื่องด้วยคำถามเดียวกัน
บทที่ 5 — ตรวจสอบเอกสาร (Verification)
ผู้เล่า: SA (NoC) — ผู้ตรวจในบันทึกคือ PaNg และ NoC ส่วน YaB ควบคุมเอกสาร เปิด: Software Project Plan §8.1 → Verification Results V0.1, V0.2, V0.3, V1.0
ประโยคหลัก
- "ตรวจสอบตามแผน 4 รอบ: 17 มี.ค. (แผนและความต้องการ), 29 พ.ค. (SRS และการออกแบบ), 31 ก.ค. (ชุดทดสอบและการสอบกลับ), 17 ส.ค. (ทุกสิ่งส่งมอบ)"
- "รอบสุดท้ายเราบันทึก ไม่ผ่าน 2 รายการ คือผลการทดสอบที่ยังมีข้อบกพร่องคงค้าง และชุดติดตั้ง Docker ที่ยังไม่ได้ทดสอบ แล้วเสนอให้ตรวจรับพร้อมแผนแก้ไข"
บทที่ 6 — ทดสอบระบบและทดสอบการยอมรับ
ผู้เล่า: SA (NoC) — ผู้ทดสอบในบันทึกคือ PaNg (ทดสอบระบบ) และ SeV (UAT) เปิด: Test Case and Test Procedures → Traceability Record → Test Report → Validation Results → Correction Register ISS-029–032
ประโยคหลัก
- "Test Case 45 รายการ หนึ่งรายการต่อหนึ่ง Software Unit จัดทำพร้อม Traceability Record เมื่อ 31 ก.ค. 69"
- "ทดสอบ 10–14 ส.ค. 69 บน Build
b2c4374— ทดสอบได้ 43 รายการ ผ่าน 38 ไม่ผ่าน 5 อีก 2 รายการ (ชุดติดตั้ง Docker) ยังไม่ได้ทดสอบ เพราะส่งมอบหลังรอบทดสอบเมื่อ 17 ส.ค." - "ข้อบกพร่องที่พบบันทึกเป็น ISS-029–032 ระดับสูงทั้งหมด: ไฟล์แนบเปิดได้จาก URL (ISS-029), การผ่าน GL ไม่อยู่ใน Transaction เดียวกับเอกสาร (ISS-030), Socket.IO ไม่ตรวจ Session (ISS-031), ค่าความลับในแม่แบบค่าตั้งค่า (ISS-032)"
- "UAT ทำคู่ขนานกับการทดสอบระบบตามมติที่ประชุม 10 ส.ค. ซึ่งต่างจากเกณฑ์เข้าสู่ UAT ในเอกสาร Test Case — เราบันทึกความต่างนี้ไว้ใน Validation Results ผลคือความต้องการ 80 รายการ ผ่าน 60 ไม่ผ่าน 11 ยังไม่ได้ทดสอบ 5 และรอดำเนินการตามแผน 4"
ถ้าถูกถาม: "ทำไมไม่แก้ก่อนส่งมอบ?" → ข้อบกพร่องพบในสัปดาห์สุดท้ายของโครงการ เราเลือกบันทึกและแจ้งผู้รับมอบตามจริง แทนการแก้เร่งรีบโดยไม่มีรอบทดสอบซ้ำ ผู้รับมอบจึงกำหนดเป็นเงื่อนไขการตรวจรับ (บทที่ 7)
บทที่ 7 — ส่งมอบ ตรวจรับ และปิดโครงการ
ผู้เล่า: PM (ApS) — การตัดสินใจตรวจรับเป็นของ SeV ให้เล่าตามที่บันทึกใน Acceptance Report และ MoM 24 ส.ค. เปิด: MoM 19 ส.ค. → Training Report → Product Operation Guide (OP-001/OP-002) → Acceptance Report → MoM 24 ส.ค. → List of Evidence
ประโยคหลัก
- "ประชุม 19 ส.ค. สรุปผลทดสอบ ผู้รับมอบรับทราบข้อบกพร่องและขอแผนแก้ไขก่อนตรวจรับ"
- "อบรมผู้ใช้ 6 คนเมื่อ 22 ส.ค. ปิดงานสำรองข้อมูลอัตโนมัติและการเฝ้าระวังเมื่อ 23 ส.ค."
- "24 ส.ค. ผู้รับมอบตรวจรับ แบบมีเงื่อนไข: (1) แก้ ISS-029–032 และทดสอบซ้ำภายใต้การบำรุงรักษาแบบแก้ไข (2) ทดสอบ TC-UN13.002–003 ก่อนใช้ชุดติดตั้ง Docker ในสภาพแวดล้อมจริง — กำหนดติดตามใน Action Item ของการประชุม 24 ส.ค."
ต้องเตรียม: สถานะปัจจุบันของการแก้ไข ISS-029–032 (ผู้ตรวจจะถามแน่นอน) — ตอบตามความคืบหน้าจริง ณ วันตรวจ
บทที่ 8 — สิ่งที่เราเรียนรู้
ผู้เล่า: PM (ApS) เปิด: Correction Register ส่วน Lessons Learned
ประโยคหลัก
- "ข้อบกพร่องทั้ง 32 รายการจัดเป็น 5 กลุ่มสาเหตุ กลุ่มใหญ่ที่สุดคือความปลอดภัยและการควบคุมสิทธิ์ (15 รายการ รวม ISS-029, 031, 032)"
- "โครงการถัดไปเราจะกำหนด Secure Coding Checklist และรูปแบบการตรวจสิทธิ์กลางตั้งแต่ช่วงออกแบบ และตามข้อแนะนำของที่ปรึกษา จะให้ PM กับ SI เดินผ่านโปรแกรมทั้งระบบพร้อม Document Control ก่อนรอบทดสอบ"
เส้นสอบกลับสำหรับสาธิต (ซ้อมให้คล่อง)
ผู้เล่า: SA (NoC) เปิดเอกสารตามลำดับในตาราง PM (ApS) เสริมเฉพาะขั้นการยอมรับและเงื่อนไขการตรวจรับ
เส้นที่ผ่าน — สต๊อกต้องไม่ติดลบ
| ขั้น | รายการ | เอกสาร |
|---|---|---|
| ความต้องการ | CR01:008 บันทึกการจ่ายสินค้าออกโดยตรวจสิทธิ์และยอดคงเหลือ | Customer Requirements |
| ความต้องการซอฟต์แวร์ | SR03:004, SR09:003 | SRS |
| การออกแบบ | UN04.002 ICS – Stock-out (StockManager.php, OrderManager.php) |
Software Design |
| ข้อบกพร่องระหว่างพัฒนา | ISS-002 พบ 18 เม.ย. แก้ใน 92d116f 24 เม.ย. |
Correction Register |
| การทดสอบ | TC-UN04.002 → Passed | Test Case, Test Report |
| การยอมรับ | CR01:008 → Passed | Validation Results |
เส้นที่ไม่ผ่าน — ความถูกต้องของ Transaction
| ขั้น | รายการ | เอกสาร |
|---|---|---|
| ความต้องการ | CR13:001 เอกสาร + สต๊อก + GL ต้องเป็น Transaction เดียวกัน | Customer Requirements |
| ความต้องการซอฟต์แวร์ | SR09:003 | SRS |
| การออกแบบ | UN08.002 Journal & GL Posting | Software Design |
| การทดสอบ | TC-UN08.002 → Failed (เอกสารไม่ถูก Rollback เมื่อการผ่าน GL ล้มเหลว) | Test Report |
| ข้อบกพร่อง | ISS-030 คงค้าง | Correction Register |
| การยอมรับ | CR13:001 → Failed → เงื่อนไขการตรวจรับข้อ (1) | Validation Results, Acceptance Report |
เรื่องที่ต้องพูดตรง ๆ
| ประเด็น | คำตอบสั้น |
|---|---|
| ไม่มีคำขอเปลี่ยนแปลงตลอดโครงการ | มีการพิจารณา 3 เรื่องตามเกณฑ์ ไม่มีเรื่องใดเข้าเกณฑ์ หลักฐานอยู่ใน Change Report และรายงานการประชุม |
| ข้อบกพร่องคงค้างตอนตรวจรับ | บันทึกตามจริง แจ้งผู้รับมอบ และตรวจรับแบบมีเงื่อนไข — ห้ามบอกว่าแก้เสร็จก่อน 24 ส.ค. |
| UAT ไม่เป็นไปตามเกณฑ์เข้า | ผู้สนับสนุนโครงการอนุมัติให้ทำคู่ขนานในการประชุม 10 ส.ค. และบันทึกความต่างไว้ใน Validation Results |
| ชุดติดตั้ง Docker ยังไม่ได้ทดสอบ | ส่งมอบหลังรอบทดสอบ เป็นเงื่อนไขการตรวจรับข้อ (2) |
Baseline ส่งมอบ 6c39700 ไม่ใช่ Build ที่ทดสอบ |
Build ที่ทดสอบคือ b2c4374 ส่วนที่เพิ่มหลังจากนั้นคือข้อมูลสาธิตและชุดติดตั้ง Docker ซึ่งระบุไว้ในเงื่อนไข |
สิ่งที่ห้ามทำในวันตรวจ
- ห้ามแก้ไขหรือเติมเอกสารย้อนหลัง ถ้ามีบันทึกใหม่ให้ลงวันที่จริง
- ห้ามตอบเกินกว่าที่เอกสารบันทึกไว้ ถ้าไม่แน่ใจให้บอกว่า "ขอตรวจสอบเอกสารก่อน" แล้วเปิดดู
- ห้ามอ้าง Commit, Branch หรือเอกสารที่เกิดหลังวันที่ของเอกสารที่กำลังพูดถึง