문제

내가 일했던 곳에서 그들은 어떤 문제에 대한 전형적인 반응은 시스템을 완벽하게 사용하지 않은 것에 대해 하드웨어 나 사용자를 비난하는 것이 었습니다. 나는 그 일을하기 전에 다른 것을 증명할 수있을 때까지 그것이 내 잘못이라는 철학을 채택했다 (지금까지 100 명 중 99 배 이상은 맞다).

내가 있었을 때 마지막 "해결할 수없는"문제 중 하나는 데이터베이스 타임 아웃이 풍부했습니다. 몇 달의 연구 후에도 나는 여전히 이론 만 있었지만 그 중 어느 것도 증명할 수 없었습니다. 내 개발자 중 한 명이 네트워크 (모든 라우터, 스위치, 액세스 포인트)를 교체하는 것을 단호하게 제안했지만 네트워크가 원인이라는 증거를 제공 할 수 없었습니다. 그러나 내 관리자 (개발/IT 경험 없음)에 따르면 "분명히 원인"이었으므로 문제를 인수했습니다. 하나의 경고와 안개 크릭 플러그 : 그는 FOGBUGZ를 통한 오류가 나머지 데이터와 동일한 SQL 서버에 대해 완벽하게 작동했다는 사실을 설명 할 수 없었습니다.

시간이없는 부부는 몇 달 후, 내 관리자는 그가 타임 아웃을 수정했다고 자랑했습니다 ( "봐, 타임 아웃 없음!"). 나는 바위를 잡고 "호랑이가 없어!"라고 말하는 것을 막아야했다. 그러나 나는 그가 아무런 응답도 얻지 못했을 것이라는 것을 어떻게 알았는지 물었다. 타임 아웃은 몇 달 후에 돌아 왔습니다 (그리고 더 많은 숫자).

나는 내가 상황을 어떻게 처리했는지에 대해 꽤 만족하지만, 군중이 어떻게 우월/동료가 당신이 아는 솔루션을 구현하도록 (또는 매우 확실하다고 확신하고) 수천 달러를 낭비 할 수있는 솔루션을 구현하는 데 어떻게 응답했는지 궁금합니다.

도움이 되었습니까?

해결책

그들을 보자. 그러나 동시에 실제 원인을 계속 검색하십시오.

수천 달러는 돈이 잘 지냅니다. 그런 종류의 생각에 반대하지 않으면 (무의미한)

다른 팁

글쎄, 문제가 상위 경영진이라면, 나는 당신이 한대로 할 것입니다 - 불만을 제기 한 다음 지침을 따르십시오. 그것이 옳은 것으로 밝혀 졌다면 (때때로 일어난 후), 당신은 당신의 오해에도 불구하고 좋은 직원처럼 보입니다. 그것이 당신이 옳았다면, 그들은 당신이 그들에게 그들의 차례를 허용했다는 것을 감안할 때 당신의 말을 더 기꺼이들을 수 있습니다.

물론 이것은 낙관적입니다.

동료의 경우 문제를 수준으로 올리고 상사에게 상담하여 주제에 접근하는 방법에 대한 조언을 구하십시오. 당신의 관점과 동료의 관점 모두에 공정하게 받아들이고, 당신이 주신 조언을 따르십시오.

때로는 관리자를 떠나는 것이 가장 좋습니다. 그의 압력과 책임에 대해 생각한다면 그는 "아무것도"보다는 무언가를하는 것을보아야했습니다. 충분한 시간이 지나면 "조사"는 시간 초과가 필요한 외부 당사자에게 아무것도 해결하지 못합니다.

행동을 취함으로써 그는 연구를 계속할 수있는 기회를 만듭니다. 속임수는 솔루션을 그의 맥락에 넣는 방법을 찾는 것입니다. 여기에 우리가 지금 할 수있는 일이 있습니다. 여기에 우리가 계속 할 수있는 일이 있습니다. 예를 들어, "우리는 네트워킹 장비를 예방 단계로 교체 한 다음 버전 제어 로그를보고 해당 가능성을 배제 할 수 있습니다."

이것은 그에게 사전 예방 적 무언가를 제공하여 자신의 체인을 생산적으로 보이며 원하는 솔루션을 달성하여 궁극적으로 성공할 수 있습니다.

장기적으로 당신은 당신의 기술적 결정을 암시 적으로 신뢰하는 사람을 위해 일해야합니다. 당신은 솔직하게 이야기 할 수 있으며, 당신이 무슨 일이 일어나고 있는지 아는 방식으로 정치를 탐색하는 데 도움을 줄 수 있습니다. 관리자가 그 사람이 아니라면 이동하십시오.

이것이 큰 문제입니까? 회사가 솔벤트를 유지하기를 원하는 것 외에는 회사 달러를 절약하는 것이 귀하의 일이 아닙니다.

하나의 관리자가 단지 한 관리자라면, 그는 조만간 잡초가 될 것입니다. 회사 전체 문화가 이와 같다면 아마도 계속 나아갈 시간이 될 것입니다.

그 동안이 내용을 볼 수 있는지 확인하십시오. 관리자의 관점.

나는 당신이 관리자의 의도가 좋은 것이라고 생각합니다. 내가 더 어렵다는 것을 귀찮게하고 싶지 않은 사람들입니다. 도움이되기 위해 그 에너지를 사용하는 방법을 찾는 것이 가장 좋습니다.

많은 사람들 (때로는 나 자신)에게 일반적인 문제는 문제를 진단하려고 할 때 주위를 돌아 다니는 것입니다. 당신이 그것을 크게 추측하고 있다면, 현대 컴퓨터의 특수성은 가장 옳은 가능성 만 있습니다. 이러한 유형의 태도로 이러한 유형의 문제에 접근하면 일반적으로 절대 고칠 수 없다는 것을 의미합니다.

복잡한 디버깅을 건소하는 가장 좋은 방법은 분열과 정복입니다. 이 경우 먼저 테스트를 생각하고 구현합니다. 그 시험이 예상대로 작용 했습니까? 테스트와 함께 어디에 있는지에 따라 문제에서 가까워 지거나 멀어지고 있습니다. 열쇠는 모든 테스트가 콘크리트 (객관적인) 동작을 초래해야한다는 것입니다. 결과가 모호하면 테스트가 쓸모가 없습니다.

시스템의 일부에서 연결이 끊어 지지만 다른 부분이 아닌 경우에는 많은 양의 귀중한 정보가 있습니다 (네트워크가 아님). 부품의 차이점은 무엇입니까? 어딘가에 도착할 때까지 내림차순을 시작하십시오 ...

관리자에게 돌아갑니다. 그런 유형의 성격 문제를 겪을 때마다 에너지를 더 유용한 것으로 리디렉션하려고합니다. 욕망은 거기에 있습니다. 그것은 단지 형성에 도움이 필요합니다. 관리자가 테스트가 구체적인지 확인하도록 설득 할 수 있다면, 충분한 작업을 수행하면 버그를 올바르게 추측하기에 충분한 정보를 생성합니다. 물론, 더 일관된 접근 방식이 더 빠를 수 있지만, 왜 무료 지원을 거절 하는가. 나는 일반적으로 모든 프로젝트에서 모든 사람에게 유용한 역할이 있다고 생각합니다. 그것은 그들의 노력을 활용할 수있게하는 것입니다 ....

폴.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top