Những sai lầm thường gặp trong quản lý dự án

“Nhân vô thập toàn” – Không có ai trên đời này là hoàn hảo, và tất nhiên các nhà quản lý cũng vậy. Ai rồi cũng sẽ có thời điểm mắc sai lầm. Tuy nhiên, nếu bạn biết sai lầm rồi sửa, biết sai lầm rồi rút ra bài học, điều đó sẽ giúp ích rất nhiều cho bạn, cho dự án của bạn. Dự án của bạn sẽ tốt dần lên và cuối cùng là đi đến thành công.

Sai lầm sẽ trở thành kinh nghiệm cho chính bạn. Tất cả những bài học, tất cả những kinh nghiệm quý báu đều có khởi nguồn từ những sai lầm. Người ta thường sẽ trưởng thành hơn mỗi khi vấp ngã, quan trọng là mỗi lần vấp ngã bạn lại đứng dậy bước tiếp. Những người có va đập nhiều, vấp ngã nhiều thường sẽ có thành công lớn hơn về sau này.

Đọc đến đây, sẽ có bạn thắc mắc là tại sao lại chúng ta bắt đầu từ sai lầm? Liệu có tiêu cực quá không? Không hề tiêu cực bạn ạ. Cách học nhanh nhất và hiệu quả nhất là cách học từ các sai lầm, có sai lầm sẽ có kinh nghiệm. Và đặc biệt hiệu quả hơn nữa, nếu chúng ta biết cách học không chỉ từ sai lầm của mình, mà còn biết cách học từ sai lầm của người khác. Khi bạn học được từ những sai lầm của người khác, chính là bạn đang được cưỡi trên vai những người khổng lồ. Bạn được học những bài học mà không phải mất thời gian làm sai rồi sửa, trong nhiều trường hợp, điều này có thể khiến bạn phải trả giá rất đắt (thời gian, công sức, sự nghiệp…). Những bài học này sẽ rút ngắn thời gian đi đến thành công cho chính bạn. 

Trong cuốn sách này, chúng tôi sẽ giúp bạn học từ các sai lầm cơ bản của một số bạn quản lý dự án mà chúng tôi đã từng thấy và từng gặp để sau này bạn không mắc phải. Sau đó, chúng tôi sẽ cung cấp cho bạn các tư duy quản lý dự án, các kiến thức cơ bản trong quản lý dự án và các nguyên tắc căn bản để quản lý dự án. Chúng tôi sẽ tổng hợp tất cả những kinh nghiệm thực tiễn, những tình huống chúng tôi đã gặp, đã thấy, hoặc đã học được, giúp bạn có cách nhìn chung nhất để định hình và sau đó xây dựng được phong cách quản lý của riêng mình. Và giúp bạn trở thành người quản lý dự án tự tin, thành công và trở thành người mà ai cũng muốn làm việc cùng. Mục tiêu cuối cùng của chúng tôi vẫn sẽ là mục tiêu đó, toàn bộ cuốn sách này chúng tôi sẽ hướng tới mục đích cuối cùng đó, và nó sẽ không thay đổi.

Dưới đây là bốn sai lầm cơ bản nhất mà một số người quản lý dự án ở các công ty phần mềm ở Việt Nam từng mắc phải, thường tạo ra những nguy hiểm lớn, là nguyên nhân chính làm cho “dự án cháy”, và đương nhiên làm ảnh hưởng rất lớn đến mức độ thành công của dự án. Bạn đừng mắc phải những sai lầm này nhé.

Sai lầm 1. Không “làm tốt ngay từ đầu”

Nói chính xác hơn là không cố gắng quản lý tốt ngay từ đầu. Khi dự án mới bắt đầu sẽ có khá nhiều khoảng thời gian thoải mái đối với hầu hết các dự án. Một vấn đề tôi thường thấy là, nhiều dự án thời gian đầu rất nhởn nhơ, nhưng cứ đến sát ngày bàn giao sản phẩm cho khách hàng là cả dự án lại “làm thêm giờ sấp mặt”

