“예제로 인도”가 효과가 없을 때 무엇을 할 수 있습니까? [닫은]

저는 거의 2 년 동안 대기업 (8000 명 이상의 직원)을 위해 일해 왔으며 공부 과정을 마친 직후에 고용되었습니다.

여기의 모든 사람들은 종종 매우 나쁘게 설계되고 해킹으로 가득 찬 레거시 코드를 매일 처리해야합니다. 처음에, 나는 일을 너무 비판하지 않으려 고 애썼다. 그러나 상황은 상황에 따라 생활하기가 매우 어려워졌으며 우리가 사용하는 도구를 기꺼이 개선 / 교체하려는 사람은 아무도 없습니다.

보다 명확하게하기 위해

• 더 이상 사용되지 않는 소스 제어 도구 (Visual SourceSafe)
• 완전 재 구축 만 지원하는 일반 오래된 makefile
• .def 모든 기존 아키텍처에 대해 수동 및 별도로 유지 관리해야하는 파일
• 모 놀리 식 헤더 파일 및 파일이 거의없는 프로젝트 (단, 각각 약 3000 줄의 코드가 있으며 때로는 다른 작업을 처리 함)
• "새로운"언어 시설을 std::string사용하지 않는 것 (잘 새로운 것은 아니지만 나 외에는 사용하지 않는 사람)

몇 달 전에 새로운 컴파일 환경을 디자인하여 그것에 대해 뭔가를하기로 결정했습니다. 점진적 빌드를 통해 안정적으로 작동하고 컴파일 시간을 단축하고 구조화 된 프로젝트를 개선하며 자동 .def파일 생성을 수행 할 수 있습니다. 심지어 Git에서 Visual SourceSafe로 /로부터 브리지를 만들었습니다.

나는 여러 동료들과 우리 상사에게 나의 업적을 보여 주었지만 아무도 걱정하지 않았습니다. 그들은 모두 "음 ... 사람들은 지금 그렇게하는 데 익숙합니다. 왜 우리가 일을 바꾸겠습니까?"

내가 제안한 변경 사항은 기존 시스템에서 새로운 시스템으로 부드럽게 전환 할 수 있도록 설계되었습니다. 각 개선 사항은 별도로 안전하게 적용 할 수 있습니다.

심지어 동료들 중 일부를 변경에 참여 시키려고했습니다. 그러나 지금까지는 성공하지 못했습니다.

이미 비슷한 상황에 직면 했습니까? "예제로 인도"가 작동하지 않을 때 무엇을 할 수 있습니까?

머리를 향한 목표 : "예시의 리드"는 개선되어야하지만 기술이 아닌 사람들을 대상으로해야합니다. 어쩌면 기술 향상에 너무 많은 시간을 투자했지만 머릿속에서 일어나고있는 일에는 시간이 충분하지 않을 수 있습니다. 새로운 것에 반대하는 이유가 무엇인지 생각해보십시오. 많은 경우에 그들은 단지 약간의 위험을 두려워합니다. 이러한 위험을 식별하고 이에 대한 반론을 찾으십시오.

신선한 고기 잡기 : 물건을 바꾸고 싶은 직원을이기는 것이 더 쉽습니다. 당신이 그들을 볼 때 즉시 눈에.니다.

썩은 고기를 피하십시오 : 어떤 사람들은 당신의 생각에 동정하지 않을 것입니다. 따로 두십시오.

중요한 집단으로 성장 : 당신의 아이디어에 동조하는 사람들을 찾으십시오. 하나씩 승리하십시오. 어떤 시점에서 임계 질량에 도달하면 점점 더 많은 사람들이 귀하의 모범을 자발적으로 따를 것입니다.

관리 어휘 : 관리자는 더 나은 디자인에 관심이 없습니다. 그들의 언어는 돈과 시간입니다. 버그가 얼마나 많은 시간을 낭비하는지 분명히하십시오. 버그가 발생한 고객 불만족은 수익성이 없다는 것을 분명히하십시오. 새로운 기능을 얼마나 빨리 구현할 수 있는지 보여줍니다. 관리자를위한 다른 어휘를 선택해야합니다.

프로세스에 관한 모든 것 : 더 나은 기술은 더 나은 프로그래머와 프로그램을 만들지 않습니다. 실행중인 프로세스가 양호하면 오래된 기술조차도 좋은 결과를 가져옵니다. 노력과 시간이 낭비되었다고 생각하십시오. 아마도 기술이 아니지만 프로세스의 무언가가 잘못되었습니다. 대부분의 경우 의사 소통이 부족합니다.

