Là nhà phát triển luân phiên trên một dự án là một ý tưởng tốt hay xấu?


38

Tôi đang làm việc trong một nhóm nhỏ sẽ bắt đầu thực hiện một dự án lớn mới với một nhóm nhỏ khác. Nhóm khác hiện đang làm việc trên một hệ thống di sản mà họ đã làm việc trong nhiều năm.

Người quản lý đã quyết định rằng các nhà phát triển từ nhóm của tôi sẽ luân chuyển cứ sau vài tháng để thay thế các nhà phát triển làm việc trên hệ thống cũ. Bằng cách đó, nhóm khác sẽ có cơ hội làm việc trong dự án mới và hiểu rõ hơn về hệ thống mới.

Tôi muốn biết những lợi ích và hạn chế (nếu có) của việc luân chuyển các nhà phát triển khỏi dự án cứ sau 2-3 tháng.

Tôi biết rằng đây là một câu hỏi tương tự như "Xoay vòng nhà phát triển chính là ý tưởng tốt hay xấu?" , nhưng câu hỏi đó tập trung vào một nhà phát triển chính. Câu hỏi này là về việc luân chuyển toàn bộ nhóm trong và ngoài dự án (công nghệ. Dẫn dắt cho dự án mới có thể hoặc không thể xoay vòng - tôi chưa biết).



2
Tôi không muốn biến điều này thành câu hỏi chủ quan / tranh luận bằng cách đưa ra ý kiến ​​cá nhân của mình trong câu hỏi. Cảm giác ruột của tôi là đây không phải là một ide tốt, nhưng có lẽ có điều gì đó mà tôi không biết về :)
Christian P

1
Lý do nào mà người quản lý đưa ra khi bạn hỏi anh ta tại sao? Đó là lợi ích tốt nhất của một công ty để chia sẻ kiến ​​thức về một sản phẩm trong trường hợp các nhà phát triển rời đi.
dcaswell

1
Đó là một vấn đề. Nếu quản lý của bạn chưa hoàn toàn minh bạch về vấn đề này thì đó có lẽ là một dấu hiệu cho thấy họ chưa nghĩ đến điều đó.
Aaronaught

1
Những gì tôi muốn đề xuất là bạn làm cho nhóm thân mật bắt đầu dự án bao gồm một số nhà phát triển di sản hiện tại và một số nhà phát triển dự án mới hiện tại. Giữ chúng thông qua porject. Cuối cùng, các nhà phát triển độ trễ hỗ trợ sản phẩm mới và các nhà phát triển mới tham gia một số nhà phát triển kế thừa khác để thực hiện dự án tiếp theo. Theo cách đó, nhóm nghiên cứu giống nhau thông qua dự án (Hoặc phát hành chính) nhưng những người kế thừa sẽ tăng tốc về những gì họ sẽ hỗ trợ sau này. Những người được thuê mới thường bắt đầu bằng di sản trừ khi họ có một số kỹ năng đặc biệt mà nhóm của bạn không có nhu cầu cho dự án.
HLGEM

Câu trả lời:


76

Tôi ngạc nhiên khi mọi người nghĩ rằng đây là một điều tốt. Các tác giả của Peopleware (IMO, vẫn là một trong số ít những cuốn sách quản lý dự án phần mềm quý giá thực sự đáng đọc) không đồng ý. Hầu như toàn bộ Phần IV của cuốn sách được dành riêng cho vấn đề này.

Các phần mềm đội là đơn vị chức năng vô cùng quan trọng. Các đội cần phải nói để trở nên thực sự hiệu quả. Phải mất nhiều thời gian ( rất nhiều thời gian) để các thành viên trong nhóm có được sự tôn trọng của nhau, để tìm hiểu thói quen và những điều kỳ quặc cũng như điểm mạnh và điểm yếu của nhau.

