내 동료는 좋은 사람이지만 그의 성과는 하위 수준입니다. 상사에게 알려주나요? [닫은]


24

나는 약 3 개월 전에 프로젝트를 시작했는데 그 당시에는 새로 고용 된 한 명의 개발자가 개발 중이었습니다. 공평하게 말하면,이 프로젝트는 미묘함이 많고 상대적으로 복잡한 의료 기기와의 인터페이스이므로 회사에 경험이없는 사람을 프로젝트에 배치하는 것은 관리적 관점에서 잘못된 결정일 것입니다.

어쨌든, 일단 작업을 시작한 후에는 ... 잘 작동하지 않았다는 것을 깨달았습니다. UI는 멋지게 보였지만 실제로 많은 작업을 수행하지 않았으며 수행 한 작업이 잘못되었습니다. 다시 말하지만, 이것의 대부분은이 개발자가 우리 장치에 대한 인터페이스를 작성할 준비가되지 않았기 때문입니다. 그러나, 나는 그 자리에 있던 코드가 깨지기 쉽고 유지하기가 매우 어렵다는 것을 빨리 깨달았습니다.

이제 저는 세계 최고의 프로그래머라고 주장하지 않습니다. 나는 나보다 더 나은 개발자 인 많은 똑똑한 사람들과 함께 일한다. 그러나 코드는 간단하고 강력하게 작성하기 위해 매우 열심히 노력한다. 체크인을 테스트합니다. 내 코드가 지저분 해지고 일찍 작업하기가 어렵다는 것을 알게되면 변경합니다. 더 나은 코드 작성을 돕기 위해 동료와 몇 가지 대화를 나누었습니다. a) 그는 20 년 이상의 현장 경험이 있고 5 명 밖에 없으며 b) 소위 "UX 전문가"로 고용되었고 다른 사람들은 그를 경험있는 개인으로 간주하기 때문에 약간 까다 롭습니다.

즉, 나는 그것을 보지 못한다. 그는 매우 좋은 사람이며 합리적이지만 시간이 지남에 따라 깨지기 쉬운 코드를 확인하고 가장 낙관적 인 경우에만 작동하며 10 중 9 번은 작업 중에 버그를 수정합니다. 그의 코드는 아마추어처럼 보였으며 그는 그가 고용되었을 때 주장했던 경험의 수준을 분명히 가지고 있지 않습니다. 그의 코드를 리팩토링하고 버그를 수정하는 데 추가 시간이 걸리는 시점에 이르렀습니다. 내가 보는 방식에는 두 가지 옵션이 있습니다.

  1. 아무 것도하지 말고 내 엉덩이를 터뜨려이 제품이 정시에 나오고 견고하게하고 앞으로 실패 할 때까지 기다리십시오.
  2. 내 상사에게 그의 공연에 대해 이야기하십시오. 상사는 합리적인 사람이지만이 방법을 사용하는 것은 어색합니다. 나는 동료들에게 더 나은 용어가없는 것을 욕하고 싶지 않다. 나는 어떻게 그것을 받아 들일지 모른다.

그래서 그게 전부입니다. 나는 왜 그의 구현이 작동하지 않는지 또는 그의 코드를 유지 관리하기 쉽게 만드는 방법을 설명함으로써 동료와 함께이 작업을 시도했지만 같은 실수를 계속합니다. 저는 다른 사람들이 비슷한 상황, 특히 현재 경영진을 어떻게 처리했는지 듣고 싶습니다. 당신이 나에게 제공 할 수있는 조언에 미리 감사드립니다.


3
그가 좋은 사람이 아니었다면 그렇게 쉽지 않을까요? 그것은 당신의 상황에있는 것이 정말로 짜증납니다 ... 어떤 실제적인 조언도하지 마십시오, 나는 비슷한 상황에 처한 것을 발견했지만 "nice"이라는 단어의 의미는 아니 었습니다. 따라서해야 할 일은 변명을 찾고있는 것처럼 경영진에 의해 매우 명확하고 즉시 지원되었습니다. 그러나 당신이 실제로 좋아하는 사람, 그것은 힘든 것입니다. 행운을 빕니다.
yannis

