วิธีการเขียนข้อเสนอการพัฒนาซอฟต์แวร์

วิธีการเขียนข้อเสนอการพัฒนาซอฟต์แวร์ที่ประสบความสำเร็จ

Kevin Languedoc

จุดประสงค์ของข้อเสนอการพัฒนาซอฟต์แวร์คือการถ่ายทอดวิธีการแก้ปัญหาที่นักธุรกิจจะอ่านดังนั้นควรทำให้ง่ายและตรงประเด็น อยู่ห่างจากคำศัพท์ทางเทคนิคให้มากที่สุด สามารถใช้โครงร่างต่อไปนี้เพื่อเตรียมข้อเสนอการพัฒนาซอฟต์แวร์ที่ประสบความสำเร็จ สิ่งสำคัญคือต้องจำไว้ว่าคนที่คุณจะนำเสนอข้อเสนอนั้นไม่มีเวลาอ่านเอกสารที่มีความยาวมากนัก คุณสามารถนำไปจากฉันฉันได้เขียนข้อเสนอหลายร้อยข้อในช่วง 20 ปีบวกของเทคโนโลยีสารสนเทศ: นักธุรกิจต้องการข้อมูลที่เพียงพอเพื่อให้พวกเขาตัดสินใจอย่างมีข้อมูล

หากคุณกำลังตอบกลับคำร้องขอข้อเสนอ (RFP) และต้องปฏิบัติตามช่วงของหน้าบางช่วงเนื่องจากหน้านั้นพิมพ์ไว้ล่วงหน้าหรือข้อกำหนดด้านเนื้อหาบังคับให้คุณต้องมีข้อเสนอที่ยาวเกินไปให้พิจารณาใช้บทสรุปสำหรับผู้บริหาร ฉันได้เพิ่มส่วนที่อธิบายวิธีการเตรียมไว้ด้านล่าง

ความยาวของข้อเสนอ

ฉันได้เห็นเทมเพลตและการอภิปรายที่สนับสนุนข้อเสนอที่ทำงานเป็นเวลา 50 หน้าหรือหลายหน้า เชื่อฉันเถอะว่าคุณจะสูญเสียความสนใจของผู้บริหารธุรกิจหลังจากหน้าที่ห้า เมื่อข้อเสนอได้รับการยอมรับเอกสารการออกแบบจะมีรายละเอียดมากขึ้นตามธรรมชาติเนื่องจากจะถูกกำหนดไว้สำหรับทีมโครงการและจะเป็นพิมพ์เขียวที่ใช้งานได้สำหรับระบบ สิ่งนี้จะใช้กับลูกค้าส่วนใหญ่ แต่ (ใช่มีเสมอ แต่) หากข้อเสนอเป็นไปตามคำร้องขอข้อเสนอ (RFP) คุณจะต้องปฏิบัติตาม RFP นอกจากนี้หน่วยงานของรัฐบาลหรือทหารอาจมีแนวทางที่เข้มงวดในการจัดเตรียมข้อเสนอการพัฒนาซอฟต์แวร์และอาจมีหลายหน้า (10, 20, 30, 50 หรือมากกว่า) ขึ้นอยู่กับความซับซ้อนของระบบกฎนี้ยังคงเป็นจริงสำหรับองค์กรขนาดใหญ่ที่อาจมีขั้นตอนการเสนออย่างเป็นทางการโดยเฉพาะอย่างยิ่งหากเป็น บริษัท มหาชนและต้องปฏิบัติตามกฎข้อบังคับหรือมาตรฐานของ Sarbannes-Oxley หรือ ISO

บทสรุปสำหรับผู้บริหาร

หากข้อเสนอมีมากกว่า 20 หน้าคุณอาจพิจารณาให้ Executive Summary ซึ่งเป็นเพจเจอร์หน้าเดียวของส่วนต่างๆในข้อเสนอ คุณยังสามารถจัดเตรียมข้อมูลสรุปสำหรับผู้บริหารในรูปแบบ PowerPoint หากคุณกำลังวางแผนที่จะใช้บทสรุปสำหรับผู้บริหารในการนำเสนอข้อเสนอการพัฒนาซอฟต์แวร์ให้นำเสนอข้อเสนอโดยใช้บทสรุปสำหรับผู้บริหารและผู้บริหารสามารถอ่านข้อเสนอได้ในเวลาต่อมาเช่นในระหว่างการเดินทางเพื่อธุรกิจ

เทมเพลต

โครงร่างต่อไปนี้เป็นเทมเพลตที่ดีที่คุณสามารถใช้เพื่อเตรียมข้อเสนอการพัฒนาซอฟต์แวร์ของคุณเอง ฉันมักจะคำนึงถึงกฎ Elevator Pitch เมื่อเตรียมข้อเสนอและคุณก็ควรทำเช่นกัน โดยทั่วไปสนามลิฟต์กำหนดว่าข้อเสนอของคุณไม่ควรนานเกินกว่าเวลาที่ใช้ในการขึ้นลิฟต์จากชั้นล่างไปชั้นบนสุดของอาคารระหว่างทางของคุณเพื่อนำเสนอข้อเสนอ

ชื่อโครงการ

ด้วยคำบรรยายหรือข้อมูลสรุปเกี่ยวกับข้อเสนอ

ข้อเสนอควรมีชื่อเรื่องและส่วนย่อยที่สรุปบริบทของข้อเสนอซอฟต์แวร์ นอกจากนี้คุณยังระบุชื่อแผนกบริการแผนกหรือองค์กรที่โครงการมีไว้สำหรับ

หากคุณกำลังตอบสนองต่อ RFP (ขอข้อเสนอ) ให้รวมข้อมูลใด ๆ ที่จำเป็นหรือระบุว่าจำเป็นใน RFP ฉันยังได้เห็น RFP ที่ขอให้คุณใส่ลายเซ็นการอนุมัตินอกเหนือจากชื่อในหน้าแรก แต่ในตัวอย่างนี้ฉันใส่ลายเซ็นในหน้าพร้อมกับส่วนการเปลี่ยนแปลง

สารบัญ

ในหน้าถัดไปคุณควรรวมสารบัญซึ่งแสดงรายการส่วนหลัก ๆ ของข้อเสนอ คุณสามารถเลือกที่จะรวมหมายเลขหน้าได้หากข้อเสนอเกินห้าหน้าหรือหาก RFP ต้องการ

การอนุมัติ

ส่วนนี้มีความสำคัญอย่างยิ่งต่อกระบวนการไม่ว่าจะเป็นการตอบสนองต่อ RFP หรือจากเทมเพลตนี้หรือจากแหล่งอื่น ๆ ส่วนนี้เป็นเอกสารยืนยันว่าโครงการเป็นไปได้และให้ข้อตกลงที่มีผลผูกพันระหว่างสมาชิกต่างๆของโครงการ คุณไม่ควรเริ่มโครงการจนกว่าคุณจะได้รับลายเซ็นที่จำเป็นทั้งหมดและมีคำมั่นสัญญาจากแชมป์โครงการและผู้มีส่วนได้ส่วนเสียในการเริ่มโครงการ มิฉะนั้นคุณอาจพบว่าตัวเองถูกผูกมัดหากโปรเจ็กต์ถูกยกเลิกหรือขอบเขตของโปรเจ็กต์เปลี่ยนแปลงไปหรือสิ่งที่ส่งมอบ

เมื่อมีการอนุมัติแล้วขอบเขตและการส่งมอบการเปลี่ยนแปลงจะทำได้ยากกว่ามากและหากมีข้อพิพาทการลงนามการอนุมัติจะช่วยให้เข้าใจสิ่งที่ตกลงกัน แน่นอนว่ามีคำถามในการตีความเสมอ

การอนุมัติควรมีชื่อของบุคคลชื่อของบุคคลนั้นตามด้วยลายเซ็นและสุดท้ายวันที่ลงนามในเอกสาร



ชื่อ	ชื่อเรื่อง / บทบาท	ลายเซ็น	วันที่

การเปลี่ยนแปลง

