คุณควรสัญญาว่าจะส่งมอบฟีเจอร์ที่คุณไม่แน่ใจว่าจะใช้งานได้หรือไม่?

ในบทความจาก HNฉันพบคำแนะนำต่อไปนี้:

บอกลูกค้า / ผู้ใช้เสมอว่า "ใช่" แม้ว่าคุณจะไม่แน่ใจ 90% ของเวลาคุณจะพบวิธีที่จะทำ 10% ของเวลาคุณจะกลับไปและขอโทษ ราคาเล็ก ๆ สำหรับการเติบโตส่วนบุคคลที่สำคัญ

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

นี่คือคำถามที่สองในช่วงสั้น ๆ ที่เกิดจากบทความนั้น

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

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

• และตอนนี้บอกลูกค้า / ผู้ใช้เสมอว่า "ใช่" แม้ว่าคุณจะไม่แน่ใจ 90% ของเวลาคุณจะพบวิธีที่จะทำ
  นี่เป็นคำแนะนำที่ไม่ดีอย่างไม่น่าเชื่อ

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

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

ลองใช้วิธีนี้: คุณคิดว่าจะเกิดอะไรขึ้นกับอุตสาหกรรมการบินหาก 90% ของการลงจอดเครื่องบินทั้งหมดประสบความสำเร็จ คุณคิดว่าจะกลับไปและขอโทษสำหรับ 10% ที่เกิดปัญหาจะแก้ไขอะไร?

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

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

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

คำถามนี้ได้รับการศึกษาอย่างเป็นทางการและได้รับการแก้ไขโดยการผลิตร่วมกันอีอีอีพีซีสังคม / ACM จรรยาบรรณ

2.01 ให้บริการในด้านความสามารถซื่อสัตย์และตรงไปตรงมาเกี่ยวกับข้อ จำกัด ใด ๆ ของประสบการณ์และการศึกษา

3.04 ตรวจสอบให้แน่ใจว่าพวกเขามีคุณสมบัติสำหรับโครงการใด ๆ ที่พวกเขาทำงานหรือเสนอให้ทำงานโดยการผสมผสานระหว่างการศึกษาและการฝึกอบรมและประสบการณ์ที่เหมาะสม

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

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

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

มีเรื่องราวจากยุคแรก ๆ ของซูเปอร์คอมพิวเตอร์ที่ Seymour Cray และทีมงานที่ Control Data Corporation ใกล้จะเปิดตัวผลิตภัณฑ์และ บริษัท คอมพิวเตอร์ขนาดใหญ่มากคนหนึ่งบอกกับลูกค้าว่ามันใกล้จะเปิดตัวแล้ว ค่าใช้จ่ายในการโกหก CDC เป็นจำนวนมากของธุรกิจและกลายเป็นคดีที่ บริษัท ใหญ่ไม่สามารถแสดงหลักฐานที่น่าเชื่อถือสำหรับการเรียกร้องของพวกเขา ผลที่ได้คือสิ่งที่เกิดขึ้นในขณะที่การตั้งถิ่นฐานครั้งใหญ่มูลค่า 80 ล้านดอลลาร์ 2513 (ประมาณ 223 ล้านดอลลาร์ใน 2555 ปรับเงินเฟ้อ) คุณสามารถอ่านได้ที่นี่:

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing

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

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

คุณลักษณะเพิ่มมูลค่าเพียงพอที่จะรับประกันค่าใช้จ่ายของความพยายามหรือไม่?

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

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

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

เล่นงานผู้สนับสนุนของปีศาจ

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

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

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

เนื่องจากไม่มีเกณฑ์ที่แน่นอนสำหรับการวัดความยากของคำขอบ่อยครั้งสิ่งที่สำคัญต่อลูกค้าคือความไว้วางใจว่าผู้รับเหมาให้ความพยายาม 100% มากกว่าที่จะตอบสนองคำขอ 90% หรือ 100%

สมมติว่าลูกค้าต้องเลือกระหว่างสองสถานการณ์:

ผู้รับเหมา A :

• มั่นใจว่าพวกเขาสามารถส่งมอบตามคำขอทั้งหมด
• ผลลัพธ์: 90% ของคำขอที่ส่งมอบ
• ลูกค้ายินดีที่ผู้รับเหมาพยายาม 100%
• ลูกค้ารับรู้ว่าคำขอที่ไม่สมบูรณ์นั้นเกิดจากปัญหาที่ไม่คาดฝันซึ่งอาจอยู่นอกเหนือการควบคุมของผู้รับเหมา

ผู้รับเหมา B :

• มุ่งมั่นที่จะส่งมอบ 90% ของคำขอ ไม่มั่นใจพวกเขาสามารถส่งมอบส่วนที่เหลือ 10%
• ผลลัพธ์: 90% ของคำขอที่ส่งมอบ
• ลูกค้าผิดหวังที่ผู้รับเหมาไม่ได้พยายามทำตาม 10% ของคำขอ
• ลูกค้าถือว่าการร้องขอ 10% ที่ยังไม่เสร็จสมบูรณ์นั้นเกิดจากการขาดความพยายามหรือความสามารถของผู้รับเหมา

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

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

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

คุณควรจะบอกพวกเขาที่จะทำให้คุณมีเวลาในการสร้างโซลูชั่น "เข็ม"

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

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

นี่คือสิ่งที่เอกสารประกอบการเขียนโปรแกรม eXtremeพูดว่า:

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

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