최근에 고용 한 직원으로서 변화를 제안하는 방법은 무엇입니까? [닫은]

나는 최근 대기업 (수천명, 규모에 대한 아이디어를주기 위해)에 고용되었습니다. 그들은 내 험한 일 때문에 저를 고용했다고 말했고, 젊었음에도 불구하고 (25 세) C / C ++ 프로그래머로 일했기 때문에 저를 고용했다고 말했습니다.

이제 시스템 전체가 오래되었고 종종 구식 기술을 사용하고 있음을 알 수 있습니다. 명명 규칙 (파일, 함수, 변수 등)이 없으며 버전 관리를 사용하지 않으며 예외 또는 다형성을 사용하지 않으며 거의 ​​모든 사람이 열정을 잃은 것처럼 보입니다 (일부는 30 세입니다) ).

나는 몇 가지 변화를 제안하고 싶지만 "그가 적응하고 싶지 않기 때문에 모든 것을 바꾸고 싶은 새로운 사람"이되고 싶지 않습니다. 나는 "적합"을 시도했지만 실제로, 우리가 강제로 사용하는 도구가 열악하기 때문에 오후에 내가하는 일을하는 데 일주일이 걸린다. 저의 동료들은 사람들이 요즘 사용하는 새로운 "사물"과 기법을 전혀 보지 않습니다. 그들은 그냥 포기한 것 같습니다. 상황은 정말 실망 스럽습니다.

비슷한 상황에 처한 적이 있습니까? 그렇다면 어떤 조언을 해 주시겠습니까? 검은 양 이되지 않고 사물을 바꾸는 미묘한 방법이 있습니까? 아니면 열정과 에너지를 포기해야합니까?

감사합니다.

업데이트

귀중한 조언에 따라 변경 사항을 제안 할 수 있었으며 현재 Subversion : D를 만들고 배포해야하는 팀을 담당하고 있습니다. 감사합니다.

6 개월 후

나는 더 나은 지불과 더 흥미로운 도전으로 훨씬 더 재미있는 환경을 그만두고 발견했습니다. 나는 아무것도 돌아 가지 않을 것입니다.

나는 5 년 동안 근무했던 이전 회사와 비슷한 상황에있었습니다. 2004 년에 합류했을 때, 그들은 :

• 여전히 데이터베이스에 Microsoft Access를 사용함 (비즈니스에 중요한 데이터베이스도 포함)
• Visual Basic 6 또는 Access / Excel VBA를 사용하여 개발
• 사내 개발 리소스를 사용하는 대신 많은 타사를 사용 (비즈니스 관리자는 자체 개발 프로젝트를 주도했으며 시간의 90 %는 IT 지식없이 계약을 체결했습니다)
• 말하다하지 아니 버전 제어를.

작년에 떠났을 때 회사는 다음과 같습니다.

• .NET 및 C #을 독점적으로 사용
• 모든 액세스 개발을 추방했다
• 버전 관리를 위해 SVN 사용
• 2 개의 강력한 SQL Server 상자가 있으며 기존 Access 데이터베이스를 SQL로 마이그레이션
• 모든 개발은 사내 팀을 통해 이루어졌으며 자원이 제한적일 때만 입찰에 나갔습니다.

당시 나는 21 살이되지 않았고, 개발팀에서 다음 막내는 30 살이었다. 나는 그것을 스스로하지 않았다. IT 관리자는 동시에 회사에 입사하여 모든 개발을 IT를 통해 수행하고 싶었습니다.

SVN은 나의 첫 업적이었습니다. 나는 라인 매니저와 회의를 가졌고, 코드가 생겼거나 문제가 발생한 변경이 발생한 상황을 강조했으며, 책임이 없다는 사실을 강조했다. 듣기 시작했다.

