새 직장에서 일 시작한지 2개월이 좀 안된, 경력 많은 Sr. SW엔지니어 입니다. 현 팀에 메니저는 구인 중이며 software architect 가 임시로 매니징 합니다. 체계상으로는 현제 우리팀 메니저는 디렉터이고, 저는 전 직장에서 일한 경험이 있어 이 director를 잘 아는 편이죠.

다음글을 팀의 Slack channel 에 올렸는데, 내일까지 응답이 없으면…. 팀의 디렉터와 우리쪽 비지니스 디렉토가 함께있는 채널에 똑같이 물어 보는 척하고, 올릴까 말까 고민중입니다. XXX 는 큰 customer로 몇달 후에 customer가 될 회사입니다.
고민의 이유는: 이 architect가 어떤 이유에서 건 이 Jira를 내일 release 해야한다고, 제게 direct message를 보내 거짓말을 했다 생각하기 때문입니다. 그래서 전 팀 채널에 아래 글을 올렸구요. 전 거짓말로 사람을 메니징하는것을 제일 싫어 합니다.

“Team. would you please help me understand the schedule / release management?
The “Jira-A” was not even within our attention until the stand-up this morning, and we just assigned it as a regular Jira. Then, suddenly I heard it needs to be released tomorrow as a hotfix. The “Jira-A” is for the XXX. How can it be suddenly a hotfix for tomorrow?
If someone can explain it, it will be very helpful to understand the schedule / release management here.”

뭔 소린지..

그렇게 하는건 좀 이상하네요. 어떤 assumption을 가지고 머리 굴리며 얘기를 쓰니까, 뭔가 불만이 있는 티가 팍팍납니다. 그냥 그 ticket에 주어진 priority에 의문이 있으면 그걸 확인하면 되죠. standup 때 팀원들이 그런 priority에 대해 agree하는 분위기였나요?

누가 file한 jira인가요? 원래 원글님의 영역인가요? 지금까지 원글님이 neglect했다는 식으로 되서 불편한건가요? 그냥 갑자기 내일까지 하라고 해서 급해서 그런건가요? 평소에 sprint planning은 하나요? 아니면 적어도 backlog라도 review하나요? 즉, 평소에 task list와 priority는 누가 어떻게 정하나요?

가장 현명한 것은, 군소리 말고 해내는겁니다.

한국말인지 영어인지 뭔 말을 하는건지 모르겠네 답답하다 진짜 ㅋㅋ

이래서 어설프게 경력만 늘어난 늙다리들이 퇴출 1순위.
불만은 많고 숨기지도 못하고 그렇다고 일을 제대로 하지도 않아. 매니저가 필요하면 시키는거지 매니저도 회사의 일부분
걔가 널 왜 시키겠나??? 무슨 이유가 있겠지 그 이유가 ㅈ같아도 이유는 있고 그 일이 싫으면 니가 나가든지 매니저 하든지야

ㅋㅋ 미안하지만 내가 일 어설프게 한다는 소린 처음 듣는다. 언어와 정치력이 약하지만 일로는 흠잡히지 않으니 걱정마라

상황을 짧게 쓰려다보니 이해하기 어려운 글이 되었나 보군요
10시에 standup 에서 backlog에 있던 A를, 1주일 전에 시작한 이번 sprint에 넣으며 기존에 있던것을 먼저 하기로 하고 standup을 끝냈는데, 이게 다른팀 영역도 해야 하는것.
11시 반에 direct message로 다른팀 메니저가 오늘 이야기 해준다고 통화 하라는 연락. 내가 필요하면 내가 연락할텐데, 뭐 이런것 까지 자기가 연락해 오늘 통화를 하라는 이야기까지 하나…하고 약간 기분이 상하더군요

그래서 jira B를 먼저 하기로 해서, 그것하고 있다 jira A 는 아직 문제가 뭔지 생각도 안해 봤으니 다른팀 메니저와는 내일 오후나 모래 통화하도록 하겠다라고 메세지를 보냈죠

10분정도후 다시 direct message 를 보내 오면서, jira A를 내일 release할것이니 오늘 다른팀 메니저랑 통화해라.

이렇게 되어, 저는… 내일 hotfix로 release할거면 이분야를 아는 사람이 하는게 옳은 방법인듯하다 라는 문자를 보내고, 팀 메신저로 도대체 hotfix나 release 스케줄이 어떻게 관리되냐고 메세지를 보낸겁니다

