프로그래머가 선임 프로그래머에게 기대하는 주요 사항은 무엇입니까?


41

최근에 나는 다음과 같은 5 가지 보스 유형과 최악의 보스 복장을 설명하는 방법을 읽었습니다 . 방금 소규모 소프트웨어 개발자 팀을 이끌 기 시작했습니다.

프로그래머가 선임 프로그래머에게 기대하는 주요 사항이나 팀을 관리하는 동안 피해야 할 사항이 무엇인지 알고 싶습니다.

또한 프로그래머를 만족시키고 팀을위한 생산적이고 완벽한 환경을 조성하는 방법을 알고 싶습니다.


19
joelonsoftware.com 자신의 블로그를 최대한 많이 읽으십시오.
P.Brian.Mackey

@ P.Brian.Mackey 멋진 링크!
아바타

2
수석 프로그래머하는 미야자키 관련 아바타 아마도이 아닌 필수, 그러나 확실하게 큰 플러스 :-)이다가
leonbloy

1
흥미 롭다 ... 내 상사는 그 시험에서 5 점 만점에 4 점을 얻었습니다 ... 나는 그에게 좋은 소식
Aeo

답변:


79

나를 위해 잘 작동하는 것 :

  • 의미있는 작업을 제공하고 소유권을 장려하십시오 . 문제가 발생하더라도 해결하지 말고 문제를 해결하고 상대방에게 통찰력을 제공하여 스스로 해결할 수 있도록하십시오.
    • 편집-추가-이것은 또한 포함하도록 의도되었습니다-세부 사항에서 벗어나십시오. . 당신의 사람들이 미시적 또는 지속적으로 확인할 필요없이 할당을 충분히 알고 있다고 가정 그들이 경우에 대한 지침의 집합 구축 해야 체크 - 어느해야에만 작업 중 하나를 수행 정도 진정 심각한 간섭이라고 엉망이 될 때 수 필요합니다. 가능하면 팀 간 지원 문제를 반복하지 않아도됩니다.
  • 솔직히 말하면 -몇 가지 목록이 있습니다.
    • "나는 화요일까지 시간이 없다", "나는 그런 짓을 한 적이 없다. 여기에 나의 가장 좋은 추측이있다"등
    • 팀과 회사에 적합한 위치에 대해 정직하십시오. 비즈니스 관련 정보를 알고있는 경우 가능하면 해당 사실을 알려주십시오.
    • 피드백을 솔직하게 말하십시오-부정적인 피드백을 줄 경우 단어 나 소프트 페달을 밟지 마십시오. 그것은 "잔인하게 정직한"과는 다릅니다. 여전히 동정심을 가질 수는 있지만, 무언가 잘못되면 그렇게 말하십시오.
    • 의미있는 일을하는 것보다 그 일이 빨간 테이프에 관한 것임을 알면 정직하십시오. 모든 사람의 삶에 무의미한 일이 떨어질 것입니다. 의미있는 척하지 마십시오. 그대로 사용하면 과거를 지나고 유용한 무언가에 집중하는 데 집중할 수 있습니다.
  • 들어 봐 . 적어도 50 %의 직업이 듣고 있습니다. 당신은 갑자기 기술적 인 일뿐 만 아니라 그것을하는 사람들에 대한 책임이 갑자기 생겼습니다. 팀이 겪고있는 문제뿐만 아니라 사람들이 문제에 어떻게 접근하는지, 그리고 팀으로서의 단점은 무엇인지를 들어야합니다.
    • 중요한 추론-청취는 포인트 1로 직접 이어질 수 있습니다-의미있는 작업을 제공합니다-엔지니어는 개발을보다 쉽게 ​​만드는 방법을 고안하는 데 능숙합니다. 모든 것을 승인 할 수는 없지만 아이디어가 좋은 곳에서는 엔지니어에게 과제를 제공해야합니다. 엔지니어는 본질적으로 당신을 위해 일한 것입니다. 그들은 의미있는 일을 만들어 내고 그것이 무엇인지 말해주었습니다.
  • "감사합니다"라고 말합니다 . 나는 분명해 보인다. 우리 모두는 돈, 더 나은 도구, 더 나은 업무 환경 및 판촉을 좋아합니다. 이러한 것들을 얻는 방법은 일련의 좋은 노력에 의한 것입니다. 각 노력은 "감사합니다". "감사합니다"는 완전 무료이며, 절대로 고갈되지 않으며, 관리자가 귀하의 노력이 확실히 동기를 부여하고 있음을 알았 음을 알고 있습니다.
  • 그것은 당신에게 위치를 가져 매일 일의 일부를 희생 의미하는 경우에도 큰 그림에 시간을 보내십시오. 팀원, 전체 프로젝트 방향, 코드베이스 상태, 프로세스 효율성 등 큰 그림에서 적절한 시간을 보내지 않으면 사실 일 수 있습니다. , 팀 환경-그들이해야 할 일을하지 않을 것입니다.
  • 팀을위한 버퍼가되는 법을 배우십시오 . 엔지니어링 팀은 엔지니어링을 할 시간이있을 때 가장 잘 작동합니다. 기업 관료주의는 공학이 아닙니다. 외부 사람들과 성가신 1 년 / 월 / 주 회의를하기 위해 할 수있는 모든 것이 더 좋습니다. 참고 : 이는 이해 관계자와의 민첩한 회의를 의미하지는 않습니다. 즉, 엔지니어링 팀이이를 위해 있어야합니다. 나는 당신의 팀 근처에 큰 소리로 들리는 기계를 놓으려는 시설이나 코드가 체크인되기 전에 팀이 종이를 세 번 채우기를 원하는 프로세스 그룹과의 만남을 의미합니다. 당신은 flak 흡수 시스템입니다.
  • 문제가있는 사람들이 악하지 않다고 가정 하고, 선을 행하기를 원하지만 아직 방법을 찾지 못한 사람들입니다. 당신은 모든 사람을 고칠 수는 없지만, 처음 몇 개의 완전한 스크류 업은 종종 무능하거나 고의적 인 악의처럼 의사 소통의 실패 요인입니다. 사람들이 악이 아니라는 가정으로 시작한다면, 위의 목록에서 많은 악의 보스 보스를 피할 수있는 희망이 있습니다.

