Giao tiếp “tồi” sẽ phá hủy sự nghiệp của một Project Manager (PM)?

Project Manager là người quản lý dự án, thường được viết tắt bằng PM. 90% công việc Project Manager liên quan đến giao tiếp như hoạch định, giải quyết sự cố, quản lý rủi ro, giao tiếp với khách hàng. 

Đọc bài phỏng vấn của ITviec với anh Phan Duy Khánh – Project Manager của Studio 60 – để nghe anh chia sẻ về:

• Project Manager là gì? Công việc hàng ngày của một Project Manager?
• Thất bại anh đã trải qua và bài học về giao tiếp giúp anh thành công như hôm nay
• Những thử thách thường gặp của Project Manager
• Lời khuyên anh dành cho các bạn Project Manager hiện tại và tương lai

Xem thêm việc làm Project Manager trên ITviec

Tiểu sử : Sau khi tốt nghiệp trường FPT ngành CNTT, anh Khánh làm ở FPT Software với vị trí ASP.NET Developer. Sau đó, anh cùng vài người bạn làm một startup app. Cụ thể là một ứng dụng tìm kiếm khu vực siêu thị nhà hàng, giống Foody, nhưng sau sáu tháng thì nó thất bại .
Sau đó thì team giải tán, anh cùng bè bạn xây dựng Silver Lining Ltd., công ty chuyên tăng trưởng ứng dụng di động Android và iOS. Anh làm developer, nhưng từ từ anh giảm dần thời hạn coding và chuyển sang quản trị .
Lí do là anh nhận ra trong team 10 người nhưng không ai đứng ra tiếp đón vai trò quản trị dự án cả. Ai cũng chỉ chăm chăm vào code, dự án xong nhưng không đồng nghĩa tương quan team mình thành công xuất sắc do không có ai làm chốt chặn sau cuối và chốt tiên phong phong .
Sau khoảng chừng một năm thì anh chuyển hẳn sang quản trị và anh là người đứng ra liên hệ với người mua nhiều hơn. Hiện tại anh đang là Project Manager – quản trị dự án cho Studio 60 .

Anh có thể chia sẻ công việc hàng ngày của một Project Manager là gì không ạ?

90 % việc của Project Manager tương quan đến tiếp xúc như hoạch định, xử lý sự cố, quản trị rủi ro đáng tiếc, tiếp xúc với người mua. Xét về vai trò thì anh kiêm luôn việc của Business Analyst ( BA ) là nhận request, trao đổi, thương lượng mọi thứ với người mua .

Anh có nghĩ là việc xuất thân từ developer đã giúp anh rất nhiều trong việc trở thành Project Manager?

Theo anh, Project Manager là người làm mọi thứ có thể để đảm bảo dự án thành công. Dự án thành công theo định nghĩa của anh là: hoàn thành đúng hạn, trong ngân sách cho phép, đúng scope, team vui vẻ, khách hàng hài lòng.

Vì vậy, thời hạn làm lập trình viên giúp anh hiểu khó khăn vất vả của những bạn developer, từ đó anh giúp họ vượt qua để cùng đưa dự án đến với thành công xuất sắc. Nhưng đồng thời, có nền tảng về kỹ thuật cũng gây trở ngại cho anh trong khoảng chừng thời hạn đầu làm Project Manager .
Dự án tiên phong làm Project Manager, do cái tôi “ xuất thân kỹ thuật ” nên anh đưa ra giải pháp và áp đặt những bạn developer làm theo khiến họ không phát huy được 100 % năng lực .
Ngoài ra, do lần đầu làm Project Manager cho một dự án lớn, chưa có kinh nghiệm tay nghề thao tác nhiều với người mua dẫn đến dự án thất bại, công ty bị lỗ, người mua không hài lòng .
Anh nhìn lại mình khi còn là một developer, anh cũng muốn được cấp trên lắng nghe quan điểm. Từ đó, anh rút ra bài học kinh nghiệm là nên hỏi những bạn developer và Tech Lead về giải pháp của họ trước .
Anh vẫn có giải pháp của anh, nhưng anh chỉ dùng nó để hướng dẫn khi những bạn chưa tìm được hướng xử lý tương thích thôi .

