Good Luck
752
2019-02-17 13:31:40
11
997

빡빡한 개발 일정 관련해서 해결방법이 있는가에 대한 얘기를 듣고 싶습니다..


제가 경험했던 이론과 현실의 차이입니다.

빡빡한 일정의 근본원인으로 '무엇'을 먼저 생각해보자면

저의 짧은 경험상으로는 '요구사항'이라고 생각합니다.


그렇다면 '누가' 이 문제를 발생시키는 근본적인 원인을 제공하는 것인가를 생각해보자면

지속적으로 요구사항을 '수정/추가'하는 '고객'인가,

그 요구사항을 '수렴'하는 '수행사' 인가 하는 것입니다.


사실 둘 다 어쩔 수 없는 상황이라는 것은 마찬가지입니다.

'고객'은 그 회사의 'CEO'가 하라는 대로 하는 것이 분명하고,

'수행사'의 PM은 그 요구사항들을 최대한 '수렴'해야만 하는 입장이고,

개발자 중에 어느 누구라도 저 위치에 있었다면 지금의 그들과 똑같이 생각하고 행동했을 거라고 생각합니다. 정도의 차이는 있겠지만요.


그럼 이 문제는 '고객'도 '수행사'도 해결할 수 있는 문제가 아닌 것 같습니다.

그렇다면 '개발자' 선에서 그걸 거부함으로써 해결할 수 있을까요?

그렇다면 밥벌이가 끊길까요? 영원히 이 바닥에서 활동할 수 없을수도 있을까요?

암묵적인 블랙리스트에 당당히 이름을 올리면서?

실제로 '갑'사에 안 좋은 인식이 박히면, 그 사람은 '제외'시키는게 맞겠죠.


도대체 해결 방법이 있기는 할까요?

아무리 생각해봐도 이건...다른 분들의 생각이 궁금합니다.