그리고 아마도 가장 중요한 것은 ... 존중 입니다. 솔직히 팀원을 존중할 수 없다면, 사람들을 가르치거나 직원 수를 변경하든 관계없이 변경해야합니다. 첫날을 존중하면 다시 돌려받을 수 있고, 부족한 사람들을 대할 수 있으며, 대가로 절대 존경을받지 못할 것입니다.

종합하면, 당신이 대부분의 일을하면 대부분의 시간을 당신의 팀은 당신이 당신이 인간임을 보여줄 때 자신을 완전히 망치는 의심의 혜택을 줄 것입니다. :) 모든 보스는 자신의 단점이 있으며, 팀과의 관계를 해결하는 데 도움이되는 약점을 보완하는 데 도움이 될 수 있습니다.


1
큰 대답, 나는 이것에 자유를 줄 것이다 . 미세 관리되거나 모든 세부 사항에 대한 허가를 요구하는 것보다 더 나쁜 것은 없습니다.
agradl

3
정말 굉장 .. 나는 :) StackExchange 사용자를 다음에 대한 지원 (조엘과 제프 짧은 메모를) 제공 할 수 있으면 좋겠다
PrinceCoder

2
와우! ... 내가 @Stackexchange에 걸쳐 온 최고의 답변 중 하나였습니다
explorest

와우 이 의견을 제출하려면 문자를 몇 개 더 입력해야하므로 와우.
Amir Afghani

2
@PrinceCoder 모든 사용자는 자신의 피드를 가지고 있으며, 일부 RSS 리더에서이를 따를 수 있습니다.
svick

12

배우는 가장 큰 것 중 하나는 원하는 것을 줄 수있는 능력이 없기 때문에 종종 행복하게 할 수 없다는 것입니다.

내가 찾은 최고의 관리자는 가장 정직한 사람들이었으며, 이들은 최고 경영자가 그들에게 던지려고하는 모든 허물 과 무엇보다 팀에 기울이는 모든 허물 로부터 팀을 방어 할 것 입니다.