그런 다음 팀에 프리젠 테이션을 작성하고 버전 제어 개념을 설명하고 SVN이 개발자를 도울 수있는 몇 가지 상황을 시연했습니다. 어린 아이들은 오리처럼 물을 먹었고, 나이든 사람들은 그렇게 많이 사용하지 않았지만 그것을 사용하는 사람들에 대해서는 불평하지 않았습니다.

또 다른 주요 성과는 사내에서 완벽한 시스템을 구축하는 것이 었습니다. 저는 회사에서 1 년에 1 억 2 천 파운드의 라이센스를 절약 한 프로젝트를 이끌었습니다. 새로운 시스템을 작성하는 데 약 2 개월의 여가 시간을 보냈고 IT 관리자에게이를 제시하고 비용 절감에 대해 설명했습니다. 그런 다음 비즈니스에이를 제시하고 "기성품"시스템에만 국한되지 않고 시스템에 원하는 것을 구현할 수있는 방법을 설명했습니다.

4 주 후 내 시스템은 10 개 지역에서 시범 운영되었으며 6 개월 후 시스템이 가동되었습니다. 1 년 후, 그들은 제 3 자 계약을 취소하고 네트워크에서 그 흔적을 모두 제거하고 사내 시스템에 대한 큰 향상 요구 사항을 찾아 왔습니다.

당신에게 나의 충고 :

• 당신이 회사에 관심이 있다면, 밀어 내십시오. 다른 사람들이 당신의 접근 방식을 싫어한다면, 그들에게 맡기십시오-그것은 타협에 관한 것입니다
• 이야기하는 사람에게 제안을 맞추십시오-관리자는 a) 돈을 저축하고, b) 잘못되었을 때 사람들을 정확하게 비난하지만 개발자는 a) 시간을 절약하고, b)는 방법을 듣는 것을 좋아합니다. 예를 들어 스스로
• 당신이 변화에 대해 열정을 가지고 있다면 (당신처럼 들린다) 사람들에게 당신의 열정을 보여주고 열정적이지 않을 때 낙담하지 마십시오.
• 변경하는 것에 대해 이야기하지 마십시오. 그들을 만드십시오. 경험이 많은 사람들보다 짧은 시간 안에 환상적인 작품을 만들기 시작하면 사람들은 "왜?"라고 묻기 시작합니다.

그들은 내 험한 일 때문에 저를 고용했다고 말했고, 젊었음에도 불구하고 (25 세) C / C ++ 프로그래머로 일했기 때문에 저를 고용했다고 말했습니다.

당신이 더 저렴하기 때문에 가능성이 높습니다.

비슷한 상황에 처한 적이 있습니까

예.

나에게 어떤 조언을 해주 겠니

떠나다. 남기다. 맡기다. 출발하다.

검은 양이되지 않고 사물을 바꾸는 미묘한 방법이 있습니까?

있을 수 있습니다. 변경 사항을 소개하고 모든 사람이 어떻게 개선하는지 설명하십시오. 여러 번 해본 후에도 길을 잃지 않은 사람들로부터 감사를받을 수 있습니다.

아니면 열정과 에너지를 포기해야합니까?

안 돼 젊고 기회를 최대한 활용해야합니다. "어딘가에"몇 년을 낭비하지 마십시오. 이 직책을보고 더 경력을 쌓는 데 귀중한 경험을 줄 수 있는지 이해하십시오. 기회가 있으면 탐색하십시오. 아무 것도없고 단지 "직업"이라면, 나가십시오. 연습에 따르면, 열정을 잃어버린 적이 있거나 다시 한 번도 얻지 못한 사람들은 다시 얻을 수 없습니다. 열정적 인 사람들로 구성된 팀을 찾아 참여하십시오.

예를 들어 리드 . 시간에 따라 조금씩 변경됩니다. 동료를 끌어내어 그들에게 무언가를 시연하십시오. 그들이 마음에 들지 않으면 다시는 다시 시도하지 마십시오.

