저는 관리자입니다. 업무 관계 및 프로그래머와의 의사 소통을 어떻게 개선 할 수 있습니까? [닫은]


431

먼저 작은 배경. 저는 중소 기업의 프로젝트 관리자입니다. CS 전공으로 시작하여 프로그래밍에 약간의 노출이 있었지만 몇 개월이 지나서야 이것이 내 길이 아니라는 것을 알았으므로 경영진으로 전환했습니다. 그것은 좋은 결정으로 판명되었고 졸업 후 저는 5 년 동안 여러 회사에서 소프트웨어 관리 업무를 수행했습니다.

최근에 우리는 매우 고통스러운 프로젝트를 가졌습니다. 우리 쪽과 고객 쪽 모두에 많은 실수가 있었고 손실없이 거의 끝내지 못했습니다. 그로 인해 많은 좌절 상황이 생겨 났으며, 그 중 하나는 고위 개발자 중 한 명이 우리와의 성명을 발표 한 후 회사를 떠날 때까지 높아졌습니다 (관리자). 이것은 나를 위해 붉은 깃발이었다 : 나는 정말 잘못했다. (기록상, 몇 가지 잘못된 시간 추정치에 대한 논쟁이 있었다)

나는 많은 곳에서 답을 찾고 친구가 나를이 사이트로 안내했다. 여기에 경영진과의 좌절에 관한 많은 질문이 있습니다. 나는 일반적인 나쁜 경험으로 인해 "정장에있는 사람들"에 대한 일반적인 망설임이 있음을 이해할 수있다.

양복 입은 그 남자 야 그것은 좋아 보이지 않을 수도 있지만, 내가 원하는 것은 성공적인 프로젝트이며 제한된 자원으로 인해 고통스러운 결정이 필요합니다. 그게 내 직업이야 앞서 언급 한 선임 개발자가 불평 한 것 중 하나는 작업 장비였습니다. 솔직히, 나는 우리가 가지고있는 컴퓨터가 작업에 적합하지 않다는 것을 몰랐습니다. 그 후, 나는 많은 프로그래머에게 물었고, 일반적인 합의는 더 나은 기계가 필요하다는 것이었다. 나는 그 이후로 그것을 고쳤지만, 나와 프로그래머 사이에는 분명히 큰 의사 소통 격차가 있었다. 가장 훌륭한 개발자 중 일부는 가장 수줍어하고 조용한 사람들입니다. 나는 그것을 알고 있으며, 인터뷰하는 동안 결코 문제가되지 않았습니다. 사람들은 다르고 다른 지역에서도 강점이 있습니다.

저전력 PC의 경우는 통신 문제가 있다고 생각하게 만든 많은 사람들 중 하나 일뿐입니다. 위협적이고 반복하지 않고 프로그래머와의 의사 소통을 개선하려면 어떻게해야합니까?

내가 바라고있는 것은 사람들이 좋은 것에 대해 불평하지 않는다는 것입니다. 직장을 좋아하고 관리자를 사랑하거나 최소한 좋아 한다면 , 그들에 대해 알려주십시오. 그들이 옳은 일을 무엇입니까? 마찬가지로, 당신이 그것을 싫어한다면 이유를 자세히 설명하십시오. 나는 그것이 내 문제라고 생각하기 때문에 의사 소통 개선에 대한 답변을 찾고 있지만 잘못되었을 수도 있습니다.


45
팀 점심 또는 저녁 식사를 위해 개발을 진행하지 않습니까? 우리는 적어도 한 달에 한 번 그렇게합니다. 당신은 그들과 팀, 그리고 개별적으로 (적어도 분기마다) 비공식 회의를하지 않습니까? 개발자가 된 적이없는 개발자 팀을 관리하는 사람인 OTOH는 어려운 상황에 처해 있습니다. 이로 인해 존중 / 신뢰 문제가있을 수 있습니다.
랜디 마인더

97
장비와 관련하여 : 아마도 시간당 약 $ 100의 비용이들 것입니다. 그들이 무언가, 기계, 책, 다른 모니터, 의자, 책상, 헤드셋이 필요하다면 그것을 구하십시오. 이러한 사소한 지출에 대한 권한이없는 경우 계속되는 매출을 기대하십시오.
케빈 클라인

22
저의 관리자는 저를 점심으로 꺼내서 비용을 지불하지만 감히 내 의견을 요구하지는 않습니다. 대신 그는 그의 마지막 직장이 얼마나 나빴는지에 대해 이야기합니다. 솔직히 말하면, 어쨌든 결정은 해외에서 이루어지고 종종 바보 같은 결정이기 때문에 묻지 않는 것이 좋습니다. 내 요점 : 1 : 1을 갖거나 점심을 먹기에는 충분하지 않습니다. 간단한 질문을해야하지만 합리적인 변경을 할 수있는 능력을 보여 주어야합니다. 그 없이는 1 : 1은 쓸모가 없습니다.
직업

27
이것이 문제의 핵심입니다 IMHO ... 첫 번째 적기가 관리자와의 대립 회의 후 회사를 떠나는 선임 개발자 인 경우 새로운 적기가 필요합니다. 더 미세한 문제에서 작동하는 것. 다른 개발자들과 이야기하고, 가장 좋은 관계를 가진 사람부터 시작하십시오. 왜 불행한지 물어 보자. 그리고 그들이 자신이 금연에 대해 생각하기에 충분히 불만족 스러웠다는 것을 질문한다. 당신이 그것을 어떻게 알아 차릴 수 있었는지, 그들이 당신이 이미 그렇게 큰 문제라는 것을 알기 위해 놓쳤다는 것을 당신이 생각한 어떤 표시를했는지 물어보십시오. 먼저 문제를 확인해야합니다.
에릭 브라운-Cal

29
"협박스럽고 반복하지 않고 프로그래머와의 의사 소통을 향상시킬 수있는 방법은 무엇입니까?" 협박과 반복에 대한 걱정은 "커뮤니케이션 개선"이 더 많은 대화를 통해하는 것이라고 생각합니다. 잘못된. 덜 말하십시오. 그리고 대화 할 때 질문하십시오. 일을 잘하기 위해 필요한 것이 있는지 물어보십시오. 마감일이 합리적인지 물어보십시오. 그들이 어려움을 겪고 있거나 어려움을 느끼고 있는지 물어보십시오. 그런 다음 우려에 대해 조치를 취 하십시오. 질문에 대답하면 실제 변화가 발생하면 사전에 의사 소통을 시작하게되고 다시는 눈을 멀지 않게됩니다.
마이클 에임스

답변:


331

와! 질문 주셔서 감사합니다. 기술적으로, 당신처럼 코드를 작성하는 것보다 팀과 의사 소통하고 팀을 이끄는 데 더 많은 시간을 소비하기 때문에 관리인이라고 생각합니다. 그러나 여기에는 관리 영역의 양쪽 끝에서 가져 왔습니다. 내가 개발자이거나 다른 관리자를 위해 일하는 관리자이든 상관없이 내 경영진과의 의사 소통에 도움이되는 것들이 있습니다.

  • 왜? 매우 중요한 질문입니다. 거의 모든 사실적인 답변에는 그 뒤에 "이유"가 있으며 "이유"가 실제 질문보다 더 중요 할 수 있습니다. 이에 대한 몇 가지 접선이 있습니다.
    • 개발자 이유 -개발자에게는 경영진에게는 전혀 이해가되지 않는 많은 답변이 있습니다. 나는 확실히했고, 내가 경영진에 들어간 방법 중 하나는 경영진이 이해할 수있는 용어로 팀에게 "이유"를 설명하는 데 정말로 능숙했다. "괴짜를위한 연설자"가 없다면,보다 일반적으로 이해되는 은유로 왜 질문에 대한 답을 되풀이함으로써 괴짜를 말하는 법을 배울 수 있습니다. 무슨 일이 일어나고 있는지에 대해 이해하고 동의 할 때까지 유지하십시오.
    • 경영 이유- "왜"가 중요합니다. 예상 시간이 왜 필요한가요? 무엇을 위해 사용하고 있습니까? 회사가 너무 높거나 너무 낮 으면 회사가 얼마나 엉망입니까? 이것은 관리자로서 아마도 통찰력을 가지고 있었을 것입니다. 그러나 이것은 개발자에게 모든 부두입니다. 요령은 개발자가 묻지 않을 수 있다는 것입니다. 경영진은 그에게 무언가를 요구했으며, 정확하고시기 적절하고 사려 깊도록 최선을 다할 것입니다. 그러나 "이유"를 모르면 그는하지 않은 방식으로 최적화 할 수 있습니다. 이유를 제시하고 똑같은 일을하도록 요청하십시오. 자신의 말로 답변을 다시 작성하십시오.

