칸나
1k
2018-11-19 13:51:57 작성 2018-11-19 13:52:31 수정됨
20
6000

흔한 개발자가 짱나는 경우




1. 스펙에 요구사항을 애매하게 써놓음


여기서 선택을 해야됨


2-1. 애매한거를 확실히 하기 위해 대화를 시도해서 모든 엣지케이스를 완벽하게 잡는다.

2-2. 대화하기 귀찮아서 그냥 써놓은 고대로~ 만 구현한다.

2-3. 대화하기 귀찮아서 내 임의로 부족한 엣지케이스에 대한 경우에 이렇게 처리한다고 단정후 작업 이어서함



2-1. 대화를 한다

장점: 대화가 빨리 끝나고 요구사항 확립이 빨리되면 가장 이상적임.

단점: 하지만 현실의 대부분이 짧게는 하루. 길게는 몇일. 심지어 까먹기도 해서. 스프린트 후반에 야근 이나 주말근무로 빡세게 일해야댐.



2-2. 써놓은 고대로~ 만든다.

장점: 대화가 필요없으니 빠르게 구현가능. 고로 야근 안함

단점: PM의 남탄 시전. 왜 이렇게 만들었냐? 난 써놓은 그대로 만든거다. 유연하게 니가 알아서 만들거나(2-3) 나한테 물어봤어야 되는거 아니냐(2-1) 시전. 무한반복. 당연히 일정은 늦춰짐.



2-3. 모자른 케이스는 내 맘대로 만든다

장점: 대화가 필요없으니 빠르게 구현가능. 고로 야근 안함. 단 내가 요구사항을 내 짱구 굴려서 만드니 골이 좀 더 아픔.

단점: 모 아니면 도. 테스팅 돌려서 PM이 맘에 들면 모. 이거 누가 이렇게 만들었냐고 싸우면 빽도. 현실은 대부분 빽도. 뺵도 걸리면 일정은 늦춰짐.



결론은 싸우거나 내가 야근 하거나 인데

쪼렙때는 대화를 했지만 지금은 당연히 싸우는걸 택함



오늘도 싸우다가 빡쳐서 글 하나 남기네요


전 CTO가 그립네요. 왠만하면 모든 엣지케이스가 스펙에 적혀있는 유일했던 사람





