Bốn lần nên dừng để kiểm tra một dự án địa tin học

Một dự án có thể tiếp tục chạy đúng kế hoạch mà vẫn đi xa dần khỏi công việc cần cải thiện. Bản đồ thêm lớp, bảng điều hành thêm biểu đồ, ứng dụng thêm màn hình; người dùng vẫn quay về tệp cũ vì dữ liệu hoặc luồng xử lý chưa phù hợp.

Bốn điểm dừng dưới đây không phải quy trình nghiệm thu hay công thức triển khai. Chúng là lúc chủ dự án nên yêu cầu một bằng chứng đủ cụ thể trước khi cho phép phạm vi đi tiếp.

Điểm dừng 1: mô tả được việc đang vướng

Theo một tình huống từ đầu đến cuối

Đi theo một tình huống thật: ai bắt đầu, họ tìm thông tin ở đâu, phải hỏi ai, quyết định dựa trên dữ liệu nào và kết quả chuyển cho ai. Chỉ nên đi tiếp khi nhóm dự án cùng mô tả được việc cần cải thiện và cách nhận biết nó đã tốt hơn.

Điểm dừng 2: dữ liệu mẫu bộc lộ được vấn đề thật

Không làm sạch dữ liệu chỉ để buổi demo đẹp

Chọn lớp dữ liệu ưu tiên, mã định danh, quyền sử dụng và một luồng thao tác ngắn. Dữ liệu mẫu nên giữ lại vài trường hợp thiếu, sai hoặc khó hiểu thường gặp. Nếu nguyên mẫu chỉ chạy trên một bộ dữ liệu đã được dọn riêng, nó chưa cho biết chi phí của phần còn lại.

Điểm dừng 3: người dùng tự hoàn thành được một vòng việc

Quan sát thao tác, không chỉ kiểm tra từng nút

Mỗi chức năng cần gắn với một kịch bản sử dụng: tìm tài sản, cập nhật tình trạng, xem lịch sử hoặc chuyển thông tin cho người tiếp theo. Người dùng cần tự làm mà không có đội phát triển hướng dẫn từng bước. Nơi họ dừng hoặc quay về công cụ cũ chính là phần cần sửa trước.

Điểm dừng 4: có người và chi phí để duy trì

Hỏi về ngày sau khi đội dự án rời đi

Trước khi mở rộng, cần biết ai duy trì danh mục dữ liệu, ai phân quyền, ai tiếp nhận lỗi và ngân sách nào giữ hệ thống hoạt động. Đây là câu hỏi về khả năng vận hành, không phải tuyên bố rằng dự án đã đủ điều kiện nghiệm thu hay bàn giao theo quy định chuyên ngành.

Đo việc tốt hơn, không đo số màn hình

Số màn hình và số lớp bản đồ chỉ phản ánh khối lượng xây dựng. Nên theo dõi thời gian tìm thông tin, số bước hoàn thành một tác vụ, tỷ lệ dữ liệu được cập nhật, số lỗi lặp lại và thời gian tổng hợp báo cáo. Những chỉ dấu này cho biết hệ thống có được sử dụng trong công việc hằng ngày hay chưa.

Một thử nghiệm có giới hạn có thể giúp kiểm tra giả định trước khi mở rộng. Xem Thử một WebGIS đủ nhỏ để biết có nên đi tiếp để thiết kế nhịp đánh giá cụ thể.

Kết quả triển khai cần có phạm vi nghiệm thu rõ, dữ liệu có người chịu trách nhiệm và quy trình đủ cụ thể để người dùng tiếp tục vận hành sau bàn giao.

Ghi chú về khung triển khai

Bốn giai đoạn trong bài là cách Thuận Gió tổ chức cuộc trao đổi, không thay thế quy trình đầu tư, đấu thầu, quản lý chất lượng hoặc nghiệm thu mà dự án phải tuân theo. Với dự án công, hạ tầng quan trọng hoặc dữ liệu nhạy cảm, cần bổ sung đầy đủ yêu cầu pháp lý, an toàn thông tin và tiêu chuẩn chuyên ngành.

Tham khảo GOV.UK Service Manual — Alpha và Beta để xem một mô hình công khai về thử nghiệm giả định, đưa dịch vụ đến người dùng thật và đo trước khi mở rộng.