프로그래머가 복권에 당첨 될 경우 회사가 수중에 가지 않도록하는 방법 [폐쇄]

저에게는 몇 명의 프로그래머가 있습니다. 그들은 모두 매우 훌륭하고 똑똑합니다. 대단히 감사합니다.

그러나 문제는 그들 각각이 하나의 핵심 영역에 대한 책임이 있다는 것입니다. 팀의 어느 누구도 그것이 무엇인지에 대해 가장 안개 낀 생각을 가지고 있지 않습니다. 즉, 이들 중 누구라도 퇴출되면 교체 할 수 없어서 회사로서의 회사가 죽었 음을 의미합니다.

버스에 부딪 히거나 사임하는 등의 이유로 새 프로그래머를 고용하여 그들을 덮을 생각입니다. 그러나 나는 그것을 두려워

1. 오래된 프로그래머는 백업이 가치를 떨어 뜨릴 것을 두려워하면서 지식 이전이라는 개념에 적극적으로 저항 할 수 있습니다.
2. 다른 개발자 간의 기술 이전을 촉진 할 수있는 시스템이 없으므로 개발자에게 요청하더라도 제대로 수행 할 것이라는 확신이 없습니다.

내 질문은

1. 그들이 예전의 프로그래머들에게 그것들을 동의하게하는 방법
2. 이런 종류의 "백업"을 용이하게하기 위해 사용하는 시스템은 무엇입니까? 코드 검토를 수행 할 수 있지만이를 수행하는 간단한 방법이 있습니까? 체크인 코드 검토를 통해 완전히 체크인 할 준비가되지 않은 것 같습니다.

그들이 예전의 프로그래머들에게 그것들을 동의하게하는 방법

물론 문제를 위협으로 보지 않고 팀과 프로젝트를 개선 할 수있는 기회로 공개적으로 문제를 제시하십시오. 예를 들어 "다른 사람들에게 해고 당했을 때 알고있는 것을 알고 싶다" 는 잘못된 접근법 이다. " 이 훨씬 좋습니다.

일반적으로 개발자는 휴가 중일 때마다 개발자 스스로 문제를 겪고 있으며이를 다루어야합니다. 또한 훌륭한 개발자는 작업중인 프로젝트에 대한 책임을 느끼므로이 아이디어에 동의 할 것입니다. 여전히, 그들에게 아이디어에 대해 토론하고 (희망스럽게) 헌신 할 시간을주십시오. 또한 팀 내에서 지식을 공유하는 방법과 대상에 대해 의견을 발표 할 수 있습니다. Joe는 Jim과는 일하고 (지식을 공유하고는) 괜찮다고 생각하지만 Jack 등은 그렇지 않습니다.

이런 종류의 "백업"을 용이하게하기 위해 사용하는 시스템은 무엇입니까? 코드 검토를 수행 할 수 있지만이를 수행하는 간단한 방법이 있습니까? 체크인 코드 검토를 통해 완전히 체크인 할 준비가되지 않은 것 같습니다.

우리 팀에서는 코드 / 디자인 검토와는 별도로

• 팀 구성원 간 작업 및 책임 영역 회전 (각각 주요 책임 영역이 있지만, 때때로 다른 팀 구성원이 더 잘 알려진 영역에서 작업을 수행함)
• 대면 지식 이전 세션 (보통 위의 작업이 필요할 때, 누군가 팀을 떠나기 전에)
• 팀 / 프로젝트 위키

코드 검토 자체로는 충분하지 않을 수 있습니다. 많은 영역에서 일반적으로 개발자가 코드에서 직접 읽을 수있는 것보다 더 많은 것을 알고 있습니다. 즉, 도메인 모델 도 있습니다. 코드가 실제로 하는 일 을 읽을 수 있지만 모델이 없으면 이유를 알 수 없습니다 .

그들이 지식을 공유하도록 동기를 부여하는 한 가지 방법은 다른 사람들에게 그들의 작업에 대한 짧은 발표 를 하도록 요청하는 것 입니다. 프로그래머는 일반적으로 자신의 작업에 큰 자부심을 가지고 있으며, 이것이 그것을 보여줄 수있는 기회가 될 것입니다. 프리젠 테이션은 외부인에게 거의 알려지지 않은 단점을 보여줄 수있는 좋은 기회입니다.

