일을 하다보면 가끔 문제를 문제로 여기는 사람들이 있다.

그래서 그 문제를 지적하며 이런 저런 이슈와 리스크들을 언급한다. 그런데 그런 언급속에는 그냥 그 사람들 머리속에는 문제일 뿐이다. 그러다보니 문제는 많은데 해결되지 않는 문제만 증가하게 된다.

프로젝트를 하다보면 다양한 Issue와 Risk를 접하게 된다. 아무리 잘 아는 영역이라도 생기지만, 처음해보거나 새로운 도전을 할 경우 이런 상황은 더 많이 발생한다.

그래서 이것을 문제로 인식하는 사람들에게 이런 일을 맡기게 될 경우에는 정말 귀에 피가날 정도로 문제에 대한 다양한 안되는 이유들을 듣게 된다. 하지만 정작 해결을 위한 고민은 하지 않는다. 그들에게는 그건 문제일 뿐이기 때문이다. 그래서 문제가 있으니 접자!!. 하지말자!!! 이런 말들이 마지막에 따라온다. 즉 문제는 해결하는 것이 아닌 회피대상으로 인식한다. 이런 사람들의 특징은 무언가 할 때 문제가 절대 일어나지 않아야 한다는 생각이 강하다.

그러다 보니 문제가 방치되며 일이 진행되기 보다는 정체되거나 지연되는 상황에 직면한다.

반대로 문제를 하나의 해결해야 할 숙제로 보는 사람도 있다. 이 경우는 프로젝트 시작부터 "문제는 일어날 수 밖에 없다"는 생각으로 발생하는 문제를 어떻게 하면 해결할지 고민을 한다. 그래서 문제가 발생하면 우선적으로 원인을 파악하고 해결방법을 찾는다.

새로운 것을 하던, 기존 것을 하던, 어떤 상황에서도 문제 자체를 피하지 않고 해결방안에 최적화 되어 있다. 그래서 이런 사람들이 있는 경우 프로젝트의 이슈들은 단기간에 빠르게 처리되고 방치되는 문제들이 줄어들며 전반적인 Risk는 줄어들게 된다.

모든 사람들이 후자의 영역을 원하지만, 정작 프로젝트를 하면 전자의 영역에 더 많은 사람들이 있다는 것에 놀라게 된다. 전자의 영역에 많은 이유는 개인의 경험, 경력 등에 비추어 문제를 파악하다보니 해결가능한 방법보다는 불가능한 영역으로 인지하는 일들이 많은 이유이다.

새로운 영역이라면 접근과 방법도 새로워야 하지만, 기존의 자신이 가지고 있는 경험에 의존하다보니 과거에 문제가 된 것들이 미래에도 동일한 영향을 줄거라는 확신에 빠지게 된다.

그래서 개인적으로 프로젝트를 하면서 이런 전자의 영역을 후자의 영역으로 전환하는 것에 가장 많은 공을 들인다. 즉 문제는 일어날거고, 그걸 우리는 해결하며 나가면 된다. 단, 문제를 해결함에 있어서의 부담없이 언제든 말해주면 책임지지 않게 하겠다는 메세지를 항상 강조한다.

문제를 바라보는 관점 하나만 바꾸더라도 정말 많은 것이 달라진다. 문제는 문제가 아닌 해결을 통한 성공을 위한 과정의 일부다.

인간의 가장 큰 고민 중 하나인 바로 언어의 차이...

바벨탑 이후 인간에게 온갖 언어로 쪼개지면서 지금의 세상이 되었다는 성경의 내용을 뒤로하고라도 각국의 언어의 장벽을 허무는 것에 많은 관심이 오랜동안 지속되어 왔다.

그래서 과거에는 이런 역관들의 지위는 낮았지만, 권력과 결탁되거나 이권을 확보하는 등의 경제적 영역까지 확대되는 특권(?)을 누렸다.

