부족한 후임 교육 어떻게 시키세요?

망치의 이미지


제 밑으로 웹프로그래밍을 하는 사원이 한 명 있는데, 경험이 많이 부족합니다.
저도 실력이 딸리는데 저보다 더 부족하다보니 뭔가 대책을 강구해야 겠는데 구체적으로 어떻게 뭐부터 해야할지 감이 안서요.

그동안 일이 바빠서 그냥 닥치는 일만 각자 처리하다보니 서로 메인업무에 대한 정보 공유가 부족했는데, 어제 짬을내서 작업물을
검토해본결과 뭔가 대책이 시급하다는걸 깨닳았습니다;

눈에띄는 몇몇... 예를들어 문제 발생시 네이버에서 검색하는걸 보고 구글 검색을 권장하도록 했고, 질문을 할 경우엔 검색 키워드를 알려주곤 했는데
정작 메인업무에 대해선 직접 코드를 보거나 작업물을 검토해본적이 없다보니 허술하기 그지 없더라구요.. 작게는 게시물 목록에서 삭제시 경고창을
띄워서 정말 삭제할것인지 확인하는 과정없이 원클릭에 삭제되도록 해뒀다던가.. 크게는 DB 쿼리에 Get/Post 메소드로 날아온 데이터를 escape 처리 하지 않고
그냥 넣는다던가 하는... 식은땀나는..;

주중엔 서로 자기 업무로 바쁘니 주말에 회사로 한번 불러내서 첨부터 코드를 쭈욱 보면서 하나하나 잡고 잔소리하면 도움이 될까요?;

hurtak의 이미지

저도 이런 고민 많이 하는데, 일단 서로 이야기를 해 보는 것이 좋죠.
회사가 돈으로 이루어진 이해관계라서, 이야기 해 보고 안 될 것 같은 녀석이면 안 되는 것이죠.
처음에는 잘 안 되고 고집이 세다고 느끼는 후배를 고칠려고 많이 노력을 했지만,
안타깝게도, 지금은 안 되는 사람은 분명히 안 되는 것입니다.

이야기를 해 보고 할 의욕이 있다면 이끌어주지만, 잘하지도 못하면서 불만을 갖고 있는 후임을 데리고 이끄는 것은 서로 피곤한 일입니다.
본인이 할려고 하는 의지가 있다면, 망치님이 잊지말아야할 가장 중요한 덕목은 "Mind Control"입니다~^^
후배를 더러 받아봤는데, 이 녀석이면 키워주고 싶다 싶은 사람은 30~40% 정도 밖에 안 된답니다~^^
좋은 후배를 만나는 것도 회사운의 하나입니다!!!

-_- _-_ -_-

snowall의 이미지

잔소리하는걸 도움으로 받아들이면 다행이고, 그냥 잔소리로만 받아들이면 발전이 없을 것 같네요.

그래도 주말에 나오면 밥은 사주세요 -_-;

피할 수 있을때 즐겨라! http://melotopia.net/b

gurugio의 이미지

서로 코드 리뷰를 해서 잘못된 코드에 대한 책임 의식을 주는 것이 먼저일것 같습니다.
그리고 너의 코드 상태가 부족하니 더 발전해야한다고 유도해야할것 같습니다.

리뷰를 통해 자기 상황이 부족함을 알면서도 노력을 하지 않는다면
리뷰 결과나 기타 증명될만한 자료를 가지고 보다 상급자에게 직원 교체등의 조치를 요구해야합니다.
그 후배님의 실수가 본인의 책임이 될 경우가 아주 많을거라 예상(확신)됩니다.

상사에게 "넌 그동안 안가르치고 뭐했니"라는 소리를 들으면 후배사원때문에 본인까지 찍힌것입니다.

망치의 이미지

말씀하신 내용 거의 그대로... '신경좀 써야지 왜 이렇게 방치해뒀어' 란 소릴 들었습니다. -_-;;..

---------------------------------------
http://www.waitfor.com/
http://www.textmud.com/

winner의 이미지

아시다시피 사람이 추가로 투입되면 오히려 결과가 느리게 나올 수도 있는 상황이 딱 현재인 것 같은데요.
후배와의 의사소통과 후배작업결과물의 질을 빠르게 올리는게 우선순위가 높다면 같이 작업해보시는 것도 좋을 것 같습니다.

