นักออกแบบ UX ทำงานหนึ่ง Sprint ข้างหน้า

นักออกแบบ UX ของเรามักจะมีเรื่องราวใน Sprint X ที่ผู้พัฒนาจะนำไปใช้ใน Sprint X + 1 (นักออกแบบ UX และผู้พัฒนา / นักทดสอบอยู่ในทีมเดียว) ฉันคิดว่ามันสมเหตุสมผลเพราะถ้าคุณไม่มีภาพจำลองหน้าจอและข้อมูลจำเพาะที่ชัดเจนคุณไม่สามารถประมาณงานระหว่างการวางแผน Sprint ได้

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

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

อย่างไรก็ตามใน Scrum คุณควรจะมีเรื่องราวของผู้ใช้ที่ให้คุณค่ากับผู้ใช้เท่านั้น

ค่าไม่ได้วัดเฉพาะในบรรทัดของรหัสที่สามารถแก้ไขได้

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

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

ข้อเสียเปรียบหลักคือ:

1. คุณกำลังไปป์ไลน์: หากนักออกแบบของคุณมาสายผู้พัฒนาของคุณจะไม่ทำงาน หากนักพัฒนาของคุณมาสายนักออกแบบของคุณจะทำงานซ้ำมากกว่าหนึ่งครั้งในที่สุด มันไม่ได้เป็นสถานการณ์ที่มีเสถียรภาพ - มันไม่ยั่งยืน

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

3. นักออกแบบ UX ของคุณกำลังตัดสินใจล่วงหน้าโดยไม่เกี่ยวข้องกับนักพัฒนา คุณไม่มีข้อมูลเชิงลึกที่เป็นประโยชน์และเพิ่มความเสี่ยงที่การออกแบบผิดพลาดหรือไม่สมจริง นี่เป็นเรื่องปกติเนื่องจากการออกแบบ UX ไม่ใช่แบบฝึกหัด "นามธรรม" - มันจะต้องสร้างขึ้นมาจากลักษณะของแอปพลิเคชัน (รวมถึงสิ่งที่เป็นไปได้ / แนะนำให้ทำหรือไม่ใช้เทคนิค)

4. การแยกหรือตัดการพัฒนาของนักพัฒนาไม่ใช่วิธีที่ยั่งยืนในการดำเนินโครงการ

5. นักออกแบบไม่ได้ให้คุณค่า: นั่นหมายความว่ามันเป็นเรื่องยากหากไม่สามารถจัดลำดับความสำคัญของงานได้อย่างถูกต้อง โดยทั่วไปงานของนักพัฒนาจะถูกจัดลำดับความสำคัญโดยใช้ข้อกังวลค่านิยมความเป็นไปได้ในการวิ่งครั้งต่อไปจำนวนความพยายาม มีการเจรจาและเปลี่ยนแปลงเรื่องเวลาเป็นจำนวนมากเพื่อให้ "พอดี" หรือเนื่องจากการสนทนาที่มีประโยชน์: หากมีการเปลี่ยนแปลงใด ๆ ใน UI (และคุณสามารถสันนิษฐานได้ว่ามันไม่ได้เป็นเพียงรายละเอียดการนำไปใช้) สิ่งที่คุณทำ กับเรื่องราวหรือไม่ คุณไม่สามารถเล่นได้อีกต่อไป

6. คุณกำลังสมมติว่าเรื่องราวที่เหมาะสมในการวนซ้ำหนึ่งครั้งสำหรับนักออกแบบนั้นเหมาะกับการวนซ้ำหนึ่งครั้งสำหรับนักพัฒนา: คุณจะแยกเรื่องราวอย่างไรเพื่อให้สมมติฐานนี้ถูกต้อง

ฉันชอบมันด้วยเหตุผลสองประการ:

1. ดูเหมือนว่าจะทำงานให้คุณ; เป็นการยากที่จะโต้แย้งกับความสำเร็จ!
2. ทีม UX นำเรื่องราวและเริ่มต้นบทสนทนาก่อน - และบทสนทนาเป็นประเด็นสำคัญ

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