12
3
  • 댓글 20

  • hisuica
    3k
    2018-11-19 14:05:48

    가불기... 

    2-1과 2-3을 적절하게 섞어서 쓰는 중이긴 한데...

    그래도 언제나 딴소리는 나옴... 

  • S나무늘보2
    94
    2018-11-19 14:37:15
    왜냐면 스펙 쓰는 사람이나 고갱님이 자기가 뭘 원하는지 모름
  • baltasar
    7k
    2018-11-19 14:49:52 작성 2018-11-19 14:50:28 수정됨

    그런 사람을 PM으로 데려다 놓은 걸보니 그 회사 S/W사업부도 오래 못 가겠네요.

    빠른 탈출 준비가 필요해 보입니다.

    그냥 하는 말이 아니라 진지하게 하는 말입니다.

  • 마쓰시타
    544
    2018-11-19 15:07:26

    2-2 에서 남탓하는 PM들의 뇌구조가 진심으로 궁금함

  • 마쓰시타
    544
    2018-11-19 15:09:08

    비슷한 도메인에서 짬좀차면, PM이나 클라이언트보다 더 잘알고, 개떡같이 얘기해도 찰떡같이 알아서 해주는 경지가 가능하지만


    그것을 신입이나 혹은 새로운 개척 도메인에서도 반복할때는 


    결국 정치싸움이 되버림

  • freestyle
    3k
    2018-11-19 15:14:25

    정말 현장에서 "흔한" 일들이죠... 그래서 지겹게 나오는 표현  "저 사람은 업무에 빠삭하다"...

    빠삭 빠삭... 😕 

  • 승천하는_흑염룡
    1k
    2018-11-19 15:32:06
    사용자는 자기가 뭘 원하는지 모른다

    띵언이네...
  • 김애용
    255
    2018-11-19 16:28:36

    무한루프에 빠진그림 보는순간 웃었네요 ㅎㅎㅎ

  • 선즈반
    262
    2018-11-19 18:22:14

    ㅋㅋㅋ 정말 많이 당했죠.. 그래서 그 다음부턴 메일로 무조건 증거를 남깁니다.

    회의를 하거나 구두로 지시받아도 메일로 다시한번 확인하는 습관이 자연스레 들었죠.

  • 메로메로
    304
    2018-11-19 19:47:34

    매우 공감되는 상황이네요. 저런 사람 본 적 있습니다.

  • mirheeoj
    11k
    2018-11-20 04:09:14

    중요한 건 문제가 반복적으로 발생하는 경우 프로젝트에 참여한 모든 인력이 이를 개선할 노력을 해야 된다는 겁니다. 애매한 부분, 싸워야 해결되는 부분이 없도록 말이죠 

  • 코딩모태요
    464
    2018-11-20 11:38:39

    매우 공감됩니다.

    저래서 여러번 뒤집었거든요. 핳핳

  • jja
    2k
    2018-11-21 00:17:20

    서로 답답할듯.. pm이 답답할땐~현업미팅을 같이 가봐요~

  • 작은안부
    545
    2018-11-21 13:46:47
    그냥 무한루프네요 ㅋㅋ
  • static
    537
    2018-11-22 22:25:38
    메일로 남겨도 메일대로 처리해주면 손바닥 뒤집듯이 바꾸는 사람도 있더군요, 까라면 까야지 말이 많다면서 말이죠 하하..
  • 아야로
    1k
    2018-11-23 08:51:36

    ㅎㅎㅎ너무 공감돼서 아침부터 빵 터졌네요

    글자 하나하나에 한이 서려있어요 왜 ㅋㅋ

  • 모카초코
    284
    2018-11-23 18:23:06

    천퍼만퍼 공감하네요

    추가로 왜 이렇게 해놨냐

    저번에 이렇게 하랬는데요

    저렇게 바꿔라

    저렇게 바꿈

    무한반복

    삽질 백만번에 말도 안되는 일정 플러스 야근 주말출근 당첨

  • 제타건담
    6k
    2018-11-24 13:54:06 작성 2018-11-24 13:55:46 수정됨

    저는 2-1이요..

    물론 단점의 의미도 알고는 있습니다..야근이나 일정 길어지는거 누가 좋아하겠습니까?

    하지만 그보다 더 싫은건 내가 만든걸 엎고 다시 새로 만드는거에요..

    두번 만들어야 하는 상황이 오게 되면..

    첫번째 만들때 보낸 시간들은 정말 아무 의미가 없어져요..

    프로젝트를 할때 그런 시간이 0이 되기는 정말 어렵지만..

    최소한도로 줄여야죠..그래야 개인이 일을 할때도 일에 대한 의미가 있어집니다..

    그런 상황이 생기면 그 시간에 난 머한거지? 차라리 칼퇴하고 하고싶은걸 할껄..하는 생각에 일이 더 안됩니다..


    그리고 꼬치꼬치 물어보면 첨에 그거 짜증내는 사람도 많이 있습니다..

    그러나 그것도 첨에 어느정도지 물어물어 하다보면 위에서 말한대로 프로그래머 본인이 점점 업무에 빠삭한 사람이 되고.

    그러면 물어보고 하는 것에 대해 짜증내거나 싫어하는 케이스가 줄어듭니다..

    오히려 내가 하는 말에 더 경청하죠..왜냐면 자신이 놓친 부분도 분명 있기 때문에..

    그걸 챙겨주게 되면 좋아하거든요..현업이나 설계자도 만능은 아니거든요..

    그리고 내가 물어볼때 마냥 몰라라 할 수는 없습니다..

    그런거에 대답 안해주거나 못해줄경우 그 책임은 그 사람이 져야 하거든요..

    유연나게 만들라는 말을 한다면 혼꾸녕(?)을 내주세요..지금 장난하냐고..

    설계도가 유연하게..라는 두루뭉실한 표현은 있을수 없습니다..

    물론 기존의 규칙이 있어서 그걸 사용할 수는 있겠죠..그러나 그건 기존의 규칙이 있다는 전제하에 움직인거지..규칙조차 없는 상태에서 걍 니가 알아서 해..이따위로 얘기하면 똑바로 정의해서 갖고 오라고 분명하게 의사 전달을 해주세요..

    그래야 나중에 본인이 덤탱이(?) 쓰지 않습니다.. 

    그래서 이런저런 이유로 저는 제가 설계역할을 하는 경우면 현업과..개발자인 경우 설계자와 치열하게(?) 미팅합니다..


    그리고 미팅할때는 디테일하게 얘기해야 합니다..

    전체적인 그림을 그리고 세부적인 것을 얘기할때 자기가 만드는 화면 한본에만 포커스를 맞추면 안됩니다..

    예를 들어 무언가 등록하는 화면 하나를 만들때 그거 하나에만 포커스를 맞추지 마고 전체적인 과정을 보면서 이렇게 갈 경우 다른 과정에서 문제가 생기는 부분은 없는지..

    그래서 전 미팅후에 노트에 정리하는 시간도 조금 길게 가지는 편입니다..그게 정리되어야 프로그래밍으 할 수 있는지라..

    머리속에서 생각 정리하고 그걸 프로그래밍으로 옮기시지 마시고..

    한번 노트에 적어보세요..적어보다 보면 어..막히는 부분이 있네 하고..다시 미팅해야 할수도 있습니다..그렇다해도 미팅 꼭 하셔서 정리하세요..

    그래야 일을 두번 안합니다..

    그리고 회의를 하면 회의 당사자간에 회의에 대한 내용을 메일로 보내주세요..그거 귀찮다고 안하시는 분들도 많이 있는데..

    10분 정도 투자해서 보험들어 놓는겁니다..나중에 그게 다 근거자료가 되거든요..

    물론 그게 자신에게 족쇄가 될 수도 있긴 하죠..그러나 그렇게 해야 업무가 서로간에 정리가 되는겁니다..

  • 아스키
    10k
    2018-11-26 12:55:55 작성 2018-11-26 12:56:29 수정됨

    @ 제트건담님..캬뮤와 아무로는 잘 지내고 있나요?..ㅋㅋㅋ

  • urbug2
    1k
    2018-11-26 13:33:20

    ㅋㅋㅋㅋㅋ

    정말 많이 공감되네요.

    제 경험에 의하면 엔티티만 충분히 정규화되고 식별관계일때는 명백하게 식별관계로 표현 되있기만 해도. 이런 문제가 거의 없더라구요.( 완전히 없는 것은 아니고)

    그런데 문제는 저런 사람이 그린 테이블은 대부분 문제가 많다는 점입니다.


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