Có dự án làm thêm giờ cả 1-2 tuần, có dự án làm thêm giờ nhiều hơn, thậm chí làm thêm giờ rồi mà vẫn không kịp ngày release, lại phải xin khách hàng lùi lịch gửi sản phẩm. Đương nhiên trong tình trạng gấp rút như vậy sẽ phát sinh nhiều nguy cơ và rủi ro, các thành viên trong dự án thì mệt mỏi, chất lượng không đảm bảo, chỉ cố gắng làm cho xong.

Và theo trải nghiệm mà tôi thấy được thì phần lớn các dự án gọi là “dự án cháy” đều rơi vào kịch bản này. Tức là thời gian đầu không tập trung làm cho tốt. Đến sát nút mới bắt đầu chạy vắt chân lên cổ nhưng cũng không kịp, có làm kịp thì đội dự án cũng không thấy thoải mái vì quá mệt mỏi, chất lượng không được bảo đảm, khách hàng phàn nàn, nhiều lỗi phát sinh, thế là lại tiếp tục làm thêm giờ triền miên để sửa. Có dự án thậm chí làm thêm giờ đến 2-3 tháng và gần như không được nghỉ Thứ Bảy, Chủ Nhật. Mà nguyên nhân chính thường là “không làm tốt ngay từ đầu“. Với những dự án rơi vào tình trạng này thường có 1 số điểm đáng chú ý như sau:

– Chưa đầu tư thời gian, công sức cho việc lập kế hoạch. Dự án cũng có lên lịch trình (thuật ngữ tiếng Anh là Schedule) nhưng nhiều khi chỉ là làm cho có, sau đó không cập nhật hoặc cập nhật không chính xác theo tình trạng thực tế. Điều đó dẫn tới việc khá là khó nắm bắt tình hình, cũng như khó phát hiện ra những rủi ro để có những biện pháp khắc phục kịp thời. 

– Không quản lý chặt chẽ ngay từ đầu đối với các yêu cầu đầu vào để có thể triển khai dự án. Ví dụ như spec khách hàng cung cấp đã đầy đủ, rõ ràng chưa? Nhóm của bạn đã làm rõ mọi điểm trong yêu cầu chưa? Các đầu vào cần thiết cho nhóm của bạn như tài liệu mô tả yêu cầu, bản thiết kế giao diện người sử dụng, kiến trúc hệ thống… đã có hoặc đã đầy đủ chưa? Nếu chưa thì khi nào có? Tôi rất hay gặp các dự án mà mọi người chỉ biết là “thiếu” hoặc “chưa cung cấp” nhưng lại không biết “khi nào” thì được cung cấp những đầu vào này dẫn tới rất bị động trong việc lên kế hoạch cũng như kiểm soát tiến độ tổng thể. 

– Không có kế hoạch cũng như quản lý chặt chẽ những rủi ro có thể có ngay từ đầu. Dường như mọi người có tâm lý “đến đâu hay đến đó, sai thì sửa” mà không có kế hoạch phòng bị ngay từ đầu nên khi có vấn đề xảy ra, mọi người khá bị động và kế hoạch bị đảo lộn. 

– Không có kế hoạch, tiêu chuẩn và kiểm soát chất lượng chặt chẽ ngay từ đầu hoặc có đề ra nhưng không thực hiện hoặc không kiểm soát. Điều này dẫn tới nợ kỹ thuật (technical debt) và lỗi tiềm ẩn cứ tích tụ dần và ngày càng phình ra. Các bạn cũng biết rằng, lỗi được phát hiện càng muộn thì chi phí để khắc phục càng lớn. Đó cũng chính là lý do mà có những dự án ở giai đoạn cuối sửa mãi không hết lỗi, sửa lỗi này lại phát sinh lỗi khác.

Sai lầm 2. “Ôm hết tất cả việc”

