Chúng tôi đã làm việc chăm chỉ trong hơn 15 năm qua để xây dựng một phần mềm nhằm giúp các đội cộng tác tốt hơn. Nhưng nếu bạn đang làm việc cho một đội IT hoặc hỗ trợ khách hàng, bạn biết rằng một phần mềm là không đủ để xây dựng văn hoá cộng tác. Bạn cũng cần có các phương pháp để giúp bạn sử dụng các công cụ của mình đạt được kết quả tốt nhất. Vì thế tôi rất vui khi chia sẻ các phương pháp hay nhất từ Atlassian giúp hai đội Service và Dev cộng tác tốt hơn.

1. Hiểu về vòng lặp phản hồi giữa đội Service và Dev

Bước đầu tiên để 2 đội Service và Dev gắn kết hơn là cần hiểu rõ giá trị mà vòng lặp phản hồi mang đến cho doanh nghiệp. Chúng ta nên chia vòng lặp thành hai phần: 1) Thu thập phản hồi về sản phẩm từ khách hàng (đội Service) và 2) Tích hợp những phản hồi này vào product roadmap (đội Dev). Khách hàng sau đó sẽ cung cấp thông tin phản hồi về tính năng mới được phát hành, và điều đó tăng cường sức mạnh cho vòng lặp phản hồi.

Nhà tư vấn chiến lược Peter Drucker từng ngụ ý rằng "Bạn sẽ không thể quản lý cái mà bạn không thể đo lường". Điều này cũng đúng cho vòng lặp phản hồi giữa đội Service và đội Dev. Để hiểu rõ giá trị mà vòng lặp này mang đến cho doanh nghiệp, đòi hỏi bạn phải hiểu cách đo lường nó. Khi bạn có thể đo lường các số liệu cần thiết trong vòng lặp, bạn sẽ tìm ra cách triển khai tốt nhất. Mặc dù các chỉ số cụ thể bạn sử dụng để định lượng có thể thay đổi, một số chỉ số chung mà chúng tôi sử dụng tại Atlassian được liệt kê bên dưới.

Đối với đội Service:

• Số người gửi yêu cầu trợ giúp
• Số lượng yêu cầu tính năng cho sản phẩm
• Số lượng lỗi đã báo cáo
• Số lượng các sự cố nghiêm trọng
• Sự hài lòng của khách hàng

Đối với đội Dev:

• Số lượng lỗi đã sửa
• Số lượng tính năng được yêu cầu đã triển khai
• Số giờ dành cho sửa lỗi
• Số giờ dành cho tính năng được yêu cầu

Tại Atlassian, chúng tôi đã sử dụng các báo cáo được tích hợp sẵn (hoặc có thể tuỳ chỉnh) trong Jira Software và Jira Service Desk để theo dõi cách thức hoạt động của vòng lặp phản hồi. Các báo cáo này cho phép các đội Dev và Service theo dõi số liệu hàng tuần, cũng như đặt mục tiêu hàng quý để có thể xác định và giải quyết các vấn đề nhanh hơn.

2. Trải nghiệm người dùng bằng phương pháp dogfooding.

Ví dụ, mỗi sáng khi đến nơi làm việc, tôi thường sử dụng 3 đến 4 sản phẩm mà Atlassian xây dựng. Tôi mở máy tính và đăng nhập vào Jira Software để xem các tác vụ trong ngày, kiểm tra Stride để xem các thông báo và mở Confluence để tìm kiếm chủ đề nào đang phổ biến. Dogfooding là một chiến thuật tuyệt vời để gắn kết 2 đội Dev và Service với nhau, mà ở đó tất cả các nhân viên của bạn sẽ biến thành khách hàng. Lợi ích của phương pháp này là thử nghiệm trước với các đồng nghiệp trong tổ chức nhằm đánh giá trải nghiệm người dùng. Đồng nghiệp của bạn như là những người tiêu dùng đầu tiên để phát hiện lỗi (bug), cung cấp phản hồi về các tính năng mới sản phẩm trước khi chúng tới tay khách hàng bên ngoài.

