จดๆจาก From Chaos to Clarity จูนทีมเทคให้ตรงจุดจนสร้าง Product ได้ตรงใจ

สำหรับวันนี้มาเกือบไม่ทัน 555 Run Tests ทิ้งไว้ แล้วรีบมางานที่ตึก K+ สามย่านครับ หัวข้อที่จดได้มีประมาณนี้

Key Note - From chaos to clarity

สำหรับ Key ของ Session นี้เข้าใจ Role อื่น เพื่อมาปรับการทำงานของตัวเองครับ

📌 อย่างตัว Speaker เค้าเป็นส่วนของ Designer มีปัญหานิดหน่อยในการสื่อสารกับ Dev เลยมีการพูดคุย จูนจนได้ และมี Blog เรื่อง Devๆ ที่ UX Designer ควรรู้: แอปกับ Server คุยกันยังไง และทำไม Designer ต้องรู้เรื่องนี้? (มี 3 ตอนนะ) ลองไปอ่านได้ครับ ไม่จำเป็นต้อง Code ได้ แต่ควรเข้าใจศัพทฺ์เฉพาะของคนที่ต้อง Deal ด้วย เคสนี้สาย Dev เพื่อจะได้คุยไปในทางเดียวกัน
📌 นอกมีเล่าเคสจาก The Money-Making Secrets Behind Hotel Design อันนี้เป็นมุมของฝั่งสถาปนิก เค้าไม่ได้ทำงานในส่วนของเค้าเพียงอย่างเดียวนะ คิดในมุมของ Role อื่น และมีการปรับ Design ย้าย mini bar ของแต่ละห้องมาพื้นที่ส่วนกลางแทน

• เพื่อช่วยลด Cost ในการสร้างในแต่ละห้อง การดูแล การเติมของ
• และสร้างพื้นที่พบปะ และสร้างรายได้จากคนมาใช้งงานพื้นที่ส่วนกลาง

📌 แต่การเข้าใจมุมมองของคนอื่น อันนี้ Speker จะยก paper Many hands make overlooked work: Over-claiming of responsibility increases with group size ทุกคนมี Bias เป็นของตัวเอง

• ตัวเองมีส่วนร่วมกับ Project เท่าไหร่ ผลรวมจะมากกว่า 100
• แต่ถ้ามองในมุมของทีม มันก็เกินอยู่ดี แต่ไม่ Over ไปแบบอันแรก

📌 ดัวนั้นทุก Role ต้องมาจูน ต่อรองความในใจ และเสียงในหัว โดยที่เราต้องไม่เสียจุดยืนใน Role ที่ตัวเองอยู่ด้วย ทั้งในส่วนของ Product (PO) / Desiner (UX/UI) / Engineering (Dev + QA + DevOps)

มีการต่อรอง แบบที่เราเข้าใจอีกฝั่งด้วย ว่าเค้าคิด ยังไง ติดอะไร ถ้าไม่ทำจะเกิดอะไรขึ้น แล้วทีม หรือผู้มีอำนาจรับได้ไหมนะ เช่น ทำได้ต้องเพิ่มเวลา หรือ ตัดบาง Feature ออก จะได้ Focus ตาม MVP แก้ Pain ของ User แล้วค่อยมา improve ต่อ

Panel Discussion

📌 มุมมองของ Dev กับ Product ทำยังถึงจะคิดเผื่อได้ ไม่ทำอะไรแปลกๆออกมา เช่น message ประหลาด แนวๆนี้ โดยเริ่มจาก

• ต้องมี Product mind engineering - คิดในมุมของคนใช้งาน ว่าถ้าต้องกด 10 ตลบ หรือถ้าเจอ Message บอกแบบนี้ เราเอาจะอ๋อ มันเข้าใจไหม ?
• ทำอย่างไรให้มี mindset นี้ - ลองใช้ และกดจริง เจ็บจริง ต๋อมเอ๊ะเริ่มทำงานแล้ว ถ้ารู้ไวเจ็บนิดๆ แต่ปรับตัวได้ไว

📌 กลับกัน ถ้าเรามองในของ Role อื่นๆบ้าง

• จับทุกคนเข้ามาฟัง ทำไปเพื่ออะไร Designer เค้าน่าจะเรียกว่า Share Research Desk ให้ทุก role มาเข้าใจก่อน ว่า user มี pain อะไร นะ แล้ว Share Flow ที่ได้วางได้
• นอกจากนี้บางครั้ง Designer อาจจะมี Over Design ได้ ซึ่งบางเรื่อง ถ้าเรารู้ Flow Business หรือ Technical บางอย่าง อาจจะช่วยให้ Solution มันง่ายขึ้น มันจะเกิดขึ้นตอนที่ Share คุยกันในช่วย Sprint Plan / Sprint Review

เสริมความเข้าใจในงานของแต่ละคน กับ Product นั้นๆ เช่น ลองเข้าไปทำงานของ Role อื่น เช่น rotate dev 》test หรือ support จะได้เอาประสบการณ์ ปัญหา / เข้าใจความลำบาก แล้วมาปรับกัย Product

📌 Speed ของ Dev แต่ละที่ไม่เท่ากัน มี challenge อะไรบ้างในมุมองค์กรใหญ่ แบบ bank

