【Hướng dẫn Toàn diện】Các bước thực tiễn đổi mới và phát triển hệ thống: Từ định nghĩa yêu cầu đến vận hành không thất bại
System Development6 tháng 3, 20267 phút đọc5 views

【Hướng dẫn Toàn diện】Các bước thực tiễn đổi mới và phát triển hệ thống: Từ định nghĩa yêu cầu đến vận hành không thất bại

Be A Racer Team

Author

Chiến lược phát triển hệ thống bắt đầu từ hôm nay

a man sitting at a table using a laptop computer

Dự án phát triển hệ thống không chỉ là việc áp dụng công nghệ đơn thuần, mà còn là quá trình thiết kế lại quy trình nghiệp vụ và tạo ra giá trị kinh doanh. Như các ví dụ tham khảo, chìa khóa thành công nằm ở sự cân bằng giữa tính vững chắc để hướng tới vận hành dài hạn và tính linh hoạt để đáp ứng thay đổi. Trong hướng dẫn này, chúng tôi trình bày các hành động cụ thể mà nhân viên thực thi có thể thực hiện ngay từ ngày mai theo từng bước. Các tổ chức đang gặp vấn đề về hệ thống cũ kỹ hoặc nâng cao hiệu quả nghiệp vụ, trước hết hãy bắt đầu phân tích hiện trạng theo quy trình này.

Danh sách kiểm tra chuẩn bị

person using laptop
  • Đã hoàn thành kiểm kê quy trình nghiệp vụ hiện tại chưa
  • Đã đạt được sự đồng thuận từ các bên liên quan chính chưa
  • Giả thuyết về quy mô ngân sách và thời gian đã được xây dựng chưa
  • Yêu cầu bảo mật và tiêu chuẩn tuân thủ đã rõ ràng chưa
  • Phân chia vai trò giữa tài nguyên nội bộ và nhà cung cấp bên ngoài đã được xác định chưa

Bước 1: Hiện thực hóa các vấn đề hiện trạng và đặt mục tiêu

Mục tiêu: Xác định vấn đề thực sự cần hệ thống hóa và đặt mục tiêu số.Hành động: Thực hiện phỏng vấn tại hiện trường, liệt kê các nút thắt trong nghiệp vụ. Tập trung trích xuất các phần vận hành bằng Excel hoặc phụ thuộc vào cá nhân.Trở ngại: Tư duy kiểu "đũa thần" cho rằng "chỉ cần đưa hệ thống vào là sẽ giải quyết được".Giải pháp: Lấy việc xem xét lại quy trình nghiệp vụ làm tiền đề.Tiêu chí hoàn thành: Trạng thái KGI và KPI đã được định nghĩa và chia sẻ với các bên liên quan.Thời gian cần thiết: 2 tuần.

Bước 2: Định nghĩa yêu cầu và sắp xếp thứ tự ưu tiên

Mục tiêu: Phân biệt rõ ràng giữa chức năng bắt buộc và chức năng nên có.Hành động: Tạo bản đồ câu chuyện người dùng. Xác định phạm vi MVP (Sản phẩm khả thi tối thiểu). Đối với khu vực công, ưu tiên hàng đầu là tuân thủ quy định pháp luật.Trở ngại: Chi phí tăng và chậm trễ do đặc tả bao gồm tất cả mọi thứ.Giải pháp: Chia thành các giai đoạn, thu hẹp các chức năng cho bản phát hành ban đầu.Tiêu chí hoàn thành: Tài liệu định nghĩa yêu cầu được phê duyệt và có thể lập báo giá từ nhà cung cấp.Thời gian cần thiết: 3 tuần.

Bước 3: Lựa chọn công nghệ và thiết kế kiến trúc

