Discovery Requirement VS Project Manager | ทำไม PM ต้องทำก่อนเริ่มพัฒนาระบบ

Discovery Requirement คือกระบวนการทำความเข้าใจความต้องการต่าง ๆ ที่เป็นส่วนสำคัญในการพัฒนาซอฟต์แวร์ ซึ่งในฐานะ Project Manager เราต้องเข้าใจความต้องการที่แท้จริงขององค์กร ซึ่งก็คือเข้าใจว่าซอฟต์แวร์นี้สร้างขึ้นไปเพื่ออะไร (Business Requirement) และต้องเข้าใจว่าผู้ใช้งานจริงต้องการนำซอฟต์แวร์นี้ไปใช้งานด้านใดบ้าง (User Requirement) แล้วนำทั้งสองอย่างมาวิเคราะห์ เพื่อให้ได้ความต้องการของระบบซอฟต์แวร์ที่กำลังจะถูกพัฒนา (Software Requirement) ซึ่งเป็นส่วนสำคัญสำหรับใช้สื่อสารกับทั้งลูกค้าและกับทีมพัฒนา

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

ในฐานะ Project Manager จึงต้องมีหน้าที่ Recheck และ Confirm Requirement ทั้งหมดที่ได้รับมาว่าครบถ้วนแล้วหรือไม่ มีข้อมูลเพียงพอสำหรับนำไปส่งต่อให้ทีม Design และ QA นำไปใช้ทำงานต่อได้ไหม หรือมีส่วนไหนที่ต้องเก็บ Requirement เพิ่มเติมบ้าง เพื่อให้ได้ UI และ User Flow Diagram ที่ตรงกับความต้องการ ซึ่งเป็นข้อมูลส่วนสำคัญที่ต้องส่งต่อให้ Developer นำไปใช้พัฒนาระบบต่อไป

“เพราะฉะนั้น… Project Management ในขั้นตอน Discovery ก็เป็นเหมือนกับการพยายามติดกระดุมเม็ดแรกให้ถูกต้อง”  

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

แล้ว Project Management ในขั้นตอน Discovery มีกระบวนการการทำงานอย่างไรบ้าง ? PM ต้องทำอย่างไร จึงจะสามารถจัดการงานในส่วนนี้ได้อย่างเป็นระบบ และนำไปสู่การติดกระดุมเม็ดแรกอย่างถูกต้องได้ บทความนี้จะช่วยไขข้อข้องใจให้กับคุณ !

Requirement | มาทำความเข้าใจประเภท Requirement กัน !

Requirement สำหรับการพัฒนาซอฟต์แวร์ (Software Development) จะแบ่งเป็น 3 กลุ่มใหญ่ ๆ ได้แก่ 

1. Business Requirement

คือความต้องการทางธุรกิจที่แท้จริง ซึ่งเนื้อหาที่ได้จะมีความต้องการแบบภาพรวมว่าต้องการพัฒนาซอฟต์แวร์นั้น ๆ เพื่ออะไร

ตัวอย่างเช่น 

• ความต้องการหลัก (Objective)

• ต้องการพัฒนา Platform สำหรับซื้อ-ขาย ผลงานกราฟิกต่าง ๆ เพื่อเป็นสื่อกลางให้ศิลปินมีโอกาสในการขายผลงานภาพวาดของตนเอง และ

• ต้องการพัฒนา Platform ที่สะดวกและน่าใช้ในการค้นหา และเลือกซื้องานกราฟิกต่าง ๆ ที่ตรงตามความต้องการของลูกค้า

• รายละเอียดของฟีเจอร์ (Features) เช่น

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

• ผู้ใช้งานที่สนใจซื้อ สามารถค้นหาผลงานที่ต้องการโดยใช้ Keyword หมวดหมู่หรือคุณสมบัติอื่น ๆ ได้

2.  User Requirement

คือความต้องการของผู้ใช้งานว่าในซอฟต์แวร์ที่จะพัฒนานั้น ผู้ใช้งานสามารถทำอะไรได้บ้าง

ตัวอย่างเช่น

• ผู้ใช้สามารถสมัครสมาชิกในเว็บไซต์เพื่อเข้าใช้งานได้

• ผู้ใช้ต้องสามารถเลือกวิธีการชำระเงินที่ต้องการได้ เช่น บัตรเครดิต ชำระผ่านธนาคาร หรือวอลเล็ท

3. Software Requirement

คือความต้องการระบบซอฟต์แวร์  โดยมีทั้งหมด 2 รูปแบบ ได้แก่

1. Functional Requirement 

คือสิ่งที่ระบบควรทำได้ เพื่อตอบสนองความต้องการของผู้ใช้