시간 추정치에 대해-나는 엄청나게 돈을 벌어야했고 개발팀에 말함으로써 정말 이익을 얻었습니다. "봉급을 지불하기 위해 더 많은 돈을 요구할 것이기 때문에 이것이 필요합니다. 나는 당신의 숫자를 사용할 것입니다. 그것은 당신이 저에게 낮은 공을 가지고 있다면, 우리는 돈을 다시 요구할 수 없기 때문에 우리 모두 망친다는 것을 의미합니다. 우리는 우리가 제안한 것에 따라 살아야합니다. " 이러한 맥락에서 개발자들은 저평가에서 실제 기대치 설정에 훨씬 근접한 고평가에 대한 자신감과 찬사를 보여 주려고 노력했습니다.

  • 아무도 틀리지 않습니다 - "왜"질문은 한 평론과 함께 오래갑니다. "그건 터무니 없어요!" 대화가 계속 흐릅니다. 때때로 누군가가 요구하는 것과 요청자가 요구하는 것 사이에 심각한 연결 끊기가 있습니다. 저의 최고 경영진은 제 답변에 크게 놀랐습니다. 놀랐을 때 놀랍게 깜박 인 다음 "왜 그렇게 말합니까?"라고 묻습니다. 그들은 "바로 바꾸지 말아야한다"고 말하지 않습니다. 경쟁 목표를 달성하기 위해 제안서 수를 줄 였지만 장면을 바꾸고 질문에 대한 다른 맥락을 만드는 방법에 대해 강렬하게 이야기 한 후에 만 ​​가능합니다.

  • 주변 소음, 단어 선택 및 단어 사이의 공백을 들어보십시오 -여기 내가 좋아하고 도난당한 것들이 있습니다.

    • 작업장에서 놀거나, 자신 만의 생산적인 일을하십시오 (개발자 작업에 참여하지 말고 개발자가 아니라는 것을 알고 있음). 팀은 어떻게 문제를 해결합니까? 그들의 큰 문제는 무엇입니까? 당신은 당신이나 경영진에 대한 직접적인 평가에서 실제적으로 마른 소리를 듣지 못할 것입니다. 그러나 문제 영역이 어디에 있는지 실제로 잘 이해할 수 있습니다. 생산적인 일을하고 있는지 확인하십시오. 스파이를 좋아하는 사람은 없지만, 사기가 너무 낮아서 모든 사람이 대피하지 않고 가까이있을 수 없다면 근접성 내 생산성은 견딜 수 있어야합니다.
    • 단어 선택을 찾아보십시오-단어 자체만큼이나 중요합니다. 특히 긍정적이거나 부정적인 단어를 사용했을 때, 경영진은 자주 익숙하지 않은 상황에서 왜 그 단어를 선택했는지 묻습니다.
    • 일시 정지, 간격 및 신체 언어를 찾으십시오. 자신과 개발자 사이의 거리가 멀고 (있는 것처럼 들리면) 모순되거나 대립하고 싶지 않을 수 있습니다. 그러나 "이봐, 당신이 틀렸다"고 말하는 본능은 대개 어딘가에 나타난다.
  • 가능한 한 많은 통신 매체를 열어야합니다. 즉 , 직접 대화하거나 전화, 이메일, IM으로 대화 할 수 있어야합니다. 사람들은 매우 다양하여 하나의 트릭만으로는 효과가 없습니다. 그리고 개발자가 아닌 멀티 포맷 커뮤니케이터가되는 것이 관리자의 일이라고 생각합니다.

  • 당신 이야기는 보람 사람이 문제에 대해 알려줍니다 어쩌면 가능한 솔루션, 그는 아마 당신은 관리자 것을 받아 들여야 및 그 전혀 그렇지 않기 때문에 다른 솔루션, 또는 전혀 솔루션에 찬성 결정할 수있는 경우 그만한 가치가 있다고 생각하십시오. 그러나 세 번째 시간이 지나면 특히 99 %의 사람들이 아무런 설명도없이 설명을하지 않으면 이런 일이 발생하지 않습니다.

그리고 여기 저에게 엄청나게 어려운 것이 있지만, 내가 할 수있을 때 크게 효과 가있었습니다 . 내향적인 것과 외향적 인 것의 차이점을 알고 있어야합니다 . 당신이 외향적 인 사람 일 가능성이 있습니다. 그래서 당신의 직업은 좋아 보였고 개발 위치는 그렇지 않았습니다. 개발자는 대부분 내 향적입니다. "내 향적"은 "통신 할 수 없음"을 의미하는 것이 아니라, 패턴, 프로세스 및 속도가 크게 다르며 끊임없이 의사 소통하려는 충동이 거의 존재하지 않음을 의미합니다. 내향적인 생각이 나올 수 있도록 시간과 조용한 (그러나 배치 된) 공간을 계획하십시오. 내 성향이 많은 친구들 중 많은 사람들이 그들이 "5 분 동안 닥쳐"기다리고 있기 때문에 그들이 생각을 갖고 반응 할 수 있다고 말합니다. 이리'외계인이 괴상한 동굴의 휴식처에있는 내 향적 인 사람랜드에 대해 알아야 할 5 가지 -특히 내 향적 인 사람에게 좋은 것의 개발자를위한 훌륭한 예입니다 . 그런데 랜드는 꽤 환상적입니다. 그는 자신이 괴짜이기 때문에 개발자 중심에서 나옵니다.이 스타일은 귀하의 스타일이 아니라면 미루지 만 재미 있고 팀 개발에 대한 좋은 통찰력을 가지고 있습니다.

내가 좋아하는 관리자에 대해 내가 좋아했던 # 1은 다음과 같습니다.

  • 그들은 내가 그랬던 것처럼 프로젝트에 대해 깊이 헌신하고 흥분했습니다.

  • 나는 그들이 내 등을 가지고 있다는 것을 결코 의심하지 않았다. 나는 그들이 다음 단계의 권위 앞에있을 때 내가 (혹은 나의 동료들) 결코 절대 염소가 될 수 없다는 것을 확실히 알고 있었다. 실패가 있으면 항상 그룹 실패가됩니다.

  • 당시에는 내 기술에 중요하고 적절한 것을 소유했지만 기술을 확장하고 업무를 수행 할 수있는 충분한 리소스가있었습니다.

  • 그들은 저를 개인이자 팀의 일원으로 보았습니다. 그들은 저의 강점과 약점을 알고 저의 강점을 완수하고 약점을 강화하는 데 적극적으로 참여했습니다.

  • 그들은 저의 개인적인 목표를 알고 최대한 많은 것을 통합하는 데 관심이있었습니다

  • 그들은 나를 행복하게 할 때 선구자가 될 수 없었으며 우선 순위가 아니 었습니다. "이러한 유형의 작업이 싫다는 것을 알고 있지만 그렇게해야합니다. 여기에 영원히없는 방법이 있습니다."

  • 큰 그림을 설명하기 위해 항상 일주일 안에 (순간에 아닐 수도 있음) 시간이있었습니다.

  • 손가락을 가리 키지 않고 개별 작업에 대해 많은 인정을 받았으며 거의 ​​일정한 피드백과 상태가있었습니다.

  • 항상 진실이 있었다. 어떤 것이 민감하고 토론 할 수 없다면, 그들은 빈칸으로 지적했다. 확실치 않은 것이 있다면, 그들은 어느 정도 자신감을 갖게되었습니다.


14
내향적인 사람들의 문제는 외향적 인 사람들도 정신적이지 않다는 것을 항상 기억하지 못한다는 것입니다.
MirroredFate

2
아 잠깐, 이것은 블로그 게시물이 아니었다-나는 아직도 프로그래머에있다! 잘 했어!
제온 크로스

17
어딘가에 +10 버튼이 있어야합니다.
Marjan Venema

3
고마워 갱! 이런 댓글을 보는 것이 얼마나 좋은지 말할 수 없습니다! 계속 써요! :)
bethlakshmi

3
음성을 통해 의사 소통을하는 일부 청소년들은 다른 청소년들에게 묻거나 관계에 대해 이야기하지 않습니다. 그들에게 문자 메시지를주고 그들은 엄청나게 친밀한 말을 할 것입니다. 비슷한 정도로 우리 모두도 마찬가지입니다. 이것이 문자 메시지를 전달하기가 훨씬 어려울 때 문자 메시지가 어디에나있는 이유입니다. 요점은 모든 채널을 여는 것이 필수적이라는 것입니다.
Kzqai

160

가장 쉬운 부분은 다음과 같습니다. 게시물에 기술적 인 문제가 있습니다. '실수 추정치'에 대해 언급하는 것을 떨고 있습니다. 추정치입니다. 추정 할 수 없습니다 . 그것은 조금 떨어져있을 수 있고, 많이 떨어져있을 수 있기 때문에 견적이라고합니다. 당신이 복음으로 평가를 받고 있다면, 그것은 "귀하의"개발자들이 당신의 스타일에 가지고있는 주요 문제 중 하나가 될 것입니다.

그러나 개발자와 의사 소통하기가 어렵다는 것에 100 % 동의합니다. 나는 몇 년 전 프로젝트 관리 교육의 개발자로서 계시를 받았습니다. 공개 토론 분위기가 조성 된 후 동료 개발자들 중 일부가 경영진에 절대적으로 의존하는 것을 보았습니다 (관리가 여기에있었습니다). 잘못된 것은 개발자의 눈에 관리자의 잘못이었습니다. 중요한 것은 경영진이 그날 제기 된 거의 모든 거대한 문제에 대해 전혀 몰랐다는 것입니다. 개발자들은 경영진이이를 놓칠 수없는 것이 너무나 명백하다고 가정했으며, 경영진은 개발자가 필요한 것을 말할 것이라고 가정했습니다.