2
관리자와 선임 프로그래머 사이에는 큰 차이가 있습니다. 나는 당신이 설명하는 것처럼 관리자를 아직 만나지 않았습니다. 어디서 찾을 수 있는지 알려주십시오 ;-)
fretje

그것은 제목이 말하는 것만 큼 공평하지만, 문제는 보스에 대해 계속 이야기합니다. 나는 내 경력에 많은 훌륭한 관리자 / 개발자 리드가있었습니다.
ozz

+1 @James 누군가가 제목을 편집했습니다. 질문에 의해 리드 / 관리자에 관한 것이 있습니다. "보스"라는 단어는 치열 해 보이므로 수석 프로그래머라는 단어를 선택합니다.
아바타

6

나는 선배 나 리더가되는 데있어 가장 중요한 부분 중 하나는 후배들에게 유용하다고 굳게 믿는다. 선배와 지도자는 종종 자신에게만 할 권리가있는 업무를 수행합니다 (예를 들어, 후배에게 준비와 자극에 대한 글을 쓰지 않습니다). 또한 직업의 중요한 부분은 중학교 사람들을 멘토링하는 것입니다. 나이가 많을수록 당신에게서 무언가를 필요로하는 다른 사람들이 당신을 방해 할 가능성이 높습니다. "방해하지 마십시오"라는 표시를 포기하고 중단 작업을 배우십시오.

듣는 것이 중요합니다.

당신이 중요하고 비용이 들지 않습니다 감사합니다.

당신이 기꺼이주는 것 이상을 기대하지 마십시오. 내가 새벽 3 시까 지 일하기를 원한다면 나도 옆에서 일하는 것이 낫다. 오전 7 시까 지해야 할 일을 한 후 매일 정시에 떠나는 사람을 위해 일하는 것보다 낙담하지 않습니다.

공정해라. 즐겨 찾기를하지 마십시오 (특히 여자 친구 나 남자 친구에게 최고의 물건을 제공하여 즐겨 찾기를하지 마십시오). 모든 직원을 존중하십시오 (개인적으로 싫어하는 사람도 포함).

결심하십시오. 5 분마다 의사 결정을 진행하거나 악화시킬 수있는 결정을 내리지 마십시오.

사람들을 위해 일어 선다. 당신은 그들 모두를 이길 수는 없지만 사람들은 그들을 체인 위로지지하는 누군가를 위해 불길을 밟을 것입니다.

필요할 때 나쁜 사람이되어 기꺼이하십시오. 하나의 나쁜 사과는 개발자 팀을 파괴 할 수 있습니다. 나쁜 소식이있을 때는 팀에 알리고 비밀로 유지하지 마십시오 (결국 알려 지다가 나쁜 소식과 비밀 유지에 대해 화가납니다). 당신은 인기가 없지만 일을 끝내기 위해 있습니다. 관리 또는 준 관리 직책에있는 사람은 누구나 인기가 없습니다.

아이디어를 상급자에게 판매하고 이러한 기술을 개발자에게 가르치는 방법을 배우십시오.

비즈니스 영역의 중요성을 이해하고 프로그래밍뿐만 아니라 비즈니스 영역에 대한 전문가가 되십시오.


3

여기서 키워드는 신뢰와 책임입니다.

당신은 당신의 팀원이 자신의 임무를 완수하는 데 유능하고 집중되어 있다는 것을 믿어야합니다. 너무 많이 방해하지 않으면 서, 당신은 본질적으로 그들에게 그들의 일에 대한 "자신의"책임을 부여하게됩니다.

IMHO, 이것만으로도 건강한 분위기를 조성 할 수 있습니다.


2
가 제공 되어 상당히 유능하고 동기를 부여. 팀이 그대로 상속되면 불행히도 주어진 것은 아닙니다. 멤버를 직접 선택한 경우에는 다른 이야기입니다.
Péter Török

1
글쎄, 내 생각에, 너무 유능하지 않은 사람들조차도 전적으로 책임을 졌을 때 프로젝트의 일부에 대한 "소유권"이라고 할 수 있습니다. 작업이 완료되는 한 포럼 및 게시판에 질문을하여 코드의 일부를 수집해도 상관 없습니다.
Jas

