조직의 기존 정책을 변경하는 방법

DevOps 변환을 수행하려는 조직에는 변경에 관심이있는 몇 가지 문제와 정책이 있다고 가정합니다. 이러한 관심은 최고 관리자, 중간 관리자 또는 상향식에서 올 수 있습니다. 이 변경을 방해하는 가장 큰 요인 중 하나는 다른 사람들이 변경을 구매하도록 만드는 것입니다.

예를 들어, Agile과 같은 "새로운"아이디어를 추진하는 경우가 종종 있습니다. 사람들은 변화에 저항하며 좋은 일이 일어나지 않도록 막는 벽처럼 보입니다. 그러나 좋은 일이 일어나야한다는 의무가 있습니다.

DevOps 전환을 시작하는 조직의 직원에게 영향을 미치는 방법은 무엇입니까? 작동하는 것으로 밝혀진 특정 기술과 방법. 더 많은 엔지니어링, 손 흔들림 감소.

프로세스는 프로세스를 따르는 사람들을 변화 시킨다는 것을 이해해야합니다. 사람들이 프로세스를 배우고, 내면화하고, 나아질수록 특정 문제를 해결하는 방법을 배우게됩니다. 비슷한 과정을 통해 사람이 문제의 범주를 해결하기 위해 사용하는 사고 방식으로 서로를 강화하고 결국 새로운 문제에 대한 결정과 새로운 솔루션을 안내하는 일련의 가치를 형성합니다.

프로세스를 변경하더라도 사고 방식을 변경하지 않고 값에 더 중요하더라도 사람은 단순히 새로운 프로세스를 원래 프로세스에서와 동일한 값, 동일한 사고 방식 또는 동일한 솔루션에 맞게 조정합니다. 특정 시점에서이 직위에서이 사람을 이념이나 획득 한 사고 방식과 이혼하거나 근본 가치를 바꿀 수는 없습니다.

변경을 수행하려면 다음 두 가지 옵션이 있습니다.

1. 이미 올바른 가치와 사고 방식을 가지고 있고 최상의 시나리오를 가진 사람을 데려와 도움없이 따라야하는 과정을 이해하십시오.
2. 최근에 신입 사원 또는 신입 사원 또는 조직 내 다른 팀에서 전근 한 신입 사원을 고용하고 권한을 부여하고 새로운 프로세스를 훈련시켜 새로운 사고 방식을 심어주고 새로운 가치가 창출되기를 바랍니다.

변경이 로컬 인 경우 해당 사용자가 보유하려는 글로벌 회사 전체 값을 이미 공유 했으므로 내부 전송을 선호 할 수 있습니다. 더 큰 변화의 경우, 새로운 관점을 갖기 위해 그리고 외부에서 누군가를 데려와 변경하려는 회사의 광범위한 가치를 공유하지 않아야합니다.

중요한 부분은 개인, 팀 또는 비즈니스 단위가 프로세스를 따르고 이전 팀, 다른 팀 또는 회사의 나머지 부서에서 프로세스를 격리 할 수 ​​있도록하는 것입니다.이 프로세스는 여전히 이전 프로세스 세트를 따릅니다. 위의 관리에서 이러한 변경 에이전트를 격리하기가 매우 어렵 기 때문에 변경이 더 커야하는 경우 관리 체인을 따라 가거나 맨 위에서 시작해야하는 경우가 종종 있습니다.

참고 : 경영진의 지원 없이는 팀 이상의 업무를 수행하기가 어렵습니다. 팀 내에서도 다른 사람들이 이미 자신의 방식으로 설정하는 것은 어렵습니다. 새로운 회사의 새 팀의 경우 성공적인 전도자는 단순히 리더가되거나 다른 사람들이 따라야 할 최소한의 저항 경로를 만들어 관리의 지원 없이도 형성 정책에 영향을 줄 수 있습니다. 그러나 기존 회사에서는 위를 참조하십시오.

팀 해킹

조직의 변화를 가져 오는 것은 어렵습니다. 사람들은 습관이 있고, 변화에 저항하며, 현상 유지에 익숙합니다. 특별한 순서없이 변경을 수행하기 위해 사용할 수있는 몇 가지 도구가 있습니다.

1. DevOps가 해결하는 문제를 다른 사람들이 경험하게하십시오. DevOps의 이점은 팀이 이론적으로 만 이해하는 경우가 많습니다. 배포 중에 발생하는 대부분의 문제는 나머지 개발 팀이나 관리 팀에서 희망적으로 거의 경험하지 않습니다. 이 문제를 해결하려면 문제가 발생할 때 소리를 내고 팀이 지속적인 통합 솔루션을 사용하는 경우이 문제가 어떻게 발생하지 않았는지 언급하십시오. 또 다른 가능성은 개발자가 직접 코드를 수정하는 대신 배포하는 동안 코드에서 발생한 문제를 해결하도록 개발자에게 요청하는 것입니다.

2. 지도자를 찾으십시오 . 사람들이 지도자 나 그룹에서 가장 인기 있고 지휘하는 사람이기 때문에 지도자를 따르는 것이 일반적입니다. DevOps 문화로의 전환을 원하는 리더를 선임하고 모범 사례를 사용하거나 옹호 할 수있는 공개 방법을 고안하십시오.

3. 신뢰 구축 . 우리는 사람들이 한두 번 전에 동의 한 후에 사람들의 것에 동의 할 가능성이 더 높습니다. 이상적으로는 문화의 변화없이 이루어질 수있는 작은 개선점을 찾아서 그 성공을 거둘 수 있습니다. 그러나 이것이 선택 사항이 아닌 경우 간단한 질문을하고 간단한 제안을 제시하여 예라고 말하거나 동의하는 습관을들이십시오.

4. 자신을 반복해서 부끄러워하지 마십시오. 반복 작업이 끝나고 결국 침몰합니다. 가능할 때마다 팀이 DevOps를 사용하는 경우 얼마나 큰 일이 될지 언급하십시오. 그러나 이는 팀 내에서 처음 신뢰를 구축 한 경우에만 작동합니다.

5. 그것을 즐겁게 만드십시오 . DevOps 상황에 대한 개념 증명을 작성할 수있는 경우 보고서 및 알림에 귀여운 이모티콘과 밝은 색상을 사용하십시오. 빌드가 실패하면 재미있는 gif를 게시하십시오. 업데이트가 성 가시지 않도록하십시오.