Theo anh, điểm khác biệt lớn nhất giữa developer và Project Manager là gì?

Điểm quan trọng nhất anh nghĩ là cách tạo ra giá trị.

Giá trị của developer là hoàn thành xong việc làm được giao, code sạch, ít bug, tiếp xúc tốt với team .
Giá trị của Project Manager là team thao tác hiệu suất cao, người mua vui tươi, dự án triển khai xong đúng hạn, đúng ngân sách, đúng nhu yếu. Một dự án thất bại, bất kể do lỗi của ai thì Project Manager vẫn là người chịu nghĩa vụ và trách nhiệm lớn nhất, và không được đổ lỗi .

Có cách nào để mình giảm thiểu rủi ro trong việc quản lý dự án không anh?

Dự án nào cũng có rủi ro đáng tiếc. Làm một Project Manager, em phải có mục quản trị rủi ro đáng tiếc cho mọi dự án .

Tuy nhiên, định nghĩa của anh về “rủi ro” là những cái có thể xảy ra. Tức là nó có thể giúp dự án hoàn thành nhanh hơn hoặc chậm hơn. Có nhiều loại rủi ro: nhân lực, kỹ thuật, khách hàng, và quy trình.

Lúc trước anh từng đương đầu với rủi ro đáng tiếc về nhân lực. Trong dự án đó, anh nhắm thời hạn triển khai xong cả project là 10 tuần. Nhưng đến tuần thứ 8 thì chỉ mới triển khai xong 60 % việc làm do dự án khá lớn mà lại ít nguồn lực .
Trước khi khởi đầu, anh đã đưa ra ba hướng xử lý cho rủi ro đáng tiếc này :

1 ) hỏi những bạn developer trong team có chịu làm thêm giờ không
2 ) thương lượng với người mua về việc dời thời hạn chuyển giao mẫu sản phẩm
3 ) nếu người mua không đồng ý chấp thuận dời thì cam kết giao mẫu sản phẩm với những công dụng chính, và bổ trợ những tính năng phụ trong vòng 3 tuần .

Cuối cùng, do thông tin sớm và nói thật với người mua, nên họ đã chấp thuận đồng ý cho dời deadline. Team cũng làm thêm giờ, dự án bị trễ nhưng về tổng thể và toàn diện người mua vẫn vui tươi với tác dụng sau cuối, team cũng cảm thấy tự do .

Quản lý rủi ro không chỉ là kỹ năng cần thiết của Project Manager, mà còn là của developer.

Vì sao quản lý rủi ro lại là kỹ năng cần thiết cho developer vậy anh?

Rủi ro hoàn toàn có thể xảy ra ở mọi khâu. Project Manager đưa ra kế hoạch dựa trên nhìn nhận từng việc làm nhỏ của developer .
Ví dụ developer đang estimate một feature, thì muốn triển khai xong feature, ngoài code còn cần học document, sửa bug, kiểm tra tổng thể test case …

Cụ thể hơn, trước mỗi dự án, anh và team đều đưa ra một định nghĩa gọi là “definition of done”.

Ví dụ một feature như thế nào thì gọi là done? Chính là code xong không có bug, đã được chính developer đó test tất cả test case, được commit lên server, đã đưa lên Dev server để QC test, được technical lead review code và duyệt.

Lúc những bạn dự trù thời hạn, cần đo lường và thống kê cho tổng thể những việc làm trên. Thông thường thì mọi người chỉ nhìn nhận thời hạn code mà không tính đến thời hạn mình sửa bug, chuyển qua lại giữa tester và developer .

Anh từng mắc phải sai lầm nào và anh học được gì từ nó?

Một trong những dự án đầu tiên anh làm Project Manager đã thất bại. Sai lầm lớn nhất là anh không kiểm soát được mong đợi của khách hàng.

