Lazy Developer

품질에 투자한다.

Whitepaper에도 언급하고 있지만, 절대적으로 완벽한 품질이란 있을 수가 없다. 품질이란 계속해서 쌓아가는 것, 발전해 나가는 것이다. 그러므로, 품질은 프로젝트의 모든 과정에서 고려되어야 한다. 즉, 일단 돌아가게 만든 다음에, 품질을 높인다..라는 어프로치는 안 된다.

MSF에서는 퀄리티 추구를 위해서 두 가지 - 테스팅 팀을 중시하는 팀 모델, 개발자들의 Readiness 관리를 위한 교육 모델 - 를 제안한다. 말은 쉽지만 이 두가지가 모두 잘 되는 프로젝트는 현실적으로 찾기 힘들다. 여러 가지 이유 - 예산의 문제, 일정의 문제 등등 - 로 인해서 소홀해지기 쉬운 부분이기 때문이다. 하지만 결국 이런 부분을 소홀히 했을 때, 결과적으로 퀄리티는 당연히 떨어지기 마련이다.

Focus on delivering business value

비즈니스 가치에 초점을 맞춰야 한다.

사실 내가 그동안 해왔던 Enterprise SI에서는 이 부분이 부족하다고 말할 수 있다. 고객이 원하는 소프트웨어를 거기에서 만들어주는 일이 대부분이기 때문에, 당연히 일을 하는 만큼 어느 정도 돈은 나올테니까.

하지만, 솔루션을 만들어서 시장에 내놓는 일을 하는 업체, 혹은 최근에 많은 웹기반의 일반 사용자용 소프트웨어(웹 2.0이라고 해야 하나?)를 만드는 업체라면 이 부분은 아주 중요하다. 즉, 시장에서 팔릴 수 있는 것, 고객이 돈을 내고 살만한 것을 만들어야 할 것이다. 이런 비즈니스적인 결과가 따라오지 못한다면 개발자나 기획자 등의 동기부여도 잘 안 될 것이고, 틀림없이 결과도 좋지 못할 것이다.

Establish clear accountability and shared responsibility

팀(개인)의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다.

이 원칙을 지키지 못했을 경우에 가장 문제가 될 수 있는 것은 MSF White Paper에서도 지적하고 있듯이, 작업의 중복으로 인한 과잉 작업 혹은 작업의 실종(?)으로 인해서 발생되는 누락등이다. 이건 결과적으로 프로젝트에 매우 큰 해를 끼칠 수 있고, 프로젝트의 실패로 이어지기도 한다.

팀 혹은 개인의 의무를 분명히 하는 것은 사실 어렵지 않다. 처음에 세심하게 준비하고 문서화함으로써 각 팀 혹은 개인이 그 프로젝트에서 갖는 의무를 분명하게 만들 수 있다.

문제는 2번째이다. 전체적인 책임은 모든 팀/개인이 공유해야 한다는 것. 만약에 어떤 팀 혹은 개인이 자신의 의무를 다 하지 못하고. 실패를 한다면 그 것을 누군가는 메꿔야 한다. 그랬을때, 사실 팀 또는 개인이 자신의 일이 아니라는 이유로 방관할 수도 있고 혹은 자신의 일 이외 부분에 대한 이해가 부족해서 그런 작업을 잘 하지 못할 수도 있는 것이다. 즉 프로젝트에 속한 모든 팀/개인이 전체적인 그림에 대해서 이해하고 전체적인 책임을 공유할 수 있어야 이런 작업에 대해서 실패하지 않을 수 있다. 책임을 모두 공유해야 한다는 것은 바로 그런 의미이다.

Empower team members

팀 멤버들에게 많은 권한을 위임한다.

이 항목에 대해서 MSF White Paper는 다음과 같은 구절을 인용한다.

“On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader, because that person would then cease to be a peer and the team interaction would begin to break down. The structure of a team is a network, not a hierarchy."

"최고의 팀에서는 각각 다른 개인이 각자의 전문 분야에 대해서 리더십을 그때마다 제공한다. 누구도 계속해서 리더가 될 수없는데, 항구적인 리더는 동등한 관계의 팀 상호작용을 파괴시키기 때문이다. 팀의 구조는 계층 구조가 아니라 네트워크이다."

Tom DeMarco and Timothy Lister "피플 웨어"

Work toward a shared vision
비전을 공유하고, 그 비전을 목표로 작업한다.

프로젝트에는 명확한 비전 혹은 목표가 있어야 한다. 그 비전은 복잡해서도 안 되고, 애매해서도 안 된다. 이를테면, "이번 프로젝트를 통해서 3달안에 우리의 전자결재 솔루션 제품에 오피스 지원 기능을 추가함으로써 경쟁 제품에 대한 우위를 점하고 업계 No.3로 올라선다" 정도의 간단하면서도 프로젝트를 통해서 달성할 비즈니스 가치, 그 비즈니스 가치를 달성하기 위한 제품의 목표 등을 완전히 기술하는 형태가 되어야 한다. 그리고 그 달성해야 할 비즈니스 가치는 엄격한 조사와 많은 토론을 통해서 제련된 아주 현실성 있는 목표여야 한다.