1
@Yannis Rizos : 예, 그렇습니다. 나는 그 남자를 좋아하고, 아마도 그의 직업을 잃어 버리는 데 기여하는 것을 싫어하지만, 그는 작은 회사의 개발자에게 많은 기대를 걸고있는 것으로 보이지 않는다. 나는 5 년의 경험이 있으며 여기서 "주니어"레벨의 과제를받은 적이 없다 . 나는 첫날부터 하드웨어 인터페이스를 작성하고 있었고 훌륭했습니다.
LostInCode

UX 란? .....

Thorbjørn Ravn 안데르센 @ : UX는 일반적으로 사용자 경험을 의미한다
마 엘렌에게

답변:


24

최소한 그가 UX 직원으로 고용 된 사람이라면 누구도 자신으로부터 훌륭한 코드를 기대 하지 않을 가능성이있을 것입니다. 이를 기반으로 프로덕션 코드를 작성하는 것은 다른 코더에게 달려 있습니다.

지금, 나는 그것이 사실이라고 말하지 않지만, 그것이 놀랍도록 놀랄만 한 것은 아닙니다. 적어도 내 경험상, UX 사람들이 주로 프로토 타입이나 스토리 보드와 같은 것을 제작하는 것은 드물지 않습니다. UX 전문가로 채용 된 직원이라면 코드 체크인이라는 개념에 경계선에 충격을받습니다. 나는 그 일을 본 적이 없다고 확신합니다.

그 사람이 실제로 UX 전문가라면, 치료법은 더 나은 코드를 만들려고하지 않고 (적어도 프로토 타입 이외의) 코딩에서 완전히 벗어나게하는 것일 수 있습니다. 그는 정직 있다면 좋은 UX 디자인에서, 진짜 실수도 전혀 생산 코드를 작성하라고 요구와 아마입니다. 대신, 그는 UX 프로토 타입 샌드 박스에서 (최대한) 일을해야하는데, 그 결과는 생산 된 다음 실제 코드 라운드를 안내하는 데 사용되지만 생산 코드로 전혀 체크인되지는 않았습니다.


나는 이것에 대해 조금 생각했고 궁금해졌습니다. 나는 채용 과정에 관여하지 않았으며, 그는 분명히 코딩을 할 것으로 예상되었지만, 아마도 UX 녀석으로서 그는 모든 프로그래밍에 대해 많은 경험이 없었습니다. 그가 20 년 이상 소프트웨어를 개발해 왔기 때문에 믿기 힘들고 80 년대에는 "UX"가 많지 않았습니다.
LostInCode 4:27에

그는의 완료 조금 (말) 10 년 동안 코딩 경우 아니,하지만, 그는이 될 수 아주 (그는 심지어이었다 특히 녹슨 작은 시작하는 코딩에 약한). OTOH, 90 시간 이상 근무할 때는 확실히 상사와 이야기해야 할 정당한 이유가 있습니다.하지만이 동료의 약점보다는 그 문제를 해결하는 데 더 집중할 것이라고 생각합니다.
Jerry Coffin

18

나는 항상 상사에게 프로젝트에 영향을 미치는 것들을 계속 알려주는 규칙을 찾으려고 노력합니다. 긍정적이고 부정적으로 ... 그리고 이런 경우 에는 코드 를 작성한 사람이 아니라 코드 와 같은 것을 비난하려고 합니다. 동료를 강타하는 것보다 훨씬 덜 들리고 제품의 품질을 향상시키려는 것처럼 보입니다.

경영진의 입장에서이 상황에서 직원을 처리하는 일반적인 3 가지 방법이 있습니다.

  1. 약점을 통제하라
  2. 그들의 강점을 플레이
  3. 그것들을 제거하십시오 (실제로 당신의 선택이 아닙니다)

외부의 도움을 구하여 약점을 통제하십시오.

보스, 코드의 상태에 대해 약간 걱정하고 있습니다. 매우 깨지기 쉽고 많이 깨졌습니다. 신뢰할 수 있다고 생각되는 상태가 되려면 약간의 노력이 필요합니다. 건축가 중 한 사람을 하루나 이틀 동안 빌려서 좋은 디자인을 만들 수있을 가능성이 있습니까?