따라서 IMHO의 첫 번째 부분은 개발자가 자신이 정신적이지 않으며 실제로 기술적 인 측면에서 멍청하다는 사실을 개발자에게 알리는 것입니다. 당신은 그들이 적시에 당신에게 올 것을 의지하고 믿고 의지하고 있습니다. 당신은 그들의 삶을 더 어렵게 만드는 것이 아닙니다.

그리고 당신이 무엇을하든, 실제로 대답을 알고 싶지 않은 질문을하지 마십시오-위의 "실수 추정";-). 이것이 개발자의 크립토나이트입니다.


5
이것은 개발자들이 종종 더 단호해야한다고 지적합니다. 많은 사람들이 "슈트"와 대화하는 것을 두려워하므로 제기해야 할 문제를 제기하지 않습니다. 관리자에게 물건을 요구하고 심지어 그것을 요구하는 것도 직업의 일부입니다.
크리스토퍼 존슨

7
동시에 개발자는 경영진이 청취에 관심이 있다는 사실을 깨닫지 못할 수 있으므로 귀찮게하지 않습니다.
jhocking

5
견적을 납품 일로 전환하는 데 사용되는 기존 규칙은 400 %를 곱하는 것입니다. 견적은 종종 모든 보조 코딩을 포함하는 것을 잊어 버리고 개발 관리자는 처음에보다 정확한 숫자를 찾으려고하기보다는 견적을 얼마나 채울지 아는 것이 중요합니다.
STW

11
@Charles E. Grant : "모두 어려운 날짜가 필요하다"... 초기 추정치는 단순한 환상입니다. 소프트웨어를 손에 넣지 않고 심각한 현금 약속을하는 관리자는 부주의하게 행동합니다. 부정확 한 개발자를 비난하는 것은 요점을 놓친다. "추정치"를 기반으로하는 약속은 종종 나쁜 사업입니다.
S.Lott

4
@ -S.Lott, 소년 나는 주요 수축 랩 소프트웨어 회사와 몇 개의 작은 소프트웨어 계약자에서 일했으며, 그들 중 누구도 당신이 제안한 접근법을 사용하는 것을 본 적이 없습니다. 그것은 확실히 회사가 개발을 수행하는 위험을 감소시킬 것이지만, 경쟁, 시장 창, 규제 요구 사항 등과 같은 고객에 대한 위험을 무시합니다. 나는 일정이 지정되지 않은 사용자 정의 개발 계약을 본 적이 없습니다. 작업 시간이 얼마나 걸리는지에 대한 헌신을 얻지 않고 주택 리모델링 계약자를 고용 하시겠습니까?
찰스 E. 그랜트

69

여기에는 좋은 것들이 많이 있지만 다음과 같이 말할 필요가 있다고 느낍니다. .. 죄송합니다 .. 그러나 이것은 말할 필요가 있습니다.

  • PM으로서 5 년이며 개발자에게 어떤 종류의 PC가 필요한지 모르는 것은 터무니 없습니다.
  • 첫 번째 실제 적신호로 나쁜 작업 조건으로 인해 개발자를 종료 시키는 것은 미친 짓입니다.

내가 생각 하는 것은 커뮤니케이션 문제보다 신뢰 문제입니다. 그들은 당신이 그 정보로 무엇을할지 믿지 않기 때문에 무엇이 잘못되었는지 말하지 않으며, 심지어 그 정보 가 그들에게 사용될 것이라고 두려워 할 수도 있습니다. 이러한 모든 문제에 대해 알려 주신 개발자는 그렇게했을 때 아무런 결과가 없었기 때문에 그렇게했습니다.

개인적으로 나는 그의 경력이 전혀없는 PM을 절대 고용하지 않을 것입니다. 다음 프로젝트에서는 Dev의 일부로 시간의 작은 부분을 바쳐야 한다고 생각합니다 . . 팀 리더로 Jr 개발자로 일하면서 일주일에 8 시간을 말합니다.

이것은 실제로 개발 팀의 역학에 주목할 것입니다. 지금은 팀의 일부가 아니기 때문에 외부인이기 때문입니다. 당신의 개발자가 당신에게 충격을 주었다는 사실이 그것을 증명합니다. 팀의 모든 사람들은 그가 불행하다는 것을 알았습니다. 그리고 그들 중 누구도 당신에게 말하지 않았습니다.

"당신이 무언가를하지 않으면 우리는 최고의 남자를 잃을 것입니다"

그것은 붉은 깃발 # 2이어야한다.


10
다시 한 번 선임 개발자가 도구였으며 다른 모든 개발자들은 그가 떠나기를 기다리고있었습니다. 당신이 이해한다고 가정하는 질문에 많은 공개되지 않은 맥락이 있습니다.
naught101

"아무도 잘못된 것을 말하지 않는다", 절대적으로 사실.
Buzz

37

관리자로서 저는 Toyota Production System의 신조 중 하나 인 kaizen 에 대해 들었습니다 . 지속적인 개선을 의미 합니다.

당신은 당신이 문제가 있음을 인정 했으므로 그것은 좋은 출발입니다.

Kaizen 에는 5 가지 기본 요소가 있습니다.

  • Quality Circles : 회사 운영의 모든 측면에 관한 품질 수준을 논의하기 위해 모이는 그룹.

  • 사기 개선 : 직원들 사이의 강한 사기는 장기적인 효율성과 생산성을 달성하기위한 중요한 단계이며, kaizen은 직원의 사기와 지속적으로 연락하기위한 기본 작업으로 설정합니다.

  • 팀워크 : 강력한 회사는 모든 단계를 하나로 묶는 회사입니다. 카이젠은 직원과 경영진이 경쟁자가 아닌 팀 구성원으로 자신을 바라 보도록 돕는 것을 목표로합니다.

  • 개인 규율 : 팀 구성원 각자가 강하지 않으면 팀이 성공할 수 없습니다. 각 직원의 개인 규율에 대한 약속은 팀이 강하게 유지되도록 보장합니다.

  • 개선을위한 제안 : 경영진은 팀의 각 구성원에게 피드백을 요청함으로써 문제가 심각해지기 전에 모든 문제를보고 해결하도록합니다.

( 소스 )

이것을 오랫동안 살펴보면 이러한 요소에 대한 상수는 팀워크와 피드백에 중점을 둡니다.

예를 들어, 시간 추정치에 대한 논쟁이 있었다고 말합니다. 당신은 그 시간 추정에 대한 책임이 있습니까? 그것에 대해 팀과 이야기합니까? 미안하지만 관리자가 방금 숫자를 뽑는 것을 보았습니다. 한 가지 중요한 점 은 팀이 당신에게 제공하는 시간이 지남에 따라 흥정 하지 마십시오 . 많은 관리자들은 팀이 더 열심히 일하면 짧은 마감 시간을 맞출 수 있다고 생각합니다. 이건 거짓말이야 한 달에 아홉 명의 여성은 아기를 가질 수 없습니다.

그래서 첫 번째 조언은 다음과 같습니다.

듣기 : 팀에게 간단한 전자 메일로 시작하십시오. "개발 팀이 관리 성과에 대해 경영진에게 피드백을 제공하는 가장 좋은 방법은 무엇입니까?" 팀과 반복하여 합의를 구현하십시오. 당신의 임무는 팀이 훌륭한 소프트웨어를 개발할 수 있도록하는 것입니다. 이것을 명심하십시오.

정직과 충성도 : 당신이 무언가를 요청할 때 아무도 대답하지 않는다면, 그들은 당신이 듣지 않을 것이라고 믿지 않기 때문입니다. 그러니 정직하십시오. 누군가가 당신이 빨다고 말하면, 이것을 피드백으로 받아들이고 복수하지 마십시오. 그들의 이유를 이해하고 개선하십시오.

그리고 마지막으로 여기에 대한 몇 가지 비판을 보았지만 The Mythical Man-Month : Essays on Software Engineering 이라는 책을 읽는 것이 좋습니다 . 이 책은 OS / 360의 개발을 관리하면서 IBM에서의 Fred Brooks 경험에 관한 것입니다. 여기에 몇 가지 일이 있었지만 복잡한 소프트웨어의 개발 프로세스가 어떻게 작동하는지 이해하는 것이 시작 단계입니다. S.Lott는 Agile Manifesto를 인용하며 , 특히 관심이 없지만 읽을 가치가 있습니다.


7
+1, 신화적인 남자-월. 그 책은 오래되었지만 결코 구식이 아닙니다.
David Hammen

또한 Anniversary Edition에는 90 년대를위한 훌륭한 새 자료가 추가되었습니다. 나는 그들이 2015 년에 40 주년 에디션을 제작하기를 희망합니다. * 8 ')
Mark Booth

