탁구 팀 vs. 배구 팀

탁구 같은 팀이라.

분명 같은 팀일텐데 문제나 이슈를 마치 탁구공을 넘기듯 상대방에게 넘긴다.

> 제 문제는 아니네요.
> 전 문제 없어요.
> 전 잘 처리했어요
> A 담당자가 봐야해요.

배구 팀은 그렇지 않다. 하나의 문제에 대해 서로 같이 확인한다.(어찌 보면 탁구 팀처럼 공을 남에게 떠넘기는 것처럼 보일 수 있지만 ㅎㅎ) 점수를 얻기 위해 공을 받고, 토스하고, 스파이크를 때리 듯 서로 같은 목적을 가지고 함께 노력한다. 얼마나 아름다운 모습인가…

보면 볼 수록 우리 팀은 탁구 팀이다.

꼬랑지) 배구 팀도 어찌 보면 문제점을 팀 단위에서 단체로 다른 팀으로 넘기는 것처럼 보일 수도 있겠다 🙂

소통의 문제는 여기에도

요즘 “소통의 부재”가 유행이다.

그런데 그 “소통의 부재”가 청와대와 국민 사이에만 있는 것은 아닐 것이다.

회사 내의 “소통의 부재”는 참 많은 생각을 하게 한다.

Agile에서 적극 추천하고 있는 “Stand-up meeting”을 시행하고 있다. 시작한 지 1년이 훨씬 넘은 듯하다.

하지만 한 번도 Agile에서 기대하고 있는 것처럼 적극적인 의사교환이나 정보 교환을 본 적이 없다.

늘 대장 노릇을 하는 사람이 주절주절 이야기를 하고, 나머지 사람들은 땅을 보거나 모니터를 보거나 가끔은 대장을 보거나.

피드백? 그런 거 별로 없다.

게다가 대장이 해주는 이야기는 대부분 진행 중인 과제의 “문제점”인 경우가 많아 듣기에 썩 좋은 이야기는 아니다. 타산지석으로 삼으면 좋겠지만 아쉽게도 전달하는 사람은 항상 “저런 저런 문제가 있었다. 우리는 이게 문제다”가 논지이기 때문에 과히 듣기 좋지는 않다. 맞는 이야기겠지만 비슷한 톤으로 비슷한 논지의 이야기를 주 5일 듣는다고 생각해 보자. 끔찍하지 않은가? 이건 마치 예전 5공때 9시 뉴스에 앵커나 늘 “오늘 대통령 각하는”으로 시작하는 기사를 매일 보도하는 거랑 다를 바가 없다.

아쉽다.

같은 이야기를 하더라도 조금만 다른 투로 친근하게, 때로는 능글맞게, 그리고 피드백을 쉽게 할 수 있는 분위기를 만들면서 한다면 좋겠는지.

그런 분위기를 만드는 게 쉽지는 않겠지만 노력을 안하는 듯 하니.

여기도 “소통”의 문제가 심각하다.

“소통”이 없으니 “팀 웍”을 꿈도 꾸지 못하고, 남이 뭐 하는 지 알 수도 없다.

날 위한 서비스 하나

웹에서 얻은 자료를 잘 공부해 머리 속에 넣어주기 보다는 일단 쌓아놓고 보는 -_-

덕분에 그저 쌓아놓고 정리도 못하고 있는 나에게 꼭 필요한 서비스.

http://www.laterloop.com/

일단 괜찮아 보이는 사이트를 만나면 laterloop bookmarklet이나  add-on을 이용해서 저장해 둔다. 그럼 그 내용이 내 계정의 current에 저장된다. 편리하게도 open ID 처럼 google 계정을 공유할 수 있어 별도로 가입할 필요는 없다.

그리고는 나중에 laterloop 홈페이지에서 차근 차근 정리하면 된다. 버릴 건 버리고 저장할 것은 저장하고.

꽤 쓸만한 사이트.

특히 맘에 드는 것은 bookmarklet이나 firefox plugin을 클릭하면 잠시(1-2초)정도 화면에 뭔가 변화가 살짝 나타났다 이내 원래대로 돌아온 다는 것. 즉 간단히 클릭만 하면 끝이라는 점이다.

