좋은 프로젝트 리더 나 상사와 대면 할 때

우리의 프로젝트 책임자는 천재적인 소프트웨어 아키텍트이며, 일반적으로 온화하고 사려 깊은 사람이며, 성격 상 괴짜이며 목소리로 섬세합니다. 그러나 때때로 우리 (팀원과 저)는 소프트웨어 아키텍처 문제, 시스템 설계 문제, UI 문제 등과 같은 의견이 리더와 다릅니다.

의견의 차이를 언제 어떻게 표현해야합니까?

당신의 상사가 틀렸다고 생각한다고 가정하자. 세 가지 옵션이 있습니다

• 그가 말한 것을하고 당신이 어리석은 짓을한다는 좌절 된 생각을하게됩니다.
• 그가 바보라고 말하십시오-그는 그것을 무시하거나 의사 소통 문제가 발생합니다-아무것도 얻지 못하거나 아프게합니다.
• 그가 제안한 아이디어에 대해 특별한 우려 가 있다고 말하고 그 우려 를 설명 하십시오. 좋은 상사는 자신의 입장을 설명하고 비즈니스에 적합한 결정을 내릴 수 있습니다. 그의 아이디어가 당신의 아이디어보다 낫다는 것을 알게 될 것입니다. 그리고 당신은 매우 중요한 것을 무시하고 있습니다.

항상 결과를 생각하십시오. 대부분의 경우 옳은 일을하기 위해 옳고 싶지 않다면 좋은 일만하면됩니다. 세 번째 옵션은이를 달성하는 데 도움이됩니다.

반대를 표명 할 때 부드럽게 존중하는 방식으로 그를 대하십시오.

전문가라는 말은 동료와 상사를 존중한다는 것을 의미한다고해서 동의하지 않는다는 의미가 아니라 예의 바르게 정중하고 존중해야한다는 의미입니다.

우리 팀이 나의 지시에 대해 의심 스럽거나 반대 의견을 가지고있을 때, 나는 그것을 나의 기회와 나의 팀 멤버 모두를위한 교육의 기회로 본다.

이것은 오래된 공격적 또는 수동적 오류의 예가 아닌가?

고전적인 세 번째 옵션은 주장 적이며 건설적인 비판과 공손한 의견 불일치 를 허용합니다 .

동등하게 중요- 건설적인 비판을 받아들이고 (필수적으로 동의하지 않고) 합리적인 의견 불일치를 수락합니다 (옳고 그른 사람과 틀린 사람의 경쟁에 사로 잡히지 않음).

http://en.wikipedia.org/wiki/Assertiveness

그리고 마지막 날에는 상사에게 연기되는 일종의 수동성이 항상 필요할 것입니다. 그는 궁극적 인 결정에 대한 책임을 가진 사람이다 - 능력, 권한과 책임되어 있지 똑같은,하지만 그들은 적어도 해야 함께 이동합니다.

BTW-Robert Bolton의 "People Skills"는 듣기 기술, 독단성 등을위한 좋은 (그리고 상당히 저렴한) 책입니다.

http://www.amazon.com/People-Skills-Yourself-Resolve-Conflicts/dp/067162248X

당신이 그를 존중하는 것처럼 보이고 똑똑한 사람처럼 보이는 이유는 다음과 같습니다.

"방법 / 방법 / 아키텍처는 x 문제를 어떻게 처리합니까?" 그렇지 않다면, "이런 식으로 x 문제를 처리하는 방법은 어떻습니까?"

이런 식으로, 당신은 그가 이미 "x 문제"를 생각하고 있고 무언가를 배우고 있는지 배울 수 있습니다. 또는 그가 그렇게 생각하지 않으면 해결책을 사용하거나 다른 해결책을 생각할 수도 있습니다 (아마도 함께 해결할 것입니다).

좀 더 구체적인 예를 생각해 볼 수는 있지만 아이디어를 얻을 수 있다고 생각합니다.

나는 그가 프로그래머 나 그와 비슷한 사람이 아니라면 어디에서나 상사에게 먼저 갈 것이라고 생각하지 않습니다.

그리고 자신의 방식이 나쁘다고 말할 필요는 없지만 특정 상황을 처리하는 방법을 묻음으로써 문제를 깨닫거나 문제가 아닌 이유를 말할 수 있습니다.

이게 도움이 되길 바란다.

CONFRONT라는 단어를 사용하면 올바른 사고 방식으로 문제에 접근하고 있지 않음을 알 수 있습니다.

대결이 아닙니다. 적대적이지 않습니다. 호전적이거나 화난 것은 아닙니다. 다양한 접근 방식과 비용 및 이점에 대한 토론입니다.

6 개의 총이 타오르는 상태로 들어 가지 마십시오. 당신이 생각한 것을 말해주십시오. "이렇게하면 어떡하지?" 누가 알면 그를 설득 할 수 있습니다.

또한 예산, 일정, 요구 사항, 기타 우선 순위 등에 대해 자신이 원하지 않는 사항을 잘 알고있을 수도 있다는 사실을 기억하십시오. 그는 당신과 동의하지 않기 때문에 반드시 바보가 아닙니다.

