คุณจะทำอย่างไรเมื่อผู้ใช้ขอคุณสมบัติที่คุณจะไม่ใช้งาน

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

ฉันเขียนแอพ iOS และมีผู้ใช้จำนวนหนึ่งที่ถามฉันถึงคุณสมบัติที่ซับซ้อนบางอย่างที่ฉันไม่สามารถทำได้เนื่องจากสาเหตุข้างต้น เวลาส่วนใหญ่ฉันเพิ่งตอบพวกเขาว่า "เราจะนำมาพิจารณาด้วย" อธิบายพวกเขาว่าพวกเขาอยู่ในชนกลุ่มน้อยที่ต้องการคุณสมบัตินี้จะไม่ช่วยเช่นกัน แล้วคุณจะทำอย่างไรในกรณีเช่นนี้?

ฉันคิดว่าคุณกำลังทำสิ่งที่ถูกต้อง คุณไม่สามารถทำให้ทุกคนพอใจและคุณไม่ควรทำ! เป็นคนสุภาพและเป็นมืออาชีพ แต่คุณไม่ต้องทำทุกสิ่งที่ต้องการ

คุณต้องมาประนีประนอม ผู้ใช้ของคุณ (เหตุผลที่แอปนั้นมีอยู่) กำลังบอกว่าไม่เป็นไปตามความต้องการของเขา / เธอ

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

เหนือสิ่งอื่นใด: โปรดจำไว้ว่าไม่มีแอพที่จะทำให้ชีวิตของคุณง่ายขึ้นในฐานะโปรแกรมเมอร์ แอปอยู่ที่นั่นเพื่อทำหน้าที่ผู้ใช้

หากคุณอ่านบล็อก Seth Godins ( http://sethgodin.typepad.com/ ) คุณจะเห็นข้อความเดียวกันที่ปรากฏขึ้นเรื่อย ๆ :

1. จัดส่งบางสิ่ง (และรับฟังความคิดเห็น)
2. อย่าพยายามทำให้ทุกคนพอใจตลอดเวลา

ฉันมีปัญหาคล้ายกับคุณกับผลิตภัณฑ์ที่ฉันขาย ฉันมีคำขอทุกประเภทสำหรับคุณสมบัติทุกประเภท แอพพลิเคชั่นนี้มีความซับซ้อนมากกว่าที่ฉันต้องการจริงๆ ทุกตัวเลือกเพิ่มความซับซ้อนสิ่งที่ฉันต้องการหลีกเลี่ยง และตอนนี้ฉันมีความซับซ้อนมากกว่าที่ฉันต้องการ

การทำเช่นนี้จะทำให้ผู้ใช้พอใจมากขึ้น และผลักไสผู้ใช้ที่พบว่ามันยากเกินกว่าจะเซ็ตอัพได้

มีการตั้งค่าง่าย / ขั้นสูงเป็นวิธีออกจากการผูก จนถึงจุดหนึ่ง มันทำให้การพัฒนาของคุณซับซ้อนยิ่งขึ้น

ในทุกกรณีที่ฉันได้รับคำขอฉันจะตอบอย่างสุภาพเสมอ บางครั้งฉันก็จะปฏิเสธทันทีแม้ว่านี่จะเป็นของหายาก และที่ฉันทำสิ่งนี้ฉันอธิบายว่าทำไมโดยปกติแล้วจะเป็นการตอบสนองต่อคำขอที่ต้องการให้ UI ทั้งหมดได้รับการปรับปรุงเป็นงานที่ใหญ่มากฉันแค่ไม่ไปที่นั่น ในกรณีนั้นฉันอธิบายเหตุผลของฉัน แต่ขอบคุณผู้ใช้สำหรับคำขอ

ในทุกกรณีรวมถึงสิ่งที่ฉันปฏิเสธทันทีฉันจะบันทึกไว้ในฐานข้อมูลคุณลักษณะและข้อบกพร่องเพื่อประกอบการพิจารณารุ่นถัดไป สิ่งนี้จะช่วยให้คุณมีเวลาคิดเพิ่มขึ้นอีกเล็กน้อยและอาจเกิดขึ้นในภายหลังพร้อมกับทางเลือกที่ไม่ใช่สิ่งที่ขอมาอย่างแน่นอน แต่อาจเพิ่มคุณค่าบางอย่าง

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

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

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

ในระยะยาวผมเชื่อว่าจะเป็นประโยชน์กับคุณมากที่สุด

ฉันแค่ขอขอบคุณพวกเขาสำหรับคำแนะนำ แต่บอกว่ามันไม่ได้อยู่ในแผนที่ถนนของคุณตอนนี้ คนส่วนใหญ่จะเข้าใจว่าคุณมีทรัพยากร จำกัด

ฉันมักจะทำสามสิ่งเมื่อฉันอยู่ในสถานการณ์เช่นนี้:

1. ฉันคิดว่าสองครั้งถ้าความคิดของผู้ใช้อาจเป็นความคิดที่ดี ฉันเรียนรู้ที่จะไม่เชื่อสัญชาตญาณแรกของฉัน บางครั้งผู้ใช้ถูกต้องและฉันผิด
2. อธิบายกับผู้ใช้ว่าเหตุใดคุณจึงไม่สามารถรวมคุณลักษณะนั้น
3. อธิบายผู้ใช้ว่าเธอสามารถรับสิ่งที่เธอต้องการด้วยซอฟต์แวร์ที่เธอมีได้อย่างไร

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

สำหรับผลิตภัณฑ์แต่ละรายการของเราเรามี "รายการแนวคิดสำหรับรุ่นอนาคต" ดังนั้นสิ่งที่เราบอกผู้ใช้ของเราคือ "เราจะให้คำแนะนำของคุณในรายการนั้น" - และนั่นคือความจริงเราทำอย่างนั้นจริง ๆ

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

การร้องขอคุณสมบัติต่อต้านความสมบูรณ์ทางแนวคิดของผลิตภัณฑ์น่าจะอยู่ที่นั่นตลอดไป แต่บางครั้งมันเกิดขึ้นที่อย่างน้อยความคิดบางอย่างที่ถูกฝังอยู่ในคำขอคุณลักษณะเหล่านั้นสามารถรับรู้ได้บางทีอาจไม่ใช่วิธีที่คนที่แนะนำให้นึกถึง แต่ในทางที่เหมาะสมกับสถาปัตยกรรมของผลิตภัณฑ์

ดังนั้นข้อเสนอแนะของฉันที่นี่คือ: อย่าเพิ่งพูดว่า "เราจะนำมาพิจารณาด้วย" และลืมความคิดนั้นทันทีที่คุณวางสาย แต่ให้มีเครื่องมือที่คุณเก็บความคิดและคำขอคุณสมบัติบางทีในตัวติดตามปัญหาหรืออาจเป็นใน Wiki หรือในสเปรดชีตไม่ว่าอะไรก็ตามที่คุณต้องการที่สุด