시간이 걸려요. 사람들을 안락 지대에서 너무 빨리 끌어 내지 마십시오.

슬프지만 그것이 바로 여기에 있고 그렇지 않은 이유입니다.

예를 들어. 버전 제어를 로컬로 설정하고 도움이 될 수있는 방법을 보여줍니다. 그런 다음 백업 할 수있는 리소스 (간단한 읽기)를 제공하십시오.

도구에 관한 또 다른 것 . 때로는 더 나은 도구를 구입하기 위해 돈을 써야합니다. 나는 그것이 '한 일'이 아니라는 것을 알고 있지만 다른 거래와 대화 할 때 많은 '실제'엔지니어들이 자신의 툴셋을 구매하여 자신의 작업을 더 잘 수행 할 수 있음을 알게됩니다. 나는 항상 기술 위축으로부터 자신을 구할 수있는 곳에서 이것을 수행했습니다.

나는 노인 (51)이고 내가 가진 모든 직업에서 똑같은 문제를 겪었습니다. 어쩌면 방에서 항상 가장 똑똑한 사람이 될 수도 있습니다! :-) 진지하게, 당신이 그것을 올바르게하는 방법을 알고 그들이 그렇지 않을 때, 당신은 종종 "이 새롭고 개선 된 기술을 모두에게 보여줄 것입니다. 그리고 그들은 모두 감동하고 뛰어 들고 싶습니다 "사용하기 위해." 그러나 실제 생활에서 90 %는 사람들에게 더 나은 방법을 보여 주며, 사람들이 왜 그렇게했는지에 대한 변명 목록을 제시합니다. 그 이유가 유효하지 않다는 것을 입증하면 새롭고 심지어 더 큰 이유가 있습니다. 나는 많은 시간을 보냈다

당신이 정말로 천재라고해도, 당신이 그것을 증명할 때까지 다른 사람이 당신이 천재임을 알지 못한다는 것을 받아 들여야합니다. 한 회사에서 10 년을 보낸 후 새 직장을 시작한 친구 인 Kris가 생각납니다. 새 직무를 시작한 직후, 그는 기술적 인 문제를 논의하는 회의에 참석하여 제안 된 해결책을 제시하기 시작했습니다. 그러자 다른 누군가가 끼어 들어 말했다. "예, 고마워요. 밥, 어떻게 생각하세요?" 처음에 그는 화가났다. 그는 정답을 알았지 만 아무도 신경 쓰지 않았다! 대신에 그들은 그보다 훨씬 적은 지식을 가진 사람의 의견을 가지고 갔다. 그러나 그는 저의 오래된 직장에서 자신이 무엇을 말하는지 알고있는 사람으로 명성을 쌓았 기 때문에 사람들이 이야기를들을 때 깨달았습니다. 나는 아직 평판이 없으므로 아무도 내 생각에 신경 쓰지 않습니다.

나는 2 년 동안 나의 현재 직장에 있었고, 지난 몇 달 동안 나의 의견이 실제 무게를 가지기 시작했다. 넌 인내가 필요해.

반면에, 새로운 사람들은 조직에 대해 아직 충분히 알지 못하고 일이 왜 진행되고 있는지 알지 못하기 때문에 실제로 비현실적인 개선에 대한 백만 건의 제안을하는 경우가 많습니다. 때때로 사람들은 20 년 동안 같은 방식으로 무언가를 계속하고 있습니다. 왜냐하면 그것이 항상 행해졌 고 더 나은 방법을 찾지 않는 사람은 없었기 때문입니다. 그러나 때때로 사람들은 경험이 그것을 수행하는 좋은 방법으로 보여 주었고 그들이 다른 것을 시도 할 때마다 재앙이기 때문에 20 년 동안 같은 방식으로 무언가를 계속합니다. 따라서이 모든 사람들이 바보라고 결론을 내릴 때 너무 빠르지 마십시오. 당신의 눈부신 새로운 제안을하기 전에 그들이 왜 옛날 방식으로하고 있는지 알아보십시오. 나는 내 인생에서 많은 시간을 보냈습니다

