วิธีการทำ Feature List
ในการพัฒนาซอฟต์แวร์ของ Senna Labs เราจะมีการใช้เอกสาร Feature List เพื่อทำให้ทีมเข้าใจการทำงานของซอฟต์แวร์นั้น ๆ ได้ถูกต้องและตรงกัน ไม่ว่าจะเป็นทีม Project Manager, UX/UI Designer, Developer และ Quality Assurance ซึ่ง Feature List จะเกิดขึ้นตั้งแต่ทีม Business Developement ไปรับ Requirement จากลูกค้า แล้วนำมาไล่เขียน Feature เป็นข้อ ๆ เพื่อประเมินค่าใช้จ่ายและระยะเวลาในการดำเนินงาน หลังจากนั้นเมื่อเริ่มการทำงานจริง Project Manager จะเป็นคนที่นำ Feature List จากทีม Business Development มาไล่ตรวจความถูกต้อง หากส่วนไหนที่ยังเขียนไว้ไม่ชัดเจน Project Manager ก็สามารถใส่รายละเอียดเพิ่มเข้าไป เพื่อทำให้ซอฟต์แวร์เสร็จออกมาตรงตามที่ตกลงไว้กับลูกค้า
Feature List คืออะไร ?
Feature List คือเอกสารที่รวบรวม Requirement หรือความต้องการของลูกค้าหรือผู้ใช้เอาไว้ ว่าต้องการให้ซอฟต์แวร์มีความสามารถในการทำอะไรได้บ้าง โดยใส่รายละเอียดของ Feature หรือสิ่งที่ควรมีใน Digital Product ที่กำลังจะพัฒนาให้ลูกค้า ว่าแต่ละส่วนของเว็บไซต์หรือแอปพลิเคชันจะประกอบไปด้วย Feature อะไรบ้าง
Feature List สำคัญอย่างไร ?
1. ช่วยให้สามารถประเมินค่าใช้จ่ายได้อย่างถูกต้องและแม่นยำ : เนื่องจาก Feature List คือตัวที่บอกความสามารถของตัวซอฟต์แวร์นั้น ๆ ว่าสามารถทำอะไรได้บ้างและมีรายละเอียดแต่ละ Feature อย่างไร ซึ่งทีมงานที่เกี่ยวข้องจะสามารถประเมินจำนวนวันทำงาน (Manday) ที่ใช้ได้จากรายละเอียดของ Feature List นี้
2. ช่วยให้เข้าใจความต้องการของลูกค้า : ช่วยให้ทุกทีม ตั้งแต่ Project Manager, UX/UI Designer, Developer และ Quality Assurance เข้าใจความต้องการของลูกค้าได้อย่างชัดเจนและถูกต้องตรงกัน
3. ช่วยให้การสื่อสารมีประสิทธิภาพมากยิ่งขึ้น : หากเอกสารมีความถูกต้อง ชัดเจน และครบถ้วน จะช่วยให้ทีมทำงานง่ายขึ้น และสามารถทำงานออกมาได้ตรงตาม Requirement
ขั้นตอนการทำ Feature List
- เก็บรวบรวม Requirement จากลูกค้าให้ครบถ้วน : ในช่วงแรกของโปรเจกต์ หรือช่วง Discovery Phase จะเป็นช่วงที่เก็บรวบรวม Requirement จากลูกค้า โดยทีม Business Development จะนัดประชุมกับลูกค้า หรือศึกษาจากเอกสารอื่น ๆ ที่ได้รับจากลูกค้า
- เริ่มทำเอกสาร Feature List : หลังจากเก็บ Requirement และเข้าใจจุดประสงค์ของโปรเจกต์อย่างดีแล้ว จึงค่อยเริ่มทำเอกสาร Feature List เพราะเราจะทราบภาพรวมแล้วว่าเว็บไซต์หรือแอปพลิเคชันนี้จะมีทั้งหมดกี่หน้า และแต่ละหน้าประกอบไปด้วย Feature อะไรบ้าง และภายใต้ Feature นั้นจะต้องแสดงหรือเก็บข้อมูลอะไรบ้าง
- ตรวจสอบความถูกต้องกับทีมทำงาน : หลังจากทำ Feature List เสร็จแล้ว ให้ตรวจสอบความถูกต้องกับทีมทำงานก่อนว่า Feature เหล่านั้นสามารถทำได้จริงหรือไม่ มีส่วนไหนที่ต้องพิจารณาเพิ่มเติมเพื่อไม่ให้เกิดปัญหาขึ้นภายหลัง
- ส่งให้ลูกค้าตรวจสอบและอนุมัติ : ว่า Feature List ที่เราทำมาตรงตาม Requirement ไหม ก่อนที่จะเริ่มออกแบบและพัฒนา
วิธีการทำ Feature list
ในการทำ Feature List ทางทีม Business Development จะต้องทำความเข้าใจเกี่ยวกับความต้องการของลูกค้าก่อนว่า Digital Product ที่ลูกค้าต้องการจะออกมาเป็นอย่างไร ซึ่งปกติแล้วหากเป็นซอฟต์แวร์หรือแอปพลิเคชัน จะมี Feature ที่เป็นพื้นฐานอยู่แล้ว เช่น Authentication, Profile Setting และ Dashboard แต่รายละเอียดที่ต่างกันจะขึ้นอยู่กับว่าซอฟต์แวร์นั้นทำเกี่ยวกับอะไร เช่น
- ลูกค้า A อยากทำเว็บไซต์ขายของ เราก็จะดูว่าลูกค้าต้องการ Feature อะไรบ้าง เช่น ลูกค้าอยากได้หน้าสมัครสมาชิก หน้ารวมสินค้า สามารถกดสินค้าลงตะกร้า พอกดสินค้าลงตะกร้าเสร็จ สามารถสรุปยอดซื้อ สรุปยอดซื้อเสร็จ กดชำระเงิน แล้วชำระเงินได้ด้วยวิธีอะไรบ้าง เราก็จะ List ออกมาตาม Feature ที่ลูกค้าอยากได้
- ลูกค้า B อยากทำเว็บไซต์ขายของเหมือนกัน แต่อยากได้การขายของแบบมีหลาย ๆ ร้านอยู่ในเว็บไซต์ตัวเอง ฟีเจอร์ก็อาจจะไม่ใช่แบบลูกค้า A แต่ก็จะกลายเป็นฟีเจอร์ในส่วนของการจัดการร้านในเครือ การเพิ่มลดร้านค้า วันหมดอายุสมาชิกร้าน
จะเห็นได้ว่าลูกค้า A กับ B ก็ขายของเหมือนกัน แต่ Feature ที่เราจะต้องพัฒนาให้ลูกค้าจะออกมาไม่เหมือนกัน ราคาที่จะเรียกเก็บจากลูกค้า A กับ B ก็ไม่เท่ากัน การทำ Feature List นี้เราต้องแปลง Requirement นั้นออกมาให้อยู่ในรูปแบบของ Feature หรือการทำงานของระบบให้ได้
เอกสาร Feature List จริง ๆ แล้วไม่ได้มี Template ตายตัว ขึ้นอยู่กับการตกลงกับทีมและการสื่อสารให้เข้าใจตรงกัน เราสามารถเพิ่มหรือลดบางคอลัมน์หรือหัวข้อได้ แต่ควรทำให้เป็นระเบียบ กระชับ อ่านง่าย มีข้อมูลที่ครอบคลุมและถูกต้อง
อย่างไรก็ตาม ทีม Project Manager, UX/UI Designer, Developer และ Quality Assurance ไม่ได้ศึกษา Requirement จากเอกสาร Feature List เพียงอย่างเดียวเท่านั้น แต่ต้องศึกษาจากเอกสารอื่นควบคู่กันไปด้วย เช่น Sitemap, Flowchart และ Requirement Document เพื่อที่จะสามารถเข้าใจ Requirement ที่ครบถ้วนและถูกต้องมากยิ่งขึ้นนั่นเอง
References: