Quản lý dự án phần mềm - 12 tips quản lý đội nhóm siêu hay

10/04/2022
Posted by: admin
Category: Tin nhanh

Quản lý dự án phần mềm - 12 tips quản lý đội nhóm siêu hay

Quản lý đội nhóm phát triển phần mềm là một việc khó khăn, ngay cả đối với các tổ chức có tính kỷ luật cao và được thành lập một cách tốt nhất. Mọi khía cạnh của quá trình phát triển phần mềm phải được cân nhắc và cân bằng một cách cẩn thận, cho phép nhiều nhóm sản xuất tham gia một cách bình đẳng và hiệu quả từ đó tạo ra được các phần mềm mà khách hàng sẽ thực sự yêu thích. Việc quản lý các nhóm này đòi hỏi sự hiểu biết về các chi tiết của dự án, cùng với hiểu được bức tranh rộng hơn về các mối quan hệ trong và giữa các nhóm, cũng như các yêu cầu kinh doanh đằng sau mỗi quyết định điều hành.

Để đối phó tốt hơn với những thách thức quản lý này, dưới đây là 12 mẹo quản lý nhóm phần mềm được thu thập từ nhiều doanh nghiệp trong ngành, tất cả đều đã được thực hành và triển khai thành công trên nhiều dự án trong vài thập kỷ qua. Hãy cùng tham khảo!

12 tips hay quản lý đội nhóm phần mềm

1. Chỉ nên thuê những người đam mê công việc của họ

Quản lý nhóm phần mềm không nên tập trung vào việc kiểm soát quá kỹ những chi tiết vụn vặt trong công việc hàng ngày của mỗi nhà phát triển, cũng như không nên giám sát xem mỗi thành viên có dành đủ tám giờ mỗi ngày để sản xuất hay không. Kiểu quản lý vi mô này không chỉ kém hiệu quả mà còn cực kỳ bất lợi cho tinh thần chung của cả đội. Không ai muốn một ông chủ hoặc giám đốc điều hành rình rập hoặc để ý mọi hành động của họ.

Vì vậy, một trong những vai trò quan trọng nhất mà bạn phải có khi quản lý nhóm phần mềm là thuê đúng người. Ý nghĩa của điều này sẽ khác nhau giữa các tổ chức, nhưng nên có một bài kiểm tra để đánh giá xem là liệu các nhà phát triển có thích loại công việc mà họ đang làm để họ chủ động làm việc trong những khoảng thời gian riêng tư hay không. Quan trọng là, chúng tôi không có ý đề cập đến việc các nhà phát triển thực sự đang làm việc riêng trong thời gian chính thức, mà thay vào đó, các nhà phát triển thích viết mã các dự án cá nhân của riêng họ, chỉ để giải trí. Trên thực tế, Google đã phần nào trở nên nổi tiếng với chính sách "20 phần trăm thời gian" cho phép nhân viên dành 20 phần trăm thời gian để làm việc cho các dự án và ý tưởng của riêng họ. Bất chấp những gì một số báo cáo đã tuyên bố trong vài năm qua, hoạt động này vẫn đang diễn ra mạnh mẽ tại Google và đã trở thành thông lệ phổ biến trong toàn ngành.
Xem thêm: Quản lý dự án là gì? Cơ hội nghề nghiệp của quản lý dự án?

2. Tránh sử dụng thêm nhân lực như một giải pháp đẩy tiến độ

Một trong những quy tắc cơ bản nhất của phát triển phần mềm là việc thêm nhiều người vào một dự án rắc rối, bị trì hoãn sẽ không đẩy nhanh quá trình mà ngược lại sẽ làm chậm tiến độ, dẫn đến sự chậm trễ thậm chí còn lớn hơn. Tuy nhiên, hết lần này đến lần khác, các giám đốc điều hành và nhà quản lý đi đến kết luận dường như hiển nhiên rằng nhiều nhân lực hơn đồng nghĩa với nhiều sản lượng hơn. Quy tắc này có thể có hiệu quả trong các lĩnh vực sản xuất nhất định, chẳng hạn như thêm nhiều nhân lực hơn vào dây chuyền nhà máy sản xuất phụ tùng, nhưng ngay cả trong những tình huống giả tưởng như vậy, tại một số điểm, những người phụ đó sẽ cản trở quá trình thực hiện hiện có, gây ra nhiều rắc rối hơn là lợi ích. Tương tự như vậy, phát triển phần mềm là một quá trình sản xuất đặc biệt phức tạp, không thể thô bạo buộc phải phục tùng - phát triển phần mềm là một vở ba lê thanh lịch, nơi những ý tưởng tuyệt vời gặp nhau trong việc triển khai mạnh mẽ.

