신입 사원 교육을위한 더 좋은 방법 [닫기]


10

현재 팀은 상당히 높은 이직 경험을 가지고 있으며 일반적으로 동일한 회사 내에서 다른 프로젝트로 이동하는 회원들과 함께합니다. 현재 신입 회원을위한 "훈련"은 실무 경험을 제공하고 신입 사원이 멘토에게 무엇인가를 물을 경우 상급 개발자에게 물어볼 주요 연락 담당자 (일반적으로 가장 최근에 훈련을받은 사람)와 연결하는 것입니다. 몰라 신입 사원이 신속하게 참여할 수있는 기회를 제공하고 멘토에게 시스템에 대한 이해도를 높이도록 요구합니다.

그러나 당신이 상상할 수 있듯이,이 훈련 스타일은 시간이 많이 걸리고, 아주 좋은 지식 전달을 제공하지 않습니다 (오해가 전파되고 격차가 커짐).

미래의 신입 사원을위한 문서 및 교육 자료를 작성하는 일을 맡았습니다. 이미 기술적 인 글을 쓰고 있지만 최종 사용자를위한 것이며 스크린 샷이 많고 완성하는 데 많은 시간이 소요됩니다.

신입 사원을위한 새 문서 작성은 우선 순위가 낮으며 현재 ~ 40 시간 밖에 걸리지 않습니다. 기술 문서를 작성하는 현재 방식으로 시스템을 문서화하면 40 시간 안에 표면이 거의 긁히지 않습니다. 특히 코드 기반뿐만 아니라 배포 및 지원에 대해서도 문서화해야한다는 점을 고려하십시오.

문서를 작성하는 데 상당한 시간을 투자하지 않고 가능한 한 빨리 신입 사원을 고용하기 위해 문서를 신속하게 작성하려면 어떻게해야합니까?

추가 정보 :
우리는 현재 위키와 몇 가지 교육 문서를 가지고 있지만 둘 다 희소합니다.


2
소프트웨어 개발은 ​​어떻습니까? 프로그래머가 아닌 교육 컨설턴트가 필요한 것 같습니다.
Cyclops

4
문서가 소프트웨어 개발의 일부가 아닌 경우 주석이 소스 코드의 일부가 아닌가?
Malfist

코드의 작동 방식을 설명하는 텍스트를 작성하는 것은 확실히 소프트웨어 개발의 일부입니다. "신입 사원을위한 문서 및 교육 자료 생성"- 소프트웨어 개발의 일부 가 아니며 프로그래머의 기술력이 적절하지 않을 수 있습니다. 프로그래밍과 관련된 신입 사원 교육 문제도 아닙니다. 귀하의 질문은 전적으로 일반적입니다.
Cyclops

답변:


17

좋은 질문. 프로그래머의 실무 교육은 거의 진지하게 받아 들여지지 않으며 자주 언급되지도 않습니다.

내가 본 몇 가지 아이디어는 잘 작동합니다.

  • 위키에서 새로운 채용 문서를 작성하십시오. 이 문서에는 신입 사원이 처음 1-2 주 동안 수행 할 작업을 설명하십시오. 내가 일하는 곳에서는 내부 소프트웨어 / 도구, 프로세스, 특정 유형의 정보 위치에 이르기까지 많은 정보가 있습니다. 편집> 우리는 구성 등의 스크린 샷과 함께 "x, y, z 순서대로 설치"와 같은 지침을 가지고 있습니다. 따라서 Win Server, SQL Server, SharePoint, BizTalk로 시스템 또는 팜 (VM)을 구성하는 것은 우리의 소프트웨어만큼 간단하지 않습니다. 소리. 이것은 우리가 지원하는 다른 버전의 응용 프로그램에도 적용됩니다.
  • 연습 문제. 내가있는 곳에는 큰 API를 노출시키는 제품이 있습니다. 따라서 고객 / 고객과 마찬가지로 확장 기능을 작성하기 위해 자체 제품 문서를 작성하는 것이 항상 유리합니다. 따라서 제품 API의 일부로 수학 라이브러리가있는 경우 "API를 사용하여 계산기 작성"또는 이와 유사한 연습 문제가 있습니다.
  • 멘토는 좋습니다. 보관하십시오. 우리는 여기서도 그렇게하며, 사람들을 만나거나 친구를 사 a 수있는 좋은 방법 일뿐만 아니라 학습의 원천으로서 귀중합니다. 다른 사람이 할 수있는 회사 지식 이력이 없으므로 교육을 마치는 것이 가장 최근 사람이 아닌 것이 좋습니다 . 모든 사람이 회전하도록하십시오.
  • 우리는 (주로) 매주 발표 / 기술 강연을합니다. 신입 사원이 귀하의 제품에서 무언가를 선택하도록하거나 3 주 후에 프리젠 테이션을하도록하십시오. 그들이 틀릴 여지가 있음을 확인하고 프레젠테이션에서 문제가 발생하면 팀에서 수정할 수 있습니다.
  • 신입 사원이 시작될 때 문서 작업을하게하십시오. 강제로 읽습니다.

