팀에서 느리고 헌신적 인 동료를 어떻게 처리합니까? [닫은]

나는 새로운 프로젝트를 진행하고 있습니다. 프로젝트는 다음과 같이 작동합니다. 최종 사용자는 링크를 사용하여 웹 애플리케이션에 액세스 할 수 있으며 네트워크에 여러 시스템을 추가하고 특정 시스템 세부 사항을 관리 할 수 ​​있습니다. 내 부분은 파이썬으로 수행되는 프론트 엔드와 웹 서버와 관련이 있습니다. 내 파이썬은 실제로 c & c ++에서 완전히 수행되는 다른 프로젝트와 통신합니다. c / c ++ 프로젝트는 모든 기능을 수행하는 기본 앱입니다. 내 파이썬은 사용자 요청을 보내고 그 응답을 사용자에게 표시합니다.

나는 내 작업에 매우 익숙하며 곧 끝낼 것입니다. 그게별로 효과가 없기 때문에. 그리고 나는 일하는 것을 좋아하는 사람입니다. 나는 대부분의 시간을 사무실에서 보내고 졸릴 때만 집으로 돌아갑니다.

c / c ++ 앱은 5 년 이상의 경험이 있고 저보다 훨씬 빠른 작업을 수행 할 수있는 다른 동료가 관리하지만 결코 그렇게하지는 않습니다. 그는 그것을 좋아하지 않을 수 있습니다. 내 파이썬이 통신하거나 잘못된 값을 반환하면 그의 앱이 자주 충돌합니다. 버그로 가득합니다. 내 앱이 그것에 의존하기 때문에 앱을 만드는 데 어려움을 겪고 있습니다. 버그를 수정하는 대신 작업 속도를 늦추도록 요청합니다. 그는 관리자에게 내 작업에 많은 시간이 필요하다고 알려달라고 요청합니다. 그는 관리자를 속일 것을 요구하고 심지어 그와 같이 천천히 일하도록 강요했다.

프로젝트 회의 중에 관리자가 버그에 대해 물어 보면 모든 것을 고쳤으며 제대로 작동한다고 말합니다. 그가 내 동료이기 때문에 관리자에게 아무 말도 할 수 없었습니다. 우리는 대부분 관리자가 아닌 동료들과 함께 할 것이기 때문에 분명히 관리자보다 동료들과 좋은 관계를 맺어야합니다.

관리자가 이유를 묻는다면 관리자에게 그에 대해 불평했다고 생각할 수 있으므로 관리자에게 이에 대해 아무 것도 말할 수 없습니다. 그리고 그는 회의에 계속 누워 있습니다. 그는 버그를 천천히 수정하기 때문에 작업 속도가 느려집니다. 이제 내 앱의 프런트 엔드 부분에서 작업하고 마무리하여 프로젝트를 안정적으로 만들 수 있다고 생각했습니다. 이제 그는 관리자에게 프론트 엔드 부분에 많은 작업이 필요하고 더 많은 시간이 필요할 수 있다고 말하면서 프로젝트를 아래로 끌 수 있습니다. 그리고 슬픈 것은 우리의 실제 관리자가 미국에 갔다는 것입니다. 그래서 우리는 임시 관리자가 있고이 남자는 프로젝트에 대해 많이 알지 못하므로 c, c ++는 그를 속입니다.

누구든지 내가 어떻게 대처하는지 제안 할 수 있습니까? 나는 곧 프로젝트를 끝내고 싶었다. 그와 좋은 관계를 유지하여 어떻게 일할 수 있습니까?

의견에 대한 답변 :

그가 의도적으로 회사를 오도하는 경우 관리자에게보고해야합니다.

나는이 회사를 처음 접했고 다른 사람은 몇 년 동안 거기에있었습니다. 그리고 나는 동료들을 알게되었습니다. 내가 직접 가서 불만을 제기하면 다른 동료들과 좋은 관계를 맺을 수 있다고 생각하지 않습니다. 심지어 그는 그들을 오도 할 힘이 있습니다. 나는 그가 나쁜 사람이라고 말하지 않고, 그는 일을 할 수 있지만 그는하지 않습니다.

