한 끗 차이지만 전혀 다른 결과를 낳는 단어(참여/참견, 심플함/부족함)

나는 기획자이기 때문에 일을 하다보면 의사소통을 많이 하게되는데  그 과정에서 비슷한 단어이지만 전혀 다른 결과를 만드는 단어(상황)를 자주 접하게 된다. 특히 참여와 참견의 차이, 심플함과 부족함의 차이는 조직의 결과물 혹은 생산성에 많은 영향을 미치는데 이번 포스팅에서는 작은 차이이지만 전혀 다른 결과를 만드는 이 단어(상황)들에 대한 내 생각을 정리했다.

 

참견과 참여

참견

일반적으로 참여는 어떤 문제가 발생했을 때 그 문제와 관련된 사람들의 자발적인 의사로 이루어진다. 그들은(참여자들) 문제를 정확히 알고 있고 해결점을 도출하기 위해 회의를 한다. 물론 그 문제와 직접적인 관련이 없는 사람도 해결방법에 대한 아이디어를 제안함으로서 참여를 할 수 있다.

문제는 어떤 이슈가 발생했을 때 참견을 하는 사람들이다. 참견을 하는 사람들은 해당 이슈에 대한 문제점을 모른다. 그리고 문제점을 모르기 때문에 당연히 아이디어도 없다. 따라서  갑자기 참견하는 사람이 회의에 끼어들면 지난 의사소통 과정이 되풀이 된다. 그리고 이 과정에서 대부분의 참견자들은 이미 기존 참여자들이 냈었던 아이디어를 제안한다. 그런데 그 아이디어로는 해결이 되지 않기 때문에 기존 참여자들이 계속 회의를 진행하고 있는 것이다. 그러면 결국 참여자 중 누군가 한 명은 참견자에게 그 아이디어로는 왜 해결이 안 되는지 또 설명을 해줘야 한다. 결국 이러면서 성과없이 회의시간은 길어진다.

내 경험에 의하면 대부분의 참견은 고위 직급의 사람에게서 시작된다. 그리고 그들의 첫 마디는 대부분 이렇다.

“문제가 뭐야? 뭔데 그렇게 다들 고민하고 있어?”

100%는 아니겠지만 고위 직급의 누군가가 당신이 회의하고 있는 사안에 대해서 위와같이 이야기를 꺼낸다면 당신의 비생산적인 회의는 시작되었다고 보는 것이 좋다. 그리고 이런 비생산적인 회의는 참여자들의 문제해결 의지를 꺾어 놓는다.

한 가지 분명한 것은 조직원들이 참여와 참견의 차이를 인식하는 것 만으로도 조직의 생산성은 달라질 수 있다는 것이다. 참여는 문제해결에 대한 의지를 돋구지만 참견은 문제해결 의지를 꺾어버린다.

 

 

심플과 부족함

simpleisthebest

애플의 아이폰이 성공하면서 IT업계에서 가장 쓰이는 말 중에 하나가 ” Simple is the best “이다. 물론 맞는 말이다. 그런데 이 심플함이라는 것이 참 애매하다. 누군가의 심플함은 다른 누군가에겐 부족함이 될 수 있기 때문이다.

내 경험상 웹서비스 개발에 있어서 심플함을 가장 많이 강조하는 사람은 개발자들이었다. UI를 직접 디자인하는 디자이너나 기획자들이 심플함을 강조할 것 같지만 오히려 디자이너/기획자들은 심플함을 단순하게 받아들이지 않는다. 왜냐하면 심플한 UI는 결국 엄청난 아이디어를 필요로 하기 때문에 그만큼 아이디어 구상에 많은 시간이 필요하기 때문이다. 이것은 마치 글을 길게 쓰는 것보다 짧게 간추려서 쓰는 것이 더 어려운 것과 비슷하다.

