당신이 일한 최고의 관리자들은 어떤 특성을 공통적으로 가지고 있습니까? [닫은]

Scott Hanselman과 Rob Conery의 Podcast 인 This Developer 's Life를 들었습니다 .

최신 에피소드에서는 성격 특성에 대해 설명합니다.

1.0.4-의미있는 것.

사람들이 우리 업계에서 의미하는 것은 무엇입니까? 공격적인 것은 어떻습니까? 자신감? 차이점이 뭐야? 보스 나 선장을위한 드릴 상사를 원하십니까? 우리는 Cyra Richardson과 Giles Bowkett와 대화합니다.

당신이 일한 최고의 관리자 들이 공통적으로 가지고있는 특성은 무엇 입니까?

편집 : 명확히하기 위해, 가까운 투표가 있었으므로 다른 직업의 관리자가 요구하는 특성이 아닌 개발자 관리자에게 공통적 인 특성이 있는지에 관심이 있습니다.

이것이 프로그래밍과 관련이 있는지 여부에 관해서는, 프로그래밍에 관한 것이 아닌 사이트 에서이 질문을하고 싶지 않습니다. 개발자 가 관리자에게 원하는 것에 관심이 있으므로 관리자에게 문의하십시오.

내 경험상 다음과 같은 조합이었습니다.

1. 입력이 아닌 결과 / 출력으로 측정합니다.
2. 당신이 존중하고 바라 볼 수있는 동기 부여, 영감을주는 리더.
3. 지원 / 훈련 / 경력 등 팀 구성원의 요구에 민감
4. 충돌을 빠르게 해결하고 어려운 상황을 확산시킵니다.
5. 당신의 일을 이해하십시오-그들은 실제로 당신의 일을 할 수는 있지만 당신을 고용했습니다.
6. 중요하지 않거나 팀의 생산성을 손상시키는 것을 처리 / 필터링합니다.

Joel Spolsky는이를 " 추상 계층 "이라고합니다. 프로그래밍을 유지하는 데 필요한 작업을 수행하십시오. 회사에서 무슨 일이 일어나고 있는지 알려주지 만 정치에서 벗어나십시오. 나는 여전히 그것을해야하지만 적어도 요청이 황소라는 것을 인정하십시오.

저를 위해 정치적 싸움을 벌이고 저의 일을 방해하는 장애물을 제거하는 사람.

기간.

그들을 위해 일하는 사람들의 말을 기꺼이 듣는다.

저는 기술적으로 매우 경사가 많은 관리자를 보유하고 있으며 멀티 태스킹에 대해 잘 모르는 사람도있었습니다 ( "아,와! Alt-Tab 기술을 어디서 배웠습니까?"). 나는 공통점을 가지고 일하는 것을 실제로 즐겼다. 그들은 그들이 모든 것을 알지 못한다는 것을 알고 있다는 사실이다. 그리고 우리의 사람들이 실제로 그 일을하고있을 때 그들이 그 일에 관한 제시된 아이디어, 문제 또는 제안을 관리해야 할 때 기꺼이 듣고 자했다.

팀을 보호하고 책임을진다

팀 중 하나가 프로덕션 데이터로 서버를 충돌시킵니다. 귀하의 관리자는 전적으로 책임을집니다. 그는 결국 실수를 저지른 사람들의 상사에게 말을 거부하고 그의 앞에 서 있습니다.

시간이 아닌 목표에 따라 관리하며 주로 목표 달성에 관심이 있습니다.

내가 책상에 얼마나 오래 앉아 있는지에 대해 걱정하기보다는 주어진 작업을 수행하는 데 필요한 것에 관심이 있습니다. 이것이 장애물이나 장애를 제거하거나 오랜 시간 / 주말을 일하게하는 것을 의미한다면, 그들은 시간을 기꺼이 절충 할 것입니다. 일정보다 미리 업무를 수행하고 의사 예약 또는 가족 활동을위한 시간이 필요한 경우, 융통성 있고 이해력이 있습니다.

나는 직장에서 책임을지고 싶지만, 내가 책상에서 보내는 시간이 아니라 내가 달성 한 것에 대한 것이어야한다.