귀사에 버그 추적 시스템이 있습니까?

실제 버그 추적 시스템은 없습니다. 회사는 가능한 빨리 프로젝트를 끝내려고 노력하고 QA에 제공합니다. 그런 다음 품질 관리에서보고 한 버그를 수정합니다.

그렇기 때문에 회사는 직원에게 재고 / 옵션 또는 일종의 소유권을 부여해야합니다. 그렇게하면 당신은 말 그대로 그 사람에게 "당신은 나에게 화폐 성장을 원하고있다. 돈도 벌고 싶지 않니?"

이 회사는 2500 주식을 주었던 주식 옵션을 가지고 있으며, 대부분 더 많은 주식을 얻었을 것입니다.

선임은 의심의 여지가 있습니다. 당신은 정말로 그에게 먼저 말하고 문제를 이해하려고 노력해야합니다. 그는 그의 깊이를 벗어 났을 수도 있고, 그를 도울 수도 있고, 알지 못하는 변수가있을 수도 있습니다. 지금은 어려울 수 있지만 총을 튕겨서 상황을 쉽게 악화시킬 수 있습니다.

나는 심지어 그의 앱이 한 번에 여러 요청을 처리하지 않았고 대기열을 사용하여 내가 보낸 요청을 처리했습니다. 나는 그에게 내 아이디어를 제안했다. 그는 이미 이러한 아이디어를 가지고 있으며이를 실행할 것이라고 말했다. 그의 설명은 "모든 작업에는 특정 시간이 필요하며이 작업은 완료하는 데 2 ​​년이 소요될 수 있으며 2 개월 안에 완료해야합니다." 이 버그로 인해 처음 몇 주 동안 코딩이 어려웠습니다. 그러나 이제 그는 그것을 고쳤다. 그러나 그는 사용자 요청에 단일 대기열을 사용하고 있으며 한 번에 하나의 요청을 처리하기 때문에 앱 속도가 느려집니다.

QA는이 모든 시간 동안 무엇을하고 있습니까? 프로젝트 상태를보고 / 확인하지 않는 이유는 무엇입니까?

관리자는 품질 관리에 제공 할 시점을 결정하는 사람입니다. 현재로서는 아직 QA에 제공되지 않았습니다. 그는 이번 달 말까지 제공해야한다고 말했다.

당신은 나쁜 상황에 처해 있습니다. 나는 당신의 신발에 있고 싶지 않습니다. 동료와 충돌하지 않고 정리할 수는 없습니다.

이것이 내가 할 일입니다.

• 범죄에서 그의 파트너가되지 마십시오. 프로젝트 또는 프로젝트의 상태에 대해 거짓말하는 것을 거부하십시오.

• 애플리케이션에 버그보고 (필요한 경우 여가 시간에)를 구현하여 모든 버그를 이메일로 동료 및 관리자 에게 보냅니다 . 응용 프로그램으로 인해 버그가 발생한 경우 전자 메일에 표시하십시오 (전자 메일 제목 등에 [XYZ APP BUG] 입력).

• 전자 메일로 버그를 보내는 것 외에 버그 데이터베이스를 유지 관리합니다. 당신은 그 주된 목적이 추적 말할 수있는 당신의 사실은 대부분 추적 할 수 있습니다 때, 버그를 자신의 버그. 무엇보다도 특정 버그를 수정하는 데 걸리는 시간을 추적해야합니다.

• 그의 응용 프로그램과의 모든 프로세스 간 통신에 테스트가 포함되도록하십시오 ( "내가 이것을 보냈을 때 그 스타일을 반환해야합니다"). 매일 이러한 테스트를 실행하는 크론 태스크를 설정할 수 있으며 실패하면 이메일이 모든 사람에게 전송됩니다.