Cố gắng hết sức để tránh bị chậm tiến độ hoặc cho phép nhóm của bạn gặp phải những thất bại lớn, nhưng nếu vấn đề như vậy xảy ra, một trong những điều tồi tệ nhất bạn có thể làm là cố gắng bổ sung thêm nhiều người mới để mọi thứ trở lại như cũ. Bên ngoài việc điều chuyển nhân sự ồ ạt gây ra tình trạng thiếu nhân lực trầm trọng cho những công việc khác, tốt hơn hết bạn nên tập trung vào việc định hình lại cách thực hành và tư duy của những thành viên trong nhóm hiện có, những người đã quen thuộc với dự án cũng như các yêu cầu phức tạp của dự án. Nếu một lượng máu mới phải được thêm vào một dự án đã chảy máu, hãy đảm bảo rằng nó được thêm vào một cách nhỏ giọt chậm rãi, thay vì tiêm thẳng máu vào tim.
Xem thêm: Cấu trúc tổ chức dự án trong một doanh nghiệp (Project Management Organizational Structure)

3. Biết giới hạn của bạn ở đâu

Khái niệm này không chỉ nằm ở những giới hạn cá nhân của bạn với tư cách là người lãnh đạo, mà còn nên được áp dụng cho phần còn lại của nhóm, nên xác định giới hạn của đội nhóm cùng với các vấn đề phải được giải quyết trong một dự án tại bất kỳ thời điểm nào. Nói một cách đơn giản, điểm mấu chốt ở đây là luôn chia nhỏ công việc khi tiếp cận một vấn đề có vẻ khó giải quyết. Thay vì cố gắng thực hiện nó một cách dài dòng và giải quyết nó trong một lần, hãy chia nó thành các nhiệm vụ nhỏ hơn và nhỏ hơn, cho đến khi phạm vi của các nhiệm vụ đã nói dường như có thể quản lý được và nhóm có thể xử lý được. Nếu kỹ thuật phân chia này được thực hành đủ thường xuyên, sẽ không bao giờ có bất kỳ vấn đề lớn nào không thể vượt qua.
Xem thêm: 7 kỹ năng cần có của người quản lý dự án

4. Tích cực lắng nghe, chủ động giao tiếp

Thực hành tích cực lắng nghe các thành viên trong nhóm và những người quản lý khác, để hiểu rõ hơn về tình trạng và tiến độ đang diễn ra của từng nhóm và cả dự án. Tích cực lắng nghe các nhận xét, phản hồi và câu hỏi, sau đó hãy chắc chắn quay lại với các câu hỏi tiếp theo của riêng bạn, chẳng hạn như "Bạn đã làm việc gì? Nó có kết hợp với nhau không? Tại sao? Tại sao không? Có thể cải thiện điều gì?"

Cuối cùng, vai trò của bạn khi quản lý nhóm phần mềm không phải là quản lý các dự án hoặc sản phẩm, mà là duy trì sự hạnh phúc và hiệu suất công việc của những người làm việc xung quanh bạn. Do đó, bạn nên thực hành giao tiếp chủ động, cho dù đó là kiểm tra với trưởng nhóm hoặc người quản lý một cách thường xuyên, hoặc chỉ đơn giản là đi bộ xung quanh và trò chuyện thân mật với các nhà phát triển. Nghe có vẻ đơn giản, nhưng nếu được thực hành đủ thường xuyên và với sự quan tâm và nỗ lực thực sự, cuối cùng bạn sẽ thiết lập được các mối quan hệ chất lượng. Điều này sẽ cho phép và khuyến khích các thành viên trong nhóm tiếp cận bạn để giải quyết các vấn đề có thể chưa được giải đáp. Cho dù những vấn đề này liên quan đến dự án hay cá nhân, tất cả đều tích cực nếu việc giao tiếp được diễn ra một cách chủ động và không bị đóng băng cứ lại.