그런 영역을 지속적으로 노크하는 기업들이 늘고 있다. 이미 구글폰에서는 이런 통역기능을 활용하기도 했지만, 삼성전자의 휴대폰에서 이 기능을 제공한다는 점은 여러 의미가 있다.

그것이 성공의 영역이 아니라도 일단 일정한 수준을 제시할 수 있다면, 새로운 변화의 또 다른 씨앗이 될 것이다. 점점 더 빨라지는 세계화의 속도가 언어의 장벽을 뛰어넘는 순간 과연 어떤 일들이 벌어질지는 상상하는 사람들에게 새로운 기회를 제공해 줄 것이다.

개인적으로 해외 개발업체와 협력하는 상황에서 새로운 영역의 시도와 그에 따른 기회가 점점 증가할 것으로 기대된다.

너무 큰 기대일지 모르지만, 지금의 국가별 다양한 문제들이 언어의 장벽이 허물어지게 될 때 보다 빠르게 해소될 수 있을 것이라는 점과 특히 국가별로 인구불균형으로 발생되는 문제들의 새로운 해결책으로 제시될 수 있는 날이 머지 않았다.

https://v.daum.net/v/20231112191500042

동료평가를 가장 한 저성과자들의 반란이 일어나고 있다.

동료평가는 팀장에 치우친 평가를 완화시키고, 동료들의 평가를 통해서 평가의 공정성을 가지기 위한 방법으로 많은 기업들이 도입하고 있다.

하지만 동료평가의 본질 자체가 왜곡되는 일들이 증가하고 있다. 과거에는 인기투표라는 오명으로 여러 방지장치를 만들고 있었지만, 최근에는 저성과자들의 고성과자를 겨냥한 평가테러가 증가하고 있다.

일반적으로 프로젝트 단위로 관리될 경우 동료평가도 프로젝트 단위로 동료평가를 시행하지만, 국내는 이와 별개로 팀단위로 동료평가를 시행함에 따라서 고성과자와 자신의 성과과 연계되지 않는 곳들은 객관적 업무역량 보다는 자신과의 관계에 의존한 평가를 하게 된다.

이런 경우 고성과자들의 업무스타일에 따라서 평가 결과가 정해진다. 즉, 그 사람의 업무적 역량은 관심없고, 단지 나에게 친철하느냐, 나에게 우호적이냐에 집중하게 된다. 사실 그 사람이 뭘 하는지 디테일하게 모르기 때문에 그저 자신과의 관계에 영향이 있는지만 관심을 갖게 된다.

어디까지나 업무적 역량이 배제되고 단순한 인간관계 중심의 동료평가로 인해서 고성과자에게는 업무 이외의 팀 내 인간관계까지 고려해야 하는 상황에 직면한다.

고성과자들은 업무중심적 성향이 강하다. 그래서 업무에 집중하다보면 관계적 상황은 상대적으로 소원해 질 수 있다. 그런 사람들이 이런 저성과자들의 표적이 된다. 성과는 있지만, 관계가 부족하다는 식으로 공격의 대상이 된다. 결국 자신들의 성과보다 이런 관계로 인해서 평가에 영향을 받는 사람들이 달성한 업적보다는 낮은 평가에 노출된다.

동료평가가 제도적으로 안착되기 위해서는 가중치 부여가 중요하다. 평가 대상자와 평가자의 업무적 연관성을 기반으로 어느정도 밀접한 업무적 연관성이 있는가, 그리고 평가자의 성과가 어떻게 되는가 예를 들어 저성과자인지 고성과자인지에 따라서 평가자의 가중치를 조정하는 것도 검토해 볼 수 있다.

그리고 기업의 인재상과 기업의 성과 그리고 평가의 목적이 구분되어야 한다. 관계만 강조하는 경우 성과보다는 이런 관계적 노력에 집중하는 정치적 일들이 증가하고 그에 따라서 조직간 사일로도 증가하게 된다. 결국 기업의 궁극적 성장의 동력은 관계속에 파뭍혀 버린다.