또한, 왜 그냥 그것에 대해 개방 하고 모든 필요한 사람이 버스에 치여되는 경우 지식 공유의 계획을 마련 할 것을 모든 사람을 말한다. 나는 이것을 불합리한 것으로 보지 않습니다. 우리 회사에서 지금 일어나고 있으며 일부는 방어 적이지만, 반드시해야한다는 것을 알고 있습니다.

어쩌면 그들은 수 쌍으로 작동 그들은 호기심 성격의 경우, 아무 문제가 없을 것, 몇 가지에.

새로운 사람들을 고용하기 전에 소프트웨어의 내부 문서를 최신 상태로 유지하는 것이 첫 단계입니다. 물론 이것은 귀중한 프로그래머가 IDE 대신 Office 및 UML 도구를 사용하는 데 시간을 할애하지만 어떤 경우에도 가치가 있다고 생각합니다.

최신 문서가 있으면 프로그래머가 다른 사람이 작성한 내용을 모든 사람이 이해하도록 프로그래머가이를 다시 확인하도록 할 수 있습니다. 여전히 새로운 사람들이 필요하지 않습니다.

그런 다음 새로운 사람들을 고용하는 것을 고려할 수 있습니다. 또는 회사의 작업량에 따라 다릅니다.

대기업 인 경우 HR에 전화하여이 문제에 대해 이야기 할 수 있습니다. 핵심 직원이 버스에 치여도 회계 담당자는 같은 문제가 있다고 믿습니다. 중요한 영업 담당자가 중요한 협상 중에 좀비가되면 마케팅 담당자들도 많은 어려움을 겪게 될 것입니다. 자주 일어나는 일입니다.

이에 대한 올바른 HR 언어는 승계 계획 이라고 생각합니다 . 귀사에는 이미이를 처리하기위한 정책과 프레임 워크가있을 수 있습니다.

제가 근무했던 한 곳에서도 같은 문제가있었습니다. 그들이 한 것은 각 수석 개발자와 함께 일할 주니어 개발자 한 명을 고용하는 것이 었습니다. 그들은 함께 프로젝트를 수행하는 2 개의 작은 팀을 만들었습니다. 몇 개월 또는 프로젝트마다 팀 사이에서 주니어 개발자를 교체 할 것입니다. 이런 식으로 선임 개발자는 주제 전문가로 남아 있었지만 후배 개발자는 모든 시스템과 이들이 어떻게 협력했는지를 잘 이해하기 시작했습니다. 또한 팀 규모가 두 배로 늘어나는 프로젝트가 더 빨라졌습니다.

더 큰 프로젝트를 위해 선임 개발자는 때때로 다른 시스템을 배우기 시작할 수 있도록 프로젝트 기간 동안 시스템의 다른 부분에서 주니어 개발자로 활동하도록 요청 받았습니다.

핵심은 기존 개발자의 지식과 연대를 존중하면서도 팀을 확장하고 확장하는 것이 었습니다. 그것은 느린 과정 이었지만 시간이 지남에 따라 잘 작동했습니다.

성공적인 오픈 소스 프로젝트를 성공시키는 것 중 하나는 코드 "소유권"이 없다는 것입니다. 즉, 아무도 응용 프로그램 영역의 유일한 관리자가 아니며, 응용 프로그램의 모든 부분에 기여할 수있는 사람이있을 수 있습니다. 내가 강하게 믿는 것입니다.

당신이하고 싶은 것은 상황이 실제로 팀에 해를 끼치고 있다고 설명하는 것입니다. 다음은 원하는 순서대로 제공되는 것입니다.

• 나는 이것이 당신이 어떻게 작동하는지 아는 유일한 사람이라면 파이크를 내려 오는 다른 멋진 물건에 대해 자유롭게 작업 할 수 없습니다.
• 우리 는 당신이 좋은 휴가를 보낼 수 있기를 원하지만, 아무도 당신이하는 일을 할 수 없기 때문에 여유가 없습니다.
• 사람들이 현재 위치에 만족하지 않아서 일자리를 바꾸는 것은 불쾌한 사실입니다. 우리는 당신이 일하는 지역에 갇혀 있다고 느끼기 때문에 당신을 잃고 싶지 않습니다.