회사를 개선하고 싶은 동맹을 찾으십시오.

지금 당장 쫓아 내고 부패 해 버리는 말이 있습니다. 그러나 버전 관리 및 기타 개선 사항을 성공적으로 달성하면 이력서가 멋지게 보입니다.

나중에 인터뷰 할 때 Joel 테스트를 사용하십시오 . 당신도 회사를 인터뷰하고 있다는 것을 기억하십시오.

내 첫 번째 조언은 너무 빨리 변경하려고하지 않습니다. 먼저 일을 할 수있는 신뢰할 수있는 훌륭한 개발자로 명성을 얻으십시오. 지금 초보자로서 당신이 제안하는 것은 의심 스럽다. 그들은 아직 당신을 알고 존중하지 않습니다. 그 첫 걸음으로 그 존경을 받으십시오. 그런 다음 변경 사항을 도입 할 때입니다.

당신을 신중하게 선택하십시오. 새로운 기술이 아닌 버전 관리로 시작하십시오. 그것이 가장 중요한 변화이기 때문입니다. 코드를 사용하여이를 수행 한 다음 변경된 내용을 찾기 위해 이전 버전이나 copmpare로 되돌릴 때 사람들이 일상적인 대화에서 얼마나 쉬운 지 알 수 있도록해야합니다.

최신 지식을 사용하여 빛을 발하는 사람이 되십시오. 그러면 사람들이 어떻게이 일을 수행하는지 묻습니다. PC가 처음 직장에 들어 왔을 때 저는 정부 감사 기관에서 일했습니다. 선배들은 모두 자신의 컴퓨터를 가지고있는 것에 대해 매우 비판적이었다 (비서관의 일 이었기 때문에). 후배들은 최초의 컴퓨터를 모두 사용하여 연로 자들이 Lotus 1-2-3 및 Harvard Graphics로 할 수없는 일을 시작했습니다.

조직 문화의 변화는 기술적 인 문제가 아니라 정치적인 문제입니다. 사무 정치 관리에 대해 읽어보십시오. 높은 수준의 정치적 지원이 필요합니다.

현재 직장에서 비슷한 상황이 발생했습니다. 저는 15 년 이상 근무한 엔지니어 인 팀에서 일하기 위해 대학원에 곧바로 고용되었습니다. 변경 작업은 쉽지 않았지만 (일부 작업을 계속 추진하고 있습니다) 가능합니다.

예를 들어, 우리 팀은 16 비트 DOS 테스트 유틸리티를 유지 관리, 업데이트 및 사용하고있었습니다. 이 앱은 16 비트 링커의 한계를 코드를 추가 한 경우 코드를 추가하기 위해 다른 것을 제거해야하는 시점까지 밀어 붙 였기 때문에 업데이트하기가 매우 어려웠습니다. 16 비트 코드에서 많은 시간과 에너지를 소비 한 이유를 물었을 때 "DOS에서 실행해야 부팅 가능한 플래시 드라이브에서 실행할 수 있기 때문에"응답이 많았습니다. 유틸리티를 32 비트 Linux로 포팅하도록 설득하려고했지만 경영진은이를 수행하는 데 시간을 투자하고 싶지 않았습니다 (이미 수행 할 작업이 너무 많았습니다). 그래서 나는 계속해서 다운 타임 (오후 15 분, 주말 또는 다른 코드를 컴파일하기 위해 기다리는 동안)에서 유틸리티를 이식했습니다. 몇 달 동안 유틸리티가 완전히 포팅되어 원래 16 비트 앱이 처리 할 수 ​​없었던 모든 종류의 기능과 Linux 플래시 드라이브로 부팅했습니다. 사람들은 내가 그것을 사용하기 시작했을 때 알아 차리고 작업을 더 빨리 수행 할 수있는 방법과 유틸리티가 더 나은 디버그 출력을 생성하는 방법에 대해 언급하고있었습니다. 곧 경영진이 들었습니다. 일단 그들이 혜택을 보았을 때 (그리고 가장 중요한 것은 이미 작업이 완료되었다는 것), 그들은 더 이상 아이디어에 반대하지 않았습니다.

