정보 보관소를 어떻게 처리합니까? [닫은]

우리는 모두 오랜 세월 동안 경험해 왔으며 환상적인 도메인 지식을 가지고 있지만 팀과 그 지식을 공유하지 못하는 개발자들을 모두 만나야합니다.

팀은 필사적으로 지식을 공유해야하지만 지식을 쌓아 둘 수는 없습니다.

팀은 어떤 방식으로이 문제를 성공적으로 해결 했습니까?

팀에서 코드 소유권을 제거하십시오. 작업량을 분산 시키십시오. 코드 검토를 수행하십시오. 지식 전달 세션을 구성하고 몇 개의 세션을 기다린 다음 해당 지역에서 프레젠테이션을하도록 요청하십시오.

물론 관리자가 아닌 경우 관리자의 지원을받는 것이 중요하지만 , 팀의 모든 사람 이 정기적으로 정보를 공유하는 경우 누군가가 같은 일을하지 않은 것에 대해 제기 할 수있는 많은 변명 만이있을 수 있습니다. .

또한, 그의 매니저는 그와 함께 앉아서 이것이 그의 직업을 위협하지 않는다고 설명해야합니다. 그래서 그가하고있는 이유입니다.

개인 이 모든 지식의 글꼴이 아닌 것이 좋습니다 . 그것은 더 흥미로운 다른 일을 할 수있게 해줍니다.

나는 그가에서 주석 때 제럴드 와인버그는 사람이 정확한 유형을 언급했다 믿습니다 컴퓨터 프로그래밍의 심리학 , (나는 내 앞에 책이 없기 때문에 의역) 은 프로그래머가 자신이 필수 불가결 만들려고 노력 통지하는 경우, 화재 그를 즉시. 25 년 후 그는이 책을 재발행 할 때 이만큼 감사의 말을 전한 적이 없다고 언급했다.

이것이 하나의 해결책입니다.

그들에게 원하는 것을 제공하십시오-그들 만이 할 수있는 모든 유지 보수 작업과 작업을 할당하십시오.

아무도 다른 중요한 유지 보수 작업을 수행 할 수 없기 때문에 새로운 작업을 수행 할 수 없습니다.

그렇습니다. 신입 사원은 재미있는 일을하고 반짝이는 새 장난감을 가지고 놀고 있지만 여러분이하는 일을 모르기 때문에 매우 어렵고 우선 순위가 높고 지루한 작업을 수행해야합니다.

물론 그들에게 방법을 보여주고 싶지 않다면 ...

이것은 Rands in Repose 의이 기사 를 상기시킵니다 .

왜이 사람이 정보를 저장하고 있는지 알아 내야한다고 생각합니다. Fez에 관한 기사와 같은 직업 보안은 큰 것입니다. 그러나 불안감도 마찬가지입니다. 또는 그가 이런 종류의 작업을 좋아하고 모든 것을 스스로 원하거나 특정 영역에 대한 강한 소유권 감각을 느낀다는 것입니다. 또는 과도하게 노력하여 시간을내는 방법을 보지 못했습니다.

이러한 문제 중 일부는 대립이 아닌 트릭으로 해결할 수 있습니다.

• 그 사람 에게 시야 를 넓히고 어떤 일을하도록 강요하는 일을 시키십시오.
• 불안이 어디에서 왔는지 파악하고 정보가 비축되는 실제 문제가 무엇이든 해결하십시오.
• 유일하게 지식 보유자가 자신을 자유롭게 할 수 없으며 그의 경력이 기술과 밀접하게 연관되어 있으며 모든 기술은 결국 사라질 것이라는 점에서 틀에 박힌 사람을 지적하십시오.
• 과잉 헌신이 어디에서 왔는지 파악하고 가장 중요한 것이 무엇인지 파악

정보 요청에 대한 몇 가지 시도에 참여하는 것도 가치가 있습니다. 탱고에 2가 걸릴 수 있으며, 질문을하는 사람이 좋은 질문을하지 않는다는 충분한 협박이 있다는 생각을 배제하고 싶지 않을 수도 있습니다. 문제를 악화시킨다. 당신은 뛰어 들어가서 물건을 백업하고 그 사람을 움직이기 위해 더 넓은 질문을해야 할 수도 있습니다. 또한 경영진이 질문을하면 정보 공유 활동에 무게와 중요성을 부여합니다. 관리를 피하기가 훨씬 어렵습니다. 일반적으로 몇 번의 생산적인 세션이 진행되는 동안 중간에서 벗어나 "당신은 이것을 가지고 있고, 필요하지 않습니다"라고 말하고 다음 문제로 넘어갑니다.

