6

ใช้ MRD เพื่อควบคุมการเอาท์ซอร์สของคุณ

ใช้ MRD เพื่อควบคุมการเอาท์ซอร์สของคุณ

กระบวนการพัฒนาซอฟต์แวร์ของคุณไม่แน่นอนเหมือนสภาพอากาศหรือไม่? ซอฟต์แวร์ของคุณใช้งานได้นานกว่าหกสัปดาห์หรือไม่? คุณใช้เอกสารข้อกำหนดทางการตลาด (MRD) หรือเวทย์มนตร์เพื่อทำนายกำหนดการเปิดตัวซอฟต์แวร์หรือไม่?

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

ฉันหยุดชั่วคราวและพยายามจดจำว่าการปรับความถี่ถูกใช้จริง ๆ ในวงจรเหล่านี้หรือไม่ ก่อนที่ฉันจะตอบคนจาก HP พูดต่อว่า “ใช่มันต้องใช้เวทมนตร์มากมายเพื่อให้วงจรเหล่านั้นทำงาน!”

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

ตั้งแต่นั้นมาฉันได้ทำงานในหลายโครงการที่จำเป็นต้องใช้ “FM” จำนวนหนึ่งเพื่อให้ซอฟต์แวร์วางจำหน่าย

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

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

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

แต่หลายคนยังคงกลัวจ้าง ข้อกังวลอันดับหนึ่งคือการสูญเสียการควบคุมกระบวนการพัฒนาซอฟต์แวร์

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

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

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

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

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

MRD หรือ PRD ควรมีสถาปัตยกรรมพื้นฐานและส่วนต่อประสานผู้ใช้ที่สำคัญสำหรับซอฟต์แวร์ของคุณ:

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

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