Những ngày gần đây, công việc của cá nhân mình có nhiều thay đổi khi dự án hiện tại bước vào giai đoạn kết thúc và chuyển giao. Thật ra, mình nghĩ điều này rất đỗi bình thường trong thế giới IT thay đổi rất nhanh hiện nay. Cái ở lại sau cùng sẽ là kinh nghiệm, là những bài học được đúc kết lại. Với dự án mới kết thúc này, bản thân mình cũng dành một chút thời gian để nhìn lại cả một quá trình dài, tự ngẫm lại những điều chưa đúng để cải thiện nhằm vận hành dự án sau một cách tốt hơn. Bài viết này ra đời nhằm mục đích đó khi nó rút rút ra những điều “xương máu” với chính mình trên hành trình làm một người quản lý dự án. 

Xác định nguyên nhân cốt lõi

Khi chạy dự án vừa rồi, mình gặp khá nhiều vấn đề liên quan đến việc tích hợp giữa hệ thống eCommerce và hệ thống quản lý bán hàng của khách và những vấn đề này xảy ra ngay từ ngày đầu tiên dự án go-live. Khách quan mà nói thì có rất nhiêu yếu tố dẫn đến việc này, thế nhưng một trong những điều mình nghĩ quan trọng nhất cần phải khắc phục đó là cách tìm ra nguyên nhân cốt lõi của vấn đề.

Nói một cách nôm na thế này, khi một vấn đề xảy ra liên quan tới việc đồng bộ dữ liệu, việc đầu tiên bạn nên làm là tìm cách tái hiện nó trên một môi trường phù hợp, ở đây là Staging. Đây là tình huống tốt đẹp nhất, thế nếu không tái hiện được thì sao? Trong hoàn cảnh, việc đặt log ở những chỗ nghi ngờ để thu thập thêm thông tin là một giải pháp phù hợp nhằm đạt được điều quan trọng nhất: tái hiện lại được vấn đề. Khi thực hiện được việc này, bạn đã đi được tầm 50 – 60% chặng đường xử lý triệt để vấn đề đó rồi.

Thế nhưng, đã có rất nhiều lần mình hay anh em thay vì tìm cách tái hiện lỗi để hiểu rõ nguyên nhân, lại đi đoán mò và đưa ra giải pháp trên những phán đoán không có cơ sở. Điều này hên thì tạm thời giải quyết cái lỗi đó, xui thì vừa tốn thời gian và khách hàng chắc chắn sẽ không vui vẻ gì rồi. Hơn nữa, giả dụ khi xử lý theo cách đó, lỗi trên không còn xuất hiện nữa nhưng không có nghĩa là nó ko dẫn tới một cái lỗi khác. Nó giống như vá một cái lỗ thủng trên thuyền lại có thể gây nên một lỗ thủng khác khiến nước tràn vô nhanh hơn cái lỗi ban đầu

Thế nên, một trong những bài học đầu tiên mình rút ra được khi vận hành dự án là

Khi có vấn đề, bạn không được phép đoán. Hãy tìm mọi cách để xác định nguyên nhân gây ra vấn đề để giải quyết triệt để nó. Đường vòng hay bất kì giải pháp tạm thời nào cũng có thể gây nên những vấn đề khác mà bạn không kiểm soát được.

Xác lập cụ thể kế hoạch hành động

Mỗi dự án như một cá thể độc lập, có đặc tính riêng biệt và đi kèm với nó là hàng tá các vấn đề đặc biệt mà không phải dự án khác, dù có tương tự về scope cũng gặp được. Chính vì thế, việc quản lý dự án và đảm bảo dự án chạy được là một thách thức bởi mỗi ngày, mỗi giờ bạn phải đối mặt với rất rất nhiều vấn đề: tiến độ – các yêu cầu ngoài dự án – các vấn đề phát sinh, v.v. Với những vấn đề phức tạp, bạn cần có sự tham vấn của các anh em để hiểu được mọi góc nhìn, có được cách giải quyết. Thế nhưng, một bước quan trọng mà mình đã vô tình quên đi là tổng hợp các ý chính cũng như kế hoạch hành động để xử lý vấn đề

