จัดการกับความคาดหวังของผู้ใช้ที่ไม่ต้องการทำการทดสอบผู้ใช้
ฉันมีผู้ใช้จากแผนกภายในที่ร้องขอการเปลี่ยนแปลงมากมายหรือชี้ให้เห็นข้อบกพร่องในเว็บไซต์ของ บริษัท ของเรา เรามีความสัมพันธ์ที่แน่นแฟ้นและแน่นแฟ้นมาก แต่เมื่อไม่นานมานี้พวกเขารู้สึกไม่พอใจที่ต้องทดสอบการเปลี่ยนแปลงเหล่านี้ พวกเขาถือว่าเสียเวลา อีเมลล่าสุดที่ฉันได้รับยังมีบรรทัดเล็ก ๆ นี้:
เมื่อคุณนำรถเข้าอู่ซ่อมรถคุณจะไม่ได้รับการขอให้ทดสอบเพื่อให้แน่ใจว่ารถใช้งานได้
ปัญหาคือเราทำตามแบบจำลองที่เว้นแต่การเปลี่ยนแปลง / แก้ไขข้อบกพร่องจะเป็นกรณีฉุกเฉินหรือใช้ขั้นตอนการเขียนมาตรฐาน (เช่นการเปลี่ยนแปลงพารามิเตอร์มาตรฐาน) เราต้องการการทดสอบ / การยืนยันจากผู้ใช้ก่อนจึงจะสามารถเผยแพร่การเปลี่ยนแปลงหรือแก้ไขข้อบกพร่องได้
วิธีใดเป็นวิธีที่ดีที่สุดในการจัดการความคาดหวังของผู้ใช้และยังคงให้การทดสอบเสร็จสมบูรณ์หรือได้รับการยืนยันจากพวกเขา
คำตอบ
ไม่มีคำตอบที่เป็นสากล สมมติว่าผู้ใช้รายงานการสะกดผิดบนหน้าเว็บ "มันบอกว่าเต๋ที่มันควรจะพูดว่า" คุณจะไม่ต้องรอการปรับใช้โปรแกรมฟิกซ์เดียวนี้เพื่อรอให้ผู้ใช้ยอมรับว่าคุณแก้ไขการพิมพ์ผิด
ตอนนี้สมมติว่าผู้ใช้ถาม (เหมือนครั้งหนึ่งของฉันเคยทำ) ให้ปุ่มเป็น "สองเฉดสีฟ้าอ่อนกว่า" มันสมเหตุสมผลแล้วที่จะขอให้พวกเขายืนยันว่าคุณเดาถูกต้องว่าหมายถึงอะไรบนโลกใบนี้ คำพูดเป็นกุญแจสำคัญที่นี่แม้ว่า: "โปรดทดสอบการแก้ไขและอนุมัติ" หมายความว่าคุณไม่แน่ใจว่าคุณทำถูกต้องและอาจฟังดูเล็กน้อย "อยู่ที่ตัวคุณหากมีอะไรผิดพลาดในภายหลัง" เป็นมิตรกว่า "คุณช่วยบอกเราได้ไหมว่าคุณชอบสีใหม่" หรือ "ตรวจสอบให้แน่ใจว่านั่นคือสิ่งที่คุณต้องการ" หรือแม้แต่ "ตรวจสอบให้แน่ใจว่านักพัฒนาของฉันเข้าใจคุณอย่างถูกต้อง" ไม่เพียง แต่แม่นยำมากขึ้นเท่านั้น แต่ยังมีคำอธิบายว่าทำไมนักพัฒนาจึงถาม สำหรับงานจากลูกค้า
คุณต้องแน่ใจด้วยว่าลูกค้าเข้าใจว่าคุณทดสอบงานของคุณและคุณได้เขียนโค้ดว่าคุณหมายถึงอะไร สิ่งที่ลูกค้ากำลังทดสอบคือคุณเข้าใจคำขอ ดังนั้นพวกเขาจึงขอให้คุณเพิ่มคอลัมน์ลงในรายงานและคุณลืมถามว่าต้องการให้ไปที่ใด: เมื่อคุณส่งมอบให้คุณพูดว่า "ฉันเพิ่มแล้วในตอนท้าย" หรือ "ฉันเพิ่มไว้ถัดจากวันที่สั่งซื้อ" แล้วขอให้พวกเขายืนยัน นั่นก็โอเค
แน่นอนว่าทั้งหมดนี้คือ "การทดสอบ" ดูแล้วรับรองว่าต้องชอบ หากต้องการใช้การเปรียบเทียบหากคุณนำรถของคุณไปทาสีฟ้าคุณจะไม่ขับรถสีแดงสดโดยไม่พูดอะไรเลย ดังนั้นสำหรับทุกสิ่งยกเว้นกรณีฉุกเฉินที่แน่นอนคุณทำการแก้ไขหรือเพิ่มสิ่งใหม่คุณวางไว้ในการจัดเตรียมเพื่อให้พวกเขาดูและยืนยันว่ามันดีแล้วคุณก็วางมันไว้ การใช้วลี " ยืนยันว่าดี " ทำสิ่งที่คุณกำลังมองหาได้มาก:
- มันมีข้อสันนิษฐานว่าคุณได้ทำในสิ่งที่ถูกต้อง "มองหาความผิดพลาด" ประกอบด้วยข้อสันนิษฐานว่ามีความผิดพลาด
- ไม่ใช้คำกริยาที่ลูกค้าจ่ายเงินให้คุณทำเช่น "test"
- ไม่ใช้คำกริยาที่ทำให้ลูกค้ากังวลเกี่ยวกับการรับผิดเช่น "การยอมรับ"
เรามักจะเพิ่มรายละเอียดที่เฉพาะเจาะจงลงในคำขอทดสอบของเรา ยืนยันว่าการจัดรูปแบบในคอลัมน์ใหม่เป็นสิ่งที่คุณต้องการ ยืนยันว่านักพัฒนาได้เลือกขนาดตัวอักษรที่ถูกต้อง โดยพื้นฐานแล้วคุณต้องตัดสินใจด้วยตัวเองเพราะไม่ได้ระบุไว้และด้วยเหตุผลบางประการที่คุณไม่ได้ถามก่อนที่จะทำบอกพวกเขาและขอให้พวกเขายืนยัน สิ่งใดที่คลุมเครือและคุณไม่ได้ชี้แจงก่อนที่จะเขียนโค้ดโปรดชี้ให้เห็นตอนนี้
วิธีใดเป็นวิธีที่ดีที่สุดในการจัดการความคาดหวังของผู้ใช้รายนี้
ทำความเข้าใจกับปัญหาอย่างถี่ถ้วนก่อนที่จะแก้ไขแล้วทดสอบอย่างมืออาชีพ
คุณไม่ควรไว้วางใจผู้ใช้ปลายทางสำหรับการทดสอบควรทำโดยมืออาชีพที่มีส่วนได้เสียเพื่อให้แน่ใจว่าไม่มีข้อผิดพลาดก่อนที่จะเผยแพร่
คุณต้องแสดงขั้นตอนการยอมรับผู้ใช้ว่าเป็นสิ่งที่เป็นประโยชน์ต่อลูกค้าไม่ใช่คุณ
คุณได้พูดคุยเกี่ยวกับประโยชน์ที่มีต่อ บริษัท ของคุณ ("เราต้องการการทดสอบผู้ใช้เพื่อยืนยันว่าการเปลี่ยนแปลง / ข้อบกพร่องทำงานตามที่ผู้ใช้คาดหวัง", "เราไม่ได้รับอนุญาตให้เผยแพร่สดโดยไม่มีการตรวจสอบผู้ใช้") ไม่น่าแปลกใจที่ลูกค้าจะรู้สึกเหมือนกำลังทำงานให้คุณ หลังจากนั้น (ในความคิดของพวกเขา) คุณล้มเหลวในการตอบสนองความต้องการของพวกเขาในตอนแรกโดยปล่อยสิ่งที่ไม่ใช่สิ่งที่พวกเขาต้องการ!
คุณสามารถเริ่มต้นด้วยการอธิบายว่านี่เป็นส่วนหนึ่งที่สำคัญของกระบวนการที่เป็นประโยชน์กับพวกเขา ลองนึกดูว่าจะแย่กว่านี้มากแค่ไหนหากคุณปล่อย "การแก้ไข" แต่ก็ยังไม่ได้รับการแก้ไขหรือทำงานในแบบที่พวกเขาต้องการ! ลองนึกดูว่าคุณทำให้มันแย่ลงโดยไม่ได้ตั้งใจ!
มีความผิดพลาดอย่างชัดเจนในการสื่อสารที่ทำให้เกิดข้อบกพร่องในตอนแรก หากคุณเข้าใจอย่างถ่องแท้ว่าพวกเขาต้องการอะไรคุณจะต้องทดสอบอย่างสมบูรณ์แบบกับความคาดหวังเหล่านั้นด้วยตัวคุณเองและปลดปล่อยสิ่งที่ ... สมบูรณ์แบบ พวกเขาพบข้อบกพร่อง นั่นหมายความว่าไม่ว่าคุณจะมีกระบวนการใดในการขอคุณสมบัติและคุณต้องจัดหาสิ่งนั้นพลาดไป มันไม่สมเหตุสมผลที่จะคิดว่ากระบวนการรายงานข้อบกพร่องและได้รับการแก้ไขจะไม่พลาดบางอย่างเช่นกัน สิ่งที่ควรทำคือตรวจสอบอีกครั้ง: "เราคิดว่าตอนนี้เราทำได้ตามที่คุณต้องการแล้วใช่ไหม"
โดยเฉพาะอย่างยิ่งหากพวกเขาจ่ายเงินสำหรับการเปลี่ยนแปลงหรือการแก้ไขใด ๆ เหล่านี้ นี่เป็นโอกาสสำหรับพวกเขาที่จะมั่นใจได้ว่าพวกเขาจะได้รับเงินอย่างคุ้มค่า หากคุณปล่อยของ แต่ยังไม่เป็นไปตามที่พวกเขาต้องการคุณจะต้องทำตามขั้นตอนทั้งหมดอีกครั้งและเรียกเก็บเงินอีกครั้ง จะดีกว่าไหมหากพวกเขายืนยันการแก้ไขก่อนที่จะปล่อยดังนั้นพวกเขาจึงจ่ายเพียงครั้งเดียว
ไม่ว่าในกรณีใดก็ตามจำเป็นต้องอธิบายให้พวกเขาฟังว่าเป็นโอกาสเชิงบวกสำหรับพวกเขาที่จะได้รับข้อมูลไม่ใช่ระบายและเรียกร้องให้ใช้เวลาโดยเปล่าประโยชน์
FWIW ฉันคิดว่ามันเป็นความคิดที่ดีที่จะโต้แย้งโดยการเปรียบเทียบเหมือนกับคำตอบอื่น ๆ เพราะคุณพูดถึงสิ่งที่ไม่ใช่ปัญหาที่คุณควรพูดถึง ถึงกระนั้นถ้าฉันเอารถไปซ่อมยางแบนฉันจะต้องดูยางก่อนขับออกไปเพื่อให้แน่ใจว่ามันดูเหมือนจะได้รับการแก้ไขแล้วจริงๆ มิฉะนั้นถ้าฉันเพิ่งเริ่มขับรถและสังเกตเห็นว่ามันแบนไปตามถนนอู่ซ่อมรถอาจบอกว่าพวกเขาทำงานได้ถูกต้องและยางเส้นใหม่จะต้องแบนหลังจากที่ฉันออกไป
เมื่อคุณนำรถเข้าอู่ซ่อมรถคุณจะไม่ได้รับการขอให้ทดสอบเพื่อให้แน่ใจว่ารถใช้งานได้
อ่าตลกดี เมื่อฉันนำรถไปซ่อม (และไม่มีการเปลี่ยนแปลงเว็บไซต์) ซึ่งอาจรวมถึงสิ่งของที่พบในการซ่อมบำรุงเช่นลูกปืนบนยางไม่กลมทั้งหมด ...
... ทุกครั้งที่เกิดขึ้นเมื่อฉันไปรับรถฉันถูกถามในการทดลองขับกับตัวแทนของช่าง (ตัวแทนเป็น: พนักงานแนวหน้าเพราะไม่ใช่ภาพเล็ก ๆ ที่แยกกลไกออกจากลูกค้า)
ดูเหมือนว่าลูกค้าของคุณจะคิดว่าการเปลี่ยนแปลงเว็บไซต์กำลังให้บริการ กรณีนี้ไม่ได้. การให้บริการจะเป็นการแก้ไขไลบรารี การเปลี่ยนแปลงนั้นคล้ายกับการซ่อมแซมหรืออัปเกรดรถยนต์ และการแบ่งประเภทที่ไม่มีการทดสอบไดรฟ์ในกรณีเหล่านั้นผิดอย่างสิ้นเชิงหรือบ่งบอกถึงการใช้งานของร้านช่างเครื่องระดับล่างจากประสบการณ์ของฉัน
คุณควรพูดคุยกับลูกค้าเกี่ยวกับเรื่องนี้ นอกจากนี้เกี่ยวกับข้อเท็จจริงที่ว่าการอัปเกรดเป็นขั้นตอน UI ของเว็บไซต์อาจไม่ได้ผลตามที่ลูกค้าคาดหวังไว้ ไม่ใช่ว่าคุณทำผิดพลาด - แต่ฉันไม่สามารถนับจำนวนครั้งที่คำขอเปลี่ยนแปลงตามด้วย "อาไม่เป็นไปตามที่ฉันคาดไว้" แม้ว่าการเปลี่ยนแปลงจะเป็นไปตามคำสั่งก็ตาม การตรวจจับในช่วงต้นเป็นส่วนหนึ่งของขั้นตอนการทำงาน
ฉันขอแนะนำให้คุณพูดคุยกับพวกเขาและอธิบายว่าการเปรียบเทียบของพวกเขาเป็นความเข้าใจผิดที่ชี้ให้เห็นมากขึ้นเกี่ยวกับการใช้ร้านกลศาสตร์ระดับล่าง;)
ฉันมีความเห็นว่าคุณไม่ควรบอกให้ผู้ใช้ทดสอบข้อบกพร่องที่พวกเขาชี้ให้คุณเห็นหรือคุณสมบัติที่พวกเขาร้องขอให้คุณ / บริษัท ของคุณเลือกที่จะใช้งานเว้นแต่คุณจะไม่สามารถสร้างจุดบกพร่องขึ้นมาใหม่ได้ จุดจบของคุณไม่ว่าจะด้วยเหตุผลใดก็ตาม
เมื่อพวกเขารายงานข้อบกพร่องให้คุณทราบก่อนอื่นคุณควรสร้างจุดบกพร่องใหม่ก่อนที่จะดำเนินการแก้ไขเพื่อที่คุณจะได้รู้ว่าคุณได้แก้ไขข้อบกพร่องนั้นแล้ว ... จากนั้นเมื่อมีการปรับใช้การแก้ไขข้อบกพร่องคุณสามารถสื่อสารกับผู้ใช้ว่า มีการปรับใช้การแก้ไข
หากพวกเขาขอคุณสมบัติใหม่คุณ / บริษัท ของคุณควรได้รับความต้องการ / ความคาดหวังทั้งหมดล่วงหน้าก่อนที่จะดำเนินการใด ๆ เพื่อนำคุณลักษณะนี้ไปใช้จริง อย่าเดาสุ่มสี่สุ่มห้าว่าพวกเขาต้องการอะไรนำไปใช้แล้วขอให้พวกเขาทดสอบให้คุณ
คุณพูดว่า:
ปัญหาคือเราทำตามแบบจำลองที่เว้นแต่การเปลี่ยนแปลง / แก้ไขข้อบกพร่องจะเป็นกรณีฉุกเฉินหรือใช้ขั้นตอนการเขียนมาตรฐาน (เช่นการเปลี่ยนแปลงพารามิเตอร์มาตรฐาน) เราต้องการการทดสอบ / การยืนยันจากผู้ใช้ก่อนจึงจะสามารถเผยแพร่การเปลี่ยนแปลงหรือแก้ไขข้อบกพร่องได้
ทำไมทำตามแบบนั้น โมเดลนี้มีจุดมุ่งหมายเพื่อบรรลุข้อกำหนด / เป้าหมายใด ใครเป็นคนสร้าง?
หากแนวคิดคือการเปิดโอกาสให้ผู้มีส่วนได้ส่วนเสียตรวจสอบวิธีแก้ปัญหาให้ตั้งเวลาในขั้นตอนการตรวจสอบผู้มีส่วนได้ส่วนเสียและหากผู้มีส่วนได้ส่วนเสียไม่ได้ตรวจสอบวิธีการแก้ปัญหา (ที่คุณได้ทดสอบ) ใน 2 สัปดาห์ให้ปิดปัญหา / รายการงานตาม "เสร็จสมบูรณ์".
หากแนวคิดคือการมอบหมายการทดสอบให้กับผู้มีส่วนได้ส่วนเสียฉันคิดว่าคุณจำเป็นต้องยกระดับเรื่องนี้ขึ้นในแผนผังองค์กรเนื่องจากผู้มีส่วนได้ส่วนเสียรายนี้ดูเหมือนจะไม่เชื่อว่าหน้าที่การงานของพวกเขารวมถึงการทดสอบที่คุณต้องการให้ทำ
หากโดยทั่วไปคุณเชื่อว่าคุณอยู่ในหน้าเดียวกันกับผู้รายงานปัญหาเกี่ยวกับปัญหาที่พวกเขารายงานกลยุทธ์การหมดเวลาดูเหมือนจะเป็นหนทางที่จะไป