Agile Software Development with ‘PDCA’, Value Proposition Canvas, and UX/UI Team Process #LearningWithSCK
บทความนี้เป็นการสรุปสาระที่ได้จากการเรียนรู้ในวันที่ 16–17 กุมภาพันธ์ 2566
Agile คือ Responding to change โดยมี 4 Manifesto หลัก ซึ่งก็เทียบเคียงกับ Value ของบริษัทเราพอดี (ซึ่งมีอยู่หลายข้อ)
แล้วเราจะทำ Software แบบไหนให้ตรงกับ Value?
ทำ Software ที่เร็ว อย่างมีคุณภาพ
เร็ว ที่แปลว่า ได้ Feedback จากลูกค้าเร็วขึ้น ซึ่งการนำ Agile มาใช้ เราก็ทำงานเป็นหลักสัปดาห์ แทนที่จะรอ 3–6–9–12 เดือน
เอาไปเช็คจริงๆ ลดการที่เราคิดไปเอง
PDCA ในบริบทของที่นี่
- วางแผน จากความต้องการของลูกค้า ต้องมี UX Process หรือ Data-Driven Process
- พัฒนาระบบ เน้น UX/UI และต้องชัดเจนว่า Release เพื่อแก้ Pain อะไร
- ใช้งานจริง พร้อมเก็บข้อมูลการใช้งาน
- เอาข้อมูลไปคิดต่อ เพื่อปรับใช้ในรอบหน้า
ซึ่งก็จะคล้ายๆ กับ หนังสือ The Lean Startup — Build Measure Learn
ที่อยากได้ เพื่อให้ประสบความสำเร็จในการทำ PDCA คือ ได้รับ Feedback จากผู้ใช้งานจริง ในระยะไม่เกิน 1 เดือน
- Iteration: Plan — Do — Check — Adjust
- Iteration = ระยะเวลา 10 วันทำการ (2 สัปดาห์)
- Deliver latest version: ทุกๆ เดือน
- อยู่บน SIT Env. หรือ อยู่บน UAT Env.
(ส่วน Level ถัดไป เป็นเรื่องของอนาคต)
P — Planning
ถ้าปัจจุบันเรามีเว็บไซต์อยู่ แล้ว Business บอกอยากให้ทำ Mobile
คำถามคือ การทำ Mobile ขึ้นมาช่วยอะไร?
อาจจะช่วยให้ Process เร็วขึ้น เช่น ทำให้ Flow การอนุมัติงานเร็วขึ้น xxx เปอร์เซ็นต์ จากการที่ต้องมานั่งโต๊ะเพื่ออนุมัติงาน คนรอต้องรออย่างน้อย 2 ชั่วโมง เพราะหัวหน้าไม่อยู่โต๊ะ แต่พอมีมือถือ แค่มี Notification ก็กดอนุมัติได้เลย เร็วขึ้น
แต่ผ่านไปสามเดือน ให้ลองวัดดูด้วยว่า พฤติกรรมคนเปลี่ยนหรือเปล่า หรือต่อให้มีมือถือ ก็เอามือถือวางอยู่บนโต๊ะเหมือนเดิม แปลว่า การมี App อยู่ในมือถือก็ไม่ช่วยอะไร
- การลงทุน มันคือการใช้คนที่มี ทำยังไงให้ได้ประโยชน์สูงสุด
- อะไรที่ทำครั้งเดียวแล้วใช้ต่อได้ แล้วดี เช่น หน้า Login ที่มีอยู่ทุกระบบ ก็ใช้ Username-Password เดียวกัน สามารถทำ Single Sign-on ได้ไหม
- ถ้าทำดีพอ เอาไปขายต่อที่อื่นได้ไหม
- ถ้าทำไปแล้วสองสามครั้ง มีหลักฐานมายันเจ้าของความต้องการว่า มันไม่เวิร์ค ก็เลิกทำเถอะ
output คือจำนวน Feature ที่เกิดขึ้น
แต่ output จำนวนมากที่เกิดขึ้น มันวัด outcome ได้ไหม?
outcome ไม่ต้องอยู่ใน Agile ก็ได้ waterfall ปกติ ก็ต้องมีเหมือนกัน
ผลลัพธ์จากการวางแผน
- Persona รู้จักลูกค้า และ Pain Point ปัญหาและจุดเจ็บปวดที่พบ พร้อมกับการจัดเรียงลำดับความสำคัญ
- สมมติฐาน ที่จะแก้ Pain Point ที่เราพบเจอ ซึ่งโดยการทำงานปกติ PO จะทำงานร่วมกับทีม UX/UI อย่างใกล้ชิด
เพื่อชี้ให้เห็นชัดว่า ปัญหาคืออะไร
ปัจจุบันมีการทำงาน (As-is) แบบไหน เพื่อแก้ปัญหานั้นเฉพาะหน้า แบบ workaround ไปก่อน
อะไรที่เราจะทำเพื่อแก้ปัญหา (To-be)
แล้วในตลาดมันมีวิธีแก้อยู่แล้วไหม ถ้าเราทำออกไป เราจะดีกว่าของคนอื่นที่มีในตลาดใช่ไหม - การวัดผลลัพธ์ในแง่ของ Business มีเป้าหมายและมีตัวชี้วัด เริ่มจากการตั้ง Target เช่น การมีระบบนี้ขึ้นมา จากเดิมใช้ 58 นาที เหลือ 25 นาที จากเดิมใช้กระดาษ 32 แผ่น เหลือ 0 แผ่น
เมื่อระบบขึ้นไปแล้ว ก็มาลองดูว่า Actual ที่เราทำได้ สามารถทำได้อย่างที่ตั้งใจไว้กับที่ตั้งเป้าหมายไว้หรือไม่ - Implementation Plan (หรือ Project Plan แบบ High Level) โดยแบ่งการทำงานเป็นรอบสั้นๆ ที่มีระยะรอบเท่ากัน ที่มี Objective, Goal, Owner (ซึ่งแผนพวกนี้ก็สามารถ Adjust ได้อีกที)
- รูปถ่ายการลงหน้างาน
D — Doing
ผลลัพธ์จากการพัฒนาระบบงาน
- UX/UI หรือ Prototype Design
- Goal ที่ชัดเจน และ Requirement ของแต่ละรอบการทำงาน
C — Checking
ผลลัพธ์จากใช้งานจริงและตรวจสอบสม่ำเสมอ
- เชิงคุณภาพ ได้จากการลงหน้างาน การ Demo งานในแต่ละรอบ
- เชิงปริมาณ ก็อาจจะได้จากการติด Tracking Tools ต่างๆ เช่น Google Analytics
- เอาผลลัพธ์มา Compare กับ Target ที่สามารถวัดผลได้ ที่เราตั้งไว้ ว่า ผ่านหรือไม่ผ่าน
A — Adjusting
ผลลัพธ์จากการปรับปรุง
- Software ได้รับการปรับปรุง ปรับแก้ตาม Feedback (และมีการใช้ Control Version)
- ผลการ Feedback มีการ Update Status ตามจริงในบอร์ดการทำงานที่ใช้ร่วมกัน
Scrum
- ถูกทำมาจาก Paper หนึ่งชื่อ The new, new product development game + ไลน์การผลิตรถยนต์ของโตโยต้า
- ทุกอย่างเป็นเรื่องของจัดการเวลา (timebox)
- ถูกคิดมาจาก Iterative Development and Incremental Development
- เน้นการส่งมอบ business value อย่างต่อเนื่อง
- Iterative Development ที่ยังไม่รู้ใครเป็นคนคิด แบ่งช่วงการทำงานออกเป็น Inception — Elaboration — Construction — Transition ทำให้เห็นว่า แต่ละช่วง ใครต้องเข้ามามีส่วนร่วมบ้าง ทุกคนต่างเข้ามามีบทบาทในแต่ละช่วงและอยู่ตลอด แค่น้ำหนักมากน้อยไม่เท่ากัน
- 1 วงรอบของการส่งมอบงานเรียกว่า Iteration (หรือ Sprint) ที่ตอนนี้เรากำหนดกันไว้ว่ามีความยาว 10 วัน
- Implementation ไม่ใช่แค่การเขียน Code อย่างเดียว แต่เหมารวมถึงการติดตั้งด้วย เช่น เอาไปลงเครื่อง POS จากนั้นก็ต้องทดสอบและวัดผล ซึ่งทั้งหมดทั้งมวลนี้ต้องเสร็จใน 1 รอบการทำงาน ที่แปลว่า 10 วัน!
จาก Needs สู่ Requirements
- Needs (ที่อยากได้) อาจจะมาจากปัญหาหน้างาน และมองเห็นโอกาสที่จะทำให้มันดีขึ้น
- เรื่องที่เอามาเสริม เพื่อให้มีรายละเอียด คือ Value Proposition Design (จริงๆ ก็มีหลายตัว แต่เลือกตัวนี้มาใช้ก่อน เพราะน่าจะเหมาะกับบริบทของเราตอนนี้)
- Problem สู่ Opportunities สู่ Features สู่ Requirements และสู่ Solutions และเก็บเข้า Backlog หรือคิวงาน (เช่น Azure Board หรือ Jira)
ความแตกต่างของ Waterfall และ Agile
- Waterfall Model สังเกตว่าเรามัก Focus ที่ Activities เช่น งานถึงไหนแล้ว
- Agile เราจะโฟกัสว่า สามารถ Deliver ออกไปตาม Quality ได้ใน ณ หนึ่งช่วงเวลาแล้วหรือยัง
โดยเริ่มต้นที่ ทำไปแล้ว Business Goal คืออะไร ตัวชี้วัด (Measurement) เป็นอย่างไร กลุ่มลูกค้าของเราที่มีหลากหลาย ก็ต้องจัดตัวแทนขึ้นมา เรียกว่า Persona (สร้างบุคลิกลักษณะของกลุ่มเป้าหมาย) จากนั้นดูว่า User Experience (ประสบการณ์ของผู้ใช้งาน) เป็นอย่างไร
ยกตัวอย่าง PDCA การลงพื้นที่ เจอปัญหาแล้วก็ปรับ ในระยะเวลาการทำงาน 5 วัน
Value (คุณค่า) Proposition (การเสนอ) Design (ออกแบบ)
ตั้งโจทย์: ย้อนกลับไป 1 เดือนที่ผ่านมา นอกจากของกิน เราซื้ออะไรให้ตัวเองบ้าง ทำไมถึงซื้อ อะไรคือ Value Proposition ของสินค้านั้นสำหรับคุณ
ยกตัวอย่างคำตอบ เช่น
- “เม้าส์” เพราะตัวเก่ามีปัญหา ใช้งานไม่สะดวก ทำงานล่าช้า คลิกยาก ก็เลยไปซื้อตัวใหม่ ลื่นปรื๊ดๆ ทำให้ทำงานได้เร็วขึ้น
- “เทียนไฟฟ้าไหว้เจ้า” ใช้แทนของเดิมที่เป็นสายไฟฟ้า แล้วมีความเสี่ยง พอซื้อก็เพิ่มความปลอดภัยให้ในบ้าน
- “คีย์บอร์ด” เพราะของเก่าเจ๊ง ที่ซื้อเพราะความอยาก (กิเลส) ล้วนๆ มีเสียง มีไฟ เปลี่ยนแป้นได้
- “กระเป๋า” อยากได้มานานแล้ว แต่ก็อดทนไม่ซื้อมาหลายรอบแล้ว พอไปต่างประเทศ มันถูกกว่า รู้สึกว่า ของมันต้องมี ถือแล้วดูสวย ดูเด่น
- “รองเท้า skechers” พอดีว่า WFH นานจนรองเท้าเก่ามันพัง ซื้อแล้วก็ซื้อเผื่อวิ่งด้วย เผื่อจะไปออกกำลังกาย จริงๆ อยากได้อีกยี่ห้อ แต่ไม่มี Size เลยมาได้ยี่ห้อนี้ เลือกสีสุภาพหน่อย ราคาไม่สน เพราะเกี่ยวกับเรื่องเข่าและสุขภาพ
วงการ PDCA ก็ใช้กันมาเยอะ โรงงานก็ใช้ ทำจนขึ้นใจ พอมี Startup เกิดขึ้น คุณ Eric Ries ก็ไปดูงานญี่ปุ่นอีก แล้วก็มา Adapt เป็น Build — Measure — Learn ซึ่งทั้งหมดทั้งมวล ไอเดียมีแค่ “ทำของออกมาเร็วๆ แล้วไปทดสอบตลาด”
เพื่อให้มีส่วนร่วมในการเรียน อ.นิรันดร์ ก็มี Slido ให้ร่วมสนุก ผ่านการตอบคำถามผ่าน Poll มีคะแนน และมีรางวัลเป็นหนังสือมาหลอกล่อ ซึ่งในนี้จะจดเฉลยไปเลยแล้วกัน
- Product ที่ทำกันออกมา 72% พบว่า Fail
- ตามสถิติ อัตราการรอดของ Startup อยู่ที่ 10% และก็คงที่แบบนี้มาหลายปีแล้ว ในเมืองไทยสถานการณ์แตกต่าง ทาง DEPA บอกว่ามีแค่ 0.5 ใน 10 เท่านั้นที่อยู่รอด
- มีเหตุผลมากมายที่ทำให้ Startup ไปไม่รอด แต่เหตุผลสำคัญที่สุด ณ ตอนนี้ คือ “ขาดเงินทุน” แต่เมื่อหกปีที่แล้ว “ทำสิ่งที่ตลาดไม่ต้องการ” เป็นอันดับหนึ่ง (แต่ก็ไม่เคยตก Top 3) เนื่องด้วยเศรษฐกิจโลกมีปัญหา เพราะฉะนั้นเงินลงทุนก็ลดลง (ผล Survey ของ CBINSIGHTS)
ไม่ใช่แค่ Startup มีปัญหา แต่บริษัทใหญ่ก็มีปัญหาเหมือนกัน ยกตัวอย่างเช่น จากลูกเจี๊ยบ เติบโตกลายเป็นไก่งวง ความมั่นใจเต็มเปี่ยม แต่วันดีคืนดี กราฟก็พุ่งลง เพราะโดนจับไปอบในวันคริสต์มาส — สิ่งนี้เรียกว่า Disruption
ก็เลยต้องพยายามจำกัด Risk ด้วยการหาสิ่งใหม่มาทดแทน และของเก่าก็ต้องตายไป เช่น Blackberry ก็เคยเป็นไก่งวง ที่มี Confidence เปี่ยมล้น แต่ตอนนี้ Market Cap เหลือเพียง 72B THB (แนะนำหนังสือ Losing the Signal)
ในขณะที่ Apple กราฟพุ่งขึ้นเรื่อยๆ ปัจจุบัน Market Cap อยู่ที่ 84 ล้านล้านบาท - หุ้นไทย ที่มีมูลค่าตลาดใหญ่ ณ วันที่ 15 ก.พ. คือ Delta → AOT → PTT
(พักช่วงเล่นเกม เข้าเรื่องสาระการเรียนก่อน)
Value Proposition Design Canvas (VPC)
กว่าจะออกมาเป็นกระดาษที่ดูง่ายๆ แบบนี้ ได้ผ่านการ Test (UX/UI) มาแล้วกับคนทั่วโลก
เกิดหลัง Business Model Canvas ประมาณสองสามปี
- เราจะคิดแค่ Customer Segment เดียว อย่าคิดหลาย Segment ไม่งั้นมันตีกัน
- แค่อันเดียวก็มีความซับซ้อนแล้ว
- ด้านขวาสุดคือ Customer Job(s) to be done เค้าต้องทำอะไรให้สำเร็จ มี checklist อะไรบ้าง
- Pains เค้ามีจุดเจ็บปวดอะไร
- Gains สิ่งที่ลูกค้าอยากเห็น อยากได้ ถ้าได้แล้วประทับใจ ได้แล้วมันเจ๋ง มีแล้วช่วยอะไร
- รักออกแบบไม่ได้ เราก็ออกแบบลูกค้าไม่ได้ ต้องไปสังเกต ไปดูพฤติกรรม ต้องไปพูดคุย
- พอเราเข้าใจลูกค้า ก็จะเอามาออกแบบ Product และ Service (ที่เปรียบเสมือนของขวัญไปมอบให้กับลูกค้า) ซึ่งมี Feature อะไร
- ที่จะช่วยลดจุดเจ็บปวด (เหมือนกินยา หรือวิตามิน)
- หรือ ช่วยให้ลูกค้ามีความสุขมากขึ้น (อารมณ์ดี กราฟพุ่งขึ้น)
- ถ้าใครมีความสามารถในการวาดรูป ก็วาดลงไป แต่ถ้าไม่สามารถ ก็เขียนเป็นตัวอักษรได้
ไอเดียของ Value Proposition คือ “Put yourself into customers’ shoes.”
They don’t care about products, but they care about the value you offer them. ลูกค้าไม่สนใจในตัวสินค้า แต่ลูกค้าสนใจมากกว่าว่าเราเสนอ “คุณค่า” อะไรให้
กลับมาจากพักกลางวัน เริ่มต้นด้วยคำถามเพื่อสร้างความตื่นตัวก่อน ข้อ 5.-7. ซึ่งเป็นคำถามเกี่ยวกับความรู้ของบริษัท เช่น มีกิจการอยู่ใน 17 ประเทศ ยังไม่มีกิจการในฝรั่งเศส และ Bon Chon ไม่ใช่ของในเครือ
คุณค่ามาจากไหนได้บ้าง?
- Price ราคาถูก แต่ไม่ใช่อยู่ดีๆ ก็ลดราคาเลย แต่มีการหั่นอะไรบางอย่างออก เช่น AirAsia ไม่มีอาหาร จะโหลดกระเป๋าต้องจ่ายเงิน
- Design เช่น louis vuitton christopher backpack ที่ราคาเป็นแสน
- Performance เช่น Mac เปลี่ยนชิปเป็นนู่นนี่ ความเร็วขึ้นกี่เท่าเทียบกับรุ่นก่อน
- Newness ความแปลกใหม่ Bose Frames เป็นแว่นตาที่มีลำโพงอยู่ข้างๆ น่าเสียดายที่ขายไม่ค่อยดี
- Brand/Status ช่วยบ่งบอกสถานะทางสังคม เช่น นาฬิกา Rolex และอื่นๆ ที่บ่งบอกนิสัยรวย รสนิยมดี อะไรก็ว่าไป สินค้าบางสินค้า ไม่ได้มีแค่ Value เดียว บางคนก็ซื้อไว้เพื่อเก็งกำไร (แต่ก็ไม่เห็นจะขายซักที)
- Customization ดัดแปลงให้เหมาะกับแต่ละบุคคล อะไรที่เป็นหนึ่งเดียวในโลก เช่น Nike by you
- Accessibility/Democratization การมีอยู่ของเรา ทำให้อำนาจที่เคยรวมศูนย์กระจายสู่ปวงชน เช่น amazon web services (cloud) ที่มาแทนห้อง Server ขนาดใหญ่ บริษัทใหญ่อาจไม่รู้สึก แต่บริษัทเล็กๆ อย่าง Startup/SME ก็สามารถเข้าถึง Server ที่ดี พอกับบริษัทใหญ่
- Cost Reduction ช่วยลดต้นทุน เช่น Salesforce ที่เป็นระบบ ERP รูปแบบหนึ่ง แทนที่จะลงไปกับ PeopleSoft, Peopleware ก็จ่ายเป็น subscription แทน เห็นต้นทุนในแต่ละเดือน ว่ามี Fix Fee ต่อเดือนเท่าไหร่ (ทำยังไงให้มีกำไร และต้นทุนต่ำ)
- Emotional State อารมณ์ เช่น Joox, Spotify ปรับ playlist ตามอารมณ์
และอื่นๆ
ตั้งโจทย์: ฝึกสมองเพื่อให้ไม่ง่วง ทำไมลูกค้าต้องซื้อของจากเรา ลองนึกถึงลูกค้าซักคน เขาขายของอะไรให้เขา หรือเรา provide service อะไรให้เขา อะไรคือ Value ที่เรามอบให้กับลูกค้า
ตัวอย่างคลิป คนที่อินกับสิ่งที่ตัวเองทำมาก แต่อธิบายให้คนอื่นฟังไม่ได้ว่าเค้ากำลังทำอะไร (พูดไม่รู้เรื่องนั่นเอง)
กลับมาที่เครื่องมือ Canvas
Job(s) to be done
คือ งานที่ต้องทำให้สำเร็จ ไม่ว่าจะเป็นเรื่องงานหรือชีวิตส่วนตัว เช่น จ้างเม้าส์มาเพื่อทำงานให้คล่องขึ้น จ้างน้ำมาเพื่อแก้กระหาย จ้างรถยนต์มาเพื่อเดินทางสะดวก มีแอร์ ปลอดภัย ในช่วงชีวิตคนหนึ่ง ตั้งแต่ตื่นมามี Job(s) to be done มากมายหลากหลาย อาจจะเป็นงานที่ต้องการทำให้สำเร็จ หรือเป็นปัญหาที่อยากแก้ หรือความต้องการที่ต้องการได้รับการตอบสนอง ซึ่งจะแตกต่างกันไปในแต่ละบริบท
- People don’t want to buy a quarter-inch drill, they want a quarter-inch hole. — Theodore Levitt คือเค้าไม่ได้ซื้อสว่านเพราะอยากได้สว่าน แต่ต้องการเจาะรู เพื่อทำอะไรบางอย่าง เช่น แขวนรูป คู่แข่งก็อาจจะเป็น ตะปู/ค้อน เทปกาว, กาว, 3M
- If I had asked people what they wanted, they would have said faster horses.” — Henry Ford (แต่แท้จริงแล้ว ประโยคนี้คุณฟอร์ด ไม่ได้พูดจริง อ้าว แล้วใครพูด?)
- จินตนาการว่าเรากำลังจะไป Business Trip สิ่งที่แพ็คมีสามอย่างคือ
1. กางเกงใน — เพื่อให้รู้สึกสดชื่น สุขอนามัย ไม่เน่า — เป็นแบบ Functional Job to be done เป็นอะไรที่ตอบสนองง่าย จับต้องได้
2. นาฬิกา Rolex — เพื่อดูเวลา (Functional) และใส่อวด เพื่อดูดีในสายตาคนอื่น — เป็น Social Job to be done
3. Bose ลำโพงบลูทูธ — เพื่อความบันเทิง Relax ผ่อนคลาย ตอบเรื่องอารมณ์ความรู้สึก — เป็น Emotional Job to be done - ถ้าเราสังเกต Functional จะราคาไม่แพง แต่ถ้าเล่นเรื่อง Social, Emotion ปุ๊บ ราคาก็พุ่ง (Add Value)
- Job(s) Last, Product Don’t
JTBD = ฟังเพลง → Solution = เทปคาสเสต สู่ Music Steaming
JTBD = เช็ดกระจก → Solution = ไม้เช็ดกระจก สู่ กระจกที่ทำความสะอาดตัวเองได้
JTBD = ค้นหาข้อมูล → Solution = ไปห้องสมุด สู่ Google / ChatGPT
JTBD = โอนเงิน → Solution = ไปธนาคาร สู่ Mobile Application
JTBD = ซื้อของเข้าบ้าน → Solution = ไป Supermarket สู่ Mobile Application - Job(s) ยังคงอยู่ตลอดไป แต่ Product เปลี่ยนแปลงไปตามกาลเวลา
- ถ้าคุณเข้าใจ JTBD ของลูกค้า เราก็จะเข้าใจการพัฒนา Product ของเรามากขึ้น
- ยกตัวอย่าง การเพิ่มยอดขาย Milkshake ของ McDonald’s ซึ่งก่อนจะเฉลย ก็ให้ลองแชร์ไอเดียกันก่อนว่า ถ้าเป็นเรา ต้องการเพิ่มยอดขาย จะทำอะไร เช่น ดู Target, ราคา, Topping, Promotion, เพิ่มรสชาติ, จ้าง Blackpink เป็นต้น
- การมองหาคู่แข่ง ต้องมองข้ามไปยังอุตสาหกรรมอื่นด้วย ไม่ใช่แค่ Product แบบเดียวกัน เช่น MilkShake ถ้า JTBD คือ ให้อิ่มท้อง เป็นเพื่อนร่วมทางในยามเช้า ระหว่างขับรถไปทำงาน คู่แข่งคือ กล้วย โดนัท เบเกิล หรือ ช็อกโกแลตบาร์
- ส่วนตอนเย็น กลุ่มลูกค้าของ MilkShake กลับเปลี่ยนไป เป็นพ่อและลูก เพราะพ่ออยากพาลูกมาปลอบใจที่ตลอดสัปดาห์ Say No ตลอด สร้างความสัมพันธ์อันดี ก็ปรับขนาดให้เล็กลง เติมสีสันให้น่าสนใจ พ่อจะได้ไม่รู้สึกผิดมากที่ให้ลูกกินขนม (ถ้ายังจำกันได้ จะมีพวกชุดเด็ก Happy Meal ที่แถมของเล่น)
- แนะนำหนังสือ Competing Against Luck: The Story of Innovation and Customer Choice
Customer Pain
ปัญหาหรือประสบการณ์ที่ไม่ดี ที่เกิดขึ้นก่อน ระหว่าง หรือหลัง JTBD เป็นอุปสรรคที่จะทำให้ลูกค้าไม่สามารถทำ Job หนึ่งได้สำเร็จ เช่น Grab ที่มาช่วยเรื่องการเรียก Taxi
Customer Gain
อะไรเป็นสิ่งที่เค้าจำเป็นต้องได้ หรือได้มากไปกว่านั้น ประโยชน์ที่ลูกค้าคาดหวังจากการใช้สินค้า อะไรคือผลสำเร็จของ JTBD อาจจะออกมาในรูปแบบของ Functional, Emotional, Social หรืออาจจะช่วยลดต้นทุนอะไรบางอย่าง
โจทย์: อะไรคือ JTBD, Pains, Gains ของนักธุรกิจที่ต้องเดินทางไปพักยังโรงแรมต่างจังหวัด
- คิดไปก่อนว่ามันจะมีแง่มุมอะไรบ้าง ก่อนที่จะลงไปสัมภาษณ์ ต้องมีข้อมูลในมือก่อน
ธุรกิจยุคใหม่หลายที่จะเป็น B2B2C คือเข้าใจ B ที่เป็นคนจ่ายเงิน และต้องไปเข้าใจ C คือลูกค้าตัวจริงด้วย เช่น เราทำปิโตรเคมี มีบริษัทหนึ่งทำน้ำปลา ก็มาจ้างเราทำ packaging ขวดน้ำปลา ก็ทำตามที่บอกไป แต่ยอดขายเค้าไม่ดีขึ้น ยอดที่สั่งเราก็น้อยลงด้วย ก็เลยต้องไปลงพื้นที่ เพื่อทำความเข้าใจว่าคนรุ่นใหม่ต้องการขวดแบบไหน มาปรับปรุง แล้วก็ปรับรูปแบบขวด แล้วยอดขายน้ำปลาก็เพิ่มขึ้น
— Value Map —
Product & Service
สินค้า/บริการ จับต้องได้ หรือ จับต้องไม่ได้ก็ได้ เช่น บริการหลังการขาย หรือเป็น Digital Product เช่น Application, Software หรือเป็นด้านการเงินเช่น Credit card, Insurance
Pain Relievers
บรรเทาจุดเจ็บปวดได้อย่างไร อาจจะเกิดขึ้นก่อน ระหว่าง หรือหลัง JTBD ก็ได้
Gain Creators
Gain คือสิ่งที่เค้าคาดหวัง หรืออะไรที่เกินคาดหมาย (wow element)
ยกตัวอย่างโรงแรมแห่งหนึ่ง สาขาแรกอยู่ที่ Amsterdam ใช้หลัก Blue ocean คือ มอบสิ่งใหม่ให้กับลูกค้า ที่ไม่เคยมีมาก่อน ขโมยสิ่งที่ดีของแต่ละระดับ Star มารวมกัน เช่น ราคากลางๆ โลเคชั่นดีมากใจกลางเมืองเดินทางสะดวก ห้องเล็กก็จริงแต่ทุกสิ่งที่อยู่ในห้องเป็นสิ่งจำเป็นและ High Quality ทั้งหมด
- ก็ออกแบบโรงแรมแบบ สำหรับนักธุรกิจที่เดินทางไปที่นั่นที่นี่เรื่อยๆ (นักท่องเที่ยวก็มาพักได้ ไม่ได้ว่าอะไร)
- Pain Relievers คือ ให้ห้องนอนเงียบ เลือกหมอนได้ มีระบบ Auto check- in ที่เร็ว (kiosk เหมือนสนามบิน) ไวไฟห้ามหลุดห้ามช้า
- Gain Creators คือ ดูดี ราคารับได้ เติมแต่งโรงแรมด้วยงานศิลปะ (เพราะคนเดินทาง คืออยากได้ inspiration) อยู่ใจกลางเมืองเพื่อให้เดินทางสะดวก
- สิ่งที่ตัดออกก็คือ ไม่มีสระว่ายน้ำ ไม่มียิม ไม่มีร้านอาหาร (เพราะอยู่ใจกลางเมือง ก็ไปหากินร้านอื่น)
- มีคนดูแลทั้งโรงแรมอยู่คนเดียว เรียกว่า Ambassador (เพราะที่เหลือใช้ระบบ Auto หมดแล้ว) ไม่มีคนต้อนรับหน้าโรงแรม ไม่มีคนยกของ
- เวลาทำอะไรก็ตาม เราเลี่ยงไม่ได้กับการเทียบกับคู่แข่ง จะมี Tools หนึ่งที่ชื่อว่า strategy canvas
เมื่อเราได้ Customer Profile → Validate กับลูกค้า → Build Design Product/Service ที่ไปตอบ Pain หรือ Gain ของเขาได้
ไม่ต้องตอบทุก Pain หรือ Gain เพราะเราไม่สามารถตอบทุกอย่างได้
ของมัน evolve ทุกวัน ทำแล้วก็ทำไปเรื่อยๆ ไม่มีวันจบ เพราะถ้ามันจบ เราก็จะไม่มีงานทำ
โจทย์: ลองคิดตัวอย่างจากลูกค้าของตัวเอง
สร้าง Customer Profile
- เริ่มที่ Product/Business Ideas
- กำหนด Customer Segment ใครคือลูกค้าของเรา
- Brainstorming: Customer JTBD
Vote ว่าอะไรคือ JTBD
เลือก Top 5 แล้ว Brainstorm ว่า Pain อะไรที่เกี่ยวข้อง Gain อะไรที่เกี่ยวข้อง
รีวิวว่ามี Gain หรือ Pain อะไรที่ตกหล่นไปหรือเปล่า
ข้อควรระวังในการออกแบบ Customers’ Profile
- คิดถึง Value Proposition ของตัวเองมากเกินไป ให้ลืมไปก่อนว่า Products/Services คืออะไร
- คิดไตร่ตรองมากไป ทำให้ JTBD, Pain, Gain ออกมาน้อย พยายามใช้จิตใต้สำนึก
- เน้นไปที่ Functional Job มากเกินไป
- ปะปน JTBD (verb) กับผลลัพธ์ เช่น แปรงฟัน vs ฟันสะอาด
- เขียน Pain, Gain คลุมเครือ ควรบอกให้ได้ว่า Success ของลูกค้าคืออะไร หากระบุเป็นตัวเลขได้ให้ระบุลงไป
- ปะปน Customers หลากหลาย Segment ไว้ใน Customer Profile เดียว โดยเฉพาะ B2B
ประโยชน์ของการใช้ Canvas คือ
เข้าใจกันและกันมากขึ้น (Team Alignment) หลังจากเราตบตีกันเสร็จเรียบร้อย ก็ไปทำความเข้าใจให้ตรงกันกับลูกค้า ทำให้เราเห็นภาพ (Visualization) ที่ตรงกัน
การทำ Value Map
- Products/Services ของเราคืออะไร
- Map out pain relievers and gain creators
- ไม่จำเป็นต้อง map Pain และ Gain ได้ 100% เลือกสิ่งที่จำเป็นก็พอ
Feature ที่เราทำมา มัน Fit หรือมันไม่ Fit
ถ้ายังไม่มีของ ก็ไปทำ Customer Profile ก่อน ไม่ต้องรีบ
แต่ถ้าเรามี Feature แล้วก็ลอง Map ดู ว่า Feature ที่เราคิด กับ Pain ที่ลูกค้ามีมันตรงกันไหม
ข้อควรระวังในการออกแบบ
- List products/services ที่ตรงกับ customer segment เท่านั้น อย่าเอามาปน
- products/services คือแค่ชื่อบอก อย่าไปสับสนกับ การลด Pain และเพิ่ม Gain
- Value map มี connection กับ customers’ pains & gains ถ้าไม่ตรงอะไรเลย ควรต้องสงสัยได้แล้วว่า เราทำ Feature นี้ไปทำไม
- ไม่จำเป็นต้อง map ทุก pains และ gains
การอธิบายสิ่งที่เราทำเป็นภาษามนุษย์ให้คนอื่นฟังได้ใน 1 กระดาษ
ช่วยให้เราอธิบายภาพได้ง่ายขึ้น และเสร็จได้ใน 1 ประโยค
6 เทคนิคในการหา Customer Insight
- Journalist: Interview หา Facts ไม่ใช่ Opinion หาสิ่งที่เค้าทำ หาประสบการณ์ของเค้า ไล่ถามหาจุดเจ็บปวดไปเรื่อยๆ ถามว่าเค้าทำอะไร มีปัญหาอะไรไหม เป็นวิธีที่ถูกและเร็ว แต่หลายๆ ครั้ง สิ่งที่ลูกค้าพูด อาจจะไม่ใช่สิ่งที่ทำจริงๆ Magic Number คือ 10–20 คน จะเริ่มเห็น Pattern อะไรบางอย่าง
- Anthropologist ไปนั่งสังเกตการณ์ ไป Observe, Shadow (สิงร่างตอนที่เค้าทำงาน) ก็จะได้เห็นของจริง
- Impersonator ปลอมตัวเป็นลูกค้า บทบาทสมมติ เพื่อจะได้เข้าใจลูกค้าอย่างลึกซึ้ง โดยที่คนหน้างานไม่รู้ว่าเราเป็นใคร จะได้ประสบการณ์จริง (first-hand) แต่ก็ยากที่จะได้ประสบการณ์ทุกอย่างที่ลูกค้าประสบ
- Data detective จะใช้ระบบอะไรก็แล้วแต่ แต่ข้อมูลอาจจะไม่ได้ตรงกับสิ่งที่ต้องการและเป็นข้อมูลในอดีต
- Co-Create ชวนลูกค้ามาร่วม Develop อะไรด้วยกันสักอย่าง ต้องใช้คนสนิท แต่ก็เป็นแค่ตัวแทนส่วนหนึ่งของกลุ่มลูกค้าเท่านั้น
- Scientist ตั้งสมมติฐาน แล้วใส่กระบวนการทดลองลงไปเหมือนนักวิทยาศาสตร์
วันที่สองเริ่มต้นด้วยการ Recap เรื่องราวของเมื่อวานที่ได้เรียนรู้ไป
และเปิดคลิปวิดีโอกันอีกหนึ่งคลิป
- ตัวอย่างของ Cross-functional team จากคลิปนี้ นอกจาก Project Lead แล้วก็มี Technicial, Marketing, นักจิตวิทยา, นักเรียนแพทย์ที่ดรอปเรียนแล้วมาอยู่ในโกดัง
- แต่ละกลุ่มลงพื้นที่ไปสังเกตการณ์ สัมภาษณ์ เพื่อเอามาทำ Prototype กระดาษ หรือโครงร่างก่อน แล้วเอามารีวิว (present) ร่วมกัน
- Post-it เล็กในคลิป มีสองสี ประยุกต์มาจากหนังสือ six thinking hats ถ้ารู้สึกว่าตรงนี้ไม่ดี ให้แปะ post-it สีเข้ม แต่ต้องมีไอเดียที่ดีกว่า คือ post-it สีอื่น แปะลงไปด้วย
- One conversation at a time
- Stay focused on a topic
- แต่ละกลุ่มทำ Prototype จริงออกมา ช่วยกัน Comment แล้วรวมร่างเป็นหนึ่งเดียว
- แล้วก็เอาไปทดลองใช้จริง ที่สถานที่จริง เก็บ Feedback จริง
- แนะนำ ตอน kick off project แล้วตั้งแผนแรก ให้เจอกันตัวเป็นๆ ในห้องประชุมหรือโกดัง สนุกกว่าเยอะ
เรื่องราวของ UX
- Process การทำงานของ UX ก็เปลี่ยนไปตามแต่ละที่ ตาม Industry
- UX คือ ประสบการณ์ที่ผู้ใช้ได้รับ เมื่อ Interact กับสิ่งใดสิ่งหนึ่ง
- บนโลกใบนี้ มีวัตถุสองแบบคือ
Physical Object มองเห็นแล้วรู้ว่ามันน่าจะทำอะไร เช่น เก้าอี้ และ
Digital Object จริงๆ แล้วพื้นฐานมันเกิดมาจาก 0, 1 แล้วโดนเปลี่ยนมาเป็น High level ขึ้นเรื่อยๆ เช่น ผ่าน command line, เม้าส์, ฯลฯ
มีการพัฒนาขึ้นมาเรื่อยๆ จนเรียกว่า UI (User Interface) เป็นตัวกลางให้เราใช้ในการสั่งการและสื่อสารกับคอมพิวเตอร์ มีทั้งหน้าจอ (Graphical) การพูดคุยด้วย (Conversational) การใช้ท่าทาง (Gestural)
ประโยชน์ของ UX คือ?
- เวลาไปร้านซูชิ มีช้อนส้อมให้เลือก กับตะเกียบ (หรือมือ) เราเลือกใช้อะไร?
เวลาที่มนุษย์ตัดสินใจเลือกใช้อะไร เราเลือกจากบางสิ่งบางอย่าง ที่เราคาดหวังว่าจะได้ประสบการณ์จากการเลือกสิ่งนั้น
- การโอนเงินที่ สาขาธนาคาร vs Mobile Banking ถ้าจำนวนไม่มาก คนส่วนใหญ่ก็จะใช้ Mobile Banking
แต่พอเป็นเปิดบัญชีใหม่ คนส่วนใหญ่กลับไปที่สาขาธนาคารมากกว่า
- Competition ฝั่ง UX/UI ตอนนี้ที่ค่อนข้างเห็นชัดคือ Food Delivery, Banking
Process ของ UX/UI
1. ทำการเก็บ Requirement เราทำอะไร
โดยพื้นฐานเราจะต้องการ 5 อย่างคือ
- Business Goals, User goals, or what we want to achieve
- Overview of the system, modules, and features
- Flow charts เช่น process flow, business flow, user flow, service blueprint คืออันไหนก็ได้ ที่อธิบายรายละเอียด และสถานการณ์ได้ดี เริ่มจากการขึง Flow (As-is) ว่า Process ปกติเป็นยังไง ภาพรวมของการทำงานทั้งหมด
- User journey คือ Roles หนึ่ง (เป็นใคร) มี Action อะไรที่ต้องทำ ใช้ Tools อะไร เพื่อทำให้สำเร็จ ก็เริ่มจาก As-is ก่อนเช่นกัน
- ถ้า Persona เปลี่ยน บางที User Journey ก็จะเปลี่ยนไป ยกตัวอย่างเช่น แม่ค้าขายผัก เวลาเราไปลงพื้นที่ เราจะพบว่า แม่ค้าขายผักในตลาดก็มีหลากหลาย อาจจะมีตั้งแต่ทำคนเดียว จนถึงร้านที่มีพนักงานช่วยขาย วิธีการเช็คสต็อกก็จะต่างกัน
2. User Research
ทำการ Research เพื่อเจาะปัญหาว่า
- มี Pain Point อะไรที่ User คนนั้นเจอ Feeling เป็นแบบไหน
- Defenition of Done ของแต่ละ Stage คืออะไร อะไรที่ทำให้เดินทางจากจุด A ไปจุด B ได้
- ความต้องการ ความคาดหวังที่อยากได้
- อะไรคือตัวชี้วัด
3. Design Flow
คิดไอเดีย ดีไซน์ Flow ใหม่ (To-Be) เราใช้เทคโนโลยีอะไรมาช่วย อะไรที่เพิ่มเข้ามา อะไรที่เปลี่ยนไป
ถ้าอิงไปถึง Value Proposition Design Canvas ที่เรียนเมื่อวาน กล่องด้านขวาตรง Pain ก็คือ As-is (ที่อาจจะเอาเรื่อง User Journey ตรงนี้เข้ามาช่วยได้) แล้วคนๆ นั้นเองอยากได้อะไร เพื่อ แก้ไขจุดเจ็บปวด หรือทำให้มีความแฮปปี้มากขึ้น (ที่อยู่กล่องด้านซ้าย)
4. Design Wireframe
จาก Flow ที่ได้รับมา ยังไม่สามารถนำมาทำ Wireframe ได้ จะต้องเพิ่มเติมรายละเอียด ที่เรียกว่า Specification เข้าไป
เช่น หากต้องการเปิดบัญชี จะต้องกรอกข้อมูลอะไรบ้าง อะไรเป็นสิ่งจำเป็น อะไรเป็น optional ถ้าเป็น Text มีความยาวเท่าไหร่ หรือมี Condition อะไรไหมสำหรับ Field นี้
แล้วพอกรอกเสร็จแล้ว Specification ของ Output (ที่เป็น Display) จะแสดงข้อมูลอะไรบ้าง แสดงแบบไหน มีการ Masking ข้อมูลส่วนไหนหรือเปล่า ตัวเลขจะต้องมีทศนิยมกี่ตำแหน่ง เพื่อให้ผู้ใช้กดยืนยัน
Specification คือสิ่งที่ทำงานร่วมกัน ทยอยเก็บกันไป เพื่อเอาไปใช้ในการออกแบบ
ซึ่ง Wireframe เป็นได้ทั้ง ร่างด้วยมือ และขึ้นผ่าน Tools เช่น Figma พอได้โครงร่าง ดราฟที่หนึ่งแล้ว ก็คุยกับ PO ก่อนว่าแบบนี้โอเคไหม ปรับเปลี่ยน จนมันเริ่มนิ่ง แล้วค่อยมาลงรายละเอียดเพิ่มเติม
5. Design User interface and interaction
คือการเปลี่ยนจาก Wireframe ให้สวยขึ้น เป็นภาพจริง ตกแต่งให้เรียบร้อยอย่างที่ควรจะเป็น กดจุดไหนเกิดอะไรขึ้น คิดให้ครบทุกอย่างที่จะเป็นไปได้ ที่จะเกิดขึ้นในระบบนั้น
แต่เราจะรู้ได้ยังไงว่าสิ่งที่เราทำสุดความสามารถแล้วมันดีจริงไหม?
6. Usability Test
เอาระบบเราไปเรียนรู้ Feedback จาก User ตั้งแต่แรก โดยการเอาข้อ 5. มาทำเป็น Prototype ที่มันกดๆ ได้ (แต่ยังไม่ได้ Dev จริง) แล้วไปให้ User ใช้งานจริง
ปกติ User กรอกข้อมูลในกระดาษ ทำไมถึงต้องมากรอกใน App ล่ะ?
ซึ่งผลลัพธ์การ Test ของ UX/UI จะออกมา 3 ค่า คือ
- System Usability Scale (SUS) ระบบนี้ใช้งานยากหรือง่ายเพียงใด คะแนนยิ่งเยอะยิ่งดี ในเชิงวิจัย ควรเกิน 68% ขึ้นไป แต่ถ้าให้ดีต้อง 70–80% ขึ้นไป
- Customer Effort Score (CES) Task นี้มีความยาก/ง่ายเพียงไร ถ้าผ่านคืออยู่ที่ประมาณ 3 กว่าๆ จาก 5
- High — Medium — Low Priority Issue ซึ่งมี Framework ในการคำนวณ ถ้าเราพบปัญหาเป็นร้อย ก็ต้องให้นำ้หนัก ว่าสิ่งไหนต้องแก้ก่อน
— High คือ ติดจนใช้การไม่ได้เลย หาไม่เจอ ต้องแก้
— Medium คือ ติดๆ หน่อย แต่ก็ยังกดจนจบ Flow ได้
— Low คือ อาจจะดูแปลกๆ หน่อย สามารถปรับให้ดีขึ้นในภายหลัง
นอกจากนั้น เราจะได้รับฟังเหตุผลต่างๆ เพิ่มเติมด้วย เป็นจุดแรกที่เราจะได้ Feedback จาก User ซึ่งเอาจริงๆ พอเราเอาลงไป Test เค้าอาจจะบอกว่า ไม่ได้ทำงานแบบนี้เลยก็ได้ (ก็รื้ออออ)
การทำแต่ต้น ค่าใช้จ่ายต่ำ เพราะเราทำไปแค่ Figma เอง แต่ทั้งนี้ก็ขึ้นอยู่กับว่าเราสามารถเข้าถึงตัว User ได้เร็วที่สุดเท่าไหร่ด้วย
แก้ให้เสร็จ แก้ให้ผ่าน ก่อนจะเอาไปส่งให้ Dev
7. Deliver to Development
ทาง UX/UI จะส่งไฟล์ Figma ส่งให้ Dev มีการโยงโฟลว์ และสามารถ Inspect ได้เลยว่า ใช้ Font อะไร สีอะไร
ซึ่งนอกจาก Dev ก็จะมี QA ก็จะมาช่วยกันในส่วนนี้ด้วย
8. Post-Launch Feedback (CSAT, NPS & Analytics)
แม้เราจะได้เจอ User แล้วในตอน Usability Testing แต่ตอนนี้เป็นแค่ระบบจำลองเท่านั้น ยังไม่ได้เขียน Code เลย
พอระบบออกมาใช้จริงแล้วก็ไปเก็บ Feedback ด้วยว่ามันแก้ Pain ได้จริงหรือเปล่า เราได้รับ Data กลับมา เพื่อพัฒนาในรอบการทำงานถัดไป
Customer Feedback — CSAT (Customer Satisfaction), NPS, Interview, etc.
- CSAT มาได้จากการคิดเฉลี่ย หรือจากการคิด Rating
- มีการเก็บทุกๆ สองครั้งต่อปี (หรือแล้วแต่กำหนด)
- เป็นความคิดเห็นจาก User ซึ่งก็อาจจะไม่จริงทั้งหมดก็ได้
Analytics — Google Analytics, Google Firebase Analytics, Google Looker studio, UXCam, etc.
- ข้อมูลที่ได้จาก Action ที่เกิดจาก User จริง แล้วระบบเก็บข้อมูลกลับมาให้เรา
- ซึ่ง GA โดยปกติก็จะ provide ค่า Basic ถ้าเราอยากได้อะไรเพิ่ม ที่ลึกขึ้นก็ Custom Event เข้าไป ถ้ากราฟที่มีมันง่ายไป ก็ Custom กราฟได้เช่นกัน
- สามารถ Track ได้ระดับรายบุคคล (ID) เพื่อดูพฤติกรรมการใช้งานของ User ว่ามีการใช้งานเป็นอย่างไร อะไรที่ผิดไปจากที่เราคาดหรือตั้งสมมติฐาน ก็สามารถเก็บ Feedback เพิ่มเติมได้
- จะได้ข้อมูลการใช้งานจริงเมื่อ Product เปิดตัวไปแล้ว
โดยหลักการ UX/UI จะทำงานใกล้ชิดกับ PO อยู่แล้ว แต่ขึ้นอยู่กับจังหวะไหนใครเป็น Main และใครเป็น Support
ช่วงบ่าย หลังพักเที่ยง
ไม่ได้จดเท่าไหร่แล้ว เพราะว่าโดนเรียกให้ไปเป็นระบบที่ถูกสั่งการด้วยเสียง และมีประชุมวิชาอื่น 555
หลักๆ ก็คือ
- การลองเอาโจทย์จริง มาใส่ใน Value Proposition Canvas ที่เรียนเมื่อวาน
- อธิบายการทำ Software Development ในรูปแบบของ Waterfall และ Agile
- แล้วก็อธิบาย PDCA ว่าอยู่ตรงภาคส่วนไหนของภาพ Agile Software Development ตั้งแต่เอาของเข้า เอาไปพัฒนา ไปเช็ค Feedback และปรับแผนใหม่ แล้วก็วนลูปไป
- จากนั้นก็ต่อที่ Iterative and Incremental Development ว่าแบ่งงานเข้ารอบการทำงานอย่างไร
- พาขึงแผน Release Planning, Milestone, รายละเอียดที่ต้องเตรียม
- การขึง As-is, To-be Flow (ประมาณ A-DAPT)