3
거짓말보다 사기를 더 빨리 죽이는 것은 없습니다. 가장 큰 거짓말 관리는 "당신은 일을하기 위해 XYZ가 필요하지 않습니다"라고 말합니다. 그들이 당신보다 어떻게 더 잘 알 수 있습니까? 그러므로 그들은 거짓말을하므로 신뢰가없고 사기도 없습니다. XYZ를 "모니터, 소프트웨어, 더 빠른 하드웨어, 서버, 음식, 조용한 작업 공간, 대량의 책상 공간, 화이트 보드, 설탕 이외의 음식으로 구성된 휴게실, 유연한 일정 등"으로 대체하십시오. t "내가하고 싶지 않은 일을 잘 해내려면 어떻게해야합니까?"라고 암묵적으로 원하지 않습니다. 사기가 없습니다.
Christopher Mahan 1

볼 가치가있는 또 다른 책은 DeMarco와 Lister의 Peopleware입니다. 내부에있는 것을 내부화 할 수 있다면 팀과 더 나은 관계를 구축하기 시작할 것입니다.
Alger

26

이것을 읽으십시오 :

http://agilemanifesto.org/

  • 프로세스 및 도구에 대한 개인 및 상호 작용

  • 포괄적 인 문서에 대한 작업 소프트웨어

  • 계약 협상을 통한 고객 협업

  • 계획에 따라 변경에 응답

대부분의 경우 조직 (즉, 상사)은

  • "죽음 행진"으로 이어지는 논리적 인 결론으로 ​​명확하게 깨진 과정을 따르십시오. 이것은 차례로 논쟁과 사임으로 이어진다.

  • 과도하고 가치가 낮고 사용하지 않은 문서를 만듭니다.

  • 복잡한 변경 관리 및 계약 협상에 참여합니다. 모든 사용자 변경에는 변경을 "품질"하고 "우선 순위를 정하는"정교한 의식이 필요합니다. 실제로, 그것은 "동결"에 관한 것입니다. 변화를 막습니다.

  • 결과에 관계없이 계획을 따르십시오. 일부 조직은 고장난 (또는 쓸모없는) 소프트웨어를 적시에 제공하는 것을 중요하게 생각합니다. 비즈니스 문제의 해결책이 아니라 가치있는 계획입니다.

문제가 개인적인 의사 소통 기술이 아닐 수도 있습니다.

전체 개발 "환경"또는 "방법론"이 치명적일 수 있으며 나쁜 감정은 일반적인 나쁜 습관의 증상 일뿐입니다.


3
애자일이 도울 수 있다고 생각하지만 분명히 수정해야 할 의사 소통 문제가있는 것처럼 들립니다. 그는 정직하게 나쁜 기계가 합법적 인 고통을 일으키는 것을 몰랐다. 문제를 제기하지 않은 개발자에게 있습니다.
Andy

@ 앤디 : 유독 한 조직은 종종 나쁜 의사 소통의 근본 원인입니다. 사람들 의사 소통을 원합니다 . 그러나 상급 관리자는 침묵을 보상하고 의사 소통을함으로써이를 쉽게 예방할 수 있습니다.
S.Lott

3
@ S.Lott : 모든 사람이 "의사 소통"하기를 원하는 것은 아닙니다.
MirroredFate

3
@ S.Lott : 모든 사람이 의사 소통하기를 원하는 것은 아닙니다. 그리고 그렇게해도 모든 사람이 효과적으로 의사 소통하는 것은 아니며, 이는이 조직의 경우처럼 들립니다.
Andy

1
"진실한 의사 소통은 평등 한 사람들 사이에서만 가능하다. 왜냐하면 열등한 사람들은 진실을 말하는 것보다 우월한 기분으로 거짓말을하는 것에 대해 더 일관된 보상을 받기 때문이다."
Benjol

22

나에게 이것은 쉬운 분위기에서 개발자와 이야기하지 않은 것처럼 들립니다. 그들과의 대화는 단지 공식적인 성격 이었습니까? 유감 이네요.

왜 개인적으로 그들을 알고 회사, 직장 및 프로젝트에 대해 무엇이 좋고 나쁜지 알게 되십니까? 그들의 일에 대한 진지한 관심과 감사를 보여줌으로써 그들을 존중하고 존중하십시오.

그들이 당신을 믿고 전당포 제안에 대해 두려워 할 필요가 없다면, 그들은 당신에게 매력없는 진실을 말할 것입니다.

나는 팀 리더이며 팀은 나를 신뢰합니다. 나는 그들을 보호합니다. 나는 모든 책임을지고 그들과 명성을 공유합니다. 우리 경영진이 나를 보호합니다. 그것은 사기를 높입니다. 우리는 정말 어려운 프로젝트와 거의 사악한 고객을 가졌으며 거의 ​​마무리 작업을 수행 할 수 없었지만 결국에는 모든 일에 대해 매우 솔직하고 개방적인 방식으로 이야기하기 때문에 완료했습니다.


아주 좋은 인용문 : "나는 모든 책임을지고 그들과 명성을 공유합니다."
Jared Burrows

20

박수! 박수! 박수! 당신은 확실히 좋은 사람이되어야합니다. 왜냐하면 당신은 직장에서 더 나아지기 위해 무엇을 할 수 있는지 볼 수 있도록 열려 있기 때문입니다.

아래에서 훌륭한 관리자에게서 목격 한 것을 찾아 내고 팀을 선임 멤버로 이끌 때 개인적으로 채택했습니다.

  • M의 entor 관리보다.
  • llow 팀 구성원은 자신의 생각과 우려를 표명한다. 모든 귀가 되십시오. 건설적인 것들을 가져 가라.
  • N은 적 분열 정치를 재생하여 팀 구성원을 배신. 이것은 조용히 조용히 발생합니다.
  • A는 하지 nger. 팀원과 함께있을 때 얼굴에 찡그린 얼굴이 생기지 않도록하십시오. 이것은 정말 어렵다.
  • G는 enuinely와 공개적으로 그 / 그녀의 좋은 작업 우승자를 주셔서 감사합니다. 같은 폭으로, 잘못을 저지른 사람이 아니라, 책임 있고, 고립되어 있고, 열려 있지 않은 사람에게 일을 매우 부드럽고 전술적으로 비판합니다.
  • E 모든 개인의 ncourage 소유권과 리더십. 이것은 그 사람이 존경받는다고 느끼기 때문에 그 사람의 사기와 헌신을 강화시킵니다.
  • R은 가끔 팀과 주위 OAM. 이것은 팀 구성원 내에서 유대를 유도 / 증가시킵니다.

진심으로 노력해 주셔서 감사합니다 :)


2
물론 그는 좋은 사람이어야합니다 . 나는 나쁜 사람들이 싫어.
제온 크로스

폭발적
Wayne Werner

23
저런 사람들과 의사 소통하기 위해 그런 약어를 사용하지 마십시오.
RMorrisey

16

일반적으로 참호에있는 사람들은 상황을 고칠 수 있고 고칠 사람들이 그립을 느끼지 못할 때 기분이 나 빠지기 시작합니다. 그들이 회사에서 자신의 입장을 위험에 빠뜨리지 않으면 서 그립 할 수 있다고 느끼지 않는다면, 훨씬 더 나빠집니다.

나는 이론 -Y 같은 사람이고, 대부분의 "지식 노동자"는 경향이 있습니다. 기회가 주어지면 우리는 우리의 일을 좋아하고 잘하고 싶습니다. 그러나 Theory-Y 직장의 단점은 문제가 있다는 것을 즉시 알 수 없다는 것입니다. 사람들은 잘하고 싶기 때문에 파도를 만들고 싶지 않으며, 그 문제를 해결할 방법을 찾거나 단순히 무시하기 때문입니다. 이것은 실망스러운 결과를 초래하여 결국 팀 전체의 얼굴을 날려 버립니다. Theory-X 관리자가 운영하는 상점에는 아마도 훨씬 일찍 불만을 제기하는 사람들이있을 것입니다. 직원들은 돈을 위해서만 돈을 벌고 있기 때문에 평소보다 더 많은 일을하게되면 사람들이 곤경에 처하게됩니다.

당신이 할 수있는 일에 대해, 선배와 직장에서 일하는 리드가있는 환경에서 그들은 최고의 자산입니다. 그들과 대화하십시오. "양방향"에 대해 일주일에 30 분을 예약 할 수 있습니다. 여기서 리드는 프로젝트의 일상에 대한 업데이트 및 대기 문제를 제공하고 비즈니스 측에서 업데이트를 제공하고 문제를 해결하도록 계획합니다. 팀에 심각한 영향을 미치는 문제가되기 전에

애자일에서는 각 "스프린트"또는 "반복"(일반적으로 1 주에서 3 주 사이 지속되는 개발 작업 단위)이 끝날 때 가장 후배 멤버부터 PM까지의 전체 팀에 "복각 적" ". 그들은 자신이 한 일, 옳은 일, 그렇지 않은 일을 되돌아보고 계속해야 할 일과 변화 할 일을 식별합니다. 몇 가지 형식이 있으며 자신만의 것을 발명 할 수 있지만 레트로의 결과는 사람들이 자신의 목소리가 들린다 고 느끼고 결과가 바뀔 것입니다.

