현재 버전

개발 직군으로 가신건가요?
우선 개발자로서 소양이 부족한 부분에서는 답 없습니다. 별도의 노력하셔야겠죠.

다만, 거래처와 커뮤니케이션하는 부분이 개발자끼리의 커뮤니케이션인가요? 아니면 개발자와 일반인(거래처)의 커뮤니케이션인가요? 일머리가 없다는 이야기를 보니 후자인 경우도 있을 수 있다는 생각이드네요. 이런 케이스라면 본인의 문제가 아니라 업무 환경이 문제일 수도 있습니다.

일단 글 내용만 봐서는 정확한 파악은 안되지만

1. 거래처에서 요구한 내용이 무엇인지 분명하게 파악하기

-> 주된 커뮤니케이션을 어떻게 하시는지 모르겠지만, 보통 중요한 내용은 메일로 먼저 상세하게 적어 공유한 상태에서 전화까지 하여 메일 내용을 함께 리뷰하는게 보통입니다. 거래처에서 요청하는 사항이 이런 프로세스를 거치지 않는다면 그건 거래처의 문제입니다. 그리고 개발자가 쓰는 용어와 일반인들이 쓰는 용어에 대한 의미의 갭이 있을 수 있습니다. 업무 진행하기전에 메일에 업무 관련자들 모두 포워딩 시켜서 내용 확실하게 정리하고나서 업무 범위가 명확해지면 그때 업무가 진행되어야합니다.


2. 중간에 급한 일이 들어왔을 경우에 우선순위 정해서 처리하기

-> 급한 일이 생기는건 어느 회사에서나 있을 수 있지만, 급한 일이 생겼을 때에 대한 대처도 중요합니다. A라는 일을 진행하고 있는 도중에 갑자기 먼저 급히 처리해야하는 B라는 일이 들어오면,
B의 업무공수 파악 - B를 먼저 처리하게 됨으로 인해 A가 딜레이 되는 상황을 상사에게 보고
이 부분이 먼저 선행되어야합니다. 그리고 이런 급한 처리의 건이 시도때도 없이 계속 들어오면 그것 역시 정상적인 업무 환경이 아닙니다.


지금 적힌 내용이 전부 사실이라면 상사들이 업무 조율을 제대로 못하고 있는 상황으로 보입니다. 처음에도 언급했지만 개발자로서 부족한 부분은 본인이 개인적으로 공부해서 채워넣으시고, 업무로서 부족한 부분은 사수에게 다 물어보시길 바랍니다. 그거야말로 사수가 케어해야할 몫입니다. 거래처 개발자랑 기술적으로 커뮤니케이션을 하는 상황이 아니라면, 솔직히 개발자에게 왜 거래처랑 커뮤니케이션을 시키고 있는지도 의문이네요.

업무가 본인에게 과하다면 사수나 팀장에게 면담 신청하셔서 지금의 고충을 다 털어놓으시길 바랍니다. 퇴사를 할지 말지 결정하는건 그때 회사의 태도에 따라 결정하셔도 늦지 않습니다.


수정 이력

2021-04-05 23:57:13 에 아래 내용에서 변경 됨 #5

개발 직군으로 가신건가요?
우선 개발자로서 소양이 부족한 부분에서는 답 없습니다. 별도의 노력하셔야겠죠.

다만, 거래처와 커뮤니케이션하는 부분이 개발자끼리의 커뮤니케이션인가요? 아니면 개발자와 일반인(거래처)의 커뮤니케이션인가요? 일머리가 없다는 이야기를 보니 후자인 경우도 있을 수 있다는 생각이드네요. 이런 케이스라면 본인의 문제가 아니라 업무 환경이 문제일 수도 있습니다.

일단 글 내용만 봐서는 정확한 파악은 안되지만

1. 거래처에서 요구한 내용이 무엇인지 분명하게 파악하기

-> 주된 커뮤니케이션을 어떻게 하시는지 모르겠지만, 보통 중요한 내용은 메일로 먼저 상세하게 적어 공유한 상태에서 전화까지 하여 메일 내용을 함께 리뷰하는게 보통입니다. 거래처에서 요청하는 사항이 이런 프로세스를 거치지 않는다면 그건 거래처의 문제입니다. 그리고 개발자가 쓰는 용어와 일반인들이 쓰는 용어에 대한 의미의 갭이 있을 수 있습니다. 업무 진행하기전에 메일에 업무 관련자들 모두 포워딩 시켜서 내용 확실하게 정리하고나서 업무 범위가 명확해지면 그때 업무가 진행되어야합니다.


