คุณตอบคำถามนี้อย่างไร:“ นับตั้งแต่อัปเดต…” คำถามจากลูกค้า? [ปิด]


19

นับตั้งแต่การอัปเดตผู้คนก็โทรมาเรื่อย ๆ และพูดว่า "นับตั้งแต่อัปเดต X, Y และ Z ช้ามากแย่และล้มเหลว"

สิ่งนี้เกิดขึ้นนับตั้งแต่รุ่งอรุณของการอัปเดต

คนคาดหวังอะไร Gamma มาหลังจากเบต้าและการทดสอบแกมม่าจะเปลี่ยนผู้ใช้ของเราให้กลายเป็น The Incredible Hulks ...

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

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


1
มันจะเกิดขึ้นกับฉันเสมอเมื่อใดก็ตามที่เรากลิ้ง sprint ไปที่ PROD
Gopi

1
การมีโปรไฟล์น้ำหนักเบาบางอย่างที่สามารถใช้ได้ตลอดเวลา (เป็นส่วนหนึ่งของกลยุทธ์ที่ใหญ่กว่า) "มันตลกมากข้อมูลแสดงให้เห็นว่าหน้าเว็บกำลังถูกสร้างขึ้นเร็วขึ้น 5% ตอนนี้ส่วนไหนที่รู้สึกช้าบางทีเราอาจจะทำอะไรกับมัน ... "

1
คำถามคือถ้า X, Y และ Z นั้นแย่กว่า tahn มาก่อนหรือถ้ามีปัจจัยอื่น ๆ ที่อยู่นอกเหนือการควบคุมของคุณในที่ทำงาน
เจอร์รี่

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

คำตอบ:


16

หากสิ่งนี้เกิดขึ้นกับคุณทุกครั้งที่คุณปรับใช้อาจมีข้อบกพร่องร้ายแรงในกระบวนการพัฒนาของคุณ ฉันสงสัยบางสิ่งที่ทำให้เกิดปัญหา

  1. คุณพัฒนากับฐานข้อมูลที่มีขนาดเท่ากัน (คร่าวๆ) กับการผลิตหรือไม่? ถ้าไม่เช่นนั้นคุณจะมีปัญหาเหล่านี้อยู่เสมอเพราะข้อความค้นหาที่ใช้ได้ดีกับชุดข้อมูลขนาดเล็กมักเป็นสุนัขที่มีปัญหา
  2. คุณโหลดการทดสอบใน QA หรือไม่ สิ่งที่ใช้ได้ผลดีกับการทดสอบผู้ใช้คนหนึ่งนั้นแตกต่างจากสิ่งที่จะตอบสนองกับผู้ใช้ 1,000 คนที่พยายามทำสิ่งต่าง ๆ ในเวลาเดียวกัน
  3. คุณคิดว่าการรับรู้ของผู้ใช้นั้นผิดและปฏิบัติต่อพวกเขาเหมือนพวกเขาโง่ที่จะบ่นหรือไม่? ถ้าเป็นเช่นนั้นทัศนคติของคุณจะทำให้เกิดการร้องเรียนมากขึ้นไม่ลดพวกเขา
  4. คุณทำการทดสอบได้ดีหรือไม่? คุณทดสอบคุณสมบัติการถดถอยไม่เปลี่ยนแปลงเพื่อดูว่าพวกเขาได้รับผลกระทบจากการเปลี่ยนแปลงหรือไม่ คุณสนใจไหมว่าจะต้องใช้เวลานานเท่าใดกว่าจะมีการแยงกัน
  5. คุณให้ความสนใจกับเวลาที่เป็นเวลาที่ดีสำหรับผู้ใช้เมื่อคุณปรับใช้หรือคุณปรับใช้การเปลี่ยนแปลงระบบบัญชีวันทำงานเงินเดือนและสงสัยว่าทำไมผู้ใช้โกรธที่ชะลอตัวลง?
  6. คุณมีความแตกต่างด้านสิ่งแวดล้อมระหว่าง dev และผลิตภัณฑ์หรือไม่ บางครั้งความแตกต่างที่น่ารำคาญในระบบปฏิบัติการหรือเวอร์ชันฐานข้อมูลจะทำให้เกิดปัญหาเช่นนี้เช่นกัน มันเป็นความคิดที่ดีที่จะจัดเตรียม enviromnet ที่เหมือนกับ prod อุปกรณ์ระบบปฏิบัติการเดียวกันฐานข้อมูลเดียวกันกับ dat ที่ใกล้เคียงกับ prod data มากที่สุด ใช้เพื่อทดสอบการปรับใช้ของคุณ เรียกใช้ครั้งแรกบนเซิร์ฟเวอร์นี้และมีผู้ใช้บางคนหรือผู้ทดสอบไปที่มันและทำงานผ่านการทดสอบบางอย่าง
  7. กระบวนการปรับใช้ของคุณดีแค่ไหนคุณมักพลาดขั้นตอนหรือไม่ บุคคลอื่นนอกเหนือจากนักพัฒนาสามารถเรียกใช้งานได้หรือไม่เพราะเป็นที่ชัดเจนว่ารหัสใดบ้างที่อยู่ในสาขาที่คุณกำลังปรับใช้ เราได้รับการปรับใช้โค้ดได้ดีขึ้นมากเมื่อเรามีทีมจัดการการกำหนดค่าและไม่มีใครมีสิทธิ์ที่จะนั่งกับ prod และ babysit เพื่อทำการเปลี่ยนแปลง "oopsie" การสร้างอัตโนมัติของคุณสามารถช่วยได้อย่างมาก ไม่มีใครควรคาดเดาสิ่งที่ต้องไปถึงการกระทุ้งเพราะมันควรจะไปที่ QA และจัดเตรียมฉากก่อน การเปลี่ยนแปลงฐานข้อมูลสคริปต์ก็สำคัญเช่นกัน พวกเขาแผดเสียงอยู่ในสคริปต์และอยู่ในการควบคุมซอร์สดังนั้นกระบวนการบิลด์สามารถรับมันได้โดยไม่ต้องมีคนจำเอาไว้เราต้องเปลี่ยนความยาวของคอลัมน์ B เป็น 241 จาก 50