내가 참석할 필요가없는 회의를 피하십시오. 관리자가이 작업을 수행 할 수만 있다면 훨씬 더 가치가있을 것입니다.

내가 결정을 내리기 위해 고용되고 지불되었음을 인정합니다.

당신이 아니오라고 말할 때 그들은 당신을 지원합니다

관리자의 가장 강렬한 특징 중 하나는 제품이나 팀에 영향을 미치더라도 자신의 직원을 대항하고 항상 자신의 상사 앞에서 절하는 용기가 없다는 것입니다.

제발 소리지르 지마 (큰 마감일, 어리석은 테스터 등에 대해 얼마나 스트레스를 받았는지에 관계없이)

그냥 내 일을하는 사람

프로그래밍이 무엇인지 이해합니다. 얼마나 많은 관리자가 그 문제에 대해 전혀 모른다는 것에 놀랄 것입니다.

내가 결정을 내리기 위해 고용되고 지불되었음을 인정합니다.

나는 시간당 $ 7의 음식 서비스 직원이 아닙니다. 나는 결정을하기 위해 여기에 있습니다. 내가해야 할 일에 대한 모든 세부 사항을 들으면 타이피스트가 될 수도 있습니다.

(깊은) 공감 기술.

나는 내가 일한 최악의 보스의 관점에서 이것에 가야한다. 좋은 사람은 이러한 자질을 갖지 못할 것이다.

_ sincgle 최악의 결정을 내릴 수 없다는 것은 누군가 대화 할 때마다 마음이 바뀌는 상사였습니다. 우리는 3 년간의 프로젝트에서 하루 4-5 번 방향을 바꿨습니다.

팀원이하는 일에 대한 크레딧을 훔칩니다. 일단 상사가 큰 상을 받았을 때 그들은 공개적으로 발표했습니다. 그들이 언급 한 모든 것, 나는 실제로했다. 말할 필요도없이이 방법은 극단적 인 동기 부여입니다.

상황이 좋지 않을 때의 패닉. 패닉이 더 심해지면 더 나 빠진다. 그것은 실제로 일을 끝내는 데 도움이되지 않습니다.

자신의 사람들을 뒷받침합니다. 그는 신용을 얻습니다, 우리는 책임을집니다. ANd는 명령 체인을 지원하지 않습니다.

소프트웨어 개발 프로세스를 이해하지 못하며 C # (또는 선택한 다른 언어)을 사용하고 있음을 알기에 충분히 배우지 않아도됩니다. 단기간에 모든 작업을 수행 할 수 있으며 User_interface 페이지 외부에서 간단한 변경으로 구현하는 데 시간이 오래 걸리지 않는다고 생각합니다. 마감일 전날까지 변경에 참여한 다음 "우리가해야 할 일 ..."이라고 말한 사람은 기본 아키텍처를 변경하는 사람입니다.

미세 관리 또는 전혀 관리하지 않습니다. 둘 다 똑같이 나쁘다. 너무 늦을 때까지 한 명의 직원에게 문제가 있다는 것을 몰랐던 상사들이 너무 많았습니다. 나는 또한 5 분마다 저를 귀찮게하지 말라고 지시하는 보스를 가졌습니다.

정치적으로 순진합니다. 상사가 그 위의 사람들과 정치적으로 잘하지 않으면 필요한 사람들을 얻는 데 어려움을 겪을 수 있습니다. 최악의 공간이 생길 것입니다. 그를 제거하는 쉬운 방법. 상사는 사무실 정치에 능숙해야합니다.

고객이 그 숫자를 좋아하지 않기 때문에 프로젝트 시간을 반으로 줄일 수 있다고 생각하는 사람은 요구 사항을 변경하지 않고도 해당 시간에 프로젝트를 완료 할 수 있습니다.

신용 기한이 충분하고 지식을 할당 할 수있는 충분한 신용

나는 청취를 잘 추가했지만 대신 그것을 상향 조정했다.

