Project Manager: Bạn là người thế nào?

Lời nói đầu

Hiện tại ở phần lớn các công ty CNTT của Việt Nam, cả outsource lẫn product, đặc biệt là các công ty vừa và nhỏ, thì vai trò và công việc của người làm Quản trị dự án (PM – Project Manager)/Scrum Master khá là mơ hồ với số đông các vị trí khác. Và số lượng các bạn được đào tạo, có chứng chỉ chuyên nghiệp (ví dụ PMP) làm vị trí này vẫn còn khá ít, thường đang tập trung ở các công ty nước ngoài hoặc các ông lớn về CNTT của Việt Nam như Viettel, FPT, CMC, TinhVan… Ở phần còn lại, thường là các bạn leader về kĩ thuật sẽ tự học hỏi các kĩ năng để dần dần đảm nhận cả 2 vị trí Technical leader + PM luôn. Điều này đã gây nên tranh cãi suốt từ xưa đến giờ và vẫn chưa có hồi kết về việc PM xuất thân từ Technical leader tốt hơn hay PM chuyên nghiệp sẽ tốt hơn. Tôi sẽ không bàn về vấn đề này, để cho các bạn chém gió tiếp. Vấn đề tôi muốn chia sẻ cùng các bạn ở series bài viết này là các kiến thức cơ bản nhất tôi đã tóm tắt, thu lượm được từ các tài liệu chính thống đào tạo về quản trị dự án. Để từ đó nếu hứng thú các bạn có thể tìm hiểu sau hơn để có thể trở thành các nhà quản trị dự án chuyên nghiệp, thi các chứng chỉ cũng như quản trị được các dự án ở nhiều lĩnh vực khác nhau không chỉ CNTT. Và cũng hy vọng sẽ có thêm các cao nhân khác chỉ giáo những lỗ hổng và chia sẻ kiến thức hay kinh nghiệm thực tế cho tôi và các bạn. Một số keywords về chuyên ngành này để tiện Google: PMP, PMBOK, PMI, Scrum master.

Khuyến cáo 1: Các kiến thức này đều ở mức cơ bản và đề cập chung về công việc quản trị dự án, chưa trình bày chi tiết cho từng loại quy trình vận hành dự án như waterfall, iteration hay Scrum/Agile…
Khuyến cáo 2: Các từ chuyên môn tôi sẽ giữ nguyên gốc tiếng Anh vì sợ dịch ra tiếng Việt sẽ không hết ý.
Khuyến cáo 3: Những chia sẻ này đều thuần lý thuyết, vì vậy khi áp dụng vào thực tế bạn cần sử dụng một cách linh hoạt, không rập khuôn

Và, để mở đầu cho series bài viết này, tôi xin giới thiệu về các tố chất/kĩ năng cần phải có dành cho nhà quản trị dự án. Có thể các bạn sẽ thấy đâu đó mình đã thực hành các kĩ thuật này nhưng chưa gọi tên được nó, hoặc nếu chưa thực hành được thì đây là các thông tin hữu ích.

1. PM – Bạn cần tố chất gì?

Con người ta thường sẽ chia ra làm 2 loại: Người dẫn dắt và Người thừa hành, và dù vai trò của cả 2 loại này đều quan trọng như nhau để có thể giải quyết được công việc, nhưng có vẻ mọi người vẫn thích làm Người dẫn dắt hơn (bởi thế người ta hay gọi họ là Lãnh đạo). PM cũng có thể coi là Người dẫn dắt của dự án, của team và đóng góp vai trò lớn trong thành công của dự án. Thường thì có người sinh ra đã có sẵn tố chất để làm Người dẫn dắt, nhưng tôi nghĩ đa phần thì đều phải qua học hỏi và luyện tập, cũng như các bạn thấy có rất nhiều người thành công nhờ lao động chứ không phải nhờ là thiên tài. Vì vậy các bạn không nên sợ nếu một ngày nào đó sếp ấn vào vị trí PM trong khi từ nhỏ tới lớn chưa từng lãnh đạo ai. Lúc đó, hãy HỌC là sẽ làm được. Vậy thì, trước hết các bạn phải nhớ tới BA tố chất (lại là số BA thần thánh) cần phải trau dồi của một PM:

