IT 프로젝트를 참여하는 모든 이들이 알게 모르게 스스로 프로젝트의 문제점을 찾는다. 이런 모습은 뒷담화로 보일 때도 있고, 불평불만을 토로하는 것처럼 보일 때가 있으나 가만히 들어보면 IT 프로젝트의 문제점이다.
IT 프로젝트 진단을 하다 보면, 저렇게 개개인이 느끼는 문제점들이 공기 중에 흩어져 부유하고 있음을 알게 된다.
문제점을 발견했을 때 자신의 힘으로 해결할 이유도 없고 해결방법도 모르기 때문에, 삼삼오오 모여서 프로젝트 요소요소 불편함에 대해 툭툭 이야기하게 되는 것이다.
이러한 불만들을 그저 흘려보내지 말고 왜 저런 상황이 벌어졌을까를 생각해 보면 참 많은 시사점을 도출해 낼 수 있다. 예를 들어서, 고객이 개발자가 작성한 설계서를 봤더니 작성 수준이 마음이 안 든다고 말했다고 가정하자.
그 원인은
- 개발자의 숙련도가 높지 않아서
- 가이드를 제대로 제공받지 못해서
- 일정이 촉박해서
- 개발자에게 할당된 양이 과도하게 많아서 등
여러 가지일 것이다.
이를 '저 팀 실력도 낮고 태도도 문제야.'라고만 말하고 아무 후속 조치를 취하지 않으면 해결되는 것은 없다.
설계서의 문제가 향후 개발과 테스트까지 악영향을 끼치게 된다.
개발자 숙련도 때문이라면,
유경험자/경험자를 팀으로 묶어 코칭 체제를 가동해도 되고, 도움이 될만한 실질적인 샘플을 제공해줘도 좋다. 주기적으로 작성한 설계서에 대해 리뷰와 공유 세션을 진행하는 것도 도움이 된다.
개발자들이 가이드를 제대로 제공받지 못했다면, 다시 그 이유를 찾아야 한다.
가이드 그룹에 문제가 있다면 다시 그 속에서 이유를 찾아야 하고, 전달 시기와 공유 방법에 문제가 있다면 관련 프로세스를 개선을 해야 한다.
일정이 촉박해서라면,
일정이 촉박해진 원인을 다시 찾아보면서 구체적인 catch up방안을 세우되, 인별 난이도에 따른 할당량을 조정해 볼 수도 있다.
개발자에 할당된 양이 문제라면,
개발자별 업무 조정도 필요하지만 초기 선정한 인력 투입 계획을 재점검해 볼 수도 있다.
프로젝트 초반 도출한 요구사항이 진행과정에서 급증해서 생긴 문제일 수도 있으니, 이때는 요구사항 관리 프로세스 정비뿐 아니라 요구사항 freezing도 필요하다. 이후 추가되는 요구사항은 일정과 인력에 영향을 주지 않는지 검토 과정이 필요하다.
공기 중에 부유하는 많은 문제들, 주로 불평불만으로 나타나는 사소한 문제들은 실제로 원인을 찾아가면 의외로 제법 큰 문제로 인해 야기된 것들로, 한 가지 방법만으로 해소시키기 어려운 경우도 많다.
그래서 문제를 발견하면 원인을 찾고 해결하는 것은 좋으나, '원인의 원인', 즉 Root couse를 밝혀내야 근본 해결을 할 수 있다.
1차적인 원인만 제거하면 동일한 문제 또는 파생된 문제가 계속 발생할 수 있기 때문이다.
우리 팀이 프로젝트 진단을 할 때, 그저 문제만 던지는 것이 아니라, 발견되는 문제에 대해 해결방법을 함께 제시하면서 시정조치를 요청하곤 한다.
바로 '원인의 원인'까지 생각하다 보니 가능한 일이다.
그렇게 고심하다 보면 창의적인 방법도 같이 떠오르곤 한다.
매번 느끼지만 프로젝트는 하나의 독립적인 '작은 생태계'이자 '작은 사회'다.
나 개인의 문제도 그 원인을 찾아보면, 다시 그 원인을 야기하게 된 근본 원인이 따로 있음을 알게 된다.
가끔씩 머리가 복잡하고 해결이 될 거 같지 않은 문제도 그렇게 원인의 원인을 찾아가서 한 가지만 해결해 보려고 애쓰면 실타래처럼 얽혀 해결 기미가 보이지 않던 문제들이 점차 서로 영향을 미치며 해결되는 쪽으로 서서히 움직이는 것을 확인할 때가 있다.
이때 염두에 둘 것은, 단시간에
짠~하고 해결되는 것이 아니기 때문에 조바심을 내지 말라는 것이다. 해결되는 방향으로 갈 수 있게 모니터링과 평가가 필요하다.
현재 하고 있는 프로젝트는 내년까지 단계적으로 8번 오픈을 하는 복잡한 계획이다.
현재 첫 번째 오픈을 앞두고 상당히 분주하다.
아직 해결되지 못한 문제도 있으나, 프로젝트 진단을 하면서 원인의 원인을 찾아보는 노력을 여전히 하고 있다. 나머지 7개 영역 오픈에는 같은 시행착오를 하지 않도록.
