PROJECT TO PRODUCT 프로젝트에서 제품으로

서문

• 전체 비즈니스 가치 흐름에 걸쳐 팀이 일하는 방식을 바꿔야만 이를 달성할 수 있다고 말한다.
• (내가 현재 달성하고 싶어하는 가장 중요한 일 중 하나. 회사 business 기능의 모든 flow를 end to end로 flow diagram으로 표현해서 구조를 파악하고 서로 communication하는데 낭비가 없도록 하는 일)

옮긴이의 말

• IT 조직은 애자일이나 데브옵스 등과 같이 프로젝트를 효율적으로 진행할 수 있는 도구를 익히고 이를 통해 의사소통합니다. 반면 소프트웨어에 대한 비즈니스 조직의 시각은 여전히 테일러리즘 방식에 머물러 있습니다. 이러한 차이가 디지털 변혁의 큰 장벽 중 하나입니다. 이는 IT 조직과 비즈니스 조직의 의사소통에 문제를 일으키고 디지털 변혁 실패의 원인이 됩니다.
• (내가 개발자라서가 아니라, 정말 전통 산업의 경우 굉장히 많은 부분이 뒤쳐져 있다. 항상 새로운 걸 받아들여야 하고, 개선이 필요한 개발업계와 달리 큰 변화없이도 업무를 진행할 수 있는 업계에서는 변화를 남의 일이라고 생각하거나 필요성을 느끼지 못하는 걸로 보인다)

들어가며

• 기술 부채나 스토리 포인트와 같이 기술자에게 익숙한 소프트웨어 전달 개념은 IT 이니셔티브를 프로젝트로 관리하고 일정과 지출 비용 준수 여부로 프로젝트를 평가하는 대부분 비즈니스 리더에게는 별 의미가 없다. 프로젝트 지향적 관리 프레임워크는 다리를 짓는다거나 데이터 센터를 만드는 데에는 적합하지만, 소프트웨어 시대의 전환점에서 살아남기에는 매우 부적합하다.
• 플로우 프레임워크는 '가치 흐름'에 알맞게 소프트웨어 전달을 측정하고 모든 IT 투자를 조정하는 새로운 방법이다. 여기서 '가치 흐름'이란 소프트웨어 제품이나 서비스로서의 소프트웨어 Saas. Software asa Service 를 통해 비즈니스 가치를 시장으로 전달하기 위해 수행하는 모든 활동을 말한다. 플로우 프레임워크는 프로젝트 지향 관리 방식에서 원가 중심으로 예산을 측정하던 방식과 조직 차트로 소프트웨어이니셔티브를 측정하던 방식을 대체한다. 지난 방식들은 기술에 대한투자가 비즈니스 결과로 연결되도록 하는 '플로우 지표'로 대체된다.플로우 프레임워크는 흐름, 피드백, 지속적 학습으로 구성된 데브옵스의 세 가지 방법(『데브옵스 핸드북』 참고)을 기술 조직을 넘어 비즈니스 전체에 적용할 수 있도록 한다.
• 우리는 미래를 바꿀 수 있다. 우리 기업을 경쟁력 있게 만들 수 있다. 거대 기술 기업과 스타트업이 주는 교훈을 우리의 복잡한 비즈니스에 도입할 수 있다. 소프트웨어 시대의 디지털 네이티브 기업들이하고 있는 것처럼, IT라는 블랙박스를 가치 흐름이라는 투명한 네트워크로 바꾸고 관리할 수 있다. 이를 성취하려면 변혁 활동보다는 측정 가능한 비즈니스 결과에 집중해야 한다.
• (‘측정 가능’이라는 게 개발 회사가 아닌 곳에 오니 정말 어렵다는 걸 절실히 느끼고 있다. 일단 측정을 하기 위한 장치나 프로세스를 만드는 거부터 거센 저항이 있다)

1부 플로우 프레임워크

• IT 조직이 자신들의 생산 단위가 무엇인지에 대해 합의해본 적조차 없다는 것이다…경영진은 철강 시대에 자리 잡은 테일러리즘의 관점에 머물러 있다…기술 언어와 비즈니스 언어의 격차는 여전하다.

