Bài học từ một Quản lý dự án Việt

“Giao tiếp là một trong những kỹ năng quan trọng nhất của một Project Manager (PM), nhưng cũng là điểm yếu của nhiều Developer. Lúc trước, do không giao tiếp tốt, anh đã phải trả một bài học đắt giá.”

Đọc bài phỏng vấn của ITviec với anh Nguyễn Sĩ Hoàng – Managing Director của Balance Internet Vietnam – để nghe anh chia sẻ về:

• Những con đường mà anh đã chọn để trở thành một PM
• Thất bại từng trải qua và bài học rút ra trên con đường của một PM
• Những lời khuyên + tips của anh dành cho các bạn muốn trở thành một PM

Tiểu sử: Khi mới tốt nghiệp, anh làm trong một công ty startup phát triển phần mềm bán lẻ với vai trò là Developer. Sau đó anh sang công ty Novellus để làm Developer và Business Analyst. Rồi anh chuyển sang FPT công tác với vai trò Solution Architect. Tiếp đến, anh chuyển sang làm Project Manager của tập đoàn EVN. Đây là một bước chuyển lớn từ kỹ thuật sang quản lý của anh. Cuối cùng, anh chuyển sang Balance Internet Vietnam ở vị trí Project Manager. Hiện tại anh đang làm Managing Director của Balance Internet Vietnam.

Anh có thể cho biết công việc và trách nhiệm thường ngày của một PM là gì?

Công việc thường ngày của một PM bao gồm:

-Lập kế hoạch cho dự án, kế hoạch nhân sự cho dự án.

-Theo dõi tiến độ của dự án, báo cáo tình trạng công việc cho khách hàng và các bên liên quan.

-Trao đổi với mọi người trong dự án và với khách hàng để nắm bắt được tình hình và yêu cầu của khách hàng.

-Quản lý đội dự án, ví dụ như động viên tinh thần anh em, giải quyết những mâu thuẫn trong nội bộ, giải quyết vấn đề nói chung trong quá trình việc.

-Báo cáo, ghi nhận thống kê cần thiết để rút kinh nghiệm.

Anh trải qua nhiều vị trí: Developer → Programmer Analyst → Project Manager → Solution Architect → Project Manager. Việc chọn lựa những career path khác nhau đã giúp anh như thế nào trên con đường trở thành một PM?

Việc trải qua nhiều career path khác nhau giúp ích rất nhiều cho công việc hiện tại của anh, vì anh hiểu Developer suy nghĩ như thế nào, anh hiểu công việc của người Solution Architect ra sao… Nó giúp anh trong việc quản lý team dự án của mình, và trao đổi với các bạn thuận lợi, dễ dàng hơn, vì anh hiểu tâm lý và cách suy nghĩ của họ.

Vậy thì có phải là nếu mình muốn trở thành PM thì mình nên trải qua nhiều vì trí khác nhau không anh?

Anh nghĩ cái đó là lợi thế, không phải bắt buộc. Một PM không nhất thiết phải có technical background, nhưng nếu có technical background thì là lợi thế lớn, công việc nhanh hơn nhiều.

Nhiệm vụ chính của một PM là quản lý dự án để có thể hoàn thành đúng thời hạn, trong ngân sách cho phép của dự án, với lượng nhân sự hữu hạn của mình. Vì vậy bạn không nhất thiết phải có hiểu biết kỹ thuật. Nhưng nếu bạn có technical background thì bạn tiết kiệm được nhiều thời gian trong trao đổi công việc.

Theo anh, có quan niệm nào về một PM nhưng lại là quan niệm sai lầm?

Thường thì Developer nghĩ rằng các bạn làm xong là hoàn thành trách nhiệm của mình, đẩy việc kiểm tra kết quả, chất lượng công việc cho PM, nhưng thực tế thì đấy không phải là nhiệm vụ của PM, mà là nhiệm vụ của chính Developer.

Ngoài ra, PM là một chức vị khá gây nhầm lẫn. Khi dịch ra tiếng Việt, mọi người nghĩ manager là vị trí cấp cao thuộc bộ máy tổ chức, nhưng sự thật không phải vậy. Trong một dự án, PM không có nhiều quyền đối với các thành viên của dự án. Nói ví dụ như anh là PM thì anh không có quyền tăng hoặc giảm lương của các thành viên trong dự án, mà phải là quản lý trực tiếp của họ.

Anh nghĩ một PM cần những kỹ năng nào?

