소프트웨어 개발 제안서를 작성하는 방법

성공적인 소프트웨어 개발 제안서를 작성하는 방법.

케빈 랑그 독

소프트웨어 개발 제안의 목적은 비즈니스 사람들이 읽을 솔루션을 전달하는 것이므로 간단하고 요점을 유지하십시오. 가능한 한 기술 용어를 멀리하십시오. 다음 개요를 그대로 사용하여 성공적인 소프트웨어 개발 제안을 준비 할 수 있습니다. 제안서를 제출할 사람들은 긴 문서를 읽을 시간이 많지 않다는 것을 명심하는 것이 중요합니다. 제 20 년 이상의 정보 기술 분야에서 수백 건의 제안을 썼습니다. 기업인들은 정보에 입각 한 결정을 내릴 수있는 충분한 정보를 원합니다.

제안 요청 (RFP)에 응답하고 특정 페이지 범위를 준수해야하는 경우 페이지가 미리 인쇄되어 있거나 콘텐츠 요구 사항으로 인해 너무 긴 제안이 필요하기 때문에 요약을 사용하는 것이 좋습니다. 아래에 준비 방법을 설명하는 섹션을 추가했습니다.

제안 길이

50 페이지 또는 페이지에 걸쳐 실행되는 제안을 옹호하는 템플릿과 토론을 보았습니다. 저를 믿으십시오, 당신은 다섯 번째 페이지 이후에 사업 임원의 관심을 잃을 것입니다. 제안이 수락되면 설계 문서는 프로젝트 팀을 대상으로하고 시스템의 작업 청사진이 될 것이므로 자연스럽게 더 상세해질 것입니다. 이는 대부분의 고객에게 적용되지만 제안이 RFP (제안 요청)에 대한 응답 인 경우 RFP를 준수해야합니다. 또한 정부 또는 군사 기관은 소프트웨어 개발 제안을 준비하는 방법에 대한 엄격한 지침을 가지고 있으며 시스템의 복잡성에 따라 여러 페이지 (10, 20, 30, 50 또는 그 이상)를 포함 할 수 있습니다.이 규칙은 특히 공기업이고 Sarbannes-Oxley 또는 ISO 규정 또는 표준을 준수해야하는 경우 공식적인 제안 프로세스를 보유 할 수있는 대규모 조직에 여전히 적용됩니다.

요약

제안서가 20 페이지를 넘으면 제안서 섹션의 1 페이지 인 요약을 제공하는 것을 고려할 수 있습니다. PowerPoint 형식으로 요약을 제공 할 수도 있습니다. 소프트웨어 개발 제안 프레젠테이션에서 전체 요약을 사용할 계획 인 경우, 실행 요약을 사용하여 제안을 제시하면 임원이 비즈니스 비행 중과 같이 나중에 제안서를 읽을 수 있습니다.

템플릿

다음 개요는 실제로 소프트웨어 개발 제안을 준비하는 데 사용할 수있는 좋은 템플릿입니다. 저는 제안서를 준비 할 때 항상 엘리베이터 피치 규칙을 염두에두고 있습니다. 기본적으로 엘리베이터 피치는 제안서를 제출하기 위해 1 층에서 건물의 최상층까지 엘리베이터를 타는 데 걸리는 시간보다 길지 않아야한다고 규정합니다.

프로젝트 제목

제안서에 자막 또는 요약 정보 포함

제안에는 소프트웨어 제안의 맥락을 요약하는 제목과 하위 섹션이 있어야합니다. 또한 프로젝트의 대상이되는 부서, 서비스, 부서 또는 조직의 이름을 포함합니다.

RFP (제안 요청)에 응답하는 경우 RFP에 필수 또는 필수로 나열된 모든 정보를 포함하십시오. 첫 페이지의 제목 외에 승인 서명을 요청하는 RFP도 보았지만이 예에서는 변경 섹션이있는 페이지에 서명을 넣었습니다.

승인

