Cách ứng phó 7 nguyên nhân phổ biến dẫn đến dự án IT thất bại

Bất kỳ dự án IT nào cũng sẽ có trường hợp thất bại. Sự thất bại này được minh họa rõ nét nhất khi bạn rơi vào các trường hợp dưới đây:

• Lặp đi lặp lại cùng một lỗi sai, cứ tưởng bug này fix rồi nhưng hai tháng sau nó lại xuất hiện trên production như chưa từng được fix.

• Dự án đang trong giai đoạn nước rút mà team member đột nhiên rời đi khiến ngày release bị chậm trễ so với plan.

• Dự án chạy trong 7 tháng, 2 tháng đầu cả team chạy được 70 %, sau đó đến cuối tháng thứ 6 dự án làm được đến 80%, mọi người không kịp chạy nốt 20% còn lại trong tháng cuối cùng .

• Cứ tưởng là làm đúng yêu cầu rồi , đến khi giao cho khách hàng thì nhận claim tới tấp vì sản phẩm hoàn thiện khác hoàn toàn với yêu cầu của khách hàng, khách tưởng tính năng là bug.

• Dự án  chạy ngon lành, release đúng hạn , tất cả mọi thứ đều ổn cho đến khâu tính tiền

Nếu đã trải qua 1 trong vài trường hợp nêu trên, tin mình đi, bạn nên đọc bài viết này để hiểu được tại sao định luật bánh bơ của Murphy* luôn rơi đúng vào dự án của mình như thế. Có thật là chúng ta chỉ có thể chấp nhận những rủi ro tình cờ và ngẫu nhiên, thay vì có biện pháp hạn chế chúng hay không ?

Định luật bánh bơ Murphy: nếu một điều xấu CÓ THỂ xảy ra, nó SẼ xảy ra, và vào thời điểm tệ nhất có thể

1. Vấn đề cần giải quyết và mục tiêu dự án không rõ ràng

“ Dự án là một nỗ lực nhằm giải quyết một vấn đề hoặc để đạt được một mục tiêu nào đó trong một khoảng thời gian nhất định.”

Mẹ có cho tôi một cái bánh ngọt với chu vi 32cm, nặng 1.2kg, vỏ là lớp socola, nhân chuối mà tôi cực kỳ thích. Hơn nữa, cái bánh này lại có thể để trong tủ lạnh dùng dần trong 3 ngày.Tôi cắt bánh làm 8 phần và cho em gái tôi 1 phần . 

Hỏi...?

Giải quyết đúng vấn đề giúp hạn chế dự án thất bại

 

Ở trong ví dụ trên, câu hỏi không được đưa ra ngay từ đầu, rất có thể thiên hướng của mọi người sẽ thường là

1. Chắc câu hỏi là tôi còn lại bao nhiêu phần bánh chứ gì? Hoặc là phần còn lại của tôi sẽ có kích thước và khối lượng bao nhiêu/ mỗi ngày tôi sẽ ăn bao nhiêu phần bánh chứ gì? 

2. Đây là level nâng cấp của những người số 1. Sau khi dự đoán được câu hỏi (mà ở đây mình tự cho là đúng), họ không giải luôn, mà họ thiết kế ra một hệ thống siêu tối tân để giúp khách hàng tính toán lượng bánh mà họ nên ăn trong một ngày và thời điểm phù hợp để ăn bánh. Họ đem bản thiết kế hệ thống quản lý dinh dưỡng tích hợp công nghệ siêu khủng khiếp này đến show cho khách hàng, trong lòng hí hửng vì mình làm được điều quá khủng, hiểu được những mong muốn của khách hàng.

Nhưng nếu như mình bảo câu hỏi trong đề bài ở trên lại là “ Làm thế nào để em gái tôi ngừng khóc và không mách mẹ?” thì bạn sẽ cảm thấy thế nào?

Trong thực tế, đôi khi yêu cầu của dự án IT cũng sẽ như câu đố ở trên, phần dữ liệu mà khách hàng đưa cho và vấn đề của khách hàng cần giải quyết không liên quan gì đến nhau hoặc không rõ ràng. Có thể đó là những thông tin duy nhất trong mớ hỗn độn mà họ tìm được để đưa cho mình (trong một tình thế cấp bách) hoặc thậm chí là ngay chính bản thân họ không hiểu được vấn đề của họ là gì, hay là họ cần gì để giải quyết vấn đề đó. 