Knowledge
Performance
Personal Skill

Tố chất đầu tiên chính là Knowledge, chúng ta có thể hiểu chung là kiến thức đa dạng: kiến thức về quản trị dự án, kiến thức về sản phẩm, kiến thức về công cụ tạo ra sản phẩm, kiến thức về quản trị tổ chức, con người, kiến thức về giao tiếp…vv. Tức là, đối với PM, để đảm bảo dự án thành công thì bạn sẽ phải có một tập hợp hầm bà lằng các thể loại kiến thức khác nhau chứ không phải chỉ có kiến thức về lập trình là đủ.

Tố chất thứ hai là Performance, tức là khi là PM, bạn phải chấp nhận làm việc hết sức chăm chỉ và năng suất, nếu không thì bạn sẽ luôn ngập đầu trong công việc và dự án lúc nào cũng lụt. Bạn hãy tưởng tượng thế này, bạn sẽ phải là cầu nối, kiểm soát các luồng thông tin giữa các bộ phận khác nhau trong dự án (dev, tester, QA, QC,…) hoặc với khách hàng, sếp to hơn hoặc kể cả các phòng ban khác (nhân sự, hành chính…). Đấy, riêng việc check mail và phản hồi thông tin cũng đã ngốn của bạn kha khá thời gian rồi. Bên cạnh đó, bạn phải quán xuyến mọi việc của dự án, từ việc ăn ngủ nghỉ, tâm tình tâm sự của anh chị em trong team tới việc phân tích một lô số liệu về dự án để đảm bảo tiến độ, chất lượng cho dự án. Và điều quan trọng không kém là bạn cũng chỉ có 24h và cũng phải yêu đương, hỉ nộ ái ố như tất cả mọi người. Vậy nên trong tất cả mọi việc bạn đều phải Nhanh (trừ một số việc Chậm sẽ tốt hơn) và Hiệu quả.

Tố chất thứ ba là Personal Skill. Đây là các kĩ năng mà chúng ta có thể học để có thể cùng team tạo nên thành công của dự án. Nó bao gồm một số các kĩ năng sẽ được giới thiệu chi tiết ở phần tiếp theo.

2. Personal skill gồm những gì?

Để có thể quản lý được team, thì các bạn sẽ cần rèn luyện để có được ít nhất 10 kĩ năng dưới đây

2.1. Leadership

Chúng ta có thể hiểu đơn giản đây là kĩ năng về việc định hướng, dẫn dắt cho team. Điều đó có nghĩa là, bạn phải chỉ rõ cho tất cả các thành viên trong team về mục tiêu mà họ cần hướng tới. Đó không chỉ là sản phẩm mà họ phải hoàn thành cho dự án, mà đó còn là những giá trị về sản phẩm, những kiến thức mà họ tích lũy được, cũng như những mục tiêu trong nghề nghiệp, trình độ chuyên môn mà họ cần đạt được. Từ đó, bạn cũng giúp cho mọi người trong team thấy được giá trị mà họ đang làm khi tham gia dự án. Và để làm được điều này, các bạn có thể sử dụng một số loại “Power” của PM trong team như:

Legitimate: đây là quyền được giao việc cho mọi người trong team cũng như được nhận báo cáo từ mọi người về kết quả công việc. Bạn nên tận dụng nó thì mới đảm bảo được công bằng cho tất cả các thành viên cũng như nắm bắt được các vấn đề của dự án một cách nhanh nhất
Reward: đó là quyền được đề xuất hoặc quyết định thưởng cho các thành viên khi đạt được kết quả công việc tốt. Đây là cách rất quan trọng để khích lệ tinh thần làm việc của tất cả mọi người
Expert: đây là quyền về chia sẻ, hướng dẫn mọi thành viên trong lĩnh vực chuyên môn. Vì thế bạn cần phải giỏi chuyên môn để áp dụng quyền này
Referent: từ này tôi chưa biết dịch thế nào cho hợp lý, nhưng các bạn có thể hiểu nôm na là khi bạn là PM thì mọi thành viên trong team đều coi bạn như một tấm gương để noi theo, nếu bạn chăm chỉ nhiệt tình thì mọi người cũng sẽ như vậy, và ngược lại nếu bạn lười nhác thì, yep, không ai cần phải chăm chỉ cả.
Punishment: trong công việc thì không phải lúc nào mọi người cũng có thể hoàn thành tốt được công việc, kể cả bạn. Và khi mọi người làm việc không tốt, thì bạn hoặc sẽ tiếp tục động viên khuyến khích, hoặc sẽ trách phạt họ. Và đây là quyền của bạn, nhiều khi “Thương cho roi cho vọt” lại tốt

