Giao tiếp tồi phá hủy sự nghiệp Project Manager
“Anh có thể nói, không giao tiếp được với khách hàng 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 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ề: Thất bại anh đã trải qua và ...
“Anh có thể nói, không giao tiếp được với khách hàng 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 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ề:
- 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 một Project Manager
- Lời khuyên anh dành cho các bạn Project Manager hiện tại và tương lai
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 địa điểm ăn uố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ạn bè thành lập Silver Lining Ltd., công ty chuyên phát triển ứng dụng di động Android và iOS. Anh làm developer, nhưng từ từ anh giảm dần thời gian coding và chuyển sang quản lý. Lí do là anh nhận ra trong team 10 người nhưng không ai đứng ra đảm nhận vai trò quản lý dự án cả, ai cũng chỉ chăm chăm vào code, dự án xong nhưng không đồng nghĩa team mình thành công, do không có ai làm chốt chặn cuối cùng và chốt đầu tiên phong. Sau khoảng một năm thì anh chuyển hẳn sang quản lý và anh là người đứng ra liên hệ với khách hàng nhiều hơn. Hiện tại anh đang là Project Manager (PM) cho Studio 60.
Anh có thể chia sẻ công việc hàng ngày của một PM là gì không ạ?
90% việc của PM 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. Xét về vai trò thì anh kiêm luôn việc của BA là nhận request, trao đổi, thương lượng mọi thứ với khách hàng.
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 PM?
Theo anh, PM 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 gian làm lập trình viên giúp anh hiểu khó khăn của các bạn developer, từ đó anh giúp họ vượt qua để cùng đưa dự án đến với thành công. 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 thời gian đầu làm PM.
Project đầu tiên làm PM, do cái tôi “xuất thân kỹ thuật” nên anh đưa ra solution và áp đặt các bạn developer làm theo khiến họ không phát huy được 100% khả năng. Ngoài ra, do lần đầu làm PM cho một dự án lớn, chưa có kinh nghiệm làm việc nhiều với khách hàng dẫn đến dự án thất bại, công ty bị lỗ, khách hàng 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 ý kiến. Từ đó, anh rút ra bài học là nên hỏi các 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 các bạn chưa tìm được hướng giải quyết phù hợp thôi.
Theo anh, đâu là điểm khác biệt lớn nhất giữa developer và PM?
Đ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 công việc được giao, code sạch, ít bug, giao tiếp tốt với team.
Giá trị của PM là team làm việc hiệu quả, khách hàng vui vẻ, dự án hoàn thành đúng hạn, đúng ngân sách, đúng yêu cầu. Một dự án thất bại, bất kể do lỗi của ai thì PM vẫn là người chịu trách nhiệm lớn nhất, và không được đổ lỗi.
Anh Khánh đứng ngoài cùng bên phải, cùng đồng nghiệp ở Studio 60.
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. Làm một PM, em phải có mục quản lý rủi ro 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 đối mặt với rủi ro về nhân lực. Trong dự án đó, anh nhắm thời gian hoàn thành cả project là 10 tuần. Nhưng đến tuần thứ 8 thì chỉ mới hoàn thành 60% công việc do dự án khá lớn mà lại ít nguồn lực.
Trước khi bắt đầu, anh đã đưa ra ba hướng giải quyết cho rủi ro này: 1) hỏi các bạn developer trong team có chịu làm thêm giờ không; 2) thương lượng với khách hàng về việc dời thời gian bàn giao sản phẩm; 3) nếu khách hàng không đồng ý dời thì cam kết giao sản phẩm với những chức năng chính, và bổ sung các chức năng phụ trong vòng 3 tuần.
Cuối cùng, do thông báo sớm và nói thật với khách hàng, nên họ đã đồng ý cho dời deadline, team cũng làm thêm giờ, dự án bị trễ nhưng về tổng thể khách hàng vẫn vui vẻ với kết quả cuối cùng, team cũng cảm thấy thoải mái.
Quản lý rủi ro không chỉ là kỹ năng cần thiết của PM, mà còn là của developer nữa.
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 có thể xảy ra ở mọi khâu. PM đưa ra kế hoạch dựa trên đánh giá từng công việc nhỏ của developer. Ví dụ developer đang estimate một feature, thì muốn hoàn thành feature, ngoài code còn cần học document, sửa bug, kiểm tra tất cả 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 các bạn dự trù thời gian, cần tính toán cho tất cả các công việc trên. Thông thường thì mọi người chỉ đánh giá thời gian code mà không tính đến thời gian 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 PM đã 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.
Đến cuối cùng, khách hàng vẫn không chịu solution anh tư vấn thì anh gửi cho họ một email bảo là: “Sẽ có hậu quả A, B, C có thể xảy ra, nếu anh vẫn muốn làm thì phải chuẩn bị tâm lý đối diện các hậu quả đó. Nếu xảy ra vấn đề gì thì anh phải chịu 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 PM trong tương lai?
Anh Khánh tại Agile Tour 2014.
Vai trò lớn nhất của PM 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ụ 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 khách hàng ở 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 công việc.
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ất cả 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 phát triển, team không phát triển, môi trường làm việc không vui vẻ. Không ai muốn làm trong một môi trường 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 một PM?
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 yêu cầu của khách hàng, mà còn ở quản lý sự cố. Lúc trước anh có một dự án sắp release mà vẫn đầy bug. Khi đó, giao tiếp là cách anh nói để khách hàng thông cảm với mình, thời điểm nói để khách hàng không bị bất ngờ, đồng thời cũng là cách nói chuyện với team để mọi người đồng lòng làm việc nhằm hoàn thành sản phẩm sớm nhất.
Lúc đó, anh báo với khách hàng trước ngày release 3 tuần, và đảm bảo là sẽ hoàn thành dự án trong 16 tuần, thay vì 12 tuần như cam kết ban đầu. Đồng thời, sau 12 tuần, anh sẽ deliver 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 khách hàng, 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 PM cho một công ty ODC hoặc các công ty lớn, em phải làm việc thường xuyên với khách hàng nước ngoài. Nếu em làm cho các công ty nhỏ với dự án tầm trung, kéo dài khoả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 PM cũng đều cần khả năng tiếng Anh tốt. Anh có thể nói, không giao tiếp được với khách hàng 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 khách hàng.
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 khách hàng đưa yêu cầu, anh bạn đó cứ ok, ok, yes, yes. Sau vài tháng, khi giao sản phẩm thì vỡ lẽ ra là khách hàng 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 khách hàng, họ không dùng được sản phẩm, đó là một dự án thất bại.
Theo anh, có thử thách nào mà mọi PM đều phải đối mặt?
Thử thách mà anh nghĩ PM 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 cập, làm server chết và khách hàng gọi đến “cháy máy” để hỏi anh xem phải làm sao. Lúc đó, anh, một bạn tech lead, và một bạn developer phải thức đến khuya để đảm bảo là server hoạt động lại bình thường. Đó là “vấn đề” tốt, vì nó chứng tỏ là app mình làm thành công. Nhưng đi kèm vẫn là thử thách làm sao để luôn đảm bảo 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 PM muốn lấy PMP.