새로운 회사 찾기 : 이미 많은 일을했습니다. 여전히 개선을 시도 할 수는 있지만 얼마나 오래 시도하고 얼마나 많은 에너지를 투자하고 싶은지 결정하는 것은 당신에게 달려 있습니다. 명심하십시오 : 많은 개선을 이룰 수 없더라도 노력을 통해 많은 것을 배울 수 있습니다. 어느 시점에서 당신은 이동해야합니다.

당신이 틀렸다고 생각한 적이 있습니까?

그래서 당신은 학교에서 디자인과 패턴 책을 읽었고 당신이 일하는 곳에서 비교되는 구식 관행처럼 보이지 않습니다. 의심 할 여지없이 그들은 더 나은 아이디어 일 것이고 새로운 프로젝트는 이러한 것을 염두에두고 시작해야하지만 완전히 다른 수준에있는 것 같습니다.

방목 개발자는 고양이를 모 으려고 노력하는 것과 같으며, 본질적으로 자신의 마음을 가지고 있으며 옳든 싫든 선호하는 일을합니다. 모범 사례를 시행하고 2 명의 개발자로 구성된 팀을 관리하는 데 어려움을 겪지 만 8000 명의 회사에서 근무합니다.

그것은 엄청나게 큰 숫자입니다. 모든 개발자가 공개 일정으로 회의 일정을 정하고 부재 중 시간을 예약해야한다는 간단한 프로세스 변경조차도 전반적으로 구현하기가 엄청나게 복잡하고 어려운 정책이되었습니다. 또한 정책이 전반적으로 수용되고 채택되도록하기 위해서는 경영진의 상당한 추진이 필요합니다.

당신은 그것을 생각하지 않을 수도 있지만, 모 놀리 식에서 여러 헤더 파일로 이동하거나 SourceSafe에서 Git으로 버전 제어를 이동하는 것과 같은 간단한 것은 관련된 모든 사람들에게 엄청난 노력과 투자가 필요합니다. 다음이 필요합니다.

• 상당한 관리 지원

• 회사 전체의 수용

• 모든 개발자가 새로운 이니셔티브를 알리기위한 회의 시간 투자

• 가장 어리석은 개발자조차 자신이하는 일을 알 수 있도록 교육을 계획하고 수립해야합니다.

• 1 시간의 교육을 가정하더라도 8000 명의 개발자 x € 50 / hr = € 400000의 교육 비용. 내 소프트웨어 개발 팀이 1 년 내내 급여, 소프트웨어 및 하드웨어 예산을 책정하는 것보다 더 많은 돈입니다. 그것은 당신이 제안하는 탁월한 투자입니다.

그러나 "생산성을 통해 절약 할 수있는 모든 시간을 생각하십시오." 그렇습니다. 그러나 상당한 투자는 중대한 위험이므로, 사인 오프하기 전에 귀하가 이에 대해 올바른지 확인하는 것이 좋습니다. 선배들 중 누구도 당신을 뒷받침하지 않으면 비용을 정당화 할 수 없습니다. 궁극적으로 우리는 비효율적 일 수 있지만 일관성이 있으며 회사 전체의 8000 명의 개발자와 일관성이 가장 중요합니다.

이를 위해서는 여러 고위급 직원의 서명이 필요하며 개발자의 손실 된 시간을 비효율적으로 측정하는 방법을 정확하고 객관적으로 찾아야합니다. 그 시간은 달러와 같으며 달러와 정치 만이이 전투에서 승리하는 데 도움이 될 것입니다.

당신이 묘사 한 것은 나에게 "예제로 인도하는 것"처럼 들리지 않습니다. 당신이 제안을하고 거부 한 것처럼 들립니다. 모범으로 인도하려면 사람들에게 자신의 길이 더 낫다는 것을 보여 주어야 합니다. 당신이 열거 한 문제들 중에서 나는 당신이 당신 자신의 변화를 스스로 사용할 수있는 세 가지를 봅니다.

전체 재 구축 만 지원하는 일반 오래된 makefile

자체 메이크 파일을 로컬로 작성하고 얼마나 효율적으로 작업 할 수 있는지 표시하십시오.

모 놀리 식 헤더 파일 및 파일이 거의없는 프로젝트 (단, 각각 약 3000 줄의 코드가 있으며 때로는 다른 작업을 처리 함)

기존 코드를 만질 때 (빌드를 깨지 않고) 기존 코드를 분할하거나 새 코드를 작성할 때 더 작은 헤더 파일을 도입하십시오. 사람들이 그들과 함께 일하기 시작할 때, 그들은 복제가 필요하지 않다는 것을 알게 될 것입니다.

