Quản trị Rủi ro trong Quản lý dự án | EXPERT TALKS
Quản lý dự án phát triển phần mềm là công việc trách nhiệm cao đòi hỏi Project Manager đáp ứng nhiều điều kiện. Nếu có định hướng trở thành Project Manager thì đây là bài viết dành cho bạn. Với chia sẻ thực tế công việc của một PM từ anh Nguyễn Viết Thuận, trong chủ đề "Làm thế nào để quản lý dự án, quản trị rủi ro cho dự án phát triển phần mềm hiệu quả?" mong rằng sẽ cung cấp các thông tin và góc nhìn đầy đủ về vị trí công việc này.
Giới thiệu
Anh Nguyễn Viết Thuận hiện tại đang giữ vị trí Trưởng phòng phát triển giải pháp Công nghệ Thông tin tại tập đoàn Manulife Việt Nam. Xuất phát điểm là một lập trình viên đến hiện nay anh đã có 10 năm kinh nghiệm làm Quản lý dự án phần mềm. Sau đây là một vài chia sẻ của anh trên con đường sự nghiệp của một quản lý dự án (Project Manager -PM)
Chủ đề EXPERTS TALK:
"Làm thế nào để quản lý dự án, quản trị rủi ro cho dự án phát triển phần mềm hiệu quả?".
PROJECT MANAGER là ai?
Nói một cách dễ hiểu Project manager là người được tổ chức giao nhiệm vụ lãnh đạo nhóm chịu trách nhiệm thực thi dự án để đạt được các mục tiêu đề ra. Thành viên Nhóm là những cá nhân hỗ trợ người quản lý dự án trong việc thực hiện công việc của dự án để đạt được các mục tiêu của nó
Vai trò của một người PM trong dự án phát triển phần mềm?
Với tôi, vai trò của PM là người chịu trách nhiệm cao nhất cho dự án.
Công việc của PM bao gồm giai đoạn khởi đầu, lên kế hoạch, thực thi, kiểm tra giám sát và kết thúc dự án.
PM có thể delegate (giao việc) cho các thành viên trong dự án tuy nhiên là người chịu trách nhiệm sau cùng (accountable) cho việc thành công hay thất bại của các dự án mà anh ta vận hành.
PM sẽ sử dụng những kiến thức chuyên môn bao gồm quy trình (process) và các công cụ (technique) để thực hiện các hoạt động quản lý nhằm bảo đảm dự án đáp ứng yêu cầu của khách hàng trên các tiêu chí phạm vi, chất lượng, thời hạn dự án sẽ bàn giao và cũng phải đảm bảo không vượt quá nguồn lực (budget, resource) cho phép. Trong quá trình đó sẽ có các công đoạn như Khởi tạo (Initiating), lên kế hoạch (Planning), Thực thi (Executing), kiểm soát (Monitoring & Control) và cuối cùng là đóng dự án (Closing).
Quản lý dự án là quản lý những khía cạnh nào?
Nói ngắn gọn là tất cả những gì liên quan đến dự án thì PM đều phải quản lý, còn nói cụ thể ra thì tụi anh sẽ chia thành các hạng mục để quản lý dễ dàng, chẳng hạn như
- Quản lý lịch trình(Schedule management),
- Quản lý chất lượng (Quality Management),
- Quản lý phạm vi dự án(Scope Management),
- Quản lý chi phí(Cost management),
- Quản lý nguồn lực (Resource Management),
- Quản lý giao tiếp(Communication Management),
- Quản lý rủi ro (Risk Management),
- Quản lý các bên liên quan(StakeHolder Management),
- Quản lý kế hoạch mua hàng(Procurement Management)
Vậy quy trình quản lý dự án đó cụ thể như thế nào?
Nó sẽ bắt đầu bằng việc anh lên kế hoạch phát triển dự án (Project Plan), quan trọng hơn nữa là tụi anh cần làm thêm một thủ tục đó là Project Charter để trình lên Project Sponsor cho ý kiến và thông qua, thì lúc này dự án mới được phép bắt đầu.
Khi bắt đầu vào giai đoạn phát triển, PM sẽ theo dõi và kiểm tra bằng cách đọc báo cáo (report) tiến độ đối chiếu với kế hoạch đã đề ra, tiếp tục quản lý các rủi ro có thể phát sinh.
Anh có đề cập đến Project Plan, vậy thì trong đó sẽ gồm các kế hoạch gì?
Khi lên kế hoạch cho dự án mình cần đề ra những mục như định lượng về thời gian phát triển cho từng công đoạn của dự án, chi phí, phân bố nhiệm vụ phát triển cho các thành viên góp mặt trong dự án.
Song song với đó còn cần lập hẳn Communication plan, kế hoạch mua hàng (những thiết bị hoặc cả các công cụ phần mềm cần thiết cho dự án) sẽ được đề xuất mua trong kế hoạch này.
Quan trọng nhất là kế hoạch để quản trị rủi ro, dù được lập ra ban đầu nhưng sẽ được theo dõi sát xao nhất, có thể sẽ luôn được cập nhật điều chỉnh trong quá trình phát triển dự án.
Vì sao PM lại chú trọng đến quản lý rủi ro nhất vậy anh?
Một dự án phát triển phần mềm có rất nhiều người với nhiều nhiệm vụ khác nhau đảm nhận nên rủi ro sẽ càng dày đặc hơn, nếu không quản trị rủi ro và cứ phớt lờ nó thì để dự án khó thành công được dù có may mắn đến cỡ nào.
Chẳng hạn 1 dự án sử dụng một kỹ thuật mới chưa từng áp dụng. Nếu quản lý tốt thì sẽ tiến hành ưu tiên nghiên cứu nó trước, tìm ra những phương án khác, giải pháp dự phòng. Nếu không quan tâm đến gần cuối dự án mới phát hiện ra vấn đề thì chắc chắn lúc đó sẽ trễ deadline, phải làm lại (tốn thêm chi phí) và khách hàng chắc chắn sẽ không hài lòng.
Có thể nói quản lý dự án là quản lý rủi ro, cần phải ghi ra (log) ra hết những rủi ro và quản lý nó hàng ngày, hàng tuần. Mục tiêu của quản lý rủi ro là làm cho các rủi ro có hại không xảy ra, hoặc có xảy ra đi nữa thì cũng giảm thiểu mức độ ảnh hưởng; trong khi các rủi ro có lợi thì cần làm sao để nó có thể xảy ra.
PM không phải là người làm tất cả nhưng là người nắm rõ ai, sẽ làm gì và khi nào thì xong các công việc liên quan đến risk đã được xác định.
Vậy theo anh Quản trị rủi ro trong dự án bao gồm những vấn đề gì?
Có rất nhiều rủi ro khác nhau nhưng nếu phân loại ra trong một dự án phát triển phần mềm thì mình sẽ có các loại rủi ro sau:
- Về mặt kỹ thuật, ví dụ khi phát triển dự án livestream, do không tìm hiểu kỹ dẫn đến khi test mới phát hiện không chạy được trên safari, những liên kết với third party mà không hiểu soát được, những lỗ hổng bảo mật, ...
- Về resource (nguồn lực, tài nguyên): ví dụ như số lượng thành viên trong team có quá nhiều junior (quá yếu), hoặc quá nhiều senior(quá mạnh), năng lực không phù hợp, hoặc không được giao cho đúng người, đúng việc, kế hoạch cá nhân về lịch nghỉ phép, nghỉ việc có thể ảnh hưởng đến dự án,...
- Rủi ro trong Phạm vi (Scope và Requirement): BA có kinh nghiệm và kiến thức về lĩnh vực business đó chưa? khách hàng có cung cấp thông tin và tài liệu đầy đủ, rõ ràng không? BA có làm rõ hết yêu cầu chưa? BA có truyền đạt lại đúng, đủ những yêu cầu của khách hàng cũng như có giải thích được cho khách hàng về cách mà team sẽ triển khai dự án chưa. Đặc biệt là có đủ khả năng thương lượng thật chi tiết về các yêu cầu và thời gian cụ thể với khách hàng không, ...
- Ngoài ra thì mình cũng cần quan tâm đến các rủi ro về Political: Những quy định, quy tắc chẳng hạn như: phải được khách hàng approve thì mới thực hiện, nằm ngoài scope thì phát sinh thêm chi phí, những tiền điều kiện, những vấn đề xảy ra thì sẽ như thế nào, ai chịu trách nhiệm,... cần phải rõ ràng, không mập mờ và được quản lý và xử lý một cách khéo léo.
Tất cả các loại rủi ro này đều chỉ do một mình PM quản lý phải không anh?
Như đã nói ở trên, PM không phải là người làm tất cả nhưng là người nắm rõ ai, sẽ làm gì và khi nào thì xong các công việc liên quan đến risk đã được xác định PM sẽ chia nhỏ các rủi ro cho những thành viên liên quan quản lý.
Chẳng hạn như những rủi ro về trong quá trình phát triển anh sẽ thảo luận và giao các Dev làm dự án đó về cách ngăn ngừa rủi ro này, còn những rủi ro trong quá trình Test thì anh sẽ giao cho các bạn Tester.
Có rủi ro nào không thể chia cho các thành viên khác quản lý không?
Cũng có! Riêng những vấn đề nhạy cảm mà không "delegate" được thì PM sẽ quản lý nó. Ví dụ liên quan đến nguồn lực, lương, thưởng, cách giao việc hạn chế rủi ro, communicate với C-Level thì đích thân PM trực tiếp quản lý. Ở đây không có tính tuyệt đối tuy nhiên PM nên nhận ra cái gì thì delegate được và cái nào không nên.
Làm thế nào để quản trị rủi ro của dự án hiệu quả?
Để quản lý hiệu quả là anh cần phải quản lý risk log, đánh giá định tính và định lượng để theo dõi các rủi ro. Việc gì cũng cần có thứ tự ưu tiên và quản lý rủi ro cũng vậy.
Không thể 1 ngày mình quản lý hết toàn risk được và mình nên focus vào các risk có xác suất xảy ra cao, ảnh hưởng lớn tới dự án và tập trung manage nó. Công việc này lặp lại hàng ngày, hàng tuần với risk được thêm mới và risk cũ được kiểm soát. Từ đó cứ theo độ ưu tiên cao mà làm việc thôi.
Quản lý Rủi ro là quản lý quản lý lặp đi lặp lại và được quản lý hàng ngày, càng sớm càng tốt để bảo đảm rủi ro sẽ giảm dần.
Tùy vào rủi ro mà sẽ giao cho thành viên trong team chịu trách nhiệm.
Trong từ rủi ro đó cần xác định các “next action” thích hợp để nó không xảy ra và nếu rủi ro đó xảy ra thì cần giải quyết như thế nào để đảm bảo mức độ ảnh hưởng nhỏ nhất để không ảnh hưởng chất lượng và tiến độ của dự án. Những action này phải đảm bảo tính nhất quán và triệt để!
Anh theo dõi các rủi ro như thế nào khi giao cho các thành viên?
Rủi ro được giao cho các thành viên trong team, các thành viên sẽ có nhiệm vụ báo cáo theo ngày, theo tuần và theo tháng về công việc cũng như khả năng có thể ngăn ngừa được những rủi ro liên quan đến vai trò của họ đảm nhận.
Còn điểm nào cần lưu ý để quản trị rủi ro hiệu quả không anh?
Trong suốt quá trình thực hiện dự án, thì luôn có những rủi ro tiềm ẩn, tùy tình hình mà nó bộc lộ nên anh cần phải thường xuyên theo dõi dự án để tìm ra các rủi ro và cập nhật ngay vào danh sách theo dõi!
Đặc biệt, cũng có những rủi ro vượt ngoài khả năng thì cần báo cáo ngay với Sponsor/Khách hàng để có những action phù hợp!
Rủi ro hay còn được biết với từ đồng nghĩa là “nguy cơ”, nên anh tin chắc rằng khi giữ vị trí PM của một dự án, các bạn sẽ gặp những nguy cơ mà chữ “cơ” có thể là cơ hội bất ngờ mang lại những thuận lợi cho quá trình phát triển dự án hoặc những giá trị mới cho khách hàng
Những rủi ro hoặc vấn đề thường gặp khi quản trị rủi ro của một dự án.
Dự án IT nói riêng thì bên cạnh các rủi ro chung, anh thấy có 4 vấn đề quan trọng thường xuất hiện trong quá trình phát triển một dự án!
Thứ nhất là về Resource, anh phải luôn tương tác với các thành viên trong nhóm về khả năng hoàn thành nhiệm vụ của họ đúng tiến độ, nắm được thời gian vắng của các thành viên cũng như rủi ro họ phải rời dự án.
Thứ hai là về Scope (Yêu cầu khách hàng), có thể xảy ra các vấn đề như estimate không đúng hoặc khi triển trai dự án thì phân công resource không đúng chẳng hạn khi estimate thì dựa vào trình độ senior nhưng lại giao cho các bạn có năng lực junior để hoàn thành các nhiệm vụ.
Thứ ba là rủi ro về mặt kỹ thuật: áp dụng kỹ thuật mới chưa có kinh nghiệm hoặc sử dụng thư viện bên thứ ba mà không có khả năng kiểm soát.
Cái nữa là chất lượng. QC/Tester chưa viết đủ test case hoặc khi test còn sót nhiều bug nghiêm trọng, khi xảy ra bug phải rework tốn rất nhiều chi phí mà phần này không nằm trong estimate ban đầu. Cần kiểm soát số bug nằm trong NORM của dự án
Học gì để trở thành PM của một dự án phát triển phần mềm?
Cá nhân anh xuất phát điểm là một lập trình viên nên trở thành PM cũng không gặp quá nhiều khó khăn, quan trọng hơn hết là bản thân có đam mê, mong muốn và có những tố chất phù hợp với vị trí này hay không! Một người có thể rất giỏi vể kiến trúc, kỹ thuật nhưng lại không thích công việc của PM thì sẽ khó để anh ấy thành công trên con đường quản lý dự án.
Về vấn đề kiến thức chính thống để học thì các bạn có tham khảo các khóa học của PMP (Project Management Professional), có cả chứng chỉ luôn!
Vậy có chứng chỉ PMP là có thể làm PM ngay được phải không anh?
Chưa hẳn! Các bạn dù muốn làm bất cứ vị trí nào mới cũng cần có thời gian được những người cấp trên hoặc đi trước training, coaching, theo sát trong thời gian tập sự! Không phải cứ học kiến thức chuyên môn là làm được liền!
Như anh từ Dev rẽ sang nhánh quản lý dự án cũng mất hơn 6 tháng vừa học vừa làm dưới sự chỉ dẫn của các anh đã có kinh nghiệm sau đó mới manage dự án độc lập được. Công việc nên đi từ dễ tới khó và trong dự án cũng có những dự án đơn giản và dự án rất phức tạp. Giao cho một người PM còn non kinh nghiệm quản lý dự án lớn, phức tạp thì xác suất thất bại là gần như 100%.
Thời gian tập sự này khoảng bao lâu?
Khoảng từ 6 tháng đến 1 năm tùy khả năng mỗi người! Sau đó thì người hướng dẫn có thể giãn dần sự training, coaching, mentoring và chỉ đứng ở góc độ cố vấn và kiểm tra định kì thôi. Trong lúc đó, người hướng dẫn hoặc cấp trên của PM này sẽ đánh giá năng lực của họ để xem là có thể dẫn dắt dự án tốt chưa!
Ngoài kiến thức thì còn yêu cầu kỹ năng gì khác không anh?
Có chứ! 90% là khoa học,10% là nghệ thuật. chính 10% nghê thuật này làm cho 90% khoa học kia vận hành trơn tru và đem lại thành công cho dự án
Bên cạnh kỹ năng cứng trong PMP, còn có các kỹ năng mềm cần có cho PM.
Nói về các kỹ năng mềm cần thiết anh thấy PM là người phải có khả năng quản lý thời gian tốt. Thời gian ở đây không phải của dự án chung chung, mà phải bắt đầu từ quản thời gian cá nhân, đến tiến độ thời gian của các thành viên trong dự án, rồi mới đến cái chung nhất là thời gian của dự án.
Và không thể không nhắc đến kỹ năng giao tiếp. Người PM quản lý tốt là người phải nắm được nhiều các thông tin của dự án và trong quá trình dự án, muốn như vậy thì cần phải chịu nói chuyện, chịu contact với các bên.
PM cùng với BA sẽ là người vừa giao tiếp với khách hàng vừa giao tiếp với nội bộ nên cũng cần khả năng đàm phán, thương lượng và truyền đạt thông tin trong nội bộ! Đảm bảo luôn luôn là giao tiếp 2 chiều!
Tiếp đến là kỹ năng giải quyết vấn đề (problem solving & critical thinking). Là người đầu tàu thì PM phải nhìn thấy rõ các rủi ro có thể xảy ra cho dự án như anh đã chia sẻ phía trên! Sau đó nghĩ biện pháp ngăn ngừa và nếu không thể thì phải suy nghĩ ra cách khắc phục chúng!
Vì sao anh chọn làm công việc PM?
Công việc PM đến với anh một cách tự nhiên. Lúc anh làm về kỹ thuật và là trưởng nhóm cho 1 dự án, anh được PM giao việc và anh quản lý tốt.
Kết thúc năm đó bên Công ty cần PM và anh thấy mình có khả năng/phù hợp với công việc này nên mạnh dạn apply vào.
Sau giai đoạn acting thì mọi việc tiến triển thuận lợi và anh đi trên con đường này 10 năm nay. Nói như ông bà ta nói là nghề chọn người.
Theo anh đó là những tố chất gì?
Thứ nhất phải nói đến là sự bản lĩnh. PM là người đầu tàu, chính vì thế luôn luôn là người đứng mũi chịu sào! Khi có sự cố xảy ra và có phàn nàn của khách hàng thì người PM sẽ là người chịu trách nhiệm chính khi đối thoại với khách hàng! PM phải nhận trách nhiệm với lý do thiếu sót trong khả năng quản lý của bản thân chứ không phải cứ nói do anh A dev thế này, anh B test thế kia được!
Thứ hai, nhưng cũng vô cùng quan trọng để phù hợp với vị trí PM là yêu thích những “con số biết nói”. Vì PM là làm việc trên những “con số biết nói”, dựa trên đó để đề ra các đối sách, hướng quản lý tiếp theo. Một người nhận ra bản thân họ có tố chất làm PM thì họ phải yêu thích và chủ động thống kê điều tra ra những con số. Bởi những quyết định dựa trên định tính mới thực sự có giá trị chứ không phải dựa trên những đặc điểm định lượng!
Thứ ba, bản thân người làm PM cần phải tiếp xúc với rất nhiều người, PM phải là người chủ động tương tác trước nhất với các thành viên và cả với khách hàng nếu muốn quản lý tốt! Nếu không có tố chất chủ động trong tương tác thì cũng rất khó để trở thành PM. Tối thiểu nhất thì khả năng giao tiếp phải đáp ứng truyền đạt thông tin đúng, đầy đủ, chính xác và kịp thời đến đúng đối tượng.
Ban biên tập chân thành cảm ơn anh đã dành thời gian chia sẻ kinh nghiệm quý báu đến các đọc giả của blog GrowUpWork, chúc anh sức khỏe và thành công!
Tin tức liên quan
Chia sẻ kinh nghiệm làm việc ở vị trí Technical Lead | EXPERT TALKS
Làm sao để người hướng nội Leadership hiệu quả | EXPERT TALKS
Làm sao để thăng tiến trong công ty IT | EXPERT TALKS
Khám phá về công việc thú vị của Product Architect | EXPERT TALKS
Những lỗi sai thường gặp phải khi phỏng vấn công ty IT | EXPERT TALKS
Công việc của IT Business Analyst là gì? Bí quyết thăng tiến? |EXPERT TALKS