ส่วนการเปลี่ยนแปลงจะให้บันทึกการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นหรือจะทำในเอกสารข้อเสนอการพัฒนาซอฟต์แวร์ ไม่มีเอกสารการเปลี่ยนแปลงใด ๆ ในขอบเขตของโครงการเองหรือด้านอื่น ๆ ของโครงการ ส่วนการเปลี่ยนแปลงควรมีอย่างน้อยชื่อของบุคคลที่ทำการเปลี่ยนแปลงวันที่ของการเปลี่ยนแปลงและความคิดเห็นหรือคำอธิบายของการเปลี่ยนแปลง



ผู้เขียน	วันที่เปลี่ยนแปลง	คำอธิบายหรือความคิดเห็น

อภิธานศัพท์และคำย่อ

ระบุคำศัพท์หรือคำย่อและคำจำกัดความ อย่าคิดว่าทุกคนรู้ความหมายของคำศัพท์หรือคำย่อโดยเฉพาะอย่างยิ่งหากคุณกำลังวางแผนที่จะใช้ที่ปรึกษาภายนอกและคำศัพท์นั้นเป็นคำภายในที่ฝังอยู่ในวัฒนธรรมองค์กรและศัพท์แสงของคุณ ทุกองค์กรมีศัพท์แสงและคำย่อของตัวเอง สามารถใช้ในข้อเสนอได้ตราบเท่าที่มีการจัดทำเอกสารอย่างถูกต้อง

นอกจากนี้หากมีการใช้คำย่อเฉพาะอุตสาหกรรมก็จำเป็นต้องจัดทำเป็นเอกสารเช่นกันเพื่อให้ทุกคนมีความเข้าใจอย่างชัดเจนเกี่ยวกับความหมายของคำศัพท์และคำย่อและกำหนดรูปแบบการตีความที่ดีขึ้น

คำย่อต่อไปนี้มาจากเทมเพลตปัจจุบัน มีไว้เป็นตัวอย่าง

RFP: ขอข้อเสนอ
ROI: ผลตอบแทนจากการลงทุน
CAGR: อัตราการเติบโตต่อปี
ไอที: เทคโนโลยีสารสนเทศ
CAPEX: รายจ่ายลงทุน
UoM: หน่วยวัด

ขอบเขต

ขอบเขตของข้อเสนอควรสรุปรายละเอียดโครงการโดยรวมสิ่งที่รวมและยกเว้นไว้ในระดับสูง ขอบเขตควรให้คำอธิบายโดยรวมความยาวของโครงการวัตถุประสงค์หลัก คุณพยายามทำอะไรให้สำเร็จด้วยการลงทุนในโครงการพัฒนาซอฟต์แวร์ที่เสนอนี้

เส้นเวลา

ส่วนนี้จะรวมวันที่เริ่มต้นและวันที่สิ้นสุด (โดยประมาณ) อย่าลืมสร้างในบัฟเฟอร์และวางแผนสำหรับเหตุการณ์ฉุกเฉิน กฎของ Thumb ที่ดีคือการเพิ่มบัฟเฟอร์ 75% ในไทม์ไลน์ของคุณ

สมาชิกโครงการ

สมาชิกโครงการควรประกอบด้วยแชมป์โครงการและผู้มีส่วนได้ส่วนเสีย แชมป์มักจะเป็นผู้บริหารที่ขับเคลื่อนโครงการและงบประมาณโดยรวม ผู้มีส่วนได้ส่วนเสียมักเป็นผู้ส่งเสริมหรือผู้สนับสนุนภายใน นอกจากนี้ยังสามารถเป็นแชมป์ได้โดยขึ้นอยู่กับขอบเขตของโครงการและหรือประเภทขององค์กรที่ขอข้อเสนอการพัฒนาซอฟต์แวร์ รายการที่เหลือประกอบด้วยบทบาททั่วไปที่ผู้คนดำเนินการในโครงการ

