แนวทางการเก็บความต้องการของลูกค้า ฉบับรวบรัด

บทความนี้เกิดจากการที่ ผมมีโอกาศได้ไปเข้าอบรม Software Requirement Development รุ่นปัดฝุ่น ที่จัดโดย สยามชำนาญกิจ ครับโดย สิ่งที่ทำให้เกิด Software Requirement Development ขึ้นเนี่ย คือ บรรดา PainPoint จากการเก็บ Requirement จากลูกค้าครับ

“เคยไหมครับที่ คุยกับลูกค้าแล้ว มานั่ง งง ต่อว่า จะต้องทำอะไรนะ?” 🙆🏼‍♂️

“ทำไม ลูกค้ามีงานต่อมาให้เรื่อยๆเลย จะจบงานยังไง?” 💆‍♀️

“ทำไม เราเปิดการ์ดให้ Dev ทำแบบนึง แต่งานออกมาอีกแบบนึงนะ?” 🤣

สิ่งที่จะแก้ไข PainPoint ข้างต้นได้คือ การสื่อสาร ครับ

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

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

การจะได้หนึ่งในวิธีสร้าง Solid Requirement!! จะมีขึ้นตอนคร่าวๆดังนี้ครับ

1. เข้าใจ Customer Journey

เริ่มต้นด้วยการทำความเข้าใจ Customer Journey เป็นสิ่งที่สำคัญมากครับ ลูกค้าจะมีความต้องการและเงื่อนไขที่แตกต่างกัน การเข้าใจและเห็นภาพเดียวกันกับ ลูกค้าจะช่วยให้เราสามารถพัฒนาฟีเจอร์ และบริการที่ตอบสนองความต้องการลูกค้าได้ดีขึ้นครับ เราจะได้ ข้อมูลความต้องการ (Need) ของลูกค้า เบื้องต้น

2. Needs to Requirement (ความต้องการ สู่ สิ่งที่ทำได้จริง)

หลังจากเข้าใจ Customer Journey แล้ว เราจะได้ข้อมูลความต้องการ (Need) ของลูกค้า แต่ (Need) ของลูกค้า ไม่สามารถนำมา ใช้ทำระบบได้เลย เราจะต้องนำ Need มาผ่านการ สกัด Requirement เพื่อให้ได้ Requirement จริงๆที่เราจะทำในระบบ ที่สามารถใช้งานได้จริง จะทำให้เราได้เห็นปัญหา ข้อจำกัด และ สิ่งที่ลูกค้าให้ข้อมูลมาไม่ครบ เราจะเอาข้อมูลเหล่านี้ไปคุยกับลูกค้า เพื่อให้เราและ ลูกค้า เห็นภาพรวมเดียวกัน ส่วนนี้จะแก้ PainPoint เรื่อง เข้าใจความต้องการของลูกค้าผิด เรื่องงานงอกขึ้นเรื่อยๆไม่หยุด หรือ งานไม่จบสักที

3. การใช้ Service Blueprint สกัด Requirement

การสร้าง Service Blueprint จะทำให้เราสามารถติดตามและตรวจสอบการทำงานได้ดีมากขึ้นครับ โดย Process การทำคือ เราจะตั้ง Customer Journey ก่อน แล้วเติม Frontstage Action และ BackStage Action เข้ามาเรื่อยๆ จะทำให้เห็นว่า แต่ละ Node ของ Customer Journey ระบบของเราต้องทำอะไรมารองรับบ้าง เกิดปัญหาอะไรบ้าง มีอะไรต้องถามลูกค้าเพิ่มเติมไหม ซึ่งการทำ Service Blueprint จะดีได้ เราต้องคัดคนที่เกี่ยวข้องจริงๆมาทำครับ ในแต่ละครั้งครับ

และการทำ Service Blueprint สามารถ ทำได้ตั้งแต่ Part ของลูกค้า Part ของ Sa และ Part ของ Dev ครับ เพราะปลายทางของการทำ Service Blueprint คือ ต้องการให้ทุกคนในระบบเห็นภาพเดียวกัน และ ทำงานไปในทางเดียวกันครับผม

ส่วน Process ที่ว่า Service Blueprint ต้องทำยังไง รายละเอียดอย่างไรบ้าง จะเพิ่มในบทความต่อไปครับ

4. สรุปและนำเสนอข้อมูลกับลูกค้า และ ขอปิดจบ Requirement

สุดท้าย การจัดทำข้อมูลในรูปแบบที่เข้าใจง่าย เช่น ตัว Prototype ของระบบส่วนนั้นๆ (หน้าจอที่ใช้งานได้) หรือ Service Blueprint พร้อมกับเตรียมคำถามที่เกิดจากการ สกัด Requirement ไปถามลูกค้า เพื่อมาทำการ สกัด Requirement ต่อไปครับ

สรุป

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