2. Non-Functional Requirement
   คือความต้องการที่ไม่ได้มาจากความต้องการของผู้ใช้งานโดยตรง แต่เป็นส่วนเสริมที่ช่วยเพิ่มประสิทธิภาพ หรือเกี่ยวข้องกับความต้องการของผู้ใช้งาน เช่น Security และ Performance 

Business Requirement Discovery | เข้าใจความต้องการขององค์กร

Business Requirement Discovery เป็นกระบวนการสำคัญที่ Project Manager จะต้องส่งต่อ Requirement สำหรับให้ทีม Design นำไปทำ User Journey Map โดยมีกระบวนการวางแผนการทำงาน ดังนี้

ขั้นตอนที่ 1 : Create Project Timeline & Milestone

• ทำไมต้องสร้าง Project Timeline & Milestone

การสร้าง Project Timeline และกำหนด Milestone จะช่วยให้เราเห็นภาพรวมของงานว่าแต่ละช่วงเราต้องทำ Feature/Module ไหน และต้องทำเสร็จเมื่อใด เพื่อให้เราสามารถควบคุมเวลาในการดำเนินงานได้ดียิ่งขึ้น และช่วยให้เราสามารถประเมินกระบวนการทำงาน ณ ปัจจุบัน ว่าเป็นไปตามแผนที่วางไว้หรือไม่ Project ยังคง On-time หรือมีแนวโน้มจะ Delayed จากที่วางไว้

Project Timeline & Milestone จึงเป็นตัวช่วยสำคัญของ Project Manager ในการบริหารความเสี่ยง และจัดเรียงลำดับความสำคัญของแต่ละ Tasks งานได้ดี

• Project Timeline ควรมีอะไรบ้าง ?

1. 1. Tasks: งานทั้งหมดที่เราต้องทำให้เสร็จ

   2. Estimation: ระยะเวลาที่ใช้ในการทำแต่ละ Task

   3. Start date - End date: วันที่เริ่มต้นทำและสิ้นสุดของแต่ละ Task

   4. Task Dependencies: การกำหนดความเชื่อมโยงของแต่ละ Task โดยอาจจะมีบาง Task ที่เชื่อมโยงการทำงานกับ Task อื่น ๆ ซึ่งจำเป็นต้องทำงานใดงานหนึ่งให้เสร็จเรียบร้อยก่อนจึงจะสามารถเริ่มทำงานนี้ได้

• การสร้าง Milestone 

Milestone เป็นเหมือนจุด Check Point ให้กับทีม เมื่อถึง ณ จุดนั้นบน Timeline แล้ว งานของเราควรมีหน้าตาอย่างไรหรืองานของเราควรทำอะไรบ้าง และมี Tasks ใดบ้างที่ควรเสร็จหรือก็คือจุดที่บ่งบอก “สิ่งที่จะต้องเสร็จ ไม่ใช่สิ่งที่จะเริ่มทำ”

ตัวอย่าง Project Timeline with Milestones จาก https://www.slideteam.net/monthly-project-timeline-with-milestones-and-tasks-project-management-bundle.html

ขั้นตอนที่ 2 : Business Requirement Discovery

Project Manager จะต้องนำ Business Requirement ที่เก็บรวมรวมจากลูกค้าในรอบแรก มาตรวจสอบความถูกต้องอีกครั้งว่าครบถ้วนหรือไม่ มีส่วนไหนต้องเก็บ Requirement เพิ่มเติมบ้าง 

หากจำเป็นต้องมีการเก็บข้อมูลเพิ่มเติม เมื่อได้รับ Requirement ใหม่มาจากลูกค้าแล้ว ก็ต้องนำมาปรับในเอกสาร Business Requirement ด้วย

ขั้นตอนที่ 3 : Understanding the Business Goal and Objective

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

จุดสำคัญของการสร้างความเข้าใจในส่วนนี้คือช่วยให้ Project Manager เข้าใจ Requirement ของลูกค้ามากยิ่งขึ้น จนสามารถให้คำแนะนำเกี่ยวกับลำดับการพัฒนา Feature ต่าง ๆ ได้ว่าควรทำส่วนใดก่อน ส่วนใดหลังตามความสำคัญในการพัฒนาระบบ

ขั้นตอนที่ 4 : Recheck Feature List

เมื่อ Project Manager ตรวจสอบ Business Requirement ว่าครบถ้วนและมีข้อมูลเพียงพอแล้ว ก็นำ Requirement ทั้งหมดที่ได้รับ ส่งต่อให้กับทีม Design นำไป User Journey Map 

ภายหลังจากที่มี User Journey Map ของ Project แล้ว Project Manager ก็นำ Feature List ที่ได้รับมาตรวจสอบกับทีมอีกครั้งว่าต้องมีการปรับปรุงหรือแก้ไข Feature ที่เคยกำหนดไว้หรือไม่

