Hãy chọn một công việc hữu ích cho một nhóm người dùng cụ thể, rồi bảo đảm họ có thể làm xong. Phiên bản đầu tiên cần có cách sửa sai, phân quyền và hỗ trợ để công việc đó tiếp tục vận hành. Các tính năng khác có thể bổ sung sau khi phạm vi này đã rõ.
Với phiên bản đầu tiên, hãy chọn một việc mà ai đó có thể làm đến nơi đến chốn. Sau đó, đưa vào những gì giúp họ hoàn thành việc ấy khi dữ liệu bị sai, một đồng nghiệp vắng mặt hoặc hệ thống cần được hỗ trợ.
Hãy hình dung sáng thứ Hai: một nhân viên mở phần mềm, hoàn thành một việc có ích và để lại kết quả mà người tiếp theo có thể tin cậy.
Hãy tưởng tượng một công ty bảo trì giả định đang xây dựng hệ thống quản lý phiếu công việc. Người dùng đầu tiên là nhân viên điều phối tại văn phòng và một đội bảo trì. Nhân viên điều phối ghi nhận một việc rồi giao cho đội. Đội ghi lại những gì đã làm. Nhân viên điều phối kiểm tra kết quả và đóng phiếu.
Đó có thể là một phiên bản đầu tiên hữu ích. Cụm từ “một màn hình phiếu công việc” cho biết ít hơn nhiều. Đội có xem được việc được giao không? Có ai sửa được khi giao sai không? Một phiếu đã đóng có nghĩa là gì?
Hãy xác định người dùng và kết quả cần đạt trước khi quyết định số màn hình. Một quy trình trọn vẹn có thể cần nhiều màn hình và nhiều vai trò. Đếm màn hình không cho biết nhiều về việc mọi người có thực sự dùng được phần mềm để làm việc hay không.
Hướng dẫn của Chính phủ Anh về giai đoạn beta nói về việc xây dựng và thử nghiệm một dịch vụ đáp ứng nhu cầu người dùng, bao gồm toàn bộ hành trình và những người hỗ trợ dịch vụ. Quy trình triển khai của chính phủ có yêu cầu riêng. Với công ty bảo trì trong ví dụ này, câu hỏi hữu ích là nhóm người dùng đã chọn có thể xử lý một phiếu đến khi xong hay không.
Trong ví dụ giả định, nhân viên điều phối giao phiếu cho nhầm đội. Đội phát hiện trước khi rời kho. Cần có người sửa lại việc phân công, và cả hai đội phải thấy phiên bản nào đang có hiệu lực. Để việc sửa sai sang giai đoạn sau sẽ tạo ra lỗ hổng trong chính công việc mà phiên bản đầu tiên phải hỗ trợ.
Hãy cùng những người thực hiện đi qua từng bước công việc dự kiến. Hỏi ai được tạo, sửa, giao và đóng phiếu; ai được xem thông tin. Quyết định điều gì xảy ra khi chưa thể hoàn thành việc, chẳng hạn không vào được tòa nhà hoặc phải đặt mua linh kiện. Phiếu cần có trạng thái tiếp theo được thống nhất và một người chịu trách nhiệm.
Tạo, giao, sửa và hoàn thành phiếu công việc. Giới hạn quyền truy cập theo vai trò. Giữ các phiếu chưa xong ở trạng thái dễ thấy và cho nhân viên cách tìm hỗ trợ.
Cổng tự phục vụ cho khách hàng, lập tuyến di chuyển và tự động lập hóa đơn có thể để sau nếu nhóm này vẫn hoàn thành được công việc đã thống nhất. Hãy xác nhận điều đó trước khi hoãn.
Cột thứ hai còn tùy cách doanh nghiệp vận hành. Nếu một việc chỉ được coi là xong sau khi đã xuất hóa đơn, hãy quyết định bước đó diễn ra thế nào trong phiên bản đầu tiên. Có thể chỉ cần bàn giao theo thỏa thuận sang quy trình lập hóa đơn hiện có. Bỏ qua bước này mà không nói rõ sẽ khiến nhân viên tự phát hiện khoảng trống sau đó.
Đội sẽ cần dữ liệu công việc thật. Hãy quyết định những hồ sơ hiện có nào phải chuyển sang, ai kiểm tra chúng và xử lý sai sót thế nào. Việc nhập dữ liệu không trở thành tùy chọn chỉ vì nó không có một màn hình bắt mắt.
Thống nhất ai tạo và xóa tài khoản, giải đáp thắc mắc của nhân viên, điều tra sự cố và vận hành dịch vụ. Đưa vào hướng dẫn hoặc hỗ trợ mà nhóm đầu tiên cần. Kiểm tra điều gì xảy ra khi dịch vụ ngừng hoạt động và cách khôi phục thông tin liên quan.
Bài viết của Google về việc chuyển giao trách nhiệm vận hành bàn đến kiểm tra mức độ sẵn sàng, tài liệu và đào tạo. Bài viết mô tả bối cảnh của Google, không đặt ra cơ cấu đội ngũ bắt buộc cho doanh nghiệp nhỏ. Điểm có thể áp dụng ở đây là chỉ rõ ai sẽ vận hành và hỗ trợ phiên bản đầu tiên, rồi bảo đảm họ có những gì cần thiết.
Giữ phiên bản đầu tiên gọn bằng cách chọn ít công việc hơn để hỗ trợ. Vẫn phải đưa quyền truy cập, quyền riêng tư, bảo mật và khả năng khôi phục cần thiết cho công việc đã chọn vào kế hoạch.
Bản mẫu thử có thể giúp kiểm tra nhân viên điều phối có hiểu màn hình giao việc không, hoặc đội có ghi nhận chuyến đi trên điện thoại được không. Hãy nói rõ nó chứng minh được điều gì. Một buổi trình diễn thuyết phục vẫn có thể dùng dữ liệu giả và bỏ qua phân quyền, lưu trữ hoặc khôi phục.
Trước khi cho phép dùng trong vận hành thực tế, hãy thống nhất bằng chứng cần có cho phiên bản thật. Trong ví dụ này, cần thử cả một phiếu bình thường và một phiếu bị giao sai, với đúng các vai trò dự kiến, trong môi trường thử nghiệm riêng. Kiểm tra một đội không xem được việc không thuộc quyền của mình, thông tin sửa sai đến đúng người và công việc chưa xong vẫn hiển thị.
Chọn thêm phép kiểm tra theo rủi ro của hệ thống: hồ sơ được nhập vào, thay đổi đồng thời, khôi phục sau sự cố hoặc lượng công việc hệ thống phải xử lý. Một lần đi hết quy trình thành công không giải quyết hết các câu hỏi đó. Giao người chịu trách nhiệm cho các rủi ro còn mở và quyết định vấn đề nào phải được xử lý trước khi nhân viên phụ thuộc vào dịch vụ.
Phạm vi của phiên bản đầu tiên cho công ty bảo trì có thể được viết như sau:
Hãy rà soát phạm vi đó với nhân viên, người phụ trách quy trình kinh doanh và những người xây dựng, vận hành phần mềm. Họ cần giải thích được phiên bản này xử lý những gì và phần việc còn lại sẽ đi đâu.
Chúng tôi xây dựng phần mềm doanh nghiệp theo yêu cầu. Nếu muốn trao đổi về phiên bản đầu tiên, hãy cho chúng tôi biết công việc cần hoàn thành, nhóm sẽ dùng phần mềm và những điểm bạn chưa rõ. Phạm vi, việc bàn giao và hỗ trợ sau đó được thỏa thuận cho từng dự án.
Nó có thể phục vụ một nhóm người dùng xác định làm trọn một việc có giá trị. Hãy đưa vào quyền truy cập, cách sửa sai và hỗ trợ vận hành cần cho việc đó. Không có số lượng tính năng hay màn hình chung nào phù hợp cho mọi trường hợp.
Báo cáo bổ sung hoặc tính năng tiện ích có thể để sau. Ngay từ đầu phải có cách được thống nhất để quản lý quyền truy cập tài khoản, sửa những lỗi cần thiết và thực hiện các việc khác giúp quy trình đã chọn tiếp tục chạy.
Bản mẫu thử chỉ cho thấy những gì thực sự đã được kiểm tra, chẳng hạn mọi người có hiểu màn hình đề xuất không. Việc dùng trong vận hành thực tế cần bằng chứng riêng cho quy trình đã thống nhất và các rủi ro của nó, gồm kiểm soát truy cập, xử lý dữ liệu, hỗ trợ và khôi phục cần thiết.
Bản tin gần nhất: kiếm nhiều hơn từ website hoặc app thu phí bạn đã sở hữu.
Bản trước đó: cách nhận ra những điều nhảm nhí về AI so với câu chuyện thành công thật.
Bạn quan tâm chứ?
Hằng tuần Hoặc cho chúng tôi biết, chúng tôi sẽ điều chỉnh theo ý bạn. Nghe ổn chứ?
