วงจรโครงการพัฒนาระบบ ตั้งแต่ TOR จนขึ้นใช้งานจริง

ทำไมต้องเรียนหลักสูตรนี้

โครงการพัฒนาระบบส่วนใหญ่ไม่ได้ล้มเหลวตอนเขียนโค้ด แต่ล้มตั้งแต่ตอนเขียนเอกสารข้อกำหนด แล้วมาระเบิดตอนตรวจรับ

ฝั่งหน่วยงานเขียน TOR ไว้กว้างจนผู้รับจ้างตีความคนละแบบ ฝั่งผู้รับจ้างรับงานมา โดยยังไม่รู้ว่าต้องส่งมอบอะไรกันแน่ พอถึงวัน UAT ผู้ใช้บอกว่าไม่ใช่สิ่งที่ต้องการ งานบานปลาย ส่งไม่ทัน เสียค่าปรับ และเสียความสัมพันธ์กันทั้งสองฝ่าย

หลักสูตรนี้พาคุณเดินครบทั้งเจ็ดขั้นในสายเดียวกัน ตั้งแต่ TOR จนระบบขึ้นใช้งานจริง เพื่อให้เห็นว่าคำที่เขียนไว้ในเอกสารต้นทางส่งผลถึงการตรวจรับปลายทางอย่างไร

สิ่งที่ทำให้หลักสูตรนี้ต่างออกไป

• เดินตามโครงการเดียวตลอดสามวัน ตั้งแต่อ่าน TOR จนวางแผนขึ้นระบบ ไม่ใช่หัวข้อกระจัดกระจาย
• เขียนเอกสารจริงในห้อง ทุกขั้นมีแบบฝึกหัดให้ลงมือทำ แล้วนำผลของขั้นก่อนหน้ามาใช้ต่อ
• มองจากทั้งสองฝั่ง ทั้งมุมหน่วยงานที่ออก TOR และตรวจรับ กับมุมผู้รับจ้างที่ต้องส่งมอบ
• มีตัวอย่างข้อกำหนดที่เขียนแล้วมีปัญหา ให้หาจุดกำกวมเอง แล้วเขียนใหม่ให้วัดผลได้
• เน้นเรื่องที่มักถูกลืม เช่น ข้อกำหนดที่ไม่ใช่ฟังก์ชัน แผนถอยกลับ และการย้ายข้อมูล

เนื้อหาแต่ละวัน

วันที่ 1 — TOR และการเก็บความต้องการ จนได้ FRD

• วงจรของโครงการพัฒนาระบบ และจุดที่มักพลาดในแต่ละช่วง
• TOR ขอบเขตงาน
  • ใครเป็นคนเขียน ใครต้องอ่านให้ออก และอ่านอย่างไรไม่ให้พลาด
  • ขอบเขตงานและสิ่งที่ไม่รวมอยู่ในขอบเขต
  • รายการส่งมอบ งวดงาน เกณฑ์การตรวจรับ และค่าปรับ
  • คำที่ทำให้เกิดข้อพิพาท เช่น เหมาะสม รวดเร็ว ใช้งานง่าย ครบถ้วน
  • เปลี่ยนข้อความกำกวมให้เป็นเกณฑ์ที่ตรวจได้จริง
• การเก็บความต้องการจากผู้ใช้
  • สัมภาษณ์ สังเกตการทำงานจริง และการประชุมเชิงปฏิบัติการ
  • แยกความต้องการที่แท้จริงออกจากวิธีแก้ที่ผู้ใช้เสนอมาเอง
  • จัดลำดับความสำคัญเมื่อเวลาและงบไม่พอทำทุกอย่าง
• FRD เอกสารข้อกำหนดเชิงหน้าที่
  • โครงสร้างเอกสารและหัวข้อที่ต้องมี
  • เขียน Use Case และ User Story ให้ทดสอบได้
  • กฎทางธุรกิจที่ต้องเขียนแยกออกมาให้ชัด
  • ผังกระบวนการทำงานและผังการไหลของข้อมูล
• ฝึกปฏิบัติ: อ่าน TOR ตัวอย่าง หาจุดกำกวม แล้วเขียน FRD หนึ่งฟังก์ชันพร้อมเกณฑ์ตรวจรับ