애자일에 대해 이야기; 저의 첫 직업은 소규모 회사 였고 "작은"이라는 말로 회사 전체가 소프트볼 팀을 만들 수 없었습니다. 내가 시작할 때 4 명의 프로그래머가 있었고, 나가기 전에 2 명으로 줄었다. 회사의 창립자, 사장, CEO 및 95 % 이해 관계자가이를 철권으로 지배했으며, 조직의 유일한 계획 소스였으며 그다지 많지 않았습니다. 보스는 일을 잘하는 사람이었으며 다른 사람들도 함께 할 것을 기대했습니다. 당신이 주어야 할 모든 것은 그의 기대 이상이었고,이를 위해 그는 10 년간 그를 위해 일했던 사람들에게 초급 급을 지불했습니다.

나는 그 회사를 떠나서 다른 일을하는 다른 회사에서 일하기 시작했습니다. 그들은 매일 스탠드 업, 페어 프로그래밍, 스프린트 팀 및 회고와 함께 SCRUM Agile 기본 방법론을 연습했습니다. 각 스프린트 시작시 2 주마다 하루 동안, 우리는 다음 2 주간의 작업을 계획하는 것 외에는 아무것도하지 않았습니다. 하루의 큰 덩어리를 위해, 우리는 우리가 한 일을 되돌아보고 팀으로서 개선 할 수있는 방법을 찾는 것 외에는 아무것도하지 않았습니다. 내 옆에 Microsoft MVP 인 개발자가 있었고, 업무를 수행하고, 내가하고있는 일을 장려하고 보완했습니다.

밤. 과. 일. 주요 차이점은 무엇입니까? 첫째, 나는 프로젝트를 위해 스스로를 죽일 것으로 예상되지 않았다. 애자일의 기본 원칙은 지속 가능한 개발 속도입니다. 둘째, 나는 어떻게 일을해야할지 결정하는 목소리를 냈다. 나는 그 일을해야했지만, 다음 스프린트에서 나올 것으로 예상되는 것에 대해 "heartburn"이 있었다면, 나는 그 의견을들을 수 있었고 그것이 들리고 무게를 줄 것입니다. 더 좋은 방법이 있다고 느꼈다면 그렇게 말할 수 있고 즐겁게 될 것입니다.

해결책을 찾고 문제를 해결하는 한 위에서 아래로 일하는 것처럼 보이지 않도록주의해야합니다. 컴퓨터의 경우; RMR (매월 반복되는 수익)을 통해 회사는 2 주 동안 4 대의 컴퓨터 만 업그레이드 할 수 있습니다. 처음 네 대의 컴퓨터가 모두 리드와 선배에게 가지 않아야합니다. 그들은 가장 느린 컴퓨터를 가진 사람들에게 가야합니다. 팀에 보너스를주는 경우, "이것이 가능하지 않은 소중한 고령자와 리드"에게만 보너스를주지 마십시오. 개발자 팀의 모든 사람들이 그렇게했습니다. 주니어가 불만을 가지고 있다면 그를 들어라. 그가 주니어라고해서 아무것도 모른다는 의미는 아닙니다.


1
당신이 말하는 Type-Y 성격 특성은 무엇입니까? 그것에 대한 자세한 내용은 링크가 있습니까?
tylermac

3
Type-Y 성격이 적고 Type-Y 관리 스타일이 더 많습니다. Type X와 Type Y 관리자를 찾아보십시오. 기본적으로, 유형 X 관리자는 사람들이 주로 일자리가 제공하는 돈에 의해 동기를 부여받는다고 믿고, 유형 Y 관리자는 사람들이 일반적으로 일자리가 제공하는 성취에 의해 동기를 부여받는다고 생각합니다. 대부분의 노동자에 대한 진실은 어딘가에 있지만 대부분의 관리 스타일은 어떤 식 으로든 기울어 져 있습니다.
KeithS

3
구글에 적절한 용어는 이론 X와 이론 Y입니다.
Mark Canlas

11

관계 개선 :
방금 프로젝트가 어려웠습니까? 나중에 휴식을 취하십시오. 긴장을 풀고 숨을 쉬는 휴가 시간.
코더 권리 장전 이것들은 주어진 것입니다. 말없이해야 할 기본 사항. 이를 위반하면 코드 원숭이를 남용하는 것입니다.
Joel 테스트 는 그들 대부분에 동의합니다. 그러나 일부는 실제로 의존합니다. 일부를 놓친 경우 프로그래머의 삶을 어려워 할 것입니다.
기술 부채 . 따라서 완료를 추진할 수는 있지만, 모서리를 줄임으로써 기술 부채가 발생하여 후일에 수정하는 데 더 많은 시간이 소요될 수 있음을 알아야합니다. 프로젝트가 끝나기 전에 그 날짜가 오면 정말 망쳤습니다.
RSA 애니메이션 : 동기 부여이것은 지식 근로자에게 동기를 부여하는 방법을 실제로 보여주는 환상적인 비트입니다.
그들이 원하는 것을 코딩 할 자유의 날. RSA 비디오에서. 이름은 기억 나지 않지만 언급 한 회사는 사이트에 짧은 설명이 있습니다. 나에게 좋은 생각 인 것 같습니다. 대부분의 상점에는 모든 사람들이 파열 한 것으로 알고 있지만 아무도 고칠 시간이 없으며 우선 순위가 높지 않습니다. 이를 통해 기술 부채를 해결할 수 있습니다. 또한 훌륭한 아이디어를 과시 할 수 있습니다.

그리고 신의 사랑을 위해 일주일에 40 시간을 일하십시오. 또한 플렉스 타임. Flextime은 전 세계의 헛소리를 보완 할 수 있습니다. 적어도 나를 위해.

프로그래머와 상사 사이의 통신을 개선
그건 나를 위해 강하다. 그 전체 shmoozing 것은 프로그래머의 초점보다 보스 스킬 셋에 가깝습니다. 나는 시간 추정과 같은 기본적인 것들이 단지 추정치라고 말할 수 있습니다. 얼어 붙으면 물 위를 걸으며 요구 사항을 충족시키는 것이 쉽습니다. 부끄러운 프로그래머에게 코드 검토 또는 무언가로 프로젝트에 대한 프레젠테이션을 요구할 수 있습니다. 연습이 완벽 해 지나요? 그러나 나는 이것에 관한 다른 사람들의 조언에 절을 할 것입니다.

"마찬가지로, 당신이 그것을 싫어한다면 그 이유를 자세히 설명하십시오."
여기에 수문이 열릴 것입니다. 그리고 분명히 나에게 링크 될 수있는 openID를 사용하지 않았다면 아마도 통풍이 잘 될 것입니다. 하지 말아야 할 일에 대한 거대한 목록을 원한다면 익명 게시에 더 친숙한 포럼에 문의하십시오.


동기 부여 를 볼 가치가 있습니다. 나는 관련된 질문에 대한 내 대답의 많은 부분을 다루려고 노력합니다. programmers.stackexchange.com/questions/87321/…
Mark Booth

8

나는 항상 사람들이 당신을 치료하는 것보다 더 잘 치료하지 못한다는 것을 항상 발견했습니다. 나는 개인적으로 (개발자입니다) 정직하게 정직하고 존중하며 신뢰하며 신뢰하는 등 중립적 인 분위기에서 팀과 비공식적으로 대화하고 방금 우리에게 말한 내용을 알려야합니다. 독성 "우리 대 그들"환경에서 잊혀지는 요점 모두 "우리" 여야 한다는 것 입니다. 경영진과 근로자 모두이를 알고 있어야하며 기업은이를 지원해야합니다.

행운을 빕니다.


7

이제 피드백을 수락 할뿐만 아니라 그에 대한 조치를 수행 한 것으로 입증되었습니다. 상위 의사 결정권자에게 영향을 미치고 팀을 위해 일을 수행 할 수 있음을 증명했습니다. 그것은 큰 차이를 만듭니다. 프로그래머들은 더 내성적이지만 프로그래밍에 대해 이야기하고 싶습니다. 비공식적 인 환경은 좋지만 모든 사람은 여전히 ​​전문적이어야합니다. 사람들이 일부를 배출 할 수 있지만 토론이 단순한 세션이 아닌 생산적인지 확인하십시오.


3
피드백을 수락하고 이에 대한 행동으로 +1. 관리자가 할 수있는 가장 중요한 일일 수 있습니다.
PSU

1
이 답변의 예상치 못한 의미는 당신이 공을 피드백을 받아 들이고 행동 할 때 공을 얻었으므로 올바른 일을 계속한다는 것입니다. 당신이 제기 한 실제 의사 소통 문제는 아마도 개발자들이 당신이 피드백을 받아들이고 행동하는 위대한 관리자 중 한 명이라는 것을 알게되어 기쁘게 놀랐을 것입니다. 피드백에 잘 응답하면 더 많은 피드백을 제공 할 것입니다.
jhocking

7

