Vấn đề lớn nhất của quản lý dự án là con người

Bài viết được dịch từ blog Coding Horror

Đôi khi tôi cảm thấy giống như là mình đã học được tất cả mọi thứ cần biết về việc quản lý dự án phần mềm trên chương trình truyền hình Monster House.

Chính việc phối hợp tốt giữa các thành viên trong nhóm sẽ quyết định sự thành bại của dự án.Chính việc phối hợp tốt giữa các thành viên trong nhóm sẽ quyết định sự thành bại của dự án.

Monster House là một show truyền hình trên kênh Discovery. Có 5 người chơi ngẫu nhiên đóng vai thợ xây dựng và một người chủ trò chơi là Steve Watson, đóng vai một “con quỷ” để trang trí lại ngôi nhà của một ai đó trong vòng 5 ngày. Nếu những người chơi này hoàn thành dự án đó, thì họ sẽ nhận được một giải thưởng có trị giá 5000 đô-la bằng hiện vật là các trang thiết bị xây dựng. Nhưng điều đó thì có liên quan gì đến việc quản lý dự án phần mềm? Vâng, nó có thể nhiều hơn bạn nghĩ đấy.

  1. Show truyền hình đó chỉ diễn ra trong một khoảng thời gian rất hạn hẹp. Những thợ xây (người chơi đóng vai) chỉ có 5 ngày; và công việc đó phải được hoàn thành vào nửa đêm của ngày Thứ Sáu, không có một ngoại lệ nào. Nếu những người chơi không kết thúc công việc để làm hài lòng Steve thì họ sẽ chẳng nhận được gì cả.
  2. Đây là sửa chữa một ngôi nhà thực sự. Bạn sẽ không nhìn thấy bất kỳ một đồ dùng xây dựng giả tạo nào ở đây; những gã này phải thực sự ngồi xuống và tìm cách làm thế nào để tạo ra thật nhiều đồ vật sáng tạo hơn — một con thuyền chiến của cướp biển Viking nằm ở khoảng sân phía sau nhà, một sàn nhảy disco đầy ánh sáng, hay một phòng khách có phong cách Âu Châu, v.v…
  3. Show truyền hình đó sử dụng 5 người chơi khác nhau cho mỗi lần, cùng với tập các kỹ năng và nền tảng hoàn toàn khác nhau. Họ phải tự điều chỉnh để có thể thích hợp cho một công việc nào đó — bạn sẽ nhìn thấy hai người thợ hàn trong trò chơi sẽ làm việc nhiều với các thanh kim loại, và những người thợ sửa ống nước làm việc cùng với vòi nước. Nhưng những gã này thì tuyệt đối không vượt quá những khả năng và cá tính của họ.
  4. Người chủ trò chơi không quản lý những công nhân (người chơi) này. Ông ta phác thảo ra một sơ đồ xây dựng, và đảm bảo rằng những người chơi này phải gắn chặt với nó, nhưng ông ta nói chung không can thiệp vào công việc của họ, ngoại trừ một số trường hợp vô cùng đặc biệt nào đó.

Tất cả những điều này gợi cho tôi về mối liên quan rất lớn của mọi dự án phần mềm mà tôi đã từng tham gia vào. Bạn sẽ chẳng bao giờ biết được loại đồng nghiệp nào mà mình sẽ làm việc cùng, và bạn sẽ chẳng bao giờ thực sự biết chính xác mình đang xây dựng cái gì — cho tới khi bạn xây dựng nó. Nhưng lạy Chúa, mọi thứ cần phải hoàn thành đúng thời hạn!

Sau khi xem khoảng một tá chương trình Monster House, một điều cứ xuất hiện lặp đi lặp lại đó là: thành công của dự án thì hầu như hoàn toàn được quyết định bởi cái cách mà 5 người chơi ngẫu nhiên đó làm việc với nhau như thế nào. Nó thì không liên quan gì đến kỹ năng của họ. Những nhóm mà giỏi truyền thông và phối hợp với nhau trong công việc — cùng với rất ít xích mích — thì lúc nào cũng thành công. Những nhóm mà tranh cãi nhau chí chóe, và dẫn đến là bị phân tán thành 5 cá nhân riêng lẻ… thì không thành công. Đây cũng là tiền đề căn bản được đề cập trong cuốn sách “kinh điển” PeopleWare:

Chúng tôi quan sát thấy rằng khoảng 15% của tất cả các dự án được nghiên cứu bị tình trạng vô dụng: chúng bị hủy hoặc bỏ giữa chừng hoặc “bị hoãn lại” hoặc chúng tạo ra các sản phẩm mà chẳng bao giờ được sử dụng cả. Đối với các dự án lớn hơn, thì tỷ lệ thậm chí còn tồi tệ hơn. Có nhiều hơn 25% các dự án không thể hoàn thành. Trong những bản khảo sát trước đây, chúng tôi đã bỏ đi những dữ liệu thất bại này và đã phân tích những số liệu khác. Tuy nhiên, từ năm 1979 thì chúng tôi cũng liên hệ với rất nhiều người mà đã rời khỏi dự án để tìm hiểu xem có điều gì sai đang diễn ra. Có vô số những nguyên nhân chính dẫn tới việc sụp đổ của dự án mà chúng tôi đã nghiên cứu được, nhưng lạ lùng thay không có thậm chí chỉ một vấn đề công nghệ nào được giải thích là nguyên nhân thất bại cả.

