ใน Scrum นักพัฒนาซอฟต์แวร์ควรพูดคุยกับลูกค้าโดยตรง (เลี่ยงผ่าน PO) หรือไม่

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

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

มีวิธีที่ดีที่สุดในการต่อสู้?

scrum communication product-owner

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

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

— Patrick Hughes

"เมื่อไหร่จะเห็นได้ชัดว่าเป็นทางออกที่เร็วกว่า ... " แค่ต้องการชี้ให้เห็นอย่างชัดเจน: เร็วกว่านั้นไม่จำเป็นต้องดีกว่า

— Eric King

คำตอบ:

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

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

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

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

— หมอบราวน์
แหล่งที่มา

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

— Giorgio

+1 หากการต่อสู้อย่างว่องไวผู้เชี่ยวชาญด้านธุรกิจน่าจะเป็นส่วนหนึ่งของทีมและพร้อมใช้งานต่อไป ...

— Marjan Venema

ขวา. PO ไม่ควรเป็นผู้รักษาประตู ในที่สุด PO จะเป็นผู้รับผิดชอบต่อผลิตภัณฑ์

— Gort the Robot

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

— tizenegy

@Giorgio: IMHO "Agile development" เป็นเพียงคำศัพท์ที่รวมเอานิสัยที่ดีบางอย่างที่เก่ากว่าคำศัพท์ไว้และไม่ได้ จำกัด ตัวเอง

— Doc Brown

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

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

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

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

— jwenting

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

— Ewan

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

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

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

"บรรทัดไม่สามารถสั้นกว่าการให้ผู้ใช้ในอนาคตนั่งอยู่ข้างๆคุณขณะที่เข้ารหัส :)": ไม่ว่าจะดีหรือไม่

— Giorgio

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

— jwenting

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

— Giorgio

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

— tizenegy