Sai lầm trong dự án dẫn đến thất bại

Trong thực tế có rất nhiều nguyên nhân gây ra các khó khăn trong một dự án phần mềm. Những khó khăn này nếu không được xử lý sẽ dẫn đến việc chi phí dự án tăng vọt và trượt thời hạn cam kết, làm cho dự án thất bại giữa chừng, hoặc vẫn “hoàn thành” nhưng không đạt một phần hoặc thậm chí toàn bộ các mục tiêu đặt ra. Có lẽ tất cả chúng ta đều nghĩ rằng các dự án "thất bại" là do quá trình thực hiện ngày càng kém, hoặc do vượt dự toán, hoặc là do hệ thống đã mắc những lỗi cơ bản ngay từ ban đầu.

Nhưng làm sao để bạn biết rằng khi nào - và tại sao – một dự án đã thất bại? Trong nhiều trường hợp, lý do này khá là rõ ràng, nhưng trong một số trường hợp khác thì lại không như vậy. Một dự án có thể bị kéo dài và gắn mác là “đã thất bại”, trong khi có dự án khác cũng bị kéo dài với thời gian tương tự mà người ta lại cho rằng nó thành công rực rỡ.

1. Làm sai requirement

Cofirmation là cực kỳ quan trọng, nếu confirm được thực hiện sớm và xuyên suốt quá trình phát triển dự án thì sản phẩm luôn hoàn thành kịp tiến độ và đáp ứng đầy đủ yêu cầu khách hàng. Nếu dự án của bạn chỉ nhận requirement từ phía khách hàng làm rập khuôn theo requirement và theo suy nghĩ hợp lý của cá nhân mà không confirm chi tiết nội dung với khách hàng cho tới cuối dự án khi release sản phẩn không đáp ứng được yêu cầu của khách hàng thì đó là một thất bại trong dự án.

2. Estimate vo viên

Có những lập trình viên rất giỏi, họ lướt qua requirement dài cỡ 1 trang A4 trong vòng 1 phút rồi estimate trong vòng 1 nốt nhạc. Quả là quá nhanh quá nguy hiểm, nhưng khi đi vào thực tế thì thời gian làm việc lại gấp 3-4 lần thời gian dự kiến. Nếu như không có biện pháp khắc phục vấn đề này thì hậu quả sẽ rất nghiêm trọng, có thể kể đến như

– Công ty phải bù lỗ vì estimate sai

– Dev phải vắt chân lên code cho kịp deadline mà mình đề xuất, nếu tình trạng này kéo dài thì dẫn tới năng suất lao động sẽ giảm sút

– Dễ đánh mất niềm tin với khách hàng (có thể vì sai hẹn hoặc làm gấp quá nên sản phẩm có lỗi)

3. Không có phương pháp đảm bảo clean code

Không có phương pháp đảm bảo clean code và không quan tâm tới clean code là 2 vấn đề khác nhau nhưng đều để lại chung một hậu quả. Phần mềm càng lớn thì khối lượng code càng nhiều, chính vì vậy cần phải đảm bảo được những đoạn code đó sáng sủa (clean code) để người sau, thậm chí là 6 tháng nữa người cũ đọc lại vẫn phải hiểu. Chưa kể đến việc đoạn code đó sáng sủa đấy nhưng đã tối ưu chưa, cần phải cải tiến gì không ? Vòng đời của một phần mềm là rất dài, tùy từng loại mà có thể lên tới trên chục năm. Chúng ta không thể làm việc tốt trên những đoạn code bẩn, hậu quả là phần mềm sẽ nhiều bug và tốn thời gian xây dựng hơn.

4. Không coi trọng kiểm thử

Đầu tiên bạn cần chú ý là “Không coi trọng kiểm thử” khác hoàn toàn với việc “không có tester” nhé, có những team có tester nhưng họ cũng hoàn toàn không coi trọng kiểm thử. Hậu quả ra sao thì chắc mình không cần nói bạn cũng có thể tưởng tượng ra, phần mềm mà lỗi thì hậu quả rất nghiêm trọng

– Công ty tổn thất về mặt tài chính, cái này là tùy mức độ nghiêm trọng

– Mất niềm tin ở khách hàng

– Bạn đã nghe nói đến technical debt chưa, đây là những món nợ phải trả, mà nợ nần thì chẳng ai thích cả

5. Thiếu họp cải tiến

Trong agile thì họp cải tiến (retrospective) được diễn ra thường xuyên cuối mỗi sprint nhưng ở các mô hình khác, ví dụ như waterfall thì không có thông lệ này. Cuộc họp này rất quan trọng vì sau mỗi sprint mỗi cá nhân và dự án rút ra kinh nghiệm cải tiến giữ điểm tốt nào và vấn đề nào còn đang vướng mắc cần cải tiến và làm tốt hơn ở các sprint tiếp theo, giúp cho phần mềm ngày càng hoàn thiện hơn, team làm việc ngày càng tiến bộ và trơn chu.

6. Giao việc qua skype

Đang hì hụi fix bug, bỗng dưng skype lóe sáng với những dòng tin nhắn của sếp như “Fix cho anh bug này”, “Có task abc xyz gì đó em nghiên cứu làm sớm” nhưng lại ko nói rõ deadline và độ ưu tiên. Và trong một ngày làm việc bạn nhận được khoảng 10 tin nhắn như vậy. Sếp thì thấy giao việc là rất nhẹ nhàng và đơn giản nhưng bản thân bạn thì “đau cái đầu” & “phân cái tâm”. Cứ mỗi một message của Sếp là bạn lại mất 1-2 phút lên jira log task lại. Như vậy thì khó lòng mà giải quyết công việc đúng deadline được và hơn thế nữa thì nó còn kéo theo những hệ quả sau đây

– Dễ bỏ qua các task quan trọng nếu như chát group hoặc nhân viên quên ko log lên tool (Jira, redmine…)

– Sếp có thể là người quên chính task mà mình đưa ra (trong trường hợp nhân viên quên log task)

– Tốn thời gian giải thích chát qua chat lại nếu task khó hiểu

– Làm giảm năng suất lao động

7. Lời kết

Để một dự án thành công, quản lý dự án của bạn thành thạo và cung cấp một sản phẩm chất lượng tốt thôi là chưa đủ. Để tránh thất bại, bạn phải chắc chắn rằng mình đã nắm rõ các yêu cầu của khách hàng, tạo ra một business case khả thi, có một hệ thống quản trị chặt chẽ và hiệu quả, quản lý việc thực thi có chất lượng cao nhất, tập trung vào lợi ích, và giám sát những biến động trong môi trường của mình. Trên hết, đừng quên quản lý kỳ vọng ban đầu của các bên liên quan, để họ luôn hỗ trợ cho dự án của bạn, vì dù gì đi chăng nữa, họ chính là người sẽ tuyên bố dự án của bạn thành công hay thất bại.