개인적으로, 나는 동료가 돌아가는 것을 다루어야했다. 정보 사일로가 없었지만 손실은 여전히 ​​심각했습니다. 이러한 일이 발생할 가능성은 위의 세 번째 글 머리 기호보다 훨씬 낮습니다.

사건을 해결 한 후에는 문제를 해결하는 방법에 대한 아이디어를 구하십시오. 물론 당신과 함께하세요. 그들의 아이디어는 그들이 팀의 일원임을 깨닫고 자신의 전문 분야 이상의 것을 필요로합니다. Jane이 Joe가하는 일에 관심이 있을지 모르지만 약간 두려워합니다. 그것을 아는 것은 지식 전달을 더 재미있게 만드는 데 도움이 될 수 있습니다. 당신이하고 싶은 일 중 일부는 다음과 같습니다

• 현재 팀을 교차 훈련하십시오. 단기적으로는 약간의 효율성을 잃을 수 있지만 앱의 한 부분에서 학습되어 앱의 다른 부분에 적용될 수있는 교훈이있을 수 있습니다. Jane과 Joe가 잠시 동안 서로의 프로젝트를 함께 수행하게하십시오.
• 지식 공유 문화를 조성하십시오. 내가 일했던 회사는 "갈색 가방 기술 토크"프로그램을 가졌습니다. 누구나 승인 된 주제에 대해 발표 할 수 있습니다 (보통 기술 또는 소프트웨어 프로세스 소개). 회사는 점심을 제공했고 발표자는 그들의 노력으로 수백 달러를 받았습니다.
• 멘토링은 삶의 방식이어야합니다. 다른 사람들을 멘토링하는 목적은 당신이 새로운 일을 할 수있게 해주고 회사에 더욱 가치있게 만드는 것입니다.
• 순위를 낮추지 않고 정보 사일로 경계를 넘을 수있는 방법을 찾으십시오. 더 재미있게 만들면 위협이 줄어 듭니다. 당신의 팀원들이 당신이 말한만큼 훌륭하다면, 그들은 상황에 완전히 만족하지 않을 것입니다. 팀이 처리 할 수 ​​있는지 여부를 판단해야하지만 "매주 선택"주를 가질 수 있습니다. 항상 여기에서 시작하십시오. 아이디어는 "so-and-so"의 책임이 무엇인지, 그리고 그들이 겪고있는 문제를 어떻게 해결할 수 있는지에 대해 모든 사람의 눈을 사로 잡는 것입니다. 목에서 선으로 시작하는 한, 아무도 자신의 직업을 갖지 못한다는 아이디어를 얻습니다.

일반적으로 작품을 더 즐겁게 만들고자한다면 그들에게 깊은 인상을 심어주십시오.

인턴은 좋은 아이디어 일 수 있습니다. 현재 개발자에게 직접 종속되므로 위협을 느끼지 않습니다.

회사가 성장함에 따라 오래된 개발자와 인턴십 후 회사를 만든 사람들이 모두 필요합니다.

나는 이것이 효과가 있다고 생각합니다.

일반적으로 일부 관리자가 갑자기 문서화 및 승계 계획에 대해 걱정하기 시작하면 프로그래머가 해고되거나 해고 될 것이라는 강력한 경고 신호입니다. 그것은 전형적인 관리적 행동에서 벗어난 것이며 프로그래머에게 모든 종류의 경고 신호를 설정하는 것과 관련이 있습니다.

모든 사람은 모든 절차와 프로세스를 문서화해야합니다

" 기업 파멸의 경고 표시 "의 레벨 3 .

대안으로서, 한 논술은 " 업 또는 아웃 " 문화를 장려 할 것이라 주장 하지만, 반론은 거의 모든 회사가 (미스) 경영 경력 사다리와 비슷한 재무 및 전력 스펙트럼과 유사한 기술 경력 사다리를 가지고 있다는 것입니다. 포함합니다.

@ammoQ가 그의 대답에서 시작한 전체 문서의 개념을 바탕으로 ...