• Legal / Compliance - innovation มี scope แคบกว่า startup ระดับนึง ข้อเสียบาง idea อาจะหลุดไป ทุก business มีข้อจำกัดของตัวเอง เข้าใจ context ของที่นั่นก่อน และเรื่องการตอบสนองกับเหตุการณ์ด้วย ถ้าเราเป็น user รู้สึกอย่างไร หาทางแก้ยังไงให้ Happy ขา Compliance / User
• อีกปัญหานึงที่พบ Product อยากได้แบบนึง Engineering มองว่าอยากได้อีกแบบ อาทิ เช่นDev ไปก่อน Quality ที่หลัง มันจะขัดกับขา Engineering Quality เป็่นสิ่งที่สำคัญ
  - อย่างแรก หาจุดที่ยอมได้ และยอมไม่ได้
  - ต่อรองกับทาง product owner ตรงๆ มีช่วงเวลาหยุดคิด เช่น dev ไปลด technical debt และ ส่วน po ปรับ product ช่วงแล้วมาเจอกันนะ
• ควรมีการออกแบบ goal ให้สอดคล้องกัน พวก OKR / KPI (Collaboration Across Org)
• อันอันเอา Automation เข้ามาช่วยอย่าง Flow ของ DevOps

📌 ถ้าโดนตัด Feature หรือตัดบางอย่าง เรารับมือยังไง

yes, but ....

• ลด flow ไม่จำเป็น แต่ถ้ามันขาดไม่ได้ ต้องชี้แจงความสำคัญไป
• ขอเวลาเพิ่ม แต่ถ้าไม่ได้ - ขอตัดของบางอย่าง เช่น เรื่องความเนียบ (Cosmetic)
• สิ่งที่ตัดไปแล้ว มัน impact อะไร แล้วทิ้งได้นานเท่าไหร่ ก่อนปัญหานี้มันลุกลาม บอก Criteria เช่น Scale ไม่ได้ หรือ แตะอะไรไปแล้วของจุดอื่นจะระเบิดบ้าง

ที่สำคัญ สื้อสาร ต้องชัดเจนใน ทุก Role - ทำเพื่ออะไร priority + impact แล้วต้องการ quality ระดับไหนนะ

📌 ถ้า dev ส่งงาน QA ช้า แต่เวลาเท่าเดิม

• ขึ้นกับการต่อรอง เช่น ตัด Test Case ออก หรือส่งบาง Case ให้ Dev ลองทดสอบก่อนเลย
• รวมถึงเปิดให้ QA แวะเข้ามาดูของก่อนเลย เช่น Demo ให้ดู จะได้เข้าใจตรงกันว่าหน้าตา ตามนี้ Flow แบบนี้นะ ถ้าเอ๊ะอะไรทักได้ก่อน

📌 ทำไม dev ไม่ทำตาม design มองเป็น cosmetic เลยไว้ที่หลังก่อน

• ต่อรองกัน - ต้องมาดู MVP ก่อน ว่าจะเน้น feature เยอะ หรือ เอาเวลาไปเน้น feature หลักอันนึง ให้ดีเลย แบบ meow jo แรกมี feature 3 อัน
• ที่สำคัญ ต่อรองให้จบ ในช่วงแรกๆ และต้องกำหนด Definition Of Done ให้ชัดด้วย
• Recap ให้ดี note ให้ชัด

📌 ถ้า Stakeholder แบบ HiPPOs (Highest paid person in the office) ขอให้ตัด Test ออก ไม่สนใจ Quality ปล่อยให้เป็นงานของ User ทำอย่างไร ?

• ชี้แจง โดยให้เป็นมูลค่าของตัวเงินที่จะเสียไป / Impact ทางธุรกิจ ถ้าจงใจปล่อยของแบบนี้ออกไป
• ลองให้ไปรับ Feedback เอง จาก Social หรือ ตัว user เป็นๆ

📌 Dev แบบรุยเจี่ย รับมือยังไง

• อันนี้เห็นคำถาม ในหัวผม จะได้ปล่อยเสียงในหัวไปไหมหว่า 55555
• ลองบอกให้ทำเอง จะได้เข้าใจปัญหา บางทีสิ่งที่เค้าคิด อาจจะผิด หรือ ถ้าถูกต้องขอคำแนะนำเพิ่มเติมไป
• แต่ถ้าไม่ไหว Leave ดีสุด เสียสุขภาพจิต  แต่ไม่ต้องวางยาแบบน้องลินุกซ์นะผิดกฏหมาย

หลังจากนี้แยกย้ายไปถกกลุ่มย่อยๆ อันนี้ขอไม่ลง Blog และมี Recap ปิดท้าย

💡สร้างทีมให้มี Product Mind Engineering - ช่วยกันเอ๊ะ โดยที่ไม่เสียตัวตน หรือ Goal ของ Role ตัวเอง
💡Overcommunication ดีกว่า Under Communication แล้วไปแผลแตกตอน Test / UAT
💡การตัดสินใจเป็นหน้าที่ของทุกคน ทุกคนควรได้ข้อมูลที่รอบด้าน เพื่อให้เห็นมุมมองที่หลากหลาย แต่ถ้ามันติดจริงๆให้ Product Owner - Final Decision ได้ เพราะทุกฝ่ายมีข้อมูลเท่ากันแล้ว

Reference

• https://luma.com/oy6lur63?tk=NxmH0X&utm_source=ep-4DxYtzrwu8