Tình huống này thường hay xảy ra khi mà người quản lý dự án xuất thân là lập trình viên. Anh ta quá quen với công việc viết code của mình, nhưng lại không chú trọng đến việc quản lý công việc của nhóm. Anh ta quen tới mức mà anh ta muốn các dòng code phải viết giống hệt như anh ta nghĩ. Hoặc anh ta không tin vào năng lực của các thành viên trong nhóm dự án. Nhiều lúc họ làm sai, anh ta hướng dẫn hoài cũng không đúng được ý anh ta, thế là anh ta quyết định tự làm cho nhanh. Anh ta lao vào viết code như con thiêu thân, quên hết mọi việc xung quanh. Cuối cùng khi đã tự mình code xong, anh ta vui mừng tỉnh dậy thì dự án đã “cháy” mất rồi. 

Lý do rất đơn giản, khi anh ta lao vào những công việc có thể giao cho người khác làm, thì rất nhiều công việc quản lý của anh ta bị bỏ bê. Dự án không ai quản lý, khách hàng hỏi không ai trả lời, thế là bị phàn nàn và chê trách. Khi anh ta lao vào công việc thì các thành viên còn khác lại nhàn vì không được quan tâm hay không được giao việc. Anh em đi trà đá trong khi anh ta ôm một đống công việc giải quyết mãi không hết.

Sai lầm 3. Không làm gì cả

Tình huống này tôi cũng thấy vài lần, nó ngược lại hoàn toàn so với sai lầm số 2. Nói là không làm gì thì hơi quá. Kiểu thường gặp là kiểu người quản lý hời hợt. Tức là, anh ta là quản lý nên nhiệm vụ của anh ta là chỉ tay 5 ngón, anh ta không phải làm gì cả. Anh ta tự xác định nhiệm vụ của anh ta là “kiểm tra tiến độ” và “báo cáo”. Khi khách hàng hoặc cấp trên hỏi tình hình, thì anh ta yêu cầu đội dự án báo cáo cho anh ta, rồi anh ta chuyển tiếp  y nguyên nội dung báo cáo đi, thế là xong nhiệm vụ. Anh ta thậm chí còn không hiểu chi tiết nội dung báo cáo viết những gì. Đương nhiên nếu có ai đó yêu cầu anh ta giải thích tóm tắt về hệ thống đang làm thì anh ta cũng không giải thích được. Nếu dự án có vấn đề, anh ta thường đổ lỗi là do thành viên nào đó trong dự án năng lực không tốt hoặc là dự án đã báo cáo sai cho anh ta. 

Thực tiễn đã chứng minh là những người quản lý thuộc nhóm này thường là không có sự phát triển trong công việc. Bản thân bạn ấy cũng không học được gì từ mỗi dự án mình đã trải qua. Một điều dễ nhận thấy nữa là vai trò của bạn PM này rất mờ nhạt, thậm chí nếu bạn ấy vắng mặt thì cũng không ảnh hưởng gì tới dự án hay nói một cách phũ phàng hơn là bạn ấy không có đóng góp gì tới thành công của dự án cả.

Sai lầm 4. Đồng ý với mọi thứ

Tôi cũng gặp kiểu người quản lý này một vài lần. Chúng tôi làm việc với khách hàng Nhật, có nhiều người khi nói chuyện với khách hàng thì tỏ ra rất tự tin, và theo phong cách Nhật Bản là cái gì cũng “gật”, và cũng thường trả lời “Hây” (“はい” trong tiếng Nhật đọc là “Hây”, có nghĩa là “vâng”).

Ở đây tôi thấy có 2 mô tuýp, mô tuýp thứ nhất là không hiểu khách hàng nói gì cũng “Hây”. Thỉnh thoảng khách hàng hỏi lại bạn ý để xác nhận lại yêu cầu thì bạn ấy lại nói là không hiểu, nhờ khách hàng giải thích lại hoặc là tự mình giải thích yêu cầu theo một cách hoàn toàn khác. Đương nhiên nếu khách hàng không hỏi lại thì nguy to, mà đúng là nguy thật. Theo thống kê, có khá nhiều lỗi xảy ra do đội dự án hiểu sai ý khách hàng. Mà nguyên nhân gốc rễ do người tiếp nhận yêu cầu ngại hỏi, không hiểu yêu cầu mà cũng gật, không hiểu cũng không hỏi lại. Thế là cứ đinh ninh mình hiểu, rồi làm theo hướng hoàn toàn khác. Đến khi nghiệm thu lại thành lỗi, lại sửa, rồi lại sai. Vừa lãng phí thời gian, vừa lãng phí công sức, chỉ vì đơn giản không dám hỏi lại khách hàng.