Họ nói gì anh cũng YES, YES, YES. Sau một hồi toàn YES, nó dẫn đến việc anh làm dự án hoàn toàn theo ý khách hàng, nhưng ra đời lại là một sản phẩm tồi, họ không dùng được. Lúc đó khách hàng quay ngược lại hỏi anh vì sao lúc trước anh không tư vấn cho họ.

Anh rút ra bài học là khách hàng không phải lúc nào cũng đúng. Anh cần phải cứng để nói “NO” và tư vấn cho họ. Trong vài dự án tiếp theo, thấy mình không đủ kiến thức kỹ thuật để thuyết phục thì anh đi cùng với Technical Lead, không đủ kiến thức về thiết kế thì đi cùng với designer để nói chuyện với khách hàng.

Tìm hiểu thêm : Làm sao để trở thành 1 Technical Lead ?

Đến ở đầu cuối, người mua vẫn không chịu giải pháp anh tư vấn. Anh sẽ gửi cho họ một email bảo là : “ Sẽ có hậu quả A, B, C hoàn toàn có thể xảy ra, nếu anh vẫn muốn làm thì phải sẵn sàng chuẩn bị tâm ý đối lập những hậu quả đó. Nếu xảy ra yếu tố gì thì anh phải chịu nghĩa vụ và trách nhiệm, vì chúng tôi đã tư vấn rồi. ”

Anh có lời khuyên nào dành cho các bạn muốn trở thành Project Manager trong tương lai?

Vai trò lớn nhất của Project Manager là quản lý người khác, vì vậy anh nghĩ cái đầu tiên là bạn phải quản lý được mình. Khi bạn quản lý được chính mình rồi thì bạn mới quản lý được người khác.

Cách đơn giản nhất để quản lý bản thân là làm kế hoạch tuần và to-do list trong ngày để hoàn thành mọi việc đúng hạn.

Ví dụ ngày hôm nay, anh ghi trong to-do list của anh là

1 ) review project A với team. Net
2 ) phỏng vấn với ITviec
3 ) họp với một người mua ở Sing lúc 14 : 00

Lưu ý là to-do list này em cũng phải đánh số thứ tự theo mức độ ưu tiên của việc làm .

Lời khuyên thứ hai của anh là các bạn nên học cách “say NO.” Như câu chuyện anh chia sẻ ở trên, hậu quả của việc không kiểm soát được kì vọng của khách hàng chính là dự án thất bại. Vì vậy, cần tập luyện cách nói “không” với những yêu cầu mình thấy không khả thi.

Cuối cùng, cá nhân anh nghĩ developer là những người rất tài năng. Bạn nên lắng nghe, hỏi ý kiến của họ và hướng dẫn họ đi đến hướng giải quyết phù hợp.

Nếu bạn áp đặt giải pháp của bạn lên developer, thì tổng thể chỉ dừng lại ở tầm hiểu biết của bạn. Việc áp đặt sẽ khiến dự án không tăng trưởng, team không tăng trưởng, môi trường tự nhiên thao tác không vui tươi. Không ai muốn làm trong một môi trường tự nhiên như vậy cả .

Anh có thể cho biết những kỹ năng nào là quan trọng nhất đối với công việc quản lý dự án?

Quan trọng nhất là em phải có kỹ năng lên kế hoạch và kỹ năng giao tiếp, vì 90% thời gian của em là giao tiếp với khách hàng và team.

