항상 내가하는 일을 방해하지만 실제로 이해하지 못하는 관리자와 어떻게 대처해야합니까?


23

우리 모두는 영업에서 왔거나 10 년 이상 전에 코드를 살펴본 관리자가 있지만 코드 작성 방법을 알고 있다고 생각합니다.

그의 개입에 감사한다는 인상을 주지만 가능한 한 짧게 유지하여 작업을 계속할 수 있습니까?

아니면 현대 코딩 기술과 실습을 교육하기 위해 관리자와 더 많은 관계를 맺어야합니까? 결국,이를 이해하는 관리자는 프로젝트와 시간 규모를 논의 할 때 고객 및 상급 관리자와 현명하게 대화 할 수 있습니다.


투표 할 수 있고 이것이 유용한 질문이거나 아래에 유용한 답변이 있다고 생각되면 투표하십시오. 좋은 커뮤니티를 구축하려면 StackExchange 사이트에 투표가 필요합니다. 하루에 30 표를 낼 수 있고 낭비하지 마십시오. 명성이 높고 카운트가 적은 투표권을 가진 사용자는 다음을 읽으십시오. meta.programmers.stackexchange.com/questions/393/…
Maniero

이런 종류의 질문에 대해서는이 제안을 따르십시오 : 조직 측면
Maniero

5
Battle Chess의 여왕 애니메이션을 작업하는 아티스트는 이러한 경향을 알고 혁신적인 솔루션을 고안했습니다. 그는 여왕을위한 애니메이션을 자신이 최고라고 생각한 방식으로 한 번의 추가로 여왕에게 애완용 오리를주었습니다. 그는이 오리를 여왕의 모든 애니메이션을 통해 애니메이션으로 만들었습니다. 또한 "실제"애니메이션과 겹치지 않도록 세심한주의를 기울였습니다.
Job

2
욥의 대답이 다른 사람의 머리 위로 넘어간 경우, 관리자는 관리자가 자신의 작업에 대한 명백한 문제를 비판했을 때 오리를 쉽게 제거했습니다.
TheBigO

답변:


20

계속 말하고 참여하고 교육하려고 노력하십시오.

그들이 정직하게 당신을 돕기 위해 노력한다면, 무언가를 배울 수있는 기회는 그들에게 가치가있을 수 있습니다. 만약 그들이 자존심이나 정치적 이유로 코를 밀고 있다면 ( "도움을주고 있습니다, 도와주고 있습니다!"), 말도 안되는 소리를 계속 들으면 당황하게 될 것입니다. -그들은 단지 이해하는 척하는 전문 용어 벽으로 그들을 죽게했다.

그리고 만약 당신이 어떤 증거가 당신이 반대에 가져올 수 있는지에 상관없이, 그들이 당신의 일에서 전문가라고 생각하는 두려운 자아 마니아를 가지고 있다면, 미소 짓고 끄덕이며 사소한 미용 변화로 인해 지옥에 갈 수 있습니다. 그리고 이력서를 업데이트하십시오.


2
참여는 여기서 유일한 장기적 답변입니다. 정직하고 개방 된 근무 환경은 [궁극적으로] 행복한 환경입니다.
dwynne

2
저는 프로그래머 인 3 인 회사에서 그런 상사를 가졌습니다. 그는 항상 "유용한"제안을하고 질문을 던졌습니다. 전문적이고 자신의 지위를 존중하는 것 외에도, 나는 그가 일을 방해하지 않기 위해 그를 떠나게하려고 그를 만족시키기위한 대답을 해줄 것입니다. 그러나 대화에 대답하거나 대화하는 방법을 생각할 때 다른 방식으로 문제를보고 해결책을 찾았습니다. 그가 나를 계속 방해하는 것이 정당하다고 느꼈기 때문에 그것은 정말로 악화되었습니다. 그리고 그는했다. 나는 많은 것을 배웠고 싫어했습니다.
Huperniketes

