Bài viết
Quản lý dự án phần mềm: hướng dẫn cho đội mới bắt đầu
Quản lý dự án phần mềm cho đội 3–15 người: bốn việc của người quản lý, chọn Scrum hay Kanban, kế hoạch 4 tuần đầu, ví dụ đội 5 người và 5 lỗi của người quản lý mới.
Khoảng 7 phút đọc
Trả lời ngắn
Định nghĩaQuản lý dự án phần mềm là tổ chức để một nhóm người biến yêu cầu thành phần mềm chạy được, đúng lúc người dùng cần, trong nguồn lực đang có. Nó khác quản lý dự án xây dựng ở hai điểm: yêu cầu đổi liên tục trong lúc làm, và sản phẩm vô hình nên không nhìn là biết xong bao nhiêu. Vì vậy đội phần mềm làm theo chu kỳ ngắn, giao từng phần, đo bằng việc đã xong thật, thay vì lập kế hoạch chi tiết một lần rồi làm theo sáu tháng.
Bài này viết cho người lần đầu phải quản lý một dự án phần mềm cho đội 3 đến 15 người: trưởng nhóm kỹ thuật được giao thêm việc, cán bộ phòng CNTT nhận đề bài từ ban giám hiệu, hay chủ công ty nhỏ tự dẫn đội. Không cần chứng chỉ, chỉ cần bốn việc và bốn tuần đầu làm đúng.
Vì sao dự án phần mềm hay trễ
Hầu hết dự án phần mềm không trễ vì đội làm chậm. Chúng trễ vì bốn lý do lặp đi lặp lại, và cả bốn đều có cách xử lý bằng cách làm chứ không phải bằng cách làm thêm giờ.
Bốn lý do quen thuộc
- Yêu cầu mơ hồ lúc đầu, rõ dần lúc cuối. Người dùng chỉ biết mình cần gì khi cầm được sản phẩm. Kế hoạch chi tiết viết ở tháng đầu sai từ tháng hai.
- Mọi việc đều “xong 90%”. Không có định nghĩa chung thế nào là xong, nên việc dở dang chất đống và không việc nào bàn giao được.
- Việc chen ngang không ai đếm. Sếp nhờ, khách hỏi, lỗi cũ quay lại; mỗi thứ mất nửa ngày và không nằm trong kế hoạch nào.
- Tiến độ báo bằng cảm giác. “Khoảng 70%” tháng này, “khoảng 80%” tháng sau; đến ngày bàn giao mới biết còn một phần ba.
Bốn việc của người quản lý dự án phần mềm
| Việc | Cụ thể là | Công cụ | Tự kiểm tra mỗi tuần |
|---|---|---|---|
| 1. Làm rõ và sắp ưu tiên | Gom mọi yêu cầu vào một danh sách, viết đủ rõ để người làm không phải hỏi lại, xếp thứ tự theo giá trị cho người dùng. | Backlog, user story, tiêu chí chấp nhận | Có việc nào đội đang làm mà không nằm trong backlog không? |
| 2. Chia nhịp và cam kết | Chọn chu kỳ cố định (thường 2 tuần), mỗi chu kỳ đội chọn phần việc vừa sức và cam kết ra phần chạy được. | Sprint, story point, velocity | Sprint này cam kết bao nhiêu điểm, dựa vào đâu? |
| 3. Làm việc nhìn thấy được | Mọi việc nằm trên một bảng, ai cũng thấy việc nào đang ở đâu, kẹt chỗ nào; họp 15 phút mỗi sáng trước bảng. | Board Kanban, giới hạn WIP, Daily | Nhìn bảng có biết ngay việc nào kẹt hơn hai ngày không? |
| 4. Đo và điều chỉnh | Xem biểu đồ mỗi ngày để cảnh báo sớm; cuối chu kỳ cho người dùng xem, rồi đội tự sửa cách làm. | Burndown, Review, Retrospective, báo cáo | Retro vừa rồi đội chốt hành động gì, ai làm? |
Bốn việc này đúng với mọi khung làm việc, từ Scrum đến Kanban. Nếu bạn mới nghe các tên gọi, mỗi khái niệm có một bài riêng: Scrum là gì?, Story point là gì?, Burndown chart là gì?.
Chọn nhịp làm việc: Scrum hay Kanban
Quyết định đầu tiên, và cũng là quyết định dễ nhất: đội đang xây một sản phẩm hay đang giữ một sản phẩm chạy? Xây, tức có danh sách tính năng cần làm ra và có người dùng để hỏi ý kiến đều đặn, thì chạy Scrum với sprint 2 tuần. Giữ, tức việc chủ yếu là sửa lỗi, hỗ trợ, yêu cầu nhỏ đến bất chợt, thì dùng Kanban với giới hạn việc đang làm dở. Đội vừa xây vừa giữ, rất phổ biến ở phòng CNTT, lập kế hoạch theo sprint nhưng làm hằng ngày trên bảng Kanban.
Đừng tự chế quy trình ở tháng đầu
Kế hoạch 4 tuần đầu
| Tuần | Làm gì | Đầu ra | Lỗi hay gặp |
|---|---|---|---|
| Tuần 1: dựng backlog | Gom mọi yêu cầu thành việc; mỗi việc có mô tả một đoạn và 2–3 tiêu chí chấp nhận; sắp ưu tiên; cả đội chấm điểm thô bằng dãy 1, 2, 3, 5, 8; thống nhất định nghĩa Xong. | Backlog 20–40 việc, 10 việc đầu đã sẵn sàng làm; một trang Định nghĩa Xong | Viết yêu cầu dưới dạng “làm tính năng X” thay vì “người dùng cần làm được gì” |
| Tuần 2–3: sprint đầu tiên | Planning tối đa 2 giờ, cam kết dè dặt; Daily 15 phút trước bảng; kéo thẻ trong ngày; nhìn burndown; ngày cuối Review với người dùng thật và Retro 45 phút. | Một phần chạy được, phản hồi của người dùng, 1–2 hành động cải tiến, con số velocity đầu tiên | Cam kết theo mong muốn của sếp thay vì sức đội; thêm việc giữa sprint mà không bớt |
| Tuần 4: sprint thứ hai và kênh yêu cầu | Cam kết theo velocity vừa đo; mở một đường duy nhất để người dùng gửi yêu cầu và báo lỗi, có hạn phản hồi; gửi báo cáo tiến độ đầu tiên bằng số. | Sprint 2 đúng nhịp; yêu cầu không còn đến qua tin nhắn riêng; báo cáo một trang | Để yêu cầu tiếp tục vào nhóm chat “cho tiện” |
Cách viết một việc cho đúng có trong chương Backlog và công việc; định nghĩa Xong mẫu sáu điều kiện ở chương Sprint.
Ví dụ: 4 tuần đầu của một đội 5 người
Ví dụ
Phòng Khoa học công nghệ một trường đại học nhờ phòng CNTT làm phần mềm quản lý đề tài nghiên cứu. Đội 5 người: trưởng nhóm kiêm quản lý dự án, 3 lập trình viên, 1 tester. Chưa ai từng chạy Scrum.
Tuần 1: trưởng nhóm ngồi với hai cán bộ phòng Khoa học công nghệ một buổi chiều, ghi được 34 việc; chọn việc mốc “sửa nhãn trên màn hình đăng nhập” 1 điểm, cả đội chấm điểm thô. Định nghĩa Xong ba điều kiện: đã merge, tester đã kiểm theo tiêu chí chấp nhận, đã lên máy thử. Tuần 2–3, sprint 1: cam kết 20 điểm, mục tiêu “giảng viên đăng ký đề tài và xem trạng thái”. Ngày 6 burndown cho thấy việc “duyệt đề tài nhiều cấp” 8 điểm chưa nhúc nhích vì chưa rõ quy trình duyệt; trưởng nhóm gọi phòng Khoa học công nghệ ngay chiều đó thay vì đợi. Cuối sprint làm được 16 điểm, Review với hai cán bộ, họ đề nghị thêm xuất Excel. Retro chốt: việc trên 5 điểm phải tách trước Planning.
Tuần 4, sprint 2: cam kết 17 điểm theo velocity, làm được 19. Mở cổng để phòng Khoa học công nghệ gửi yêu cầu, tuần đầu nhận 6 yêu cầu, 2 thành việc, 4 trả lời trong ngày. Báo cáo tiến độ đầu tiên gửi trưởng phòng: 35 điểm đã xong trên 96 điểm backlog, dự kiến 4 sprint nữa. Lần đầu tiên con số này không phải là cảm giác.
Yêu cầu và báo lỗi: một đường vào duy nhất
Với dự án đã có người dùng, phần lớn việc mới đến từ họ. Nếu yêu cầu đến qua Zalo, điện thoại và hành lang, người quản lý sẽ mất buổi sáng để chép lại và mất niềm tin của người gửi vì không ai biết yêu cầu đã đến đâu. Quy tắc đơn giản: yêu cầu không có trong hệ thống thì không tồn tại, và mỗi yêu cầu có mức độ cùng hạn phản hồi lần đầu. Cách xếp mức độ, hạn phản hồi theo mức và cách tiếp nhận có ở chương Yêu cầu khách hàng và SLA là gì?.
Năm lỗi của người quản lý mới
Đội mới hay mắc
- Vẽ Gantt sáu tháng ở tuần đầu. Đẹp để trình bày, sai từ tháng thứ hai, và không ai cập nhật. Dùng Gantt cho mốc bàn giao lớn; trong sprint dùng bảng và burndown.
- Ước lượng hộ đội. Người không làm không thấy chỗ khó, và người làm không cam kết với con số người khác đặt. Để đội chấm, quản lý chốt phạm vi.
- Không có định nghĩa Xong. Mỗi người một chuẩn, “xong” của dev khác “xong” của tester, và tiến độ thành con số vô nghĩa.
- Báo cáo bằng phần trăm cảm tính. Báo bằng điểm đã xong trên tổng, số sprint còn lại theo velocity, và số yêu cầu đúng hạn.
- Làm hết việc của mọi người. Quản lý mới hay tự sửa bug cho nhanh, và backlog không ai sắp, yêu cầu không ai trả lời. Việc của bạn là bốn việc ở trên.
Danh sách dài hơn với cách tránh ở Lỗi thường gặp và cách tránh.
Quản lý dự án phần mềm trên Pentara
Bốn việc ở trên nằm ở bốn tab của một dự án: Backlog để gom việc, viết tiêu chí chấp nhận, chấm story point và tạo sprint; Board để kéo thẻ hằng ngày với giới hạn WIP; Báo cáo với burndown, velocity, việc trễ hạn và tỉ lệ đúng SLA để gửi cấp trên; Yêu cầu KH nhận yêu cầu từ cổng khách hàng, biểu mẫu nhúng hoặc API, có hạn phản hồi theo mức độ và một nút chuyển thành việc.
Kế hoạch 4 tuần trong bài chạy được trọn vẹn trên gói Miễn phí (10 tài khoản, 3 dự án). Bắt đầu bằng đăng ký đơn vị, rồi làm theo Bắt đầu nhanh; người chưa từng làm Scrum có lộ trình học 7 ngày. Đang cân nhắc giữa các công cụ? Đọc Phần mềm quản lý dự án cho đội nhỏ: chọn thế nào.
Hỏi đáp nhanh
- Đội mới nên bắt đầu bằng Scrum hay Kanban?
- Đang xây một sản phẩm có danh sách tính năng và có người dùng để hỏi ý kiến đều đặn thì Scrum với sprint 2 tuần, vì nó ép đội có điểm dừng và buổi Review. Chủ yếu sửa lỗi, hỗ trợ, yêu cầu đến bất chợt thì Kanban với giới hạn việc đang làm dở. Vừa xây vừa giữ thì lập kế hoạch theo sprint, làm hằng ngày trên bảng Kanban.
- Quản lý dự án phần mềm có cần chứng chỉ PMP hay Scrum Master không?
- Không, với đội 3–15 người. Chứng chỉ có ích khi làm dự án lớn nhiều bên hoặc khi khách hàng yêu cầu. Thứ cần trước là bốn việc trong bài làm đều đặn trong ba sprint: backlog rõ, cam kết theo sức đội, bảng nhìn thấy được, đo bằng việc xong thật. Sau đó muốn học bài bản thì đọc Scrum Guide, bản gốc chỉ khoảng 13 trang.
- Một người vừa code vừa quản lý dự án được không?
- Được, và ở đội nhỏ Việt Nam đây là bình thường, nhưng phải chia thời gian rõ. Gợi ý: buổi sáng đầu tuần dành cho backlog và yêu cầu khách hàng, 15 phút mỗi sáng cho Daily, còn lại code. Nếu bạn nhận ít việc code hơn người khác một chút thì đó là chi phí đúng của việc quản lý, không phải lười.
- Báo cáo tiến độ cho sếp hoặc khách thế nào cho đúng?
- Một trang, bốn con số: điểm đã xong trên tổng điểm backlog, velocity trung bình ba sprint, số sprint dự kiến còn lại, tỉ lệ yêu cầu khách hàng phản hồi đúng hạn. Kèm hai dòng: điều gì thay đổi so với báo cáo trước và đội cần gì từ người nhận báo cáo. Không dùng phần trăm cảm tính.