ต่อไปนี้เป็นเพียงตัวอย่างของประเภทบทบาทที่ผู้เข้าร่วมโครงการอาจมี บางคนอาจมีมากกว่าหนึ่งบทบาท รายชื่อสมาชิกโครงการอาจมีความยาวมากหรือบุคคลคนเดียวกันอาจมีบทบาทที่แตกต่างกันทั้งนี้ขึ้นอยู่กับขอบเขตของโครงการ

รายการควรมีข้อมูลที่ระบุตัวบุคคลได้อย่างเหมาะสมบทบาทของพวกเขาภายในโครงการวิธีการเข้าถึงและความรับผิดชอบของพวกเขาคืออะไร คุณสามารถใส่ข้อมูลอื่น ๆ ได้โดยขึ้นอยู่กับ RFP หรือประเภทขององค์กรที่คุณจะทำงานด้วยและนโยบายภายในขององค์กรนั้น ๆ



สมาชิกในทีม	บทบาท	ข้อมูลติดต่อ	หน้าที่ความรับผิดชอบ
	แชมป์
	ผู้มีส่วนได้ส่วนเสีย
	ผู้จัดการโครงการ
	สถาปนิก
	นักวิเคราะห์
	นักพัฒนา

โอกาสทางธุรกิจ

แม่แบบส่วนใหญ่ที่มีให้กำหนดส่วนนี้ว่า“ ปัญหาทางธุรกิจ” หรือ“ คำชี้แจงปัญหา” แต่ฉันมักจะพบผู้นำทางธุรกิจที่รู้สึกขุ่นเคืองว่าพวกเขามีปัญหาในหน่วยธุรกิจหรือกระบวนการ ฉันจำได้ว่าผู้อำนวยการคนหนึ่งโยนฉันออกจากที่ทำงานของเธอเพราะฉันบอกว่าเรากำลังแก้ไขกระบวนการและเธอบอกฉันว่าจะไม่ใช่คนจากไอที (เทคโนโลยีสารสนเทศ) ที่จะคอยสั่งถ้าเธอมีปัญหา ด้วยกระบวนการของเธอหรือไม่

ดังนั้นระวังคำพูด ฉันใช้คำว่า“ โอกาสทางธุรกิจ” เสมอเพราะท้ายที่สุดแล้วข้อเสนอนี้ตอบสนองต่อโอกาสทางธุรกิจในการปรับปรุงกระบวนการสนับสนุนกระบวนการหรือทำให้กระบวนการทำงานอัตโนมัติ



คำชี้แจงทางธุรกิจ	ระบบจะตอบสนองความต้องการได้อย่างไร
กระบวนการทางธุรกิจสถานการณ์ปัญหาที่ได้รับผลกระทบ	วิธีการแก้ปัญหาที่เสนอจะปรับปรุงพื้นที่ธุรกิจเป้าหมาย
สิ่งที่จำเป็นกำลังได้รับการแก้ไข	โครงการปัจจุบันจะจัดการกับมันอย่างไร

ภาพรวมโซลูชัน

ในส่วนภาพรวมโซลูชันคุณสามารถให้ภาพรวมระดับสูงของระบบได้ ภาพรวมนี้อาจรวมถึงแผนที่การนำทางหากข้อเสนอสำหรับเว็บไซต์หรือเว็บแอป คุณยังสามารถรวมผังงานของโฟลว์กระบวนการ นอกจากนี้คุณสามารถรวมไดอะแกรมของส่วนประกอบหลักของระบบ

วัตถุประสงค์ในที่นี้คือเพื่อให้ผู้ที่ทำการตัดสินใจมีข้อมูลเพียงพอเพื่อให้พวกเขาเข้าใจว่าระบบคืออะไรมันจะทำงานอย่างไรและอะไรคือองค์ประกอบหลักที่สำคัญ แน่นอนว่านี่เป็นเพียงแนวทางปฏิบัติเนื่องจากองค์กรอาจมีรูปแบบที่เป็นทางการที่กำหนดสิ่งที่คุณจะต้องส่งในข้อเสนอโดยเฉพาะอย่างยิ่งคุณกำลังติดต่อกับหน่วยงานของรัฐหรือกระทรวงกลาโหม

คุณสมบัติและสิ่งที่ส่งมอบ