2. 중간에 급한 일이 들어왔을 경우에 우선순위 정해서 처리하기

-> 급한 일이 생기는건 어느 회사에서나 있을 수 있지만, 급한 일이 생겼을 때에 대한 대처도 중요합니다. A라는 일을 진행하고 있는 도중에 갑자기 먼저 급히 처리해야하는 B라는 일이 들어오면,
B의 업무공수 파악 - B를 먼저 처리하게 됨으로 인해 A가 딜레이 되는 상황을 상사에게 보고
이 부분이 먼저 선행되어야합니다. 그리고 이런 급한 처리의 건이 시도때도 없이 계속 들어오면 그것 역시 정상적인 업무 환경이 아닙니다.


지금 적힌 내용이 전부 사실이라면 상사들이 업무 조율을 제대로 못하고 있는 상황으로 보입니다. 처음에도 언급했지만 개발자로서 부족한 부분은 본인이 개인적으로 공부해서 채워넣으시고, 업무로서 부족한 부분은 사수에게 다 물어보시길 바랍니다. 그거야말로 사수가 케어해야할 몫입니다. 거래처 개발자랑 기술적으로 커뮤니케이션을 하는 상황이 아니라면, 솔직히 개발자에게 왜 거래처랑 커뮤니케이션을 시키고 있는지도 의문이 가네요.

업무가 본인에게 과하다면 사수나 팀장에게 면담 신청하셔서 지금의 고충을 다 털어놓으시길 바랍니다. 퇴사를 할지 말지 결정하는건 그때 회사의 태도에 따라 결정하셔도 늦지 않습니다.

2021-04-05 23:56:26 에 아래 내용에서 변경 됨 #4

개발 직군으로 가신건가요?
우선 개발자로서 소양이 부족한 부분에서는 답 없습니다. 별도의 노력하셔야겠죠.

다만, 거래처와 커뮤니케이션하는 부분이 개발자끼리의 커뮤니케이션인가요? 아니면 개발자와 일반인(거래처)의 커뮤니케이션인가요? 일머리가 없다는 이야기를 보니 후자인 경우도 있을 수 있다는 생각이드네요. 이런 케이스라면 본인의 문제가 아니라 업무 환경이 문제일 수도 있습니다.

일단 글 내용만 봐서는 정확한 파악은 안되지만

1. 거래처에서 요구한 내용이 무엇인지 분명하게 파악하기

-> 주된 커뮤니케이션을 어떻게 하시는지 모르겠지만, 보통 중요한 내용은 메일로 먼저 상세하게 적어 공유한 상태에서 전화까지 하여 메일 내용을 함께 리뷰하는게 보통입니다. 거래처에서 요청하는 사항이 이런 프로세스를 거치지 않는다면 그건 거래처의 문제입니다. 그리고 개발자가 쓰는 용어와 일반인들이 쓰는 용어에 대한 의미의 갭이 있을 수 있습니다. 업무 진행하기전에 메일에 업무 관련자들 모두 포워딩 시켜서 내용 확실하게 정리하고나서 업무 범위가 명확해지면 그때 업무가 진행되어야합니다.


2. 중간에 급한 일이 들어왔을 경우에 우선순위 정해서 처리하기

-> 급한 일이 생기는건 어느 회사에서나 있을 수 있지만, 급한 일이 생겼을 때에 대한 대처도 중요합니다. A라는 일을 진행하고 있는 도중에 갑자기 먼저 급히 처리해야하는 B라는 일이 들어오면,
B의 업무공수 파악 - B를 먼저 처리하게 됨으로 인해 A가 딜레이 되는 상황을 상사에게 보고
이 부분이 먼저 선행되어야합니다. 그리고 이런 급한 처리의 건이 시도때도 없이 계속 들어오면 그것 역시 정상적인 업무 환경이 아닙니다.


