Có nghiên cứu nào về các nhóm chức năng chéo so với các nhóm dựa trên miền (ví dụ: dựa trên dự án so với phần mềm / cơ học / vv) không?


8

Tôi làm việc trong một tổ chức tạo ra nhiều sản phẩm hệ thống tích hợp - tức là nó là sản phẩm hoàn chỉnh với cơ khí / hệ thống / điện tử / phần mềm được thiết kế và sản xuất. Hiện tại, hầu hết các đội được tổ chức xung quanh các dự án theo cách đa chức năng. Ưu điểm của một tổ chức như thế này là những người đang làm việc chặt chẽ với nhau vì một mục tiêu chung là gần gũi.

Những bất lợi đến từ sự cô lập của các kỹ sư từ các đồng nghiệp của họ. Thông thường một dự án được chỉ định một kỹ sư phần mềm. Điều này có nghĩa là các dự án có yếu tố xe tải cao, chia sẻ kiến ​​thức tối thiểu và thực hành tốt nhất và phát triển kỹ thuật bị hạn chế.

Vì vậy, câu hỏi của tôi là: có nghiên cứu nào so sánh chi phí / lợi ích của hai phương pháp này không?


Đúng. Mỗi ngày có rất nhiều công ty đưa ra lựa chọn này. Và mỗi ngày, nhiều công ty thấy rằng nó không thực sự quan trọng lắm. Nếu có người chiến thắng rõ ràng, nó đã bị khóa trong thực tiễn kinh doanh. Những ý tưởng thiết yếu đã có từ khi phát minh ra đường sắt và cửa hàng bách hóa. Vì không có người chiến thắng rõ ràng, điều đó nói gì với bạn?
S.Lott

Tôi nghĩ rằng đây là một câu hỏi hay, nhưng tôi tự hỏi liệu nó sẽ có được khả năng hiển thị phù hợp hơn trong Quản lý dự án. Những vấn đề này thường vượt qua sự phát triển phần mềm và có thể được áp dụng cho bất kỳ nhóm nào trong bất kỳ cài đặt dự án nào. Ngoài ra, @ S.Lott nó rất quan trọng. Tuy nhiên, không có người chiến thắng vì cả hai đều hoạt động (và hoạt động tốt) trong một số điều kiện nhất định. Thật không may, tôi đang thực sự nghỉ giữa các nhiệm vụ, vì vậy tôi không có thời gian để trả lời ngay bây giờ. Tôi sẽ cung cấp một câu trả lời ngay khi tôi có thêm thời gian.
Thomas Owens

@Thomas Owens: "không có người chiến thắng vì cả hai đều hoạt động (và hoạt động tốt) trong những điều kiện nhất định"? Điều đó không thể đúng. Nếu không, sẽ có một câu trả lời trong sách dạy nấu ăn, và mọi doanh nghiệp chỉ đơn giản là bị bắt buộc (bởi luật sư và kiểm toán viên của họ) tuân theo cách tiếp cận sách dạy nấu ăn đó.
S.Lott

Tôi nghĩ ý nghĩa của Thomas Owens (sửa tôi nếu tôi sai) là nó phụ thuộc vào văn hóa công ty. Tôi đã làm việc trong các công ty khác nhau, những người từng sử dụng một trong những cách tiếp cận này và nó đã làm việc cho họ. Tôi thậm chí đã thấy công việc này giữa các phòng ban trong cùng một công ty (mỗi bộ phận sử dụng một mô hình khác nhau). Theo tôi thì điều này phụ thuộc rất nhiều vào văn hóa công ty và con người.
NomadAlien

Câu trả lời:


3

Loại cấu trúc nhóm tốt nhất để sử dụng không nhất thiết phải là một lợi ích chi phí, mà thay vào đó là văn hóa tổ chức hiện tại, đặc điểm của nhân viên và loại dự án đang được tiến hành. Do các biến này, không có cách nào để nói rằng một chiến lược hoặc cách tiếp cận cụ thể là tốt nhất, nhưng có một số chỉ số chung về cách bạn có thể cấu trúc tốt nhất một nhóm để hoàn thành nhiệm vụ trong tay.

Có nhiều loại đội và cách tổ chức đội và tổ chức . Một số hình thức phổ biến hơn là chức năng, nhẹ, nặng và tự trị. Dưới đây, tôi đang tóm tắt một phần của cuốn sách về quản lý đổi mới công nghệ - Quản lý chiến lược đổi mới công nghệ của Melissa A. Schilling .

Một nhóm chức năng là hoàn toàn không chức năng chéo. Mỗi nhân viên vẫn ở trong bộ phận riêng của họ. Sự cô lập hoàn toàn giữa khoa học, kỹ thuật, nguồn nhân lực, v.v. Một nhân viên sẽ báo cáo cho người quản lý chức năng. Theo cấu trúc này, những người làm việc trong một dự án có xu hướng cam kết nhiều hơn với bộ phận chức năng của họ hơn là với dự án. Cấu trúc này phù hợp với những gì được gọi là dự án phái sinh - tận dụng công việc hiện tại chỉ với những sửa đổi hoặc cải tiến nhỏ và các dự án chỉ (hoặc chủ yếu) yêu cầu một loại chuyên môn duy nhất.

