16102020110815.jpg)
Làm thế nào để ứng phó với các Requirement Changes dạng "lông gà vỏ tỏi"
Các thông tin dạng "lông gà vỏ tỏi" là những thông tin ít chắc chắn nhất, dễ bay (nghĩa đen). Làm sao để nhận dạng các thông tin này?
Requirement changes thường xảy ra ở các nghiệp vụ Backend, hiếm khi xảy ra ở Front-end. Bạn cần thống nhất các workflows trên Frontend càng sớm càng tốt, chỉ để lại "gap" ở nghiệp vụ chuyên sâu. Nên nhớ rằng một đứa trẻ sinh ra thì đã có khung xương và giao diện bên ngoài (da, mắt, mũi...) ở mức cơ bản, những đường nét chủ đạo sẽ đi theo đứa trẻ cho đến hết cuộc đời. Khi đứa trẻ phát triển thì mới hình thành khối thịt mỡ bên trong cùng các cơ quan nội tạng đã phát triển. Đấy chính là backend của một cơ thể đang dần trưởng thành.
Trung Quốc có câu: Một nhát cắt nhỏ chỉ làm bạn tê tái, nhưng một ngàn nhát cắt sẽ làm bạn chết từ từ...
Death by a thousand cuts is a figure of speech that refers to a failure that occurs as a result of many small problems. Death by a thousand cuts could refer to the termination of a proposed deal as a result of several small issues rather than one major one.
Kinh nghiệm từ làm PM và BA của tôi thì gần như đa số khách hàng "phá vỡ cuộc chơi" bằng cách liên tục đưa ra nghiệp vụ mới ngay cả khi đội triển khai đã bắt tay xây "code" được một thời gian. Họ không chấp nhận những cách giải thích như "out-of-scope", "bám vào mục tiêu ban đầu (objectives)" hay là "bám sát nội dung hợp đồng"... Trên thế giới, những vấn đề này thi thoảng cũng có xảy ra. Ngày nay với sự xuất hiện của các quy trình phát triển hiện đại, năng lực và tri thức của xã hội được nâng cao thì những "gap" như vậy cũng dần dần được thu hẹp lại.
Vậy hiểu thế nào là "requirement changes"?
- Đối với những thay đổi và điều chỉnh nhỏ, thí dụ như thay đổi nhỏ về workflows trên mặt giao diện, thì đó là những "lớp mỏng" thay đổi có thể chấp nhận được.
- Đối với những thông tin làm thay đổi hẳn bản chất nghiệp vụ đang xây, thì bắt buộc phải đi qua một vòng đời gồm 3 giai đoạn: phân tích Use Case, dựng prototypes và mô hình hóa với workflows, data flows level-1. Các đánh giá kỹ thuật và đánh giá tác động lên timeline dự án là những yếu tố quan trọng xác định có tích hợp thay đổi này hay không.
- Nói không với những nghiệp vụ chưa rõ ràng, những nghiệp vụ chỉ căn cứ trên thông tin thô. Nên nhớ rằng nghiệp vụ phải được mô hình hóa và chuyển thể thành workflows trên phần mềm, không để xảy ra tình huống "bi hài" là phần mềm giờ đây vẫn như một "tờ sớ" rất dài giống như khi chưa có phần mềm vậy.
Dự án Over-Scoped giống như một đứa trẻ sinh non, thiếu tháng và "dật dẹo"
Tình huống của một ca "khó":
- Đầu mối KH không đồng ý với các ý kiến của bên xây nói rằng cái này cái kia 'out-of-scope'...
- Một phòng ban nói rằng nếu ko đưa đc nghiệp vụ của họ vào thì module đó fail!
- KH ko muốn nói về hợp đồng, ko cho rằng scope đã chốt mặc dù lỗi rất lớn của họ là ko đưa ra req sớm. Một số stakeholders involve muộn trong giai đoạn implemtation và cố đưa lợi ích của họ vào (họ ko muốn ôm nhiều việc vận hành, họ muốn đẩy việc cho các phòng khác, họ muốn automatic công việc hàng ngày của họ...)
- Đang có "gap" giữa các bên khi hiểu thế nào là điều chỉnh nhỏ, thế nào là out-of-scope, thế nào gọi là "tính năng cơ bản".
- KH phá vỡ "objectives" ban đầu của dự án là version 1 chỉ xây các tính năng ở mức "cơ bản". Họ ngày càng đưa vào nhiều tính năng nghiệp vụ phức tạp, và đa số based trên thông tin thô như dựa trên thông tư, nghị định... này nọ.
Chiến lược nào cho ứng phó với sự len lỏi của các requirement changes?
- Sau khi đã chốt specs, chỉ nên cử BA sang làm việc với khách hàng để làm rõ thêm ranh giới của phạm vi. Tất cả các thông tin mới chỉ nên ghi nhận và phân tích sau khi đã về nhà, và sẽ gửi văn bản để làm bằng chứng.
- Đừng bao giờ biến mình thành "con nợ" của khách hàng khi mải mê chạy theo yêu cầu của họ. Hãy buộc họ phải trải qua quy trình 3 bước phân tích khảo sát như trên cho đến khi hết giờ, sẽ không còn cơ hội đảo ngược tình thế.
- Chiến thuật "Lê Lai cứu chúa": Nên có một trợ lý dự án (TLDA) đắc lực, thường là nữ. TLDA sẽ làm tốt công tác đối ngoại và thu hẹp khoảng trống (bridge the gap) giữa các bên. Có những lúc TLDA sẽ đại diện nhóm để gửi một email "phá băng" ngăn chặn hiện tượng "Scope Creep", sau đó rất có thể nhà thầu sẽ bị khách hàng yêu cầu nhà thầu thay đổi nhân sự này, tuy vậy bảo toàn nhân sự key còn lại. Chiến lược này sẽ làm thức tỉnh những cái đầu sa đà vào danh sách nghiệp vụ dài bất tận...
Xem thêm:
Tác giả: Phạm Đình Trường
