Theory/Project Management

5장 아이디어 내기

요구사항으로부터 좋은 명세서를 작성하려면 요구사항의 품질은 높이거나 설계를 세심하게 탐구해야 합니다.

우수한 요구사항은 고객의 요구와 프로젝트의 목표를 효과적으로 전달하고 문제를 명확히 정의합니다.

좋은 질문을 던져야 좋은 아이디어가 나옵니다. 좋은 질문은 주의를 문제의 핵심에 집중시키거나 미처 생각지도 못했던 창의적인 방향으로 유도합니다. 나쁜 질문은 권위적이고 부정적인 어감으로 상대방을 위축시키고 원하는 대답을 얻지 못하게 합니다.

많은 아이디어에서 좋은 아이디어가 나옵니다. 여러 아이디어를 통해서 나쁜 아이디어와 좋은 아이디어를 구별할 수 있습니다.

아이디어를 도출하기 위한 방법에는 즉흥 게임이 있습니다 . 이 게임의 네가지 규칙은, 1) "예, 그리고..."(이전 발언자의 아이디어를 받아서 진전시키거나 방향을 바꾸기), 2) 얼버무리기 없기, 3) 차단성 질문 피하기, 4) 다른 사람 띄어주기(다른 사람의 아이디어에 도움을 준 사람에게 보상하기) 입니다.

고객의 경험에서 기술로 내려가는 방향으로 설계를 합니다. 설계는 모두가 만족스러운 방안을 찾을때까지 대화를 통해서 아이디어를 제기하고 검토하면서 진전시켜 나가는 과정입니다.

'Theory > Project Management' 카테고리의 다른 글

7장 명세서  (0) 2007.02.27
6장 아이디어 관리하기  (0) 2007.02.23
5장 아이디어 내기  (0) 2007.02.21
4장 비전  (0) 2007.02.13
3장 할 일을 파악하기  (0) 2007.02.12
2장 일정  (0) 2007.02.12
Theory/Project Management

4장 비전

비전 문서는 프로젝트를 올바른 방향으로 유도합니다. 비전문서는 프로젝트가 끝난 관점을 가시적으로 묘사합니다.

비전 문서를 세부적으로 나눌 수 있습니다. 전체, 팀, 개인으로 나누고, 상위 문서를 토대로 다른 문서로 정의합니다.

좋은 비전 문서는 단순/목적/통합/고무/인상적인 특징을 가지고 있습니다. 좋은 비전 문서는 대개 한사람이 작성하며 짧고도 읽기가 쉽습니다.

'Theory > Project Management' 카테고리의 다른 글

7장 명세서  (0) 2007.02.27
6장 아이디어 관리하기  (0) 2007.02.23
5장 아이디어 내기  (0) 2007.02.21
4장 비전  (0) 2007.02.13
3장 할 일을 파악하기  (0) 2007.02.12
2장 일정  (0) 2007.02.12
Theory/Project Management

3장 할 일을 파악하기

계획수립에 대한 관점에 대해서 이해하기 쉬게 표현하면 다음과 같습니다:
요구사항('무엇을 해야 하지?') -> 설계/명세('어떻게 하지?') -> 구현('하자!')

'요구사항의 결정'/설계/기술/예산의 권한에 대해서 초기에 정하고 팀원 모두에게 알립니다.

요구사항에 관한 문서들은 마케팅 요구사항 문서(MRD: Marketing Requirement Document), 비전/범위 문서, 명세서, 그리고 WBS(Work Breakdown Structure) 등이 있습니다.

계획을 보는 관점에는 비지니스 관점, 기술 관점 그리고 고객 관점이 있습니다. 세 관점은 서로 교집합이 찾아서 프로젝트의 목표를 세웁니다.

계획 수립의 단계는 MRD <-> 비전 <-> 명세서 <-> WBS 로 이루어집니다.

고객의 의견을 조사하기 위해서는 여러개의 방법을 복합적으로 사용합니다.

문제 기술문을 사용하여 요구사항을 문서화합니다. 고객 관점에서 문제나 필요를 지적하는 형식으로 작성합니다.

기능 기술문을 사용하여 프로젝트가 수행해야하는 시나리오를 문서로 만듭니다. 해결책이 고객에게 미치는 영향을 설명합니다.

'Theory > Project Management' 카테고리의 다른 글

7장 명세서  (0) 2007.02.27
6장 아이디어 관리하기  (0) 2007.02.23
5장 아이디어 내기  (0) 2007.02.21
4장 비전  (0) 2007.02.13
3장 할 일을 파악하기  (0) 2007.02.12
2장 일정  (0) 2007.02.12
Theory/Project Management

2장 일정

일정은 어떻게 사용하느냐에 의미가 있지, 그것을 만드는데 의미가 있는 것은 아닙니다. 일정은 '시간에 대한 약속', '기여도 관찰', '관리가능한 단위로 쪼개기' 등의 필요에 의해서 존재하며 성공적인 프로젝트를 만드는데 목적이 있습니다.

일정은 확률입니다. 따라서 일정이 완벽할 필요가 없습니다. 대신에 일정을 논할때는 항상 확률을 덧붙이도록 합니다.

일정의 확율을 높이기 위해서는 좋은 설계를 해야 합니다. 좋은 설계은 간과된 문제들을 없애고 좋은 예측을 할 수 있게 합니다.

일정은 설계, 구현 그리고 테스트라는 세가지 요소가 있습니다. 기간은 그것을 3등분해서 배분합니다. 합당한 이유가 있다면 균등하지 않아도 됩니다.

일정을 세우기 어려워하는 팀원이 있다면 적절한 질문으로 구체적인 생각을 하도록 유도합니다. 비단 일정 뿐만이 아니라 다른 여러가지 것에 있어서 적절한 질문은 개인/팀원의 생각을 유도하는 좋은 도구입니다.

'Theory > Project Management' 카테고리의 다른 글

7장 명세서  (0) 2007.02.27
6장 아이디어 관리하기  (0) 2007.02.23
5장 아이디어 내기  (0) 2007.02.21
4장 비전  (0) 2007.02.13
3장 할 일을 파악하기  (0) 2007.02.12
2장 일정  (0) 2007.02.12
Life/Books

다빈치 코드

다빈치 코드의 책
한마디로 평가하자면 재미있는 책이다. 한편의 헐리우드 영화를 본 기분이었다. 흥미로운 소재, 빠른 진행과 마지막 반전, 수수께끼와 그것을 풀어가는 과정이 이 책의 전부이다. 그래서 단지 재미있다고 밖에는 달리 표현할 것이 없다.

'Life > Books' 카테고리의 다른 글

철학자의 돌 - 1권  (0) 2007.04.23
링크(알버트 라즐로 바라바시)  (0) 2007.04.07
다빈치 코드  (0) 2007.02.01
지식의 추구와 수학  (0) 2007.01.24
백만번의 변명  (0) 2007.01.10
코드북(The Code Book)  (0) 2007.01.08

알림

이 블로그는 구글에서 제공한 크롬에 최적화 되어있고, 네이버에서 제공한 나눔글꼴이 적용되어 있습니다.

카운터

Today : 115
Yesterday : 134
Total : 205,384