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

มีคำถามใช่ / ไม่ใช่และทำไม?

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

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

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

ฉันเป็นนักพัฒนาระบบคนที่ 3 หรือ 4 (นักพัฒนาคนสุดท้ายออกจากงาน) และนั่นอาจเป็นเหตุผลที่ลูกค้าคาดหวังว่าจะมีความเข้าใจด้านนักพัฒนา

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

ที่จริงฉันกำลังคิดที่จะเลิกงาน แต่ยังไม่ได้เนื่องจากฉันไม่แน่ใจว่าใครถูกและผิด

ถ้ามันเป็นงานของคุณที่จะเข้าใจมันเป็นหน้าที่ของคุณที่จะถามคำถามจนกว่าคุณจะทำ

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

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

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

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

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

ในความคิดของทั้งสอง (ลูกค้าและนักพัฒนา) ต้องได้รับเดียวกันความเข้าใจในปัญหาและการแก้ไขของตน

หากคุณไม่เข้าใจคำขอคุณไม่สามารถสร้างโซลูชันได้

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

ฉันทำงานเป็นทีมที่มีหนึ่งคนที่สามารถตอบคำถามทางธุรกิจได้ นี้เป็นเจ้าของธุรกิจเป็นทั้งสมาชิกคนหนึ่งของฉันทำงานพัฒนา บริษัท ที่รู้ธุรกิจของลูกค้าหรือสมาชิกของทีมลูกค้า

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

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

มีสาเหตุบางประการที่ผู้จัดการโครงการอาจเลือกที่จะไม่ให้คุณถามคำถาม:

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

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

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

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

ฉันเชื่อว่าวิธีการที่เน้นลูกค้าเป็นวิธีที่จะทำสิ่งต่าง ๆ มันเป็นรูปแบบธุรกิจที่ผ่านการทดลองและทดสอบแล้ว

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

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

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

ซึ่งจะขึ้นอยู่กับข้อมูลใหม่ในความคิดเห็นของคำถามเดิม

คำแถลงว่า

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

มาจากหัวหน้าโครงการ เหตุผลที่ระบุไว้คือ

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

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

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

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

คนเหล่านี้ต้องการอะไร ??? "

ถามบางสิ่งเช่น

ในวรรคที่ 17 ของเอกสารข้อกำหนดมันบอกว่า foobar จะต้องทำให้เป็นน้ำแข็ง อันไหนของ frozzles ทั้งสามนี้ที่อ้างถึง? "

หรือถ้าความต้องการนั้นถูกเขียนแย่มากจนคุณไม่สามารถถอดรหัสได้ให้บอกเขาว่า

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

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

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

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

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

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

• ขนาดของทีม
• มาตรฐานของ บริษัท
• วิธีที่เจ้านายใช้ในการทำงาน
• ความเชี่ยวชาญที่แตกต่างกันในหมู่สมาชิกในทีม

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

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