วันที่ 2 — SRS รายการตรวจสอบก่อนส่งงาน และการทดสอบ

• SRS ข้อกำหนดความต้องการของซอฟต์แวร์
  • ความต่างของ TOR, FRD และ SRS และเหตุผลที่ต้องมีทั้งสามชุด
  • พจนานุกรมข้อมูลและการออกแบบโครงสร้างข้อมูลเบื้องต้น
  • ข้อกำหนดการเชื่อมต่อกับระบบอื่น
  • สิทธิ์การเข้าถึงแยกตามบทบาทผู้ใช้
• ข้อกำหนดที่ไม่ใช่ฟังก์ชัน ซึ่งมักถูกลืมจนเป็นปัญหาหลังระบบขึ้นใช้งาน
  • ปริมาณข้อมูลและจำนวนผู้ใช้พร้อมกันที่ต้องรองรับ
  • ความปลอดภัยและการเก็บร่องรอยการใช้งาน
  • การสำรองข้อมูลและการกู้คืน
  • ข้อกำหนดตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล
• Dev Checklist รายการตรวจสอบก่อนส่งงาน
  • นิยามของคำว่างานเสร็จ ที่ทั้งทีมเข้าใจตรงกัน
  • มาตรฐานการเขียนโค้ดและการทบทวนโค้ดระหว่างกัน
  • การจัดการเวอร์ชันและการแยกสาขางาน
  • รายการตรวจความปลอดภัยก่อนส่ง
  • วินัยการจัดการโครงสร้างฐานข้อมูลด้วย migration
• Test การทดสอบ
  • ระดับของการทดสอบ ตั้งแต่หน่วยย่อย การเชื่อมต่อ จนถึงทั้งระบบ
  • เขียนกรณีทดสอบจากข้อกำหนด ไม่ใช่ทดสอบตามที่นึกออก
  • ข้อมูลทดสอบที่ใกล้เคียงของจริงโดยไม่ละเมิดข้อมูลส่วนบุคคล
  • การทดสอบซ้ำเมื่อแก้โค้ด เพื่อไม่ให้ของเดิมพัง
  • บันทึกผลการทดสอบให้ใช้เป็นหลักฐานตอนตรวจรับได้
• ตารางสอบทานความครบถ้วน โยง TOR ไป FRD ไป SRS และไปถึงกรณีทดสอบ
• ฝึกปฏิบัติ: แปลงข้อกำหนดที่เขียนไว้วันแรกเป็นกรณีทดสอบพร้อมเกณฑ์ผ่าน

วันที่ 3 — UAT และการขึ้นใช้งานจริง

• UAT การทดสอบเพื่อยอมรับระบบโดยผู้ใช้
  • เตรียมสภาพแวดล้อมและข้อมูลให้ผู้ใช้ทดสอบได้เหมือนใช้งานจริง
  • เขียนสคริปต์ UAT ที่ผู้ใช้ทำตามได้เองโดยไม่ต้องมีคนไอทีนั่งข้าง
  • การรัน UAT กับผู้ใช้จริง บันทึกผล และจัดลำดับสิ่งที่ต้องแก้
  • แยกข้อบกพร่องออกจากคำขอเปลี่ยนแปลง ซึ่งเป็นคนละเรื่องและคิดเงินคนละแบบ
  • เกณฑ์การผ่านและการลงนามตรวจรับ
• Production การขึ้นใช้งานจริง
  • แผนการขึ้นระบบและลำดับขั้นในวันจริง
  • แผนถอยกลับเมื่อเกิดปัญหา และเงื่อนไขที่จะตัดสินใจถอย
  • การย้ายข้อมูลจากระบบเดิม การตรวจสอบความถูกต้อง และการทำซ้ำได้
  • รายการตรวจสอบก่อนเปิดใช้และหลังเปิดใช้
  • การตั้งค่าสำรองข้อมูลและการเฝ้าระวังหลังขึ้นระบบ
• การส่งมอบและช่วงรับประกัน
  • เอกสารส่งมอบและคู่มือที่ผู้ใช้อ่านแล้วทำตามได้จริง
  • การอบรมผู้ใช้และการถ่ายโอนความรู้ให้เจ้าหน้าที่ของหน่วยงาน
  • การรับแจ้งปัญหาและระดับความเร่งด่วนในช่วงรับประกัน