Vậy nên, điều cần làm ở đây là liên tục hỏi và xác nhận cho đến khi biết được chính xác vấn đề cần giải quyết và mục tiêu muốn đạt được của dự án (cũng như của khách hàng) và đạt được sự đồng thuận về nó.

Thậm chí, có thể câu hỏi  “ Làm thế nào để em gái tôi ngừng khóc và không mách mẹ?” cũng không thể nói hết được vấn đề mà người khách này muốn giải quyết thực sự là gì.

Điều này thực ra rất đơn giản để hiểu, nhưng lại không đơn giản để làm, đấy chính là giải quyết đúng vấn đề. Để phòng tránh cho dự án IT không thất bại ở bước cơ bản đầu tiên này, bạn có thể thử áp dụng những câu hỏi sau:

1. Mục đích của dự án này là gì?

2. Vấn đề mà khách hàng thực sự cần giải quyết là gì? Vì sao dự án lại giải quyết được vấn đề đó ?

3. Liệu dự án này có phải là phương án tốt và phù hợp nhất để giải quyết vấn đề của khách hàng hay không?

Dự án không giống như đi thi học sinh giỏi toán, câu hỏi rõ ràng rồi và chỉ cần tìm cách giải trong thời gian quy định. Việc vội vàng lao vào thực hiện, thiếu kiên nhẫn và quyết tâm trong việc làm rõ mục tiêu, dùng sai các phương pháp thu thập, phân tích, đánh giá,... trong một dự án IT sẽ là con đường dẫn tới sự hỗn loạn và đổ vỡ của dự án đó. Vậy nên, nếu như bạn tích cực lắng nghe và xác nhận từ phía khách hàng (hoặc là Project Owner), bạn đã giảm thiểu được khả năng dự án thất bại xuống khá nhiều rồi đó!

2. Đánh giá sai stakeholders (Người liên quan) trong dự án

 

Vòng tròn khái quát các loại stakeholder ảnh hưởng đến dự án 

 

Một dự án có thể đổ vỡ, từ việc thiếu nhận biết những người liên quan (stakeholder). Đối tượng mà đôi khi thoạt nhìn thì ta nghĩ họ chả có liên quan gì đến dự án hoặc không ảnh hưởng gì lắm đến chất lượng sản phẩm. 

Đừng nghĩ Stakeholder chỉ là khách hàng của bạn. Bên kiểm duyệt ứng dụng (CH play và App store) cũng là một stakeholder.

Nhận diện được toàn bộ Stakeholder của dự án là một việc cực kỳ quan trọng trong quản lý dự án nói chung và quản lý dự án IT nói riêng.

Bạn có thể chia họ vào hai nhóm lớn: nhóm nội bộ và nhóm bên ngoài tổ chức. Sau khi chia nhóm thì chia theo bộ phận, vị trí trong tổ chức, vai trò đối với dự án (người dẫn dắt, người hỗ trợ, người quan sát). Điều này giúp bạn nhận định được ai là người có vai trò và tầm ảnh hưởng quan trọng đến hướng phát triển của dự án; từ đó có kế hoạch, đối sách điều chỉnh thái độ, hành vi của họ để giúp dự án nhận được nhiều hỗ trợ tốt hơn, dễ thành công hơn. 

Nên có tài liệu ghi lại danh sách các stakeholder và được update thường xuyên. Nên tách riêng tên, chức vụ và vai trò của họ. Bởi nếu có một người được thay vào vị trí của một stakeholder, bạn chỉ cần bỏ cái tên cũ và thay bằng cái tên mới là được. Ngoài ra độ dài của danh sách stakeholder cũng có thể là một yếu tố khá hữu ích giúp bạn đánh giá được quy mô của dự án.

3. Quản lý dự án thất bại vì không lập và update kế hoạch

Dự án đã thất bại của bạn đã từng được lập kế hoạch chưa ?

Một nghiên cứu của NASA đã chỉ ra rằng hầu như tất cả các dự án thất bại đều có nguyên nhân chính là lập kế hoạch không tốt.

Tuy tốn nhiều thời gian để lập ra và quản lý, theo dõi, update nó. Nhưng lập kế hoạch luôn là một công cụ đắc lực để giúp dự án vận hành suôn sẻ. 

Lập kế hoạch còn giúp chúng ta chia nhỏ cũng như giới hạn số lượng công việc cần làm/số người/nhiệm vụ. Từ đó dễ dàng điều động nhân sự hơn nếu như trong nội bộ có sự thay đổi về người hoặc về yêu cầu.

