엔터프라이즈 지식 공유?

나는 최근 에 지식 공유에 관한 이 기사를 읽고 내 조직 내에서 동일한 문제를 즉시 인식했습니다. 저의 주요 목표는 이제 비 개인, 시스템 관련 토론을위한 기본 통신 방법으로 '피어 투 피어 공동 작업을 죽이는 것'입니다. 그렇지 않으면 개인의 머리 속에 살거나 거대한 이메일 시스템에서 잃어버린 모든 역사적 지식으로 끝납니다.

그룹에 대한 나의 질문은 다음과 같습니다.

• 개발자들 사이에서 더 많은 '공개'토론을 장려하기 위해 어떤 방법 / 소프트웨어를 사용 했습니까?

내가 가진 몇 가지 초기 아이디어 .. 어떤 의견이라도 좋을 것입니다

• 내부 뉴스 그룹
• '더 나은'위키 소프트웨어 (지금 Sharepoint 사용)
• 메세지 보드

(StackExchange의 내부 인스턴스를 갖고 싶지만 이것이 옵션이라고 생각하지 않습니다!)

참고 : 위에서 언급 한 바와 같이, 우리는 이미 위키를 가지고 있지만, 일이 보통, 사후 위키에 추가되기 때문에 나는 위키의 아이디어를 싫어하는 전혀 경우 .

감사!

내부 Sharepoint 사이트와 고객 지원 사이트가 있으며 내부 Sharepoint 사이트에서 많은 문서를 가져옵니다. 이것은 구현 세부 사항과 지원에 대한 자세한 내용은 아니지만 지원 용량에서 주로 일할 때 많은 구현 정보에 액세스해야하므로 엔지니어링 팀이 수행중인 작업과 이유를 문서화하는 드라이버가됩니다. 자세한 버그 추적 시스템은 문제 해결 방법을 추적하는 데에도 유용합니다.

우리 회사는 부분적으로 개발이 두 곳에 분산되어 있기 때문에 새로운 기능과 지원 문제에 대한 많은 토론이 전자 메일을 통해 발생합니다. 이를 변경하려는 것이 아니라 가장 쉬운 방법은 전자 메일 보관 시스템으로 토론을 검색 가능하고 효과적으로 추적 할 수있게하는 뉴스 그룹 유형의 접근 방식입니다. 우리는 Sharepoint를 통해이 작업을 수행 할 수 있지만 목록 크기의 한계는 수백만 개의 항목으로 커지더라도 실제로는 큰 목록을 정렬하거나 뷰를 편집하지 않고 많은 편집을 할 수는 없습니다. 그것은 극적으로 붕괴되었다.

언급 한 기사에서 설명한 것과 같은 엔터프라이즈 용 StackOverFlow?

IMHO 그것은 끔찍한 아이디어 입니다.

협업 대신 경쟁 을 강화할 것입니다 .

경쟁을 늘리지 않고 부서 간 부서 간 협업이 필요합니다.

또한 동료 (다른 사람들 앞에서)에 의해 다운 보트가 정신 건강에 미칠 수있는 극도로 부정적인 영향을 상상하십시오.

모든 것을 섞지 마십시오.

그러나 직원들이 (익명으로) 아이디어를 게시 할 수 있고 아이디어를지지하는 다른 직원들도 (명실하게) 아이디어 상자에 긍정적 인 영향을 미칩니다. 나는 몇 년 전에 매우 큰 은행 기관을 위해 그러한 플랫폼을 개발했으며 경영진이 우선 순위를 개선 할 대상을 파악하는 데 도움이되었습니다.

나는 위키 아이디어도 정말로 좋아하지만 당신이 옳다-사람들이 기여하기가 어렵습니다. 기여하지 않으면 정보가 충분하지 않기 때문에 실제로 사용하지 않습니다. 그러나 어떤 시점에 사람들이 (필요한 비즈니스 프로세스를 통해) 게시하도록 할 수 있다면 위키는이 훌륭한 정보 저장소가되기 때문에 이륙 할 수있는 "티핑 포인트"가 있습니다.

페어 프로그래밍은 암묵적 지식을 유포하는 좋은 방법입니다.

암묵적 지식의 문제는 정의에 의해 기록되거나 가르치지 않고 경험이 많을 수 있다는 것입니다. 페어 프로그래밍 (특히 무차별 페어링)이이를 제공합니다.

기업에 중요한 지식은 잘 작성된 코드, 아키텍처에 대한 고급 주석, 프로젝트 목표 및 기술로 달성 한 방법에 대한 예외적 인 문서 형식으로 프로젝트 자체에 적용해야합니다.

나는 연결된 저자의 결론에 더 이상 동의하지 않았다. 팀 협업을 장려하여 지식 포착을 장려하고 있습니까? 죄송하지만 작동 방식은 아닙니다. 큐비클에서 엔지니어를 격리시키는 것이 아니라 지식을 창출하는 것은 협업 자체입니다.

우리 회사에는 내부 토론 게시판이 있습니다. 그들은 거의 사용되지 않습니다. 대부분의 경우, 우리가 알고있는 지식은 너무 일반적이거나 (인터넷에서 마찬가지로 논의되는 일반적인 기술 질문 / 주제) 너무 구체적입니다 (동일한 회사의 다른 응용 프로그램 팀이 아닌 응용 프로그램에만 적용됨). 사람들이 여기서 xyz를 어떻게 달성 할 수 있는지 말하지만 커뮤니티 느낌은별로 좋지 않습니다.