문서 작업을 잘 못하거나 싫어하는 직원은 어떻게 하시나요?
글쓴이: gamgi / 작성시간: 월, 2009/12/21 - 6:03오후
몇년째 여기서 눈팅만 하고 가는 회원입니다.
여러 고수분들의 글들을 읽으면서 도움도 많이 얻고 있습니다.
현재 고민중인 것이 지금 일하고 있는 직장에서 부하직원들의 문서작성 스킬이 너무 떨어져서 걱정입니다.
기본적인 개발자료 정리도 거의 안하는데 일이 바쁘니 그것까지는 터치하지 못하는데..
문제는 결과보고서나 중간 중간 보고 내용을 정리해서 올려야 하는데,
그런 것조차도 잘 못한다고 안하니, 보통 제가 정리하게 됩니다.
억지로 시켜도 내용이 너무 안나오니 90%이상은 제가 다시 작성을 하게 됩니다.
물론, 문서작업이 귀찮고 짜증도 많이 날 뿐더러, 코딩작업 못지 않게 머리아프게 하는 것은 알지만,
시키는 사람도 스트레스로 많이 쌓이네요... ㅠㅠ
이럴때 보통 어떻게 하시나요? 조언 부탁드립니다..
Forums:
샘플로 이렇게
샘플로 이렇게 작성해라 라고
완성 문서를 보여주면
따라해서 작업할 수 있지 않을까요??
제가 회사다니던 회사는 업무보고 외에
아무도 문서작업을 안했었다는...소스에 주석도 없었습니다...;;
해보긴 했는데..
답변 감사드립니다.
물론, 이전에 작성했던 보고서 등을 가지고 얘기를 해주고,
보고서 내용중의 일부분(특히, 본문 중 기술적으로 구현된 부분이 들어가는 부분)을 위주로
작성하라고 얘기를 합니다.
서론이나 결론 부분은 보통 제가 정리하지요..
막히면 어떻게 정리할 지 생각이라도 해보고 서로 논의하면 괜찮을 텐데..
그런 생각도 없이 사는 것 같네요.. ㅠㅠ
샘플을 작성하고
샘플을 작성하고 작성하는 법을 포함한 표준 작성 절차를
바인더로 묶어 만드는 것도 괜찮을 것 같아요. 나중에 신입이 들어올 때
실무 교육하기도 유용하고, 서로 크로스 트레이닝하기에도 자료로 활용할 수
있어서요. 사수와 부사수가 일단 있을 정도로 인력이 충분하다면,
더 멘토링하기가 편해질 텐데요.
문서 작성도 노력과 기술이 필요하죠
문서 작성도 나름 노력과 노하우, 기술이 필요 합니다.
그냥 이렇게 하면 되지.. 하고 접근하다가 잘 안되니까 대충 하고 덮어 버리다 보니 계속 늘지 않습니다.
senior 개발자들이 기안/기획서는 커녕 보고서 작성도 제대로 못하시는 거 보고 저도 놀랐습니다.
나름 내린 결론은 문서 작성은 Top-down 방식으로 진행 되어야 합니다.
양식을 만들고 과정별로 작성되어야 할 문서 목록을 만들고, 예제와 함께 등록 해 놓고 교육을 시킨 다음,
단계 별로 어떠한 문서를 작성해야 한다고 규정을 만들어 놓아야 좀 됩니다.
물론 폰트 사이즈까지 규정 하는 비 효율적인 규정 보다는 최대한 간결하게 내용일 전달 될 수 있도록 규정을 만드는 것이 중요 하겠지요.
이렇게 하면 개발 하면서 개발자들도 나름대로 나중에 문서 작업 할 것을 염두하고 작업을 하게 됩니다.
문서 작업이 어려운 이유 중 하나가
개발 할때 부터 문서 작업을 고려해서 만들어야 하는데, 그냥 개발하고 나중에 문서 작업 하려니 쓸 내용도 없고 뭘 어찌 써야 할지도 모른다는 것 이거든요.
이런 상황에서는 문서 작업 할 시간을 줘도 못합니다.시간 없어 못한다는 말 거짓말 입니다.
할 줄 몰라서 못하는 겁니다.
문서 작업은 최신성을 유지 해야 하는게 제일 중요 한 점인데,
규정이 잘 적용 되고 있는지 잘 관리 하셔야 겠죠.
이건 중간 관리자의 중요한 업무이겠죠.
답변 감사합니다.
계속 직장생활을 하다보니, 코딩보다는 설계나 관련 문서작업이 훨씬 더 중요한 것을
느끼게 되네요.
샘플이라고 말하지
샘플이라고 말하지 마시고, "템플릿"이라고 하시는게 좋겠지요?
보통 SI업체가 프로그램은 안짜고, 문서작업만 한다고 알려져있지만, 대부분의 경우,
프로그램 코딩은 하청을 줘도 문서템플릿이나 방법론은 직접 만들고, 그에 따라 문서를 작성해둡니다.
소스코드보다 제대로 된 문서가 나중에 훨씬 돈(?)이 되기 때문이지요.
일단 개발방법론을 정리하고, 각 개발 단계별로 필요한 입력산출물과 출력산출물 목록을 정리한 다음에,
각각의 산출물에 해당하는 템플릿을 작성하고, 그 템플릿에 해당되는 샘플을 한벌 만든 다음에
개발을 시작할때, 개발자들에게 각 산출물을 샘플양식에 맞춰서 다 채우도록 가이드하면 됩니다.
간혹 소스코딩은 해도, 산출물은 못채우겠다는 개발자들이 있는데, 그럴경우는 정해진 일을 종료하지
못했으므로 임금지불 및 대금지불을 안해도 됩니다. 납품물건을 "산출물" + "소스코드"로 해야
돈을 받기 위해서도 채우게 됩니다.
마찬가지로 직원들도 소스코드를 맨날 만들어봐야 산출물이 없는 무능한 개발자라고 구박을 줘야 그나마
문서 작성 스킬이 늡니다.
그리고, 이러한 산출물 및 소스코드를 통해서 QA 및 감리를 진행하게 됩니다. 이건 어느 개발에서도 필수적인
것이고, 허접하더라도 한벌의 산출물 세트를 만들면서 진행하는 개발방법론을 도입해야만 합니다.
그리고, 매번 단계별로 산출물과 소스코드를 체크하고 단계를 완료해서 다음단계로 진행하도록 하는 것이
PM 및 PL의 역할이라고 생각이 듭니다.
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
답변 감사합니다.
답글을 보니 새삼 문제가 많다는 것을 느끼게 되네요.
아무래도 회사가 작다보니 기본적인 것이라고 생각되는 부분도 정리가 안된것이 문제네요.
혼자서 대부분을 정리하고 개발도 직접 진행하다보니 이젠 힘에 부치는 지라.. ㅠㅠ
안돼면, 부서 이동이라도 시킬까 고민중이네요. ㅠㅠ
갈구셔야죠
별수 있나요 ^^
동감 100%
모르겠다. 안하겠다는...문제가 있는 것으로 비춰집니다~~ ^^;
============================
Stay Hungry, Stay Foolish
============================
Stay Hungry, Stay Foolish
입장 바꿔놓고 보면
입장 바꿔놓고 보면 악덕상사를 만났다고 불평할 지도 모릅니다.
아랫사람에게 뭘 시켰는지도 모르고...
아랫 사람이 뭘 했는지도 모르고...
고작해야 걸어다니는 전화기, 말하는 도장... 뭐 이런 부류로 매도당하고 계실지도 모르겠네요.
OTL
회사를 오래 다닐수록 주업무가 보고 위주로 됩니다.
회사를 오래 다닐수록 업무 비율이 이렇게 바뀝니다.
10-20% 실제로 내가 한 일
80-90% 내가(또는 우리팀이) 한 일을 남에게 보여주기위하여 자료 만드는 일
개발자로 성공하려면 개발을 잘하는 것이 아니라, 내가 개발한 것을 고객에게 이해시키는 것이 중요합니다.
고객의 대부분은 소스코드를 이해하지 못하므로, 고객이 이해하는 형태로 자료를 가공하는 스킬이 매우 중요합니다.
지금 제 업무는 개발에서 멀어졌지만, 고객을 이해시키기 위한 자료는 아직도 많이 만들고 있습니다.
No document, No result
No document, No result 입니다.
문서로 남기지 않은 것은 결과가 없는 겁니다.
이것은 말로 해서 될 일이 아니라 시스템 자체를 그렇게 되어야 합니다.
시간이 없다고 한다면 업무 조정 등을 통해서 일단 시간을 줍니다.
그래도 시간이 없다고 하면 그것은 다른 일 모두 제쳐놓고 문서화 작업만 시켜도 시간 없다고 할 겁니다.
DPR, WPR, MPR, QPR, HPR, YPR ... 모두 작성하도록 하면 그걸 묶으면 그 자체가 문서가 됩니다.
DPR - Daily progess report, WPR - Weekly ... MPR - Monthly ... QPR - Quarty, HPR - Half ..., YPR - Yearly ...
뭐 대충 이렇게 되는데, 우리 말로 하면 일일보고, 주간보고, 월간보고, 분기보고, 반기보고, 연간보고 .. 쯤 될 겁니다.
일일보고가 어려운 게 아닙니다.
그날 뭐 했다... 누구 만나서 뭘 했고, 어떤 얘기가 오갔다.
이거 그냥 쭉 모아서 일주일간의 내용을 정리하면 WPR
다시 WPR 을 쭉 모아서 정리하면 MPR
MPR 묶으면 QPR
QPR 두개 묶으면 HPR
HPR 두개 묶으면 YPR ...
YPR 은 인사고과 기초 자료...
이런 시스템으로 되어 있어야 문서 작성합니다. 그렇게 안하면 때려 죽여도 안하는 사람은 안 합니다.
정 쓸 게 없다거나 문장력이 없다고 하더라도, 적어도 하루에 A4 지 반장 정도만 채우게 해 보세요. 6개월 뒤면 다들 알아서 채웁니다. 그 6개월이 문제죠. 그때까지는 계속 끌고 갈 수 밖에는 없습니다.
저는 제 밑의 직원들이 DPR 제출을 안하면 이틀은 봐주고(정 급하거나 하는 경우도 있으니까요.) 삼일째 빼먹으면 그 주는 일을 안한 걸로 치고 다시 일 하라고 지시합니다. 위에서 일정 가지고 쪼건 뭐건 그건 내가 깨질테니 너는 니 할 일 하라고 다시 하라고 합니다. 그렇게 했더니 ... 좀 시스템이 갖추어지더군요.
매주 화요일 오전에 주간회의가 있는데, 그 회의시간에는 전주에 작성한 WPR 을 가지고만 얘기합니다. WPR 에 없는 건 일이 진척이 안된 것이므로 일정 점검을 위해서도 꼭 필요합니다.
근데.. 사실 저도 작성하기 귀찮을 때도 있습니다만, 머리가 나빠서 그날 그날 뭐 했는지 적어두지 않으면 까먹기 때문에라도 적어둡니다. 그렇지 않으면 그 다음날 했던 거 까먹고 다시 또 하는 경우도 있거든요.
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
http://akpil.egloos.com
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
계신 곳은 체계가 잘 잡혀있네요.
답변 감사드립니다.
사실 말은 하기 쉬워도 매일 일일보고하기가 쉽지는 않던데요..
저도 한번씩 빠뜨리고 지나가는 경우가 많기는 해서요.
그래도, 개발자료나 참고자료들을 틈날때마다 정리해 놓으면 나중에 급히 사용하기가 용이해서
조금씩 정리해 나가고 있습니다.
사실 규모가 작은 회사라 사내에서의 교육이나 지시도 한계가 있는편이라
외부 교육이 있으면 좋을 것 같다는 생각이 듭니다.
혹시 그런 것이 효과가 있을까요?
회사 규모하고는 별
회사 규모하고는 별 상관은 없습니다.
외부교육은 꽤 있는 것 같은데, 그런 교육을 체계적으로 받아본 적은 ... 입사때 30분쯤 들은 게 전부입니다.
분위기를 어떻게 만드느냐가 중요할 겁니다.
저 역시 저런 분위기 만드는데, 6개월 넘게 걸렸습니다.
뭔가 열심히 만들었는데, 문서화를 못해서 남이 그 공을 가로채가는 경우도 여러번 봤죠.
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
http://akpil.egloos.com
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
설마 MS워드나
설마 MS워드나 MS엑셀로 작성하라고 하시는건 아니죠?
───────────────────────
yaourt -S gothick elegant
khris'log
Naver English dictionary bookmarklet
───────────────────────
yaourt -S gothick elegant
khris'log
MS계열에 문제가 있는가요?
기본양식은 한글문서인데, MS워드나 MS엑셀에 무슨 문제가 있나요?
그 직원이 하는 일에
그 직원이 하는 일에 대한 문서가 필요하신 것이죠?
개발자에게 가장 쉬운 접근 방법은 이슈 트래킹 시스템과 버전 컨트롤 시스템을 이용하는 겁니다
이슈가 있을 때마다 이슈에 대해 티켓을 발행하고 해결하거나 새로운 사실 발생 때마다 한두줄씩 그것을 기록으로 남기게 하세요.
마찬가지로. 버전 컨트롤에 커밋 때마다 한두줄 정확한 커멘트를 남기게 하세요.
기간동안 수행한 작업에 대해 이슈 트래킹 시스템과 버전 컨트롤 시스템에서 기간으로 검색해서 쭉 나열한 뒤 필요에 따라 가감하여 보고서를 만드세요. 만든 보고서는 다시 이슈 트래킹 시스템에 등록해 놓으면 후에도 참고할 수 있습니다. 저희는 아예 스크립트 만들어서 돌려서 특정 기간동안 수행한 일 나열해서 쓰기 때문에 그런 보고서 만드는데 1분도 안걸립니다 - 언제든 원하는 사람이 있으면 그냥 스크립트 돌려서 아웃풋 줍니다.
매뉴얼 등과 같은 문서에 대해서는 글 못쓰는 사람에게는 안시키는 것이 좋다고 생각합니다.
저도 비슷한
저도 비슷한 생각입니다.
프로그래밍 작업에 영향을 줄 정도의 문서화 작업은 가능한 피하고 자동화된 문서로 해결을 보는게 훨씬 낫습니다.
버전콘트롤에 입력하는 로그, 프로젝트 관리시스템에 입력하는 로그(이 두가지가 최고죠.입력하는데 20초면 되고 모아놓으면 곧 기간별 작업 진행 보고서 나오고),
가끔씩 위키에 끄적이는 것들, 소스에 대충 적어넣어 doxygen등으로 만들어낸
문서, 이슈트래킹 시스템의 로그 등등...
물론, 일하는 분야에 따라 프로그래밍 이외에 따로 시간 투자가 필요한 문서화가 (마르미 같은거 보니 코딩보다 훨씬 어렵더군요)
필수인 경우도 있겠지만 프로그래머인들에게 일 시키는고 진척률 체크하는 등에 대한
실용적인 필요에 의해 요구되는 문서화는 이 정도면 충분하다고 봅니다.
프로그래밍 작업 열라 해서 일 끝냈는데 이제부터 문서 작성하라며 아래아 한글 깔아주는 보스는 별로 안예뻐 보일거 같습니다. ^^ 차라리 팀원들에게는 프로그래밍만 시키고 문서는 팀장등이 알아서 모두 맡는게 어떤가 싶네요. 매니저가 월급 더 받는 이유가 그런거 아닌가 싶습니다.
아니면 팀내에 여러가지 부가적인 일들(문서작성, 테스트 등 QA)만 전담하는 일종의 비서(?)를 한 명 두시는 것도 의외로 괜찮습니다.
개인적으로는... 문서 작업이라니 프로그래밍을 2배 더 하는 한이 있어도 피하고 싶습니다. 프로그래머들은 모두 비슷하지 않나요? ^^
=-=-=-=-=-=-=-=-=
http://youlsa.com
=-=-=-=-=-=-=-=-=
http://youlsa.com