이 섹션은 RFP에 대한 응답이든이 템플릿 또는 다른 소스의 응답이든 프로세스에 중요합니다. 이 섹션은 프로젝트가 진행 중이라는 확인을 문서화하고 프로젝트의 다양한 구성원 간의 구속력있는 계약을 제공합니다. 필요한 모든 서명을 획득하고 프로젝트 챔피언 및 이해 관계자들로부터 프로젝트를 시작하기로 약속 할 때까지 프로젝트를 시작해서는 안됩니다. 그렇지 않으면 프로젝트가 취소되거나 프로젝트의 범위가 변경되거나 결과물이 변경되면 구속에 빠질 수 있습니다.

승인을 받으면 범위 및 결과물을 변경하기가 훨씬 더 어렵고 분쟁이있는 경우 승인에 서명하면 합의 된 내용을 명확하게 이해할 수 있습니다. 물론 해석의 문제는 항상 있습니다.

승인에는 사람의 이름, 직위, 서명, 마지막으로 문서에 서명 한 날짜가 포함되어야합니다.



이름	직함 / 역할	서명	데이트

변화

변경 사항 섹션은 소프트웨어 개발 제안서 문서에 적용되었거나 변경 될 모든 변경 사항에 대한 로그를 제공합니다. 프로젝트 자체의 범위 또는 프로젝트의 다른 측면에 대한 변경 사항은 문서화하지 않습니다. 변경 섹션에는 최소한 변경하는 사람의 이름, 변경 날짜 및 변경에 대한 설명 또는 설명이 포함되어야합니다.



저자	변경 날짜	설명 또는 설명

용어 및 약어

용어 또는 두문자어 및 그 정의를 나열하십시오. 모든 사람이 용어 나 두문자어의 의미를 알고 있다고 가정하지 마십시오. 특히 외부 컨설턴트를 사용할 계획이고 용어가 내부적이고 기업 문화와 용어에 포함되어있는 경우에는 더욱 그렇습니다. 모든 조직에는 고유 한 용어와 약어가 있습니다. 적절하게 문서화되어있는 한 제안서에 사용하는 것은 괜찮습니다.

또한 산업별 약어가 사용되는 경우 모든 사람이 용어 및 두문자어의 의미를 명확하게 이해하고 더 나은 해석을 만들 수 있도록 문서화해야합니다.

다음 약어는 현재 템플릿에서 가져온 것입니다. 예제로 제공됩니다.

RFP: 제안 요청
ROI: 투자 수익
CAGR: 복합 연간 성장률
IT: 정보 기술
CAPEX: 자본 지출
UoM: 측정 단위

범위

제안의 범위는 전체 프로젝트 세부 사항, 포함 및 제외되는 사항을 개략적으로 설명해야합니다. 범위는 전체 설명, 프로젝트 기간, 주요 목표를 제공해야합니다. 제안 된 소프트웨어 개발 프로젝트에 대한이 투자로 무엇을 달성하려고하십니까?

타임 라인

이 섹션에는 시작 및 종료 날짜 (예상)가 포함됩니다. 버퍼를 구축하고 비상 사태에 대비하십시오. 좋은 경험 법칙은 타임 라인에 75 % 버퍼를 추가하는 것입니다.

프로젝트 멤버

프로젝트 참여자는 프로젝트 챔피언과 이해 관계자를 포함해야합니다. 챔피언은 일반적으로 전체 프로젝트와 예산을 주도하는 임원입니다. 이해 관계자는 일반적으로 내부 발기인 또는 후원자입니다. 또한 프로젝트의 범위 및 소프트웨어 개발 제안을 요청하는 조직의 유형에 따라 챔피언이 될 수 있습니다. 나머지 목록에는 사람들이 프로젝트에서 수행하는 일반적인 역할이 포함되어 있습니다.

다음은 프로젝트 참여자가 가질 수있는 역할 유형의 예로서 만 제공됩니다. 어떤 사람들은 하나 이상의 역할을 가질 수 있습니다. 프로젝트의 범위에 따라 프로젝트 참여자 목록이 매우 길거나 같은 사람이 다른 역할을 맡을 수 있습니다.

