คุณจัดการคำขอคุณลักษณะและการเปลี่ยนแปลงซอฟต์แวร์ได้อย่างไร [ปิด]

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

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

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

ฉันมักจะจำแนกคำขอตามลำดับนี้ (YMMV):

1. ปัญหาที่เกี่ยวข้องกับการอัปเกรดหรือการย้ายข้อมูลล่าสุด (สำคัญที่สุด)
2. แก้ไขความปลอดภัย
3. ฟังก์ชั่นที่ใช้งานไม่ได้ของระบบที่มีอยู่
4. ฟังก์ชั่นที่ใช้งานไม่ได้ในคุณสมบัติ RC และเบต้า
5. คำขอคุณสมบัติที่ต้องชำระ
6. คำขอคุณลักษณะการวิจัยและพัฒนาจากส่วนใหญ่ของฐานผู้ใช้
7. คำขอคุณลักษณะการวิจัยและพัฒนาจากผู้ใช้เพียงหนึ่งหรือสองคน

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

ฉันชอบหลักการของ:

1. QI - สำคัญและเร่งด่วน
2. QII - สำคัญ แต่ไม่ด่วน
3. QIII - ไม่สำคัญ แต่เร่งด่วน
4. QIV - ไม่สำคัญและไม่ด่วน

1. ติดตั้งระบบติดตามคุณสมบัติ / ข้อบกพร่อง / คำขอและมีตั๋วไฟล์สำหรับลูกค้า / ผู้ร่วมงานของคุณ หากพวกเขาไม่ได้ยื่นตั๋วมันแสดงว่าคุณไม่ได้ทำมัน ตั๋วจะต้องมีรายละเอียดมากพอที่จะดำเนินการได้และต้องระบุ "ความเร่งด่วน" ("ฉันต้องการตอนนี้" กับ "ยินดีที่ได้มี")
2. ผ่านตั๋วใหม่และกำหนดขอบเขตอย่างระมัดระวัง ป้อนค่าใช้จ่ายในตั๋วเป็นดอลลาร์นักพัฒนาทรัพยากรและ / หรือเวลา นี้เป็นสิ่งจำเป็น เมื่อลูกค้าเห็นว่ามีค่าใช้จ่ายจริงคุณจะเห็นตัวเลือกที่แตกต่างกันมากในฟิลด์ "ความเร่งด่วน"
3. ในแต่ละวันให้คิดกำหนดการของคุณตามตั๋วที่ยื่น & เร่งด่วนของพวกเขา ทำให้คนอื่นเห็นตารางเวลาดังนั้นจึงชัดเจนว่าคุณทำอะไรอยู่และพร้อมใช้งานสำหรับคำขอในอนาคต

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

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

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

นี่คือความคิด ...

มีซอฟต์แวร์มากมายในตลาดที่ช่วยคุณhttp://www.fogcreek.com/ด้วย Fogbugz, GeneXus USA พร้อม XPM http://www.genexususa.com/xpmเป็นต้น

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

คุณมีเวลาทรัพยากรและขอบเขตทำให้ดีที่สุด

เฮนรี่ฟอร์ดเคยกล่าวไว้ว่า "ถ้าฉันฟังลูกค้าฉันจะให้ม้าที่เร็วขึ้นแก่พวกเขา" ...

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

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

บริษัท ที่ฉันทำงานเพื่อใช้สองแอปพลิเคชันหลักซึ่งเป็นเครื่องมือบนเว็บที่เรียกว่า JIRA เพื่อจัดการด้านที่เกี่ยวข้องกับโครงการและระบบโต๊ะช่วยเหลือของเราเพื่อจัดการการร้องขอการเปลี่ยนแปลงผ่านทางฟังก์ชั่น rfc

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

หากคุณอนุญาตให้ลูกค้าตั้งค่าความเร่งด่วนมันจะเกือบจะ "สูง" (หรือมากกว่า) เสมอ

คุณ (ตัวคุณเองหรือทีมขึ้นอยู่กับการตั้งค่าของคุณ) จะต้องประเมินคำขอเหล่านี้และจัดลำดับความสำคัญตามเกณฑ์ของคุณเอง