내 경험상 관리자를 좋아하거나 싫어하는 가장 중요한 요소는 일반적으로 개발을 이해하고 내가하고있는 작업을 이해하는 것입니다. 일부 긍정적 인 결과는 다음과 같습니다.

  • 변경 시간이 오래 걸리거나 구현할 수없는 이유를 정당화하기 위해 너무 많은 시간을 낭비하지 않아도됩니다. 기술적으로 모든 변경 사항을 구현할 수 있으며 상위 관리는 일반적으로 구현 방법을 요구합니다. 그러나 적어도 그러한 상황에서는 직속 상사가 당신을 밀어 붙이고있는 대신 더 많은 시간을 요구합니다.
  • 상황이 좋지 않은 경우 (WTF 해킹, 생산 문제 등) 더 나은 지원을받을 수 있다는 것을 알고 있습니다. 일반적으로 비 기술적 인 사람은 그러한 상황에 대해 개발자를 비난하는 경향이있는 반면, 좋은 관리자는 실제로 진행중인 일을 이해하고 자신의 개발자를 지원합니다.
  • 본인은 본인의 업무와 성과가 적절한 사람에 의해 평가되어야한다는 것을 알고 있습니다.

제 생각에, 더 이상 일반적으로 프로젝트 일정이나 예산이 부족한 프로그래밍을하지 않으면 개발자가 좋아할 가능성이 매우 낮습니다. 이 경우 신속하게 진행하여 다른 관리자가 직접 관리자가되도록하는 것이 좋습니다. 이 단락에서 나쁘게 들리지만 그것이 내가 보는 방식입니다. 당신은 좋은 사람인 것 같고 진실이 필요합니다.


5

나는 또한 한 벌의 남자 중 한 명이며 15 년 이상 근무 해 왔습니다. 처음 시작할 때 소프트웨어 개발자였으며 ​​기회가있을 때 코드를 작성합니다. 그래서 나는 양쪽에 대해 이야기 할 수 있다고 생각하며 이러한 상황에 약간의 경험이 있습니다. 또한 직원이 선출 한 "올해의 직원"과 같은 자격 증명을 통해 이러한 상황을 처리 할 수 ​​있습니다.

필자가 자주 목격 한 것은 가치 시스템과 운영 방법 / 접근 방식에 경영진과 개발자간에 실질적인 차이가 있다는 것입니다.

많은 개발자들에게는 성실, 정직 및 유연한 작업 환경이 목록에서 매우 높습니다. 불행히도 최고 경영자 목록에서 동일한 값이 그리 높지는 않습니다. 그리고 이것은 특히 중간 경영진 (당신과 나)이 최고 경영진을 완전히 결정하기로 결정한 경우, 불가피하게 큰 충돌로 이어집니다. (내 관점에서 볼 때)이 유일한 방법은 팀 앞에서 확고한 입장을 취하고 그들을 완전히 뒷받침하고 열린 의사 소통을 통해 신뢰 관계를 구축하는 것입니다. (정치가 성실성을 완전히 압도하는 최고 경영진이 얻는 것과는 정반대입니다).

동시에 운영 상태를 유지해야하므로 경영진이 이해하고 게임을하는 언어로 커뮤니케이션 할 수있는 방법을 찾아야합니다. 이것이 중간 관리의 진정한 과제입니다.


5

나는 개발자의 행복으로 생산성은 모두 작은 것들에 기인한다고 생각합니다. 수학은 관리에 아주 훌륭합니다. 아침에 도넛 (-25 센트)을 주면 하루 종일 두 배 (+ 많은 달러) 열심히 일할 것입니다. 우리가 불만족 할 때 느리게 일함으로써 사물을 적극적으로 습득하는 것이 아니라, 매우 복잡한 시스템에서 일하고 있으며 무언가에 대해 좌절 할 때 집중하기가 매우 어렵다는 것입니다. 화가 났을 때 코드를 많이 작성하지 않는 것이 좋습니다.

그러나 견적은 스스로 해결해야합니다. 비현실적인 추정을 제외하고 도넛을 나눠 주면 내가 가진 모든 문제를 해결할 수 있습니다 . 참 또는 거짓은 개발자가 보는 방식입니다. 경영진은 더 짧은 추정치로 새로운 보트와 같은 모든 것을 얻을 수 있지만 개발자는 한 달의 수면과 같은 모든 것을 잃을 수 있습니다. 그러나 관리는 담당하므로 매번 예상 전쟁에서 승리합니다. 개발자가 마감일을 결정할 때 견적 시스템이 가장 효과적이라고 생각합니다 (정확한 견적을 내리기가 어려우므로 관리자는 어떻습니까?) 조금 벗어난.


1
도넛의 경우 +1 우리는 실제로 케이크를 사용합니다. 우리는 그 달에 모든 사람의 생일을 위해 한 달에 한 번 케이크를 가지고 있습니다 (그리고 그 달에 생일이 없다면). 모두가 케이크를 얻는 것을 좋아할뿐만 아니라 함께 모여서 먹는 것도 모든 사람들이 모여 이야기 할 수 있는 비공식적 인 기회를 제공합니다 . 여기에는 관리가 포함됩니다. 저의 관리자와 그의 감독은 모두이 사람들에게 와서 다른 사람들처럼 이야기합니다. 의사 소통이 아니라 평범한 사람으로 생각하기 때문에 커뮤니케이션에 많은 도움이됩니다. 그들은 또한 두 명의 개발자가 도넛보다 느린 컴퓨터에 대해 이야기하기 시작했을 때 들었습니다.
Tridus

@Tridus-예, 매월 우리 회사의 CEO와 COO는 지난달 생일을 보낸 사람을 dinnner로 데려갑니다. 모두가 그것을 받아들이는 것은 아니지만 약 250 명을 가진 회사에서 저의 상사 상사 상사와 함께 앉고 우리가 더 효과적으로 운영 할 수있는 방법에 대해 제 뇌를 선택하게하는 것은 매우 시원합니다.
Morgan Herlocker

1
"비현실적인 견적을 제외하고 도넛을 나눠 주면 모든 문제를 해결할 수 있습니다."
KK.

4

질문, 의견 또는 우려 사항이있을 수있는 프로그래머에게 어떤 반응을 보이는지 고려하십시오. " 지금 무엇을 원 하세요 ?" 또는 "왜 나를 귀찮게 ?" 어떤 종류의 응답? 개발자가 음성 우려와 의견을 제시하도록 얼마나 잘 장려하고 있습니까? 그것은 시작일뿐입니다.

둘째, 이러한 토론을 할 장소에주의하십시오. 내 관리자가 모든 것을들을 수 있다는 것을 알고 있다면 다음 큐브의 누군가와 내 작업 기계에 대해 매우 공개적으로 논의하고있을 것입니다. 사람들이 공개적이고 정직한 피드백을 제공하기를 원한다면, 그들의 답변이 공개적으로 방송되거나 그들에 대해 사용되지 않을 것이라는 것을 알고있는 프라이버시가 있어야합니다.

셋째, 어떤 종류의 감성 지능 기술을 가지고 있는지 고려하십시오 . 프로젝트 관리자를위한 감성 지능 : Anthony Mersino의 뛰어난 결과를 달성하기 위해 필요한 사람들 기술 어제 점심에서 얻은 책 추천이자 EQ에 대해 배웁니다. 심리학에 깊이 들어가고 싶다면 Enneagram, social styles, MBTI와 같은 다양한 성격 프로파일 도구를 사용할 수 있습니다.

마지막으로 회사의 문화가 무엇인지 고려하십시오. 깔개 밑에서 뭔가가 휩쓸 렸습니까? 불만을 가진 사람이 실제로 어려움을 겪을 수있는 큰 어려움이 있습니까? 어떤 행동이 상을 받거나 격려되며 어떤 행동이 용납되고 받아 들여 집니까? 이 중 일부는 관찰이지만 일부는 사무실이나 도청이 없을 가능성이있는 방에서 개최해야하는 대화가 필요할 수도 있습니다. 당신은 처음에 이것을 사용하려고 반복 할 것입니다. 만약 문화가 주로 모든 사람들이 "빨리 빨아 들였다"고 알고 있다면 새로운 연습을하고 사람들과 대화를 나눌 때 나쁜 일이 아닙니다. 이것은 다른 답변보다 훨씬 부담 스럽지만 이것이 내가 할 것입니다.


3

개발자들은 당신이 그들의 옹호자라고 생각합니까? 즉, 그들이 구타하지 않고 자신의 우려 / 좌절을 자유롭게 당신과 공유 할 수 있음을 알고 있습니까? 그들은 당신이 그들을 위해 싸우고 있다고 생각합니까? 그들은 당신이 그들의 일을 고맙게 생각한다고 생각합니까? 그들은 당신이 진정으로 그들의 경력에서 성공하기를 원한다고 생각합니까?

그들이 감사하다고 느끼면 아마도 더 나은 의사 소통을 할 것입니다.


3

개발자로서 나는 대단한 대단하고 사회적 기술이 부족하며 그것에 대해 사과하지 않습니다. 결국, 나는 재능이고, 당신은 나의 재능을 위해 나를 고용했습니다. 업무를 수행하기 위해 소셜 버터 플라이가 필요한 경우 개발자 대신 프로젝트 관리자로 가득 찬 방이 있습니다.

