팀의 코드 카우보이


15

당신은 당신보다 나이가 많고 항상 다른 사람들의 프로젝트에 뛰어 들어 밤이나 주말에 완료하는 팀원을 어떻게 처리합니까? 그녀는 응급 상황이 있든 없든 80 시간 동안 일하는 것으로 보이며, 할 일 목록에서 어느 부분이 다음에 올 것인지 예측하기는 다소 어렵습니다. 월요일 아침에 지난 주 대부분의 시간 동안 작업 한 프로젝트를 완료 한 체크인을 발견하기 때문에 작업 일이 낭비되는 경우가 있습니다.

품질을 요구하는 사람들에게 : 일반적으로 그것은 좋지만 : 다른 팀 구성원이 '소유'한 코드를 포함하여 테스트 적용 범위를 고려하지 않은 코드의 리팩토링도 명백한 결과와 함께 있습니다.


51
그녀의 세부 사항을 알려 주시면 회사가 밀렵을시키기 위해 무엇을 할 수 있는지 보겠습니다.
Kevin D

7
@ MK01, Howabout, "우리는 여러분이 한 기여를 좋아하지만 작업을 명확하게 분류 할 수있는 방법에 대해 논의하고 싶습니다. 다른 팀과 코딩을 활용할 수 있다면 아마도 지금보다 훨씬 빨리이 작업을 수행 할 수있을 것입니다. " 큰 열쇠는 이것입니다. 그녀가 아이디어를 생각 해낸 사람처럼 느끼게하십시오.
riwalk

7
긴장을 풀고 타 버릴 때까지 기다리십시오.
Steven Evers

9
월요일 아침에 더 많은 SO 시간을 계획 할 수있는 것 같습니다.
JeffO

3
당신이 우리에게 말하지 않은 것은 그녀의 코드의 품질입니다. 그녀는 다른 사람에게 동일하거나 더 높거나 낮은 품질의 솔루션을 선점하고 있습니까?
David Thornley

답변:


17

이것은 아마도 투명성 문제 일 것입니다. 그녀는 당신의 시간을 낭비하지 않을 것입니다. 사람들이 작업중인 작업을보다 명확하게하는 방법에 대해 경영진과 이야기를 나누면 누군가는 이미 해당 작업에 시간을 투자했다는 사실을 더 쉽게 알 수 있고 어떤 작업이 고발되지 않았는지 확인할 수 있습니다.

나는 이것에 대해 그녀와 직접 대면하지 않을 것이다. 관리자와 이야기를 나누면 일부 절차를 진행할 수 있습니다. 문제는 아마도 그녀에게 가장 잘 드러날 것이지만, 다른 규모의 팀원들과 같은 일을하고있는 다른 팀원들도 있습니다. 관리자가이 새로운 프로세스를 이끌 수있는 최상의 위치에 있다고 생각하지만, 그에게 아이디어를 줄 수도 있습니다. 관리자와의 작업이 효과가 없다면 직접 이야기를 진행해야합니다. 그러나 관리자부터 시작하겠습니다.

우리 팀은 화이트 보드에서 수행해야하는 모든 작업에 대해 스티커 메모를 작성하여이 문제를 해결했습니다. 모든 팀원은 자신의 이름이 적힌 레이블을 가지고 있었고, 진행중인 스티커 메모를 "진행 중"열로 옮기고 이름을 붙였습니다. 다른 사람이 그 일을 돕고 자한다면, 그 일을 주장한 사람과 논의하고 협상해야했습니다. 비슷한 시스템이 문제에 많은 도움이 될 수 있습니다.


17

그녀가 정말 효율적이고 "모든 거래의 잭"이라고 가정하면 ...

그녀의 스타일을 받아들입니다. 그녀를 풀어 라 . 그리고-그녀를 격리시킵니다.

또한...

