คำถามติดแท็ก product-features

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว อนุญาตให้ฉันเพิ่มรายละเอียด: ฉันทำงานในสถานที่ของสถาบันที่มีผู้เขียนโค้ดนักทดสอบนักวิเคราะห์ QA เจ้าของผลิตภัณฑ์ ฯลฯ และที่นี่เป็นสิ่งที่ทำให้ฉัน: เราสามารถขายซอฟต์แวร์เส็งเคร็ง (แม้ว่าฟังก์ชั่นสวย) มานานกว่าทศวรรษ มันมีคุณสมบัติมากมายและผลิตภัณฑ์มีการแข่งขัน แต่มีข้อผิดพลาดบางอย่างร้ายแรงเช่นเดียวกับ "การตัดกระดาษ" หลายพันครั้ง - สร้างความรำคาญเล็กน้อยที่ลูกค้าจำเป็นต้องคุ้นเคย มันทำให้ฉันลำบากในการดูบางสิ่งเพราะฉันเชื่อมั่นอย่างยิ่งว่าหากคอมพิวเตอร์ไม่ช่วยให้ชีวิตของเราง่ายขึ้นเราก็ไม่ควรใช้มัน ฉันมีความมั่นใจในเพื่อนร่วมงานของพวกเขา - พวกเขาฉลาดมีความสามารถและสามารถปรับปรุงสิ่งต่าง ๆ เมื่อมุ่งเน้นไปที่การทำเช่นนั้น แต่มันอาจเป็นเรื่องยากที่จะยื่นข้อบกพร่องกับฟังก์ชั่นเก่าบางอย่างโดยไม่เห็นพวกเขาปิดหรือลืม "มันทำงานได้อย่างนั้นสำหรับมหายุค" เป็นคำตอบทั่วไป นอกจากนี้เมื่อ QA ทำการถดถอยพวกเขามักจะมองหาสิ่งที่แตกต่างกันมากเท่ากับสิ่งที่ดูเหมือนจะไม่ถูกต้อง ดังนั้นการแก้ไขปัญหาเก่าสามารถเขียนขึ้นเป็นข้อผิดพลาดเพราะ "มันเป็นเช่นนั้นมาก่อนแม้กระทั่งเวลาของฉัน" ผู้เขียนโค้ดหนุ่มในฉันคิดว่า: เขียนสิ่งที่เลวร้ายนี้ใหม่! ในฐานะที่เป็นคนที่มีโอกาสใกล้เคียงกับยอดขายลูกค้าฉันต้องการให้ข้อสงสัยเกี่ยวกับวิธีการนี้ ฉันสนใจในความเห็น / ประสบการณ์ของคุณเช่นกัน โปรดลองพิจารณาความเสี่ยงต้นทุนต่อผลประโยชน์และปัจจัยอื่น ๆ ที่ไม่ใช่ด้านเทคนิค

18 business  product-features  usability 

ก่อนหน้านี้ฉันเขียนสคริปต์ python ขนาดเล็กมากที่ตรวจสอบฟีด xml เป็นระยะ ๆ สำหรับรายการใหม่และแจ้งเตือนผู้ใช้ไปยังรายการใหม่เมื่อมี ฉันเขียนสิ่งนี้ด้วยตนเองดังนั้นจึงเป็นโปรแกรมที่ใช้คอนโซลเป็นหลักซึ่งทุกคนที่คุ้นเคยกับส่วนต่อประสานคอนโซลสามารถใช้งานได้ หลังจากที่ในขณะที่ฉันตัดสินใจว่ามันอาจเป็นประโยชน์กับคนอื่น ๆ และเริ่มที่จะเป็นระเบียบขึ้นอินพุตฆ่าเชื้อกำจัดแมลง มันเกิดขึ้นกับฉันเพราะฉันเขียนสคริปต์ฉันรู้วิธีใช้อย่างมีประสิทธิภาพถูกต้อง ฯลฯ คนอื่นอาจไม่ได้ดังนั้นฉันจึงเริ่มเพิ่ม GUI สิ่งนี้เริ่มต้นจากเมนูง่าย ๆ จากนั้นขยายเป็น GUI เต็มรูปแบบมากขึ้นด้วยทั้งเมนูอินเตอร์เฟสและตัวเลือก ฉันเพิ่มการตั้งค่าผู้ใช้ที่เก็บไว้และที่เก็บข้อมูลสำหรับฟีด xml ที่ค้นหาก่อนหน้านี้เพื่อเพิ่มความเร็วในการค้นหาซ้ำ ฉันเพิ่มการบันทึกเพื่อช่วยในการดีบักแอปพลิเคชันในกรณีที่มีสิ่งผิดปกตินำแอปพลิเคชั่นไปยังฐานข้อมูลหลามเสถียรล่าสุดสำหรับแพลตฟอร์มที่ฉันเลือกและปรับปรุงคุณสมบัติการโต้ตอบ ฉันได้แก้ไขข้อผิดพลาดและแสดงความคิดเห็นรหัสของฉันอย่างชัดเจน แต่ฉันยังมีสิ่งที่ฉันคิดว่าสามารถทำได้เพื่อปรับปรุงแอพก่อนที่ฉันจะเปิดให้ผู้ทดสอบอัลฟ่าใช้งานได้ มันเป็นหนทางไกลมากจากสคริปต์บรรทัดเดิมของฉัน 20-30 สิ่งที่ฉันคาดหวังจะใช้เวลาเพียงหนึ่งหรือสองชั่วโมงในการเปลี่ยนจากการพิสูจน์แนวคิดไปสู่โปรแกรมการใช้งานที่ยอมรับได้ซึ่งใช้เวลา 10-20 เท่า (ฉันยังคงเป็น noob และสิ่งต่าง ๆ ใช้เวลานาน แต่ก็ยัง .... ) คุณจะรู้ได้อย่างไรว่าเมื่อใดที่จะหยุดเพิ่ม / ปรับแต่ง / แก้ไขสิ่งต่าง ๆ และปล่อยให้ลูกของคุณคลานออกมาในที่โล่ง

