Mục lục:
- Độ dài đề xuất
- Tóm tắt điều hành
- Bản mẫu
- Tên dự án
- Mục lục
- Phê duyệt
- Những thay đổi
- Bảng chú giải thuật ngữ và từ viết tắt
- Phạm vi
- Mốc thời gian
- Thành viên dự án
- Cơ hội kinh doanh
- Tổng quan về giải pháp
- Tính năng và Sản phẩm
- Ngân sách và ROI
- Những lợi ích
- Ràng buộc
Làm thế nào để viết một đề xuất phát triển phần mềm thành công.
Kevin Languedoc
Mục đích của một đề xuất phát triển phần mềm là truyền đạt một giải pháp mà những người kinh doanh sẽ đọc được, vì vậy hãy giữ cho nó đơn giản và đi vào trọng tâm; tránh xa các thuật ngữ kỹ thuật càng nhiều càng tốt. Bản phác thảo sau đây có thể được sử dụng để chuẩn bị một đề xuất phát triển phần mềm thành công. Điều quan trọng cần nhớ là những người mà bạn sẽ trình bày đề xuất không có nhiều thời gian để đọc một tài liệu dài. Bạn có thể hiểu điều đó từ tôi, tôi đã viết hàng trăm đề xuất trong hơn 20 năm làm công nghệ thông tin của mình: các doanh nhân chỉ muốn có đủ thông tin để cho phép họ đưa ra quyết định sáng suốt.
Nếu bạn đang phản hồi Yêu cầu đề xuất (RFP) và phải tôn trọng một phạm vi trang nhất định, vì các trang được in sẵn hoặc yêu cầu nội dung buộc bạn phải có một đề xuất quá dài, thì hãy xem xét sử dụng Tóm tắt điều hành. tôi đã thêm một phần phác thảo cách chuẩn bị bên dưới.
Độ dài đề xuất
Tôi đã thấy các mẫu và cuộc thảo luận ủng hộ các đề xuất chạy trên 50 hoặc trang. Tin tôi đi, bạn sẽ mất đi sự quan tâm của nhà điều hành doanh nghiệp sau trang thứ năm. Khi đề xuất được chấp nhận, các tài liệu thiết kế đương nhiên sẽ chi tiết hơn vì chúng sẽ được dành cho nhóm dự án và sẽ là bản thiết kế hoạt động cho hệ thống. Điều này sẽ áp dụng cho hầu hết các khách hàng nhưng (vâng luôn có nhưng) nếu đề xuất đáp ứng Yêu cầu đề xuất (RFP) thì bạn phải tuân thủ RFP. Ngoài ra, một cơ quan chính phủ hoặc quân đội có thể sẽ có các hướng dẫn nghiêm ngặt về cách chuẩn bị một đề xuất phát triển phần mềm và có thể bao gồm một số trang (10, 20, 30, 50 hoặc nhiều hơn) tùy thuộc vào độ phức tạp của hệ thống.Quy tắc này vẫn đúng đối với các tổ chức lớn có thể có quy trình đề xuất chính thức, đặc biệt nếu họ là một công ty đại chúng và phải tuân thủ mọi quy định hoặc tiêu chuẩn của Sarbannes-Oxley hoặc ISO.
Tóm tắt điều hành
Nếu đề xuất dài hơn 20 trang, thì bạn có thể xem xét cung cấp Bản tóm tắt điều hành là một trang tổng hợp các phần trong đề xuất. Bạn thậm chí có thể cung cấp Bản tóm tắt điều hành ở định dạng PowerPoint. Nếu bạn đang lên kế hoạch sử dụng Bản tóm tắt điều hành trong bản trình bày đề xuất phát triển phần mềm, hãy trình bày đề xuất bằng Bản tóm tắt điều hành và người điều hành có thể đọc qua bản đề xuất sau đó, như trong một chuyến bay công tác.
Bản mẫu
Bản phác thảo sau đây thực sự là một mẫu tốt mà bạn có thể sử dụng để chuẩn bị đề xuất phát triển phần mềm của riêng mình. Tôi luôn ghi nhớ quy tắc Quảng cáo chiêu hàng khi chuẩn bị đề xuất và bạn cũng vậy. Về cơ bản Quảng cáo chiêu hàng thang máy quy định rằng đề xuất của bạn không được dài hơn thời gian đi thang máy từ tầng trệt lên tầng cao nhất của một tòa nhà trên đường bạn trình bày đề xuất.
Tên dự án
Với một phụ đề hoặc thông tin tóm tắt về đề xuất
Đề xuất nên có tiêu đề và một tiểu phần tóm tắt bối cảnh của đề xuất phần mềm. Bạn cũng bao gồm tên của bộ phận, dịch vụ, phòng ban hoặc tổ chức mà dự án dự định sẽ hoạt động.
Nếu bạn đang trả lời một RFP (Yêu cầu Đề xuất), thì hãy bao gồm bất kỳ thông tin nào được yêu cầu hoặc liệt kê là bắt buộc trong RFP. Tôi cũng đã thấy các RFP yêu cầu bạn đặt chữ ký phê duyệt ngoài tiêu đề trên trang đầu tiên, nhưng trong ví dụ này, tôi đặt chữ ký trên trang có phần Thay đổi.
Mục lục
Trên trang tiếp theo, bạn nên bao gồm một mục lục liệt kê các phần chính của đề xuất. Bạn có thể tùy ý bao gồm số trang nếu đề xuất vượt quá năm trang hoặc nếu RFP yêu cầu.
Phê duyệt
Phần này rất quan trọng đối với quy trình, cho dù đó là phản hồi với RFP hoặc từ mẫu này hoặc từ một số nguồn khác. Phần này ghi lại các xác nhận rằng dự án đang hoạt động và cung cấp một thỏa thuận ràng buộc giữa các thành viên khác nhau của dự án. Bạn không bao giờ nên bắt đầu một dự án cho đến khi bạn đã có được tất cả các chữ ký cần thiết và có sự cam kết từ nhà vô địch dự án và các bên liên quan để bắt đầu dự án. Nếu không, bạn có thể thấy mình bị ràng buộc nếu dự án bị hủy bỏ hoặc nếu phạm vi của dự án thay đổi hoặc các sản phẩm được giao.
Với các Phê duyệt đã có, các thay đổi về phạm vi và phân phối khó thực hiện hơn nhiều và nếu có tranh chấp, việc có các phê duyệt đã ký sẽ cung cấp sự hiểu biết rõ ràng (sai) về những gì đã được thỏa thuận. Tất nhiên, luôn có một câu hỏi diễn giải.
Phê duyệt phải bao gồm tên của người đó, chức danh của họ, tiếp theo là chữ ký của họ và cuối cùng là ngày tài liệu được ký.
Tên | Vai trò tiêu đề | Chữ ký | Ngày |
---|---|---|---|
Những thay đổi
Phần Thay đổi cung cấp nhật ký về tất cả các thay đổi đã được thực hiện hoặc sẽ được thực hiện đối với tài liệu Đề xuất Phát triển Phần mềm. Nó không ghi lại bất kỳ thay đổi nào đối với phạm vi của dự án hoặc bất kỳ khía cạnh nào khác của dự án. Phần Thay đổi phải bao gồm tối thiểu tên của người thực hiện thay đổi, ngày thay đổi và nhận xét hoặc mô tả về thay đổi.
Tác giả | Ngày thay đổi | Mô tả hoặc Nhận xét |
---|---|---|
Bảng chú giải thuật ngữ và từ viết tắt
Liệt kê bất kỳ thuật ngữ hoặc từ viết tắt nào và định nghĩa của chúng. Đừng cho rằng mọi người đều biết ý nghĩa của các thuật ngữ hoặc từ viết tắt, đặc biệt nếu bạn đang có kế hoạch sử dụng các chuyên gia tư vấn bên ngoài và các thuật ngữ này là nội bộ, gắn liền với văn hóa doanh nghiệp và biệt ngữ của bạn. Mọi tổ chức đều có biệt ngữ và từ viết tắt của riêng mình. Bạn có thể sử dụng chúng trong đề xuất miễn là chúng được ghi chép đúng cách.
Ngoài ra, nếu sử dụng bất kỳ từ viết tắt cụ thể nào trong ngành, chúng cũng cần được ghi lại để mọi người hiểu rõ về ý nghĩa của các thuật ngữ và từ viết tắt cũng như xây dựng cách giải thích tốt hơn.
Các từ viết tắt sau là từ mẫu hiện tại. Chúng được cung cấp như một ví dụ.
- RFP: Yêu cầu Đề xuất
- ROI: Lợi tức đầu tư
- CAGR: Tỷ lệ tăng trưởng hàng năm tổng hợp
- CNTT: Công nghệ thông tin
- CAPEX: Chi tiêu vốn
- UoM: Đơn vị đo lường
Phạm vi
Phạm vi của đề xuất nên phác thảo ở mức độ cao các chi tiết tổng thể của dự án, những gì được bao gồm và loại trừ. Phạm vi cần cung cấp mô tả tổng thể, độ dài của dự án, các mục tiêu chính. Bạn đang cố gắng hoàn thành điều gì với khoản đầu tư này vào dự án phát triển phần mềm được đề xuất.
Mốc thời gian
Phần này sẽ bao gồm ngày bắt đầu và ngày kết thúc (ước tính). Hãy chắc chắn xây dựng trong một vùng đệm và lên kế hoạch cho các trường hợp dự phòng. Một Quy tắc Ngón tay cái tốt là thêm bộ đệm 75% vào dòng thời gian của bạn.
Thành viên dự án
Các thành viên dự án nên bao gồm nhà vô địch dự án và các bên liên quan. Nhà vô địch thường là giám đốc điều hành, người điều hành dự án tổng thể và ngân sách. Bên liên quan thường là người quảng bá hoặc nhà tài trợ nội bộ. Họ cũng có thể là nhà vô địch tùy thuộc vào phạm vi của dự án và hoặc loại tổ chức đang yêu cầu đề xuất phát triển phần mềm. Danh sách còn lại chứa các vai trò tiêu biểu mà mọi người thực hiện trong một dự án.
Phần sau chỉ được cung cấp như một ví dụ về loại vai trò mà người tham gia dự án có thể có. Một số người có thể có nhiều hơn một vai trò. Tùy thuộc vào phạm vi của dự án, danh sách thành viên dự án có thể rất dài hoặc cùng một người có thể đảm nhận các vai trò khác nhau.
Danh sách phải chứa bất kỳ thông tin nào xác định đúng người, vai trò của họ trong dự án, cách tiếp cận họ và trách nhiệm của họ. Bạn có thể bao gồm các thông tin khác tùy thuộc vào RFP hoặc loại tổ chức bạn sẽ làm việc và các chính sách nội bộ của họ.
Thành viên của đội | Vai trò | Thông tin liên lạc | Trách nhiệm |
---|---|---|---|
Quán quân |
|||
Bên liên quan |
|||
Quản lý dự án |
|||
Kiến trúc sư |
|||
Nhà phân tích |
|||
Nhà phát triển |
Cơ hội kinh doanh
Hầu hết các mẫu có sẵn đều xác định phần này là “Vấn đề kinh doanh” hoặc “Tuyên bố vấn đề” tuy nhiên tôi thường gặp các nhà lãnh đạo doanh nghiệp xúc phạm thực tế rằng họ có vấn đề trong đơn vị hoặc quy trình kinh doanh của họ. Tôi nhớ một giám đốc đã ném tôi ra khỏi văn phòng của cô ấy theo đúng nghĩa đen vì tôi đã tuyên bố rằng chúng tôi đang sửa một quy trình và cô ấy nói với tôi rằng sẽ không phải một người từ CNTT (Công nghệ thông tin) sẽ ra lệnh nếu cô ấy gặp sự cố. với quy trình của cô ấy hay không.
Vì vậy, hãy cẩn thận với từ ngữ. Tôi luôn sử dụng thuật ngữ “Cơ hội kinh doanh” vì cuối cùng, đề xuất là để đáp ứng một cơ hội kinh doanh nhằm cải thiện quy trình, hỗ trợ quy trình hoặc tự động hóa quy trình
Báo cáo kinh doanh | Hệ thống sẽ đáp ứng yêu cầu như thế nào |
---|---|
Quá trình kinh doanh bị ảnh hưởng, tình hình, vấn đề |
Giải pháp được đề xuất sẽ cải thiện lĩnh vực kinh doanh mục tiêu như thế nào |
Cần gì đang được giải quyết |
Dự án hiện tại sẽ giải quyết nó như thế nào |
Tổng quan về giải pháp
Trong phần Tổng quan về Giải pháp, bạn có thể cung cấp tổng quan cấp cao về hệ thống. Tổng quan này có thể bao gồm bản đồ điều hướng nếu đề xuất dành cho trang web hoặc ứng dụng web. Bạn cũng có thể bao gồm một sơ đồ của quy trình. Ngoài ra, bạn có thể đưa vào sơ đồ các thành phần chính của hệ thống.
Mục tiêu ở đây là cung cấp cho người ra quyết định đủ thông tin để họ hiểu hệ thống là như thế nào, nó sẽ hoạt động như thế nào và các khối xây dựng chính là gì. Tất nhiên, đây chỉ là một hướng dẫn vì một tổ chức có thể có một định dạng chính thức xác định những gì bạn sẽ cần đưa ra trong đề xuất, đặc biệt là khi bạn đang giao dịch với cơ quan chính phủ hoặc bộ quốc phòng.
Tính năng và Sản phẩm
Phần này cung cấp một cơ chế để ánh xạ một tính năng của hệ thống được đề xuất thành một sản phẩm có thể phân phối hữu hình. Tôi cũng đã thấy phần này chứa ước tính thời gian để hoàn thành sản phẩm có thể phân phối, nhưng tôi không thích sử dụng phần này vì nó quá hạn chế và tạo ra sự ràng buộc. Khi làm việc trên dự án, các sản phẩm được phân phối có thể không xếp hàng chính xác như đã viết ra, vì vậy nếu bạn đã cam kết trên giấy là sẽ hoàn thành một sản phẩm có thể giao hàng vào một thời điểm nhất định, điều đó sẽ loại bỏ hoặc giảm bớt bất kỳ độ co giãn nào sau này khi bạn thực sự thực hiện dự án.
Một cột khác có thể được thêm vào là Bản phát hành mà Có thể phân phối thuộc về. Điều này rất hữu ích nếu dự án sẽ được phân phối trong một khoảng thời gian dài hơn và sẽ có một số bản phát hành. Điều này cũng có thể áp dụng cho một dự án dựa trên Agile hoặc Lean mà mỗi tính năng hoặc Câu chuyện của người dùng thuộc về một Bản phát hành.
Khái niệm là đơn giản; đối với mỗi tính năng trong hệ thống, hãy cung cấp tên của tính năng, mô tả ngắn gọn và có thể phân phối sẽ đáp ứng yêu cầu về tính năng.
Đặc tính | Sự miêu tả | Có thể giao hàng |
---|---|---|
Ngân sách và ROI
Ngân sách & ROI có lẽ là phần quan trọng nhất đối với một số giám đốc điều hành. Tất cả họ đều lo lắng muốn biết hệ thống sẽ tiêu tốn bao nhiêu hoặc dự án này sẽ có tác động như thế nào đến ngân sách bộ phận của họ. Điều này đặc biệt đúng nếu dự án không được đưa vào Capex vào đầu năm tài chính.
Đôi khi, ngay cả khi dự án đã được cấp ngân sách, một dự án khác có thể được ưu tiên hơn đề xuất hiện tại và quỹ có thể được chuyển hướng khỏi nguồn dự kiến của chúng. Thường có một chút tranh cãi chính trị xảy ra ở cấp điều hành và quản lý để đưa một dự án khởi công và thường có những trường hợp không lường trước được có thể được ưu tiên hơn các dự án đã lên kế hoạch.
Vì vậy, hãy sẵn sàng làm việc với bên liên quan của bạn để giúp đàm phán hoặc linh hoạt và chủ động để đưa ra giải pháp hiệu quả nếu tình hình ngân sách đi ngang. Tốt hơn là bạn nên điều chỉnh dự án cho phù hợp với thực tế ngân sách, thậm chí dàn trải hệ thống đã phân phối trong một khoảng thời gian dài hơn hoặc thậm chí rời khỏi dự án. Tốt hơn là bỏ đi xa hơn là làm việc trong một dự án và không được trả tiền và phải dùng đến các vụ kiện tụng ngay từ đầu.
Bảng sau đây chỉ nhằm mục đích trình bày để cung cấp cho bạn ý tưởng về cách chuẩn bị ngân sách. Đương nhiên, bạn sẽ cần thêm các mục hàng của riêng mình để phù hợp với dự án của bạn. Sau đó, bạn điền số lượng, đơn giá, đơn vị đo lường và tổng chi tiết đơn hàng. Sau đó, kiểm đếm tổng số mục hàng ở dưới cùng.
Điều này sẽ cung cấp một bức tranh tốt về khoản đầu tư cần thiết để thực hiện dự án phần mềm. Hầu hết các giám đốc điều hành mà tôi từng làm việc đều muốn biết tỷ lệ lợi nhuận sẽ là bao nhiêu hoặc chi phí dự án này sẽ là bao nhiêu theo thời gian, vì vậy tôi cũng bao gồm giá trị ROI đơn giản và CAGR, bằng cách sử dụng các ước tính và giả định của riêng tôi (phải là giải thích) trong đề xuất hoặc sử dụng các ước tính và giả định được cung cấp.
Mục dự án | Số tiền | Đơn giá | UoM | Toàn bộ |
---|---|---|---|---|
Bản quyền phần mềm |
||||
(Các) máy |
||||
Giấy phép Máy chủ |
||||
Giấy phép cơ sở dữ liệu |
||||
Tư vấn phát triển |
||||
Quản lý dự án |
||||
Đào tạo (Thời gian + Vật liệu) |
ROI
Việc tính toán ROI rất dễ dàng. Về cơ bản, công thức là lợi nhuận - chi phí chia cho chi phí. Công thức được cung cấp bên dưới:
Nhược điểm duy nhất là việc tính toán không tính đến thời gian, vì vậy ROI tốt cho các dự án ngắn hạn nhưng đối với dự án dài hạn, tôi thường bao gồm CAGR (Tỷ lệ tăng trưởng hàng năm tổng hợp). Cách tính CAGR là tỷ suất sinh lợi hàng năm trong một thời điểm nhất định.
CAGR
Công thức CAGR là:
Phần đầu tiên là phép chia giá trị cuối cho giá trị bắt đầu. Kết quả được nâng lên thành lũy thừa 1 trong số năm đầu tư. Giá trị kết quả được trừ đi 1.
Những lợi ích
Trong phần này, bạn liệt kê các lợi ích kinh doanh mà dự án phần mềm sẽ cung cấp. Chúng có thể được liệt kê ở dạng dấu đầu dòng miễn là chúng phù hợp với các mục tiêu tổng thể. Họ phải chứng minh phần mềm hoặc hệ thống sẽ nâng cao giá trị doanh nghiệp như thế nào.
Tóm lại, giải pháp được đề xuất sẽ giúp doanh nghiệp thành công hơn và đạt được các mục tiêu đã đề ra như thế nào? Sử dụng các từ và câu tích cực.
Ràng buộc
Phần ràng buộc nên liệt kê bất kỳ ràng buộc hữu hình và vô hình nào mà bạn có thể thấy trước. Điều này có thể liên quan đến thiết bị, một số yếu tố thời vụ như một nhà máy sản xuất đóng cửa mà hầu hết các nhà máy làm ít nhất một lần một năm là một ví dụ.
Cố gắng giảm bớt các ràng buộc hoặc sơn chúng ở mức tối thiểu. Không liệt kê bất kỳ khía cạnh tiêu cực nào của phần mềm hoặc hệ thống hoặc nếu bạn phải liệt kê, sau đó cung cấp các giải pháp thay thế.
© 2012 Kevin Languedoc