Chắc chắn, từ kinh nghiệm cá nhân, tôi có thể nói rằng sau một năm làm việc với một số người nhất định, tôi đã học được cách cười nhạo những điều đã từng làm tôi khó chịu, ước tính của tôi với tư cách là trưởng nhóm tốt hơn nhiều và không quá khó để nhận được công việc phân phối để làm cho tất cả mọi người hạnh phúc. Nó đã không như thế lúc ban đầu.

Bây giờ bạn có thể nói, "Ồ, nhưng chúng tôi sẽ không chia tay cả đội, chỉ di chuyển một vài người." Nhưng hãy xem xét (a) việc thay thế một cách mù quáng sẽ không có tác dụng ngay từ đầu và (b) bạn sẽ thấy mình hoặc các đội khác nói bao nhiêu lần, thậm chí không nghĩ rằng "Tôi thực sự thích X" hoặc "Điều này sẽ có vẫn dễ dàng hơn với Y vẫn ở xung quanh " , xúc phạm một cách vô thức và vô thức các thành viên mới và tạo ra những quan điểm trong nhóm hiện có, thậm chí gieo rắc sự bất bình giữa các thành viên" cũ ".

Tất nhiên mọi người không làm điều này trên mục đích , nhưng nó xảy ra gần như mọi lúc. Mọi người làm điều đó mà không cần suy nghĩ. Và nếu họ buộc mình không làm, cuối cùng họ sẽ tập trung vào vấn đề hơn nữa, và thất vọng vì sự im lặng bắt buộc. Các nhóm và thậm chí các nhóm phụ sẽ phát triển các hiệp lực bị mất khi bạn xoay quanh cấu trúc. Các tác giả của Peopleware gọi đó là một hình thức "giết người".

Điều đó đang được nói, mặc dù các thành viên trong nhóm luân chuyển là một thực tế khủng khiếp, bản thân các đội xoay vòng là hoàn toàn tốt. Mặc dù các công ty phần mềm hoạt động tốt nên có một số khái niệm về quyền sở hữu sản phẩm, nhưng gần như không gây khó chịu cho một nhóm để chuyển toàn bộ nhóm đó sang một dự án khác, miễn là nhóm thực sự hoàn thành dự án cũ hoặc ít nhất là đưa nó đến một mức độ họ hài lòng với.

Bằng cách có các gợi ý nhóm thay vì các gợi ý dành cho nhà phát triển , bạn sẽ nhận được tất cả các lợi ích giống như bạn mong muốn nhận được với các nhà phát triển luân phiên (tài liệu, "thụ phấn chéo", v.v.) mà không có bất kỳ tác dụng phụ khó chịu nào trên mỗi nhóm như một đơn vị. Đối với những người không thực sự hiểu về quản lý, có vẻ như kém năng suất hơn, nhưng hãy yên tâm rằng năng suất bị mất bằng cách tách nhóm hoàn toàn làm giảm năng suất bị mất bằng cách chuyển nhóm đó sang một dự án khác.

PS Trong chú thích của bạn, bạn đề cập rằng vai công nghệ có thể là chỉ người không đến được luân chuyển. Điều này là khá nhiều đảm bảo để gây rối cho cả hai đội. Người lãnh đạo công nghệ là một nhà lãnh đạo, không phải là người quản lý, anh ta hoặc cô ta phải giành được sự tôn trọng của nhóm và không chỉ đơn giản là được cấp quyền quản lý cao hơn. Đặt toàn bộ đội ngũ dưới sự chỉ đạo của một người lãnh đạo mới mà họ chưa từng làm việc và rất có khả năng có những ý tưởng khác nhau về những thứ như kiến ​​trúc, khả năng sử dụng, tổ chức mã, ước tính ... tốt, nó sẽ căng thẳng như địa ngục cho người dẫn đầu cố gắng xây dựng uy tín và rất không có tác dụng đối với các thành viên trong nhóm, những người bắt đầu mất sự gắn kết trong trường hợp không có người lãnh đạo cũ. Đôi khi các công ty để làm điều này, tức là nếu người dẫn đầu bỏ cuộc hoặc được thăng chức, nhưng thực hiện nó bằng sự lựa chọn nghe có vẻ điên rồ.