불행히도 나는 반례를 만났다 :-( 최악의 경우, 개발자가 약 2 개월 동안 자유와 전적인 책임을 졌을 때 전혀 아무것도 생산 하지 못했습니다. 어떤 사람들은 단지 팀에 자신의 체중을 당겨되지 않으며, 당신이 그들을 가까이 조사없이 자유롭게 실행할 수 있도록, 당신은 단지 나쁜 일을 당신이 시간에이 사람들을 제거하지 않으면, 그들은 팀 전체가 손상 될 수 있습니다..
Péter Török

@ Peter Török-모든 사람들이 모든 회사에서 그런 사람들을 알고 있습니다 (실제로 이것을 읽으면 나와 같은 사람을 알고 있다고 생각합니다). 그러나 내 경험에 따르면 대부분의 사람들은 집중하고 최선을 다하려고 노력합니다.
Jas

대부분의 사람들은 최선을 다하려고합니다. (또는 내가 말할 것이다 모든 사람의 시도가해야 할 그 / 그녀의 최고의 - 그냥 들어, "가장"noticeability의 문턱에 충돌하지 않습니다 :-) 하나는 아직 시간의 예외를 통지하는 경고해야한다 -이 있기 때문 입니다 예외. 프로덕션 코드에서와 마찬가지로 정상적인 상황에서는 드물지만 오류 사례를 올바르게 처리 해야합니다 .
Péter Török

3

IMO 저는 선임 개발자 / 리드 / 무엇이 바보 같은 마감일, 자원은 없지만 로마를 건설하고 초과 근무를 의무화하는 등 생산성을 줄이고 사람들을 불행하게 만드는 모든 것들에 대해 개발 팀과 함께 할 것을 기대합니다.

IMO가 피해야 할 가장 중요한 것은 상위 경영진에게 "예스맨"이되고 그들이하는 말에 상관없이 항상 동의하는 것입니다 (즉, 엉덩이 키스).


+1 : 그렇습니다. '예스맨 (Yes-Man)'에게보고하는 경우 최대한 빨리 떠나십시오.
Jim G.

1
슬프게도, 선임 / 리드 / 관리자 프로그래머가 예스맨 (또는 "Smithers"라고 부르기를 선호하는)이 아닌 많은 환경이 있으며 최악의 부분은 당신이 알지 못하는 대부분의 시간입니다 일을 마칠 때까지
Wayne Molina

3

사람들의 기술. 때때로 사람들은 "Senior"라는 제목을 받았으며 전능하지 않다는 것을 잊었습니다. 그들은 승진이 최고의 기술력과 잠재 천재성에 대한 논평이라고 생각합니다. 실제로 그들은 현재 매우 낮은 수준의 관리자입니다. 그들은 어떻게 그리고 누가 동기를 부여해야하는지, 누가해야하는지, 타협하고, 듣는 시간을 이해해야합니다.

소유권. 최악의 시니어 프로그래머는 자신의 "노인"에 대한 소유권을 가지지 않습니다. 그들은 작업 도저 리의 전술과 게임을 비난하여 판촉을 이끌어 냈습니다 (버스에서 던진 사람의 무덤에서 춤을 추는 동안 가능성이 높습니다). 이제 그들은 슬링의 엉덩이와 디자인, 계획 및 많은 작업을 소유해야 할 책임을 이해해야합니다.

경험. 수석 개발자가 모든 것을 두 번 보았을 것으로 기대합니다. 도메인과 기술을 이해해야합니다. 그들은 적극적으로 위험을 공격하고 붉은 청어를 낭비하는 시간을 알아낼 수 있어야합니다.


2

일관성은 가장 중요한 것 중 하나입니다. 개발자가 어떻게 행동할지 예측할 수 있다면 더 행복해질 것입니다. 당신이 지속적으로 전체 도구 인 경우에도 때로는 더 시원하고 때로는 도구 인 것이 좋습니다. 그것은 도구가 아니라고 말합니다.


2

지식과 커뮤니케이션. 출처를 아는 사람은 자신이 이해하고 유지할 수있는 방식으로 누구에게나 설명 할 수있는 것보다 훨씬 중요합니다.

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