1. 사내, 오픈 소스 또는 타사에서 개발 한 라이브러리에서 발견 된 기능에 대해 지속적으로 크레딧을 얻는 사람이 있다면 보상을받지 않고 격추해야합니다.
2. 실제로 단위 테스트를 작성하고 찾기 때문에 누군가가 모든 버그 책임을 맡고 있다면 벌을받지 않고 보상을 받아야합니다. 버그를 찾는 것은 처음에 버그를 쓰는 것과 다릅니다.
3. 개발 또는 개발자 그룹이 기한을 정하기 위해 엉덩이를 터뜨릴 경우, 마감 시한을 먼저 제시 한 관리자가 아니라 박수를 보내야합니다.

그들은 그들의 일을 끝내기 위해 사람들을 신뢰하고 "고양이를 her 으려고"하지 않습니다.

사람들에게 실수를 할 수있는 공간을 제공하고 (거의 큰 실수는 아님) 그들로부터 배울 수 있습니다.

잘 듣는 사람

과

실제로 적어도 일주일에 한 번 이야기를 나누는 사람

나는 좋은 관리자와 나쁜했다. 이들은 나쁜 관리자들에게 언급 한 몇 가지 특성입니다.

당신이 일을 할 수 있도록 방해하지 마십시오

좋은 관리자는 코드를 작성하는 데 적합한 장비가 있다는 것을 알게 될 것입니다.

잘못된 세부 사항을 미세 관리

이런 종류의 관리자는 전자 메일에 서명을 첨부하지 않고 전자 메일에 추가 작업을 무시한 채 처리하지 못하게합니다.

개발 과정에 관심이 없습니다

이것은 소프트웨어 개발자를 담당하는 관리자에게는 나쁜 신호입니다. 그는 다른 개발 접근 방식을 조사하지 않고 소프트웨어의 다음 릴리스가 어떤 버전 번호인지 알지 못하며 Joel on Software 또는 Peopleware와 같은 개발자 관리와 관련된 블로그를 읽지 않습니다.

그가 저에게보고 할 것이라고 생각합니다

이런 종류의 관리자는 사람들이 모든 것에 대해 그에게보고하게합니다.

시간을 잘못 할당하다

개발 프로젝트를 처음부터 끝까지 완료하는 데 한 달이 걸리면이 관리자는 한 달의 3/4를 디자인 및 요구 사항 팀에 할당하여 1000 개의 라인 단어 문서를 생성하고 개발자 팀이 일주일 안에 모두 구현할 것으로 기대합니다. 또한 문서가 사용할 수 없을 때까지 많은 양의 세부 사항을 추가하여 요구 사항이 '완벽해질'때까지 반복합니다. 그러나 나중에 개발 과정에서 디자인 및 요구 사항 문서에서 버그를 발견하고 완벽한 문서를 작성하는 데 중점을 둔 것은 실수라는 것을 알 수 있습니다.

가장 중요한 두 가지 특성은 관리 원칙에 대한 기본적인 이해와 "우리 중 하나"라고 생각합니다. 불행히도, 두 사람은 너무 자주 함께 일어나는 경향이 없지만, 그렇게 할 때, 일하기 좋은 사람을 찾았습니다.

내가 일하는 곳에서 프로젝트 관리자는 전 개발자입니다. 그는 관리자가 알아야 할 일의 우선 순위를 정하고 지시하는 데 능숙하지만 관리 수준의 비전이 모두 필요한 것을 구현하는 방법에 대한 질문을 할 때 무슨 일이 일어나고 있는지 잘 알고 있습니다. 그리고 나에게서 기술적 인 입력.

상사는 또한이 스킬 셋을 모두 가지고 있습니다. 그는 실제로 다른 개발자가 코드에서 멀어지지 않을 때 코드베이스에서 작업하고 커밋 하는 현재 개발자입니다. 그는 우리에게 좋은 작업 환경이 무엇인지 직관적으로 알고 있기 때문에 우리가 좋은 작업 환경을 가지고 있는지 확인합니다. 그것이 그가 일하고 싶은 조건입니다!

나를 위해 싸운다. IT 부서에 들어 가지 않아도됩니다. 필요한 도구를 제공합니다. 회사 정책을 전달합니다. 요청이있을 때 결정을 내리고 요청이 없을 때 유지합니다.

