프로세스는 오픈 소스여야 하는 이유

오픈 소스 접근법을 사용하여 엔지니어링 프로세스를 유동적으로 만듭니다. 회사의 모든 사람이 협력 방식을 개선할 수 있도록 허용합니다.

 

사내 프로세스는 오픈 소스여야 하는 이유

 

프로세스: 무언가를 만들거나 특정 결과를 얻기 위해 수행되는 일련의 행동 또는 이벤트 

 

 

프로세스는 오픈 소스

프로세스에 대해 가장 먼저 깨달아야 할 것은 프로세스가 이미 존재한다는 것입니다. 이를 인정하든 인정하지 않든 말입니다. 프로세스는 우리가 함께 일하는 방식입니다.

프로세스는 명시적이고 기록될 수 있습니다. 아니면 암묵적일 수도 있습니다. 사람들이 특정한 방식으로 팀으로서 일하는 것에 익숙하기 때문에 이해하는 것입니다. 

그 과정은 한 그룹의 사람들이 일치하는 것이 될 수 있습니다. 그들은 모두 일이 어떻게 돌아가는지에 대해 동의합니다. 아니면 사람들이 동의하지 않는 것일 수도 있습니다. 그들은 일이 어떻게 진행되는지에 대해 다른 생각을 가지고 있을 수 있습니다.

그 과정은 집단으로 일하는 인간의 일부이기 때문에, 그 과정에 반대하는 것은 무의미합니다. 그것은 사람들이 시도하는 것을 막지 못합니다! 하지만 진짜 문제는 우리가 함께 일하는 방식을 어떻게 형성하고 정의하느냐 하는 것입니다.

 

 

프로세스에 문제가 있을 수 있음

그 과정에 대한 대부분의 반대는 그것에 대한 사람들의 나쁜 경험에서 비롯됩니다. 이건 자연스러운 거예요. 프로세스는 코드와 약간 유사합니다. 주의하지 않으면 프로세스가 저하되고 문제가 발생할 수 있습니다.

프로세스의 문제점은 프로세스 자체의 삶을 가지고 있다는 것입니다.

예를 들어, 소프트웨어 엔지니어링 팀이 새로운 작업에만 집중하고 지원 팀에서 들어오는 버그에 대해서는 어떠한 작업도 수행하지 않는다고 가정해 보겠습니다.

이를 무시하고, 왜 이런 일이 일어나는지 더 깊이 조사해야 할 것입니다. 그리고 이 문제에 대한 프로세스 대응을 하는 것으로 가정해 보겠습니다.

- 엔지니어링 관리자와 제품 관리자가 스프린트할 때마다 몇 가지 버그를 예약하도록 합니다

- 팀이 당직자에게 당직 근무 주 동안 버그를 처리하도록 지시하기로 결정합니다

- 버그에 대한 SLA 추가

 

어떤 결정을 내리든, 여러분은 문제를 보고 있고, 여러분은 미래에 그 문제를 해결하기 위해 팀의 행동을 바꾸고 있습니다. 이것은 공정 작업입니다.

따라서 엔지니어링 관리자와 제품 관리자가 일주일에 한 번씩 지원 담당자를 만나 가장 중요한 버그의 우선순위를 결정한다고 가정해 보겠습니다. 회의를 설정하면 매주 시작됩니다.

문제는 2년 후에 문제가 발전할 수도 있다는 것입니다. 그리고 그 과정을 만든 사람들은 그곳에 없을지도 모릅니다. 그래서 2년 후에 그 회의에 참여한 사람들은 그 회의가 해결하고자 했던 문제들을 이해하지 못할 수도 있습니다.

과정의 기원에 대한 이러한 불확실성은 사람들로 하여금 변화를 꺼리게 할 수 있습니다. 이는 프로세스가 중요하거나 위험해 보이는 것과 관련된 경우에 특히 해당됩니다. 그래서 프로세스는 일종의 좀비처럼 작동하는 그 자체의 삶을 가질 수 있습니다. 그리고 사람들은 그것이 나쁘거나 해롭더라도 그것을 따라야 하기 때문에 그것을 따릅니다.