인성의 문제와 업무적 스타일을 구분해야 한다. 그렇지 않으면 정말 중요한 사람, 특히 회사를 성장시켜줄 사람을 잃을 수 있다. 평가가 단순히 물질적 돈만을 의미하지 않는다. 그 사람의 1년간의 노력에 대한 대답이기 때문이다. 그런 것들이 단순히 관계적 저평가들의 테러에 휘둘려서는 안된다.

변화는 언제나 위험하다. 하지만 해야만 한다.

변화의 끝은 언제나 희망으로 가득차 있다.

만약 변화의 끝이 어둠이라면, 인류는 이미 사라졌을 것이다.

우리가 말하는 변화의 핵심은 인류가 조금씩 앞으로 전진하는 것이다.

그렇기에 변화를 하기위한 노력에는 끊임없이 지속하는 것이 중요하다.

그 속에서 우리는 변화를 리딩할 수 있는 힘을 얻게 된다.

Who uses it?

IT 시스템을 만들 때 가장 많이 드는 생각이지만, 의외로 많이 듣지 않는 질문이기도 하다.

많은 프로젝트를 진행하면서 이 질문을 하는 사람보다는 기술적인 부분에 관심을 갖는 사람들이 대부분이다.

그래서 프로젝트 시작시에 대부분 기술적 요구사항에 집중하고 정작 그것을 사용하는 사용자에 대한 정의와 그에 따른 방향성에 대해서 논의하는 것을 간과한다.

규모가 큰 프로젝트일 경우 업체와 참여자들도 다양해지고 그에 따라서 방향성을 공유하는 일이 그만큼 커지고 있지만, 상대적으로 사용자에 대한 이해가 기술에 대한 관심의 뒷전으로 밀려나고 있다.

프로젝트를 할 때 가장 경계하는 부분도 기술에 빠져서 정작 그걸 사용하는 사용자를 놓치게 되는 부분이다. 사용자들이 원하지도 않는 기능들을 의외로 신기술이라는 명목으로 덕지덕지 시스템에 적용하다보면 정작 기술적으로는 높은 수준이라고 할 수 있지만, 사용성은 떨어지는 상황에 빠지고 만다.

내부인력으로 개발하는 경우라면 그래도 예외적이지만, 대부분의 프로젝트들은 내부인력과 외부인력을 활용하여 프로젝트를 진행하다보면 내부인력들이야 이미 아는 내용이라는 점에서 외부인력들에게 이런 전반적 프로젝트의 상황을 공유하지 않는다.

최근에 프로젝트 일로 베트난 업체와 같이 추진하는 상황에서도 이 부분에서 이해차이가 발생하면서 정작 중요한 개발 방향이 자칫 필요없는 개발로 이어질 수 있었던 아찔한 상황이 있었다.

그만큼 프로젝트의 배경, 사용자구성, 현황 등을 어쩌면 프로젝트 전체인력들과 공유하면서 개발의 목표가 단순히 기술적으로 치우치지 않고, 사용자를 고려한 진정한 시스템을 만들 수 있도록 같이 고민하도록 하는 것이 중요하다.

그래서 강조하는 부분은 기술이전에 UX가 중요하다는 점에 집중한다. 즉 누가 사용할 것이고, 어떤 사람들이고, 이 사람들이 원하는 것들은 이런 것들이므로 개발하려는 것은 이런 사용자들을 인지하고 그들의 UX 관점에서 시스템에 기술을 어떻게 활용할 것인지를 고민하도록 한다.

일전에 어떤 프로젝트에서는 최신기술을 적용하여 시스템을 오픈했으나, 정작 폰트크기가 작아서 사용성 자체가 낮아진 문제로 사용자들의 불만에 직면한 경우가 있었다. 이 문제는 최근 일어나고 있는 기업들의 고령화와 맞물려 있다는 점에서 UX를 간과한 간단한 문제이다.