댄 맥그래스 (Dan McGrath)가 지적했듯이, 신입 사원이 위키를 향상 시키도록 격려하는 것이 좋습니다.


2
+1. 새로 고용 된 직원은 이것이 누락되었거나 부족한 것을 발견 할 때 위키 / 문서를 개선해야한다고 덧붙이는 것이 좋습니다. 이를 통해 가장 숙련 된 직원이 보내는 시간을 최소화하면서 온 보딩 리소스를 개선 할 수 있습니다. 또한 신입 사원의 이해를 공고히하는 데 도움이됩니다.
Dan McGrath

신입 사원이 문서 작업을 할 수 있도록하는 것과는 별도로, 우리가 직장에서하는 모든 좋은 점과 일. 이것에 대한 몇 가지 문제 : a) 너무 정신적입니다. b) 아마 전문 용어가 들어있을 것이다. c) 새로운 것이 올바른지 어떻게 알 수 있습니까?
Burhan Ali

2

먼저, 고객을 위해 작성하는 것만 큼 새 고용 교육 문서를 작성하지 않아도되도록 제안합니다. 새로운 개발자가 가이드로 사용할 수있을만큼 충분히 기술적 인 것이 필요하지만, 모든 작은 것을 간략하게 설명 할 수는 없습니다. 결국 질문이 있으면 팀과 대화 할 수 있습니다.

신입 사원이 팀에 유용하기 위해 알아야 할 10 가지 사항은 무엇입니까? 이것에 집중하십시오. 새로운 개발자가 할 수있는 충분한 정보와 계속 진행할 수있는 충분한 정보를 얻을 수 있도록 적중 항목 목록을 작성하십시오. 목록에 너무 많은 것들이 있다면, 처음 2 ~ 3 주 안에 할 것인지 스스로에게 물어보십시오. 만약 그들이이 시간에 무언가를하지 않는다면, 탑승 가이드에 포함되어서는 안됩니다.

가이드의 각 섹션마다 맨 위에 강조 표시된 사람이 있는지 확인하십시오. 이런 식으로, 신입 사원이 궁금한 점이 있으면 누구에게 도움을 청해야하는지 알고 있습니다. 또한 한 팀원이 너무 많은 섹션으로 이동하지 않도록하십시오. 한 사람이 멘토가 아닌 경우 새 고용 관련 질문에 시간을 투자하고 싶지 않습니다.

이 문서에 1 주일을 소비하지 마십시오. 적어도 한 명의 신입 사원이 통과 한 후에는 시간을내어 조정하십시오. 잘 작동하는 것과 그렇지 않은 것을보고 수정하십시오.


~ 40은 다른 프로젝트를 조기에 완료 한 것이므로 처음 40 시간이 지나도 나중에 더 이상 시간이 없다는 것을 의미하지는 않습니다.
Malfist

1
@Malfist-충분합니다. 그러나 시간이없고 우선 순위가 낮은 경우 프로젝트에서 작업하는 동안 테스트 실행을위한 첫 번째 초안을 작성하는 것이 가장 좋습니다. 이에 대한 반복적 인 접근 방식을 사용하여 작업을 수행하고 더 많은 피드백을 받으십시오. 당신이 10 가지를 고르고 신입 사원이 '실제로 4 섹션을 실제로 사용하지 않았지만 ____ 섹션은 좋았을 것입니다.'라고 말하면 문서를 개선하고 다음에 더 유용하게 업데이트하는 방법을 알고 있습니다 사람.
Tyanna

2

최근에 비슷한 시간 제약 조건으로 직장에서 비슷한 문서를 시작했습니다. 나는 처음에했던 것처럼 매우 상세한 수준으로 작성하기가 쉽지만 실제로는 비생산적 일 수 있음을 공감합니다.

새로운 사람이 역할을 시작하면 처음 몇 주 동안 정보가 넘칠 수 있습니다. 초기 교육을 여러 해 동안 회사에서 근무한 개발자의 두뇌 덤프로 생각하면 처음 몇 개월 또는 심지어 그 위치에서 1 년 동안 알아야 할 사항이 훨씬 복잡해집니다. 높은 수준을 유지하고 표준 전문 용어와 개념을 사용한 다음 회사 프로세스 내에서 구체적인 내용으로 확장하십시오.