목표가 명확해야 길을 잃지 않는다. 목표가 명확해야 다른 길로 잘못 들어서지 않는다. 목표가 명확해야 팀원들이 힘을 잃지 않는다. 현재 No.4인데 무조건 No.1로 올라서자 등의 현실성 없는 목표나 최고의 전자결재 솔루션을 만든다 등의 애매한 목표를 가지고 일을 하게 되면, 끝도 보이질 않고 중간에 헤매게 되고 그러다 보면 팀원들의 힘은 빠지는 최악의 상황으로 흘러 갈 수 있다. 명확하고 현실성 있는 목표를 설정해야, 그 목표를 이룰 수 있다. 그리고 결국 프로젝트의 성패를 가루는 기준은 프로젝트가 목표한 바를 이루었느냐이다.

다른 원칙 보기

Foster open Communications (열린 커뮤니케이션을 장려한다)
Work toward a shared vision (비전을 공유하고, 그 비전을 목표로 작업한다)
Empower Team Members (팀 멤버들에게 많은 권한을 위임한다)
Establish clear accountability and shared responsibility (팀,개인의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다)
Focus on delivering business value(비즈니스 가치에 초점을 맞춰야 한다)
Stay agile, expect change (언제나 유연하게 변화에 대응할수 있도록 한다)
Invest in Quality (품질에 투자한다)
Learn From all Experiences(모든 경험으로부터 배운다)

Foster open communications

열린커뮤니케이션을장려한다.

당연한 말일지도 모른다. 하지만 커뮤니케이션이 잘못되어서, 프로젝트가 위기에 빠지는 경우를 우리는 너무나 흔하게 본다. 실제로 많은 소규모 프로젝트들이 담당자들간의 간단한 대화에만 커뮤니케이션을 의존한다. 그런 경우, 마치 가족오락관의 어떤 게임처럼 한군데서 커뮤니케이션의 미스가 생기면 그게 눈덩이처럼 불어나면서, 돌이킬 수 없는 큰 문제로 발전하게 된다. 그리고 서로 책임 떠넘기기에 바빠진다.

위에서 언급한 사례들이 바로 닫힌 커뮤니케이션이다. 즉, 커뮤니케이션 자체는 이뤄졌지만 그 커뮤니케이션의 결과물들은 아무데도 없다. 단지 참여한 사람들의 기억 속에만 있다. 폐쇄적이고 닫혀 있어서 다른 사람들은 아무도 알 수가 없다. 열린 커뮤니케이션은 이런 것을 지양한다. 모든 커뮤니케이션은 기록되고 공개되어 있어서, 적절한 권한이 있다면 누구나 볼 수 있다. 그래서 현재 프로젝트의 상황을 투명하게 볼 수가 있다. 적어도 오른손이 하는 일을 왼손이 몰라서 문제가 생기지는 않는 것이다.

다른 원칙 보기

Foster open Communications (열린 커뮤니케이션을 장려한다)
Work toward a shared vision (비전을 공유하고, 그 비전을 목표로 작업한다)
Empower Team Members (팀 멤버들에게 많은 권한을 위임한다)
Establish clear accountability and shared responsibility (팀,개인의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다)
Focus on delivering business value(비즈니스 가치에 초점을 맞춰야 한다)
Stay agile, expect change (언제나 유연하게 변화에 대응할수 있도록 한다)
Invest in Quality (품질에 투자한다)
Learn From all Experiences(모든 경험으로부터 배운다)

invalid-file

MSF(Microsoft Solutions Framework)는 Microsoft에서 제안하는 Software 개발방법론이다. 실제로 Microsoft에서 그동안 많은 소프트웨어를 개발하면서 겪어왔던 여러 교훈들이 녹아있는 꽤 훌륭한 방법론이다. (물론 제대로 적용되었을 때 얘기이다.) MSF는 다음 8가지를 기본 원칙으로 삼는다.

Foster open communications

열린 커뮤니케이션을 장려한다.

Work toward a shared vision

비전을 공유하고, 그 비전을 목표로 작업한다.

Empower team members

팀 멤버들에게 많은 권한을 부여한다.

팀(개인)의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다.

Focus on delivering business value

비즈니스 가치에 초점을 맞춰야 한다.

Stay agile, expect change

언제나 유연하게 변화에 대응할수 있도록 한다.

Invest in quality

품질에 투자한다.

Learn from all experiences

모든 경험으로부터 배운다.