Ví dụ: trước khi công bố Stride (công cụ giao tiếp mới) vào tháng 9, Atlassians đã thực hiện phương pháp dogfooding trên 4 tháng! Bằng cách kết hợp việc thu thập phản hồi vào xây dựng sản phẩm, chúng tôi đã nhận được hàng ngàn phản hồi về lỗi, khả năng sử dụng đến tính năng và thẩm mỹ.

Nhưng phương pháp này không chỉ là thu thập thông tin phản hồi về việc ra mắt sản phẩm và các tính năng. Nó cũng là một phần quan trọng của việc thiết lập vòng lặp phản hồi liên tục giữa các đồng nghiệp của bạn và các nhà phát triển cho việc sử dụng sản phẩm hàng ngày. Tại Atlassian, chúng tôi là những người sử dụng nhiều phần mềm Jira và Confluence. Ví dụ: chúng tôi có hơn 5.000 spaces ở Confluence và hơn 900 boards trong Jira Software. Với việc sử dụng rộng rãi trên toàn công ty, bạn có thể tưởng tượng rằng chúng tôi đã thu thập được nhiều phản hồi từ các đồng nghiệp. Lợi ích của thu thập phản hồi sản phẩm từ các đồng nghiệp còn tạo ra một vòng lặp thông tin phản hồi khác giữa các đội IT nội bộ và các đội Dev. Điều này cũng cho phép các đội IT nội bộ có thể chia sẻ kiến thức với các đội hỗ trợ bên ngoài nhằm xác định các vấn đề phổ biến và khắc phục sự cố nhanh hơn.

3. Dễ dàng nhận phản hồi từ khách hàng

Sau khi đã dành thời gian để hiểu được vòng lặp phản hồi và bắt đầu thử nghiệm sản phẩm của bạn, bây giờ cần tập trung vào cải thiện việc giúp người dùng dễ dàng đưa ra yêu cầu trợ giúp. Sức mạnh vòng lặp phản hồi của bạn liên quan trực tiếp đến số lượng phản hồi mà bạn thu thập từ người dùng. Giảm rào cản để tăng khối lượng phản hồi bạn thu thập. Thông tin đó giúp ích nhiều cho đội Service và Dev để đưa các quyết định đúng đắn trong việc phục vụ khách hàng tốt nhất.

Tại Atlassian, chúng tôi sử dụng cổng thông tin khách hàng Jira Service Desk để tiếp nhận các yêu cầu hỗ trợ từ khách hàng và nhân viên. Mặc dù khách hàng có thể sử dụng email để gửi yêu cầu đến các đội Service, nhưng phần lớn chúng tôi tiếp nhận yêu cầu hỗ trợ thông qua cổng thông tin (vì nó dễ sử dụng). Trên thực tế, cổng thông tin khách hàng của chúng tôi đã thành công đến mức tất cả các đội nội bộ từ CNTT đến Tiếp thị đến Pháp lý, đều sử dụng để nhận các yêu cầu từ bất cứ ai cần được giúp đỡ. Cuối cùng, hiện nay chúng tôi đã có khoảng 100 service desk nội bộ!

Ngoài việc cung cấp cổng thông tin dịch vụ dành riêng cho khách hàng và nhân viên, chúng tôi cũng vừa tung ra embeddable portal, một tính năng mới cho phép gửi yêu cầu trợ giúp từ bất cứ đâu thuận tiện cho khách hàng. Với embeddable portal, bạn dễ dàng tạo các yêu cầu ở bất cứ đâu trên trang web hoặc trong ứng dụng web để khách hàng có thể yêu cầu trợ giúp nhanh khi gặp phải sự cố.

Lợi ích của việc sử dụng cổng thông tin không chỉ làm cho khách hàng dễ dàng hơn khi gửi yêu cầu trợ giúp, mà còn giảm khối lượng công việc cho các nhân viên hỗ trợ. Cổng thông tin có thể được tùy chỉnh để thu thập các thông tin liên quan cần thiết cho các nhân viên hỗ trợ để tự động phân loại yêu cầu và giải quyết các vấn đề nhanh hơn. Ví dụ: cổng thông tin hỗ trợ Atlassian của chúng tôi đi kèm với một loạt các trường tùy chọn cho phép khách hàng cung cấp thông tin như loại yêu cầu, sản phẩm và giấy phép. Kết quả cuối cùng là có nhiều phản hồi từ khách hàng, giảm công việc cho các nhân viên hỗ trợ và nhiều thông tin hơn cho các đội Dev