Mục tiêu: Quyết định cấu hình công nghệ kết hợp cả khả năng mở rộng và khả năng bảo trì.Hành động: Ra quyết định Cloud-native hay On-premise. Xác nhận khả năng liên kết API. Thiết kế kiến trúc bảo mật.Trở ngại: Khóa chặt nhà cung cấp do áp dụng công nghệ thịnh hành.Giải pháp: Ưu tiên lựa chọn công nghệ tiêu chuẩn và mã nguồn mở.Tiêu chí hoàn thành: Tài liệu thiết kế cơ bản hoàn thành và rủi ro công nghệ được đánh giá.Thời gian cần thiết: 2 tuần.

Bước 4: Phát triển và quản lý tiến độ

Mục tiêu: Tiến hành triển khai đúng kế hoạch trong khi đảm bảo chất lượng.Hành động: Quản lý bằng Agile hoặc Waterfall. Xác nhận tiến độ và vấn đề qua cuộc họp định kỳ hàng tuần. Thực hiện nghiêm ngặt kiểm duyệt mã.Trở ngại: Xảy ra nhiều lần làm lại do thay đổi yêu cầu.Giải pháp: Củng cố quy trình quản lý thay đổi và đánh giá phạm vi ảnh hưởng.Tiêu chí hoàn thành: Hoàn thành triển khai toàn bộ chức năng và vượt qua kiểm thử đơn vị.Thời gian cần thiết: Tùy quy mô (từ 3 tháng trở lên).

Bước 5: Kiểm thử và bảo đảm chất lượng

Mục tiêu: Thực hiện kiểm tra giả định vận hành tại hiện trường, tiến gần đến con số không lỗi.Hành động: Thực hiện kiểm thử tích hợp, kiểm thử tổng hợp, kiểm thử tải. Kiểm chứng bằng dữ liệu thực tế.Trở ngại: Bỏ sót xử lý ngoại lệ tại hiện trường do chỉ dựa trên kịch bản kiểm thử trên giấy tờ.Giải pháp: Bắt buộc thực hiện UAT (Kiểm thử chấp nhận người dùng) bởi người dùng hiện trường.Tiêu chí hoàn thành: Giải quyết các lỗi nghiêm trọng và nhận được OK tại cuộc họp quyết định phát hành.Thời gian cần thiết: 2 tuần.

Bước 6: Phát hành và hỗ trợ triển khai

Mục tiêu: Đảm bảo chuyển đổi suôn sẻ và người dùng ổn định.Hành động: Soạn thảo tài liệu hướng dẫn, tổ chức đào tạo. Xây dựng cơ chế hỗ trợ kỹ thuật. Di chuyển dữ liệu từ hệ thống cũ.Trở ngại: Giảm tỷ lệ sử dụng do tâm lý phản kháng của người dùng.Giải pháp: Lựa chọn nhân vật chủ chốt và thực hiện chương trình đào tạo người ủng hộ (Champion).Tiêu chí hoàn thành: Nghiệp vụ bắt đầu bình thường trên hệ thống mới và các sự cố ban đầu lắng xuống.Thời gian cần thiết: 1 tháng.

Bước 7: Giám sát vận hành và cải tiến liên tục

Mục tiêu: Duy trì hoạt động ổn định của hệ thống và đóng góp vào tăng trưởng kinh doanh.Hành động: Giám sát log, đo lường hiệu năng. Thu thập phản hồi người dùng và đưa vào backlog.Trở ngại: Hoạt động cải tiến sau phát hành bị đình trệ.Giải pháp: Đặt KPI cải tiến và tổ chức cuộc họp rà soát định kỳ.Tiêu chí hoàn thành: Thể chế báo cáo định kỳ được thiết lập và chu kỳ cải tiến tiếp theo diễn ra.Thời gian cần thiết: Liên tục.

So sánh công cụ khuyến nghị

