คุณพัฒนาซอฟต์แวร์โดยไม่มีเกณฑ์การยอมรับได้อย่างไร

คุณจะร่วมมือกันพัฒนาซอฟต์แวร์ในทีมนักพัฒนา 4-5 คนโดยไม่มีเกณฑ์การยอมรับได้อย่างไรโดยไม่รู้ว่าผู้ทดสอบจะทดสอบอะไรกับคนหลายคน (2-3) ที่ทำหน้าที่เป็นเจ้าของผลิตภัณฑ์

สิ่งที่เรามีคือ 'สเป็ค' ภาพร่างพร้อมภาพหน้าจอและสัญลักษณ์กระสุนเล็กน้อย

เราได้รับการบอกว่ามันจะง่ายดังนั้นสิ่งเหล่านี้จึงไม่จำเป็น

ฉันกำลังสูญเสียวิธีการดำเนินการต่อไป

ข้อมูลเพิ่มเติม

เราได้รับกำหนดเวลาที่ยากลำบาก

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

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

ฉันสามารถเข้าใจได้ว่าเราไม่สามารถมีสเป็คที่สมบูรณ์แบบได้ แต่ฉันคิดว่ามันเป็น 'ปกติ' ที่จะมีเกณฑ์การยอมรับสำหรับสิ่งที่เรากำลังทำจริง ๆ ในการวิ่งแต่ละครั้ง

กระบวนการซ้ำจะประสบความสำเร็จอย่างนี้โดยไม่มีข้อกำหนดรายละเอียด

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

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

มันควรจะไปโดยไม่บอกว่าคุณจะไม่ทำงานสัญญาแบบตายตัวหรือแบบตายตัวด้วยวิธีนี้

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

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

หากลูกค้าของคุณถูกต้องเมื่อพวกเขาพูดว่า "มันจะง่าย" การออกกำลังกายนี้ควรเป็นเค้กชิ้นหนึ่ง

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

เจ้าของผลิตภัณฑ์ส่งต้นแบบให้คุณ ส่งเขากลับคนที่ดีกว่า (จนกว่าคุณจะทำ)

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

ต้นแบบของคุณควรเริ่มต้นด้วยกระดาษเลื่อนไปสู่การจำลองแบบดิจิทัลแล้วสร้างด้วยเทคโนโลยี "ของจริง"

Treehouseมีคู่มือที่ยอดเยี่ยมสำหรับเรื่องนี้ซึ่งสรุป:

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

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

ตรงตามกำหนดเวลาของคุณ

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

กำหนดเวลาของคุณคือข้อกำหนดที่ดีที่สุดที่คุณมี มีบางสิ่งที่สมบูรณ์และเชื่อมโยงกันที่คุณสามารถส่งมอบตรงเวลา

ทำงานร่วมกับผู้ทดสอบของคุณ

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

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

ลองทดสอบการออกแบบครั้งแรก

เนื่องจากคุณไม่มีข้อกำหนดที่เป็นทางการการขอทดสอบเพื่อพัฒนาต่อไปจะทำให้มีโครงสร้าง

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

ยึดตามมาตรฐานโดยเฉพาะอย่างยิ่งสำหรับ UI

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

เลือก UI มาตรฐานสำหรับเว็บไซต์ของคุณและไม่ปรับแต่งเว้นแต่ / จนกว่าจะมีการกำกับ ฉันไม่รู้ว่าคุณกำลังพัฒนาแพลตฟอร์มใด แต่BootstrapหรือGoogle Material Designเป็นสองตัวอย่าง

สื่อสาร แต่อย่ารบกวน

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

หากคุณมีคำถามให้อธิบายว่าคุณจะดำเนินการอย่างไรหากคุณไม่ได้รับคำแนะนำ ตัวอย่างเช่น:

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

อย่าตกใจ

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

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

โครงการคือการลดความไม่แน่นอนจนกว่าจะมั่นใจ :

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

นั่นคือหลักการของการทำอย่างละเอียดถี่ถ้วน: ข้อกำหนด, เกณฑ์และผลลัพธ์จะอธิบายอย่างละเอียดทีละขั้นตอนเช่นเดียวกับที่จะทำความเข้าใจลูกค้าเกี่ยวกับความคาดหวังและความต้องการของตัวเองผ่านการมีส่วนร่วมในกระบวนการพัฒนา

นี่เป็นปัญหาหรือไม่?

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

คำตอบของคำถามทั้งสองนี้ควรอยู่ในสัญญา หรือจะเป็นเรื่องของการเจรจาต่อรอง และลูกค้าต้องยอมรับการมีส่วนร่วมเพิ่มเติม (อาร์กิวเมนต์หลักจะเป็น "ขยะในขยะออก" แม้ว่าฉันจะแนะนำคุณอย่างยิ่งที่จะนำเสนอมันในลักษณะทางการทูตมากขึ้น ;-))

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

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

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

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

นอกจากนี้จุดเด่นอีกประการหนึ่งของการพัฒนาแบบวนซ้ำก็คือการเปลี่ยนแปลงข้อกำหนดจะทำให้เกิดการเปลี่ยนแปลงในไทม์ไลน์ คุณไม่สามารถกระทำการตามกำหนดเวลาได้หากคุณไม่สามารถพัฒนาไทม์ไลน์ได้และคุณไม่สามารถพัฒนาไทม์ไลน์ได้หากคุณไม่มีความคิดที่ดีเกี่ยวกับสิ่งที่ต้องทำ แทนที่จะขอข้อมูลจำเพาะอย่างดื้อรั้นให้ทบทวนข้อมูลจำเพาะปัจจุบันบันทึกคำถามใด ๆ ที่คุณหรือทีมมีเกี่ยวกับวิธีการทำงานกำหนดตารางเวลากับเจ้าของผลิตภัณฑ์เพื่อพูดคุยและจัดทำเอกสารคำตอบ เมื่อคุณทำเสร็จแล้วคุณจะมีข้อกำหนดของคุณตามการตัดสินใจของพวกเขาซึ่งคุณสามารถให้เจ้าของผลิตภัณฑ์ยอมรับ (เป็นลายลักษณ์อักษร) วัตถุประสงค์ของสเป็คคือการลบความคลุมเครือและสร้าง DoD ซึ่งเป็นสิ่งที่ Q&A สามารถให้ได้ หากมีการต่อต้านสเป็คอย่าเรียกมันว่าสเป็ค

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

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

คุณไม่มีการทำงานเป็นทีม ไปเปรียว

นั่งลงกับ PO และออกเนื้อ / เรื่องเล็ก ๆ เริ่มต้น / โอบอุ้ม "เรากำลังจะส่งมอบหน้าจอนี้โดยมีเพียงปุ่มนี้ที่จะไป 'bing!'" ชำระบัญชี AC บางตัว ส่งมอบเรื่องราว แสดงให้เห็นถึงเรื่องราว ปรากฎปุ่มควรเป็นสีแดง ยกข้อบกพร่องหรือเรื่องใหม่ ส่งมอบปุ่มที่ไปบ้องและปัง และอื่น ๆ

ระบุและส่งชิ้นส่วนแนวตั้งขนาดเล็กร่วมกันที่แสดงให้เห็นบ่อยครั้ง

หากลูกค้าไม่ทำงานกับคุณในลักษณะนี้ให้มองหาทางออก

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

คุณต้องระบุรายละเอียดที่สามารถตรวจสอบได้ก่อนที่จะเริ่มเขียนโค้ด นั่นเป็นความจริงและไม่มีการรับรอบ

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

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