지금 적힌 내용이 전부 사실이라면 상사들이 업무 조율을 제대로 못하고 있는 상황으로 보입니다. 처음에도 언급했지만 개발자로서 부족한 부분은 본인이 개인적으로 공부해서 채워넣으시고, 업무로서 부족한 부분은 사수에게 다 물어보시길 바랍니다. 그거야말로 사수가 케어해야할 몫입니다.

업무가 본인에게 과하다면 사수나 팀장에게 면담 신청하셔서 지금의 고충을 다 털어놓으시길 바랍니다. 퇴사를 할지 말지 결정하는건 그때 회사의 태도에 따라 결정하셔도 늦지 않습니다.

2021-04-05 23:52:47 에 아래 내용에서 변경 됨 #3

개발 직군으로 가신건가요?
우선 개발자로서 소양이 부족한 부분에서는 답 없습니다. 별도의 노력하셔야겠죠.

다만, 거래처와 커뮤니케이션하는 부분이 개발자끼리의 커뮤니케이션인가요? 아니면 개발자와 일반인(거래처)의 커뮤니케이션인가요? 일머리가 없다는 이야기를 보니 후자인 경우도 있을 수 있다는 생각이드네요. 이런 케이스라면 본인의 문제가 아니라 업무 환경이 문제일 수도 있습니다.

일단 글 내용만 봐서는 정확한 파악은 안되지만

1. 거래처에서 요구한 내용이 무엇인지 분명하게 파악하기
-> 주된 커뮤니케이션을 어떻게 하시는지 모르겠지만, 보통 중요한 내용은 메일로 먼저 상세하게 적어 공유한 상태에서 전화까지 하여 메일 내용을 함께 리뷰하는게 보통입니다. 거래처에서 요청하는 사항이 이런 프로세스를 거치지 않는다면 그건 거래처의 문제입니다. 업무 진행하기전에 메일에 업무 관련자들 모두 포워딩 시켜서 질의사항 부분은 확실하게 정리하고나서 업무 범위가 명확해지면 그때 업무가 진행되어야합니다.


2. 중간에 급한 일이 들어왔을 경우에 우선순위 정해서 처리하기
-> 급한 일이 생기는건 어느 회사에서나 있을 수 있지만, 급한 일이 생겼을 때에 대한 대처도 중요합니다. A라는 일을 진행하고 있는 도중에 갑자기 먼저 급히 처리해야하는 B라는 일이 들어오면,
B의 업무공수 파악 - B를 먼저 처리하게 됨으로 인해 A가 딜레이 되는 상황을 상사에게 보고
이 부분이 먼저 선행되어야합니다. 그리고 이런 급한 처리의 건이 시도때도 없이 계속 들어오면 그것 역시 정상적인 업무 환경이 아닙니다.


지금 적힌 내용이 전부 사실이라면 상사들이 업무 조율을 제대로 못하고 있는 상황으로 보입니다. 처음에도 언급했지만 개발자로서 부족한 부분은 본인이 개인적으로 공부해서 채워넣으시고, 업무로서 부족한 부분은 사수에게 다 물어보시길 바랍니다. 업무가 본인에게 과하다면 사수나 팀장에게 면담 신청하셔서 지금의 고충을 다 털어놓으시길 바랍니다. 퇴사를 할지 말지 결정하는건 그때 회사의 태도에 따라 결정하셔도 늦지 않습니다.

2021-04-05 23:50:39 에 아래 내용에서 변경 됨 #2

개발 직군으로 가신건가요? 개발자로서 소양이 부족한 부분에서는 답 없습니다. 별도의 노력하셔야겠죠.

거래처와 커뮤니케이션하는 부분이 개발자끼리의 커뮤니케이션인가요? 아니면 개발자와 일반인(거래처)의 커뮤니케이션인가요? 일머리가 없다는 이야기를 보니 후자인 경우도 있을 수 있다는 생각이드네요. 이런 케이스라면 본인의 문제가 아니라 업무 환경이 문제일 수도 있습니다.

일단 글 내용만 봐서는 정확한 파악은 안되지만

1. 거래처에서 요구한 내용이 무엇인지 분명하게 파악하기
-> 주된 커뮤니케이션을 어떻게 하시는지 모르겠지만, 보통 중요한 내용은 메일로 먼저 상세하게 적어 공유한 상태에서 전화까지 하여 메일 내용을 함께 리뷰하는게 보통입니다. 거래처에서 요청하는 사항이 이런 프로세스를 거치지 않는다면 그건 거래처의 문제입니다. 업무 진행하기전에 메일에 업무 관련자들 모두 포워딩 시켜서 질의사항 부분은 확실하게 정리하고나서 업무 범위가 명확해지면 그때 업무가 진행되어야합니다.