ทีม UX ไม่ได้ผลิตผลิตภัณฑ์ที่สามารถนำกลับมาใช้ซ้ำได้และทีมต่อสู้ไม่สามารถผลิตฟังก์ชันตามแนวตั้งได้เนื่องจากไม่มีทักษะที่จำเป็นทั้งหมด เหล่านี้เป็นความผิดปกติ

Sklivvz ได้เขียนบทความที่ยอดเยี่ยมเกี่ยวกับปัญหาที่ความผิดปกติข้างต้นอาจนำไปสู่ โดยสรุปฉันไม่คิดว่าคุณกำลังฝึกการต่อสู้

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

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

มีสองประเด็นที่นี่ประเด็นหนึ่งเกี่ยวกับการออกแบบที่เน้นผู้ใช้เป็นศูนย์กลางและอีกประเด็นเกี่ยวกับการจัดตำแหน่ง sprint

ข้อแรก : เรื่องราวของผู้ใช้ควรสอดคล้องกับความต้องการของผู้ใช้ไม่ใช่แค่งานค้าง เรื่องราวของ UX นั้นต้องมีคุณค่าที่ชัดเจนสำหรับผู้ใช้ สิ่งนี้ไม่ต้องการข้อมูลจำเพาะที่สมบูรณ์และข้อความสั้น ๆ เช่น

"ผู้ใช้จะสามารถเข้าถึงกิจกรรมบัญชีได้ง่ายขึ้นในหน้าเดียวแทนที่จะแบ่งระหว่างหลายหน้า"

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

ที่สอง : การจัดตำแหน่ง Sprint UX ออกแบบคุณสมบัติใน sprint X ที่ผู้พัฒนาใช้ใน spring X + 1 ในทางปฏิบัติสิ่งนี้เกิดขึ้นในร้านค้าหลายแห่งและบางครั้งมันอาจเป็นเหมือนการนำไปใช้ในการวิ่ง X + 2 หรือ X + 3 ด้วยทีมงานที่มีประสบการณ์และมีประสบการณ์ มันจะกลายเป็นความท้าทายถ้าคุณมีทีมใหม่หรือสมาชิกใหม่ที่ไม่คุ้นเคยกับชุดทักษะความชอบนิสัยสไตล์การทำงานและแนวโน้มของสมาชิกคนอื่น ๆ ในทีม หากคุณทำงานร่วมกันมาไม่ถึง 6 เดือนนี่น่าจะเป็นปัญหา

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

หนึ่งในปัญหาที่เป็นไปได้ที่ฉันเห็นคือใน Scrum ขอบเขตของการวิ่ง N + 1 จะถูกกำหนดโดยปกติก่อนที่จะเริ่ม ดังนั้นคุณจะทำ UX สำหรับการวิ่ง N + 1 เรื่องราวใน sprint N ได้อย่างไรก่อนที่คุณจะรู้ว่าเรื่องราวใดจะอยู่ในขอบเขต หากคุณตัดสินใจที่จะแก้ไขขอบเขตของการวิ่ง N + 1 ที่จุดเริ่มต้นของการวิ่ง N คุณจะสูญเสียความยืดหยุ่น

อย่างไรก็ตามใน Scrum คุณควรจะมีเรื่องราวของผู้ใช้ที่ให้คุณค่ากับผู้ใช้เท่านั้น ในกรณีของเราเรื่องราวการออกแบบ UX ไม่ได้ให้คุณค่าเช่นนั้น

วิธีที่ฉันเห็นพวกเขาให้คุณค่ากับผู้ใช้เป็นจำนวนมาก สิ่งคือ: ผู้ใช้ของพวกเขาไม่ใช่ผู้ใช้ขั้นสุดท้ายของ บริษัท ผู้ใช้ของพวกเขาคือทีมพัฒนาที่จะใช้คุณสมบัติที่ sprint X + 1

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

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

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

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

ไม่มีอะไรเลวร้ายจริงๆที่นั่นมีเพียงกระบวนการที่แตกต่างจากที่คุณบอกไว้