대규모 회의에서 좋은 디자인을 얼마나 효과적으로“판매”

여러 번 나는 슬픈 비극을 목격했습니다. 다음과 같은 일이 발생합니다.

1. 새로운 프로젝트에 대한 팀 디자인 검토.
2. 구멍이 거의없는 단순한 디자인이 보입니다.
3. 나는 구멍과 그것들을 피하는 방법을 우연히 언급한다
4. 경고는 "실제로 '생존하지 마십시오'"와 같은 주석으로 무시됩니다.
5. 결국 "절대 일어나지 않을"일이 일어난다
6. 부서진 프로젝트에 대한 비상 팀 설계 검토.

어떻게해야합니까? "내가 그렇게 말한"태도를 극복하는 것은 친구를 사귀고 사람들에게 영향을 미치지 않을 것입니다. 때때로 몇 년이 지났고 3 단계의 의견은 잊혀졌습니다. 나는 확실히 세상의 문제를 상기시키는 성가신 해충이되고 싶지 않다. 나는 종종 앉아서 타이타닉이 유럽으로 항해하는 것을 보았다.

나쁜 디자인이 진전되는 것을 보는 것은 실망 스럽다. 또한 현재의 길에 처한 위험을 다른 사람들에게 납득시킬 수 없다는 것이 실망 스럽습니다. 나는 모든 사람이 다른 용어를 이해하는 다른 방법을 가진 팀 회의에서 최악의 일을합니다. 또한 자아는 이성과 사고로이기는 경향이 있습니다. 그룹 사람들이 새롭고 복잡한 아이디어를 사용하도록 설득하기위한 좋은 전술을 찾고 있습니다.

가능한 경우 프로젝트에 상당한 시간을 추가하지 않는 수정을 제안하십시오. 지금 끝내지 않으면 나중에 다시 작업하는 것이 훨씬 더 고통 스럽습니다. 팀에게 완전히 새로운 방향이 더 좋다고, 프로젝트를 지연시킬 수있는 원인 등을 설득하려고하면 더 어려워 질 것입니다.

회의에서 사람들을 방어 모드에 두지 마십시오. 그들은 단지 승자가되기 위해 싸울 것입니다. 지구가 둥글다는 데 동의하지 않을 것입니다. 이것은 정상적인 정치입니다 (예 : FoxNews의 모든 사람)

다른 개발자를 존중하는 것이 정말 도움이됩니다. 당신이 팀의 새로운 사람이라면, 당신은 SOL이라고 생각합니다. 따라서 팀 대표를 구성하고 실제로 레벨에서 벗어나려고 노력하면 바로 퇴장 당하지 않을 것입니다. 물론, 만약 당신이 항상 비관적 인 금액이라면, 당신은 단지 "부정적인"사람으로 분류 될 것입니다.

간단한 작업 (예 : 일정에 영향을 미치지 않음)의 경우 작업을 최선의 방법으로 수행하십시오. 즉각적인 결과물에 노력을 기울이면 (예 : 테스트 사례 작성 또는 일부 간단한 (하지만 멋진) 기능을 얻는) 결국 다른 사람들은 코드가 안정적으로 작동하고 시간 테스트를 견뎌냅니다. 코드를 사용하여 깔끔한 트릭을 보여주기 시작하면 모든 사람 앞에서 두 번 촬영합니다.

마지막으로, 나는 당신이 "나는 당신에게 그렇게 말한"루틴을하고 싶지 않다는 것에 동의하지만, 당신이 실제로 옳았을 때 당신의 상사 / 기술자에게 힌트를 주도록 노력해야합니다. 이전 의견으로 오래된 이메일을 다시 보낼 수도 있습니다. 이것이 "새로운"문제를 해결하는 데 도움이되는지 물어보십시오. 이 작업을 수행하지 않으면 사용자가 처음으로이 작업을 수행 한 사람임을 기억하지 못합니다. 결국 그들은 회의에서 과시하려고하지 않는다는 힌트를 얻게 될 것입니다. 다음 번에는 특히 "오래된"디자인이 현재 고장난 디자인을 대체하고있는 경우 두 번 날릴 것입니다.

드문 유스 케이스에서 문제가 될 것이라고 생각하는 것이 아니라 무엇이 효과가 있을지 식별 할 수있는 사람으로 명성을 쌓으십시오. 이러한 잠재적 인 문제를 볼 때 나중에 해결해야 할 각주를 고려하십시오.

사람들은 회중에 미치게됩니다. 회의 이외의 주요 인물에게 우려 사항을 언급하십시오. 그들은 이것을 위협이 덜한 것으로보고 그들의 디자인을 방어하는 것에 대해 생각하는 대신 당신의 주장을 듣는 데 시간이 걸릴 수 있습니다. 또한 유효한 포인트가있는 이유를 설명하는 데 시간이 더 걸릴 수 있지만 v1.0에서 해결하는 것은 불가능합니다.

