All of Software: 7월 2012
작성자: 전규현 시간: 오전 6:19 댓글 5개:
작성자: 전규현 시간: 오전 2:24 댓글 2개:
소프트웨어를 체계적으로 개발해 보겠다고 맘을 먹으면 가장 먼저 하는 것이 "문서작성"이다.
문서의 개수와 종류와 상관없이 문서작성 시 가장 중요한 것은 무엇일까?
사람마다 다르게 생각하겠지만, 내가 생각하기에 가장 중요한 것은 "눈높이 맞추기"이다.
문서의 "눈높이 맞추기"란 의외로 매우 어렵다.
첫째, 문서의 독자가 누구인지 파악해야 한다.
소프트웨어를 개발할 때 만드는 대표적인 문서들은 MRD(기획), SRS(분석), SDS(설계) 를 들 수 있다.
각 문서마다 독자가 다르다. 심지어는 하나의 문서에서도 각 장마다 독자가 다르기 때문에 각 문서를 읽을 독자의 눈높이 맞추는 것이 쉽지는 않다.
둘째, 독자를 파악했다면 해당 독자에게 문서를 통해서 전달해야 할 내용과 독자가 프로젝트에서의 역할이 무엇인지 생각해야 한다. 그렇게 해서 독자에게 필요한 내용을 전달해야 한다.
더 많은 내용 또는 부족한 내용을 전달할 경우 문서로서의 가치가 떨어진다.
셋째, 독자의 눈높이에 맞는 용어를 사용해야 한다. 경영자가 읽어야 문서라면 경영자가 이해하는 용어로 적어야 한다. 영업부서가 봐야 하는 부분이라면 영업이 이해할 수 없는 전문용어를 써서는 안된다.
더불어 문서를 작성할 때 문서의 서두에 문서의 독자와 읽는 방법에 대해서 설명을 해주는 것이 좋다. 특히 각 장마다 독자와 읽는 방법을 설명해주면 문서를 읽는 사람은 그 안내에서 따라서 가장 효율적으로 문서를 읽을 수 있다.
"옳은 문서"가 좋은 것이 아니고 "읽기 좋은 문서"가 좋은 것이다. 맞는 내용이라고 하더라도 어렵게 작성했거나, 너무 많이 작성했다면 비효율적인 문서 작성을 하고 있는 것이다.
"읽기 좋은 문서"를 작성하기 위한 노력은 꾸준히 계속되어야 한다. 한두해 걸릴 일이 아니기 때문이다.
작성자: 전규현 시간: 오전 2:03 댓글 2개:
작성자: 전규현 시간: 오전 10:22 댓글 없음:
작성자: 전규현 시간: 오전 9:45 댓글 8개:
라벨: 개발프로세스, 분석, 설계, 프로세스, SI회사
작성자: 전규현 시간: 오전 6:00 댓글 12개:
소프트웨어 회사에서 꼭 필요한 개발문화 한가지를 꼽으라면 주저없이 "공유" 문화를 꼽는다.
"공유"의 문화야 말로 소프트웨어 회사를 가장 효율적으로 만들고 프로젝트를 효과적으로 진행할 수 있도록 하며 개발자들의 역량을 향상시키는 결정적인 문화이다.
"공유"의 문화가 잘 정착된 회사에서는 자연스럽게 문서화를 하며 시스템에 기록을 하고 소스코드에 주석을 남기고 필요한 리뷰를 진행한다.
하지만 공유의 문화가 부족한 회사에서는 자발적으로 공유의 활동이 잘 이루어지지 않는다.
물론 공유의 문화가 부족한 곳에서도 선도적인 개발자들이 공유의 문화를 정착하기 위해서 노력하고 있지만 역부족인 경우가 많다.
그 이유는 다른 개발자들의 협조를 이끌어내기가 어렵기 때문이다.
모든 사람이 다 공유를 하고 있는 상황이 아니라면 공유하는 사람만 손해를 보게 된다.
공유를 위해서 시간과 노력을 조금이라도 더 들였다. 하지만 공유를 하지 않는 사람들은 다른 사람이 공유한 결실은 얻으면서 자신의 것은 공유를 하지 않는다.
바빠서 그러기도 하고,
아직 습관이 안되서 그렇기도 하고,
귀찮아서 그러기도 하고,
공유하면 손해라고 생각하는 경우도 있다.
공유의 문화가 팽배한 회사는 서로 공유하는 것이 서로 이익이라고 몸으로 느끼고 있어서 자발적으로 자연스럽게 공유를 한다.
그럼 어떻게 공유의 문화를 정착할 수 있을까?
공유의 문화가 정착되기 전에는 회사의 규칙으로 강제화 해야 한다.
물론 너무 심하게 강제를 하면 반발하여 실패하기 쉽다.
너무 목표를 높게 잡아도 대부분 실패한다.
장기적인 계획을 하지고 단계적으로 시행해 나가야 한다.
첫번째가 이슈(버그)관리시스템을 적극적으로 사용하는 것이다. 모든 이슈와 버그는 시스템으로 모으고 최대한 메일과 전화를 줄이는 것이 그 시작이다.
두번째는 스펙을 작성하는 것이다. 스펙을 처음부터 제대로 쓰기는 어렵지만, 일단 프로젝트를 시작할 때 스펙문서를 작성하는 것을 규칙으로 두고 써보는 것이 좋다. 차츰 나아질 것이다.
세번쨰는 스펙을 리뷰하는 것이다. 스펙을 적고 리뷰를 해보면 그동안 얼마나 서로 모르고 프로젝트를 했다는 것이 조금씩 드러날 것이다.
이렇게 단계적으로 공유를 위한 제도를 강제로 적용하면 어느새 공유가 당연한 것으로 받아들여지는 때가 올것이다.
작성자: 전규현 시간: 오전 4:51 댓글 없음: