✍🏼 สิ่งสำคัญที่หายไปจากการเขียนรีไควเม้นท์

รีไควเม้นท์หรือฟีเจอร์ใหม่เป็นเรื่องน่าตื่นเต้นเสมอสำหรับโปรดักท์ เมเนเจอร์ … อาจจะรวมถึงทีมพัฒนาด้วย สิ่งใหม่ ไอเดียใหม่ วิธีการใหม่ และลูกเล่นแบบใหม่ๆที่ถูกเพิ่มเข้าไปในโปรดักท์ของเรา

“ฟีเจอร์นี้ทำงานยังไง ต้องทำอะไรได้บ้าง?” — หัวหน้าทีมพัฒนาตั้งคำถามกับเราในฐานะโปรดักท์ เมเนเจอร์

แน่นอนว่ามันเป็นหน้าที่ที่เราต้องตอบ และเราก็ตอบได้นั่นแหละ 👇🏽

รีไควเม้นท์กับสิ่งที่ควรทำได้

“จากการที่คุยกับลูกค้ามากลุ่มหนึ่ง ผมสรุปได้ว่าเราน่าจะเพิ่มปฏิทินเข้าไปในแอปของเรานะ” — คำตอบมาตรฐาน

รีไควเม้นท์คือปฏิทิน? 📅 แค่นั้นหรือ? ไม่หรอกๆ เราตอบได้ดีกว่านั้นเยอะ

“พอดีลูกค้าค่อนข้างมีปัญหากับการดูตารางเวลาของตัวเองและทีมงานตอนนี้เพราะหน้าจอแอปเราลิสต์แค่อีเว้นท์และมีตติ้งออกมาเป็นตารางยาวๆอย่างเดียวเลย มันยากที่จะดูภาพรวม ผมเลยคิดว่าปฏิทินน่าจะช่วยแก้ปัญหาตรงนี้ได้ดีนะ”

โอเค ฟังดูมีหลักการขึ้นเยอะ

  • เราเล่าถึงเบื้องหลังที่มาของรีไควเม้นท์ — ดี
  • เราเล่าถึงความลำบากที่ผู้ใช้กำลังเผชิญอยู่ — ดี
  • เราชี้ให้เห็นว่าสิ่งที่มีอยู่ในแอปเวอร์ชั่นนี้เป็นแบบไหนและมีปัญหาอะไร — ดี
  • เรานำเสนอแนวทางแก้ไขที่ค่อนข้างสมเหตุสมผล — ดี

แต่มันดีพอแล้วรึยัง?

รีไควเม้นท์กับสิ่งที่อยู่นอกเหนือความต้องการ

คำว่าปฏิทินหมายถึงอะไร? พูดฟังดูเหมือนง่ายแต่รายละเอียดมันเยอะมากจนไม่น่าเชื่อ …​ ลองนึกภาพปฏิทินแบบจีเมล์แล้วจะพอเข้าใจ เรามองเห็นอะไรบ้าง?

  • ป๊อบ-อัพขึ้นมา
  • เลือกมุมมองได้หลายแบบ — รายวันหรือเฉพาะที่มีการลงเวลาไว้
  • สร้างอีเว้นท์หรือมีตติ้งได้จากการคลิ๊กบนวันที่ในปฏิทิน
  • เลือกดูปฏิทินแต่ละรายการได้
  • เดินหน้าถอยหลังวันได้ด้วยการคลิ๊กที่ลูกศร
  • และอะไรอื่นๆอีกเยอะ

ปฏิทินของเราหมายถึงอะไร? สโคปอยู่ที่ไหน? และจุดนี้เองคือสิ่งที่ขาดหายไปกับการเขียนรีไควเม้นท์ของเรา — สิ่งที่เราไม่ต้องการ

ทีมพัฒนาของเราทำได้ทุกอย่าง ไม่ว่ามันจะเป็นรีไควเม้นท์แบบไหน พวกเขามีความสามารถและความทะเยอทะยานพอที่จะทำมันออกมาให้ได้ แต่เรามีหน้าที่รับผิดชอบต่อความพยายามและเวลาที่พวกเขาเสียไปด้วย เราต้องสื่อสารให้ชัดเจนว่าอะไรที่ใช่และอะไรที่ไม่ใช่

