MoSCoW - NHỮNG ĐIỀU CẦN BIẾT CHO QUẢN TRỊ DỰ ÁN

---

MoSCoW ở đây là một cách chơi chữ, viết tắt của các từ sau

---

Đây là một trong những công cụ đánh priority trong phương pháp quản lý Agile mà cụ thể hơn là nó được xuất phát từ phương pháp DSDM (Dynamic Systems Development Method). Tuy nhiên sau này, MoSCoW được nhiều phương pháp Agile khác học tập và lấy vào sử dụng, trong đó có cả Scrum.

Mặc dù là một công cụ của Agile, tuy nhiên ở bài viết này tôi sẽ chia sẻ với các bạn cách thức tôi đã áp dụng MoSCoW trong một dự án chạy theo quy trình Waterfall.

À, khoan đã, trước khi chia sẻ về việc này, tôi muốn các bạn hãy ngừng đọc và suy nghĩ giúp tôi, có cái gì không ổn ở đây? Vì sao lại có thể sử dụng MoSCoW trong mô hình Waterfall? Đây là điều phi lý mà!

Để cho bạn dễ hình dung rằng tại sao MoSCoW trong mô hình Waterfall (hay còn gọi là mô hình truyền thống, traditional) là phi lý mời các bạn cùng nhìn hình dưới đây:

Chắc các bạn đã nhận ra hình tam giác thần thánh trong quản lý dự án. Đó là tam giác thể hiện sự ràng buộc của 3 yếu tố: tính năng, thời gian và chi phí. Ở hình trên còn có thêm một ràng buộc nữa đó là chất lượng (quality). Bạn hãy chú ý sự khác nhau của 2 hình trái và phải, bạn có nhận ra chúng là sự đảo ngược lẫn nhau. Hình bên trái dựa theo mô hình truyền thống, features được vẽ ở trên tương ứng với dòng “fixed” tức là cố định; trong khi đó hình bên phải, những thứ được cố định là time, cost và quality.

Tất nhiên ta đều biết, một dự án hoàn hảo sẽ làm tất cả mọi thứ đều y như dự kiến ban đầu, nghĩa là cả chức năng, thời gian, giá cả và chất lượng đều không bị thay đổi. Nhưng rất tiếc trên đời chẳng có thứ gì là hoàn hảo cả nên hầu như ở tất cả các dự án thì những thứ trên đều không bao giờ cùng đảm bảo được hết (thế nên mới cần tạo ra môn Project management). Và sự khác nhau trong việc lựa chọn yếu tố nào được phép biến đổi đã dẫn đến sự khác nhau lớn về phương pháp quản lý.

Thời xưa rất là xưa, khi mô hình Waterfall ngự trị thì ta đều biết rằng, mỗi khi khách hàng vẽ ra một phần mềm nào đó, thì người lập trình phải đáp ứng tất cả các yêu cầu (nghĩa là tất cả các requirement đều là Must have, mà Must have hết thì còn dùng MoSCoW làm gì, đây chính là điểm vô lý tôi nói ban đầu). Tuy nhiên nếu chọn cố định features thì hệ quả là thời gian và tiền bạc sẽ bị thay đổi tuỳ vào tình hình thực tế.

Sau này, khi thế giới thay đổi nhanh chóng hơn, người ta thay đổi suy nghĩ, thay vì cho rằng “khách hàng là thượng đế” – với ý nghĩa là cái gì họ cũng biết, ta chỉ làm theo, thì bây giờ chúng ta suy nghĩ một cách thực tiễn hơn: cho rằng khách hàng cũng là con người, họ cũng không biết tất cả được, vì thế những gì họ yêu cầu không hẳn là đúng; hôm nay họ muốn thế này thì rất có thể ngày mai lại khác. Và để đáp ứng với kiểu khách hàng hay thay đổi đó thì các phương pháp Agile đã ra đời.

Như ta thấy ở hình trên, “features” được đảo ngược xuống vùng biến đổi, và nhờ thế mà phần “time”, “cost” và “quality” được ưu tiên cố định hơn. Thật ra để biện hộ cho việc cắm cái “features” xuống đáy tam giác, người ta còn viện lý do về quy luật 80/20, trong đó là 80% người dùng chỉ sử dụng tới 20% features mà thôi. Ví dụ trong Excel có số lượng hàm tính toán nhiều vô kể, nhưng chắc 80% số người dùng (có khi nhiều hơn) chỉ dùng tới các hàm cơ bản nhất kiểu sum(), count(), countif(),… Chính vì lẽ đó mà người ta cho rằng thay vì cố làm hết thì chúng ta nên tập trung đảm bảo thời gian, tiền bạc và chất lượng vào những gì quan trọng nhất thay vì làm tất cả mọi thứ nhưng thứ gì cũng dở dang như Waterfall. Đây chính là lý do MoSCoW ra đời: để đánh dấu cái gì phải làm, cái gì nên làm, cái gì cần làm và cái gì sẽ không được làm trong giai đoạn này.