기본적으로 버그에 대해 논쟁하면서 시간을 낭비하지 말고 대신 작업에 집중하십시오. 그의 앱이 고장 나서 앱에서 작업을 할 수없고 관리자가 앱으로 아무 것도하지 않으면 관리상의 문제이며 버그 데이터베이스, 이메일 및 테스트 보고서로 처리됩니다.

그러나 조심하고 그를 과소 평가하지 마십시오. 그와 같이 오랫동안 느슨해 진 사람은 소매에 2 ~ 2 개의 트릭이있을 수 있습니다. 그는 팀 전체를 당신이나 다른 것에 대항 할 수 있지만, 그것은 당신의 특정 상황에 달려 있으며 그것은이 질문의 범위를 벗어납니다.

나는 약간 논란의 여지가있는 견해를 던질 것입니다 : 당신은 깨어있을 수있는 한 많은 시간을 일하고 있다고 말합니다. 아마도 그는 "너희가 나쁘게 보이고 실제로 내가 원하는만큼 많은 시간을 일하고있다"고 말하는 것이 부당하지 않을 수도있다. 어쩌면 그는 거기에 있었고 그 일을하고 어쩌면 태워 버렸을 것입니다. 나는 당신이 그것을 유지한다면 당신이 할 것이라고 약속드립니다.

어느 날 밤 그와 함께 술을 마시고 전문가를 기반으로 더 나은 개인적 관계를 구축 할 수 없는지 알아보십시오. 어쩌면 조금 더 넣겠다고 동의하고 조금 덜 넣는 것에 동의하면 둘 다 더 잘 협력 할 수 있습니다.

내가 당신이라면, 나는 또한이 "내 일, 당신의 일"태도 전체를 매우 조심할 것입니다. 두 사람 사이에 당신은 거기에 나가야 할 제품을 가지고 있으며, 이것은 아마도 그 제품에 좋지 않을 수 있습니다. 그것은 결국 회사 나 고객 모두 에게 좋지 않으며 그들은 둘 다 일하는 비용을 지불합니다 .

그러나 본인은 관리자와의 관계의 중요성을 재검토해야하며 동료를 신뢰할 때주의해야 할 다른 견해에 여전히 동의합니다. 나는 단지 당신이 자신의 행동뿐만 아니라 자신의 행동을 봐야한다고 말하고 있습니다.

기록을 유지해. 상대방과 의사 소통 할 때, 문제를 고치라고 요청했을 때, 그리고 언제라도 그랬을 때 발생하는 모든 오류를 기록하십시오. 이것이 내가이 상황을 다루는 유일한 방법입니다. 따라서 관리자가 문제가 진행되지 않는 이유를 물으면 소문이 나 나쁜 동료로 보이지 않고 명확하게 보여줄 수 있습니다.

제기되지 않은 다른 가능성을 지적하고 싶습니다. 당신은 그가 당신의 작업 속도를 늦추기를 원한다고 말합니다. 말 그대로 그는 "근무 시간 단축"또는 "일부 테스트 작성, 추가 테스트, 문서 작성"및 기타 속도 저하를 말하는 것입니까? 나는 새로운 사람들이 하루에 16 시간 동안 코드를 작성하는 것을 보았고 실제로 유효하지 않은 매개 변수를 전달하거나 반환 값을 확인하지 않을 때 호출하는 코드의 버그에 대해 불평하는 것을 보았습니다. 나는 당신의 동료가 이런 것들을 생각하고 있다는 것을 배제 할 수 없습니다.

다음에 당신이 회의에 참석할 때 그는 자신의 모든 코드가 훌륭하다고 말합니다. 지금 수정 되었습니까? " 다음 세 가지 중 하나가 발생합니다.