맡겨야 할 책임을 분명히하십시오.
팀이 그녀로부터 배우도록하십시오 (예 : 페어 프로그래밍이 우수함).
"올인"하지 마십시오-그녀를 테스트하고 상황이 악화되면 백업 계획을 가지고 있는지 확인하십시오.

당신이 할 수있는 최악의 일은 그녀의 동기를 망치는 것입니다.


나는 내 자신의 경험에서 이것을 말하고 있습니다. 나는 원하는만큼 효율적이지 않을 수도 있지만, UI에서 지속성까지 확실히 갈 수 있으며 확실히 카우보이 코딩 (양날의 검)을 연습하고 있습니다.

나는 아주 희망이없는 프로젝트에만 쏟아졌습니다 (물건을 더 재 작성하고 그것을 받아 들일 것을 제안했습니다). 실수를 저지른 사람은 아무도 없습니다. 자발적으로 결정했을 때 울리는 사람은 없습니다 으로 모든 것을 리팩토링 .

실제로-이 자유는 내가 여전히 여기서 일하는 이유와 같습니다.


9

나는 더 나쁜 문제가 있다고 생각합니다. 비록 당신이나 다른 팀원의 일이 중요하지만 그녀의 일의 결과로 인해 팀에 대한 기여가 효과적으로 사라지는 것 같습니다.

내 생각에 그녀는 팀에 미치는 영향을 깨닫지 못한다. 오히려, 그녀가 공헌 한 기여는 아마도 그녀가 팀에게 가치 있다고 느끼게 할 것입니다.

해결책 (IMHO) : 그녀를 직접 대면하십시오. 물론, 외교적이며 그녀가하는 공헌과 희생에 대해 감사해야합니다.

그러나 동료, 후배 또는 다른 사람을 소외시키지 않는 방식으로 행동하는 것은 그녀의 책임입니다. 그리고 팀의 모든 직원은 자신의 노력이 의미가 있다고 생각할 가치가 있습니다.


SO / SE에 대한 OP의 프로필을 살펴본 후, 동전의 반대편을 살펴볼 수 있습니다. 또한 주니어가 자라거나 발달하지 못하게하는 기본 요점 때문에 주니어가 당신을 대신 할만큼 충분히 나아질 때만 공연 없이도 쇼를 진행할 수 있습니다. 그래서 +1
Aditya P

9

그녀에게 많은 일을하도록하세요. 그래서 그녀는 당신을 찾을 필요가 없습니다!


6

팀의 나머지 팀이 너무 느리게 움직이거나 상사가 그녀에게 요청했기 때문에 그녀가 "점프하고 마무리하는"것일 수 있습니까?

이 중 얼마나 많은 것이 우회되는 것에 대한 성가심이며, 더 많은 (필수적으로 더 좋은 것은 아님) 코더에 의해 단순히 "표시"되는가?


4

그녀는 다른 사람들이이 성가신 것을 발견한다는 것을 알고 있습니까? 나는 당신이 프로젝트를 끝내기를 선호한다고 말하면서 그녀와 함께 그것을 능숙하게 제안하는 것이 좋습니다. 그래도 문제가 해결되지 않거나 선임자와 연락이 불편한 경우 관리의 경우입니다. 프로젝트가 완료되어 프로젝트를 완료하지 않은 경우 관리자가 상황을 알지 못하면 느슨해 보일 수 있습니다.

또한 다른 사람들이 말했듯이 그녀가 자신을 향상시키기 위해 어떻게 노력하는지 살펴보십시오. 그녀의 체크인을보고 문제가 어떻게 해결되었는지 확인하십시오. 아마도 자신이 생각하지 못한 영리한 수정일 수 있습니다. 선임 개발자는 사용자보다 훨씬 더 친밀하게 코드베이스를 알고 있습니다. 사소한 것처럼 보이는 것은 실제로 새로운 개발자가 발견하기 어려울 수 있습니다.


7
선호도에 따라 프로그래밍에서 80 시간 동안 일하는 사람은 사회적 기술이 약간 부족할 수 있습니다.
David Thornley