다른 사람에게 프로젝트 참여를 요구하지 않고 짧은 시간 동안 더 많은 '전문가 입력'을 요구하고 있습니다. 건축가가 원하는 경우 필요한 모든 문서, UML 다이어그램 및 코드 스 니펫을 생성하십시오. 코드의 상태를 확인한 다음 상사가 다른 사람에게 의견을 제시 할 것입니다.

회의에서 여러분과 다른 개발자가 많은 것을 망칠 필요없이 더 나은 디자인을 얻을 수 있기를 바랍니다. 이것은 많은 경우에 설계 및 사양이 적용되는 것입니다.

그들의 강점을 플레이

보스, 저는 프로젝트 x의 코드로 작업하고 있으며 화려합니다. 반면에이 코드는 상당한 작업을 수행 할 수 있습니다. [ux guy]가 UX에 더 집중할 수 있다면 프로젝트가 더 좋을 것이라고 생각하지만, 좀 더 안정적인 상태로 만들기 위해 리팩토링을합니다. UX가 확실 해지면 프로젝트 b 는 아마도 Midas touch를 사용할 수 있습니다.

여기, 당신의 상사가 바로 그것을 볼 것입니다; 다른 개발자는 그다지 좋지 않다고 말하지만 적어도 당신은 그것에 대해 멍청하지 않습니다. 그리고 그가 UX 작업을 정직하게 잘한다면, 각 프로젝트에서 안정적인 위치를 차지하고 유용성 관점에서 훌륭하게 만들 수 있습니다. 나는 그가 그런 식으로 더 나은 것을 원한다고 생각합니다.


+1 기술 사양 및 다이어그램의 경우 나쁜 개발자가 할 수있는 피해를 줄입니다. 사실입니다.
maple_shaft

비난 게임을하는 대신 나쁜 코드에 집중하면 +1입니다. 인터네 신 충돌은 항상 일정과 코드 품질에 부정적인 영향을 미칩니다.
TMN

9

정지는 반복적으로 자신의 실수를 수정. 그는 배우지 않을 것이다. 나는 그렇지 않다는 것을 안다.

프로그래밍은 주로 논리적 인 작업이지만 메모리 수집도 포함됩니다. 공통 코드를 자주 작성할 때 솔루션 을 다시 파악하지 않고 마지막으로 솔루션을 구현 한 방식 을 기억 합니다. 그가 올바른 코드를 구현하지 않았다면 왜 그가 같은 실수를 계속 반복하는지 알 수 있습니다.

그에게 자신이 잘못한 것을 보여주고 처음에 고치십시오. 같은 사건이 더 발생하면 그에게 보여준 수정을 시행하게하십시오.


5

몇 가지 이유로 조심해야합니다.

  1. 최초 출시 이후에 그와 함께 일하지 않을 것이라고 어떻게 확신하십니까? 경영진은 "어떻게 팀이이 위대함을 함께 제공했는지 살펴보십시오!"라고 생각할 수있었습니다. 당신을 함께 유지하고 싶습니다.

  2. 당신이 상사에게 가면, 당신은 당신의 입장을 설명하려고 어떻게 기술적으로 원하십니까? 동료의 성과가 얼마나 나쁜 문서가 있습니까?

그것들은 내가 당신이 요청한 것에 주목할 것입니다. 코드에 대해 물어보고 코드가 왜 그런지에 대한 칭의가 있는지 확인하십시오. 아마도 코드를 작성하는 동안 서클에서 실행되어 일부 문제가 발생할 수 있습니다. 원은 일련의 변경 사항을 통해 무언가를 코딩하는 곳으로 누군가의 변경 목록이 결국 취소 될 때 시작한 것과 거의 동일한 지점에 도달합니다. 나는 피곤한 변화 후에 변화가 일어나고 변화를 취소하는 상황에 처해있었습니다.


예, 비슷한 생각을했습니다. 나는 정직하게 내가이 일을 바로 잡기 위해 투입해온 90 시간 이상의 팬의 팬이 아니기 때문에 상사에게 아무 말도 하지 않으면 실제로 1 번 이 무섭다. 나는 내 상사에게 내가 의미하는 바를 보여주는 데 아무런 문제가 없을 것이고, 그는 그 문제를 인식 할 것이지만, 나는 내가 어떻게하면 어떻게 벗어날 지 모른다. 나는 정중하고 도움이되는 방식으로 동료와 함께이 문제를 해결하려고 노력했지만 같은 실수를 계속합니다. 입력 해 주셔서 감사합니다.
LostInCode