어떤 결정이나 주어진 디자인 / 소프트웨어 아키텍처를 의심하는 것은 잘못된 일이 아닙니다. 방금 첫 직장을 시작하지 않으면 99 %의 시간이 잘못되어 더 큰 그림 의 일부가 부족 합니다.

귀하 (및 / 또는 팀)가 의견이 다를 경우 프로젝트 리더에게 논의 할 시간이 있는지 물어 보거나 소규모 회의 (15-30 분)를 계획하십시오. 존중하는 방식으로 자신의 의견을 환기시키고 왜 그가 다른 결정을했는지 들어보십시오. 당신이 어떻게 그를 묘사했는지 보시면, 그는 문제에 대한 그의 통찰력을 토론하고 공유하게되어 기쁩니다. 그는 "내가 그렇게 말했기 때문에"(그런 사람들은 슬프게도 존재한다) 말하지 않을 것이다. 이 경우, 직업을 유지하고 싶을 때는 자신의 의견을 무시하거나 불행하게되기 때문에 다른 직업으로 떠나십시오.

좋은 토론은 여러 가지 방법으로 끝날 수 있습니다.

• 프로젝트 책임자는 문제를 해결하기위한 더 나은 방법으로 솔루션을 받아 들일 것입니다 (그리고 그는 아직 경험이 많지 않은 새로운 기술, 패턴을 배울 수도 있습니다).
• 당신과 팀은 그림의 더 큰 부분을 보거나 왜 이런 식으로 그렇게해야하는지에 대한 좋은 설명을 얻습니다. 새로운 것을 배우고 초기 솔루션이 올바른 솔루션임을 이해하거나 새로운 정보를 사용하여 솔루션을 개선 할 수있는 방법을 찾을 수도 있습니다 (어떤 시점에서는 동의해야 함).
• 토론은 도움이되지 않으며 여전히 동의하지 않습니다. 경험을 쌓을 가능성이 높기 때문에 그것을 포기하고 솔루션을 구현하십시오.

어쨌든, 그것을 배울 수있는 기회로보아야하며 문명을 존중하고 존중하는 한 이러한 토론에 대해 큰 경험을하게 될 것입니다.

그냥 가져와!

내가 할 수있는 가장 민첩하고 식민지적인 방법으로 나는 일반적으로 "이 부분에 관심이 있습니다.이 잠재적 문제에 대한 당신의 생각은 무엇입니까?"

나는 공을 그의 법정에 넣어서 나를 교육시킬 것이다.

성숙한 개발자와 관리자의 # 1 신호는 그들이 틀렸다는 것을 인정할 수 있다는 것입니다. 먼저 상사에게 보여주십시오. 여러분 모두가 자신이 잘못했을 때 자신이 잘못되었다는 것을 완벽하게 기꺼이 인정하고 상사에게 동일한 예의를 기대한다는 것을 분명히하십시오.

당신이 좋은 상사를 가지고 있다면 (그리고 당신이 그렇게 말한다면) 이것은 일반적으로 전혀 문제가되지 않을 것입니다! 당신은 건설적인 토론을 할 수 있고 모든 사람에게 최상의 해결책을 찾게 될 것입니다.

주의해야 할 사항 : 제안 된 설계를 의심 할만한 실제적이고 기술적 인 근거가 충분한 지 확인하십시오. "잘못 느낀다"는 일반적으로 충분하지 않으며 건설적인 토론에 기여하지 않습니다. 이런 일이 너무 자주 발생하면, 당신의 상사는 "토론"(단순히 논의하기는 어렵습니다)을 단락시키고 "죄송합니다."라고 말할 수밖에 없습니다. 왜 다른 아이디어가 더 나은지 사실로 입증하십시오. "

그렇기 때문에 귀하의 상사가 상사 인 것입니다. 개발자가 결정하기 어려운 결정을 내릴 수 있습니다.

내 의견과 내가 일반적으로 상사와 어떻게 행동하는지 :

주제가 뜨거울 때 항상 의견을 말하고 최대한 빨리 처리하십시오. 용기와 결정이 이미 설정되어있을 때 나중에하지 말고 새로운 이슈 나 프로젝트에 대해 스크럼을 가지고있을 때 이상적입니다.

자신의 의견, 우려 사항, 문제를 공개적으로 제안하고 그러한 방식으로 수행해야한다는 것을 강요하기보다는 제안이나 우려 사항이 있는지 확인해야합니다.

그 습관을 버리고 더 나은 의사 소통 자, 팀원, 그리고 더 나은 팀이 되십시오. 좋은 팀은 긍정적 인 것뿐만 아니라 부정적인 것에 대해서도 공개적으로 이야기 할 것입니다. 훌륭한 팀 리더는 팀의 의견을 듣고 제공된 정보를 고려하여 결정을 내립니다.

행운을 빕니다.

그가 당신이 묘사 한 것처럼 훌륭한 건축가라면, 당신의 우려에 대한 논리적이고 구체적인 이유를 가지고 교육받은 방식으로 그에게 접근하십시오.