4

당신은 당신보다 나이가 많고 항상 다른 사람들의 프로젝트에 뛰어 들어 밤이나 주말에 완료하는 팀원을 어떻게 처리합니까?

더 빨리 일하십니까?

그녀는 응급 상황이 있든 없든 80 시간 동안 일하는 것으로 보이며, 할 일 목록에서 어느 부분이 다음에 올 것인지 예측하기는 다소 어렵습니다.

정의에 따라 할 일 목록에 있으면 완료되지 않습니다. 그녀가 그것을 완료하면 할 일 목록에서 그것을 교차하십시오.

월요일 아침에 지난 주 대부분의 시간 동안 작업 한 프로젝트를 완료 한 체크인을 발견하기 때문에 작업 일이 낭비되는 경우가 있습니다.

일반적으로 팀워크라고합니다. 그녀가 취한 지시가 마음에 들지 않으면 문제가 무엇입니까?

품질을 요구하는 사람들에게 : 일반적으로 그것은 좋지만 : 다른 팀 구성원이 '소유'한 코드를 포함하여 테스트 적용 범위를 고려하지 않은 코드의 리팩토링도 명백한 결과와 함께 있습니다.

"소유"와 코드는 함께 가지 않습니다. 당신이 계속 유지하는 데 어려움이 있다면, 그녀에게 당신에게 설명하도록 요청하십시오. 그녀는 매우 생산적인 것처럼 들리므로 멘토에게 문의하십시오. 관계를 활용하고 함께 일하십시오.

테스트 범위는 조직의 표준 인 경우 리더 / 관리자를 불러 오십시오. 빠르지 만 뻔뻔한 일은 누구에게도 소용이 없습니다. 그녀가 당신보다 10 배 더 생산적이라면, 결국 그녀를 청소하는 거친 작업을하게 될 수도 있습니다. 이 경우, 그녀와의 관계에 더 많은 투자를하십시오.


그녀는 이상적인 팀원처럼 들립니다 ... 그녀는 자신이 일한 / 마무리 한 일을 분명히하고 있으며, 팀의 모든 구성원 등을 돕고 있습니다.
Augury

3
  • 그녀에게서 배우고 작업 속도를 향상 시키려고 노력하십시오.
  • 작업이 지연 될 수 있습니다.
  • 그녀가 선임 할 때 경영진의 기대에 근거하여 무대 뒤에서 또는 지식보다 더 많은 일이 일어날 수 있습니다.
  • 당신은 그녀가 더 잘할 일이 없다고 생각할 수도 있습니다.
  • 응급 상황을 알지 못할 수 있습니다.
  • 경영진이나 노인이 수행 한 성과에 대한 힌트 일 수 있습니다.

어느 쪽이든 최선을 다하면 먼저 자신을 평가하기 시작합니다. 그녀와 "거래" 하려는 노력 이 경영진과 잘 맞지 않을 수 있습니다.


3

그녀는 문제를 해결하고 영웅이 된 것에 대해 만족감을 분명히 얻습니다.하지만 괜찮습니다.하지만 팀을 잘 이끌고 있지만 그 동안 활용하는 방법을 찾아야합니다.

중요한 것들이 나에게 튀어 나온다 :

  • 그녀는 다른 사람들보다 더 빨리 일을 할 수있는 재능을 가지고 있습니다.

따라서 활용하십시오. 다음 프로젝트에서 할 일을 미리 알려주십시오. 그렇게함으로써 그녀는 무엇을 계획하고 있는지 알 수 있습니다. 그녀의 만족이 문제 해결에서 비롯된 경우, 마치 그녀가 마치 배경에서하는 것처럼 그녀에게 제공하는 것만으로도 행복 할 것입니다.

팀이 여분의 일을하고 싶은 사람을 위해 마련된 일을하면서 도둑질의 요소가 사라지고 모든 사람이이기는 방식으로 하나 더 나아지고 공식화 할 수 있습니다.