sql2의 이미지

후배의 의도, 목표 ...등을 먼저 파악하시는게 중요할 것 같습니다.

술자리, 티타임, 여가활동.. 등으로 많은 대화를 해보고,

이 친구가 어떤 코드멍키인지 파악하는게 좋을 것 같습니다.

선천적 개발자라면 휴일에 불러서 밥, 술 사주면서 코드리뷰해주면 좋아 할테고,

생활밀착형 개발자라면 휴일에 부르면 참~ 싫어할 겁니다.

select99의 이미지

해야할 업무를 주고..

기간내 기능을 검토하고 미비점이 있으면 지적을 합니다.

당연 되어야할기능이 (확인기능등).. 없다면 지적될것이고.. 왜 있어야 하는지는 설명을 해줘야겠죠..
단동일한 실수를 반복해서 저지르지 않으면 됩니다.

부족한점이 있따면 방향을 제시해주고... 방향대로 잘 따른다면 그걸로 된것인데..
하지않고 딴짓만 한다면.. 문제죠...

nthroot의 이미지

저는 그냥 못 본척 덮습니다...원하는 아웃풋만 나오면 됩니다.
안에서 무슨 짓을 하고 무슨 잠재적인 버그가 있던지..그건...먼..미래의 일..
그땐 제가 이 회사에 없길 빌면서..말이죠.

------식은이 처------
길이 끝나는 저기엔 아무 것도 없어요. 희망이고 나발이고 아무 것도 없어.

ydhoney의 이미지

품에 안거나

내치거나

품에 안을 놈이다 싶으면 정말 옆에 끼고 집에 데리고 다니는 한이 있어도 옆에 죽어라 붙어서 얘기해보고 생각을 틔워놓으면 되구요. 솔직히 업무스킬이니 기술이 어쩌고 하지만 마인드가 터야 일을 하니까요. 마인드 개조부터 하는게 급선무고 그게 되면 나머지는 알아서 차차 풀립니다. 그렇다고 그 쪽으로는 터치를 안한다던지 하면 안되고 기술적으로도 도자기 만들듯 좌우 안 삐져나오게 툭툭 치고 매만져서 둥글둥글 도자기 모양 만들어가면서 하면 되는거구요. 너무 처음부터 끝까지 틀을 잡아준다 생각하면 힘들어요. 기본적 틀은 마인드로 만드는거고 기술적 틀은 어긋나가지 않게만 해주면 된다고 봅니다.

내칠놈이면 솔직히 그냥 신경 끄시고 스스로 후임때문에 피해볼 일만 피하시구요.

lowid의 이미지

1 구글링을 가르칩니다.
- 검색 옵션(?) 팁 같은걸 말이죠, 스스로 할수 있도록

2 예제를 들어 줍니다.
- 제대로 만든 웹페이지 예시라던가를 보여줘서... "아 이렇게 하는게 제대로 하는구나" 라는것을 느낄수 있게요. 그리고 나중에라도 흉내라도 낼수 있게......

3 포맷을 줍니다
즉, 가이드라인 - 해야만 하는것, 하지 말아야할것, 문서로 작성해서 줍니다.

이걸 하기전에 당연히 의사소통이나, 책임의식이라던가 이런건 먼저 선행되어야 하겠죠....

이정도만 하면 될것같다고 생각해요...... 개인적으로.......

적어도 떡밥은 풀어놓고 물길 바라는게 나을것 같습니다. 맨땅에 해딩하는거 보다요.

---------------------------------------------
아치리눅스좀 써주세요
-> 아치리눅스 유저 좀 꼬셔오세요. 1인당 10명!

whitenoise의 이미지

저는 후임이 생긴다면 주말에 불러내기 보다는, 업무를 나누지 않고 같이 짝프로그래밍으로 해보고 싶어요. 더 피곤한 건 알지만, 설명해주고 피드백 받고하다 보면 오히려 내가 정리가 되면서 개선점을 발견하거나 놓쳤던 핵심을 파악하는 경우도 생기고...

mmx900의 이미지

