เมื่อไรที่จะจัดส่งผลิตภัณฑ์ที่มีข้อบกพร่องที่รู้จัก

เมื่อไรที่จะจัดส่งผลิตภัณฑ์ที่มีข้อบกพร่องที่รู้จัก

ฉันถือว่าคุณกำลังพูดถึงข้อผิดพลาด "รู้จัก" (คำถามนี้ไม่มีความหมายเป็นอย่างอื่น) คำตอบนั้นขึ้นอยู่กับปัจจัยเหล่านี้:

1) ใครคือผู้ใช้และจะยอมรับข้อผิดพลาดในกรณีที่พบได้อย่างไร

2) อะไรคือผลกระทบที่อาจเกิดขึ้น (ความเสียหาย) ของบั๊ก?

3) เป็นไปได้ไหมที่จะชะลอการส่งซอฟต์แวร์เพื่อแก้ไขข้อบกพร่อง?

4) ที่สำคัญที่สุด: สิ่งที่คุณคาดหวังจากซอฟต์แวร์ของคุณ? เวลาไปตลาด? คุณภาพ? คุณต้องการดูว่าลูกค้าของคุณใช้ซอฟต์แวร์นานพอที่จะพบข้อบกพร่องหรือไม่

จะต้องมีการตกลงเสมอเพราะไม่มีสิ่งใดที่เป็นซอฟต์แวร์ที่ไม่มีข้อผิดพลาด

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

ดังนั้นดูจากมุมมองค่าใช้จ่าย / ผลประโยชน์

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

ดังนั้นหากคุณมีระยะเวลาการทดสอบ 2 สัปดาห์ก่อนที่คุณจะวางจำหน่ายและพบข้อบกพร่องเล็ก ๆ คำถามคือ ... กำลังแก้ไขข้อบกพร่องนั้นที่มีค่าเพิ่มเติมอีก 2 สัปดาห์ที่ทีมอาจต้องใช้เพื่อทดสอบแอปพลิเคชันและการติดตั้งใหม่ (บ่อยครั้งที่ลืมเกี่ยวกับขั้นตอนในการสร้างซอฟต์แวร์) ค่าใช้จ่ายในการสร้างชื่อเสียงหรือการขายเป็นอย่างไรหากซอฟต์แวร์ช้า? คนจะโกรธหรือเปล่า? พวกเขาอาจมีความสุขที่ได้อยู่กับบั๊กเล็กน้อยหากสามารถส่งมอบฟังก์ชันการทำงานที่สำคัญตรงเวลา

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

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

บักมีความรุนแรงแตกต่างกัน ที่ บริษัท ซอฟต์แวร์ใด ๆ ที่ฉันเคยทำงานกับเราได้จัดหมวดหมู่บั๊กตามลำดับความสำคัญตั้งแต่ P0 ถึง P4

P0 เป็นซอฟต์แวร์ที่ไม่ทำงาน / ผิดพลาดและอาจทำให้เกิดความเสียหายต่อธุรกิจของลูกค้า P1 มันไม่ทำงานตามที่ออกแบบมาและล้มเหลวอย่างต่อเนื่องในฟังก์ชั่นหลัก P2 มันล้มเหลวเป็นครั้งคราวและฟังก์ชั่นด้านข้างอาจไม่ทำงาน P3 องค์ประกอบบางส่วนของซอฟต์แวร์ไม่ทำงานตามที่ได้รับการออกแบบ / คาดว่าจะเกิดปัญหากับ P4 Cosmetic

ฉันทำงานในสถานที่ที่ P4 ไม่ได้รับการแก้ไขเพราะพวกเขามีผลกระทบเล็กน้อยต่อซอฟต์แวร์

ฉันจะบอกว่ามันโอเคที่จะจัดส่งถ้าซอฟต์แวร์ของคุณรู้จักปัญหา P3 / P4 ฉันจะใส่สิ่งนี้ลงในบันทึกย่อประจำรุ่นและทราบว่ากำลังทำงานอยู่

ฉันจะไม่ปล่อยซอฟต์แวร์ที่มีปัญหา P0, P1 หรือ P2 ที่ฉันรู้

มันเรียกว่า " ปัญหาที่เป็นที่รู้จัก " Google, Microsoft, Apple และอื่น ๆ ทั้งหมดจัดส่งผลิตภัณฑ์ที่มีข้อบกพร่องทั้งที่รู้จักและไม่รู้จัก พยายามย่อให้เล็กที่สุด แต่อย่ารอให้สมบูรณ์แบบ จัดส่งเร็วจัดส่งบ่อย

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

เมื่อมันเป็น "คุณสมบัติ"! ;)

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

ดังนั้นโปรดนำไปใช้ในทางปฏิบัติหากทุกสิ่งที่คุณพบในการทดสอบของคุณได้รับการแก้ไขแล้วสิ่งพิเศษควรได้รับการแก้ไขตามความจำเป็น

ตราบใดที่คุณซื่อสัตย์ต่อลูกค้าคุณสามารถจัดส่งด้วยข้อบกพร่อง การบอกพวกเขาเกี่ยวกับข้อบกพร่องที่มีอยู่ทั้งหมดแสดงให้เห็นว่าคุณมีความรู้ที่ดีเกี่ยวกับซอฟต์แวร์ของคุณและนั่นเป็นการทดสอบที่ดี (ถ้าเป็น .. ) :)

เห็นได้ชัดว่าสิ่งที่ดีที่สุดคือการหลีกเลี่ยงการขนส่งด้วยข้อบกพร่อง

เป็นการดีกว่าหากมีการจัดส่งผลิตภัณฑ์ตรงเวลาพร้อมกับรายการปัญหาที่ทราบแล้วไม่ใช่การจัดส่ง

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

นี่คือสาเหตุที่อูบุนตูจัดส่งทุก ๆ ครึ่งปีแม้ว่าจะยังมีปัญหาที่เปิดอยู่

ฉันจะบอกว่ากฎง่ายๆคือ "ข้อผิดพลาดนี้เป็น showstopper หรือไม่"

หากข้อผิดพลาดทำให้เกิด "สถานการณ์เส้นทางความสุข" ล้มเหลวแล้ว อย่างไม่มาพร้อมกับข้อผิดพลาดที่

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

หากมีการบันทึกข้อผิดพลาดและมีวิธีแก้ไขปัญหาที่ทราบแล้วก็อาจเป็นไปได้ที่จะจัดส่งด้วยจุดบกพร่องนั้น

จากมุมมองของผู้บริโภค ... ไม่เคย ประเด็นของฉันคือตราบใดที่คุณรู้ว่ามีข้อผิดพลาดที่สำคัญในซอฟต์แวร์แล้วคุณไม่ควรจัดส่ง อย่างไรก็ตามกองกำลังของธรรมชาติ (ธุรกิจ) แทนที่สิ่งนี้หากวงจรการผลิตของซอฟต์แวร์อยู่ในขั้นตอนที่มันสามารถเป็นอันตรายต่อรูปแบบธุรกิจและพวกเขาเป็นข้อบกพร่องเล็ก ๆ น้อย ๆ ที่จะไม่: (i) ประนีประนอมความปลอดภัยของซอฟต์แวร์ (ii)

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

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

1. การเกิดขึ้น
2. ความรุนแรง
3. การตรวจพบ

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

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

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