การวิเคราะห์ธุรกิจ - การจัดการความต้องการ

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

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

เหตุใดโครงการจึงล้มเหลว

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

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

แก่นของปัญหาคือโครงการมีความซับซ้อนมากขึ้นการเปลี่ยนแปลงเกิดขึ้นและการสื่อสารเป็นสิ่งที่ท้าทาย

เหตุใดทีมที่ประสบความสำเร็จจึงจัดการความต้องการ

การจัดการความต้องการเป็นเรื่องเกี่ยวกับการรักษาทีมของคุณ in-sync และให้ visibility กับสิ่งที่เกิดขึ้นภายในโครงการ

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

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

เริ่มต้นด้วยพื้นฐาน

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

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

ความต้องการระดับสูงบางครั้งเรียกง่ายๆว่า needs หรือ goals. ภายในแนวทางปฏิบัติในการพัฒนาซอฟต์แวร์ข้อกำหนดอาจเรียกว่า "กรณีการใช้งาน" "คุณลักษณะ" หรือ "ข้อกำหนดด้านการทำงาน" โดยเฉพาะอย่างยิ่งในวิธีการพัฒนาแบบคล่องตัวข้อกำหนดมักถูกจับเป็นepics และ stories.

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

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

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

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

• การวางแผนข้อกำหนดที่ดี:“ เรากำลังสร้างอะไรกันแน่”
• การทำงานร่วมกันและการซื้อใน:“ แค่อนุมัติสเป็คแล้ว!”
• การตรวจสอบย้อนกลับและการจัดการการเปลี่ยนแปลง:“ เดี๋ยวก่อนนักพัฒนารู้ไหมว่ามีการเปลี่ยนแปลงหรือไม่”
• การประกันคุณภาพ:“ สวัสดีมีใครทดสอบสิ่งนี้บ้างไหม”

ทุกคนรู้หรือไม่ว่าเรากำลังสร้างอะไรและทำไม? นั่นคือคุณค่าของการจัดการความต้องการ

การทำงานร่วมกันและการซื้อจากผู้มีส่วนได้ส่วนเสีย

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

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

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

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

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

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