@Huperniketes, 마음을 구성하십시오.
Pacerier

5

나는 보통 그 사람이하는 모든 말을 듣습니다. 나는 거의 모든 것에 동의하며 어쨌든 내 방식대로한다. 보통 그는 확인을 귀찮게하지 않습니다.


이것이 내가 행동하는 방식입니다 :)
Emiliano

5

그룹 코드 검토 대중의 당혹감은 이런 종류의 습관을 억제하는 데 항상 좋습니다. :)


4

특히 관리자가 l33t h @ x0r라고 생각하지만 지난 10 년 동안 아무것도 코딩하지 않았다면 매우 어려울 수 있습니다.

능동적 청취 를 사용하여 시작하십시오 . 그들이 겪고있는 지점을 정확히 이해해야합니다. 다시 말해서 이해하고 이해하도록 그들에게 다시 쏘십시오. 때때로 이것은 그들이 정말로 염려하는 전부입니다.

그들이 어떤 구현을 고집한다면, 왜 거부하는지 스스로에게 물어보십시오. 이유가 있어야합니다. 아마도 기본적인 소프트웨어 설계 원칙을 깨뜨릴 수 있습니다. 원칙을 알고 대안보다 더 나은 이유를 알아보십시오 . 그런 다음 원리를 인용하고이 경우 왜 따라야 하는지를 설명하십시오. 그것은 토론을 학문적으로 만듭니다.

왜 그들이 말하는 것을 좋아하지 않는지 알 수 없다면, 가정에 의문을 제기 할 수있는 좋은 기회입니다.


1

나는 그 / 그녀를위한 코드 히스토리가 있는지 교육하지 않았다. 개발 문제에 대한 지식이 떠오를 것입니다.

정중하게 그 / 그녀가 점심에 대해 생각하고있는 것을 토론 할 수 있는지 물어보십시오.


0

때로는 원치 않는 경우에도 앉아서 듣고 있어야합니다.

주의를 기울이지 않으면 사람의 존엄성을 해칠 수 있습니다.

관리자는 사람입니다. 그를 하나처럼 대하십시오. 마치 거리에있는 사람인 것처럼 그를보십시오. 제목이 없습니다.

친구를 필요로하는 사람, 외로움을 느낄 수있는 사람이되지 않습니까?

감정적 인 관점에서 생각해 보셨습니까?

그는 암묵적인 메시지를 전하려고 노력하고 있습니까?

그와 대화하십시오. 단지 문제에 관한 것이 아닙니다. 인생은 어떻습니까? 그는 감사하다고 느끼게되어 근로 불안을 줄입니다.

이미 이것을 고려했거나 수행 했습니까?

그렇지 않다면 왜?


어느 나라 출신입니까?
Pacerier

0

그에게도 같은 일을하십시오. 당신이 그를 볼 때마다, 당신이 그것을 이해하는지의 여부에 관계없이 즉시 그의 물건에 대해 이야기하기 시작하십시오. "저희 영업팀이해야 할 일이라고 생각합니다!" "이봐, 다음에 매니저와 이야기 할 때, 그에게 quox를 말해야한다!" 그는 전염병처럼 당신을 피하기 시작합니다.


0

여기서 문제는 관리자가 아닌 경우 관리자가 유능하다고 느끼는 것입니다.

나는 전에 그런 경험을 해왔고 프로그래밍이 그의 영역이 아니라는 것을 미묘하게 보여 주면 효과가있었습니다.

예를 들어, 특정 코드를 설명하기 위해 많은 시간을 할애하여 해시 테이블 및 링크 된 목록, 큰 O 표기법 등에 대해 이야기 할 때까지 그의 얼굴이 더 이상 따라갈 수 없다고 느낄 때까지 당신의 토론.

따라서 이것을 풀 수 있다면 어리석은 질문과 소액 관리를 없애 게 될 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.