Lộ trình tính năng M2W Edu là danh sách những gì nền tảng dự kiến xây dựng và theo thứ tự nào. Nó được hình thành chủ yếu từ nhu cầu thật của những người dùng hằng ngày, chứ không từ danh sách ý tưởng nội bộ.
Bài viết này nêu cách góp ý sao cho đề xuất được cân nhắc nghiêm túc, các tiêu chí quyết định thứ tự ưu tiên, và những loại đề xuất sẽ không được thực hiện dù có nhiều người yêu cầu.
Vì sao góp ý từ nhà trường quan trọng
Người xây dựng một công cụ luôn có góc nhìn hạn chế so với người dùng nó hằng ngày.
Bộ phận phát triển biết hệ thống vận hành thế nào, nhưng không biết một nhân viên phòng hợp tác quốc tế thực sự mất bao lâu để cập nhật học phí, hay chỗ nào trong quy trình khiến họ phải làm thủ công.
Những chi tiết đó chỉ người dùng biết, và chúng thường là nguồn của những cải tiến có giá trị nhất.
Vì vậy phần lớn hạng mục trong lộ trình xuất phát từ ba nguồn: đề xuất trực tiếp từ nhà trường và đối tác, những vấn đề lặp lại trong các yêu cầu hỗ trợ, và quan sát về những chỗ người dùng phải xoay xở bằng cách thủ công.
Góp ý thế nào cho hiệu quả
Cách trình bày ảnh hưởng lớn tới việc một đề xuất được hiểu đúng và được ưu tiên.
Mô tả vấn đề trước, giải pháp sau. Đây là điểm quan trọng nhất.
Một đề xuất dạng “cần thêm nút xuất dữ liệu” cho biết giải pháp mà người đề xuất nghĩ ra, nhưng không cho biết vấn đề. Có thể có cách khác tốt hơn để giải quyết cùng vấn đề đó.
Một đề xuất dạng “mỗi quý chúng tôi phải chép tay số liệu từ hồ sơ sang báo cáo nội bộ, mất khoảng nửa ngày” cho biết vấn đề, tần suất, và chi phí thời gian. Từ đó có thể tìm giải pháp phù hợp nhất.
Nêu tần suất và quy mô. Việc này xảy ra mỗi ngày hay mỗi năm một lần, ảnh hưởng tới một người hay cả phòng.
Nêu cách xoay xở hiện tại. Nếu đã có cách làm tạm, mô tả nó giúp hiểu rõ vấn đề hơn nhiều so với mô tả trừu tượng.
Kèm ví dụ cụ thể. Một tình huống thật đã xảy ra có sức thuyết phục hơn mô tả chung.
Tiêu chí quyết định thứ tự ưu tiên
Không phải đề xuất tốt nào cũng được làm ngay. Bốn tiêu chí dưới đây quyết định thứ tự.
Số người dùng bị ảnh hưởng. Một vấn đề mà nhiều trường cùng gặp được ưu tiên hơn một nhu cầu đặc thù của một trường.
Mức độ ảnh hưởng tới chất lượng dữ liệu. Những tính năng giúp dữ liệu chính xác hơn, cập nhật hơn, hoặc dễ kiểm chứng hơn được ưu tiên cao, vì đó là giá trị cốt lõi của nền tảng.
Chi phí thời gian mà nó tiết kiệm được. Một cải tiến giúp mỗi trường tiết kiệm nửa ngày mỗi quý có giá trị tích luỹ lớn.
Mức độ phức tạp để xây dựng. Với hai đề xuất có giá trị tương đương, cái đơn giản hơn thường được làm trước, vì nó tạo ra kết quả sớm hơn.
Tiêu chí thứ hai có trọng số cao nhất. Một tính năng làm nền tảng tiện dụng hơn nhưng không cải thiện chất lượng dữ liệu sẽ xếp sau một tính năng làm ngược lại.
Những loại đề xuất sẽ không được thực hiện
Cần nói rõ để tránh mất thời gian của cả hai bên.
Đề xuất về thứ tự hiển thị. Không có cách nào để một hồ sơ được ưu tiên hiển thị ngoài việc bổ sung thông tin có nguồn và giữ ngày đối chiếu mới. Đây là ranh giới không thương lượng được.
Đề xuất về xếp hạng hoặc chấm điểm. Kể cả khi nhiều người dùng yêu cầu, nền tảng không xây dựng chức năng xếp hạng, vì lý do đã nêu trong phần về ranh giới của nền tảng.
Đề xuất về việc gỡ thông tin đúng. Nếu một thông tin chính xác và có nguồn, nó không bị gỡ vì bất lợi cho một bên.
Đề xuất về việc hiển thị dữ liệu cá nhân của người học. Ranh giới cứng, không có ngoại lệ.
Đề xuất mang tính quảng bá. Hồ sơ trình bày dữ liệu theo cấu trúc thống nhất, không phải nơi đăng nội dung tiếp thị.
Khi một đề xuất rơi vào năm nhóm trên, câu trả lời sẽ nêu rõ lý do thay vì im lặng, để người đề xuất hiểu đây là quyết định về nguyên tắc chứ không phải về thứ tự ưu tiên.
Lộ trình tính năng M2W Edu được công bố thế nào
Việc công bố lộ trình có hai mặt cần cân nhắc, và cách xử lý là công bố ở mức phù hợp.
Công bố những gì đang làm và sắp làm. Người dùng biết được điều gì đang tới và có thể lập kế hoạch tương ứng.
Không cam kết thời điểm chính xác cho những hạng mục xa. Ước lượng thời gian trong phát triển phần mềm thường không chính xác, và một cam kết bị trễ gây thiệt hại nhiều hơn là không cam kết.
Nêu rõ trạng thái của từng hạng mục. Đang xây dựng, đã lên kế hoạch, đang cân nhắc, hoặc đã quyết định không làm kèm lý do.
Nhóm cuối cùng đáng được công bố, dù nghe có vẻ tiêu cực. Nó tránh cho nhiều người cùng đề xuất một việc đã được cân nhắc và bác bỏ.
Mỗi hạng mục hoàn thành nên có thông báo tới những người dùng đã đề xuất nó, kèm hướng dẫn sử dụng ngắn.
Thử nghiệm trước khi triển khai rộng
Với những thay đổi lớn, cách làm hợp lý là thử nghiệm với một nhóm nhỏ trước.
Chọn nhóm đại diện. Vài trường có quy mô và cách sử dụng khác nhau, thay vì chỉ những trường tích cực nhất.
Thời gian thử nghiệm đủ dài để người dùng gặp các tình huống thực tế, không chỉ dùng thử vài lần.
Thu thập phản hồi có cấu trúc, tập trung vào việc tính năng có giải quyết được vấn đề ban đầu hay không.
Sẵn sàng huỷ. Nếu thử nghiệm cho thấy tính năng không giải quyết đúng vấn đề, việc dừng lại là quyết định đúng, dù đã đầu tư công sức.
Điểm cuối cùng khó thực hiện trong thực tế nhưng quan trọng: một tính năng không hữu ích vẫn làm tăng độ phức tạp của hệ thống và tăng chi phí duy trì mãi về sau.
Cân bằng giữa tính năng mới và sự ổn định
Một nguyên tắc ít được nói tới nhưng ảnh hưởng lớn tới trải nghiệm người dùng.
Mỗi tính năng mới đều làm hệ thống phức tạp hơn một chút. Sau nhiều lần bổ sung, một công cụ vốn đơn giản có thể trở nên khó dùng, và người dùng mới sẽ mất nhiều thời gian hơn để làm quen.
Vì vậy lộ trình không chỉ gồm việc thêm mà còn gồm việc bỏ. Những tính năng ít được dùng nên được cân nhắc gỡ đi, và việc gỡ cũng cần thông báo trước cho người dùng có thời gian điều chỉnh.
Một nguyên tắc thực dụng: với mỗi tính năng mới đáng kể, nên xem lại xem có tính năng cũ nào không còn cần thiết. Cách này giữ cho hệ thống không phình ra theo thời gian.
Kênh gửi góp ý
Để việc góp ý diễn ra đều đặn, cần kênh rõ ràng và phản hồi có thật.
Kênh chuyên trách. Một địa chỉ dành riêng cho góp ý về sản phẩm, tách khỏi kênh hỗ trợ kỹ thuật. Hai loại yêu cầu này có nhịp xử lý khác nhau và trộn lẫn thì cả hai đều chậm.
Phản hồi mọi đề xuất. Kể cả khi câu trả lời là chưa làm hoặc sẽ không làm. Một đề xuất rơi vào im lặng khiến người gửi không góp ý lần sau.
Thông báo khi hoàn thành. Người đã đề xuất nên được biết tính năng của họ đã được xây, kèm hướng dẫn ngắn.
Trao đổi định kỳ với nhóm người dùng chính. Mỗi quý một buổi ngắn thường cho nhiều thông tin hơn hàng chục biểu mẫu khảo sát.
Buổi trao đổi này nên có người trực tiếp xây dựng sản phẩm tham dự, không chỉ có bộ phận hỗ trợ. Việc nghe trực tiếp người dùng mô tả khó khăn tạo ra hiểu biết mà không bản tóm tắt nào truyền đạt lại được đầy đủ. Nhiều cải tiến có giá trị nhất xuất phát từ một câu nói bâng quơ trong những buổi như vậy. Vì lý do đó, buổi trao đổi nên để mở về nội dung thay vì bám chặt vào một danh sách câu hỏi soạn sẵn.
Vai trò của phản hồi tiêu cực
Những góp ý chỉ ra chỗ khó dùng thường có giá trị hơn những lời khen.
Người dùng thường ngại nêu vì nghĩ đó là do mình chưa quen. Trong thực tế, khi nhiều người cùng gặp khó ở một chỗ, vấn đề nằm ở thiết kế chứ không ở người dùng.
Ba dạng phản hồi đặc biệt có giá trị.
Chỗ khiến người dùng phải hỏi. Nếu một thao tác cần hỏi mới làm được, giao diện chưa đủ rõ.
Chỗ người dùng làm sai rồi phải sửa. Đây là dấu hiệu của thiết kế dễ gây nhầm.
Việc người dùng bỏ dở. Nếu một quy trình thường bị bỏ giữa chừng, có lẽ nó quá dài hoặc yêu cầu thông tin mà người dùng chưa có sẵn.
Khi cần đặt các nhu cầu vào bối cảnh chung của ngành giáo dục quốc tế, dữ liệu và báo cáo của Tổ chức Hợp tác và Phát triển Kinh tế (OECD) cung cấp tham chiếu về xu hướng chung.
Với những đề xuất liên quan tới cách trình bày thông tin công nhận văn bằng, khuôn khổ của Tổ chức Giáo dục, Khoa học và Văn hoá Liên Hợp Quốc (UNESCO) là chuẩn tham chiếu được dùng.
Mỗi tính năng chỉ nên đưa vào lộ trình khi đã có người dùng, vấn đề cần giải quyết và tiêu chí nghiệm thu rõ ràng.
Tổng kết
Lộ trình tính năng M2W Edu được xây chủ yếu từ nhu cầu thật của người dùng hằng ngày, và cách góp ý hiệu quả nhất là mô tả vấn đề kèm tần suất, thay vì đề xuất giải pháp.
Bốn tiêu chí quyết định thứ tự ưu tiên, trong đó mức độ ảnh hưởng tới chất lượng dữ liệu có trọng số cao nhất.
Và năm loại đề xuất sẽ không được thực hiện dù có nhiều người yêu cầu, vì chúng chạm vào những ranh giới đã công bố của nền tảng.
Bước tiếp theo
Hãy quan sát công việc của Quý trường trong một tuần và ghi lại những chỗ phải làm thủ công hoặc phải nhập lại cùng một thông tin ở nhiều nơi.
Danh sách đó, kèm tần suất và thời gian tiêu tốn, chính là góp ý có giá trị nhất mà Quý trường có thể gửi, và nó cụ thể hơn nhiều so với những đề xuất về tính năng.
Không cần chờ tới khi danh sách đầy đủ mới gửi. Một mục duy nhất, mô tả rõ ràng kèm ví dụ thật, đã đủ để được cân nhắc, và nó thường mở ra cuộc trao đổi dẫn tới việc phát hiện những vấn đề liên quan mà chính người đề xuất chưa nghĩ tới.