참고) 제작사 FAQ에 보면 비슷한 서비스를 몇 가지 드는데 그 중 하나가 instapaper다. 이곳 역시 아주 simple한 UI를 보여준다. 사용해 보니 이것 역시 무척 간단하다.

log activity with launchy

1. make a directory named c:scratch

2. create a python script log.py and save the same directory
import time
import sys

now = time.localtime(time.time())
tim=time.strftime(“%Y/%m/%d %H:%M:%S”, now)

fp = open(“c:scratchmyLog.txt”, “a”)
message = ” “.join(sys.argv[1:])
print >>fp, tim+” “+message

fp.close()

3. register that directory and *.py in launchy category and rescan

4. Restart launchy

5. invoke launchy and type “log” and type tab

6. jot down log message and enter

Reference
http://benkraal.wordpress.com/2007/05/16/launchy-append-text-to-a-file-from-anywhere/

이건 아니잖아~

몇 번을 버텼더니 결국 하는 이야기.

씩수시구마가 임원 평가에 들어간다. 만약 니들이 안 해서 임원 평가가 나쁘면 임원이 본인 점수가 왜 나쁜 지 볼 거고, 그러면 결국 너한테도 좋을 거 없다.

씩수시구마를 이용해 업무의 생산성을 높인다는 등의 그럴 듯한 소리가 아니라 아주 대놓고 이야기를 하는 거다. 저게 무슨 업무 진행이냐. 고과를 무기로 협박하는 거지.

또 본질은 사라지고 껍데기만 남았구나.

제발 누가 좀 말려줘요. 씩수시그마가 소프트웨어 얼마나 잘 맞는 건지 좀 알려달라고

제일 고래잡는 데 호미들고 설치지 말아라.

How to be an expert

끊임없이 개선하려고 노력하고, 새로운 더 좋은 방법을 찾는 것.

