ขั้นตอนพัฒนาระบบ (SDLC) 7 ขั้น ที่ต้องรู้ก่อนเริ่มโครงการ

SDLC ย่อมาจาก Software Development Life Cycle หรือวงจรการพัฒนาซอฟต์แวร์ เป็นลำดับขั้นที่ใช้กันเป็นมาตรฐานในการพัฒนาระบบ ไม่ว่าจะทำภายในองค์กรเองหรือจ้างภายนอก การรู้ลำดับนี้ทำให้ฝั่งผู้ว่าจ้างรู้ว่าตอนนี้โครงการอยู่ตรงไหน และต้องเตรียมอะไรไว้ล่วงหน้า ถ้ายังไม่ได้ตัดสินใจว่าจะพัฒนาเองหรือซื้อสำเร็จรูป อ่านก่อนได้ที่ซื้อซอฟต์แวร์สำเร็จรูปหรือสั่งพัฒนาเอง

ขั้นที่ 1 รวบรวมและจัดลำดับความต้องการ

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

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

1. สัมภาษณ์ผู้ใช้จริงอย่างน้อยสองคนต่อหนึ่งบทบาท ไม่ใช่ถามแค่หัวหน้า
2. ขอดูไฟล์และแบบฟอร์มที่ใช้อยู่จริงทั้งหมด รวมถึงไฟล์ Excel ที่ทำกันเอง
3. เขียนขั้นตอนปัจจุบันออกมาเป็นผัง แล้วให้ผู้ใช้ตรวจว่าตรงกับที่ทำจริงหรือไม่
4. ระบุจุดที่เสียเวลาและจุดที่เกิดข้อผิดพลาดบ่อย เพราะสองจุดนี้คือคุณค่าหลักของระบบใหม่
5. จัดลำดับความต้องการเป็นต้องมี ควรมี และไว้ทีหลัง แล้วให้ผู้บริหารยืนยัน

ขั้นที่ 2 สรุปขอบเขตและประเมินงบประมาณ

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

ขั้นที่ 3 ออกแบบระบบและฐานข้อมูล

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

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

ขั้นที่ 4 พัฒนาและส่งมอบเป็นรอบ

ควรแบ่งงานเป็นรอบละ 2-4 สัปดาห์ แล้วส่งมอบส่วนที่ใช้ได้จริงให้ทดลองทุกรอบ ข้อดีไม่ใช่แค่เห็นความคืบหน้า แต่คือได้แก้ทิศทางตั้งแต่ยังแก้ถูก โครงการที่รอส่งมอบครั้งเดียวตอนจบมักพบว่าเข้าใจโจทย์คลาดเคลื่อนตั้งแต่เดือนแรก แต่มารู้ตอนที่แก้แล้วมีต้นทุนสูงมาก

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

ขั้นที่ 5 ทดสอบร่วมกับผู้ใช้จริง

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

ขั้นที่ 6 ย้ายข้อมูลและขึ้นระบบจริง

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

ขั้นที่ 7 ดูแลและปรับปรุงหลังส่งมอบ

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

สิ่งที่ควรตกลงเพิ่มในขั้นนี้คือรอบการปรับปรุงหลังส่งมอบ ระบบที่ใช้จริงจะเจอกรณีที่ไม่มีใครนึกถึงตอนออกแบบเสมอ ซึ่งเป็นเรื่องปกติ ไม่ใช่ความผิดพลาด องค์กรที่ได้ประโยชน์จากระบบมากที่สุดคือองค์กรที่วางแผนไว้ตั้งแต่ต้นว่าจะมีรอบปรับปรุงเล็ก ๆ ทุกไตรมาสในปีแรก แทนที่จะถือว่างานจบในวันส่งมอบแล้วรอจนเจอปัญหาสะสมจนต้องทำโครงการใหม่ การกันงบไว้ประมาณ 15-20% ของค่าพัฒนาสำหรับการปรับปรุงปีแรก เป็นตัวเลขที่ใช้ได้จริงกับโครงการส่วนใหญ่ และทำให้ระบบค่อย ๆ เข้ารูปกับงานจริงมากขึ้นทุกไตรมาส อีกสิ่งที่ควรทำในขั้นนี้คือกำหนดผู้ดูแลระบบภายในองค์กรอย่างน้อยหนึ่งคน ที่รู้ว่าระบบตั้งค่าอย่างไรและติดต่อใครเมื่อมีปัญหา เพราะความรู้เรื่องระบบที่อยู่กับผู้พัฒนาฝ่ายเดียว จะกลายเป็นความเสี่ยงทันทีที่ผู้พัฒนาเปลี่ยนทีมหรือเลิกให้บริการ การส่งต่อความรู้ให้คนในองค์กรตั้งแต่ช่วงส่งมอบใช้เวลาไม่มาก แต่ป้องกันปัญหาที่แก้ยากที่สุดได้