By-Design“ Bugs” เป็นสัญญาณที่ไม่ดีหรือไม่?

29

มันเป็นสัญญาณที่ไม่ดีถ้าผู้ใช้ส่งรายงานข้อผิดพลาดสำหรับสิ่งที่ออกแบบ

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

(จริง ๆ แล้วฉันไม่มีรายงานใด ๆ เลยนี่เป็นคำถามที่สมมุติอย่างถี่ถ้วนว่าการมี "บั๊ก" โดยการออกแบบนั้นเป็นสิ่งที่ไม่ดีหรือไม่)

bug users

— Maxpm
แหล่งที่มา

19

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

— James Anderson

5

มันแนะนำให้ฉันทราบว่าข้อกำหนดของผู้ใช้ที่กำหนดให้กับนักพัฒนาไม่ตรงกับสิ่งที่ผู้ใช้คิดว่าพวกเขาถาม

— ล่อลวง

7

@temptar "มันเป็นสิ่งที่ฉันขอ แต่มันไม่ใช่สิ่งที่ฉันต้องการ"

— StuperUser

5

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

— CVn

7

@Dunk: ฉันใช้ระบบที่คิด 24 ชั่วโมงทุกวันเพราะเราล้มเหลวในการโน้มน้าวใจลูกค้าเกี่ยวกับเวลาออมแสงตามฤดูกาล พวกเขาแค่ไม่เชื่อว่ามีวันกับ 25 ชั่วโมง นั่นเป็นข้อบกพร่องในโปรแกรมหรือไม่?

— MSalters

54

มันเป็นสัญญาณที่ไม่ดี? ฉันคิดว่ามันเป็นคำเตือนที่ควรค่าแก่การดู แต่ฉันก็คิดว่ามันน่าจะเกิดขึ้น

เมื่อมีคนส่งความคิดเห็นใด ๆ มาหาฉันฉันพยายามกรองมันออกเป็นสามถัง:

เป็นโรคจิต
คำขอคุณสมบัติ
ผิดพลาดในการสื่อสาร

เป็นโรคจิต

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

คำขอคุณสมบัติ

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

ผิดพลาดในการสื่อสาร

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

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

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

— Scott Whitlock
แหล่งที่มา

3

การสื่อสารที่ไม่ถูกต้องยังรวมถึงการจำผิด (หรือลืมธรรมดา) ความคาดหวังซึ่งสื่อสารและตกลงกัน

— Peter Taylor

1

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

— Alex Andronov

@Alex Andronov - การสื่อสารผิดพลาดไม่ได้หมายความว่าจะไม่มีการดำเนินการใด ๆ : เปลี่ยนเอกสารคำแนะนำเครื่องมือ ฯลฯ อัปเดตเอกสารการฝึกอบรมหรืออาจเป็นเพียงคำอธิบายสั้น ๆ และดำเนินการต่อ

— Scott Whitlock

7

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

ผู้ใช้ส่วนใหญ่ไม่ได้ตระหนักถึงความซับซ้อนของซอฟต์แวร์ที่จะต้องตอบสนองความต้องการบางอย่าง บางสิ่งที่มีผลต่อความพยายาม 80% มีเพียง 20% ของฟังก์ชัน (ขอบและกรณียกเว้น)

บางครั้งพวกเขาไม่เข้าใจว่าทำไมซอฟท์แวร์จำเป็นต้องทำงานในลักษณะที่แน่นอนหลายต่อหลายครั้งเพื่อป้องกันข้อบกพร่องมากมายหรือข้อมูลเสียหาย ฯลฯ

สิ่งนี้ไม่ต้องกังวลเพราะจะดีขึ้นด้วยเอกสารและการสื่อสารที่ชัดเจนและรัดกุม

— maple_shaft
แหล่งที่มา

2

+1 แต่โปรดค้นหาความแตกต่างระหว่างความซับซ้อนและความซับซ้อน ... ซอฟต์แวร์ไม่จำเป็นต้องซับซ้อนเลย แต่บ่อยครั้งก็ซับซ้อนมาก

— Marjan Venema

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

— Scott Whitlock

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

— maple_shaft

5

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

ความคิดเห็นอย่างหนึ่งเกี่ยวกับคุณลักษณะ UI หรือเขตข้อมูลที่พวกเขาคิดว่าควรมีสัญลักษณ์สกุลเงินหรือรูปแบบอื่น ๆ ควรได้รับการพิจารณาอย่างน้อยก็จนกว่าคุณจะได้รับข้อเสนอแนะเพิ่มเติม การวิจัยนี้อาจเป็นเรื่องยากขึ้นเล็กน้อย

— JeffO
แหล่งที่มา

1

ไม่มีคำตอบเดียวแล้วฉันคิดว่า ควรได้รับการประเมินเป็นกรณี ๆ ไป ฉันคิดได้มาก

— Maxpm

5

ข้อบกพร่องจากการออกแบบในประสบการณ์ของฉันหมายความว่ากรณีการใช้งานของคุณไม่เหมาะสมกับผู้ใช้จริงของคุณ ลองอ่านเกี่ยวกับการใช้ผู้ใช้จริงสำหรับเคสการใช้งานของคุณ (เพียงแค่ให้ชื่อกับพวกเขาและคำอธิบายรูปขนาดย่อจะเป็นสิ่งมหัศจรรย์สำหรับคุณภาพของกรณีการใช้งาน)

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

— ทิม Williscroft
แหล่งที่มา

5

