Lập Trình

Đôi điều trong Project Management Fundamental

919

Project Management, vị trí quản lý dự án phần mềm sẽ cần biết những gì? Những yếu tố nào trong quá trình quản lý dự án cần quan tâm?

Bài viết này cung cấp cái nhìn khách quan về dự án, các bước sẽ làm khi lên plan, lên quotation cho 1 dự án mới. Kiến thức này chỉ là kiến thức chung chung, chi tiết hơn anh em có thể tìm tới từng phần để đọc và hiểu sâu hơn.

Project Management Fundamental — Không có gì mệt mỏi nha anh em. Hiểu cho PM, họ cũng mệt lắm.

Quản lý dự án cũng là công việc nặng hơn về yếu tố kinh nghiệm. Tức là càng trải qua nhiều dự án càng quản lý dự án tốt hơn. Phần đầu tiên này mới chỉ nói tớ 1 vài point trong Project Management Fundamental. Anh em có thể theo dõi tiếp phần 2 ở các bài viết tiếp sau đây.

Bắt đầu thôi nào anh em!

1. What’s is my project?

Đơn giản nhưng luôn là câu hỏi đầu tiên cần được giải đáp đối với bản thân quản lý dự án (Project Manager). Nó cũng là bước đầu tiên trong kiến thức quản lý dự án – Project Management. Project sắp tới chúng ta quản lý làm về gì? Câu hỏi này tưởng chừng như là không quan trọng nhưng nếu không hiểu hoặc hiểu sai, rất dễ dẫn tới cả dự án sẽ thất bại.

Những thông tin cần nắm bao gồm:

Business domain là gì?
Project làm về lĩnh vực gì?
Project plan làm trong bao lâu?
Budget là gì?
Expect của khách hàng là gì?
Nguồn ảnh / Source: wiki.en.it-processmaps.com

5 câu hỏi phía trên đây chưa được xem là đủ. Ở bước đầu tiên này, define được project, hiểu được project làm gì sẽ cần tốn chút thời gian của Project Manager. Bằng mọi cách, hỏi, kick of meeting, email, gặp mặt trực tiếp khách hàng. PM cần có thông tin đầy đủ và chính xác, tốt nhất là thông tin official từ chính khách hàng để hiểu được project sắp quản lý tới đây sẽ làm gì?

3 tiếu chí lớn cần quan tâm:

Quality
Time
Cost

5 câu hỏi phỏng vấn Project Manager nhà tuyển dụng hay hỏi nhất

Mẫu bảng mô tả công việc Project Manager

2. Work Breakdown Structure

Sau khi đã hiểu rõ dự án làm gì. Có thể anh em sẽ cần một vài step nữa để làm rõ hơn requirement. Hoặc đặt QnA để hiểu chính xác scope, các nội dung còn chưa chắc chắn.

Một khi đã đảm bảo hiểu được nhiều nhất có thể về cái khách hàng dự định làm (nói là nhiều nhất vì đôi khi không thể hiểu hết tất cả, nhất là những cái quá chi tiết). Giờ là lúc anh em chia nhỏ công việc cần làm, thông thường ta gọi là WBS file.

Trong WBS file, ta có tất cả thông tin liên quan tới dự án. Bản thân PM, teammember và tất cả thành viên liên quan tới WBS cần hỗ trợ nhau để diền các thông tin này.

Một số thông tin nên có trong file WBS bao gồm:

Pre condition (điều kiện là gì)
Infrastructure (hạ tầng ra sao, thiết kế như nào)
Out of scope (những feature hay tính năng nào nằm ngoài scope sẽ không làm)
Development environment (môi trường phát triển)
Development effort (break theo task hoặc epic)
Gía cả (cost)
Timeline dự kiến
Resource (team như nào, bao nhiêu người)
Các giả định (assumption – trong trường hợp dự án đang có nhiều assumption)

Nếu các dự án khác liên quan tới device, mục precondition có thể yêu cầu cung cấp device

Nhiều tin tuyển dụng Project Manager lương cao trên TopDev, ứng tuyển ngay!