매일 혹은 정해진 시간에 코드를 리뷰합니다.
함께 리뷰할 여력이 안 되면, SCM을 쓰시면 좋습니다.
매일 로컬 사본을 업데이트 하면서, 업데이트된 내용을 보면 파악이 어렵지 않습니다.
(커밋 주기나 커멘트 등 커밋 습관을 바로잡아 줄 수도 있고...)
이렇게 리뷰 하면서

1) 구조가 이상하거나 괴상한 코드를 만들어 낸다 -> 문제를 정확히 짚어 줍니다.
2) 같은 문제가 또 발생한다 -> 저번에 알려 준 문제를 바탕으로 스스로 풀게 합니다. 못 풀면 바로 답을 알려주지 말고 옆에 붙어서 어떻게 풀려고 했는지를 따라가면서 푸는 방법을 알려줍니다.
3) 조금 미흡하지만 해결하려고 노력한 게 보인다 -> 지나친 수준 미달이 아니라면 셋에 두 번은 적당히 넘어가는 식으로 긴장을 조금씩 완화(?)하면서 간간히 문제점과 더 나은 방법을 제시합니다. 물론 본인이 별 스트레스 안 받고 알려주는 사람도 안 피곤하다면야 보이는 족족 알려주면 좋지만요 ㅡㅅㅡ

이때 관리자 입장에서는
- 알려 준 내용을 잘 활용하는지(지적할 사항이 점차 줄어드는지)
- 이렇게 알려주는 것을 자기 발전에 도움이 된다 생각하고 달갑게 받아들이는지
를 확인할 필요가 있습니다. 이 두 가지가 되지 않는 사람은 추후 계속 함께 일하기가 정말 어렵습니다.

이 두 가지가 되는 사람이라면 알려 줄 것은 알려주되, 비 권위적인 자세로 임하는 게 좋습니다. 무슨 소리냐면 이렇게 지적을 하다 보면 지적하는 내가 반드시 가장 옳은 답이 아닐 수도 있고 듣는 입장에서는 그런 의도로 작성한 코드가 아닌데 억울하게 듣는 소리가 있을 수도 있습니다. 혹은 후임이 작성한 코드가 다른 면까지 고려했을 때 최선의 방안일 수도 있고, 그리고 내가 과거에 했던 이야기를 잊어버리고 다른 이야기를 하게 되거나 하는 수도 있습니다. 이 경우 호통을 치다가 얼버무리면 모양새가 좋지 않겠지요.(...) 처음에 문제점을 지적하는 입장과 이유를 명확히 알려주고 토론의 자세로 임하다 보면 나중에 배우는 경우도 생깁니다(!).

그리고 제 경험으로는 처음부터 마인드의 문제로 보는 것은 별로 좋지 않습니다. 어느정도 경계는 해야겠지만, 그렇다고 처음부터 이런 이야기를 해야지 하면 자칫 경험 부족에서 나올 수 있는 어떤 실수도 다 마인드 문제로 보일 수가 있습니다. 닥달한다고 갑자기 뇌의 숨겨진 구석에서 프로그래밍 지식 같은 게 튀어나오고 하지 않습니다. 모르는 건 가르쳐 줘야 합니다. 다만 같은 실수가 반복되는데도 본인이 별 노력이 없어 보인다 싶으면 그때 비전이나, 평소의 시간 활용 같은 좀 사적인 이야기로 넘어갈 수는 있겠습니다. 물론 사람마다 가장 적합한 방법이 분명 따로 있기는 할 겁니다만 (...)

그리고 위에 언급하신 경고창이나 escape 처리의 경우, 개발 가이드가 부재한 상황으로 보이는데요. 혹 분명히 문서에 명시 되어 있는데도 무시한다면 이 역시 알려주고 바로잡을 필요가 있습니다.

쓰고 보니 위에서 다 나온 이야기만 한 것 같군요. 어디까지나 제 스타일입니다. 욕설과 망신을 번갈아 주면서-_- 깨우쳐 주는 경우도 있다고 들었습니다만 제 경우는 받은 적도 준 적도 없고 앞으로 할 생각도 없어서 모르겠습니다.

Setzer Gabbiani