User Requirement Discovery | เข้าใจความต้องการของผู้ใช้งาน

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

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

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

1. User ทั่วไป = นักศึกษามหาวิทยาลัยที่มีอายุ 18-22 ปี

2. User Persona = นักศึกษามหาวิทยาลัยที่มีอายุ 18-22 ปี ที่อาศัยอยู่ในคอนโดหรูข้างมหาวิทยาลัยใกล้ ๆ สยามพารากอน 

จะเห็นได้ว่าเราสามารถจะเจาะลึกลงไปได้ว่า User ที่เราต้องการให้มาเป็นกลุ่มลูกค้าของเราจะต้องการ Product แบบไหนและเจอปัญหาอะไรอยู่ สามารถนำไปต่อยอดในการทำฟีเจอร์ของ Product ได้

2. การทำ User Journey คือการวิเคราะห์พฤติกรรมของผู้ใช้ในสถานการณ์ต่าง ๆ เพื่อดูความสัมพันธ์ระหว่างผู้ใช้กับ Product ของเราว่ามีปฏิกิริยาใดเกิดขึ้นบ้างในระหว่างการใช้งาน เมื่อเราทำ User Journey เราจะพบกับพฤติกรรมของผู้ใช้งานที่มองเห็นได้ชัดเจนมากยิ่งขึ้นและสามารถตอบโจทย์หลายข้อในการทำ Product ได้ เช่น

เราจะรู้ว่าผู้ใช้งานชอบดูข้อมูลอะไร

เราจะรู้ว่าผู้ใช้งานมีพฤติกรรมอย่างไร

เราจะรู้ว่าผู้ใช้งานหยุดใช้งาน Product เราที่หน้าไหน

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

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

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

1. Usability Test ที่ดี ควรมีองค์ประกอบ 5 อย่าง ดังนี้

1. 1. เข้าใจง่าย (Learnability)

   2. ใช้งานไม่ติดขัด ไม่ติดปัญหา (Efficiency)

   3. คนจำวิธีการใช้งานได้ (Memorability)

   4. มีข้อผิดพลาดน้อย (Errors)

   5. ความชื่นชอบและพอใจ (Satisfaction)

เมื่อได้ผลการทดสอบแล้วเราสามารถนำไปแก้ไขพัฒนาและนำกลับมา Test อีกได้เรื่อย ๆ เพื่อจะได้เป็น Product ที่ตอบโจทย์ User ที่สุด

Software Requirement Discovery | เข้าใจความต้องการของระบบ

Software Requirement เป็นความต้องการในการทำ Product โดยก่อนจะลงมือพัฒนาจะมีการวิเคราะห์ความต้องการ หลังจากเราวิเคราะห์เสร็จก็จะมากำหนดความต้องการว่ามีอะไรบ้าง ความต้องการจะถูกแบ่งออกเป็น 2 อย่าง คือ

1. Functional Requirement

เป็นความต้องการหลักของระบบ เช่น ฟีเจอร์ / ฟังก์ชันที่จำเป็นต่อการใช้งาน สิ่งที่จำเป็นต้องมีเพื่อให้ Software ตอบโจทย์การใช้งานของผู้ใช้งานให้มากที่สุด ซึ่งวิธีที่ช่วยให้ Project Manager สามารถเขียน Requirement ออกมาได้ง่ายขึ้นคือการทำ User Story 

การทำ User Story คือการเขียน Requirement ออกมาในรูปแบบของการเล่าเรื่องราวของผู้ใช้งาน เพื่อที่จะเล่าให้กับทีมนักพัฒนาระบบ (Dev) เข้าใจได้ทันทีว่า Requirement ที่กำลังเขียนโปรแกรมอยู่นั้น กำลังทำให้กับใคร ต้องทำอะไรและเพื่ออะไร เพื่อให้ Dev สามารถเข้าใจผู้ใช้งานได้ดีขึ้นและพัฒนา Product ได้ตรงความต้องการของผู้ใช้ที่สุด 

2. Non-Functional Requirement

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

โดยการเก็บ Non-Functional Requirement จะต้องคำนึงถึง 3 ประเด็น คือ Business Rules, External Interfaces และ Constraints

1. Business Rules
   เก็บรวบรวมกฎเกณฑ์ที่ใช้ในการดำเนินการหรือการตัดสินใจทางธุรกิจขององค์กร ที่ต้องการนำมาเป็นตัวกำหนด หรือข้อจำกัดที่นักพัฒนาต้องออกแบบระบบให้ผู้ใช้งานต้องปฏิบัติตามนั้นด้วย เช่น มีงบประมาณจำกัด มีข้อกฎหมายที่จำเป็นต้องปฏิบัติตาม

2. External Interfaces

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

3. Constraints 

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

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