훌륭한 관리자는 직접 보고서의 기술을 개발하여 보고서 중 하나가이를 대체 할 수 있도록 노력합니다. 작업의 완벽한 투명성을 제공하는 직원이 모든 작업을 비밀로 유지하고 숨기는 직원보다 가치가 있다는 것을 개발자에게 이해 시키십시오. 만약 '비밀'개발자가 오늘 죽었다면 회사는 그 잃어버린 지식을 되 찾는 데 큰 비용 부담이 될 것입니다. '전체 공개'직원이 오늘 사망 한 경우 회사는 여전히 손실을 입었지만 여전히 덜 파괴적 일 것입니다. 따라서 '전체 공개'직원에게는 더 많은 가치가 있습니다.

해고에 대한 면역을 유지하기 위해 숨겨진 지식을 유지하려는 직원도 승진에 면역이됩니다. 오늘날 그들이 맡고있는 일상적인 작업을 완료 할 사람이 없으면 개발자를 더 도전적이고 보람있는 위치로 옮길 수 없습니다. 일상적인 작업이 완전히 문서화되고 완전히 공개 된 경우, 새로운 개발자를 고용하여 이전 개발자를 작성하고 더 고위 직책으로 승진시킬 수 있습니다.

즉, 귀하가하는 일을 문서화하고 각 직속 보고서에 대한 교육을 제공해야합니다. 경우 그 방법은, 당신이 오늘 사망 풀 타임 교체가 발견 될 때까지, 그 중 하나는 당신을 위해 기입 할 수있다.

새로운 프로그래머를 데려 오기 전에 그들 각자에게 문서화 된 레거시를 만들도록 도와달라고 부탁했다.

Wiki 또는 업무의 모든 측면에 대한 문서의 3 링 성경이 있습니다.

또는 정말 상세하고 철저한 문서를 원한다면 기술 작가를 고용하여 각 프로그래머를 인터뷰 한 후 모든 사람이 매일, 매주, 매월, 매년 모든 문서를 작성하십시오.

그런 다음 프로그래머가 업데이트 / 편집 / 참여 / 설명을 할 수 있도록 위키 버전을 만드십시오.

그런 다음 시간이 지남에 따라 새로운 프로그래머를위한 향상된 학습 곡선이 될 시스템이 있습니다.

또한 솔직히 프로그래머가 하나의 핵심 영역에 갇혀있는 것이 현명하지 않으며, 훈련, 교차 핵심 작업을 실제로 지불해야합니다.

그런 다음 한 사람이 휴가 또는 이와 비슷한 것을 할 때 기존 직원을 사용할 수 있습니다.

프로그래머 중 한 명이 아플 때마다 질문과 문제로 반복해서 전화하십시오.

프로그래머 중 한 사람이 휴일에있을 때마다 질문과 문제로 반복해서 전화하십시오.

그들은 곧 더 나은의 실현거야 그들 뿐만 아니라 회사되지 핵심 영역에 대한 책임을 단일 사람들이있다.

버스를 타기를 원하지 않는 사람도 있지만 짧은 통지로 다른 사람의 프로젝트를 인수하고 프로젝트를 유지 관리 할 필요도 없습니다. 그러면 모든 사람이 사업을 중단 할 위험이 있습니다.

사일로에서 개발하는 경우 한 프로젝트에서 다른 프로젝트로 사람들을 옮기기 시작해야합니다. 문서화, 코드 검토 또는 간단한 버그 수정으로 시작하십시오. 너무 작은 코드 보호 / 영토 행위는 해결하기 전에 해결해야합니다.

코드 한 조각에 고독한 전문가를 두는 것이 효율성 환상입니다.

휴가를 가고 싶은 사람이 있습니까?

경영진의 어리석은 실수로 인해 더 많은 회사가 근무하게되었습니다. 한두 명의 엔지니어가 떠나도 충돌하지 않고 화상을 입지 않을 수 있습니다. 잠시 동안 더 열심히 일해야합니다. Sheesh, 저는 매 분기마다 누군가를 잃는 해외 팀을 관리합니다. 작업을 이동하기 시작하십시오. 오늘.