5

그의 작업을 모두 다시 수행하지 않고 프로젝트를 실패하게 만들면 어떤 결과가 발생합니까? 당신에게 결과는 의미합니다.

그의 경험 수준과 직책의 누군가가 우연히 거기에 도착하지 않았기 때문에 그의 일이 당신이 그것을 인식하는 것만 큼 나쁘지 않거나 그의 경력 전체가 그를 따라 다니는 사람들로 구성되어 있습니다.

프로젝트에서 일주일에 50 시간 이상 일하는 경우 프로젝트에 심각한 문제가 있으므로 PM의 관심을 끌지 않거나 떠나지 않아 스스로 장애를 일으 킵니다. 저는 하더가 아니라 더 작게 일하는 것을 강력하게지지합니다.

현명하게 작업하고 프로젝트가 제대로 작동하지 않으면 IT는 당신의 결함이 아닙니다. 그의 무능함으로 인해 실패하고 그들이 당신을 비난한다면 그것은 아마도 당신이 일하고 싶은 환경이 아닐 것입니다.

너무나 많은 친구들이 실패 또는 성공이 경력 전체에 직접적인 영향을 미치는 것을 알지 못했을 때 실패를 두려워하기 때문에 잘못 관리되는 프로젝트에서 일주일에 40 분 이상 일을 잘합니다.

프로젝트의 80 % 이상이 실패하면 부끄러운 일이 없습니다.


아름다운 접근 및 69 발명 합계 번호 % +1
cregox

@Cawas, LOL, 나는 그 통계를 추측했지만 메모리에서 추측했습니다. 나는 프로젝트의 거의 80 %가 실패로 간주된다는 것을 어딘가에서 읽었다.
maple_shaft

코드를 작성할 수없는 20 년의 경험을 가진 개발자를 보았습니다. 그리고 당신이 심각한 주식을 가지고 있거나 시장에서 잘 지불되지 않는 한, 일주일에 50 시간을 현명하게 사용하지 마십시오. 현명한 40 작업하고 그들이 충분하지 않으면 구직을 시작하십시오.
케빈 클라인

4

이를 동료 검토라고합니다. 당신의 관리자는 당신에게서 그것을 기대하고, 그의 소중한 개발자의 시간이 어디에 소비되는지 알려줘야합니다. 나는 그가 이것에 대해 이미 모른다는 것에 놀랐다. 그러나 다시, 나는 더 나 빠졌다.

다른 사람과 대화하지 말고 매일하는 일과 관련하여 대화하십시오. 그것이 그의 코드를 파기하는 것을 의미한다면, 그렇게하십시오. 체크인 링크 등으로 무장하여 일상 업무에 대한 증거를 제공하십시오. 관리자는 20 년 동안 UX를 도입하고 강력한 코드를 얻습니다. 와이어 프레임을 수행하는 대신 프로토 타입 레벨 코드 만 작성합니다. 관리자에게 문의하십시오.

그의 보모로 고용되지 않았기를 바랍니다. 행운을 빕니다.


3

그의 작업을 다시 쓰거나 다시 실행할 필요가 없다면 프로젝트가 더 빨리 시작됩니까? 예산이 부족할 때 도움이 되나요? 개인적으로 우려를 제기하기 위해 강타하지 않아도됩니다. 여기에 대부분의 사람들이 실수를 저지르는 곳이 있으며 해결책을 제시하지 않고 불평합니다.

상사에게 결과를 개선 할 수있는 구체적인 권장 사항이 있습니까? 더 나은 문서? 강력한 사용자 테스트? 당신의 목표는 회사, 프로젝트, 동료 및 자신을 성공시키는 것입니다. 아무 문제가 없다고 주장하면 4 명 중 3 명은 전혀 실패 할 수 있으며, 운이 좋은 사람은 아닙니다.


1

당신은 당신의 상사에게 최대한 빨리 가서 당신이 여기서 말한 것을 분명히 말해줘야합니다.

우선, 이것은 의료 기기입니다. 버그가 있으면 누군가 다치거나 죽을 수 있습니까? 사람들의 삶이나 건강에 의존하는 코드는 최상의 시나리오를 위해 낙관론자가 쓴 버그가 아니라 인간이 할 수있는 한 강력해야합니다.

