회사 일일 업무일지에 대한 생각은 어떠하신지요?

zenguy의 이미지

일반 회사에서, 일일 업무일지의 제출을 요구할시에, 순응하시는 편이신가요?

저는, 그것이 왜 그렇게도 싫은지, 왠지 감시당한다는 느낌도 들고, 저를 못 믿어서 그러는것 같기도 하고, 뭐 그다지 썩 좋지는 않네요. ^-^;;

무언가를 보고 한다는것은 좋지만, 일일 업무일지를 메일 메일 하루 일과를 일기 쓰듯이, 상세하게 보고하여야 한다는것은 정말 마음에 들지 않는 군요.

이곳의 직장인분들도 직장에서 업무일지 작성을 하시나요? 그렇다면, 기분좋게 작성하시나요? 불필요한 작업이라고 생각하지 않으시나요? ㅋ

ps. 개인적으로 저는, 업무일지보다는, 작업결과물을 E-Mail로 보고 하는 쪽을 선택하여, 행하고 있습니다. 왠지 일기도 자주 못쓰는데, 일일 업무일지를 메일 메일 똑같이 쓴다는게.. 영 힘들기도 하고 귀찮기도..하고 :oops:

fender의 이미지

예전에 열받아서 한 3시간 동안 일일이 작업 내용을 모두 풀어서 4-5 페이지 쯤 되는 업무일지를 써서 올린 적 있습니다.

전 반항한다고 혼날 줄 알았는데 자세히 쓴다고 좋아하더군요 -_-;;

실제 무슨 일을 하는지, 또 얼마나 효율적으로 하는지보다 윗사람에게 얼마나 열심히 하는 걸로 보이는지에 더 신경을 써야하는 회사는 발전 가능성이 없다고 생각했습니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

siabard의 이미지

처음에는 그리 귀찮았지만 실제 프로젝트를 진행해나가면서 상당히 필요한 작업이란 것을 느끼게 되었습니다. 전체적인 일정이 나오더라도 실제 일단위로 작업을 분배하는 것이 상당히 어려운 것이고, 따라서 약간 개괄적으로 잡는 식으로 일을 했었는데, 일일 업무일지를 쓰면서, 일의 작업량을 계산하는 것이 편해졌습니다.

그리고 누가 어디를 못하고 있는지를 제대로 알 수 있었기때문에, 펑크가 날만한 작업을 그 때 그 때 체크할 수 있던 것도 상당한 의미를 둘 수 있었구요.

Email로 보고를 하든, Project같은 프로그램으로 공동작업을 하든간에 하루의 업무에 관한 보고는 상당히 필요성이 높은 것 같습니다.

새로움을 느끼기에 삶은 즐겁다..
모험가 아돌 크리스틴을 꿈꾸며..
Sia..

rxunil의 이미지

기록의 문화라 봅니다.
말을 아무리 많이하고 해봤자 흔적이없으면 무용지물이더군요 --;
저는 참고로 프로그램개발자는 아니지만
어쨋든 결과적으로 두고봤을때 업무일지라는것은
상당한 근거자료가된다고봅니다.
예전에 기계파트쪽의 일을 하고지금도 하고있지만 개발업무의 특성상
개발업무에 대한 기록은 필히 해두어야 한다고 개인적으로 생각합니다.
그것이 억지가되면 곤란하지만 능동적인 자세가 된다면 개인적인 발전에
상당한 도움이 되리라고봅니다...^^;;;
예전에 심할때는 전화통화 내용까지 적었던적까지있었던거 같더군요.
그때 거래처가 모모사의 무선사업부쪽이었는데...흘 그넘들 말바꾸는데.
환장하는줄 알았습니다....--;; 그때 제시한 근거가 그넘들 사인받은
일지였습니다...

저희회사는 참고로 일지를 적는 프로그램을 만들어버렸더군요...흘..

가끔은 거꾸로 세상을 보는 여유~
뛰면서 즐기는 소주한잔의 여유~

espereto의 이미지

지금 다니는 회사에서는 형식은 정해져있지 않아 상당히 편하게 씁니다. :-)
그리고 주 단위로 정리합니다.

내용도 간략히 적는 걸로 끝마칩니다.
중요하거나 자세히 해야 하는 부분은 보고할 때 말로 하고, 일지에는 간단히 정리해 놓습니다.

