IT Project 성공 열쇠, 돌보기
*출처: https://medium.com/swlh/how-to-run-an-it-project-3de28603fec1
IT 프로젝트가 망가지는 이유를 실질적으로 살펴보고, 이를 피하는 방법을 살펴보자.
Simon Pitt
2019.9.11
위키피디아 페이지에서 "~ 목록"이라는 제목을 보면 왠지 눈이 간다.
- 포켓몬 목록
- 이미지 공유 웹 사이트 목록
- 목록 중의 목록이 있는 페이지의 목록
이런 상황이니, 실패하고 예산을 넘어 버린 맞춤 소프트웨어(특정 조직이나 개인이 사용할 목적으로 설계되고 쓰이는 소프트웨어) 프로젝트 목록도 있을 것이다. 아! Big IT Project. 이미 돈 냄새를 맡았을 것이다. 구매 주문이 발생되고, 파워포인트 문서가 생산되고 있으며, 사방에 칸트 차트가 넘실거리고, 아웃소싱 기업들이 넥타이를 바로 하고 패키지와 요청 사항을 준비한다.
무슨 일이 일어난 것인가. 한 경영진이 조직에 성가신 문제가 있음을 발견하고 회합을 소집했다(아마도 간식이 마련된 회의일 것이다). 또 한 명의 C-레벨 임원이 유사한 문제가 있다고 말한다. 그런 다음, 몇 명의 왜그(wag: 진지하게 생각하지 않고 가볍게 지껄이는 사람)들이 문제를 해결할 혁신 프로그램(transformation programme)을 실행할 필요가 있다고 결정한다. 이에 따라 파워포인트에 "Big IT Project"라고 쓰인 박스를 그려 넣거나 문제 추적 문서 위에 줄을 한 줄 추가하고, 짜증 나는 문제들을 모두 모아 그 안에 쏟아버린다. 문서를 장식하던 누군가가 "이 프로젝트에 명칭이 필요하다"라고 말한다. 이것이 그들이 즐기고 있는 회의의 대화이자, 업무의 정점이라 하겠다. 누군가 "바라쿠다(창꼬치)?"라고 툭 던진다.
"버찌 씨(Cherrystone)?"
"황옥(Topaz)?"
모두가 즐기고 있다. 이 프로젝트가 과연 잘 굴러갈 것인가?
CFO가 예산을 승인하고, 이제 프로젝트는 결과를 산출할 프로그램 매니저에게 넘어간다. 그들은 이 어려운 일을 해냈다, 그렇지 않은가? 에설론(Echelon)이란 훌륭한 이름을 가지고 있는 프로젝트는 기본적으로 이 명칭을 통해 프로그램의 의미를 전달할 것이다. IBM은 커다란 패키지를 준비하고, SAP는 기본적으로 그것 모두를 수행할 수 있는 신규 제품을 18개월이 지난 다음 해에 내놓는다.
나는 기술 제품을 구축하고 있다. 비록 요즘 점점 더 많은 회의에 참석하고 다른 이들에게 기술 제품을 구축하도록 요청하고 있지만. 나는 잘 진행된 프로젝트에서 작업했고, 망친 프로젝트에서도 일(기여)했다. 심지어 위키피디아에 이름을 올린 프로젝트 중 하나에도 (간접적이지만) 관여했다.
내는 IT 프로젝트가 가진 문제를 풀어냈다고 말하고 싶고, 프로젝트를 잘 운용했다고 말하고 싶다. 여기에 당신도 잘할 수 있는 4 가지 팁을 제시한다(세 번째 팁에 충격을 먹을지도 모르겠지만). 하지만, 인생은 그리 간단하진 않다. 수 백만 달러짜리 프로젝트를 원활하게 굴러가게 하는 일이 쉬웠다면, 실패하는 프로젝트는 없었을 것이다.
잘 되는 프로젝트와 실패하는 프로젝트 사이에는 어떤 차이점 있고, 우리는 어디로 가고 있는가? 아마도 우리는 미묘한 차이가 있다고 말할 수 있다.
인터넷을 서핑하다 보면, 한 때 아름다웠지만, 수정 변경으로 점점 더 혼란에 빠진 웹 사이트들을 목격하게 된다. 이런 사이트들은 종종 자금이 풍족한 대기업의 것인 경우가 많다. 로고가 비율을 벗어나 늘어져 있거나, 아이콘들이 일관되지 않거나, 설명할 수는 없지만 사이트의 절반이 Times New Roman체로 되어 있다.
그런 것들을 목격한 적이 있어서, 이러한 문제에 관한 하나의 이론을 가지고 있다. 프로젝트에는 이러한 작은 디테일 모두를 깊이 있게 살피고 고려한 사람이 있었다. 그(녀)는 그래픽들이 정확하게 표시되는지 확인했다. 매뉴얼을 살펴보고 배경을 투명하게 설정하는 방법을 확인했다. 사이트가 안드로이드 환경에서 작동하지 않는 문제를 찾아내고 버그를 정리했다. 이 사람은 이 제품에 마음을 다 했다. 그러고 나서, 이직을 했다.
그 사이트는 로마군이 다녀간 후의 영국 같았다. 앵글로 색슨 같은 신규 사이트 관리자에 의해 고문당하고 파괴된 채 남아 있는 모든 위대한 건축물들. 이 모든 송수관을 통해 지나다닌 것이 무엇인지 확실하지 않다. 아니면 새로운 욕조를 추가한 방법이 무엇인지 모른다. 나는 와서 보고 대충 고쳤다.
돌보기.
나는 돌보기가 웹 개발 프로젝트에서 가장 간과되는 요건인지 궁금하다. 작은 디테일까지 충분한 주의를 기울이는 돌보기 말이다. 돌보기를 통해 우리가 의미하는 것을 더 작게 분해해 보자:
1. 웹 사이트의 배경으로 디지털 철학이 있어야 한다는 것을 아는 것. 혹은 웹 사이트가 느리게 운영되고 있음을 아는 것, 혹은 보기보다 이용하기 쉬워야 한다는 것을 아는 것.
2. 디자인 철학을 제시하거나 제시할 사람을 찾거나 사이트가 느리게 운영되는 이유를 찾아 고치도록 신경 쓰는 것.
3. 디테일을 기억하고 나중에 이행하거나 확인하는 것.
만일 프로젝트를 돌보는 사람들이 없다면, 그들은 그냥 만들어 제출할 뿐인 것이다. 그들이 자신의 직업과 평판을 주의 깊게 관리할지는 몰라도 궁극적으로, 그들은 요건 목록에 휘둘리고 있는 것이다. 그리고 내가 자신 있게 말할 수 있는 것은 대형 프로젝트를 행할 때 생각할 필요가 있는 모든 것을 수록하고 있는 요건 목록은 없다는 것이다. 한 발 앞서 의사 결정할 모든 것을 기술하는 것 자체가 가능하지 않다. 의사 결정할 사항들이 너무 많고, 너무 세세하며, 서로 얽혀 있다. 냉혹한 현실에 직면했을 때 원칙을 고수하기 힘들다. 결국, 최종 제품은 요건 목록 그대로다.
만일 당신이 실패한 IT 프로젝트의 요건 목록을 빌려 볼 수 있다면(빙산 위에 사는 북극곰의 머리 위에서 겨우 구할 수 있을 것이지만), "아웃 소싱됨"이란 단어를 자주 볼 수 있을 것이다. 문제를 가진 기업이 거대 IT 복합기업을 찾아 이렇게 말했다. "내가 귀사에 현금으로 가득 찬 손수레를 안긴다면, 이 문제를 해결해 줄 수 있소?" 현금으로 가득한 손수레를 거절할 사람이 있을까?
문제는 아웃소싱 자체에 있는 것이 아니라 무엇을 아웃소싱 했느냐는 것이다. 아웃소싱은 할 수 있다. 그러나 돌보기를 아웃 소싱하기는 극단적일 정도로 어렵다. 그리고 돌보기를 성공적으로 아웃소싱을 한 경우, 그 모든 개발자와 컨설턴트들이 멀리 떠났을 때, 당신은 이 모든 물을 도관을 통해 흘려보내는 것이 극단적인 탐욕스러움이 주는 진짜 고통이라는 것을 이해하고, 다시 한번, 그 앵글로 색슨들처럼 떠날 것이다.
상위자들이 보기엔, 내가 참여했던, 잘 굴러간 프로젝트나, 잘 안 된 프로젝트나 동일하게 보인다. 성공한 프로젝트와 실패한 프로젝트가 동일한 사람들에 의해 진행된 경우도 있다. 예산과 거버넌스 구조가 동일한 적도 있다. 심지어 이미지는 거의 사용하지 않고 적색, 녹색, 호박색의 동일한 패턴을 사용해 위험과 문제점을 표시한 2차원 그래프를 그린 보고서까지 동일하게 보인다.
성공한 프로젝트와 실패한 프로젝트의 차이는, 그 어떤 차트나 요건 문서에도 없는, 수백만 가지의 작은 의사 결정 사항들을 찾아 해결하기 위해 그 팀이 어느 정도의 노력을 기울였나 하는 점이다. 그리고 그 차이는 눈에 보이지 않는다. 결국, 프로젝트를 돌보지 않았다면, 몇몇 프로젝트들이 산으로 올라가고 있다는 것을 모든 사람이 알게 되고, 실패한 결과라는 막대한 돈 덩어리 위에 예산을 계속 쌓는 것보다 오히려, 프로젝트에 발을 들여 무엇이라도 할 것이다.
그리고 무슨 일이 일어나고 있나. 프로젝트 에셜론은 경영진 회의에 계속해서 불쑥불쑥 등장한다. 그 프로젝트는 다시 지연된다. 첫 번째 버전은 파워포인트로 표현하기 너무 복잡한, 분명치 않은 이유로 잘 진행되지 않았다. 몇 가지 내다보지 못한 이유가 발생했고, 비용이 발생하게 될 것이다. 잘은 몰라도 추가적인 £1,200만 정도 될 것이다. 매몰 비용 오류에 대해 언급하는 사람은 없다. 애석하게도 경영진들은 샌드위치와 꼬챙이에 꾄 작은 과일을 먹고 있다. 에셜론 프로젝트는 누군가 이 프로젝트를 취소하고 위키피디아 목록에 올릴 때까지 그 육중한 몸을 느릿느릿 움직이고 있다. 혹은 아마도 누군가 성공할 수 있다고 그럴싸하게 주장한다면 이 프로젝트는 느리긴 하지만 결승점에 도달할 것이다.
모든 직원들에게 보내는 연간 케이크 판매량에 대한 매일 하단에 "에셜론 프로젝트가 완료됨을 기쁘게 공지합니다"라는 문구 하나가 들어갈 것이다.
경영진은 안도의 한숨을 쉰다. 아마도 그들의 사업은 결국 안전하게 유지될 것이다.
몇 달이 지나고 신임 CTO가 "내가 우리 보유 재산을 살펴봤는데 몇 가지 심각한 기술 문제가 있음을 발견했다. IT 리프레시 프로젝트(IT refresh project)가 필요하다"라고 지적했다.
누군가 의심스러운 목소리로 "지난해 수행했던 IT 혁심 프로젝트 같은 것 말입니까?"라고 묻는다.
CTO는 "아니다", 어느 정도 표정 관리를 하며 "완전히 다르다"라고 말한다.
사람들이 지속적으로 참여하게 하는 이러한 모든 대화가 충분하지 않을 경우, 다른 방향으로 상황을 너무 기울여도 문제를 만나게 된다. 너무 과하게 프로젝트를 돌보는 매우 참여적인 직원들은 프로젝트를 마치 종교활동처럼 프로젝트를 다룬다. 이것은 따분한 액션 영화의 구성과 같다. 그들은 그것이 보다 큰 선을 위한 것이라고 믿기 때문에, 결국 회의에서의 논쟁, 지연되는 프로젝트, 일반적으로 문제를 야기하는 수단들을 정당화 하기 시작한다.
그러므로, 내가 도달한 결론은 다음과 같다. 기술을 들여오기는 쉽다. 프로젝트를 돌보는 사람을 채용하긴 어렵다. 그리고 프로젝트를 위해 사람을 채용하거나 기업에 아웃소싱을 할 때, 우리는 그들이 프로젝트를 얼마나 잘 돌볼지가 아니라 보유 기술에 따라 그들을 판단한다. 하지만 IT 프로젝트는 기술이 충분하지 않아서 산으로 가는 것이 아니다. IT 프로젝트를 실패했던 조직들, Swedish Police, US Air Force, UK Border Agency를 보라. 그들은 개발자가 부족하지 않았다. 이 프로젝트는, 개발자들이 스택 오버플로우 상태의 데이터베이스를 코딩하는 법을 물었을 때 충분한 답변을 얻을 수 없어서 실패한 것은 아니다. 충분히 돌보지 않았기 때문에 실패한 것이다.
프로젝트 규모가 클수록, 더 많은 의사 결정을 하고 적절하게 프로젝트를 돌보는 올바른 수준의 사람들을 더 많이 구해야 한다. 문제를 찾아내고 그것을 해결하도록 충분히 돌보고 다른 영역에 문제를 야기하는 일이 적은 사람들이 필요하다.
애자일 방법론에 따르면, 개발자와 고객이 작은 그룹을 이루어 함께 일하고 빈번하게 과정을 반복하라고 말한다. Amazon은 팀을 작게 유지하기 위해 두 개의 피자 규칙(Two pizza rule)을 추가했다. 스퀘이드, 스크럼, 길드, 갱, 코우터리 등 어떤 용어를 사용하든 팀을 작게 운용한다. 이런 아이디어 모두 동일한 일을 하려 하고 있다. 즉, 그룹을 작게 유지하고 그 그룹의 사람들이 그들이 하고 있는 일을 보살필 수 있을 정도로 지속적으로 집중하게 하기 위함이다.
다시 에셜론 프로젝트로 돌아가자. 무엇이 잘못됐나? 에셜론 프로젝트는 짜증 나고 성가신 프로젝트는 한 데 묶어 돈을 들이면 해결될 수 있다는 생각을 가지고 출발했다. 에셜론 프로젝트는 조직도 위에 잘 정돈된 모습으로 그려져 있었고, 모든 이들의 마음을 사로잡았지만, 성가신 문제들은 여전히 그곳에 존재했고, 단지 묻혀 있었을 뿐이다. 그들은 마법의 총알이 내는 희망적인 사이렌 소리에 속았던 것이다.
분위기, 돌봄, 관심
이것들은 규모가 잘 변하지 않는 아이디어들이다. 너무 규모가 커서 전체 모습을 볼 수 없고 당신의 영향력이 적은 프로젝트를 돌보기는 어렵다. 프로젝트 규모가 너무 커서 "모든 것을 고치게 될" 경우, 그 어떤 것도 고칠 기회는 없다.
잘 협력해서 일하고, 올바른 수준으로 프로젝트를 돌보는 팀이 있다면, 그들은 하나 혹은 두 개의 문제를 해결할 기회를 가진다. 심지어 그들이 지금 당장 기술이 없더라도 - 당신은 돈을 써서 기술을 살 수 있다. 돈을 써서 돌봄을 살 수는 없다.
모든 것을 한 바구니에 담고 그것이 마법처럼 정렬될 것이라는 생각, 아니면 당신이 충분히 살펴보지 않는 문제를 돌볼 누군가를 돈으로 살 수 있다는 생각은 어떤가? 그 프로젝트가 곧 위키피디아 목록에 오를 것이기 때문에 훌륭한 프로젝트 이름을 갖고 있는지 확인하는 것이 더 나을 것이다.