Nguyên nhân của thất bại được viện dẫn thường xuyên nhất bởi những người tham gia cuộc khảo sát của chúng tôi là “chính trị”. Nhưng quan sát hiện nay cho thấy rằng những người có khuynh hướng sử dụng từ này khá là cẩu thả. Những thứ bao gồm dưới cụm từ “chính trị” thường là những thứ không liên quan hoặc liên quan rất ít như là những vấn đề trong truyền thông, vấn đề nhân sự, vỡ mộng với ông chủ hoặc với khách hàng, thiếu hụt động lực, và việc luân chuyển nhân sự quá lớn. Mọi người thường sử dụng cụm từ “chính trị” để mô tả bất kỳ khía cạnh nào của công việc mà liên quan đến con người, nhưng trong tiếng Anh có một thuật ngữ chính xác hơn cho những ảnh hưởng này: Chúng cấu thành tính xã hội học của dự án đó. Những vấn đề chính trị thực sự thường rất ít.

Nếu bạn nghĩ một vấn đề liên quan đến chính trị, thì bạn có khuynh hướng chấp nhận nó. Bạn biết mình có thể vượt qua những thách thức về kỹ thuật, nhưng thành thực mà nói, ai trong chúng ta có thể cảm thấy tự tin trong địa hạt chính trị cơ chứ? Nhưng bằng việc chỉ ra bản chất của vấn đề là xã hội học chứ không phải chính trị, thì bạn có thể khiến cho nó dễ dàng giải quyết hơn. Các vấn đề xã hội học trong dự án và trong nhóm làm việc có thể nằm ngoài kinh nghiệm của bạn một chút, nhưng bạn hoàn toàn có khả năng học cách giải quyết nó.

Bất cứ vấn đề liên quan đến con người mà bạn có thể nêu tên nó ra, hay nhiều khi bạn gặp rắc rối trong việc giao nhiệm vụ cho người của bạn hơn là những vấn đề trong thiết kế, thi hành và phương pháp luận mà bạn sẽ phải xử lý. Trong thực tế, cái ý tưởng được nhấn mạnh của toàn bộ cuốn sách này là: Những vấn đề chính trong công việc của chúng ta thì không liên quan nhiều đến công nghệ mà chủ yếu là về xã hội học.

Hầu hết các nhà quản lý sẵn lòng chấp nhận ý tưởng rằng họ phải lo lắng nhiều về vấn đề con người hơn là vấn đề kỹ thuật. Nhưng họ lại hiếm khi quản lý theo hướng đó. Họ quản lý như thể công nghệ là mối quan tâm hàng đầu của họ vậy. Họ dành thời gian quá nhiều vào những vấn đề hóc búa và những vấn đề thú vị nhất mà nhân viên của họ sẽ phải giải quyết, gần như là bản thân họ đang chạy đi làm công việc đó hơn là quản lý nó. Những khía cạnh liên quan đến con người trong trách nhiệm của họ thì thường có mức độ ưu tiên thấp nhất.

Một chủ đề khác cũng thường lặp lại — và nó dứt khoát liên quan đến vấn đề đầu tiên — đó là hội chứng quả táo thối. Trong rất nhiều trường hợp, một thành viên trong nhóm gây ra những ảnh hưởng tiêu cực đến toàn bộ phần còn lại của nhóm và anh ta đã đầu độc toàn bộ dự án. Trong những trường hợp đó, thành công của dự án dựa trên cách làm thế nào để nhóm đó loại bỏ thành phần có vấn đề càng nhanh càng tốt. Nếu họ chần chừ càng lâu, thì họ càng có nguy cơ bị thất bại nhiều hơn. Hy vọng rằng, điều này thì không mới đối với bất kỳ ai. Vấn đề về các thành viên trong nhóm thì cũng là phần quan trọng thứ 3 trong danh sách những sai lầm kinh điển mà tác giả McConnell đã đề cập trong cuốn sách của mình:

3. Vấn đề mất kiểm soát đối với nhân viên

Thất bại trong việc giải quyết các vấn đề nhân sự cũng là mối đe dọa nguy hiểm đến tốc độ phát triển. Đây là một vấn đề phổ biến và đã được hiểu rõ ít nhất là từ khi cuốn sách của tác giả Gerald Weinberg được xuất bản vào năm 1971 có tên là Psychology of Computer Programming (Tâm lý học trong việc lập trình máy tính). Thất bại trong việc đưa ra những hành động để xử lý một nhân viên có vấn đề là lời phàn nàn phổ biến nhất mà các thành viên trong nhóm nói về các leader của họ (Larson và LaFasto 1989). Trong Case Study 3-1, nhóm đó biết rằng anh chàng Gà là một “quả táo thối”, nhưng nhóm trưởng đã không làm bất cứ điều gì cả. Và kết quả là — cả nhóm phải làm lại tất cả những công việc mà Gà ta đã làm — đó là một điều có thể đoán trước được.

Thực ra không có điều gì mới ở đây cả, nhưng nó cứ lặp đi lặp lại trên màn hình đến mức khó tin, cùng với những người khác nhau vào mỗi show khác nhau. Đừng cho phép điều này xảy ra đối với nhóm của bạn nhé!

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

Về tác giả bài viết:

Jeff_atwood_coding_horrorJeff Atwood là một chuyên gia công nghệ tại Mỹ, hiện đang sinh sống và làm việc tại Berkeley, CA. Anh là một kỹ sư phần mềm chuyên về công nghệ Microsoft .NET, và là một blogger nổi tiếng trong cộng đồng công nghệ với blog Coding Horror, anh là người sáng lập và kiêm Giám đốc điều hành (CEO) của trang web hỏi đáp uy tín Stack Overflow và cũng là đồng sáng lập của Stack ExchangeDiscourse.

Advertisements

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s