2
Đừng hoàn toàn không đồng ý - tuy nhiên không phải là không có lỗi của nó - Các đội có thể và thực hiện các đế chế được xây dựng, đôi khi những vụ vỡ vụn này không phải luôn luôn là mục tiêu quan trọng nhất của một người quản lý, người (nếu có thể), đang hướng đến trò chơi kết thúc nhiều hơn khác có thể được.
mattnz

4
@mattnz: "trò chơi kết thúc" nào dành cho người quản lý ngoài năng suất cao, giữ chân nhân viên và có thể giao hàng đúng thời hạn / ngân sách? Tất nhiên, tôi đang nói về các nhà quản lý đạo đức , những người thực sự muốn làm những gì tốt nhất cho công ty và không sử dụng nhóm hoặc dự án như một phương tiện để tiếp tục các mục tiêu nghề nghiệp cá nhân của họ. Một tổ chức phần mềm muốn các đế chế - các đế chế ổn định và kiếm tiền - và vâng, các đế chế có thể sụp đổ, nhưng chúng ít có khả năng sụp đổ hơn một ngôi nhà thẻ.
Aaronaught

2
luân chuyển tốt hơn so với những người rời khỏi công ty hoàn toàn
warren

4
@warren: Nếu hai lựa chọn đó là lựa chọn duy nhất của bạn, thì cái sau gần như không thể tránh khỏi.
Aaronaught

3
Tôi thực sự không hiểu câu trả lời này. Mọi người trong nhóm nên là một người chuyên nghiệp và làm việc tốt với những người khác giả định rằng tất cả các thành viên trong nhóm thực sự có năng lực là một vấn đề khác nhau. Các thành viên trong nhóm luân phiên thường là sự lựa chọn duy nhất cho một người quản lý thường xuyên bị thiếu trong cả hai sản phẩm hoặc khi sự tiêu hao gây ra mối đe dọa nghiêm trọng. Ngay từ đầu thường rất khó tìm được tài năng tốt. Xoay vòng các thành viên trong nhóm là một cách để phòng ngừa các vụ cá cược chống lại các nhà phát triển rời đi. Nó cũng công bằng hơn với các nhà phát triển làm việc trên phần mềm cũ khi họ muốn tìm hiểu một cái gì đó mới.
maple_shaft

18

Bản thân tôi không thấy nhiều nhược điểm ở đây. Vòng quay giúp bạn:

  • Thụ phấn chéo của kiến ​​thức thể chế - mọi người sẽ biết dự án kế thừa và dự án mới, ít nhất là trên lý thuyết.
  • Đào tạo chéo - các dự án khác nhau đòi hỏi những thứ khác nhau thường xuyên. Bạn phát triển nhiều hơn với tư cách là một nhà phát triển làm việc trong các dự án cũ, xấu xí hơn là trong các dự án xanh sạch đẹp.
  • Về cơ bản các dự án tốt hơn - không có gì giống như có một nhóm mới tham gia để khiến bạn hoàn thành tài liệu và dọn sạch các quy trình xấu xí mà bạn sẵn sàng sống cùng nhưng không công khai thừa nhận.
  • Mã tốt hơn - nhiều đầu tốt hơn trong hầu hết các trường hợp.
  • Có khả năng cải thiện tinh thần - sự đa dạng là gia vị của cuộc sống. Và ai muốn bị mắc kẹt trong chế độ sửa lỗi / ghi ống lỗi dự án cũ. Ngoài ra, hãy nhớ rằng dự án "mới" của bạn sẽ trở thành di sản vào một lúc nào đó, bạn có muốn bị mắc kẹt ở đó mãi mãi không?

Có lẽ nhược điểm duy nhất là giảm năng suất bạn nhận được từ việc chuyển đổi địa điểm nhưng điều đó chỉ làm tổn hại đến vòng đầu tiên. Sau đó, cả hai bên sẽ có thời gian ngồi ở cả hai nơi và những phần xấu xí của bàn giao có lẽ sẽ được hiểu rõ hơn và có lẽ sẽ được giải quyết.