다시 말하지만, 이것은 레거시 코드와 같습니다. 효과는 있지만, 여러분이 그것을 만질 때마다, 여러분이 다른 문제들을 일으킬 위험이 있습니다. 그래서 대부분 사람들은 그것을 만지는 것을 피하려고 노력합니다.

 

 

프로세스가 유동적이고 역동적이라면?

- 유동적이고 역동적으로 느껴질 것입니다. 조직의 요구에 쉽게 적응할 수 있습니다.

- 그 안에 좋은 맥락을 담을 것입니다. 이렇게 하면 변경하기가 더 쉬워집니다.

- 명확하고 간결하며 최신 정보입니다.

- 그것은 진실의 근원이 될 것이므로 당신은 그것에 의존할 수 있습니다.

 

 

프로세스를 코드처럼 처리

간단히 말해서, 좋은 프로세스는 좋은 코드와 약간 유사합니다:

- 쉽게 업데이트할 수 있습니다

- 버전을 제어할 수 있습니다. 시간이 지남에 따라 어떻게 변화했는지 확인할 수 있는 좋은 역사적 정보를 가지고 있습니다.

- 변경 비용 최소화

- 프로세스가 존재하는 이유와 프로세스가 수행하려는 작업을 파악할 수 있는 좋은 컨텍스트가 있습니다

- 그 과정은 어떻게 일이 진행되는지를 설명하는 것입니다

 

솔루션: 오픈 소스 프로세스

그렇다면 변화하는 조직의 요구사항에 적응할 수 있는 유연한 프로세스를 어떻게 확보할 수 있을까요?

가장 좋은 해결책은 프로세스를 오픈 소스화하는 것입니다. 프로세스를 기록하고 누구나 변경사항을 제안할 수 있도록 합니다. 회사 운영 방식을 바꿀 수 있다고 모두에게 말합니다.

이것은 많은 일이 될 수 있지만, 매우 명확하게 할 수도 있습니다.

그리고 그것은 우리가 함께 일하는 방식이 기록되어 있다고 말할 수 있는 권한을 부여한다고 느낄 수 있습니다. 누구나 변경할 수 있습니다.

 

문자 문화의 이점

프로세스를 기록하는 것은 서면 문화를 가진 조직의 핵심 관행입니다. 그리고 내용을 적는 것에는 다음과 같은 여러 가지 이점이는 다음과 같습니다:

글을 쓰는 것이 더 명확한 생각입니다. 그것은 정확성을 요구합니다. 명확성을 제공합니다.

쓰기는 비동기식이며 항상 사용할 수 있습니다. 정보를 공유하기 위해 미팅이 필요하지 않기 때문에 쓰기는 더 확장 가능합니다.

따라서 쓰기는 분산된 팀에 더 적합합니다.

가장 큰 단점은 문서를 유지하기 위해 노력해야 한다는 것입니다.

 

프로세스의 소스를 여는 방법: 엔지니어링 핸드북

그렇다면, 어떻게 서면 문화를 구축하고 조직을 위해 유연하고 유지 가능한 프로세스를 만들 수 있을까요?

엔지니어링 핸드북을 생성합니다. 이것은 조직에서 작동하는 방식에 대한 저장소입니다. 프로세스 문서를 나타냅니다.

이것을 수없이 해왔습니다. 추천하는 일반적인 단계는 다음과 같습니다.

 

1. 엔지니어링 핸드북의 형식 선택

첫 번째 과제는 프로세스 문서를 보관할 위치를 파악하는 것입니다. 완벽하게 작동하는 것을 발견한 적이 없습니다. 저는 직원 핸드북에 어떤 도구를 사용해야 하는지에 대한 제 노트를 공유하는 별도의 게시물을 가지고 있습니다. 중요한 단계는 무언가를 선택하는 것입니다. 당신은 나중에 마음을 바꿀 수 있습니다.

 

2. 콘텐츠 부트스트랩

