Làm thế nào để đảm bảo công ty của bạn không bị chìm dưới nước nếu lập trình viên của bạn trúng xổ số [đóng cửa]

Tôi có một vài lập trình viên dưới tôi, tất cả họ đều đang làm rất tuyệt vời và rất thông minh rõ ràng. Cảm ơn nhiều.

Nhưng vấn đề là mỗi người trong số họ chịu trách nhiệm cho một lĩnh vực cốt lõi, điều mà không ai khác trong nhóm có ý tưởng rõ ràng nhất về nó là gì. Điều này có nghĩa là nếu bất kỳ ai trong số họ bị loại ra, công ty của tôi là một doanh nghiệp đã chết vì họ không thể thay thế.

Tôi đang suy nghĩ về việc đưa các lập trình viên mới đến để bảo vệ họ, chỉ trong trường hợp họ bị xe buýt đâm, hoặc từ chức hoặc bất cứ điều gì. Nhưng tôi sợ rằng

1. Các lập trình viên cũ có thể chủ động chống lại ý tưởng chuyển giao kiến ​​thức, sợ rằng một bản sao lưu có thể làm giảm giá trị của chúng.
2. Tôi không có hệ thống để tạo điều kiện chuyển giao công nghệ giữa các nhà phát triển khác nhau, vì vậy ngay cả khi tôi yêu cầu họ làm điều đó, tôi không đảm bảo rằng họ sẽ thực hiện đúng.

Câu hỏi của tôi là,

1. Làm thế nào để đưa nó cho các lập trình viên cũ để họ đồng ý
2. Các hệ thống mà bạn sử dụng là gì, để tạo điều kiện cho loại "dự phòng" này? Tôi có thể hiểu rằng bạn có thể thực hiện đánh giá mã, nhưng có cách nào đơn giản để thực hiện việc này không? Tôi nghĩ rằng chúng tôi chưa sẵn sàng cho một sự thay đổi hoàn toàn, kiểm tra bằng cách xem xét mã đăng ký.

Làm thế nào để đưa nó cho các lập trình viên cũ để họ đồng ý

Trình bày vấn đề một cách cởi mở với họ, tất nhiên theo cách mà họ không coi đó là mối đe dọa, thay vào đó là cơ hội để làm cho nhóm và dự án hoạt động tốt hơn. Ví dụ: "Tôi muốn cho người khác biết những gì bạn biết trong trường hợp bạn bị sa thải" rõ ràng là một cách tiếp cận sai :-) "Tôi muốn đảm bảo dự án hoạt động trơn tru ngay cả khi một số bạn đi nghỉ hoặc bị ốm " Tốt hơn nhiều.

Thông thường, các nhà phát triển tự trải nghiệm các vấn đề mỗi khi một số trong số họ đi nghỉ và họ cần phải trang trải cho anh ấy / cô ấy. Hơn nữa, các nhà phát triển giỏi cảm thấy có trách nhiệm với dự án mà họ đang thực hiện, vì vậy họ có thể sẽ đồng ý với ý tưởng này. Tuy nhiên, hãy cho họ thời gian để thảo luận và (hy vọng) cam kết với ý tưởng. Ngoài ra, cho phép họ có tiếng nói về cách thức và ai chia sẻ kiến ​​thức của họ trong nhóm. Nó có thể hóa ra Joe cảm thấy ổn khi làm việc (và chia sẻ kiến ​​thức của mình) với Jim, nhưng không phải với Jack, v.v.

Các hệ thống mà bạn sử dụng là gì, để tạo điều kiện cho loại "dự phòng" này? Tôi có thể hiểu rằng bạn có thể thực hiện đánh giá mã, nhưng có cách nào đơn giản để thực hiện việc này không? Tôi nghĩ rằng chúng tôi chưa sẵn sàng cho một sự thay đổi hoàn toàn, kiểm tra bằng cách xem xét mã đăng ký.

Trong nhóm của chúng tôi, ngoài các đánh giá về mã / thiết kế, chúng tôi sử dụng