일지 쓰는 시간은 보통 30분 이내입니다.

일단, 한 주 동안 뭔 일을 했는지 스스로 알 수 있어서 좋습니다. 앞으로 계획 짤 때도 도움이 되고, 일의 특성상 내가 무슨 일을 하는지 남들이 알기 어려운 경우가 종종 생기는데 남들에게 인식시킬 수도 있고, 또 남들은 무엇을 어떻게 하는 지 알 수 있고 :)

안하는 경우에 비해 훨씬 좋다고 생각하고 있습니다.

근데 형식에 치우치면 일지 쓰는 게 또 일이 되어 버리니 그다지 안 좋을 듯 :)

morning의 이미지

회사는 예측 가능 해야 합니다.
그래야 이런 저런 판단을 하고 계획을 세웁니다.
어차피 회사는 조직이고, 조직다운 운영이 필요합니다.

개발자의 입장에서는 조금 더 일을 집중해서 실질적으로 하고 싶지만
회사의 입장에서는 일이 조금 느리더라도 정확한 스케줄이 나와야 합니다.
일의 진행 상태에 따라 다른 일을 조절하던가 지금의 일을 계속 추진 및
정리를 선택해야 하기도 합니다.
또 사실 직원이 무슨 일을하고 있는지 잘 모르기도 하고
불성실하게 일하는 직원에 대하여 감시와 압력이 필요하기도 하겠죠.

위의 이야기는 제가 직장 다니던 시절에
업무일지 작성에 대하여 자주 불만을 토하자
사장님과 이사님이 저에게 해주시던 이야기입니다.
음... 제가 경영자가 되면 간소하게 나마 업무일지 쓰게 할 것입니다.
지금은 백수라서 그런 일이 없지만 ^^

조르바와 함께 춤을....

fender의 이미지

관리자가 팀원들의 일정을 정확히 파악하는 것은 필수입니다만 그게 꼭 업무일지로만 가능하다고 생각하지는 않습니다.

개발의 특성상 초기에는 실제적인 코딩보다는 구상이나 이런저런 proof of concept 수준의 프로토타입 제작, 혹은 설정 테스트 등으로 보내는 시간이 많습니다. 또 개발이 진행되서도 어떤 날은 하루에 몇백줄 씩 나가기도 하고 어떤 때는 버그 하나 가지고 몇일을 헤매기도 합니다.

반면에 영업직은 설사 계약을 성사 못시키더라도 얼마던지 컨택한 사람들과 회사를 나열하는 것만으로도 쉽게 업무일지를 채울 수 있습니다.

따라서 몇일 씩 "xx버그 수정"이란 말로 업무일지를 채우는 개발자를 기술쪽을 잘 모르는 관리직이 곱게 볼리 없고 그러다보면 개발자는 갈굼 당하기 싫어서라도 적절히 어려운 말 섞어서 업무일지를 꾸매내는데 더 신경을 씁니다. 그렇게 만들어진 업무일지로 프로젝트 스케줄을 제대로 파악할 수 있을리는 만무합니다.

이렇게 볼 때 가장 이상적인 경우는 기술쪽에 충분한 식견을 가진 관리자가 개별적인 개발자들과 매일 얼굴을 맞대고 이야기를 하면서 정확한 문제 상황과 진행현황을 파악하는 것이 개발자 입장에서도 덜 번거롭고 훨씬 정확하게 일정관리를 할 수 있다고 봅니다.

반면 근거 자료로서의 업무일지는 어느 정도 가치가 있을지 모르지만 그런 성격의 일지라면 관리자가 작성해서 고객사에 보여주면 되는 것이고 오히려 업무 일지 보다는 회의록, 기획자료 등을 꼼꼼히 챙기는게 훨씬 효과적입니다.

...

아싸 100번째 포스트! -_-v

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

pebiman의 이미지

자신이 무슨 일을 하는지, 어떻게 진행되는지를 나름대로 정리할 수 있고, 팀단위의 일정을 조절하는데 필수라고 생각합니다.
또한 다음 연봉협상때 근거자료로 쓰일 수도 있으니, 업무일지는 그날그날 자세히 기록하는게 좋을 것 같습니다.
머..윗사람을 위해서 쓴다고 생각하는 것보다, 자신을 위해서 쓴다고 생각하시는 편이 좋을듯..^^