Để đảm bảo tiến độ của dự án luôn theo sát lịch trình đã lên, bạn hãy luôn nhớ phải cập nhật kế hoạch mỗi khi có bất kỳ thay đổi gì kèm với đánh giá các thay đổi đó nhé!

Có thể bạn quan tâm: 6 lỗi của dự án phần mềm và giải pháp quản lý chất lượng dự án

4. Không quan tâm đến quản lý rủi ro

 

Dự án IT thất bại do không quản trị rủi ro

Một vài người sẽ nghĩ rằng kiểm soát tốt những yếu tố như nguồn lực, thời gian, tiến độ, thái độ của các stakeholders đối với dự án đã là quá đủ để khiến một dự án thành công. Tuy nhiên, từng đó là chưa đủ, còn cần phải tự hỏi thêm một câu nữa, “điều gì có thể khiến cho dự án thất bại ?”

Rủi ro - một thế lực siêu nhiên và đầy ngẫu hứng, liệu ta có thể nắm bắt được nó để dự án của mình không bị thất bại hay không ? 

Câu trả lời là có, bạn hoàn toàn có thể kiểm soát rủi ro ở một mức độ nào đó.

Trước tiên, bạn cần nhận diện chúng và đánh giá nguy cơ phát sinh của các rủi ro này từ cao đến thấp, càng chi tiết thì càng tốt, ở tất cả các giai đoạn của dự án. Sau đó, với từng rủi ro này hãy ghi phương án đối phó nếu như rủi ro đó xảy đến với dự án của bạn. Nếu như bạn đã nhuần nhuyễn ở bước này, chắc chắn dự án của bạn sẽ không bao giờ bị đổ bể một cách nặng nề.

Việc nhận diện được những rủi ro cần kinh nghiệm và kiến thức tổng quát. Hãy tự bồi đắp cho mình 2 yếu tố quan trọng này nhé.

5. Mất kiểm soát với dự án

Rất nhiều dự án đã thất bại vì người thực hiện, quản lý dự án không nắm được phạm vi, sprint, phase, scope của dự án. 

Ngoài ra, trong quá trình làm sản phẩm, stakeholder liên tục muốn thay đổi, bổ sung tính năng, giao diện sao cho phần mềm thật hoàn hảo. Điều này nếu không được kiểm soát thật tốt sẽ dẫn đến trường hợp nhóm phát triển không đủ thời gian chăm chút cho những tính năng cốt lõi. Phần mềm không đảm bảo được nhu cầu tối thiểu của khách hàng. 

Vậy giải pháp là làm điều quan trọng!

Thay vì tìm cách hạn chế khách hàng tạo ra nhiều thay đổi trong yêu cầu,  điều tốt hơn là giúp khách hàng nhận ra điều họ cần và muốn, cũng như tác động mà điều này đem đến cho dự án của họ.

Đầu tiên ta cần phải xác định đâu là việc mà team dự án sẽ làm trong một sprint, phase, scope. Hãy đảm bảo luôn đánh thứ tự quan trọng và xác nhận với khách hàng của mình rằng những đầu việc này được thực hiện nhằm đạt được mục tiêu gì. 

Sau khi đã thống nhất được những điều trên, mỗi khi có thay đổi hoặc tính năng mới được thêm vào giữa chừng, cả hai bên đều sẽ phải cân nhắc những câu hỏi khác. Ví dụ như:

1. Vì sao requirement này lại bị thay đổi / thêm mới? Điều này có hợp lý và giúp đạt được mục đích ban đầu của dự án không?

2. Độ ưu tiên của requirement này như thế nào? Thời gian thực thi mất bao nhiêu lâu? Rủi ro là gì? Phạm vi ảnh hưởng như thế nào?

Sau khi đã có câu trả lời, việc còn lại là cập nhật kế hoạch và tạo yêu cầu thay đổi. Sau đó giải quyết chúng như một task bình thường mà thôi.

Tóm lại, nếu như cả khách hàng lẫn team phát triển đều nhận thức đúng đắn về thay đổi và cho rằng nó là thực sự cần thiết ở giai đoạn này, thì mọi việc sẽ suôn sẻ hơn, và CX cũng sẽ được nâng cao hơn rất nhiều.

6. Giao tiếp không tốt