"새로운"언어 기능을 사용하지 않음 (잘 std :: string은 새로운 것이 아니지만 나 외에는 아무도 사용하지 않습니다)

기존 코드를 만지거나 새로운 코드를 도입 할 때마다 새로운 언어 기능을 계속 도입하십시오. 당신이 일을 단순화하고 있는지 확인하십시오. 이것에서 낙심하지 마십시오. 우리 대부분은 게으르다. 새로운 언어 기능으로 작업이 더 쉬워지면이를 채택 할 것입니다.

몇 달 후 다른 개발자가 개선 사항을 채택하기 시작하면 소스 제어 시스템 업그레이드와 같은 더 급진적 인 변화에 대해 상사에게 다시 접근 할 수 있습니다. 다른 개발자가 이점을 볼 수 있도록해야합니다. 접근하는 한 가지 방법은 소수의 개발자만이 활동하는 작은 프로젝트에서 Git을 사용해 보는 것을 제안하는 것일 수 있습니다. 그렇게하면 익숙하지 않은 시스템으로 대규모로 전환하는 것이 아니라 평가로 홍보 할 수 있습니다.

마지막으로, 몇 달 동안 노력한 후에도 회사에서 업무 수행 방식을 개선하는 데 관심이없는 사람은 자신에게 적합한 지 실제로 고려해야합니다.

라이오넬 바렛 (주로 동의)과 더불어 저항에 대한 가능한 동기 부여도 고려하십시오.

• 실제 프로세스 비용 평가
• 귀하의 프로세스 비용을 평가하십시오

또한 :

• 기간의 변경 비용 평가
  • 누구에게나 새로운 환경을 조성하기 위해 소비하는 비용
  • 새로운 모드에 익숙해 지도록 모든 사람을 교육하는 데 소요되는 시간
  • 중단없이 변경 사항을 관리하는 데 소요되는 시간.

용의자가 있습니다. 나이와 문화 (내가 "학교"와 "학교 유형")의 관점 에서 귀하 와 같은 사람들이 몇 명 입니까? 향후 2/3 년 동안 당신과 같은 사람들이 몇 명이나 고용 될 것이며 얼마나 많은 사람들이 조직에서 퇴직하거나 역할을 바꿀 것입니까?

내 용의자는 당신이 회사를 바꿀 힘이 충분하지 않은 위치에 있다는 것입니다. 그러한 상황에서 더 많은 시간을 기다릴 수 없다면 회사는 당신을 변화 시키거나 당신을 "추방"할 것입니다 .

그러나 회사가 내가 말한 추가 비용을 절약하여 사람들의 자연적인 교체가 일어나기를 기다리면서 자연스럽게 변경 프로세스가 수행되도록 할 수 있다고 평가하고있을 수 있습니다. 당신은 뒤에 아직 아무것도 (아직) 없기 때문에 볼 수없는 프로세스의 시작에 있습니다.

이 시점에서 나는 당신이 그런트 일 때 Joel 기사에 대한 참조 만 추가 할 수있다 . 섹션에는 다음이 포함됩니다.

전략 1 그냥 해

전략 2 바이러스 성 마케팅의 힘 활용

전략 3 우수성 창출

전략 4 Bozos를 중화

전략 5 중단을 피하십시오

전략 6 귀중한

이 기사를 "변화는 당신과 함께 시작해야합니다"라고 요약했습니다.

슬프게도 사람들은 틀에 박힌 생활을하고 '모든 사람들이 그것을 잘 사용하고 왜 바꾸는가'라는 정신을 키우고 분노하게됩니다.

불만을 제기 할뿐만 아니라 대체 솔루션으로 실행 가능한 솔루션을 개발하여 올바른 방법으로 전환했습니다. 이제 구매 만하면됩니다.

직통 관리자 (또는 기술 책임자)를 보여주십시오. 그들이 관심이 없다면 변화 관리 나 혁신을 담당하는 사람이 있습니까?

잠재적으로, 귀하의 아이디어와 작업은 무시 될 수 있으며 상황은 그대로 유지됩니다.

당신의 상사가 당신 편에 닿게하는 방식으로 사건을 진술해야합니다. BTW, 이런 종류의 변경은 기술 책임자 또는 프로젝트 관리자가 제안하므로 프로젝트에 전념해야합니다. (대체 경로로서 기술 감사를 제안 할 수 있습니다. 외부인은 귀하와 같은 말을 할 가능성이 있지만 더 많은 무게를 갖게됩니다.)