목록에는 사람, 프로젝트 내에서의 역할, 연락 방법 및 책임이 무엇인지를 적절하게 식별하는 모든 정보가 포함되어야합니다. RFP 또는 함께 작업 할 조직 유형 및 내부 정책에 따라 다른 정보를 포함 할 수 있습니다.



팀 구성원	역할	연락 정보	책임
	챔피언
	이해 관계자
	프로젝트 매니저
	건축가
	분석자
	개발자

비즈니스 기회

사용 가능한 대부분의 템플릿은이 섹션을 "비즈니스 문제"또는 "문제 설명"으로 정의하지만 비즈니스 단위 또는 프로세스에 문제가 있다는 사실에 불쾌감을 느끼는 비즈니스 리더를 자주 만났습니다. 나는 우리가 프로세스를 수정하고 있다고 말했고 그녀가 문제가 있는지 지시 할 IT (정보 기술)의 누군가가 아니라고 말했기 때문에 말 그대로 나를 사무실에서 내던진 한 감독을 기억합니다. 그녀의 프로세스와 상관없이.

따라서 문구에주의하십시오. 저는 항상 "비즈니스 기회"라는 용어를 사용합니다. 결국 제안은 프로세스를 개선하거나 프로세스를 지원하거나 프로세스를 자동화 할 비즈니스 기회에 대한 응답이기 때문입니다.



사업 성명	시스템이 요구 사항을 충족하는 방법
영향을받는 비즈니스 프로세스, 상황, 문제	제안 된 솔루션이 대상 비즈니스 영역을 어떻게 개선 할 것인가
해결되는 요구 사항	현재 프로젝트가이를 어떻게 해결할 것인가

솔루션 개요

솔루션 개요 섹션에서 시스템에 대한 높은 수준의 개요를 제공 할 수 있습니다. 제안이 웹 사이트 또는 웹 앱 용인 경우이 개요에는 내비게이션 맵이 포함될 수 있습니다. 프로세스 흐름의 순서도를 포함 할 수도 있습니다. 또한 시스템의 주요 구성 요소에 대한 다이어그램을 포함 할 수 있습니다.

여기서의 목표는 결정을 내리는 사람에게 시스템이 무엇인지, 어떻게 작동하는지, 주요 구성 요소가 무엇인지 이해할 수 있도록 충분한 정보를 제공하는 것입니다. 물론 이것은 조직이 제안서에 필요한 것을 정의하는 공식적인 형식을 가질 수 있으므로 지침 일뿐입니다. 특히 정부 기관이나 국방부와 거래하는 경우입니다.

기능 및 결과물

이 섹션에서는 제안 된 시스템의 기능을 유형의 결과물에 매핑하는 메커니즘을 제공합니다. 또한 산출물을 완료하는 데 소요되는 예상 시간이 포함 된이 섹션을 보았습니다. 그러나 너무 제한적이고 동점을 만들기 때문에 이것을 사용하는 것을 좋아하지 않습니다. 프로젝트에서 작업 할 때 산출물이 기록 된대로 정확하게 정렬되지 않을 수 있습니다., 따라서 특정 시간까지 결과물을 완성하기로 종이에 약속 한 경우 나중에 실제로 프로젝트를 수행 할 때 탄력성이 제거되거나 줄어 듭니다.

추가 할 수있는 또 다른 열은 산출물이 속한 릴리스입니다. 이는 프로젝트가 더 오랜 기간에 걸쳐 제공되고 여러 릴리스가있을 경우 편리합니다. 이는 각 기능 또는 사용자 스토리가 릴리스에 속하는 Agile 또는 Lean 기반 프로젝트에도 적용될 수 있습니다.

개념은 간단합니다. 시스템의 각 기능에 대해 기능의 이름, 간단한 설명 및 기능 요구 사항을 충족 할 결과물을 제공합니다.



특색	기술	결과물

예산 및 ROI

예산 및 ROI는 일부 경영진에게 가장 중요한 부분 일 것입니다. 그들은 모두 시스템 비용이 얼마인지 또는이 프로젝트가 부서 예산에 얼마나 많은 영향을 미칠지 알고 싶어합니다. 회계 연도 초에 프로젝트가 Capex에 포함되지 않은 경우 특히 그렇습니다.

