김창준님의 블로그에서 "애자일 도입에 대한 팀장과 사장의 대화"라는 글을 보고 몇가지 적어 보도록 하겠습니다.
물론 김창준님 글의 의도는 "효과적인 커뮤니케이션 방법" 이지만 제시한 예시는 현실과 조금 동떨어졌다는 생각이 들었습니다. 커뮤니케이션 방식을 개선 함으로서 일단 서로가 같은 눈높이에서 대화 나눌 수 있도록 도와 줍니다만 고질적인 개발자/기획자 혹은 개발자/사장님 간의 괴리감을 해소하기 위해서는 서로에 대한 진정한 이해가 필요하다고 봅니다.
대부분의 사장들은 개발자들이 회사의 전체적인 현황에 대하여 고려하지 않은채 이런 저런 현실성 없는 제안을 하고 있다는 생각을 해서 대화가 비생산적인 방향으로 흘러가는 경우가 많습니다. 개발자이지만 재무/마케팅/기획 등 모든 분야를 포괄하여 이해하고 있거나 이해하고자 한다는 것을 보여줘야 합니다.
김창준님이 포스팅해주신 개발자가 사장님에게 애자일 도입으로 업무 프로세스 개선을 제안하는 시나리오를 들어 설명하겠습니다.
** 포인트: 장기적으로 업무 효율을 증진하기 위해 업무 프로세스 개선하는 것이 좋다는 것은 팀장이나 사장이나 서로 동의할 수 있는 내용인 것 같습니다.
팀장과 사장이 함께 고려해야 할 것은 현재 회사의 사정상 당장 애자일을 도입하여 프로세스 개선을 시도하기에는 적절한 시기인가? 아니면 상황을 보아 가면서 좀 더 치밀한 전략으로 서서히 도입을 해야 하는가? 에 대한 것이라고 생각합니다.
** 변수 1: 현재 회사의 재정상태는 어떠한가?
현재 사업이 안정적이지 못하거나 현금 흐름이 좋지 않은 경우 경영진에서는 무리한 risk 를 지는 것을 꺼려합니다. 당연한 것이죠. 애자일이 제대로 정착이 되기도 전에 회사가 문을 닫을지도 모른다는 것에 대한 생각도 함으로 더욱 신중할 수 밖에 없습니다.
** 변수 2: 회사와 함께 얽혀 있는 주주들과 채권자들은 어떤가?
당장 현금을 더 투자할 계획이 있고 회사의 변화에 적극적이면 다양한 실험이 가능합니다. 하지만 주주들과 채권자들이 넣은 현금을 회수하고 빠질 계획을 세우는 상황이라면 역시 사업상 큰 risk 를 지고 가는 것은 전략적으로 좋은 생각이 아닐겁니다.
** 변수 3: 마케팅 전략은 어떤가? 시장의 특성은 어떤가?
개발을 하고 나서 팔아야 하는 쪽이 마케팅입니다. 하지만 애자일을 도입함으로서 마케팅 전략과 충돌할 가능성도 있습니다. 시장의 특성상 판매/오픈 타이밍이 중요한 경우 더욱 그렇습니다. 예측 가능한 효율적인 개발 프로세스로 뛰어난 서비스가 탄생하더라도 시기를 놓쳐서 결국 팔아 먹지 못하는 상황이 되었다면 애자일을 도입한 것에 대한 이득보다는 손해가 많아지겠죠.
** 변수 4: 협력 업체 / 납품 업체와의 상황은 어떤가?
외부 업체와 긴밀하게 협력을 하는 경우라면 약속한 데드라인과 예측가능한 타임라인을 제시하는 것이 매우 중요합니다. 회사 내부의 공감대가 형성이 되어 애자일 도입에 대한 risk 를 감당할 준비가되어 있다고 해서 외부 협력 업체들이 항상 반기는 것은 아니죠. 이런 경우 외부 업체를 설득하는 것에 대한 비용도 발생하게 되겠죠. 애자일 도입으로 인해 외부 협력 업체와의 관계가 회손된다면 역시 도입에 대한 이득보다는 손해가 커질 수가 있겠죠.
더 많은 예시들이 있겠지만 이쯤으로 요약을 하겠습니다. 중요한 포인트는 개발파트가 회사에서 독립적인 엔티티가 아니라 회사의 핵심 기관중 하나라는 것입니다. 개발 업무 프로세스를 개선한다고 해서 꼭 회사의 전체적인 업무프로세스가 개선되는 것은 아니라는 점, 그리고 항상 현금 흐름 개선으로 연결되지 않는다는 점이 중요하겠죠.
회사는 돈을 버는 기계이고 회사가 돈을 벌지 않으면 문을 닫아야 합니다. 그리고 이것은 모든 사장님의 뇌아리 속에 아주 깊이 박혀 있죠. 기존에 하던 방식이 아닌 다른 방식으로 해보는 것은 risk 입니다. 회사가 Risk를 지는 경우는 실패 했을때 그 실패를 만회할 만한 어떤 "담보"가 있거나 더이상 잃을 것이 없는 막장(?)인 경우일 것입니다. 그렇지 않은 경우 업무 프로세스가 조금 비효율적이더라도 들어오는 현금이 안정적으로 들어오고 직원들 월급 주고 회사 굴리는 것이 사장입장에서 좋은 것이겠죠.
물론 제일 좋은 것은 사장이 팀장에게 회사의 전체적인 상황을 이해시키고 애자일 도입에 대한 계획을 수립할때 고려해야 할 회사 내/외부의 다양한 이해관계자들과 risk에 대한 분석을 포함시킬 수 있도록 도와주는 것입니다. 이런 risk assessment 가 완벽하게 나와야 risk 가 감당할만 한지에 대한 올바른 평가가 나오고 경영진을 설득하는데 성공적일 것 같습니다.
개발자들은 우리 팀이 조금 더 일을 효율적으로 하고 개인 적인 스트레스를 줄이는 차원의 업무 프로세스 개선이 아니라 전사적으로 바라보아야 합니다. 사장은 "업무 프로세스 개선이 회사가 돈을 더 벌어 들이는데 도움이 되는가?" "얼마나 도움이 되는가? 도입함으로서 올해 혹은 내년의 매출이 얼마나 성장 할 수 있는가?" "재무제표에 반영이 될 수 있는 가?" "주주들을 만족시킬 수 있는 결과를 보여줄 수 있는가?" 와 같은 질문에 대한 해답을 원하는 것이고 그것을 제공하는 것이 바로 CIO 입니다.
개발자들은 단순 코더의 위치에서 벗어나 CIO의 눈으로 회사를 바라보아야 합니다.