ส่วนนี้ให้กลไกในการแมปคุณลักษณะของระบบที่นำเสนอกับการส่งมอบที่จับต้องได้ ฉันยังเห็นส่วนนี้มีการประมาณเวลาเพื่อให้การส่งมอบเสร็จสมบูรณ์ แต่ฉันไม่ชอบใช้สิ่งนี้เพราะมีข้อ จำกัด เกินไปและทำให้เกิดความสัมพันธ์กันเมื่อทำงานในโครงการสิ่งที่ส่งมอบอาจไม่ตรงตามที่เขียนไว้ ดังนั้นหากคุณมีความมุ่งมั่นบนกระดาษที่จะเสร็จสิ้นการส่งมอบในช่วงเวลาหนึ่งมันจะลบหรือลดความยืดหยุ่นใด ๆ ในภายหลังเมื่อคุณกำลังทำโครงการจริงๆ

คอลัมน์อื่นที่สามารถเพิ่มได้คือรุ่นที่ส่งมอบได้ สิ่งนี้มีประโยชน์หากจะส่งมอบโครงการในช่วงเวลาที่ยาวนานขึ้นและจะมีการเผยแพร่หลายฉบับ นอกจากนี้ยังสามารถนำไปใช้กับโปรเจ็กต์แบบ Agile หรือ Lean ที่แต่ละฟีเจอร์หรือ User Story เป็นของ Release

แนวคิดนั้นเรียบง่าย สำหรับแต่ละคุณลักษณะในระบบระบุชื่อของคุณลักษณะคำอธิบายสั้น ๆ และสิ่งที่ส่งมอบได้จะเป็นไปตามข้อกำหนดคุณลักษณะ



ลักษณะเฉพาะ	คำอธิบาย	ส่งมอบได้

งบประมาณและ ROI

งบประมาณและ ROI น่าจะเป็นส่วนที่สำคัญที่สุดสำหรับผู้บริหารบางคน พวกเขาทุกคนต่างกังวลที่จะทราบว่าระบบจะต้องเสียค่าใช้จ่ายเท่าใดหรือโครงการนี้จะมีผลกระทบต่องบประมาณของแผนกเท่าใด โดยเฉพาะอย่างยิ่งหากโครงการไม่ได้รวมอยู่ใน Capex เมื่อต้นปีงบประมาณ

บางครั้งแม้ว่าโครงการจะได้รับงบประมาณสำหรับโครงการอื่นอาจมีความสำคัญเหนือกว่าข้อเสนอปัจจุบันและเงินสามารถโอนจากแหล่งที่มาที่ต้องการได้ มักจะมีการทะเลาะวิวาททางการเมืองเกิดขึ้นในระดับผู้บริหารและระดับบริหารเพื่อให้โครงการเริ่มต้นขึ้นและมักจะมีสถานการณ์ที่ไม่คาดฝันซึ่งอาจมีความสำคัญเหนือกว่าโครงการที่วางแผนไว้

ดังนั้นเตรียมพร้อมที่จะทำงานร่วมกับผู้มีส่วนได้ส่วนเสียของคุณเพื่อช่วยในการเจรจาหรือมีความยืดหยุ่นและเป็นเชิงรุกเพื่อจัดหาแนวทางในการทำงานหากสถานการณ์ด้านงบประมาณไปด้านข้าง จะเป็นการดีกว่าที่จะปรับโครงการให้เข้ากับความเป็นจริงด้านงบประมาณแม้กระทั่งการกระจายสิ่งที่ส่งมอบของระบบในช่วงเวลาที่นานขึ้นหรือแม้แต่เดินออกไปจากโครงการ เดินออกไปดีกว่าทำงานในโครงการและไม่ได้รับเงินและต้องหันไปใช้การฟ้องร้องตามท้องถนน

ตารางต่อไปนี้ใช้เพื่อการสาธิตเท่านั้นเพื่อให้คุณทราบถึงวิธีการจัดเตรียมงบประมาณ โดยปกติคุณจะต้องเพิ่มรายการโฆษณาของคุณเองเพื่อให้เหมาะกับโครงการของคุณ จากนั้นกรอกปริมาณราคาต่อหน่วยหน่วยวัดและยอดรวมรายการโฆษณา จากนั้นรวบรวมผลรวมของรายการโฆษณาที่ด้านล่าง

