Trong lớp học về kỹ năng report của bác Nakamura do FSU11.PMO tổ chức,(tranh thủ quảng cáo) khi một vài bạn được hỏi là có muốn làm PM không, thì có câu trả lời làm tôi suy nghĩ mãi. Bạn không muốn làm PM bởi thấy công việc của PM toàn việc "linh tinh, lặt vặt".
Nghe cũng rất có lý, vì thực sự trong 1 dự án thì công việc của PM có vẻ là khó hiểu và khó định nghĩa nhất. Kết quả của công việc PM ko được đong đếm cụ thể như Line Of Code hay số test case như các vị trí DEV và Tester. Công việc của PM cũng không được định nghĩa thật rõ ràng theo kiểu lên plan hôm nay làm việc này trong bao nhiêu lâu, việc kia trong bao nhiêu lâu.
Vậy thực sự công việc của PM là gì?
Theo định nghĩa trong quy định của Fsoft thì PM được định nghĩa theo mục đích như sau:
Job purpose: | The SPMA is responsible for managing project, ensuring the delivery of project results to customer within the given scope, schedule and resource, overseeing all aspects of the project life-cycle. |
Một định nghĩa rất ngắn gọn nhưng cũng vô cùng khó hiểu vì để hiểu được định nghĩa này cần hiểu được PMBOK, mà theo PMBOK thì công việc của PM được chia thành 10 Knowledge Areas, 5 process group và 47 processes. Giả sử bạn có đi họp lớp với lũ bạn cấp 2, mà được hỏi "mày làm gì?", bạn trả lời "tao làm PM", rồi lôi 47 cái process ra để giải thích thì chắc tới lúc tan tiệc là vừa.
Vậy có cách nào để hiểu về cái công việc của PM một cách dễ dàng hơn không?
Tôi nghĩ để phù hợp với background của hầu hết anh em trong fsoft, chúng ta sẽ nhìn công việc PM qua lăng kính của vòng đời 1 phần mềm, có lẽ như thế dễ hiểu hơn.
Chúng ta đều biết rằng để có 1 phần mềm chạy trên hệ thống, đầu tiên phả lập trình ra nó, sau đó là cài đặt và chạy trên server, tất nhiên, thỉnh thoảng phải vào khởi động lại hoặc chạy lại nếu server có vấn đề gì đó.
Công việc của PM cũng vậy thôi, về cơ bản nó cũng gồm 3 bước chính :
|
---|
Nếu như các bạn lập trình ra phần mềm phải dùng tới các ngôn ngữ lập trình, Database, server, đó là những kỹ năng và tài nguyên cần thiết để đảm bảo cho việc làm phần mềm, thì công việc của P PM cũng vậy, cũng phải biết sử dụng các kỹ năng và tài nguyên tương ứng.
Sau đây là list các kỹ năng dành cho PM mà tối chôm được từ bác Nakamura. Trong đó nhưng kỹ năng hàng trên được gọi là Hard skill, và các kỹ năng bên dưới được gọi là soft skill.
Tuy nhiên để tránh làm loãng vẫn đề, tôi sẽ không đề cập sâu hơn đến các kỹ năng này nữa, vì bạn nào muốn học thì hoàn toàn có thể đăng ký các lớp học của CTC hoặc của FSU11.PMO tổ chức.
Quay lại với việc so sánh công việc PM với 1 chương trình phần mềm, chúng ta đều biết giai đoạn lập trình là giai đoạn quan trọng nhất và tốn nhiều thời gian nhất. Thì tương tự như thế trong công việc của PM, việc lên kế hoạch là công đoạn quan trọng nhất, PM phải dồn nhiều tâm huyết nhất (hãy nhìn bảng bên dưới để thấy cột planning nó dày đặc process như thế nào). tuy nhiên nó lại thường bị áp lực về thời gian do thời gian thực hiện ngắn, do vậy nhiều PM khi làm plan thường hay có tư tưởng làm cho xong, làm đối phó (không tin cứ nhìn vào chất lượng cái PP thì biết). Nhưng có 1 câu nói về việc lập kế hoạch mà tôi vô cùng tâm đắc: "Thất bại trong việc lập kế hoạch, chính là lập kế hoạch cho việc thất bại", bạn không làm tốt giai đoạn planning là bạn đã bước 1 chân vào con đường thất bại.
Sau giai đoạn planning mà tôi đã so sánh với việc lập trình, thì bước sang giai đoạn 2 cũng quan trọng không kém. Đó là giai đoạn cài đặt. Để dễ hình dung về giai đoạn này tôi lại muốn các bạn hình dung ra việc cài 1 phần mềm lên hệ thống để cho nó "go live". Phần lớn trong chúng ta gắn bó với công việc lập trình sẽ nghĩ rằng quá trình này rất dễ, chỉ đơn giản là vứt phần mềm lên server, gõ 1 lệnh chạy là xong. Tuy nhiên tôi có 1 điều muốn tiết lộ với các bạn lập trình viên, rằng công việc kỹ sư hệ thống, những người chuyên cài đặt chương trình có mức lương cao hơn các bạn lập trình tương đối nhiều, vì một phần mềm được cài đặt trên 1 server thì rất dễ, nhưng để nó chạy được thành 1 hệ thống trên nhiều server cùng 1 lúc (nhiều khi đến hằng trăm) lại là 1 câu chuyện hoàn toàn khác. Công việc của PM trong giai đoạn vận hành dự án cũng vậy, hãy hình dung mỗi người trong dự án như là một server, nhiệm vụ của PM là phải cài phần mềm (planning) cho tất cả các server đó là sao cho tất cả xử lý đồng bộ với nhau, nhưng khốn nỗi trong một dự án 20 người thì mỗi người một kiểu. Cũng giống như chúng ta cài 1 phần mềm để chạy trên hệ thống 20 server mà mỗi server có 1 loại cấu hình, và một loại hệ điều hành hoàn toàn khác nhau vậy. Lúc này chắc các bạn đã tưởng tượng ra công việc của PM "củ chuối" đến mức nào chứ. Vì vậy khi là member của một dự án, mà thấy thằng PM cài nhầm tập lệnh cho "server" mình, thì các bạn hãy thông cảm nhé.
Khâu cuối cùng trong 3 khâu so sánh tôi đã nói ở trên, đó là giám sát và điều khiển. Tôi nghĩ tư duy phổ biến của các bạn lập trình viên sẽ như câu chuyện sau. Tôi viết 1 trang web giúp ông anh họ tôi bán chuối và bưởi (có tên miền chuoi.com và b___.com), tôi vứt cái website đó lên server và cho nó chạy là tôi hết nhiệm vụ, khi nào website có vấn đề thì ông ý gọi tôi, tôi sẽ vào sửa. Như vậy là bạn vừa giao phó toàn bộ việc giám sát hệ thống cho ông anh họ, vì đơn giản ông ý bán hàng trên đấy, nên hỏng là ông ý biết ngay. Tuy nhiên nếu bạn từng làm ở 1 data center thì câu chuyện giám sát hệ thống nó lại khác hoàn toàn, ở đây mọi người phải đảm bảo cho hệ thống chạy ở mức 99,997% hay là mỗi năm hệ thống chỉ được down dưới 15'. Do vậy việc giám sát hệ thống để phát hiện vấn đề sớm là vô cùng quan trọng, nên luôn phải có người trực 24/24 trong phòng điều khiển và nhìn chằm chằm vào cái màn hình giám sát để đề phòng sự cố. Công việc của PM với một dự án cũng vậy, luôn luôn phải giám sát để phát hiện sự cố sớm nhất có thể. Để làm như vậy thế PM thường xuyên phải đo đạc, báo cáo các chỉ số liên quan đến năng suất lao động của dự án. Rồi phải tìm cách quản lý và xử lý những sự cố xảy ra. Kiểu như Test lead vừa mới cưới chẳng hạn, PM nhanh nhạy sẽ phải nghĩ đến vấn đề phải tìm ngay người dự phòng vị trí đó vì rất có thể từ 1-9 tháng nữa sẽ có người xin nghỉ sinh :D.
Đến đây tôi xin kết thúc việc so sánh công việc của PM với một vòng đời của phần mềm, mặc dù thật ra vẫn còn 2 công đoạn nữa đó là giai đoạn đóng và mở dự án. Tôi hi vọng với bài viết này các bạn DEV sẽ hiểu hơn về công việc PM và đừng coi nó là việc "lặt vặt" nữa nhé. Còn với các bạn PM, rất mong các bạn hiểu rõ tầm quan trọng của tất cả các khâu để đừng bỏ qua công đoạn nào nhé.
Nguyễn Thanh Tiến