• การขอเปลี่ยนแปลงระหว่างโครงการ และวิธีคุมขอบเขตไม่ให้บานปลาย
• ฝึกปฏิบัติ: วางแผนขึ้นระบบพร้อมแผนถอยกลับสำหรับโครงการตัวอย่าง

หลังจบหลักสูตร คุณจะทำสิ่งเหล่านี้ได้เอง

• อ่าน TOR แล้วชี้ได้ว่าข้อไหนเสี่ยง ข้อไหนตีความได้หลายทาง และควรขอความชัดเจนเพิ่มตรงไหน
• เขียน FRD และ SRS ที่ทีมพัฒนานำไปทำงานต่อได้ และผู้ว่าจ้างใช้ตรวจรับได้
• ตั้งรายการตรวจสอบก่อนส่งงานให้ทีม เพื่อให้คุณภาพไม่ขึ้นกับว่าใครเป็นคนทำ
• ออกแบบการทดสอบที่โยงกลับไปหาข้อกำหนดได้ทุกข้อ
• จัด UAT ที่จบด้วยการลงนามตรวจรับ ไม่ใช่จบด้วยรายการแก้ไขที่ไม่มีวันหมด
• วางแผนขึ้นระบบจริงพร้อมทางถอย และรู้ว่าต้องตรวจอะไรบ้างก่อนและหลังเปิดใช้

รูปแบบการอบรม

• บรรยายสลับกับแบบฝึกหัด โดยใช้โครงการตัวอย่างเดียวกันตลอดสามวัน
• ผลงานของแต่ละขั้นถูกนำไปใช้ต่อในขั้นถัดไป ทำให้เห็นความเชื่อมโยงจริง
• ระยะเวลารวม 18 ชั่วโมง แบ่งเป็น 3 วัน
• ไม่จำเป็นต้องเขียนโปรแกรมได้

สิ่งที่ผู้เข้าอบรมจะได้รับ

• แม่แบบเอกสาร TOR, FRD, SRS พร้อมคำอธิบายแต่ละหัวข้อ
• รายการตรวจสอบก่อนส่งงาน แบบฟอร์มกรณีทดสอบ และสคริปต์ UAT
• รายการตรวจสอบก่อนและหลังขึ้นระบบจริง
• ใบประกาศนียบัตรออนไลน์ที่ตรวจสอบความถูกต้องได้ด้วย QR

คำถามที่พบบ่อย

ไม่ใช่นักพัฒนา เรียนได้ไหม
ได้ หลักสูตรนี้ออกแบบให้ผู้ที่ทำงานฝั่งผู้ว่าจ้างเรียนได้ด้วย เช่น ผู้รับผิดชอบโครงการ เจ้าหน้าที่พัสดุ และผู้ใช้งานที่ต้องให้ความต้องการกับทีมพัฒนา เนื้อหาไม่มีการเขียนโปรแกรม

หน่วยงานเราเป็นฝ่ายจ้าง ไม่ได้พัฒนาเอง จะได้ประโยชน์ไหม
ได้มาก เพราะครึ่งหนึ่งของหลักสูตรคือการเขียน TOR ให้ชัด และการตรวจรับงานให้ได้ของที่ต้องการ ซึ่งเป็นงานของฝ่ายจ้างโดยตรง

ต่างจากหลักสูตรพัฒนาระบบด้วย Yii Framework อย่างไร
หลักสูตรนั้นสอนวิธีเขียนโค้ด ส่วนหลักสูตรนี้สอนวิธีบริหารโครงการทั้งวงจร ตั้งแต่กำหนดว่าจะทำอะไรจนส่งมอบให้ผ่าน เรียนแยกกันได้ ไม่ต้องเรียงลำดับ

หน่วยงานส่งเจ้าหน้าที่หลายคนได้ไหม
ได้ และแนะนำให้ส่งทั้งฝ่ายที่เขียนข้อกำหนดและฝ่ายที่ตรวจรับมาด้วยกัน เพราะแบบฝึกหัดออกแบบให้ทำงานร่วมกันเป็นทีม