키! 직속 상사의 의제가 무엇인지 완전히 이해하고 회의에 참석하십시오. 어쩌면 그들은 이것을 사소한 프로젝트로보고 회의에서 마지막으로 필요한 것은 더 중요한 문제에서 시간을 뺏어가는 해설자 일 것입니다. 그들에게 도움을 요청하십시오.

그들에게 영향을 미치려면 디자인 회의 밖에서 그것에 대해 이야기하십시오. 그렇지 않으면 그들은 단지 당신이 "점수"를하려고 생각할 것입니다. 많은 사람들이 "청중"과의 회의에서 실제 토론을하고 싶지 않습니다.

이 상황이 우둔한 보스를 가진 고독한 개발자와 어떻게 다른지 알 수 없습니다. 불행히도, 임박한 운명에 대한 경고에도 불구하고 프로젝트를 특정 방식으로 구축하고 배송하기로 확신 한 횟수를 잃었습니다. 그것은 당신을 건물뿐만 아니라 속담 타이타닉을 빙산으로 직접 항해하게합니다.

설명했듯이 비트가 속담에 부딪 칠 때부터 내 경고가 잊혀졌습니다. 때로는 더 이상 프로젝트에 참여하지 않은 후 (행운 적으로) 상황이 몇 달 이상 나빠졌습니다. 불행히도, 이것은 내 후임자가 미쳤다고 생각하게 만들었습니다. 보스가 손을 부인했다고 내기 할 수 있습니다. :)

그들이가 자신있게 우둔하기 때문에 어쨌든, '확신'프로그래머의 그룹은 때때로 단지 뾰족한 머리 보스 우둔으로 더 할 수 있습니다 제프 O 언급 . 이런 일이 발생하면 문제를 해결할 충분한 시간이 있습니다. 집단적인 방귀를 통해 이성의 목소리를 들으려고하지 마십시오. 이를 효과적으로 수행 할 수 있다면 책상 작성 소프트웨어 뒤가 아니라 회의가 진행되고있는 것입니다.

행동이 말보다 더 크게 말하면 다음과 같이 할 수 있습니다.

• 테스트 시나리오에서 설계가 정상적인 상황에서 실패하는 이유를 보여줍니다. 이것은 아마도 당신이 발표하는 작은 회의를 초래할 것이며 아마도 당신이들을 필요가있을 것입니다.

• 그룹이 '코너 사례'라고만 생각한 것을 적절하게 다루는 경쟁 제품을 보여주십시오. 예를 들어 스프레드 시트 프로그램에서 Google이 실수를 예상하는 데 걸리는 시간에 놀랄 것 입니다.

• 배송 예정일 1 주일 전에 다시 작성해야하는 마지막 프로젝트를 반복하십시오.

다시 말해, 첫 단계는 당신이 무엇을 하든지 개인이나 (많은) 더 작은 그룹을 다루는 것입니다. 귀하의 우려가 실제로 유효한 경우, 개발에 1 주일 또는 2 주가 더 걸릴 것으로 확신합니다. 언급했듯이 '내가 말한'자세를 피하십시오.

가능하면 회의 전에 (또는 심지어 후에) 디자인을 검토하고 디자이너들과 개인적으로 대화하십시오. 모든 동료들 앞에서 회의에서 사람들을 쏴 ​​버리면 당신의 제안에 대해 즉시 방어적이고 폐쇄적 인 태도를 취하는 경향이 있으며, 도움이된다고 생각하더라도 "문제가있는 제작자"라는 평판으로 이어질 수 있습니다.

"비평"을 제시하는 좋은 (그러나 종종 어려운) 방법은 선행 질문을하는 것입니다. 다른 사람이 귀하의 질문에 대답하고 자신에 대한 결함을 깨닫게하십시오. 그런 다음 자신의 아이디어와 훨씬 비슷해 보이며 앞으로 나아갈 가능성이 높습니다. 다시 말하지만, 이것은 개인 토론에서 가장 잘 작동하지만 회의 상황에서보다 외교적이고 효과적인 방법이 될 수 있습니다 (참고 : 회의에서 사람들을 설득하기 위해 논쟁이나 긴 토론에 빠지지 않도록하십시오. 아이디어를 얻고 시도하십시오. 회의를 마치고 회의를 마친 후 "간단히 이해하지 못한 것을 정리"하는 것이 "단순한 30 분을 만든 사람보다"하는 것이 더 나을 수 있습니다. 아침 내내 낭비하다 ")

또 다른 방법은 제안을 (디플로마 방식으로) 리드 디자이너 (또는 관련이 있지만 소규모 배포 목록)에 전자 메일로 보내는 것입니다. 그것은 당신의 아이디어를 고려하는 데 도움이 될 것입니다. 그리고 미래에 "내가 말한"상황을 지원할 수있는 "종이 흔적"을 제공합니다 (만약 배 모양이라면, 당신은 적어도 당신이 도와 주려고 노력했지만 하지만 상황이 나빠지면 올바른 회사에서 일하고 있지 않을 것입니다.)

마지막으로 때때로 "잘못"될 수 있음을 명심하십시오. 당신이 말하는 사람들은 당신보다 그들의 디자인에 대해 더 명확하고 더 완전하게 이해하고 그들의 접근에 대한 정당한 이유가있을 수 있습니다. 예를 들어, 저는 최근에 "비효율적 인"디자인을 만들어 낸 팀원에 의해 비난을 받았습니다 성능이 여전히 수용 가능하다는 것을 알았을 때 고의적 인 디자인 이었지만 개발 비용을 절반으로 줄일 것입니다. 코드 품질 결정보다는 비즈니스 결정이었습니다.) 다른 사람의 아이디어에 대해 열린 마음으로 생각하십시오. 때로는 당신에게 나쁜 생각으로 보이는 것이 고려되지 않은 이유로 좋은 생각 일 수 있습니다.