Bây giờ thì bạn đã thấy sự vô lý của việc áp dụng MoSCoW vào mô hình truyền thống rồi chứ? Tuy nhiên như các bạn đều biết, các dự án Software làm theo mô hình truyền thống (tức là không phải dự án dùng Scrum), dù khách hàng có hứa chắc như đinh đóng cột rằng “Những Requirement anh gửi ban đầu cho chú mày estimate là đủ rồi đấy, cứ làm plan trên đấy thực hiện hết là xong”, thì tới một ngày đẹp trời khi chúng ta gửi Q&A, khách hàng mới vỗ trán nhận ra rằng “sao hồi xưa mình khờ thế nhỉ có thế mà không nghĩ ra”. Thế là khách hàng mới gửi một cái mail thông báo rằng, “anh xin lỗi nhé, nhờ Q&A của chú mày mà anh update được thêm một số chức năng mới, nhờ chú mày cố gắng làm xong trong thời gian như cũ nhé” (đây chính là case điển hình của CR).

Thế là xong phim, ông PM nhà ta lại phải vùi đầu vào đọc đống design mới để esitmate lại xem đống thay đổi đó đội dự án hiện tại phải làm hết bao lâu. Và khi estimate xong rồi, thì PM mới choáng váng nhận ra rằng: để làm xong đống thay đổi thì cả team phải làm trong 2 tháng nữa mới hoàn thành trong khi đó dự án chỉ còn 1 tháng phải xong. PM nghĩ đi nghĩ lại, thấy quả thật là nhiệm vụ bất khả thi, không có cách nào cả đành thông báo tin buồn với khách hàng, bảo khách cho xin lùi 1 tháng.

Nhưng câu trả lời của khách hàng còn làm PM choáng hơn “anh đã hứa với end-user rồi, không lùi được đâu, chú mày tăng gấp đôi người đi, bao nhiêu tiền anh cũng trả”.

Nhưng yêu cầu của khách hàng thì chẳng khác gì kiểu “anh cần đứa trẻ trong 1 tháng nữa, mày cho 9 chị em chửa trong 1 tháng giúp tao”. Vì để có số người gấp đôi (giả sử team hiện tại là 20 người), thì ngay lập tức không thể tuyển người mới đủ, lại còn training để làm được việc, ngoài ra overhead để quản lý 40 người và 20 người là khác hẳn nhau.

Đây chính là câu truyện thực tế đã xảy ra không chỉ một lần ở các dự án và nhiệm vụ của PMO mỗi khi có những ca như thế là phải nhảy vào tìm cách support (lúc ngon chẳng thấy ai gọi, toàn đi gặm xương).  Và sau khi khuyên dại khiến vài dự án bị chết (just kidding), thì cuối cùng tôi cũng nhận thấy cách làm sau có vẻ hiệu quả nhất, đó là làm theo các bước sau đây:

• Hãy liệt kê tất cả những requirement còn lại ra.
• Estimate cho các requirement đó.
• Rồi ngồi bàn với khách hàng về priority theo tiêu chuẩn “MoSCoW”.

 

May mắn thay, lần nào khách hàng cũng đồng ý chỉ cần tập trung vào một vài tính năng quan trọng để kịp hoàn thành trong thời gian deadline như cũ, những tính năng khác được phép hoàn thành trong thời gian sau đó. Tất nhiên trong thời gian gấp rút này, nếu dự án có thể OT và thêm người thì vẫn nên bổ sung để hoàn thành càng nhiều càng tốt.  Ơn giời, sau những lần khách hàng OK như thế thì các dự án cuối cùng đều về đích an toàn cả.

Như vậy,  việc đưa dự án chạy theo một quy trình chuẩn thì rất quan trọng. Tuy nhiên quy trình nào cũng có giới hạn của nó, mà hoàn cảnh của dự án thì thiên biến vạn hoá do vậy việc nắm vững công cụ quản lý nào phù hợp với hoàn cảnh nào thực sự rất hữu ích. Như trường hợp trên mặc dù dự án là Waterfall nhưng thực ra hoàn cảnh xảy ra CR thì dự án đã bị biến thành ngữ cảnh Agile, nghĩa là time và cost (vì không thể thêm người kịp) bị cố định, thì lúc đó ta vẫn nên sử dụng các công cụ Agile vào một cách hợp lý.

Các bạn PM cũng nên luyện Agile và Waterfall. Không chỉ học thuộc các process mà hãy hiểu từng công cụ nó dùng trong hoàn cảnh nào là hợp lý nhất. Nếu làm được như vậy cũng có nghĩa là bạn đã đạt tới tầng cao nhất của CMMI “Level 5: Optimizing”, nghĩa là bạn đã biết cách tối ưu hoá process thực hiện dự án phụ thuộc vào từng hoàn cảnh cụ thể rồi đấy.

 

Emanvn | Nguyễn Thanh Tiến