저는 5 명 이상의 개발자와 팀장입니다. 나는 좋은 프로그래머이고, 깨끗하고 이해하기 쉬운 코드를 작성 하는 개발자 ( A 라고 부르 자)가 있습니다. 그러나 그는 관리하기가 다소 어려우며 때로는 실적이 저조한 지 궁금합니다.

1. 우리 회사는 개발자가 프로그래머를 모니터링 할뿐만 아니라 이해 관계자가 진행 상황을 파악할 수 있도록 버그 추적기에서 작업 진행 상황을 표시하도록 요구합니다. 문제는 A 가 완료되면 (아마도 처음 작업 한 후 3 주 후에) 작업 진행 상황 만 업데이트하므로 모든 사람이 개발 주간 중반에 무슨 일이 일어나고 있는지 궁금해합니다. 그는 반복적 인 조사에도 불구하고 습관을 바꾸지 않았다. (괜찮습니다. 개발자는 서류 작업을 싫어합니다.
2. 최근 2 ~ 3 개월은 여러 가지 사건으로 인해 자주 휴가를 떠납니다. 아프거나 많은 개인적인 행사 등에 참석해야합니다.
3. 매월 스프린트 또는 로드맵을 정의합니다. 그리고 스프린트 시작 부분에서 각 개발자가 스프린트에서 수행해야하는 작업량에 대해 논의하고 개발자는 각 작업에 필요한 시간을 설정합니다 . 그는 일반적으로 모든 것을 완료 할 수 없습니다. (괜찮아, 개발자들은 결함으로 인한 것이 아니라 마감일을 정기적으로 놓치고있다).
4. 저는 싱가포르에 있습니다. 그게 중요한지 확실하지 않습니다. 예, 아시아 인은 회귀하는 것으로 알려져 있지만 그게 중요합니까?

위의 사건 중 하나 또는 두 가지만 발생하면 A 가 실적이 낮다고 생각하지 않지만 모두 함께 발생합니다. 그래서 나는이 느낌 A가 수행 밑에 하나님 께서 안해서 --- 금지 봐 주길입니다.

이것은 프로그래머로서의 오랜 경험을 바탕으로 한 느낌입니다. 그러나 나는 틀릴 수 있습니다.

두 가지 작업이 모두 같지 않다는 점을 감안할 때 프로그래머의 작업을 측정하는 것은 어렵고 회사에 대한 프로그래머의 노력을 측정 할 표준 목표가 부족하다는 점은 악명 높습니다. 프로그래머가 자신의 일을하고 있는지 또는 느슨해 보이는지를 말하는 것은 불가능합니다. 당신이 할 수있는 것은 그들을 신뢰하는 것입니다. 예, 그들에게 자율성을 신뢰하고 제공하는 것이 프로그래머가 일하는 가장 좋은 방법입니다. 나는 프로그래머를 신뢰해야하는 이유에 대해 강의를 시작하지 마십시오. 많은 - 그들이 당신의 신뢰를 악용하는 경우에, 당신은 알 수 있는가?

결과:

나는 그의 공연에 대한 나의 인식에 관해 그와 직접 이야기했다. 내가 최고 수준에서 공연을하지 않는다는 느낌을 받았다고 제안했을 때 그는 분개했다. 그는 이것이 완전히 불공평하다고 느꼈다. 나는 이것이 내 느낌이라고 대답했고 내 느낌이 옳은지 알지 못했다. 그는이 중 어느 것도 없었으며 즉시 토론을 끝냈습니다.

그가 떠나기 전에 그는 매우 차가운 톤으로 "회사에 더 많은 것을 주려고 할 것"이라고 말했다. 나는 그의 반응에 쫓겨났다. 나는 어떤 식 으로든 그를 화나게했다고 확신한다. 그래도 내가 그에게 솔직 해지려면 옳은 일인지 확실하지 않습니다.

내 질문은 : 프로그래머가 저조한 지 여부를 어떻게 알 수 있습니까? 분명히 나보다 더 잘 알고있는 경험 팀장이 있습니까? 

추가 메모 :

1. 나는 미세 관리가 싫어. 따라서 소프트웨어 프로세스에 필요한 모든 것은 스프린트 (작업의 우선 순위가 지정되고 할당되며 월말에 수행 된 작업량 검토)입니다. 개발자는 일상 업무에 따라 작업을 업데이트해야합니다.
2. 스탠드 업 회의가 없습니다. 주로 집에서 일할 자유가 있고 모든 사람이이 자유를 소중히 여깁니다.
3. 마감일을 정하는 사람이지만 개발자는 각 작업에 대한 견적을 제공하고 견적에 따라 특정 스프린트에 들어가는 작업을 결정합니다. 스프린트 종료시 작업을 완료 할 수 없으면 다음 작업으로 진행합니다. 따라서 이론적으로 전체 스프린트 동안 하나 또는 두 개의 작업을 수행 한 다음 나머지 99 개의 작업을 다음 스프린트로 푸시 할 수 있으며 매일 작업 진행 업데이트의 형태로 이것을 정당화하는 한 괜찮습니다.

이것은 놀랍게도 쉽게 해결할 수있는 문제 여야합니다.

그와 두 번째 모임을 가지십시오. 그에게 아마도 현실에 대한 당신의 인식이 잘못되었다는 것을 인정한다고 말하십시오. 그런 다음 "그러나 그러한 경우 우리는 내 인식을 향상시키기 위해 함께 노력해야합니다." 마지막으로 그 문제를 해결하도록 도전하십시오 .

이 정확한 일은 오래 전에 나에게 일어났다. 나에게있어 문제는 누군가 내가 단순히 일을한다고해서 추가 크레딧을 원한다고 생각할 가능성을 싫어한다는 것이었다. 그리고 그것은 공평했지만 직원들과 그들의 라인 매니저 사이에는 정기적 인 피드백 루프가 있어야합니다.

그렇지 않은 경우 이러한 문제가 발생합니다.

정기적이고 계획된 1 : 1은 좋은 생각입니다. 그리고 사람들이 지적했듯이 스탠드 업은 집에서 일하는 데 직교 할 필요가 없습니다. 그러나 그들은 세 가지 질문을 포함해야합니다. 어제 무엇을 했습니까? 오늘 무엇을 할 계획입니까? 그리고 대부분의 사람들이 잊어 버린 사람은 무엇입니까?

그것은 당신이 말했다 해야 팀 구성원이 함께 작동하지 않을 경우 상황을 억제하려고합니다. 나는 그 상황에서 전에 일해 왔으며 팀 내부와 외부에서 불신을 심었습니다. 모두가 사무실에 들어 오도록 규칙적인 하루를 보내십시오. 프로세스 개선 또는 기타 사항에 대한 사람들의 의견을들을 수있는 정기 회의를 갖습니다.

행보고 이벤트로 만들지 마십시오. 대화 할 수있는 기회를 만드십시오. 당신이 배우는 것에 놀랄 것입니다. 가능하다면,이를 사교 행사로 바꾸고, 노동 시간에 결합 음료로 두 잔을 마신다.

여기에는 훌륭한 조언이 많이 있으며 그중 어떤 것도 제거하고 싶지 않으므로 이것을 별도의 답변으로 게시하고 있습니다.

첫째, 당신이 문제 의 근본 원인을 발견하지 못했다는 것이 나에게 명백합니다 . 증상을보고 치료하려고합니다. 자신과이 개발자 사이에 많은 마찰을 일으키는 원인을 찾아야합니다. 어쩌면 당신은 너무 권위적 일 것입니다. (내 제품 소유자는 최근 자신이 프로젝트에 대해 "무한의 힘"을 가지고 있다고 설명했으며, 그녀가 말했을 때 웃었더라도 불쾌했습니다.) 아마도 그는 심각한 가족 문제를 겪고있을 것입니다. 여기에는 근본적인 문제가 있으며, 찾을 때까지 해결 되지 않습니다 .

잘 잡아라!

그의 퍼포먼스가 더 나을 수 있다면, 당신이 결정한 것이 좋습니다. 그럼에도 불구하고 그의 나쁜 성능이 여전히 좋은 성능이라면, 좋은 개발자를 잃지 않도록 조심해야합니다. 좋은 개발자는 찾아 오기가 어렵고, 좋은 개발자에게는 매우 특정한 것들이 필요합니다. 아마도 그의 요구가 충족되는지 확인하기 위해 Joel 테스트 를 살펴보십시오.

문제의 원인 찾기

그가하고있는 일과 관련하여 불만이있는 경우 문제의 원인을 파악하여 문제를 해결할 수 있습니다. 프로그래머가 좋은 코드를 작성했다고 말했다. 그것은 그가 프로그래밍을 좋아한다는 것을 의미합니다. 그가 직장에서 (회의 설명에서) 좌절했다는 것은 명백한 일이며, 그의 성과가 예상보다 낮을 수도 있지만 추측하지는 않을 것 입니다. 많은 프로그래머들이 사회적 기술을 가지고 있지 않다는 것을 기억하십시오.

당신은 완벽하지 않다

때때로 당신은 특히 내향적인 사람들과 성격 충돌을 겪게 될 것임을 기억하십시오 . 이것이 성격 갈등으로 판명되면 성과를 높이기 위해 얼마나 멀리 갈 의향이 있는지 고려하십시오 (1 참조).

그 모든 것

프로그래머 관리에 관한 블로그 게시물을 작성했습니다. 나는 당신이 그것을 읽어야한다고 생각합니다.

http://deltreey.blogspot.com/2012/07/managing-programmers.html

나는 그 포스트의 마지막 부분을 충분히 강조 할 수 없다.

개발자가 전혀 능숙하다면 코딩을 원합니다.

프로그래머가 느슨해져도 느슨해지기를 원하지 않습니다. 이 문제의 근본을 찾아야하며, 단순히 고칠 수 없어야 만하는 문제로 판명 될 수 있지만, 무엇이든지간에 결정을 내리지 않고 현명한 결정을 내릴 수는 없습니다.

누군가가 당신이 설명처럼 더 나은, 하나 dev에 팀 구성원의 생산성에 영향을 미치는 (객관적 또는 주관적) 문제가 있는지 수행하고 않는 방법을 이해하는 연습을 구축 고려, "관리하기가 다소 어렵다"입니다 느끼는 경우 일반 1 : 1의를 사용하여 우수한 기사 The Update, The Vent 및 The Disaster 에 나와있는 팀원 :

... 모든 1 : 1이 숨겨져있는 긴급한 재난을 발견하기 위해 끔찍한 일이라고 제안하는 것은 아니지만, 불만족이 조용히 나타날 수있는 주간 장소를 만들고 싶습니다. 1 : 1은 매주 예방 유지 보수를 수행하는 동시에 팀의 건강을 이해하는 기회입니다.

... 1 : 1의 성공적인 요법을 둘러싼 소리는 침묵입니다. 1 : 1 중에 발생하는 모든 청취, 질문 및 토론은 관리 예방 유지 보수입니다. 프로젝트에 대한 관심이 사라지고 작업 불만족이되기 전에 조치를 취하는시기를 알 수 있습니다. 두 직원 간의 긴장에 대해 듣고 회의에서 소리 치기 전에 토론을 진행합니다. 건강한 1 : 1 문화에 대한 귀하의 보상 은 드라마 의 뚜렷한 부족입니다 .

_{언급 된 기사의 매우 중요한 점은 장점을 설명하는 것 외에도 기본적으로 다른 소스를 파지 않고 정기적으로 1 : 1 연습을 시작할 수있는 실용적인 권장 사항을 제공한다는 점에서 자체적으로 포함되어 있다는 것입니다. 추가 정보는 아프지 않습니다.)}