Các nhóm nhẹ xảy ra khi các thành viên cư trú trong các bộ phận chức năng của họ và báo cáo cho các nhà quản lý chức năng. Tuy nhiên, một người quản lý dự án được giới thiệu. Người quản lý dự án sẽ giám sát những người cần thiết để thực hiện dự án, nhưng không quản lý trực tiếp họ. Vai trò của người quản lý dự án là tạo điều kiện giao tiếp và đảm bảo rằng mỗi thành viên trong dự án được đóng góp thích hợp. Cấu trúc này là tốt nhất cho các dự án phái sinh không đòi hỏi nhiều sự phối hợp và giao tiếp giữa các thành viên.

Các đội hạng nặng loại bỏ các cá nhân cần thiết khỏi các bộ phận chức năng của họ, tuy nhiên họ vẫn báo cáo cho người quản lý chức năng. Người quản lý dự án giám sát các hoạt động của dự án, nhưng không trực tiếp giám sát hoặc quản lý từng thành viên trong nhóm. Các nhà quản lý dự án thường vượt trội hơn các nhà quản lý chức năng trong môi trường này và chịu trách nhiệm đánh giá, khen thưởng và lãnh đạo các thành viên dự án. Các nhóm này có mức độ giao tiếp và hợp tác cao trong số những người được giao cho dự án và các thành viên cũng cam kết cho sự thành công của dự án. Định dạng này được sử dụng trên các dự án nền tảng, được sử dụng để cải thiện chi phí, chất lượng và hiệu suất từ ​​thế hệ trước (nhưng có thể không có sự đổi mới mới đáng kể).

Các nhóm tự trị loại bỏ hoàn toàn các thành viên khỏi các bộ phận chức năng và để họ làm việc trực tiếp dưới một người quản lý dự án. Quản lý dự án ở đây là nhân viên cấp cao và lãnh đạo của tổ chức. Đôi khi, các nhóm này được trao quyền tự do to lớn để "hoàn thành công việc" bằng cách phát triển các chính sách và quy trình của riêng họ. Đồng thời, họ sẽ phải chịu trách nhiệm hoàn toàn cho những thành công hay thất bại của dự án. Các loại nhóm này thường được triển khai trên các dự án đột phá, giới thiệu sự đổi mới mới cho các sản phẩm của tổ chức hoặc để sản xuất các đơn vị kinh doanh mới.

Tuy nhiên, chỉ vì một loại nhóm cụ thể có thể nói chung là tốt cho một loại dự án cụ thể, nó cũng quan trọng văn hóa của tổ chức là gì. Một số tổ chức không thể (hoặc sẽ không) hỗ trợ các đội tự trị vì lý do văn hóa. Những người khác "đã luôn luôn làm điều đó" theo một cách nhất định và đơn giản là sẽ không thay đổi. Nó cũng quan trọng loại người nào trong nhóm - một số người hoạt động tốt hơn nếu họ được tham gia và có mức độ giao tiếp và khả năng cộng tác cao, trong khi những người khác thích không gian của họ để giải quyết vấn đề và ném nó ra ngoài.

Các giấy tờ / sách / tài liệu sau đây được trích dẫn bởi phần của cuốn sách tôi đang đọc:

  • SC Wheelwright và KB Clark, Cách mạng hóa phát triển sản phẩm: Bước nhảy vọt lượng tử về tốc độ, hiệu quả và chất lượng (New York: Free Press, 1992).
  • F. Damanpour, "Đổi mới tổ chức: Phân tích tổng hợp các tác động của các yếu tố quyết định và điều hành," Tạp chí Học viện Quản lý số 34, không. 3 (1991).
  • EF McDonough, "Điều tra các yếu tố góp phần vào sự thành công của các nhóm chức năng chéo." Tạp chí Quản lý đổi mới sản phẩm 17 (2000).

Cảm ơn, tôi đánh giá cao các tài liệu tham khảo, tôi sẽ xem xét thêm về điều này.
mikelong

@mikelong Nếu bạn muốn nhiều hơn, hãy xem xét các chủ đề hành vi tổ chức và lãnh đạo khác - đó sẽ là những loại tài nguyên sẽ thảo luận chi tiết hơn về vấn đề này.
Thomas Owens

1

Mặc dù bạn có thể có các nhóm chức năng chéo, nhưng điều đó cũng không gây hại cho đội ngũ những đội có nhiều kỹ sư bán thời gian. Ví dụ, bạn có thể đưa Bob vào dự án a và dự án b và cũng đưa Jane vào dự án a và dự án b. Cách này được phân phối, tuy nhiên, nếu bạn có các dự án đủ nhỏ để xây dựng chỉ với một kỹ sư phần mềm, thậm chí cách tiếp cận này có thể có những hạn chế.

Một lựa chọn khác có thể là giữ cho cấu trúc nhóm giống nhau nhưng tổ chức môi trường làm việc xung quanh chức năng. Đặt tất cả các kỹ sư phần mềm lại với nhau, nơi họ có thể hợp tác trong một môi trường mở. Điều này đi ngược lại với một số suy nghĩ và đôi khi mọi người sẽ phòng thủ khi bạn hạ tường, nhưng nó có thể giúp làm việc theo kiểu sắp xếp bút bò.

Khái niệm hợp tác cũng dựa trên điều này. Các chuyên gia tư vấn và thiết kế độc lập, nếu không sẽ làm việc trong một văn phòng tại nhà, hãy chuyển đến một cơ sở chia sẻ nơi họ có thể nuôi sống những thế mạnh của nhau.

Có thể không có nhiều ý tưởng về những ý tưởng này, có lẽ bạn có thể đưa nó cho các nhóm tham gia như một thử nghiệm để có năng suất tốt hơn và sự hài lòng trong công việc. Sau đó viết lên một tờ giấy trắng về kết quả.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.