Muze Roundtable: ออกแบบ System Design อย่างไร ให้เป็น Product ที่ดี?
ก่อนที่เราจะพัฒนา Product ให้ดีได้นั้น มีขั้นตอนอย่างไร? ต้องคุยกับลูกค้าเพื่อรับรู้ถึงข้อมูลเชิงลึกแบบไหน? ปัญหาที่ต้องเจออย่างหลีกเลี่ยงไม่ได้คืออะไร? และจะต้องแก้ไขอย่างไรถึงจะเหมาะสม?
มาร่วมจับเข่าคุยและค้นหาคำตอบของคำถามนี้ ไปกับขุนพลด้านเทคโนโลยีของ Muze Innovation อย่างพี่เข็ม พิชาน์ และพี่พีท กิตติพัฒน์ Chief Technology Officer (CTO) และพี่แบงค์ วสันต์ Head of Software Development Department กันได้เลย!
Q: คำว่า System Design ที่ดีของพี่ ๆ ทั้ง 3 เป็นอย่างไร?
พี่เข็ม: ในมุมมองของพี่ คือการออกแบบระบบที่ตอบโจทย์ Stakeholder หลาย ๆ ด้านให้ได้มากที่สุด และครอบคลุมที่สุด หรืออย่างน้อยก็มี Priority มาว่าเราจะตอบโจทย์ใครเป็นอันดับแรกก่อน แล้วใครคืออันดับที่สองและสาม เพราะเราไม่จำเป็นต้องออกแบบทุกระบบให้ใหญ่เป็น global scale ทุกครั้ง เพราะบางทีระบบนั้นอาจจะนำมาใช้แค่เพียงชั่วคราวหรือระยะสั้น หรือมีงบประมาณที่จำกัดมาก ๆ
พี่แบงค์: เห็นด้วยกับพี่เข็มครับ และขอเสริมเรื่องการตอบโจทย์ Stakeholder ในตอนนั้นระบบที่อยากได้ อาจจะมี Concern หลายอย่างจากทางลูกค้า อย่างเช่น Budget, Security หรือ Time ที่อาจกระทบกับระบบที่เราออกแบบทั้งหมดได้ เงื่อนไขหลายอย่างเหล่านี้เป็นสิ่งที่เราต้อง Follow ตาม ดังนั้น System Design ที่ดี ก็ควรจะต้องตอบโจทย์ของ Stakeholder รวมถึงเงื่อนไขลูกค้ามีในตอนนั้นด้วย
พี่พีท: พี่ขอตอบอีกมุมนะครับ การ Design ระบบจะมีอีกมุมคือ ถ้าเราอยากมีระบบ ระบบควรจะทำให้มัน Composable ซึ่งหมายถึงว่ามันควรจะเป็นจิ๊กซอว์ที่ต่อกันได้ง่ายมากพอ เช่น สมมติว่าในอนาคตเราบอกว่าเรามีงบเท่านี้ เราจะทำตุ๊กตาตัวแรกที่ไว้ Prove ว่าเท่านี้โอเคแล้วนะ หรือว่าเป็นการ Test ว่าพาร์ตไหนที่สำคัญสำหรับลูกค้าจริง ๆ แล้วเราก็จะเอาพาร์ตนั้นเป็นตัวปูพรมแรก เสร็จแล้วพอลูกค้าบอกว่ามีงบเข้ามาเพิ่ม อยากจะเปลี่ยนตรงนู้นตรงนี้ ก็สามารถเปลี่ยนได้โดยที่ไม่ต้องทุบทิ้งทั้งหมด
Q: การทำ System Design ที่ดี มักจะเริ่มจากการเก็บ Requirement จากลูกค้า พี่ ๆ อยากแนะนำให้โฟกัสจุดไหนเป็นพิเศษไหม?
พี่พีท: คำถามนี้อยู่ที่ว่าเราคุยกับใคร ยกตัวอย่างเช่น เราคุยกับคนที่ให้ Requirement ได้ แต่ไม่ได้เป็น Technical หมายถึงว่าไม่ได้เป็นคนออกแบบระบบ หรือดูแลระบบ เขาอาจจะไม่เข้าใจในเชิงของระบบ แต่ว่าเขาจะเข้าใจในเชิงของภาพรวมว่าอยากได้อะไร อันนี้ก็จะต้องคุยอีกรูปแบบหนึ่ง ซึ่งส่วนมากคนที่ให้ Requirement ภาพใหญ่ เขาจะเห็นแค่ภาพ Output ที่อยากได้แต่จะไม่รู้ Detailed Input ที่ feed มาจาก Ecosystem ที่เขามีอยู่ เพราะฉะนั้นเวลาคุยเราก็จะพยายามโฟกัสถึงจุดที่เขาสามารถให้ได้ เราก็จะขอ Output เป็นหลัก แล้วในมุมกลับกันก็คือ เราก็จะบอกเขาว่าเราอยากได้อีก Meeting หนึ่ง สำหรับไปคุยกับคนที่รู้ Detail ในเชิง Technical เพิ่มเติม เพื่อเราจะได้ Design ระบบให้ครบทุกส่วน ซึ่งเวลาไปคุยกับ Technical ส่วนใหญ่เราจะพยายามคุยให้ถึง Edge Case ที่มันมีสิทธิเกิดขึ้น
พี่แบงค์: ของพี่จริง ๆ ก็คล้ายๆ กัน อันดับแรกต้องเข้าใจภาพปัจจุบันของลูกค้าก่อนว่าสิ่งที่อยากได้คืออะไร เขาเป็นอย่างไรอยู่ มีอะไรบ้าง แล้วอาจจะเหมือนที่พี่พีทบอก คือแค่ประชุม Session นั้นมันอาจจะกินเวลาหมดแล้ว ก็อาจจะมีเวลาให้เราตั้งหลักสักนิดหนึ่งว่า จากที่เราฟังมาเราคิดว่าลูกค้าต้องการอะไร ก็จะมีการนัดคุยกันก่อนว่าโอเค วันนี้ฟังมาได้อะไร คิดว่าอะไรจะตอบโจทย์ คิดว่าตรงไหนคือ Pain คิดว่าตรงไหนที่เราไปจับได้ ระบบควรจะออกมาแบบไหน แล้วก็อาจจะมีอีก Meeting ที่ไปเจาะลึกหน่อย ว่าเราเข้าใจถูกไหม ถ้าสร้างอันนี้สามารถช่วยได้หรือเปล่า แล้วดูว่าลูกค้าเห็นว่าอย่างไร คิดว่ามันเป็นเหมือน Journey ว่าตอนแรกฟังก่อนว่าลูกค้ามีอะไร เป็นอย่างไรบ้าง และเราเสนออะไรได้บ้าง
Q: แล้ววิธีการคุยกับลูกค้า ให้ Get Requirement ที่ต้องการ ควรเตรียมตัวเรื่องการพูดอย่างไรดี?
พี่เข็ม: สำหรับในพาร์ตของ System Analyst อยากบอกว่าถ่อมตัวเข้าไว้ เพราะว่าบางครั้งในบทสนทนา ประเด็นที่เราต้องการจะ Get Requirement หรือขุดคุ้ยหาความจริงก่อนที่เราจะเอาไปออกแบบระบบ บางครั้งเราอาจจะต้องใช้ความรู้ ความเป็น Expert ของเราที่มีอยู่ เพื่อไปอธิบายบางอย่างว่าทำแบบนี้จะดีกว่าอีกแบบหนึ่ง เพียงแต่ว่า Mood และ Tone ในการสนทนาควรจะไปในวิธีทางที่ค่อนข้างถ่อมตัว (Humble) อันนี้คืออาจจะเป็นเพราะว่าเป็นวัฒนธรรมแบบเอเชียด้วยแหละ เราเป็นคนไทย ถ่อมตัวไว้ก่อนก็ไม่ใช่เรื่องเสียหาย ทั้งนี้การสนทนาก็ขึ้นอยู่กับแต่ละวัฒนธรรม กับชาวต่างชาติก็จะเป็นอีกรูปแบบหนึ่ง
Q: หลังจากที่ออกแบบระบบประมาณหนึ่งแล้ว พี่ ๆ มีวิธีการพรีเซนต์ให้ลูกค้าเข้าใจอย่างไรบ้าง?
พี่พีท: อันนี้ก็ขึ้นอยู่กับลูกค้าแต่ละเจ้า คือจะมีลูกค้าประเภทที่ต้องลง Detail กับลูกค้าประเภทที่ไม่ต้องลง Detail ซึ่งลูกค้าที่ลง Detail เขาจะดูละเอียดว่า System Design ออกมาอย่างไร A ต่อกับ B แล้วต่อกับ C ตอนที่ต่อ B กับ C ใช้วิธีอะไรคุยกัน แต่บางคนที่ดู Detail จัด ๆ จะลงไปถึงแบบอันนี้ต้องใช้ Network อย่างไร แล้วตรงนี้จะต้องมี Firewall อย่างไร หรือว่า Communication จังหวะนี้เป็นอย่างไร ก็จะมีความลง Detail ที่ไม่เท่ากัน
แต่สำหรับพี่ปกติแล้วเวลาถ้าอยากจะคุยภาพรวม จะคุยเป็นก้อน ๆ ว่าระบบทั้งหมดมีอยู่กี่ Component แล้วแต่ละ Component คุยกันอย่างไร เวลาที่พี่ไปคุยกับลูกค้าส่วนมากพี่จะทำเอกสารเป็น Markdown มาก่อน อารมณ์ประมาณว่าไล่ความคิดของตัวเองเขียนออกมาเป็น Document แล้วก็เอาตัวนี้ไป Present ให้ลูกค้าดู มันจะทำให้ลูกค้าตามภาพได้ทัน แล้วเวลาคุยแล้วออกทะเล เราจะดึงกลับมาง่ายมาก
พี่แบงค์: จริง ๆ ที่พี่พีทบอกขึ้นอยู่กับลูกค้าซะส่วนใหญ่ หมายถึงว่าแล้วแต่องค์กรด้วยว่า เราเป็น IT คือเรากำลังเสนอระบบ IT ถ้าลูกค้าเป็นบริษัทที่มีความเชี่ยวชาญในด้าน IT อยู่แล้ว เขาอาจจะต้องการรายละเอียดเยอะอย่างที่พี่พีทบอก แต่ถ้าเกิดเป็นบริษัทที่เขาเป็น Industry ที่จริง ๆ Operation ส่วนใหญ่ไม่ค่อยมีระบบ IT ใช้ แล้วอยากได้ระบบ IT ใหม่ ๆ หรือวิธีการ Approach วิธีการคุยวิธีการเล่าให้ฟังก็จะต้อง Tone Down ลงมา ไม่ใช่แบบ Technical มาก อาจจะต้องเล่าไปถึงสิ่งที่เรา Offer ลูกค้าว่าจะได้อะไรบ้าง จะไป Match กับ Operation ตรงส่วนไหน อะไรแบบนี้
Q: แล้วปัญหาอะไรที่มักเจอ ตอนพรีเซนต์งานอย่างเลี่ยงไม่ได้?
พี่เข็ม: ปัญหาคลาสสิกเลยคือ เล่าให้ฟังแล้วลูกค้าบอกว่าเข้าใจแต่จริง ๆ แล้วไม่เข้าใจ แล้วถ้าหนักกว่านั้นก็คือ ไม่ได้ฟังหรือไม่ได้มองอย่างลงลึกไปในรายละเอียดที่เราพยายามจะสื่อสาร ทั้งในแง่ของตัว Document เองหรือว่าการนำเสนอก็ดี แล้วสุดท้ายจะเป็นปัญหาในภายหลังได้
Q: ใช้วิธีไหนในการรับมือหรือจัดการปัญหานี้ ให้กระทบทีมน้อยที่สุด?
พี่เข็ม: ในฐานะที่เราเป็น System Analyst เราต้องหมั่นสังเกตอีก Party ที่เรากำลังพูดคุยด้วย เช่น ภาษากาย คำถามของเขา คำพูดของเขาเวลาที่เรานำเสนอไป หรือส่งอะไรให้ไป แล้วเราจะพอบอกได้ว่าจริง ๆ แล้ว ลูกค้าตามเราทันอยู่ หรือแค่ตอบผ่าน ๆ ถ้าเรารู้แล้วว่าแค่ตอบผ่าน ๆ ไป ถามว่ามีวิธีแก้ไหม อาจจะไม่ได้เป็นวิธีแก้หรอก แต่เราอาจต้องเตรียมทางหนีทีไล่ไว้นิดนึง เช่น เราอาจจะต้องไปลองดูว่าสื่อสารไปทาง Product Owner ได้ไหม ให้ Product Owner ลองไป Make Sure กับลูกค้าอีกที
พี่พีท: ตอนที่พวกพี่เคยทำ พี่จะใช้วิธีว่าประกบไปด้วย Document คือพี่จะดักที่ Proposal ก่อน หมายถึงว่าใน Proposal พี่จะเขียน Assumption ไปด้วยว่าเรา Assume ว่ามันคืออย่างนี้นะ แล้วสิ่งนี้จะปรากฏอยู่ใน Document หากมีเรื่องอย่างนี้แทงขึ้นมาจริง ๆ เราก็จะบอกว่ามันคือก้อนนี้ แต่ถ้ามันคือพาร์ตที่เรามองว่าจริง ๆ บางเรื่องก็หลับตาได้ เราก็จะบอกให้ลูกค้าเห็นว่าอันนี้ตอน Proposal จริง ๆ เป็นอย่างนี้นะครับกลับไปดูได้ แต่ว่าเดี๋ยวผมแก้ให้ เพราะฉะนั้นเราต้อง Assume ให้ได้ก่อนว่าอาจจะมีปัญหาแบบนี้เกิดขึ้น แล้วเราก็หาทางบล็อกไว้เลย หรือไม่อย่างนั้นก็ต้องหาทางแจงลงไปใน Document ให้เห็นว่าพาร์ตนี้เราไม่ Cover นะ
Q: รู้ได้อย่างไรว่า System Design ที่ออกแบบมา ดีพอแล้ว?
พี่เข็ม: จริง ๆ อันนี้อยู่ที่สถานการณ์ของโปรเจกต์นั้น ๆ ด้วยนะ ยกตัวอย่างเช่น บางโปรเจกต์สถานการณ์คือต้องรีบ Launch แล้ว ระบบนี้ต้องรีบทำมี Due Date ที่ชัดเจนมากเลื่อนไม่ได้ ถ้าเป็นสถานการณ์แบบนี้อาจจะง่ายหน่อย เพราะว่าเหมือนทุกอย่างถูกบีบรัดด้วยเวลา ด้วย Timeline เราจะรู้ได้ง่าย ๆ เลยว่าพอหรือไม่พอ ก็คือให้มองไปที่ปลายทางเลยครับ ไปที่ Due Date เลยว่าในวันนั้นที่ระบบที่ต้องขึ้น จะต้องทำงานอะไรได้บ้าง แล้วถ้าตอบโจทย์แล้วอันนี้ถือว่าเพียงพอแล้วนะสำหรับสถานการณ์ตรงนั้น
แต่ถ้าเกิดเป็นสถานการณ์ทั่ว ๆ ไป ที่เราไม่ได้มี Timeline มาบีบรัดขนาดนั้น เราต้องการจะ Deliver หรือทำระบบที่มัน Stable ไปเลย สามารถใช้ได้ยาว ๆ ถ้าอย่างนั้นเราคงมองแค่เรื่องของ Functional หรือเรื่องของสิ่งที่ตัวระบบทำงานได้ไม่พอ อาจจะต้องมองไปถึงเรื่องของการ Maintenance เช่นทำ Back Up อะไรอย่างนี้ ทำยากไหม ทำบ่อยไหม หรือต้องมีการ Migrate ข้อมูลเรื่อย ๆ หรือเปล่า เรื่องของ Maintenance และการ Extend คือการต่อยอด Element ของระบบเพิ่มเติมเข้าไปให้รองรับมากขึ้น
พี่แบงค์: คำว่าพอแล้วต้องเป็นพอจากทั้งสองฝั่ง ของคนออกแบบระบบคือเรา กับทางของเจ้าของระบบด้วย ดังนั้นระบบต้องตอบโจทย์ทั้งลูกค้าและเรา ว่าลูกค้าควรจะได้สิ่งที่อยากได้ แต่ว่าได้ทั้งหมดหรือไม่ เราอาจจะต้องดูว่าด้วยเงื่อนไขหลาย ๆ อย่าง ด้วยระยะเวลา ด้วยเงิน หรือด้วยคน หรือสิ่งที่อยากได้มัน Typical ขนาดไหน แล้วสิ่งที่ได้จะตอบโจทย์อะไรบ้าง เพียงพอแล้วหรือเปล่า ถ้าลูกค้า Say Yes มา พี่ว่าก็ตอบโจทย์ทั้งสองฝั่ง
พี่พีท: คำว่าเพียงพอของพี่ คือพี่มองแค่เส้นตรงเส้นแรกว่า ถ้ามันมี Error Case เราจัดการได้หรือเปล่า แล้วเส้นตรงเส้นแรกเราสามารถ Deliver จนจบ Business Value ได้หรือไม่ ถ้าได้พี่มองว่าก็เพียงพอ แต่คำว่าเส้นตรงของพี่ไม่ได้แปลว่ามันจะเป็นเส้นตรงเส้นเดียวที่จะถูกลากขึ้นมา แล้วเราไม่สามารถเอาอะไรเข้าไปแทรกได้เลย ทำขึ้นมาเพื่อตอบแค่โจทย์เดียวแล้วปิดตัวเองตาย ไม่สามารถ Extend ได้ ไม่สามารถแก้ไขได้ หรือเส้นตรงเส้นนี้ ถ้าจะแก้ตรงกลางตรงนี้นิดหนึ่งก็คือต้องทุบทิ้ง แบบนี้พี่ก็เรียกว่าไม่เพียงพอ
เพราะฉะนั้นในมุมพี่มีอยู่แค่สองมุม มุมที่หนึ่งคือ ตัว Business Value Deliver ได้ไหม แล้วก็ส่วนที่สองก็คือ เมื่อไหร่ที่ต้อง Extend มันพอจะ Extend ได้ไหม หรือว่าเมื่อไหร่ที่จะต้องทุบทิ้ง ต้องทุบทิ้งเยอะขนาดไหน ถ้าทุบทิ้งเยอะมาก แต่ Budget มัน Satisfy กับเรื่องนั้น ก็โอเค แต่ว่าถ้าเกิด Budget มันเพียงพอเราก็ควรจะทำให้ตรงนั้นมันเป็น Exemptible เป็นข้อต่อที่ Exemptible จริงๆ ก็ประมาณนี้ครับ
เป็นอย่างไรบ้างครับกับ Muze Roundtable ในหัวข้อ ออกแบบ System Design อย่างไรให้เป็น Product ที่ดี? Muze ขอสรุปทั้งหมดให้ฟังอีกครั้งว่า การจะออกแบบระบบที่ดีนั้น ต้องเริ่มจากเข้าใจโจทย์ของลูกค้าก่อนเลย ทำให้การรับฟัง Requirement ตั้งแต่ Meeting แรกสำคัญมาก ๆ เพื่อที่ทีมจะได้เอาข้อมูลมาวิเคราะห์และวางแผนทำงานต่อได้ หลังจากนั้นก็จะเป็นการพัฒนาระบบ และนัดพรีเซนต์งานกับลูกค้า ว่าสิ่งที่เราออกแบบมาช่วยเรื่องอะไร ตอบโจทย์ตรงจุดไหน อะไรที่ควรปรับแก้ หรืออะไรที่อยากให้เพิ่ม เพื่อส่งมอบ System Design ที่ดีที่สุดตามที่ลูกค้าต้องการ
เชื่อว่าเพื่อน ๆ ที่อ่านมาจนถึงตรงนี้ คงได้รับรู้ถึงเทคนิคดี ๆ และการแชร์ประสบการณ์ที่น่าสนใจมากมาย จากพี่เข็ม พี่พีท และพี่แบงค์ กันไปไม่มากก็น้อยแน่นอน แล้วกลับมาพบกันใหม่กับ Muze Roundtable ในหัวข้อที่น่าสนใจครั้งหน้านะครับ 🙂