기술에 치우친 시스템 개발은 기술적 완성도에 몰임된 개발자를 위한 시스템일뿐 정작 사용자는 그 속에 존재하지 않는다. 누가 어떻게 무엇을 할 것인지 기본적인 이해가 중요하고, 그것을 바탕으로 가용성 높은 시스템으로 만들 수 있다.

경청의 한자를 잘 보면 말을 듣는 자세를 어떻게 해야 하는지 알 수 있다.

기울어질 경(傾)은 상대방의 말을 듣기위해서 그 상대방 쪽으로 몸을 기울인다는 의미다. 이것은 듣는 자세 즉 상대방에 말을 적극적으로 듣고 있다는 것이다. 말 하는 사람을 향해서 몸을 기울일정도로 적극적인 자세를 뜻한다

​​들을 청(聽)은 한자에서도 나타나듯이 귀와 눈과 온 마음을 다해서 듣는 것이다. 그냥 건성으로 듣는 것이 아닌 귀를 쫑긋 세우고 눈은 상대방을 보며 마음으로 그 말을 이해하고 공감하는 것이다.

간혹 질문에 다른 답을 하거나 대화 내용과 동떨어진 말을 하는 것은 남의 말을 집중해서 오롯이 듣기 보다는 자신의 생각이 머리속에 꽉차 있어서 말 자체를 이해 못하는 사람들이 많다.

그리고 경청은 상대방의 말만은 의미하지 않는다. 몸짓, 행도, 시선, 표정 등 비언어적 상황에 대해서도 경청이 필요하다.

보고하다보면 말을 망설이는 사람들이 표정이나 행동들로 표현하는 경우가 많다. 이때 비언어적 행동은 포착하는 사람은 보고를 중단하고 상대방에게 질문의 기회를 준다. 말을 망설이던 사람은 자신의 말을 하게되고 그것을 경청함으로써 보고의 수준이 높아진다.

이처럼 경청을 잘 한다는 것은 단순히 말을 잘 듣는것이 아닌 상대방의 모든것에 집중하여 어떤 것을 전달하고 싶어 하는지 명확하게 파악하는 것이 중요하고, 듣고난 뒤 내가 얼마나 당신의 말을 잘 이해하고 공감했는지 표현하면 상대는 자신의 말이 잘 전달 되었다는 생각에 만족하게 된다.

내 생각을 먼저 말하기 보다 상대방의 말을 먼저 듣고 공감한 뒤 말하면 그 효과는 배가 된다. 설득 하지 말고 공감하고 이해하면 자연스럽게 자신의 말에 상대방도 경청하게 된다.

http://www.bizhankook.com/bk/article/25234

시험발사에 국내 언론들은 대부분 실패라 한다

반면 미국은 대단한 시도, 성공적인 테스트라 말한다.

시험발사임에도 국내는 실패라고 하는것을 보면 창업에 대한 인식도 고스란히 뭍어난다.

그래서 우리는 창업이 하나의 훈장이 아닌 교도소의 주홍글씨처럼 여기는 반면 미국은 시도에 대해 높은 점수를 준다.

1차 테스트가 끝나고 7개월만에 다시 쏘아 올린것도 대단하지만 2단분리까지 성공 시켰다는 점에서 그 놀랍다. 이렇게 차곡차곡 쌓은 경험이 이제까지 본적없는 우주시대를 만들것이다.

이미 펠컨 1단로켓 재활용으로 우주시대를 연 일론머스크 이기에 이번 2차 테스트도 실패가 아닌 엄청난 도전에 멋진 성과가 아닐까 생각 된다

우리도 이제는 도전에 박수를 보내고 실패를 통한 성장을 할 수 있는 환경이 필요하다.

https://video.kakao.com/s/442568420

새로운 시스템 또는 기존 시스템을 재구축 하는 경우 간과되는 부분이 바로 오픈 후 운영관리 영역이다.

대부분이 시스템의 오픈에만 초점이 맞추어져 있다. 그래서 오픈때까지 그리고 안정화 기간까지는 다들 관심을 가지지만, 실질적으로 오픈을 하고 난 다음이 관리의 가장 중요한 시점이다.