18
Tôi không thấy tinh thần của mình sẽ được cải thiện như thế nào nếu tôi bị "hạ cấp" để làm việc trên hệ thống cũ.
Telastyn

3
Một vài nhược điểm là trong thời gian phát triển ban đầu đi lên và các nhiệm vụ cụ thể khác của nhóm kế thừa nhận được các ưu tiên thấp hơn.
Oded

16
@Telastyn Nếu công ty cũ của tôi đã bị loại khỏi công việc cũ, tôi vẫn sẽ làm việc ở đó. Chắc chắn rằng nó hút để được xoay vòng, nhưng nó thậm chí còn hút nhiều hơn để biết bạn sẽ không bao giờ bị xoay vòng đơn giản chỉ vì họ cần một nhà phát triển kế thừa.
BeardedO

8
@Telastyn và Christian và những người khác: Đó là vấn đề của bạn nếu bạn xem đó là việc giáng chức. Làm việc trên các hệ thống cũ là một thách thức trong chính nó có thể mang lại cho bạn trải nghiệm vô giá để sử dụng lợi thế của bạn trong phát triển lĩnh vực xanh. Phát triển Greenfield thực sự nên có ít "tín dụng" hơn so với nó vì nó dễ dàng hơn nhiều so với việc cố gắng tạo ra các tính năng mới trên cơ sở hiện tại ngay cả một cơ sở không có nhiều nợ kỹ thuật. Phát triển lĩnh vực màu nâu là nơi bạn tìm thấy những người thợ và phụ nữ thực sự. Vâng, bạn cũng tìm thấy chúng ở nơi khác, nhưng không phải là những người chiến đấu cứng.
Marjan Venema

8
@MarjanVenema - Xin lỗi, thực hiện một số công việc bảo trì trong Cobol sẽ không thúc đẩy sự nghiệp của tôi. Chắc chắn, công việc có thể cần được thực hiện và nó thậm chí có thể là kinh nghiệm quý giá - nhưng nếu người quản lý của tôi chuyển tôi đến toàn thời gian đó, tôi sẽ đưa sơ yếu lý lịch của mình ra càng sớm càng tốt. Thực tế của vấn đề là một số nhà phát triển sẽ coi đây là việc hạ cấp, bất kể nó thực sự là gì. Cân bằng nhận thức này với mong muốn thụ phấn chéo không phải là vấn đề của tôi, đó là vấn đề của người quản lý; đó là họ công việc .
Telastyn

6

Thật thú vị, theo kinh nghiệm của tôi, chúng tôi thường bắt đầu các dự án của chúng tôi với ý định này. Chúng tôi thường thất bại trong việc thực hiện ý định này do những ràng buộc đối với dự án mới hơn và tin rằng đào tạo chéo là quá tốn kém.

Tôi luôn mong muốn chúng tôi đã quản lý nó, vì về lâu dài tôi tin rằng nó có lợi cho tất cả các bên - nhóm, công ty, khách hàng và phần mềm. 2/3 tháng nghe có vẻ như đủ dài để có nguy cơ hạn chế bất kỳ tác động tiêu cực nghiêm trọng nào, không có sự chuyển đổi bối cảnh nào xảy ra cho các nhà phát triển liên quan ngoại trừ tại thời điểm chuyển đổi mà tại đó họ có thể cống hiến cho dự án thay thế.

