전문가가 아닌 관리자에게 개발자를 설명하는 방법은 무엇입니까?

DevOps에 완전히 흥분합니다. DevOps는 회사를 능률화하고 발전시킬 IT 인프라를 구축 할 수있는 방법론이라는 것을 알고 있습니다.
그러나 이것을 보스, 특히 비 기술적 인 보스에게 어떻게 판매합니까?

우리는 자동화 된 배포, 인프라 클라우드 화, 지속적인 통합 프로세스를 포함하는 자동화 프로젝트를 구현할 것입니다. 우리는 보스에게 더 높은 수준의 투자를하도록 설득해야합니다.

참고 : 우리는 테스트, 릴리스 및 감독을 자동화하여 프로세스를 개선하기 시작했습니다. devOps 채택 단계이지만 자동화 프로젝트 자체는 더 많은 투자가 필요하므로 대기 중입니다.

컨설턴트이기 때문에 나는 계약 상 "의존한다"고 대답 할 의무가있다. 그 방법으로, 나는 실제로 당신의 질문에 대답 할 수 있습니다.

무엇에 의존합니까? 글쎄, 그것은 당신의 상사가 DevOps에 대해 어떻게 생각하는지에 따라 올 수 있습니다.

1. 상사가 CIO.com에 대한 집착을 통해이 용어에 대해 들었다면 , 그들이 생각하는 바를 물어보십시오. 거기에서 차이점이 무엇인지, 뷰가 호환되는지 확인하십시오. DevOps를 평가하고 적합한 프로젝트를 식별하십시오. 핵심 DevOps는 문화이므로 프로젝트에 적용 할 수있는 방법을 고려하십시오.

2. 상사가이 용어를 들어 본 적이 없다면 DevOps의 비즈니스 사례를 작성하십시오. 사용 인형 연구소 개발 운영 팀의 주 와 같은 책에서와 자료를 피닉스 프로젝트 비즈니스 사례를 작성. 상사가 가지고있는 문제를 찾아서 DevOps가이를 해결하고 대화 스타터로 사용할 수 있습니다. Kenchew는 DevOps에 대해 언급 할 필요가 없다고 말했듯이, 예를 들어 Operations가 프로젝트에 더 많이 참여하거나 프로젝트 제공의 일부로 계획하기 위해 더 많은 테스트 자동화를 제안 할 수 있습니다.

3. 상사가 DevOps가 또 다른 유행어라고 생각하는 경우 위의 방법 중 하나를 수행하지만 DevOps를 언급하지 않는 경우 사이트 안정성 엔지니어링, 플랫폼 엔지니어링 또는 연속 배포와 같은 다른 유사한 모델을보고 문제를 해결하는 방법을 찾으십시오.

열쇠는 당신의 상사가 무엇을 동기 부여하는지 이해하는 데 집중하고, 그 문제를 해결하기 위해 실질적인 조치를 취하기 위해 약간의 시간, 돈 및 사람들을 개척하는 것입니다.

나는 다니엘 H. 핑크 (Daniel H. Pink)의 인간 판매 (To Sell Is Human) 라는 책 을 강력히 추천한다 . 이러한 요구를 충족시키는 솔루션.

당신은하지 않습니다.

DevOps에 대한 열정에도 불구하고 비 기술적 인 보스는 실제로 기술 전문가와 당신의 매력을 공유하지 않습니다.

먼저, 상사들에게 소규모 파일럿 프로젝트의 이점을 보여주십시오. 사례를 입증하기 위해 유용한 데이터 포인트를 수집하십시오. (이 질문이 도움이 될 수 있음을 발견했습니다. DevOps의 ROI를 측정하는 방법에는 어떤 것이 있습니까? )

다음으로 상사들에게 더 많은 혜택을 줄 수 있지만 적은 투자가 필요한 프로젝트가 있다고 말하십시오. (상사가 의자에서 떨어지지 않도록하는 프로젝트를 찾아보십시오. 잠시 동안 상사와 함께 일한 경우이 수치가 무엇인지 느낄 것입니다.)

투자를 받으면 목표를 달성하는 훌륭한 일을하십시오. 더 나은 아직, 그것을 초과 초과!

이제 상사가 마지막으로 물었을 때 "그러면 무엇을 했습니까?"

당신이 선포 할 때입니다 :

"DevOps"

다음 devops 프로젝트에 대한 추가 투자를 요청하십시오.

조직의 최고 또는 최저에 관련성을 보여 주면 모든 비즈니스 이니셔티브는 관심을 끌 것입니다.

devops와 같은 내부 이니셔티브는 수익에만 영향을 줄 수 있습니다. 개인이 수행하는 되풀이 작업 비용과 자동화가 해당 지출을 줄이는 방법을 식별해야합니다.

기술자가 아닌 관리자가 꼭두각시 대신 요리사를 선택하는 것의 차이점을 이해하지 못할 수도 있지만 업계 동향에 대한 이해가 있습니다. 사용할 수없는 빌드로 인한 지연 비용, 회귀 문제 및 접근 방식으로 이러한 비용을 줄일 수있는 방법을 알려줄 수 있습니다. 결론을 개선하기위한 실질적인 계획을 보여줄 수 있고, 판에있는 다른 조치 항목보다 나은 경우 미리 진행할 수 있습니다.

DevOps 끓임이라는 용어에 대해 잘 모르거나 실수 한 사람들을위한 나의 추론은 "비즈니스 가치를 더 자주 전달"하는 것입니다. 내 경험상 이것은 관리자가 이의를 제기 할 수있는 사람이 거의 없습니다. 그들은 그것을 얻는다.

만약 그들이 "우리는 단지 몇 주 정도의 일을 할 사람을 바로 잡을 사람이 필요하다. 그래서 우리가 지금 일할 사람에 얼마를 투자 할 것인지에 한계가있다"고 말하면 "우리는 회사가 너무 많은 비즈니스 가치를 제공하는 것을 원하지 않습니다. 우리는 조금 더 필요하지만 그게 전부입니다."

물론 수사적이지만 도요타에 관한 책을 읽도록 지시하는 것보다 훨씬 효과적입니다.

이전 답변의 모든 내용은 사실이지만 실제로 상사로부터 승인과 약속을 얻기 위해 누락 된 것이 있다고 생각합니다 (BTW : 대부분의 사람들은 최대 1 명의 상사 만 있습니다 ...).

머피 씨는 곧 나올 것입니다 (= 잘못되거나 잘못되어서 잘못되어서는 안될 문제 ). 그리고 그 시점에서 일부 보스는 다음과 같은 질문에 대한 답변을 원할 것입니다.

언제, 왜 어떤 일이 일어 났으며 어떤 승인 된 사용자가 실제로 그것을 승인했는지 ...

그리고 그 시점에서 당신은 당신이 가지고있는 DevOps- 실습으로부터 실제 ROI를 얻게 될 것입니다. 그리고 / 또는 갑자기 당신이 찾고있는 것을 구현하기 위해 모든 종류의 거대한 예산 승인을 얻습니다.

Murphy가 등장하는 데 시간이 너무 오래 걸리더라도 회사에서 Richard가 " 엔지니어가 코드를 배포하고 실행할 때 어떤 프로세스 또는 도구를 사용하여 업무를 분리 할 수 ​​있습니까? " 요구 사항은 CxO를 두려워합니다 ...).

그러나, 새로운 누군가에게 "DevOps"를 소개해야한다면, "좋아요"와 같이 미리 "경고"하는 데 도움이 될 수 있습니다 . 따라서 DevOps 사례를 시작하고 싶을 것입니다! 다른 종교로 전환하는 중 ... "