[img]Sơ đồ quy trình Agile với các iteration ngắn và feedback loop từ stakeholder[/img]
Vấn đề thực tế: Vibe Coding Nhưng Team Vẫn Bị Đánh Giá Là Chậm
Nhiều team lead và developer đang gặp phải tình huống: sếp tổng nghĩ rằng với AI và vibe coding, việc làm phần mềm phải rất nhanh chóng. Tuy nhiên, thực tế tiến độ team lại chậm – không phải do kỹ năng code kém hay không dùng AI, mà do requirement thay đổi liên tục.
Hệ quả: team phải làm đi đập lại, xây đi phá lại nhiều lần cho từng feature. Và khi nhìn vào kết quả cuối cùng, sếp dễ đánh giá performance team không cao.
Bài viết này phân tích giải pháp quản lý expectation và chứng minh năng lực team trong môi trường requirement bất ổn.
[img]Biểu đồ so sánh thời gian release giữa mô hình truyền thống (vài tháng/năm) và MVP (liên tục)[/img]
Tại Sao Rework Không Có Nghĩa Là Performance Kém
Nature Of Work – Bản Chất Của Công Việc Phần Mềm
Khi làm sản phẩm phần mềm, không có chuyện 100% requirement được finalize và freeze hoàn toàn từ đầu. Đây là bản chất của ngành – nature of work.
Chính vì lý do này, chúng ta mới áp dụng các methodology như Agile, Scrum vào quá trình phát triển phần mềm – để thích nghi nhanh với:
- Sự thay đổi về mặt requirements
- Sự thay đổi về mặt expectation của khách hàng
Agile khuyến khích thích ứng với thay đổi. Tuy nhiên, rework (làm đi làm lại) vẫn sẽ bị xem là yếu tố cho thấy performance không tốt trong mắt nhiều sếp.
Điểm Mấu Chốt: Deliver Sản Phẩm Chạy Được
Để đánh giá performance hay productivity của một nhóm có tốt hay không, cần nhìn vào khả năng deliver:
- Tạo ra sản phẩm chạy được
- Có thể demo được
- Có thể xem được để lấy feedback
Vấn đề nhiều team gặp phải: cố gắng làm cho thật tốt, thật hoàn chỉnh trước khi demo hoặc release. Kết quả: mãi không có gì để cho thấy tiến độ.
[img]Mô hình MVP với vòng lặp Build-Measure-Learn và feedback từ user thực tế[/img]
Giải Pháp 1: Tiếp Cận MVP Và POC
Từ Vài Tháng Xuống Vài Tuần
Thông thường, nhiều team mất tới vài tháng hoặc cả năm mới release được một version. Cách tiếp cận hiện đại là đi theo hướng:
- POC (Proof of Concept): Chứng minh khái niệm khả thi
- MVP (Minimum Viable Product): Sản phẩm tối thiểu khả dụng
Mục tiêu: tạo ra thứ người ta có thể dùng được và feedback được ngay.
Lợi Ích Của MVP
Khi làm ra các MVP, bạn sẽ:
- Kết được phản hồi trực tiếp từ sếp và người dùng
- Người ta sẽ thấy được tiến độ – có sự thay đổi rõ ràng
- Bạn cập nhật và làm liên tục để đáp ứng yêu cầu
Đôi khi yêu cầu đến từ sếp – mặc dù có lúc developer nghĩ rằng "sếp chả biết gì cả". Nhưng việc có sản phẩm dùng được sẽ giúp chứng minh: tôi làm cũng ra kết quả.
MVP có thể đem ra thử trong một lượng user nhỏ – đủ để validate direction mà không cần hoàn thiện mọi thứ.
[img]Timeline của một iteration với requirement được freeze ở đầu sprint và change request chuyển sang sprint sau[/img]
Giải Pháp 2: Freeze Requirement Theo Iteration
Nguyên Tắc: Iteration Đủ Nhỏ = Kiểm Soát Được
Khi bạn chia iteration trong software development đủ nhỏ, bạn có thể freeze requirement trong chu kỳ đó.
Dù gì thì gì, chúng ta cũng cần có một khung thời gian hoặc một phase đủ nhỏ mà chúng ta có full control để:
- Ensure về mặt quality
- Ensure về mặt planning
Vấn Đề Của Change Request Giữa Sprint
Khi push requirement và chain requirement vào quá nhiều in between sprint hoặc iteration, sẽ dẫn tới:
- Team bị vỡ kế hoạch
- Phải rework hoặc làm lại
- Additional feature làm loãng focus
Cách Áp Dụng Thực Tế
Ví dụ: một iteration là một tháng. Trong tháng đó, mọi người đừng đụng vô tất cả những gì về requirement development. Cái gì thay đổi thì để đó cho iteration tiếp theo fix lại.
Trường hợp extreme: Nếu requirement thay đổi đến mức làm mà không mang lại lợi ích gì vì gần như công cốc → đóng luôn sprint đó.
[img]Ma trận quyết định: khi nào nên đóng sprint vs khi nào nên absorb change[/img]
Vai Trò Quan Trọng Của PO
Mức Độ Certainty Cần Thiết
Việc này phụ thuộc rất nhiều vào người làm PO (Product Owner). PO cần đạt tới một certain level về mức độ certainty:
- Requirement đã collect được
- Cảm thấy tương đối ổn, tương đối fix rồi
- Mới cho team làm
Thay vì bắt team làm một thứ mà khách hàng không aware và không happy khi nghe tới.
Ngoại Lệ: Giai Đoạn VOC
Có một giai đoạn ngoại lệ: khi cần làm VOC (Voice of Customer) để chứng minh năng lực. Lúc này bạn có thể làm ra bất cứ thứ gì bạn muốn – vì bạn cũng không được phép hoặc không có thời gian để gặp user nhiều nhằm get confirmation về một feature có nên hay không nên có trong hệ thống.
PO Cần Học Cách Baseline Requirement
PO nên học cách để:
- Baseline requirement
- Freeze requirement
- Để cho team làm việc ổn định
Tóm Lại: Ba Bước Chứng Minh Performance
| Bước | Hành Động | Kết Quả Mong Đợi |
|---|---|---|
| 1 | Lập plan phù hợp, chia iteration đủ nhỏ (2 tuần – 2 tháng) | Có khung thời gian kiểm soát được |
| 2 | Freeze requirement theo iteration, cam kết không đổi | Có demonstration thấy tiến độ rõ ràng |
| 3 | Đi theo hướng MVP – feature gì test xài được luôn | Có feedback thực tế từ user/sếp |
Nếu requirement trên quá lớn khiến việc implement của sprint gần như công cốc → close sprint đó và replan.
Kết Luận
Việc requirement thay đổi liên tục là bản chất của phát triển phần mềm hiện đại. Thay vì cố gắng chống lại thay đổi, team cần:
- Chứng minh qua deliverable: Sản phẩm chạy được giá trị hơn lời hứa
- Áp dụng MVP: Ra mắt sớm, feedback sớm, điều chỉnh sớm
- Freeze theo iteration: Tạo vùng ổn định trong chu kỳ ngắn
Khi sếp thấy được tiến độ qua các demo liên tục và sản phẩm dùng được, perception về performance team sẽ thay đổi – ngay cả khi requirement vẫn tiếp tục biến động.