또 다른 열쇠는 그 사람이 지식을 공유해야하는 분야에서 일을 지배하지 못하게하는 것입니다. 다른 사람이 작업을 담당하도록하고 지식을 공유하는 것이 정보 보관소의 일임을 분명히하십시오. 그가 공유 할 수없는 경우 옵션 공유가 아니라 팀에서 정보 공유가 필요하다는 설명을하는 잔인한 대화가 필요할 수 있습니다. 그는 다른 사람이 배우지 못하도록하여 팀 일정 문제에 기여하고 있습니다.

나는 '거절'이 종종 올바른 단어인지 잘 모르겠습니다. 보통 너무 바빠서 분명한 것을 설명하기 위해 많은 시간을 할애 할 여가 (또는 성향 또는 사회적 기술)가 없습니다. )를 n00bs에 연결합니다.

긍정적 인 해결책은 팀에게 일을 퍼뜨리는 것과 거의 같은 보조자를 제공하는 것입니다 (그러나 시스템에 대해 모든 것을 알고있는 노인과 그렇지 않은 새로운 사람들이 있다면 팀이 많지 않다고 생각합니다) 이 설정을 통해 귀중한 기술을 전달하고 더 젊고 저렴한 버전으로 교체하고 싶지 않은 것은 당연한 일입니다!) 새로운 아웃소싱 팀에 ... 흠?)

조수가 시스템의 일부에서 작업하는 것이 좋으며 시간이 지남에 따라 전문가가 될 것으로 예상되며 숙련 된 개발자는 소규모 지역에서 작업을 수행하도록 도울 것입니다. 어쨌든 "X가 어떻게 작동하는지 알고 싶다면 (구식이 없거나 존재하지 않는) 문서를 잊고 Jim에게 이야기하십시오."

그들에게 조수를 제공하면 숙련 된 개발자 (자신의 위치)로서의 지위를 확인할뿐만 아니라 일부 고급 업무량을 줄일 수있는 기회를 제공 할뿐만 아니라 시간이 지남에 따라 지식을 전파 할 수 있습니다. 이들은 멘토 또는 '팀의 첫 단계'직책이되어 업무가 안전하고 경험이 중요하다는 것을 확신시켜야합니다. 이러한 작업 중 하나를 수행 할 수 없으면 관리자로서 실패한 것입니다.

당신이 어떤 종류의 슈퍼 콤플렉스 시스템 (당신이하거나 새로운 사람들이 스스로 그것을 알아낼 수 있어야 함)을 가지고 있다면 지식 전달은 매우 긴 과정이라는 것을 잊지 마십시오. 아무도 내 자리에 앉아 속도를 완전히 올릴 수있는 방법이 없습니다. 제 작업에서 최소 6 개월이 걸리고 심지어는 그때까지도 계속됩니다. 여기 거의 십 년!

각 팀원에게 의사 소통을하고 연례 검토의 일환으로이를 평가하십시오.

팀이 개인뿐만 아니라 업적을 인정 받고 모든 개인이 팀 성공이 최우선임을 아는지 확인하고 팀의 성공을 방해 할 경우 처벌합니다.

의사 소통에 대한 차단이 없는지 확인하고 문서를 작성하고 정보를 공유하기위한 프로세스와 시스템이 있는지 확인하십시오. 예 : 위키, 공유 지점 사이트, 디자인 문서를위한 예정된 결과물 등

모든 프로젝트에는 작업 할 수있는 프로그래머가 두 명 이상 있어야합니다. 이것은 누군가가 회사를 떠날 때 항상 백업을 갖도록하기위한 것입니다.

또한 모든 데이터베이스 정보가 포함 된 위키 를 시작했습니다 . 정보에 빠르게 액세스하거나 업데이트 할 수있는 매우 유용한 방법입니다.

"보장 자"가 의도적으로 그렇게하지 않고 실제로는 사회 기술 부족, 시간 약속 등으로 인해 그렇게하고 있다면, 반드시 "보조자"또는 주니어 프로그래머에게 특별히 완화를 요구하십시오 작업량 또는 지식 추출에 도움이됩니다. 이것이 새로운 사람의 목적이며, 인터뷰 과정에서 "수용자"와 관련이 있음을 양 당사자에게 분명히하십시오. 경영진은 이에 참여하여 지식을 공유 할 수 있도록해야합니다. 그것이 관리의 목적이며, 장애물을 제거하고 근로자가 작업을 수행 할 수있게합니다.

내 경험상 정보 보관소는 두 가지 유형으로 분류 될 수 있습니다. 지식을 공유하고 자신과 같은 다른 사람을 지나치게 도와 주면서 만족감을 느끼는 사람들과 그렇지 않은 사람들. 명백하게.