지금까지 그는 변화의 필요성을 보지 못했지만 화장품이 그에게 변하는 것처럼 보입니다. 그에게 중요한 것은 돈의 흐름과 안정적인 팀입니다. 기술은 블랙 박스입니다. 작동한다면 충분합니다.

첫 번째 돈, 현재 설정으로 인해 비용이 많이 든다는 것을 증명해야합니다. 개발자의 비용 / 시간과 컴파일 시간이 얼마나 많은 시간을 절약 할 수 있습니까? 수학하세요. 또한 현재 코드 파이프 라인의 위험에 대한 기사 또는 증언을 작성하고 그에게 무서운 숫자를 보여줍니다.

두 번째로, 당신의 상사는 길을 바꾸고 싶지 않은 오래된 심술쟁이 코더들로 갇혀있을 수 있습니다. 첫 번째 요점이 확립되면이 문제에 대한 해결책도 제안해야합니다. 당신은 몇 명입니까? 현재의 코딩 파이프 라인이 비잔틴이기 때문에 누군가를 대체하기가 어렵다는 것을 강조하는 것은 흥미로울 수 있습니다. 팀을 업데이트 할 계획을 제안해야합니다. 업계 모범 사례를 배우고 새로운 규칙을 따르고 있는지 확인하십시오.

마지막으로, 마일스톤 및 리소스 할당과 함께 작은 프로젝트로 나누어 진 코드베이스를 변경하는 계획을 제안해야합니다. 실제로, 당신은 프로젝트 관리자로서 자신을 팔고 있으며 견고한 코드 파이프 라인을 갖기 위해 필수적으로 변경 사항을 팔고 있습니다.

일을 잘 수행하고 효율성과 혁신을 통해 성공과 수익성을 창출 할 수 있다고 믿는 조직에서 일하십니까? 또는 매출 추구와 판매 유지에 집중하는 것이 성공의 세입자입니까?

당신이 묘사하는 것처럼 행동하는 회사는 기술적으로 확고합니다. 경쟁이 치열한 시장에서는 개인과 혁신에 중점을 둔 회사와 경쟁 할 수 없습니다.

당신이 당신이 말하는 사람이라면, 당신의 정신을 존중하고 보상하는 곳에서 일하십시오. 결국 몇 년 동안 정착 한 후에는 상사가 받아들이는 것과 동일한 철학을 타협하기 시작할 것입니다. 노력, 영감, 창의성 및 진보를 중요시하는 다른 곳 (아마도 더 작은 조직)에서 일하십시오.

당신이 위험을 감수하지 않고 곧 그렇게한다면 당신은 결국 정착하게 될 것이며, 현재 동료 집단에서 철학적으로 반대하기 때문에 호기심과 창의성을 계속해서 공급할 수 없을 것입니다.

탁월함은 태도와 세계관입니다.

이 경험을 통해 피해야 할 사항에 대한 통찰력을 얻었고, 안주와 보호주의에 대해 예리한 눈을 유지하여 조기에 탐지 할 수 있음을 알고 계십시오.

다음 인터뷰에서 "직원이 어떤 종류의 혁신을 가져 왔는가", "개인의 창의성으로 인해 어떤 변화가 있습니까?", "이 팀에 어떤 개인적인 재능을 가져갈 수 있습니까?", "귀하의 조직의 성공을 이끄는 것은 무엇입니까? ? ","귀하의 조직은 어떻게 기술 혁신을 지속적으로 수용하고 있습니까? "... 이와 같은 질문에 대한 대답은 매우 분명합니다. 많은 조직에는 비전이 없거나 비전을 만든 조직이 사라졌으며 조직은 회계사에 의해 운영됩니다. 기술 이사와 인터뷰하는 경우 조직을 기술 회사로보고 있는지 물어보십시오.

작업 환경이 마음에 들지 않으면 자신에게 장애를 겪고 있습니다. 전문적으로하는 것과 비슷한 관심사와 목표를 가진 사람들로 둘러싸여 야합니다. 나는 그것이 때때로 그렇게 쉬운 말을하는 것을 알고 있지만, 몇 년을 되돌아보고 마치 시간을 낭비한 것처럼 느끼는 것은 위험을 감수하는 두려움보다 나쁩니다.

대안으로, 특정 기술 및 / 또는 방법론을 사용하는 시스템 또는 환경에서 개발하려면 작업 이외의 프로젝트에 참여하는 것이 좋습니다. 최소한 두 시스템에서 다양한 작업을 수행하면 자신이 속한 곳을 찾는 동안 다른 무언가가 필요합니다.

당신은 물에서 물고기 인 것 같습니다. 바다의 몸을 찾아 헤엄 치세요!