분명히 여기에는 중요한 의사 소통 문제가 있습니다. 그는 훌륭한 일을하고 있을지 모르지만, 자신이 무엇을하고 있는지 모른다는 느낌이 든다면 그 자체만으로도 문제가됩니다. 그리고 당신이 그가 무엇을하고 있는지 모른다면, 그의 동료들도 모르고있을 것입니다. 이로 인해 2 주 된 코드를 체크인 할 때 문제가 발생할 수 있습니다. 특히 비슷한 지역에서 일하는 사람이있는 경우 특히 그렇습니다.

이러한 종류의 충돌을 최소화하기 위해 업데이트를 정기적으로 체크인 / 제공하도록 제안 할 수 있습니다. 이를 통해 "무엇을하고 있는지 잘 모르겠습니다"라기보다는 팀을 돕는 측면에서 요청을 처리 할 수 ​​있습니다.

나는 스탠드 업이 많은 증오를 받는다는 것을 알고 있지만 실제로는 같은 방에서 개최 될 필요는 없습니다. 하루에 한 번 빠른 통화 또는 그룹 Skype 업데이트는 매우 빠르며 모든 사람이 같은 페이지를 유지합니다.

저는 현재 인도에서 아일랜드 팀과 함께 일하고 있으며 매일 그들 각자와 의사 소통을하지 않는 것을 상상할 수 없으며, 각 팀원들이 대략 무엇인지 알거나 매우 빨리 알 수 있습니다.

