Chapter6.3 - 고객의 요구사항은 변할 수 밖에 없다 개발은 고객 요구 실현 고객이 요구사항이 명확하지 않은데는 이유가 있음 요구사항을 분석하지 말고 제시하라 고객은 자기가 원하는 제품이 정확히 무엇인지 모름 그렇기에 외주를 맡기는 것! 변화하는 요구사항에 대비하라 요구사항은 반드시 변함 최초의 요구사항은 단순한 참고사항일 뿐 기존 방식을 투 트랙으로 변경 목표시스템 전체에 대한 분석-설계-구현-테스트-검수 기능별 세부 활동에 대한 정밀한 요구 정의 이러한 시스템을 통해 고객의 요구와 개발, 검수 사이의 시간 차이를 최소화할 수 있음 참고문헌: 개발자의 글쓰기
Chapter6.2 - 고객의 문제 인식과 제안사의 문제 해결 능력 문제 인식과 문제 해결 능력 제안서의 시작은 문제가 아니라 고객의 문제 인식 고객이 문제를 얼마나 중대하게 생각하느냐에 따라 문제 해결 수준도 달라짐 제안사의 문제 해결능력: 탁월함 vs 부족함 / 고객의 문제 인식: 중대함 vs 사소함 구분 탁월함 부족함 중대함 경쟁사와 비교하여 제안하라 일단 동감하고 다른 방안을 제시하라 사소함 고객이 문제를 중대하게 인식하게 만들어라 경쟁사의 전략을 확인하여 대처하라 경쟁사와 비교하여 제안하라 제안사의 강점을 최대한 부각하는 방법이 경쟁사와 비교하는 것임 일단 동감하고 다른 방안을 제시하라 '나도 할 수 있다'라고 쓰는 순간 그 프로젝트는 망할 수 있음 경쟁사와 다른 접근법 찾기 고객..
Chapter6.1 - 개발자가 알아야 할 제안서 작성 원칙 개발자와 제안 PM의 차이 개발자는 제안서에서 주로 기술 부문을 작성함 대부분 그림과 표로 구성 시스템 구성도의 본질은 그림이 아니다 제안요청소에 있는 시스템 구성도(As-Is)를 분석해서 새로운 시스템 구성도(To-Be)를 구상해 그림을 그리고 제안서에 넣는 것이 본래 업무 첫째, 제안요청서 분석 제안요청서 제대로 분석하기 목표 시스템, 하드웨어 구상도, 소프트웨어 구성도, 요구 기능 등의 내용들이 이미 들어있음 개발자가 제안요청서에서 힌트를 잘 찾아내면 기술 부문을 더 전략적으로 쓸 수 있음 둘쨰, 논리적 완결성 항목을 논리적으로 완결하기 기업 담당자나 심사위원은 자기와 관련있는 항목 또는 페이지만 골라서 읽는다는 것을 알고있어야 함 참고문..
Chapter5.4 - 서사를 활용해 목차를 만들자 개발과 서사 서사: 사실을 있는 그대로 적는 것 그림이나 사진이 글과 붙어 있는 잡지처럼 글을 써야함 보통 글의 번호와 스크린샷 안의 번호를 같게하여 번호마다 글을 씀 독자의 수준 대신 기술의 범용성을 기준으로 쓰자 의미 있는 사건을 시간에 따른 전개 과정으로 써야 함 개발문서에서 서사는 개발자와 독자 사이에 줄다리기 범용성을 기준으로 기술하기! 순서에서 단계를, 단계에서 목차를 만들자 단계마다 나누어 단계별 목표를 정확히 하기 쉬운 단계 -> 어려운 단계 순 목차를 배치하여 링크를 거는 방법도 좋음 참고문헌: 개발자의 글쓰기