• 그는 거짓말을하고 그런 문제가 없다고 말할 것입니다. "그렇습니다! 우리는 그것을 토론했습니다! 이메일을 보냈습니다!" 모든 것은 관리자의 관심을 끌 것입니다
• 그는 실제로 코드에서 버그가 아니라 코드에서 버그라고 말합니다. 근무일을 지나야하기 때문에 곧 그가 생각하고 있지만 말하지 않은 것을 알게 될 것입니다.
• 그는 "아니오, 당신이 나에게 오늘 다루겠다고 말한 것이지만 다른 모든 것들은 좋다"고 말할 것입니다. 그가 그렇게 말한다면, 그냥 고마워.

당신은 당신의 오랜 빠른 코딩이 좋은 코드를 생성하지 못한다는 것을 알게 될 것입니다. 그리고 누군가 (관리자)는 다른 개발자가 문제가 무엇인지 설명하기 위해 번역 할 수도 있습니다. 또는 누워있는 뱀과 함께 일하고 있다는 것을 알게 될 수도 있습니다. 물건을 공개적으로 가져 오는 것이 실제로 더 나빠질 수는 없습니다. 또는 당신은 정치에 사로 잡히지 않고 그에게서 설 수있는 충분한 움직임을 얻을 수 있습니다.

당신이 가진 것은 정치적 문제입니다. 먼저 관리자의 의견은 생각보다 훨씬 중요합니다. 이 녀석은 지연에 대해 당신을 비난하고 당신이 그를시키는 것입니다. 당신은 누군가가 버스 아래에 던져지면 해고 당할 사람입니다. 지금까지 관리자가 알고있는대로, 당신은 적시에 일을하는 능력이있는 하나입니다.

버그 추적, 전자 메일 등을 통해 가능한 한 자신을 보호하십시오. 그러나 이것이 그의 지연이 아닌 척하는 것은 아닙니다. 상사에게 가짜 상태 보고서를 제공하지 마십시오. 상사가 코드가 작동하지 않는 문제에 대해 진실을 말하고 증거를 보여주십시오.

당신이 느슨해 보이도록 느슨하게 해달라고 요청하는이 사람은 뱀입니다 (잘 뱀 뱀 커뮤니티에 대한 모욕 (미묘한 반딧불 참조), 거기에있는 모든 실제 뱀에게 미안합니다). 그는 버스 대신에 당신을 던지기 위해 무엇이든 할 것입니다. 그를 믿지 마십시오.

무엇보다 먼저:

그가 내 동료이기 때문에 관리자에게 아무 말도 할 수 없었습니다.

동료가 자신의 얼굴에 누워 있어도 관리자가 진실을 알 수 있도록해야합니다. 회의실에서 3 명 모두와의 회의에서 아무 말도하고 싶지 않다면 완전히 이해할 수 있습니다. 그러나 적어도 관리자 (임시뿐만 아니라 실제 관리자)를 제쳐두고 당신의 작업이 거의 완료되었으며 전체 응용 프로그램이 프라임 타임 준비가되기 전에 다른 개발자의 말에서 버그 수정을 기다리고 있음을 알려야합니다 . 동료가 거짓말을한다고 비난하지 말고, 거기 앉아 앉지 말고 상사가 불완전한 정보로 작동하게하십시오.

당신의 상태를 정직하게보고하십시오. 다른 개발자의 말에 버그로 인해 작업이 중단 된 경우 C / C ++에서 버그를 발견했으며이를보고했다고 문서화하십시오 (문서를 남기는 문서 형식을 사용하고 있다고 말씀해주십시오).

그동안 작업을 마무리하고 작업이 끝나면 상사에게 알리십시오. 관리자가 프로젝트의 나머지 부분이 아직 시작되지 않은 이유를 알고 싶다면 다른 개발자를 추천 할 수 있으며 아마도 매우 복잡하고 / 대량 / 많은 테스트가 필요하다고 말할 수 있습니다. 바쁜 등 C / C ++를 알고 있다면 주요 응용 프로그램 논리를 통해 작업을 진행할 수 있습니다. 예, 당신은 다른 사람의 일을하게 될 것이지만, 당신이 직원이 열심히 일하고 생산적이며 다른 사람이 당신을 상사에게 더 가치있게 만드는 것은 말할 것도 없습니다. 심지어 다른 개발자가 일을 강화하고 더 빨리 끝내도록 압력을 가할 수도 있습니다.