• 제조업의 발자취를 무작정 따르는 것은 아무것도 하지 않는 것만큼 많은 위험이 따른다는 불편한 진실이다.
• (피터 드러커의 what gets measured gets managed가 생각이 났다. 워낙 유명해서 나도 자주 들어봤고 많은 사람들이 이 말을 사용하지만, 사실 이 말이 오용되고 있다는 주장 — e.g. http://www.innovator.or.kr/2015/08/blog-post.html — 도 있다. 정말 중요한 건 측정하기 어렵거나 불가능한데, 저 말 때문에 많은 사람들이 측정 가능한 거만 집착하고 있다는 뜻. 위의 말도 어느 정도 맞닿아 있다는 생각이다. 나도 개발자 출신이라 측정해서 그대로 다 진실을 보여주고 싶지만, 이게 가능한지, 또 가능하더라도 무조건 좋은 일인지가 아직 확신이 들진 않는다)

1장 소프트웨어 시대

• 새로운 생산 방식을 마스터한 기업은 비교적 느리게 움직이는 시장일지라도 이를 마스터하는 데 시간이 오래 걸리는기업을 대체할 것이다… 산업 분야나 시장과 관계없이 소프트웨어 시대의 전환점을 통과하고 있는 현시점에 안전한 비즈니스는 없다는 점을 강조하려 한다… 문제는 기업이 파괴에 대한 취약성을 모른다는 것이 아니다…이런 변혁이 실패하고 있다는 것이 문제다.
• 다만 프로젝트 지향적 접근이 인재를 끌어들이는 대신 조직 밖으로 밀어내는 상황을 만든다는 것이다…결론은 최고의 전략과 의도가 있어도 소프트웨어 전달 능력과 역량이 디지털 변혁의 병목 지점이 된다는 것이다. 문제가 매우 조금씩 그리고 천천히 나타나기 때문에 비즈니스 측에서는 문제가 왜 일어나는지와 어떻게 해야 하는지를 이해하지 못한다.
• (“기업이 파괴에 대한 취약성을 모른다는 것이 아니다”와 “비즈니스 측에서는 문제가 왜 일어나는지와 어떻게 해야 하는지를 이해하지 못한다”가 처음에는 상충되는 거 아닌가 했는데 그게 아니었다. 문제점 자체의 위력은 알고 있지만, 이유를 모르니 대처할 방법도 모른다는 뜻이었네)

• 앨런 케이 Alan Kay의 "미래를 예측하는 가장 좋은 방법은 미래를 발명하는 것이다'
• (정말 멋진 말이지만 언제나 그렇듯 발명을 선도하는 사람은 극소수이고 그 중에서 성공하는 건 더 소수였다)
• 지난 20년 동안 디지털 통신 및 협력으로 향하는 변화에 처음으로 노출된 코닥Kodak이나 블록버스터 BlockBuster와 같은 기업은 파괴의 첫 번째 희생양이 되고 말았다. 현재와의 차이점이라면 지금은 경제 전체가 파괴를 겪고 있다는 점이다.

• 소프트웨어 혁신을 이룬 기업은 승자가 되고, 그렇지 못한 기업은 점차 쇠락의 길을 걷거나 블록버스터의 전철을 밟게 될 것이다.
• 비즈니스가 어떤 상황에 있든지 간에 소프트웨어 시대에 성공하려면 어떤 유형의 파괴가 비즈니스를 위험에 빠뜨렸는지 정확히 정의해야 한다.

• 이미 전환전에 들어선 지 수십년이고 활용기에 들어서면 전환하지 못한 기업들은 모두 사라질 거라는 무서운 이야기

• 우리는 오랜 기간 많은 기업이 IT, 애자일, 데브옵스 전환을 시도했다가 실패하는 사례를 지켜봤다. 최신 기술 시대에서 살아남기위한 싸움을 해 볼 기회를 얻으려는 대부분 기업에는 이번이 마지막 기회가 될 것이다.
• 첫 번째 깨달음: 소프트웨어 규모가 확장함에 따라 아키텍처와 가치 흐름 사이의 단절로 생산성은 감소하고 낭비는 증가한다. - 개발자가 가치 흐름으로부터 단절돼 있을 때 소프트웨어 생산성이 감소하고 낭비가 증가한다
• 두 번째 깨달음: 단절된 소프트웨어 가치 흐름은 소프트웨어 전달의 병목 지점이 된다. 가치 흐름의 단절 원인은 프로젝트 관리 모델의 잘못된 사용에 있다. - e.g. 개발자가 시간을 어떻게 사용하는지 좀 더 자세한 분석을 수행했고 오직 34%의 시간만이 개발에 사용된다는 것이 드러났다. 코드를 작성하는 일이 개발자에게 급여를 지급하는 이유이며 개발자가 하고 싶어 하는 일인데도 말이다. 이것은 심각한 시스템적 문제였다. 또한 개발자만의 문제도 아니었다.
• 세 번째 깨달음: 소프트웨어 가치 흐름은 선형적인 제조 공정이 아니라 제품에 따라 조정돼야 하는 복잡한 협업 네트워크다. - 소프트웨어 가치 흐름을 고려하기 위한 모델 전체가 잘못되었다는 생각이었다.
• 비즈니스와 기술자의 간극은 변혁 이니셔티브를 통해 좁아지기는 커녕 오히려 넓어지고 있다

• 가장 큰 문제는 경영 관점에서 기성 기업은 이전 시대의 관리 방법 및 생산 방식을 사용하고 있으며 그렇기 때문에 실패하고 있다는 점이다.

2장 프로젝트에서 제품으로

• 이 두 가지 실패 사례는 과거에 잘 통했던 패러다임이 지금 시대에는 실패의 원인이 됨을 보여준다.
• (과거에 안주하면 실패하는 건 모든 분야에서 마찬가지이지만, 개발과 관련된 쪽은 특히 심하다. 어렸을 때 삼성에서 일하던 시절 NOKIA는 정말 넘을 수 없는 벽이었다. 당시 삼성에서도 상상하기 힘든 저가로 적당한 품질의 폰을 만들며 승승장구했다. 그러나 스마트폰 시대가 도래하며 순식간에 몰락하고 결국 MS에 팔린 후 순식간에 사라졌다)

• 공장 전체는 병목 지점을 중심으로 설계돼 있습니다.
• (결국 병목 지점, 병목 자원을 중심으로, 잘 활용할 수 있게 설계하는 게 필요. HW냐 SW냐는 중요하지 않다)

• 문제는 애자일 도입에 대한 리더들의 좋은 의도와 조직의 의지에도 불구하고 모든 노력이 실패로 돌아갔다는 것이다. 변화를 위해 많은 에너지가 공급됐으며 모두가 옳은 일을 하고 있다고 말했고 그렇게 보였다.
• 나는 애자일 방법론의 도입을 위한 노키아의 헌신적인 노력 그리고 우리와 함께 일했던 팀들이 만들어낸 인상적인 애자일 모델 활동에 진심으로 감명받았다. 빠르게 변화하는 시장에 회사가 적응하는 데 애자일이 많은 도움이 된다는 것을 경영진이 깨달았다는 것은 확실했다.
• 하지만 점점 더 많은 개발 팀과 일을 하면서 불길한 조짐이 보이기 시작했다. 애자일 활동과 준수 여부를 평가할 때 실제 활동에서 나온 명확한 결과를 반영하지 않는다는 점이 문제였다.
• 이야기를 나눠 본 개발자들은 어떤 애자일 기법과도 문제가 없었고 오히려 호의적인 편이었다. 그러나 훨씬 큰 문제가 있었다. 노키아의 강력한 소프트웨어 보안 프로세스가 빌드 테스트 배포 과정을 더디게 한다는 것이 다운스트림의 주요 이슈였다. 심비안 OS의 구조에도 중대한 문제가 있었다... 심비안 OS는 충분히 확장성 있게 설계되지 않았다.
• 마지막으로 개발자들이 스크럼을 대체로 긍정적으로 생각했음에도 불구하고, 개발자들의 일상 업무는 전혀 다른 툴을 사용하는 경영진의 플래닝 과정과 분리돼 있었다...현대 애자일의 정수인 유저 스토리는 원래의도인 흐름과 피드백 메커니즘이 아닌 문서화 도구로 쓰이고 있었다.
• 활동을 측정하는 것이 아닌 성과 및 결과를 측정해 변혁의 지표로 삼았다면 그림은 훨씬 달라졌을 것이다. 개발자가 맞닥뜨렸던 근본적인 병목 지점이 수면 위로 올라왔다면 노키아의 핵심 플랫폼인 심비안 OS에 투자를 감행해 애플Apple과 같이 새로 진입한 소프트웨어 전문 업체들과 충분히 경쟁해 볼 수 있었을 것이다. 하지만 실제로는 개발과 비즈니스 사이의 단절 때문에 중요한 피드백이 비즈니스에 전달될 수가 없었다. 다운스트림과의 단절, 소프트웨어 빌드 및 배포 과정의 비효율성은 어떠한 개선 과정이라도 너무나 느린 속도로 진행될것임을 의미했다.
• 시장의 선두 주자이자 준수한 사업 역량을 가졌던 노키아는 급격하게 변화하는 모바일 생태계에서 기민하게 행동하며 전략을 조정하는 것이 필요함을 이해하고 있었다... 그렇지만 변혁이 가져온 실제 사업적인 성과는 전혀 없었다.
• 비즈니스 수준에서 어디가 병목 지점인지 모르고 있다는 것을 느낄 수 있었다. 개발 부서가 아는 것과 사업 부서가 추정한 내용 사이의 간극은 너무나 컸다. 엔드 투 엔드 가치 흐름을 부분적으로만 최적화한 애자일 도입은 병목 현상을 해결하지 못한 채 성과를 거의 거두지 못했다.
• (내가 가장 중요하게 생각하며 또 경계해야 하는 부분. 개발 프로세스를 개선하려는 내 의도가 비즈니스 수준에서의 병목 문제를 해결해야 하지, 부분 최적화에 그치면 절대 실패)

• 골드랫은 병목 지점이 아닌 곳에 투자하는 것이 얼마나 헛된 일인지 잘 설명했으며, 이는 노키아의 애자일 변혁이 실패한 원인이다.

• 의사 결정 프레임워크나 조직의 가시성 어딘가에 근본적으로 잘못된 부분이 있고, 이것이 비즈니스를 수없이 반복해서 실패하게 만드는 이유다.

• 테스트 비행 동안 비행기가 흔들리자 소프트웨어 엔지니어들은 난기류 제어 소프트웨어를 비행 중에 수정할 수 있었다. 기업이 소프트웨어 리더를 고위험 제품 개발에 제대로 참여시킨 예로 이보다 더 나은 사례를 아직 들어본 적이 없다.
• (정말 극단적이긴 하지만, 또 어느 정도 이해는 간다. 결국 제품을 체험해야 한다는 뜻일까?)

• 보잉은 약 30년 동안의 생산과 그 뒤 30년 동안의 유지 보수를 전제로 비행기를 설계한다는 것을 알게 됐다. 다시 말해 하드웨어와 소프트웨어 지원 측면에서 60년 앞을 내다보고 있다는 것이다.
• (6개월도 예측하기 힘든데 60년을 예측한다는 건 어떤 걸까?)

• 많은 조직이 디지털 변혁에서 저지르는 실수는 생산성 영역의 지표인 비용과 순이익을 통해 전체 IT 및 소프트웨어 전달 능력을 측정하는 것이다. 소프트웨어 시대 이전에는 IT가 생산성 영역에 있었겠지만 이제는 조직이 상황에 따라 서로 다른 영역에서 제품을 출시하고 운영해 시장에서의 지속 가능성을 도모하고자 하는 것이 디지털 변혁의 목표다.
• (그러나 비용에 대해 이야기하는 비즈니스의 이야기를 무시할 수도 없는게 딜레마다)

• 프로젝트 지향적 관리 vs. 제품 지향적 관리
• (내가 작년 11월 프로세스 개편을 하면서 기존의 프로젝트 기반의 TF 형태로 일하는 걸 폐지하면서 했던 이야기들이 포함되어 있다)

• 여기서 부조화가 발생한다. 데브옵스와 애자일 팀은 소프트웨어전달에 내재한 불확실성을 다루기 위해 피드백 루프를 만들고 비즈니스가 피드백에 따라 대응할 수 있도록 제공하는 것이 주요 업무다. 확실성이 높을수록 프로젝트 계획에 의해 최적의 장기 자원 할당이 이뤄진다. 하지만 소프트웨어 전달의 복잡성과 전환점의 시장 변화 속도 때문에 불확실성을 모두 포함해 프로젝트 계획을 만든다는 것은 엄청난 낭비일 뿐 아니라 성과가 아닌 활동과 대리 지표에 집중하는 잘못된 가시성을 비즈니스에 제공할 수 있다.
• 이와는 대조적으로 제품 지향 관리는 비즈니스로 가치를 전달하는 투자 단위 각각의 결과를 측정하는 데 집중한다. 이 단위에 해당하는 것이 제품이며, 이 제품이 고객에게 가치를 전달하므로 측정은 반드시 제품의 비즈니스 결과를 기반으로 이뤄져야 한다. 기존 가치 흐름에 투입되는 투자와 마찬가지로 새로운 가치 흐름에 대한 투자 역시 제품의 비즈니스 사례를 기반으로 한다.
• (확실하다면, 프로젝트 기반 방식도 나쁘지 않고 가능하다. “확실”하다면. 하지만 비즈니스에서 확실한 게 요즘 어디 있는가? 결국 agile도 유연성을 높이기 위한 방법이고, product 조직을 만드는 이유도 여기 있는 법)

• 한 엔지니어가 가치 흐름을 하나 이상 할당받는 경우 생산성이 크게 떨어진다는 것을 알게 됐다.
• (이런 이유로 WIP를 제한하고 싶으나, 현실은 오히려 급건이라는 이유로 하루에도 몇 개씩 sprint planning에서 논의되지 않은 issue들이 들어오고 있다)

• 리스크
• 프로젝트 지향 관리는 프로젝트를 진행하는 동안 발생할 수 있는 모든 리스크를 식별하도록 설계돼 있다. 이는 모든 발생 가능한 리스크를 미리 알고 있어야 한다는 의미다. 다른 분야에서는 가능할지도 모르지만 소프트웨어 전달이라는 불확실하고 변화무쌍한 세상에서는 불가능하다.
• 이에 반해 제품 지향적 관점에서는 최소 기능 제품MVP과 같은 린스타트업 Lean Startup의 접근 방식을 중요시한다. 리스크를 줄이는 것 외에도 점진적인 제품 지향적 접근 방식은 비즈니스가 정기적인 체크포인트에서 방향을 재설정할 수 있도록 해 선택 가치를 만들어낸다. 더 잦은 리뷰와 체크포인트는 비싼 관리 비용을 요구하기 때문에 추가비용이 발생한다. 하지만 소프트웨어의 복잡성과 시장이 바뀌는 속도를 고려하면 제품 생애 주기 전반에 걸쳐 추가 비용이 고루 퍼져 있는것이 낫다.
• 팀
• 프로젝트 지향적 관리에서는 리소스가 프로젝트에 할당된다. 이는 사람을 대체 가능한 소모품으로 보는 테일러리즘의 사고방식이다. 이러한 생각은 소프트웨어 전달이라는 가장 복잡한 지적 작업의 분야에서는 무의미하다.
• 개인별 IT 인력의 생산성 및 만족도에 대한 비용 위에 팀 비용이 더해져야 한다. 심리학자 브루스 터크만Bruce Tuckman은 복잡한 문제를 수행하는 팀이 경험하게 되는 형성기, 혼돈기, 규범기, 성취기의 발달주기를 제시했다. 인력을 재할당하는 것은 발달 주기를 방해해 더 많은 사람이 이동할수록 팀의 생산성에 드는 비용을 증가시킨다.
• 소프트웨어 전달과 같은 복잡한 지식 산업에 '일에 사람을 투입'하는 프로젝트 지향적 관리 접근은 적합하지 않다. 높은 성과를 내는 소프트웨어 조직은 이미 '사람에게 일을 전달' 하는 것의 효과를 잘 알고 있다.

• 경영진이 계속 프로젝트의 관점에서 사고하고 관리한다면 소프트웨어 전달의 반복적 특성과 프로젝트 및 포트폴리오 관리, 성과 가치 관리 등 프로젝트 관리 기법의 정적 특성 사이를 계속해서 매핑해야만 한다.
• 나중에는 결국 '수박' 현상으로 귀결된다. 만약 엔지니어링 책임자가 프로젝트 매니저로부터 '일이 잘 진행되고 있는가'라는 질문을 받는다면 대답은 '예' 일 것이다. 질문이 모호했기 때문이다. 그러나 릴리즈는 완료됐는데 비즈니스 목표와 일치하지 않았다면 이는 명백히 프로젝트가 제대로 진행되지 않는 것이다. 이 프로젝트는 겉보기에는 '녹색'인 것처럼 보이나 안쪽은 '빨간색인 것이다(마치 수박처럼), 문제는 프로젝트에 있는 것이 아니라 소프트웨어 전달의 복잡성과 역학 관계를 처리하도록 설계되지 못한 관리 패러다임에 있다.
• (좀 더 명확한 비즈니스 목표와, 더 명확한 비즈니스와 프로덕트의 연결)

• 만약 디지털 변혁이 비즈니스 결과가 아닌 애자일 프로세스나 활동에만 집중한다면 성공하지 못할 것이며, 무언가 잘못됐음을 비즈니스가 깨닫는 때는 너무 늦은 순간일 것이다.
• 제품 지향적 관리와 플로우 프레임워크로 전환하는 것이 소프트웨어 시대에 있어 성공을 보장하기에 충분한 것은 아니다. 조직은 소프트웨어 기반 제품을 시장에 전달하고 적응하기 위한 경영 문화와 시장에 대한 이해가 필요하다. 어떻게 더 많은 가치를 전달할지 고민하기 전에 소프트웨어 전달의 비즈니스 가치를 측정할 방법을 정의해야 한다. 그것이 플로우 프레임워크가 만들어진 이유다.
• (개발에만 국한되지 않은 전사적인 변화, 경영진의 이해, 시장/비즈니스에 대한 이해… 하나같이 정말 쉽지 않다)

3장 플로우 프레임워크 소개

• IT와 소프트웨어 전달 비용이 수년간 끊임없이 증가하고 있음에도 이제는 비즈니스의 가장 큰 비용 중 하나가 된 소프트웨어 전달에 대해 기업은 적절한 가시성을 갖지 못할뿐더러 제대로 이해하지도 못하고 있다... 따라서 기업의 많은 기술자는 애자일과 데브옵스 업무가 변혁에 필수임을 잘 알고 있으며 그것을 조직에 전파하려 노력하고 있다.
• 문제는 현대적인 소프트웨어 전달 접근 방식의 원칙들이 비즈니스로 옮겨지지 않는 것이다.

• 전체 공장의 구조는 생산 라인을 따라 현재와 잠재적인 미래의 생산흐름에 최적화돼 있다. 공장의 가치 흐름에서 다섯 개 관절은 가장 복잡한 부분이기 때문에 생산 라인 가치 흐름 구조의 주요 제약 조건 아래 흐름과 미래 확장성을 최대화하기 위해 건물이 이 관절을 중심으로 지어진 것이다.

• 플로우 프레임워크의 역할
• 플로우 프레임워크의 역할은 비즈니스 수준의 프레임워크와 변혁 이니셔티브를 기술 분야의 프레임워크와 이니셔티브로 연결하는 것이다.
• 소프트웨어 개발의 특이성을 무시하고 소프트웨어를 제조업처럼 관리해서는 안 된다. 또한 소프트웨어 전달의 개발, 운영, 고객 성공의 각 측면 중 어느 한쪽으로 지나치게 치우쳐서도 안된다.
• 새로운 프레임워크는 마치 제조 분야에서 관리 구성 요소로서 가치 흐름 지도, 기업 요구 사항 처리, 공급망 관리 등을 제공하는 것처럼 대규모 소프트웨어 전달을 위한 관리 방법을 캡슐화해야 한다.

• 가치 흐름: 제품이나 서비스를 통해 고객에게 가치를 전달하는 일련의 엔드 투 엔드 활동

• 소프트웨어 플로우: 소프트웨어 가치 흐름을 따라 비즈니스 가치를 생산하는 것과 관련된 활동
• 플로우 프레임워크는 엔드 투 엔드 가치 흐름과 비즈니스 결과의 상관관계에 집중한다
• 플로우 프레임워크는 플로우 지표를 추적하고 결과와 상호연관시키기 위해 활동 측정을 지양한다... 각 가치 흐름을 통해 얼마나 많은 비즈니스 가치가 흘러가는지와 어떤가치가 만들어지는지에만 집중한다.
• 플로우 프레임워크의 역할은 애자일과 데브옵스 기법에 대한 투자 결정을 돕고 기법들을 개선하는 데 필요한 지표를 제공한다.

• 비즈니스에서 생산성이 무엇인지에 대한 합의 없이 병목 지점이 무엇인지 합의하는 것은 불가능하다.
• 학계나 산업계 이론가들 사이에서 명확히 합의된 소프트웨어 생산성의 정의는 존재하지 않는다... 개발 활동과 결과를 연관시키는 방법은 훈련할 수 있는 활동이라기보다는 이해하기 어렵고 경험적인 기교에 가깝다. 가치 흐름에서 생산성을 정의하려면 가치 흐름 내부를 흐르는 것이 무엇인지부터 정의해야 한다.
• 고객이 가치를 끌어당기려면 가치가 무엇인지 고객 스스로 볼 수 있어야 하며 기꺼이 경제적 단위와 가치를 교환할 의사가 있어야 한다. 내부 제품의 경우 경제적 단위란 소프트웨어 채택이 될 수 있다. (예를 들어 서로 다른 사업부에서 공통 인증 시스템을 채택하는 경우), 외부 제품의 경우라면 매출이 경제적 단위에 해당할 수 있다. 또는 소셜 미디어 둘과 같이 간접적인 제품이나 광고 기반 수익 모델 제품의 경우 경제적 단위는 제품을 사용하는 시간이 될 수 있다. 정부나 비영리 조직이라면 새롭게 출시한 디지털 서비스 사용률이 경제적 단위가 될수 있다.
• 소프트웨어가치 흐름이 무엇인지 정의할 핵심이 여기에 있다. 우리가 창출해 내는 것이 새로운 기능 또는 결함 수정이라면 그것은 소프트웨어 가치흐름의 '플로우 아이템'이다.
• 플로우 아이템: 제품 가치 흐름을 통해 이해관계자가 끌어당기는 비즈니스 가치의 단위
• 즉, 가치 흐름 내의 모든 사람과 팀에 걸쳐 있는 작업을 플로우 아이템 중 하나로 특징지을 수 있다는 것이다.

• 각 플로우 아이템의 흐름이 소프트웨어 아키텍처를 형성해야 한다는 의미다. 많은 기업의 아키텍처가 형성된 방식처럼 아키텍처가 플로우 아이템을 형성하는 방향이어서는 안 된다.
• (개발만을 위한 활동이 아니라 비즈니스 가치를 실현하기 위한 변화, 개선이어야 한다. 내가 처음부터 강조하던 부분)

• 플로우 아이템 — 기능 결함 리스크 부채
• 어떠한 우발 상황을 지원하기 위해 소프트웨어 아키텍처에 집중하기보다 앞으로 다가올 사고를 제품 가치 흐름을 통해 예측하고 이를 위해 아키텍처를 최적화하는 데 집중해야 한다. 이는 사고 가능성을 최소화하는 복원력 있는 아키텍처를 만들고 예상치 못한 다른 사고에 신속히 대응할 수 있는 소프트웨어, 인프라, 가치 흐름 아키텍처를 생성해야 한다는 것을 의미한다.

2부 가치 흐름 지표

4장 플로우 지표 수집하기

• 가장 놀라운 것은 비즈니스와 생산 라인의 높은 통합 수준
• BMW 그룹 공장의 가치 흐름은 공장 흐름에 비즈니스 요구 사항을 바로 연결한 것이었다. 차량의 숫자와 각 차량이 전달되는 시간을 통해 가치가 명확히 정의됐다. 프로젝트로, 제품으로, 자동차로, 다시 비즈니스로 돌아가는 복잡한 수동 매핑 과정은 없었다. 일부 문제가 발생한 부분에 재작업이 필요할지라도 생산 라인의 모든 자동차는 결국고객에게 인도될 것이기에 생산 품질은 수리가 필요한 차량의 수를 헤아리는 것만으로 측정 가능했다. 재작업 자체도 가치 흐름을 흐르는 플로우의 또 다른 부분일 뿐이었다.
• 이는 속도만큼이나 품질 또한 가시화했다. 속도는 생산 라인에서 완성되는 자동차 수에 해당하며 재작업 영역은 품질 역시 투명하게 만들었다. 어떻게 하면 IT 분야에서 전달해야 할 네 가지 플로우 아이템에서 이 정도 수준의 가시성을 얻을 수 있을까?

• 플로우 분포의 트레이드오프를 고려하면 비즈니스는 소프트웨어 전달의 트레이드오프를 더 잘 이해할 수 있다. 이러한 사고방식은 거대 기술 기업의 CEO처럼 한때 소프트웨어 엔지니어였던 비즈니스 리더에게는 자연스러운 일이지만 플로우 프레임워크의 목적은 코딩과 소프트웨어 제품 관리에 익숙지 않은 모든 구성원이 이러한 의사 결정 방식을 쉽게 이해하도록 하는 것에 있다.
• 플로우 분포 트레이드오프라는 제로섬 게임은 계획되지 않은 작업이 가치 흐름에 들어왔을 때마다 개발 리더가 내려야 했던 다른 작업을 포기하는 결정을 비즈니스에게도 강제한다. 너무 많은 결함이 들어오면 기능 전달은 떨어져 나갈 것이다. 결함을 수정하면서 새 기능을 전달하라는 비즈니스의 압박이 몇 분기째 완화되지 않는다면 기술 부채 백로그의 증가로 새로운 기능 전달이 불가능한 지점에 도달할 수 있다. 팀의 백로그 내에 명시적으로 리스크의 우선순위를 조정하지 않는다면 고객이나 비즈니스에서는 잘 보이지 않는 위험 요소들은 절대로 해결되지 않을 것이다. 소프트웨어 전달 팀에서는 이를 알고 있겠지만 비즈니스 관계자들이 모르는 경우 의사 결정에 문제가 있어 보이는 것은 놀랄 일이 아니다.
• (계획에 없던 일, 혹은 갑작스러운 일, 버그가 sprint 중간에 들어오면 우선순위가 낮은 다른 일이 나가야 한다는 걸 이해하는 게 개발을 안 하는 사람들에게는 어렵거나, 혹은 그냥 이해하고 싶지 않은 걸로 보인다. 애초에 계획을 하길 싫어할지도 모르겠고)
• 균형 잡힌 플로우 분포를 보려면 각 플로우 아이템은 비슷한 수준의 작업 공수와 크기를 가져야 한다. 평균적으로 기능 구현 작업 소요시간이 결함 처리 작업 소요 시간의 4배라면 누적 막대그래프에는 결함 플로우가 기능 플로우보다 4배 더 큰 비중으로 표현될 것이다. 플로우 아이템의 점수는 비즈니스에 의미 있는 가치와 작업 단위를 캡슐화하기 때문에 본질적으로 잘못된 것은 아니다. 그러나 실제 상황에서는 이러한 왜곡이 비즈니스 이해관계자들에게 오해를 불러일으킬 수 있다.
• (그러면 이 부분도 결국은 이해를 해야 하지 않을까? 내가 너무 개발 중심적인 시각으로 보는 걸까? 하지만 결국 이걸 이해해야 흐름에 대해서 보다 정확하게 이해할 수 있는 거 아닌가?)

• 일간배포 횟수는 IT 및 조직의 성과와 상관관계가 있다. 이는 데브옵스기법을 적용하고 확장하려 시도하는 IT 조직에서 배포 자동화가 여전히 흔한 병목 지점임을 의미한다.
• (내 상황은 현재 이걸 하는 거도 너무 힘들다. 거기에 비즈니스쪽에서는 협조가 없으니 기술관련 주제를 보는 건 더 여력이 없고)
• 소프트웨어 시대의 전환점에 생겨난 많은 조직과 마찬가지로 태스크톱 또한 몇 년 전 '얼마나 많은 기능을 전달했는지', '얼마나 빠르게 고객 요청을 받아들이고 요구 사항을 전달했는지'와 같은 고객 관점의 생산성 지표가 필요함을 깨닫게 됐다. 그렇게 플로우 속도와 플로우 타임을 생각해 낸 것이다.
• 코드 라인 중심 지표는 다양한 가치 흐름에서 일어나는 작업의 세세한 측면의 이해에는 도움이 되지만 비즈니스 가치를 캡슐화하는 데는 적합하지 않다.
• (이건 너무 당연한 이야기. 20여년 전 유행했던 6 시그마를 소프트웨어에 적용하려던 게 생각난다)

• 플로우 아이템은 비즈니스 가치와 명시적으로 엮여 있다. 예를 들어 어떤 기능이 고객의 요구 사항과 끌어당김에 기반한 가치가 있는지 없는지 정의하는 것은 비즈니스 분석가와 제품 관리자의 역할이다. 결함, 리스크, 기술 부채 아이템도 마찬가지다. 플로우 아이템이 가치 흐름에 들어가기 전에 반드시 명시적으로 정의된 비즈니스 가치가 있어야 한다. 여기서 플로우 프레임워크는 어떻게 가치를 정의하는지에 대한 가이드는 제공하지 않는다(예를 들어 기능 채택이 되도록 설계하는 방법, 어떤 리스크를 먼저 해소해야 할지 결정하는 방법 등), 이것은 애자일 프레임워크와 제품 관리 프로세스의 역할이다. 이렇게 정의된 가치를 기반으로 플로우 프레임워크는 고객으로 향하는 가치 플로우를 측정해 시장과 빠른 피드백 루프를 구축하도록 한다.
• (결국 비즈니스는 비즈니스하는 쪽에서 정의해야 하는 부분. 기술과 결합하는 건 애자일, 개발 프로세스의 역할. 내가 매번 이야기하듯 같이 가야 한다. 한쪽만 움직이거나 변화해서는 절대 안된다)
• 애자일 프레임워크에서 이러한 측정값과 비즈니스 가치 순위는 작업의 우선순위를 정하고 계획하는 데 활용된다. 그러나 플로우 프레임워크는 작업 우선순위를 정하려는 것이 아니라 작업 흐름과 결과를 보여주는데 목적이 있다. 따라서 큰 수의 법칙 (충분히 많은 시행이나 사례가 주어지면 발생 가능성이 균일해진다는 법칙)에 따라 전체 결과를 측정할 때는 특정 플로우 아이템을 완료하기 위한 작업량이 균일한 분포를 따른다고 생각할 수 있다. 다시 말해 충분히 많은 수의 플로우 아이템이 있다면 특정 기간에 플로우 아이템이 몰리는 경우는 극히 드물다.
• (하지만 이렇게 하려면 결국 end to end의 비즈니스 가치 흐름을 먼저 파악해야 하고, 모든 걸 한 번에 할 수 없으니 그런 흐름들 중에서 우선 순위, 혹은 적용 효과를 알기 위해 간단한 거부터 하는 등의 플로우 프레임워크 적용에 대한 우선 순위는 필요하지 않을까?)

• 플로우 타임: 한 플로우 아이템이 가치 흐름에 들어온 때부터 활성 및 대기 시간을 포함해 완료되기까지 걸리는 시간.

• 플로우 부하: 하나의 가치 흐름 내에서 진행 중인 플로우 아이템의 개수, 즉 WP의 양.

5장 비즈니스 결과로 연결하기

• 가치 흐름의 완벽한 예시
• 시장과 비즈니스 요구가 변할 때 특정 제품에 좀 더 많은 투자가 이뤄질 수 있으며 가치 흐름 자체의 아키텍처는 확장될 수 있다.
• 소프트웨어의 전달도 제품, 시장 적합성과 확장성을 정확히 예측할 수 있다고 믿는게 아니라, 가치 흐름을 위한 성공 지표를 명확히 정의하고 적응성과 확장성을 고려한 가치 흐름을 만들어야 한다

• 각 가치 흐름에서 가장 중요한 지표는 객관적인 가치 측정
• 가치측정 지표는 조직에서 사용하는 재무 지표에서 직접 가져와야 한다.

• 생산성은 언제나 팀에서 수행하는 창조적 작업에 달려 있음을 기술 기업들은 오래전부터 잘 알고 있었다.
• 대니얼 핑크Daniel Pink를 비롯한 많은 사람이 행복하고 몰입된 직원이 창의적 업무에 참여했을 때 더 좋은 결과를 낳는다는 것을 보여줬다. 프로젝트 지향적 관리는 핑크가 정의한 업무 만족도의 핵심인 자율성, 숙련도, 목적의식을 방해하는 반면, 제품 지향적 방식이 제공하는 업무와 팀에 대한 안정감은 이를 고양시킨다.
• 개인 및 팀의 행복도와 생산성을 측정하고 개선해야 하는 것과 더불어 행복도를 추적하는 것은 가치 흐름 내 문제점을 드러나게 할 수도 있다. 예를 들어 행복하지 않은 직원의 존재는 지루한 수작업을 초래하는 자동화의 부족, 또는 새로운 기능 개발을 힘들게 하는 복잡한 아키텍처와 같은 생산 과정의 문제점을 알리는 중요한 지표가 될 수 있다. 성과가 좋은 조직은 이미 eNPS(직원 추천 지수)와 같은 지표를 통해 직원 참여도를 측정한다. 액셀러레이트 Accelerate는 IT 조직에서 좋은 성과를 내는 조직의 직원이 그들의 조직을 일하기 좋은 곳으로 추천하는 경향이 2.2배 더 높음을 발표했다.
• (직원의 행복도가 가치 흐름을 방해할 수 있다는 이야기)

6장 파괴 추적

• 엔드 투 엔드 플로우 사고방식으로 시작해 플로우 타임과 플로우 속도를 향상하기 위해 각 단계와 순서를 지속적으로 최적화하고 있다.
• (end to end에 대해서는 PO들에게 처음부터 지속적으로 전달은 하고 있지만, 내 전달력이 문제인지 아니면 다른 문제가 있는지 여전히 만족스러운 flow를 받지 못했다)

• 자동차 산업 전반적으로 다른 플로우 아이템보다 기능에 우선순위를 높게 부여한 트레이드오프로서 지금의 품질 저하가 나타난 것이다.
• (트레이드오프로 품질이 아니라 기능에 우선순위를 둘 수도 있지만, 이건 품질 문제가 일어나도 성장에 문제가 없는 경우, 예를 들어 초기 인터넷 기업같이 결국 성공하는 경우에나 문제가 없다. 즉 이런 트레이드오프는 예상되는 비즈니스 결과를 염두에 두고 이뤄져야 한다)

• 기술 기업의 CEO가 일상 업무 과정에서 발생한 실수에 대한 책임을 개별 구성원에게 돌리는 것은 양심적이지 못한 일이다.
• (기업의 종류와 무관하게 당연히 CEO라면 그러면 안 되는 거 아닌가?)

• 플로우 분포의 중요한 측면 중 하나는 소프트웨어 전달 팀부터 비즈니스 전략에 이르기까지 수직으로 연결한다는 점이다. 이를 통해 어떤 하나의 가치에 대해 플로우 분포를 측정하거나, 전체 조직의 가치 흐름에 걸쳐 결합된 플로우 분포의 영향도를 분석할 수 있다.
• (그래서 end to end의 흐름에서 문제가 되는 부분을 파악하고 대처를 해야 한다는 뜻)

• 기술 부채란 말 그대로 기술 및 인프라에 관련된 부채는 물론, 자동화 부족 등 개발자의 생산성과 작업 흐름에 영향을 주는 가치 흐름 네트워크 자체에 축적된 부채까지 포함한다.

• 한 엔지니어에게 책임을 뒤집어씌우는 행동은 비난하는 문화에서 만들어진다. 비난하는 문화는 전환점이라는 어려움을 헤쳐나가는 데 필수적인 위험 부담과 변화를 어렵게 한다. 이미 성숙한 생산 시스템에 비춰봤을 때 고위 경영진에서 행해지는 비난은 말도 안 되는 일이다. 어떤한 명의 직원이 내린 결정이나 실수가 백 년 이상 된 기업을 무너뜨릴수는 없기 때문이다.

• 노키아: 요구를 더는 들어줄 수 없을정도로 기술 부채가 쌓이기 전까지 기술 부채에 우선순위를 할당하는 것은 비즈니스의 안중에 없었다.

• 플로우 프레임워크 관점에서 게이츠의 이러한 의사 결정들을 바라보면 그는 먼저 리스크에 집중한 뒤 기술 부채에 집중하도록 조직에 방향성을 제공했다는 것을 알 수 있다. 또한 그 눈금들이 10까지 올라갔다는 것은 기능 전달의 눈금이 곧 0으로 낮춰짐을 의미한다는 것을 그가 잘 인식하고 있었음을 보여준다. 플로우 프레임워크를 사용해 빌 게이츠와 찰스 시모니의 지난 의사 결정들을 소급해 분석할 수야 있겠지만 이들은 당시 이 프레임워크가 필요하지 않았다. 이들 모두 IT와 소프트웨어 전달을 제대로 이해하는 데 필요한 프로그래밍 및 제품에 대한 직무적 경험이 있었다. 지금의 마이크로소프트를 클라우드의 시대로 끌어가는 CEO 사티아 나델라Satya Nadella 도 마찬가지다... 소프트웨어 시대에서 부를 경제 전반에 공유하기 위해서는 전략적 의사 결정 프레임워크가 모든 비즈니스 리더에게 필요하다는 것을 깨달은 때였다.
• (앤더슨 하일스버그가 MS로 갔던 걸 이렇게 해석할 수도 있구나)

3부 가치 흐름 네트워크

7장 기업 툴 네트워크의 실측 정보

• 문제는 소프트웨어 전달의 시각화가 가능하냐는 것이 아니라 어떻게 하면 비즈니스에 의미 있는 시각화와 데이터 모델링을 수행할 수 있는가에 있다.
• (하지만 소프트웨어 전달, 전달의 시각화도 쉬운 일은 아니다)

• (RSI의 아픔은 나도 겪어봐서 잘 안다. 거의 15년 전이지만 치료받으러 이런 저런 병원을 다니던 기억이 나는데 결국 버티컬 마우스를 쓰면서 어느 정도 벗어날 수 있었다)

• 소프트웨어 아키텍처의 핵심은 코드 변경 사항을 지역화하는 것이다. 나쁜 아키텍처는 새로운 기능을 추가하거나 결함을 고칠 때 지역화됐어야 하는 여러 위치의 코드를 변경해야 한다. PARC의 우리팀에서 진행한 것이 바로 횡단 변경 사항을 지역화하기 위한 관점 지향 프로그래밍 언어였지만 모순적이게도 해당 언어를 위한 작업은 내게 별 도움이 되지 않았다. 백로그에 등록되는 업무와 아키텍처 사이에 깊은 불일치가 있었고 더 나은 프로그래밍 언어가 이를 해결할 수 있을지 확신할 수 없었다.
• (백로그에 등록되는 업무, 즉 비즈니스 기능 구현과 프로그래밍 아키텍처 사이에 불일치가 발생하고 항상 비즈니스 — 개발진 사이에 발생하는 내가 원하는 거 아닌데? vs. 네가 원하는 거 만든 건데? 의 문제가 발생한다)

• 첫 번째 깨달음: 소프트웨어의 규모가 커짐에 따라 소프트웨어 생산성이 감소하고 스래싱이 증가하는 것은 아키텍처와 가치 흐름 사이의 단절 때문이다.

• 운영 인프라와 배포 자동화 및 통합 관리 방법의 부족은 소프트웨어 아키텍처뿐만 아니라 운영 인프라 또한 가치 흐름과 단절돼 있었다는것을 의미했다. 이번 관찰을 통해 프로젝트 관리 모델, 엔드 투 엔드전달 아키텍처 그리고 가치 흐름 사이의 단절이 소프트웨어 생산성의병목 지점이 된다는 두 번째 깨달음을 얻게 됐다.
• 두 번째 깨달음: 단절된 소프트웨어 가치 흐름은 소프트웨어 생산성의 병목 지점이다. 이러한 가치 흐름 단절의 원인은 프로젝트 관리 모델의 잘못된 사용에 있다.

8장 전문화된 불과 가치 흐름

• 가치 흐름 아키텍처 관점에서 두 가지 유형의 복잡성 모두 신경써야만 한다. 일종의 가치 흐름 부채로 볼 수 있는 우연적 복잡성은 지속적 노력으로 줄여 나가야 한다... 더욱 문제가 되는 경우는 조직이 우연적 복잡성과 근본적 복잡성을 구분하지 못할 때다.
• 우연적 복잡성: 비즈니스 가치 플로우 개선과 무관하게 발생한 툴의 이질성. e.g. 인수 합병의 결과로 넘겨받는 툴, 혹은 중앙 집중형 관리가 부족해 비슷한 툴을 팀별로 선택하는 경우
• 근본적 복잡성: 비즈니스 가치 플로우 개선을 위해 전문성을 갖춘 이해관계자의 요구 사항을 수용하면서 발생한 툴의 이질성. e.g. java를 사용하면 jira를, .net이나 azure를 쓰면 vsts를 issue tracker로 더 사용

• 이러한 툴의 폭발적인 증가는 매우 활발한 시장을 형성했지만 툴들을 연결해 줄 인프라 계층 없이는 기술 대기업이 경험한 소프트웨어 전달 효율을 경험할 수 없다. 자체 툴을 만들고 통합하려는 시도는 위험하고 실패하기 쉬운 접근 방식이다. 툴을 만드는 데 비용과 시간이 소모될 뿐만 아니라 일반적으로 우선시되는 비즈니스 애플리케이션과 예산 및 인력을 할당받기 위한 내부 경쟁을 해야 하기 때문이다.
• 그렇다면 스타트업과 소규모 조직에서는 어떨까? 이에 대한 확실한 데이터를 찾기는 힘들지만 스타트업에서 일했던 개인적 경험에 의하면 소프트웨어 전달에 관련된 구성원이 100명 미만일 때 문제가 훨씬 쉬워진다. 규모 요인(표 8.1)이 훨씬 더 작을 뿐 아니라 직원 및 프로세스의 수도 훨씬 적기 때문에 스타트업은 중앙화된 툴 하나만을 사용하는 단순화된 툴 네트워크에서 많은 부분 성장이 가능하다. 이렇게 하면 소프트웨어 전달을 더 간단한 비즈니스 관리 시스템에 연결하기가 쉬워진다. 결과적으로 스타트업은 고도로 집중된 디지털 제품을 활용해 기존 기업을 파괴하기 충분한 속도로 혁신을 이룰 수 있다. 그러나 스타트업 규모가 커져 큰 기업이 되면 툴의 이질성이 드러나기 시작한다. 페레스의 모델이 예측하는 활용기의 황금기를 맞이하려면 기술 거대 기업의 소프트웨어 전달 능력과 경쟁할 수 있는 혁신적인 인프라가 기성 기업과 신규 기업 모두에게 필요하다.

9장 가치 흐름 관리

• 병목 지점이 발생했을 때 생산이 중단되지는 않았으며 제약 조건을 피해 우회하는 방법을 찾아내 문제를 해결할 수 있었다. 각 팀은 맞닥뜨린 제약 조건을 창의적으로 해결하는 새로운 길을 생각해 낸 것이다.생산성은 다소 저하될 수 있지만 팀은 항상 플로우를 보장하는 작업경로 변경을 해낼 수 있었다.
• (속도가 저하되더라도 flow가 끊기면 안된다는 의미인가?, 속도가 느려도 우선 정확하게 구현해야 한다는 거와 일맥상통하는 부분일까?)
• ...우리의 가치 흐름을 통해 흘러가는 모든 내부 전달 아티팩트를 시각화하는 문제였다. 나는 그들의 작업에 대한 피드백에서 생산 라인이나 가치 흐름 지도를 연상할 수 있게 제조업에 빗댄 개념을 사용할 것을 계속 요구했었다.
• (결국 end to end business flow 파악)

• 제조업적 관점을 지나치게 적용하고 잘못된 멘탈 모델을 계속 따르는 것을 피하려면 소프트웨어 개발의 반복적이며 네트워크 기반인 가치 흐름을 관리하는 것과 제조업의 선형적 가치 흐름을 관리하는 것 사이의 핵심적인 차이를 확실하게 정의해야 한다.
• 가변성: 제조업에서는 가변성을 최소화해야 하지만 소프트웨어 개발에서는 소프트웨어 기능의 디자인은 얼마든지 조정할 수 있다.
• 반복성: 제조업이란 제품에 대한 생산량을 최대로 하는 것을 목표로 한다. 반면에 소프트웨어란 반복과 피드백을 최대화하고 계속해서 제품을 개선하는 것에 목표가 있다. 소프트웨어 전달의 단계마다 신뢰성 있는 배포 자동화와 같은 반복성이 필요하며 엔드 투 엔드 프로세스를 위해서는 반복성뿐만 아닌 플로우, 피드백, 지속적 학습을 최적화해야 한다.
• 설계 빈도: 자동차와 같은 제조 생산품은 수년에 걸친 프로젝트 중심 주기에 따라 설계된다. 생산 라인 자체의 변경을 요구하는 설계 변경은 그만큼 자주 일어나지 않는다. 소프트웨어에서는 제품 지향적 방식으로 기능을 전달하므로 가치흐름을 흐르는 플로우 아이템의 비율에 따라 설계 빈도가증가한다. 이때 설계는 외부가 아닌 내부, 즉 생산 시스템에서 일어난다.
• 창의성: 제조 프로세스는 최대한 많은 자동화를 목표로 한다. 이는 창의적이거나 결정되지 않은 작업을 생산 프로세스에서 제거하기 위함이다. 이와 반대로 소프트웨어 전달은 각단계에서 창의성과 협업을 가능하게 하는 것에 초점을 맞추며 창의성을 지원하기 위해 자동화를 활용한다.
• 가치 흐름 네트워크가 충분한 연결성이 없다면 특정 단계를 최적화하는 의미가 있을까? 여러가지 프로젝트 관리 툴을 사용하는 가운데 정형화된 피드백 루프가 아무것도 없다고 가정하자. 이런 경우 지속적 전달에 수백만 달러를 투자한들 측정 가능한 비즈니스 결과를 끌어낼수 있을까? 질문에 답을 하려면 가치 흐름 네트워크를 측정하고 가시화할 수 있어야 한다.
• 소프트웨어 전달을 선형의 제조 프로세스로 보는 관점을 계속 유지한다면 우리는 비행기가 없던 시절에 머무르게 될 것이다.
• (제조업 형태의 프로세스라도 갖추는 게 좋을까? 아니면 차라리 이런 프로세스는 없는 게 좋을까?)

• 대규모 조직이라면 통합 모델을 통해 툴 네트워크를 연결하는 효과 자체만으로도 혁신적일 것이다. 예를 들어 한 보험 회사에서 품질관리 툴과 개발자 툴을 서로 연결했을 때 해당 분기에 직원 조사에서 참여도가 22% 증가했음을 확인할 수 있었다. 이러한 개선은 중복 데이터 입력을 비롯해 단절로 발생한 마찰이 줄었기 때문으로 분석됐다.
• (결국 모든 도구를 통합해서 하나로 사용해야 하는 걸까?)

• 추적 가능성 지수: 아티팩트 유형에 따른 아티팩트 연결의 너비와 깊이.
• 추적 가능성 지수는 툴 네트워크 아티팩트에서 통합 모델로 향하는 매핑에 기반하므로 가치 흐름 네트워크의 자동화된 추적성의 규모를 나타내기도 한다. 요구 사항, 관련 코드 변경, 테스트 케이스 사이에 자동화된 추적성이 설정되지 않았다면 단절된 아티팩트의 추적 가능성 지수는 낮게 나타날 것이다. 관리, 규제, 규정 준수 등을 위해 추적 자동화는 가치 흐름 네트워크의 필수 요소이며 추적 가능성 지수는 추적 자동화 수준을 나타낸다.

• 정렬 지수: 둘 네트워크 전체의 모든 아티팩트 컨테이너 대비 제품 가치 흐름에 연결된 아티팩트 컨테이너 비율.
• 도미니카 드그란디스의 업무 시각화에서 '시간 도둑'으로 정의된 내용이다. 드그란디스는 개인, 팀, 조직에 영향을 주는 다섯 가지 유형의 시간 도둑에 대해 설명한다. 칸반 보드가 팀 수준에서 작업을 가시화하는 것처럼 가치 흐름 네트워크 및 관련 지표들은 조직 차원에서 작업을 가시화하여 팀의 적절한 대응과 투자를 끌어낸다.

1. 과다한 WIP

• 너무 많은 WIP가 가치 흐름에 있으면 대기열이 생기고 전달 속도가 떨어진다. 플로우 부하는 각 가치 흐름에 있는 WIP의 양을 측정한다. 더 중요한 것은 플로우 부하의 증가가 플로우 속도와 플로우 타임에 주는 영향을 확인할 수 있으며 비즈니스 결과에 주는 영향을 확인하기 위해 이들 지표의 상관관계를 분석할 수 있다는 점이다. 경험 많은 제품 및 엔지니어링 전문가는 WIP가 많으면 속도가 늦어진다는 사실을 잘 알지만 비즈니스 요구를 무시하기에는 어려움이 따른다. 플로우 프레임워크는 각 가치 흐름의 플로우 지표를 드러냄으로써 플로우 속도를 높이려면 플로우 부하를 낮추도록 데이터 중심 비즈니스 운영을 활성화한다.
• 서로 다른 가치 흐름은 플로우 부하에 대해 서로 다른 저항력을 가진다. 예를 들어 불충분한 아키텍처 위에서 성공적인 제품을 만들어야 한다면 끌어당겨질 기능을 구현하기 위해 개발자가 끊임없이 새로운 아키텍처 요소를 덧댈 필요가 있고 예상치 못한 많은 작업을 야기한다. 이런 경우 플로우 부하에 대한 가치 흐름의 저항력이 낮을 것이며, 좋은 아키텍처가 있었다면 플로우 부하에 대한 저항력이 높을 것이다. 가치 흐름 네트워크는 각 가치 흐름에 제한할 일반적인 WIP의 수를 상정하는 것이 아닌, 시간 경과에 따라 플로우 부하를 결정하고 조정할 수 있도록 데이터를 제공한다. 

2. 알려지지 않은 종속성

• 소프트웨어 전달에서 관리가 가장 어려운 것 중 하나는 팀, 구성 요소, 제품 간 종속성이다. 드그란디스는 아키텍처, 전문 지식, 활동 기반이라는 세 가지 종속성을 정의한다. 각각의 종속성은 아티팩트 네트워크에서 분명하게 드러난다. 예를 들어 한 제품 팀이 다른 팀에 API 기능을 반복적으로 요청한다면 이에 상응되는 아티팩트 관계는 두 팀 간 아키텍처 종속성으로 아티팩트 네트워크에 명확히 드러날것이다. 또한 협업 툴에서 코드 리뷰 또는 비슷한 리뷰 메커니즘은 아티팩트 네트워크 내 전문 지식 종속성으로서 드러나기도 한다. 이러한 정보를 활용해 가치 흐름 간 종속성을 모델링하고 이를 해결할 방법을 찾아볼 수 있다. 예를 들어 특정 공통 기능 종속성이 있는 여러고객향 제품 가치 흐름에 초점을 맞추는 플랫폼 가치 흐름을 만듦으로써 이를 확인할 수 있다.
• 가치 흐름 네트워크를 조사해 본 결과, 병목 지점은 개발 처리 능력의 부족에 있었던 것이 아니라 개발자들이 디자이너가 만드는 와이어프레임이 나오기를 기다리는 상황이었던 것을 알게 됐다. 하지만 개발자들은 가만히 앉아있지 못하고 자체 UX를 만들어 붙였다. 제품 팀과 고객의 기대를 만족시키기 위해 이렇게 만들어진 데모는 더 쉽고 제대로 된 UX를 위한 재작업으로 이어질 수밖에 없었다. 이러한 플로우 속도 문제와 이를 유발한 재작업으로 개발자를 더 고용하는 것이 아니라 전담 UX 전문가를 고용해 UX 디자인을 내재화하는 것이 정답임을 깨달았다. 핵심 플랫폼과 SDK 컴포넌트에 의존하는 가치 흐름을 지원할 인력이 충분치않은 경우에도 유사한 병목 지점이 발견됐다. 구성원, 팀 그리고 가치흐름이 많아질수록 가치 흐름과 종속성을 가시화할 방법이 없다면 종속성 문제의 원인을 찾는 것은 더욱 어려워진다.
• (이 부분이 내가 지적하는 부분. 개발 지연의 원인이 개발이 아니라는 걸 분명히 설명하지만 가시적으로 드러낼 수는 없으니, 반복적으로 이야기해야 하고 그러다보니 나도 지치고 힘들고 짜증이 난다)

3. 계획되지 않은 작업

• 계획되지 않은 작업은 소프트웨어 전달 일정에 예측 불가능성을 추가하는 원인 중 하나로 지목된다. 조직과 가치 흐름에 따라 계획되지 않은 작업의 양은 다양할 수 있으며, 가치 흐름 네트워크는 모든 작업을 가시화한다. 기능 및 리스크 작업은 비즈니스의 참여 아래 계획되기 때문에 가치 흐름이 시작할 시점부터 계획해 들어가는 편이다. 이와는 대조적으로 심각성이 높은 사고 또는 최근에 출시된 제품을 지원하는 티켓은 개발 팀 백로그에 결함으로 등록되며 짧은 플로우 타임안에 처리돼야 한다. 이러한 활동은 해당 팀의 플로우 분포에서 즉각적으로 확인 가능하며 플로우 분포의 예상치를 조절해 계획되지 않은작업의 원인을 식별하는 데 집중할 수 있다. 이는 초기 릴리즈부터 축적된 기술 부채나 인프라 부채를 줄이는 것과 같은 작업일 수 있다.
• (결국 비즈니스가 전체 흐름에서 포함이 되어야 함)

4. 우선순위 충돌

• 플로우 프레임워크는 플로우 아이템 수준에서 충돌하는 우선순위를 표면으로 드러나게 한다. 예를 들어 플로우 프레임워크는 기능, 결함,리스크, 기술 부채 각각에 얼마나 커다란 노력을 기울일 것인가를 이해관계자에게 명확히 결정하도록 강제한다. 또한 플로우 프레임워크는 조직이 고차원의 비즈니스 우선순위를 제품별로 나눠 비즈니스 목표 및 결과에 기반한 우선순위를 설정할 수 있게 한다. 그러나 가치흐름 안에서의 작업 및 우선순위 결정(예를 들어 어떤 기능을 먼저 릴리즈할지에 대한 결정 등)은 플로우 프레임워크보다 하위 차원의 플래닝 프레임워크(SAFe, 스크럼 등)에서 이뤄져야 한다.

5. 방치된 작업

• 기술 부채는 플로우 프레임워크에서 중요한 부분으로 방치된 작업에 시간을 할당하게 한다. 또한 제품 모델을 정의하는 과정에서는 정렬 지수를 통해 모든 좀비 프로젝트를 드러나게 한다.

• 플로우 프레임워크는 비즈니스 리더와 기술자가 한데 모여 디지털 비즈니스를 관리하기 위한 공통의 언어와 성공 기준을 만들어내기 위해 일련의 공유 지표에 대한 합의가 필요하다. 이를 위해서는 비즈니스 계획 및 관리 시스템을 소프트웨어 전달 툴과 통합해 통일된 피드백 루프를 생성해야 한다. 이러한 새로운 인프라를 만들고 관리하려면 조직에 가치 흐름 설계자가 필요하다. 이는 제품 기반의 비즈니스 결과를 전달하기 위한 가치 흐름에서 작업을 하는 팀으로 하여금 권한과 책임 모두 필요하게 만든다. 무엇보다 예산 편성 및 비즈니스 관리 방법을 프로젝트에서 제품으로 전환하는 것이 중요하다. 전환이자리 잡게 되면 그 결과로 구성되는 가치 흐름 네트워크는 빠른 속도로 변화하는 시장 및 고객 행동에 대응할 수 있는 가시성을 사람과 발전하는 인공 지능 모두에 제공할 것이다.
• 반면 프로젝트 중심적이며 비용 중심적인 사고방식에 머물러 있는 이들은 경제의 나머지 부분마저 소프트웨어 시대로전환되면서 점점 더 소외될 것이다.

맺음말 전환점을 넘어서

• PARC의 뛰어난 구성원들은 소프트웨어 시대가 어떻게 펼쳐질지에 대한 명확한 비전이있었기에 더 큰 좌절을 경험했다. 연구진과 기술자는 무엇을 해야 이시대에 승리할 수 있는지 잘 이해하고 있었지만, 제록스의 경영진은 이전 시대의 경영 모델에 갇혀 있었고 이에 관한 책 『Fumbling the Future(iUniverse. 1999)의 제목처럼 미래를 놓쳐 버리고 말았다.
• 하지만 경영진 역시 파괴 속에서 항해를 계속하기 위해 나름대로 최선을 다했다는 것을 알기에 그들을 비난할 수만은 없다. 그저 잘못된 경영 시스템을 사용했을 뿐이다. 이러한 사례를 통해 오늘날 기업이 배우는 점이 없다면 제록스와 같은 일을 겪는 회사는 늘어나게 될것이다.
• 개인적으로 플로우 프레임워크가 비즈니스를 황금기로 이끌 수있는 새롭고 효율적인 방법이라고 생각한다. 플로우 프레임워크는 엔드 투 엔드 플로우를 지원하기 위해 둘 네트워크를 연결하고 엔드 투 엔드 추적 가능성을 제공하는 아티팩트 네트워크를 생성하며 프로젝트에서 제품으로 전환을 가능하게 하는 가치 흐름 네트워크를 만드는 방법을 제공한다. 플로우 지표는 소프트웨어 투자 결정이 어떤 비즈니스 결과를 수반할지 추적하는 방법을 제공하며 병목 지점을 찾아내투자할 수 있는 조직을 만들어 준다.
• 이 책은 절대 모든 것을 담아내지 못한다. 다른 새로운 개념들처럼 각 조직에 적용하려면 구체적인 것들을 고려해야 한다. 예를 들어 플로우 프레임워크의 비즈니스 결과는 각 조직에 맞도록 커스터마이징해야 한다. 앞서 언급했듯 플로우 프레임워크는 일반적인 디지털혁신을 위한 플로우와 피드백 루프를 활성화하는 데 목적이 있다. 훌륭한 소프트웨어를 만들기 위한 전략이나 설계 측면에서는 별 도움이되지 않는다. 또한 이 책은 가치 흐름 네트워크를 만들고 관리할 가치흐름 설계자와 다른 실무자들에게 필요한 기술적인 세부 내용이 부족하다.
• 플로우 지표 자체는 가치 흐름 네트워크를 가시화하는 시작점일 뿐이다. 병목 지점과 최적화할 영역을 찾아내는 데 도움을 줄 실시간 시계열 재생 등 풍부한 시각화를 실현할 수 있다. 나는 이러한 시각화 작업을 하면서 완전히 연결된 가치 흐름 네트워크가 주는 가장 중요한 가치는 소프트웨어 전달에 대한 명확하고 통일된 데이터 모델이라는 것을 깨달았다.