5. Yêu cầu các nhóm làm việc gần nhau

Quản lý nhiều nhóm phần mềm có thể là một thách thức ngay cả trong môi trường tốt nhất, nhưng không có gì làm cho nhiệm vụ này trở nên khó khăn hơn khi các nhóm được cho là hoàn toàn tách biệt với nhau, về mặt địa lý, theo thứ tự thời gian, v.v. Có lẽ không có gì ngạc nhiên khi các nghiên cứu đã chỉ ra rằng các nhóm hoạt động tốt hơn nhiều khi họ làm việc gần nhau. Nếu có thể, hãy để tất cả các nhóm làm việc trong cùng một tòa nhà, lý tưởng nhất là trên cùng một tầng hoặc thậm chí trong cùng một không gian làm việc. Điều này sẽ làm tăng đáng kể việc phổ biến thông tin theo cách không chính thức. Các đồng nghiệp đang làm việc trong các nhóm hoàn toàn khác nhau sẽ có xu hướng chia sẻ thông tin về dự án của họ một cách tự nhiên, điều này luôn dẫn đến việc giải quyết vấn đề bên ngoài khi một thành viên của Nhóm A đề xuất giải pháp cho điều gì đó gây khó khăn cho Nhóm B.

Hơn nữa, bất kỳ hiềm khích nào giữa các đội có xu hướng biến mất (bằng vũ lực, nếu không có gì khác) khi các đội được gắn kết với nhau. Ví dụ: buộc các nhà phát triển và người kiểm tra đảm bảo chất lượng làm việc gần nhau để cải thiện mối quan hệ, đồng thời giảm đáng kể tỷ lệ lỗi và mã code có vấn đề. Nói tóm lại, các thành viên trong nhóm sẽ tương trợ lẫn nhau.
Xem thêm: Làm thế nào để làm việc linh hoạt hơn?

6. Tránh kiệt sức

Vòng đời phát triển phần mềm không nên được coi là một cuộc chạy nước rút mãnh liệt, mà đúng hơn, như một cuộc chạy marathon nhịp độ tốt. Việc buộc các nhóm phần mềm liên tục làm việc với tốc độ quá mức sẽ nhanh chóng dẫn đến kiệt sức trong toàn nhóm, điều này chắc chắn sẽ gây ra các vấn đề phát triển, lỗi trong mã và cuối cùng là quá trình phát triển kéo dài hơn, tốn kém hơn. Các nhà phát triển cảm thấy hạnh phúc trong công việc sẽ tạo ra mã chất lượng cao, vì vậy việc quản lý các nhóm phần mềm nên cho phép cân bằng công việc và cuộc sống lành mạnh.

Điều đó nói rằng lên rằng, điều này không có nghĩa là không bao giờ có những tình huống đòi hỏi sự thúc đẩy thêm về tiến độ. Nói một cách thông thường, những giai đoạn như vậy thường được gọi là chạy nước rút bởi vì, giống như thể bạn đang chạy marathon với tốc độ ổn định trong một thời gian, về cuối, bạn có thể cần phải chạy nước rút trong chút thời gian cuối cùng để về đích trong thời gian cho phép. Hầu hết các nhóm có thể xử lý các pha chạy nước rút không thường xuyên, miễn là những khoảng thời gian này là ngoại lệ và được bù đắp bằng tốc độ vừa phải trong phần còn lại của vòng đời phát triển.