직장에서 많은 문제가 있습니다. 다음을 명심하십시오 :

1. 당신은 다른 사람들의 동기에 대해 가정하고 있습니다
2. 당신은 의견을 가지고 사실을 채색하고 있습니다.
3. 외부인 (다른 사람)은 역사를 알지 못하며 동료와의 좌절감을 알지 못합니다.
4. "gotcha"게임을하고있는 것으로 보이는 경우 유치하게 보일 수 있습니다. 당신의 동료는 아마 더 잘 재생할 수 있습니다-그는 여전히 직업을 가지고 있지 않습니까?

따라서 프로젝트 상태를 제시 할 때 :

1. 다른 사람은 언급하지 마십시오.
2. 개발자가 아닌 코드 관련 오류 또는 문제를보고 할 때 "FooBar () 메소드 호출은 2를 리턴해야 할 때 1을 리턴합니다"라고 말합니다. 그렇다면 어떤 문제는 개인적인 공격이 아니라 사람들이 아니라 코드에 대해서만 말하는 것입니다.
3. 증거가 있다는 사실을 고수하십시오.
4. 동료가 방어 적이거나 적대적이라면 질문하십시오. "당신은 내가해야한다고 생각하는지 이해가 안 _ "
5. 사소한 일이나 수고를 잘 모르십시오. 개인적인 공격을받지 않는 척하십시오.
6. 어떤 상태 회의 전에 밤에 많은 수면을 취하십시오. 그래서 당신은 정신적으로 민첩합니다.
7. 문서, 문서, 문서.
8. 이 녀석에게 흥미로운 문제를 도와달라고 부탁하는 것에 대해 부끄러워하지 마십시오. 이것은 관계를 구축하는 것입니다. (이것은 빨라 지지 않습니다 -이것은 다른 것입니다)
9. 불필요하거나 감정적으로 갇히지 않도록해야 할 경우 떠날 준비를하십시오. 이것은 회의에서 머리를 유지하는 데 도움이 될 것입니다.

"저는 일하는 것을 좋아하는 사람입니다. 나는 대부분의 시간을 사무실에서 보내고 졸릴 때만 집에 돌아갑니다."

피할 수없는 소진으로 몇 년이 걸릴 수 있다는 점을 보상받지 않으면 건강하지 않으며 동료에게 기대할 수 없습니다. (회사에서> 10 % 이상의 소유권 또는 $ 200ka 연도 이상). 그가 매우 빨리 개발할 수있는 지점에 도달하기 위해 전문 지식을 유지하려면 시간이 걸립니다. 귀하의 시간 중 일부는 전문 지식 개발에 전념해야합니다.

"c / c ++ 프로젝트는 모든 기능을 수행하는 기본 응용 프로그램입니다. 내 파이썬은 사용자 요청을 전송하고 그 응답을 사용자에게 표시합니다. ... 그가 싫어하는 것 같습니다."

파이썬은 C / C ++보다 더 민첩한 언어입니다. 그의 앱에는 모든 기능이 포함되어있는 것 같습니다. 앱은 UI뿐입니다. 그렇지 않을 수도 있지만, 어려움이 동일하지 않습니다. 코드를 빨리 생성하지 않을 수 있습니다. 그러나 품질 코딩은 수량 코딩보다 훨씬 낫습니다. 일할 의사가 있거나 예상되는 시간 (주로 ~ 40 시간)으로 얼마나 빨리 코딩 할 수 있는지에 대한 비현실적인 기대가있을 수 있습니다. 작업 주 중 상당 부분을 차지하는 프로젝트).