16 development-process  product-features 

เมื่อเร็ว ๆ นี้ฉันได้เห็นปัญหาที่คล้ายกับปัญหาที่อธิบายไว้ในบทความนี้มากขึ้นเรื่อย ๆ อีกคำสำหรับมันคือสายผลิตภัณฑ์แม้ว่าฉันมักจะเชื่อว่าสิ่งเหล่านี้กับผลิตภัณฑ์ที่แตกต่างกันจริงในขณะที่ฉันมักจะพบปัญหาเหล่านี้ในรูปแบบของการกำหนดค่าผลิตภัณฑ์ที่เป็นไปได้ แนวคิดพื้นฐานของปัญหาประเภทนี้ง่ายมาก: คุณเพิ่มคุณสมบัติให้กับผลิตภัณฑ์ แต่อย่างใดสิ่งที่ซับซ้อนเนื่องจากการรวมกันของคุณสมบัติที่มีอยู่อื่น ๆ ในที่สุด QA พบปัญหากับชุดค่าผสมที่หายากซึ่งไม่มีใครคิดมาก่อนและสิ่งที่ควรเป็นตัวแก้ไขข้อบกพร่องอย่างง่าย ๆ ก็อาจกลายเป็นการต้องการการเปลี่ยนแปลงการออกแบบที่สำคัญ มิติของปัญหาการแยกคุณลักษณะนี้มีความซับซ้อนที่เหลือเชื่อ สมมติว่าเวอร์ชันซอฟต์แวร์ปัจจุบันมีNคุณสมบัติและคุณเพิ่มคุณสมบัติใหม่หนึ่งรายการ นอกจากนี้เราจะทำให้สิ่งต่าง ๆ ง่ายขึ้นด้วยการบอกว่าคุณลักษณะแต่ละอย่างสามารถเปิดหรือปิดได้เท่านั้นจากนั้นคุณ2^(N+1)มีการผสมผสานคุณสมบัติที่เป็นไปได้ที่จะต้องพิจารณา เนื่องจากการขาดการใช้ถ้อยคำที่ดีกว่า / คำค้นหา, ผมหมายถึงการดำรงอยู่ของชุดเหล่านี้เป็นปัญหาคุณลักษณะที่สี่แยก (คะแนนโบนัสสำหรับคำตอบรวมถึงการอ้างอิงสำหรับคำที่กำหนดขึ้น) ตอนนี้คำถามที่ฉันต่อสู้คือวิธีจัดการกับปัญหาความซับซ้อนนี้ในแต่ละระดับของกระบวนการพัฒนา สำหรับเหตุผลด้านราคาที่ชัดเจนมันเป็นไปไม่ได้จนถึงจุดที่เป็นอุดมคติที่ต้องการแยกแต่ละชุดค่าผสม ท้ายที่สุดเราพยายามหลีกเลี่ยงอัลกอริธึมที่ซับซ้อนแบบเอกซ์โปเนนเชียลเพื่อเหตุผลที่ดี แต่เพื่อเปลี่ยนกระบวนการพัฒนาให้กลายเป็นสัตว์ประหลาดขนาดเอ็กซ์โพเนนเชียล ดังนั้นคุณจะได้รับผลลัพธ์ที่ดีที่สุดในแบบที่เป็นระบบที่ไม่ระเบิดงบประมาณใด ๆ และเสร็จสมบูรณ์ในวิธีที่เหมาะสมมีประโยชน์และเป็นที่ยอมรับอย่างมืออาชีพ ข้อมูลจำเพาะ: เมื่อคุณระบุคุณลักษณะใหม่ - คุณจะมั่นใจได้อย่างไรว่ามันเล่นได้ดีกับเด็กคนอื่น ๆ ทั้งหมด? ฉันสามารถเห็นได้ว่ามีใครสามารถตรวจสอบแต่ละคุณลักษณะที่มีอยู่ร่วมกับคุณลักษณะใหม่อย่างเป็นระบบ แต่จะแยกคุณลักษณะอื่น ๆ เมื่อพิจารณาถึงลักษณะที่ซับซ้อนของคุณลักษณะบางอย่างมุมมองที่แยกได้นี้มักเกี่ยวข้องกันอยู่แล้วเพื่อให้ต้องการแนวทางแบบมีโครงสร้างในตัวเองโดยไม่คำนึงถึง2^(N-1)ปัจจัยที่เกิดจากคุณสมบัติอื่น ๆ ที่เราไม่สนใจ การติดตั้งใช้งาน: เมื่อคุณติดตั้งฟีเจอร์ - คุณจะมั่นใจได้อย่างไรว่าโค้ดของคุณโต้ตอบ / ตัดกันอย่างถูกต้องในทุกกรณี อีกครั้งฉันสงสัยเกี่ยวกับความซับซ้อนที่แท้จริง …

11 complexity  product-features