티스토리 뷰
나는 말로 설득하는 것보다 말로 설득당하기 쉬운 성격인것 같다. 에이 내가 하고 말지라든지, 뭐 그정도는 해 줄 수 있지라는 둥의 태도가 그런 것을 대변한다.
5년전 다녔던 회사의 장~ 대표님이 하신 말 중에 기억나는 것은, 엔지니어는 50%의 기술과 50%의 커뮤니케이션 능력이라고 했는데, 본인의 말인지 인용구인지는 모르겠지만, 내 머리속에 각인 되어 있는 말 중 하나이다.
하고 싶은 말은 업무와 관계된 것에 있어서의 대화 능력이 언제 나타나느냐인데, 개발 프로세스를 진행하는 엔지니어의 입장에서는 다양한 부서, 다양한 사람이 대화하는데 가장 중요한 문서가 소프트웨어 요구 사양서이다.(Software Requirement Specification;SRS) 이것을 어느 수준으로 작성하는가의 가장 중요한 기준은 누가 과연이 문서를 보는지에 대해 정의하는 것이다. 대화를 하겠다고 만든 문서가 대화 상대를 가정하지 않는 것은 이상한일 아닌가?
그러면, 설계서는 어떠한가? 이것은 개발 관련된 사람들끼리 대화하기 위한 문서이다. 최소한의 문서로 최대한의 설계를 전달할 수 있는 것을 목표로 작성하면 된다. 이해의 단위는 곧 대화의 세부 주제들이기 때문에 적절히 구분되어(모듈화) 이해를 돕도록 작성하는 것이 설계서를 만드는 것이다.
최소한의 공통된 지식기반으로 대화가 통하는 사람을 머리 속에 그려야 설계된 전체 그림을 이해할 수 있는 것 아니겠나. 엔지니어의 이 50% 능력은 나머지 50%를 진정한 100%로 만들어주는 능력이다.
5년전 다녔던 회사의 장~ 대표님이 하신 말 중에 기억나는 것은, 엔지니어는 50%의 기술과 50%의 커뮤니케이션 능력이라고 했는데, 본인의 말인지 인용구인지는 모르겠지만, 내 머리속에 각인 되어 있는 말 중 하나이다.
하고 싶은 말은 업무와 관계된 것에 있어서의 대화 능력이 언제 나타나느냐인데, 개발 프로세스를 진행하는 엔지니어의 입장에서는 다양한 부서, 다양한 사람이 대화하는데 가장 중요한 문서가 소프트웨어 요구 사양서이다.(Software Requirement Specification;SRS) 이것을 어느 수준으로 작성하는가의 가장 중요한 기준은 누가 과연이 문서를 보는지에 대해 정의하는 것이다. 대화를 하겠다고 만든 문서가 대화 상대를 가정하지 않는 것은 이상한일 아닌가?
그러면, 설계서는 어떠한가? 이것은 개발 관련된 사람들끼리 대화하기 위한 문서이다. 최소한의 문서로 최대한의 설계를 전달할 수 있는 것을 목표로 작성하면 된다. 이해의 단위는 곧 대화의 세부 주제들이기 때문에 적절히 구분되어(모듈화) 이해를 돕도록 작성하는 것이 설계서를 만드는 것이다.
최소한의 공통된 지식기반으로 대화가 통하는 사람을 머리 속에 그려야 설계된 전체 그림을 이해할 수 있는 것 아니겠나. 엔지니어의 이 50% 능력은 나머지 50%를 진정한 100%로 만들어주는 능력이다.
반응형
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- url
- TCP/IP
- perl
- 벤자민
- 클레로덴드럼
- ssh
- SSO
- VIM
- 수선화
- tattertools
- 대화
- writely
- Subversion
- 오픈소스
- MySQL
- 식물
- 퀴즈
- BlogAPI
- macosx
- 킹벤자민
- SVN
- 덴드롱
- OpenID
- Tattertools plugin
- 구근
- Linux
- nodejs
- 디버깅
- 커피
- JavaScript
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
글 보관함