이제 양쪽에 이유가 있으며, 지식을 공유하는 것을 좋아하는 사람은 일반적으로 지식을 공유하지 않는 사람이하지 않는 것과 같은 이유로 거의 모든 것을 제공하지 않습니다. 그것들은 더 나아졌고, 편견에 의하면 그렇게하는 것이 옳습니다. (물론, 지식을 공유하지 않고 단순히 자신을 빼놓을 수없는 사람들도 있습니다. 잘못된 이유가 있기 때문에, 처음에는 그다지 좋지 않기 때문에 제거해야합니다)

결국, 그들은 순수한 실험, 비판적 사고의 자유로운 적용, 직관과 통찰의 번쩍임, 다양한 유형의 희생 가축과 관련된 신비로운 의식을 통해 자신이 알고있는 것을 배우기 위해 비전 해와 난해에 깊숙이 파고 들어야했습니다. 그들은 더 나아졌습니다. 생각의 선은 일반적으로 주위 사람들이 너무 게 으르거나 동일하게 관리 할 수 ​​없다면, 시작하기 위해 일을해서는 안되며 분명히 지식에 합당하지 않다는 것입니다. 주변 사람들이해야 할 것과 똑같은 일을 겪으면 더 나은 프로그래머가 나올 것입니다. 왜냐하면 그들은 잘 생각하고 복잡한 문제를 해결하는 방법을 배웠기 때문입니다.

그것은 본질적으로 다른 사람들이 투쟁을 통해 더 나아지도록 강요합니다. 많은 것들이 모여서 쫓겨날 것이지만, 건틀릿을 통해 그것을 만드는 사람들은 협력을 통해 더 나아 졌다면 필연적으로 훨씬 나아질 것입니다.

이제 정보를 공유하게 할 수 있습니다. 강요 할 수는 없습니다. 그들에게 강요하려고하면 욕심이 많거나 게 으르거나 너무 멍청한 것으로 여기게되며, 어떤 경우에도 당신을 불쌍히 여기지 않을 것입니다. 누군가가 그들에게 그렇게하도록 강요하려고 시도하면, 그들은 매우 불쾌하게 될 수 있으며, 모든 상당한 지능을 개인을 방해하거나, 원칙을 배신하기보다는 똑바로 그만 둘 수 있습니다. 지식.

자신의 지식을 기꺼이 공유하기 위해 지식을 공유하고 싶지 않은 이들 중 하나를 얻는 유일한 방법이 있습니다. 일반적으로 그들이 가지고 있지 않다는 지식 만 있으면 충분합니다 (그러나하기는 어렵습니다). 프로 쿼와 그 모든 것을 종료하십시오. 그렇지 않으면, 염소 두 마리를 사서 뛰어 들어보십시오.

보스는 누구인가? 어디서 끝나요? 정보를 공유 할 필요는 없습니다. 문서를 제공 할 필요는 없습니다. 정시에 일을 끝내지 못합니다. 코딩 표준을 따르지 마십시오. 담당자가 이것이 중요하다고 생각하거나 그렇지 않다고 생각합니다. 결과가 있어야합니다. 그들은 기본적으로 회사에서 도둑질하고 있습니다.

플레이 사람들은 "나는있어 비밀 게임은" 절대 최악입니다. 이 사람들은 위기 상황 에서 불안전하고 번창하는 경향이있다 .

시스템에 대한 모든 변경 사항이나 수정 사항을 문서화하도록하겠습니다. 또한 그들이 포함하도록 개발 한 각 수정 사항에 대해 포스트 모템을 제공하게 만들 것입니다 ...

• 어떻게 된 거예요
• 왜 그런 일이
• 그것을 방지하는 방법
• 다른 시스템이 같은 버그에 취약한 것

나는 또한이 사람이 책임을지게 할 것입니다 ...

• 코딩 표준 개발
• 코드 라이브러리 유지

많은 것은 관련된 지식의 유형에 달려 있습니다. 직접 코드이든 비즈니스 프로세스 중심이든 상관 없습니다. 일반적으로 후자는 비즈니스의 다른 곳에서 사용할 수 있으며 획득 할 수 있습니다.

둘째, 개발자가 공유하지 않고 특정 영역에서 전체 작업 수명을 소비하지 못하도록하는 주장이 있습니다. 따라서 업무를 담당 할 책임이있는 라인 관리자가있는 경우 특정 개발자가 비즈니스 프로세스 소유자의 첫 번째 담당자가되지 않고 비즈니스 변경 요청이 처리되도록해야합니다. ... 이것은 개발자가 전문가가 되려는 노력을 방해 할 것입니다.

정보 보유자가 더 작은 규모의 회사를 찾거나 자신의 회사를 시작하도록 장려했다면 양 당사자의 이익이 가장 좋을까요? 아마도 그 사람은 더 작은 유형의 환경에서 번성 할 것입니다. (실제로이 접근법을 시도한 사람이 있는지 궁금합니다.)