세상을 놀라게 하자!

서로 일정 맞춰가기 본문

Software construction/Agile development

서로 일정 맞춰가기

유진호 2011. 3. 11. 01:49


서로 다른 욕구


 대부분의 경우 개발자들은 사람과 상호 작용을 다루는 일에 서투릅니다. 경영진은 사람과 친숙치 않은 사람과 일을 함께 하는데 서툽니다. 개발자들은 경영진이 쉽게 일을 생각한다 느끼고 경영진은 개발자들이 일을 성실하게 하지 않는다고 느낍니다. 그런데 정말 그것이 사실일까요?

왜 경영진은 개발팀이 보기에 촉박한 일정을 제시할까요? 경영진의 ‘욕구’를 생각해봅시다. 일반적인 경영에서는 제품의 출시로 매출이 나오면 성공이라 생각하지요. 그래서 빠르게 개발이 되어서 시장의 반응을 알고 싶어합니다. 또는 개발 기간 = 임금 비용이기 때문입니다. 즉 경영진에게 가치가 있는 일이란 가능한 적은 비용은 적게 들이고  빨리 시장에 물건을 내놓아 매출을 만드는 것입니다. 그리고 의외로 많은 시간을 고민고민해서 일정을 잡습니다. 이 점을 개발팀들이 잘 모르는 경우가 있습니다. (물론 지나치게 즉흥적인 제안을 들고오는 경우가 없다는 것은 아닙니다. )


개발팀의 욕구는 어떤 것일까요? 보통 일반적인 개발팀의 욕구는 ‘좋은 물건’입니다. 좋은 품질의 소프트웨어를 만들고자 하고 그것이 주는 기쁨을 매우 크게 생각합니다. 때로는 다른 모든 것을 희생하고라도 좋은 소프트웨어를 만드는데 힘을 쏟고 싶어합니다. 그리고 경영진이 생각하는 것 보다 실질적인 일정을 만들어낼 수 있는데 그 일을 하는데 제일 실질적인 정보를 가지고 있기 때문입니다. (물론 지나치게 일정을 늘려서 버퍼를 만드는 경우가 없다는 것은 아니지요. )


위에서 보듯이 경영진과 개발팀은 ‘제품출시’를 빼놓고서는 서로 욕구가 다릅니다. 그렇다면 어떻게 서로 대화를 이끌어가고 또 맞춰나갈까요?


우리는 서로 얼마나 이야기 하고 있나요.


자, 둘은 어떤 식으로 대화를 진행해야 할까요? 저는 몇 가지 체크리스트를 드리고 싶습니다.

  1. 계획을 세운 다음 그것이 유효했는지 스스로 물어볼 수 있는 회고와 같은 시간을 가지고 있습니까? 그것도 1주일 안쪽으로?

  1. 주어진 계획의 진행 상황을 관찰한 결과를 개발/경영 모두 정직하게 사실을 바라보고 있습니까? 두 조직 모두 같이 피드백을 주고 받습니까? 그 피드백에 대한 행동을 정해서 위험을 최소화 하는 노력을 했습니까?

  1.  우리가 만든 제품에 대해 고객이 정말 원하는 것인지 피드백을 정기적으로 받아보았습니까? 그 결과를 개발/경영 모두 정직하게 바라보고 있습니까?

  1. 요구사항이 변경 불가능한 시점에 대해 고객과 협의를 했습니까? (적어도 출시 2주 안쪽 ) 이에 대해 고객이 수긍하고 있습니까?



위에서 보듯이 사실상 경영진-고객-개발팀 이 세 이해당사자들이 모두 같이 그리고 함께 일을 진행해야 합니다. 그리고 세운 계획들이 제대로 돌아가는지 확인하고 위험 요소를 미리 분석하기 위한 노력을 기울여야 합니다. 세워진 계획이 얼마나 잘 돌아가는지 다시 피드백을 받고 점검하는 일에 대해 우리는 얼마나 힘을 쓰고 있나요?

애자일 프랙티스중 하나인 ‘반복계획’은 이런 문제를 해결하고자 만든 행동지침입니다. 보통 개발 계획을 잡으면 이런 식으로 많이 하죠.

계획회의1-> 계획회의2-> 계획 회의3-> 요구사항분석->개발->검증->출시



문제는 늘 요구사항 분석 뒤의 일들이 어떻게 돌아갈지 아무도 모른다는 점입니다. 출시가 되어야 고객은 뭔지 알아보는 경우가 있다는 거지요. 반복 계획은 이렇게 하는 겁니다.
1단계:
 큰 것들에 대한 계획회의-> 요구 사항 분석-> 개발-> 검증->고객에게 출시

2단계: 1단계에서 알게된 것에 따라 계획 수정-> 요구 사항 수정/추가->개발-> 검증->고객에게 출시

3단계 부터 이후 : 2단에서 했던 방식을 고객의 요청과 수렴할 때까지 반복.


