UX có nên là một phần của Nhóm Scrum không?

“Chúng tôi vẫn đang tuyển dụng một UX cho miền của bạn.” Đó là một câu đáng sợ khi gia nhập một đội mới. Nó ngụ ý rằng cần phải có, do đó có một khoảng trống về kỹ năng cần thiết bây giờ hoặc ngày mai và giải pháp tập trung vào một người.

Đồng thời, nó không phải là một tình huống cá biệt. Nhiều đội tự hỏi mình Kiến trúc có cần phải là một phần của đội không? có cần một DBA trong nhóm không? những gì về một nhà phân tích kinh doanh? hay Nhà khoa học dữ liệu? Vào thời điểm và thời đại mà các chuyên môn ngày càng trở nên quan trọng, làm thế nào để chúng ta kết hợp khái niệm về sự xuất sắc về kỹ năng cho đội toàn ngăn xếp?

Thí nghiệm kéo dây của Ringelmann

Bạn có thể đã nghe nói về hiệu ứng Ringelmann. Ý tưởng đằng sau nghiên cứu này là một khi bạn thêm đủ người vào một nhóm, hiệu quả sẽ giảm xuống. Một số con số gợi ý rằng nếu bạn cần 8 người cho một nhiệm vụ, bạn sẽ đạt được hiệu suất khoảng 50% so với một nhóm 1 (hmm, đó có phải là một nhóm không?)

Những lý do chính cho điều đó là: (1) mất động lực “chắc chắn ai đó sẽ làm điều này….” và (2) mất phối hợp “Tôi đã chờ đợi…”

Vì vậy, đội ngũ chuyên gia khổng lồ không phải là điều chúng tôi muốn, nhưng chúng tôi cũng cần chuyên môn cá nhân có thể không tồn tại ở tất cả các thành viên trong nhóm. Đây là lý do tại sao nhiều tổ chức đấu tranh để thuê đủ chuyên gia, nhưng có một vấn đề tiềm ẩn với điều đó.

Có, chúng tôi làm Scrum và…

Gunther Verheyen đã đi tiên phong trong khái niệm Scrum, vâng và .. và cảm giác rất phù hợp tự nhiên với vấn đề mà một trong những người sáng lập Scrum đã giải thích trong lá thư của mình “ Scrum rất khó và gây khó khăn. ”Bởi vì nó khó, nó có nghĩa là sẽ rất khó khăn để đến được đó, nó đòi hỏi sự kiểm tra và điều chỉnh và tuyến đường có thể quan trọng hơn trạng thái cuối.

Nhúng UX vào Scrum có nghĩa là bạn có thể mong đợi nhiều lợi ích hơn, UX chặt chẽ hơn được tích hợp vào quy trình phát triển của bạn. Nhưng điều đó trông như thế nào?

Nếu bạn không làm UX nhưng đang xây dựng sản phẩm thì sẽ rất khó để mang lại giá trị cho người dùng cuối và chúng tôi sẽ coi đây là “thời kỳ đen tối” của sự phát triển sản phẩm. Tôi thậm chí không đưa nó vào bảng xếp hạng, vì điều đó.

Thông thường hơn, chúng ta thấy UX được thực hiện bên ngoài nhóm Scrum. Đôi khi bởi các cơ quan thiết kế, đôi khi bởi một đội UX hoặc một cái gì đó tương tự. UX được coi là thứ mà một người cụ thể làm. Đó là một vai trò chuyên gia, và thường họ rất giỏi. Tất nhiên, đó là một thiết kế trả trước, vì vậy khi cao su gặp mặt đường, nó tạo ra mối thù gia đình giữa các chuyên gia UX và Nhà phát triển có "ý kiến" về nhau.