다음으로 해야 할 일은 내용을 채우기 시작하는 것입니다. 프로세스를 만날 때마다 간략하게나마 작성합니다. 현재 상황이 어떻게 작동하는지 설명합니다.

조직에 가입할 때 특히 잘 작동합니다. 이러한 기록을 사용하여 작업 방식을 명확히 할 수 있습니다. 사람들에게 여러분의 글을 보여주고 그것이 정확한지 물어볼 수도 있습니다.

이것을 더 출시하기 전에 몇 달 동안 할 수도 있습니다. 저는 조직 변경을 할 때 문서화하고 전후 섹션을 가질 것입니다. 변경한 후에는 문서의 기록 부분에 사전 섹션을 추가하여 시간이 지남에 따라 프로세스가 어떻게 발전하고 있는지 확인할 수 있도록 하겠습니다.

프로세스 문서의 이전 버전이 어딘가에 저장되어 있는 경우가 종종 있습니다. 불완전하거나 유지 관리되지 않을 수 있습니다. 하지만 그들은 이 과정의 많은 부분을 단축시킬 수 있습니다. 구성하고 유지 관리를 시작합니다.

상호 작용할 수 있는 충분한 콘텐츠를 갖는 것은 중요합니다. 그것은 그 연습 뒤에 추진력이 있고 그것이 심각하게 받아들여질 것이라는 것을 보여줍니다. 이것은 사람들이 그들만의 시간을 그것에 투자할 수 있게 해줍니다.

 

3. 유지관리자 선택

이러한 프로세스 문서가 진지하게 받아들여지고 업데이트 및 정리되었는지 확인할 수 있는 사람이 필요합니다. 여러분은 도움을 요청할 수 있지만, 궁극적으로 도움을 받을 누군가가 필요합니다. 이 작업은 쉽게 위임할 수 없는 작업일 수 있습니다.

이상적으로는 모든 경영진이 진지하게 생각하는 것이며, 모델링은 할 수 있지만 더 많은 사람들이 도와줍니다.

 

4. 모든 것이 작동하는 방식을 전달하고 변경 사항을 공개합니다

다음 단계는 롤아웃하는 것입니다. 컨텐츠를 부트스트랩하고 있다면, 컨텐츠를 롤아웃하는 것은 조직 전체에 놀라운 일이 아닐 수 있습니다. 어떤 사람들은 이미 그것을 본 적이 있을 것입니다.

일반적으로 제가 한 일은 서면 문화를 강조하는 이유에 대해 이야기한 다음 프로세스 문서를 최신 상태로 유지하기 위해 준수하는 규칙을 공유하는 것입니다. 그런 다음, 저는 누구나 조직이 어떻게 작동하는지 개선하고 어떻게 작동하는지 설명하려고 합니다. 이것은 팀에게 흥미롭고 힘이 될 수 있습니다.

 

프로세스 규칙

그렇다면 프로세스 문서화에 대한 규칙은 무엇입니까? 여기 제가 공유하고 싶은 것들이 있습니다.

 

1. 문서와 함께 회신

첫 번째로 공유하고 싶은 것은 문서로 회신하는 개념입니다. 저는 보통 올엔지니어링 미팅이나 조직에 보내는 뉴스레터에서 엔지니어링 팀 전체와 공유합니다. 제가 직접 모델을 만들어 보겠습니다. "문서로 회신"이란 무엇입니까?

다른 사용자가 질문을 하면 해당 질문에 대답하는 URL로 응답하는 것이 좋습니다. Wiki로 이동하여 답이 없는지 확인하고 없으면 추가합니다. 그런 다음 당신이 그들에게 URL을 보내주세요.

이를 통해 다음과 같은 몇 가지 작업이 수행할 수 있습니다: 

사용자가 질문에 답변하지 않아도 나중에 답변할 수 있도록 보장합니다.

그것은 미래의 질문에 대한 답을 어디서 찾을 수 있는지 묻는 사람을 훈련시킵니다.

문서로 회신하는 것은 사람들이 당신에게 물어볼 수 있는 모든 질문 앞에 캐싱 계층을 배치하는 것입니다. 이를 통해 전문 지식을 더욱 폭넓게 활용할 수 있습니다. 

