좋은 습관이라고 생각하는 것을 채택하지 않거나 나쁜 습관으로 보이는 것을 계속하고있는 사람들의 동기를 추측하는 것이 도움이되지 않는다고 생각합니다. 이 비즈니스에서 해당 범주 중 하나 또는 둘 모두에 해당 하는 사람들은 눈에 보이는 사람들보다 훨씬 많으므로 자신을 미치게하지 마십시오.

대신 문제와 가능한 해결 방법에 중점을 둡니다.

1. 좋은 문서를 직접 작성하십시오

팀의 모든 사람이 자신이 문제라고 생각하는 것에 노력을 기울일 것이라고 기대하는 것은 현실적이지 않을 수 있습니다. 팀에 비교적 새로운 사람이라면 더욱 그렇습니다. 팀의 창립 멤버 인 경우 이미이 문제를 이미 해결했을 것으로 보입니다.

대신 좋은 문서를 직접 작성하여 사람들이 사용하도록하는 목표를 향해 노력하십시오. 예를 들어, 팀의 누군가가 프로젝트 A의 소스 코드가 어디에 있는지 또는 프로젝트 A가 필요한 특별한 구성을 묻는다면 프로젝트 A 위키 페이지를 가리 킵니다.

누군가 C 클라이언트를 위해 커스터마이징하기 위해 Factory F의 새로운 구현을 작성하는 방법을 묻는다면 개발자 안내서의 10 페이지에 나와 있습니다.

대부분의 개발자는 문서를 읽는 것보다 훨씬 더 “코드를 읽을”수없는 것처럼 보이게 만드는 질문을 싫어하므로 이러한 특성에 대한 충분한 대답을 마치면 먼저 문서로 이동합니다.

2. 문서의 가치 입증

문서가 그 가치를 입증하는 곳 (또는 사용 된 경우)을 가리킬 수있는 기회를 갖도록하십시오. 미묘하게 행동하고 “내가 말했듯이”피하는 것은 좋지만

나중에 참조 할 수 있도록이 프로젝트의 위키 페이지에는 릴리스 2.1을 지속적으로 지원하기 위해 작성된 핵심 코드의 분기에 대한 정보가 있으므로 향후 릴리스 버전을 유지 관리하는 사람이 확인하는 경우 전체 회귀 테스트를 수행하지 않아도됩니다. 코드를 확인하기 전에 위키.

또는

작업 T를 수행하기위한 단계를 적어 두었습니다. 다른 사람이 사용하지 않더라도 실제로 신경 쓰지 않습니다. 이미 쓴 시간보다 더 많은 시간을 절약했습니다.

3. 선상 관리

문서화가 시간 / 돈을 절약 할 수있는 몇 가지 사건이 발생하면 문서화에 대한 뚜렷한 “해동”을 보게 될 것입니다. 이것은 예상 시간에 문서화 시간을 포함하여 요점을 누를 때입니다 (솔직히 말하면 컴파일 또는 체크인과 같은 긴 프로세스가 실행되는 동안 일반적으로 문서를 업데이트 / 생성합니다). 특히 이것이 최근 고용인이라면, 이것이 의문의 여지가 없지만 이전 직장에서 가져 오는 새로운 관행으로 간주 될 수 있습니다 (아마도 가능할 것입니다).

주의 말씀 : 대부분의 상사는 싫어 하기 때문에 이러한 지원은 위임의 형태로 될 것으로 기대하지 않습니다, 특히, 사람들은 아무것도 할 직접 청구 작업에 묶여 있지 것을. 대신, 더 많은 문서를 작성할 수있는 상대적으로 자유로운 고삐를 줄 가능성이 높습니다.

4. 문서를 볼 때 격려하십시오

사람들이 문서를 자주 쓰지 않는 이유 중 일부는 아무도 그것을 읽고 있지 않다고 생각하기 때문입니다. 그러므로, 당신이 좋아하는 것을 볼 때, 적어도 당신이 그것을 이용할 수 있다는 것이 기쁘다는 것을 언급하십시오.

팀에서 코드 검토를 수행하는 경우 좋은 의견을 장려하기 위해 미묘한 단어를 넣을 수 있습니다.

프레임 워크 G에 버그 B에 대한 해결 방법을 문서화 해 주셔서 감사합니다. 나는 그것에 대해 몰랐습니다.

팀에 실제로 문서화에 대해 열정적 인 사람이 있다면 , 점심이나 커피를 마시면서 그 사람을 키우고 팀의 나머지 부분을 볼 때 얻을 수있는 실망을 막기 위해 약간의 검증을 제공하는 것이 상처를 입지 않습니다. 문서를 중요하게 생각하지 않습니다.

그 외에도, 당신이 리드 또는 관리 직책에 있지 않으면 실제로 문제가 아닙니다. 말을 물로 인도 할 수는 있지만 마실 수는 없습니다. 그것이 당신의 말이 아니라면, 목이 말라서 기뻐할 수도 있지만, 여물통을 채우는 것만으로도 가능합니다.

답변