2.2. Team building & Trust building

Đây là một kĩ năng rất quan trọng khi bạn là người dẫn dắt một nhóm để cùng thực hiện một công việc hay mục tiêu nào đấy, kể cả là trong trò chơi chứ không phải chỉ trong công việc. Bạn phải luyện tập khả năng để có thể kết nối được mọi người trong team với nhau và cố gắng giúp cho các thành viên trong team giải quyết 3 vấn đề:

Học hỏi, giúp đỡ lẫn nhau và có thể phụ thuộc vào người khác: bởi vì không ai có thể làm tốt được mọi việc, trong khi sản phẩm là một khối thống nhất nên mọi người sẽ phải phụ thuộc vào các thành viên khác để có thể làm tốt phần việc của mình
Học hỏi cách giao tiếp và giữ động lực khi thất bại: khi bạn dẫn dắt một đoàn người vượt qua sa mạc, thì điều đáng sợ nhất không phải là việc đi sai đường, mà là có thành viên muốn quay trở lại. Khi đó thì có thể tất cả các thành viên khác sẽ sụp đổ cùng.
Tạo môi trường nơi mọi người có thể tin tưởng lẫn nhau: cái này tôi nghĩ là một trong những điều tưởng dễ nhưng lại là khó. Đấy là bạn phải tạo cho mọi người trong team cảm thấy như đang trong một gia đình, thì lúc đó mọi người mới có thể tin tưởng và chia sẻ mọi vấn đề với nhau, cả trong lẫn ngoài công việc

2.3. Motivation

Tạm dịch là khích tướng. Đây là công cụ rất đắc lực để bạn có thể giữ được tinh thần nhiệt huyết cho các thành viên trong team và giúp họ hài lòng với công việc đang làm. Đối với các dự án ngắn (tầm 6 tháng trở lại) thì việc này sẽ giúp cho các thành viên làm việc với hiệu suất cao nhất, còn đối với dự án trung và dài hạn thì nó giúp mọi người không rời bỏ bạn mà đi vì cảm thấy hết động lực. Tuy nhiên, không phải việc khích tướng này trường hợp nào cũng giống trường hợp nào, người thì cần tiền người thì cần thứ khác. Vì vậy bạn nên tìm hiểu qua một số lý thuyết sau:

Tháp nhu cầu Maslow: với mỗi người thì sẽ có tháp nhu cầu như sau: thức ăn chốn ở -> độ an toàn -> được chấp nhận -> được tôn trọng -> được phát triển
Thuyết động lực Herzberg:
- Cần thỏa mãn các yếu tố cơ bản trước: điều kiện làm việc tốt, cuộc sống cá nhân thoải mái, quan hệ đồng nghiệp tốt
- Các yếu tố motivation: thành tích, sự công nhận, phát triển cá nhân, tiến bộ nghề nghiệp
Thuyết kỳ vọng: cung cấp cho mọi người kỳ vọng về một phần thưởng khả thi để khuyến khích
Thuyết thành tích McClelland: mọi người đều cần được khuyến khích bằng cách ghi nhận thành tích Và quan trọng là bạn cần xác định được mỗi người đang ở vị trí nào, có nhu cầu như thế nào để đáp ứng cho từng trường hợp cụ thể, chứ không có ông đang thiếu tiền mà bạn đưa chức tước ra "dụ" thì chưa chắc đã dính.

2.4. Communication

Tạm dịch là cách “giao thông” trong team. Đây là vấn đề thường mọi người ít khi để ý khi bắt đầu dự án hay làm việc cùng nhau, tuy nhiên lại vô cùng quan trọng, đặc biệt là khi team của bạn có quy mô lớn. Có hai bài toán mà bạn sẽ phải giải quyết khi đưa ra cách thức giao tiếp, truyền đạt thông tin giữa các thành viên trong team với nhau hoặc với các bên liên quan, đó là khi bạn ra quyết định, thì bạn cần:

Đảm bảo mọi người hiểu được vì sao phải làm vậy, và hiểu cùng một ý
Cho mọi người thấy được tinh thần cởi mở và thành thật về mọi thứ đã thúc đẩy quyết định của bạn
Minh bạch thông tin để mọi người luôn có được thông tin khi cần. Để làm được điều này thì ngay từ lúc bắt đầu, bạn và team phải thống nhất với nhau về quy tắc giao tiếp, truyền đạt và lưu trữ thông tin rõ ràng.

2.5. Influencing

Có một từ tiếng Việt tôi nghĩ khá hợp với kĩ năng này, đó là Ủy nhiệm. Tức là, thay vì bạn luôn đứng ra giải quyết mọi việc, quyết định mọi thứ trong dự án thì sẽ có 2 vấn đề: 1) bạn không đủ sức, và dự án sẽ phụ thuộc hoàn toàn vào bạn, nếu chẳng may bạn nghỉ một hôm thì cũng là vấn đề lớn và 2) mọi người sẽ không thấy được giá trị của họ khi tham gia dự án. Vì vậy, bạn cần phải giao trách nhiệm cho các thành viên trong team thay bạn giải quyết một số công việc. Tùy vào vai trò của mỗi người mà công việc được giao có mức độ quan trọng khác nhau đối với dự án, ví dụ Technical leader có thể toàn quyền review chất lượng code, assign công việc cho các dev trong team. Và trước khi giao trách nhiệm, bạn cũng phải chỉ rõ tiêu chuẩn thực hiện, tiêu chuẩn đánh giá, kỳ vọng cần đạt được của bạn về công việc đó cho những người được ủy nhiệm hiểu để họ đạt được kết quả tốt nhất.

2.6. Political and cultural awareness

Đối với một team nhỏ và thực hiện một số công việc nhỏ (ví dụ team 5 người chỉ gồm dev và test, chỉ code + test sản phẩm) thì kĩ năng này có thể không cần thiết. Tuy nhiên khi team phải thực hiện nhiều công việc tính chất khác nhau, kết hợp nhiều thành phần, bộ phận cùng tham gia, thì lúc đó bạn sẽ thấy cần biết kĩ năng này. Đó là việc bạn phải thấu hiểu “Background” của từng thành viên trong team, tư duy hay cách suy nghĩ, văn hóa trong công việc của họ (ví dụ Dev sẽ coi các bug về UI là những bug nhỏ nhặt, trong khi đối với Khách hàng thì nó lại rất trầm trọng) để có thể dung hòa, kết nối họ lại với nhau. Không những thế, trường hợp các thành viên trong dự án của bạn đến từ nhiều vùng miền, thậm chí nhiều nước khác nhau thì có thể bạn còn phải thấu hiểu cả văn hóa, lối sống của vùng miền, nước đó để có thể kết hợp họ, giúp họ nói chuyện được với nhau. Cũng khó nhằn đấy, các bạn nên tập uống bia rượu đi là vừa nếu trong team bạn có các chàng trai cô gái miền núi hay miền Tây.

2.7. Decision making

Hiểu nôm na là kĩ năng ra quyết định. Nếu là PM thì trong toàn bộ thời gian hoạt động của dự án, số lần bạn phải ra quyết định là vô số, từ quyết định nhỏ tới quyết định lớn. Đơn giản là khi làm việc thì trong team sẽ có ý kiến này ý kiến khác, và không ai khác bạn phải là người ra quyết định chốt. Tuy nhiên, để ra được quyết định thì không phải lúc nào bạn cũng là người độc đoán bắt mọi người tuân theo, mà cần phải áp dụng khéo léo một số các kĩ thuật sau tùy theo tình huống:

Command: bạn là người ra quyết định theo ý bạn, và thông tin để mọi người thực hiện theo, không ý kiến ý cò gì hết
Consultations: bạn đưa ra quyết định và xin ý kiến tư vấn từ mọi người trong team (hoặc ngoài team) trước khi chốt
Consensus: bạn đưa ra nhiều options và mọi người sẽ chọn cái tốt nhất
Coin flip: bạn và mọi người chọn random