คะแนนที่ดี: 1. ใช่ 2. บางครั้ง 3. ผ่าน 4. ไม่ใช่ / 5. ไม่ถ้าเราสามารถช่วยได้ ฉันมีคำถามสำหรับคุณ แต่ฉันอาจคิดถึงมันและโพสต์ในภายหลัง
Peter Turner

6. บางครั้ง แต่นั่นเป็นข้อบกพร่องที่ถูกต้องตามกฎหมายมักเกิดจากบางสิ่งในการอัปเดตเก่าที่ไม่ได้ทำงาน
Peter Turner

7. ใช่มันเป็นปัญหาใหญ่ - ไม่มีใครใช้ makefile ที่ฉันเขียนเว้นแต่ว่ามันจำเป็นจริงๆและนี่เป็นสาเหตุของ 60% ของความเสียหาย (PS ฉันจะทำเครื่องหมายเป็นสิทธิถ้าคุณจัดรูปแบบที่ดีกว่า)
ปีเตอร์เทอร์เนอ

นี่คือคำตอบที่ยอดเยี่ยมสำหรับ "ฉันควรดูสิ่งใดเพื่อป้องกันการเผยแพร่จากการทำลาย UX" แต่ฉันไม่แน่ใจว่าทำไม @PeterTurner ยอมรับเนื่องจากไม่ตอบคำถามจริง
Lilienthal

13

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

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

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


9

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

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

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

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


1
ใช่พวกเขาประหลาดใจ ฉันทำงานกับพยาบาลจำนวนมากที่เข้าสู่ฟอรัม PHPBB ของเราและใช้อิโมติคอน 'Bang's head with the wall' จากนั้นก็คิดว่าเราค่อนข้างร้อนแรงเมื่อเราโอน DLL หรือรันเคียวรี SQL และระบบของพวกเขา ทำงานอีกครั้งและพวกเขาไม่ต้องออกจากระบบ
Peter Turner

6

โดยส่วนตัวฉันจะนำปัญหาไปใช้ในเชิงบวก ฉันโต้ตอบตลอดเวลากับผู้ดูแลจำนวนมากและฉันก็ยังใช้รหัสด้วย

เมื่อพวกเขาดาวน์โหลดรีลีสใหม่และบอกฉันแบบนั้นฉันจะพูดแบบนี้เสมอ:

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

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

แม้ว่าเขาจะไม่ถูกต้องคุณเป็นส่วนหนึ่งของ บริษัท คุณควรใช้โอกาสนี้ในการ:

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