Một vài lợi ích có thể không được đề cập:

  • Quản lý dự án tốt hơn. Nếu các nhà quản lý dự án cho cả hai dự án đều ở trên tàu thì đó là lợi ích tốt nhất của họ để làm việc chăm chỉ để các giai đoạn chuyển tiếp không gây đau đớn cho cả hai dự án. Đây là lượt (tùy thuộc vào thiết lập của bạn) có thể mang lại sự hợp tác chặt chẽ hơn giữa các PM và nhóm phát triển.
  • Tài liệu tốt hơn (chủ động). Nếu bạn biết rằng bạn đang được chuyển đổi trong và ngoài một dự án, thì đó không chỉ là lợi ích tốt nhất của dự án, là công ty quan tâm nhất, thực tiễn tốt nhất nói chung, mà giờ đây, mỗi nhà phát triển đều có lợi ích tốt nhất để làm cho cuộc sống dễ dàng trong khi họ đang nảy xung quanh.
  • Điều tinh thần là một vấn đề lớn, nếu các nhà phát triển của bạn không bị mắc kẹt trong một dự án cũ, thì họ có thể không phải là nhà phát triển bạn muốn! Nếu họ có, chuyển đổi chúng xung quanh và khiến các nhà phát triển khác làm việc với nó sẽ khiến họ cảm thấy yêu thích công ty của bạn - họ có thể thu dọn các đoạn mã mà họ nghĩ sẽ không ai thấy được. Các hệ thống kế thừa thường được xem là dự án hạng hai thường gây bất lợi cho chúng, có thể theo cách này bạn sẽ giúp thay đổi nhận thức đó.

Tôi nghĩ rằng đây là cách nó kết thúc ở hầu hết các công ty. Mục tiêu cao cả, nhưng yêu cầu quay vòng nhanh và tránh chi phí tức thời tối thiểu thường cản trở việc đào tạo chéo và phát triển chéo do năng suất bị mất khi đưa ai đó mới tăng tốc vào dự án.
BBlake

2
@BBlake Vâng, thật không may, đó là trường hợp. Thật không may, vì nó rất thiển cận và rủi ro khá cao cho một công ty "hạn chế" kiến ​​thức về các hệ thống quan trọng đối với số lượng người thấp hơn.
Marjan Venema

1
Thật không may, hầu hết các doanh nghiệp, bao gồm cả ngân hàng lớn trên toàn thế giới mà tôi mới rời khỏi để làm việc ở nơi khác, quan tâm nhiều hơn đến điểm mấu chốt của dự án hoặc tuần hoặc ngân sách này, hơn là họ đang lên kế hoạch trước cho các chi phí sẽ xảy ra khi một nhà phát triển cao cấp ( như bản thân tôi) lá. Không có ngân sách cho đào tạo chéo trên các ứng dụng, tôi chỉ có quen biết nâng cao. Thêm hàng tá giờ làm việc lãng phí theo dõi các vấn đề sản xuất mà tôi có thể giải quyết trong vài giờ vì tôi biết các hệ thống. Thiển cận, nhưng đó là cách của công ty.
BBlake

@Marjan: Tôi sẵn sàng đặt cược rằng các chi phí phát sinh khi phải đào tạo chéo một cách thường xuyên sẽ cao hơn nhiều so với chi phí đào tạo một người thuê mới khi cần nếu có người rời đi. Bây giờ, nếu toàn bộ đội rời đi, thì đó là một vấn đề khác.
Dunk

1
@ Dunk: Tôi không biết rằng nó sẽ. Đào tạo chéo không cần phải đi xa như làm cho chéo đào tạo một chuyên gia trong lĩnh vực không trực tiếp là của mình. Nó chỉ cần đi xa để đảm bảo rằng doanh nghiệp sẽ ngay lập tức gặp khó khăn và có nguy cơ mất khách hàng khi các chuyên gia lĩnh vực rời đi khiến cho sự phát triển trong lĩnh vực đó bị đình trệ. Không ai là không thể thay thế, nhưng kinh doanh 'gặp rủi ro khi kiến ​​thức hoặc kỹ năng quan trọng bị hạn chế ở rất ít người. Và chi phí cho rủi ro đó trở thành hiện thực có thể rất, rất cao.
Marjan Venema 14/12/13

4

Xoay vòng là một điều tốt cho công ty, và cũng có thể là một điều tốt cho các nhà phát triển.

