완벽한 프로그램을 지향해야 하는가?

기술 기반 스타트업이 아니라면... 적정선에서 타협하라.

기술기반의 테크 기업이 아니라면, 너무 IT서비스나 프로그램을 완벽하게 만들려고 노력하는 것이 의미가 없을 경우가 생각보다 많다는 것은 그렇게 놀라운 일이 아니다.

고품질의 소프트웨어 영역이 정말 의미 있게 쓰이고, 배치되는 것이 사실상 비즈니스의 경쟁력과 수익에 그다지 영향이 없다는 것을 느끼게 된 품질담당자나 CTO의 당혹스러운 상황을 실제 경험하게 된다는 것을 이야기하는 것이다.

웃픈 상황이 될 것이다.

굳이 개선되지 않더라도, 사용자들은 관련 행동 패턴에 익숙해있을 것이고, 

개발자들은 원래 우리 도메인이나 우리 앱은 이렇게 해도 무방해요.

귀찮게 리팩터링이나 더 심도 있는 서비스를 만들 이유가 굳이 없어요.

이렇게 이야기하면서 심도 있는 구성으로 진화하는 것에 대해서 거부할 것이다.

더군다나, 앱이나 서비스가 상당히 큰 수익을 얻고 있고,

해당 도메인을 거의 독점적으로 지배하고 있거나, 해당 서비스의 1위 업체라면 

이런 딜레마에 빠질 것이다.

...

결론은 당장은 아무것도 의미가 없을 가능성이 크다.

개발자들은 더 깊은 작업을 반대할 것이고,

주주들이나 서비스 운영파트에서는 왜 서비스가 잘되고 있는데 사서 고생하느냐며 핀잔을 줄 것이다.

심지어, 대표가 추진하려고 하더라도...

추진력이 발생되지 않는 순간이 발생한다.

...

미안하고, 슬프지만...

해당 기업은 이미

창업자나 초기에 참여한 사람들의 회사가 아닌 곳이 되어 버린 것이다.

이미, 어느 사이에 대 기업화된 기업의 내부 조직의 구성을 보고 화들짝 놀라게 될 것이다.

특정 구역의 정치 세력화된 집단들과...

자기 밥그릇을 지키기 위해서 눈을 부릅뜬 사람들의 존재를 알게 될 것이다.

외부적인 커다란 경쟁자가 생기기 전까지는

이 조직은 굳이 더 변화하지 않을 것이다.

적당한 수준에서 기업이 연착륙을 하는 시나리오 모델을 고민하거나...

테크 중심의 조직원들이 조용하게 빠져나가는 것을

조심스럽게 보게 될 것이라는...

...

기업에 위험이 다가오고,

서비스에 커다란 경쟁자가 다가올 때에 기민하게 움직일 기업의 상태를 유지하는 탄력성은...

바로, 완벽을 추구하려고 애를 쓰는 기술 책임자와 품질 책임자의 힘에서 유지된다.

그들의 말에 귀 기울이고, 그들의 말을 잘 따라야 하는 이유는 그러하다.

기업의 기민함은, 품질에서 유지되고, 품질에서 커버한다.