• Luân chuyển nhiệm vụ và lĩnh vực trách nhiệm giữa các thành viên trong nhóm (mỗi người trong chúng ta đều có trách nhiệm chính của mình, nhưng thỉnh thoảng, chúng tôi thực hiện các nhiệm vụ trong một khu vực được một thành viên khác biết đến nhiều hơn)
• Các buổi chuyển giao kiến ​​thức trực diện (thường là khi các nhiệm vụ trên yêu cầu, nhưng cũng có trước khi ai đó rời khỏi nhóm)
• Nhóm / dự án wiki

Bản thân việc xem xét mã có thể không đủ vì trong nhiều lĩnh vực thường có rất nhiều thứ để nhà phát triển biết hơn những gì có thể đọc được trực tiếp từ mã. Nói cách khác, có mô hình miền là tốt. Bạn có thể đọc những gì mã thực sự làm, nhưng không có mô hình, bạn sẽ không biết tại sao .

Một cách để thúc đẩy họ chia sẻ kiến ​​thức của họ là yêu cầu họ trình bày ngắn về công việc của họ cho người khác. Các lập trình viên thường rất tự hào về công việc của họ, và đây sẽ là cơ hội để thể hiện điều đó. Một bài thuyết trình là một cơ hội tốt để làm cho họ thể hiện một số điều kỳ quặc hiếm khi được người ngoài biết đến.

Ngoài ra, tại sao không chỉ cởi mở về nó và nói với mọi người rằng tất cả các bạn cần đưa ra một kế hoạch chia sẻ kiến ​​thức trong trường hợp ai đó bị xe buýt đâm. Tôi không thấy điều này là không hợp lý. Điều đó đang xảy ra trong công ty của tôi ngay bây giờ, và mặc dù một số người đang bảo vệ nó, họ biết rằng nó cần phải được thực hiện.

Có lẽ họ có thể làm việc theo cặp trên một số thứ, nếu chúng có bản chất tò mò, sẽ không có vấn đề gì.

Làm cho tài liệu nội bộ của phần mềm được cập nhật phải là bước đầu tiên, trước khi bạn bắt đầu tuyển dụng người mới. Chắc chắn, điều đó có nghĩa là các lập trình viên có giá trị của bạn sẽ dành thời gian cho các công cụ Office và UML thay vì IDE, nhưng tôi nghĩ rằng nó đáng giá trong mọi trường hợp.

Khi bạn có một tài liệu hiện tại, bạn có thể để các lập trình viên của bạn kiểm tra chéo để đảm bảo mọi người hiểu những gì người khác đã viết. Vẫn không cần người mới.

Sau đó, bạn có thể xem xét việc thuê người mới. Hoặc không, tùy thuộc vào khối lượng công việc trong công ty của bạn.

Nếu bạn ở trong một công ty lớn, bạn có thể gọi nhân sự và nói về vấn đề này. Tin tôi đi, những kẻ làm kế toán cũng gặp vấn đề tương tự nếu nhân sự chủ chốt bị xe buýt đâm. Những người tiếp thị cũng sẽ gặp nhiều rắc rối nếu một nhân viên bán hàng chủ chốt trở thành một thây ma giữa các cuộc đàm phán quan trọng - nó xảy ra thường xuyên, hoặc vì vậy tôi đã được thông báo.

Tôi tin rằng ngôn ngữ nhân sự chính xác cho việc này là kế hoạch kế nhiệm . Công ty của bạn có thể đã có chính sách và khuôn khổ để xử lý vấn đề này.

Một nơi mà tôi làm việc có cùng một vấn đề. Những gì họ đã làm là thuê một nhà phát triển cơ sở làm việc với mỗi nhà phát triển Cao cấp. Họ đã tạo ra các nhóm nhỏ gồm 2 người cùng làm việc với nhau. Cứ sau vài tháng hoặc các dự án họ sẽ luân chuyển các nhà phát triển cơ sở giữa các đội. Bằng cách này, các nhà phát triển cao cấp vẫn là chuyên gia về vấn đề này, nhưng các nhà phát triển cơ sở bắt đầu nắm bắt tốt tất cả các hệ thống và cách họ làm việc cùng nhau. Cộng với các dự án nhân đôi quy mô nhóm đã được thực hiện nhanh hơn.

Đối với các dự án lớn hơn, các nhà phát triển cao cấp đôi khi được yêu cầu đóng vai trò là nhà phát triển Junior trên một phần khác của hệ thống trong thời gian dự án để họ có thể bắt đầu tìm hiểu các hệ thống khác.

Chìa khóa ở đó là tôn trọng kiến ​​thức và thâm niên của các nhà phát triển hiện tại trong khi vẫn mở rộng và phát triển đội ngũ. Đó là một quá trình chậm nhưng theo thời gian làm việc tốt.

Một trong những điều làm cho các dự án nguồn mở thành công trở nên thành công là thiếu mã "quyền sở hữu". Điều đó có nghĩa là không ai là người duy trì duy nhất một khu vực của ứng dụng - bất kỳ ai cũng có thể và được khuyến khích đóng góp cho bất kỳ phần nào của ứng dụng. Đó là điều tôi tin tưởng mạnh mẽ.

Những gì bạn muốn làm là giải thích rằng cách mọi thứ đang thực sự làm tổn thương đội bóng bạn có bây giờ. Dưới đây là những điểm bạn muốn vượt qua, và tốt nhất là theo thứ tự này:

• Tôi không thể giải phóng bạn để làm việc với những thứ hay ho khác khi đi xuống nếu bạn là người duy nhất biết cách thức hoạt động của nó.
• Chúng tôi muốn bạn có thể có một kỳ nghỉ tốt, nhưng không đủ khả năng vì không ai khác có thể làm những gì bạn làm.
• Một sự thật khó chịu là mọi người thay đổi công việc vì họ không hài lòng với vị trí hiện tại của họ, chúng tôi không muốn mất bạn vì bạn cảm thấy bị mắc kẹt bởi khu vực bạn đang làm việc.

Về lưu ý cá nhân, tôi đã phải đối phó với một đồng nghiệp đã qua đời. Mặc dù không có bất kỳ silo thông tin nào, sự mất mát vẫn tác động mạnh. Cơ hội xảy ra điều này thấp hơn nhiều so với điểm đạn thứ ba ở trên.

Khi bạn đã đưa trường hợp của mình ra khỏi đó, hãy tranh thủ sự giúp đỡ của họ để có ý tưởng về cách khắc phục vấn đề. Tất nhiên hãy đến với chính bạn. Ý tưởng của họ sẽ giúp họ nhận ra rằng họ là một phần của một nhóm và họ cần nhiều hơn là lĩnh vực chuyên môn của họ. Có thể Jane có thể có hứng thú với những gì Joe đang làm, nhưng cảm thấy hơi sợ nó. Biết rằng có thể giúp làm cho việc chuyển giao kiến ​​thức thú vị hơn. Một số điều bạn sẽ muốn làm là:

• Đào tạo chéo đội hiện tại. Bạn có thể mất một chút hiệu quả trong thời gian ngắn, nhưng có thể có một số bài học kinh nghiệm ở một góc của ứng dụng có thể được áp dụng cho các phần khác của ứng dụng. Để Jane và Joe làm việc cùng nhau trong dự án của nhau trong một thời gian.
• Nuôi dưỡng văn hóa chia sẻ kiến ​​thức. Một công ty tôi làm việc đã có một chương trình "nói chuyện công nghệ túi màu nâu". Bất cứ ai cũng có thể trình bày về bất kỳ chủ đề được phê duyệt (thường giới thiệu các quy trình công nghệ hoặc phần mềm). Công ty phục vụ bữa trưa và người trình bày đã nhận được vài trăm đô la cho nỗ lực của họ.
• Kèm cặp nên là một cách sống. Mục đích của việc tư vấn cho người khác là để giải phóng bạn làm những điều mới, và khiến bạn trở nên có giá trị hơn đối với công ty.
• Tìm cách vượt qua ranh giới silo thông tin mà không cần xếp hạng. Bạn càng làm cho nó vui, nó sẽ ít đe dọa hơn. Nếu những người trong nhóm của bạn tốt như bạn nói, có lẽ họ không hoàn toàn hài lòng với cách mọi thứ diễn ra. Bạn sẽ phải là người đánh giá xem liệu nhóm có thể xử lý nó hay không, nhưng bạn có thể có một tuần "hãy chọn một ngày nào đó". Luôn luôn bắt đầu với chính mình ở đây. Ý tưởng là để mọi người chú ý đến trách nhiệm của "cái gì đó" và cách họ có thể giải quyết các vấn đề họ đang gặp phải tốt hơn. Miễn là bạn bắt đầu với cổ trên đầu tiên, họ sẽ có ý tưởng rằng không có ai ra ngoài để nhận công việc của họ

Nói chung, hãy cố gắng gây ấn tượng với họ rằng bạn muốn làm cho công việc trở nên thú vị hơn, và bạn cần sự giúp đỡ của họ để thực hiện nó.

Thực tập sinh có thể là một ý tưởng tốt, họ sẽ là cấp dưới trực tiếp cho các nhà phát triển hiện tại, vì vậy họ sẽ không cảm thấy bị đe dọa.

Khi công ty phát triển, bạn sẽ cần cả những nhà phát triển cũ VÀ những người đã thành lập sau khi thực tập.

Tôi nghĩ rằng điều này có thể làm việc.

Nói chung, khi một số người quản lý đột nhiên bắt đầu quan tâm đến tài liệu và lập kế hoạch kế nhiệm, đó là một dấu hiệu cảnh báo mạnh mẽ rằng các lập trình viên sắp bị sa thải hoặc bị sa thải. Đó là một sự khởi đầu từ hành vi quản lý điển hình và mối quan tâm rằng nó đặt ra tất cả các loại tín hiệu cảnh báo trong các lập trình viên.

Mọi người được yêu cầu ghi lại tất cả các quy trình và quy trình của họ

Cấp độ 3 của " Dấu hiệu cảnh báo của Doom doanh nghiệp ".

Thay vào đó, một bài tiểu luận gợi ý rằng chúng tôi sẽ khuyến khích văn hóa " Lên hoặc xuống " mặc dù điều ngược lại là rất ít công ty có một nấc thang nghề nghiệp kỹ thuật giống như phổ biến tài chính và quyền lực mà thang nghề nghiệp quản lý (mis) chứa đựng.

Dựa trên khái niệm tài liệu đầy đủ mà @ammoQ bắt đầu trong câu trả lời của mình ...

Một người quản lý tốt làm việc để phát triển các kỹ năng của các báo cáo trực tiếp của họ để bất kỳ một trong các báo cáo có thể thay thế chúng. Làm cho các nhà phát triển của bạn hiểu rằng một nhân viên cung cấp sự minh bạch hoàn toàn cho công việc của họ có giá trị hơn một người giữ tất cả công việc của họ bí mật và ẩn. Nếu nhà phát triển 'bí mật' chết hôm nay, đó sẽ là một trách nhiệm chi phí rất lớn đối với công ty để lấy lại kiến ​​thức đã mất. Nếu nhân viên 'công bố đầy đủ' đã chết ngày hôm nay, công ty vẫn sẽ thua lỗ, nhưng nó sẽ ít tàn phá hơn. Do đó, nhân viên 'tiết lộ đầy đủ' có nhiều giá trị hơn.