Có rất nhiều lý do chính đáng và Wyatt đã đề cập đến nhiều trong số đó trong câu trả lời của mình.

Điều đó đang được nói, trong tình huống của bạn, bạn có thể thấy khi giới thiệu điều này, các nhà phát triển đang chuyển dự án mới hơn sang dự án cũ có thể không hài lòng, vì vậy cần phải truyền thông rất rõ ràng tại sao điều này xảy ra và trong bao lâu là cho, và kế hoạch sắp tới.

Có thể tốt khi nghĩ đến việc không trao đổi các đội bán buôn để bắt đầu và xoay 1 hoặc 2 nhà phát triển để bắt đầu, mặc dù điều này có vẻ giống như việc mọi người bỏ qua để hạ chức (mà một số người có thể thấy).


Tôi thích ý tưởng hoán đổi chỉ 1-2 dev để bắt đầu. Điều đó sẽ giúp giảm tác động tiêu cực ban đầu đến năng suất.
superM

Bạn đang làm việc với các nhà phát triển phần mềm, không phải người bình thường. Các nhà phát triển phần mềm có xu hướng logic. Họ không thể dễ dàng bị thao túng như công chúng bằng cách kết hợp các ý tưởng như ở trên. Các thủ thuật khác có hiệu quả hơn đối với chúng, (ví dụ: màn hình lớn hơn, máy tính nhanh hơn) nhưng không phải là chính trị vì ý tưởng này đang cố gắng thực hiện. Nó sẽ là một tiêu cực cho những người trong nhóm phát triển mới, không có vấn đề gì. Lời hứa về phần thưởng (ví dụ. Xem ở trên) là về cách duy nhất để che đậy mùi vị xấu. Tất nhiên, nó sẽ rất tuyệt (lúc đầu) cho những người bảo trì, cho đến khi họ nhận ra họ không ủng hộ điều đó.
Dunk

2

Đồng ý với Aaronaught rất kỳ lạ khi thấy có bao nhiêu người không nhìn thấy nhược điểm .. Rất ít suy nghĩ, rằng bạn có thể chỉ ra rất nhanh - mã không có chủ sở hữu và khi mọi người chịu trách nhiệm về mọi thứ không tốt cho chất lượng . Các nhà phát triển không phải là tài nguyên (thậm chí họ thường được các nhà quản lý gọi như vậy), họ là người và đối với đội ngũ là rất quan trọng để biết nhau, xoay vòng làm cho một chút hỗn loạn ở đó. Nếu bạn làm việc cho một dự án nào đó trong thời gian dài hơn, bạn sẽ trở thành một chuyên gia (không chỉ trong lĩnh vực, mà trong dự án đó), bạn sẽ biết hầu hết các rắc rối đến từ đâu, ai sẽ giúp bạn có câu trả lời tốt nhất hoặc có thể là một số kiến ​​thức tên miền cụ thể hơn, v.v. Nếu bạn là người mới, bạn sẽ cần học tất cả những suy nghĩ này, vì vậy nó sẽ làm chậm tiến độ. Nhưng tất nhiên cũng tốt khi biết các thực tiễn khác trong tổ chức của bạn, làm thế nào các đội khác xây dựng và tổ chức. Điều này đặc biệt tốt nếu các dự án của bạn có liên quan theo một cách nào đó, ví dụ một dự án là đầu vào cho một dự án khác (không cần thiết trực tiếp), vì vậy sẽ hiểu rõ hơn về bức tranh lớn. Và tất nhiên việc truyền bá chuyên môn là tốt (nếu bạn sẽ có thời gian để có được những kiến ​​thức này).


bài này khá khó đọc (tường văn bản). Bạn có phiền chỉnh sửa ing nó thành một hình dạng tốt hơn?
gnat

2

