Một số sai lầm phổ biến trong quản lý dự án phần mềm

Phát triển phần mềm chưa bao giờ là việc đơn giản, nó lại càng khó hơn khi team có nhiều người. Mọi sự kết hợp giữa các thành viên trong team phải thật ăn ý và để làm được điều này thì quy trình phát triển phần mềm là điều quan trọng nhất. Bài viết này mình sẽ liệt kê một số sai lầm mà có lẽ ít nhất một lần bạn từng mắc phải

1. Không có trainning đầu vào

Đối với những nhân viên mới được tuyển dụng, những ngày đầu tiên đi làm họ sẽ rất bỡ ngỡ về nhiều thứ như quy trình nghiệp vụ là gì, công nghệ cần thiết để làm việc ra sao, cách sử dụng tool quản lý dự án như nào….blah blah… Khả năng lớn nhất của lập trình viên là tự học. Ví dụ họ có thể học Spring trong vòng 1 tuần để áp dụng vào dự án, nhưng nếu có training thì chỉ còn 3 ngày thôi. Theo bạn thì có hay không có trainning sẽ hiệu quả hơn ?

2. 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

3. 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ả

4. Estimate vo viên

Mình từng gặp trường hợp là 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 (có khi là ông lead đề xuất, dễ gây sứt mẻ tình anh em :))), 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)

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. Bản thân mình cho rằng ở bất cứ mô hình nào cũng nên có họp để rút kinh nghiệm vì nếu không thì chúng ta khó lòng mà tiến bộ được. Cứ dậm chân mãi tại chỗ thì công ty sao mà phát triển và bản thân chúng ta cũng vậy.

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

Không có phương pháp đảm bảo clean codekhô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.

7. Thời gian làm việc quá linh hoạt

Con người sẽ phát huy tính sáng tạo cao nhất khi họ được làm việc trong một môi trường tự do, thoải mái về mặt thời gian. Điều này được hiểu theo nghĩa là không ai quản lý thời gian của bạn, cái mà sếp bạn quan tâm là sản phẩm bạn làm ra có đúng tiến độ không chứ không phải mấy giờ bạn đến công ty. Mình đánh giá cao và cũng rất thích những công ty có chính sách đó đối với nhân viên, nhưng cái gì cũng có 2 mặt của nó. Thoải mái thì tốt nhưng thoải mái quá thì không bao giờ là tốt cả. Nói đơn giản như này cho dễ hiểu, chúng ta đang làm việc nhóm mà làm việc nhóm thì cần thảo luận. Nếu 9h bạn có 1 vấn đề cần thảo luận với anh A, anh B mà tới 10h-11h hai anh này mới xuất hiện ở công ty thì quả thật không còn gì để nói, chậm deadline là cái chắc.

8. Không có quy trình làm việc

Nếu bạn không mắc các sai lầm từ 1 đến 7 thì mình xin nhiệt liệt chúc mừng bạn, nhưng điều đó không có nghĩa là bạn đang làm đúng. Rất có thể quy trình mà bạn đang áp dụng cho team của mình mang tên “free style”. Không có quy trình thì rất dễ dẫn tới sai lầm và thiếu sót, mắc lỗi không biết tại khâu nào và tại ai, làm sao để khắc phục…blah blah… tựu chung lại là để lại rất nhiều hậu quả.