그를 위해 거짓말하지 마십시오. 그러나 다시는 그를 비판하지 않습니다. 그의 시스템이 얼마나 위대한 지 이야기하십시오. 완료 될 때까지 더 많은 작업이 필요하다는 것을 인정했습니다. 이름을 지정하거나 책임을 부여하지 않고 관리자에게 정확한 상태 업데이트를 제공하십시오. 자신의 시스템이 준수해야하는 것과 동일한 표준을 따르는 시스템 모형을 작성하십시오. 자동화 된 테스트 스위트를 사용하여 시스템이 모형 시스템과 완벽하게 작동하는지 확인하십시오. 그러면 라이브 시스템이 여전히 버그가 있더라도 시스템을 완성 할 수 있습니다 (예 : 모형과 완벽하게 동기화 됨).

그런 다음 합의 된 표준을 준수하는 외부 시스템 호출을위한 자동 테스트 스위트를 작성할 수 있습니다. 예를 들어 Foo (1,2,3)보다 test는 "Bar 4 5 6"의 응답을 반환합니다. 이를 통해 개발 과정에서 버그를 식별하고 속도를 높일 수 있습니다 (코드를 엉망으로 만들 필요는 없음). 이러한 작업이 완료되면 다른 프로젝트 / 태스크로 넘어갈 수 있습니다 (예 : C / C ++ 파트 지원).

다른 사람들이 언급했듯이, 전문적인 행동은 장기적인 경력에서 가장 중요한 것입니다. 그리고 정직하게, 당신이 전문적으로 행동하는 한, 당신은 주변 사람들이 어떻게 행동하든, 꽤 좋은 모습을 보일 것입니다.

이 상황에서는 고려해야 할 몇 가지 사항이 있습니다.

먼저, 주어진 기한까지 원하는 사양으로 작업하는 프로그램에 대한 책임은 귀하에게 있음을 이해해야합니다. 귀하의 프로그램이 다른 사람의 프로그램과 상호 운영되는 경우, 귀하는 다른 프로그램도 동일한 마감일까지 작동하도록해야 할 책임이 있습니다. 달리 말하면 : 다른 사람이 마감일을 놓치면 프로젝트의 일부가 제 시간에 맞춰져 있어도 마감일을 놓친 것입니다. 관리 용어로이를 입력 소유 라고 합니다 .

동료가 회의에서 자신의 프로그램 버그가 수정되었다고 선언하면 즉시 관리자에게 잘못된 것으로 선언 할 수 없습니다 (관리자는 "버스에서 동료를 던지는"것으로 볼 수 있습니다). 매우 나쁜 경력 이동). 반면에 다른 사람들 은 프로젝트의 실제 상태를 관리자에게 선언 하지 않는 것이 비전문가라고 지적했습니다 . 양쪽이 완전히 맞습니다.

따라서 관리자 앞에서 동료와 모순되는 것이 좋지 않고 모순 되지 않는 것이 나쁜 경우 어떻게해야합니까?

답은 실제로 매우 간단합니다. 관리자와 회의를하기 전에 동료와 잘 이야기해야하며, 다가오는 회의에서 관리자에게 발생한 문제에 대해 관리자에게 알려야한다는 것을 알려야합니다. 그들의 프로그램, 그리고 그것은 당신의 프로젝트 측면을 정시에 제공하는 능력과 그들이 겪고있는 어려움을 해결하기 위해 당신이 할 수있는 일이 있는지에 영향을 미치고 있습니다. 이 대화 는 회의 전 최소 2 일 전에 관리자에게 알리고 일주일 전에 미리 대화해야합니다 .

대부분의 경우 동료에게 특정 회의에서 자신의 프로그램을 위험으로 나열해야한다고 말하면 문제를 해결하기 위해 동기를 부여받을 수 있으며 관리자와 전혀 대화 할 필요가 없습니다. . 문제가 더 일정에 따라 진행되는 경우에는 종종 동료가 귀하에게 동의하며 두 사람이 함께 관리자에게 갈 수 있습니다.