Tôi đồng ý với câu trả lời hàng đầu của Aaronaught và tôi có một số bổ sung.

  • Mọi người không thích bị đẩy xung quanh.
  • Trong một thiết lập kinh doanh phân cấp, mọi người có thể được phân công trách nhiệm mà sau đó lại bị lấy đi từ họ. Đây có thể chỉ là một phần của công việc. Tuy nhiên, điều này càng thường xuyên xảy ra, những người này sẽ càng ít cảm thấy có trách nhiệm với bất cứ điều gì được giao cho họ.
  • Điểm trước đây cũng áp dụng cho công việc bảo trì trên những thứ mà chính người dân không tạo ra. Dọn dẹp mớ hỗn độn của người khác (hoặc có công thức trung lập hơn: công việc còn dang dở) không đặc biệt thúc đẩy hầu hết các cá nhân tạo ra.
  • Triết lý "lập trình viên là lập trình viên là lập trình viên, họ là các trình cắm thêm ẩn danh để chèn vào các dự án khi cần" không làm cho bất kỳ lập trình viên nào cảm thấy được đánh giá cao hoặc quan tâm nhiều hơn đến các nhiệm vụ được giao.

Thời điểm hoàn hảo để phân công lại bất cứ ai là khi họ bắt đầu chán với những gì họ đang làm. Không còn gì để đạt được, mọi thứ đều nằm trong tầm kiểm soát, công việc đã hoàn thành. Trong những trường hợp này, họ thường sẽ tiến về phía trước và yêu cầu các cơ hội khác.

Tất nhiên thực tế là cứng đầu và thường không có sự lựa chọn, ai đó có thể cần ở nơi khác vì lý do gì. Điều này không hẳn là xấu, nó cũng có thể khiến một người cảm thấy quan trọng và nếu người đó giải quyết một số vấn đề lớn, sẽ có tín dụng trong đó cho anh ta.

Chỉ cần xáo trộn mọi người xung quanh để truyền bá kiến ​​thức có khả năng tăng doanh thu. Bằng cách đó, kiến ​​thức sẽ được lan truyền, nhưng nó sẽ được lan truyền ra bên ngoài công ty mà có lẽ không phải là mục đích.


0

TL; DR Làm cho nó thành một nhóm và sau đó là một nhóm hỗ trợ 2 dự án.

Để lặp lại @Aaronaught Tôi nghĩ rằng các nhóm trộn có thể có vấn đề vì có thể mất thời gian để thích nghi với các thực tiễn, quy trình mới, v.v. Nếu bạn xoay quá nhiều người để nhanh chóng nhóm sẽ mất bản sắc. Điều này dẫn đến nhiều câu hỏi, nhầm lẫn và thời gian cố gắng để bù đắp cho danh tính đó.

Mặt khác, nếu có nỗ lực phối hợp để tham gia 2 đội vào một đội và có 1 đội hỗ trợ 2 dự án tôi nghĩ điều đó sẽ hiệu quả miễn là đội đó không quá lớn. Tôi đã là một phần của nhiều đội hỗ trợ nhiều dự án. Công nghệ càng gần hai dự án thì việc chuyển đổi càng dễ dàng. Theo kinh nghiệm của tôi, chi phí cao hơn khi chuyển từ dự án này sang dự án khác xuất hiện khi giao tiếp ngôn ngữ, máy khách / máy chủ (đặc biệt là GUI), công nghiệp (y tế, web, trò chơi) hoặc các dòng tương tự khác. Bí quyết là khiến những người khác nhau làm việc trong dự án đủ thường xuyên để đạt được lợi ích, nhưng không thường xuyên đến mức chi phí chuyển đổi vượt quá lợi ích.

Sau đó, lợi ích để có được nhiều người hơn trong một dự án là khá nổi tiếng, cũng như các chi phí.


1
"Miễn là đội không quá lớn" là chìa khóa ở đây, tôi nghĩ vậy; Nếu mỗi đội có 10 người trên đó, một đội gồm 20 người rất có thể là quá lớn. Ngoài ra, nếu có bất kỳ tách vật lý giữa các đội (OP không xác định), sau đó nó sẽ không hoạt động như một đội bóng duy nhất và sẽ làm cho mọi việc disorganized hơn. Điều này chắc chắn có thể hoạt động, nhưng nó phụ thuộc vào tình huống (các nhóm có thể được hợp nhất một cách hiệu quả) và cả các mục tiêu của ban quản lý (việc sáp nhập ít nhiều thường xuyên, nó sẽ thêm nhiều tài nguyên hơn nhưng sẽ không hoàn thành cùng một kết quả như một dự án Vòng xoay).
Aaronaught