그렇다면 개발자들은 왜 심플함을 강조하는 것일까? 개발자들에게 있어서 심플함은 코딩과 관계가 있기 때문이다. 즉 개발자들에게 있어서 심플함은 코드의 간결함으로 직결된다. 예외사항이 많아지거나 특정 상황에만 필요한 기능이 많아질 수록 코드가 지저분해지기 때문이다. 그래서 시스템이 단순해지면 코드도 깔끔해질 것이라는 생각을 하게 되는 것이다.

그런데 사실 UI가 심플해질수록 코드는 더 더러워질 가능성이 많다. 예를들어 웹페이지에 3개의 버튼이 있다고 가정하자. 그리고 각 버튼을 클릭할 때마다 다른 기능이 실행된다. 총 3개의 기능이 있는 것이다. 그런데 사용성을 단순화 하기 위해  기존 3개의 버튼을 1개의 버튼으로 줄였다. 그러면 개발사항은 어떻게 바뀔까? 개발자는 사용자가 버튼을 클릭했을 때 3개의 기능중 어떤 기능을 원하는지 판단하는 로직을 추가로 개발해야 한다. 그리고 그 로직에는 생각보다 많은 IF문이 들어갈 수 있다. 그러다보면 결국 일부 개발자들은 3개의 기능이 전부 필요한 기능은 아닌것 같다고 하면서 다시 한 번 심플함을 강조하기 시작하고 기능을 빼자고 제안하기 시작한다.

그래서 나는 개발자들이 말하는 심플함을 그대로 믿지 않는 편이다. 그 이유는 그들의 그런 상황을 이해하기 때문이다. 절대로 개발자들의 의견을 무시하는 것이 아니다. 나도 조금이나마 코딩을 해보니 깔끔한 코드를 작성하고 싶은 욕구가 생기는 것을 강하게 느꼈기 때문에 개발자들의 그런 심정을 이해하는 것이다. 그리고 깔끔한 코드를 위해서는 그 만큼 시간이 많이 필요한데 알다시피 개발자들에겐 그럴만한 여유가 없다.

결론적으로 심플함에 대해서 생각을 할 때는 이것이 정말 심플한 것인지 아니면 부족한 것인지에 대해서 냉정한 판단이 필요하다. 심플함이 지나치면 사용자들은 부족함으로 느끼게 될 것이기 때문이다.

 

 

 

0 Shares:
답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

You May Also Like
Read More

기획자와 스토아철학

기획자로서 일을 하다보면 생각보다 많은 부분에서 우울할 때가 있다. 그 우울함이 심해지면 '나는 과연 필요한 존재가 맞는가?'라는 생각까지 들곤 한다. 문제는 이런 경험을 자주 할수록 자존감이 낮아진다는 것이다. 내가 겪어온 경험을 토대로 이 문제를 어떻게 극복했는지 이야기하고자 한다.
Read More

내 리더가 회사를 떠났다.

어떤 한 사람이 있다. 그 사람을 보면서 나는 이런 생각을 했다. "저 분의 인성과 역량을 닮고 싶다. 내 아들이 커서 어른이 된다면 나의 모습보다는 저 분의 모습을 닮았으면 좋겠다." 그 분은 내가 현재 재직중인 회사의 CTO이자 나의 리더였다. 아이러니하게도 그 분과 나는 전혀 다른 성격의 소유자이고 업무 스타일도 많이 달랐다. 하지만 난 정말로 그분을 닮고 싶었다.
2021년 회고
Read More

2021년 회고(Product Owner, 가족, 성장)

회사에는 동료와 일이 있다. 가정에는 아내와 애들, 육아업무가 있다. 그러나 그 어디에도 나는 없었다. 원래 나 본연의 내가 존재할 수 있는 시간과 장소는 없었다. 단지, 의무로서의 나만 존재했다. 언뜻 생각해보면 참 서글프기도 하지만 잘 생각해보면 꼭 그렇지도 않다. 현재 나의 상황, 역할, 가족, 일.....그 모든 것이 결국은 나를 구성한다. 원래 나 본연의 나는 처음부터 없는 것인지도 모르겠다.