สิ่งนี้จะให้ภาพที่ดีของการลงทุนที่จำเป็นในการทำโครงการซอฟต์แวร์ ผู้บริหารส่วนใหญ่ที่ฉันเคยทำงานด้วยต้องการทราบว่าอัตราผลตอบแทนจะเป็นเท่าไหร่หรือโครงการนี้จะมีค่าใช้จ่ายเท่าใดเมื่อเวลาผ่านไปดังนั้นฉันจึงรวมค่า ROI แบบง่ายและ CAGR โดยใช้ค่าประมาณและสมมติฐานของฉันเอง (ซึ่งต้องเป็น อธิบาย) ในข้อเสนอหรือใช้การประมาณการและสมมติฐานที่ตกแต่งแล้ว



รายการโครงการ	จำนวน	ราคาต่อหน่วย	UoM	รวม
ใบอนุญาตซอฟต์แวร์
เครื่อง (s)
สิทธิ์การใช้งานเซิร์ฟเวอร์
ใบอนุญาตฐานข้อมูล
ที่ปรึกษาด้านการพัฒนา
การบริหารโครงการ
การฝึกอบรม (เวลา + วัสดุ)

ROI

การคำนวณ ROI นั้นง่ายมาก โดยทั่วไปสูตรคือกำไร - ต้นทุนหารด้วยต้นทุน สูตรมีให้ด้านล่าง:

ข้อเสียเพียงอย่างเดียวคือการคำนวณไม่ได้คำนึงถึงเวลาดังนั้น ROI จึงดีสำหรับโครงการระยะสั้น แต่สำหรับโครงการระยะยาวฉันมักจะรวม CAGR (อัตราการเติบโตต่อปีแบบผสม) การคำนวณ CAGR คืออัตราผลตอบแทนปีต่อปีในช่วงเวลาหนึ่ง

CAGR

สูตร CAGR คือ:

ส่วนแรกคือการหารค่าสิ้นสุดด้วยค่าเริ่มต้น ผลลัพธ์ที่ได้จะเพิ่มขึ้นเป็น 1 ในจำนวนปีที่ลงทุน ค่าผลลัพธ์จะถูกลบด้วย 1

สิทธิประโยชน์

ในส่วนนี้คุณระบุผลประโยชน์ทางธุรกิจที่โครงการซอฟต์แวร์จะมอบให้ สามารถแสดงรายการในรูปแบบสัญลักษณ์แสดงหัวข้อย่อยได้ตราบเท่าที่เชื่อมโยงกับวัตถุประสงค์โดยรวม ควรแสดงให้เห็นว่าซอฟต์แวร์หรือระบบจะเพิ่มมูลค่าทางธุรกิจได้อย่างไร

สรุปได้อย่างไรว่าโซลูชันที่นำเสนอจะช่วยให้ธุรกิจประสบความสำเร็จและบรรลุวัตถุประสงค์ในการแถลงได้อย่างไร ใช้คำและประโยคเชิงบวก

ข้อ จำกัด

ส่วนข้อ จำกัด ควรแสดงรายการข้อ จำกัด ที่จับต้องได้และไม่มีตัวตนที่คุณสามารถคาดเดาได้ สิ่งนี้อาจเกี่ยวข้องกับอุปกรณ์ปัจจัยตามฤดูกาลบางอย่างเช่นโรงงานผลิตที่ปิดตัวลงซึ่งโรงงานส่วนใหญ่ทำอย่างน้อยปีละครั้งเป็นตัวอย่าง

พยายามมองข้ามข้อ จำกัด หรือวาดภาพให้เป็นเพียงเล็กน้อย อย่าแสดงรายการด้านลบใด ๆ ของซอฟต์แวร์หรือระบบหรือหากคุณจำเป็นต้องทำจากนั้นให้วิธีแก้ปัญหาเบื้องต้น