1
DeMarco 책을 읽으면 좋은 개발자와 그렇지 않은 개발자가 생산할 수있는 양의 비율이 약 10 : 1이라는 것을 알 수 있습니다. 당신이하고 싶은 마지막 일은 다른 사람들보다 더 많은 일을하는 이상자를 절름발이하는 것입니다. 그 에너지를 활용하여 가장 잘 할 수있는 곳으로 보내야합니다.
quick_now

2

페어 프로그래밍을하는 팀을 시작하십시오.

첫째, 페어 프로그래밍은 소진됩니다. 특히 주말 내내 혼자 일하는 것을 좋아하는 내향적인 개발자에게는 그렇습니다. 주말은 휴식을 취하기에 귀중한 시간이 될 것입니다.

두 번째로, 그녀는 (더 많은 초보자 개발자들이 운전하는 한) 지식을 전달하여 놀라운 능력을 팀의 다른 팀에게 전파 할 것입니다.

셋째, 그녀는 현재 귀하를 대신하여 수행하는 막대한 위험을 줄여서 한 명 이상의 팀원이 자신이 알고있는 것을 알도록합니다.

넷째, 그녀와 팀의 나머지 팀은 현재 진행중인 작업에 대해 더 잘 이해할 것입니다. 전체 기능을 팀으로 구성하여이 기능을 결합하면 진행중인 작업이 줄어들고 체크인 전에 작업이 복제 될 가능성이 줄어 듭니다.

다섯째, 팀의 일원으로 배우는 법을 배웁니다 . 다른 팀원들의 업무 중복과 함께 그녀가 야기한 시위는 그녀가 생산하는 것보다 더 많은 비용이들 수 있습니다. 생산성! = 효과.

여섯째, 개발자가 페어링하면 일반적으로 코드 품질이 향상됩니다. 좋은 부작용.


1

사람들이하는 일과 진행 상황을 알고 있습니까? 경영진이 다른 사람들과 업무를 중복하지 않도록 방향을 제시 할 수 있습니까? 나는 그녀가 다른 사람들이하지 않는 것이 중요한 일이 무엇인지 아는 방향을 사용할 수있는 일을하는 사람 일 수 있기 때문에 경영진을 데려 오기 전에 1 : 1 대화를하는 것이 좋습니다. 하다.

작업이 낭비되는 경우 다른 관점에서 살펴보십시오. 당신이 한 일에서 무엇을 배울 수 있습니까? 어떤 부분을 끝내지 않았으며 어떻게 했습니까? 다른 사람이 무언가를 한 것에 대해 신용을 얻을 수 있다고해서 모든 피, 땀 및 눈물이 아무것도 아니라고 생각하지 마십시오.


0

카우보이는 열정적으로 보인다. 나는 경영진에게 접근하여 그들이 그녀에게 할 일을 많이 줄 수 있고 너희들이 당신 자신의 일을 할 수있게 할 것입니다. 그러나 카우보이에게서 한두 가지를 배울 수있을 것입니다. 나는 80 시간의 노동 시간이 표준이어야한다고 말하지는 않지만 (확실히 이것은 과장입니다) 대기업 환경에서는 직장에서 여분의 시간을 보내는 것이 일반적입니다.


5
프로그래밍 시간을 길게하는 것은 일반적으로 장기적으로 비생산적입니다.
David Thornley

@David : 매주 금요일마다 포기하지 않으면 :)
Brian

2
@ 0A0D : "근무 시간에 추가 시간을 두지 않음"이 아니라 flexitime입니다.
Carson63000

3
@OAOD : 사람들이 정기적으로 보상받지 않은 초과 근무를하는 모든 상점은 땀을 흘리는 상점입니다.
비트 트위 들러

@ bit-twiddler : 급여를받는 직원에 대해 들어 본 적이 없습니까?
Brian
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.