때로는 프로젝트 예산이 책정 되었더라도 다른 프로젝트가 현재 제안보다 우선 할 수 있으며 자금이 의도 한 소스에서 전환 될 수 있습니다. 프로젝트를 시작하기 위해 경영진 및 경영진 수준에서 약간의 정치적 논쟁이 벌어지는 경우가 많으며 계획된 프로젝트보다 우선 할 수있는 예기치 않은 상황이 종종 있습니다.

따라서 이해 관계자와 협력하여 협상을 돕거나 예산 상황이 횡보 할 경우 작업 솔루션을 제공하기 위해 유연하고 능동적으로 준비하십시오. 프로젝트를 예산 현실에 맞게 조정하는 것이 더 낫습니다. 심지어 시스템 결과물을 장기간에 걸쳐 분산 시키거나 프로젝트에서 벗어나는 경우도 있습니다. 프로젝트에 참여하고 보수를받지 않고 길을 따라 소송에 의존하는 것보다 떠나는 것이 훨씬 낫습니다.

다음 표는 예산을 준비하는 방법에 대한 아이디어를 제공하기위한 데모 용입니다. 당연히 프로젝트에 맞게 자체 광고 항목을 추가해야합니다. 그런 다음 수량, 단가, 측정 단위 및 품목 합계를 입력합니다. 그런 다음 하단에서 라인 항목 합계를 집계합니다.

이것은 소프트웨어 프로젝트를 수행하는 데 필요한 투자에 대한 좋은 그림을 제공합니다. 제가 함께 일한 대부분의 경영진은 수익률이 얼마인지 또는 시간이 지남에 따라이 프로젝트에 드는 비용이 얼마인지 알고 싶어합니다. 따라서 자체 추정치와 가정을 사용하여 간단한 ROI 값과 CAGR도 포함합니다. 설명) 제안서 또는 제공된 추정치 및 가정 사용.



프로젝트 항목	양	단가	UoM	합계
소프트웨어 라이선스
기계
서버 라이선스
데이터베이스 라이선스
개발 컨설턴트
프로젝트 관리
교육 (시간 + 재료)

ROI

ROI 계산은 매우 쉽습니다. 기본적으로 공식은 이득-비용을 비용으로 나눈 값입니다. 공식은 다음과 같습니다.

유일한 단점은 계산이 시간을 고려하지 않기 때문에 ROI가 단기 프로젝트에는 좋지만 장기 프로젝트에는 일반적으로 CAGR (Compound Annual Growth Rate)을 포함한다는 것입니다. CAGR 계산은 특정 시점에 대한 연간 수익률입니다.

CAGR

CAGR 공식은 다음과 같습니다.

첫 번째 부분은 종료 값을 시작 값으로 나누는 것입니다. 그 결과는 투자 된 연도 수에 따라 1의 거듭 제곱으로 올라갑니다. 결과 값은 1을 뺍니다.

혜택

이 섹션에서는 소프트웨어 프로젝트가 제공 할 비즈니스 이점을 나열합니다. 전체 목표와 관련이있는 한 글 머리 기호 형식으로 나열 할 수 있습니다. 소프트웨어 또는 시스템이 비즈니스 가치를 어떻게 향상시킬 수 있는지 보여 주어야합니다.

간단히 말해서 제안 된 솔루션이 비즈니스의 성공과 성명서 목표 달성에 어떻게 도움이 될까요? 긍정적 인 단어와 문장을 사용하십시오.

제약

제약 섹션에는 예측할 수있는 모든 유형 및 무형 제약 조건이 나열되어야합니다. 이는 대부분의 공장이 예를 들어 적어도 1 년에 한 번하는 생산 공장 폐쇄와 같은 일부 계절적 요인 인 장비와 관련 될 수 있습니다.

제약 조건을 경시하거나 최소한으로 칠하십시오. 소프트웨어 또는 시스템의 부정적인 측면을 나열하지 않거나 필요한 경우 해결 방법을 제공하십시오.