Hẳn ai làm trong ngành phần mềm đều biết đến áp lực về thời gian và chất lượng: chất lượng sản phẩm phải tốt nhất, nhưng thời gian hoàn thành thì luôn bị rút ngắn.
Mỗi lần nhắc đến vấn đề này, tôi lại nhớ đến một nhận định của cô bạn làm trong ngành phần mềm khá lâu rồi:
“Thời gian và chất lượng sản phẩm chẳng khác gì tiền và giỏ hàng đi chợ của một cô dâu mới về nhà chồng”.
Làm thế nào để vừa lòng nhà chồng khi số tiền đi chợ thì ít nhưng bữa cơm nhất định phải tươm tất. Tất nhiên là chẳng có cách nào khác ngoài việc bỏ thêm tiền riêng của cô ấy vào tiền đi chợ. Tôi lấy làm ngạc nhiên khi nghe cô ta so sánh như vậy: tôi luôn nghĩ rằng cái vấn đề “mẹ chồng nàng dâu” ấy đã “đi vào dĩ vãng” từ lâu lắm rồi chứ. Vì không đồng ý, tôi đã làm một cuộc khảo sát nhỏ với tất cả những bạn bè quen biết (và tất nhiên cả những người quen của người quen nữa…). Và tôi đã đúng: Các nàng dâu bây giờ không hề chịu áp lực về tiền bạc và chất lượng bữa ăn. Họ hoàn toàn tự quyết định việc chi tiêu cho bữa ăn như thế nào là hợp lý nhất.
Khi phát hiện ra phán đoán ban đầu của mình là đúng, thay vì thích thú tôi lại cảm thấy phiền não vì lại xuất hiện một câu hỏi khác: Tại sao cái quan điểm cổ hủ ấy đã bị xã hội đào thải rồi, nay lại sống dậy và len lỏi vào trong tư tưởng của hầu hết các nhà quản lý dự án hiện nay?
Cách tốt nhất để khiến người khác làm việc hiệu quả là luôn đặt họ dưới áp lực về thời gian hoàn thành công việc.
Chính cái tư tưởng này đặt một áp lực lớn lên các lập trình viên. Để có được chất lượng sản phẩm như mong đợi, họ buộc phải tăng thời gian làm việc: đó là những lúc làm việc overtime, cuối tuần hay đem cả công việc về nhà làm…
Vậy, hệ lụy của nó là gì?
- Chất lượng sản phẩm không đạt được như mong đợi, vì rằng người bị đặt dưới áp lực thời gian không hề làm việc tốt hơn, họ chỉ làm việc nhanh hơn.
- Niềm yêu thích và sự thỏa mãn đối với công việc giảm đi dần, và kết quả là sự ra đi của người nhân viên đó.
Trong một buổi ăn tối cùng bạn bè thuở còn học đại học, sau một lát truyện phím chúng tôi lại qua ra bàn chuyện công việc. Tôi mang nhận định này ra thảo luận. Cũng may trong buổi tối đó không chỉ có dân IT, thành phần khá đa dạng: hai người là quản lý dự án, ba lập trình viên và một vài người làm kinh doanh.
- “Hừm, nếu không có áp lực thời gian thì làm sao quản lý được những tay lười biếng chứ. Tao đã từng quản lý những nhân viên mà lúc nào cũng trễ nải dù công việc là khó hay dễ“, một tay quản lý dự án phản đối.
- Và hắn lập tức có ủng hộ, “Deadline của dự án là thứ mà không thể không đạt được, do đó đôi khi cần phải tạo cả những áp lực thời gian giả tạo lên nhân viên của mình. Nghệ thuật quản lý là gì? Đó là kicking ass”, tay quản lý dự án còn lại nói.
Lập tức, có nhiều ý kiến phản đối:
- “Áp lực thời gian ư, nó hoàn toàn không tốt. Tôi đã từng phải viết ra những đoạn mã vội vàng để kịp thời gian, và tất nhiên chúng tiềm tàng những lỗi. Còn overtime ư, nó chẳng giúp ích được bao nhiêu cả”, “Những đoạn mã viết dưới áp lực về thời gian không thể là đoạn mã tốt”, hắn kết luận.
- “Rõ ràng như vậy! Không những thế, khi viết tiếp các thiết kế hay những đoạn mã tồi, tôi mất đi hoàn toàn cảm giác thú vị trong công việc”.
Sau một hồi chăm chú lắng nghe, với các luận cứ của cả hai bên, một trong những người làm kinh doanh mới lên tiếng nhằm dung hòa hai quan điểm trái ngược trên (có lẽ là hắn muốn đổi đề tài nhàm chán này):
- “Quyết định có đặt áp lực thời gian lên một công việc cũng giống như việc bạn quyết định có phạt con trẻ khi chúng nghịch ngợm vậy. Nếu lúc nào cũng áp dụng, chắc chắn sẽ bị phản tác dụng”.
Tôi thật sự bị lạc vào mê hồn trận của những quan điểm trái ngược nhau, nhưng có lẽ đây là một nhận định đúng.
- “Này! Thế các dự án phần mềm lúc nào cũng phải có deadline cố định sao? Các lập trình viên không thể tham gia vào việc quyết định thời hạn ra release của sản phẩm à?”, một cô bạn học kinh tế hỏi.
Một câu hỏi thật hay và gợi ta nhiều suy nghĩ. Sau này, tôi được biết một số công ty ở Nhật (
Vậy, ta thử tìm hiểu xem nếu dự án không có áp lực về thời gian thì có được những lợi điểm gì?
Thời gian hoàn thành dự án:
Trước tiên, chúng ta hãy khảo sát bảng số liệu dưới đây. Jeffẻy-Lawrence đã khảo sát productivity của 24 dự án phần mềm dưới các áp lực thời gian khác nhau:
Productivity by Estimation Approach
(Full Result)
EFFORT ESTIMATE AVERAGE NUMBER OF
PREPARED BY PRODUCTIVITY PROJECTS
-----------------------------------------------------------------------------------------------
Programmer alone 8.0 19
Supervisor alone 6.6 23
Programmer & supervisor 7.8 16
Systems analyst 9.5 21
(No estimate) 12.0 24
(bảng số liệu này được lấy từ Peopleware - Productive Projects and Teams)
Kết quả khảo sát cho ta thấy rằng dự án không có bất kì một áp lực nào về thời gian lại có productivity cao nhất.
Hỡi các nhà quản lý dự án, định luật Parkinson không đúng với các lập trình viên làm việc trí óc đâu!
Nhóm phát triển dự án:
Khi không chịu áp lực về thời gian, họ mạnh dạn áp dụng những kỹ thuật mới, dám loại bỏ đi những thiết kế tồi. Và kết quả của nó là những bài học, những kinh nghiệm quý báu mà chẳng có sách vở nào giúp bạn được. Kiến thức và kinh nghiệm làm việc của cả nhóm tăng lên sau mỗi dự án, không những thế niềm yêu thích và cảm giác thú vị trong công việc cũng tăng theo.
Ngược lại, chuyện gì sẽ xảy ra trong mộ môi trường luôn có áp lực về thời gian. Nhân viên của bạn rất sợ mắc lỗi, họ luôn hướng mọi giải pháp theo những gì mà họ đã làm hoặc ít nhất là đã biết. Chẳng có một ý tưởng mới, táo bạo gì trong công việc. Một môi trường như vậy sẽ làm thui chột tài năng và giết chết đi mọi cảm hứng.
Tôi có người bạn gặp phải một vấn đề nan giải: nhân viên của anh ấy cứ lần lượt rời khỏi nhóm mặc dù anh ta đã có chính sách đãi ngộ thích đáng. Sau thời gian tìm hiểu, anh ta nhận ra rằng nguyên nhân chính là vì tính chất công việc luôn đặt dưới áp lực thời gian, làm cho các nhân viên đó không dám áp dụng những cái mới, và dần dần họ không còn cảm giác thú vị với dự án nữa, việc ra đi là một sự tất yếu. Và hẳn ai đã làm quản lý đều biết rằng để tìm và đào tạo được một nhân viên mới không hề đơn giản tí nào.
Hỡi các nhà quản lý dự án, hãy sáng suốt lên!
Nếu không thì bạn thắng trong những trận đánh nhỏ, nhưng lại thất bại trong cả cuộc chiến.
Chất lượng sản phẩm:
Tôi vẫn còn nhớ cái cảm giác lần đầu tiên học lập trình, cái cảm giác vui sướng khi hoàn thành một chương trình; hay một niềm tự hào khi tìm ra được một thiết kế hay, một đoạn mã đơn giản hơn khi ngồi refactoring các đoạn mã. Cái cảm giác ấy hiện nay vẫn còn, và tôi cũng tin chắc rằng không chỉ có mình tôi có cảm giác đó. Đấy là sự thú vị của nghề lập trình.
Vì vậy, tôi hoàn toàn đồng ý với nhận đinh sau:
Một developer luôn gắn lòng tự trọng bản thân vào chất lượng sản phẩm họ sáng tạo ra.
Vì thế mà trong quá trình phát triển, các developer luôn định hình ra các tiêu chí về chất lượng sản phẩm riêng của họ, các tiêu chí này luôn cao hơn so với quan niệm của nhà quản lý cũng như sự chấp nhận của thị trường.
Trong khi đó các nhà quản lý lại không như vậy, dưới áp lực cần phải bàn giao sản phẩm đúng hạn, họ chỉ xem chất lượng là một thuộc tính của sản phẩm, nó thay đổi tùy vào đòi hỏi của thị trường. Chất lượng sản phẩm chẳng khác gì một nồi canh, khi có nhiều người dùng thì đổ thêm nước vào. Đi làm dự án nhiều, hẳn bạn thường phải nghe những lời phàn nàn thế này:
- “Tại sao cứ phải luôn cải tiến mã lệnh vậy?”
- “Thiết kế như vậy là tốt rồi, chúng ta không có nhiều thời gian”.
- “Vấn đề này không cần tốn nhiều thời gian như vậy”.
- “Tôi không cần biết nó có rắc rối gì, các anh phải có được sản phẩm vào tháng tư”
- …
Các nhận định này vô hình chung đã áp đặt một áp lực về thời gian lên nhóm phát triển sản phẩm, và tất nhiên họ buộc phải hi sinh chất lượng để lấy thời gian, cái mà không một lập trình viên nào cảm thấy hài lòng cả.
Các nhà quản lý dự án, xin chú ý:
Tiêu chí chất lượng sản phẩm mà các developers đưa ra luôn cao hơn mong muốn của bạn.
Hãy cho họ một cơ hội quyết định chúng.
Ai là người ước lượng thời gian hoàn thành sản phẩm?
Không tạo áp lực thời gian hoàn toàn không có nghĩ là để dự án “trôi nổi” vô định, kết thúc khi nào nó kết thúc. Mọi công việc đều phải được ước lượng thời gian hoàn thành, và không ai ước lượng tốt hơn chính bản thân những người thực hiện nó.
- “Hừm! Nhân viên của tao luôn ước lượng lớn hơn thời gian cần thiết nhiều”. Tôi nhận ngay một lời phản đối khi đưa ra nhận định trên.
Nhưng lần này tôi nghĩ hắn đúng, rõ ràng ước lượng là công việc đòi hỏi có nhiều kinh nghiệm.
Hãy để việc ước lượng cho nhóm phát triển sản phẩm dưới sự tư vấn của một nhân viên nhiều kinh nghiệm
Hẳn ai cũng từng nghe Modern Talking hát: “You can win if you want. If you want it you will win”. Thật vậy, mọi người đều nỗ lực khi bản thân họ muốn vậy. Developer cũng không ngoại lệ, họ sẽ có khuynh hướng làm việc tốt hơn để đạt được thời gian do chính mình ước lượng.
Lời kết
Hãy tưởng tượng một ngày nọ bạn tỉnh giấc và thấy mình đang đi trên dây, tay cầm sào giữ thăng bằng: đi nhanh quá thì ngã mà đi chậm quá cũng không xong, đứng lại thì càng không được. Hẳn là lúc đó bạn đang quản lý dự án đấy, rồi chuyện gì xảy ra đây nếu bạn lại thêm chứng bệnh sợ độ cao…
Không có nhận xét nào:
Đăng nhận xét