치비
362
2019-01-14 14:51:52
11
1880

개발요청 기간보다 더 빨리 일을 처리했을때....


반갑습니다. 형님들

저는 화학공장에서 자채개발 ERP를 유지,보수 담당하는

뉴비 개발자 입니다.

회사에서 조건별 생산량 총합을 조회할 수 있는 기능을 넣어달라고 해서

2019년 1월 8일날 요청서 올려서 2019년 1월 8일 당일 다 끝냈습니다.

문제는 이사님께서 "이게 가능하나??" 라는 의문을 가지면서

개발기간 말해라길래 1월 19일까지 만들겠다고 했습니다.

저희 회사는 전산실이 따로 존재 하지않고 사방이 차장, 부장님들이

계신곳이라서... 다른거 하기도 좀 그런 상황이네요

빨리 끝나는대로 보고를 해야하는건지 아니면

기간동안 다른거 하다가 19일날 완료보고를 드려야 할지

okky 형님들의 경험을 듣고 싶습니다. 감사합니다.


0
0
  • 댓글 11

  • 8k
    2019-01-14 15:00:26

    분위기에 따라 틀린데

    내일모레정도 다 했다고 그냥 말합니다.


    1
  • 유니티
    15
    2019-01-14 15:02:52

    빨리 개발완료해서

    칭찬을 받을 수는 있겠지만

    결국 일잘하니깐 계속 부려먹을 수 있겠다 라는 마인드를 갖습니다.


    저라면 완벽하지 않은 예외처리가 있나 한번 더 확인해보고,

    기타 관련 자료, 소스코드 등을 보면서 깊이 있게 파악해보면서 시간을 보내다가

    이틀 전인 1월17일즈음 완료보고 올릴듯합니다.

    그러면 일을 엄청나게 잘해보이진않지만

    책임감있게 완료하는 사람으로 인식하게 되며, 기타 다른 업무가 주어져도 벌어놓은 시간동안 보았던 것들로 인해 업무가 수월해지니 1석2조일듯싶습니다.


    그리고 팁을 드리자면 

    1. 먼저 업무에 대한 제의를 하지않는다.(책임은 책임대로 지며 일이 많아집니다.)

    2. 개발기간은 넉넉히 잡는다.(차라리 남는게 낫습니다.)

    3. 눈치껏 일한다.(마냥 쉬는 모습말고, 공부라도하고있는게 낫습니다.)


    이정도면 직장생활은 무난하다고 생각됩니다.

    3
  • 크랩매니아
    28
    2019-01-14 15:11:37

    따로 뭘 할 수 있는 분위기도 아니라고 하시니 다른 일 없으면 보고 해도 될 것 같습니다.

    신입이라고 하시니 점수라도 딸 겸 일정보다 미리 보고하는 것도 나쁘지 않을 것 같네요.

    물론 속도보다는 정확도가 우선이니 마지막까지 테스트는 잘 해보시고요.


    근데 1월 19일이면 토요일인데... 토요일 출근하십니까? ㅎ

    1
  • March
    2k
    2019-01-14 15:18:56

    아뇨...테스트, 디버깅 하시면서 일정완료 시점에 보고 하세요.

    다했다고 했는데 생각지도 못한 버그, 에러 팡팡 터지면 불안해 합니다

    1
  • onimusha
    7k
    2019-01-14 15:21:19

    예상을 해보자면.. 이사님이 해달라는 기능이 분명히 그게 다가 아니였다고 말할 거 같네요;;

    2
  • 하두
    10k
    2019-01-14 15:45:09

    개발이 다 끝이 아닐수도 있어요.

    고객확인,사후문제 모니터링등

    며칠 더 지난후에 하심이

    1
  • 치비
    362
    2019-01-14 15:47:05

    역시 내공에서 우러나오는 주옥같은 답변이십니다!

    형님들 감사합니다 필씅~~!

    0
  • fender
    14k
    2019-01-14 15:53:08

    저 같으면 꼼꼼하게 테스트 했다는 전제하에 일찍 끝났다고 보고를 할 것 같습니다.

    제 경험상 개발 일정은 기본적으로 신뢰의 문제라서, 일단 저 개발자는 일정을 부풀리지도 않고 한 번 말한 일정은 왠만하면 잘 지킨다는 인식이 생기면, 정말 어려운 문제가 있어서 일정을 길게 잡거나 어쩌다 불가피하게 일정이 밀리더라도 별 문제없이 넘어가게 됩니다.

    반면에 개발자가 일정을 부풀린다는 인식이 생기면 무리하게 일정 단축을 종용하거나 고객과 협의를 한다던지 할 때 개발자가 예상한 일정을 무시한다거나 하는 일이 생겨 피곤해지기 마련입니다.

    물론 그런 신뢰 관계를 쌓을 가치가 없는 관리자도 많다는 건 잘 알고 있습니다만, 그런 경우는 일정을 따지는 것 이전에 하루라도 빨리 더 나은 회사로 이직하는게 답이라고 생각합니다.

    0
  • ㅇㅈㅇ
    3k
    2019-01-14 15:55:53 작성 2019-01-14 15:57:49 수정됨

    반복된 테스트로 에러율 0%에 도전해보시죠.

    그리고 저는 시간이 남는 경우는 없는데 그 이유가..

    기능의 목적을 생각하다보면 이러면 더 좋을 것같고 

    이러면 더 유연할거같고 이러면 나중에 쓸일이 있을것같고 

    그런게 계속 떠올라서 추가하다보면 일정 금방 다씁니다.

    같은 기능으로 하루를 주든 일주일을 주든 일정은 다써요.

    퀄리티만 달라지고..

    0
  • zip6656
    1k
    2019-01-14 16:28:57

    저 같으면 문제가 없다는 가정하에 정해진 일정에 맞추어 보고 할거 같네요.

    10년 넘게 SI바닥 굴러본 결과 빨리 개발했다고 결국 남는건 옆동료 일만 더 받고 PM은 만만하면 나한테 일던지고..

    일잘하는 놈으로 평가받기 보다 일많이하는 놈으로 평가받죠

    0
  • urbug2
    1k
    2019-01-14 17:22:14 작성 2019-01-14 17:29:10 수정됨

    투입된지 얼마 안된 시점이라면,
    완료 되었다고 보고 하세요.
    왜냐하면, 처음 투입되고서는 자신의 퍼포먼스를 보여 줄 필요가 있습니다.

    그리고, 개발완료라는 것이.
    본인의 입장에서 완료이지, 다른 사람 입장에서는 추가적인 검증이 필요한 상황일 수도 있어요.

    추가적인 버퍼 시간은 프로젝트 진행되면서, 스스로 잡는 요령이 생기실꺼에요.



    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.