나는 일부 개발자들이 사회적으로 매우 친숙하다는 것을 알고 있지만, 중간 값은 내성적 인 괴상한쪽으로 기울어 져 있다고 생각합니다.

누군가 나에게 무언가를 요청하면 절대 추론하지 않고 요청 된 것을 정확하게 수행합니다. 일부 프로젝트 관리자의 경우 항상 문제로 끝나는 것 같습니다. 왜냐하면 그들은 절대로하지 않을 프로젝트에 대해 추론하기를 기대하기 때문에 때로는 정확히 무엇인지 밝혀도 예상대로 결과가 나오지 않습니다. 그들은 요청했다. 나는 이것이 일부 프로젝트 관리자에게 일어나는 이유는 그들이 고품질의 HLD, BRD를 제공하지 않고 흑백보다는 프로젝트 관리의 사회적 측면에 너무 많은 가치를두기 때문이라고 생각합니다.

세계가 충돌하는 곳이라고 생각합니다. 저는 프로젝트 관리의 세계에서 개인적인 기술의 사회적 기술과 품질이 중요한 요소라고 생각하지만 저와 같은 개발자에게는 전혀 의미가 없습니다. 이 작업이나 그 작업이 얼마나 중요한지에 대해 생각 나게하지는 않습니다. 나는 심지어 사람들이 제안한 것처럼 점심이나 맥주를 마시고 싶지 않습니다.

내가 정말로 원하는 것은 좋은 고품질 HLD와 BRD입니다. 달성 할 수있는 일정과 마감일을 원하고 새로운 디자인이나 계획이 도입되면 일정과 마감일을 다시 조정하고 싶습니다. 요구 사항이 즉시 바뀌는 것처럼 보이는 프로젝트를 진행했습니다. 저에게 이것은 저품질 프로젝트 리더십을 다루고있는 저의 적기입니다. 개발자로서 당신이 할 수있는 최악의 일은 특히 새로운 일정이 있거나 일정을 약속 한 후에 매일 새로운 프로젝트 요구 사항을 가져 오는 것입니다. 마감일에 대한 보상없이 새로운 요구 사항이 도입되면 참을 수 없습니다. 더 많은 시간을 일하고 늦게까지 일하는 데 아무런 문제가 없지만 개발에 항상 양적인 것은 아닙니다. 일부 변경 사항은 몇 시간이 더 걸릴 수 있습니다. 적절한 R & D, 테스트, QA 등을 위해 몇 주가 소요될 수 있습니다. 케이크를 굽는 것과 항상 같은 것은 아니며 요구 사항을 한 번만 변경하면 전체 레시피를 변경하는 것과 같습니다. 프로젝트 관리자가 기한이 지남에 따라 추가 개발이 허용되지는 않지만 초기 프로젝트 요구 사항이 아닌 개발을 요구하고 있기 때문에 프로젝트 관리자가 녹아 내고 전화 회의에 화를 낸 것을 목격했습니다.

나는 단지 자신의 개인적인 편견과 경험을 예로들 수 있으므로 모든 개발자를 대표하여 말하는 것을 추론하지 마십시오. 나는 내 자신의 경력의 소우주를 통해서만 이러한 것들을 볼 수 있지만이 게시물은 내가 잠언 수건에 던지게 한 정확한 조건을 설명합니다.


2

개발자와 얼마나 자주 이야기하고 있습니까? 나는 프로젝트 상태 회의, 결과물에 대한 질문 또는 당신이 그들에게 가져 오는 다른 주제를 의미하지는 않습니다. 프로그래머와 함께 앉는 빈도, 일이 어떻게 진행되는지 물어보고 그냥 듣는 것 입니다.

다른 많은 답변이 실제로 좋습니다. 민첩한 개발을 조사해야합니다. 개발자가 자신의 역할을 배우고 성장시켜야합니다. 그러나 실제로 개발자의 말에 귀를 기울이지 않는다면 (또는 그렇지 않다!) 먼저 처리해야합니다.

일대일에 대한 유용한 참조-http: //www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html



1

위의 게시물에있는 모든 훌륭한 아이디어와 의견!

아이디어는 다음과 같습니다. IT 직원을 현지 커뮤니티 칼리지의 커뮤니케이션 워크샵 (회사가 지불 한)으로 보내십시오.

a) 워크샵의 평판이 양호해야하며 b) 직원을 함께 보내지 않아야합니다. 워크숍의 가치를 떨어 뜨릴뿐만 아니라 다른 사람들에게 혼란을 야기 할뿐 아니라 다른 반원들과 어울리지 않는 경향이 있습니다.

생산적인 팀 지향적 의사 소통은 누구나 배울 수있는 기술이지만, 대부분의 학문적 길에서 부족하다고 느끼는 주제입니다.

이 아이디어는 결코 마법의 총알이 아니지만 퍼즐의 좋은 기초 조각입니다. 직원들은 서로 더 나은 의사 소통하는 법을 배우게 될뿐만 아니라, 보너스는 직원의 업무를 더 잘 이해하고 존중하기 시작합니다 (PM의 핵심이되는 의사 소통).

그냥 내 2 비트 :)


3
그것은 문제가 프로그래머가 아니라고 가정하고 위의 대답을 읽으면 이미 큰 통찰력을 얻었습니다.
AgentSmith

1

이미 몇 가지 답변 으로 나온 추천에서 답변을 드리겠습니다 . Michael Lopp (일명 rands )은 자신의 블로그 Rands in Repose 및 책 인간 관리 ( 책 소스 ) 에서 개발자 관리 및 "머리를 숙여 "하는 것에 대해 글을 썼습니다 . 이 책에는 2007 년 이전의 게시물에서 편집 한 내용이 대부분 포함되어 있으며 블로그의 관리 관련 부분 (예 : 도박, 다른 내용을 읽고 싶은지 여부)에 대한 정보를 얻을 수있는 좋은 방법을 제공합니다. 그의 글은 일반적으로 위대하고 종종 유머이므로 그를 읽을 위험이 거의 없습니다.


1

맥주를 위해 팀을 데리고 나가십시오.


2
모든 개발자와는 거리가 멀다. 일부는 어려워하는 다른 약속도 있습니다.
CVn

+1 : Ya know ... 이것은 은색 총알이 아니며 (그렇다고 말한 적이 없다) 여전히 상처를 치료할 수있다.
Jim G.

1

나는 파티에 늦었지만이 질문을 보았습니다.

내가 잘 다루지 않은 것 중 하나는 다음과 같습니다.

그런트들은 정장에 전체 진실을 말하지 않습니다. Rands는 이것을 DNA로 밝히지 만이를 직접 다루지는 않지만 다른 주제에 있습니다.

양복을 입고 수표에 서명합니다. 당신은 회사의 이익을 대표합니다. 엔지니어를 대표하지 않습니다. 그랬다면 수표에 서명하지 않았을 것이고, 그들은 수표에 서명 할 것입니다.

이것은 물론 당신이나 엔지니어에게 뉴스가 아닙니다. 그러나 엔지니어가 특정 문제를 일으킨다는 사실을 알면 직장과의 문제로 인해 심각한 충돌이 발생할 수 있습니다. 위험 / 보상 상충 관계는 엔지니어에게 유리하지 않습니다. 엔지니어는 직장 문화 싸움을 시작하지 않고 제품을 생산해야합니다. 그 일에 참여하는 것은 일을 잘못하는 빠른 길입니다.

따라서 관리 작업의 일부는 엔지니어가 회사 정치 및 경력의 반발을 일으키지 않고 문제에 대해 공개 할 수있는 방법을 제공하는 것입니다. 그것은 모든 후, 인상을 가지고 좋은, 그리고 거기에 있는 이 사람이 맞는 생각하지 않는 경우에, 다른 회사.


1

DeMarco와 Lister의 "Peopleware : Productive Projects and Teams"라는 질문과 주제를 정확히 다루고있는이 위대한 책을 언급 한 사람이 아무도 없습니다 . 편집에서 : 소프트웨어 개발의 주요 이슈는 기술적 인 것이 아니라 인간적인 것 입니다. 아마존에 대한 처음 세 가지 리뷰는 내가 당신의 상황에 처해 있다면이 책을 사도록 설득하기에 충분할 것입니다.


0

여기에 많은 답변이 아주 좋은 점이 있지만, 도움이 될만한 몇 가지 자료를 던져보고 싶습니다. 나는 몇 가지 상황에 처해있어서 큰 혼란에 빠지거나 관련된 사람들 간의 의사 소통으로 인해 매우 효율적으로 해결되었습니다. 세 권의 책은 특히 개인적으로 스트레스가 많은 상황에서 개인적으로 의사 소통 기술을 향상시키는 데 도움이되었습니다.

질문을 읽음으로써 의사 소통의 가치가 있다고 생각합니다. 저는 개인적으로 의사 소통이 비즈니스 나 기술에 비해 관리자 나 리더에게 더 중요하다고 생각합니다. 당신이 이끄는 사람들은 대부분의 프로젝트를 수행하는 데 필요한 어려운 기술을 가지고 있어야합니다. 훌륭한 기술 리더 또는 프로젝트 관리자는 팀 내이든 팀이나 고객 또는 팀과 비즈니스 주체 (또는 이들의 조합) 간에도 커뮤니케이션에 집중할 수 있어야합니다.