Trong các tổ chức khác, chúng tôi thấy một chuyên gia UX sắp xếp nhiều nhóm. Điều này có xu hướng cải thiện mối quan hệ giữa mọi người mặc dù nó có thể khá căng thẳng đối với chuyên gia UX, người hiện đang tìm thấy anh ta / cô ta trong nhiều Bảng khảo sát hàng ngày, Lập kế hoạch Sprint, Hồi tưởng, v.v. Ngoài ra, họ phải sắp xếp thời gian của mình và làm việc giữa các nhóm khác nhau, thường cần chuyển đổi ngữ cảnh. Không phải hiếm khi họ có “UX tồn đọng” của riêng mình với các mục đề cập đến các mục trong Product Backlog “thực”. Scrum giống như một dây nịt hạn chế và đồng thời, các Nhà phát triển tự hỏi tại sao họ lại bị trì hoãn bởi UX.

Một bước đi táo bạo là chuyển chuyên gia UX vào đội. Người đó vẫn được coi là “chuyên gia” và do đó cần phải thực hiện tất cả các công việc của người dùng. Thường thì cơn đau UX tương tự như cơn đau QA. Khi QA nhận được rất nhiều PBI để kiểm tra và phê duyệt vào cuối Sprint, UX được theo đuổi ngay từ đầu “vì vậy chúng tôi có tất cả các thông số kỹ thuật”. Ngay cả trong nhóm, chuyên gia UX nhận thấy anh ấy / cô ấy thường làm việc “chạy trước một Sprint”, dẫn đến sự nhầm lẫn và lãng phí khi xuất hiện những thông tin chi tiết mới.

Chuyển từ UX như một người sang UX như một kỹ năng

(Cảm ơn @garrypedretti về cái nhìn sâu sắc này) Điều kỳ diệu xảy ra khi chúng ta chuyển từ việc xem UX như một người sang UX như một kỹ năng. Kỹ năng của mỗi Nhà phát triển hiện không bằng kỹ năng của một chuyên gia UX hoặc ngược lại, nhưng bắt đầu có sự trùng lặp.

Thông thường, điều này được thực hiện bởi chuyên gia UX tích cực cố vấn cho các Nhà phát triển khác về các nguyên tắc UX. Bạn có thể bắt đầu với quy mô nhỏ. Ở một trong các nhóm của tôi, một Nhà phát triển đã bị chặn vì cô ấy không có biểu tượng yêu thích cho biểu trưng của chúng tôi. Câu trả lời ban đầu là: "Tôi bị chặn, hãy để tôi viết mã thứ khác" nhưng với một số trợ giúp, cô ấy đã tự bỏ chặn và mang lại giá trị. Bắt đầu từ nhỏ và lớn dần.

Công việc UX trở thành một kỹ năng có thể được cộng tác trong quá trình chạy nước rút của các Nhà phát triển, giờ đây bao gồm cả chuyên gia về UX. Hãy nghĩ về một số hoạt động UX điển hình :

• Nghiên cứu người dùng
• Phát triển Persona
• Kiến trúc thông tin
• Wireframing
• Tạo mẫu
• Kiểm tra người dùng
• Báo cáo vấn đề kinh doanh
• Viết giả thuyết
• Thiết kế thí nghiệm
• Kiểm tra tính ổn định

Cuối cùng..

UX là một phần của mỗi PBI, giống như thử nghiệm và kiến ​​trúc, v.v. Nó không phải là thứ được thực hiện trước bởi một nhóm riêng biệt. Điều gì sẽ xảy ra nếu không thể phân biệt giữa thiết kế và giao hàng? Điều gì sẽ xảy ra nếu ranh giới mờ nhạt giữa việc khám phá những gì khách hàng cần và đưa ra giải pháp cho vấn đề của họ đan xen nhau đến mức chúng ta không còn tập trung vào những gì tách biệt chúng ta nữa mà vào những gì hợp nhất với chúng ta.

Một mục tiêu kéo dài, chắc chắn. Scrum có nghĩa là đơn giản, không dễ dàng ;-) tất cả chúng ta chỉ đang cố gắng tìm ra những gì phù hợp với chúng ta.