รีไควเม้นท์หรือฟีเจอร์ใหม่เป็นเรื่องน่าตื่นเต้นเสมอสำหรับโปรดักท์ เมเนเจอร์ … อาจจะรวมถึงทีมพัฒนาด้วย สิ่งใหม่ ไอเดียใหม่ วิธีการใหม่ และลูกเล่นแบบใหม่ๆที่ถูกเพิ่มเข้าไปในโปรดักท์ของเรา
“ฟีเจอร์นี้ทำงานยังไง ต้องทำอะไรได้บ้าง?” — หัวหน้าทีมพัฒนาตั้งคำถามกับเราในฐานะโปรดักท์ เมเนเจอร์
แน่นอนว่ามันเป็นหน้าที่ที่เราต้องตอบ และเราก็ตอบได้นั่นแหละ 👇🏽
รีไควเม้นท์กับสิ่งที่ควรทำได้
“จากการที่คุยกับลูกค้ามากลุ่มหนึ่ง ผมสรุปได้ว่าเราน่าจะเพิ่มปฏิทินเข้าไปในแอปของเรานะ” — คำตอบมาตรฐาน
รีไควเม้นท์คือปฏิทิน? 📅 แค่นั้นหรือ? ไม่หรอกๆ เราตอบได้ดีกว่านั้นเยอะ
“พอดีลูกค้าค่อนข้างมีปัญหากับการดูตารางเวลาของตัวเองและทีมงานตอนนี้เพราะหน้าจอแอปเราลิสต์แค่อีเว้นท์และมีตติ้งออกมาเป็นตารางยาวๆอย่างเดียวเลย มันยากที่จะดูภาพรวม ผมเลยคิดว่าปฏิทินน่าจะช่วยแก้ปัญหาตรงนี้ได้ดีนะ”
โอเค ฟังดูมีหลักการขึ้นเยอะ
- เราเล่าถึงเบื้องหลังที่มาของรีไควเม้นท์ — ดี
- เราเล่าถึงความลำบากที่ผู้ใช้กำลังเผชิญอยู่ — ดี
- เราชี้ให้เห็นว่าสิ่งที่มีอยู่ในแอปเวอร์ชั่นนี้เป็นแบบไหนและมีปัญหาอะไร — ดี
- เรานำเสนอแนวทางแก้ไขที่ค่อนข้างสมเหตุสมผล — ดี
แต่มันดีพอแล้วรึยัง?
รีไควเม้นท์กับสิ่งที่อยู่นอกเหนือความต้องการ
คำว่าปฏิทินหมายถึงอะไร? พูดฟังดูเหมือนง่ายแต่รายละเอียดมันเยอะมากจนไม่น่าเชื่อ … ลองนึกภาพปฏิทินแบบจีเมล์แล้วจะพอเข้าใจ เรามองเห็นอะไรบ้าง?
- ป๊อบ-อัพขึ้นมา
- เลือกมุมมองได้หลายแบบ — รายวันหรือเฉพาะที่มีการลงเวลาไว้
- สร้างอีเว้นท์หรือมีตติ้งได้จากการคลิ๊กบนวันที่ในปฏิทิน
- เลือกดูปฏิทินแต่ละรายการได้
- เดินหน้าถอยหลังวันได้ด้วยการคลิ๊กที่ลูกศร
- และอะไรอื่นๆอีกเยอะ
ปฏิทินของเราหมายถึงอะไร? สโคปอยู่ที่ไหน? และจุดนี้เองคือสิ่งที่ขาดหายไปกับการเขียนรีไควเม้นท์ของเรา — สิ่งที่เราไม่ต้องการ
ทีมพัฒนาของเราทำได้ทุกอย่าง ไม่ว่ามันจะเป็นรีไควเม้นท์แบบไหน พวกเขามีความสามารถและความทะเยอทะยานพอที่จะทำมันออกมาให้ได้ แต่เรามีหน้าที่รับผิดชอบต่อความพยายามและเวลาที่พวกเขาเสียไปด้วย เราต้องสื่อสารให้ชัดเจนว่าอะไรที่ใช่และอะไรที่ไม่ใช่
ไม่ว่าจะเกิดอะไรขึ้น ไม่ว่ารีไควเม้นท์นี้จะยากหรือง่าย เราต้องลงทุนเวลากับมันทั้งสิ้น และเวลาคือสิ่งที่ทุกคนมีจำกัด ปฏิทินแบบจีเมล์อาจจะต้องใช้เวลาครึ่งปีในการพัฒนา (พูดจริงๆ ไม่ใช่เล่นๆนะ) โปรดักท์ เมเนเจอร์มืออาชีพแบบเราต้องตอบให้ได้ว่านั่นมันเกินความต้องการของเราไปไกลแค่ไหน หรือไม่ อย่างไร
กลับกลายเป็นว่าการเขียนในสิ่งที่รีไควเม้นท์หรือฟีเจอร์นี้ไม่ต้องการนั้นสำคัญเท่าๆกับการเขียนอธิบายในสิ่งที่เราต้องการ เพราะถ้าทีมพัฒนาไม่เข้าใจกรอบและขอบเขตของงานตั้งแต่แรกสิ่งที่จะเกิดขึ้นคือ
การประเมินเวลาผิดพลาดไปไกลหลายปีแสง การออกแบบที่ยากและมากเกินความจำเป็น การลองผิดลองถูกและเกิดการตั้งคำถามเกิดขึ้นในระหว่างการพัฒนา — ตรงนี้คือจุดสำคัญที่ทำงานให้ไม่เสร็จทันตามเวลาที่กำหนด ทำไมหนะหรอ? เพราะเมื่อทีมพัฒนามารู้ภายหลังว่า “นี่ไม่ใช่สิ่งที่ต้องทำ” มีโอกาสสูงที่พวกเขาต้องปรับเปลี่ยนโครงสร้างบางอย่างเพื่อไม่ทำในสิ่งที่ไม่ต้องทำ
ทีมพัฒนาที่ไม่เข้าใจสโคปงานอย่างชัดเจนว่าอะไรต้องทำและอะไรไม่ต้องทำนั้นจะไม่มีโฟกัส และทุกคำถามใหญ่ๆที่เกิดขึ้นระหว่างการทำงานคือสิ่งที่ทำให้พวกเขาไขว้เขว เช่น “เอ๊ะ ตรงนี้จะเอายังไง?” หรือ “อยากเพิ่มตรงนี้เข้าไปด้วยมั้ย?” หรือ “อันนี้มันยากกว่าที่คิดไว้เยอะเลย จะเอาแน่หรอ?” — คำถามพวกนี้ทำให้งานเราไม่เสร็จครับ
ถ้าเกิดคำถามหรือเหตุการณ์เหล่านี้ขึ้นระหว่างการพัฒนาโปรดักท์ (จะเรียกสปริ้นท์หรือโปรเจกต์หรืออะไรก็ตามแต่) เราในฐานะโปรดักท์ เมเนเจอร์ต้องโทษตัวเองก่อนเลยครับ เรามีอำนาจที่จะเลือกได้ว่าจะทำหรือไม่ทำอะไร แต่เราต้องใช้อำนาจนั้นอย่างมีความรับผิดชอบด้วย
“ผมไม่เข้าใจว่าทำไมเข้าสปริ้นท์แล้วงานไม่เสร็จ หรืองานมาเร่งเสร็จเอาสองวันสุดท้าย” — ถ้าเราตั้งคำถามแบบนี้บ่อยๆ … วิธีแก้ไขอันแรกเลยคือมองดูผลงานของตัวเองก่อนครับ เราทำหน้าที่ของเราได้ดีแล้วรึยัง
As a user, I want to … so that … — 👎🏼 โนวววว เขียนแค่นี้ใครๆก็เขียนได้ การกำหนดรีไควเม้นท์ที่ดีมันมีอะไรมากกว่านี้เยอะมาก (มากๆ) และการแค่ทำหน้าที่เขียน User Story ไม่ใช่เรื่องน่าภูมิใจอะไรของโปรดักท์ เมเนเจอร์เลยครับ
เราดีกว่านั้น เราทำได้มากกว่านั้นเยอะ … และเราต้องหาโอกาสทำมันตั้งแต่วันนี้ ทุกคนในทีมหวังพึ่งพาเราอยู่