4. Kết hợp cả 2 đội Service và Dev vào cùng một quy trình

Giờ đây, khách hàng của bạn có thể dễ dàng yêu cầu trợ giúp, điều quan trọng là phải đảm bảo tổ chức của bạn có sự phản hồi cho khách hàng. Tập trung vào việc loại bỏ mâu thuẫn giữa đội Service và đội Dev để có thể bắt đầu cải thiện sản phẩm. Atlassian kết hợp cả 2 đội Service và Dev thông qua các chiến lược đơn giản:

• Thiết lập cuộc họp hàng tuần giữa các đội Service và Dev để cùng đánh giá số liệu và xác định các vấn đề chính

Thiết lập các cuộc họp hàng tuần giữa các đội Service và Dev, giúp mọi người luôn thông nhất về các chỉ số hiệu suất chính trong khi vẫn đảm bảo các nhóm được thông báo bất cứ khi nào có các vấn đề quan trọng phát sinh. Ví dụ: nếu đội service nhận được nhiều yêu cầu hỗ trợ liên quan đến cùng một vấn đề, họ có thể sử dụng cuộc họp này để gắn cờ thông báo mức độ ưu tiên đến cho đội Dev. Tương tự khi đội Dev biết rằng có một bản cập nhật phần mềm mới, họ có thể chủ động sử dụng cuộc họp này để hướng dẫn cho đội Service, cung cấp các ghi chú cần thiết, và thông báo các hành động chính xác cần thực hiện nếu có bất kỳ vấn đề nào phát sinh.

• Trao quyền cho các đội Service để chuyển đổi phản hồi của khách hàng thành các bản sửa lỗi và tính năng

Chúng tôi sử dụng đội Service để thực hiện hai mục tiêu chính: 1) tổng hợp phản hồi từ các nhóm hỗ trợ để cung cấp hướng dẫn có ý nghĩa cho đội Dev trong việc điều chỉnh lộ trình sản phẩm, 2) tổng hợp thông tin từ đội dev về những thay đổi trong sản phẩm để hỗ trợ cho việc phát hành những tính năng mới. Có một nhóm chuyên tâm vào việc điều chỉnh các mục tiêu với các kết quả mong muốn và giữ cho các thông tin quan trọng luôn thông suốt giữa đội Service và đội Dev.

• Đội Service và Dev cùng làm việc trên một nền tảng

Cuối cùng, Atlassian sử dụng Jira để đồng bộ hóa cả đội Service và Dev thông qua việc tận dụng sự tích hợp mạnh mẽ giữa Jira Software và Jira Service Desk. Khi đội Service nhận được yêu cầu mới từ khách hàng mà cần sự tham gia của đội Dev, các nhân viên đội hỗ trợ sẽ có nhiều sự lựa chọn để xử lý. Họ có thể liên kết ticket đó trên Jira Service Desk đến một issue trong Jira Software và ngược lại. Ngoài ra các nhân viên hỗ trợ có thể @ mention các thành viên trong đội Dev hoặc bình luận trong issue trên Jira Software. Tương tự, người dùng trên Jira Software cũng có thể thực hiện điều đó trên ticket trong Jira Service Desk. Điều này cho phép cả developer và khách hàng liên lạc trực tiếp với nhau để nắm bắt rõ yêu cầu và xử lý vấn đề nhanh hơn

4 lời khuyên trên giúp phá vỡ bức tường ngăn cách giữa các đội Dev và Service, cũng như kết hợp nhanh phản hồi từ khách hàng vào quá trình phát triển sản phẩm. Điều này giúp bạn xác định bug nhanh hơn, ưu tiên phát triển các tính năng mà khách hàng quan tâm nhất và tạo nên quá trình cộng tác đồng bộ giữa khách hàng, nhân viên hỗ trợ và các developers.