0

Xoay vòng lập trình viên là điều tốt từ quan điểm của công ty và quan điểm của nhà phát triển.

Từ góc độ công ty

  1. Quản lý sẽ nhận biết, điểm mạnh và điểm yếu của nhà phát triển cụ thể cho dù họ có thể xử lý đa nhiệm hay không và thích ứng với các thay đổi.
  2. Nếu một số nhà phát triển rời công ty vì một số lý do, công ty đã sẵn sàng sao lưu cho tương lai.
  3. Nó sẽ tăng cường hiệu suất của dự án, vì nhiều người sẽ làm việc với nó, điều tương tự được thử nghiệm bởi ngày càng nhiều nhà phát triển. (Kiểm tra giảm thiểu lãng phí tài nguyên)
  4. Tất cả các thành viên trong nhóm làm việc theo nhóm và nó sẽ tăng hiệu suất của dự án và trong tương lai quản lý sẽ biết, loại nhóm nào cần được thực hiện trong khi thực hiện mô-đun hoặc nhiệm vụ khó khăn.

Từ góc độ nhà phát triển

  1. Nó sẽ làm cho nhà phát triển tích cực hơn khi sự tự tin của anh ta tăng lên.
  2. Các nhà phát triển có được những ý tưởng tốt hơn và tốt hơn từ những người khác trong nhóm làm việc với mã và họ có thể sử dụng những kỹ thuật đó để phát triển trong tương lai.
  3. Từ những ý tưởng và đề xuất tốt hơn từ các thành viên khác trong nhóm, năng suất của nhà phát triển tăng lên.

Chỉ có một điều chính, cần phải nhớ rằng,

Việc luân chuyển lập trình viên không nên xảy ra rất thường xuyên. sau khi phát triển 60% - 70% thì chỉ cần dịch chuyển sẽ có lợi.


3
Tôi thấy rất nhiều khẳng định hói được thực hiện ở đây. Một số trong số họ hầu như không liên quan gì đến việc xoay vòng ("ban quản lý sẽ biết được điểm mạnh và điểm yếu của nhà phát triển cụ thể"?), Những người khác thì lúng túng hoặc chỉ không có ý nghĩa ("tất cả các thành viên trong nhóm làm việc theo nhóm và nó sẽ tăng hiệu suất của dự án "?). Tất cả những điểm này dựa trên cái gì? Bạn có một nguồn? Có phải là kinh nghiệm cá nhân? Nếu vậy, những gì kinh nghiệm? Là "quan điểm công ty" của bạn đến từ kinh nghiệm làm quản lý hoặc trưởng nhóm? Bạn đã thực sự thấy bất kỳ những điều này làm việc trong thực tế?
Aaronaught

1
Hầu hết những lợi ích được đề xuất này thực sự có liên quan đến việc đơn giản là ở trong một đội chứ không phải bị luân chuyển giữa các đội ...
Aaronaught

đầu tiên "Quản lý sẽ nhận biết, điểm mạnh và điểm yếu của nhà phát triển cụ thể." thực sự ngược lại, bởi vì việc che giấu điểm yếu của bạn dễ dàng hơn nhiều khi bạn di chuyển từ nơi này sang nơi khác, luôn có nhiều người / phần mềm để đổ lỗi, tại sao nó bị trễ, lỗi, không được thực hiện.
Dainius

Không có cách nào trong h ... hiệu suất dự án sẽ không bị ảnh hưởng tiêu cực. Tại sao bạn có thể tin rằng hiệu suất của một dự án sẽ được "nâng cao"?
Dunk
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.