Thứ nhất là quản lý công việc. Ví dụ anh giao mười việc cho một bạn nhưng bạn đó làm bất cứ công việc nào bạn thích, không theo thứ tự. Dẫn đến kết quả có những việc quan trọng, cần gấp không được hoàn thành đúng hạn. Nếu bạn đó biết quản lý công việc, sắp xếp theo thứ tự quan trọng, mức độ ưu tiên của từng công việc, bạn đó có thể hoàn thành tất cả mọi việc đúng hạn. Và nếu bạn ấy quản lý tốt, thì sẽ biết công việc này cần những kỹ năng nào, khi bạn ấy thiếu những kỹ năng mà người khác có thể hỗ trợ được thì bạn ấy sẽ sớm tìm được người hỗ trợ mình.

Thứ hai là kỹ năng lập kế hoạch. Đầu ngày đến công ty bạn phải biết hôm nay mình cần làm những việc gì thì năng suất làm việc mới cao, bỏ được những thời gian chết. Kỹ năng này cũng giúp tránh tình trạng dồn việc đến cuối dự án, khi đã đến deadline mới nhận ra là vẫn còn rất nhiều việc phải hoàn thành.

Thứ ba, kỹ năng chia đúng người đúng việc giúp tốc độ làm việc của team nhanh hơn. Ví dụ anh giao việc cho bạn có kỹ năng phù hợp thì chỉ mất một ngày để hoàn thành. Kinh nghiệm thực tế là khi anh giao sai người, bạn ấy mất mười ngày để xong task. Kết quả dẫn đến không hoàn thành đúng deadline.

Thứ tư là kỹ năng quản lý thời gian. Kỹ năng này không tốt thì thường xuyên làm việc OT. Quản lý thời gian tốt liên quan đến vấn đề kỷ luật cá nhân. Ví dụ anh đặt ra kế hoạch trong hôm nay cần phải hoàn thành mười đầu việc thì khi bắt đầu làm, anh xem xét mỗi đầu việc cần làm bao nhiêu lâu, và sau đó bắt đầu với những việc quan trọng. Tránh để những yếu tố bên ngoài như là: đang làm, đang suy nghĩ thì có người nhảy vào chat hay là sang Facebook để đọc news feed… ảnh hưởng đến năng suất làm việc.

Thứ năm là kỹ năng giao tiếp. Thông thường anh phải giao tiếp nhiều với khách hàng để làm rõ yêu cầu dự án. Đôi khi khách hàng họ không nói rõ yêu cầu ngay từ đầu. Anh cần trao đổi thường xuyên với họ để nắm yêu cầu chính xác. Ngoài ra anh còn trao đổi với các thành viên trong team, để nắm tiến độ dự án có xảy ra vấn đề gì dẫn đến chậm trễ không. Phát hiện sớm vấn đề thì có thể giải quyết sớm.

Trong thời gian đầu khi làm PM, anh từng gặp một khách hàng của Mỹ, nhưng khách hàng đó có một nhóm là người Ấn Độ. Tiếng Anh của họ hơi khó nghe. Việc giao tiếp với khách hàng lúc đó phụ thuộc vào bạn BA (Business Analyst). Bạn ấy đi nói chuyện với khách hàng và lấy yêu cầu về. Với vai trò PM, anh hoàn toàn tin tưởng bạn BA đó, và làm project theo đúng yêu cầu mà bạn ấy viết trong tài liệu. Nhưng đến cuối dự án, khi anh nói chuyện, demo với khách hàng sản phẩm thì biết nó không hoàn toàn đúng yêu cầu của khách hàng. Nếu anh nói chuyện với khách hàng thường xuyên hơn thì anh đã biết là yêu cầu chưa đúng ngay từ đầu, tránh được việc phải làm đi làm lại.

Trong quá trình làm PM, anh từng mắc phải sai lầm nào và anh học được gì từ nó?

Lúc trước có một project anh tiếp nhận từ PM khác. Anh gặp vấn đề là deadline khách hàng đã đến gần mà dự án vẫn còn nhiều thứ chưa hoàn thành. Vì vậy dù chất lượng công việc không đủ đảm bảo nhưng anh vẫn phải giao cho khách hàng đúng hạn.

Khi khách hàng sử dụng thì gặp rất nhiều lỗi. Họ không hài lòng với sản phẩm. Và họ quay lại bắt anh sửa lỗi, làm lại sản phẩm để nó đạt được chất lượng mà họ mong muốn. Thời gian làm dự án cũng vì vậy mà phải kéo dài nhiều hơn.

Anh rút ra kinh nghiệm lớn nhất chính là phải giao tiếp thường xuyên và thành thật với khách hàng. Khi anh nói thật với họ rằng là thời gian này không đủ để cho ra đời sản phẩm đúng mong muốn của họ, 1) là họ hiểu, thông cảm, cho mình kéo dài thời gian hơn để đảm bảo chất lượng sản phẩm; 2) là nếu họ không cho thêm thời gian thì chúng ta phải cam kết lại rằng chỉ giao cho khách hàng sản phẩm với những chức năng chính trước, đảm bảo chất lượng của những chức năng đó, những chức năng còn lại sẽ từ từ bổ sung sau.