ไม่ว่าจะเกิดอะไรขึ้น ไม่ว่ารีไควเม้นท์นี้จะยากหรือง่าย เราต้องลงทุนเวลากับมันทั้งสิ้น และเวลาคือสิ่งที่ทุกคนมีจำกัด ปฏิทินแบบจีเมล์อาจจะต้องใช้เวลาครึ่งปีในการพัฒนา (พูดจริงๆ ไม่ใช่เล่นๆนะ) โปรดักท์ เมเนเจอร์มืออาชีพแบบเราต้องตอบให้ได้ว่านั่นมันเกินความต้องการของเราไปไกลแค่ไหน หรือไม่ อย่างไร

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

การประเมินเวลาผิดพลาดไปไกลหลายปีแสง การออกแบบที่ยากและมากเกินความจำเป็น การลองผิดลองถูกและเกิดการตั้งคำถามเกิดขึ้นในระหว่างการพัฒนา — ตรงนี้คือจุดสำคัญที่ทำงานให้ไม่เสร็จทันตามเวลาที่กำหนด ทำไมหนะหรอ? เพราะเมื่อทีมพัฒนามารู้ภายหลังว่า “นี่ไม่ใช่สิ่งที่ต้องทำ” มีโอกาสสูงที่พวกเขาต้องปรับเปลี่ยนโครงสร้างบางอย่างเพื่อไม่ทำในสิ่งที่ไม่ต้องทำ

ทีมพัฒนาที่ไม่เข้าใจสโคปงานอย่างชัดเจนว่าอะไรต้องทำและอะไรไม่ต้องทำนั้นจะไม่มีโฟกัส และทุกคำถามใหญ่ๆที่เกิดขึ้นระหว่างการทำงานคือสิ่งที่ทำให้พวกเขาไขว้เขว เช่น “เอ๊ะ ตรงนี้จะเอายังไง?” หรือ “อยากเพิ่มตรงนี้เข้าไปด้วยมั้ย?” หรือ “อันนี้มันยากกว่าที่คิดไว้เยอะเลย จะเอาแน่หรอ?” — คำถามพวกนี้ทำให้งานเราไม่เสร็จครับ


ถ้าเกิดคำถามหรือเหตุการณ์เหล่านี้ขึ้นระหว่างการพัฒนาโปรดักท์ (จะเรียกสปริ้นท์หรือโปรเจกต์หรืออะไรก็ตามแต่) เราในฐานะโปรดักท์ เมเนเจอร์ต้องโทษตัวเองก่อนเลยครับ เรามีอำนาจที่จะเลือกได้ว่าจะทำหรือไม่ทำอะไร แต่เราต้องใช้อำนาจนั้นอย่างมีความรับผิดชอบด้วย

“ผมไม่เข้าใจว่าทำไมเข้าสปริ้นท์แล้วงานไม่เสร็จ หรืองานมาเร่งเสร็จเอาสองวันสุดท้าย” — ถ้าเราตั้งคำถามแบบนี้บ่อยๆ … วิธีแก้ไขอันแรกเลยคือมองดูผลงานของตัวเองก่อนครับ เราทำหน้าที่ของเราได้ดีแล้วรึยัง

As a user, I want to … so that … — 👎🏼 โนวววว เขียนแค่นี้ใครๆก็เขียนได้ การกำหนดรีไควเม้นท์ที่ดีมันมีอะไรมากกว่านี้เยอะมาก (มากๆ) และการแค่ทำหน้าที่เขียน User Story ไม่ใช่เรื่องน่าภูมิใจอะไรของโปรดักท์ เมเนเจอร์เลยครับ

เราดีกว่านั้น เราทำได้มากกว่านั้นเยอะ … และเราต้องหาโอกาสทำมันตั้งแต่วันนี้ ทุกคนในทีมหวังพึ่งพาเราอยู่

Leave a Reply

Your email address will not be published. Required fields are marked *