UI ควรเป็นไปตามหลักการของความน่าเชื่อถือน้อยที่สุด - รายงานข้อผิดพลาดซ้ำ ๆ เกี่ยวกับคุณลักษณะที่ทำงานตามที่ออกแบบมาเป็นข้อบ่งชี้ว่าหลักการนี้ไม่ได้ปฏิบัติตามอย่างถูกต้อง

— Joris Timmermans
แหล่งที่มา

3

หรือว่ามีกลุ่มผู้ใช้ที่แบ่งออกเป็น ตัวอย่างเช่นสมมติว่า webapp ของคุณสร้างเดสก์ท็อป คุณคาดหวังว่าการปิดหน้าต่างจะเป็นการปิดโปรแกรมหรือไม่? ใช่สำหรับผู้ใช้ Windows ไม่ใช่สำหรับผู้ใช้ Mac

— keppla

1

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

— Joris Timmermans

1

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

— Jeff Atwood

@Jeff Atwood - ตามที่บอกว่า "one กลืนไม่ได้ทำให้ฤดูร้อน", "รายงานข้อผิดพลาดอย่างใดอย่างหนึ่งไม่ได้หมายความถึงข้อผิดพลาดการออกแบบ" รายงานข้อผิดพลาดเพียงครั้งเดียวเกี่ยวกับสิ่งที่เป็นคุณลักษณะนั้นไม่ได้เป็นสาเหตุสำหรับการออกแบบใหม่และแม้แต่รายงานหลาย ๆ ฉบับเกี่ยวกับคุณสมบัติทั่วไปก็ไม่ได้หมายความว่าผู้ใช้ส่วนใหญ่ของคุณจะไม่พอใจมากขึ้นหากไม่มี "แก้ไข" โดยเฉพาะอย่างยิ่งหากการเปิดตัวครั้งแรกของคุณได้รับความนิยมและผู้คนคุ้นเคยกับการใช้ "แบบนั้น"

— Joris Timmermans

2

มีข้อบกพร่องสองประเภท: ฟังก์ชันการทำงานไม่ตรงกับความตั้งใจของโปรแกรมเมอร์หรือฟังก์ชันไม่ตรงกับข้อกำหนด โปรแกรมเมอร์มีแนวโน้มที่จะมุ่งความสนใจไปที่ความเสียหายในอดีต หากต้องการให้ผู้ใช้ของคุณรายงานผู้ใช้ของคุณอย่าง "by-design bugs" ความต้องการของคุณไม่ใช่สิ่งที่คุณคิด

— Karl Bielefeldt
แหล่งที่มา

2

ไม่จำเป็น. อาจเป็นไปได้ว่าข้อผิดพลาดที่รายงานอยู่ในการใช้งานซอฟต์แวร์ซึ่งอยู่นอกขอบเขตที่กำหนดไว้เดิม พิจารณาซอฟต์แวร์ที่ออกแบบมาเพื่อทำ A, B และ C (สำหรับตัวอย่างเล็กน้อยวาดเส้นสามเหลี่ยมและสี่เหลี่ยม) หาก D เป็นขั้นตอนถัดไปแบบลอจิคัล (เช่น pentagons) ผู้ใช้อาจคิดว่ามันควรทำเช่นกันและการไม่ทำเช่นนั้นจะเป็นข้อผิดพลาด แต่ถ้านี่อยู่นอกขอบเขตเดิมนั่นไม่ใช่ข้อผิดพลาด มันอาจเป็นการควบคุม (บั๊ก) ในการออกแบบหรือพื้นที่สีเทาในสเปคหรือชุดของสมมติฐานที่แตกต่างกันโดยนักพัฒนาและผู้ใช้

(แก้ไข - เพิ่มความคิดเห็นของฉันในคำตอบตามคำแนะนำของ @Marjan Venema

— James McLeod
แหล่งที่มา

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

— Maxpm

1

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

— James McLeod

1

James ถ้าคุณเพิ่มข้อคิดเห็นลงในคำตอบของคุณคำตอบทั้งหมดจะดีขึ้น

— Marjan Venema

1

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

ฉันเห็นการออกแบบสองประเภท - ออกแบบโดยไม่ได้ตั้งใจ - ออกแบบตามความตั้งใจ

การออกแบบโดยบังเอิญนำไปสู่ปัญหาดังกล่าวบ่อยครั้งและไม่สามารถรักษาไว้ได้

— 18bytes
แหล่งที่มา

1

ฉันต้องการเพิ่มคำตอบของ maple_shaft เกี่ยวกับ "ความไม่รู้" ของผู้ใช้ คุณต้องจำไว้ว่า 90% ของผู้ใช้จะใส่ใจเฉพาะประสบการณ์ของตนเองและวิธีการใช้ระบบ พวกเขาไม่สนใจผู้ใช้รายอื่นทำไมพวกเขาควร? เป็นหน้าที่ของเราในฐานะนักออกแบบ / นักพัฒนาที่จะรับข้อมูลจากผู้ใช้หลากหลายประเภทและทำสิ่งที่เหมาะกับทุกคนให้ดีที่สุดเท่าที่จะทำได้ ส่วนใหญ่คุณไม่สามารถแก้ปัญหาที่ดีที่สุดสำหรับทุกคน

แต่แน่นอนคุณต้องอ่านและประเมินผลตอบรับจากผู้ใช้ของคุณ! พวกเขาคือผู้ใช้การสร้างของคุณ!

— AndSoYouCode
แหล่งที่มา

0

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

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

— HLGEM
แหล่งที่มา