무의미한

일일 상태 업데이트는 의미가 없습니다. 사람들이 '오늘 나는 2.5 % 완료', '오늘 나는 3.74 % 완료'라고보고하는 것은 말도 안됩니다.

그것은 이해 관계자들에게 가치를 제공하지 않으며, 일을하는 사람들을 귀찮게한다.

방해받지 않고 그들의 일에 맡기십시오.

베이스리스

개발자 A가 '성능이 부족'하다고 가정하는 근거는 무엇입니까? 그 / 그녀의 작업이 정시에 완료되면 충분합니다.

당신은 당신이 미세 관리를 싫어한다고 말하지만, 당신이 묘사 한 것은 정확히입니다.

우리 회사는 개발자가 프로그래머를 모니터링 할뿐만 아니라 이해 관계자가 진행 상황을 파악할 수 있도록 버그 추적기에서 작업 진행 상황을 표시하도록 요구합니다. ... 개발자는 일상 업무에 따라 작업을 업데이트해야합니다.

이것은 의미가 없습니다 (위 참조). 당신의 팀은 햄버거를 뒤집지 않고 기술 솔루션을 만들고 있습니다. 진전은 선형 적이 지 않으며 쉽게 측정되거나 추정되지도 않습니다. 그렇더라도 그러한 일일 측정 또는 추정치는 가치가 없습니다.