저에게이 문서의 첫 번째 반복은 단순히 각 단계 내에서 관련된 역할 목록, 해당 역할을 수행하는 사람들의 몇 가지 예 및 수명주기의 각 단계도 마찬가지입니다. 나는 개인적으로 훈련 목적에 없어서는 안될 체크리스트는 물론 직장에서하는 다른 일도 발견합니다. 예를 들면 다음과 같습니다.

  • 프로젝트 관리자 (Joe)는 Jira에서 작업을 할당합니다.
  • 공식 x를 기반으로 작업의 예상 완료 시간을 설정하십시오.
  • 티켓 작업을 시작할 때 티켓을 '진행 중'으로 설정하십시오.
  • 자식에서 분기를 만들고 링크를 클릭하면이 진행 상황에 대한 30 초 비디오를 볼 수 있습니다.
  • 설계 문서에서 제약 조건에 따라 단위 테스트를 작성하십시오. 단위 테스트 명명 규칙은 y 페이지를 참조하십시오.
  • 검토를위한 티켓을 설정하고 검토 시스템에 코드를 제출하십시오. '등

신입 사원은 대부분의 개념을 잘 알고 있어야하며 이제 회사에서 프로세스를 적용하는 방법을 단계별로 안내해야합니다. 또한 잘 실행되었다고 생각되는 프로젝트의 실제 문서를 사용하여 처음부터 끝까지 프로세스를 빠르게 시연합니다.

언급했듯이, 그것의 살아있는 문서이기 때문에 더 많은 정보가 필요하다고 식별되면 섹션을 확장 할 수 있습니다. 팀 전체를 최신 상태로 유지해야합니다. Wiki, OneNote 문서 등 모든 사람이 편집하고 검토 할 수있는 문서 일 수 있으며 여가 시간이있을 때 다른 사람이 문서를 개선하는 데 참여할 수 있습니다. 그렇게하면 한 사람이 그렇게하지 않고 모든 신입 사원에게 그 과정에서 자신의 스핀을 전파합니다.

프로세스를 검토 한 후에는 미션 크리티컬 프로젝트의 작은 기능 / 버그 수정을 따르고 문서에서 다루지 않는 질문을하게합니다. 다음에 작업 할 때 문서에 가장 먼저 추가해야 할 질문이므로 이러한 질문이 무엇인지 기록하십시오.


1

시간을 보내지 않으면 서 이와 같은 일을 함께 할 수는 없습니다. 적어도, 당신이 직접하고 싶다면. 시도하고있는만큼 정확하게 문서화해야하는지 스스로에게 자문해야합니까?

유일한 대안은 신입 사원이 주요 업무를 수행하도록하는 것입니다. 그들에게 일부를 쓰게하십시오. 피드백의 형태로 이러한 문제를 해결하는 데 소요되는 시간은 현재 상황보다 적습니다. 좋은 템플릿을 제공하면 레이아웃에 대해 걱정할 필요가 없습니다.


1

나는 그들이 당신에게 임무가 불가능한 임무를 수행했다는 것을 이미 알고 있다고 생각합니다. 작가로서 아마도 Mark Twain의 인용문에 이미 익숙 할 것입니다.

시간이 더 있다면 글을 적게 썼을 것입니다.

실제로 리소스가없는 경우 파일 캐비닛을 가져와 모든 사람에게 이미 가지고있는 사본을 만들어 파일 캐비닛에 넣도록 요청하는 것이 가장 좋습니다. 그렇게하면 최소한 신입 사원에게 "시스템에 대해 뭔가를 찾아 보려면 시작할 곳이 파일 캐비닛에 있습니다."라고 말할 수 있습니다.

글을 잘 쓰려면 시간과 시간이 걸립니다. 또한 대상 고객에 맞게 조정해야합니다. 최종 사용자에게 효과적인 것은 프로그래머에게 필요한 것이 아닙니다.

좋은 교육은 서면 자료에만 국한되지 않으며 온라인, 강의실, 멀티미디어 등을 포함한 전체 교육 리소스가 포함됩니다.

"교육이 비싸다고 생각되면 무지 비용을 시도하십시오."

또한 문서를 처음부터 프로세스의 불가분의 일부로 만드는 것이 아니라 사실 이후에 수행해야 할 것으로 문서를 보는 것은 체계적인 조직 문제를 나타냅니다.


우리 팀은 전 세계에 퍼져 있습니다 ... 그래서 제출 캐비닛이 최선의 아이디어가 아닐 수도 있습니다.)
Malfist

자, DropBox.com과 같은 가상 파일 캐비닛을 마스킹하십시오
JonnyBoats

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.