Tình trạng kiệt sức cũng có thể xảy ra do bố trí nhân lực quá mỏng. Mặc dù quản lý nhiều nhóm phần mềm nên tạo cơ hội cho các nhóm làm việc chặt chẽ với nhau, nó không nên đưa ra các tình huống mà các thành viên đang làm việc trên nhiều dự án cùng một lúc. Hầu hết mọi người không thể sắp xếp công việc cho hai dự án riêng biệt cùng một lúc và cố gắng làm như vậy sẽ chỉ có hại cho cả hai dự án. Thay vào đó, hãy đảm bảo rằng các nhóm được xác định rõ ràng và làm việc tập trung vào dự án ưu tiên cao cho mỗi nhóm.

7. Lập Kế hoạch và Tài liệu một cách phù hợp

Cố gắng tạo ra phần mềm phức tạp, mạnh mẽ mà không có bất kỳ một bộ tài liệu yêu cầu nào giống như cố gắng dựng bốn bức tường của một ngôi nhà mà không có bất kỳ dầm đỡ nào - ngay cả khi bạn cố gắng nâng cao mọi thứ, cuối cùng mọi thứ sẽ tự sụp đổ. Vấn đề với các yêu cầu phần mềm là chúng phức tạp, không rõ ràng. Các yêu cầu có thể vượt quá phạm vi hoặc được viết thiếu - một dự án có thể hầu như không chứa tài liệu yêu cầu, trong khi dự án tiếp theo có thể bao gồm hàng nghìn trang thông tin yêu cầu. Tìm kiếm sự cân bằng thích hợp giữa lập kế hoạch và xây dựng các tài liệu yêu cầu dự án là một thách thức thực sự đối với hầu hết các dự án phát triển phần mềm.

Với các phương pháp quản lý dự án theo kiểu thác nước truyền thống hơn, không có gì lạ khi các yêu cầu là các tài liệu dày cộp chứa đầy mọi thứ rất rõ ràng. Điều này thường dẫn đến các dự án có quy mô quá lớn và quá nhiều yêu cầu khiến quá trình phát triển diễn ra nhanh như chớp - thông thường, vào thời điểm sản phẩm cuối cùng được phát hành, nhu cầu của khách hàng và / hoặc thị trường đã hoàn toàn thay đổi. Đó là một rủi ro rất lớn có thể dẫn đến làm lại sản phẩm từ bước đầu.

Do đó, các phương pháp Agile hiện đại tránh được cạm bẫy này bằng cách xoay con lắc theo cách khác, thường đẩy các yêu cầu sang một bên. Điều đó nói lên rằng, tập trung vào nhu cầu và lợi ích của phần mềm hơn là các yêu cầu cứng nhắc. Trong quá trình phát triển phần mềm việc thay đổi yêu cầu nên được thực hiện một cách tự nhiên để tạo ra sản phẩm phù hợp nhất vào giai đoạn kết thúc dự án.
Xem thêm: Bài học kinh nghiệm (Lessons Learned) trong dự án là gì?

8. Tạo phần mềm mà mọi người yêu thích

Các yêu cầu đặc biệt quan trọng khi xem xét là từ khách hàng / người dùng, vì khách hàng hiếm khi biết họ muốn gì. Giám đốc điều hành, người quản lý, nhà phát triển và tất cả mọi người ở giữa sẽ nói không ngừng về tất cả các loại khái niệm nhằm đo lường tiến trình và khả năng thành công của phần mềm, chẳng hạn như yêu cầu, ngân sách, lập lịch, tính năng, v.v. Tuy nhiên, phán quyết cuối cùng về việc liệu phần mềm mà nhóm của bạn đang sản xuất có đến từ người dùng hay không: Nếu mọi người yêu thích phần mềm của bạn, dự án của bạn đã thành công; tất cả những thứ khác đều không có ý nghĩa. Vì vậy, bạn nên cố gắng để ý niệm đó luôn đập trong tâm trí bạn: "Mọi người sẽ thích điều này? Tại sao hoặc tại sao không?"

9. Thiết lập ngay các tiêu chuẩn cao