[How to be an expert](http://headrush.typepad.com/creating_passionate_users/2006/03/how_to_be_an_ex.html)

관리자가 잘못 생각하는 착각들

via 관리자가 잘못 생각하는 착각들

착각1 : 하나를 알려주면 열을 안다.

착각2 : 회식을 하면 침체된 분위기가 좋아진다.

착각3 : 사람을 중시하는 경영을 하고 있다.

착각4 : 물질적인 보상은 직원들을 열심히 일하게 한다.

크.. 부서내 위키를 재정비하고 있는데 이런 글을 올려놓으면 관리자들이 어떤 반응을 보일까?

중국 정부처럼 위키를 검열하려고 들까? 하긴 그럴 마음이 있어도 그럴 필요가 없겠지. 그냥 불러서 말 한마디를 하지 않을까?

Positive Retrospective

우리는 왜 긍정적인 회고를 하지 못하는가?

  • 짜증스런 목소리로 “왜 잘못했냐고?” 소리치는 매니저가 만들어 놓은 아픈 상처때문에?
  • 짜증스런 표정으로 의자에 엉덩이를  걸치고 앉아 핸드폰 게임만 하고 있는 개발자들때문에?
  • 해봐야 소용없다는 회의적인 생각때문에?
  • 얄팍한 자존심때문에? 이미 패치내서 지난 간 일을 들쳐내기 싫어서?
  • 왜 회고를 맨날 골방에서 큰 소리를 내가면서 해야 할까? 왜 밝은 장소에서 할 수 있는 분위기가 안 되는 걸까?

우리는 안 하는 걸까? 못하는 걸까? 둘 다 겠지.

어떻게 하면 바꿔갈 수 있을까?

내가 희망하는 개발팀 문화를 가진 회사

예전에도 한번 “잔업없는 회사”라는 내용으로 접한 적이 있었는데 우연히 어떤 글을 보고 다시금 찬찬히 그 회사의 글들을 보게 되었다.

(주)사이냅소프트

많은 IT업체가 그렇듯이 회사의 생활등을 블로그를 통해 접할 수 있다(우리도 IT업체인듯 한데 그러기엔 우린 엄살이 너무 심하지. 뭐 그리 숨길 게 많다고)

그 중에는 사이냅소프트의 전경헌 사장님과의 인터뷰 글도 볼 수 있는데 사장님의 생각을 통해 회사의 생활이 어떨 지 짐작할 수 있다(반론의 여지가 있는 말이긴 하다. 윗사람의 생각대로 회사가 움직인다고 단정지을 수 없기 때문이다. 구름 위에 있는 사람이 갖는 생각과 현실은 다를 수 있으니. 그래도 일단 들어보자)

그 중 일부다.

유용빈: 정치적 스트레스는 어떻게 해결하시나요.
회 사 내에 그런 스트레스가 얼마나 있는지 제가 잘 알지는 못합니다만 다른 회사에 비해서는 상대적으로 적으리라 생각합니다. 개발자들이 지원하는 역할에 머무르는 회사가 많은데 사이냅소프트는 저부터 시작해 영업 직원들도 개발자 출신이라 서로 이해하는 부분이 많아 갈등이 크지는 않습니다. 또 지난해 애자일 컨설팅의 컨설팅을 받으면서 회고하는 문화가 자리잡고 있습니다. 회고란 체계적으로 즐겁게 반성하고 개선점을 찾는 활동인데 그 이후로는 회사에 있던 문제들에 대해 서로 동등한 수준에서 의사 소통을 하면서 그와 같은 스트레스가 더 줄고 있다고 봅니다.

이국진: ‘가정을 지키기 위해 일찍 퇴근한다’는 글을 쓰셨는데 정시 퇴근은 잘 지켜지나요.
그 글은 2005년에 쓴 글입니다. 전에는 일을 굉장히 많이 했습니다. 결혼하고 나서도 아침에 일찍 출근하고 막차 시간이 거의 다 됐을 때나 새벽에 집에 들어갔습니다. 집에서는 잠만 자고 휴일에도 회사에 나와 일하기도 했습니다. 거의 일만 하는 사람이었죠. 일로서 성공하고 싶은 생각도 많았고요. 2005년은 큰 아들이 유치원에 다니던 해였는데 밥 먹으면서 유치원 생활에 대해 아들에게 물었는데 아이가 대답을 하지 않았습니다. 아내가 대신 이야기를 해줬지만 아들에게 직접 듣고 싶다고 말을 거니 아이가 “아빠는 알지도 못하면서 아는 체 해”라고 말했습니다. 그러고 보니 아이가 보기에는 자기가 일어나기 전에 회사에 나가고 자고 있을 때 집에 들어오니 자신에 대해 아무것도 모른다고 생각하는 게 당연하겠더군요. 물론 아내를 통해 아이가 어떻게 지내는지 늘 듣고 있었지만요. 굉장히 충격을 받았고 이게 제가 원하던 삶은 아니라는 걸 깨달았습니다. 아이가 태어날 때만 해도 크는 동안 많이 안아주고 좋은 이야기를 들려주고 싶었는데 열심히 일하다 보니 어느새 아이는 자라 학교 갈 나이가 되어 있더군요. 세상은 장기전이고 그러려면 가정도 지켜야 하고 저뿐만 아니라 직원들도 마찬가지라는 생각이 들었습니다. 그 때부터 열심히(?) 저녁에 일찍 퇴근하고 있습니다. 아이들이 굉장히 좋아하고요. 요즘은 간혹 집에서 저녁 먹고 들어오라는 전화가 옵니다.(웃음)

오랜 기간 몸에 밴 야근이란 습관을 되돌리는 데 반발은 없었나요.
야 근을 하느냐 하지 않느냐가 좋은 개발자를 판단하는 기준은 아닐 겁니다. 책임감이 굉장히 강한 개발자들은 맡은 일이 진전되는 것을 확인하려고 야근을 하기도 합니다. 야근 금지를 반대하는 개발자들도 있었습니다. 회사에서 뭐라 하든 ‘내 일이기 때문에’ 야근을 해도 상관 없다는 이유 때문이었죠. 소프트웨어 개발은 장기전이고 몇 달 바짝 해서 성공하는 게 아니기 때문에 자신의 건강과 가정을 지키며 일하자고 계속 설득해 지금은 야근 금지가 많이 정착되어 특별한 일이 있지 않는 한 다들 일찍 퇴근합니다.

지금도 개발을 하시나요.
예. 수시로 하고 있습니다. 직원들이 개발을 하다 문제에 부딪히면 같이 살펴보기도 하구요. 프로그래밍 공부도 꾸준히 하고 있습니다. 제품 코딩보다는 직원 교육을 위한 코딩 위주로 하고 있습니다. 최근에는 파이썬을 많이 쓰는데 아이디어가 떠오르면 파이썬으로 빠른 시간 안에 구현할 수 있어 직원들이 어떤 문제에 막혔을 때 그것을 푸는 데 도움이 될 만한 코드를 파이썬으로 짜서 보여주기도 합니다. 개발이 여전히 좋아 은퇴 후에도 코드를 짜는 걸 즐기지 않을까 합니다.

앞으로 구상이 있으시다면 소개해 주세요.
지 금까지 한국 소프트웨어 개발사들을 보면 유명 개발자 한두 명에게 크게 의존하는 경우가 많았는데 그런 방식에는 한계가 있다고 봅니다. 문화를 잘 가꾸며 체계적으로 개발을 하는 회사가 성공하는 사례가 나와야 할 것 같습니다. 좋은 소프트웨어를 만드는 데 필요한 것이 있다면 기꺼이 받아들여 배우고 적용할 계획입니다.

또 다른 글,

다양한 기능은 어떻습니까? 마이크로소프트 오피스에는 수없이 많은 기능이 있습니다. 그러나 우리가 사용하는 기능은 매우 단순한 몇가지에 지나지 않습니다. 그 많은 다양한 기능은 어디다 쓰는 것이죠? 그 기능들을 개발하느라고 수없이 많은 개발자들이 시간을 쏟아 부었을텐데… 우리한테 어떤 의미가 있습니까? 사실상 거의 의미가 없죠. 일반인들이 워드에서 XML로 저장하는 기능을 사용할 일이 있겠습니까? 엑셀에서 포아송분포를 계산할 필요가 얼마나 있겠습니까? 그러한 다양한 기능들은 영업을 위한 자료에 사용될 문장 몇개 만드는 것 이상의 용도가 없습니다. 핵심기능이 잘되는 것이 훨씬 중요합니다. 일정과 기능도 무시 못할 요소이기는 하지만, 결코 품질보다 중요하지는 않습니다.

먼저, 정치적 환경입니다. 이건 언제나 발생하고 가장 골치아프고, 해결하기 어려운 것 중에 하나 입니다. 팀장이상 급에서는 어느 정도 신경을 쓸 수 밖에 없죠. 정치적 환경에서 발생하는 문제는 임원들에게 알려주세요. 임원들이 해결하도록 하겠습니다. 정치적 환경 때문에 골치아파 하지 마십시오. 임원들이 해야하는 역할 중에 하나가 정치적 문제를 없애는 것입니다.

두번째로는 기술적 환경이 있습니다. AIX에서 돌아가는 프로그램을 짜야하는데 AIX가 없으면 안되겠죠. PC가 2대 있으면 금방 해결할 수 있는 문제라면 한대 더 사야겠구요. 지금 쓰고 있는 컴퓨터가 느려서 컴파일시간이 오래걸리면 바꿔야죠. 메모리가 부족하면 늘려야겠구요. 기술적인 환경은 약간의 비용을 들이면 쉽게 해결이 가능합니다.

우리 인트라원 자유게시판에 보면 “빌게이츠 찾아가는 법”이라는 제목으로 지도 3장이 올려져 있을 것입니다. 아마 관심있게 본 사람들은 알 수 있었겠지만 마이크로소프트 메인 캠퍼스의 대부분 건물들은 십자(+)형이나 에이취자(H)형으로 되어있습니다. 우리나라 건물들이 대부분 박스(ㅁ)형인 걸 생각하면 매우 특이한 것입니다. 마이크로소프트 메인 캠퍼스에도 박스형 건물들이 몇개 있지만 강당 등 공통 공간인 경우입니다. 직원들이 일하는 공간은 대부분 십자형과 에이취자형 건물입니다. 박스형건물이 건축비가 싸게 먹힌다는데… 왜? 십자형과 에이취자형으로 건물을 지었을까요? 십자형과 에이취자형 건물의 특징은 좁은 복도와 복도 양쪽으로 창이 딸린 방을 배치할 수 있다는 것입니다. 즉, 마이크로소프트는 메인 캠퍼스에 근무하는 모든 사람에게 창이 딸린 작은 방(1인실 또는 2인실)을 주고 있습니다. 너무 돈이 많아서, 돈질을 하는 걸로 보이나요? 빌게이츠씨가 헛 돈 쓰는 거 봤습니까? 차라리 기부를 하면 했지, 과시를 위해서 돈쓰는 건 아닐 겁니다. 또, 빌아저씨쯤되면 과시하지 않아도 누구나 인정하는 세계에서 제일 돈이 많은 사람이잖아요. 빌아저씨가 소프트웨어 회사에서 생산성과 품질을 높이는 가장 좋은 업무 환경을 연구해서(연구비줘서 시켰겠죠) 실현한 것이라 생각합니다.

자, 어떤가?

흔한 말로 생각이 바로 박혀있는 것처럼 보이지 않는가? 어떤 회사의 사장이란 사람이 저런 위험한(?) 말을 할 수 있을까? MS의 건물 배치에 대해서는 피플웨어에서도 언급했던 내용인데 우리 회사 매니저중에 얼마나 많은 사람들이 그 책을 봤을까? 내 근처 사람중에 단 한 사람이라도 본 적이 있을까?(이런 S/W 생산성에 관한 책을 정리해서 공유 해볼까?)

구글 리더에 등록했는데 최근 10개만 보여서 열심히 블로그 페이지에서 직접 글들을 읽고 있다. 볼만한 내용이 너무 많다.

다만 블로그에 댓글이 그리 많은 편이 아닌 것이 아쉽다.

과연 우리 회사는? 우리 회사 역시 세상이 좋다고 하는 것 중 몇 개는 따라 하려고 한다. 다만 항상

  • Top-down
  • 수치를 통관 관리
  • 안하면 갈금

의 형식을 갖는다. 왜 해야 하는 지에 대해 충분히 설명하고(당연한 것도 있겠지만) 자발적으로 하는 문화를 만들기 보다는 늘 명령하달식으로 진행한다. 위키를 설치해서 사용하는 것을 몇 번 보여줬는데 맘에 들었나 보다. 위키를 많이 사용하라고 권고하기 시작했다. 조만간 주간별 포스팅 수등을 관리하면서 1인당 포스팅 갯수를 할당하지 않을까 걱정이다 -_-

너무나 이기적인 개발자

옆 부서는 신입사원이 들어오면 기존 블럭에 대한 F/U을 시키는 것이 아니라 무조건 Test 작업부터 할당한다. 그래서 옆에서 보기에 참 불쌍(?)하다는 생각을 많이 했다.

Test 업무라는 것이 내가 만든 것이 아니라 대부분 남이 만들어 놓은 것을 대상으로 하는 지라 나름 부품 꿈을 안고 “개발자”의 길을 선택했는데 그것과는 사뭇 다른 일을 하고 있으니 어찌 흥이 나겠는가?

얼추 보면 최소 6개월에서 1년동안 이런 일을 한다.(리더가 특별히 계획을 가지고 이렇게 진행하는 것인지는 모르겠다. 아무래도 그 분이 그럴 것같지는 않고)

개인적으로 이렇게 하는 것에 그리 공감하는 편이 아니었는데 이번에 출장와서 겪은 일을 계기로 다른 생각이 들었다. 바로 “역지사지”, “사용자 입장에서 바라보기”가 그것이다.

많은 실은 대부분의 개발자들은 코딩을 할때 자신의 관점에서 작업한다. 자신의 관점이라 하면 어떤 방법을 사용하던 자신에게 주어진 요구사항에 맞게 프로그램이 동작하게 만드는 것이다. That’s it.

당연히 코딩하고, 시험하면서 필요한 부분을 확인하기 위해 로그 메시지도 출력하고, 상태 확인을 위한 디버깅 기능도 추가한다. 하지만 이런 것은 거의 100%가 자신을 기준으로 한 것이다. 즉 누구보다 해당 블럭을 잘 알고 있다는 것을 바틍으로 로그나 디버깅 기능을 추가하는 것이다.

그런데 정말 로그나 디버깅은 개발자 자신만 사용하는 것일까? 만일 그 사람이 다른 업무를 맡게 되었다면? 만일 퇴사했다면? 갑자기 동작에 문제가 있는데 연락이 안된다면? 담당자가 있는 곳이랑 전혀 반대의 시간대에서 문제가 발생했다면?

결코 로그나 디버깅 기능은 개발자를 위한 기능이 아니다. 개발자(담당자) 자신을 포함한 많은 사용자를 위한 기능이다.

그렇다면 어떻게 해야 할까?

쉽고 직관적이어야 한다.

당연한 이야기다. (대부분의 경우) 쓸데없는 소스 파일 이름, 함수 이름, 라인수를 찍어 로그를 지저분하게 하지 말고, 단순하게 error 문이나 Return -1 같은 거의 무의미한 내용을 출력하지 말고, 16진수를 0x도 없이 찍지 말고, 16진수를 10진수로 출력하지 말고, 디코딩이 필요한 값을 단순하게 숫자로 찍어서는 안된다.

한가지 정보를 얻기 위해 사용자가 몇 번의 명령어를 입력하게 해서는 안된다. 개발/시험 중에는 고작해야 1-2군데에서 그 명령어를 치겠지만 현장에서는 단위가 달라진다. 몇 십번에서 몇 백번 똑같은 명령을 입력하는 경우도 있다. 이런 어처구니 없는 불편함은 누구 잘못이겠는가? 모든 것이 자신을 기준으로 자신만을 생각하고, 사용자를 생각하지 않는 개발자 잘못이다.

그럼 처음에 왜 신입사원에게 Test 업무부터 시키는 것에 대한 생각이 바뀌었는지 답이 나온다. 바로 다른 사람이 만들어 놓은 불편한 로그/디버깅 기능을 체험하라는 것이다. 내가 다른 사람이 만들어 놓은 지저분한 로그를 분석할 때도 있고, 불편한 디버깅 기능을 이용해 봐야 정말 다른 사용자의 심정을 조금이라도 이해할 것이라고 생각하기 때문이다.

정말 부서내에 게시판을 하나 만들어놓고 다른 사람의 로그나 디버깅 기능을 이용하면서 느낀 불편한 점을 공유했으면 좋겠다. 모든 불편한 점을 해결할 수는 없을 테니 주기적으로 게시판에 올라온 것중에서 꼭 필요한 부분을 골라 activity로 잡아 개선하는 작업이 있으면 좋겠다.

그리고 시험 인력은 로그가 부정확하거나 불편한 점 역시 개선요구사항을 개발팀에 feedback을 줄 수 있는 분위기/체계가 있었으면 한다. 제대로 기능 동작은 기본이 아닌가? 단지 제대로 동작하는 것 그 이상을 목표로 삼아야 한다.

많은 경우 제대로 되지 않는 management나 process를 욕하는 경우가 많다. 하지만 시간이 가면 갈수록 결국 문제점은 개발자의 태도라는 생각이 든다. 개발자의 능력이 아니라 태도.

꼬랑지) 그래서 읽고 싶은 책. “소프트웨어, 누가 이렇게 개떡같이 만든거야” 중 (via Inuit Blogged)

geek들의 지적 만족을 위한 프로그램이 아니라 제품으로서의 소프트웨어를 만들어야 합니다