어차피 제가 senior로 결정하고 풀어 갈 일을, 괜히 쓸대없는 이곳에 글을 올린듯 하네요. 조금 심심했었나 봅니다.
내일 본문의 글은 지우도록 하겠습니다

사이코아니냐. 결론도 없는 뭔 뚱딴지 같은 글을 올리나.

일처리도 이런 식으로 하고는 잘한다 생각하는 듯. 몸에 힘이 잔뜩 들어가 있는 표가 납니다. 힘 빼고 감정 푸세요.

다른팀과 관련있는 건가보네요.
그쪽에서 님의 모듈을 사용해야 해서 그런게 아닌가 싶네요.
그럼 님것이 먼저 올라가야, 자기들 것이 제대로 작동하는데 그쪽 스케줄을 미룰 수 없어서 윗선에서 뭔가
딜을 한게 아닌가 싶네요.
뭔가 오해를 하고 계신듯보이네요.

전략적으로 판단해야죠.

일정을 무리하게 바꾸는데 찍소리 안하고 시키는데로 해야할 만큼 님의 입지가 불안하다면 생존을 위해서 어쩔 수없이 그렇게 해야겠죠. 그렇지 않다면 적절한 방식으로 피드백을 줘서 문제를 바로 잡도록 노력하는 건 직업윤리상 권리이자 의무입니다.

그런데, 내용을 보니 피드백을 주는 방식이 매끄러워 보이지는 않네요. 다른 히스토리없이 일회성 사안이라면, 저같으면 면담을 해서 상황을 확인해 보겠습니다. 협상의 bottom line은 이번에는 처음이니까 요청을 수용하겠지만, 다음에는 본인이 원하는 절차를 따라줄 것을 요청하는 정도가 되겠네요. 물론, 다 아는 얘기 구차하게 할 것없이 바로 치받는게 직성이 풀리면 그렇게 해야죠. 대신 그런 캐릭터로 살아 남기 위해서는 남들이 시비걸지 못할만한 비장의 무기가 있어야 겠습니다.

역시… 모든 상황없이 인터넷에 글을 올리고 feedack을 기대한다는데는 무리가 있는 것을 알고 있음에도 글을 올린 제 잘 못인듯 하군요.
그래도 bomi님 글이 가장 fair했습니다. 심봉사님과 job님의 댓글도 감사드리구요.

monolithic application을 쪼개 micro application이라 나눈지 오래 되지 않아 team의 boudary를 터치하는때가 종종 있구요…
customer XXX는 현제 customer가 아니라 다른팀이 저희쪽 module에 의존 할일이 아직 없습니다. 그 쪽이 upstream이고 우리쪽이 downstream이기도 하구요.

사실…. 약간의 power game이 있기도 한듯 하죠. 제 코드를 github에 올려 pull request시 이 architect가 몇번 comment를 달았는데, 제가 고맙지만, 그런 식으로 coding이 되면 이런 저런 문제가 있기에 이런 코드가 나온것이다라고 다시 feedback을 단 적이 있거든요. 전 특별히 잘 못 된게 아니면 comment에 달린것 다 들어 주는 편입니다.

그리고 미팅이란 것이 내가 그 문제를 어느 정도 알고 들어 가야 도움도 받고 그러는 거지, 아무 생각 없이 들어가 상대편 메니저가 어쩌고 저쩌고 하면 무슨 소린지 모르는 법입니다. 그래서 오늘 하지 말고 내일이나 모레쯤 하는게 더 적절 하다고 한것이지요.

그리고… 사람 마다 생각의 차이겠지만, 내일 release한다고 했을때, 다른 사람에게 주는게 더 적절하다라고 하는 것은 “하라고 했는데 말을 안듯는다”라는게 아닙니다. 회사에 들어 온지 2달이 안된 사람에게 다른 팀의 영역과도 겹치는 문제를 반나절에 끝내고 production release를 할수 있겠냐는 문제 입니다. 이것은 회사와 팀의 제대로된 인원과 시간 관리의 문제이죠. 갑자기 내일 release를 한다하면 이런것들은 더 익숙한 사람에게 돌리는게 management상 먼저 생각해야하고, developer도 기분 나빠하지 말고 팀을 위해 내 주어야 한다고 봅니다.

어쨋든 제가 별로 유익하지 않은 글을 올린듯하네요.

잘 이해 안가는 상황이네요. 그래서 transparency라는게 중요한건데… 이게 부족하면 신뢰를 가지기 힘들고 잘 돌아갈 수가 없죠. 내가 일해온 분위기와는 너무 다르군요.