위험한

개발자 A가 '성능이 부족'하다는 '느낌'에 대한 근거를 다시 검토하십시오. 당신은 그 / 그녀가 더 잘할 수 있다고 생각하지만, 어떤 증거에 근거합니까?

불행한! = 실적이 저조하다

설명 된대로 계속 진행하고 어느 시점에서 개발자 A는 평가가 부족하고 회사에 충분히 제공했으며 다른 회사를 찾게 될 것입니다. 직원의 노력 중 마지막 0.01 %를 짜는 것이 장기적으로 유지하는 것보다 훨씬 덜 중요합니다.

개발자는 자신이하는 일을 문서화하고 상태를 업데이트하려는 노력을 싫어할 수 있지만 이는 전문 개발자의 일부입니다. 문제 로그에 대한 그의 최신 업데이트로 인해 그의 작업에 대한 부정적인 인식이 불필요하다고 지적 할 수 있습니다. 그가 의사 소통에 실패한 것이 성과 문제라는 것을 알지 못한다면, 당신은 그의 팀장입니다. 그에게 말해 .

추정에 관해서는-그것은 고전적인 문제입니다. Steve McConnell의 "Software Estimation-Demystifying the black art"을 읽는 것이 좋습니다. 이 경우 대부분의 개발자가 과소 평가한다는 인상을줍니다. 이것은 호기심 많고 정상적이며 거의 다루지 않습니다. 이 개인보다는 추정 프로세스 자체에 문제가 있다고 제안합니다.

추정 측정 검토의 '루프를 닫고'개선하십시오. 그런 다음 개발자가 정시에 제 시간에 와서이 개인이 아닌 경우, 그에 대해 어떻게해야하는지 고려할 수 있습니다.

마지막으로, 일 어설 회의를 가지십시오. 인스턴트 메시지 인 경우에도 마찬가지입니다. 당신이 원하는 것은 모두 내가 "내가 한 일, 오늘하고있는 일, 어떤 문제"를 아는 것입니다. 문제가있는 경우 나중에 논의하기 위해 오프라인 상태로 만듭니다. 그게 내가 전에 한 일이며 그 팀에게는 성공했습니다.