이 이야기에서 배운 교훈은 다음과 같습니다. 무언가를 개선 할 수 있다고 생각되면 관리자에게 문의하십시오. 그들이 자원을 소비하고 싶지 않다면, 스스로 그것을하고 당신의 아이디어가 유효하고 유용 하다는 것을 증명 하십시오. 명백한 가치가있는 당신 앞에서 보는 것보다 누군가가 제안하는 아이디어에 대해 거부하는 것이 훨씬 쉽습니다.

팀 / 관리자가 아이디어를 구현하고 아이디어의 이점을보기 시작하면 향후 아이디어를들을 가능성이 훨씬 높아집니다. 테스트 툴에서 다시 작성한 "스트리트 크리드"를 사용하여 팀에 현재의 구식 버전 관리 시스템을 버리고 (난처한 상황을 피하기 위해 익명으로 유지해야 함) Subversion으로 마이그레이션해야한다고 설득했습니다. 경영진이 승인 할 수 있도록 설정 / 마이그레이션 노력을 주도했습니다.

"한 번에 한 걸음"의 종류입니다. 아마도 당신이 바꾸고 싶은 많은 것들이 있지만, 시작할 작은 것을 선택하십시오. 팀과 관리자가 '아니요'라고 말할 수없는 방식으로 아이디어의 품질을 보여줍니다. 스택 오버플로 계정과 마찬가지로 아이디어가 많을수록 평판이 좋아지고 아이디어를 더 쉽게 받아 들일 수 있습니다.

로컬에서 원하는 도구를 사용하기 시작하십시오 (가능한 경우-일부 회사는 상자에 설치할 수있는 것을 주먹으로 꽉 조이는 것처럼 보입니다). 선호하는 버전 관리 시스템을 설정하고 사용을 시작하십시오. 어떤 코드를 만질 때, 특히 새 코드를 작성할 때 코드를 깔끔하게 만드는 작은 변경을하십시오. 그들이 당신의 엄격한 경험을 위해 당신을 고용했다면, 그들은 이미 당신을 존중한다는 의미입니다.

최근에 Hiren Ren과 Stimpy를 읽고 Stimpy 예제가 큰 과제라는 것을 알았습니다. 그의 리드를 따르면, 동료들로부터 온갖 종류의 관점을 요구하게되며, 열정없는 개발자가하지 않을 것이라는 지식을 갖게됩니다. 당신은 당신이 개선하는 방법을 꿈꾸는 여가 시간을 보낼 것입니다. 회사에서 귀하의 작업이 가치있는 것으로 판단되면 귀중한 가치를 얻게됩니다. 그렇지 않은 경우 구직을 원할 것입니다.

많은 사람들이 한 번에 하나의 작은 것에 중점을 두겠다는 제안으로 대답했으며, 일부는 버전 관리를 제안했습니다. 한 단계 더 나아가 데스크탑 컴퓨터에 리포지토리를 만들고 해당 리포지토리에서 작업합니다. 회사가 사용하는 마스터 저장소에서 정기적으로 업데이트하십시오. 누군가가 마스터를 손상시켜 위기가 발생하면 개인 저장소에서 새 사본을자를 수 있다고 알려주십시오.

그러나 어떠한 상황에서도 회사 코드를 개인적으로 소유하거나 집으로 가져 오는 기계에 두지 마십시오 . 그러므로 당신은 영웅이 아니라 변호사 (최상의) 또는 법 집행 (최악)의 잘못된 편에 서게됩니다.

