획일화된 프로세스의 함정

SW를 개발하는데 있어서 체계화된 프로세스가 필요하다는 것은 당연하다.

대부분의 SW회사가 최소한의 프로세스도 없이 주먹구구식으로 SW를 개발한다. 작은 회사들은 문제가 안되는 것처럼 보이지만 회사가 조금만 커져도 여기저기서 문제가 발생하다.

이런 문제에 시달리다보면 프로세스와 문서화가 이 문제를 해결해 줄것이라고 너무 믿게 된다.
그래서 엄격한 프로세스를 만들고 각 프로세스마다 문서를 꼭 만들게 하고 검사를 하기도 한다. 물론 프로젝트의 종류에 따라서 만드는 필수문서를 다르게 하기도 하지만, 이러한 규정은 개발자들이 요리조리 프로세스를 피해가는데 활용이 되곤 한다.

프로젝트에서 꼭 필요한 문서를 획일적으로 정하는 것은 매우 어렵다. 프로젝트 팀에서 결정하고 이를 존중하는 것이 좋다. 하지만 아직 개발팀의 역량이 부족하고 문화가 부족하다면 개발팀의 결정을 따르기도 어렵다.

가장 좋은 방법은 회사가 작을 때부터 체계적으로 개발하는 방법을 익히고 스펙과 설계를 적절하게 작성해가면서 개발문화를 키워나가고 개발자들의 역량이 같이 커져가는 것이다. 그렇게 되면 회사가 커져도 좀더 복잡한 프로세를 자율적으로 운영할 수 있게 된다.

하지만 대부분이 회사는 이러한 기회를 놓치게 된다.
그래서 택하는 것이 획일화된 프로세스이다. 이 고통스러운 프로세스를 거쳐서 이겨내면 점점 자율적인 프로세스로 바뀌게 되지만 이를 극복하지 못하면 점점 더 복잡하고 엄격한 프로세스를 만들게 된다.

가장 좋은 방법은 회사가 성장함에 따라서 문제가 생기기 이전에 미리 체계를 갖추고 개발자들의 역량을 키우는 것이고, 이미 문제가 발생했다면 최소한의 프로세스만을 만들고 지금이라고 개발자들이 분석, 설계 역량을 키울 수 있도록 회사에서 지원하는 것이다.