"그렇지 않을 것"시나리오를 만났을 때, "그럴 수없는"항목을 수정해야했던 과거의 모든 시간을 상기 시키십시오. 그러나 "내가 말했듯이"오지 않도록 조심해야합니다. 나는 우리가이 프로젝트를 위해 지금 무엇을해야한다고 생각하는지에 대해 과거의 문제를 해결하는 것이 가장 효과적이라는 것을 알게되었습니다. 결코 일어나지 않을 것입니다.

아마 당신의 문제는 당신이 문제를 피하는 방법을 부담없이 언급한다고 말하는 것입니다. 아마도 당신은 더 많은 정보로 무장하고 왜 이것이 시스템에 대한 위험인지 더 자세하게 보여 주어야 할 것입니다. 때때로 그것은 약간의 연구를 할 시간이 있은 후 두 번째 회의에서 주제를 제기하는 것을 의미합니다. 지금 얼마나 저렴한가에 대한 비즈니스 사례를 구축하십시오.

가장 좋은 방법은 팀 리더 자리에 오르는 것입니다. 이러한 기회를 활용하여 이러한 상황이 발생하고이를 피할 수 있었던 힘을 지적하십시오. 현재 팀을 매각 할 필요가 없습니다.

"실제로 구멍을 언급"의 "캐주얼"은 문제인 것 같습니다. 프로젝트 위험을 분석하기위한 일부 서면 프로세스를 사용하십시오 (또는 존재하지 않는 경우 가져 오십시오). 일반적으로 위험 분석 회의의 결과는 간단한 두 개의 열 표입니다. 위험과 위험을 완화하기위한 합의 된 전략은 무엇입니까 ( "우리는 결코 일어나지 않는다고 생각합니다"는 수용 가능한 완화입니다. 중요한 것은 현재 생각을 기록하는 것입니다 당시 문제에). 문제가 위험으로 기록되어 있는지 확인하십시오. 위험은 정기적으로 검토해야합니다. 기회는 위기가 실제로 발생하고 검토가 "OMG 역할을 할 위험 오래 전에 꽤 많은 사람들이 당신의 관점에 라운드 온 것입니다 일어나지 않는; 우리는 이런 촉매제를 가지고 계속 미쳐 버릴 것입니다. 장기적으로, 종이 흔적은 "봐, 여기에 제도적 문제가있는 것 같습니다"라고 말하고 디자인이나 변화된 것에 대한 태도를 얻는 데 유용한 증거입니다.

아이디어를 구현하는 방법

회의에서 첫 번째는 문제를 문제라고합니다. 문제를 해결하고 도전을 극복합니다. 도전은 좋은 일이지만 문제는 아닙니다.

천천히 시작하여 한 번에 한 번의 도전으로이 기술을 사용하십시오. 다음에 상사가 아이디어 중 하나를 채택하도록하려면 다음을 수행하십시오.

• 세 가지 유사하지만 다른 접근법 개발
• 상사에게 뭔가 도움이 필요하다고 말하십시오
• 세 가지 방법 중 어느 것이 문제를 해결하기위한 최선의 조치인지 확실하지 않다고 설명하십시오.
• 그 중 하나를 선택하도록 도와달라고 부탁하십시오.

1. 이것은 매우 강력합니다. 당신이하고있는 일은 최후 통첩이 아닌 선택을 제공하는 것입니다. Ultimatums는 그들의 아이디어가 아니며 하나의 옵션 만 있기 때문에 더 자주 격추되지 않습니다.

2. 여기서 단어 사용이 매우 중요합니다. " 당신의 도움이 필요합니다 ".

3. 보스가 "A", "B"또는 "C"를 선택하게하십시오. 실제로 보스는 "A", "B"및 "C"에서 섹션을 꺼내서 "D"옵션을 만들도록합니다. 당신이하고있는 일은 상사가 선택하게하는 것입니다.

이 시점에서 당신은 그가 선택하는 옵션이 모두 당신의 아이디어이기 때문에 덜 신경 쓸 수 있습니다. 그는 당신이 결정이 그의 것이되게했기 때문에 실제로 문제를 해결하고 있다고 생각할 것입니다.

당신 Proof of Concept의 아이디어를 구현하십시오. 팀에게 현재 문제를 해결하고 현재 문제를 해결하는 것보다 원하는 것을 보여줄 경우.