다른 후배 개발자로부터 왔습니다 ... 훌륭한 인적 기술이 있습니까? 아이디어를 제안하는 것이 적절하고 부적절한시기와 그 아이디어를 가장 잘 판매하는 방법에 대한 이해가 뛰어나고 자제력이 뛰어 납니까? 당신이 할지라도, 당신은 여전히 ​​다른 사람들에게 당신의 가치를 증명하지 않고 그들의 일을하는 방법을 알려주는 "그 사람"이 될 수 있습니다.

이것이 여전히 주니어 개발자로서 신뢰를 쌓는 방법입니다. 꼬임 / kludge / 시간 낭비를 식별합니다. 그런 다음 다른 사람을 귀찮게하지 않고 자동화 (배치 파일, powershell 스크립트, 간단한 프로그램, 새로운 프리웨어 등)하여 문제를 해결합니다. 나는 지속적인 기술 자체 교육의 일환으로“새로운 것을 가르치고 회사를 돕기 위해 더 많은 시간을 투자하는 것”으로 생각할 수 있도록합니다.

내 수정 사항이 특히 멋지면 공유하고 "이봐 요, 멋진 도구를 만들었습니다. XY와 Z를 자동화하고 다른 작업을 빠르게 수행합니다."라고 말합니다. 그것에 당신의 이름을 유지하십시오. 반복. 자신의 수준에 맞는 성과를내는 사람이라면 몇 달 안에 신뢰성 문제가 해결되었으며, 아이디어가 왜 좋은지, 어떻게 문제를 해결할 수 있는지 설명 할 준비가되면 위의 사람들이 제안에 더 개방적 일 것입니다.

최근 나는 받아 들여지는 상급 경영진에게 새로운 아이디어를 제안 할 수 있었는데, 그 이유는 대부분 내 추론을 설명하고 피드백을 듣고 과거의 일에 대한 신뢰성을 가지고 있었기 때문이다.

부록 : 관리자가 귀하의 행동에 의문을 제기하는 경우 ... 귀하의 성과가 "최고 25 %"이상이라고 느끼지 않는 한이 작업을 수행하지 마십시오. IE는 모든 종류의 작업을 시작하기 전에 상사가 당신에게 만족하는지 확인합니다. 당신을 그 최고 %로 끌어 올리는 영리한 수정 프로그램 중 하나입니다. 그렇지 않으면 그는 당신이 시간을 낭비한다고 생각할 것입니다. 긍정적 인 성능 피드백을 이끌어 내면서도 여전히 새로운 유틸리티와 솔루션을 포기하고 있지만 여전히 미세 관리를 요구하고 있다면이 주제의 범위를 벗어난 문제가있을 수 있습니다.

을 섞다.

당신이 말했듯이, 당신은 검은 양이되고 싶지 않습니다. 그러나 (나처럼) 유용한 변경 사항을 추가하고 싶기 때문에 :

백그라운드에서 가치를 추가하십시오.

사람들의 코드를 svn / hg / git에 체크인하기 위해 cronjob을 설정하십시오. 개발 시간을 대폭 향상시킬 수있는 시간에 자신 만의 도구를 만드십시오. 특히, 자신의 칸막이에 선배를 보여줄 수 있도록 회사를 개선하려고합니다 . 그리고 그 이유는 다음과 같습니다.

와우 팩터

"이봐 앨리스, 밥이 어떻게 빌드를 깨뜨 렸는지 알아? 편집을 되돌릴 수 있고 빌드가 다시 작동한다"고 말할 수 있습니다. 그리고 당신의 선배가 성스러운 말을 할 때, 당신은 그들이 당신의 새로운 관행을 추진하거나 최소한 격려 할 수 있도록 그들에 대한 충분한 열정을 깨울 것입니다.

여기 내 조언이 있습니다.

