นักพัฒนาคาดหวังรายละเอียดเกี่ยวกับเรื่องราวของผู้ใช้ได้มากน้อยเพียงใด

ข้อเสียเปรียบที่ใหญ่ที่สุดของการพัฒนาแบบเปรียวที่ฉันเคยพบคือคนที่ไม่ได้มีส่วนร่วมในการพัฒนามุ่งเน้นไปที่มนต์ที่เรื่องราวของผู้ใช้ (3-10 วันในอุดมคติของคน) ไม่ควรมีมากกว่า 1-3 ประโยคเช่น:

ในฐานะลูกค้าฉันสามารถใช้การค้นหาข้อความอิสระเพื่อหาผลิตภัณฑ์ที่ฉันกำลังมองหา

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

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

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

• เราต้องการตัวดำเนินการบูลีนเช่น AND และ OR
• เราต้องการคำทั้งหมดคลุมเครือ
• เราจำเป็นต้องค้นหาด้วยคำเดียวเช่นเดียวกับวลี
• เราไม่ต้องการค้นหาผลิตภัณฑ์ที่ตรงตามเกณฑ์ X, Y และ Z
• เราต้องการเรียงลำดับผลลัพธ์ ผู้ใช้สามารถเลือกเกณฑ์การเรียงในกล่องคำสั่งผสมพร้อมตัวเลือก a, b และ c

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

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

บางครั้งผู้จัดการอาจหารายละเอียดทางเทคนิคเช่น "เราต้องการค้นหา Lucene" แต่พวกเขาไม่ต้องการคิดว่าพวกเขาต้องการค้นหาเฉพาะชื่อผลิตภัณฑ์หรือคำอธิบายผลิตภัณฑ์ บางครั้งฉันคิดว่าพวกเขาขี้เกียจ;)

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

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

คุณมีข้อมูลอ้างอิงบ้างไหม?

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

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

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

เสียงเหมือนปัญหาแรกคือคุณไม่ควรใช้การประมาณเวลากับเรื่องราวของผู้ใช้ คุณควรจะเล่าเรื่องและใช้ "คะแนนเรื่องราว" ซึ่งเป็นค่าประมาณความซับซ้อนโดยทั่วไปจาก 1 ถึง INFINITY 1,2,3,5,8,13,20 ... (ทุกองค์กรมีกฎของตัวเอง) โดยทั่วไปแล้วพวกเขาจะนำไปใช้เช่น:

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

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

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

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

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

แน่นอนมีองค์ประกอบของ "การฝึกอบรม PMs" ที่นี่ พวกเขาต้องเรียนรู้ว่าเรื่องราวที่คลุมเครือนั้นส่งผลให้เกิดเรื่องราวขนาดใหญ่และหากพวกเขากำหนดเรื่องราวให้คลุมเครือเพื่อให้ได้สิ่งที่ต้องการพวกเขาต้องทำอีกครั้ง

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

นี่ไม่ใช่ระบบเกม ... นี่ใช้ได้อย่างสมบูรณ์ หากคุณไม่ทราบว่าเป็น "A" หรือ "B" คุณประมาณว่าจะให้ค่าประมาณที่ใหญ่ที่สุดเพื่อครอบคลุมตูดของคุณหรือไม่

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

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

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

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

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

ลูกค้า

ฉันต้องการค้นหาผลิตภัณฑ์

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

• ค้นหาผลิตภัณฑ์
• จัดเรียงผลลัพธ์
• กรองผลการค้นหา

นักพัฒนา ฉันได้รับเรื่องราวของผู้ใช้จากผู้จัดการผลิตภัณฑ์ ฉันได้วิเคราะห์เรื่องราวของผู้ใช้แต่ละคนและสร้างรายการงานสำหรับเรื่องราวของผู้ใช้แต่ละคน

• ค้นหาผลิตภัณฑ์
  1. ภารกิจที่ 1: การเปลี่ยนแปลงฐานข้อมูล
  2. ภารกิจ 2: การเปลี่ยนแปลงฝั่งเซิร์ฟเวอร์
  3. ภารกิจ 3: การเปลี่ยนแปลงส่วนหน้า

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

เรื่องราวของผู้ใช้ของเราได้รับการวิเคราะห์และปรับปรุงตามลำดับต่อไปนี้ (แน่นอนว่ามีรูปแบบบางอย่าง):

ศูนย์ช่วยเหลือ -> เจ้าของผลิตภัณฑ์ -> ผู้จัดการผลิตภัณฑ์ -> ฝ่ายขายเป้าหมาย (นักพัฒนาอาวุโส qa นำไปสู่ ​​ฯลฯ ) -> นักพัฒนา

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

ฉันไม่ได้บอกว่านี่เป็นวิธีที่ถูกต้องในการทำสิ่งต่าง ๆ แต่มันทำงานได้ดีภายในองค์กรของเรา