3. Safety margin và check OK

Cũng nằm trong quá trình lên WBS cho dự án, nhưng phần Safety margin này muốn tách riêng ra để nói cho anh em. Margin là khoảng cách, Safety là an toàn -> khoảng cách an toàn.

Khoảng cách an toàn ở đây anh em người Việt mình thường gọi là buffer cho dự án. Rất ít dự án có thể đảm bảo 100% không có rủi ro. Tất nhiên anh em không thể biết được khúc nào trong quá trình phát triển phần mềm sẽ có vấn đề.

Chính vì vậy ta cần thêm Safety margin, cái này thì tuỳ dự án, tuỳ tính chất hoặc mức độ rủi ro đã được ước lượng (cái này sẽ nói ở phần ngay sau).

Một trường hợp khác khi nói tới Safety margin là khách hàng yêu cầu trong khoảng thời gian gấp rút. Lúc này tuyệt đối không nên bỏ đi cái Safety margin đã đề ra, tất nhiên margin đó đã được tính toán cẩn thận và có thể tương đối ước lượng được.

Vậy nếu khách hàng vẫn yêu cầu delivery trong thời gian ngắn hơn. Lúc này sẽ có 2 kịch bản có thể xảy ra:

Money up, quality down (nhiều tiền hơn nhưng kém chất lượng hơn)
Task can overlapped (có thể trùng lặp hoặc làm song song nhau trong các task)

4. Risk Analytics

Trong quá trình lên plan hoặc làm WBS cho dự án. Một yếu tố quan trọng mà người quản lý dự án cần hiểu rõ là xác định rủi ro. Cần hiểu thôi nha anh em, chứ cần xác định thì còn tuỳ thuộc vào từng dự án.

Đối với các dự án nặng nề về mặt kỹ thuật, risk sẽ được các Software Engineer hoặc Technical leader hỗ trợ để break down. Tuy nhiên cần nhớ rõ và define cụ thể 2 risk như sau:

Project Risk (cái này là rủi ro cho cả dự án, những thứ có thể ảnh hưởng tới việc dự án có thành công hay không)
Product Risk (cái này là risk của riêng sản phẩm, bảo mật, performance, vân vân mây mây)

Ở bước này, thông thường quản lý dự án sẽ đặt câu hỏi “What could go wrong?”. Sau khi đã có câu hỏi về các yếu tố có thể được xác định là rủi ro, ta cần đặt tiếp hai câu hỏi. Hai câu hỏi này giúp xác định rõ thêm 1 lần nữa, loại bỏ các rủi ro chưa xác định.

How likely (nó sẽ như thế nào)
How serious (nó sẽ nghiêm trọng ra sao)

5. Resources

Resource ở đây hiểu là nhân lực. Tất nhiên tuỳ thuộc vào từng dự án, từng yêu cầu cụ thể mà ta sẽ có plan resource khác nhau cho từng dự án.

Resource sẽ cần được define dựa trên yêu cầu của khách. Tất nhiên đối với các mô hình như Time & Materials thì khách hàng sẽ request trực tiếp, họ cần bao nhiêu. Một số điểm cần lưu ý khi lên plan resource là các vị trí cần có trong resource plan.

Nếu khách hàng đã có design hoặc bản thân họ đang development services, không cần UI thì không nên bổ sung vị trí này vào trong resource. Một yếu tố khác cũng cần quan tâm là resource risk. Bản thân các vị trí quan trọng cần có kế hoạch backup.

Nếu việc transfer để thực hiện công việc trong dự án tốn nhiều thời gian, sẽ là rủi ro nếu 1 nhân viên được trainning đầy đủ và hiểu kĩ về dự án nghỉ việc. Đây cũng là một rủi ro cần phải lường trước trong quá trình lên resource plan cho dự án.

6. Tham khảo

Cảm ơn anh em đã đọc bài – Thank you for your time – Happy coding!

Tác giả: Kiên Nguyễn

Xem thêm:

Xem thêm nhiều việc làm IT hấp dẫn, lương cao tại TopDev!