2.8. Negotiation

Kĩ năng thương thảo, là một kĩ năng nên có đối với bất cứ ai, bởi vì trong cuộc sống lẫn công việc thì luôn luôn bạn phải thương thảo với người khác về bất cứ thứ gì. Riêng đối với PM thì cái này lại rất quan trọng, bởi bạn đang đại diện cho team nên mỗi thứ mà bạn đồng ý hoặc không sẽ ảnh hưởng tới rất nhiều người (ví dụ khi bạn đồng ý làm thêm chức năng, update lại theo yêu cầu khách hàng thì anh chị em trong team lại thêm việc, lại OT, nếu như deadline vẫn không đổi thì quả là ác mộng). Ngoài ra, việc xung đột trong team luôn xảy ra liên tục, lúc đó bạn lại phải giữ vai trò trọng tài hòa giải, và làm sao để cả hai bên cùng thỏa mãn là cả một nghệ thuật. Ở điểm này thì để hòa giải tốt, sẽ có 2 lưu ý dành cho các bạn

Lắng nghe nhiều bên, phân tích ý kiến từ nhiều người để nắm bắt được đầy đủ vấn đề cũng như cách nhìn từ các phía khác nhau, bởi không gì là tuyệt đối cả
Khi có sự nhượng bộ từ một phía, thì phải đảm bảo mọi thứ đều rõ ràng cho tất cả các bên. Điều đó sẽ giúp cho phía phải nhượng bộ cũng cảm thấy có phần thoải mái chứ không bị ức chế.

2.9. Coaching

Huấn luyện, đào tạo, hướng dẫn, bạn muốn gọi nó là gì cũng được. Nhưng một khi bạn là PM, là người dẫn dắt team thì bạn phải xác định rằng đây là việc bắt buộc bạn phải làm để giúp mọi thành viên trong team có thể học hỏi và nâng cao trình độ, kĩ năng. Điều đó sẽ vừa giúp cho dự án tốt hơn cả về tiến độ lẫn chất lượng, đồng thời vừa giúp mọi người thấy mình được trưởng thành hơn, nâng cao trình độ nghề nghiệp hơn, từ đó sẽ gắn bó hơn với team và công ty. Còn về việc bạn sẽ coaching mọi người cái gì? Có rất nhiều thứ bạn có thể chia sẻ với mọi người. Ví dụ đối với toàn bộ các thành viên, thì bạn có thể hướng dẫn từ cái to to như về quy trình thực hiện dự án, cách làm việc, cách trao đổi,… đến cái nhỏ nhỏ như cách viết mail hay chia sẻ các kinh nghiệm đau thương từ các dự án bạn đã từng làm. Còn đối với từng nhóm thành viên, thì bạn có thể chia sẻ các kinh nghiệm về chuyên môn mà bạn có. Ngoài ra, đối với các bạn leader kế cận bạn trong team, bạn còn có thể hướng dẫn họ chuyên sâu hơn về những phần việc quản trị dự án, để từ đó họ có thể buffer cho bạn. Phương châm của tôi luôn là, nếu có thể thì hãy chia sẻ, và hãy cố gắng “nhờ” người khác làm hộ bạn một số công việc để bạn rảnh tay làm việc quan trọng hơn.

2.10. Conflict management

Đây là kĩ năng cuối của top 10 kĩ năng cần có của PM, tuy nhiên trên thực tế tôi nghĩ bạn sẽ phải sử dụng nhiều nhất, bởi conflict xuất hiện khắp nơi. Các nhà lý thuyết học đã tổng kết hộ chúng ta một số nguyên nhân chính gây ra conflict như (con trên thực tế thì chỉ có bạn mới kiểm chứng được):