Mô tuýp thứ hai là, khách hàng yêu cầu gì cũng đồng ý hết, đúng tinh thần “khách hàng là thượng đế”. Đương nhiên chiều khách hàng ở phương diện bán hàng là tốt, nhưng trong nhiều tình huống khi quản lý dự án, không phải là lúc nào cũng chiều là tốt. Có một điểm tôi muốn lưu ý với bạn là “không phải ai cũng thích chiều”. Nếu chiều mà làm tốt thì không sao, nếu chiều xong lại làm không tốt thì rất dở. Nhiều bạn quản lý dự án khách hàng nói gì cũng đồng ý, sau đó về ép đội dự án tăng ca để làm cho bằng được. Cuối cùng, do thời gian ngắn chất lượng không tốt, lại bị khách hàng phàn nàn. Khi được hỏi nguyên nhân thì ai cũng đổ lỗi là do khách hàng là hay thay đổi, hay thêm yêu cầu. Điều này không tốt bởi những cố gắng, công sức của đội dự án không những không mang lại kết quả tốt nhất, không được ghi nhận xứng đáng mà ngược lại còn bị khách hàng phàn nàn, thậm chí là năng lực của đội bị đánh giá thấp.

Tôi đã từng làm việc với nhiều khách hàng, đặc biệt là khách hàng Nhật Bản. Tôi thấy đa phần họ muốn “thảo luận, bàn bạc” với mình hơn là “chỉ thị“. Nhiều lúc họ đưa ra yêu cầu với mong muốn lắng nghe ý kiến, tư vấn hoặc đề xuất của đội dự án cho họ. Có thể là thảo luận về tính năng, hay tư vấn về giải pháp, hoặc là đề xuất về thời gian thực hiện. Nhưng nhiều bạn quản lý dự án lại coi mọi lời nói của khách hàng là chỉ thị, mà chỉ thị thì phải cố gắng mà làm.

Nhiều dự án gặp nhiều vấn đề khó khăn mà nguyên nhân bắt nguồn từ những sai lầm rất cơ bản của người quản lý dự án. Tôi mong muốn rằng, bạn đọc cuốn sách này sẽ không mắc phải những sai lầm như vậy.

===================
Một số sai lầm khác

5. Không có mục tiêu cho từng giai đoạn của dự án (từng tháng)
6. Không lập kế hoạch đã làm
7. Không định nghĩa ro vai trò của từng người trong dự án
8. Thông tin không thông suốt trong dự án
– Không có file quản lý tổng hợp thông tin
– Nói miệng hoặc chat private quá nhiều
– Lack thông tin, lack task
– Thấy member sai mà ko dám chửi
– Thấy vấn đề mà ko đưa lên
– Chia sẻ các cột mốc hoặc thời hạn thiếu rõ ràng
– Spec thiếu chi tiết mà ko confirm lại đã làm
9. Quá cứng nhắc trong các tình huống cần linh hoạt
10. Không hề quản lý hay đánh giá rủi ro
11. Không tương tác với member trong dự án
12. Không biết cách kêu gọi sự giúp đỡ từ bên ngoài (chuyên gia, khách hàng, các bộ phân khác)
13. Không sâu sát quản lý tiến độ của từng task
– Để member tự bơi
14. Không làm KPT để cải tiến
15. Không hiểu gì về khách hàng, sản phẩm, mục đích, bối cảnh

(Trích từ cuốn sách Tư Duy – Kiến Thức – Nguyên Tắc để quản lý dự án thành công)