꿈을 날짜와 적으면 목표가 되고, 목표를 나누면 계획이 된다. 그 계획을 실행하면 꿈이 현실이 된다. 

서태지와 아이들, 이주노

http://opnote.tistory.com/33 여기에서 발췌함. 배울 것이 있어 보인다. 한번 읽어봐야겠다.

HARD CODE 에서 재미있었거나 곱씹어 봐야 할 내용을 정리해본다면

• 기본적으로 일정 예측에 리히터 척도(Richter scale)를 사용. 예측이 조금 빗나가는 것은 신경 쓰지 않는다. 대신 중간목표 점검일로 긴장감을 심어주고 보통 재미없는 ‘반드시 출시할’ 기능 목록을 반드시 밝혀서 이 기능을 완료했을 때, 개발자에게 재미있는 일을 할 수 있게 했다. 이렇게 동기 부여.
• 합의가 어렵고 사적인 감정이 개입돼서 만장일치가 무리인 모임에선 반대자가 없으면 통과하는 ‘퀘이커’식 합의를 사용.
• 회의. “왜 모였죠?” “목적이 뭐죠?” “저 사람들은 왜 참석했죠?” “왜 이제서야 말하죠?” “다음 단계는 뭐죠?”
• 명세서는 그만 쓰고 기능팀을 한곳으로 모으자. PM이 기능팀과 같은 공간에 온종일 같이 있어준다면 명세서가 필요한가?
• 명세서의 요구 사항은 테스트할 수 있는 항목이어야 한다. 테스트할 수 없다면 잘못 쓴 것이니 테스트할 수 있도록 다시 작성.
• 테스터는 개발자가 온 힘을 다해도 놓치는 문제를 잡아내 고객을 보호하는 사람
• 코드 검토는 목적이 명확해야 한다. ‘아이디어와 해결책 찾아내기’ ‘진행 중인 작업에 대한 피드백 받기’ ‘완료한 작업의 품질을 진단하고 문제 찾아내기’
• jpg 파일을 복사해서 붙였을 때와 마우스로 끌어다 떨어뜨렸을 때 동작이 다르다. 크, 마소도 이렇구나. DRY(Don’t Repeat Yourself)는 진리. 여러 명이 개발하다 보면 예상하지도 못하게 발생할 수 있지만 이런 건 모두가 병적으로 싫어하고 장인 정신을 가져야지만 극복할 수 있다.
• 독립성을 제공할 정도로만 하향식 설계. 협력과 품질을 최적화할 정도로만 상향식 설계
• 눈에 띄고 좋은 평가를 받는 기능을 구현하는지는 개발자 스스로의 책임. 고객과 비즈니스를 아는 수완 좋은 개발자 몫. 스스로 어떻게 하느냐에 달림
• 아무리 좋은 아이디어를 낸다고 해도 이해하고 인정하려면 시간이 걸린다. 게다가 아이디어도 쏟아지기 때문에 인맥이 없다면 다른 아이디어에 우선순위가 밀린다. 내 아이디어를 인정받으려면 내 아이디어를 인정할 사람들과 관계를 맺어야 한다.
• 협상이 끝나면 이긴 팀으로 모두를 포용. “이게 바로 우리가 만든 멋진 설계입니다.”
• 의외다. 두 가지 프로젝트에 전념할 때 생산성이 최고라니…
• 정직과 개방이 좋은 덕목이긴 하지만 나쁜 결과를 가져올 수 있다. 성실과 투명성이 추구해야 할 목표
• ‘왜? –> 답변 –> 왜? –> …’ ‘왜?’로 시작해서 계속 ‘왜?’로 물어보면 진짜 속내를 알 수 있다.
• “XXX보단 제가 낫지 않습니까?” 이렇게 물어본다면 사람이 아니라 행동을 비교해서 설명하자