Resources: cái này dễ xảy ra khi dự án có tài nguyên dùng chung (từ người ngợm cho tới thiết bị), mà tất cả các bên đều muốn giải quyết việc của mình xong trước, thế nên bạn không sắp xếp và hòa giải tốt là cũng hơi mệt đấy
Priorities: cái này thường xuất hiện khi độ ưu tiên công việc của các bên liên quan không rõ ràng, ví dụ sếp bảo cần làm cái này trước, trong khi khách hàng lại giục làm cái kia, technical leader lại bảo phải xong cái kìa thì mới làm được hai cái trên. Do đó để xử cái này thì chỉ có cách các bên ngồi lại và chốt rõ ràng.
Schedules: cái này cũng hay xảy ra, đặc biệt là với khách hàng khi chưa thống nhất rõ ràng về estimation, hoặc trong lúc làm lại có change request nhưng không thông tin rõ
Personalities: cái này thường sẽ xảy ra nhiều trong nội bộ team, khi mỗi người đều là một cái tôi to đùng và không ai chịu ai
Cost: cái này cũng tương tự schedules nhưng là về chi phí thực hiện dự án
Technical opinions: cái này cũng rất hay xảy ra, đặc biệt là với dự án khó, sử dụng nhiều công nghệ, tập hợp nhiều siêu nhân kĩ thuật. Lúc đó thì lắm thầy nhiều ma là quá bình thường. Vậy thì, khi xảy ra các conflict, bạn với vai trò là người đứng giữa, sẽ phải làm gì để giải quyết đây, “lỳ hay tính?”

Các chuyên gia lý thuyết cũng đã cho chúng ta 6 kĩ thuật như sau:

Confronting: đối đầu với vấn đề và cùng mọi người tìm kiếm nguyên nhân conflict để giải quyết triệt để. Đây cũng là cách hiệu quả nhất để giải quyết, nhưng thường cũng là cách khó nhất
Compromise: cách này có nghĩa là các bên sẽ phải thỏa hiệp với nhau để giữ hòa bình, anh nín tí tôi nhịn tí. Cách này sẽ không giải quyết được trọn vẹn vấn đề và có thể là “lose-lose solution” vì cả hai bên cùng ức chế, tuy nhiên ưu điểm của nó là mọi người có thể thống nhất cách giải quyết conflict nhanh chóng
Collaborating: đây là cách tập hợp tất cả ý kiến của mọi người trong team để có được cái nhìn đầy đủ, khách quan của người trong cuộc lẫn ngoài cuộc, từ đó có thể đưa ra cách giải quyết tương đối ổn thỏa do có được ý kiến đồng thuận và cam kết của cả team
Smoothing: đây là cách mà chung ta hay gọi là chuyện to thành nhỏ, nhỏ thành không có gì. Tức là các bạn cố làm giảm nhẹ sự trầm trọng của vấn đề để mọi người bớt căng thẳng, không gây mất tập trung và thời gian của mọi người vào công việc của họ. Sau đó bạn sẽ giải quyết việc này vào lúc khác hợp lý hơn
Forcing: đây là lúc bạn quyết đoán, đưa ra quyết định một thắng một thua luôn. Tất nhiên sau đó nếu người thua có thể rời bạn mà đi thì bạn cũng không nên ngạc nhiên quá .
Withdrawal: đến cả Tôn Tử có 36 kế mà vẫn phải dùng kế né tránh này thì việc gì bạn không dùng. Nếu trường hợp mà bạn biết là chưa thể giải quyết được thì tốt nhất nên tìm cớ né tránh nó, để đến một lúc khác khi những cái đầu nóng đã nguội thì lại tiếp tục.

Lời kết

Như vậy, đến đây là tôi cũng đã chia sẻ sơ lược cho các bạn một số tố chất và kĩ năng cơ bản bạn nên có/hoặc nên học để có thể trở thành một PM tốt, dẫn dắt mọi thành viên trong team hoàn thành xuất sắc dự án. Và thực ra cái quan trọng nhất không phải là bạn hoàn thành tốt dự án là đủ, mà là việc bạn có thể dẫn dắt team đi tới đâu, có thể làm tiếp những dự án lớn hơn tới mức độ nào, cũng như các thành viên trong team bạn trưởng thành thế nào. Đấy mới là điều mà bất cứ người dẫn dắt nào cũng nên hướng tới. Yep, ở các bài tiếp theo, tôi sẽ chia sẻ về các khái niệm cơ bản cũng như các công việc cần phải chuẩn bị hay thực hiện dành cho PM khi chạy dự án, mời các bạn đón xem. Rất hy vọng sẽ được các cao nhân chỉ giáo thêm và đặc biệt là chia sẻ từ thực tế của mọi người.

Keep moving \m/

Via Viblo