2. 중간에 급한 일이 들어왔을 경우에 우선순위 정해서 처리하기
-> 급한 일이 생기는건 어느 회사에서나 있을 수 있지만, 급한 일이 생겼을 때에 대한 대처도 중요합니다. A라는 일을 진행하고 있는 도중에 갑자기 먼저 급히 처리해야하는 B라는 일이 들어오면,
B의 업무공수 파악 - B를 먼저 처리하게 됨으로 인해 A가 딜레이 되는 상황을 상사에게 보고
이 부분이 먼저 선행되어야합니다. 그리고 이런 급한 처리의 건이 시도때도 없이 계속 들어오면 그것 역시 정상적인 업무 환경이 아닙니다.


지금 적힌 내용이 전부 사실이라면 상사들이 업무 조율을 제대로 못하고 있는 상황으로 보입니다. 처음에도 언급했지만 개발자로서 부족한 부분은 본인이 개인적으로 공부해서 채워넣으시고, 업무로서 부족한 부분은 사수에게 다 물어보시길 바랍니다. 업무가 본인에게 과하다면 사수나 팀장에게 면담 신청하셔서 지금의 고충을 다 털어놓으시길 바랍니다. 퇴사를 할지 말지 결정하는건 그때 회사의 태도에 따라 결정하셔도 늦지 않습니다.

2021-04-05 23:50:19 에 아래 내용에서 변경 됨 #1

개발 직군으로 가신건가요? 개발자로서 소양이 부족한 부분에서는 답 없습니다. 별도의 노력하셔야겠죠.

거래처와 커뮤니케이션하는 부분이 개발자끼리의 커뮤니케이션인가요? 아니면 개발자와 일반인(거래처)의 커뮤니케이션인가요? 일머리가 없다는 이야기를 보니 후자인 경우도 있을 수 있다는 생각이드네요. 이런 케이스라면 본인의 문제가 아니라 업무환경이 문제일 수도 있습니다.

일단 글 내용만 봐서는 정확한 파악은 안되지만

1. 거래처에서 요구한 내용이 무엇인지 분명하게 파악하기
-> 주된 커뮤니케이션을 어떻게 하시는지 모르겠지만, 보통 중요한 내용은 메일로 먼저 상세하게 적어 공유한 상태에서 전화까지 하여 메일 내용을 함께 리뷰하는게 보통입니다. 거래처에서 요청하는 사항이 이런 프로세스를 거치지 않는다면 그건 거래처의 문제입니다. 업무 진행하기전에 메일에 업무 관련자들 모두 포워딩 시켜서 질의사항 부분은 확실하게 정리하고나서 업무 범위가 명확해지면 그때 업무가 진행되어야합니다.


2. 중간에 급한 일이 들어왔을 경우에 우선순위 정해서 처리하기
-> 급한 일이 생기는건 어느 회사에서나 있을 수 있지만, 급한 일이 생겼을 때에 대한 대처도 중요합니다. A라는 일을 진행하고 있는 도중에 갑자기 먼저 급히 처리해야하는 B라는 일이 들어오면,
B의 업무공수 파악 - B를 먼저 처리하게 됨으로 인해 A가 딜레이 되는 상황을 상사에게 보고
이 부분이 먼저 선행되어야합니다. 그리고 이런 급한 처리의 건이 시도때도 없이 계속 들어오면 그것 역시 정상적인 업무 환경이 아닙니다.


지금 적힌 내용이 전부 사실이라면 상사들이 업무 조율을 제대로 못하고 있는 상황으로 보입니다. 처음에도 말했지만 개발자로서 부족한 부분은 본인이 개인적으로 공부해서 채워넣으시고, 업무로서 부족한 부분은 사수에게 다 물어보시길 바랍니다. 업무가 본인에게 과하다면 사수나 팀장에게 면담 신청하셔서 지금의 고충을 다 털어놓으시길 바랍니다. 퇴사를 할지 말지 결정하는건 그때 회사의 태도에 따라 결정하셔도 늦지 않습니다.