Quản lý dự án phát triển phần mềm được ví như những con mèo chăn gia súc. Nói cách khác, bạn thực sự không thể thực hiện một cách hoàn hảo, nhưng bạn chắc chắn phải cố gắng hết sức. Quản lý một dự án phần mềm cũng giống như cố đối đầu với LeBron James tại giải NBA. Bạn không thể ngăn cản anh ta, bạn chỉ có thể hy vọng có thể kiềm chế anh ta.
Không có gì bí mật khi quản lý một dự án phần mềm là một khoa học không chính xác. Dưới đây là 11 bài học mà Nick Hodges, tác giả của blog nickhodges.com, người đã có nhiều năm trong quản lý các dự án phát triển phần mềm đã học được. Những bài học này anh đã học hiểu được những hạn chế trong khả năng quản lý thế giới kỳ lạ của các dự án phát triển phần mềm.
1. Ước tính luôn sai
Cho dù bạn ước tính thực hiện điều gì đó trong một giờ hay một năm, ước tính của bạn không thể nào chính xác. Có thể sẽ không thực sự sai và chỉ sai một chút, nhưng sai là sai.
Nếu bạn xem một báo cáo lỗi và nghĩ “sẽ mất một giờ để sửa” thì gần như chắc chắn sẽ không mất một giờ. Có thể mất 45 phút, có thể mất ba giờ, nhưng khả năng chính xác một giờ, thậm chí sai số một hoặc hai phút, là rất nhỏ. Thay vào đó, bạn có thể nói “khoảng một giờ”. Đó thực sự là một ước tính tốt hơn vì ước tính thực tế, chính xác là không thể.
Bây giờ đối với các dự án nhỏ có thể mất một giờ, đây không phải là vấn đề lớn. Nhưng…
2. Dự án càng lớn, ước tính càng kém chính xác
Dự án càng lớn, ước tính càng ít chính xác – đặc biệt nếu ước tính đó được thực hiện ngay từ đầu dự án. Như với ước tính giờ ở trên, nếu bạn ước tính một dự án trong một năm, thì có thể mất chín tháng hoặc 36 tháng. Trong một số trường hợp, có thể mất 5 năm. Không có cách nào để biết được thời gian hoàn thành chính xác khi nào dự án bắt đầu.
Dự án càng lớn thì càng có nhiều “ẩn số”. Thường có nhiều người tham gia hơn. Nghĩa là, khi quy mô của một dự án tăng lên, sẽ có nhiều biến số hơn và nhiều điều sẽ xảy ra mà bạn không thể lường trước được. Tất cả những điều này sẽ tăng thêm thời gian cho dự án mà bạn không thể lập kế hoạch ngay từ đầu bởi vì theo định nghĩa thì bạn không biết rằng chúng sẽ xảy ra.
3. Khó khăn để giữ sự tập trung
Khi xây dựng phần mềm, điều có giá trị nhất cần thiết để hoàn thành một dự án là khả năng tập trung của các developers trong nhóm một cách hiệu quả.
Càng ít phiền nhiễu, nhóm sẽ càng làm việc hiệu quả hơn. Nó thực sự đơn giản. Một trong những trách nhiệm chính của người quản lý phát triển phần mềm là giảm số lượng và thời gian gây xao nhãng cho đội dự án.
Các nhà phát triển phần mềm, khi bị bỏ lại một mình, có thể làm việc khá hiệu quả. Khi họ bị gián đoạn – cho dù là cho cuộc họp hay mọi người đặt câu hỏi hay bất cứ điều gì – họ có thể mất năng suất đó rất nhanh chóng. Tất cả chúng ta đều biết về “dòng chảy” và khó khăn như thế nào để hòa vào dòng chảy và ở lại đó. Thời gian dòng chảy đó giống như vàng và cần được bảo vệ như vậy.
4. Luật Hofstadter
Luật Hofstadter được phát biểu như sau:
“Luôn mất nhiều thời gian hơn bạn mong đợi, ngay cả khi bạn tính đến Luật Hofstadter.” – Wikipedia
Định luật Hofstadter mô tả khó khăn trong việc ước tính chính xác thời gian cần thiết để hoàn thành các nhiệm vụ có độ phức tạp đáng kể.
Điều này liên quan đến các ước tính, nhưng điều quan trọng cần lưu ý là vẻ đẹp của câu cách ngôn này. Bạn có thể bổ sung các ước tính của mình bởi vì bạn nghĩ rằng nó sẽ giúp bạn có thời gian để hoàn thành công việc. Bạn có thể thêm các yếu tố bổ sung, lập kế hoạch cho “ẩn số chưa biết” và tăng ước tính của mình để tính đến niềm tin rằng sẽ mất nhiều thời gian hơn bạn nghĩ. Nhưng cuối cùng, việc hoàn thành một dự án vẫn mất nhiều thời gian hơn sau tất cả những ước tính bổ sung đó.
5. Không thể tăng tốc độ phát triển và chỉ có thể giới hạn mức độ làm chậm quá trình phát triển phần mềm
Sự thật này thực sự khó hiểu đối với một số nhà quản lý. Phát triển phần mềm sẽ mất nhiều thời gian. Không có cách nào để làm cho nó đi nhanh hơn. Bạn có thể yêu cầu nhóm làm thêm giờ. Bạn có thể cầu xin và vỗ về và cầu xin. Bạn có thể nói, “Nhưng điều này sẽ chỉ mất ba tháng!” Cuối cùng, bạn không thể tăng tốc độ của nhóm phát triển phần mềm về lâu dài (tức là trong quá trình thực hiện một dự án).
Nếu bạn bắt đầu nhận ra rằng Luật Hofstadter thực sự đúng và bạn nghĩ, “Tôi có thể khiến những người này làm việc nhanh hơn,” bạn đã nhầm. Tất cả những gì bạn thực sự có thể làm là ngăn họ hoạt động chậm hơn bằng cách giảm bớt sự phân tâm và cho phép họ làm việc tự chủ. Đó là một sự khác biệt nhỏ, nhưng đó là một điều quan trọng.
6. Bạn chỉ có thể chạm vạch đỏ trong một khoảng thời gian rất rất ngắn
Bạn có thể yêu cầu nhóm làm thêm giờ, làm việc vào cuối tuần và với tất cả những cố gằng đó, và bạn có thể nhận được một số lợi ích ngắn hạn.
Nhưng nếu bạn cố gắng biến nó thành tiêu chuẩn – nếu bạn cố gắng chạy động cơ của đội mình ở vạch đỏ RPM một cách liên tục – bạn sẽ đốt cháy động cơ. Bạn sẽ thấy lợi ích giảm đi khá nhanh. Con người, giống như động cơ xe đua, không thể hoạt động quá mức trong thời gian dài mà không bị hỏng.
Thuật ngữ đường đỏ (redline) xuất phát từ thực tế là bạn chạm đến các vạch đỏ trên máy đo tốc độ (bộ đếm RPM). Đó là tốc độ động cơ tối đa bạn có thể đạt được sẽ không gây hại cho xe.
7. Thời gian não quan trọng hơn thời gian mông
Không có gì sẽ làm giảm năng suất hơn việc đòi hỏi Butt Time (tức là các nhà phát triển của bạn được nhìn thấy ngồi trên ghế của họ hàng giờ liền). Bạn có thể đo lường Butt Time và cảm thấy như bạn đã có một số liệu thực sự cho thấy mọi người đang làm việc hiệu quả như thế nào. Nhưng bạn đã nhầm. Yêu cầu Butt Time sẽ làm mất tinh thần của một nhóm thực sự muốn dành thời gian trí óc.
Thời gian Não bộ là thứ thực sự quan trọng. Hãy nghĩ về điều này theo cách này: Giả sử bạn là một người quản lý và điều quan trọng nhất là bạn phải thấy nhóm của mình ngồi tại bàn của họ “làm việc”. Bạn đi lang thang quanh văn phòng và thấy những nhà phát triển đó đang ngồi trên ghế, đập bàn phím của họ. Tất cả có vẻ là rất tốt với thế giới này.
Nhưng sau đó bạn gặp một developer và họ chỉ ngồi đó nhìn chằm chằm vào màn hình của họ. Đó là nó. Họ đang ngồi và nhìn chằm chằm. Trong nửa giờ. Cái quái gì vậy! Họ không làm gì cả!
Nhưng sự thật là họ đang suy nghĩ. Họ đang dành thời gian trí óc để giải quyết một vấn đề rất khó. Có thể họ thậm chí đứng dậy và đi lang thang xung quanh tòa nhà một lúc. Cuối cùng, họ ngồi xuống, gõ 11 dòng mã và đánh dấu một mộ việc đã hoàn thành.
Họ có đáp ứng tiêu chí “Butt Time” của bạn không? Không. Họ đã đưa ra một giải pháp tuyệt vời cho một vấn đề rất khó? Đúng.
Butt Time không chứng minh được gì. Brain Time có nghĩa là tất cả mọi thứ.
8. Phần cứng rẻ hơn thời gian của nhà phát triển
Các developers đắt tiền. Bạn trả mức lương cạnh tranh để thu hút nhân tài hàng đầu. Một giờ thời gian của họ không hề rẻ. Mặc dù vậy, nhiều công ty không nhận ra giá trị đáng kinh ngạc của một giờ dành cho nhà phát triển và tiết kiệm phần cứng cho nhóm.
Nhưng thôi nào, máy tính rất đắt! RAM bổ sung đó sẽ phá vỡ ngân sách cho phần cứng!
Chà, nó có thể phá vỡ ngân sách, nhưng đó là do bạn gặp vấn đề về ngân sách.
Hãy nhìn nó theo cách này: Giả sử bạn trả cho nhà phát triển 100.000 đô la một năm – hoặc khoảng 50 đô la một giờ. Giả sử họ dành một giờ mỗi ngày để chờ trình biên dịch thực hiện công việc của nó. Sau đó, giả sử bạn có thể thêm một số RAM và bộ xử lý nhanh hơn vào máy của nhà phát triển đó và cắt giảm thời gian đó xuống còn 45 phút mỗi ngày. Bạn tiết kiệm được 15 phút mỗi ngày. Ở 200 ngày một năm, tức là 50 giờ. Với 50 đô la một giờ, tức là 2.500 đô la tiết kiệm cho mỗi nhà phát triển mỗi năm. Nhưng điều gì sẽ xảy ra nếu chi phí gia tăng của chiếc máy nhanh hơn là 500 đô la?
Bạn sẽ có được điểm. Nếu bạn có 20 nhà phát triển, việc sở hữu máy nhanh hơn sẽ giúp bạn tiết kiệm được 40.000 đô la cho khoản đầu tư 10.000 đô la. Điều đó không có gì phải bàn cãi.
Và điều đó chỉ dành cho thời gian biên dịch nhanh hơn. Mọi thứ khác họ làm cũng sẽ nhanh hơn.
Nếu ngân sách của bạn không cho phép các máy nhanh hơn, thì bạn cần phải điều chỉnh ngân sách của mình.
9. Bạn không thể đo lường năng suất của nhà phát triển phần mềm
Cố gắng đo lường năng suất của nhà phát triển một cách khách quan là một việc vặt vãnh và không nên thử. Có những cách chủ quan mà bạn có thể đo lường năng suất, nhưng điều đó đòi hỏi kinh nghiệm và khả năng phán đoán tốt. Những thứ đó rất khó có được và vô giá khi bạn có chúng.
10. Nếu bạn chưa đọc “PeopleWare”, thì bạn thực sự không phải là Giám đốc phát triển phần mềm
Có một cuốn sách sẽ dạy bạn cách quản lý các nhà phát triển phần mềm: Peopleware của Tom DeMarco và Timothy Lister (nhớ lấy ấn bản thứ ba…). Cuốn sách này rất xuất sắc, sâu sắc, rõ ràng. Nó chứa đầy sự khôn ngoan về quản lý các dự án phần mềm và các nhà phát triển phần mềm. Hãy đọc cuốn sách này.
11. Chất lượng là một nhận thức – Không phải là số lượng lỗi
Điều này thực sự khó chấp nhận.
Đây là tiền đề cơ bản: Bạn có thể gần như không có bug trong hệ thống theo dõi lỗi (bug tracker) của mình nhưng mọi người vẫn có thể nghĩ rằng phần mềm của bạn có lỗi. Bạn có thể có một số lượng lớn lỗi trong bug tracker và mọi người có thể nghĩ rằng phần mềm của bạn thật hoàn hảo. Không có mối tương quan nào giữa số lượng lỗi trong hệ thống theo dõi lỗi và nhận thức về chất lượng phần mềm của bạn.
Không ai nói rằng bạn không nên cố gắng giảm số lượng lỗi của mình – hoàn toàn ngược lại. Nhưng cuối cùng, phần mềm của bạn chỉ có thể được cho là có chất lượng cao nếu khách hàng của bạn nhìn nhận nó theo cách đó – và số lượng lỗi của bạn không nhất thiết phải quyết định điều đó. Thật kỳ lạ phải không nào?
Và có số lượng lỗi “nhiều” là thế nào? Định nghĩa “nhiều” là gì khi codebase của bạn có 100.000 dòng code? và khi có 5 triệu dòng code?
Kết luận
Để một dự án phần mềm hạ cánh an toàn trên đường băng ngắn là một đề xuất đầy thách thức và khó khăn trong cả khi có hoàn cảnh tốt nhất. Bí quyết là chấp nhận và hiểu những điều mơ hồ đó và làm việc với chúng, không chống lại chúng. Việc chấp nhận 11 sự thật này sẽ giúp ích cho công việc của bạn
Bài viết được đăng trên Betterprogramming
Bạn có biết?
tham gia cộng đồng ITguru trên Linkedin, Facebook và các kênh mạng xã hội khác có thể giúp bạn nhanh chóng tìm được những chủ đề phát triển nghề nghiệp và cập nhật thông tin về việc làm IT mới nhất
Linkedin Page:
Facebook Group:
cơ hội việc làm IT : ITguru.vn