Thật ra, việc tổng hợp lại không khó, nhưng cụ thể ra được từng bước cần làm để giải quyết vấn đề nó khó hơn và buộc team của bạn phải động não để suy nghĩ. Về mặt cá nhân, mình nhận ra rằng việc này sẽ mang lại cho bạn những lợi ích như sau:

• Giúp đội ngũ của bạn có được một cái nhìn cụ thể về con đường cần đi để giải quyết vấn đề. Điều này giúp họ duy trì được động lực cho đến khi bạn đến được cái đích mong muốn.
• Giúp bạn, ở vai trò quản lý dự án, dễ dàng trao đổi với cấp trên và khách hàng về những việc bạn sẽ làm để thúc đẩy dự án. Điều này theo mình là quan trọng, bởi lẽ không phải vấn đề nào cũng sẽ có giải pháp ngay tắp lự. Nhưng việc chỉ ra rằng bạn đang đi và có tiến độ cụ thể cho con đường bạn đi sẽ mang lại sự tin tưởng và tính thuyết phục để bạn có thêm thời gian để giải quyết nó.
• Cuối cùng, đó là việc này chắc chắn sẽ thúc đẩy dự án đi tiếp, và chỉ càn tiếp tục đi, thì dự án sẽ đạt được cái đích đến mà nó mong muốn.

Đơn giản thế, nhưng không phải lúc nào bản thân mình cũng thực hiện đủ và đúng dược việc này, thậm chí đôi khi nó lại được thực hiện quá sơ sài khiến nhiều vấn đề tồn đọng không được giải quyết một cách triệt để.

Cân bằng giữa quy trình cùng lợi ích của khách hàng

Dự án vừa rồi là dự án thứ ba mình chạy tại công ty. Ở dự án đầu tiên, do quá non nớt hay có thể gọi là nhiệt tình thái quá nên hoá phá hoại, mình tham gia hầu hết tất cả các cuộc họp mà rất nhiều trong đó là không thuộc phạm vi công việc của mình. Thêm vào đó, quy trình mình chuyển tải không rõ ràng và kết hợp rất nhiều yếu tố tiêu cực khác, dự án mém toang ngay từ giai đoạn đầu tiên. Một cách tích cực mà nói thì điều đó mang lại cho minh rất rất nhiều bài học xương máu để mình bước vào dự án này với những nguyên tắc và quy trình rõ ràng, cũng như sự tuân thủ với phạm vi công việc của mình – của team BA/ Client facing PM. Dĩ nhiên, điều này khiến dự án chạy trơn tru hơn rất nhiều: thời gian được tuân thủ, các tính năng được triển khai theo hợp đồng. Nhưng bạn biết mà, nguyên tắc được sinh ra để thực hành và cải thiện, hơn nữa dự án sẽ có rất nhiều tính năng, vấn đề phát sinh để có thể áp dụng các quy tắc. Và đã có nhiều lúc mình “múc” luôn cả Client facing PM lẫn khách hàng, thậm chí khi bị doạ là sẽ escalate lên trên mình cũng không hoang mang chùn bước. Dĩ nhiên, tại thời điểm này khi nghĩ lại, mình nhận ra mình hoàn toàn có thể linh động được để câu chuyện đi theo một hướng khác.

Cụ thể mà nói, mình thử đặt bản thân vào hoàn cảnh của khách hàng:

Khách hàng đi trả tiền, mà lại bị “múc” không thương tiếc trong khi tính năng đó cần thiết, hay phát sinh thêm thì sao mà vui cho được.