0

나는 수년 동안 개발자, 수석 개발자, 기술 책임자 등 다양한 역할을 수행했습니다.

귀하의 질문에서-개발자가 당신이 도울 수 있다고 생각하지 않기 때문에 물건을 말하지 않는 것이 분명합니다.

두 가지 이유 때문일 수 있습니다.

  1. 그들은 당신이 사물을 고칠 힘이 없다고 생각합니다. 그러나, 아마도 이것이 당신이 아마 그것을 알았을 것이고 개발자가 당신에게 그것에 대해 징계했을 것이기 때문에 이것이 가능하지 않다고 생각합니다.
  2. 귀하는 개발자가 문제를 가지고 왔을 때 다음 중 하나 이상을 수행하는 사람입니다.
    • 그들이 문제를 가지고 왔을 때, 당신은 그들에게 말합니다-나는 문제가 아닌 해결책을 좋아합니다.
    • 당신은 그들을 잘 듣고 & 문제를 해결하여 그들을 작업. 당신은 그들에게 문제를 해결해야 할 책임이 주어진다는 것에 대해 pep 이야기를합니다. 시간이 지남에 따라 당신은 그들이 문제를 가지고 당신에게 갈 때, 그들은 추가 작업으로 끝날 것입니다, 그래서 그들은 당신에게 문제가 와서하지 않습니다.
    • 당신은 그것이 문제라는 것을 부인합니다. 이에 대한 설득력있는 이유를 제공합니다. 그러나 이것이 계속 발생함에 따라 시간이 지남에 따라 문제가있는 당신에게 접근 할 점이 없다는 것을 배우십시오.
    • 당신은 "예, 이해합니다"라고 말합니다. 당신은 이런 종류의 일이 때때로 일어나고 아무도 할 수있는 일이 없다고 말합니다. 이것이 패턴이라면, 너희들은 다시 그것을 이해한다.

위의 일부 또는 모두 인 경우이를 수정해야합니다.


-1

내가 가장 싫어하는 것은 사람들이 나와 개발자, 최종 사용자 사이에 있다는 것입니다. 최고의 관리자가이 작업을 수행하고 사용자가 원하거나 할 수있는 일과 일치하도록 솔루션을 변경합니다.

나에게 최악의 관행은 종종 "좋은"것으로 차려 입습니다. 일반적으로 관리자가 스스로 또는 BA 또는 누군가가 사전에 동의 한 타임 스케일로 개발자가 해석하고 구현해야하는 사양을 작성합니다.

맞춤형 솔루션이 종종 개발자조차도 시간이 얼마나 걸리는지 알지 못하고 일반적으로 고객은 자신에게 가장 적합한 것을 알지 못합니다. 이것이 반복 개발이 큰 이유입니다. 대부분의 거래가 이루어지는 방식은 아니지만 좋은 관리자는 위와 같이 일하기 위해 싸울 것입니다.

마지막으로 일부 개발자는 의사 소통에 능숙하지 않으며 고객과 관련이 없습니다. 명확한 요구 사항, 특히 명확한 기술 요구 사항의 문제에 가장 적합 할 수 있습니다. 아마도 당신은 더 나은 의사 소통을하는 개발자가 필요하고 순수한 기술적 인 문제가 아닌 비즈니스 문제를 해결하기 위해 노력하고 있습니다.


-1

팀을 행복하게 유지하는 것은 매우 쉽습니다

그들의 질문에 대한 답변도 여러 번 들으십시오. 팀원이 문제와 가능한 해결책을 찾도록 권장합니다.

팀 나들이는 좋은 생각입니다 (게임 계획 일 수도 있습니다)

늦은 밤과 주말에 프로젝트가 필요하고 실제로 팀에 많은 가치를 부여하지 않는다고 생각한다면 팀원의 노력에 대해 먹고 팀에 감사를 표하는 것이 좋습니다. 일부 PTO 사전을 마련

모든 팀원과 격월 1 : 1로 편안하게 지내십시오.

마지막으로 프로젝트를 기능적으로 그리고 다소 기술적으로 이해하는 것이 좋습니다.

더 궁금한 점이 있으면 알려주세요


1
-1 : 당신은 매우 "기계적인"구제책을 처방하고 있으며 개발자를 오토 마톤처럼 취급하고 있습니다.
Jim G.

-1

나는 또한 과학 공학 배경을 가지고 있지만 구체적으로 IT 소프트웨어 배경을 가지고 있지 않은 (프랑스어를 영어로 용서합니다) 소프트웨어 관리자입니다. 그래서 처음에는 코딩에 특별한 친화력이 없지만 Deming 학교의 통계적 품질 엔지니어로 데밍에서 상속받은 척하는 모든 "현대"학교에 대해 다른 교육을 받았습니다. 최악의 상황은 6 시그마이며, 린은 더 좋았지 만 불행히도 무슨 일이 있었는지 http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

“원래 Six Sigma는 Motorola의 Toyota Quality Management (TQM)에서 6 시그마 수준의 품질을 달성 한 다음 Allied Signal 및 GE를 통해 통계를 기반으로 Black Belts의 프로젝트로 전환하여 모든 프로젝트에서 비용 절감 프로그램이되었습니다. 명확한 ROI가 필요합니다. 다시 말해, 우리는 프로그램을 리더십 철학에서 일회성 프로젝트로 전환하여 비용을 절감했습니다. 그것은 원래의 완벽한 놈 이었으나 리더십과 문화가 없어 지속되고 지속 가능한 변화를 가져 오는 경우는 거의 없었습니다.

“툴킷 (예 : 가치 스트림 매핑, KPI 보드, 셀, 칸반)으로 축소되었을 때 비슷한 일이 발생했습니다.

"Lean과 Six Sigma는 훌륭한 일본 기업이나 데밍 (Deming)과 같은 교사들의 원래 생각을 반영하지 않습니다."

오늘날 민첩한 운동은 린과 비슷합니다 (제프 서덜랜드 코스와 데밍에 대한 그의 존경 참조 http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -century-of-scrum / ), Waterfall보다 낫지 만 여전히 원본 텍스트에서 Deming을 읽는 대신 전문가의 14 가지 원칙을 인용하지 않기 때문에 Deming의 원래 가르침과는 거리가 멀다. 자체 가치가 거의없는 도구와 세미나를 판매합니다.

이제는 소프트웨어 분야와 관련하여 일반적인 원칙을 알고 있지만 실제로 적용하는 방법에 대한 실제 아이디어가없는 반면 소프트웨어를 작성하지만 원칙을 무시하는 사람들은 단순히 듣는 것에 문제가있는 사람들이 있습니다 실제 원칙을 알려주지 않고 도구를 판매 한 가짜 전문가들은 실제로 자체 관리 도구를 만들어야합니다.

따라서 소프트웨어 프로젝트 관리자는 Microsoft Project (또는 Agile을 사용한 Burdown Chart)에서 계획을 세우는 것뿐만 아니라 Powerpoint에서 상위 관리에 대한 훌륭한 프레젠테이션뿐만 아니라 일부 가치도 갖는 소프트웨어 코딩의 일상적인 운영에 대해 심도있게 노력해야합니다. 개발자 팀. 기술적 인 문제이더라도 개발자 팀에 문제가있는 경우 프로젝트 관리자는 외부의 눈으로 진단 방향을 잡을 수 있습니다. 그는 작은 세부 사항을 이해하지 못하더라도 코드를 볼 수 있지만 개발자가 그 단서에 대해 생각하지 않았다는 사실을 깨닫게하는 몇 가지 순진한 질문을 할 수 있습니다 (개인 예제가 많지만 너무 길어서 오히려 내 블로그에 기사를 작성하십시오).

또 다른 것은 기술 프레임 워크를 읽고 새로운 프레임 워크, 새로운 아키텍처 패러다임과 같은 분야에서의 진화에 대한 일반적인 인식을 얻으려고 노력한다는 것입니다. 나는 통합 테스트에 참여하고 문서를 직접 작성합니다 (프로그래머가 싫어하기 때문에 핵심 요소를 제공합니다). 팀을 돕기 위해 실제로 할 수있는 모든 것.

일반적으로 개발자는 열심히 일하는 것처럼 느끼고 사실이지만 종종 추상화에 머물면서 쉬운 부분을하고 있다고 말하지만, 필요할 때 구체적으로 도와 주려고 노력합니다. 간섭 느낌을 생성 할 수 있으므로 좋지 않습니다.

결론적으로 개발자들과의 슬로건 (실제로는 Deming의 14 가지 원칙 중 하나임)을 제거하고, 문서 나 고위 경영진과의 만남이 아니라 프로젝트의 구체적인 소프트웨어에 관심이 있다는 것을 보여주십시오.


-1 : Deming으로 인해 OP의 문제가 해결되지 않습니다. 이 게시물에서 모든 Deming 참조를 제거하십시오. 그들은 전혀 적용되지 않습니다.
Jim G.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.