Mặc dù điều quan trọng là không nên ép buộc một tốc độ phát triển không thực tế cho đội nhóm (đúng hơn là thực hiện một cách tiếp cận marathon), nhưng điều quan trọng không kém là phải thiết lập các tiêu chuẩn chất lượng cao mà bạn mong đợi ở các đội nhóm của mình ngay từ đầu. Hầu hết các nhà phát triển sẽ phản hồi tốt với sự củng cố tích cực trong vài ngày đầu tiên của một dự án, chẳng hạn như yêu cầu một chất lượng mã nhất định trong giai đoạn đầu này và khen ngợi chất lượng đã đạt được, sẽ khuyến khích các nhà phát triển phấn đấu cho mức đó trong suốt phần còn lại của Chu trình phát triển phần mềm.

10. Loại bỏ những yếu tố phân tâm cho các nhà phát triển

Theo bản chất của công việc họ làm, các nhà phát triển có xu hướng trở thành những cá nhân ưu logic và tập trung cao độ. Do đó, điều cuối cùng họ cần khi tập trung sâu vào một vấn đề khó khăn là ít bận tâm đến các cuộc họp ngẫu nhiên hoặc công việc hành chính bận rộn. Do đó, một trong những vai trò của bạn với tư cách là người quản lý là giảm (hoặc thậm chí loại bỏ) những phiền nhiễu tiềm ẩn này. Bạn nên dành ra các khoảng thời gian trong ngày để công việc của các nhà phát triển không bị gián đoạn (nếu các cá nhân muốn điều đó), quản lý danh sách nhiệm vụ và trạng thái có thể truy cập.

11. Xây dựng vừa đủ quy trình

Thách thức thực sự của người quản lý nhóm phần mềm, là tìm ra sự cân bằng chính xác giữa quy trình có trật tự và tình trạng hỗn loạn. Khi quá nhiều thứ tự và thủ tục áp đặt vào, toàn bộ sự việc sẽ bị dừng lại và ít đạt được tiến bộ công việc. Tương tự, quá nhiều rối loạn cũng ngăn cản sự tiến triển, vì sự phát triển hỗn loạn dẫn đến phần mềm nhiều lỗi.

Bí quyết là tìm ra sự cân bằng giữa cả hai, điều này thường bắt đầu với ý tưởng rằng chỉ nên đưa vào quy trình một lượng thủ tục tối thiểu. Ví dụ, thiết lập một quy trình phức tạp trong đó các lỗi phần mềm được kiểm tra, báo cáo, theo dõi, giải quyết, kiểm tra lại, xác nhận, v.v. là một thủ tục khó khăn cho mọi thành viên trong nhóm. Thay vào đó, câu thần chú phải là tìm ra mức độ tối thiểu của thủ tục có thể chấp nhận được có thể được sử dụng để hoàn thành nhiệm vụ trong tầm tay.

Hãy xem phần mềm theo dõi lỗi của Airbrake ngay hôm nay và tự mình tìm hiểu lý do tại sao rất nhiều nhóm kỹ sư giỏi nhất thế giới sử dụng Airbrake để cách mạng hóa các phương pháp xử lý ngoại lệ của họ!

12. Hãy quản lý cánh rừng chứ đừng quản lý từng cái cây

Quản lý nhóm phần mềm, đặc biệt là trong các tổ chức lớn, có thể dẫn đến rất nhiều công việc bận rộn hàng ngày. Trả lời email, tham dự cuộc họp, nhận cuộc gọi; tất cả đều có thể nhanh chóng tăng lên và hút hết phần lớn hoặc thậm chí toàn bộ thời gian trong ngày của bạn. Điều này chắc chắn sẽ không còn thời gian cho công việc của bạn: Khuyến khích người khác tạo ra phần mềm mà mọi người yêu thích. Vì vậy, điều quan trọng đối với sự thành công của các nhóm của bạn là bạn không bị sa lầy vào những công việc vụn vặt hàng ngày và luôn dành cho mình đủ thời gian và năng lượng để thực hiện các nhiệm vụ rộng lớn hơn cần thiết cho vai trò của bạn, rất nhiều trong số đó chúng tôi đã được đề cập trong suốt bài viết này!

Nếu thấy bài viết thú vị, đừng ngại ấn LIKE - SHARE - COMMENT để ủng hộ VNPMI nhé!

Các bài viết liên quan:

Số 229 Tây Sơn, Đống Đa, Hà Nội