Vẫn biết rằng sẽ không công bằng với team delivery khi Client facing PM liên tục hứa với khách những tính năng không có trong phạm vi dự án mà không giãn khoản thời gian thực hiện ra, hay hứa với khách mà không cần thảo luận trước. Nhưng tại thời điểm này, mình nhận ra rằng lằn ranh giữa tuân thủ theo nguyên tắc và sự cứng nhắc là rất mơ hồ, đôi khi chỉ cần linh hoạt áp dụng quy tắc để sắp xếp công việc theo năng lực thực tế của team để hỗ trợ thì mọi việc sẽ khác. Điều này có thể sẽ cân bằng lại cái mong muốn của anh em Dev – các chị QC về mặt thời gian, cũng như kì vọng của khách hàng về chất lượng cũng như dịch vụ mà họ nhận được

Với mình, đây là bài học thứ 3 mình cần phải nhớ để cân bằng giữa công sức – thời gian của team cũng như niềm vui của khách hàng khi họ nhận được một dịch vụ tốt tương ứng với số tiền họ bỏ ra.

Đầu tiên, hãy đàm phán.

Cũng trong những lúc suy nghĩ về cách mình vận hành dự án trong năm vừa rồi, mình nhận ra, mà thật ra vốn dĩ đã đọc từ trước đó nhưng tới giờ nó mới vỡ ra, rằng ai cũng có một mong muốn cần được đáp ứng

• Khách hàng thì muốn thấy tiến độ, muốn được chiều khi họ thêm chỗ này, bỏ chỗ nọ mà không cần phải thay đổi thời gian hay thêm thắt chi phí,
• Team delivery thì muốn rằng mọi việc phải rõ ràng, chốt là làm để team có thể triển khai đúng theo kế hoạch,
• Clien facing PM thì muốn chiều khách, muốn lấy thêm việc và xa hơn muốn lấy những dự án khác về

Và sự khác biệt về nhu cầu dẫn tới câu chuyện Đàm phán mà mình muốn chia sẻ. Thật ra, nhiều người vẫn hay lầm tưởng rằng Đàm phán (Negotiation) là tìm cách có được phần lợi về mình. Thật ra không phải vậy, đàm phán là nơi để mỗi bên tìm cách đáp ứng được mong muốn của mình mà không cần phải hi sinh lợi ích hiện có. Xa hơn là đạt được một trạng thái win – win: đôi bên cùng có lợi khi mong muốn của các bên được thoả mãn. Dĩ nhiên, không phải vấn đề nào cũng tìm được tiếng nói chung và khi đó, việc áp dụng các nguyên tắc của dự án là điều cần làm. Có điều khi đã đạt được tới điểm đó, mình nghĩ các bên cũng đã chia sẻ rõ ràng các mong muốn, điểm lợi/hại. Khi đó, việc thêm scope vào dự án, chi phí, thời gian phát sinh hay dời thời hạn là việc khó tránh khỏi

Thật ra mà nói, để làm được điều mình nói đòi hỏi một quá trình dài học hỏi, tích luỹ kinh nghiệm để tìm ra được giải pháp nhằm cân bằng lợi ích các bên. Thế nhưng, một trong những điều mà mình kì vọng ở bài học này là

Hãy luôn nghĩ tới một giải pháp để đáp ứng mong muốn của đội ngũ và khách hàng.

Khi đó không chỉ công ty có lợi, anh em làm việc vui vẻ, mà chính bạn cũng có thể nhận được những bài học tích cực trên hành trình quản lý dự án.

Kết thúc

Danh sách trên là những bài học chính mà mình rút tỉa ra được. Dĩ nhiên, trong quá trình vận hành dự án thì có rất rất nhiều vấn đề và sai sót cần phải khắc phục. Việc của mình ở vai trò hiện tại là đối mặt với những sai sót đó và tìm hướng phát triển để thúc đẩy dự án phát triển. Với bản thân mình, viết ra được những bài học này cũng là một cách để nhấn mạnh lại tầm quan trọng của nó và tìm cách khắc phục ở những dự án tiếp theo. Và mình cũng mong rằng bạn dù đang làm bất kì ngành nghề nào hay trong cuộc sống, đều nhận ra rằng những bài học này không chỉ dừng lại ở phạm vi của một dự án mà nó còn có thể áp dụng vào cuộc sống của chính bạn hay trong công việc hằng ngày.

Nhat Minh Ngo – Tháng 06/2022