나는 이런 식으로 표현할 때 나를 위해 신속하게 문제를 해결하거나 내 관심사에 동의하지 않은 동료가 없었습니다. 그러나 이런 일이 발생하면 동료에게 사전 경고를함으로써 관리자와 대화 할 때 여전히 더 나은 위치에있게됩니다. 동료와 이야기를 나누고 스스로 해결책을 찾기 위해 노력하고이 회의에서 문제를 제기해야 할 것이라고 미리 경고 했으므로 동료는 놀라지 않을 것입니다. 당신은 단순히 책임을 이동하려고 생각하지 않습니다.

동료 나 관리자에게 우려 사항을 표현할 때 나쁜 데이터를 반환하는 동료 프로그램 (또는 다른 작업)에 대한 우려가 있음을 기억하십시오. 이것들은 확인되고 수정 될 수있는 측정 가능한 것들입니다. 당신의 걱정은 동료가 느리거나 헌신적 이지 않은 것에 관한 것이 아닙니다 . 이것들은 측정 할 수없는 것이 아니며 사실 일 수도 있고 아닐 수도 있으며, 상사 앞에서 회의를 열어서 고칠 것 같지 않습니다.

어떤 버그 추적 시스템을 사용하고 있습니까? 나는 버그가 적시에 수정되지 않는 부분을 강조해야한다고 기대했을 것입니다. 코드가 다른 레이어의 입력을 기다리는 경우 프로젝트 추적 문서에서 지연이 강조 표시되어야합니다. 이것도 일어나지 않습니까?

여기에 부적절한 프로젝트 관리가있는 것처럼 들립니다. a) 자신에게 영향을 미치는 버그를 추적하고 b) 서면 토론을 수행해야합니다.

동료는 자신의 의지 부족을 해결하기 위해 개발 시간을 늘리라고 요구해서는 안됩니다. 언젠가는 관리자에게 해결해야 할 문제입니다. 일이 벌어지면서, 당신은 당신의 동료를 덮고 있으며 그것은 거의 확실하게 역효과를 낳을 것입니다.

동료를 고집하는 데 아무런 문제가 없지만 매일 상사에게 거짓말 할 것을 기대하는 사람은 없어야합니다. 나는 그를 사람으로 존중할 수 없었고이 사람을 우연한 지인으로 갖고 싶어하지 않았습니다. 그는 원수가되고 싶어합니다.

프론트 엔드로 인해 애플리케이션 계층에서 지연을 어떻게 주장 할 수 있습니까? 그렇기 때문에 별도의 작업을 수행 할 수 있습니다. 다음으로, 누군가 모빌 프론트 엔드를 구축하기를 원하기 때문에 더 많은 지연이 있습니까?

작업을 완료하십시오. 그의 앱에서 실패로 인한 모든 문제를 문서화하십시오. 그리고 집에 가십시오! 네가 졸리 든 상관 없어 가질만한 친구를 찾으십시오.

방금 RC Martin (Uncle Bob)의 "The Clean Coder"를 읽었습니다. 이 책의 주요 요점은 일반적으로 프로그래머가 전문적으로 행동하지 않기 때문에 많은 존경을받지 않는다는 것 입니다. 이는 주로 프로젝트 상태에 대해 경영진과 효과적으로 의사 소통하지 않는다는 것을 의미합니다.

거짓말은 확실히 매우 나쁜 형태의 의사 소통입니다. 당신의 동료는 매우 전문적이지 않으며 당신도 마찬가지입니다. 둘 다 프로그래머의 인식을 향상시키기 위해 아무 것도하지 않고 있습니다.

경영진에게 바로 가라고 권합니다. 그러나 나는 과거에 너무 정직하지 않아 (어떤 관련이없는 상황에서) 문제를 겪었으므로 조언을해야할지 모르겠습니다. 또한 많은 사람들이 지적했듯이 상황에 대한 당신의 인식이 생각만큼 정확하지 않을 수도 있습니다.

