The Art of Getting Requirements เก็บความต้องการอย่างไรให้ได้สิ่งที่ลูกค้าต้องการ?
[Muze Roundtable] เก็บความต้องการอย่างไรให้ได้สิ่งที่ลูกค้าต้องการ? ถอดบทสนทนาว่าด้วยการเก็บ Requirement โดย CTO และ Head of Product Owner ของ Muze Innovation
พบกับ Muze Roundtable บทความที่จะชวนคนในทีมของเรามานั่งจับวงคุยกันเกี่ยวกับประเด็นต่าง ๆ เกี่ยวกับ Software Development โดยหัวข้อแรกที่เราชวนคนในทีมมานั่งคุยกัน ก็คือ การ Get Requirement เรื่องพื้นฐานที่ใครต่างก็เห็นตรงกันว่าไม่ง่าย และต้องอาศัยการสั่งสมประสบการณ์ในการหาวิธีที่ใช่ในแบบของตัวเอง
โดยบุคคลที่ Muze ชวนมาแลกเปลี่ยนประสบการณ์กันในครั้งนี้ ประกอบไปด้วย พี่พีท กิตติพัฒน์, พี่เข็ม พิชาน์ ดูโอ้ CTO ที่ดูแลด้านเทคทั้งหมด และพี่เนม ภูมิพัฒน์, พี่เก๋ นภาศรี Head of Product Owner ที่เป็นผู้ดูแลทีม Product Owner ของเราในการประสานงานและควบคุมการพัฒนา Product ให้เป็นไปตามความต้องการของผู้ใช้งาน
มาเริ่มกันเลย!
Q: การ Get Requirement ที่ดีในแบบของพี่ ๆ เป็นอย่างไร?
พี่เก๋: การ Get Requirement ที่ดีสำหรับพี่คือ ทางคนที่เราคุยด้วยเขารู้ว่าเขาต้องการอะไร เขาสามารถอธิบายได้ว่าปัญหาที่เขาพบคืออะไร เราฟังไปก่อนแล้วเอามาวิเคราะห์ทีหลัง หรือถ้าไม่ซับซ้อนมากก็วิเคราะห์ไปเลย แล้วก็อาจจะมีถามคำถามเพิ่มเติมจากที่เขาเล่าให้ฟัง เพื่อให้เราเข้าใจในสิ่งที่เขาอยากสื่อมากขึ้น
พี่เข็ม: สำหรับพี่ การ Get Requirement ที่ดี หลัก ๆ เราต้องรับฟังความต้องการหรือ Pain Point ของลูกค้า แต่บางทีฟังอย่างเดียวไม่พอ ฟังแล้วต้องมองให้เห็นถึงแก่นของมัน ประเด็นของมัน ว่าในความต้องการของเขาที่เขาเล่ามา แท้ที่จริงอยู่ที่จุดไหน บางทีตัว User อาจจะไม่ได้พูดถึง เราในฐานะผู้ฟังก็ต้องตั้งคำถาม บางทีก็อาจจะเป็นกรณีที่เขาไม่รู้หรือตระหนักว่ามีปัญหาอะไรบ้าง
พี่เนม: ขอเสริมที่พี่เข็มพูด เกี่ยวกับการมองให้เห็นถึงแก่นของความต้องการเขา ก็อาจจะเริ่มที่การให้ลูกค้าแชร์เรื่อง Business ของเขาก่อน เป้าหมายของเขาคืออะไร หลาย ๆ ครั้งเราฟัง Requirement มาแล้วต้องนำไปส่งต่อให้คนอื่นทำงาน ในมุมคนที่บริหาร Product มันก็ต้องเอาไปเล่าให้คนอื่นเข้าใจได้ว่าจุดมุ่งหมายของสิ่งที่จะทำคืออะไร สิ่งแรกที่ควรเข้าใจ User คือ Vision หรือวิสัยทัศน์ที่จะสามารถทำให้เราไปต่อยอดจากตรงนั้นต่อได้ หลายครั้งบางทีการเล่าว่าอยากทำอะไร ไม่สำคัญเท่าจุดมุ่งหมายคืออะไร
ถ้าเรารู้ Vision ตรงนี้แล้ว มันก็สามารถช่วยเขาดูได้ว่าระบบที่เขาต้องการ มันตอบโจทย์วิสัยทัศน์ภาพใหญ่จริงหรือเปล่า และเราจะได้เห็นทิศทางทางของ Product ในการมาเสริมภาพใหญ่ของเขาพร้อมได้ทิศทางที่ชัดเจนและตรงจุดในการพัฒนา ไม่ต้องทำแล้วแก้วนซ้ำไปมา
ยกตัวอย่างที่พี่เคยทำ เป็นโปรเจกต์ที่ลูกค้าอยากทำระบบหนึ่งขึ้นมาใหม่ แต่เขาไม่ได้เล่าว่าระบบนี้ทำแล้วจะไปกระทบกับระบบอะไรที่เขามีอยู่แล้วหรือเปล่า ระบบนี้ควรมีอะไรอย่างอื่นที่ควรจะคำนึงถึงในการออกแบบให้เข้ากับสิ่งที่เขามีอยู่แล้ว ถ้าเขาช่วยแชร์กับเราก่อนว่าในเชิง Business และการนำ Product เข้ามาใช้ เขามี Roadmap อย่างไร มันจะเห็นภาพมากขึ้นว่าเราสามารถเชื่อมต่อสิ่งที่เขาเคยทำไว้อยู่แล้ว กับสิ่งที่เขากำลังจะพัฒนาได้อย่างไรให้ทั้งหมดทำงานด้วยกันได้
พี่พีท: ท่าน ๆ ทั้งหลายพูดถึงประเด็นสำคัญไปหมดแล้ว พี่ขอสรุปให้ละกัน ถ้าจะทำให้มันดูสวยหน่อยก็คือ การ Read between the lines หรือการตีโจทย์ให้ออกแม้จะเป็นสิ่งที่เขาไม่ได้พูดออกมา
จากประสบการณ์ของพี่ คนที่ให้ Requirement แบ่งออกเป็น 2 ประเภทหลัก ๆ ประเภทแรกคือ คนที่ทำงานอยู่ระดับสูง จะรู้ว่าอยากได้อะไรในภาพกว้าง แต่รายละเอียดอาจจะไม่ชัด อีกประเภทคือคนที่ทำเนื้องานจริง อาจเป็น User ที่ใช้แค่เฉพาะส่วน เขาจะเห็นรายละเอียดหรือปัญหาส่วนที่เขาทำเป็นหลัก
สิ่งที่เราต้องหาให้เจอคือ แล้วปัญหาจริง ๆ มันคืออะไร Use Case นี้เกิดมาเพื่ออะไร ซึ่งจุดนี้ก็คือสิ่งที่พี่เข็มพี่เนมเล่าเมื่อกี้แหละ ว่าต้องหากระพี้ของมันให้เจอ บางทีสิ่งที่เขาบอกเรา อาจจะเป็นสิ่งที่เขาอยากได้ แต่ไม่ใช่สิ่งที่เขาต้องการ
สิ่งที่เราต้องการจากการเก็บ Requirement แต่ละครั้งคือ “ปัญหา” ไม่ใช่ “Solution” เราต้องถามให้ลึกให้ได้ปัญหา เพื่อที่เราจะนำไปคิด Solution ให้เขา
กับบางครั้ง สิ่งที่เขาเล่ามาอาจจะฟังดูเหมือน Solution เราต้องถอยออกมาให้เห็นภาพกว้างกว่านั้น ว่าจริง ๆ แล้วมันจะมี Solution อื่นที่ดีกว่าหรือไม่ จะมีวิธีอื่นที่แก้ปัญหาที่ลูกค้าต้องการ แล้วสามารถแก้อีกปัญหาที่เขามองไม่เห็นอยู่ได้หรือเปล่า
พี่เข็ม: พี่พีทพูดมาตรงนี้ก็เลยคันปากอยากแชร์ในสิ่งที่ทำมาโดยตลอด ไม่แน่ใจว่าคนอื่นทำมั้ย แต่ถ้าพี่มีโอกาสเข้าไปฟังการคุย Requirement ในช่วงแรก ๆ เวลาลูกค้าพูดว่าเขาอยากได้ Solution แบบนี้ ๆ นะ พี่จะทดในใจไปก่อนว่ามันต้องมีวิธีที่ดีกว่านั้น แต่ไม่ได้พูดออกไปนะ เราก็รับฟังเขา เพราะเขาก็อาจจะคิดมาเรียบร้อยแล้ว
อย่างไรก็ตามเราก็จะยังขอฟังข้อมูลอื่น ๆ และไม่หยุดหา Solution ที่ดีกว่า จนถึงท้ายที่สุดถ้าได้ข้อมูลทั้งหมดมาวิเคราะห์แล้วถึงเจอว่าสิ่งที่เขาคิดมามันเหมาะสมแล้วก็ตามนั้น หรือบางทีสุดท้ายมันก็ออกมาเป็นส่วนผสมของไอเดียเขาไอเดียเราก็มีเหมือนกัน
หลัก ๆ ก็คืออย่าเพิ่งยึดติดกับ Solution ที่ลูกค้าให้มา จนเรามองไม่เห็นวิธีอื่นที่อาจจะดีกว่า
Q: ถ้าต้องลงไป Get Requirement ใน Business ที่ไม่คุ้นเคย หรือไม่รู้จัก พี่ ๆ มีวิธีจัดการอย่างไร?
พี่เก๋: ก็ต้องรีเสิร์ชเพิ่มแน่นอน เราเข้าใจทุก Business ไม่ได้หรอก ปกติทีม Business Development ก็จะส่งงานมาให้ก่อนว่าลูกค้าอยากต้องการอะไรคร่าว ๆ เราต้องไปรีเสิร์ชก่อนประมาณหนึ่งว่า Business เขามีกระบวนการทำงานอะไรบ้าง มี Product อะไรในท้องตลาด แล้ว มี Feature อะไร
หลังจากคุยกับเขาแล้ว เราก็เอามา Brainstorm กันอีกทีว่า มาตรฐานใน Business นี้เป็นอย่างไร แล้วเราควรวางแผนอย่างไร
ปกติในขั้นตอนการรีเสิร์ช เราก็มีตั้งแต่ถามเพื่อน ถาม Google ถาม ChatGPT
พี่เนม: ช่วงนี้พี่จะใช้ ChatGPT เยอะหน่อย ด้วยความที่มันช่วยจัดกลุ่มความคิด และ กรอบความคิดให้ได้เนื้อหาที่เราต้องการหาคำตอบได้ดีกว่า Google ที่คำตอบกระจัดกระจายแล้วเราต้องมาจัดระบบคำตอบเอง อย่างพี่ได้งานที่ต้องทำระบบที่ไม่เคยทำ พี่ให้มันช่วยตั้งแต่เริ่ม Sprint 0 ให้มันช่วยเล่าเลย ว่าระบบนั้นคืออะไร ประกอบด้วย Component อะไรบ้าง การเชื่อมต่อข้อมูลแต่ละส่วนคืออะไร อะไรบ้างที่ต้องคำนึงถึง รวมถึงให้มันลองช่วยออกแบบ Database
พี่พีท: Microsoft Bing ก็ดีเหมือนกันนะ
พี่เนม: ChatGPT มันช่วยได้เยอะมาก ถ้ามีคำถามที่เฉพาะเจาะจงชัดเจน เช่น ข้อดีข้อเสียของแต่ละตัวคืออะไร มันจะตอบได้ตรงมาก ส่วนเรื่องความถูกต้องของข้อมูลต้องให้ ChatGPT 4 พร้อมมี Plugin อ่านลิงก์เพิ่ม เป็นต้น
Q: ฝากพี่ ๆ ช่วยแชร์ประสบการณ์ที่ทำให้เจอการเก็บ Requirement แบบที่ใช่กับตัวเองมากขึ้น
พี่เก๋: ตอนพี่เก็บ Requirement แรก ๆ ยังไม่ได้ทำมาเยอะมาก เราต้องใส่ Effort ไปค่อนข้างเยอะ พี่เคยทำ Business ประกันภัย ไม่เข้าใจด้วยซ้ำว่ามันคำนวนเบี้ยประกันยังไง พี่ต้องเข้าใจมันแบบจริงจัง ทำ Journey ออกมาว่ามีกี่เคส แต่ละเคสคำนวนยังไง จนเราเข้าใจที่จะเล่าต่อให้ Developer หรือนำไปเสนอ User ได้ว่าเราเข้าใจตรงกันหรือไม่
ตอนที่เราคุยกันมันจะเป็นคำพูด เราต้องตีคำพูดออกมาให้เป็น Flow แบ่งออกเป็น Journey แล้ววาดออกมาเพื่อดูว่า ความเข้าใจเรายังขาดตรงไหนไปหรือเปล่า สำหรับพี่นะ ส่วนตัวที่เริ่มทำแบบตอนที่ยังไม่มีประสบการณ์ ก็จะใช้เวลาตรงนี้ค่อนข้างเยอะ
ซึ่ง Flow ตัวนี้พี่มองว่า Product Owner ควรต้องทำ เพราะถ้าใช้วิธีเล่าหรือสรุปเป็นข้อความส่งไป มันยากต่อการทำความเข้าใจ และใช้เวลาในการอ่านด้วย การอธิบายด้วยภาพง่ายกว่าอยู่แล้ว การทำ Flow อันนี้ก็จะช่วยตัวเราในการทำความเข้าใจ และในการนำเสนอให้คนอื่นนำไปทำงานด้วย
และถ้าเราสรุปการคุยกันสองชั่วโมงออกมาเป็น Flow สัก 2–3 อันได้ ก็จะเห็นแล้วว่าเราเข้าใจมันจริง ๆ มันไม่ฟุ้งแล้ว
พี่พีท: พี่เสริมด้วย เรียกเรื่องนี้ว่าเป็นการ Visualization ละกัน Flow ที่ Product Owner ทำจะหมายถึงว่า จะมีอะไรเกิดขึ้นกับ User บ้าง แต่ในมุมของ System ที่ออกแบบไว้เพื่อสื่อสารกับทีม บางมุมก็เอาไปใช้สื่อสารกับลูกค้าได้ด้วยเหมือนกัน ว่าตัวระบบหลังบ้านเราจะทำแบบนี้นะ ของพี่เองเวลาทำจะเขียนเป็น Document ออกมาเพื่อสรุปความเข้าใจตัวเองและให้แน่ใจว่าเรากับเขาเข้าใจตรงกันนะ
จริง ๆ ตรงนี้มันแอบเป็นในมุมประสบการณ์ที่พี่ทำที่เก่ามากกว่า ตอนนั้นบริษัทไม่มี Product Owner เวลาคุยกับลูกค้า เราต้องสรุปก่อนว่า เราจะทำอะไรให้เขา สรุปออกมาเป็น Feature List แล้วแตกรายละเอียดไปว่าแต่ละอันทำแล้วจะมีข้อจำกัดอะไรบ้าง แล้วเรามี Assumption หรือข้อสันนิษฐานว่าอะไรในมุมการออกแบบระบบ
มันแอบเป็นทั้ง System Design และสรุป Requirement ไปในตัว เพราะว่าเรากำลังจะบอกว่า ระบบที่เราออกแบบ Assumption เป็นแบบนี้นะ ถ้าไม่ใช่ให้บอกตั้งแต่ในขั้นตอนนี้เลยก่อนที่จะเริ่มงาน
นิสัยพี่กับพี่เข็มจะเป็นเหมือนกันเลย จะนั่งทำ Feature List มา แล้วถ้าตรงไหนไม่แน่ใจก็โน้ตไว้ก่อนเลยว่าเป็น Assumption นะ แล้วก็ระบบจะทำงานแบบนี้ มี Data อยู่กี่ประเภท แล้วแต่ละส่วนสัมพันธ์กันยังไง
แล้วก็ในช่วงโปรเจกต์ล่าสุดที่ทำกับพี่เก๋ โปรเจกต์มัน Technical มากจนต้องนั่งหา Tool มาวาดเป็นรูปในมุม Logic หลังบ้าน เดี๋ยวนี้เวลาสื่อสารก็จะมีรูปมาด้วย ข้อดีก็คือประหยัดเวลาและเข้าใจตรงกันมากขึ้น เอาจริง ๆ ก็คงไม่เข้าใจตรงกันทั้งหมด แต่ก็ได้สักประมาณ 60–70% ที่เหลือก็ขึ้นอยู่กับตอนทีมหรือลูกค้าเอาไปทำต่อแล้ว ว่าเขาเข้าใจมากกว่านั้นแค่ไหน แต่อย่างน้อยเราก็มั่นใจได้ว่า 60–70% มันอยู่ใน Document แล้ว
Q: สิ่งที่อยากแชร์ให้กับคนอื่น ๆ ที่ต้องทำหน้าที่ Get Requirement ด้วยเหมือนกัน
พี่เก๋: สำหรับพี่คือการฟังเขาให้มาก ๆ อย่าเพิ่งไปขัดเขา ถามเพิ่มได้ ในสิ่งที่สงสัย แต่ไม่ควรชี้นำว่าควรทำอย่างนั้นอย่างนี้ในขั้นตอนการคุย Requirement การบอกเขาว่าควรทำอะไร ไม่ใช่เวลาที่เหมาะในช่วงแรก ฟังให้มากก่อน แล้วค่อยเสนอความเห็นของเราหลังจากเรา Grooming รายละเอียดกันครบแล้ว
หลัก ๆ คือ ฟังให้เข้าใจ อย่าเพิ่งบอกว่าควรเป็นอะไร
พี่เข็ม: อาจจะแชร์จากประสบการณ์สมัยก่อนที่ทำงานแบบไม่มี Product Owner พวกพี่จะรับหน้าที่นั้นไปในตัว จะเป็นเรื่องการสื่อสารเนี่ยแหละ บางทีต้องเลือกระดับการสื่อสารให้ถูก ลูกค้าแต่ละเจ้าแต่ละคนมีระดับ Proficiency ไม่เหมือนกัน
บางเจ้าคนให้ Requirement เป็น End User มาก ๆ ความท้าทายของกลุ่มนี้คือข้อมูลจะเยอะมาก และปนกันไปหมด ในขณะที่ถ้าไปเก็บ Requirement จากคนที่ถูกมอบหมายให้ทำระบบ เขาอาจจะไปทำการบ้าน มี Solution บางอย่างมาแล้ว กลุ่มนี้ความง่ายคือเข้าประเด็นเร็ว ข้อเสียคือ การกลั่นกรองมาแล้วของเขามันแก้ Pain Point จริง ๆ หรือเปล่า ก็ต้องระวังว่าระบบทำออกมาแล้วไม่ได้แก้ปัญหาอะไรให้ผู้ใช้งานเลย
สิ่งที่จะช่วยป้องกันกรณีนี้คือกลับไปที่พื้นฐาน เราต้องจินตนาการว่าถ้าเราเป็น User แล้วต้องมาใช้ระบบนี้จะคิดว่ามันแปลกมั้ย ถ้าเอ๊ะตรงไหนก็ถามกลับไป ว่าถ้าทำแบบนั้นแบบนี้จะลำบากหรือเปล่า มันก็จะมีคำตอบที่เกี่ยวข้องกับ User Journey จริง ๆ เข้ามาช่วยเสริม ช่วยให้เราเข้าใจการใช้งานของ User มากขึ้น
พี่เนม: ของพี่ค่อนข้างตรงกับที่พี่ ๆ บอก ตอนที่ฟัง Requirement มันจะเหมือนเราเก็บข้อมูล แล้วเอามาจับกับความรู้ที่เรามี ถ้าอันไหนไม่รู้ให้ทดไว้ในใจก่อน ไปทำการบ้าน และต้องไม่ลืมเอาจินตนาการของเราไป Test กับ User ในเชิงไอเดียว่ามันใช่หรือเปล่า ซึ่งต้องระวังด้วยว่าคนที่เราเอาไป Test ด้วยเขาอาจจะไม่ใช่ User จริง ๆ
แล้วก็อีกเรื่อง คือ ให้เก็บเกี่ยวประสบการณ์ติดตัวไว้ให้มากที่สุด
ศึกษาเว็บหรือแอปพลิเคชั่นให้เยอะ ๆ แล้วเวลาเราไปเก็บ Requirement ต้นทุนเราจะเยอะกว่าคนอื่น ถ้าเราไม่มีต้นทุนนี้ ดอกแรกคือมันจะปิงปองไอเดียกับลูกค้ายาก ดอกสองที่จะตามมา คือ ต้องเสียเวลาทำการบ้านให้ตามเขาให้ทัน โดยส่วนใหญ่เวลาพี่เล่นแอปพลิเคชั่น นอกจากเล่นตามปกติ ก็จะจำ ๆ ไว้ด้วย ดูว่าเขาทำแบบไหน ถ้าทำแบบนี้ระบบด้านหลังจะเป็นยังไง ถ้าเป็นเราจะทำยังไง
พี่เข็ม: พี่จะขยายต่อจากพี่เนมนิดนึง เราต้องเก็บสะสมแต้มบุญน่ะ พี่เนมจะพูดในเชิงแอปพลิเคชั่นหรือระบบ ซึ่งก็สำคัญ อีกอันคือเรื่อง Process ละกัน พี่จะชอบสังเกตในชีวิตประจำวัน เช่น เราไปเที่ยวห้าง เราเห็นพนักงานแคชเชียร์คิดเงิน พี่จะสังเกตว่าตอนเขาคิดเงิน เขากดอะไรเยอะแยะนะ เรื่องเล็ก ๆ น้อย ๆ แบบนี้ ถ้ามีโอกาสได้เห็น ได้สังเกต ก็เป็นสิ่งที่เอากลับมาสะสมเป็นคลังความรู้ให้ตัวเองได้
หลาย ๆ ครั้งตัวโปรเจกต์ที่เราต้องไป Get Requirement มันก็ไม่ได้ติดอยู่ในโลก IT หรือดิจิทัลอย่างเดียว มันจะต้องไปข้องเกี่ยวกับโลกความเป็นจริง ที่คนทั่วไปจะต้องเอาสิ่งนี้ไปใช้ด้วยได้ มันเป็นหน้าที่เราที่ต้องออกแบบระบบให้มันตอบโจทย์โลกความเป็นจริงด้วย ซึ่งการสังเกต Process พวกนี้ก็จะเพิ่มคลังแต้มบุญ ที่จะสามารถหยิบมาเสนอในการคุยกันได้ แล้วหยิบข้อสังเกตในชีวิตจริงนั้น มา Map กับดิจิทัลว่ามีอะไรที่ดิจิทัลจะช่วยจัดการตรงนี้ได้
พี่เก๋: พี่จะคล้าย ๆ กัน คือ สังเกตจากสิ่งรอบตัว เรื่องบางเรื่องมันอาจจะไม่ได้ต้องแก้ไขเรื่องระบบ มันแค่แก้ไขที่ Process เราก็ต้องสะสมประสบการณ์ไปเรื่อย ๆ ถึงจะบอกได้
พี่พีท: หาวิธีเก็บเกี่ยวประสบการณ์ให้ Effective ที่สุด อย่าปล่อยให้ประสบการณ์มันผ่านไปเฉย ๆ ควรช่างสังเกต คิดถึงเหตุการณ์เบื้องหลังว่าทำไมเขาถึงทำแบบนั้น อะไรประมาณนั้น
Q: สุดท้ายสำหรับพี่พีทและพี่เข็ม ในมุมของ Developer ที่เคยต้องรับหน้าที่ Get Requirement เอง มีอะไรอยากแนะนำให้กับ Developer ที่ต้องอยู่ในกระบวนการนี้เหมือนกันมั้ย
พี่พีท: ถ้าส่วนตัวพี่ พี่มองว่า “พูดให้น้อย ต่อยให้หนัก” พอเราเข้าไปคุย เรามีไพ่ของการเป็น Developer อยู่แล้ว ลูกค้าจะเชื่อเราในมุมของคนที่นำไอเดียไปทำจริง
ทีนี้ คำว่าพูดให้น้อย หมายถึงสิ่งที่พูดกันไปในตอนแรก ว่าฟังเขาให้เยอะ ๆ
ต่อยให้หนัก หมายถึง ตอนที่จะให้ความเห็นเรากลับไป ให้พูดในสิ่งที่เขาจะจำเราได้เลย ลงรายละเอียดในคำพูด และวางกรอบให้ชัด ว่าที่เราพูดเพราะเราเข้าใจแบบนี้ มีเหตุผลแบบนี้ แล้วตอนทำจะเป็นยังงี้ อธิบายให้เขาเห็นภาพว่ามันยากง่ายขนาดไหนในการจะทำสิ่งนี้
อีกความหมายที่ซ่อนอยู่ในการต่อยให้หนัก คือ ถามให้เหมือนเราเป็นคนที่ไม่รู้อะไรเลย แต่ถามในจุดที่เรารู้ว่าเขาอาจจะยังคิดไปไม่ถึงตรงจุดนั้นแน่นอน แล้วมันจะทำให้ลูกค้าไว้ใจเรา ในฐานะที่เป็นคนถามดักในสิ่งที่เขามองไม่เห็นได้
พี่เข็ม: แต่ก็โน้ตว่า ถ้าจะทำแบบนี้ได้ เราเองก็ต้องแม่นนะ พูดน้อยแต่ต่อยพลาดเป้า ถ้าเป็นมวยจริงก็มีโอกาสแพ้สูง ต้องต่อยให้ตรงประเด็น
และประเด็นสุดท้าย Developer บางส่วน จะไม่ค่อยชอบเข้าไปฟังการคุย Requirement บางคนอาจจะรู้สึกว่าไม่ใช่ขอบเขตงานของเขา หรือบางคนอาจจะว่ามันยาวนาน คุยกันไม่ตรงประเด็นสักที พี่อยากแนะนำว่าอย่าคิดอย่างนั้นเลย ทุกอย่างมันเป็นประสบการณ์ อย่างน้อยที่สุด เราจะได้รู้ว่า User หรือใครก็ตามที่ไม่ใช่ Developer เขามีวิธีคิดยังไง สุดท้ายยังไงมันก็กลับมาเพิ่ม Value และ Skill ให้เราอยู่ดีโดยไม่รู้ตัว เราเอาตัวเราเข้าไปฟัง เชื่อเถอะ ว่าจะได้อะไรเยอะจากการเข้าไปฟังครั้งนั้น ๆ แน่นอน
จบแล้วกับ Muze Roundtable หัวข้อแรกของเรา ที่ชวนพี่ ๆ มาแชร์ประสบการณ์และเทคนิคส่วนตัวกัน จากการคุยกันในครั้งนี้ แน่นอนการ Get Requirement ไม่ใช่เรื่องง่าย และมีรายละเอียดยิบย่อยที่ต้องอาศัยประสบการณ์ในการหาวิธีที่ใช่ในบริบทของโปรเจกต์ และลักษณะการทำงานของตัวเอง ขอสรุปส่งท้ายด้วย 3 สิ่งสำคัญที่พี่ ๆ ทั้งสี่คนย้ำเกี่ยวกับการเก็บ Requirement ให้มีประสิทธิภาพ คือ รับฟัง เข้าใจ และเห็นให้ถึงแก่นของปัญหา