Nếu như kế hoạch là chiếc bánh lái giúp định hướng dự án đi đúng thì giao tiếp chính là chất bôi trơn không bao giờ thiếu ở các dự án thành công.

Việc giao tiếp trong dự án bao gồm giao tiếp với khách hàng và giao tiếp trong nội bộ. Việc giao tiếp hiệu quả với khách hàng sẽ giúp bạn tránh hiểu sai về dự án. Việc giao tiếp hiệu quả với nội bộ sẽ giúp dự án diễn ra trôi chảy và đúng hướng.

Vậy giao tiếp như thế nào là hiệu quả?

Mình xin đưa ra 4 phương pháp dưới đây, bạn nên áp dụng không chỉ cho nội bộ team phát triển, mà áp dụng cả với khách hàng nhé.

• Daily meeting : Hiện tại nơi mình làm việc đang áp dụng hình thức này để đảm bảo không có ai bị bỏ lại phía sau, cũng như giúp PM có cái nhìn hàng ngày về tiến độ của dự án. 

• Phương pháp Horenso của người Nhật : Về cơ bản thì phương pháp này của người Nhật xoay quanh 3 từ khóa chính “ Báo cáo “(Ho)- “Liên lạc” (Ren) - Thảo luận (So). Nói một cách ngắn gọn , nó là việc thông báo  vấn đề cần giải quyết  thông qua một phương thức giao tiếp phù hợp để cùng tìm ra giải pháp giải quyết vấn đề đó. 

• Duy trì giao tiếp hai chiều : Tương tác với đối tượng giao tiếp, luôn thực hiện xác nhận lại nội dung giao tiếp với đối phương dù đã hiểu nhằm hạn chế hiểu nhầm, hiểu sai, hiểu thiếu. Những vấn đề quan trọng đều cần được xác nhận lại bằng văn bản

• Lắng nghe tích cực : Hiểu được điều mà đối tượng giao tiếp muốn truyền đạt chứ không phải điều họ nói. Thực hiện diễn giải và xác nhận lại với đối phương ( kết hợp với giao tiếp hai chiều ở trên)

 Ngoại trừ những điều trên, việc dành thời gian tìm hiểu về ngôn ngữ cơ thể, cũng như giữ một thái độ thân thiện cởi mở khi giao tiếp cũng sẽ giúp ích cho cả bạn lẫn dự án của bạn khá nhiều đó.

Có thể bạn quan tâm: Những yếu tố cơ bản để quản lý dự án công nghệ thông tin

7. Quản lý tài nguyên dự án kém

 

Tuân thủ chính sách bảo mật để tài nguyên của dự án không bị rò rỉ

Tài nguyên dự án ở đây có thể là nhân sự, vật chất, cơ sở trang thiết bị, nguồn tài chính, phần mềm, tài liệu,... thuộc về dự án đó. 

Ví dụ như về phần mềm, nếu như dự án IT không có cơ chế hay quy định về an toàn bảo mật thông tin nội bộ thì rất có thể sẽ bị rò rỉ ra bên ngoài mã nguồn bị hack.

Từ đó khiến dự án thất bại trong phút chốc, thậm chí tệ hơn là dính đến kiện cáo, bồi thường.

Tham khảo thêm: Bảo mật với Cookies?

Hoặc như nguồn kinh phí dành cho dự án không tăng nhưng yêu cầu mới và yêu cầu sửa đổi liên tục tăng, dẫn tới phải tăng nhân sự và thời gian, khiến dự án trở nên thua lỗ.

Về tài liệu, nó có thể là việc tài liệu đã cũ và không được cập nhật, hoặc thất thoát trong khi team dự án có thay đổi liên tục về mặt nhân sự tham gia.

Để kiểm soát được những điều này, ở giai đoạn bắt đầu của dự án, bạn nên liệt kê hết tất cả các tài nguyên dự án mà bạn nghĩ đến, đánh giá độ quan trọng cũng như tình trạng của chúng vào tài liệu “quản lý tài nguyên” và  ghi thêm phương án khắc phục nếu xảy ra thất thoát nhé !

Kết luận

Là một nhà phát triển dự án có kinh nghiệm, chúng tôi rất hy vọng bài viết sẽ giúp bạn tránh những nguyên nhân khiến dự án IT thất bại. Để đọc thêm nhiều bài viết về quản lý chất lượng dự án, vui lòng truy cập vào kênh tri thức của chúng tôi.