http://opnote.tistory.com/33 여기에서 발췌함. 배울 것이 있어 보인다. 한번 읽어봐야겠다. HARD CODE 에서 재미있었거나 곱씹어 봐야 할 내용을 정리해본다면 기본적으로 일정 예측에 리히터 척도(Richter scale)를 사용. 예측이 조금 빗나가는 것은 신경 쓰지 않는다. 대신 중간목표 점검일로 긴장감을 심어주고 보통 재미없는 ‘반드시 출시할’ 기능 목록을 반드시 밝혀서 이 기능을 완료했을 때, 개발자에게 재미있는 일을 할 수 있게 했다. 이렇게 동기 부여. 합의가 어렵고 사적인 감정이 개입돼서 만장일치가 무리인 모임에선 반대자가 없으면 통과하는 ‘퀘이커’식 합의를 사용. 회의. “왜 모였죠?” “목적이 뭐죠?” “저 사람들은 왜 참석했죠?” “왜 이제서야 말하죠?” “다음..
개인적으로 아는 사람을 관리하는 게 더 힘들다. 먼저는 공사를 구분하지 못할 때가 종종 있다. 직급 차이가 나도 특히 나이가 같다면 아무리 약속을 해도 이게 잘 안된다. 특히 객관적인 실력을 증빙할 수 없는 사람일수록 이게 심하다. 그럼, 가능하면 뽑지 말고 혹 뽑더라도 함께 하지 말아야 할 것이다. 어쩔 수 없이 함께 하게 되었다면 기대하지도 말자. 왜냐하면 나이, 직급, 업무가 다 차이가 나도 정작 상대방이 업무를 못할 수 있기 때문이다. 협업이 잘 안되서, 개인적인게 깨어지기 쉽다. 그래서 혹시 회사에서 개인적으로 아는 사람을 뽑는다면, 직접 부딪히지 않는 부서에서 뽑는 것이 상책이다. 물론 아는 사람이 객관적인 증빙이 있다면, 함께 일하는게 좋을 것이다. 사람을 뽑았다면 무엇보다, 왜 그 사람을 ..
다음 글(http://gurugio.blogspot.com/2010/03/blog-post_07.html)에 동감한다. 이걸 쓰분은 자기만의 OS 를 만들고 있다. 참 부럽다. 완성도는 나중이고 일단 발걸음을 떼자. 공부위해서거나 포트폴리오를 준비하기 위해서 개인 프로젝트를 기획하고, 개발하는 사람이 많은데 어떻게 관리를 하시는지는 모르겠다. 내가 생각하기에 개인 프로젝트를 오랫동안 유지하고, 꾸준히 개발하기 위해서는 몇가지 준비 사항이 있어야 한다. 특히 바뻐서 신경쓰지 못하다가도 시간이 생겼을때 다시 착수하기 위해서 개발 환경에 대한 준비가 철저해야 한다. 1. 소스 관리: 회사에서나 집에서나, 아니면 산속에서라도? 틈날때마다 개발하기 위해서 인터넷으로 소스를 관리할 수 있어야 한다. 구글 코드나 네..