현실적인 가능성과 논리적인 가능성

우리가 해결해야 할 문제는 논리적인 가능성과 현실적인 가능성의 중간지대에 놓여있는 경우가 많다.

 

특히, 이런 상황은 개발직군과 비개발직군에서 극단적으로 치달을 가능성도 있으며, 좀처럼 협의가 이뤄지지 않는 상황이 생길 수도 있다.

각 영역의 가능성을 좁힐 수 있도록 하는 타협점이 어디인지 서로 협의할 필요가 있다.

 

일반적으로 개발직군은 엣지 케이스를 고려하여 논리적 결함은 없는지를 먼저 검토한다.

논리적으로 발생할 수 있는 가능성에서 발생하는 결함을 용납지 않는 경우가 많다.

 

반대로 비개발직군은 현실적인 가능성을 우선적으로 검토한다.

따라서 논리적으로 발생할 수 있는 가능성의 엣지케이스를 고려해야 하는 것에 잘 이해하지 못하는 상황이 일어날 수 있다.

 

제품을 개발할 때는 정책과 정책이 충돌하지 않도록.. 확장성을 고려하여 잘 설계하는 것도 중요하겠지만.. 불확실한 상황에서 어떻게 모든 것을 고려하겠는가. 사실 현실에서는 어려운 경우가 많다.

 

지나고 나서 “그때에는 맞았지만, 지금은 틀리다”와 같은 이야기가 나오기도 한다.

 

문제는 다양한 관점에서, 논리적이고 현실적인 방법을 함께 생각하며 풀이해야 한다.

해결해야 할 문제는 뾰족할수록 좋고, 단순한 해결일수록 좋다.

때론, 간단히 문구를 수정하는 일로 고객이 겪는 문제를 해결할 수도 있다.

 

현실적 가능성과 논리적 가능성을 절대 고수하는 입장이 충돌하여 전혀 타협이 일어나지 않을 때는 상호 보완하며 해결할 방법은 없는지 한 걸음 떨어져서 문제를 다시 살펴보는 것이 좋을 것이다.

현실적 가능성을 논리적 해결책으로 해소하고, 논리적 가능성을 현실적 해결책으로 해소하는 방법은 없을지 생각해 보아도 좋다.

 

업무를 진행하며 예시 상황에 대한 전체 논의의 과정 및 문제와 해결 방향 등을 이곳에 작성할 수 없어 아쉽지만..

대략 논리적/현실적 가능성으로 인한 의견의 차이가 좁혀지지 않을 때,

내 주장에 대해 너무 몰입하고 있지는 않은지,

서로의 가능성을 서로의 해결책으로 해소할 묘수는 없는지 생각해 보자.

 

결국 어떻게 구현하느냐가 중요한 것이 아니라 고객의 문제를 해결하는 것이 더 중요하다는 의미이다.