첫째, 왜 스프린트가 길습니까? 스프린트는 2 주를 초과하지 않아야합니다. 나는 당신의 문제의 대부분이 거기에 있다고 생각합니다. 스프린트 시간을 시험 기준으로 단축 한 다음 질문을 다시 분석하는 것이 좋습니다.

코드 체크인은 어떻습니까? 그는 항상 코드를 확인합니까? 저는 개인적으로 프로그래머가 실제로 경영진이 아니라고 생각할수록 더 많은 좌절감을 느끼게됩니다. 사실, 나는 그 업데이트 작업을하는 것을 싫어하며 아마도 PM과 Leads가있는 이유 일 것입니다. 그러나 동시에 스크럼 회의 중이나 만날 때마다 상태를 제공합니다. 이제 작업을 할당 할 때 타임 라인에 커밋됩니까? 아니면 타임 라인을 할당하는 사람입니까?

따라서 누군가 수행 중인지 알 수있는 유일한 방법은 커밋 된 타임 라인을 수행 한 작업의 %에 매핑하는 것입니다. 물론 누군가 누군가 두 개의 숫자를 더하는 방법을 작성하는 데 이틀이 걸릴 것이라고 말하면 문제가 있다는 것을 알기 때문에 일정이 현실적이고 양 당사자가 합의한 것이어야합니다.

이 방법으로 가져 가십시오. 한 시간 안에 코드 조각을 작성할 수 있다면 한 시간 + 약간의 버퍼를주십시오. 그가 그 시간 안에 당신에게 그것을 전달한다면, 나는 너희들이 잘하고 있다고 생각합니다. 만약 그가 그렇지 않다면 그에게 질문을하고 나중에 그에게 합리적인 설명을 제공하고 있는지 아닌지를 결정하십시오.

XPlanner와 같은 것을 버전 관리 도구와 통합하는 것이 가능합니다.

나는 풀려 난 사람을 식별 할 때 프로그래밍 직업이 본질적으로 다른 직업과 다르다고 생각하지 않습니다. 장과 함께 가야 할 수도 있습니다.

개인적으로 A가 한 번에 몇 주 동안 업데이트를 제공하지 않는 것이 이상하다고 생각합니다. 저는 집에서 일하는 프로그래머이며, 저와 고용주 사이에 매일 진행 상황에 대한 업데이트를 제공해야하는 암묵적인 계약이 있습니다. 이것들은 "공식적인"업데이트가 아니며, 짧은 이메일이나 메신저로 내가 지불하는 소프트웨어로 무슨 일이 일어나고 있는지 알려줍니다. 업데이트는 작성하는 데 1-2 분도 걸리지 않으며 우리 모두에게 폐쇄됩니다. 버그 수정의 경우 티켓을 하루 종일 버그 추적기에서 해결 된 것으로 표시합니다. 나는 서류 작업이 거의없는 편안한 작업 환경을 즐기지 만 어려운 절차는 아닙니다.

평범한 업데이트조차도 그에게서 오는 것이 좋을 것입니다. 게시물에서 매우 관대하게 들립니다. 그가 오랫동안 느슨해 졌다고 의심되는 경우, 다른 문제를 해결할 필요가 없습니다.

Skype를 통해 또는 대화방에 있더라도 매일 스탠드 업은 이해 관계자를위한 업데이트로 취급하지 않습니다. 하루에 한 번 팀 전체가 그들이 무엇을하고 있는지, 그들이 겪고있는 과제와 다음에 할 계획을 말하기 위해 체크인하면 몇 가지 승리를 얻게됩니다.

• 좋은 이유로 든 나쁜 이유로 든 시간을 낭비하든 무언가가 너무 오래 걸리면 투명성이 높아질 것입니다. 또는 팀의 다른 팀으로부터의 입력이 문제를 훨씬 빨리 해결하는 데 도움이 될 때 문제에 대한 문제를 해결하는 것입니다.

• 관리자는 사람들이로드 블록을 가장 자주 만나는 위치를 확인할 수 있으므로 시간 / 돈을 낭비하는 근본적인 문제를 더 잘 예측하고 해결할 수 있습니다.

• IMO는 팀원들이 모든 사람들이 때때로 비교적 간단한 일을하는 데 걸리는 시간을 알 수있을 때 추정치에 대해 더 잘 이해하지 못하는 것을 배우는 데 실제로 도움이됩니다.