시스템을 만들 때 설계에 공을 들이며 누락없이 다양한 Needs를 충족시키기 위한 고민을 한다. 그런 고민속에 개발을 통해 시스템이 오픈을 하더라도 실질적으로 만족도는 높지 않은 경우가 많다.

개인적으로 시스템의 구축과 운영의 비율을 50:50 또는 40:60으로 판단한다. 아무리 잘 만들었다고 해도 결국 사용자에게 놓여지는 순간 새로운 접근과 새로운 Needs들이 지속적으로 발생하게 된다.

시스템을 구축하고 오픈한 상황이 50%라고 가정한다면 나머지 50%는 지속적으로 사용자들의 Needs를 수렴해서 완성해나가는 단계로 생각할 수 있다. 일부에서는 시스템 오픈을 100%로 생각하고 오픈하고 끝... 이라는 마인드를 가진 사람들을 종종 만나게 되지만, 이런 경우 운영상황에서의 대응에 대한 준비가 없다보니 다양한 사용자의 Needs를 무시하거나 간과하는 등으로 실질적인 시스템의 사용성은 낮아지거나 기대했던 성능에 미치지 못한다.

시스템을 만들때도 다양한 의견들이 존재하지만 모든 사람들의 Needs를 받을 수 없다. 오픈 후에도 동일하지만, 중요한 점은 오픈 후에도 언제나 새로운 요구가 시스템의 긍정적 요인이라고 판단되는 것들은 지속적으로 업데이트를 실행해야 한다. 그것을 통해서 오픈 이후 나머지 50%의 조각이 채워질 수 있다.

시스템은 살아있는 생물과도 같다. 오픈 시점은 유년기 또는 청소년기의 상태라면 사람들이 사용하면서 점차 성장하게되고 본격적인 성년기까지 만들기 위해서는 지속적인 관리가 필요하게 된다.

그래서 개인적으로는 시스템 오픈 보다는 이후 운영을 가장 많이 고려한다. 의외로 많은 시스템들이 구축시점에 운영을 고려하지 않는다. 오픈이라는 목표만을 향해서 달리는 경주마같이 주변을 보지 않는 것과 같다.

운영을 고려하여 만드는 경우와 운영이 배제된 상태로 만드는 경우의 시스템의 구조는 다르다. 운영이 배제된 경우 시스템 설계부터 단순 구축에만 집중되어 있어서 실제 오픈 이후에 다양한 문제에 대해서 대응이 어렵다. 반면 운영이 고려된 경우에는 오픈 이후에 발생되는 사항 또는 운영 관점의 효율성을 고려한 기능들을 설계부터 적용하여 오픈 후 운영상황에 보다 효율적인 관리가 가능하다.

또한 운영이 고려된 경우는 오픈 이후의 운영비도 예상할 수 있다. 반면 운영이 배제된 경우에는 운영상황이 고려가 되지 못하여 실질적인 운영비의 증가와 안정화기간이 지속된다. 이유는 운영에 필요한 기능들에 대한 추가적 개발이 발생하고, 그에 따라서 안정화 기간은 점점 길어진다.

대부분 시스템 구축 이후 IT고정비가 증가하는 원인도 위와 같다. 특히 시스템 구축이 KPI가 된 경우에는 이 상황이 더 심해진다. KPI로 성과를 달성했다고 생각한 뒤에는 해당 시스템은 방치된다. 생각보다 많은 기업에서 이렇게 방치되며 기업의 비용을 갉아먹는 좀벌래같은 시스템들이 의외로 많다.

시스템의 시장은 오픈일지 모르지만, 시스템의 완성은 운영이다. 얼마나 운영을 사용자 친화적으로 할 것인지, 사용자의 사용성에 맞추어서 진화발전할 수 있는 구조를 가질 것인지, 그리고 언제나 새로운 Needs에 대응할 준비가 되어 있는지... 그것이 진정한 시스템의 완성에 가깝다고 할 수 있다.