PoC와 BMT

예전에는 제안서작업이나, PoC , BMT에 참석을 해서

실제로 코딩을 하거나 오퍼레이팅을 할일이 많았는데,

이제는 평가하고 결과보고하는 일이 주가 되버렸다.

양쪽입장이 되고 보니,

왜 제안서 제출은 항상 휴일 다음날 인지,

잘돌아가던 것들도 시연할려면 안되는지.. 

뭐.. 그런것들이 대충은 이해가 간다.

그런데.. 양쪽 입장에서 가만히 생각하다 보니..

PoC야 그렇다 치고,

BMT는 좀더 생각해 봐야 하는것이 아닌가 하는 생각이 든다.

만일 내가 10의 성능을 내는 제품이 필요한데.

어떤 제품은 8의 성능을 내지만 저렴하고,

어떤 제품은 20의 성능을 내지만 너무 비싸다면,

과연 어떤것을 선택하는게 맞는것인지 고민하게 된다.

물론 항상 평가에는 성능과 가격에 대한 비중이 정해져 있지만,

그 비중도 수시로 바뀌는 경우가 많고, 어떤것이 적정한 값인지를

아는 경우는 거의 없다고 해도 될듯..

그래서 난...

일단 꼭 필요한 기능을 나열하고, 해당 기능에 대한 점검을 수행한다.

  ==> 만일 꼭 필요한 기능이 없는 경우에는 해당 제품은 제외가 된다.

여기서 중요한것은 꼭 필요한 기능인지를 정확히 이해해야 한다는 것이다.

내가 PoC또는 BMT하는 제품에 대해 전체적으로 이해할 수 있어야 하고,

어떤것들이 중요한지를 사용하고 관리하는 입장에서 분별할 수 있어야 한다.

성능이 필요한 항목에 대해서 각각 우리가 필요로 하는 성능이 어느정도인지를 알아야 한다.

마냥 좋다고 좋은것은 없다. 분명 좋은게 있으면 나쁜것들이 따라오게 마련이다.

때문에 어느정도가 성능이 필요한것인지에 대해 각 부분별로 정의를 할 필요가 있다.

해당 성능을 상회한다면.. 그 상회정도가 어느정도인지는 중요하지 않은 경우가 많다.

최대한 공정하도록 해야 한다.

상당히 어려운 부분중에 하나인데, 공정하기 위해서는 그만큼 많이 알아야 한다.

성능을 위해 특정 기능을 뺀다거나, 별도 구매가 필요한 요소를 포함시킨다거나,

정당하지 않은 방법으로 수정을 가한다거나 하는 경우가 많다.

이런 부분이 있는지를 아는것은 정말 쉽지 않은 일이다.

하지만, 전체는 아니더라도 이런 것들을 어떻게 방지할것인지 반드시 고민이 필요하다.

너무나 당연한것들은 문서로 대체한다.

할 수 있는걸 다 한다면 좋겠지만, 항상 제한적인 것들이 많다.

그렇다면 기본적인 것들은 문서로 대체하고,

시나리에중 중복되는 부분은 최대한 제거하는것이 중요하다.

그것이 하는 사람도 보는 사람도 정말 해야할 일에 집중할 수 있는 방법이다.

너무 많은 것들을 하려고 하면, 정작 중요한것을 하지 못한다.

어떤 것이 중요한지를 아는것은 쉽지 않지만, 

어짜피 우리가 하는일이 쉽지 않은것이다.