Giao tiếp không chỉ dừng lại ở việc ghi nhận đúng nhu yếu của người mua, mà còn ở quản trị sự cố .
Lúc trước anh có một dự án sắp release mà vẫn đầy bug. Khi đó, kiến thức và kỹ năng tiếp xúc biểu lộ ở việc anh nói như thế nào để người mua thông cảm, thời gian nào là thích hợp để nói ra mà họ không cảm thấy giật mình. Đồng thời, đó còn là cách trò chuyện với team để mọi người đồng lòng thao tác nhằm mục đích triển khai xong mẫu sản phẩm sớm nhất .
Lúc đó, anh báo với người mua trước ngày release 3 tuần, và bảo vệ là sẽ hoàn thành xong dự án trong 16 tuần, thay vì 12 tuần như cam kết khởi đầu. Đồng thời, sau 12 tuần, anh sẽ deliver mẫu sản phẩm với tính năng A, B, C trước .
Ngoài ra, trước khi thương lượng với người mua, anh đã thương lượng với team trước xem mọi người chịu làm thêm giờ không, hay cần outsource ra ngoài, và mọi người đều đồng lòng làm thêm giờ .

Thứ hai là em phải có tiếng Anh tốt. Tiếng Anh tốt giúp em có khả năng thăng tiến nhanh hơn đến vị trí Program Manager, Program Director, General Manager… Đây là những nấc thang tiếp theo, sau vị trí Project Manager.

Ngoài ra, nếu em làm Project Manager cho một công ty ODC hoặc những công ty lớn, em phải thao tác liên tục với người mua quốc tế .
Nếu em làm cho những công ty nhỏ với dự án tầm trung, lê dài khoảng chừng 3-6 tháng và team dưới 10 người thì cũng không có BA đi lấy requirement cho em, mà chính em phải làm luôn việc đó .
Nói tóm lại, dù làm ở công ty nào thì một người quản trị dự án cũng đều cần năng lực tiếng Anh tốt. Anh hoàn toàn có thể nói, không tiếp xúc được với người mua sẽ đưa em tới hai hậu quả : 1 ) dự án của em trở thành thảm họa ; 2 ) em mất người mua .
Lúc trước bạn anh có làm dự án fix scope, fix time, fix budget theo Waterfall. Do tiếng Anh không vững nên lúc người mua đưa nhu yếu, anh bạn đó cứ ok, ok, yes, yes. Sau vài tháng, khi giao mẫu sản phẩm thì vỡ lẽ ra là người mua muốn A mà mình lại làm B .
Khách hàng không hài lòng, không trả tiền cho milestone cuối, mình mất người mua, họ không dùng được mẫu sản phẩm, đó là một dự án thất bại .

Xem thêm : Bí quyết để trở thành Project Manager giỏi

Theo anh, có thử thách nào mà mọi Project Manager đều phải đối mặt?

Thử thách mà anh nghĩ Project Manager nào cũng phải trải qua chính là thử thách về việc đảm bảo chất lượng của dự án.

Ví dụ hồi trước anh có làm dự án để launching một app. Nhưng trong một đêm, app đó lên đến hàng chục nghìn lượt truy vấn, làm server chết và người mua gọi đến “ cháy máy ” để hỏi anh xem phải làm thế nào .
Lúc đó, anh, một bạn Tech Lead và một bạn developer phải thức đến khuya để bảo vệ là server hoạt động giải trí lại thông thường. Đó là “ yếu tố ” tốt, vì nó chứng tỏ là app mình làm thành công xuất sắc. Nhưng đi kèm vẫn là thử thách làm thế nào để luôn bảo vệ chất lượng của dự án .

Anh có tham khảo resource/ ebook nào trong suốt sự nghiệp của mình không?

Một số sách anh đọc thấy hay là:

• The One Minute Manager. Sách này ngắn nhưng đề cập đến những điều kỹ năng quan trọng cho người làm manager.
• Vì anh làm Scrum nên anh đọc cuốn Scrum Primer để học thêm về Scrum.
• Software in 30 Days. Sách này là về Agile, nó giúp anh hiểu hơn về Scrum Framework.
• Ngoài ra còn có PMBOK, sách gối đầu cho mọi Project Manager muốn lấy PMP.

Bạn nghĩ rằng những chia sẻ này sẽ giúp ích cho bạn bè hoặc đồng nghiệp? Đừng quên nhấn nút Share bên dưới nhé!

Bạn cũng có thể tham khảo một số việc làm Manager trên website ITviec.

Source: https://thevesta.vn
Category: Nhà Đất