문서로 회신하는 것이 조직에 미치는 영향은 답변을 미래에 대비하는 것입니다. 질문에 백만 번 대답하는 대신 한 번만 대답하면 됩니다. 당신은 일회성이 아닌 체계적으로 문제를 해결하고 있습니다.

 

2. 핸드북에 수록되기 전까지는 공식적이지 않습니다

다음 규칙은 제가 경영진에게 반복하는 것입니다. 핸드북에 넣기 전까지는 공식적인 것이 아닙니다.

관리자가 변경을 하거나 계획을 발표할 때마다, 저는 계획에 URL이 포함되어야 합니다.

이 규칙은 중요합니다. 그렇지 않으면 핸드북이 진실의 원천이 아니기 때문입니다. 사람들은 정확하기 위해 그것에 의존할 수 없습니다. 이는 핸드북에 대한 신뢰를 떨어뜨리고 유용한 정보 소스가 되지 않도록 합니다. 그러나 이러한 제약을 추가하면 핸드북에 있는 것이 진실이 됩니다. 프로세스 문서를 최신 상태로 유지하는 데 관심이 있다면 이는 완전히 필요한 규칙입니다.

 

3. 프로세스 문서를 편집하는 것만으로는 변경할 수 없습니다

공유하는 세 번째 규칙은 문서를 편집하는 것만으로 사람들이 무언가를 하도록 만들 수 없다는 것입니다. 그건 인간이 일하는 방식이 아닙니다. 하지만 당신은 이 규칙이 필요합니다; 많은 사람들이 그것을 시도할 것입니다.

변경 내용이 작동하는 방식을 설명하는 페이지가 필요합니다. 보통 그것을 "우리가 일하는 방식을 바꾸는 방법"과 같은 것이라고 부릅니다 

또한 승인 및 변경에 대한 규칙을 설명해야 합니다. 완전한 승인 과정을 거쳤고, 누구나 변경할 수 있는 위키에서 일을 했습니다. Wiki에서 작업을 수행할 때는 주기적으로 변경 사항을 모니터링하여 부적절한 변경 사항이 발생하지 않도록 하는 것이 좋습니다. 또한 정기적으로 릴리스 노트를 생성하여 시간이 지남에 따라 운영 방식이 어떻게 바뀌었는지 사람들이 알 수 있도록 했습니다.

 

4. 프로세스는 맥락과 역사를 포함해야 합니다

프로세스 페이지에는 컨텍스트 및 기록 섹션이 명시적으로 포함된 일종의 템플릿이 필요할 수 있습니다. 이것은 여분의 오버헤드처럼 느껴질 수 있습니다. 하지만 도움이 됩니다. 구현 중인 프로세스에 필요한 상황을 명시적으로 호출할 수 있습니다. 그리고 여러분은 가끔 그것이 더 이상 유용하지 않을 때나 여러분이 이런 방식으로 일을 하는 것에 대해 다시 생각해보고 싶을 때도 언급할 수 있습니다.

역사를 추가하는 것은 사람들이 시간이 지남에 따라 이루어진 변화를 이해하는 데 도움이 될 수 있습니다. 그리고 그 맥락은 사람들이 미래의 변화를 어떻게 형성할 것인지를 이해하는 데 도움을 줄 수 있습니다.

 

한 차원 높은 수준으로: 공개

엔지니어링 핸드북을 배포하고 성공적으로 배포했다면 다음 단계로 확장하는 것을 고려해 볼 수 있습니다. 전 세계에 공개하는 것입니다.

이것은 급진적인 단계이며 아마도 많은 회사에 적합하지 않을 것입니다. 그리고 사람들을 그 아이디어에 동참시키는 것은 어려울 수도 있습니다. 하지만 다음과 같은 이점이 있습니다:

이것을 한 것으로 가장 유명한 회사는 Gitlab입니다. Gitlab 핸드북은 회사의 운영 매뉴얼이고, 꽤 잘 되어 있습니다.