면책 조항 : 나는 이전에 관리 역할을했지만 현재는 아닙니다. 그로부터 나는 그것이 테이블의 다른 쪽에서도 꽤 어려울 수 있다고 말할 수 있습니다.

해야 할 일이 분명하고, 기술적 세부 사항을 해결하고, 필요할 때 상황을 제시하며, 반 이상을 끝냈을 때 요구 사항을 변경하지 않는 사람이 있습니다.

두가지:

1) (또는 최근에는) 개발자 자신입니다.
2) 관리 위쪽 뿐만 아니라 아래쪽 .

포인트 1, 당신을 줄 것이다 개발자, 정말 매니저로 이해하는 작업이 무엇인지와 구성, 그리고 이해 당신은 (그리고 필요 하지 최선을 다해 작업을 할 필요). 현재 개발자 가 아니고 (실제로 관리자로서 실무 개발자가되어서는 안되며, 풀 타임 직종 인 경우) 이전의 개발 경험이 있어야하지만 공정 해야합니다. 최근 (즉, 지난 몇 년 동안) 최신 개발 언어, 도구, 방법 및 기술에 익숙해졌습니다.

포인트 2는 당신이 자신의 책임을 받아들이는 관리자를 제공합니다 사무실 정치와 그의 팀이되기 위해서는 불필요한 혼란과 싸움에서 자신의 팀을 방패 제공하는 그들이 (따라서 포인트 1 가능) 필요가있는 것들로하고, 비즈니스 및 그에서 기대를 관리 할 수 있습니다 그 이상 (이는 개발자 (개발자)와 비즈니스 의사 결정자 (고급 관리) 사이에 많은 수준과 관리 계층이 존재하는 대기업에서 더 중요합니다).

간단히 말해서, 특성 (1)을 갖는 것은 당신이 당신의 일을 끝내기 위해 필요한 것을 이해 하는 관리자를 제공 하고, 특성 (2)를 갖는 것은 당신에게 필요한 것을 제공 할 관리자를 제공 합니다.

Yale에서 의 Joel Spolsky의 대화 (및 관련 " 명령 및 정복 및 코코넛 무리 "기사)는이를 간결하게 요약했습니다.

Juno의 (나쁜) 관리에 대해 이야기 할 때 :

"사람들에게 무엇을해야할지 관리자가 존재한다고 가정했다."

Microsoft의 (일반적으로 좋은) 관리에 대해 이야기 할 때 :

"실제 재능이 훌륭한 작업을 수행 할 수 있도록 가구를 방해하는 관리자가 존재합니다."

나는 데드 우드를 인식하고 제거 할 능력이 있고 용기가있는 사람을 원합니다. 이 사람들은 제품을 손상시키고 완성을 늦추고 있습니다. 너무 많은 관리자는 누가 나쁜 개발자인지 알 수 없습니다 (또는 지저분한 책상을 가진 사람이 나쁘거나 자신이 실제로 똑똑하거나 가장 생산적인 개발자 일지라도 공간을 많이 차지하는 사람이라고 생각합니다) 또는 누군가에게 그들이 가고 있다는 사실을 알리기 위해 데드 우드가 해마다 머 무르도록 해달라고 권한을 부여하지 말아야합니다.

우리가 사용하는 언어 나 데이터베이스 백엔드 또는 기타 중요한 도구조차 모르는 관리자가 당황하고 싶지 않습니다. 3 년 동안 프로젝트에 참여한 후 우리가 어떤 언어를 프로그래밍했는지 물어 봤습니다. 나는 오랫동안 관리를 해 온 사람들이 여전히 모든 것에 대한 최신 정보를 기대하지는 않지만 최소한 우리가 무엇을 사용하고 있는지 알아야합니다. 그리고 그들은 그렇지 않으면 다른 사람들 앞에서 그런 것을 요구하지 않을 정도로 똑똑해야합니다.