좋아, 내 전 매니저 모자를 쓰고 ... 당신은 당신의 상사가 이것에 대해 알고 있는지, 그것이 그의 뉴스라면 그의 반응이 무엇인지 전혀 모른다. 그러나 그가 모른다면 그는 필요하며, 당신은이 정보를 숨겨서 그를 추측해서는 안됩니다. 동료가 이런 식으로 코딩하는 것이 괜찮다면 알려줄 것입니다.

나는 몇 년 전에 이와 같은 상황에 부딪쳤다. "네트워킹 전문가"와 저는 계약자로서 개념 증명 작업을하고있었습니다. 실제로, 그는 거의 아무것도하지 않았고, 대부분 구토를하고있었습니다. 어느 날 상사는 우리에게 데모가 나올 것이라고 말했습니다. 곧, "네트워킹 전문가"는 많은 허쉬-허쉬 전화를 받기 시작했고, 마침내 데모 전에 다른 계약직 공연을하기 위해 떠날 것이라고 말했습니다. 내가 상사를 혼자 데려가 자마자 나는 그에게 그것에 대해 말했다. 그는 "네트워킹 전문가"를 버리고 내가 추천 한 사람을 데려왔다. 그는 3 일 만에 "guru"가 3 개월 만에 더 많은 코드를 작성했다. 데모는 대히트 였지만 조용히한다면 프로젝트는 완전히 실패했을 것입니다.


1
또한 저자는 관리자에게 시간을 보내는 것에 대해 알려줄 것을 제안합니다.
Ramhound

0

네, 상사에게 말하십시오. 그러면 당신이 그곳에있는 사람이 아닌지 알게 될 것입니다. 팀이 어떻게 운동하고 있는지 알고 있고, 보스가 아직 눈치 채지 못했을 경우, 내가 코딩했던 곳과 같이 적절한 코딩을하는 것만 큼 신경 쓰지 않을 것입니다.

그리고 다른 모든 직장들 중에서, 이미 많은 수의 친구들로부터 손을 (5를 의미하는) 친구들로 가득 찼다면. 그들은 모두 좋은 남자와 여자를 가졌지 만 당신은 당신의 일을한다고해서 우정을 잃지 않을 것입니다. 만약 당신이 그들을 잃어 버리면 그것은 좋은 것입니다. 당신의 경우에, 그는 당신보다 직업을 더 소중히 여길 것입니다.

물론, 그를 해고하려는 시도는 아닙니다. 그것은 단지 프로젝트에 대한 당신의 관심사를 보여주는 것입니다. 그래서 여러분 모두가 거기에 있어야합니다.

당신은 결국 그와 대화를 시도했지만, 아무 것도하지 않으면 실제로 그곳에서 일을 할 위험이 있습니다.


2
나는 왜 그의 코드가 작동하지 않는지 또는 더 나은 방법을 설명하기 위해 여러 번 시도했다고 언급하지 못했습니다. 불행히도 같은 실수를 계속 반복합니다.
LostInCode

운 좋게도 "소규모"클래스 프로젝트 였지만 다른 팀 멤버와 같은 문제를 겪었습니다. 코드 작업을하는 동안 그와 짝을 이루어 프로그램을하도록 가르치십시오. 이것은 당신이 이것이 잘못되었다고 말하는 것이 아니라 자신의 실수를 직접 보게 할 것입니다. 또한 회사의 누군가가 어떻게 작동하는지 확인할 수 있습니다.
Jonathan

프로젝트에 관심이있는 것처럼 보일 때주의하십시오. 많은 곳에서 확고한 경영진으로 고통 받고 있으며 많은 경우 프로젝트에 대한 자신의 충성도에 더 관심이 있습니다. 그들은 스스로 당신이하는 것처럼 프로젝트를 중요하게 보지 않을 수도 있습니다. 그래서 그들은 다른 개발자의 열악한 성능을 다루는 데 결코 신경 쓰지 않았을 수 있습니다.
maple_shaft

@LostInCode 예, 새로운 정보와 일치하도록 완전히 편집 한 후에도 조언이 훨씬 나아지지 않았습니다. 챈들러 인 것 같아
cregox
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.