쓰레기는 쓰레기통에...

warpdory의 이미지

저는 써야 한다고 생각을 합니다.

전공이 전산쪽은 아닙니다만....

실험일지도 비슷하다고 봅니다.
하루종일 정말 진공 하나 잡으려고 나사 풀었다 조였다.. 할 떄가 있고.. 어떨 땐 근 2,3 달씩 그짓만 할 때도 있습니다. 버그패치하는 거랑 비슷하죠. 하지만...
그것도 적어둡니다. 최소한 교수한테 혼나지 않기 위해서라도 말이죠.
그런데... 그렇게 적다보면 뭔가 보입니다.
전번에 어느 포트의 나사를 다시 조였으니깐, 이번엔 이쪽을 다시 조여야겠군...
전번엔 알콜로 테스트를 했는데 못 잡았으니깐, 이번엔 헬륨으로 해봐야겠군... 이런 거라도 보인다는 거죠.
그것도 안되면 .. 해도 해도 안되는 거니깐 통쨰로 다시 만들어보자...

또...

실험을 씨리즈로 쭉 진행하다보면 했던 걸 또 하는 경우도 많이 발생합니다. (6개월동안 했단 걸 또 하는 경우도 있습니다.) 실험노트에 실험조건만 간단하게 적어두면 .. 대개 했던 걸 또 하게 됩니다. 하지만, 왜 그 실험을 했고, 실험할 때 전압이 어떻고, 전류가 어떻고, 날씨는 비가 왔었고(비가 오는 날엔 진공이 죽어라고 안 뽑히기도 합니다. 진공과 습기는 상극인지라... 하다못해 실리콘 웨이퍼 표면에 습도차이에 의해서도 공정 조건은 바뀌거든요.)... 이런 게 다 도움이 됩니다.

일지를 쓴다는 것도 비슷하리라 봅니다. 물론, 관리자가 겉모습만 중시한다면 ... 왜 일지에 쓴 글씨가 엉망이냐, 이딴 걸 트집 잡겠지만, 제대로 된 관리자라면 내용을 보고 이렇게, 저렇게 .. 업무 지도를 할 수 있겠죠. 뭐.. 제대로 된 관리자가 많지 않다는 게 또 문제가 되기는 하겠죠.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

redbaron의 이미지

Main 업무에 지장을 안주는 범위내에서는..필요하다고 생각합니다.

Main 업무에 지장을 초래할 만한 것은..좀 거시기..하다는..ㅡ_ㅡㅋ

eminency의 이미지

결국 방식의 문제가 아닐까 싶네요.

기록을 남겨두는 것이 나중에 나쁜 결과를 가져오는 경우는 거의 못 봤습니다. 비자금 기록 같은 것이 아닌 이상...-_-;;
일종의 문서화의 연장이라고 볼 수도 있을 것 같습니다만...

하지만 단순히 몇시부터 몇시까지 뭐 했음.. 이 정도로 적는 업무일지가 과연 필요한가에 대해서는 의문입니다. 시간단위 업무 내용기록은 프로그램에 남기는 ChangeLog랑은 얘기도 다르고요...
저같은 경우는 거의 다 'xxx 코딩' 이렇게만 적습니다만... ㅡ.ㅡ;;

목적이 감시라면 얘기가 다르겠지만 개발자들의 경우 업무 진행 파악을 위해서라면 솔직히 CVS log만 제대로 남겨도 어느 정도 목적을 만족하지 않을까 싶군요. 전 뭐든 컴터를 많이 이용하려는 편이라서요, 글씨도 무척 못 쓰고...ㅡ.ㅡ;;

노루가 사냥꾼의 손에서 벗어나는 것 같이, 새가 그물치는 자의 손에서 벗어나는 것 같이 스스로 구원하라 -잠언 6:5

ajaajaza의 이미지

아침마다 일일업무보고 시작전에 스트레스를 엄청받습니다.
별로 영양가도 없어보이고 놀고있는 팀장한테 우리 대충 이런일 한다....라는 보고하는거밖에 안되는듯 싶기도하고
간단하게나마 준비하면서 잡아먹는 시간도 불쾌하고
백해무익한 일 같네요.