0
0
  • 댓글 11

  • 독거소년
    2k
    2019-02-17 13:48:13

    저는 "혼자 다 못합니다. 사람뽑아주세요" 라고 노래를 부릅니다.

    0
  • 생존형개발자
    1k
    2019-02-17 14:01:17

    답은 아닙니다.

    강호에서 살아남기 위해서는 몇할 숨겨라.

    ----

    애시당초 PM 이든 고객이든 저 일정이 떨어졌을때 누군가는 '할 수도 있겠는데?' 이렇게 시작되죠.

    그런데, 팀이 저 일을 못할것이란게 너무너무 뻔하다면, 저 일정이 나올 일이 없어요.

    예를들면 초등학교 6학년 5명에게 누구의 도움도 없이 2달이내에 쇼핑몰 만들어라? -_-;


    그렇다면, 굴리고 굴리면 이번건은 어떻게 어떻게든 진행된다. 이게 핵심인데,

    개발자는 괜찮죠. 

    몇할 숨긴게 있다면.. '나'는 괜찮겠죠. 혹은 '팀' 이거나.


    이런 소설을.. 쿨럭..

    1
  • Good Luck
    752
    2019-02-17 14:07:54

    @생존형개발자

    다들 몇할 숨기며 진척보고하시죠..ㅎㅎ

    그런데 '할 수도 있겠는데?' 라는 게

    야근을 해서든, 철야를 해서든..이라고 당연하게 생각하는게 문제인 것 같습니다

    1
  • 나도아빠다
    2k
    2019-02-17 14:20:48 작성 2019-02-17 14:22:17 수정됨

    이미 정해진 짜디짠 고객사의 사업비와

    사업비중 몇프로를 남겨먹을지 고민하는 수행사의 이윤사이에

    개발자들은 그 이윤을 한푼이라도 더 늘려주기위해 갈려가는거지요


    프로젝트가 막장이 되간다면 전 수행사가 1차잘못이라고 봅니다.

    사업비는 처음부터 정해져있는거고, 

    이윤을 조금이라도 더 남기겠다고 맨먼스억지로 밀고 사람안뽑고 버티다가, 막판 3-4개월 남기고 지체보상금 터질거 같으면 그때서야 소방수로 사람 뽑는 수행사들이 제일 큰 문제 아닌가 싶어요.

    소방수로 누가 들어옵니까? 보통은 경력속인 신입이니 돈이 어지간히 궁한 아저씨들 뿐인데 마무리가 잘되는것도 웃긴일이지요.

    사업비를 처음부터 넉넉하게 잡거나, 수행사가 처음부터 이윤 전에 현실적인 맨먼스 계산을 하거나 둘중하나느누이루어져야 풀릴문제일텐데.. 전자보단 보통 후자때문에 일이 터지지요

    0
  • 초무쿤
    2k
    2019-02-17 14:29:11

    waterfall 형식의 개발방법론이 현실과 잘 맞지 않아서 대안으로 여러방법론이 나오는거겠지요.

    근데 뭘해도 waterfall보다는 나을듯 합니다. ;;;

    0
  • Good Luck
    752
    2019-02-17 14:41:15

    @나도아빠다

    정말 SI업계는 개발자들을 기업이윤 짜내는 부품으로만 생각하는 것 같습니다

    하회탈을 쓴 채 온갖 회유책과 강경책을 병행해가면서요

    그렇게 순해빠진 개발자들은 그 묘책에 갈려나가는 분들이 여럿 계시더라구요

    저를 포함한..?ㅎㅎ

    0
  • 초무쿤
    2k
    2019-02-17 14:45:32 작성 2019-02-17 14:46:40 수정됨

    @Good Luck

    개발자를 갈아서 만드는거죠...우리나라 SI(Sibal IT)는..ㄷㄷㄷ;;;

    1
  • 나도아빠다
    2k
    2019-02-17 14:51:13

    /초무쿤

    워터폴보다 낫다니요.. 엑자일(한국형에자일) 방법론 당해보시면 워터폴이 행복해집니다.


    개발에 테스트에 문서작업까지 한 스프린트에 몰아두고 한달이나 2-3주단위로 개발자갈아대는거보면 스프린트를 저렇게 해석하는구나..하고 창의성에 불알을 탁 하고치게됩니다.

    0
  • 초무쿤
    2k
    2019-02-17 14:59:13 작성 2019-02-17 15:09:56 수정됨

    @나도 아빠다.

    한국형 애자일 ㅎㅎ;

    그렇긴 하죠..SI 막장에 보급되면서 애자일이 토속화 되서 이상하게 변했더군요.ㅋㅋ

    SI쪽 애자일은 그냥 워터폴을 SPRINT로 2주에 한번씩 돌린다? 라는 이상한 ㄷㄷ; (K*미친..)

    근데..제대로 애자일 하는데 가보시면 문서,테스트 모두 자동화 되어있고 꽤 편합니다. 

    그 프로젝트는 PM이 개발자라서 그랬을수도 있지만요. 누가 하느냐에 따라 틀린거 같긴 하네요.



    0
  • 하두
    10k
    2019-02-17 21:22:30

    저 같으면,

    구축을 설계쪽으로 댕길거 같아요.

    공학관행이 설계중심으로

    잘 다져진 개발자란 전제하에요.

    0
  • Good Luck
    752
    2019-02-18 00:19:22

    @하두

    저도 비슷한 생각입니다

    어차피 요구사항이 지속적으로 변경될거라면, 베이스 설계만 다져놓고 설계문서니 뭐니 만드느라 시간 버리지 말고 구축부터 시작하는게 더 좋은 것 같습니다. 어차피 변경될 사항들이 많은데 일정이 그렇게 되어있으니 설계산출불, 프로그램명세서니 뭐니 어차피 나중에 죄다 수정해야 할 것들을 왜 미리 만들라고 난리들인지 모르겠어요.

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