용기가있는 매니저를 원합니다. 비현실적인 마감일을 뒤로 밀지 말고 받아들이지 말고 사람들이 직원을 괴롭 히거나 루즈 개발자가 짧은 시간을 보내지 않고 자신의 길을 가도록 내버려 두지 마십시오. 내가 화가 날까봐 두려워서 내가 잘못한 일을하고 있는지 말하지 마십시오. 관리자는 나쁜 소식을 처리하기 위해 부분적으로 존재합니다.

나는 집에 사는 삶을 이해하고 지친 개발자들이 실수를한다는 것을 이해하고 40 주보다 주당 60 시간 일하는 프로젝트를 수행하는 데 시간이 더 걸린다는 것을 이해하는 관리자를 원합니다.

무엇보다도 나는 선한 일을 인정 하고 개인적으로 나에게 그리고 자신의 상사에게 사슬을 말해 주는 관리자를 원합니다 . 그들이 나쁜 일이 좋은 일이라고 생각하고 잘못된 사람들에게 상을 줄 때 정말 싫어하지만!

친근 함은 내가 거기에 올려 놓은 것입니다. 상사가 매번 칸막이를 방문하기로 결정하면 공포감을 느끼는 것을 좋아하지 않습니다 . 예를 들어 마감일 동안 프로젝트를 완료하기 위해 여기저기서 호의를 구하는 친구를 돕는 것처럼 느끼면 내 성과가 조금 나아질 수 있습니다. 내가 달리하고 싶지 않은 시간.

여러 가지를 관리하는 데있어 경쟁력은 어느 정도 명백한 특성으로 보일 수 있지만 필자가 바라는 또 다른 측면 일 것입니다. 갈등 해결 및 화해 기술도 개발자가 개발자 또는 개발자에 대해 분석가에 대해 개발자 또는 개발자가 옳지 않은 문제가있을 수있는 문제가있을 수 있으므로 관리자가 처리 할 수 ​​있다는 것을 알고 싶습니다. 어떤 경우에는 작업에 대한 일부 측면이 여러 가지 해석을 가질 수 있습니다.

개발이 공장 작업이 아님을 이해하는 사람. 하루에 더 많은 시간을 투자해도 수확량이 크게 증가하지는 않습니다. 프로그래머는 숫돌에서 코를 자주 들어야하며 문제를 해결하고 일을 끝내기 위해 무엇을하고 있는지 생각하지 않아도됩니다.

좋은 관리자는 기꺼이 거절하겠습니다 . 그들은 소프트웨어 개발이 사악한 문제 라는 것을 알고 있습니다 . 따라서 관리자가 기술적으로보다 능숙하더라도 솔루션을 구현하는 사람이기 때문에 문제를 더 잘 알 수 있음을 깨닫습니다. 동시에, 내가 문맥을 놓칠 때 알려줍니다. 많은 경우 관리자는 내가 모르는 것을 기초로 의사 결정을 할 수 있습니다. 이 경우 세부 사항을 작성하거나 적어도 내가 모르는 것을 알고 있음을 알려주십시오 .

저는 경영진이 기술적으로 비 기술적 인 몇 곳에서 일했습니다. 현재 고용주는 기술 결정을 내리는 관리자가 해지 사유라는 정책을 가지고 있습니다. (이것은 당신이 들어 본 적이없는 소규모 회사가 아니며 약 3 분의 1이 제품을 운영하고 있습니다). 이 정책의 결과로, 적어도 내 의견으로는, 여기의 관리자는 다른 고용주보다 훨씬 "더 강력합니다". 그들이 기술적 인 의사 결정에 관여하지 않기 때문에 경영진에 의해 '약간 잘못에 대한'기술적 인 의사 결정의 연속적인 문자열은 없으며, 단지 큰 "제품 라인 수준"의 결정 만 내립니다.

내가 가진 최고의 관리자는 개발자를 위해 '간섭을 실행'하는 사람들입니다. 훌륭한 관리자는 '필수 회의'와 의무 회의의 차이점을 알려줄 수 있습니다.

기본 관리 기술은 개발자가 자신의 환경을 통제 할 수 있도록하는 것입니다. 이는 회사에 따라 생각 나게하거나 환상 일 수 있지만 매우 중요한 기술입니다.