Thể loạiTên công cụĐặc điểmQuy mô phù hợp
Định nghĩa yêu cầuMiroBảng trắng có thể chỉnh sửa chungTất cả quy mô
Quản lý dự ánBacklogQuản lý vấn đề và Wiki tích hợpVừa và nhỏ
Quản lý dự ánJiraTối ưu cho phát triển AgileLớn
Quản lý kiểm thửTestRailChuyên về quản lý kịch bản kiểm thửVừa và lớn
Hạ tầngAWS/AzureĐám mây có khả năng mở rộngTất cả quy mô

Xử lý sự cố Q&A

Câu hỏi 1: Phải làm gì nếu yêu cầu thay đổi giữa chừng?
Trả lời: Đánh giá mức độ ảnh hưởng của thay đổi và trình bày tác động đến ngân sách/lịch trình để lấy sự phê duyệt. Tránh các thay đổi vô hạn.
Câu hỏi 2: Làm thế nào để ngăn ngừa rắc rối với nhà cung cấp?
Trả lời: Rõ ràng hóa định nghĩa sản phẩm đầu ra trước khi ký hợp đồng và ngăn ngừa hiểu lầm qua cuộc họp hàng tuần.
Câu hỏi 3: Phương pháp xử lý khi ngân sách thiếu hụt?
Trả lời: Xem xét lại thứ tự ưu tiên chức năng, tập trung nguồn lực vào các chức năng bắt buộc. Cần có quyết định chuyển sang giai đoạn 2 trở đi.
Câu hỏi 4: Biện pháp khắc phục khi người dùng không sử dụng?
Trả lời: Ngoài cải thiện UI/UX, cần thiết kế lại quy trình nghiệp vụ xem nó có phù hợp với hệ thống hay không.
Câu hỏi 5: Làm thế nào để chi phí bảo trì không tăng vọt?
Trả lời: Áp dụng công nghệ tiêu chuẩn và chuẩn bị tài liệu để ngăn ngừa sự phụ thuộc vào cá nhân. Sử dụng tính năng tự động mở rộng của đám mây cũng rất hữu ích.
Câu hỏi 6: Hành động sơ cứu khi xảy ra sự cố bảo mật?
Trả lời: Chuẩn bị sẵn sổ tay biện pháp phòng ngừa và xác định đội ngũ sơ cứu. Ưu tiên hàng đầu là xác minh sự thật và xác định phạm vi ảnh hưởng.
Câu hỏi 7: Phải làm gì khi tài nguyên nội bộ không đủ?
Trả lời: Bổ sung PM chuyên gia bên ngoài hoặc thu hẹp phạm vi phát triển bằng cách tận dụng SaaS.

Mẹo cho chuyên gia - Phần nâng cao

Phát triển hệ thống thành công quan trọng hơn cả việc lựa chọn công nghệ là cần được coi là "biến đổi tổ chức". Bằng cách sử dụng phát triển AI-driven hoặc tận dụng các công cụ Low-code, hãy rút ngắn thời gian xây dựng nguyên mẫu và tạo chu kỳ nhận phản hồi sớm. Ngoài ra, đối với cơ quan công cộng, hãy xác nhận quy tắc mua sắm sớm; đối với khu vực tư nhân, hãy thực hiện tính toán ROI nghiêm ngặt để dễ dàng nhận được sự thấu hiểu từ cấp lãnh đạo.

Mẫu quản lý tiến độ - Danh sách kiểm tra

Vui lòng xác nhận các mục sau hàng tuần:

  • Tuần này có tiến độ đúng kế hoạch không (nguyên nhân chậm trễ là gì)
  • Số lượng vấn đề chưa giải quyết tăng hay giảm
  • Yếu tố rủi ro của tuần tới là gì
  • Báo cáo cho các bên liên quan đã hoàn thành chưa
  • Chuẩn chất lượng (số lỗi, v.v.) có nằm trong phạm vi cho phép không

Tags

#システム開発#offshore開発#アジャイル開発
0 reactions
💬

Bình luận

🗣️ Tham gia thảo luận

Sign in to leave a comment and join the discussion

Loading...