Theo kinh nghiệm của anh thì mức độ hài lòng của khách hàng cao hơn rất nhiều, so với việc họ nghĩ mình đã hoàn thành dự án, nhưng cuối cùng lại nhận được kết quả với chất lượng tệ.

Theo anh thì có những career path nào dành cho một PM?

Khi đã trở thành một PM thì sau đó bạn cũng có nhiều con đường khác nhau để chọn.

Bạn có thể trở thành Program Manager. Tức là người quản lý nhiều dự án của cùng một công nghệ hoặc một khách hàng. Rồi thăng tiến thành Portfolio Manager.

Ở một số công ty như công ty anh thì có một nhóm PM và một người quản lý gọi là Project Management Office. Lên cao hơn thì bạn có thể trở thành Head of PM.

3 lời khuyên mà anh dành cho các bạn Developer muốn trở thành PM là gì?

Anh nghĩ là trước tiên các bạn phải rèn luyện được kỹ năng mềm.

Tập quản lý thời gian của chính mình, tự lên kế hoạch công việc cho mình trong từng ngày, ngay từ đầu ngày, xác định xem hôm nay mình cần phải làm những việc gì, và cuối ngày thì tổng kết xem mình đã làm được những gì, và chuẩn bị cho những ngày hôm sau.

Tập giao tiếp bằng cách nói chuyện nhiều với cả các bạn Developer, PM, Team Lead, khách hàng. Giao tiếp là điểm yếu của nhiều Developer, nhưng đây là kỹ năng hoàn toàn có thể cải thiện.

Thông thường khi làm công việc nào đấy thì Developer thường chờ PM tính cho mình xem làm công việc này trong bao lâu. Nhưng kỹ năng estimation này Developer nên tự rèn luyện, tự ước tính thời gian mình sẽ hoàn thành công việc vì đây là một trong những kỹ năng cần thiết để trở thành PM. Có nhiều phương pháp để estimation. Phương pháp dễ nhất là các bạn cứ chia nhỏ công việc hết mức có thể (task breakdown) và sau đó estimate cho từng đầu việc nhỏ. Từ đó sẽ có được estimation cho cả một công việc lớn hoặc cả dự án. Chắc chắn ban đầu con số estimate không được chuẩn xác, nhưng sau đó khi mình làm nhiều công việc tương tự dần dần sẽ rút ra kinh nghiệm để estimate với những khối lượng công việc với độ khó khác nhau ngày càng chuẩn xác hơn.

Lời khuyên thứ hai là các bạn phải đặt mình vào vị trí của khách hàng, không nên chỉ suy nghĩ như một Developer. Tức là bạn phải hiểu phần mềm mà khách hàng mong muốn phục vụ họ làm việc gì, vì sao họ cần phần mềm như vậy. Cụ thể hơn là bạn đặt mình vào vị trí người sử dụng thì sẽ cảm thấy thế nào, rồi chỉnh sửa nếu thấy UI chưa chuẩn như thiết kế, hoặc trải nghiệm người dùng (UX) chưa tốt chẳng hạn.

Cần nâng cao khả năng giải quyết vấn đề và tư duy logic. Ví dụ như khi bạn gặp một vấn đề, bạn cần phân tích nguyên nhân, từ đó tìm giải pháp. Đừng giải quyết mà chưa biết nguyên nhân thật sự của vấn đề. Để rút ngắn thời gian giải quyết vấn đề thì bạn có thể hỏi xung quanh, những người có kinh nghiệm để học hỏi cách giải quyết từ họ ngay.

Nguồn resource mà anh nghĩ là hữu ích dành cho các bạn Developer trên con đường trở thành PM?

Anh thấy có một vài quyển sách mà các bạn có thể tham khảo về Project Management.

1. Project Management Body of Knowledge (PMBOK): Sách gối đầu giường cho các bạn muốn trở thành PM chuyên nghiệp
2. Head First PMP: Quyển sách này tổng hợp tài liệu dành cho bạn thi chứng chỉ PMP
3. PMP Preparation Exam: Bạn có thể chuẩn bị cho kì thi PMP với sách này
4. The Scrum Guide – Ken Schwaber & Keith Sutherland: do 2 tác giả của mô hình phát triển phần mềm SCRUM viết. Rất hay cho các bạn muốn áp dụng Agile nói chung và SCRUM nói riêng vào dự án. Phía dưới là một số website hay về SCRUM:
   • https://www.scrum.org/
   • https://www.scrumalliance.org/
   • http://hanoiscrum.net/hnscrum/
5. Series sách Havard Business Essentials – First News phát hành: bộ sách này chọn lọc và cô đọng những kỹ năng quản lý dành cho mọi người. Đơn giản, dễ hiểu, không quá dày nên dễ đọc và dễ thực hành.

Nguồn: ITViec