만약에 위의 단계에서 2단계 정도를 2주일 정도 약식으로라도 해보고 그 피드백을 근거로 개발팀이 일정을 추산한다면 경영진은 토를 달아서는 안됩니다. 실제 그것이 그 개발팀이 낼 수 있는 ‘최선’일 것입니다. 10년 걸려야 만리장성을 쌓을 수 있는데 위에서 ‘간절히 원하면 소원을 이뤄준다는’요정이 1년만에 쌓을 수 있게 해주지 않습니다. 대신 개발팀은 이렇게 이야기를 해야 겠지요.

 “주어진 일정 XX개월 동안에는 이러이러한 기능까지 개발 할 수 있다. 일정을 더 주시면 어느정도까지 가능할 것이다.”

개발팀은 자신들이 내놓은 일정의 ‘근거’를 내놓는데 인색해서는 안될 것입니다.

제가 추천드리고 싶은 것은 일정은 한번 위에서 아래로, 다시 아래에서 위로 올리라는 것입니다. 그렇지 않은 일정은 대부분 공수표입니다. 지켜지지 않을 일정은 오히려 일할 의욕을 떨어뜨리고 경영진의 신뢰를 잃게 만듭니다. 일정을 가치있게 만들어야 하는 이유가 여기있습니다.


최악의 경우: 관리자가 무당이 될 때.


이때 제일 안좋은 상황은 ‘ 나쁜 관리’가 끼어드는 경우입니다. 지나친 조바심에 무조건 경영진의 입장을 강요하고 굴복시키려고만  하는 사람이 경영진과 개발자 사이에 끼어서 ‘관리’를 하는 경우를 말합니다. 그런데 이때  관리자들이 잊어버리는 것이 있습니다.  ‘경영자가 약속 이행을 아무리 강하게 요구해도 진정으로 원하는 것은 결과물 자체’라는 점입니다. 그러므로 아무리 압박을 하더라도 그것이 결과물을 나오게 하지 못하거나 더디게 한다면 아무소용이 없다는 것입니다.

보통 자원이 부족하고 급한 상황이 벌어졌을 때, ‘합숙’같은 방법을 들고 나오는 관리자들이 있습니다. 같이 뭔가 모이면 뭔가 되지 않을까 싶은 ‘주술행위’지요. 만약에 테스트를 험하게 하기 위한 것이거나 구현 자체를 좀 집중적으로 하기에는 1주일 정도 괜찮을 수도 있지만 몇달이상 가거나 설계자체가 뒤죽박죽인 경우에는 오히려 문제가 더 커집니다. 이래서 피드백을 받고 이를 해석하는 시간이 필요하다는 겁니다. 방향이 틀릴 수가 있거든요.



의사소통이 우리를 구원했어요.


 1986년 챌린저호가 폭파하는 사고가 벌어졌습니다. 출발한지 73초만에 공중분해되어 승무원 7명 전원이 사망했습니다. 물리학자인 리차드 파인먼이 이 사고의 조사를 담당했고 그 원인이 O-ring이 성층권에서 얼어버린 것이라고 밝혔습니다. 하지만 그보다 더 큰 원인은 NASA의 의사소통이라고 지적했습니다. 가장 말단에서 낸 우려가 위까지 전달안되서 생긴  사고란 것이었지요. 파인만은 여기서 지적하기를 “밑에서 낸 아이디어나 경고를 무시하는 순간 더이상 새로운 정보는 올라오지 못하게 된다"라 이야기를 했습니다.

 경영진이 내는 일정은 보통 ‘출시’가 되야 하는 적기인 경우가 많습니다. 개발팀이 내는 일정은 ‘제대로 된 제품’이 나올 수 있는 시기인 경우가 많습니다. 경영진의 일정이 다소 짧다면 개발팀은 개발할 기능의 수를 줄이는 방식으로 재협의를 진행해야 할 것입니다. 만약에 경영진이 너무 짧은 일정밖에 줄 수 없는데 개발팀에서 거의 불가능하다는 판단이 나왔다면 서로 욕심을 부려서는 안됩니다.

일방적인 일정 강행이나 명령에 추종해서 어떤 중간 점검도 하지 않는 관리 문화가 가져다 주게 되는 폐해는 인류역사에서 충분히 많이 보았지만 많은 사람들은, 특히 군대문화의 신화를 가지고 있는 관리자일 수록 이를 따릅니다. 그리고 실패합니다. 제럴드 와인버그는 프로젝트의 실패 요인을 크게 두가지로 이야기 합니다.
  • 행동 오류: 관리자의 비일치적인 행동때문에 일어나는 문제들
  • 정보 오류: 주어지는 피드백에 오류가 있거나 잘못된 정보 때문에 생기는 문제들
 

 혹시 우리는 개발 조직내에서 들려오는 목소리를 외면하지는 않습니까? 혹은 경영진의 요구사항을 '철부지들의 투쟁'이라 낙인찍고 들어보려고도 하지 않나요? 내일 아침, 출근해서 일정을 세우거나 추산해야 한다면 얼마나 정보를 가지고 있는지, 나의 결정이 내가 느끼는 것을 정말 제대로 반영하고 있는지 스스로에게 물어봐야 할 것입니다.


Comments