나는 비슷한 상황에 처해 있었고, 우리 회사는 약 6 명의 개발자이며, 새로운 기술, 새로운 도구 및 작업을보다 쉽고 고품질의 소프트웨어로 만드는 것을 좋아하는 프로그래머입니다. .

처음 시작했을 때 VS2008이 꽤 오랫동안 나왔을 때 Visual Studio 2005를 사용하고 있었지만, 모든 개발자가 쉽지 않은 업그레이드를 상사에게 맡기려면 천천히 아이디어를 가져와야했습니다. "우리가 이것을 할 수 있다면 좋을 것입니다.",하지만 그것을 상사에게 가져 오기 전에 다른 개발자들이 아이디어를 잘 활용하도록해야합니다. 호의는 한 사람의 결정처럼 보이지 않습니다.

회사를 더 나은 방식으로 변화시킬 아이디어를 제안하고, 직업에 대한 관심과 계획을 보여주기 때문에 아이디어를 상사에게 던지는 대신 천천히 변화를 가져올 수 있다고 생각합니다. 거기에 집을 만드는 것.

이것은 또한 당신이있는 직장 환경과 상사의 성격에 달려 있으며, 그들이 누워서 당신을 가족처럼 대우하고 조언을 구하고 제안하면 제안하지만, 그들이 당신을 숫자처럼 대우한다면 어떻게 조심해야합니까? 당신은 그것에 접근합니다.

평생의 기회가 될 수 있습니다-회사가 25 세에서 일하는 방식을 바꾸십시오. 그래도 저항하고 항상 적대감을 나타내면 그것은 당신을위한 곳이 아닙니다.

인터뷰는 양방향 프로세스였습니다. 고풍스럽고 변화에 대한 저항력을 느낄 수있었습니다.

Ps, 나도 25 살이고 기분이 어떤지 알아 당신은 아마도 동료보다 배우고 새로운 것을 시도하기를 훨씬 더 열망 할 것입니다. 어쨌든, 내가 소개하고있는이 .NET4 작업으로 돌아 가야합니다.)

Joel Spolsky 가 그런 일을했을 때해야 할 일을 읽으 십시오 .

... 때로는 경영진으로 조직을 변화시킬 힘이 없습니다. 토템 폴의 맨 아래에있는 단순한 프로그래머라면 일정이나 버그 데이터베이스를 작성하도록 사람들에게 정확하게 명령 할 수는 없습니다. 실제로 관리자 인 경우에도 개발자 관리는 고양이를 유인하는 것과 비슷하지만 재미는 없을 것입니다. "만약 그렇게 만든다"는 말만으로는 그렇게되지 않습니다.

Joel Test 에서 낮은 점수를받은 조직에서 일할 때 실망 할 수 있습니다 . 코드가 아무리 우수하더라도 동료는 프로젝트와 관련하여 부끄러운 코드를 작성합니다. 또는 경영진이 작성할 코드에 대해 잘못된 결정을 내릴 수 있으므로 AS / 400 버전의 퇴직 계획 게임 어린이를 디버깅하는 데 재능을 낭비해야합니다.

... 나쁜 팀에서의 삶을 다루는 것은 화를 낼 수 있습니다. 그러나 아래에서 팀을 개선하기위한 전략이 있습니다. 몇 가지를 공유하고 싶습니다.

경영진과 협력하십시오. "도적"하지 마십시오. 프로세스 내에서 작업하고 "svn을 구현하면 서버에 공간이 필요하고 설정하는 데 이틀이 걸리므로 백업해야합니다. 그러나 x, y, z를 얻게됩니다. 돈을 많이 절약 할 수 있습니다. "

떠나다. 거기에는 많은 직업이 있습니다. 당신을 고용 한 임의의 회사를 고치는 것은 당신의 일이 아닙니다. 그들은 자신의 방식을 좋아하고, 그렇지 않으면 새로운 CTO 또는 다른 것을 고용 할 것입니다.