• 팀원이 다음에 무엇을할지 계획 할 때 우선 순위를 정할 때 의사 소통이 필요한 것들을 종종 떠올리게됩니다.

따라서 '완전한 %'를 잊어 버리십시오. 모든 사람이 다른 사람과 마찬가지로 정직하게 행동하고 경험이 많을수록 더 좋고 신뢰할 수있는 견적을 제공하며 사람들이 마음이 바뀌지 않고 보고서를 작성하도록 동기 부여 당신이 정말로 할 수없는 무언가에 숫자를 넣는 -numbing 연습.

최고 경영진이 마감 시한이 항상 맞지는 않는다는 것을 이해하는 것 같습니다. 데일리 스탠드 업을하면 그 탄약에 더 많은 탄약을 줄 수 있습니다.

그리고 먼저하지 마십시오. 항상 실수 IMO. 사람들은 모든 문제가 무엇인지 더 확실하게보고하기 전에 치아를 문제에 빠뜨릴 시간이 필요합니다.

책임보다 의사 소통에 관한 것, 목표를 설정하는 것보다 빠른 스탠드 업은 무엇보다도 내 생각에 민첩하게 작용하는 것입니다. 내가 가져 가거나 떠날 수있는 나머지 부분, 특히 스크럼은 경영진 / 이해 자 뱀 오일로 보았습니다.

실적이 저조합니까?

강도는 개인의 커리어 동안 흘리며 흐릅니다. 그가 비용보다 더 가치가 있다면, 그에게 말을 걸고 더 쉽게 일을하려고 노력하십시오. 아니면 교체품을 찾기 시작하십시오.

통신

주별 회의에 의존하지 마십시오. 대부분의 사람들은 완전한 뇌 덤프를하지 않을 것입니다. 더 많은 1 : 1을 예약하십시오. 상황이 어떻게 진행되는지, 더 잘할 수있는 일, 더 잘할 수 있다고 생각하는 것을 물어보십시오. 때때로, 아무 말도 할 수 없지만 괜찮습니다. 더 많은 1 : 1을 가짐으로써 그들이 무언가를 언급하는 것을 기억할 가능성이 높아집니다.

보다 지속적인 의사 소통 수단을 갖추십시오

여분의 집안일처럼 느끼지 않으면 사람들로부터 더 많은 정보를 얻을 수 있습니다. 모두 원격 인 경우 Hipchat 또는 IRC와 같은 로깅 기능이있는 채팅 프로그램을 사용하도록하십시오. 보다 지속적인 의사 소통 수단을 갖추면 사람들이 더 많이 이야기 할 수 있습니다. 다른 사람들도 그렇게하도록 격려하기 위해 모범으로 인도하고 자주 이야기하십시오. 적어도 하루에 한 번, 사람들에게 프로젝트가 어디에 있는지 말하게하십시오. 때로는 채팅을 보면서 상황이 어떻게 진행되고 있는지 느낄 수 있습니다.

소스 컨트롤

모든 사람이 매일 코드를 확인하도록합니다. 자식을 사용하는 경우 회사 리포지토리의 자체 지점으로 푸시하십시오. 커밋을 살펴보면 커밋 방법을 알 수 있습니다.

수단을 끝에서 분리하십시오

이해 관계자 업데이트를 원하십니까? 이해 관계자와 직접 거래하십시오. 관리자로서의 일의 일부는 똥 우산이되므로 코더가 작업에 집중할 수 있습니다. 채팅 로그와 커밋을 살펴본 후 상황이 어떻게 진행되고 있는지 요약을 작성하십시오.

이것들은 나의 제안입니다.

1. 혁신 : 상상력과 창의력으로 비용을 낮추고 현재 상황을 개선합니다.

2. 공사 : 다른 사람들이 그들의 목표를 달성하도록 돕는 의지

3. 이니셔티브 : 비 루틴 작업 및 태스크 시도.

4. 출석 : 부재 또는 지각, 표준 이하.

5. 경고 : 새로운 정보와 상황을 빠르게 이해하는 능력

6. 정확성 및 품질 : 코드 검토, 정시 제공, 문제 발생률).