Bất kỳ nhân viên nào cố gắng giấu kín kiến ​​thức để khiến bản thân miễn nhiễm với việc bị sa thải cũng khiến họ miễn nhiễm với chương trình khuyến mãi. Bạn không thể di chuyển một nhà phát triển vào một vị trí đầy thách thức và bổ ích hơn nếu không có ai hoàn thành các nhiệm vụ trần tục mà họ phải chịu trong ngày hôm nay. Nếu các nhiệm vụ trần tục được ghi lại đầy đủ và được tiết lộ đầy đủ hơn bạn có thể thuê một nhà phát triển cơ sở mới để điền vào và thúc đẩy nhà phát triển trước đó lên một vị trí cao cấp hơn.

Điều này có nghĩa là bạn cũng cần phải ghi lại những gì bạn làm và cung cấp đào tạo cho từng báo cáo trực tiếp của bạn. Bằng cách đó, nếu bạn chết hôm nay, một trong số họ có thể điền vào cho bạn cho đến khi tìm thấy sự thay thế toàn thời gian.

Trước khi tôi bắt đầu đưa vào lập trình viên mới, tôi yêu cầu mỗi người trong số họ giúp tạo ra di sản tài liệu của riêng họ.

Hoặc với một wiki, hoặc một cuốn kinh thánh gồm 3 vòng tài liệu về mọi khía cạnh của công việc của họ.

Hoặc nếu bạn muốn tài liệu thực sự chi tiết và kỹ lưỡng, hãy thuê một nhà văn kỹ thuật, phỏng vấn từng lập trình viên và sau đó tạo một tài liệu về mọi thứ, mọi người đều làm, hàng ngày, hàng tuần, hàng tháng, hàng năm.

Sau đó tạo một phiên bản wiki của nó, mà lập trình viên của bạn có thể cập nhật / chỉnh sửa / tham gia / nhận xét.

Sau đó, bạn có một hệ thống sẽ phát triển kịp thời và là đường cong học tập được cải thiện cho bất kỳ lập trình viên mới nào.

Thành thật mà nói, thật không khôn ngoan khi lập trình viên chỉ bị mắc kẹt trong một lĩnh vực cốt lõi, nó thực sự phải trả cho việc đào tạo chéo, công việc cốt lõi.

Sau đó, bạn có thể sử dụng nhân sự hiện có của mình, khi 1 người đi nghỉ hoặc đại loại như thế.

Mỗi khi một trong những lập trình viên của bạn bị ốm, hãy gọi điện cho anh ta liên tục với những câu hỏi và vấn đề.

Mỗi khi một trong những lập trình viên của bạn đi nghỉ, hãy gọi điện thoại liên tục cho anh ấy với những câu hỏi và vấn đề.

Họ sẽ sớm nhận ra rằng tốt hơn cho họ cũng như công ty là không có những người độc thân chịu trách nhiệm cho các lĩnh vực cốt lõi.

Không ai muốn bị xe buýt đâm, nhưng họ cũng không muốn tiếp quản dự án của người khác trong một thời gian ngắn và duy trì dự án của họ. Sau đó tất cả mọi người có nguy cơ đi ra khỏi kinh doanh.

Nếu bạn đang phát triển trong silo, bạn cần bắt đầu chuyển mọi người từ dự án này sang dự án khác. Bắt đầu với tài liệu, xem lại mã hoặc sửa một lỗi đơn giản. Bất kỳ hành vi nhỏ nào về bảo vệ mã / lãnh thổ cần được giải quyết trước khi điều này vượt quá tầm tay.

Có một chuyên gia đơn độc trên một đoạn mã của bạn là một ảo tưởng hiệu quả.

Bất cứ ai cũng muốn đi nghỉ?

Tôi đã có nhiều công ty đi theo do những sai lầm ngu ngốc của ban quản lý. Bạn sẽ không gặp sự cố và bị bỏng nếu một hoặc hai kỹ sư rời đi, bạn sẽ phải làm việc chăm chỉ hơn một chút. Sheesh, tôi quản lý một đội ngoài khơi mất một người mỗi quý. Bắt đầu di chuyển các nhiệm vụ xung quanh. Hôm nay.