시간 / 자원이 있다면 자신이 옳다는 것을 입증 할 수있는 시나리오를 테스트하려고한다면, 데이터를 보유하는 것이 큰 도움이됩니다.

당신이 그와 이야기하면 그는 단지 할 수 있습니다 :

a) 당신과 동의하십시오 : 문제가 해결되었습니다!

b) 거부하고 이유를 설명하십시오. 어쩌면 당신은 잘못된 사람 일 것입니다.

c) 이유없이 거부하십시오 : 그가 불합리하고 완전히 확신한다면 책임있는 프로젝트에 관심을 표명하십시오.이 경우 실제로는 차가운 데이터가 필요하며 가능하면 팀의 다른 구성원의 지원이 필요합니다. 건축가를 매우 행복하게 만들지는 않지만 윤리적 일입니다 (건물을 설계하고 구조에 결함이 있다고 상상해보십시오 ...)

내 질문은 의견의 차이를 언제 어떻게 표현할 것인가?

물론 그렇습니다. 통제 할 수없는 부분이 없다면난기류 가능성이나 그로 인한 일자리 상실 가능성이 너무 큰 드문 상황이 아닌 한, 다른 의견이있을 때 다른 사람들과 대면해야합니다.

여기서 중요한 열쇠는 언제 그리고 어떻게.

첫 번째 '언제': 모든 환경은 다르지만 일부 장소는 주별 회의 또는 오픈 / 라운드 테이블 토론을 통해 특정 주제를 제기하는 것이 적절한 장소입니다. 당신이 하지 않는 주요 원하지 과 1 ~ 2 명의 사람들 사이에있는 개인적인 디자인 논쟁을 겁 내거나 공개하는 것처럼 만드는 것입니다. 당신이 도전하는 사람들은 도전을 받고 고마움을 느끼지 못하고 심지어 공공 장소에서 당혹 스러울 수도 있습니다. 이러한 상황에서는 자신의 생각을 자세히 설명하기 위해 해당 사람과 일대일로 회의를 예약하십시오.

'방법'2 차 : 상급자에게 가려면 생각을 뒷받침 할 모든 오리를 한 줄에 두십시오. "모든 웹 양식을 중지해야하며 MVC를 수행해야합니다!"라고 말하는 고위급 직원 사무실로 넘어갈 수는 없습니다. "왜?" "모든 사람이하는 일이고 모든 잡지에 있습니다"라고 말하면 멀지 않습니다. 아키텍처, 코딩, 디자인, 베스트 프랙티스 등에 대한 생각을 정당화하는 것에 대해 앞뒤로 논의 할 준비를 갖추십시오. 작업을 정당화하기위한 작업 코드의 예가 있다면 (즉, 생각을 증명하기위한 작은 테스트 하네스) 도와주세요. 여기서 중요한 것은 자아 싸움에 빠지거나 감정이 일어나지 않도록하는 것입니다.

결국 당신이 견고하고 정당하며 ​​논리적 인 제안을한다면 그것들을 고려해야합니다. 그러나이 세상에는 자신 이외의 다른 사람의 말을 듣고 싶지 않은 불합리한 사람들이 몇 명있을 것입니다. 이 유형의 개성을 가진 구석에 백업되지 않기를 바랍니다.

행운을 빕니다!

실수를 저지르고 질문을받지 않고 어떻게 훌륭한 소프트웨어 아키텍트가 될 수 있는지 잘 모르겠습니다. 그가이 상황에 처했다고 가정하는 것이 안전하다고 생각합니다.

똑똑하고 성숙하고 전문적인 사람들은 더 나은 아이디어의 유혹에 오랫동안 저항 할 수 없습니다. 그가 처음에 자신의 아이디어에 의문을 제기하여 화가 나더라도 결국 그는 와야하며 당신은 그것에 대한 존경을 얻게 될 것입니다. 그가 성숙하지도 전문적이지 않다면 더 큰 문제가 생겼을 것입니다.

그가 전문 건축가라면, 그는 두 번째 의견을 존중하고 받아 들일 것입니다. 그러나 어쨌든 사실 / 전문 지식을 기반으로 대안을 잘 준비하고 제시해야합니다. 또한 아키텍처와 관련하여 이러한 문제에 대해 기본적으로 두 가지 다른 가능성이 있음을 명심하십시오.

1. 하나의 접근법 / 디자인은 수학 2 + 2 = 4에서와 같이 단순히 5 개가 아닌 옳거나 잘못 될 수 있습니다. 잘못된 경우 사실 이의 제기를 바탕으로 올바른 해결책을 찾아야합니다.
2. 지금까지 시스템 설계에서 가장 많은 주제는 배타적이지 않은 가능한 접근법입니다. 경험, 풍미, 편견, 전반적인 그림 등에 따라 선택하는 다른 대안도 있습니다. 더 나은 접근법을 감독하지 않기 위해 개발자가 의견을 말하고 의견을 나누도록 권장 할 때 일반적으로 프레젠테이션과 토론이 있습니다. 그러나 민첩한 프로그래밍에서는 이러한 단계가 잘 정의되어 있으며 토론 기간과 구현 기간이 있습니다.