코드베이스에 익숙하지 않은 경우 다른 프로젝트의 상대적 노력과 복잡성을 추정하는 것은 어렵고 비합리적입니다. 그의 코드는 오류가 발생하기 쉽지만 매우 높은 수준의 추상화에서 나머지 모든 문제와 잘 어울릴 수 있습니다 ... 문제는 프런트 엔드에 필요한 유일한 코드입니다!

아니면, 그는 나쁜 직원 일 수도 있고 회사를 타고 다닐 수도 있습니다. 말할 수 없으며 자신감을 가지고 알아야 할 모든 정보가 없을 수도 있습니다.

미드웨이 전술을 제안합니다. 다음에 만날 때는 자신의 코드에 영향을 미치는 주요 버그에 대한 세부 정보를 가져 오십시오. 그가 모든 것이 좋다고 말할 때, 당신의 진보를 방해하고있는 한 가지 현저한 문제가 있다고 공손하게 말합니다 .

정치적으로, 그렇게 말하면 당신은 그가 옳지 않다고 주장하면서 여전히 멍청한 플레이를 할 수있는 기회를 제공하고 수비를하지 않습니다.

관리자는 다음 모임에서 문제가 해결되었는지 문의해야합니다. 그렇지 않은 경우 하나의 버그를 수정하라는 압력이 그에게 떨어집니다. 문제가 해결되면 감사합니다. 지금 제대로 작동하고 있으며 새로운 차단 기능을 찾았습니다. 당신이 특히 좋기를 원한다면, 당신은 회의 직전에 그것을 만났다고 말하십시오.

당신은 그 자체로 거짓말을하지 않으며, 편을 들지 않습니다. 당신은 문제에주의를 기울이고 일이 실제로 잘 진행되지 않는다면 동료가 얼굴을 구하게함으로써 정치를하고 있습니다.

관리자와 대화하고 싶은 유혹이 있지만 그 중 어느 쪽을 가장 많이 사용해야하는지 잊지 마십시오.

Pat의 대답은 훌륭했습니다. 100 % 동의합니다. 상사와 회의를 몰래 가지 마십시오. 네 눈 사이에 동료와 함께 가져 가거나 세 사람 모두와 함께하십시오. 그러나 사람들이 아닌 코드 문제에 초점을 두려는 Pat의 제안은 올바른 길입니다.

Btw, 주당 40 시간이면 충분합니다. 동기를 높이 유지해야합니다!

통합 테스트에 도움을 줄 다른 사람을 요청하십시오. 그 사람은 문제가 발생한 곳을 말할 수 있어야합니다. temptar가 지적했듯이 문제를 추적 할 수있는 Excel조차없는 이유가 궁금합니다! 추적이 없기 때문에 다른 사람이 현재 모든 것이 정상이라고 말하면서 탈출 할 때마다 마찬가지입니다! 그런 식으로 작동하지 않습니다!

모듈을 완료 해야하는 경우 ur 측에서 지연을 일으키는 원인에 대해 붉은 깃발을 들어야합니다. MERE Years의 경험은 할 일이 없습니다. 그저 지식과 그 점 때문에 관리자가 주장해야합니다. 내가 말했듯이 여기에서 프로젝트 관리가 열악하다고 느낍니다.

1. 추가 작업을 요청하고 조직에 가치를 더할 수있는 방법을 묻는 방법으로 이니셔티브를 표시하는 것이 신뢰를 얻는 가장 좋은 방법입니다.

관리자는 프로젝트 속도를 늦추는 사람을 파악하기에는 기술적으로 충분하지 않을 수도 있지만, 새로운 작업을 적극적으로 찾고있는 개발자가 현재 작업을 통해 산다는 것을 알기에 충분히 똑똑 할 것입니다. 이렇게하면 현재 작업에서 다른 사람의 버그 수정을 기다리고 있음을 분명히 할 수있는 대화가 나타납니다. 동료가 버그 수정으로 너무 느려지는 것이 아니라 자유 시간을 효율적으로 사용하여 조직 에 가치를 더할 수 있는 방법으로 토론을 구성 하십시오.