1
"แปลงมากกว่าลูกค้าที่ไม่มีความสุขไปเป็นลูกค้าที่ไม่มีความสุข" หรือไม่ ฉันไม่อยากทำอย่างนั้น
Lie Ryan

4

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

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

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


3

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

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

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

ขั้นตอนที่ 4 สำหรับความทุกข์ยากเหล่านี้คุณควรเรียนรู้บทเรียนที่คุณจะทดสอบในครั้งต่อไป คุณจะกลายเป็น "คนที่แต่งตัวประหลาด" ที่คัดค้านการสร้างบางอย่างเพราะ "ที่จะน่ากลัวเมื่อมี 10,000 บันทึก"

อีกเล็กน้อยที่ด้านหน้า "นี่เป็นเรื่องปกติ" ฉันทำงาน (ในทุกสิ่งที่เราดำเนินการ) โครงการที่คล่องตัวสำหรับลูกค้าภายนอก เราทำการเผยแพร่ประมาณทุกๆ 6 สัปดาห์เป็นเวลาสองหรือสามปีแล้ว และใช่มีกำหนดการวางจำหน่ายเป็นนาที เมื่อวานเราเพิ่งทำรายการหนึ่งเวลา 8 โมงเช้า และประมาณทุก ๆ การปล่อยครั้งที่ 4 หรือครั้งที่ 5 (หนึ่งครั้งหรือสองครั้งต่อปีในคำอื่น ๆ ) มีอะไรบางอย่างที่พังทลายและเราก็กระโจนสู่การปฏิบัติและทำให้มันถูกต้องอย่างรวดเร็วที่สุดเท่าที่จะทำได้ แม้ว่าเราจะทดสอบและทดสอบและทดสอบก่อนการเปิดตัว จากนั้นเราก็บอกพวกเขาว่าเกิดอะไรขึ้น "มีข้อผิดพลาดเล็กน้อยในการปรับใช้เดือนมิถุนายนที่ปล่อยให้ฟิลด์นี้ว่างเปล่า แต่เราไม่เคยสังเกตเห็นเพราะเราไม่ได้ใช้ค่าในเวลานั้นจากนั้นในการปรับใช้นี้เมื่อเราเริ่มใช้ฟิลด์สิ่งที่เกิดขึ้นนั้นว่างเปล่า ข้อความผิดพลาดที่คุณเห็นเรา ' แก้ไขข้อผิดพลาดเพื่อให้ว่างเปล่าใส่ค่าในบันทึกที่ไม่ดีและยืนยันว่าจะไม่ระเบิดอีกต่อไป คำขอโทษของเรา "หรือ" การเปลี่ยนแปลงฉุกเฉินที่คุณขอร้องเมื่อสองวันก่อนการปล่อยตัวมีผลที่ตามมาเราไม่ได้คิดและไม่ได้ทดสอบ จำได้ไหมว่าทำไมเราถึงต่อต้านการเปลี่ยนแปลงในกรณีฉุกเฉิน "ฉันอาจไม่ใช่โปรแกรมเมอร์ที่ไม่ดีที่ทำให้มันแย่ลงด้วยการอัพเดท แต่แน่นอนฉันทำสิ่งที่ไม่ดีและฉันต้องทำให้ถูกต้อง ฉันอาจไม่ใช่โปรแกรมเมอร์ที่ไม่ดีที่ทำให้มันแย่ลงด้วยการอัพเดท แต่แน่นอนฉันทำสิ่งที่ไม่ดี และฉันต้องทำให้ถูกต้อง ฉันอาจไม่ใช่โปรแกรมเมอร์ที่ไม่ดีที่ทำให้มันแย่ลงด้วยการอัพเดท แต่แน่นอนฉันทำสิ่งที่ไม่ดี และฉันต้องทำให้ถูกต้อง


0

เพียงเพื่อครอบคลุมด้านอื่น:

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

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


1
แง่มุมที่แท้จริงยกเว้นฉันคิดว่าพวกเขาไม่ได้โกหก พวกเขาเพิ่งสังเกตเห็นหลังจากการอัพเดท (ไม่ว่าจะด้วยเหตุผลทางจิตวิทยาใด) จากนั้นก็ข้ามไปสู่ข้อสรุป - ผู้ใช้เป็นผู้เชี่ยวชาญจริง ๆ เมื่อพูดถึงเรื่องนี้ :-)
Martin Ba
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.